Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

New Ethernet-like interfaces have been defined in the Institute of Electrical and Electronics Engineers (IEEE) Standard 802.3ah-2004 , a.k.a. Ethernet in the First Mile (EFM), which is now a part of the base IEEE Standard 802.3-2005 . In particular, 2BASE-TL and 10PASS-TS physical interfaces (PHYs), defined over voice-grade copper pairs, have been specified for the long and short reach, respectively. These interfaces, collectively called EFM Copper (EFMCu), are based on Single-pair High-speed Digital Subscriber Line (SHDSL) and Very High speed Digital Subscriber Line (VDSL) technology, supporting optional Physical Medium Entity (PME) aggregation (a.k.a. multi-pair bonding) with variable rates. 2BASE-TL PHY is capable of providing at least 2 Mbps over a 2700 m long single copper pair with a mean Bit Error Rate (BER) of 10^-7 (using 5 dB target noise margin). 10PASS-TS PHY is capable of providing at least 10 Mbps over a 750 m long single copper pair with a mean BER of 10^-7 (using 6 dB target noise margin). This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community to manage EFMCu interfaces. In addition, a MIB module is defined describing the cross-connect capability of a stacked interface. Note that managed objects for Operation, Administration and Maintenance (OAM) and Ethernet over Passive Optical Networks (EPON) clauses of IEEE 802.3ah are defined in EFM-COMMON-MIB and EFM-EPON-MIB , respectively.

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 . Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 , STD 58, RFC 2579 and STD 58, RFC 2580 . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

This section outlines the relationship of the MIB modules defined in this document with other MIB modules described in the relevant RFCs. Specifically, the Interfaces Group MIB (IF-MIB), Ethernet-Like (EtherLike-MIB), MAU (MAU-MIB), SHDSL (HDSL2-SHDSL-LINE-MIB), and VDSL (VDSL-LINE-EXT-MCM-MIB) modules are discussed.

2BASE-TL and 10PASS-TS PHYs specified in the EFM-CU-MIB module are stacked (a.k.a. aggregated or bonded) Ethernet interfaces and as such are managed using generic interface management objects defined in the IF-MIB . The stack management (i.e., actual connection of the sub-layers to the top-layer interface) is done via the ifStackTable, as defined in the IF-MIB , and its inverse ifInvStackTable, as defined in the IF-INVERTED-STACK-MIB . The new tables ifCapStackTable and its inverse ifInvCapStackTable defined in the IF-CAP-STACK-MIB module below, extend the stack management with an ability to describe possible connections or cross-connect capability, when a flexible cross-connect matrix is present between the interface layers.

An EFMCu interface can aggregate up to 32 Physical Medium Entity (PME) sub-layer devices (modems), using the so-called PME Aggregation Function (PAF). A generic EFMCu device can have a number of Physical Coding Sublayer (PCS) ports, each connected to a Media Access Controller (MAC) via a Medium Independent Interface (MII) at the upper layer, and cross-connected to a number of underlying PMEs, with a single PCS per PME relationship. See clause 61.1 of for more details. Each PME in the aggregated EFMCu port is represented in the Interface table (ifTable) as a separate interface with ifType of shdsl(169) for 2BASE-TL or vdsl(97) for 10PASS-TS. The ifType values are defined in . ifSpeed for each PME SHALL return the actual data bitrate of the active PME (e.g., for 2BaseTL PMEs it is a multiple of 64 Kbps). A zero value SHALL be returned when the PME is Initializing or Down. The ifSpeed of the PCS is the sum of the current operating data rates of all PMEs in the aggregation group, without the 64/65-octet encapsulation overhead and PAF overhead, but accounting for the Inter-Frame Gaps (IFGs).

When using the stated definition of ifSpeed for the PCS, there would be no frame loss in the following configuration (the test-sets are configured to generate 100% of back-to-back traffic, i.e., minimal IFG, at 10 or 100 Mbps, with min and max frame sizes; the EFM interfaces are aggregated, to achieve the shown speed):

