RFC 5066
Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
RFC 5066: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 🎀
Okay bestie, the title block tea ☕: this one's by E. Beili from Actelis Networks, it's a Standards Track doc (so it's an actual protocol standard, not just a vibe), and it dropped in November 2007. The header doesn't list anything it obsoletes or updates, so no drama there 🫶
Status of This Memo ✨
This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 💬 For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜 And the good news? Distribution of this memo is unlimited, so share away 🌍
Abstract 🌸
This doc defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. It extends 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, which are defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005) 🔥
It also defines a set of objects describing the cross-connect capability of a managed device with multi-layer (stacked) interfaces. These extend the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules 🧚
Table of Contents 💜
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 4
3.1. Relation to Interfaces Group MIB Module . . . . . . . . . 4
3.1.1. Layering Model . . . . . . . . . . . . . . . . . . . . 4
3.1.2. PME Aggregation Function (PAF) . . . . . . . . . . . . 7
3.1.3. Discovery Operation . . . . . . . . . . . . . . . . . 7
3.1.4. EFMCu Ports Initialization . . . . . . . . . . . . . . 9
3.1.5. Usage of ifTable . . . . . . . . . . . . . . . . . . . 10
3.2. Relation to SHDSL MIB Module . . . . . . . . . . . . . . . 11
3.3. Relation to VDSL MIB Module . . . . . . . . . . . . . . . 12
3.4. Relation to Ethernet-Like and MAU MIB Modules . . . . . . 12
4. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. EFM Copper MIB Overview . . . . . . . . . . . . . . . . . 13
4.2. Interface Stack Capability MIB Overview . . . . . . . . . 13
4.3. PME Profiles . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . 14
5. Interface Stack Capability MIB Definitions . . . . . . . . . . 16
6. EFM Copper MIB Definitions . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 84
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1. Normative References . . . . . . . . . . . . . . . . . . . 86
10.2. Informative References . . . . . . . . . . . . . . . . . . 881. Introduction 🦋
Okay so, new Ethernet-like interfaces got defined in the Institute of Electrical and Electronics Engineers (IEEE) Standard 802.3ah-2004 [802.3ah], aka Ethernet in the First Mile (EFM). It's now part of the base IEEE Standard 802.3-2005 [802.3] 💅 The two big players are the 2BASE-TL and 10PASS-TS physical interfaces (PHYs). They run over voice-grade copper pairs, and they're built for long reach and short reach respectively 🔥
These interfaces together are called EFM Copper (EFMCu). They're based on Single-pair High-speed Digital Subscriber Line (SHDSL) [G.991.2] and Very High speed Digital Subscriber Line (VDSL) [G.993.1] technology. They support optional Physical Medium Entity (PME) aggregation (a.k.a. multi-pair bonding) with variable rates ✨
The 2BASE-TL PHY can provide 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) 🫶
The 10PASS-TS PHY can provide 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 so network management protocols on the Internet can manage EFMCu interfaces. It also defines a MIB module 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 [RFC4878] and EFM-EPON-MIB [RFC4837], respectively 📌
2. The Internet-Standard Management Framework 🌸
For a detailed overview of the documents describing the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 📖
Managed objects are accessed through a virtual information store called 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 in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🧠
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 [RFC2119]. These are the official rule-words, so read them carefully bestie 👑
3. Relation to Other MIB Modules ✨
This section explains how the MIB modules in this document relate to other MIB modules in the relevant RFCs. Specifically, we're talking about 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 🦋
3.1. Relation to Interfaces Group MIB Module 💖
The 2BASE-TL and 10PASS-TS PHYs specified in the EFM-CU-MIB module are stacked (a.k.a. aggregated or bonded) Ethernet interfaces. That means they're managed using generic interface management objects defined in the IF-MIB [RFC2863] 🔥
Stack management (meaning the actual connection of the sub-layers to the top-layer interface) is done via the ifStackTable, as defined in the IF-MIB [RFC2863]. Its inverse, ifInvStackTable, is defined in the IF-INVERTED-STACK-MIB [RFC2864] 🧚
The new tables ifCapStackTable and its inverse ifInvCapStackTable are defined in the IF-CAP-STACK-MIB module below. They extend stack management so it can describe possible connections, or cross-connect capability, when a flexible cross-connect matrix exists between the interface layers 🌈
3.1.1. Layering Model ✨
Okay so an EFMCu interface can team up with up to 32 Physical Medium Entity (PME) sub-layer devices (modems) 🦋 using the so-called PME Aggregation Function (PAF). The whole squad goes in together, lol.
A generic EFMCu device can have a bunch of Physical Coding Sublayer (PCS) ports 🌸. Each one connects up to a Media Access Controller (MAC) through a Medium Independent Interface (MII) at the upper layer, and gets cross-connected to a bunch of underlying PMEs, with a single PCS per PME relationship. See clause 61.1 of [802.3ah] for more details.
Each PME in the aggregated EFMCu port shows up in the Interface table (ifTable) as its own separate interface, with ifType of shdsl(169) for 2BASE-TL or vdsl(97) for 10PASS-TS. The ifType values are defined in [IANAifType-MIB].
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):
.-------. .--. .---. .-------.
|testset|--10BaseT--|CO|--2BaseTL--|CPE|--10BaseT--|testset|
'-------' '--' '---' '-------'
ifSpeed= 10 Mbps 10 Mbps 10 Mbps
.-------. .--. .---. .-------.
|testset|--100BaseT--|CO|--10PassTS--|CPE|--100BaseT--|testset|
'-------' '--' '---' '-------'
ifSpeed= 100 Mbps 100 Mbps 100 MbpsFigure 1: Example configuration with no frame loss
The following figure shows the IEEE 802.3 layering diagram and corresponding use of ifTable and ifMauTable 📚:
.-------------------------. -
| LLC | ^
+-------------------------+ | 1 ifEntry
| MAC | | ifType: ethernetCsmacd(6)
+-------------------------+ ) ifMauEntry
| Reconsiliation | | ifMauType: dot3MauType2BaseTL or
+-------------------------+ | dot3MauType10PassTS
| PCS | v
+-------------+---+-------+ -
| TC \ | | | ^
+-----\ | | | |
| PMA )PME 1 |...| PME N | ) N ifEntry (N=1..32)
+-----/ | | | | ifType: shdsl(169) or vdsl(97)
| PMD/ | | | v
'-------------+---+-------' -
LLC - Logical Link Control PMA - Physical Medium Attachment
MAC - Media Access Control PMD - Physical Medium Dependent
PCS - Physical Coding Sub-layer PME - Physical Medium Entity
TC - Transmission ConvergenceFigure 2: Use of ifTable and ifMauTable for EFMCu ports
The ifStackTable is indexed by the ifIndex values of the aggregated EFMCu port (PCS) and the PMEs connected to it 🔥. ifStackTable lets a Network Management application figure out which PMEs are connected to a particular PCS, and change connections (if the application supports it). The ifInvStackTable, being an inverted version of the ifStackTable, gives an efficient way for a Network Management application to read a subset of the ifStackTable and figure out which PCS runs on top of a particular PME.
A new table, ifCapStackTable, defined in the IF-CAP-STACK-MIB module, lists for each higher-layer interface (e.g., PCS port) a list of lower-layer interfaces (e.g., PMEs) that can possibly be cross-connected to that higher-layer interface, based on the cross-connect capability of the device 👑. This table is modeled after ifStackTable, is read-only, and reflects the current cross-connect capability of the stacked interface, which can be dynamic in some implementations (e.g., if PMEs live on a pluggable module and the module gets pulled out). PME availability per PCS, described by ifCapStackTable, can be constrained by other parameters too, like the aggregation capacity of a PCS, or by the PME in question already being connected to another PCS. So, to make sure 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), giving an inverted mapping of the ifCapStackTable. It contains no extra information beyond what's already in the ifCapStackTable, but 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 🌈. That makes it an efficient way for a Network Management application to read a subset of the ifCapStackTable and figure out which interfaces can be connected to run on top of a particular interface.
3.1.2. PME Aggregation Function (PAF) 🧁
The PME Aggregation Function (PAF) lets a number of PMEs be aggregated onto a PCS port, by fragmenting the Ethernet frames, transmitting the fragments over multiple PMEs, and reassembling 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 lets a Network Management application query the PAF capability and enable or disable it if it's supported. Note that enabling PAF effectively turns on fragmentation and re-assembly, even on a single-PME port 🙈.
3.1.3. Discovery Operation 🔍
The EFMCu ports may optionally support discovery operation, where PMEs, during initialization, exchange information about their respective aggregation groups (PCS). This information can then be used to detect copper misconnections, or to automatically assign the local PMEs into aggregation groups instead of a fixed pre-configuration ✨.
The MIB modules defined in this document let a Network Management application 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) 🧠:
// Go over all PCS ports in the CO device
FOREACH pcs[i] IN CO_device
{ // Perform discovery and auto-assignment only on PAF enabled ports
// with room for more PMEs
IF ( pcs[i].PAFSupported AND pcs[i].NumPMEs < pcs[i].PAFCapacity )
{ // Assign a unique 6-octet local discovery code to the PCS
// e.g., MAC address
dc = pcs[i].DiscoveryCode = MAC[i];
// Go over all disconnected PMEs, which can
// potentially be connected to the PCS
FOREACH pme[j] IN ifCapStackTable[pcs[i]] AND
NOT IN ifStackTable[pcs[i]] // not connected
{ // Try to grab the remote RT_device, by writing the value
// of the local 6-octet discovery code to the remote
// discovery code register (via handshake mechanism).
// This operation is atomic Set-if-Clear action, i.e., it
// would succeed only if the remote discovery register was
// zero. Read the remote discovery code register via Get
// operation to see if the RT_device, attached via the PME
// is indeed marked as being the CO_device peer.
pme[j].RemoteDiscoveryCode = dc; // Set-if-Clear
r = pme[j].RemoteDiscoveryCode; // Get
IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity)
{ // Remote RT_device connected via PME[j] is/was a peer
// for PCS[i] and there is room for another PME in the
// PCS[i] aggregation group (max. PAF capacity is not
// reached yet).
// Connect this PME to the PCS (via ifStackTable,
// ifInvStackTable being inverse of ifStackTable is
// updated automatically, i.e., pcs[i] is auto-added
// to ifInvStackTable[pme[j]])
ADD pme[j] TO ifStackTable[pcs[i]];
pcs[i].NumPMEs = pcs[i].NumPMEs + 1;
// Discover all other disconnected PMEs,
// attached to the same RT_device and connect them to
// the PCS provided there is enough room for more PMEs.
FOREACH pme[k] IN ifCapStackTable[pcs[i]] AND
NOT IN ifStackTable[pcs[i]]
{ // Get Remote Discovery Code from the PME to see if
// it belongs to a connected RT_device "grabbed" by
// the CO_device.
r = pme[k].RemoteDiscoveryCode;
IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity)
{ // Physically connect the PME to the PCS
// (pcs[i] is auto-added TO ifInvStackTable[pme[k]])
ADD pme[k] TO ifStackTable[pcs[i]];
pcs[i].NumPMEs = pcs[i].NumPMEs + 1;
}
}
}
// At this point we have discovered all local PMEs which
// are physically connected to the same remote RT_device
// and connected them to PCS[i]. Go to the next PCS.
BREAK;
}
}
}An SNMP Agent for an EFMCu device builds the ifCapStackTable and its inverse ifInvCapStackTable according to the information in the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and 45.2.3.20) 📖.
Adding a PME to the ifStackTable row for a specific PCS means actually connecting the PME to the PCS, which can be done by modifying the Clause 45 PME_Aggregate_register (see [802.3ah] 61.1.5.3 and 45.2.3.21) 🌟.
Note that the PCS port doesn't have to be operationally 'down' for the connection to succeed. In fact, a dynamic PME addition (and removal) MAY be implemented by initializing an available PME first (by setting its ifAdminStatus to 'up') and then adding it 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, because that action would completely drop the link 🚨.
3.1.4. EFMCu Ports Initialization ✨
okay so EFMCu ports are built on xDSL tech, which means they need a loooong initialization (aka 'training') before any data can pass 🫠. During that training, both ends of the link (the peers) work together 🫶 to hit the required data rate on one particular copper pair. Sometimes the copper line is too long or the noise is too loud, and the training just... doesn't reach the target rate with the characteristics it needs 💀.
The ifAdminStatus object from the IF-MIB is the one that controls the desired state of a PCS (with all the PMEs connected to it) or of one individual PME port 💅. Setting it to 'up' tells a PCS or PME to kick off initialization, which can take tens of seconds for EFMCu ports, especially if PAF is involved 😭. The ifOperStatus object shows the operational state of an interface. It gets extended by the ifMauMediaAvailable object from MAU-MIB for PCS, and by efmCuPmeOperStatus (defined in the EFM-CU-MIB module) for PME interfaces 🌈.
A disconnected PME can be initialized by changing the ifAdminState from 'down' to 'up' 🎀. Changing ifAdminState to 'up' on the PCS initializes all the PMEs connected to that PCS. Note that with PAF, some interfaces might fail to initialize while others succeed 👀. The PCS counts as 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 isn't connected to any PME. The PCS/PME interface SHALL remain operationally 'down' during initialization 🧚.
The efmCuPmeOperStatus object from the EFM-CU-MIB module takes the PME's ifOperStatus value of 'down' and expands it into 'downReady', 'downNotReady', and 'init'. These values flag the various EFMCu PME-specific states 🦋.
3.1.5. Usage of ifTable
Both the PME and PCS interfaces of the EFMCu PHY are managed with interface-specific management objects from the EFM-CU-MIB module, plus the generic interface objects from the ifTable of IF-MIB. Every management table entry is referenced by the interface index ifIndex 🍓.
Here's a quick cheat sheet of EFMCu-specific interpretations for some of the ifTable objects in the mandatory ifGeneralInformationGroup 📋:
+---------------+---------------------------------------------------+
| IF-MIB object | EFMCu interpretation |
+---------------+---------------------------------------------------+
| ifIndex | Interface 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. |
+---------------+---------------------------------------------------+
| ifType | ethernetCsmacd(6) for PCS, shdsl(169) for |
| | 2BASE-TL PME, vdsl(97) for 10PASS-TS PME. |
| ifSpeed | Operating 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). |
+---------------+---------------------------------------------------+
| ifAdminStatus | Setting this object to 'up' instructs a |
| | particular PCS (with all PMEs connected to it) or |
| | PME to start initialization process. |
+---------------+---------------------------------------------------+
| ifOperStatus | efmCuPmeOperStatus supplements the 'down' value |
| | of ifOperStatus for PMEs. |
+---------------+---------------------------------------------------+Table 1: EFMCu interpretation of IF-MIB objects
3.2. Relation to SHDSL MIB Module
G.SHDSL.bis modems, which are similar to the PMEs that make up a 2BASE-TL port, are described in the HDSL2-SHDSL-LINE-MIB module [RFC4319]. Heads up though: not every attribute of G.SHDSL modems that shows up in the HDSL2-SHDSL-LINE-MIB module has a good management object (Clause 30 attributes and Clause 45 registers) in the EFM standard 🤓.
Because of those differences, and to keep things simple, plus unify attributes shared by 2BASE-TL and 10PASS-TS PMEs and keep names consistent (like prefixing 2BASE-TL PME objects with 'efmCuPme2B' instead of 'hdsl2shdsl'), it was decided not to reference HDSL2-SHDSL-LINE-MIB objects. Instead, all the relevant objects are defined in the EFM-CU-MIB module 💜.
That said, if some functionality that the EFM-CU-MIB module doesn't have is required and supported by the PME (performance monitoring, for example), then relevant HDSL2-SHDSL-LINE-MIB groups MAY be included and applied for PMEs of the 2BASE-TL subtype 🌸.
3.3. Relation to VDSL MIB Module
VDSL modems, which are similar to the PME(s) that make up a 10PASS-TS port, are described in the VDSL-LINE-EXT-MCM-MIB module [RFC4070]. Same deal as before: not every attribute of VDSL modems in the VDSL-LINE-EXT-MCM-MIB module has a solid management object (Clause 30 attributes and Clause 45 registers) in the EFM standard 🙈.
For the same reasons (simplicity, unifying shared attributes between 2BASE-TL and 10PASS-TS PMEs, and name consistency), it was decided not to reference VDSL-LINE-EXT-MCM-MIB objects, and to define all the relevant objects in the EFM-CU-MIB module instead ✨.
Still, if some functionality missing from 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 the 10PASS-TS subtype 🦋.
3.4. Relation to Ethernet-Like and MAU MIB Modules
Implementing the EtherLike-MIB [RFC3635] and MAU-MIB [RFC4836] modules is REQUIRED for EFMCu interfaces. No skipping this one bestie 🫶.
Two new values of ifMauType (OBJECT-IDENTITIES of dot3MauType), plus the matching bit definitions of ifMauTypeListBits (IANAifMauTypeListBits), were defined in the IANA-MAU-MIB module [RFC4836] for EFMCu MAUs:
dot3MauType2BaseTLandb2BaseTL- for 2BASE-TL MAUdot3MauType10PassTSandb10PassTS- for 10PASS-TS MAU
The IANA-MAU-MIB module also defines two new values of ifMauMediaAvailable that are specifically for EFMCu ports: availableReduced and ready (in textual convention IANAifMauMediaAvailable) 💅. Because of PME aggregation, the EFMCu meaning of some possible ifMauMediaAvailable values is different from other MAUs. Here's the tea ☕:
unknown- the EFMCu interface (PCS with connected PMEs) is Initializingready- the interface is Down, at least one PME in the aggregation group (all PMEs connected to the PCS) is ready for handshakeavailable- the interface is Up, all PMEs in the aggregation group are upnotAvailable- the interface is Down, all PMEs in the aggregation group are Down, no handshake tones are detected by any PMEavailableReduced- 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 UppmdLinkFault- 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 the LLC, MAC, and PCS (sub)layers) SHALL return an ifType of ethernetCsmacd(6). Most MAU characteristics don't apply to EFMCu ports (no auto-negotiation, false carriers, or jabber), but they SHALL return an appropriate ifMauType (dot3MauType2BaseTL or dot3mauType10PassTS) so that management software knows to look in the EFM-CU-MIB module for the info it wants 🔍. For instance, the particular EFMCu flavor a port is running is available from efmCuOperSubType, which is defined in the EFM-CU-MIB module.
Since EFMCu PMEs are not EtherLike interfaces, they can't be instantiated as MAU interface objects 🙅♀️.
4. MIB Structure 🧩
4.1. EFM Copper MIB Overview
The main management objects 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 contains the efmCuPme2B and efmCuPme10P groups in turn. These define PME profiles specific to 2BASE-TL and 10PASS-TS PMEs respectively, plus PME-specific status information 🌈.
4.2. Interface Stack Capability MIB Overview
The IF-CAP-STACK-MIB module has 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 theifCapstackTable.
4.3. PME Profiles
A managed node can have a ton of EFMCu PHYs, so provisioning every parameter on every single one could get burdensome 😩. Plus, most PMEs are provisioned identically with the same set of parameters. To make provisioning easier, the EFM-CU-MIB module uses 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 for representing a PME. The same profile can be shared by multiple PME ports that use 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 to rapid provisioning of EFMCu PHYs in most scenarios. The EFM-CU-MIB also defines two additional predefined profiles for "best-effort" provisioning of 2BASE-TL PMEs. And there's an ability to define new configuration profiles too, so EFMCu deployments can be 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 list of possible profiles) for that PME. This mechanism lets you specify a common profile for all PMEs connected to the PCS port, while still changing individual PME profiles by setting efmCuPmeAdminProfile, 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 ✨.
4.4. Mapping of IEEE 802.3ah Managed Objects 🗺️
okay bestie, this section is the cheat sheet 📝 It maps the managed objects from [802.3ah] Clause 30 to the stuff in this document and its MIB modules, which means the IF-MIB [RFC2863] too. Basically, if you know the IEEE name, this table tells you the SNMP name 🫶
ngl the big thing to know is that most of the EFM-CU-MIB objects don't have a direct buddy in Clause 30. 💀 They point at Clause 45 registers instead, so the table is a bit of a treasure hunt 🧚
+---------------------------------+---------------------------------+
| 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 |
+---------------------------------+---------------------------------+
| aPMEFECUncorrectableBlocks | efmCuPme10PFECUncorrectedBlocks |
+---------------------------------+---------------------------------+
Table 2: Mapping of IEEE 802.3 Managed ObjectsTable 2 is the whole vibe 💜 Every row lines up one IEEE attribute with its SNMP twin, so keep it handy while you read the MIB sections 🎀
5. Interface Stack Capability MIB Definitions ✨
okay so this is the actual MIB module for cross-connect capability, and it's giving "which layers are even allowed to sit on top of which other layers" 💅🦋
IF-CAP-STACK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TruthValue
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer
FROM IF-MIB -- [RFC2863]
ifInvStackGroup
FROM IF-INVERTED-STACK-MIB -- [RFC2864]
;
ifCapStackMIB MODULE-IDENTITY
LAST-UPDATED "200711070000Z" -- November 07, 2007
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/OLD/hubmib-charter.html
Mailing Lists:
General Discussion: hubmib@ietf.org
To Subscribe: hubmib-request@ietf.org
In Body: subscribe your_email_address
Chair: Bert Wijnen
Postal: Alcatel-Lucent
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-407-775
EMail: bwijnen@alcatel-lucent.com
Editor: Edward Beili
Postal: Actelis Networks Inc.
25 Bazel St., P.O.B. 10173
Petach-Tikva 10173
Israel
Phone: +972-3-924-3491
EMail: edward.beili@actelis.com"
DESCRIPTION
"The objects in this MIB module are used to describe
cross-connect capabilities of stacked (layered) interfaces,
complementing ifStackTable and ifInvStackTable defined in
IF-MIB and IF-INVERTED-STACK-MIB, respectively.
Copyright (C) The IETF Trust (2007). This version
of this MIB module is part of RFC 5066; see the RFC
itself for full legal notices."
REVISION "200711070000Z" -- November 07, 2007
DESCRIPTION "Initial version, published as RFC 5066."
::= { mib-2 166 }
-- Sections of the module
-- Structured as recommended by [RFC4181], see
-- Appendix D: Suggested OID Layout
ifCapStackObjects OBJECT IDENTIFIER ::= { ifCapStackMIB 1 }
ifCapStackConformance OBJECT IDENTIFIER ::= { ifCapStackMIB 2 }
-- Groups in the module
--
-- ifCapStackTable group
--
ifCapStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table, modeled after ifStackTable from IF-MIB,
contains information on the possible 'on-top-of'
relationships between the multiple sub-layers of network
interfaces (as opposed to actual relationships described in
ifStackTable). In particular, it contains information on
which sub-layers MAY possibly run 'on top of' which other
sub-layers, as determined by cross-connect capability of the
device, where each sub-layer corresponds to a conceptual row
in the ifTable. For example, when the sub-layer with ifIndex
value x can be connected to run on top of the sub-layer with
ifIndex value y, then this table contains:
ifCapStackStatus.x.y=true
The ifCapStackStatus.x.y row does not exist if it is
impossible to connect between the sub-layers x and y.
Note that for most stacked interfaces (e.g., 2BASE-TL)
there's always at least one higher-level interface (e.g., PCS
port) for each lower-level interface (e.g., PME) and at
least one lower-level interface for each higher-level
interface, that is, there is at least a single row with a
'true' status for any such existing value of x or y.
This table is read-only as it describes device capabilities."
REFERENCE
"IF-MIB, ifStackTable"
::= { ifCapStackObjects 1 }
ifCapStackEntry OBJECT-TYPE
SYNTAX IfCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer MAY possibly run
on 'top' of the other sub-layer. Each sub-layer corresponds
to a conceptual row in the ifTable (interface index for
lower and higher layer, respectively)."
INDEX {
ifStackHigherLayer,
ifStackLowerLayer
}
::= { ifCapStackTable 1 }
IfCapStackEntry ::= SEQUENCE {
ifCapStackStatus TruthValue
}
ifCapStackStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the 'cross-connect capability' relationship
between two sub-layers. The following values can be returned:
true(1) - indicates that the sub-layer interface,
identified by the ifStackLowerLayer MAY
be connected to run 'below' the sub-layer
interface, identified by the
ifStackHigherLayer index.
false(2) - the sub-layer interfaces cannot be
connected temporarily due to
unavailability of the interface(s), e.g.,
one of the interfaces is located on an
absent pluggable module.
Note that lower-layer interface availability per higher-layer,
indicated by the value of 'true', can be constrained by
other parameters, for example, by the aggregation capacity of
a higher-layer interface or by the lower-layer interface in
question being already connected to another higher-layer
interface. In order to ensure that a particular sub-layer can
be connected to another sub-layer, all respective objects
(e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity for
EFMCu interfaces) SHALL be inspected.
This object is read-only, unlike ifStackStatus, as it
describes a cross-connect capability."
::= { ifCapStackEntry 1 }
ifInvCapStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfInvCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information on the possible relationships
between the multiple sub-layers of network interfaces. This
table, modeled after ifInvStackTable from
IF-INVERTED-STACK-MIB, is an inverse of the ifCapStackTable
defined in this MIB module.
In particular, this table contains information on which
sub-layers MAY run 'underneath' which other sub-layers, where
each sub-layer corresponds to a conceptual row in the ifTable.
For example, when the sub-layer with ifIndex value x MAY be
connected to run underneath the sub-layer with ifIndex value
y, then this table contains:
ifInvCapStackStatus.x.y=true
This table contains exactly the same number of rows as the
ifCapStackTable, but the rows appear in a different order.
This table is read-only as it describes a cross-connect
capability."
REFERENCE
"IF-INVERTED-STACK-MIB, ifInvStackTable"
::= { ifCapStackObjects 2 }
ifInvCapStackEntry OBJECT-TYPE
SYNTAX IfInvCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer MAY run underneath the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackLowerLayer, ifStackHigherLayer }
::= { ifInvCapStackTable 1 }
IfInvCapStackEntry ::= SEQUENCE {
ifInvCapStackStatus TruthValue
}
ifInvCapStackStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the possible 'cross-connect capability'
relationship between two sub-layers.
An instance of this object exists for each instance of the
ifCapStackStatus object, and vice versa. For example, if the
variable ifCapStackStatus.H.L exists, then the variable
ifInvCapStackStatus.L.H must also exist, and vice versa. In
addition, the two variables always have the same value.
The ifInvCapStackStatus object is read-only, as it describes
a cross-connect capability."
REFERENCE
"ifCapStackStatus"
::= { ifInvCapStackEntry 1 }
--
-- Conformance Statements
--
ifCapStackGroups OBJECT IDENTIFIER ::=
{ ifCapStackConformance 1 }
ifCapStackCompliances OBJECT IDENTIFIER ::=
{ ifCapStackConformance 2 }
-- Units of Conformance
ifCapStackGroup OBJECT-GROUP
OBJECTS {
ifCapStackStatus,
ifInvCapStackStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing information on the
cross-connect capability of multi-layer (stacked) network
interfaces."
::= { ifCapStackGroups 1 }
-- Compliance Statements
ifCapStackCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities, which provide
information on the cross-connect capability of multi-layer
(stacked) network interfaces, with flexible cross-connect
between the sub-layers."
MODULE -- this module
MANDATORY-GROUPS {
ifCapStackGroup
}
OBJECT ifCapStackStatus
SYNTAX TruthValue { true(1) }
DESCRIPTION
"Support for the false(2) value is OPTIONAL for
implementations supporting pluggable interfaces."
OBJECT ifInvCapStackStatus
SYNTAX TruthValue { true(1) }
DESCRIPTION
"Support for the false(2) value is OPTIONAL for
implementations supporting pluggable interfaces."
MODULE IF-MIB
MANDATORY-GROUPS {
ifStackGroup2
}
MODULE IF-INVERTED-STACK-MIB
MANDATORY-GROUPS {
ifInvStackGroup
}
::= { ifCapStackCompliances 1 }
END6. EFM Copper MIB Definitions ✨
next up is the EFM Copper MIB, the big one, so get your snacks 🍓🧚
EFM-CU-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32,
Unsigned32, Counter32, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION, TruthValue, RowStatus, PhysAddress
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
ifIndex, ifSpeed
FROM IF-MIB -- [RFC2863]
;
efmCuMIB MODULE-IDENTITY
LAST-UPDATED "200711140000Z" -- November 14, 2007
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/OLD/hubmib-charter.html
Mailing Lists:
General Discussion: hubmib@ietf.org
To Subscribe: hubmib-request@ietf.org
In Body: subscribe your_email_addressOkay bestie, the contact details come first 🎀 Chair, Editor, the whole squad with their addresses and emails. Here's the contact block exactly as it's written:
Chair: Bert Wijnen
Postal: Alcatel-Lucent
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-407-775
EMail: bwijnen@alcatel-lucent.com
Editor: Edward Beili
Postal: Actelis Networks Inc.
25 Bazel St., P.O.B. 10173
Petach-Tikva 10173
Israel
Phone: +972-3-924-3491
Email: edward.beili@actelis.com"
DESCRIPTION
"The objects in this MIB module are used to manage
the Ethernet in the First Mile (EFM) Copper (EFMCu) Interfaces
2BASE-TL and 10PASS-TS, defined in IEEE Std. 802.3ah-2004,
which is now a part of IEEE Std. 802.3-2005.
The following references are used throughout this MIB module:
[802.3ah] refers to:
IEEE Std 802.3ah-2004: 'IEEE Standard for Information
technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks -
Specific requirements -
Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer
Specifications -
Amendment: Media Access Control Parameters, Physical
Layers and Management Parameters for Subscriber Access
Networks', 07 September 2004.
Of particular interest are Clause 61, 'Physical Coding
Sublayer (PCS) and common specifications, type 10PASS-TS and
type 2BASE-TL', Clause 30, 'Management', Clause 45,
'Management Data Input/Output (MDIO) Interface', Annex 62A,
'PMD profiles for 10PASS-TS' and Annex 63A, 'PMD profiles for
2BASE-TL'.
[G.991.2] refers to:
ITU-T Recommendation G.991.2: 'Single-pair High-speed Digital
Subscriber Line (SHDSL) transceivers', December 2003.
[ANFP] refers to:
NICC Document ND1602:2005/08: 'Specification of the Access
Network Frequency Plan (ANFP) applicable to transmission
systems used on the BT Access Network,' August 2005.
The following normative documents are quoted by the DESCRIPTION
clauses in this MIB module:
[G.993.1] refers to:
ITU-T Recommendation G.993.1: 'Very High speed Digital
Subscriber Line transceivers', June 2004.
[T1.424] refers to:
ANSI T1.424-2004: 'Interface Between Networks and Customer
Installation Very-high-bit-rate Digital Subscriber Lines
(VDSL) Metallic Interface (DMT Based)', June 2004.
[TS 101 270-1] refers to:
ETSI TS 101 270-1: 'Transmission and Multiplexing (TM);
Access transmission systems on metallic access cables;
Very high speed Digital Subscriber Line (VDSL); Part 1:
Functional requirements', October 2005.
Naming Conventions:
Atn - Attenuation
CO - Central Office
CPE - Customer Premises Equipment
EFM - Ethernet in the First Mile
EFMCu - EFM Copper
MDIO - Management Data Input/Output
Mgn - Margin
PAF - PME Aggregation Function
PBO - Power Back-Off
PCS - Physical Coding Sublayer
PMD - Physical Medium Dependent
PME - Physical Medium Entity
PSD - Power Spectral Density
SNR - Signal to Noise Ratio
TCPAM - Trellis Coded Pulse Amplitude Modulation
Copyright (C) The IETF Trust (2007). This version
of this MIB module is part of RFC 5066; see the RFC
itself for full legal notices."
REVISION "200711140000Z" -- November 14, 2007
DESCRIPTION "Initial version, published as RFC 5066."
::= { mib-2 167 }
-- Sections of the module
efmCuObjects OBJECT IDENTIFIER ::= { efmCuMIB 1 }
efmCuConformance OBJECT IDENTIFIER ::= { efmCuMIB 2 }
-- Groups in the module
efmCuPort OBJECT IDENTIFIER ::= { efmCuObjects 1 }
efmCuPme OBJECT IDENTIFIER ::= { efmCuObjects 2 }
-- Textual Conventions
EfmProfileIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each PME configuration
profile in the managed EFMCu port. It is RECOMMENDED that
values are assigned contiguously starting from 1. The value
for each profile MUST remain constant at least from one
re-initialization of the entity's network management system
to the next re-initialization."
SYNTAX Unsigned32 (1..255)
EfmProfileIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
EfmProfileIndex convention. The latter defines a greater than
zero value used to identify a PME profile in the managed EFMCu
port. This extension permits the additional value of zero.
The value of zero is object-specific and MUST therefore be
defined as part of the description of any object that uses
this syntax.
Examples of the usage of zero value might include situations
where the current operational profile is unknown."
SYNTAX Unsigned32 (0..255)
EfmProfileIndexList ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d:"
STATUS current
DESCRIPTION
"This textual convention represents a list of up to 6
EfmProfileIndex values, any of which can be chosen for
configuration of a PME in a managed EFMCu port.
The EfmProfileIndex textual convention defines a greater than
zero value used to identify a PME profile.
The value of this object is a concatenation of zero or
more (up to 6) octets, where each octet contains an 8-bit
EfmProfileIndex value.
A zero-length octet string is object-specific and MUST
therefore be defined as part of the description of any object
that uses this syntax. Examples of the usage of a zero-length
value might include situations where an object using this
textual convention is irrelevant for a specific EFMCu port
type."
SYNTAX OCTET STRING (SIZE(0..6))
EfmTruthValueOrUnknown ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual convention is an extension of the TruthValue
convention. The latter defines a boolean value with possible
values of true(1) and false(2). This extension permits the
additional value of unknown(0), which can be returned as the
result of a GET operation when an exact true or false value
of the object cannot be determined."
SYNTAX INTEGER { unknown(0), true(1), false(2) }
-- Port Notifications Group
efmCuPortNotifications OBJECT IDENTIFIER ::= { efmCuPort 0 }
efmCuLowRateCrossing NOTIFICATION-TYPE
OBJECTS {
ifSpeed,
efmCuThreshLowRate
}
STATUS current
DESCRIPTION
"This notification indicates that the EFMCu port's data rate
has reached/dropped below or exceeded the low rate threshold,
specified by efmCuThreshLowRate.
This notification MAY be sent for the -O subtype ports
(2BaseTL-O/10PassTS-O) while the port is Up, on the crossing
event in both directions: from normal (rate is above the
threshold) to low (rate equals the threshold or below it) and
from low to normal. This notification is not applicable to
the -R subtypes.
It is RECOMMENDED that a small debouncing period of 2.5 sec,
between the detection of the condition and the notification,
is implemented to prevent simultaneous LinkUp/LinkDown and
efmCuLowRateCrossing notifications to be sent.
The adaptive nature of the EFMCu technology allows the port to
adapt itself to the changes in the copper environment, e.g.,
an impulse noise, alien crosstalk, or a micro-interruption may
temporarily drop one or more PMEs in the aggregation group,
causing a rate degradation of the aggregated EFMCu link.
The dropped PMEs would then try to re-initialize, possibly at
a lower rate than before, adjusting the rate to provide
required target SNR margin.
Generation of this notification is controlled by the
efmCuLowRateCrossingEnable object."
::= { efmCuPortNotifications 1 }
-- PCS Port group
efmCuPortConfTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPortConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for Configuration of EFMCu 2BASE-TL/10PASS-TS (PCS)
Ports. Entries in this table MUST be maintained in a
persistent manner."
::= { efmCuPort 1 }
efmCuPortConfEntry OBJECT-TYPE
SYNTAX EfmCuPortConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu Port Configuration table.
Each entry represents an EFMCu port indexed by the ifIndex.
Note that an EFMCu PCS port runs on top of a single
or multiple PME port(s), which are also indexed by ifIndex."
INDEX { ifIndex }
::= { efmCuPortConfTable 1 }
EfmCuPortConfEntry ::=
SEQUENCE {
efmCuPAFAdminState INTEGER,
efmCuPAFDiscoveryCode PhysAddress,
efmCuAdminProfile EfmProfileIndexList,
efmCuTargetDataRate Unsigned32,
efmCuTargetSnrMgn Unsigned32,
efmCuAdaptiveSpectra TruthValue,
efmCuThreshLowRate Unsigned32,
efmCuLowRateCrossingEnable TruthValue
}
efmCuPAFAdminState OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Administrative (desired) state of the PAF of the EFMCu port
(PCS).
When 'disabled', PME aggregation will not be performed by the
PCS. No more than a single PME can be assigned to this PCS in
this case.
When 'enabled', PAF will be performed by the PCS when the link
is Up, even on a single attached PME, if PAF is supported.
PCS ports incapable of supporting PAF SHALL return a value of
'disabled'. Attempts to 'enable' such ports SHALL be
rejected.
A PAF 'enabled' port with multiple PMEs assigned cannot be
'disabled'. Attempts to 'disable' such port SHALL be
rejected, until at most one PME is left assigned.
Changing PAFAdminState is a traffic-disruptive operation and
as such SHALL be done when the link is Down. Attempts to
change this object SHALL be rejected if the link is Up or
Initializing.
This object maps to the Clause 30 attribute aPAFAdminState.
If a Clause 45 MDIO Interface to the PCS is present, then this
object maps to the PAF enable bit in the 10P/2B PCS control
register.
This object MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] 61.2.2, 45.2.3.18.3"
::= { efmCuPortConfEntry 1 }efmCuPAFDiscoveryCode OBJECT-TYPE SYNTAX PhysAddress (SIZE(0|6)) MAX-ACCESS read-write STATUS current DESCRIPTION "PAF Discovery Code of the EFMCu port (PCS). A unique 6-octet code used by the Discovery function, when PAF is supported. PCS ports incapable of supporting PAF SHALL return a zero-length octet string on an attempt to read this object. An attempt to write to this object SHALL be rejected for such ports. This object MUST be instantiated for the -O subtype PCS before writing operations on the efmCuPAFRemoteDiscoveryCode (Set_if_Clear and Clear_if_Same) are performed by PMEs associated with the PCS. The initial value of this object for -R subtype ports after reset is all zeroes. For -R subtype ports, the value of this object cannot be changed directly. This value may be changed as a result of writing operation on the efmCuPAFRemoteDiscoveryCode object of remote PME of -O subtype, connected to one of the local PMEs associated with the PCS.
Discovery MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing.
The PAF Discovery Code maps to the local Discovery code variable in PAF (note that it does not have a corresponding Clause 45 register)." REFERENCE "[802.3ah] 61.2.2.8.3, 61.2.2.8.4, 45.2.6.6.1, 45.2.6.8, 61A.2" ::= { efmCuPortConfEntry 2 }
efmCuAdminProfile OBJECT-TYPE SYNTAX EfmProfileIndexList MAX-ACCESS read-write STATUS current DESCRIPTION "Desired configuration profile(s), common for all PMEs in the EFMCu port. This object is a list of pointers to entries in either efmCuPme2BProfileTable or efmCuPme10PProfileTable, depending on the current operating SubType of the EFMCu port as indicated by efmCuPortSide.
The value of this object is a list of up to 6 indices of profiles. If this list consists of a single profile index, then all PMEs assigned to this EFMCu port SHALL be configured according to the profile referenced by that index, unless it is overwritten by a corresponding non-zero efmCuPmeAdminProfile instance, which takes precedence over efmCuAdminProfile. A list consisting of more than one index allows each PME in the port to be configured according to any profile specified in the list. By default, this object has a value of 0x01, referencing the 1st entry in efmCuPme2BProfileTable or efmCuPme10PProfileTable.
This object is writable and readable for the -O subtype (2BaseTL-O or 10PassTS-O) EFMCu ports. It is irrelevant for the -R subtype (2BaseTL-R or 10PassTS-R) ports -- a zero-length octet string SHALL be returned on an attempt to read this object and an attempt to change this object MUST be rejected in this case.
Note that the current operational profile value is available via the efmCuPmeOperProfile object.
Any modification of this object MUST be performed when the link is Down. Attempts to change this object MUST be rejected, if the link is Up or Initializing. Attempts to set this object to a list with a member value that is not the value of the index for an active entry in the corresponding profile table MUST be rejected.
This object maps to the Clause 30 attribute aProfileSelect.
This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 30.11.2.1.6" DEFVAL { '01'H } ::= { efmCuPortConfEntry 3 }
efmCuTargetDataRate OBJECT-TYPE SYNTAX Unsigned32(1..100000|999999) UNITS "Kbps" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired EFMCu port 'net' (as seen across MII) Data Rate in Kbps, to be achieved during initialization, under spectral restrictions placed on each PME via efmCuAdminProfile or efmCuPmeAdminProfile, with the desired SNR margin specified by efmCuTargetSnrMgn. In case of PAF, this object represents a sum of individual PME data rates, modified to compensate for fragmentation and 64/65-octet encapsulation overhead (e.g., target data rate of 10 Mbps SHALL allow lossless transmission of a full-duplex 10 Mbps Ethernet frame stream with minimal inter-frame gap).
The value is limited above by 100 Mbps as this is the max burst rate across MII for EFMCu ports.
The value between 1 and 100000 indicates that the total data rate (ifSpeed) of the EFMCu port after initialization SHALL be equal to the target data rate or less, if the target data rate cannot be achieved under spectral restrictions specified by efmCuAdminProfile/efmCuPmeAdminProfile and with the desired SNR margin. In case the copper environment allows a higher total data rate to be achieved than that specified by the target, the excess capability SHALL be either converted to additional SNR margin or reclaimed by minimizing transmit power as controlled by efmCuAdaptiveSpectra.
The value of 999999 means that the target data rate is not fixed and SHALL be set to the maximum attainable rate during initialization (Best Effort), under specified spectral restrictions and with the desired SNR margin.
This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes.
Changing of the Target Data Rate MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing.
Note that the current Data Rate of the EFMCu port is represented by the ifSpeed object of IF-MIB.
This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 4 }
efmCuTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32(0..21) UNITS "dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired EFMCu port SNR margin to be achieved on all PMEs assigned to the port, during initialization. (The SNR margin is the difference between the desired SNR and the actual SNR).
Note that 802.3ah recommends using a default target SNR margin of 5 dB for 2BASE-TL ports and 6 dB for 10PASS-TS ports in order to achieve a mean Bit Error Rate (BER) of 10^-7 at the PMA service interface.
This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes.
Changing of the target SNR margin MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing.
Note that the current SNR margin of the PMEs comprising the EFMCu port is represented by efmCuPmeSnrMgn.
This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 61.1.2" ::= { efmCuPortConfEntry 5 }
efmCuAdaptiveSpectra OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates how to utilize excess capacity when the copper environment allows a higher total data rate to be achieved than that specified by the efmCuTargetDataRate.
A value of true(1) indicates that the excess capability SHALL be reclaimed by minimizing transmit power, e.g., using higher constellations and Power Back-Off, in order to reduce interference to other copper pairs in the binder and the adverse impact to link/system performance.
A value of false(2) indicates that the excess capability SHALL be converted to additional SNR margin and spread evenly across all active PMEs assigned to the (PCS) port, to increase link robustness.
This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes.
Changing of this object MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing.
This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 6 }
efmCuThreshLowRate OBJECT-TYPE SYNTAX Unsigned32(1..100000) UNITS "Kbps" MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the EFMCu port low-rate crossing alarm threshold. When the current value of ifSpeed for this port reaches/drops below or exceeds this threshold, an efmCuLowRateCrossing notification MAY be generated if enabled by efmCuLowRateCrossingEnable.
This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes.
This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 7 }
efmCuLowRateCrossingEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuLowRateCrossing notifications should be generated for this interface.
A value of true(1) indicates that efmCuLowRateCrossing notification is enabled. A value of false(2) indicates that the notification is disabled.
This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes.
This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 8 }
efmCuPortCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPortCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table for Capabilities of EFMCu 2BASE-TL/10PASS-TS (PCS) Ports. Entries in this table MUST be maintained in a persistent manner" ::= { efmCuPort 2 }
efmCuPortCapabilityEntry OBJECT-TYPE SYNTAX EfmCuPortCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu Port Capability table. Each entry represents an EFMCu port indexed by the ifIndex. Note that an EFMCu PCS port runs on top of a single or multiple PME port(s), which are also indexed by ifIndex." INDEX { ifIndex } ::= { efmCuPortCapabilityTable 1 }
EfmCuPortCapabilityEntry ::= SEQUENCE { efmCuPAFSupported TruthValue, efmCuPeerPAFSupported EfmTruthValueOrUnknown, efmCuPAFCapacity Unsigned32, efmCuPeerPAFCapacity Unsigned32 }
okay so we're still deep in the EFM Copper MIB definitions 🎀 this bit is all about the port capability objects, and they're giving main character energy ✨ efmCuPAFSupported is the "can this port do PME aggregation?" flag 💅
efmCuPAFSupported OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME Aggregation Function (PAF) capability of the EFMCu port
(PCS).
This object has a value of true(1) when the PCS can perform
PME aggregation on the available PMEs.
Ports incapable of PAF SHALL return a value of false(2).
This object maps to the Clause 30 attribute aPAFSupported.
If a Clause 45 MDIO Interface to the PCS is present,
then this object maps to the PAF available bit in the
10P/2B capability register."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.4, 45.2.3.17.1"
::= { efmCuPortCapabilityEntry 1 }
efmCuPeerPAFSupported OBJECT-TYPE
SYNTAX EfmTruthValueOrUnknown
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME Aggregation Function (PAF) capability of the EFMCu port
(PCS) link partner.
This object has a value of true(1) when the remote PCS can
perform PME aggregation on its available PMEs.
Ports whose peers are incapable of PAF SHALL return a value
of false(2).
Ports whose peers cannot be reached because of the link
state SHALL return a value of unknown(0).
This object maps to the Clause 30 attribute
aRemotePAFSupported.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the Remote PAF supported bit in the
10P/2B capability register."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.9, 45.2.3.17.2"
::= { efmCuPortCapabilityEntry 2 }
efmCuPAFCapacity OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of PMEs that can be aggregated by the local PAF.
The number of PMEs currently assigned to a particular
EFMCu port (efmCuNumPMEs) is never greater than
efmCuPAFCapacity.
This object maps to the Clause 30 attribute
aLocalPAFCapacity."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.6"
::= { efmCuPortCapabilityEntry 3 }
efmCuPeerPAFCapacity OBJECT-TYPE
SYNTAX Unsigned32 (0|1..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of PMEs that can be aggregated by the PAF of the peer
PHY (PCS port).
A value of 0 is returned when peer PAF capacity is unknown
(peer cannot be reached).
This object maps to the Clause 30 attribute
aRemotePAFCapacity."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.10"
::= { efmCuPortCapabilityEntry 4 }
efmCuPortStatusTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPortStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides overall status information of EFMCu
2BASE-TL/10PASS-TS ports, complementing the generic status
information from the ifTable of IF-MIB and ifMauTable of
MAU-MIB. Additional status information about connected PMEs
is available from the efmCuPmeStatusTable.
This table contains live data from the equipment. As such,
it is NOT persistent."
::= { efmCuPort 3 }
efmCuPortStatusEntry OBJECT-TYPE
SYNTAX EfmCuPortStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu Port Status table.
Each entry represents an EFMCu port indexed by the ifIndex.
Note that an EFMCu PCS port runs on top of a single
or multiple PME port(s), which are also indexed by ifIndex."
INDEX { ifIndex }
::= { efmCuPortStatusTable 1 }
EfmCuPortStatusEntry ::=
SEQUENCE {
efmCuFltStatus BITS,
efmCuPortSide INTEGER,
efmCuNumPMEs Unsigned32,
efmCuPAFInErrors Counter32,
efmCuPAFInSmallFragments Counter32,
efmCuPAFInLargeFragments Counter32,
efmCuPAFInBadFragments Counter32,
efmCuPAFInLostFragments Counter32,
efmCuPAFInLostStarts Counter32,
efmCuPAFInLostEnds Counter32,
efmCuPAFInOverflows Counter32
}
efmCuFltStatus OBJECT-TYPE
SYNTAX BITS {
noPeer(0),
peerPowerLoss(1),
pmeSubTypeMismatch(2),
lowRate(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"EFMCu (PCS) port Fault Status. This is a bitmap of possible
conditions. The various bit positions are:
noPeer - the peer PHY cannot be reached (e.g.,
no PMEs attached, all PMEs are Down,
etc.). More info is available in
efmCuPmeFltStatus.
peerPowerLoss - the peer PHY has indicated impending
unit failure due to loss of local
power ('Dying Gasp').
pmeSubTypeMismatch - local PMEs in the aggregation group
are not of the same subtype, e.g.,
some PMEs in the local device are -O
while others are -R subtype.
lowRate - ifSpeed of the port reached or dropped
below efmCuThreshLowRate.
This object is intended to supplement the ifOperStatus object
in IF-MIB and ifMauMediaAvailable in MAU-MIB.
Additional information is available via the efmCuPmeFltStatus
object for each PME in the aggregation group (single PME if
PAF is disabled)."
REFERENCE
"IF-MIB, ifOperStatus; MAU-MIB, ifMauMediaAvailable;
efmCuPmeFltStatus"
::= { efmCuPortStatusEntry 1 }
efmCuPortSide OBJECT-TYPE
SYNTAX INTEGER {
subscriber(1),
office(2),
unknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"EFM port mode of operation (subtype).
The value of 'subscriber' indicates that the port is
designated as '-R' subtype (all PMEs assigned to this port are
of subtype '-R').
The value of the 'office' indicates that the port is
designated as '-O' subtype (all PMEs assigned to this port are
of subtype '-O').
The value of 'unknown' indicates that the port has no assigned
PMEs yet or that the assigned PMEs are not of the same side
(subTypePMEMismatch).
This object partially maps to the Clause 30 attribute
aPhyEnd."
REFERENCE
"[802.3ah] 61.1, 30.11.1.1.2"
::= { efmCuPortStatusEntry 2 }
efmCuNumPMEs OBJECT-TYPE
SYNTAX Unsigned32 (0..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PMEs that is currently aggregated by the local
PAF (assigned to the EFMCu port using the ifStackTable).
This number is never greater than efmCuPAFCapacity.
This object SHALL be automatically incremented or decremented
when a PME is added or deleted to/from the EFMCu port using
the ifStackTable."
REFERENCE
"[802.3ah] 61.2.2, 30.11.1.1.6"
::= { efmCuPortStatusEntry 3 }
efmCuPAFInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of fragments that have been received across the
gamma interface with RxErr asserted and discarded.
This read-only counter is inactive (not incremented) when the
PAF is unsupported or disabled. Upon disabling the PAF, the
counter retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF RX error register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.21"
::= { efmCuPortStatusEntry 4 }
efmCuPAFInSmallFragments OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of fragments smaller than minFragmentSize
(64 bytes) that have been received across the gamma interface
and discarded.
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF small fragments register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.22"
::= { efmCuPortStatusEntry 5 }
efmCuPAFInLargeFragments OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of fragments larger than maxFragmentSize
(512 bytes) that have been received across the gamma interface
and discarded.
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF large fragments register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.23"
::= { efmCuPortStatusEntry 6 }
efmCuPAFInBadFragments OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of fragments that do not fit into the sequence
expected by the frame assembly function and that have been
received across the gamma interface and discarded (the
frame buffer is flushed to the next valid frame start).
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF bad fragments register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.25"
::= { efmCuPortStatusEntry 7 }the lost-fragment counters are next and they're honestly so juicy 🍓
Okay so the PAF counters are up next, and they're basically the frame assembly function keeping score 📊✨
efmCuPAFInLostFragments OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of gaps in the sequence of fragments that have
been received across the gamma interface (the frame buffer is
flushed to the next valid frame start, when fragment/fragments
expected by the frame assembly function is/are not received).
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF lost fragment register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.26"
::= { efmCuPortStatusEntry 8 }
efmCuPAFInLostStarts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of missing StartOfPacket indicators expected by
the frame assembly function.
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF lost start of fragment
register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.27"
::= { efmCuPortStatusEntry 9 }
efmCuPAFInLostEnds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of missing EndOfPacket indicators expected by the
frame assembly function.
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF lost start of fragment
register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.28"
::= { efmCuPortStatusEntry 10 }
efmCuPAFInOverflows OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of fragments, received across the gamma interface
and discarded, which would have caused the frame assembly
buffer to overflow.
This read-only counter is inactive when the PAF is
unsupported or disabled. Upon disabling the PAF, the counter
retains its previous value.
If a Clause 45 MDIO Interface to the PCS is present, then
this object maps to the 10P/2B PAF overflow register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.3.24"
::= { efmCuPortStatusEntry 11 }So those four are lost fragments, lost starts, lost ends, and overflows 💅 They're all Counter32 and read-only, they go quiet when PAF is unsupported or disabled, and they hold onto their last value if you turn PAF off. If there's a Clause 45 MDIO interface to the PCS, each one maps to its own 10P/2B register. Main character data, honestly 🦋
Now the PME notifications, which are basically the alarms 🚨 There are five: line attenuation crossing, SNR margin crossing, device fault, config init failure, and protocol init failure. The two crossing ones can fire in both directions, and the code has the exact debounce wording, so go check the block for the details 🫶
-- PME Notifications Group
efmCuPmeNotifications OBJECT IDENTIFIER ::= { efmCuPme 0 }
efmCuPmeLineAtnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeLineAtn,
efmCuPmeThreshLineAtn
}
STATUS current
DESCRIPTION
"This notification indicates that the loop attenuation
threshold (as per the efmCuPmeThreshLineAtn
value) has been reached/exceeded for the 2BASE-TL/10PASS-TS
PME. This notification MAY be sent on the crossing event in
both directions: from normal to exceeded and from exceeded
to normal.
It is RECOMMENDED that a small debouncing period of 2.5 sec,
between the detection of the condition and the notification,
is implemented to prevent intermittent notifications from
being sent.
Generation of this notification is controlled by the
efmCuPmeLineAtnCrossingEnable object."
::= { efmCuPmeNotifications 1 }
efmCuPmeSnrMgnCrossing NOTIFICATION-TYPE
OBJECTS {
efmCuPmeSnrMgn,
efmCuPmeThreshSnrMgn
}
STATUS current
DESCRIPTION
"This notification indicates that the SNR margin threshold
(as per the efmCuPmeThreshSnrMgn value) has been
reached/exceeded for the 2BASE-TL/10PASS-TS PME.
This notification MAY be sent on the crossing event in
both directions: from normal to exceeded and from exceeded
to normal.
It is RECOMMENDED that a small debouncing period of 2.5 sec,
between the detection of the condition and the notification,
is implemented to prevent intermittent notifications from
being sent.
Generation of this notification is controlled by the
efmCuPmeSnrMgnCrossingEnable object."
::= { efmCuPmeNotifications 2 }
efmCuPmeDeviceFault NOTIFICATION-TYPE
OBJECTS {
efmCuPmeFltStatus
}
STATUS current
DESCRIPTION
"This notification indicates that a fault in the PME has been
detected by a vendor-specific diagnostic or a self-test.
Generation of this notification is controlled by the
efmCuPmeDeviceFaultEnable object."
::= { efmCuPmeNotifications 3 }
efmCuPmeConfigInitFailure NOTIFICATION-TYPE
OBJECTS {
efmCuPmeFltStatus,
efmCuAdminProfile,
efmCuPmeAdminProfile
}
STATUS current
DESCRIPTION
"This notification indicates that PME initialization has
failed, due to inability of the PME link to achieve the
requested configuration profile.
Generation of this notification is controlled by the
efmCuPmeConfigInitFailEnable object."
::= { efmCuPmeNotifications 4 }
efmCuPmeProtocolInitFailure NOTIFICATION-TYPE
OBJECTS {
efmCuPmeFltStatus,
efmCuPmeOperSubType
}
STATUS current
DESCRIPTION
"This notification indicates that the peer PME was using
an incompatible protocol during initialization.
Generation of this notification is controlled by the
efmCuPmeProtocolInitFailEnable object."
::= { efmCuPmeNotifications 5 }Then comes the PME group itself, starting with the config table 🎀 It's a persistent table for the common stuff on each 2BASE-TL or 10PASS-TS modem port, indexed by ifIndex. Each row has its own per-type details elsewhere, and the subtype object is where the fun choices live ✨
-- The PME group
efmCuPmeConfTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPmeConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for Configuration of common aspects for EFMCu
2BASE-TL/10PASS-TS PME ports (modems). Configuration of
aspects specific to 2BASE-TL or 10PASS-TS PME types is
represented in efmCuPme2BConfTable and efmCuPme10PConfTable,
respectively.
Entries in this table MUST be maintained in a persistent
manner."
::= { efmCuPme 1 }
efmCuPmeConfEntry OBJECT-TYPE
SYNTAX EfmCuPmeConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu PME Configuration table.
Each entry represents common aspects of an EFMCu PME port
indexed by the ifIndex. Note that an EFMCu PME port can be
stacked below a single PCS port, also indexed by ifIndex,
possibly together with other PME ports if PAF is enabled."
INDEX { ifIndex }
::= { efmCuPmeConfTable 1 }
EfmCuPmeConfEntry ::=
SEQUENCE {
efmCuPmeAdminSubType INTEGER,
efmCuPmeAdminProfile EfmProfileIndexOrZero,
efmCuPAFRemoteDiscoveryCode PhysAddress,
efmCuPmeThreshLineAtn Integer32,
efmCuPmeThreshSnrMgn Integer32,
efmCuPmeLineAtnCrossingEnable TruthValue,
efmCuPmeSnrMgnCrossingEnable TruthValue,
efmCuPmeDeviceFaultEnable TruthValue,
efmCuPmeConfigInitFailEnable TruthValue,
efmCuPmeProtocolInitFailEnable TruthValue
}
efmCuPmeAdminSubType OBJECT-TYPE
SYNTAX INTEGER {
ieee2BaseTLO(1),
ieee2BaseTLR(2),
ieee10PassTSO(3),
ieee10PassTSR(4),
ieee2BaseTLor10PassTSR(5),
ieee2BaseTLor10PassTSO(6),
ieee10PassTSor2BaseTLO(7)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Administrative (desired) subtype of the PME.
Possible values are:
ieee2BaseTLO - PME SHALL operate as 2BaseTL-O
ieee2BaseTLR - PME SHALL operate as 2BaseTL-R
ieee10PassTSO - PME SHALL operate as 10PassTS-O
ieee10PassTSR - PME SHALL operate as 10PassTS-R
ieee2BaseTLor10PassTSR - PME SHALL operate as 2BaseTL-R or
10PassTS-R. The actual value will
be set by the -O link partner
during initialization (handshake).
ieee2BaseTLor10PassTSO - PME SHALL operate as 2BaseTL-O
(preferred) or 10PassTS-O. The
actual value will be set during
initialization depending on the -R
link partner capability (i.e., if
-R is incapable of the preferred
2BaseTL mode, 10PassTS will be
used).
ieee10PassTSor2BaseTLO - PME SHALL operate as 10PassTS-O
(preferred) or 2BaseTL-O. The
actual value will be set during
initialization depending on the -R
link partner capability (i.e., if
-R is incapable of the preferred
10PassTS mode, 2BaseTL will be
used).
Changing efmCuPmeAdminSubType is a traffic-disruptive
operation and as such SHALL be done when the link is Down.
Attempts to change this object SHALL be rejected if the link
is Up or Initializing.
Attempts to change this object to an unsupported subtype
(see efmCuPmeSubTypesSupported) SHALL be rejected.
The current operational subtype is indicated by the
efmCuPmeOperSubType variable.
If a Clause 45 MDIO Interface to the PMA/PMD is present, then
this object combines values of the Port subtype select bits
and the PMA/PMD type selection bits in the 10P/2B PMA/PMD
control register."
REFERENCE
"[802.3ah] 61.1, 45.2.1.11.4, 45.2.1.11.7"
::= { efmCuPmeConfEntry 1 }Heads up, efmCuPmeAdminSubType is the one with the traffic-disruptive warning 👀 changing it only goes through when the link is Down, so keep that in mind as we keep going 🌸
Okay bestie, we're picking up right where the last part left off, inside the EFMCu PME config table 💅🎀
Our first stop is the admin profile pointer. It points at a row in one of the two profile tables, and it depends on which SubType the PME is running 🦋
efmCuPmeAdminProfile OBJECT-TYPE
SYNTAX EfmProfileIndexOrZero
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired PME configuration profile. This object is a pointer
to an entry in either the efmCuPme2BProfileTable or the
efmCuPme10PProfileTable, depending on the current operating
SubType of the PME. The value of this object is the index of
the referenced profile.
The value of zero (default) indicates that the PME is
configured via the efmCuAdminProfile object for the PCS port
to which this PME is assigned. That is, the profile
referenced by efmCuPmeAdminProfile takes precedence
over the profile(s) referenced by efmCuAdminProfile.
This object is writable and readable for the CO subtype PMEs
(2BaseTL-O or 10PassTS-O). It is irrelevant for the CPE
subtype (2BaseTL-R or 10PassTS-R) -- a zero value SHALL be
returned on an attempt to read this object and any attempt
to change this object MUST be rejected in this case.
Note that the current operational profile value is available
via efmCuPmeOperProfile object.
Any modification of this object MUST be performed when the
link is Down. Attempts to change this object MUST be
rejected, if the link is Up or Initializing.
Attempts to set this object to a value that is not the value
of the index for an active entry in the corresponding profile
table MUST be rejected.
This object maps to the Clause 30 attribute aProfileSelect.
This object MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] 30.11.2.1.6"
DEFVAL { 0 }
::= { efmCuPmeConfEntry 2 }Next up is the PAF Remote Discovery Code. It's a 6-octet code, and this one's a little more complicated because reading it, setting it to zeroes, and writing a non-zero value all trigger different discovery operations ✨
efmCuPAFRemoteDiscoveryCode OBJECT-TYPE
SYNTAX PhysAddress (SIZE(0|6))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"PAF Remote Discovery Code of the PME port at the CO.
The 6-octet Discovery Code of the peer PCS connected via
the PME.
Reading this object results in a Discovery Get operation.
Setting this object to all zeroes results in a Discovery
Clear_if_Same operation (the value of efmCuPAFDiscoveryCode
at the peer PCS SHALL be the same as efmCuPAFDiscoveryCode of
the local PCS associated with the PME for the operation to
succeed).
Writing a non-zero value to this object results in a
Discovery Set_if_Clear operation.
A zero-length octet string SHALL be returned on an attempt to
read this object when PAF aggregation is not enabled.
This object is irrelevant in CPE port (-R) subtypes: in this
case, a zero-length octet string SHALL be returned on an
attempt to read this object; writing to this object SHALL
be rejected.
Discovery MUST be performed when the link is Down.
Attempts to change this object MUST be rejected (in case of
SNMP with the error inconsistentValue), if the link is Up or
Initializing.
If a Clause 45 MDIO Interface to the PMA/PMD is present, then
this object is a function of 10P/2B aggregation discovery
control register, Discovery operation result bits in 10P/2B
aggregation and discovery status register and
10P/2B aggregation discovery code register."
REFERENCE
"[802.3ah] 61.2.2.8.4, 45.2.6.6-45.2.6.8"
::= { efmCuPmeConfEntry 3 }Now the two threshold objects 📈 They're both writable on the CO side only, and both are read-only on the CPE side. The line attenuation one is first 🦋
efmCuPmeThreshLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired Line Attenuation threshold for the 2B/10P PME.
This object configures the line attenuation alarm threshold.
When the current value of Line Attenuation reaches or
exceeds this threshold, an efmCuPmeLineAtnCrossing
notification MAY be generated, if enabled by
efmCuPmeLineAtnCrossingEnable.
This object is writable for the CO subtype PMEs (-O).
It is read-only for the CPE subtype (-R).
Changing of the Line Attenuation threshold MUST be performed
when the link is Down. Attempts to change this object MUST be
rejected (in case of SNMP with the error inconsistentValue),
if the link is Up or Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the loop attenuation threshold bits in
the 2B PMD line quality thresholds register."
REFERENCE
"[802.3ah] 45.2.1.36"
::= { efmCuPmeConfEntry 4 } efmCuPmeThreshSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128)
UNITS "dB"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Desired SNR margin threshold for the 2B/10P PME.
This object configures the SNR margin alarm threshold.
When the current value of SNR margin reaches or exceeds this
threshold, an efmCuPmeSnrMgnCrossing notification MAY be
generated, if enabled by efmCuPmeSnrMgnCrossingEnable.
This object is writable for the CO subtype PMEs
(2BaseTL-O/10PassTS-O). It is read-only for the CPE subtype
(2BaseTL-R/10PassTS-R).
Changing of the SNR margin threshold MUST be performed when
the link is Down. Attempts to change this object MUST be
rejected (in case of SNMP with the error inconsistentValue),
if the link is Up or Initializing.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the SNR margin threshold bits in the 2B PMD
line quality thresholds register."
REFERENCE
"[802.3ah] 45.2.1.36"
::= { efmCuPmeConfEntry 5 }Next is a little run of notification enable switches 🔔 Each one is a TruthValue, where true(1) means on and false(2) means off. They're all pretty chill, so I've grouped them together 🌸
efmCuPmeLineAtnCrossingEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether efmCuPmeLineAtnCrossing notifications
should be generated for this interface.
A value of true(1) indicates that efmCuPmeLineAtnCrossing
notification is enabled. A value of false(2) indicates that
the notification is disabled."
::= { efmCuPmeConfEntry 6 }
efmCuPmeSnrMgnCrossingEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether efmCuPmeSnrMgnCrossing notifications
should be generated for this interface.
A value of true(1) indicates that efmCuPmeSnrMgnCrossing
notification is enabled. A value of false(2) indicates that
the notification is disabled."
::= { efmCuPmeConfEntry 7 }
efmCuPmeDeviceFaultEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether efmCuPmeDeviceFault notifications
should be generated for this interface.
A value of true(1) indicates that efmCuPmeDeviceFault
notification is enabled. A value of false(2) indicates that
the notification is disabled."
::= { efmCuPmeConfEntry 8 }
efmCuPmeConfigInitFailEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether efmCuPmeConfigInitFailure notifications
should be generated for this interface.
A value of true(1) indicates that efmCuPmeConfigInitFailure
notification is enabled. A value of false(2) indicates that
the notification is disabled."
::= { efmCuPmeConfEntry 9 }
efmCuPmeProtocolInitFailEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether efmCuPmeProtocolInitFailure notifications
should be generated for this interface.
A value of true(1) indicates that efmCuPmeProtocolInitFailure
notification is enabled. A value of false(2) indicates that
the notification is disabled."
::= { efmCuPmeConfEntry 10 }Now we're in the capability table era 🧚 This is where the common stuff for the PME ports lives, and it's indexed by ifIndex 💜
efmCuPmeCapabilityTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPmeCapabilityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table for the configuration of common aspects for EFMCu
2BASE-TL/10PASS-TS PME ports (modems). The configuration of
aspects specific to 2BASE-TL or 10PASS-TS PME types is
represented in the efmCuPme2BConfTable and the
efmCuPme10PConfTable, respectively.
Entries in this table MUST be maintained in a persistent
manner."
::= { efmCuPme 2 }
efmCuPmeCapabilityEntry OBJECT-TYPE
SYNTAX EfmCuPmeCapabilityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu PME Capability table.
Each entry represents common aspects of an EFMCu PME port
indexed by the ifIndex. Note that an EFMCu PME port can be
stacked below a single PCS port, also indexed by ifIndex,
possibly together with other PME ports if PAF is enabled."
INDEX { ifIndex }
::= { efmCuPmeCapabilityTable 1 }
EfmCuPmeCapabilityEntry ::=
SEQUENCE {
efmCuPmeSubTypesSupported BITS
}
efmCuPmeSubTypesSupported OBJECT-TYPE
SYNTAX BITS {
ieee2BaseTLO(0),
ieee2BaseTLR(1),
ieee10PassTSO(2),
ieee10PassTSR(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME supported subtypes. This is a bitmap of possible
subtypes. The various bit positions are:
ieee2BaseTLO - PME is capable of operating as 2BaseTL-O
ieee2BaseTLR - PME is capable of operating as 2BaseTL-R
ieee10PassTSO - PME is capable of operating as 10PassTS-O
ieee10PassTSR - PME is capable of operating as 10PassTS-R
The desired mode of operation is determined by
efmCuPmeAdminSubType, while efmCuPmeOperSubType reflects the
current operating mode.
If a Clause 45 MDIO Interface to the PCS is present, then this
object combines the 10PASS-TS capable and 2BASE-TL capable
bits in the 10P/2B PMA/PMD speed ability register and the
CO supported and CPE supported bits in the 10P/2B PMA/PMD
status register."
REFERENCE
"[802.3ah] 61.1, 45.2.1.4.1, 45.2.1.4.2, 45.2.1.12.2,
45.2.1.12.3"
::= { efmCuPmeCapabilityEntry 1 }Last one in this part: the status table 🌈 Quick heads-up, this one holds live data from the equipment, so it is NOT persistent 💀
efmCuPmeStatusTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPmeStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides common status information of EFMCu
2BASE-TL/10PASS-TS PME ports. Status information specific
to 10PASS-TS PME is represented in efmCuPme10PStatusTable.
This table contains live data from the equipment. As such,
it is NOT persistent."
::= { efmCuPme 3 }Okay so we're now deep inside the efmCuPmeStatusEntry, which is the row for each PME port, keyed by ifIndex 🧚 The status columns are the main character of this whole table, so let's see what they've got 💅
efmCuPmeStatusEntry OBJECT-TYPE
SYNTAX EfmCuPmeStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu PME Status table.
Each entry represents common aspects of an EFMCu PME port
indexed by the ifIndex. Note that an EFMCu PME port can be
stacked below a single PCS port, also indexed by ifIndex,
possibly together with other PME ports if PAF is enabled."
INDEX { ifIndex }
::= { efmCuPmeStatusTable 1 }
EfmCuPmeStatusEntry ::=
SEQUENCE {
efmCuPmeOperStatus INTEGER,
efmCuPmeFltStatus BITS,
efmCuPmeOperSubType INTEGER,
efmCuPmeOperProfile EfmProfileIndexOrZero,
efmCuPmeSnrMgn Integer32,
efmCuPmePeerSnrMgn Integer32,
efmCuPmeLineAtn Integer32,
efmCuPmePeerLineAtn Integer32,
efmCuPmeEquivalentLength Unsigned32,
efmCuPmeTCCodingErrors Counter32,
efmCuPmeTCCrcErrors Counter32
}
efmCuPmeOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
downNotReady(2),
downReady(3),
init(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current PME link Operational Status. Possible values are:
up(1) - The link is Up and ready to pass
64/65-octet encoded frames or fragments.
downNotReady(2) - The link is Down and the PME does not
detect Handshake tones from its peer.
This value may indicate a possible
problem with the peer PME.
downReady(3) - The link is Down and the PME detects
Handshake tones from its peer.
init(4) - The link is Initializing, as a result of
ifAdminStatus being set to 'up' for a
particular PME or a PCS to which the PME
is connected.
This object is intended to supplement the Down(2) state of
ifOperStatus.
This object partially maps to the Clause 30 attribute
aPMEStatus.
If a Clause 45 MDIO Interface to the PME is present, then this
object partially maps to PMA/PMD link status bits in 10P/2B
PMA/PMD status register."
REFERENCE
"[802.3ah] 30.11.2.1.3, 45.2.1.12.4"
::= { efmCuPmeStatusEntry 1 }
efmCuPmeFltStatus OBJECT-TYPE
SYNTAX BITS {
lossOfFraming(0),
snrMgnDefect(1),
lineAtnDefect(2),
deviceFault(3),
configInitFailure(4),
protocolInitFailure(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current/Last PME link Fault Status. This is a bitmap of
possible conditions. The various bit positions are:
lossOfFraming - Loss of Framing for 10P or
Loss of Sync word for 2B PMD or
Loss of 64/65-octet framing.
snrMgnDefect - SNR margin dropped below the
threshold.
lineAtnDefect - Line Attenuation exceeds the
threshold.
deviceFault - Indicates a vendor-dependent
diagnostic or self-test fault
has been detected.
configInitFailure - Configuration initialization failure,
due to inability of the PME link to
support the configuration profile,
requested during initialization.
protocolInitFailure - Protocol initialization failure, due
to an incompatible protocol used by
the peer PME during init (that could
happen if a peer PMD is a regular
G.SDHSL/VDSL modem instead of a
2BASE-TL/10PASS-TS PME).
This object is intended to supplement ifOperStatus in IF-MIB.
This object holds information about the last fault.
efmCuPmeFltStatus is cleared by the device restart.
In addition, lossOfFraming, configInitFailure, and
protocolInitFailure are cleared by PME init;
deviceFault is cleared by successful diagnostics/test;
snrMgnDefect and lineAtnDefect are cleared by SNR margin
and Line attenuation, respectively, returning to norm and by
PME init.
This object partially maps to the Clause 30 attribute
aPMEStatus.
If a Clause 45 MDIO Interface to the PME is present, then this
object consolidates information from various PMA/PMD
registers, namely: Fault bit in PMA/PMD status 1 register,
10P/2B PMA/PMD link loss register,
10P outgoing indicator bits status register,
10P incoming indicator bits status register,
2B state defects register."
REFERENCE
"[802.3ah] 30.11.2.1.3, 45.2.1.2.1, 45.2.1.38,
45.2.1.39, 45.2.1.54"
::= { efmCuPmeStatusEntry 2 }
efmCuPmeOperSubType OBJECT-TYPE
SYNTAX INTEGER {
ieee2BaseTLO(1),
ieee2BaseTLR(2),
ieee10PassTSO(3),
ieee10PassTSR(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Current operational subtype of the PME.
Possible values are:
ieee2BaseTLO - PME operates as 2BaseTL-O
ieee2BaseTLR - PME operates as 2BaseTL-R
ieee10PassTSO - PME operates as 10PassTS-O
ieee10PassTSR - PME operates as 10PassTS-R
The desired operational subtype of the PME can be configured
via the efmCuPmeAdminSubType variable.
If a Clause 45 MDIO Interface to the PMA/PMD is present, then
this object combines values of the Port subtype select
bits, the PMA/PMD type selection bits in the 10P/2B
PMA/PMD control register, and the PMA/PMD link status bits in
the 10P/2B PMA/PMD status register."
REFERENCE
"[802.3ah] 61.1, 45.2.1.11.4, 45.2.1.11.7, 45.2.1.12.4"
::= { efmCuPmeStatusEntry 3 }
efmCuPmeOperProfile OBJECT-TYPE
SYNTAX EfmProfileIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PME current operating profile. This object is a pointer to
an entry in either the efmCuPme2BProfileTable or the
efmCuPme10PProfileTable, depending on the current operating
SubType of the PME as indicated by efmCuPmeOperSubType.
Note that a profile entry to which efmCuPmeOperProfile is
pointing can be created automatically to reflect achieved
parameters in adaptive (not fixed) initialization,
i.e., values of efmCuPmeOperProfile and efmCuAdminProfile or
efmCuPmeAdminProfile may differ.
The value of zero indicates that the PME is Down or
Initializing.
This object partially maps to the aOperatingProfile attribute
in Clause 30."
REFERENCE
"[802.3ah] 30.11.2.1.7"
::= { efmCuPmeStatusEntry 4 }
efmCuPmeSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128|65535)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Signal to Noise Ratio (SNR) margin with respect
to the received signal as perceived by the local PME.
The value of 65535 is returned when the PME is Down or
Initializing.
This object maps to the aPMESNRMgn attribute in Clause 30.
If a Clause 45 MDIO Interface is present, then this
object maps to the 10P/2B RX SNR margin register."
REFERENCE
"[802.3ah] 30.11.2.1.4, 45.2.1.16"
::= { efmCuPmeStatusEntry 5 }
efmCuPmePeerSnrMgn OBJECT-TYPE
SYNTAX Integer32(-127..128|65535)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current SNR margin in dB with respect to the received
signal, as perceived by the remote (link partner) PME.
The value of 65535 is returned when the PME is Down or
Initializing.
This object is irrelevant for the -R PME subtypes. The value
of 65535 SHALL be returned in this case.
If a Clause 45 MDIO Interface is present, then this
object maps to the 10P/2B link partner RX SNR margin
register."
REFERENCE
"[802.3ah] 45.2.1.17"
::= { efmCuPmeStatusEntry 6}
efmCuPmeLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128|65535)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Line Attenuation in dB as perceived by the local
PME.
The value of 65535 is returned when the PME is Down or
Initializing.
If a Clause 45 MDIO Interface is present, then this
object maps to the Line Attenuation register."
REFERENCE
"[802.3ah] 45.2.1.18"
::= { efmCuPmeStatusEntry 7 }
efmCuPmePeerLineAtn OBJECT-TYPE
SYNTAX Integer32(-127..128|65535)
UNITS "dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current Line Attenuation in dB as perceived by the remote
(link partner) PME.
The value of 65535 is returned when the PME is Down or
Initializing.
This object is irrelevant for the -R PME subtypes. The value
of 65535 SHALL be returned in this case.
If a Clause 45 MDIO Interface is present, then this
object maps to the 20P/2B link partner Line Attenuation
register."
REFERENCE
"[802.3ah] 45.2.1.19"
::= { efmCuPmeStatusEntry 8 }
efmCuPmeEquivalentLength OBJECT-TYPE
SYNTAX Unsigned32(0..8192|65535)
UNITS "m"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the equivalent loop's physical length in
meters, as perceived by the PME after the link is established.
An equivalent loop is a hypothetical 26AWG (0.4mm) loop with a
perfect square root attenuation characteristic, without any
bridged taps.
The value of 65535 is returned if the link is Down or
Initializing or the PME is unable to estimate the equivalent
length.
For a 10BASE-TL PME, if a Clause 45 MDIO Interface to the PME
is present, then this object maps to the 10P Electrical Length
register."
REFERENCE
"[802.3ah] 45.2.1.21"
::= { efmCuPmeStatusEntry 9 }
efmCuPmeTCCodingErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of 64/65-octet encapsulation errors. This counter
is incremented for each 64/65-octet encapsulation error
detected by the 64/65-octet receive function.
This object maps to aTCCodingViolations attribute in
Clause 30.Okay so picking up right where we left off, bestie 🫶 the coding violations counter still has one more note, and it's a big one for MDIO folks 🔥
If a Clause 45 MDIO Interface to the PME TC is present, then
this object maps to the TC coding violations register
(see 45.2.6.12).
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 61.3.3.1, 30.11.2.1.5, 45.2.6.12"
::= { efmCuPmeStatusEntry 10 }Next up is the TC CRC error counter 💅 It's the one that ticks every time the 64/65-octet receive function catches a TC-CRC error, and it's iconic because it hooks straight into aTCCRCErrors in Clause 30 ✨
efmCuPmeTCCrcErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of TC-CRC errors. This counter is incremented for
each TC-CRC error detected by the 64/65-octet receive function
(see 61.3.3.3 and Figure 61-19).
This object maps to aTCCRCErrors attribute in
Clause 30.
If a Clause 45 MDIO Interface to the PME TC is present, then
this object maps to the TC CRC error register
(see 45.2.6.11).
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 61.3.3.3, 30.11.2.1.10, 45.2.6.11"
::= { efmCuPmeStatusEntry 11 }Now we're entering the 2BASE-TL specific PME group 🌸 This is where the profile table lives, and honestly it's giving very organised vibes ✨
-- 2BASE-TL specific PME group
efmCuPme2B OBJECT IDENTIFIER ::= { efmCuPme 5 }
efmCuPme2BProfileTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme2BProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table supports definitions of administrative and
operating profiles for 2BASE-TL PMEs.
The first 14 entries in this table SHALL always be defined as
follows (see 802.3ah Annex 63A):
-------+-------+-------+-----+------+-------------+-----------
Profile MinRate MaxRate Power Region Constellation Comment
index (Kbps) (Kbps) (dBm)
-------+-------+-------+-----+------+-------------+-----------
1 5696 5696 13.5 1 32-TCPAM default
2 3072 3072 13.5 1 32-TCPAM
3 2048 2048 13.5 1 16-TCPAM
4 1024 1024 13.5 1 16-TCPAM
5 704 704 13.5 1 16-TCPAM
6 512 512 13.5 1 16-TCPAM
7 5696 5696 14.5 2 32-TCPAM
8 3072 3072 14.5 2 32-TCPAM
9 2048 2048 14.5 2 16-TCPAM
10 1024 1024 13.5 2 16-TCPAM
11 704 704 13.5 2 16-TCPAM
12 512 512 13.5 2 16-TCPAM
13 192 5696 0 1 0 best effort
14 192 5696 0 2 0 best effort
-------+-------+-------+-----+------+-------------+-----------
These default entries SHALL be created during agent
initialization and MUST NOT be deleted.
Entries following the first 14 can be dynamically created and
deleted to provide custom administrative (configuration)
profiles and automatic operating profiles.
This table MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] Annex 63A, 30.11.2.1.6"
::= { efmCuPme2B 2 }Okay so the first 14 rows are the defaults, and they're not optional, no cap 😭 The agent has to create them at initialization, and the default entries are off limits for deletion 🔒 Everything after row 14 is where you get to be creative with your own custom profiles 🦋
efmCuPme2BProfileEntry OBJECT-TYPE
SYNTAX EfmCuPme2BProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry corresponds to a single 2BASE-TL PME profile.
Each profile contains a set of parameters, used either for
configuration or representation of a 2BASE-TL PME.
In case a particular profile is referenced via the
efmCuPmeAdminProfile object (or efmCuAdminProfile if
efmCuPmeAdminProfile is zero), it represents the desired
parameters for the 2BaseTL-O PME initialization.
If a profile is referenced via an efmCuPmeOperProfile object,
it represents the current operating parameters of an
operational PME.
Profiles may be created/deleted using the row creation/
deletion mechanism via efmCuPme2BProfileRowStatus. If an
active entry is referenced, the entry MUST remain 'active'
until all references are removed.
Default entries MUST NOT be removed."
INDEX { efmCuPme2BProfileIndex }
::= { efmCuPme2BProfileTable 1 }
EfmCuPme2BProfileEntry ::=
SEQUENCE {
efmCuPme2BProfileIndex EfmProfileIndex,
efmCuPme2BProfileDescr SnmpAdminString,
efmCuPme2BRegion INTEGER,
efmCuPme2BsMode EfmProfileIndexOrZero,
efmCuPme2BMinDataRate Unsigned32,
efmCuPme2BMaxDataRate Unsigned32,
efmCuPme2BPower Unsigned32,
efmCuPme2BConstellation INTEGER,
efmCuPme2BProfileRowStatus RowStatus
}
efmCuPme2BProfileIndex OBJECT-TYPE
SYNTAX EfmProfileIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"2BASE-TL PME profile index.
This object is the unique index associated with this profile.
Entries in this table are referenced via efmCuAdminProfile or
efmCuPmeAdminProfile objects."
::= { efmCuPme2BProfileEntry 1 }
efmCuPme2BProfileDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual string containing information about a 2BASE-TL PME
profile. The string may include information about the data
rate and spectral limitations of this particular profile."
::= { efmCuPme2BProfileEntry 2 }Now the region setting 🌈 It decides the PSD mask and PBO values, and it's the reason region1 and region2 act so differently ✨
efmCuPme2BRegion OBJECT-TYPE
SYNTAX INTEGER {
region1(1),
region2(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Regional settings for a 2BASE-TL PME, as specified in the
relevant Regional Annex of [G.991.2].
Regional settings specify the Power Spectral Density (PSD)
mask and the Power Back-Off (PBO) values, and place
limitations on the max allowed data rate, power, and
constellation.
Possible values for this object are:
region1 - Annexes A and F (e.g., North America)
region2 - Annexes B and G (e.g., Europe)
Annex A/B specify regional settings for data rates 192-2304
Kbps using 16-TCPAM encoding.
Annex F/G specify regional settings for rates 2320-3840 Kbps
using 16-TCPAM encoding and 768-5696 Kbps using 32-TCPAM
encoding.
If a Clause 45 MDIO Interface to the PME is present, then this
object partially maps to the Region bits in the 2B general
parameter register."
REFERENCE
"[802.3ah] 45.2.1.42; [G.991.2] Annexes A, B, F and G"
::= { efmCuPme2BProfileEntry 3 }
efmCuPme2BsMode OBJECT-TYPE
SYNTAX EfmProfileIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Desired custom Spectral Mode for a 2BASE-TL PME. This object
is a pointer to an entry in efmCuPme2BsModeTable and a block
of entries in efmCuPme2BRateReachTable, which together define
(country-specific) reach-dependent rate limitations in
addition to those defined by efmCuPme2BRegion.
The value of this object is the index of the referenced
spectral mode.
The value of zero (default) indicates that no specific
spectral mode is applicable.
Attempts to set this object to a value that is not the value
of the index for an active entry in the corresponding spectral
mode table MUST be rejected."
REFERENCE
"efmCuPme2BsModeTable, efmCuPme2BRateReachTable"
DEFVAL { 0 }
::= { efmCuPme2BProfileEntry 4 }Data rates next, and these are where the fixed versus adaptive thing lives 💖 If min and max match it's fixed, and if min is lower than max it's adaptive. Main character energy 👑
efmCuPme2BMinDataRate OBJECT-TYPE
SYNTAX Unsigned32(192..5696)
UNITS "Kbps"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Minimum Data Rate for the 2BASE-TL PME.
This object can take values of (n x 64)Kbps,
where n=3..60 for 16-TCPAM and n=12..89 for 32-TCPAM encoding.
The data rate of the 2BASE-TL PME is considered 'fixed' when
the value of this object equals that of efmCuPme2BMaxDataRate.
If efmCuPme2BMinDataRate is less than efmCuPme2BMaxDataRate in
the administrative profile, the data rate is considered
'adaptive', and SHALL be set to the maximum attainable rate
not exceeding efmCuPme2BMaxDataRate, under the spectral
limitations placed by the efmCuPme2BRegion and
efmCuPme2BsMode.
Note that the current operational data rate of the PME is
represented by the ifSpeed object of IF-MIB.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the Min Data Rate1 bits in the 2B PMD
parameters register.
This object MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BProfileEntry 5 }
efmCuPme2BMaxDataRate OBJECT-TYPE
SYNTAX Unsigned32(192..5696)
UNITS "Kbps"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum Data Rate for the 2BASE-TL PME.
This object can take values of (n x 64)Kbps,
where n=3..60 for 16-TCPAM and n=12..89 for 32-TCPAM encoding.
The data rate of the 2BASE-TL PME is considered 'fixed' when
the value of this object equals that of efmCuPme2BMinDataRate.
If efmCuPme2BMinDataRate is less than efmCuPme2BMaxDataRate in
the administrative profile, the data rate is considered
'adaptive', and SHALL be set to the maximum attainable rate
not exceeding efmCuPme2BMaxDataRate, under the spectral
limitations placed by the efmCuPme2BRegion and
efmCuPme2BsMode.
Note that the current operational data rate of the PME is
represented by the ifSpeed object of IF-MIB.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the Max Data Rate1 bits in the 2B PMD
parameters register.
This object MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BProfileEntry 6 }And last for this part, the transmit power 🔥 It's counted in 0.5 dBm steps, and a value of 0 means the device gets to pick whatever maximizes the rate, which is honestly such a vibe 🧚
efmCuPme2BPower OBJECT-TYPE
SYNTAX Unsigned32(0|10..42)
UNITS "0.5 dBm"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Signal Transmit Power. Multiple of 0.5 dBm.
The value of 0 in the administrative profile means that the
signal transmit power is not fixed and SHALL be set to
maximize the attainable rate, under the spectral limitations
placed by the efmCuPme2BRegion and efmCuPme2BsMode.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the Power1 bits in the 2B PMD parameters
register."
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BProfileEntry 7 }Okay bestie, we're picking up right where the 2BASE-TL stuff gets really spicy 🌶️💖 Constellations, spectral modes, and reach-rate tables, all in one go. Let's go ✨
Here's the constellation object, which is how the PME picks between 16-TCPAM and 32-TCPAM 🎀
efmCuPme2BConstellation OBJECT-TYPE
SYNTAX INTEGER {
adaptive(0),
tcpam16(1),
tcpam32(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"TCPAM Constellation of the 2BASE-TL PME.
The possible values are:
adaptive(0) - either 16- or 32-TCPAM
tcpam16(1) - 16-TCPAM
tcpam32(2) - 32-TCPAM
The value of adaptive(0) in the administrative profile means
that the constellation is not fixed and SHALL be set to
maximize the attainable rate, under the spectral limitations
placed by the efmCuPme2BRegion and efmCuPme2BsMode.
If a Clause 45 MDIO Interface to the PME is present, then this
object maps to the Constellation1 bits in the 2B general
parameter register."
REFERENCE
"[802.3ah] 45.2.1.43"
::= { efmCuPme2BProfileEntry 8 }
efmCuPme2BProfileRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls the creation, modification, or deletion
of the associated entry in the efmCuPme2BProfileTable per the
semantics of RowStatus.
If an 'active' entry is referenced via efmCuAdminProfile or
efmCuPmeAdminProfile instance(s), the entry MUST remain
'active'.
An 'active' entry SHALL NOT be modified. In order to modify
an existing entry, it MUST be taken out of service (by setting
this object to 'notInService'), modified, and set 'active'
again."
::= { efmCuPme2BProfileEntry 9 }Next up is the custom spectral mode table. It's basically a little VIP list for countries with their own loop-length rules 🇬🇧✨
efmCuPme2BsModeTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme2BsModeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table, together with efmCu2BReachRateTable, supports
definition of administrative custom spectral modes for
2BASE-TL PMEs, describing spectral limitations in addition to
those specified by efmCuPme2BRegion.
In some countries, spectral regulations (e.g., UK ANFP) limit
the length of the loops for certain data rates. This table
allows these country-specific limitations to be specified.
Entries in this table referenced by the efmCuPme2BsMode
MUST NOT be deleted until all the active references are
removed.
This table MUST be maintained in a persistent manner."
REFERENCE
"efmCu2BReachRateTable"
::= { efmCuPme2B 3 }
efmCuPme2BsModeEntry OBJECT-TYPE
SYNTAX EfmCuPme2BsModeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry specifies a spectral mode description and its
index, which is used to reference corresponding entries in the
efmCu2BReachRateTable.
Entries may be created/deleted using the row creation/
deletion mechanism via efmCuPme2BsModeRowStatus."
INDEX { efmCuPme2BsModeIndex }
::= { efmCuPme2BsModeTable 1 }
EfmCuPme2BsModeEntry ::=
SEQUENCE {
efmCuPme2BsModeIndex EfmProfileIndex,
efmCuPme2BsModeDescr SnmpAdminString,
efmCuPme2BsModeRowStatus RowStatus
}
efmCuPme2BsModeIndex OBJECT-TYPE
SYNTAX EfmProfileIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"2BASE-TL PME Spectral Mode index.
This object is the unique index associated with this spectral
mode.
Entries in this table are referenced via the efmCuPme2BsMode
object."
::= { efmCuPme2BsModeEntry 1 }
efmCuPme2BsModeDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual string containing information about a 2BASE-TL PME
spectral mode. The string may include information about
corresponding (country-specific) spectral regulations
and rate/reach limitations of this particular spectral mode."
::= { efmCuPme2BsModeEntry 2 }
efmCuPme2BsModeRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls creation, modification, or deletion of
the associated entry in efmCuPme2BsModeTable per the semantics
of RowStatus.
If an 'active' entry is referenced via efmCuPme2BsMode
instance(s), the entry MUST remain 'active'.
An 'active' entry SHALL NOT be modified. In order to modify
an existing entry, it MUST be taken out of service (by setting
this object to 'notInService'), modified, and set 'active'
again."
::= { efmCuPme2BsModeEntry 3 }Now the reach-rate table, which is the real main character of this section 🦋 It comes with an example table for ANFP, so keep your eyes on the numbers:
efmCuPme2BReachRateTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme2BReachRateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table supports the definition of administrative custom
spectral modes for 2BASE-TL PMEs, providing spectral
limitations in addition to those specified by
efmCuPme2BRegion.
The spectral regulations in some countries (e.g., UK ANFP)
limit the length of the loops for certain data rates.
This table allows these country-specific limitations to be
specified.
Below is an example of this table for [ANFP]:
----------+-------+-------
Equivalent MaxRate MaxRate
Length PAM16 PAM32
(m) (Kbps) (Kbps)
----------+-------+-------
975 2304 5696
1125 2304 5504
1275 2304 5120
1350 2304 4864
1425 2304 4544
1500 2304 4288
1575 2304 3968
1650 2304 3776
1725 2304 3520
1800 2304 3264
1875 2304 3072
1950 2048 2688
2100 1792 2368
2250 1536 0
2400 1408 0
2550 1280 0
2775 1152 0
2925 1152 0
3150 1088 0
3375 1024 0
----------+-------+-------
Entries in this table referenced by an efmCuPme2BsMode
instance MUST NOT be deleted.
This table MUST be maintained in a persistent manner."
REFERENCE
"[ANFP]"
::= { efmCuPme2B 4 }
efmCuPme2BReachRateEntry OBJECT-TYPE
SYNTAX EfmCuPme2BReachRateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry specifies maximum 2BASE-TL PME data rates
allowed for a certain equivalent loop length, when using
16-TCPAM or 32-TCPAM encoding.
When a 2BASE-TL PME is initialized, its data rate MUST NOT
exceed one of the following limitations:
- the value of efmCuPme2BMaxDataRate
- maximum data rate allowed by efmCuPme2BRegion and
efmCuPme2BPower
- maximum data rate for a given encoding specified in the
efmCuPme2BsModeEntry, corresponding to the equivalent loop
length, estimated by the PME
It is RECOMMENDED that the efmCuPme2BEquivalentLength values
are assigned in increasing order, starting from the minimum
value.
Entries may be created/deleted using the row creation/
deletion mechanism via efmCuPme2ReachRateRowStatus."
INDEX { efmCuPme2BsModeIndex, efmCuPme2BReachRateIndex }
::= { efmCuPme2BReachRateTable 1 }
EfmCuPme2BReachRateEntry ::=
SEQUENCE {
efmCuPme2BReachRateIndex EfmProfileIndex,
efmCuPme2BEquivalentLength Unsigned32,
efmCuPme2BMaxDataRatePam16 Unsigned32,
efmCuPme2BMaxDataRatePam32 Unsigned32,
efmCuPme2BReachRateRowStatus RowStatus
}
efmCuPme2BReachRateIndex OBJECT-TYPE
SYNTAX EfmProfileIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"2BASE-TL custom spectral mode Reach-Rate table index.
This object is the unique index associated with each entry."
::= { efmCuPme2BReachRateEntry 1 }
efmCuPme2BEquivalentLength OBJECT-TYPE
SYNTAX Unsigned32(0..8192)
UNITS "m"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum allowed equivalent loop's physical length in meters
for the specified data rates.
An equivalent loop is a hypothetical 26AWG (0.4mm) loop with a
perfect square root attenuation characteristic, without any
bridged taps."
::= { efmCuPme2BReachRateEntry 2 }
efmCuPme2BMaxDataRatePam16 OBJECT-TYPE
SYNTAX Unsigned32(0|192..5696)
UNITS "Kbps"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum data rate for a 2BASE-TL PME at the specified
equivalent loop's length using TC-PAM16 encoding.
The value of zero means that TC-PAM16 encoding should not be
used at this distance."
::= { efmCuPme2BReachRateEntry 3 }
efmCuPme2BMaxDataRatePam32 OBJECT-TYPE
SYNTAX Unsigned32(0|192..5696)
UNITS "Kbps"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum data rate for a 2BASE-TL PME at the specified
equivalent loop's length using TC-PAM32 encoding.
The value of zero means that TC-PAM32 encoding should not be
used at this distance."
::= { efmCuPme2BReachRateEntry 4 }
efmCuPme2BReachRateRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls the creation, modification, or deletion
of the associated entry in the efmCuPme2BReachRateTable per
the semantics of RowStatus.
If an 'active' entry is referenced via efmCuPme2BsMode
instance(s), the entry MUST remain 'active'.
An 'active' entry SHALL NOT be modified. In order to modify
an existing entry, it MUST be taken out of service (by setting
this object to 'notInService'), modified, and set 'active'
again."
::= { efmCuPme2BReachRateEntry 5 }That wraps up the 2BASE-TL bits 💅 Last but not least, the 10PASS-TS PME group gets its own little header, and we're starting that branch now 🧚
-- 10PASS-TS specific PME group
efmCuPme10P OBJECT IDENTIFIER ::= { efmCuPme 6 }The 10PASS-TS profile table is giving main character energy 💅 It has 22 default profiles that get created on startup and can never be deleted, plus room for custom ones. Here's the table itself 🎀
efmCuPme10PProfileTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme10PProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table supports definitions of configuration profiles for
10PASS-TS PMEs.
The first 22 entries in this table SHALL always be defined as
follows (see 802.3ah Annex 62B.3, table 62B-1):
-------+--------+----+---------+-----+-----+---------------
Profile Bandplan UPBO BandNotch DRate URate Comment
Index PSDMask# p# p# p# p#
-------+--------+----+---------+-----+-----+---------------
1 1 3 2,6,10,11 20 20 default profile
2 13 5 0 20 20
3 1 1 0 20 20
4 16 0 0 100 100
5 16 0 0 70 50
6 6 0 0 50 10
7 17 0 0 30 30
8 8 0 0 30 5
9 4 0 0 25 25
10 4 0 0 15 15
11 23 0 0 10 10
12 23 0 0 5 5
13 16 0 2,5,9,11 100 100
14 16 0 2,5,9,11 70 50
15 6 0 2,6,10,11 50 10
16 17 0 2,5,9,11 30 30
17 8 0 2,6,10,11 30 5
18 4 0 2,6,10,11 25 25
19 4 0 2,6,10,11 15 15
20 23 0 2,5,9,11 10 10
21 23 0 2,5,9,11 5 5
22 30 0 0 200 50
-------+--------+----+---------+-----+-----+---------------
These default entries SHALL be created during agent
initialization and MUST NOT be deleted.
Entries following the first 22 can be dynamically created and
deleted to provide custom administrative (configuration)
profiles and automatic operating profiles.
This table MUST be maintained in a persistent manner."
REFERENCE
"[802.3ah] Annex 62B.3, 30.11.2.1.6"
::= { efmCuPme10P 1 }Each row is one ready-to-go profile 🦋 The first 22 are locked in as defaults. Some of them are special, like profile 1 (the default one, obviously) and profile 22, which is the only one that goes up to 200 for downstream. So iconic 🔥
Now for the entry definition, which is where the rules for references and deletion live 🧚
efmCuPme10PProfileEntry OBJECT-TYPE
SYNTAX EfmCuPme10PProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry corresponds to a single 10PASS-TS PME profile.
Each profile contains a set of parameters, used either for
configuration or representation of a 10PASS-TS PME.
In case a particular profile is referenced via the
efmCuPmeAdminProfile object (or efmCuAdminProfile if
efmCuPmeAdminProfile is zero), it represents the desired
parameters for the 10PassTS-O PME initialization.
If a profile is referenced via an efmCuPmeOperProfile object,
it represents the current operating parameters of the PME.
Profiles may be created/deleted using the row creation/
deletion mechanism via efmCuPme10PProfileRowStatus. If an
'active' entry is referenced, the entry MUST remain 'active'
until all references are removed.
Default entries MUST NOT be removed."
INDEX { efmCuPme10PProfileIndex }
::= { efmCuPme10PProfileTable 1 }Okay so an entry can be the admin profile (what you want) or the oper profile (what's actually running) 💖 And if something is still pointing at an active entry, it stays active until nothing references it anymore. Defaults are never deleted, full stop 🙈
Next up is the row layout and the index, which is how each profile gets its name tag 🌸
EfmCuPme10PProfileEntry ::=
SEQUENCE {
efmCuPme10PProfileIndex EfmProfileIndex,
efmCuPme10PProfileDescr SnmpAdminString,
efmCuPme10PBandplanPSDMskProfile INTEGER,
efmCuPme10PUPBOReferenceProfile INTEGER,
efmCuPme10PBandNotchProfiles BITS,
efmCuPme10PPayloadDRateProfile INTEGER,
efmCuPme10PPayloadURateProfile INTEGER,
efmCuPme10PProfileRowStatus RowStatus
}
efmCuPme10PProfileIndex OBJECT-TYPE
SYNTAX EfmProfileIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"10PASS-TS PME profile index.
This object is the unique index associated with this profile.
Entries in this table are referenced via efmCuAdminProfile or
efmCuPmeAdminProfile."
::= { efmCuPme10PProfileEntry 1 }
efmCuPme10PProfileDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual string containing information about a 10PASS-TS PME
profile. The string may include information about data rate
and spectral limitations of this particular profile."
::= { efmCuPme10PProfileEntry 2 }The description field is just a free-text label, so you can write down the rate and spectrum limits right there 🍓
Now the big one, the Bandplan and PSD Mask profile. It has 30 options and they're all pulled from 802.3ah Annex 62A 🌈
efmCuPme10PBandplanPSDMskProfile OBJECT-TYPE
SYNTAX INTEGER {
profile1(1),
profile2(2),
profile3(3),
profile4(4),
profile5(5),
profile6(6),
profile7(7),
profile8(8),
profile9(9),
profile10(10),
profile11(11),
profile12(12),
profile13(13),
profile14(14),
profile15(15),
profile16(16),
profile17(17),
profile18(18),
profile19(19),
profile20(20),
profile21(21),
profile22(22),
profile23(23),
profile24(24),
profile25(25),
profile26(26),
profile27(27),
profile28(28),
profile29(29),
profile30(30)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 10PASS-TS PME Bandplan and PSD Mask Profile, as specified
in 802.3ah Annex 62A, table 62A-1. Possible values are:
--------------+------------------------+------------+--------
Profile Name PSD Mask Bands G.993.1
0/1/2/3/4/5 Bandplan
--------------+------------------------+------------+--------
profile1(1) T1.424 FTTCab.M1 x/D/U/D/U A
profile2(2) T1.424 FTTEx.M1 x/D/U/D/U A
profile3(3) T1.424 FTTCab.M2 x/D/U/D/U A
profile4(4) T1.424 FTTEx.M2 x/D/U/D/U A
profile5(5) T1.424 FTTCab.M1 D/D/U/D/U A
profile6(6) T1.424 FTTEx.M1 D/D/U/D/U A
profile7(7) T1.424 FTTCab.M2 D/D/U/D/U A
profile8(8) T1.424 FTTEx.M2 D/D/U/D/U A
profile9(9) T1.424 FTTCab.M1 U/D/U/D/x A
profile10(10) T1.424 FTTEx.M1 U/D/U/D/x A
profile11(11) T1.424 FTTCab.M2 U/D/U/D/x A
profile12(12) T1.424 FTTEx.M2 U/D/U/D/x A
profile13(13) TS 101 270-1 Pcab.M1.A x/D/U/D/U B
profile14(14) TS 101 270-1 Pcab.M1.B x/D/U/D/U B
profile15(15) TS 101 270-1 Pex.P1.M1 x/D/U/D/U B
profile16(16) TS 101 270-1 Pex.P2.M1 x/D/U/D/U B
profile17(17) TS 101 270-1 Pcab.M2 x/D/U/D/U B
profile18(18) TS 101 270-1 Pex.P1.M2 x/D/U/D/U B
profile19(19) TS 101 270-1 Pex.P2.M2 x/D/U/D/U B
profile20(20) TS 101 270-1 Pcab.M1.A U/D/U/D/x B
profile21(21) TS 101 270-1 Pcab.M1.B U/D/U/D/x B
profile22(22) TS 101 270-1 Pex.P1.M1 U/D/U/D/x B
profile23(23) TS 101 270-1 Pex.P2.M1 U/D/U/D/x B
profile24(24) TS 101 270-1 Pcab.M2 U/D/U/D/x B
profile25(25) TS 101 270-1 Pex.P1.M2 U/D/U/D/x B
profile26(26) TS 101 270-1 Pex.P2.M2 U/D/U/D/x B
profile27(27) G.993.1 F.1.2.1 x/D/U/D/U Annex F
profile28(28) G.993.1 F.1.2.2 x/D/U/D/U Annex F
profile29(29) G.993.1 F.1.2.3 x/D/U/D/U Annex F
profile30(30) T1.424 FTTCab.M1 (ext.) x/D/U/D/U/D Annex A
--------------+------------------------+------------+--------
"
REFERENCE
"[802.3ah] Annex 62A"
::= { efmCuPme10PProfileEntry 3 }Each profile number is basically a shortcut to a whole combo of PSD mask, band layout and G.993.1 bandplan 🦋 Ngl, that's a lot of combos to keep track of, but the table has you covered.
Next is the Upstream Power Back-Off reference, which just points at a reference PSD. Profile 0 means no profile 💅
efmCuPme10PUPBOReferenceProfile OBJECT-TYPE
SYNTAX INTEGER {
profile0(0),
profile1(1),
profile2(2),
profile3(3),
profile4(4),
profile5(5),
profile6(6),
profile7(7),
profile8(8),
profile9(9)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 10PASS-TS PME Upstream Power Back-Off (UPBO) Reference
PSD Profile, as specified in 802.3 Annex 62A, table 62A-3.
Possible values are:
------------+-----------------------------
Profile Name Reference PSD
------------+-----------------------------
profile0(0) no profile
profile1(1) T1.424 Noise A M1
profile2(2) T1.424 Noise A M2
profile3(3) T1.424 Noise F M1
profile4(4) T1.424 Noise F M2
profile5(5) TS 101 270-1 Noise A&B
profile6(6) TS 101 270-1 Noise C
profile7(7) TS 101 270-1 Noise D
profile8(8) TS 101 270-1 Noise E
profile9(9) TS 101 270-1 Noise F
------------+-----------------------------
"
REFERENCE
"[802.3ah] Annex 62A.3.5"
::= { efmCuPme10PProfileEntry 4 }Last up for this part is the Band Notch bitmap. This one is basically a checkbox list, so any combo can be selected by ORing the profiles together ✨
efmCuPme10PBandNotchProfiles OBJECT-TYPE
SYNTAX BITS {
profile0(0),
profile1(1),
profile2(2),
profile3(3),
profile4(4),
profile5(5),
profile6(6),
profile7(7),
profile8(8),
profile9(9),
profile10(10),
profile11(11)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 10PASS-TS PME Egress Control Band Notch Profile bitmap,
as specified in 802.3 Annex 62A, table 62A-4. Possible values
are:
--------------+--------+------+------------+------+------
Profile Name G.991.3 T1.424 TS 101 270-1 StartF EndF
table table table (MHz) (MHz)
--------------+--------+------+------------+------+------
profile0(0) no profile
profile1(1) F-5 #01 - - 1.810 1.825
profile2(2) 6-2 15-1 17 1.810 2.000
profile3(3) F-5 #02 - - 1.907 1.912
profile4(4) F-5 #03 - - 3.500 3.575
profile5(5) 6-2 - 17 3.500 3.800
profile6(6) - 15-1 - 3.500 4.000
profile7(7) F-5 #04 - - 3.747 3.754
profile8(8) F-5 #05 - - 3.791 3.805
profile9(9) 6-2 - 17 7.000 7.100
profile10(10) F-5 #06 15-1 - 7.000 7.300
profile11(11) 6-2 15-1 1 10.100 10.150
--------------+--------+------+------------+------+------
Any combination of profiles can be specified by ORing
individual profiles, for example, a value of 0x2230 selects
profiles 2, 6, 10, and 11."
REFERENCE
"[802.3ah] Annex 62A.3.5"
::= { efmCuPme10PProfileEntry 5 }Ok that's the 10PASS-TS profile table and all its columns so far. The profile families are about to get even more iconic 🌈
Okay so we're picking right back up with the 10PASS-TS profile objects, and bestie, the payload rate profiles are giving menu 🍓💅
efmCuPme10PPayloadDRateProfile OBJECT-TYPE
SYNTAX INTEGER {
profile5(5),
profile10(10),
profile15(15),
profile20(20),
profile25(25),
profile30(30),
profile50(50),
profile70(70),
profile100(100),
profile140(140),
profile200(200)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 10PASS-TS PME Downstream Payload Rate Profile, as
specified in 802.3 Annex 62A. Possible values are:
profile5(5) - 2.5 Mbps
profile10(10) - 5 Mbps
profile15(15) - 7.5 Mbps
profile20(20) - 10 Mbps
profile25(25) - 12.5 Mbps
profile30(30) - 15 Mbps
profile50(50) - 25 Mbps
profile70(70) - 35 Mbps
profile100(100) - 50 Mbps
profile140(140) - 70 Mbps
profile200(200) - 100 Mbps
Each value represents a target for the PME's Downstream
Payload Bitrate as seen at the MII. If the payload rate of
the selected profile cannot be achieved based on the loop
environment, bandplan, and PSD mask, the PME initialization
SHALL fail."
REFERENCE
"[802.3ah] Annex 62A.3.6"
::= { efmCuPme10PProfileEntry 6 }
efmCuPme10PPayloadURateProfile OBJECT-TYPE
SYNTAX INTEGER {
profile5(5),
profile10(10),
profile15(15),
profile20(20),
profile25(25),
profile30(30),
profile50(50),
profile70(70),
profile100(100)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 10PASS-TS PME Upstream Payload Rate Profile, as specified
in 802.3 Annex 62A. Possible values are:
profile5(5) - 2.5 Mbps
profile10(10) - 5 Mbps
profile15(15) - 7.5 Mbps
profile20(20) - 10 Mbps
profile25(25) - 12.5 Mbps
profile30(30) - 15 Mbps
profile50(50) - 25 Mbps
profile70(70) - 35 Mbps
profile100(100) - 50 Mbps
Each value represents a target for the PME's Upstream Payload
Bitrate as seen at the MII. If the payload rate of the
selected profile cannot be achieved based on the loop
environment, bandplan, and PSD mask, the PME initialization
SHALL fail."
REFERENCE
"[802.3ah] Annex 62A.3.6"
::= { efmCuPme10PProfileEntry 7 }
efmCuPme10PProfileRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls creation, modification, or deletion of
the associated entry in efmCuPme10PProfileTable per the
semantics of RowStatus.
If an active entry is referenced via efmCuAdminProfile or
efmCuPmeAdminProfile, the entry MUST remain 'active' until
all references are removed.
An 'active' entry SHALL NOT be modified. In order to modify
an existing entry, it MUST be taken out of service (by setting
this object to 'notInService'), modified, and set 'active'
again."
::= { efmCuPme10PProfileEntry 8 }Next up is the status table, which is basically the live-data corner of the 10PASS-TS world 🦋 The table is marked as NOT persistent, so don't go expecting it to stick around across things ✨
efmCuPme10PStatusTable OBJECT-TYPE
SYNTAX SEQUENCE OF EfmCuPme10PStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides status information of EFMCu 10PASS-TS
PMEs (modems).
This table contains live data from the equipment. As such,
it is NOT persistent."
::= { efmCuPme10P 2 }
efmCuPme10PStatusEntry OBJECT-TYPE
SYNTAX EfmCuPme10PStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EFMCu 10PASS-TS PME Status table."
INDEX { ifIndex }
::= { efmCuPme10PStatusTable 1 }
EfmCuPme10PStatusEntry ::=
SEQUENCE {
efmCuPme10PFECCorrectedBlocks Counter32,
efmCuPme10PFECUncorrectedBlocks Counter32
}
efmCuPme10PFECCorrectedBlocks OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received and corrected Forward Error Correction
(FEC) codewords in this 10PASS-TS PME.
This object maps to the aPMEFECCorrectedBlocks attribute in
Clause 30.
If a Clause 45 MDIO Interface to the PMA/PMD is present,
then this object maps to the 10P FEC correctable errors
register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.1.22, 30.11.2.1.8"
::= { efmCuPme10PStatusEntry 1 }
efmCuPme10PFECUncorrectedBlocks OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received uncorrectable FEC codewords in this
10PASS-TS PME.
This object maps to the aPMEFECUncorrectableBlocks attribute
in Clause 30.
If a Clause 45 MDIO Interface to the PMA/PMD is present,
then this object maps to the 10P FEC uncorrectable errors
register.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times
as indicated by the value of ifCounterDiscontinuityTime,
defined in IF-MIB."
REFERENCE
"[802.3ah] 45.2.1.23, 30.11.2.1.9"
::= { efmCuPme10PStatusEntry 2 }Now the conformance section, which is where the groups get bundled up into neat little packages for the object list 💜 Here's the group lineup:
--
-- Conformance Statements
--
efmCuGroups OBJECT IDENTIFIER ::= { efmCuConformance 1 }
efmCuCompliances OBJECT IDENTIFIER ::= { efmCuConformance 2 }
-- Object Groups
efmCuBasicGroup OBJECT-GROUP
OBJECTS {
efmCuPAFSupported,
efmCuAdminProfile,
efmCuTargetDataRate,
efmCuTargetSnrMgn,
efmCuAdaptiveSpectra,
efmCuPortSide,
efmCuFltStatus
}
STATUS current
DESCRIPTION
"A collection of objects representing management information
common for all types of EFMCu ports."
::= { efmCuGroups 1 }
efmCuPAFGroup OBJECT-GROUP
OBJECTS {
efmCuPeerPAFSupported,
efmCuPAFCapacity,
efmCuPeerPAFCapacity,
efmCuPAFAdminState,
efmCuPAFDiscoveryCode,
efmCuPAFRemoteDiscoveryCode,
efmCuNumPMEs
}
STATUS current
DESCRIPTION
"A collection of objects supporting OPTIONAL PME
Aggregation Function (PAF) and PAF discovery in EFMCu ports."
::= { efmCuGroups 2 }
efmCuPAFErrorsGroup OBJECT-GROUP
OBJECTS {
efmCuPAFInErrors,
efmCuPAFInSmallFragments,
efmCuPAFInLargeFragments,
efmCuPAFInBadFragments,
efmCuPAFInLostFragments,
efmCuPAFInLostStarts,
efmCuPAFInLostEnds,
efmCuPAFInOverflows
}
STATUS current
DESCRIPTION
"A collection of objects supporting OPTIONAL error counters
of PAF on EFMCu ports."
::= { efmCuGroups 3 }
efmCuPmeGroup OBJECT-GROUP
OBJECTS {
efmCuPmeAdminProfile,
efmCuPmeOperStatus,
efmCuPmeFltStatus,
efmCuPmeSubTypesSupported,
efmCuPmeAdminSubType,
efmCuPmeOperSubType,
efmCuPAFRemoteDiscoveryCode,
efmCuPmeOperProfile,
efmCuPmeSnrMgn,
efmCuPmePeerSnrMgn,
efmCuPmeLineAtn,
efmCuPmePeerLineAtn,
efmCuPmeEquivalentLength,
efmCuPmeTCCodingErrors,
efmCuPmeTCCrcErrors,
efmCuPmeThreshLineAtn,
efmCuPmeThreshSnrMgn
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
a 2BASE-TL/10PASS-TS PME."
::= { efmCuGroups 4 }
efmCuAlarmConfGroup OBJECT-GROUP
OBJECTS {
efmCuThreshLowRate,
efmCuLowRateCrossingEnable,
efmCuPmeThreshLineAtn,
efmCuPmeLineAtnCrossingEnable,
efmCuPmeThreshSnrMgn,
efmCuPmeSnrMgnCrossingEnable,
efmCuPmeDeviceFaultEnable,
efmCuPmeConfigInitFailEnable,
efmCuPmeProtocolInitFailEnable
}
STATUS current
DESCRIPTION
"A collection of objects supporting configuration of alarm
thresholds and notifications in EFMCu ports."
::= { efmCuGroups 5 }
efmCuNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
efmCuLowRateCrossing,
efmCuPmeLineAtnCrossing,
efmCuPmeSnrMgnCrossing,
efmCuPmeDeviceFault,
efmCuPmeConfigInitFailure,
efmCuPmeProtocolInitFailure
}
STATUS current
DESCRIPTION
"This group supports notifications of significant conditions
associated with EFMCu ports."
::= { efmCuGroups 6 }
efmCuPme2BProfileGroup OBJECT-GROUP
OBJECTS {
efmCuPme2BProfileDescr,
efmCuPme2BRegion,
efmCuPme2BsMode,
efmCuPme2BMinDataRate,
efmCuPme2BMaxDataRate,
efmCuPme2BPower,
efmCuPme2BConstellation,
efmCuPme2BProfileRowStatus,
efmCuPme2BsModeDescr,
efmCuPme2BsModeRowStatus,
efmCuPme2BEquivalentLength,
efmCuPme2BMaxDataRatePam16,
efmCuPme2BMaxDataRatePam32,
efmCuPme2BReachRateRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects that constitute a configuration
profile for configuration of 2BASE-TL ports."
::= { efmCuGroups 7}
efmCuPme10PProfileGroup OBJECT-GROUP
OBJECTS {
efmCuPme10PProfileDescr,
efmCuPme10PBandplanPSDMskProfile,
efmCuPme10PUPBOReferenceProfile,
efmCuPme10PBandNotchProfiles,
efmCuPme10PPayloadDRateProfile,
efmCuPme10PPayloadURateProfile,
efmCuPme10PProfileRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects that constitute a configuration
profile for configuration of 10PASS-TS ports."
::= { efmCuGroups 8 }
efmCuPme10PStatusGroup OBJECT-GROUP
OBJECTS {
efmCuPme10PFECCorrectedBlocks,
efmCuPme10PFECUncorrectedBlocks
}
STATUS current
DESCRIPTION
"A collection of objects providing status information
specific to 10PASS-TS PMEs."
::= { efmCuGroups 9 }
-- Compliance Statements
efmCuCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for 2BASE-TL/10PASS-TS interfaces.
Compliance with the following external compliance statements
is REQUIRED:
MIB Module Compliance Statement
---------- --------------------
IF-MIB ifCompliance3
EtherLike-MIB dot3Compliance2
MAU-MIB mauModIfCompl3
Compliance with the following external compliance statements
is OPTIONAL for implementations supporting PME Aggregation
Function (PAF) with flexible cross-connect between the PCS
and PME ports:Okay so the compliance bit wraps up like this 💅
MIB Module Compliance Statement
---------- --------------------
IF-INVERTED-STACK-MIB ifInvCompliance
IF-CAP-STACK-MIB ifCapStackCompliance"
MODULE -- this module
MANDATORY-GROUPS {
efmCuBasicGroup,
efmCuPmeGroup,
efmCuAlarmConfGroup,
efmCuNotificationGroup
}
GROUP efmCuPme2BProfileGroup
DESCRIPTION
"Support for this group is only required for implementations
supporting 2BASE-TL PHY."
GROUP efmCuPme10PProfileGroup
DESCRIPTION
"Support for this group is only required for implementations
supporting 10PASS-TS PHY."
GROUP efmCuPAFGroup
DESCRIPTION
"Support for this group is only required for
implementations supporting PME Aggregation Function (PAF)."
GROUP efmCuPAFErrorsGroup
DESCRIPTION
"Support for this group is OPTIONAL for implementations
supporting PME Aggregation Function (PAF)."
GROUP efmCuPme10PStatusGroup
DESCRIPTION
"Support for this group is OPTIONAL for implementations
supporting 10PASS-TS PHY."
OBJECT efmCuPmeSubTypesSupported
SYNTAX BITS {
ieee2BaseTLO(0),
ieee2BaseTLR(1),
ieee10PassTSO(2),
ieee10PassTSR(3)
}
DESCRIPTION
"Support for all subtypes is not required. However, at
least one value SHALL be supported."
OBJECT efmCuPmeAdminSubType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required (needed only for PMEs
supporting more than a single subtype, e.g.,
ieee2BaseTLO and ieee2BaseTLR or ieee10PassTSO and
ieee10PassTSR)."
OBJECT efmCuTargetSnrMgn
MIN-ACCESS read-only
DESCRIPTION
"Write access is OPTIONAL. For PHYs without write access,
the target SNR margin SHALL be fixed at 5dB for 2BASE-TL
and 6dB for 10PASS-TS."
OBJECT efmCuAdaptiveSpectra
MIN-ACCESS read-only
DESCRIPTION
"Write access is OPTIONAL. For PHYs without write access,
the default value SHOULD be false."
::= { efmCuCompliances 1 }
END7. Security Considerations ✨
Okay bestie, this part is serious 😭 The EFM-CU-MIB module has a bunch of managed objects with a MAX-ACCESS of read-write or read-create, which means they can be changed. Most of them can only be written while the link is Down. Writing to them can be seriously disruptive to the network, for example:
- Changing
efmCuPmeAdminSubTypemay lead to a potential locking of the link, since peer PMEs of the same subtype cannot exchange handshake messages. 🔒 - Changing
efmCuPAFAdminStateto enabled may lead to a potential locking of the link, if the peer PHY does not support PAF. - Changing
efmCuPAFDiscoveryCode, before the discovery operation, may lead to a wrongful discovery, for example, when two-Oports are connected to the same multi-PME-Rport and both-Oports have the same Discovery register value. - Changing PCS or PME configuration parameters (e.g., profile of a PCS or PME via
efmCuAdminProfileorefmCuPmeAdminProfile) 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.
So the user of the EFM-CU-MIB module has to be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. 💀
Honestly, this is the part where you protect your network like it's your phone passcode. SET operations without protection can wreck things.
The readable objects in the EFM-CU-MIB module (anything with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments, because together they give information about the performance of network interfaces and can reveal some aspects of their configuration. Especially 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 on an EFMCu transmission just by "listening" to the cross-talk from the EFMCu pairs, especially if the parameters of the EFMCu link in question are known. 👂
In those environments it's important to control GET and NOTIFY access to these objects too, and possibly even 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), there is still no control over 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 [RFC3410], 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 make sure the SNMP entity giving access to an instance of these MIB modules is properly configured, so access to the objects is only given to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 👑
8. IANA Considerations
Object identifiers for the efmCuMIB MODULE-IDENTITY and ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 🌸
9. Acknowledgments
This document was produced by the [HUBMIB] 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)
10. References
10.1. Normative References
- [802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2005, December 2005.
- [802.3ah] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks", IEEE Std 802.3ah-2004, September 2004.
- [G.991.2] ITU-T, "Single-pair High-speed Digital Subscriber Line (SHDSL) transceivers", ITU-T Recommendation G.991.2, December 2003,
<http://www.itu.int/rec/T-REC-G.991.2/en>. - [G.993.1] ITU-T, "Very High speed Digital Subscriber Line transceivers", ITU-T Recommendation G.993.1, June 2004,
<http://www.itu.int/rec/T-REC-G.993.1/en>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
- [RFC4836] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 4836, April 2007.
- [T1.424] ANSI, "Interface Between Networks and Customer Installation Very-high-bit-rate Digital Subscriber Lines (VDSL) Metallic Interface (DMT Based)", American National Standard T1.424-2004, June 2004.
- [TS 101 270-1] ETSI, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements", Technical Specification TS 101 270-1, October 2005.
10.2. Informative References ✨
Okay bestie, these are the informative ones 📚 They give you background and context, but they aren't normative, so you don't have to follow them to get the spec right 🫶
[ANFP]Network Interoperability Consultative Committee (NICC), "Specification of the Access Network Frequency Plan (ANFP) applicable to transmission systems used on the BT Access Network", NICC Document ND1602:2005/08, August 2005.[HUBMIB]IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", <http://www.ietf.org/html.charters/OLD/hubmib-charter.html>.[IANAifType-MIB]Internet Assigned Numbers Authority (IANA), "IANAifType Textual Convention definition", <http://www.iana.org/assignments/ianaiftype-mib>.[RFC3410]Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.[RFC4070]Dodge, M. and B. Ray, "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding", RFC 4070, May 2005.[RFC4181]Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.[RFC4319]Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", RFC 4319, December 2005.[RFC4837]Khermosh, L., "Managed Objects of Ethernet Passive Optical Networks (EPON)", RFC 4837, July 2007.[RFC4878]Squire, M., "Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces", RFC 4878, June 2007.
Author's Address 🎀
The author is Edward Beili at Actelis Networks, and here's where to find him:
Edward Beili
Actelis Networks
Bazel 25
Petach-Tikva
Israel
Phone: +972-3-924-3491
EMail: edward.beili@actelis.comFull Copyright Statement 💜
Copyright (C) The IETF Trust (2007).
This doc is covered by the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 says, the authors keep all of their rights 💅
The document and everything in it come "AS IS", and here's the legal fine print you need to see:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🦋
The IETF doesn't take a side on whether any IPR or other rights that someone might claim over this technology are valid or how far they reach. It also doesn't say it has looked into whether any such rights exist 🙈 If you want the details on how rights work for RFC documents, check BCP 78 and BCP 79.
IPR disclosures that were sent to the IETF Secretariat, along with any promised licenses, and any results from trying to get a general license for implementers or users, are all available at the IETF's online IPR repository: http://www.ietf.org/ipr.
The IETF also asks anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them. Send that info to ietf-ipr@ietf.org 🫶
📦 where this page comes from
- ietf: rfc5066 2007-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms