RFC 7369

GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration

📅 published October 2014, from ietf

GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration 🎀

okay bestie, let's get into RFC 7369 🦋 Here's the title block tea first:

RFC number: 7369
Category: Standards Track ✨
Date: October 2014 🌸
ISSN: 2070-1721
Authors: A. Takacs (Ericsson), B. Gero (Ericsson), and H. Long (Huawei) 👑
Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates, so this one is standing on its own 💅

Abstract ✨

so the GELS crew (GMPLS Ethernet Label Switching) took GMPLS RSVP-TE and made it able to set up Ethernet Label Switching Paths (LSPs) 🫶 IEEE Ethernet Connectivity Fault Management (CFM) gives you an adjunct OAM flow that checks connectivity in Ethernet networks. CFM can also be used on Ethernet LSPs to detect faults and kick off recovery mechanisms, which is so useful 🔥 ITU-T Y.1731 builds on CFM and adds more OAM mechanisms for Ethernet networks, including Performance Monitoring 📊

This document extends GMPLS RSVP-TE so it can set up the matching Ethernet OAM entities for Ethernet LSPs. It also defines Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework 🧚 And the best part is that it supports the IEEE and ITU-T OAM mechanisms without changing them at all. No notes 🙈

Status of This Memo ✨

this is an Internet Standards Track document 🎀 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and feedback, go to http://www.rfc-editor.org/info/rfc7369 🌈

Copyright Notice 💜

© 2014 IETF Trust and the people listed 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, which you can find at http://trustee.ietf.org/license-info as of the publication date. Read those carefully, because they spell out your rights and restrictions. Any code components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as the Simplified BSD License describes 🫶

Table of Contents 🍓

1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Overview of Ethernet OAM Operation  . . . . . . . . . . . . .   3
3.  GMPLS RSVP-TE Extensions  . . . . . . . . . . . . . . . . . .   5
  3.1.  Operation Overview  . . . . . . . . . . . . . . . . . . .   5
  3.2.  OAM Configuration TLV . . . . . . . . . . . . . . . . . .   7
  3.3.  Ethernet OAM Configuration Sub-TLV  . . . . . . . . . . .   8
    3.3.1.  MD Name Sub-TLV . . . . . . . . . . . . . . . . . . .   9
    3.3.2.  Short MA Name Sub-TLV . . . . . . . . . . . . . . . .  10
    3.3.3.  MEP ID Sub-TLV  . . . . . . . . . . . . . . . . . . .  11
    3.3.4.  Continuity Check (CC) Sub-TLV . . . . . . . . . . . .  12
  3.4.  Proactive Performance Monitoring  . . . . . . . . . . . .  12
  3.5.  Summary of Ethernet OAM Configuration Errors  . . . . . .  13
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
  4.1.  RSVP-TE OAM Configuration Registry  . . . . . . . . . . .  14
  4.2.  Ethernet Sub-TLVs Sub-Registry  . . . . . . . . . . . . .  15
  4.3.  RSVP Error Code . . . . . . . . . . . . . . . . . . . . .  15
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  17
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Background 🌸

okay so Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE.802.1Q-2011] splits the Ethernet data plane from the control plane, which lets outside control and management systems build explicitly routed Ethernet connections. PBB-TE also has protection switching for bidirectional Ethernet connections 🔥 Ethernet Connectivity Fault Management (CFM) adds an adjunct connectivity-monitoring OAM flow to check that Ethernet networks are alive [IEEE.802.1Q-2011], including monitoring specific explicitly routed Ethernet connections. Then ITU-T Recommendation Y.1731 [ITU-T.G.8013-2013] extended CFM and added more OAM functionality 💅

In the IETF, the GELS work extended the GMPLS control plane so it can set up explicitly routed Ethernet connections [RFC5828] [RFC6060]. We call GMPLS-established Ethernet connections "Ethernet LSPs" 🦋 GELS lets you use MPLS-TE and GMPLS provisioning and recovery features in Ethernet networks, and honestly that's giving main character energy ✨

