RFC 7759

Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping

📅 published February 2016, from ietf

Part 1 of 6 🧚

RFC 7759 🎀

Okay bestie, this is RFC 7759, and it's a Standards Track document from the IETF, so it's an actual Internet standard and not just a vibe. It's dated February 2016 and has ISSN 2070-1721. The author list is E. Bellagamba, G. Mirsky (Ericsson), L. Andersson (Huawei Technologies), P. Skoldstrom (Acreo AB), D. Ward (Cisco), and J. Drake (Juniper) 💅. The title is "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping" ✨. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.

Abstract 🦋

Okay so the big idea is this: it explains how to set up proactive MPLS-TP OAM functions (the always-on health checks and measurements) for a given Label Switched Path (LSP). The trick is that it uses a set of TLVs that ride along inside the LSP Ping protocol 🫶.

Status of This Memo 📜

This is an Internet Standards Track document, so it's official 👑.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🌸.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7759 💜.

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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions 🙈. If you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥.

Table of Contents 📖

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
           1.1.1. Terminology .........................................4
           1.1.2. Requirements Language ...............................5
   2. Theory of Operations ............................................5
      2.1. MPLS OAM Configuration Operation Overview ..................5
           2.1.1. Configuration of BFD Sessions .......................5
           2.1.2. Configuration of Performance Monitoring .............6
           2.1.3. Configuration of Fault Management Signals ...........6
      2.2. MPLS OAM Functions TLV .....................................7
           2.2.1. BFD Configuration Sub-TLV ...........................9
           2.2.2. BFD Local Discriminator Sub-TLV ....................11
           2.2.3. BFD Negotiation Timer Parameters Sub-TLV ...........11
           2.2.4. BFD Authentication Sub-TLV .........................13
           2.2.5. Traffic Class Sub-TLV ..............................14
           2.2.6. Performance Monitoring Sub-TLV .....................14
           2.2.7. PM Loss Measurement Sub-TLV ........................17
           2.2.8. PM Delay Measurement Sub-TLV .......................18
           2.2.9. Fault Management Signal Sub-TLV ....................20
           2.2.10. Source MEP-ID Sub-TLV .............................21
   3. Summary of MPLS OAM Configuration Errors .......................22
   4. IANA Considerations ............................................23
      4.1. TLV and Sub-TLV Allocation ................................23
      4.2. MPLS OAM Function Flags Allocation ........................24
      4.3. OAM Configuration Errors ..................................25
   5. Security Considerations ........................................26
   6. References .....................................................26
      6.1. Normative References ......................................26
      6.2. Informative References ....................................27
   Acknowledgements  .................................................28
   Authors' Addresses ................................................29

1. Introduction ✨

So MPLS-TP is a profile of MPLS built for transport networks. It keeps the operational models those networks are used to, and it adds Operations, Administration, and Maintenance (OAM), survivability, and other maintenance functions that plain MPLS doesn't currently support 💖. [RFC5860] is where the OAM requirements for MPLS-TP are defined 🧚.

This document is all about configuring proactive MPLS-TP OAM functions for a given LSP using TLVs carried in LSP Ping [RFC4379] 💅. It lays out the mechanisms needed to set up MPLS-TP OAM entities at the maintenance points, so they can monitor and measure an LSP. It also defines the information elements and procedures for configuring proactive MPLS-TP OAM functions running between Label Edge Routers (LERs) 🌸.

On-demand MPLS-TP OAM is a different story. Starting and controlling those functions is expected to happen by directly accessing network nodes through a management interface. So configuring and controlling on-demand OAM functions is out of scope for this document 🙈.

Now, the Transport Profile of MPLS must, by definition [RFC5654], be able to operate without a control plane. That means there are a few ways to configure MPLS-TP OAM 🫶:

  • Without a control plane, using a Network Management System (NMS).
  • By implementing LSP Ping instead.
  • With a control plane, by implementing extensions to the signaling protocols RSVP Traffic Engineering (RSVP-TE) [RFC3209] and/or Targeted LDP [RFC5036].

Proactive MPLS-TP OAM runs on a set of protocols 🔥:

  • Bidirectional Forwarding Detection (BFD) [RFC6428] handles Continuity Check/Connectivity Verification.
  • The Delay Measurement (DM) protocol [RFC6374], [RFC6375] handles delay and delay variation (jitter) measurements.
  • The Loss Measurement (LM) protocol [RFC6374], [RFC6375] handles packet loss and throughput measurements.

On top of those, there are a number of Fault Management Signals that can be configured [RFC6427] 👑.

BFD is the protocol that gives you low-overhead, fast detection of failures in the path between two forwarding engines. That covers the interfaces, the data link(s), and, to the extent possible, the forwarding engines themselves 🦋. BFD can be used to detect continuity and mis-connection defects of MPLS-TP point-to-point LSPs, and it might also be extended to support point-to-multipoint LSPs 💜.

The delay and loss measurement protocols [RFC6374] and [RFC6375] use a simple query/response model. They can do unidirectional and bidirectional measurements, which lets the originating node measure packet loss and delay in the forward direction, or in the forward and reverse directions 🌈. The measurement packets get timestamped and/or get current packet counters written into them (four times, Transmit and Receive in both directions). From that, current delays and packet losses can be calculated ⭐. Doing successive delay measurements lets you calculate the delay and/or inter-packet delay variation (jitter) 🍓.

