]> China Mobile

Beijing100053 China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing100053 China duzongpeng@chinamobile.com

Centec

Shanghai201203 China wangjj@centec.com

Centec

Shanghai201203 China chengw@centec.com

Centec

Shanghai201203 China zhanggy@centec.com

Inesa

Shanghai200030 China sunxun@inesa.com

SAIA

Shanghai200125 China chunhao.zhao@sh-aia.com

OPS OPSAWG CFM CCM OAM interval IEEE 802.1ag Y.1731 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.

Introduction Ethernet Connectivity Fault Management (CFM) 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. 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. 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 includes built-in timer negotiation (Section 6.8.2 of ): 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the CFM terminology from and . In this document, "CCM interval" and "CCM Period" both refer to the value encoded in the 3-bit Period field of the CCM PDU.

Interval Learning State:

A transient MEP state in which the MEP applies the interval value from the next received CCM carrying PC=1.

Relationship to Existing Standards and 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. 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. specifies GMPLS extensions for CCM interval provisioning at session setup. This document addresses the case of interval changes after session establishment. defines a YANG data model for connection-oriented OAM including CCM. The extension in this document is compatible with that model.

Coordinated Interval Modification Procedure 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 ; 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 .

Phase 1: Defect Suppression Window 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.

Phase 2: Interval Application 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.

Phase 3: Verification and Resumption 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.

Failure Handling 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.

YANG Considerations The procedure can be executed with existing configuration models. A future revision of this document may define an augmentation to 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.

Manageability Considerations 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.

Security Considerations 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 . 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.

IANA Considerations 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.

IEEE ITU-T

Acknowledgements The BFD timer negotiation in RFC 5880 served as the design precedent for runtime interval signaling in continuity check protocols.