RFC 7487

Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE

📅 published March 2015, from ietf

RFC 7487: Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE 💖

Okay bestie, this one is a Standards Track doc from March 2015, and it has an ISSN of 2070-1721 🦋. It was written by E. Bellagamba, A. Takacs, and G. Mirsky from Ericsson, L. Andersson from Huawei Technologies, P. Skoldstrom from Acreo AB, and D. Ward from Cisco 🫶. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract ✨

This spec is all about setting up proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP). It does this with a set of TLVs carried by the GMPLS RSVP-TE protocol, building on the OAM Configuration Framework for GMPLS RSVP-TE 🎀.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7487 🧚.

Copyright (c) 2015 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 date this document was published. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 📜.

Table of Contents 📋

   1. Introduction ....................................................4
      1.1. Conventions Used in This Document ..........................5
           1.1.1. Terminology .........................................5
           1.1.2. Requirements Language ...............................6
   2. Overview of MPLS OAM for Transport Applications .................6
   3. Theory of Operations ............................................7
      3.1. MPLS-TP OAM Configuration Operation Overview ...............7
           3.1.1. Configuration of BFD Sessions .......................8
           3.1.2. Configuration of Performance Monitoring .............8
           3.1.3. Configuration of Fault Management Signals ...........9
      3.2. MPLS OAM Configuration Sub-TLV .............................9
           3.2.1. CV Flag Rules of Use ...............................11
      3.3. BFD Configuration Sub-TLV .................................12
           3.3.1. BFD Identifiers Sub-TLV ............................14
           3.3.2. Negotiation Timer Parameters Sub-TLV ...............15
           3.3.3. BFD Authentication Sub-TLV .........................16
           3.3.4. Traffic Class Sub-TLV ..............................17
      3.4. Performance Monitoring Sub-TLV ............................17
           3.4.1. MPLS OAM PM Loss Sub-TLV ...........................19
           3.4.2. MPLS OAM PM Delay Sub-TLV ..........................21
      3.5. MPLS OAM FMS Sub-TLV ......................................22
   4. Summary of MPLS OAM Configuration Errors .......................23
   5. IANA Considerations ............................................25
      5.1. MPLS OAM Type .............................................25
      5.2. MPLS OAM Configuration Sub-TLV ............................25
      5.3. MPLS OAM Configuration Sub-TLV Types ......................26
      5.4. BFD Configuration Sub-TLV Types ...........................26
      5.5. Performance Monitoring Sub-TLV Types ......................27
      5.6. New RSVP-TE Error Codes ...................................28
   6. Security Considerations ........................................28
   7. References .....................................................29
      7.1. Normative References ......................................29
      7.2. Informative References ....................................30
   Acknowledgements ..................................................31
   Contributors ......................................................31
   Authors' Addresses ................................................32

1. Introduction ✨

Okay so this doc describes how to configure proactive MPLS-TP OAM functions for a given LSP, using TLVs that ride on GMPLS RSVP-TE [RFC3473] 💅. [RFC7260] already defines using GMPLS RSVP-TE to configure OAM functions in a technology-agnostic way. This doc adds the extra mechanisms needed to set up MPLS-TP OAM entities at the maintenance points, so you can monitor and measure an LSP. It also defines the information elements and procedures for configuring proactive MPLS-TP OAM functions that run between Label Edge Routers (LERs) 🌸.

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

MPLS-TP, the Transport Profile of MPLS, must, by definition [RFC5654], be capable of operating without a control plane. That means there are several ways to configure MPLS-TP OAM without a control plane: using a Network Management System (NMS), using an LSP Ping, or using signaling protocols such as RSVP-TE in the control plane 🧚.

MPLS-TP describes a profile of MPLS that fits the operational models typical of transport networks. It also adds OAM survivability and other maintenance functions that MPLS doesn't currently support. [RFC5860] defines the requirements for the OAM functionality of MPLS-TP 💜.

Proactive MPLS-TP OAM runs on three different protocols, and it's giving a whole team 🔥:

  • Bidirectional Forwarding Detection (BFD) [RFC6428] handles Continuity Check / Connectivity Verification.
  • The Delay Measurement (DM) protocol [RFC6374] handles delay and delay variation (jitter) measurements.
  • The Loss Measurement (LM) protocol [RFC6374] 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 a protocol that gives you low-overhead, fast detection of failures in the path between two forwarding engines. That includes the interfaces, the data link(s), and (to the extent possible) the forwarding engines themselves ⚡. BFD can track liveliness and detect data plane failures for MPLS-TP point-to-point connections. It might also be extended to support point-to-multipoint connections 🦋.

The delay and loss measurement protocols [RFC6374] use a simple query/response model for bidirectional measurements. This lets the originating node measure packet loss and delay in both directions. The measurement packets get timestamped and/or have current packet counters written into them four times (Tx and Rx in both directions). From that, current delays and packet losses can be calculated 🍓. Doing successive delay measurements lets you calculate the 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. Combine 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 we are not configuring on-demand throughput estimates based on saturating the connection, as defined in [RFC6371]. Instead, we only enable estimating the current throughput based on loss measurements 🙈.

1.1. Conventions Used in This Document 📝