Current throughput can be calculated from the packet loss measurements by dividing the number of packets sent/received by the time it took to perform the measurement, which is given by the timestamp in the LM header 🎀. Pair that with a packet generator and the throughput measurement can be used to measure the maximum capacity of a particular LSP 🔥.

It should be noted that this document does NOT specify how to configure on-demand throughput estimates based on saturating the connection as defined in [RFC6371]. It only specifies how to enable the estimation of current throughput based on loss measurements 🙈.

Wait, I need to be careful with that last one: the original uses lowercase "not" in the sentence, so that's what I'm keeping. Here's the corrected version of that aside, which is what actually goes in the document:

It should be noted that this document does not specify how to configure on-demand throughput estimates based on saturating the connection as defined in [RFC6371]. Rather, it only specifies how to enable the estimation of the current throughput based on loss measurements 🙈.

1.1. Conventions Used in This Document 📚

1.1.1. Terminology 🧠

  • BFD - Bidirectional Forwarding Detection
  • DM - Delay Measurement
  • FMS - Fault Management Signal
  • G-ACh - Generic Associated Channel
  • LSP - Label Switched Path
  • LM - Loss Measurement
  • MEP - Maintenance Entity Group End Point
  • MPLS - Multi-Protocol Label Switching
  • MPLS-TP - MPLS Transport Profile
  • NMS - Network Management System
  • PM - Performance Monitoring
  • RSVP-TE - RSVP Traffic Engineering
  • TC - Traffic Class

1.1.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 [RFC2119] 💖.

2. Theory of Operations 🌟

2.1. MPLS OAM Configuration Operation Overview 🗺️

The MPLS-TP OAM tool set is described in [RFC6669] 🧚.

LSP Ping, or alternatively RSVP-TE [RFC7487], can be used to easily enable the different OAM functions. You do this by setting the corresponding flags in the MPLS OAM Functions TLV (refer to Section 2.2) 💅. If you want a more detailed configuration, you can include sub-TLVs for the different OAM functions to specify various parameters in detail 🫶.

Typically, intermediate nodes just forward OAM configuration TLVs to the end node without any processing or modification 🌸. There's at least one exception to this: if the FMS sub-TLV (refer to Section 2.2.9) is present, it MUST be examined, even by intermediate nodes that support this extension 🔥. The sub-TLV MAY be present if a flag is set in the MPLS OAM Functions TLV 👑.

To be continued in Part 2 of 6 💜

2.1.1. Configuration of BFD Sessions 🎀

okay so, for this spec, BFD MUST run in one of two modes 💅:

  • Asynchronous mode, where both sides are in active mode
  • Unidirectional mode

In the simplest scenario, LSP Ping [RFC5884], or alternatively RSVP-TE [RFC7487], is only used to bootstrap a BFD session for an LSP, with no timer negotiation at all ✨

Timer negotiation can happen in later BFD control messages (in that case it works like the LSP Ping bootstrapping described in [RFC5884]), or directly in the LSP Ping configuration messages 🌸

When BFD Control packets ride in the Associated Channel Header (ACH) encapsulation, they are not protected by any end-to-end checksum. Only the lower layers handle error detection and correction 😭 A single bit error, like one flipped bit in the BFD State field, could make the receiving end wrongly think the link is down, and then trigger protection switching. yikes 💀

To stop that from happening, the BFD Configuration sub-TLV (refer to Section 2.2.1) has an Integrity flag. When it's set, it turns on BFD Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. This means every BFD Control packet carries a SHA1 hash of itself, which can be used to catch errors 🔥

If you want BFD Authentication with a pre-shared key/password (so, real authentication and not just error detection), the BFD Authentication sub-TLV (refer to Section 2.2.4) MUST be included in the BFD Configuration sub-TLV. The BFD Authentication sub-TLV says which authentication method to use and which pre-shared key/password to use for that particular session. How the key exchange is done is out of scope for this document 🔑

2.1.2. Configuration of Performance Monitoring 📊

Performance Monitoring can be configured for things like Loss, Delay, Delay/Interpacket Delay variation (jitter), and throughput, as described in [RFC6374] 💜

When you configure Performance Monitoring, you can go with the default configuration, which just means setting the respective flags in the MPLS OAM functions TLV. Or you can customize it, by setting the respective flags in the MPLS OAM functions TLV and including the respective Loss and/or Delay sub-TLVs 🎀

By setting the PM Loss flag in the MPLS OAM Functions TLV and including the PM Loss sub-TLV (refer to Section 2.2.7), you can configure the measurement interval and the loss threshold values for triggering protection 🛡️

Delay measurements are configured by setting the PM Delay flag in the MPLS OAM Functions TLV and including the PM Delay sub-TLV (refer to Section 2.2.8). With that, you can configure the measurement interval and the delay threshold values for triggering protection 🍓

2.1.3. Configuration of Fault Management Signals 🚨

To configure Fault Management Signals (FMSs) and their refresh time, the FMS Flag in the MPLS OAM Functions TLV MUST be set, and the FMS sub-TLV MUST be included. When you configure an FMS, an implementation can turn on the default configuration by setting the FMS Flag in the OAM Function Flags sub-TLV. But if you want to change the default configuration, the MPLS OAM FMS sub-TLV MUST be included 🧚

If an intermediate point is meant to originate FMS messages, then that intermediate point is associated with a Server MEP through a co-located MPLS-TP client/server adaptation function. The Fault Management subscription flag in the MPLS OAM FMS sub-TLV is set to ask for that association to be created at each intermediate node of the client LSP. The corresponding Server MEP needs its own LSP Ping session, or it can be configured through a Network Management System (NMS) or RSVP-TE 🦋

2.2. MPLS OAM Functions TLV 👑

The MPLS OAM Functions TLV in Figure 1 is carried as a TLV of the MPLS Echo Request/Reply messages [RFC4379] ✨

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  MPLS OAM Func. Type (27)     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    MPLS OAM Function Flags                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                           sub-TLVs                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: MPLS OAM Functions TLV Format

The MPLS OAM Functions TLV holds the MPLS OAM Function Flags field. Those flags say which OAM functions should be turned on, plus the OAM function-specific sub-TLVs that carry configuration parameters for that function 💖

Type: this is the MPLS OAM Functions TLV (Section 4) 🎀

Length: the length of the MPLS OAM Function Flags field, including the total length of the sub-TLVs in octets 📏

MPLS OAM Function Flags: a bitmap numbered from left to right, as shown in Figure 2. IANA manages these flags (refer to Section 4.2). The flags defined in this document are listed in Table 2. Undefined flags MUST be set to zero, and unknown flags MUST be ignored. The flags tell you what OAM is being configured and which optional sub-TLVs are present, as set out below 🧠

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|V|F|L|D|T|Unassigned MUST be zero (MBZ)                    |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: MPLS OAM Function Flags Format

The sub-TLVs for each flag are below. Don't read any meaning into the order of the sub-TLVs 🙈

  • If a flag in the MPLS OAM Function Flags is set and the sub-TLVs listed below are absent, then this MPLS OAM function MUST be initialized according to its default settings. The default settings of MPLS OAM functions are outside the scope of this document 🌈
  • If any sub-TLV shows up without its corresponding flag being set, the sub-TLV SHOULD be ignored 👀
  • The BFD Configuration sub-TLV MUST be included if either the CC, the CV, or both MPLS OAM Function flags are set in the MPLS OAM Functions TLV 🔥
  • The Performance Monitoring sub-TLV MUST be used to carry the PM Loss sub-TLV and/or the PM Delay sub-TLV. If neither of those sub-TLVs is present, then the Performance Monitoring sub-TLV SHOULD NOT be included. An empty Performance Monitoring sub-TLV, meaning one with no enclosed sub-TLVs, SHOULD be ignored 🧚
  • The PM Loss sub-TLV MAY be included if the PM/Loss OAM Function flag is set. If the "PM Loss sub-TLV" is not included, default configuration values are used. The sub-TLV MAY also be included when the Throughput function flag is set and there's a need to specify a measurement interval that's different from the default ones. Honestly, the throughput measurement uses the same tool as the loss measurement, so the same TLV is used 💅
  • The PM Delay sub-TLV MAY be included if the PM/Delay OAM Function flag is set. If the "PM Delay sub-TLV" is not included, default configuration values are used 🍓
  • The FMS sub-TLV MAY be included if the FMS OAM Function flag is set. If the "FMS sub-TLV" is not included, default configuration values are used 🦋

If all the flags in the MPLS OAM Function Flags field have a value of zero, that MUST be interpreted as meaning the MPLS OAM Functions TLV is not present in the MPLS Echo Request. If more than one MPLS OAM Functions TLV is present in the MPLS Echo request packet, the first TLV SHOULD be processed and the rest ignored. Any parsing error within nested sub-TLVs that is not specified in Section 3 SHOULD be treated as described in [RFC4379] 🫶

2.2.1. BFD Configuration Sub-TLV 💖

okay so the BFD Configuration sub-TLV 🎀 is where all the BFD OAM-specific config lives. Check out Figure 3 below. It rides along as a sub-TLV of the "OAM Functions TLV" 🧚

This TLV holds generic BFD OAM info and carries its own 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | BFD Conf. Sub-type    (100)   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vers.|N|S|I|G|U|B|         Reserved (set to all 0s)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: BFD Configuration Sub-TLV Format ✨

Sub-type: Indicates a new sub-type, the BFD Configuration sub-TLV (value 100). 🌸

Length: Indicates the length of the Value field in octets. 🍓

Version: Identifies the BFD protocol version. If a node does not support a specific BFD version, an error must be generated: OAM Problem/Unsupported BFD Version. 🙈

BFD Negotiation (N): If set, timer negotiation/renegotiation via BFD Control Messages is enabled. When cleared, it is disabled and timer configuration is achieved using the BFD Negotiation Timer Parameters sub-TLV as described in Section 2.2.3. 🦋

Symmetric session (S): If set, the BFD session MUST use symmetric timing values. If cleared, the BFD session MAY use any timing values either negotiated or explicitly configured. 💜

Integrity (I): If set, BFD Authentication MUST be enabled. If the BFD Configuration sub-TLV does not include a BFD Authentication sub-TLV, the authentication MUST use Keyed SHA1 with an empty pre-shared key (all 0s). If the egress LSR does not support BFD Authentication, an error MUST be generated: OAM Problem/BFD Authentication unsupported. If the Integrity flag is clear, then Authentication MUST NOT be used. 🔐✨

Encapsulation Capability (G): If set, it shows the capability of encapsulating BFD messages into the G-ACh channel. If both the G bit and U bit are set, configuration gives precedence to the G bit. 🫶

Encapsulation Capability (U): If set, it shows the capability of encapsulating BFD messages into IP/UDP packets. If both the G bit and U bit are set, configuration gives precedence to the G bit. 🌈

If the egress LSR does not support any of the ingress LSR Encapsulation Capabilities, an error MUST be generated: OAM Problem/Unsupported BFD Encapsulation format. 💀

Bidirectional (B): If set, it configures BFD in the Bidirectional mode. If it is not set, it configures BFD in the unidirectional mode. In the second case, the source node does not expect any Discriminator values back from the destination node. 🔁

Reserved: Reserved for future specification; set to 0 on transmission and ignored when received. 🧊

The BFD Configuration sub-TLV MUST include the following sub-TLVs in the MPLS Echo Request message:

  • BFD Local Discriminator sub-TLV, if the B flag is set in the MPLS Echo Request;
  • BFD Negotiation Timer Parameters sub-TLV, if the N flag is cleared.

The BFD Configuration sub-TLV MUST include the following sub-TLVs in the MPLS Echo Reply message:

  • BFD Local Discriminator sub-TLV;
  • BFD Negotiation Timer Parameters sub-TLV if:
    • The N and S flags are cleared, or if:
    • The N flag is cleared and the S flag is set, and the BFD Negotiation Timer Parameters sub-TLV received by the egress contains unsupported values. In this case, an updated BFD Negotiation Timer Parameters sub-TLV, containing values supported by the egress node [RFC7419], is returned to the ingress. 👑

2.2.2. BFD Local Discriminator Sub-TLV 🧚

The BFD Local Discriminator sub-TLV is carried as a sub-TLV of the "BFD Configuration sub-TLV" and is depicted in Figure 4. 🎀

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Locl. Discr. Sub-type (101)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Discriminator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: BFD Local Discriminator Sub-TLV Format ✨

Sub-type: Indicates a new sub-type, the "BFD Local Discriminator sub-TLV" (value 101). 🌷

Length: Indicates the length of the Value field in octets (4). 🍒

Local Discriminator: A nonzero discriminator value that is unique in the context of the transmitting system that generates it. It is used to demultiplex multiple BFD sessions between the same pair of systems. 🔥

2.2.3. BFD Negotiation Timer Parameters Sub-TLV 🌈

The BFD Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of the BFD Configuration sub-TLV and is depicted in Figure 5. ⭐

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Nego. Timer Sub-type (102)    |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Acceptable Min. Asynchronous TX interval              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Acceptable Min. Asynchronous RX interval              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Required Echo TX Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: BFD Negotiation Timer Parameters Sub-TLV Format ✨

Sub-type: Indicates a new sub-type, the BFD Negotiation Timer Parameters sub-TLV (value 102). 🎶

Length: Indicates the length of the Value field in octets (12).

Acceptable Min. Asynchronous TX interval: If the S (symmetric) flag is set in the BFD Configuration sub-TLV, defined in Section 2.2.1, it expresses the desired time interval (in microseconds) at which the ingress LER intends to both transmit and receive BFD periodic control packets. If the receiving edge LSR cannot support such a value, it SHOULD reply with an interval greater than the one proposed. 🏃‍♀️💨

If the S (symmetric) flag is cleared in the BFD Configuration sub-TLV, this field expresses the desired time interval (in microseconds) at which an edge LSR intends to transmit BFD periodic control packets in its transmitting direction.

Acceptable Min. Asynchronous RX interval: If the S (symmetric) flag is set in the BFD Configuration sub-TLV, Figure 3, this field MUST be equal to Acceptable Min. Asynchronous TX interval and has no additional meaning respect to the one described for "Acceptable Min. Asynchronous TX interval". 🪞

If the S (symmetric) flag is cleared in the BFD Configuration sub-TLV, it expresses the minimum time interval (in microseconds) at which edge LSRs can receive BFD periodic control packets. If this value is greater than the value of Acceptable Min. Asynchronous TX interval received from the other edge LSR, such an edge LSR MUST adopt the interval expressed in this Acceptable Min. Asynchronous RX interval. 🫶

Required Echo TX Interval: The minimum interval (in microseconds) between received BFD Echo packets that this system is capable of supporting, less any jitter applied by the sender as described in Section 6.8.9 of [RFC5880]. This value is also an indication for the receiving system of the minimum interval between transmitted BFD Echo packets. If this value is zero, the transmitting system does not support the receipt of BFD Echo packets. If the receiving system cannot support this value, the "Unsupported BFD TX Echo rate interval" error MUST be generated. By default, the value is set to 0. 🌸

2.2.4. BFD Authentication Sub-TLV 🔐

The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD Configuration sub-TLV" and is depicted in Figure 6. 💌

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BFD Auth. Sub-type (103)   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |  Auth Key ID  |         Reserved (0s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: BFD Authentication Sub-TLV Format ✨

Sub-type: Indicates a new sub-type, the BFD Authentication sub-TLV (value 103). 🧁

Length: Indicates the length of the Value field in octets (4).

Auth Type: Indicates which type of authentication to use. The same values as are defined in Section 4.1 of [RFC5880] are used. Simple Password SHOULD NOT be used if other authentication types are available. 🙅‍♀️🔑

Auth Key ID: Indicates which authentication key or password (depending on Auth Type) should be used. How the key exchange is performed is out of scope of this document. If the egress LSR does not support this Auth Key ID, an OAM Problem/Mismatch of BFD Authentication Key ID error MUST be generated. 🗝️

Reserved: Reserved for future specification; set to 0 on transmission and ignored when received. 🫧

An implementation MAY change the mode of authentication if an operator re-evaluates the security situation in and around the administrative domain. If the BFD Authentication sub-TLV is used for a BFD session in Up state, then the Sender of the MPLS LSP Echo Request SHOULD ensure that old and new modes of authentication, i.e., a combination of Auth.Type and Auth. Key ID, are used to send and receive BFD control packets, until the Sender can confirm that its peer has switched to the new authentication. 🔄💜

2.2.5. Traffic Class Sub-TLV 🦋

okay so the Traffic Class sub-TLV is a sub-TLV that nests inside the "BFD Configuration sub-TLV" and the "Fault Management Signal Sub-TLV" (Section 2.2.9) 🪆 it's giving nested doll energy, and it's shown in Figure 7 bestie 💖

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Traffic Class Sub-type (104)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TC |                 Reserved (set to all 0s)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Traffic Class Sub-TLV Format

  • Sub-type: Indicates a new sub-type, the "Traffic Class sub-TLV" (value 104).
  • Length: Indicates the length of the Value field in octets (4).
  • TC: Identifies the Traffic Class (TC) [RFC5462] for periodic continuity monitoring messages or packets with fault management information.

okay the main vibe here: if the TC sub-TLV is present, then the sender of any periodic continuity monitoring messages or packets with fault management information on the LSP, with a Forwarding Equivalence Class (FEC) that corresponds to the FEC for which fault detection is being performed, MUST use the value contained in the TC field of the sub-TLV as the value of the TC field in the top label stack entry of the MPLS label stack. and if the TC sub-TLV is absent from either "BFD Configuration sub-TLV" or "Fault Management Signal sub-TLV", then selection of the TC value is a local decision 🫶

2.2.6. Performance Monitoring Sub-TLV 📊

so if the MPLS OAM Functions TLV has any of the L (Loss), D (Delay), and T (Throughput) flags set, the Performance Monitoring sub-TLV MUST be present. no skipping it! failure to include the correct sub-TLVs MUST result in an "OAM Problem/PM Configuration Error" being generated 😭

the Performance Monitoring sub-TLV provides the configuration information mentioned in Section 7 of [RFC6374]. it includes support for configuring quality thresholds and, as [RFC6374] describes:

...the crossing of which will trigger warnings or alarms, and result in reporting and exception notification will be integrated into the system-wide network management and reporting framework.

if the values need to be different than the default ones, the Performance Monitoring sub-TLV MAY include the following sub-TLVs:

  • PM Loss sub-TLV, if the L flag is set in the MPLS OAM Functions TLV;
  • PM Delay sub-TLV, if the D flag is set in the MPLS OAM Functions TLV.

the Performance Monitoring sub-TLV depicted in Figure 8 is carried as a sub-TLV of the MPLS OAM Functions TLV, and it looks like this 🌸

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Perf. Monitoring Sub-type (200)|          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     PM Configuration Flags                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Performance Monitoring Sub-TLV Format

  • Sub-type: Indicates a new sub-type, the Performance Monitoring sub-TLV (value 200).
  • Length: Indicates the length of the Value field in octets, including PM Configuration Flags and optional sub-TLVs.

here are the PM Configuration Flags, the little control panel of this whole thing 🎛️✨

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|L|J|Y|K|C|            Reserved (set to all 0s)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: PM Configuration Flags Format

the PM Configuration Flags format is presented in Figure 9. for the specific function description, check [RFC6374]:

  • D: Delay inferred/direct (0=INFERRED, 1=DIRECT). if the egress LSR does not support the specified mode, an "OAM Problem/Unsupported Delay Mode" error MUST be generated.
  • L: Loss inferred/direct (0=INFERRED, 1=DIRECT). if the egress LSR does not support the specified mode, an "OAM Problem/Unsupported Loss Mode" error MUST be generated.
  • J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). if the egress LSR does not support Delay variation measurements and the J flag is set, an "OAM Problem/Delay variation unsupported" error MUST be generated.
  • Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE). if the egress LSR does not support Dyadic mode and the Y flag is set, an "OAM Problem/Dyadic mode unsupported" error MUST be generated.
  • K: Loopback (1=ACTIVE, 0=NOT ACTIVE). if the egress LSR does not support Loopback mode and the K flag is set, an "OAM Problem/Loopback mode unsupported" error MUST be generated.
  • C: Combined (1=ACTIVE, 0=NOT ACTIVE). if the egress LSR does not support Combined mode and the C flag is set, an "OAM Problem/Combined mode unsupported" error MUST be generated.
  • Reserved: Reserved for future specification; set to 0 on transmission and ignored when received.

2.2.7. PM Loss Measurement Sub-TLV 📉

the PM Loss Measurement sub-TLV depicted in Figure 10 is carried as a sub-TLV of the Performance Monitoring sub-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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PM Loss Sub-type (201)       |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OTF |T|B|              Reserved (set to all 0s)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Measurement Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Test Interval                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Loss Threshold                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: PM Loss Measurement Sub-TLV Format

  • Sub-type: Indicates a new sub-type, the PM Loss Measurement sub-TLV (value 201).
  • Length: Indicates the length of the Value field in octets (16).
  • OTF: Origin Timestamp Format of the Origin Timestamp field described in [RFC6374]. by default, it is set to IEEE 1588 version 1. if the egress LSR cannot support this value, an "OAM Problem/Unsupported Timestamp Format" error MUST be generated.

these are the Configuration Flags. for the details, please refer to [RFC6374] 🧐

  • T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular traffic class (Differentiated Services Code Point value), and 0 otherwise. when set to 1, the Differentiated Services (DS) field of the message indicates the measured traffic class. by default, it is set to 1.
  • B: Octet (byte) count. when set to 1, indicates that the Counter 1-4 fields represent octet counts. when set to 0, indicates that the Counter 1-4 fields represent packet counts. by default, it is set to 0.
  • Reserved: Reserved for future specification; set to 0 on transmission and ignored when received.
  • Measurement Interval: The time interval (in milliseconds) at which Loss Measurement query messages MUST be sent on both directions. if the edge LSR receiving the Path message cannot support such a value, it SHOULD reply with a higher interval. by default, it is set to (100) as per [RFC6375].
  • Test Interval: Test messages interval in milliseconds as described in [RFC6374]. by default, it is set to (10) as per [RFC6375].
  • Loss Threshold: The threshold value of measured lost packets per measurement over which action(s) SHOULD be triggered. 🚨

2.2.8. PM Delay Measurement Sub-TLV ⏱️

the "PM Delay Measurement sub-TLV" depicted in Figure 11 is carried as a sub-TLV of the Performance Monitoring sub-TLV, and it's the delay-measuring twin of the one before 👯‍♀️

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PM Delay Sub-type (202)      |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OTF |T|B|             Reserved (set to all 0s)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Measurement Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Test Interval                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Delay Threshold                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: PM Delay Measurement Sub-TLV Format

  • Sub-type: Indicates a new sub-type, the "PM Delay Measurement sub-TLV" (value 202).
  • Length: Indicates the length of the Value field in octets (16).
  • OTF: Origin Timestamp Format of the Origin Timestamp field described in [RFC6374]. by default, it is set to IEEE 1588 version 1. if the egress LSR cannot support this value, an "OAM Problem/Unsupported Timestamp Format" error MUST be generated.

Configuration Flags, same deal, check [RFC6374] for the full tea ☕

  • T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular traffic class (Differentiated Services Code Point value), and 0 otherwise. when set to 1, the DS field of the message indicates the measured traffic class. by default, it is set to 1.
  • B: Octet (byte) count. when set to 1, indicates that the Counter 1-4 fields represent octet counts. when set to 0, indicates that the Counter 1-4 fields represent packet counts. by default, it is set to 0.
  • Reserved: Reserved for future specification; set to 0 on transmission and ignored when received.
  • Measurement Interval: The time interval (in milliseconds) at which Delay Measurement query messages MUST be sent on both directions. if the edge LSR receiving the Path message cannot support such a value, it can reply with a higher interval. by default, it is set to (1000) as per [RFC6375].
  • Test Interval: Test messages interval (in milliseconds) as described in [RFC6374]. by default, it is set to (10) as per [RFC6375].
  • Delay Threshold: The threshold value of measured two-way delay (in milliseconds) over which action(s) SHOULD be triggered. 🌈

2.2.9. Fault Management Signal Sub-TLV ✨

okay bestie, the FMS sub-TLV (Figure 12) rides along inside the MPLS OAM Configuration sub-TLV 🎀. when you've got both a working path and a protection path, both LSPs SHOULD be configured with identical settings of the E flag, T flag, and the refresh timer 💖. the one exception is 1:N protection, where an implementation MAY configure the working and protection LSPs with different settings of these fields 🦋.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       FMS Sub-type (300)      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|S|T|            Reserved           |      Refresh Timer      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12: Fault Management Signal Sub-TLV Format

Sub-type: this is the brand new FMS sub-TLV, value 300 🌸.

Length: the length of the Value field, in octets ✨.

FMS Flags are what switch on the FMS Flags at the end point MEPs and at the Server MEPs of the links the LSP goes over 🧚. in this doc, only the S flag cares about Server MEPs 💅.

here are the flags:

  • E: turns on Alarm Indication Signal (AIS) and Lock Report (LKR) signaling, as described in [RFC6427] 🔥. the default is 1 (enabled). if the egress MEP can't do FMS Flag generation, it MUST generate an "OAM Problem/Fault management signaling unsupported" error 💀.
  • S: tells a Server MEP that it should transmit AIS and LKR signals on the client LSP 🫶. the default is 0 (disabled). if a Server MEP that can generate FMS messages is somehow unable to do it for the LSP being signaled, it MUST generate an "OAM Problem/Unable to create fault management association" error 😭.
  • T: sets a timer value, which enables the configuration of a specific timer value 🌈. the default is 0 (disabled).

Reserved: bits 4-16 that come after the FMS Flags are reserved for future allocation 🍓. these bits MUST be set to 0 on transmit, and ignored on receipt if they aren't allocated 👑.

Refresh Timer: the refresh timer for fault indication messages, in seconds ⭐. the value MUST be between 1 to 20 seconds, as specified for the Refresh Timer field in [RFC6427] 💜. if the edge LSR that gets the Path message can't support the value, it SHOULD reply with a higher timer value 🦋.

