| Internet-Draft | OAM CCM Interval Mod | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
In IEEE 802.1ag Connectivity Fault Management (CFM), the Continuity Check Message (CCM) interval is a static parameter that must match on both peer Maintenance End Points (MEPs). Changing the interval at runtime on one MEP without simultaneously updating the peer causes a Loss of Continuity (LOC) defect and may trigger protection switching.¶
Because the CFM PDU formats and OpCode space are governed by IEEE 802.1, this document does not modify the protocol; instead, it specifies a coordinated management-plane procedure that transitions both MEPs to a new CCM interval without raising spurious defects or triggering protection switching, together with failure handling and rollback behavior. The procedure can be operated through existing configuration models such as the connection-oriented OAM YANG model.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 January 2027.¶
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Ethernet Connectivity Fault Management (CFM) [IEEE-802.1ag] [ITU-Y.1731] uses Continuity Check Messages (CCMs) for periodic connectivity verification between Maintenance End Points (MEPs). A receiving MEP declares Loss of Continuity (LOC) if no valid CCM arrives within 3.5 times the configured interval. [IEEE-802.1ag] defines eight interval values, ranging from 3.3 ms to 10 minutes, encoded as the 3-bit Period field in the CCM PDU.¶
Both peer MEPs in a Maintenance Association must use the same CCM interval. [IEEE-802.1ag] treats this interval as a static provisioning parameter set before session establishment. No in-band signaling exists to modify the interval during the session lifetime. When an operator needs to change the interval -- for example, increasing the rate during troubleshooting and reducing it afterward -- each MEP must be reconfigured separately. The time gap between the two reconfigurations creates a window of mismatched intervals that triggers LOC defects and may cause protection switching.¶
The IETF's BFD protocol [RFC5880] includes built-in timer negotiation (Section 6.8.2 of [RFC5880]): each BFD Control packet carries the sender's desired intervals, and peers adjust continuously. Ethernet CCM lacks equivalent in-band interval signaling. This document specifies a coordinated management-plane procedure for CCM interval modification.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the CFM terminology from [IEEE-802.1ag] and [ITU-Y.1731]. In this document, "CCM interval" and "CCM Period" both refer to the value encoded in the 3-bit Period field of the CCM PDU.¶
[IEEE-802.1ag] and [ITU-Y.1731] define the CCM format, interval encoding, and LOC detection. This document extends CFM with a signaling procedure for runtime interval changes; it does not modify the existing CCM processing rules. [RFC5880] defines BFD with built-in timer negotiation. The procedure in this document serves the same operational purpose for CCM but is adapted to CCM's constraints. [RFC7369] specifies GMPLS extensions for CCM interval provisioning at session setup. This document addresses the case of interval changes after session establishment. [RFC8531] defines a YANG data model for connection-oriented OAM including CCM. The extension in this document is compatible with that model.¶
This document defines a management-plane procedure that changes the CCM interval of an active Maintenance Association without inducing spurious LOC defects. The procedure does not modify the CCM PDU, define new CFM OpCodes or TLVs, or alter the CCM processing rules of [IEEE-802.1ag]; all protocol elements on the wire remain unchanged. The CFM PDU and OpCode space are governed by IEEE 802.1, and protocol extensions to CFM are outside the scope of the IETF.¶
The procedure is executed by a coordinating management system (a controller or an orchestration function) that has configuration access to both MEPs, for example through the YANG model of [RFC8531].¶
The management system instructs both MEPs to enter a transition window in which LOC defect consequences are suppressed: alarm generation and protection-switching actions triggered by LOC for the affected Maintenance Association are temporarily inhibited. The window duration MUST be bounded by a configured value; a default of 3 times the larger of the old and new intervals plus the expected configuration propagation delay is RECOMMENDED.¶
The management system reconfigures the CCM interval on both MEPs to the new value, in either order. During the window, interval mismatch between the two MEPs may cause CCM defect conditions (such as LOC at the MEP still running the shorter interval); these are suppressed per Phase 1 and clear once both MEPs operate at the new interval.¶
After confirming that both MEPs report the new interval and that CCM reception is healthy (no active LOC), the management system ends the transition window, restoring normal defect handling. If verification fails before the window expires, the management system MUST either roll both MEPs back to the previous interval or extend the window, and MUST raise an operator notification.¶
If connectivity to one MEP is lost mid-procedure, the management system MUST roll back the reachable MEP to the previous interval before the window expires. Because defect consequences are suppressed only for a bounded window, a genuine connectivity failure occurring during the window is reported at most one window-duration late; operators SHOULD size the window accordingly.¶
The procedure can be executed with existing configuration models. A future revision of this document may define an augmentation to [RFC8531] providing: (1) a transition-window state with bounded duration and automatic expiry, and (2) an atomic interval-change action that encapsulates the three phases, so that a single management operation per MEP suffices.¶
Implementations SHOULD expose, per Maintenance Association: whether an interval modification is in progress, current and target interval values, transition-window status and remaining duration, and counters for successful, rolled-back, and failed modification attempts.¶
The procedure in this document operates entirely through the management plane. An attacker with management access could suppress defect consequences or change CCM intervals, disrupting fault detection; management interfaces used for this procedure MUST be authenticated and authorized, for example using the NETCONF access control model [RFC8341]. Defect-suppression windows are a temporary reduction in fault visibility; implementations MUST bound their duration and SHOULD log window entry, exit, and expiry as auditable events. Interval modification attempts SHOULD be rate-limited and logged.¶
This document has no IANA actions. The CFM OpCode and TLV spaces are administered by IEEE 802.1 and are not affected by this document.¶
The BFD timer negotiation in RFC 5880 served as the design precedent for runtime interval signaling in continuity check protocols.¶