1.1.1. Terminology 🧠

  • AIS - Alarm Indication Signal
  • BFD - Bidirectional Forwarding Detection
  • CC - Continuity Check
  • CV - Connectivity Verification
  • DM - Delay Measurement
  • FMS - Fault Management Signal
  • G-ACh - Generic Associated Channel
  • GMPLS - Generalized Multi-Protocol Label Switching
  • LDI - Link Down Indication
  • LER - Label Edge Router
  • LKR - Lock Report
  • LM - Loss Measurement
  • LOC - Loss Of Continuity
  • LSP - Label Switched Path
  • LSR - Label Switching Router
  • MEP - Maintenance Entity Group End Point
  • MIP - Maintenance Entity Group Intermediate Point
  • MPLS - Multi-Protocol Label Switching
  • MPLS-TP - MPLS Transport Profile
  • NMS - Network Management System
  • PM - Performance Measurement
  • RSVP-TE - Reservation Protocol 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]. These are the official BCP 14 key words, so if you see them in caps, they're doing real work 🫶.

2. Overview of MPLS OAM for Transport Applications 🦋

[RFC6371] explains how MPLS-TP OAM mechanisms operate to meet the transport requirements outlined in [RFC5860] ✨.

[RFC6428] specifies two BFD operation modes 💖. The first is "CC mode", which uses periodic BFD message exchanges with symmetric timer settings to support Continuity Check. The second is "CV/CC mode", which sends unique maintenance entity identifiers in the periodic BFD messages, supporting CV as well as CC 🔥.

[RFC6374] specifies mechanisms for Performance Monitoring of LSPs. In particular, it specifies the loss and delay measurement OAM functions 🌈.

[RFC6427] specifies fault management signals. These let a server LSP notify client LSPs about various fault conditions, either to suppress alarms or to act as triggers for actions in the client LSPs 🚨. The signals defined are Alarm Indication Signal (AIS), Link Down Indication (LDI), and Lock Report (LKR) 🍓.

[RFC6371] describes how fault conditions map to consequent actions. Some of these mappings can be configured by the operator, depending on the application of the LSP 🧚. The defects identified are Loss Of Continuity (LOC), Misconnectivity, MEP Misconfiguration, and Period Misconfiguration. Of these defect conditions, the following consequent actions may be configurable: 1) whether or not the LOC defect should result in blocking the outgoing data traffic; and 2) whether or not the "Period Misconfiguration defect" should result in a signal fail condition 💅.

3. Theory of Operations 👑

To be continued in part 2, bestie 🫶💜

3.1. MPLS-TP OAM Configuration Operation Overview ✨

okay so GMPLS RSVP-TE, or LSP Ping [LSP-PING-CONF] if that's your vibe, can just switch on the different OAM functions by setting the matching flags in the OAM Function Flags Sub-TLV [RFC7260] 💅. Want more control? You can add sub-TLVs for each OAM function and spell out the parameters in detail 🎀.

Usually, intermediate nodes SHOULD NOT process or modify any of the OAM Configuration TLVs. They just forward them along to the end node 🦋. There's one exception, and it's the MPLS OAM FMS Sub-TLV 👑. That one MUST be examined even by intermediate nodes that support these extensions, but only nodes that can send FMS signals into the LSP being set up should actually act on it. The sub-TLV MAY be present when the FMS flag is set in the OAM Function Flags Sub-TLV. If it's there, then the "OAM MIP entities desired" and "OAM MEP entities desired" flags (described in [RFC7260]) in the LSP Attribute Flags TLV MUST be set, and the whole OAM Configuration TLV has to go in either the LSP_REQUIRED_ATTRIBUTES object or the LSP_ATTRIBUTES object so that capable intermediate nodes actually process the config 🫶.

If it goes in LSP_ATTRIBUTES, nodes that can't process the OAM Configuration TLV just forward the message with no error ✨. But if the MPLS OAM FMS Sub-TLV sits in LSP_REQUIRED_ATTRIBUTES, a node that supports RFC 7260 but doesn't support the MPLS OAM FMS Sub-TLV MUST generate a PathErr message with "OAM Problem/Configuration Error" [RFC7260] 💀. Otherwise, if the node doesn't support RFC 7260, it won't raise any errors, as described in Section 4.1 of [RFC7260].

Last thing: if the MPLS OAM FMS Sub-TLV isn't included, only the "OAM MEP entities desired" flag gets set, and the OAM Configuration TLV may be placed in either LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 🌸.

3.1.1. Configuration of BFD Sessions 🦋

For this specification, BFD MUST be run in either one of the two modes:

  • Asynchronous mode, where both sides should be in active mode; or
  • Unidirectional mode.

In the simplest scenario, RSVP-TE (or alternatively LSP Ping [LSP-PING-CONF]) is used only to bootstrap a BFD session for an LSP without any timer negotiation. Easy mode 🧚.

Timer negotiation can be performed either in subsequent BFD Control messages (in this case the operation is similar to LSP-Ping-based bootstrapping described in [RFC5884]) or directly in the RSVP-TE signaling messages.

Okay, this part is lowkey important 😭. When BFD Control packets are transported in the G-ACh, they are not protected by any end-to-end checksum; only lower layers are providing error detection/correction. A single bit error, e.g., a flipped bit in the BFD State field, could cause the receiving end to wrongly conclude that the link is down and, in turn, trigger protection switching. 💀 To prevent this from happening, the BFD Configuration Sub-TLV has an Integrity flag that, when set, enables BFD Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. This would ensure that every BFD Control packet carries a SHA1 hash of itself that can be used to detect errors.

If BFD Authentication using a pre-shared key / password is desired (i.e., authentication and not only error detection), the BFD Authentication Sub-TLV MUST be included in the BFD Configuration Sub-TLV. The BFD Authentication Sub-TLV is used to specify which authentication method should be used and which pre-shared key / password should be used for this particular session. How the key exchange is performed is out of scope of this document 🙈.