an FMS sub-TLV MAY include a Traffic Class sub-TLV (Section 2.2.5) 🎀. if the TC sub-TLV is there, the value of the TC field MUST be used as the value of the TC field of an MPLS label stack entry for FMS messages 💖. if the TC sub-TLV is absent, picking the TC value is a local decision 🌸.

2.2.10. Source MEP-ID Sub-TLV ✨

the Source MEP-ID sub-TLV (Figure 13) is carried as a sub-TLV of the MPLS OAM Functions TLV 🧚.

quick heads up: support of ITU IDs is out of scope 🙈.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source MEP-ID Sub-type (400)  |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Node ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel ID           |           LSP ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 13: Source MEP-ID Sub-TLV Format

Sub-type: a brand new sub-type, the Source MEP-ID sub-TLV, value 400 💅.

Length: the length of the Value field, in octets (8) 🌈.

Source Node ID: a 32-bit node identifier, as defined in [RFC6370] 🫶.

Tunnel ID: a 16-bit unsigned integer, unique to the node, as defined in [RFC6370] 🔥.

LSP ID: a 16-bit unsigned integer, unique within the Tunnel_ID, as defined in [RFC6370] 👑.

3. Summary of MPLS OAM Configuration Errors ✨

this is the big recap of the Return Codes [RFC4379] defined in this document 🧚. get your highlighters ready 🖍️💖.

  • If an egress LSR does not support the specified BFD version, an error MUST be generated: "OAM Problem/Unsupported BFD Version".
  • If an egress LSR does not support the specified BFD Encapsulation format, an error MUST be generated: "OAM Problem/Unsupported BFD Encapsulation format".
  • If an egress LSR does not support BFD Authentication, and it is requested, an error MUST be generated: "OAM Problem/BFD Authentication unsupported".
  • If an egress LSR does not support the specified BFD Authentication Type, an error MUST be generated: "OAM Problem/Unsupported BFD Authentication Type".
  • If an egress LSR is not able to use the specified Authentication Key ID, an error MUST be generated: "OAM Problem/Mismatch of BFD Authentication Key ID".
  • If PM flags in MPLS OAM Functions TLV don't have corresponding PM sub-TLVs present, an error MUST be generated: "OAM Problem/PM Configuration Error".
  • If an egress LSR does not support the specified Timestamp Format, an error MUST be generated: "OAM Problem/Unsupported Timestamp Format".
  • If an egress LSR does not support specified Delay mode, an "OAM Problem/Unsupported Delay Mode" error MUST be generated.
  • If an egress LSR does not support specified Loss mode, an "OAM Problem/Unsupported Loss Mode" error MUST be generated.
  • If an egress LSR does not support Delay variation measurements, and it is requested, an "OAM Problem/Delay variation unsupported" error MUST be generated.
  • If an egress LSR does not support Dyadic mode, and it is requested, an "OAM Problem/Dyadic mode unsupported" error MUST be generated.
  • If an egress LSR does not support Loopback mode, and it is requested, an "OAM Problem/Loopback mode unsupported" error MUST be generated.
  • If an egress LSR does not support Combined mode, and it is requested, an "OAM Problem/Combined mode unsupported" error MUST be generated.
  • If an egress LSR does not support Fault Monitoring Signals, and it is requested, an "OAM Problem/Fault management signaling unsupported" error MUST be generated.
  • If an intermediate Server MEP supports Fault Monitoring Signals, but is unable to create an association, when requested to do so, an "OAM Problem/Unable to create fault management association" error MUST be generated.

an Ingress LSR MAY combine multiple MPLS OAM configuration TLVs and sub-TLVs into a single MPLS echo request 🎀. if an egress LSR doesn't support any of the requested modes, it MUST set the return code to report the first unsupported mode in the list of TLVs and sub-TLVs 💅. and if any of the requested OAM configuration isn't supported, the egress LSR SHOULD NOT process the OAM Configuration TLVs and sub-TLVs listed in the MPLS echo request 😭.

4. IANA Considerations ✨

4.1. TLV and Sub-TLV Allocation

IANA maintains the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry 📋, and inside that registry there's a subregistry for TLVs and sub-TLVs 🌸.

IANA has allocated a new MPLS OAM Functions TLV from the Standards Action [RFC5226] range (0-16383) 🧚. the sub-TLVs are allocated as follows, from the subregistry in Table 1, called "Sub-TLVs for TLV Type 27" 💖.

Registration procedures for Sub-TLVs from the ranges 0-16383 and 32768-49161 are by Standards Action 👑. the ranges 16384-31743 and 49162-64511 go through Specification Required (Experimental RFC Needed) 🦋.

+------+----------+---------------------------------+---------------+
| Type | Sub-type | Value Field                     | Reference     |
+------+----------+---------------------------------+---------------+
| 27   |          | MPLS OAM Functions              | This document |
|      | 100      | BFD Configuration               | This document |
|      | 101      | BFD Local Discriminator         | This document |
|      | 102      | BFD Negotiation Timer           | This document |
|      |          | Parameters                      |               |
|      | 103      | BFD Authentication              | This document |
|      | 104      | Traffic Class                   | This document |
|      | 200      | Performance Monitoring          | This document |
|      | 201      | PM Loss Measurement             | This document |
|      | 202      | PM Delay Measurement            | This document |
|      | 300      | Fault Management Signal         | This document |
|      | 400      | Source MEP-ID                   | This document |
+------+----------+---------------------------------+---------------+

                   Table 1: IANA TLV Type Allocation