The following figure shows the IEEE 802.3 layering diagram and corresponding use of ifTable and ifMauTable: The ifStackTable is indexed by the ifIndex values of the aggregated EFMCu port (PCS) and the PMEs connected to it. ifStackTable allows a Network Management application to determine which PMEs are connected to a particular PCS and change connections (if supported by the application). The ifInvStackTable, being an inverted version of the ifStackTable, provides an efficient means for a Network Management application to read a subset of the ifStackTable and thereby determine which PCS runs on top of a particular PME. A new table ifCapStackTable, defined in the IF-CAP-STACK-MIB module, specifies for each higher-layer interface (e.g., PCS port) a list of lower-layer interfaces (e.g., PMEs), which can possibly be cross-connected to that higher-layer interface, determined by the cross-connect capability of the device. This table, modeled after ifStackTable, is read-only, reflecting current cross-connect capability of stacked interface, which can be dynamic in some implementations (e.g., if PMEs are located on a pluggable module and the module is pulled out). Note that PME availability per PCS, described by ifCapStackTable, can be constrained by other parameters, for example, by aggregation capacity of a PCS or by the PME in question being already connected to another PCS. So, in order to ensure that a particular PME can be connected to the PCS, all respective parameters (e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity) SHALL be inspected. The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module, describes which higher-layer interfaces (e.g., PCS ports) can possibly be connected to a particular lower-layer interface (e.g., PME), providing an inverted mapping of the ifCapStackTable. While it contains no additional information beyond that already contained in the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in its INDEX clause in the reverse order, i.e., the lower-layer interface first, and the higher-layer interface second, providing an efficient means for a Network Management application to read a subset of the ifCapStackTable and thereby determine which interfaces can be connected to run on top of a particular interface.

The PME Aggregation Function (PAF) allows a number of PMEs to be aggregated onto a PCS port, by fragmenting the Ethernet frames, transmitting the fragments over multiple PMEs, and assembling the original frames at the remote port. PAF is OPTIONAL, meaning that a device with a single PME MAY perform fragmentation and re-assembly if this function is supported by the device. Note however that the agent is REQUIRED to report on the PAF capability for all EFMCu ports (2BASE-TL and 10PASS-TS). The EFM-CU-MIB module allows a Network Management application to query the PAF capability and enable/disable it if supported. Note that enabling PAF effectively turns on fragmentation and re-assembly, even on a single-PME port.

The EFMCu ports may optionally support discovery operation, whereby PMEs, during initialization, exchange information about their respective aggregation groups (PCS). This information can then be used to detect copper misconnections or for an automatic assignment of the local PMEs into aggregation groups instead of a fixed pre-configuration. The MIB modules defined in this document allow a Network Management application to control the EFM Discovery mechanism and query its results. Note that the Discovery mechanism can work only if PAF is supported and enabled. Two tables are used by the EFM Discovery mechanism: ifStackTable and ifCapStackTable. The following pseudo-code gives an example of the Discovery and automatic PME assignment for a generic PAF-enabled multi-PCS EFMCu device, located at Central Office (CO), using objects defined in these MIB modules and in the IF-MIB (Note that automatic PME assignment is only shown here for the purposes of the example. Fixed PME pre-assignment, manual assignment, or auto-assignment using an alternative internal algorithm may be chosen by a particular implementation):

An SNMP Agent for an EFMCu device builds the ifCapStackTable and its inverse ifInvCapStackTable according to the information contained in the Clause 45 PME_Available_register (see 61.1.5.3 and 45.2.3.20). Adding a PME to the ifStackTable row for a specific PCS involves actual connection of the PME to the PCS, which can be done by modifying Clause 45 PME_Aggregate_register (see 61.1.5.3 and 45.2.3.21). Note that the PCS port does not have to be operationally 'down' for the connection to succeed. In fact, a dynamic PME addition (and removal) MAY be implemented with an available PME being initialized first (by setting its ifAdminStatus to 'up') and then added to an operationally 'up' PCS port, by modifying a respective ifStackTable (and respective ifInvStackTable) entry. It is RECOMMENDED that a removal of the last operationally 'up' PME from an operationally 'up' PCS would be rejected by the implementation, as this action would completely drop the link.