3.1.2. Configuration of Performance Monitoring 📊

It is possible to configure Performance Monitoring functionalities such as Loss, Delay, Delay variation (jitter), and Throughput, as described in [RFC6374] 🌈.

When configuring Performance Monitoring functionalities, it is possible to choose either the default configuration (by only setting the respective flags in the OAM Function Flags Sub-TLV) or a customized configuration. To customize the configuration, one would set the respective flags and include the respective Loss and/or Delay sub-TLVs.

By setting the PM/Loss flag in the OAM Function Flags Sub-TLV and by including the MPLS OAM PM Loss Sub-TLV, one can configure the measurement interval and loss threshold values for triggering protection.

Delay measurements are configured by setting the PM/Delay flag in the OAM Function Flags Sub-TLV; by including the MPLS OAM PM Loss Sub-TLV, one can configure the measurement interval and the delay threshold values for triggering protection.

3.1.3. Configuration of Fault Management Signals 🚨

To configure Fault Management signals and their refresh time, the FMS flag in the OAM Function Flags Sub-TLV MUST be set and the MPLS OAM FMS Sub-TLV included. When configuring Fault Management signals, an implementation can enable the default configuration by setting the FMS flag in the OAM Function Flags Sub-TLV. In order to modify the default configuration, the MPLS OAM FMS Sub-TLV MUST be included.

If an intermediate point is intended to originate fault management signal messages, this means that such an intermediate point is associated with a server MEP through a co-located MPLS-TP client/server adaptation function, and the "Fault Management subscription" flag in the MPLS OAM FMS Sub-TLV has been set as an indication of the request to create the association at each intermediate node of the client LSP. The corresponding server MEP needs to be configured by its own RSVP-TE session (or, alternatively, via an NMS or LSP Ping).

3.2. MPLS OAM Configuration Sub-TLV 🎀

The OAM Configuration TLV, defined in [RFC7260], specifies the OAM functions that are used for the LSP. This document extends the OAM Configuration TLV by defining a new OAM Type: "MPLS OAM" (3). The MPLS OAM type is set to request the establishment of OAM functions for MPLS-TP LSPs. The specific OAM functions are specified in the OAM Function Flags Sub-TLV as depicted in [RFC7260].

When an egress LSR receives an OAM Configuration TLV indicating the MPLS OAM type, the LSR will first process any present OAM Function Flags Sub-TLV, and then it MUST process technology-specific configuration TLVs. This document defines a sub-TLV, the MPLS OAM Configuration Sub-TLV, which is carried in the OAM Configuration 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MPLS OAM Conf. Sub-TLV (33)   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: MPLS OAM Configuration Sub-TLV Format

Type: 33, the MPLS OAM Configuration Sub-TLV.

Length: Indicates the total length in octets, including sub-TLVs as well as the Type and Length fields.

The following MPLS-OAM-specific sub-TLVs MAY be included in the MPLS OAM Configuration Sub-TLV:

  • BFD Configuration Sub-TLV MUST be included if either the CC, the CV, or both OAM Function flags are being set in the OAM Function Flags Sub-TLV [RFC7260]. This sub-TLV carries additional sub-TLVs; failure to include the correct sub-TLVs MUST result in an error being generated: "OAM Problem/Configuration Error". The sub-TLVs are:
    • BFD Identifiers Sub-TLV MUST always be included.
    • Timer Negotiation Parameters Sub-TLV MUST be included if the N flag is not set.
    • BFD Authentication Sub-TLV MAY be included if the I flag is set.
  • Performance Monitoring Sub-TLV, which MUST be included if any of the PM/Delay, PM/Loss, or PM/Throughput flags are set in the OAM Function Flag Sub-TLV [RFC7260]. This sub-TLV MAY carry additional sub-TLVs:
    • MPLS OAM PM Loss Sub-TLV MAY be included if the PM/Loss OAM Function flag is set. If the MPLS OAM PM Loss Sub-TLV is not included, default configuration values are used. The same sub-TLV MAY also be included in case the PM/Throughput OAM Function flag is set and there is the need to specify measurement intervals different from the default ones. Since throughput measurements use the same tool as loss measurements, the same TLV is used.
    • MPLS OAM PM Delay Sub-TLV MAY be included if the PM/Delay OAM Function flag is set. If the MPLS OAM PM Delay Sub-TLV is not included, default configuration values are used.
  • MPLS OAM FMS Sub-TLV MAY be included if the FMS OAM Function flag is set. If the MPLS OAM FMS Sub-TLV is not included, default configuration values are used.

The following are some additional rules of processing the MPLS OAM Configuration Sub-TLV 📝:

  • The MPLS OAM Configuration Sub-TLV MAY be empty, i.e., have no Value. If so, then its Length MUST be 8. Then, all OAM functions that have their corresponding flags set in the OAM Function Flags Sub-TLV MUST be assigned their default values or left disabled.
  • A sub-TLV that doesn't have a corresponding flag set MUST be silently ignored.
  • If multiple copies of a sub-TLV are present, then only the first sub-TLV MUST be used and the remaining sub-TLVs MUST be silently ignored.

However, not all the values can be derived from the standard RSVP-TE objects, in particular the locally assigned Tunnel ID at the egress cannot be derived by the ingress node. Therefore, the full LSP MEP-ID used by the ingress has to be carried in the BFD Identifiers Sub-TLV in the Path message and the egress LSP MEP-ID in the same way in the Resv message.

3.2.1. CV Flag Rules of Use 🦋

