rfc-5066

Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

E. Beili
date2007-11 streamIETF areaops wghubmib statusPROPOSED STANDARD pages90 canonicalhttps://www.rfc-editor.org/rfc/rfc5066 doi10.17487/RFC5066
This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]

updated by

Extracted elements (30)

design-rationale §3.1.1

ifCapStackTable is defined as read-only (unlike the writable ifStackTable) because it reflects device hardware capability, not operator configuration. The capability can be dynamic (e.g., if PMEs are on a removable module), but cannot be changed by management operations — only the actual connections in ifStackTable are writable.

design-rationale §4.3

Profile-based provisioning was chosen to reduce management burden when a node has a large number of EFMCu PHYs, since most PMEs are provisioned identically. A port-level profile (efmCuAdminProfile) applies to all PMEs on a PCS, while per-PME overrides (efmCuPmeAdminProfile) allow individual customization, following the model used in HDSL2-SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB.

design-rationale §3.3

Similarly, VDSL-LINE-EXT-MCM-MIB (RFC 4070) objects are not reused for 10PASS-TS PMEs for the same reasons of simplicity and unified naming across both PHY types. VDSL-LINE-EXT-MCM-MIB groups MAY be optionally included for additional functionality.

design-rationale §3.2

The EFM-CU-MIB deliberately does not reuse HDSL2-SHDSL-LINE-MIB (RFC 4319) objects for 2BASE-TL PMEs, despite underlying SHDSL similarity. The rationale is simplicity, unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs, and name consistency (prefixing with 'efmCuPme2B' instead of 'hdsl2shdsl'). HDSL2-SHDSL-LINE-MIB groups MAY be optionally included for functions not covered by EFM-CU-MIB.

interoperability-note §3.1.1

EFMCu PMEs are not EtherLike interfaces and cannot be instantiated as MAU interface objects; only the PCS port (ifType ethernetCsmacd(6)) gets an ifMauTable entry. PME interfaces use ifType shdsl(169) for 2BASE-TL and vdsl(97) for 10PASS-TS, as defined in IANAifType-MIB.

interoperability-note §3.4

The EFMCu interpretation of ifMauMediaAvailable differs from other MAU types due to PME aggregation: 'unknown' means Initializing; 'ready' means Down with at least one PME ready for handshake; 'available' means Up with all PMEs up; 'availableReduced' means Up but with a link fault on one or more PMEs while at least one PME remains up; 'pmdLinkFault' means link fault on all PMEs.

normative-requirement §6 SHOULD

A PAF-enabled port with multiple PMEs assigned cannot be disabled; attempts to set efmCuPAFAdminState to 'disabled' when more than one PME is assigned SHALL be rejected until at most one PME remains. PAF-incapable ports SHALL return 'disabled' and SHALL reject attempts to enable.

normative-requirement §6 MUST

All entries in efmCuPortConfTable and efmCuPortCapabilityTable MUST be maintained in a persistent manner across management system re-initializations. The profile index value for each profile MUST remain constant at least from one re-initialization to the next.

normative-requirement §6 MUST

Changing efmCuPAFAdminState, efmCuPAFDiscoveryCode, efmCuAdminProfile, efmCuTargetDataRate, efmCuTargetSnrMgn, and efmCuAdaptiveSpectra MUST be performed when the link is Down; attempts to change these objects when the link is Up or Initializing MUST be rejected (SNMP error: inconsistentValue).

normative-requirement §3.1.5 MUST

Each PME and each PCS in the EFMCu PHY MUST have a unique ifIndex value, since there are PCS- and PME-specific attributes accessible only at their respective layers.

normative-requirement §3.4 REQUIRED

Implementation of EtherLike-MIB (RFC 3635) and MAU-MIB (RFC 4836) is REQUIRED for EFMCu interfaces. EFMCu PCS ports SHALL return ifType ethernetCsmacd(6) and the appropriate ifMauType (dot3MauType2BaseTL or dot3MauType10PassTS).

normative-requirement §3.1.3 RECOMMENDED

Removal of the last operationally 'up' PME from an operationally 'up' PCS is RECOMMENDED to be rejected by the implementation, as this would completely drop the link.

normative-requirement §3.1.2 REQUIRED

The SNMP agent is REQUIRED to report PAF capability (efmCuPAFSupported) for all EFMCu ports (both 2BASE-TL and 10PASS-TS), regardless of whether PAF is actually used.

normative-requirement §3.1.1 SHOULD

To determine whether a PME can be connected to a PCS, all relevant parameters SHALL be inspected: ifCapStackTable (cross-connect capability), ifStackTable (current connections), and efmCuPAFCapacity (aggregation limit). No single object is sufficient.

protocol-element §6

efmCuPortConfTable provides per-PCS configuration including PAF administrative state (efmCuPAFAdminState), PAF discovery code (efmCuPAFDiscoveryCode, 6-octet PhysAddress), admin profile list (efmCuAdminProfile, up to 6 profile indices), target data rate (efmCuTargetDataRate, 1–100000 Kbps or 999999 for best-effort), target SNR margin (efmCuTargetSnrMgn, 0–21 dB), adaptive spectra flag, and low-rate threshold. All configuration entries MUST be maintained persistently.