EFMCu ports being built on top of xDSL technology require a lengthy initialization or 'training' process, before any data can pass. During this initialization, both ends of a link (peers) work cooperatively to achieve the required data rate on a particular copper pair. Sometimes, when the copper line is too long or the noise on the line is too high, that 'training' process may fail to achieve a specific target rate with required characteristics. The ifAdminStatus object from the IF-MIB controls the desired state of a PCS with all the PMEs connected to it or of an individual PME port. Setting this object to 'up' instructs a particular PCS or PME to start the initialization process, which may take tens of seconds for EFMCu ports, especially if PAF is involved. The ifOperStatus object shows the operational state of an interface (extended by the ifMauMediaAvailable object from MAU-MIB for PCS and efmCuPmeOperStatus defined in the EFM-CU-MIB module for PME interfaces). A disconnected PME may be initialized by changing the ifAdminState from 'down' to 'up'. Changing the ifAdminState to 'up' on the PCS initializes all PMEs connected to that particular PCS. Note that in case of PAF some interfaces may fail to initialize while others succeed. The PCS is considered operationally 'up' if at least one PME aggregated by its PAF is operationally 'up'. When all PMEs connected to the PCS are 'down', the PCS SHALL be considered operationally 'lowerLayerDown'. The PCS SHALL be considered operationally 'notPresent' if it is not connected to any PME. The PCS/PME interface SHALL remain operationally 'down' during initialization. The efmCuPmeOperStatus defined in the EFM-CU-MIB module expands PME's ifOperStatus value of 'down' to 'downReady', 'downNotReady', and 'init' values, indicating various EFMCu PME-specific states.

Both PME and PCS interfaces of the EFMCu PHY are managed using interface-specific management objects defined in the EFM-CU-MIB module and generic interface objects from the ifTable of IF-MIB, with all management table entries referenced by the interface index ifIndex. The following table summarizes EFMCu-specific interpretations for some of the ifTable objects specified in the mandatory ifGeneralInformationGroup: IF-MIB object EFMCu interpretation ifIndexInterface index. Note that each PME and each PCS in the EFMCu PHY MUST have a unique index, as there are some PCS- and PME-specific attributes accessible only on the PCS or PME level. ifTypeethernetCsmacd(6) for PCS, shdsl(169) for 2BASE-TL PME, vdsl(97) for 10PASS-TS PME. ifSpeedOperating data rate for the PME. For the PCS, it is the sum of the current operating data rates of all PMEs in the aggregation group, without the 64/65-octet encapsulation overhead and PAF overhead, but accounting for the Inter-Frame Gaps (IFGs). ifAdminStatusSetting this object to 'up' instructs a particular PCS (with all PMEs connected to it) or PME to start initialization process. ifOperStatusefmCuPmeOperStatus supplements the 'down' value of ifOperStatus for PMEs.

G.SHDSL.bis modems, similar to PMEs comprising a 2BASE-TL port, are described in the HDSL2-SHDSL-LINE-MIB module . Note that not all attributes of G.SHDSL modems reflected in the HDSL2-SHDSL-LINE-MIB module have adequate management objects (Clause 30 attributes and Clause 45 registers) in the EFM standard. Because of these differences and for the purposes of simplicity, unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs, and name consistency (e.g., prefixing the 2BASE-TL PME related objects with 'efmCuPme2B' instead of 'hdsl2shdsl'), it was decided not to reference HDSL2-SHDSL-LINE-MIB objects, but define all the relevant objects in the EFM-CU-MIB module. However, if some functionality not available in the EFM-CU-MIB module is required and supported by the PME, e.g., performance monitoring, relevant HDSL2-SHDSL-LINE-MIB groups MAY be included and applied for PMEs of 2BASE-TL subtype.

VDSL modems, similar to the PME(s) comprising a 10PASS-TS port, are described in the VDSL-LINE-EXT-MCM-MIB module . Note that not all attributes of VDSL modems reflected in the VDSL-LINE-EXT-MCM-MIB module have adequate management objects (Clause 30 attributes and Clause 45 registers) in the EFM standard. Because of these differences and for the purposes of simplicity, unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs, and name consistency, it was decided not to reference VDSL-LINE-EXT-MCM-MIB objects, but define all the relevant objects in the EFM-CU-MIB module. However, if some functionality not available in the EFM-CU-MIB module is required and supported by the PME, relevant VDSL-LINE-EXT-MCM-MIB groups MAY be included and applied for PMEs of 10PASS-TS subtype.