If the CV flag is set in the OAM Function Flags Sub-TLV [RFC7260], then the CC flag MUST be set as well because performing Connectivity Verification implies performing Continuity Check as well. The format of an MPLS-TP CV/CC message is shown in [RFC6428]. In order to perform Connectivity Verification, the CV/CC message MUST contain the "LSP MEP-ID" in addition to the BFD Control packet information. The "LSP MEP-ID" contains four identifiers:

  • MPLS-TP Global_ID
  • MPLS-TP Node Identifier
  • Tunnel_Num
  • LSP_Num

These values need to be correctly set by both ingress and egress when transmitting a CV packet, and both ingress and egress need to know what to expect when receiving a CV packet. Most of these values can be derived from the Path and Resv messages [RFC3473], which use a 5-tuple to uniquely identify an LSP within an operator's network. This tuple is composed of a Tunnel Sender Address, Tunnel Endpoint Address, Tunnel_ID, Extended Tunnel ID, and (GMPLS) LSP_ID. bestie, the networking is literally so iconic 💖

3.3. BFD Configuration Sub-TLV 💖

okay so the BFD Configuration Sub-TLV is the bestie for all the BFD-OAM-specific config stuff 🦋 it rides along as a sub-TLV inside the MPLS OAM Configuration Sub-TLV, and it's basically a little container for generic BFD OAM info that carries its own sub-TLVs inside 🧚

    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. Type (1)       |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vers.|N|S|I|G|U|B|       Reserved (set to all 0s)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: BFD Configuration Sub-TLV Format

Type: 1, the BFD Configuration Sub-TLV. 🌸

Length: this is the total length in octets, and it counts the sub-TLVs plus the Type and Length fields too 📏

Version: this tells you which BFD protocol version is being used. If the egress LSR doesn't support that version, an error MUST be generated: "OAM Problem/ Unsupported BFD Version" 😭

BFD Negotiation (N): if this is set, timer negotiation/re-negotiation through BFD Control messages is enabled. If it's cleared, it's disabled 🙈

Symmetric Session (S): if this is set, the BFD session MUST use symmetric timing values. no cap, that's a hard rule 🔥

Integrity (I): if this is set, BFD Authentication MUST be enabled. If the BFD Configuration Sub-TLV doesn't include a BFD Authentication Sub-TLV, the authentication MUST use Keyed SHA1 with an empty pre-shared key (all 0s). If the egress LSR doesn't support BFD Authentication, an error MUST be generated: "OAM Problem/BFD Authentication unsupported" 💀

Encapsulation Capability (G): if this is set, it shows the capability of encapsulating BFD messages into The G-Ach channel. If both the G bit and U bit are set, the configuration gives precedence to the G bit 👑 If the egress LSR doesn't support any of the ingress LSR Encapsulation Capabilities, an error MUST be generated: "OAM Problem/Unsupported BFD Encapsulation format" ✨

Encapsulation Capability (U): if this is set, it shows the capability of encapsulating BFD messages into UDP packets. If both the G bit and U bit are set, the G bit wins 🦋 If the egress LSR doesn't support any of the ingress LSR Encapsulation Capabilities, an error MUST be generated: "OAM Problem/Unsupported BFD Encapsulation Format" 🫶

Bidirectional (B): if this is set, BFD runs in Bidirectional mode. If it's not set, BFD runs in unidirectional mode. In that second case, the source node does not expect any Discriminator values back from the destination node 🌈

Reserved: reserved for future specs. It's set to 0 when sent and ignored when received 🎀

The BFD Configuration Sub-TLV MUST include the following sub-TLVs in the Path message:

  • BFD Identifiers Sub-TLV; and
  • Negotiation Timer Parameters Sub-TLV if the N flag is cleared.

The BFD Configuration Sub-TLV MUST include the following sub-TLVs in the Resv message:

  • BFD Identifiers Sub-TLV; and
  • 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 Negotiation Timer Parameters Sub-TLV received by the egress contains unsupported values. In this case, an updated Negotiation Timer Parameters Sub-TLV containing values supported by the egress LSR MUST be returned to the ingress. 💅

3.3.1. BFD Identifiers Sub-TLV 🧚

The BFD Identifiers Sub-TLV rides along as a sub-TLV of the BFD Configuration Sub-TLV, and 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   BFD Identifiers Type (1)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Local Discriminator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       MPLS-TP Global_ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    MPLS-TP Node Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel_Num          |            LSP_Num            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 3: BFD Identifiers Sub-TLV Format

Type: 1, the BFD Identifiers Sub-TLV. 🌸

Length: the TLV total length in octets, including the Type and Length fields (20). 📏

Local Discriminator: a unique, non-zero discriminator value that the transmitting system generates and that refers to itself. It's used to de-multiplex multiple BFD sessions between the same pair of systems, as defined in [RFC5880]. 🦋

MPLS-TP Global_ID, Node Identifier, Tunnel_Num, and LSP_Num: all set as defined in [RFC6370]. 🎀

3.3.2. Negotiation Timer Parameters Sub-TLV 🌈

The Negotiation Timer Parameters Sub-TLV is carried as a sub-TLV of the BFD Configuration Sub-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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Nego. Timer Type (2)       |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Acceptable Min. Asynchronous TX interval              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Acceptable Min. Asynchronous RX interval              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Required Echo TX Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 4: Negotiation Timer Parameters Sub-TLV Format

Type: 2, the Negotiation Timer Parameters Sub-TLV. 🌸

Length: the TLV total length in octets, including Type and Length fields (16). 📏