4.2. MPLS OAM Function Flags Allocation

IANA has created a brand new registry called the "MPLS OAM Function Flags" registry 🌈. assignments of bit positions 0 through 31 happen via Standards Action 🔥. the new registry gets populated as follows 💅.

+------------+--------------------+---------------------------------+
|    Bit     | MPLS OAM Function  | Description                     |
|  Position  |        Flag        |                                 |
+------------+--------------------+---------------------------------+
|     0      |         C          | Continuity Check (CC)           |
|     1      |         V          | Connectivity Verification (CV)  |
|     2      |         F          | Fault Management Signal (FMS)   |
|     3      |         L          | Performance Monitoring/Loss     |
|            |                    | (PM/Loss)                       |
|     4      |         D          | Performance Monitoring/Delay    |
|            |                    | (PM/Delay)                      |
|     5      |         T          | Throughput Measurement          |
|    6-30    |                    | Unassigned (Must be zero)       |
|     31     |                    | Reserved                        |
+------------+--------------------+---------------------------------+

                   Table 2: MPLS OAM Function Flags

4.3. OAM Configuration Errors 🎀

okay bestie, so IANA keeps a registry called "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 🧚 and inside that registry there's a subregistry called "Return Codes" 💅

IANA has assigned new Return Codes from the Standards Action range (0-191) like this:

+----------------+--------------------------------------+-----------+
| Error Value    | Description                          | Reference |
| Sub-codes      |                                      |           |
+----------------+--------------------------------------+-----------+
| 21             | OAM Problem/Unsupported BFD Version  | This      |
|                |                                      | document  |
| 22             | OAM Problem/Unsupported BFD          | This      |
|                | Encapsulation format                 | document  |
| 23             | OAM Problem/Unsupported BFD          | This      |
|                | Authentication Type                  | document  |
| 24             | OAM Problem/Mismatch of BFD          | This      |
|                | Authentication Key ID                | document  |
| 25             | OAM Problem/Unsupported Timestamp    | This      |
|                | Format                               | document  |
| 26             | OAM Problem/Unsupported Delay Mode   | This      |
|                |                                      | document  |
| 27             | OAM Problem/Unsupported Loss Mode    | This      |
|                |                                      | document  |
| 28             | OAM Problem/Delay variation          | This      |
|                | unsupported                          | document  |
| 29             | OAM Problem/Dyadic mode unsupported  | This      |
|                |                                      | document  |
| 30             | OAM Problem/Loopback mode            | This      |
|                | unsupported                          | document  |
| 31             | OAM Problem/Combined mode            | This      |
|                | unsupported                          | document  |
| 32             | OAM Problem/Fault management         | This      |
|                | signaling unsupported                | document  |
| 33             | OAM Problem/Unable to create fault   | This      |
|                | management association               | document  |
| 34             | OAM Problem/PM Configuration Error   | This      |
|                |                                      | document  |
+----------------+--------------------------------------+-----------+

Table 3: IANA Return Codes Allocation 🌸

5. Security Considerations 🔥

okay, this section is SERIOUS, so pay attention 😭 The signaling of OAM-related parameters and the automatic establishment of OAM entities adds extra security considerations on top of the ones discussed in [RFC4379]. The big one: a network element could get overloaded if an attacker asked for high-frequency liveliness monitoring of a large number of LSPs, all aimed at one single network element 💀

So implementations need to be aware of their available OAM resources, and they MAY refuse new OAM configurations that would overload a node 🛡️ Policies for managing OAM resources may also be used to keep things fair in how OAM resources get shared out among the monitored LSPs ⚖️

Security of OAM protocols configured with the LSP Ping extensions described in this document is discussed in [RFC5880], [RFC5884], [RFC6374], [RFC6427], and [RFC6428] 🔐

For OAM functionality to be configured securely using the techniques in this document, security mechanisms must already be in place and working for LSP Ping 🫶 So the exchange of security parameters (like keys) for securing OAM is outside the scope of this document. It's assumed to use an off-line mechanism or an established secure key exchange protocol 🗝️

Additional discussion of security for MPLS protocols can be found in [RFC5920] 📚

6. References 🌈

6.1. Normative References

6.2. Informative References

Acknowledgements 💖

The authors would like to thank Nobo Akiya, David Allan, and Adrian Farrel for their thorough reviews and insightful comments 🙌

Authors' Addresses ✨

Elisa Bellagamba
Email: elisa.bellagamba@gmail.com

Gregory Mirsky
Ericsson
Email: Gregory.Mirsky@ericsson.com

Loa Andersson
Huawei Technologies
Email: loa@mail01.huawei.com

Pontus Skoldstrom
Acreo AB
Electrum 236
Kista  164 40
Sweden
Phone: +46 8 6327731
Email: pontus.skoldstrom@acreo.se

Dave Ward
Cisco
Email: dward@cisco.com

John Drake
Juniper
Email: jdrake@juniper.net

That's the whole RFC, bestie! 🦋🌈💖 Every error code, every reference, and every contact, all accounted for ✨

📦 where this page comes from