Using GMPLS RSVP-TE to set up and configure OAM entities with LSP signaling is defined in a technology-agnostic way in [RFC7260]. This document's job is to specify the extra technology-specific OAM entities needed to support Ethernet connections 🧚

1.1. Requirements Language 💜

okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🫶

2. Overview of Ethernet OAM Operation 🎀

for this doc we only cover the Ethernet OAM bits that matter for proactive connectivity monitoring of Ethernet LSPs. On-demand OAM functions are assumed to be handled by management-plane operations 💖

PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as provisioned, traffic-engineered, unidirectional connectivity. They're identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where ESP-MAC DA is the ESP's destination address, ESP-MAC SA is its source address, and ESP-VID is a VLAN identifier allocated for explicitly routed connections. To make a bidirectional PBB-TE connection, you combine two co-routed point-to-point ESPs. The combined ESPs must have the same ESP-MAC addresses, but they may have different ESP-VIDs. The result is a co-routed bidirectional path, where the forward and backward directions follow the same route (links and nodes) across the network 🌈

Heads up, it would technically be possible to set up one unidirectional ESP with GMPLS, but the Ethernet OAM mechanisms only work fully with bidirectional connections that use co-routed ESPs. So this document only covers bidirectional point-to-point PBB-TE connections 🙈

At both ends of a bidirectional point-to-point PBB-TE connection, one Maintenance Entity Group End Point (MEP) is configured. The MEPs monitoring a PBB-TE connection must be configured with the same Maintenance Domain Level (MD Level) and Maintenance Association Identifier (MAID). Each MEP has a unique identifier, the MEP ID. Besides those identifiers, a MEP monitoring a PBB-TE connection must be provisioned with the 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs ✨

For point-to-point VLAN connections, the connection can be identified with a single VLAN or with two VLANs, one per direction. So instead of the PBB-TE ESP 3-tuples, MEPs must be provisioned with the proper VLAN identifiers 💅

MEPs exchange Connectivity Check Messages (CCMs) periodically at fixed intervals. [IEEE.802.1Q-2011] defines eight distinct intervals 🍓

             +---+--------------------+----------------+
             | # | CCM Interval (CCI) | 3-Bit Encoding |
             +---+--------------------+----------------+
             | 0 |      Reserved      |      000       |
             |   |                    |                |
             | 1 |      3 1/3 ms      |      001       |
             |   |                    |                |
             | 2 |       10 ms        |      010       |
             |   |                    |                |
             | 3 |       100 ms       |      011       |
             |   |                    |                |
             | 4 |        1 s         |      100       |
             |   |                    |                |
             | 5 |        10 s        |      101       |
             |   |                    |                |
             | 6 |       1 min        |      110       |
             |   |                    |                |
             | 7 |       10 min       |      111       |
             +---+--------------------+----------------+
                   Table 1: CCM Interval Encoding

if three consecutive CCMs get lost, connectivity failure is declared 💀 The MEP that detects the failure signals the defect to the remote MEP in the next CCMs it sends, by setting the Remote Defect Indicator (RDI) bit in the CCM. If a MEP gets a CCM with the RDI bit set, it declares failure right away. Detecting a failure may trigger protection switching mechanisms, or it may be signaled to a management system 🔥

at each transit node, Maintenance Entity Group Intermediate Points (MIPs) may be set up to help localize failures, for example with link trace and loopback functions. MIPs need to be provisioned with a subset of the MEP identification parameters described above 🧚

3. GMPLS RSVP-TE Extensions 🌈

3.1. Operation Overview ✨

okay so bestie, to make connectivity monitoring easy to set up, the associated MEPs should be automatically established when an Ethernet LSP gets signaled 🦋. To monitor an Ethernet LSP, a set of parameters must be provided to set up a Maintenance Association and related MEPs. Optionally, MIPs may be created at the transit nodes of the Ethernet LSP 🧚. The LSP Attribute Flags "OAM MEP entities desired" and "OAM MIP entities desired", as described in [RFC7260], are used to signal that the respective OAM entities must be established 💅. An OAM Configuration TLV, as described in [RFC7260], is added to the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that Ethernet OAM is to be set up for the LSP. Information specific to Ethernet OAM, as described below, is carried in the new Ethernet OAM Configuration Sub-TLV (see Section 3.3) within the OAM Configuration TLV 🌸.