Acceptable Min. Asynchronous TX interval: if the S flag is set in the BFD Configuration Sub-TLV, this expresses the desired time interval (in microseconds) at which the ingress LER intends to both transmit and receive BFD periodic control packets. If the egress LSR can't support the value, it SHOULD reply with a supported interval 🥺

If the S flag is cleared in the BFD Configuration Sub-TLV, this field expresses the desired time interval (in microseconds) at which the ingress LSR intends to transmit BFD periodic control packets. 🦋

Acceptable Min. Asynchronous RX interval: if the S flag is set in the BFD Configuration Sub-TLV, this field MUST be set equal to "Acceptable Min. Asynchronous TX interval" on transmit, and MUST be ignored on receipt, since it has no additional meaning beyond what's described for "Acceptable Min. Asynchronous TX interval" 🙃

If the S flag is cleared in the BFD Configuration Sub-TLV, it expresses the minimum time interval (in microseconds) at which the ingress/egress LSRs can receive periodic BFD Control packets. If this value is greater than the "Acceptable Min. Asynchronous TX interval" received from the ingress/egress LSR, the receiving LSR MUST adopt the interval expressed in the "Acceptable Min. Asynchronous RX interval" 🔥

Required Echo TX Interval: the minimum interval (in microseconds) between received BFD Echo packets that this system can support, less any jitter applied by the sender as described in Section 6.8.9 of [RFC5880]. It's also a hint for the receiving system about the minimum interval between transmitted BFD Echo packets. If this value is zero, the transmitting system does not support receiving BFD Echo packets. If the LSR node can't support this value, it SHOULD reply with a supported value (which may be zero if Echo isn't supported) 💅

3.3.3. BFD Authentication Sub-TLV 🔐

The BFD Authentication Sub-TLV is carried as a sub-TLV of the BFD Configuration Sub-TLV, and it's shaped 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      BFD Auth. Type (3)       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |  Auth Key ID  |         Reserved (0s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5: BFD Authentication Sub-TLV Format

Type: 3, the BFD Authentication Sub-TLV. 🌸

Length: the TLV total length in octets, including Type and Length fields (8). 📏

Auth Type: indicates which type of authentication to use. The same values are used as are defined in Section 4.1 of [RFC5880]. If the egress LSR doesn't support this type, an "OAM Problem/Unsupported BFD Authentication Type" error MUST be generated 😤

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 for this document 🤫 If the egress LSR doesn't support this Auth Key ID, an "OAM Problem/Mismatch of BFD Authentication Key ID" error MUST be generated 💀

Reserved: reserved for future specs. It's set to 0 when sent and ignored when received 🎀

3.3.4. Traffic Class Sub-TLV 💜

The Traffic Class Sub-TLV is carried as a sub-TLV of the BFD Configuration Sub-TLV or the Fault Management Signal Sub-TLV (Section 3.5), and it's shown 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Traffic Class Sub-Type (4)   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TC |                 Reserved (set to all 0s)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Traffic Class Sub-TLV Format

Type: 4, the Traffic Class Sub-TLV. 🌸

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

Traffic Class (TC): identifies the TC [RFC5462] for periodic continuity monitoring messages or packets carrying fault management information. 🌈

If the Traffic Class Sub-TLV is present, the value of the TC field MUST be used as the value of the TC field of an MPLS label stack entry. If the Traffic Class Sub-TLV is absent from the BFD Configuration Sub-TLV or Fault Management Signal Sub-TLV, then selecting the TC value is a local decision ✨

3.4. Performance Monitoring Sub-TLV ✨

okay bestie, listen 👂 if the OAM Function Flags Sub-TLV has the PM/Loss, PM/Delay, or PM/Throughput flag set, the Performance Monitoring Sub-TLV MUST be present in the MPLS OAM Configuration Sub-TLV 💅. if you leave out the right sub-TLVs, you MUST get an "OAM Problem/Configuration Error" message generated. no cap, that's not optional 😭

this sub-TLV carries the config info from Section 7 of [RFC6374] 📊. it lets you set quality thresholds, and as [RFC6374] puts it, "the crossing of which will trigger warnings or alarms, and result reporting and exception notification will be integrated into the system-wide network management and reporting framework." iconic 🔥. if you want values that aren't the defaults, the Performance Monitoring Sub-TLV holds these sub-TLVs:

  • MPLS OAM PM Loss Sub-TLV if the PM/Loss and/or PM/Throughput flag is set in the OAM Function Flags Sub-TLV; and
  • MPLS OAM PM Delay Sub-TLV if the PM/Delay flag is set in the OAM Function Flags Sub-TLV.

here's the layout, it's giving very organized 🎀

    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 Type (2)  |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|L|J|Y|K|C|            Reserved (set to all 0s)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Performance Monitoring Sub-TLV Format

Type: 2, the Performance Monitoring Sub-TLV 🦋

Length: the TLV total length in octets, counting the sub-TLVs plus the Type and Length fields 📏

Configuration Flags (for the specific function description, check [RFC6374] 📖):

  • D: Delay inferred/direct (0=INFERRED, 1=DIRECT). if the egress LSR doesn't support the mode you picked, an "OAM Problem/Unsupported Delay Mode" error MUST be generated 🙈
  • L: Loss inferred/direct (0=INFERRED, 1=DIRECT). if the egress LSR doesn't support the mode you picked, an "OAM Problem/Unsupported Loss Mode" error MUST be generated 💀
  • J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). if the egress LSR doesn't 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 doesn't 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 doesn't 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 doesn't support Combined mode and the C flag is set, an "OAM Problem/Combined mode unsupported" error MUST be generated 🫶

Reserved: reserved for future specs, so set it to 0 when you send and ignore it when you receive 🌸

3.4.1. MPLS OAM PM Loss Sub-TLV 🍓

the MPLS OAM PM Loss Sub-TLV 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 Type (1)        |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OTF |T|B|              Reserved (set to all 0s)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Measurement Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Test Interval                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Loss Threshold                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: MPLS OAM PM Loss Sub-TLV Format

Type: 1, the MPLS OAM PM Loss Sub-TLV 🎀

Length: the length of the parameters in octets, including the Type and Length fields (20) ✨

Origin Timestamp Format (OTF): the Origin Timestamp Format of the Origin Timestamp field, described in [RFC6374] ⏱️. by default it's IEEE 1588 version 1. if the egress LSR can't support this value, an "OAM Problem/Unsupported Timestamp Format" error MUST be generated 😭

Configuration Flags (please check [RFC6374] for the details 📖):

  • T: Traffic-class-specific measurement indicator. it's set to 1 when the measurement is scoped to packets of a particular traffic class (Differentiated Service Code Point (DSCP) value), and 0 otherwise. when it's 1, the Differentiated Services (DS) field of the message tells you the measured traffic class. by default it's 1 🌈
  • B: Octet (byte) count. when set to 1, the Counter 1-4 fields are octet counts. when set to 0, they're packet counts. by default it's 0 🔢

Reserved: reserved for future specs, so set it to 0 when you send and ignore it when you receive 🌸

Measurement Interval: the time interval (in milliseconds) at which Loss Measurement query messages MUST be sent in both directions 📨. if the egress LSR can't support the value, it SHOULD reply with a supported interval 🤝. by default it's 100 milliseconds, per [RFC6375] 🦋

Test Interval: the test messages interval (in milliseconds), as described in [RFC6374] 🧪. by default it's 10 milliseconds, per [RFC6375]. if the egress LSR can't support the value, it SHOULD reply with a supported interval 🙌

Loss Threshold: the threshold of measured lost packets per measurement that triggers action(s) when you cross it. action(s) SHOULD be triggered 🚨

3.4.2. MPLS OAM PM Delay Sub-TLV 🧚

the MPLS OAM PM Delay Sub-TLV 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 Delay Type (2)        |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OTF |T|B|             Reserved (set to all 0s)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Measurement Interval                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Test Interval                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Delay Threshold                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: MPLS OAM PM Delay Sub-TLV Format

Type: 2, the MPLS OAM PM Delay Sub-TLV 🌺

Length: the length of the parameters in octets, including the Type and Length fields (20) 📐

OTF: the Origin Timestamp Format of the Origin Timestamp field, described in [RFC6374] ⏰. by default it's IEEE 1588 version 1. if the egress LSR can't support this value, an "OAM Problem/Unsupported Timestamp Format" error MUST be generated 💅

Configuration Flags (please check [RFC6374] for the details 📖):

  • T: Traffic-class-specific measurement indicator. it's set to 1 when the measurement is scoped to packets of a particular traffic class (Differentiated Services Code Point (DSCP) value), and 0 otherwise. when it's 1, the Differentiated Service (DS) field of the message tells you the measured traffic class. by default it's 1 🌈
  • B: Octet (byte) count. when set to 1, the Counter 1-4 fields are octet counts. when set to 0, they're packet counts. by default it's 0 🔢

Reserved: reserved for future specs, so set it to 0 when you send and ignore it when you receive 🌸

Measurement Interval: the time interval (in milliseconds) at which Delay Measurement query messages MUST be sent on both directions 📬. if the egress LSR can't support the value, it SHOULD reply with a supported interval 🤝. by default it's 1000 milliseconds, per [RFC6375] 🕰️

Test Interval: the test messages interval (in milliseconds), as described in [RFC6374] 🧪. by default it's 10 milliseconds, per [RFC6375]. if the egress LSR can't support the value, it SHOULD reply with a supported interval 🙌

Delay Threshold: the threshold of measured two-way delay (in milliseconds) that triggers action(s) when you cross it. action(s) SHOULD be triggered 🚨

3.5. MPLS OAM FMS Sub-TLV ✨

okay so the MPLS OAM FMS Sub-TLV 🦋 rides inside the MPLS OAM Configuration Sub-TLV. when both working and protection paths get signaled, both LSPs SHOULD be signaled with identical settings of the E flag, T flag, and refresh timer. matching twins, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MPLS OAM FMS Type (3)     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|S|T|           Reserved            |      Refresh Timer      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           Sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: MPLS OAM FMS Sub-TLV Format 🎀

Type: 3, the MPLS OAM FMS Sub-TLV 💖

Length: this is the total TLV length in octets, counting the Type and Length fields too, so it's 8 🌸

FMS Signal Flags are the switches that turn on FMS signals at MEPs and at the server MEPs of the links the LSP goes over. in this doc, only the S flag cares about server MEPs 🧚

the flags, in order:

  • E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) signaling as described in [RFC6427]. The default value is 1 (enabled). If the egress MEP does not support FMS signal generation, an "OAM Problem/Fault management signaling unsupported" error MUST be generated. 🔥
  • S: tells a server MEP that it should transmit AIS and LKR signals on client LSPs. The default value is 0 (disabled). If a server MEP, which is capable of generating FMS messages, is for some reason unable to do so for the LSP being signaled, an "OAM Problem/Unable to create fault management association" error MUST be generated. 💅
  • T: sets the timer value, enabled by configuring a specific timer value. The Default value is 0 (disabled). 🌈
  • Remaining bits: reserved for a future specification and set to 0. 🔒

Refresh Timer: this is in seconds, and it's the refresh timer for fault indication messages. the value MUST be between 1 and 20 seconds, the same range as the Refresh Timer field in [RFC6427]. if the egress LSR can't support the value, it SHOULD reply with a timer value it does support 🫶

the Fault Management Signals Sub-TLV MAY include the Traffic Class Sub-TLV (Section 3.3.4.) ✨ if that's there, the TC field value MUST be used as the TC field value of an MPLS label stack entry for FMS messages. if the Traffic Class Sub-TLV is absent, picking the TC value is a local decision 👑

4. Summary of MPLS OAM Configuration Errors 💀

in addition to the error values in [RFC7260], this document defines these values for the "OAM Problem" error code. lowkey the full list of things that can go wrong 😭

  • 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 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 the specified Delay mode, an "OAM Problem/Unsupported Delay Mode" error MUST be generated. 🍓
  • If an egress LSR does not support the 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. 🫠

5. IANA Considerations 📋

5.1. MPLS OAM Type

this document specifies the new MPLS OAM type. IANA has allocated type (3) from the "OAM Types" space of the "RSVP-TE OAM Configuration Registry" 🎀

                    +------+-------------+-----------+
                    | Type | Description | Reference |
                    +------+-------------+-----------+
                    |  3   |   MPLS OAM  | [RFC7487] |
                    +------+-------------+-----------+

Table 1: MPLS OAM Type

5.2. MPLS OAM Configuration Sub-TLV

this document specifies the MPLS OAM Configuration Sub-TLV. IANA has allocated type (33) from the OAM Sub-TLV space of the "RSVP-TE OAM Configuration Registry" 🌸

           +------+--------------------------------+-----------+
           | Type |          Description           | Reference |
           +------+--------------------------------+-----------+
           |  33  | MPLS OAM Configuration Sub-TLV | [RFC7487] |
           +------+--------------------------------+-----------+

Table 2: MPLS OAM Configuration Sub-TLV Type

5.3. MPLS OAM Configuration Sub-TLV Types

IANA has created an "MPLS OAM Configuration Sub-TLV Types" sub-registry in the "RSVP-TE OAM Configuration Registry" for the sub-TLVs carried in the MPLS OAM Configuration Sub-TLV. new values from this sub-registry are to be allocated through IETF Review, except for the "Reserved for Experimental Use" range. this document defines these types: 🧚

       +-------------+--------------------------------+-----------+
       |     Type    |          Description           | Reference |
       +-------------+--------------------------------+-----------+
       |      0      |            Reserved            | [RFC7487] |
       |      1      |   BFD Configuration Sub-TLV    | [RFC7487] |
       |      2      | Performance Monitoring Sub-TLV | [RFC7487] |
       |      3      |      MPLS OAM FMS Sub-TLV      | [RFC7487] |
       |   4-65532   |           Unassigned           |           |
       | 65533-65534 | Reserved for Experimental Use  | [RFC7487] |
       |    65535    |            Reserved            | [RFC7487] |
       +-------------+--------------------------------+-----------+

Table 3: MPLS OAM Configuration Sub-TLV Types

5.4. BFD Configuration Sub-TLV Types

IANA has created a "BFD Configuration Sub-TLV Types" sub-registry in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the BFD Configuration Sub-TLV. new values from this sub-registry are to be allocated through IETF Review, except for the "Reserved for Experimental Use" range. this document defines these types: 🔥

    +-------------+--------------------------------------+-----------+
    |     Type    |             Description              | Reference |
    +-------------+--------------------------------------+-----------+
    |      0      |               Reserved               | [RFC7487] |
    |      1      |       BFD Identifiers Sub-TLV        | [RFC7487] |
    |      2      | Negotiation Timer Parameters Sub-TLV | [RFC7487] |
    |      3      |      BFD Authentication Sub-TLV      | [RFC7487] |
    |      4      |        Traffic Class Sub-TLV         | [RFC7487] |
    |   5-65532   |              Unassigned              |           |
    | 65533-65534 |    Reserved for Experimental Use     | [RFC7487] |
    |    65535    |               Reserved               | [RFC7487] |
    +-------------+--------------------------------------+-----------+

Table 4: BFD Configuration Sub-TLV Types

5.5. Performance Monitoring Sub-TLV Types

IANA has created a "Performance Monitoring Sub-TLV Type" sub-registry in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Performance Monitoring Sub-TLV. new values from this sub-registry are to be allocated through IETF Review, except for the "Reserved for Experimental Use" range. this document defines these types: 📊

        +-------------+-------------------------------+-----------+
        |     Type    |          Description          | Reference |
        +-------------+-------------------------------+-----------+
        |      0      |            Reserved           | [RFC7487] |
        |      1      |    MPLS OAM PM Loss Sub-TLV   | [RFC7487] |
        |      2      |   MPLS OAM PM Delay Sub-TLV   | [RFC7487] |
        |   3-65532   |           Unassigned          |           |
        | 65533-65534 | Reserved for Experimental Use | [RFC7487] |
        |    65535    |            Reserved           | [RFC7487] |
        +-------------+-------------------------------+-----------+

Table 5: Performance Monitoring Sub-TLV Types

5.6. New RSVP-TE Error Codes 🎀

okay so the "OAM Problem" error code from [RFC7260] has a bunch of new sub-codes now, and they were handed out through IETF Review 💅 Every one of them points back to [RFC7487], so this is the list of MPLS OAM configuration errors:

+------------------+------------------------------------+-----------+
| Error Value Sub- | Description                        | Reference |
| Codes            |                                    |           |
+------------------+------------------------------------+-----------+
| 13               | Unsupported BFD Version            | [RFC7487] |
| 14               | Unsupported BFD Encapsulation      | [RFC7487] |
|                  | format                             |           |
| 15               | Unsupported BFD Authentication     | [RFC7487] |
|                  | Type                               |           |
| 16               | Mismatch of BFD Authentication Key | [RFC7487] |
|                  | ID                                 |           |
| 17               | Unsupported Timestamp Format       | [RFC7487] |
| 18               | Unsupported Delay Mode             | [RFC7487] |
| 19               | Unsupported Loss Mode              | [RFC7487] |
| 20               | Delay variation unsupported        | [RFC7487] |
| 21               | Dyadic mode unsupported            | [RFC7487] |
| 22               | Loopback mode unsupported          | [RFC7487] |
| 23               | Combined mode unsupported          | [RFC7487] |
| 24               | Fault management signaling         | [RFC7487] |
|                  | unsupported                        |           |
| 25               | Unable to create fault management  | [RFC7487] |
|                  | association                        |           |
+------------------+------------------------------------+-----------+

Table 6: MPLS OAM Configuration Error Codes

the "Sub-Codes - 40 OAM Problem" sub-registry lives in the "Error Codes and Globally-Defined Error Value Sub-Codes" registry, so that's where you'll find these 🧚

6. Security Considerations 💀

okay this part is lowkey important, so pay attention 👀 Putting OAM parameters into signaling and having OAM entities set themselves up automatically adds security concerns on top of the ones already covered in [RFC3473]. The big worry is overload: if an attacker asks for high-frequency liveliness monitoring on a whole bunch of LSPs, all aimed at one network element, that box could get swamped. [RFC7260] and [RFC6060] talk about this same risk.

If you want more security background on MPLS and GMPLS, [RFC5920] is the place to look 🔒

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Resource ReserVation Protocol-
           Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
           January 2003, <http://www.rfc-editor.org/info/rfc3473>.

[RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
           Sprecher, N., and S. Ueno, "Requirements of an MPLS
           Transport Profile", RFC 5654, September 2009,
           <http://www.rfc-editor.org/info/rfc5654>.

[RFC5860]  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, <http://www.rfc-editor.org/info/rfc5860>.

[RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD)", RFC 5880, June 2010,
           <http://www.rfc-editor.org/info/rfc5880>.

[RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
           "Bidirectional Forwarding Detection (BFD) for MPLS Label
           Switched Paths (LSPs)", RFC 5884, June 2010,
           <http://www.rfc-editor.org/info/rfc5884>.

[RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
           "Generalized Multiprotocol Label Switching (GMPLS) Control
           of Ethernet Provider Backbone Traffic Engineering (PBB-
           TE)", RFC 6060, March 2011,
           <http://www.rfc-editor.org/info/rfc6060>.

[RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
           Profile (MPLS-TP) Identifiers", RFC 6370, September 2011,
           <http://www.rfc-editor.org/info/rfc6370>.

[RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
           Measurement for MPLS Networks", RFC 6374, September 2011,
           <http://www.rfc-editor.org/info/rfc6374>.

[RFC6427]  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,
           <http://www.rfc-editor.org/info/rfc6427>.

[RFC6428]  Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
           "Proactive Connectivity Verification, Continuity Check,
           and Remote Defect Indication for the MPLS Transport
           Profile", RFC 6428, November 2011,
           <http://www.rfc-editor.org/info/rfc6428>.

[RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
           Extensions for Operations, Administration, and Maintenance
           (OAM) Configuration", RFC 7260, June 2014,
           <http://www.rfc-editor.org/info/rfc7260>.

7.2. Informative References

[LSP-PING-CONF]
           Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P.,
           Ward, D., and J. Drake, "Configuration of Proactive
           Operations, Administration, and Maintenance (OAM)
           Functions for MPLS-based Transport Networks using LSP
           Ping", Work in Progress, draft-ietf-mpls-lsp-ping-mpls-tp-
           oam-conf-09, January 2015.

[RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
           (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
           Class" Field", RFC 5462, February 2009,
           <http://www.rfc-editor.org/info/rfc5462>.

[RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
           Networks", RFC 5920, July 2010,
           <http://www.rfc-editor.org/info/rfc5920>.

[RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
           Administration, and Maintenance Framework for MPLS-Based
           Transport Networks", RFC 6371, September 2011,
           <http://www.rfc-editor.org/info/rfc6371>.

[RFC6375]  Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
           Delay Measurement Profile for MPLS-Based Transport
           Networks", RFC 6375, September 2011,
           <http://www.rfc-editor.org/info/rfc6375>.

Acknowledgements 🫶

The authors would like to thank David Allan, Lou Berger, Annamaria Fulignoli, Eric Gray, Andras Kern, David Jocha, and David Sinicrope for their useful comments. these people are literally the best 💜

Contributors ✨

This document is the result of a large team of authors and contributors. The following is a list of the contributors:

John Drake

Benoit Tremblay

Authors' Addresses 🦋

Elisa Bellagamba
Ericsson

EMail: elisa.bellagamba@ericsson.com


Attila Takacs
Ericsson

EMail: attila.takacs@ericsson.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 70 7957731
EMail: pontus.skoldstrom@acreo.se


Dave Ward
Cisco

EMail: dward@cisco.com
📦 where this page comes from