protocol-element §6

efmCuPortStatusTable provides live (non-persistent) per-PCS status: a BITS fault status object (efmCuFltStatus covering noPeer, peerPowerLoss, pmeSubTypeMismatch, lowRate), port side (subscriber/-R or office/-O), number of aggregated PMEs, and a suite of PAF fragment error counters (InErrors, InSmallFragments, InLargeFragments, InBadFragments, InLostFragments, InLostStarts, InLostEnds, InOverflows).

protocol-element §5

ifCapStackTable, indexed by ifStackHigherLayer and ifStackLowerLayer, exposes a TruthValue (ifCapStackStatus) indicating whether a lower sub-layer interface MAY be connected under a higher one based on device cross-connect capability. The table is read-only and may reflect dynamic availability (e.g., pluggable modules).

protocol-element §5

ifInvCapStackTable is a read-only inverse of ifCapStackTable, indexed with lower-layer first and higher-layer second, allowing efficient lookup of which higher-layer interfaces can sit above a given lower-layer interface. It contains exactly the same rows as ifCapStackTable but in reverse index order.

protocol-element §4.3

PME configuration profiles (efmCuPme2BProfileTable for 2BASE-TL, efmCuPme10PProfileTable for 10PASS-TS) allow shared provisioning across multiple PMEs. There are 12 predefined profiles for 2BASE-TL and 22 for 10PASS-TS per 802.3ah, plus two additional best-effort profiles for 2BASE-TL. Per-PME profile (efmCuPmeAdminProfile) overrides the port-level profile (efmCuAdminProfile).

protocol-element §6

The EFM-CU-MIB module (OID mib-2 167) manages EFMCu 2BASE-TL and 10PASS-TS interfaces defined in IEEE 802.3ah-2004. It is split into two object groups: efmCuPort (PCS-level configuration, capability, status, and notifications) and efmCuPme (PME-level configuration, capability, and status).

registry

protocol-element §6

The efmCuLowRateCrossing NOTIFICATION-TYPE is sent when the EFMCu port data rate crosses the efmCuThreshLowRate threshold in either direction. It carries ifSpeed and efmCuThreshLowRate, applies only to -O subtype ports while Up, and a debouncing period of 2.5 seconds is RECOMMENDED to avoid simultaneous LinkUp/LinkDown and rate-crossing notifications.

protocol-element §5

The IF-CAP-STACK-MIB module (OID mib-2 166) defines two read-only tables — ifCapStackTable and ifInvCapStackTable — that describe cross-connect capability of stacked (layered) interfaces, complementing the writable ifStackTable and ifInvStackTable in IF-MIB and IF-INVERTED-STACK-MIB.

registry

protocol-element §3.1.3

The PAF Discovery mechanism allows PMEs during initialization to exchange 6-octet discovery codes to detect copper misconnections and enable automatic PME-to-PCS assignment. It requires PAF support and uses a Set-if-Clear atomic write to efmCuPAFRemoteDiscoveryCode and subsequent read to confirm remote device association.

registry §6

EFM-CU-MIB is assigned OID { mib-2 167 }, registered under the IANA-controlled mib-2 subtree. Two new dot3MauType values (dot3MauType2BaseTL, dot3MauType10PassTS) and two new ifMauMediaAvailable values (availableReduced, ready) were registered in the IANA-MAU-MIB module via RFC 4836.

registry

registry §5

IF-CAP-STACK-MIB is assigned OID { mib-2 166 }, registered under the IANA-controlled mib-2 subtree. The module defines the ifCapStackGroup containing ifCapStackStatus and ifInvCapStackStatus objects.

registry

security-consideration §7

The EFM-CU-MIB and IF-CAP-STACK-MIB modules contain read-write objects that could be misused to disrupt network operation (e.g., modifying PAF state, target data rates, or profile assignments). Implementations should apply SNMP security mechanisms (authentication, access control) to restrict write access to authorized managers only.

security

state-machine §3.1.4

A PCS port operational state is derived from its PMEs: 'up' if at least one PME is operationally up; 'lowerLayerDown' when all connected PMEs are down; 'notPresent' when no PME is connected; 'down' during initialization. The efmCuPmeOperStatus object extends the PME ifOperStatus 'down' value with 'downReady', 'downNotReady', and 'init' sub-states.

wire-format §6

efmCuFltStatus is encoded as a BITS object with four named bit positions: noPeer(0), peerPowerLoss(1), pmeSubTypeMismatch(2), and lowRate(3), representing concurrent fault conditions on the PCS port.

wire-format §6

EfmProfileIndex is a Textual Convention defined as Unsigned32 (1..255), providing a unique identifier for each PME configuration profile. EfmProfileIndexOrZero extends this to Unsigned32 (0..255) where zero indicates unknown or no profile.

wire-format §6

EfmProfileIndexList is an OCTET STRING (SIZE 0..6) where each octet encodes an 8-bit EfmProfileIndex value (1–255); a zero-length string is object-specific. It represents a list of up to 6 profile indices, any of which may be selected for PME configuration.