The implementation of the EtherLike-MIB and MAU-MIB modules is REQUIRED for EFMCu interfaces. Two new values of ifMauType (OBJECT-IDENTITIES of dot3MauType) and corresponding bit definitions of ifMauTypeListBits (IANAifMauTypeListBits) have been defined in the IANA-MAU-MIB module for EFMCu MAUs: dot3MauType2BaseTL and b2BaseTL - for 2BASE-TL MAU dot3MauType10PassTS and b10PassTS - for 10PASS-TS MAU Additionally, the IANA-MAU-MIB module defines two new values of ifMauMediaAvailable, specifically for EFMCu ports: availableReduced and ready (in textual convention IANAifMauMediaAvailable). Due to the PME aggregation, the EFMCu interpretation of some possible ifMauMediaAvailable values differs from other MAUs as follows: unknown - the EFMCu interface (PCS with connected PMEs) is Initializing ready - the interface is Down, at least one PME in the aggregation group (all PMEs connected to the PCS) is ready for handshake available - the interface is Up, all PMEs in the aggregation group are up notAvailable - the interface is Down, all PMEs in the aggregation group are Down, no handshake tones are detected by any PME availableReduced - the interface is Up, a link fault is detected at the receive direction by one or more PMEs in the aggregation group, but at least one PME is Up pmdLinkFault - a link fault is detected at the receive direction by all PMEs in the aggregation group As an EtherLike interface, every EFMCu port (an ifEntry representing a consolidation of LLC, MAC, and PCS (sub)layers) SHALL return an ifType of ethernetCsmacd(6). While most of the MAU characteristics are not applicable to the EFMCu ports (no auto-negotiation, false carriers, or jabber), they SHALL return an appropriate ifMauType (dot3MauType2BaseTL or dot3mauType10PassTS) in order to direct the management software to look in the EFM-CU-MIB module for the desired information. For example, the information on the particular EFMCu flavor that an EFMCu port is running is available from efmCuOperSubType, defined in the EFM-CU-MIB module. Since EFMCu PMEs are not EtherLike interfaces, they cannot be instantiated as MAU interface objects.

The main management objects defined in the EFM-CU-MIB module are split into 2 groups: efmCuPort - containing objects for configuration, capabilities, status, and notifications, common to all EFMCu PHYs. efmCuPme - containing objects for configuration, capabilities, status, and notifications of EFMCu PMEs. The efmCuPme group in turn contains efmCuPme2B and efmCuPme10P groups, which define PME profiles specific to 2BASE-TL and 10PASS-TS PMEs, respectively, as well as PME-specific status information.

The IF-CAP-STACK-MIB module contains 2 tables: ifCapStackTable - containing objects that define possible relationships among the sub-layers of an interface with flexible cross-connect (cross-connect capability). ifInvCapStackTable - an inverse of the ifCapstackTable.

Since a managed node can have a large number of EFMCu PHYs, provisioning every parameter on every EFMCu PHY may become burdensome. Moreover, most PMEs are provisioned identically with the same set of parameters. To simplify the provisioning process, the EFM-CU-MIB module makes use of configuration profiles, similar to the HDSL2-SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB modules. A profile is a set of parameters, used either for configuration or representation of a PME. The same profile can be shared by multiple PME ports using the same configuration. The PME profiles are defined in the efmCuPme2BProfileTable and efmCuPme10PProfileTable for 2BASE-TL and 10PASS-TS PMEs, respectively. There are 12 predefined standard profiles for 2BASE-TL and 22 standard profiles for 10PASS-TS, defined in 802.3ah and dedicated for rapid provisioning of EFMCu PHYs in most scenarios. In addition, the EFM-CU-MIB defines two additional predefined profiles for "best-effort" provisioning of 2BASE-TL PMEs. An ability to define new configuration profiles is also provided to allow for EFMCu deployment tailored to specific copper environments and spectral regulations. A specific configuration or administrative profile is assigned to a specific PME via the efmCuPmeAdminProfile object. If efmCuPmeAdminProfile is zero, then the efmCuAdminProfile object of the PCS port connected to the PME determines the configuration profile (or a list of possible profiles) for that PME. This mechanism allows specifying a common profile for all PMEs connected to the PCS port, with an ability to change individual PME profiles by setting efmCuPmeAdminProfile object, which overwrites the profile set by efmCuAdminProfile. A current operating PME profile is pointed to by *the* efmCuPmeOperProfile object. Note that this profile entry can be created automatically to reflect achieved parameters in adaptive (not fixed) initialization.

This section contains the mapping between relevant managed objects (attributes) defined in Clause 30, and managed objects defined in this document and in associated MIB modules, i.e., the IF-MIB . Note that the majority of the objects defined in the EFM-CU-MIB module do not have direct counterparts in Clause 30 and instead refer to Clause 45 registers. IEEE 802.3 Managed Object Corresponding SNMP Object oMAU - Basic Package (Mandatory) aMAUType ifMauType (MAU-MIB) aMAUTypeList ifMauTypeListBits (MAU-MIB) aMediaAvailable ifMediaAvailable (MAU-MIB) oPAF - Basic Package (Mandatory) aPAFID ifIndex (IF-MIB) aPhyEnd efmCuPhySide aPHYCurrentStatus efmCuStatus aPAFSupported efmCuPAFSupported oPAF - PME Aggregation Package (Optional) aPAFAdminState efmCuPAFAdminState aLocalPAFCapacity efmCuPAFCapacity aLocalPMEAvailable ifCapStackTable aLocalPMEAggregate ifStackTable (IF-MIB) aRemotePAFSupported efmCuRemotePAFSupported aRemotePAFCapacity efmCuRemotePAFCapacity aRemotePMEAggregate oPME - 10P/2B Package (Mandatory) aPMEID ifIndex (IF-MIB) aPMEAdminState ifAdminState (IF-MIB) aPMEStatus efmCuPmeStatus aPMESNRMgn efmCuPmeSnrMgn aTCCodingViolations efmCuPmeTCCodingErrors aTCCRCErrors efmCuPmeTCCrcErrors aProfileSelect efmCuAdminProfile, efmCuPmeAdminProfile aOperatingProfile efmCuPmeOperProfile aPMEFECCorrectedBlocks efmCuPme10PFECCorrectedBlocks aPMEFECUncorrectableBlocksefmCuPme10PFECUncorrectedBlocks

There is a number of managed objects defined in the EFM-CU-MIB module that have a MAX-ACCESS clause of read-write or read-create. Most objects are writeable only when the link is Down. Writing to these objects can have potentially disruptive effects on network operation, for example: Changing of efmCuPmeAdminSubType may lead to a potential locking of the link, as peer PMEs of the same subtype cannot exchange handshake messages. Changing of efmCuPAFAdminState to enabled may lead to a potential locking of the link, if the peer PHY does not support PAF. Changing of efmCuPAFDiscoveryCode, before the discovery operation, may lead to a wrongful discovery, for example, when two -O ports are connected to the same multi-PME -R port and both -O ports have the same Discovery register value. Changing PCS or PME configuration parameters (e.g., profile of a PCS or PME via efmCuAdminProfile or efmCuPmeAdminProfile) may lead to anything from link quality and rate degradation to a complete link initialization failure, as ability of an EFMCu port to support a particular configuration depends on the copper environment. Activation of a PME can cause a severe degradation of service for another EFMCu PHY, whose PME(s) may be affected by the cross-talk from the newly activated PME. Removal of a PME from an operationally 'up' EFMCu port, aggregating several PMEs, may cause port's rate degradation. The user of the EFM-CU-MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in the EFM-CU-MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the performance of network interfaces and can reveal some aspects of their configuration. In particular, since EFMCu can be carried over Unshielded Twisted Pair (UTP) voice-grade copper in a bundle with other pairs belonging to another operator/customer, it is theoretically possible to eavesdrop to an EFMCu transmission simply by "listening" to a cross-talk from the EFMCu pairs, especially if the parameters of the EFMCu link in question are known. In such environments, it is important to control also GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see , section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

Object identifiers for the efmCuMIB MODULE-IDENTITY and ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree.

This document was produced by the working group, whose efforts were greatly advanced by the contributions of the following people (in alphabetical order): Udi Ashkenazi (Actelis) Mike Heard Alfred Hoenes (TR-Sys) Marina Popilov (Actelis) Mathias Riess (Infineon) Dan Romascanu (Avaya) Matt Squire (Hatteras) Bert Wijnen (Alcatel)