Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces
Extracted elements (29)
Active OAM mode can initiate monitoring actions (such as putting the peer into loopback), while passive mode waits for the peer to initiate. The default mode should be active unless the device is intended to play a subservient role, reflecting an asymmetric deployment model (e.g., customer premises equipment vs. provider edge).
Ethernet OAM is intentionally complementary to SNMP rather than a replacement: it operates at layer 2 and provides single-hop link-specific functions between directly connected Ethernet entities, whereas SNMP requires a layer 3 IP infrastructure. This allows OAM diagnostics to function even when higher-layer connectivity is impaired.
Event Notification OAMPDUs may be sent in duplicate to increase the probability of successful delivery, given that Ethernet frames can be lost in transit. Unique and duplicate transmissions are tracked separately (dot3OamUniqueEventNotificationTx vs dot3OamDuplicateEventNotificationTx) and distinguished by the Sequence Number field.
The optional OAM functional groups (link events, remote loopback, variable retrieval) are independently controlled by separate MIB tables, allowing implementations to support any subset without affecting the mandatory discovery and state-machine functions.
Ethernet OAM can be implemented on any Ethernet-like interface, not only EFM (Ethernet in the First Mile) interfaces. The OAM MIB module is independent of the copper and EPON EFM MIB modules, and the same ifIndex used by the IF-MIB is reused as the table index.
The DOT3-OAM-MIB objects do not overlap with the interfaces MIB (RFC 2863), the Ethernet-like interfaces MIB (RFC 3635), or any other currently standardized Ethernet management MIB; all managed objects here are additive and specific to OAM functions defined in IEEE 802.3ah Clause 57.
An Event Notification OAMPDU should be generated when any of the four threshold-crossing event counters exceeds its configured threshold within its configured window. If a threshold is set to zero, notifications are sent periodically at the end of every window.
Changing dot3OamMode results in incrementing dot3OamConfigRevision in locally generated OAMPDUs, and potentially re-initiating the OAM discovery process if the interface was already operational(9).
dot3OamAdminState always starts in the disabled(2) state; Ethernet OAM will not operate until an explicit management action or retained configuration causes a transition to enabled(1).
Ethernet OAM on an interface must not transmit OAMPDUs that exceed the peer's advertised maximum OAMPDU size (dot3OamPeerMaxOamPduSize). Peers negotiate to use the smaller of the two maximum sizes.
Loopback places the remote OAM entity in a state where every received frame (except OAMPDUs) is echoed back without modification; normal traffic forwarding is disabled at the remote entity during loopback. This is described as an intrusive operation that should be used accordingly.
Peer information in dot3OamPeerTable is not available (entries absent) when dot3OamOperStatus is disabled(1), linkFault(2), passiveWait(3), activeSendLocal(4), or nonOperHalfDuplex(10); entries are auto-created only once the peer is communicating.
The default value of dot3OamLoopbackIgnoreRx is ignore(1), meaning received loopback commands are silently discarded unless explicitly configured to process(2). This prevents unsolicited remote loopback activation.
When Ethernet OAM is enabled (dot3OamAdminState is enabled) but the interface is operating in half-duplex mode, dot3OamOperStatus returns nonOperHalfDuplex(10), because Ethernet OAM is not designed to work over half-duplex interfaces.
Writing initiatingLoopback(2) to dot3OamLoopbackStatus is only effective when the current status is noLoopback(1); writing it in any other state has no effect. Writing terminatingLoopback(4) is only effective when in remoteLoopback(3).
An OAMPDU (Ethernet OAM Protocol Data Unit) is a valid Ethernet frame with a destination MAC address equal to the reserved Slow Protocols MAC address, a lengthOrType field set to the Slow Protocols reserved type, and a Slow Protocols subtype for Ethernet OAM. OAMPDUs are the sole mechanism by which two directly connected Ethernet interfaces exchange OAM information.
The dot3OamEventConfigTable configures thresholds and enable flags for the four standard threshold-crossing link events: Errored Symbol Period, Errored Frame Period, Errored Frame, and Errored Frame Seconds Summary. It also enables Dying Gasp and Critical Event signaling via OAMPDU flags.
The dot3OamEventLogTable records a history of both locally detected and remotely signaled OAM events (threshold crossing and non-threshold crossing). Entries capture event type, timestamp, OUI, vendor-specific info, window, threshold, and running totals for each event.
The dot3OamLoopbackTable controls and reports the loopback state for each interface that supports loopback (loopbackSupport bit set in dot3OamFunctionsSupported). It contains dot3OamLoopbackStatus (read-write, with writable values initiatingLoopback and terminatingLoopback) and dot3OamLoopbackIgnoreRx.
The dot3OamPeerTable maintains per-interface information about the remote OAM entity, including its MAC address, vendor OUI, vendor info, mode (active/passive/unknown), maximum OAMPDU size, configuration revision, and supported functions. Entries are auto-created when peer information becomes available and auto-deleted when the peer is no longer in communication.
The dot3OamStatsTable maintains per-interface counters for all OAMPDU types: InformationTx/Rx, UniqueEventNotificationTx/Rx, DuplicateEventNotificationTx/Rx, LoopbackControlTx/Rx, VariableRequestTx/Rx, VariableResponseTx/Rx, OrgSpecificTx/Rx, UnsupportedCodesTx/Rx, and FramesLostDueToOam. Counters are 32-bit (matching IEEE 802.3ah) and persist across dot3OamOperStatus transitions.
The dot3OamTable is the primary control and status group for Ethernet OAM on each Ethernet-like interface. It contains dot3OamAdminState, dot3OamOperStatus, dot3OamMode, dot3OamMaxOamPduSize, dot3OamConfigRevision, and dot3OamFunctionsSupported, indexed by ifIndex.
This document registers the DOT3-OAM-MIB module under { mib-2 158 }, creating the dot3OamNotifications, dot3OamObjects, and dot3OamConformance sub-trees. The MIB was assigned via IANA as part of the mib-2 registry.
Several objects in DOT3-OAM-MIB have read-write access and can cause operational disruption if manipulated by unauthorized parties: dot3OamAdminState can disable OAM, dot3OamLoopbackStatus can force a link into loopback (disrupting all user traffic), and dot3OamLoopbackIgnoreRx can suppress loopback commands. SNMPv3 with authentication and privacy (authPriv) is strongly recommended to protect these objects.
The most sensitive writable objects—those controlling loopback initiation and termination—can render a link non-operational for user traffic. Implementations should ensure that access to dot3OamLoopbackStatus and dot3OamLoopbackIgnoreRx is tightly controlled and that SNMP access control policies restrict write access to authorized management entities only.
The OAM discovery state machine is reflected in dot3OamOperStatus with ten states: disabled, linkFault, passiveWait, activeSendLocal, sendLocalAndRemote, sendLocalAndRemoteOk, oamPeeringLocallyRejected, oamPeeringRemotelyRejected, operational, and nonOperHalfDuplex. Transitions are driven by peer capability exchange via OAMPDUs and the acceptance or rejection of OAM peering by either end. The terminal operational(9) state corresponds to the SEND_ANY state of the IEEE 802.3ah Discovery state diagram.
The dot3OamMaxOamPduSize field is an Unsigned32 constrained to 64..1518 octets, representing the largest OAMPDU the local OAM entity supports. The effective maximum negotiated between peers is the minimum of the two peers' values.
The EightOTwoOui textual convention encodes a 24-bit IEEE 802 Organizationally Unique Identifier as an OCTET STRING of exactly 3 bytes. It is used for dot3OamPeerVendorOui to identify the peer's vendor.
The Errored Symbol Period window and threshold are each encoded as a pair of Unsigned32 objects (Hi and Lo) forming an unsigned 64-bit integer: value = (2^32 * Hi) + Lo. This accommodates symbol counts that exceed 32-bit range on high-speed physical layers.