A unique MAID must be allocated for the PBB-TE connection, and both MEPs must be configured with the same information 🎀. The MAID consists of an optional Maintenance Domain Name (MD Name) and a mandatory Short Maintenance Association Name (Short MA Name). Various formatting rules for these names have been defined in [IEEE.802.1Q-2011]. Since this information is also carried in all CCMs, the combined length of the MD Name and Short MA Name is limited to 44 bytes (see [IEEE.802.1Q-2011] for the details of the message format). How these parameters are determined is out of the scope of this document.
Each MEP must be provisioned with a MEP ID. The MEP ID uniquely identifies a given MEP within a Maintenance Association. That is, the combination of MAID and MEP ID must uniquely identify a MEP. How the value of the MEP ID is determined is out of the scope of this document 🫶.
The Maintenance Domain Level (MD Level) allows hierarchical separation of monitoring entities. [IEEE.802.1Q-2011] allows differentiation of eight levels. How the value of the MD Level is determined is out of the scope of this document. Note that probably for all Ethernet LSPs, a single (default) MD Level will be used within a network domain 🌈.
The desired CCM Interval must be specified by the management system based on service requirements or operator policy. The same CCM Interval must be set in each of the MEPs monitoring a given Ethernet LSP. How the value of the CCM Interval is determined is out of the scope of this document ⭐.
The desired forwarding priority to be set by MEPs for the CCM frames may be specified. The same CCM priority must be set in each of the MEPs monitoring a given Ethernet LSP. How CCM priority is determined is out of the scope of this document. Note that the highest priority should be used as the default CCM priority 👑.
MEPs must be aware of their own reachability parameters and those of the remote MEP. In the case of bidirectional point-to-point PBB-TE connections, this requires that the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are configured in each MEP, where the ESP-MAC A is the same as the local MEP's Media Access Control (MAC) address and ESP-MAC B is the same as the remote MEP's MAC address. The GMPLS Ethernet Label format, as defined in [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence, the necessary reachability parameters for the MEPs can be obtained from the Ethernet Labels (i.e., carried in the downstream and upstream labels). In the case of point-to-point VLAN connections, MEPs need to be provisioned with the VLAN identifiers only, which can be derived similarly from the Ethernet Labels 🍓.

Based on the procedures described in [RFC6060] for bidirectional PBB-TE Ethernet LSP establishment, the Ethernet OAM configuration procedures are as follows 🔥.

When the RSVP-TE signaling is initiated for the bidirectional Ethernet LSP, the local node generates a Path message and:

Allocates an upstream label formed by combining its MAC address (ESP-MAC A) and locally selected VID (ESP-VID1), which will be used to receive traffic;
MUST include the OAM Configuration TLV with OAM Type set to Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects;
MUST include the OAM Function Flags Sub-TLV in the OAM Configuration TLV and set the OAM function flags as needed;
MUST include an Ethernet OAM Configuration Sub-TLV in the OAM Configuration TLV that specifies the CCM Interval and MD Level;
MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, which will unambiguously identify a Maintenance Association for this specific PBB-TE connection. Note that values for these parameters may be derived from the GMPLS LSP identification parameters; and
MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration Sub-TLV and select two distinct integer values to identify the local and remote MEPs within the Maintenance Association created for monitoring of the point-to-point PBB-TE connection 💖.

Once the remote node receives the Path message, it can use the UPSTREAM_LABEL to extract the reachability information of the initiator. Then, it allocates a Label by selecting a local MAC address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive traffic. These parameters determine the reachability information of the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the Ethernet Labels. In addition, the information received in the Ethernet OAM Configuration TLV is used to configure the local MEP 🦋.

Once the Resv message successfully arrives to the initiator, this end can extract the remote side's reachability information from the Label object and therefore has all the information needed to properly configure its local MEP ✨.

3.2. OAM Configuration TLV 🎀

This TLV is specified in [RFC7260] and is used to select which OAM technology/method should be used for the LSP. In this document, a new OAM Type, Ethernet OAM, is defined. IANA has allocated OAM Type 1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry" 🌸.

RSVP-TE OAM Configuration Registry

  OAM Type           Description
------------      ------------------
    1               Ethernet OAM

When the Ethernet OAM Type is requested, the receiving node should look for the corresponding technology-specific Ethernet OAM Configuration Sub-TLV 🧚.

3.3. Ethernet OAM Configuration Sub-TLV 💅

The Ethernet OAM Configuration Sub-TLV (depicted below) is defined for configuration parameters specific to Ethernet OAM. The Ethernet OAM Configuration Sub-TLV, when used, MUST be carried in the OAM Configuration TLV. This new sub-TLV accommodates Ethernet OAM information and carries sub-TLVs 🫶.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type 32             |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.|           Reserved (set to all 0s)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                           Sub-TLVs                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV. IANA has assigned the value 32 from the "OAM Sub-TLVs" space in the "RSVP-TE OAM Configuration Registry" 🍓.

Length: Indicates the total length of the TLV including padding and including the Type and Length fields.

Version: Identifies the CFM protocol version according to [IEEE.802.1Q-2011]. If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version" 🙈.

MD L. (MD Level): Indicates the desired MD Level. Possible values are defined according to [IEEE.802.1Q-2011]. If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level" 💀.

3.3.1. MD Name Sub-TLV 🌈

The optional MD Name Sub-TLV is depicted below. It MAY be used for MD naming 🦋.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type (1)            |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Format     |  Name Length  |   Reserved (set to all 0s)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                            MD Name                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 1, MD Name Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV 🧚.

Length: Indicates the total length of the TLV, including padding and the Type and Length fields.

Format: According to [IEEE.802.1Q-2011].

Name Length: The length of the MD Name field in bytes. This is necessary to allow non-4-byte padded MD Name lengths.

MD Name: Variable-length field, formatted according to the format specified in the Format field.

If an undefined Format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem" 💅.

Note that it is allowed to have no MD Name; therefore, the MD Name Sub-TLV is optional. In this case, the MA Name must uniquely identify a Maintenance Association 🫶.

3.3.2. Short MA Name Sub-TLV ✨

Okay so the Short MA Name Sub-TLV is up next, and it's giving main character energy 💅 Here's how it's laid out:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (2)            |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Format     |  Name Length  |   Reserved (set to all 0s)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Short MA Name                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV, so don't skip it 🫶

Type: 2, which is the Short MA Name Sub-TLV. IANA keeps an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types that ride inside the Ethernet OAM Configuration Sub-TLV.

Length: the total length of the TLV, counting padding and the Type and Length fields too.

Format: this one is defined by [IEEE.802.1Q-2011] 🎀

Name Length: how many bytes the Short MA Name field takes up. It's needed so that MA Name lengths that aren't a multiple of 4 bytes can still be handled 🌸

Short MA Name: a variable-length field, formatted however the Format field says it should be.

Now the rules, bestie 👑 If an undefined Format shows up, an error MUST be generated: "OAM Problem/Unknown MA Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If that gets violated, an error MUST be generated: "OAM Problem/Name Length Problem". And here's the tea: you're allowed to have no MD Name at all 🙈 If you don't have one, the MA Name MUST uniquely identify a Maintenance Association.

3.3.3. MEP ID Sub-TLV 🦋

The MEP ID Sub-TLV is next, and it also MUST be present in the Ethernet OAM Configuration 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (3)            |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Local MEP ID           |T|R|      Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Remote MEP ID          |T|R|      Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 3, the MEP ID Sub-TLV. IANA keeps an Ethernet TLV Type space for it in the "RSVP-TE OAM Configuration Registry", for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.

Length: the total length of the TLV, padding and Type and Length fields included.

Local MEP ID: a 16-bit integer from 1-8191, naming the MEP ID on the initiator side.

Remote MEP ID: also a 16-bit integer from 1-8191, and this is the MEP ID that gets set for the MEP sitting on the receiving side. The initiator node is the one who decides this value. It works like this because every PBB-TE connection gets its own brand new MAID, and MEP IDs only need to be unique inside the scope of that MAID. Smart, right? 🧠✨

Two flags live here: Transmit (T) and Receive (R). When T is set, the matching MEP MUST send OAM packets. When R is set, the matching MEP MUST expect to receive OAM packets. These flags are how you set up the role each MEP plays 🔥

3.3.4. Continuity Check (CC) Sub-TLV 💜

The Continuity Check (CC) Sub-TLV is last in this group, and yep, it MUST be present in the Ethernet OAM Configuration Sub-TLV too 🌈

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (4)            |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prio  | CCM I |           Reserved (set to all 0s)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 4, the Continuity Check (CC) Sub-TLV. IANA maintains an Ethernet TLV Type space for it in the "RSVP-TE OAM Configuration Registry", covering the sub-TLV types that go inside the Ethernet OAM Configuration Sub-TLV.

Length: the total length of the TLV, padding and Type and Length fields included.

Prio: this sets the priority for CCM frames. Ethernet uses 3 bits in VLAN TAGs to carry priority info. Setting the priority is optional. If the most significant bit is 0, the 3 priority bits after it get ignored, and the CCM frame's priority bits are set from the default values on the Ethernet nodes. If the most significant bit is 1, then those 3 bits are used to set the CCM frame's priority bits.

CCM I (CCM Interval): this MUST be set using the 3-bit encoding from [IEEE.802.1Q-2011] shown in Table 1. Because of that, the most significant bit ends up being 0. Four bits are reserved so that CCM Intervals can be configured in the future. If a node doesn't support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval" 😭

3.4. Proactive Performance Monitoring 📈

Ethernet OAM Performance Monitoring (PM) functions let you measure things like Frame Loss Ratio, Frame Delay, and Frame Delay Variation, as defined in [ITU-T.G.8013-2013]. Only some PM functions run proactively, meaning they keep watching the connection's performance all the time. Proactive PM helps Fault Management by flagging when service performance drops, so it can kick off recovery procedures 🚑

On-demand PM functions, for this document, are always started by management commands. For proactive PM, though, it can make sense to use the control plane for configuration and activation, alongside Fault Management functions like the Continuity Check 💅

[ITU-T.G.8013-2013] defines dual-ended Loss Measurement as proactive OAM for Performance Monitoring, and as a PM function that applies to Fault Management too. With dual-ended Loss Measurement, each MEP piggybacks its transmitted and received frame counters onto CC messages. That lets the MEPs support and synchronize bidirectional Loss Measurements. To turn it on, you set the Performance Monitoring/Loss OAM Function Flag and the Continuity Check Flag in the OAM Function Flags Sub-TLV [RFC7260], and you configure the Continuity Check by including the Ethernet OAM Configuration Sub-TLV. That's it, no extra configuration needed for this kind of Loss Measurement 🎀

3.5. Summary of Ethernet OAM Configuration Errors 🚨

In addition to the error values in [RFC7260], this document defines the following values for the "OAM Problem" Error Code.

If a node doesn't support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version".
If a node doesn't support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".
If an undefined MD name format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format".
If an undefined MA name format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format".
The combined length of MD Name and Short MA Name must be less than or equal to 44 bytes. If that's violated, an error MUST be generated: "OAM Problem/Name Length Problem".
If a node doesn't support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".

4. IANA Considerations 🌸

4.1. RSVP-TE OAM Configuration Registry 🍓

IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has assigned an "OAM Type" from this registry like so:

"Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry".
"Ethernet OAM Configuration Sub-TLV" has been allocated type 32 from the technology-specific range of the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry".

RSVP-TE OAM Configuration Registry

  OAM Types

  OAM Type Number | Description  | Reference
  -------------------------------------------
        1         | Ethernet OAM | [RFC7369]


  OAM Sub-TLVs

  Sub-TLV Type |        Description               |   Ref.
  -----------------------------------------------------------
      32       |Ethernet OAM Configuration Sub-TLV| [RFC7369]

4.2. Ethernet Sub-TLVs Sub-Registry 🧁

IANA will maintain an "Ethernet Sub-TLVs Sub-Registry" in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. This document defines the following types.

Ethernet Sub-TLVs Sub-Registry

   Range       |  Registration Procedures
   ------------+--------------------------
   0-65534     |  IETF Review
    65535      |  Experimental

  Sub-TLV Type |      Description               |  Ref.
  ---------------------------------------------------------
      0        |  Reserved                      | [RFC7369]
      1        |  MD Name Sub-TLV               | [RFC7369]
      2        |  Short MA Name Sub-TLV         | [RFC7369]
      3        |  MEP ID Sub-TLV                | [RFC7369]
      4        |  Continuity Check Sub-TLV      | [RFC7369]
      5-65534  |  Unassigned                    | [RFC7369]
      65535    |  Reserved for Experimental Use | [RFC7369]

4.3. RSVP Error Code 🚫

IANA maintains an Error Code, "OAM Problem", in the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines a set of Error Value sub-codes for the "OAM Problem" Error Code. This document adds some more Error Value sub-codes for the "OAM Problem" Error Code, summarized below 💜

       Value | Description               | Reference
      -------+---------------------------+-----------
           7  | Unsupported OAM Version   | [RFC7369]
           8  | Unsupported MD Level      | [RFC7369]
           9  | Unknown MD Name Format    | [RFC7369]
          10  | Unknown MA Name Format    | [RFC7369]
          11  | Name Length Problem       | [RFC7369]
          12  | Unsupported CC Interval   | [RFC7369]

5. Security Considerations 🔐✨

okay bestie, this part is SERIOUS so let's be serious for a sec 💅 This document does not introduce any additional security issues to those discussed in [RFC7260] and [RFC6060]. Nothing new to worry about there, periodt 🌸

Here's the plot twist 👀 The signaling of OAM-related parameters and the automatic establishment of OAM entities based on RSVP-TE messages add a new aspect to the security considerations discussed in [RFC3473]. Lowkey scary: a network element could get overloaded if a remote attacker targeted it by sending frequent periodic messages asking for liveliness monitoring of a high number of LSPs 😭 The good news is that this kind of attack can be efficiently prevented when mechanisms for message integrity and node authentication are deployed 🛡️ Also, since the OAM configuration extensions rely on the hop-by-hop exchange of existing RSVP-TE messages, the procedures specified for RSVP message security in [RFC2747] can be used to mitigate possible attacks. Bestie, use those tools 🫶

⚠️ Overloading a node with OAM liveliness requests is a real risk, so think about integrity and node authentication early.

For a more comprehensive discussion of GMPLS security and attack mitigation techniques, check out "Security Framework for MPLS and GMPLS Networks" [RFC5920] 🦋

6. References 📚

6.1. Normative References

[IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[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.
[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.
[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.

6.2. Informative References

[ITU-T.G.8013-2013] International Telecommunications Union, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2011.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000, http://www.rfc-editor.org/info/rfc2747.
[RFC3473] Berger, L., "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.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010, http://www.rfc-editor.org/info/rfc5828.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010, http://www.rfc-editor.org/info/rfc5920.

Acknowledgements 🎀

The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful comments. Iconic squad 👑

Contributors 🧚

Don Fedyk
EMail: don.fedyk@hp.com

Dinesh Mohan
EMail: dinmohan@hotmail.com

Authors' Addresses 💌

Attila Takacs
Ericsson
Konyves Kalman krt. 11.
Budapest  1097
Hungary

EMail: attila.takacs@ericsson.com


Balazs Peter Gero
Ericsson
Konyves Kalman krt. 11.
Budapest  1097
Hungary

EMail: balazs.peter.gero@ericsson.com


Hao Long
Huawei
China

EMail: lonho@huawei.com

📦 where this page comes from

ietf: rfc7369 2014-10
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms