RFC 7460
Monitoring and Control MIB for Power and Energy
RFC 7460: Monitoring and Control MIB for Power and Energy ⚡
okay bestie, this one is RFC 7460 💖, a Standards Track doc from the IETF, published in March 2015 📅. It's ISSN: 2070-1721 and it was written by M. Chandramouli, B. Claise, B. Schoening, J. Quittek, and T. Dietz 🫶. Chandramouli and Claise are at Cisco Systems, Inc., Schoening is an Independent Consultant, and Quittek and Dietz are at NEC Europe, Ltd. 🌸
Abstract
so the whole point of this doc is that it defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices ⚡🔋
Status of This Memo
this is an Internet Standards Track document 💅
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community ✨. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. if you want more on Internet Standards, check out Section 2 of RFC 5741 📚.
info about the current status of this doc, any errata, and how to send feedback is over at http://www.rfc-editor.org/info/rfc7460 🦋
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ©️🎀
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date it was published. please actually read these, bestie, because they explain your rights and restrictions for this doc 🙈. any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. The Internet-Standard Management Framework ......................3
3. Use Cases .......................................................4
4. Terminology .....................................................4
5. Architecture Concepts Applied to the MIB Modules ................5
5.1. Energy Object Tables .......................................5
5.1.1. ENERGY-OBJECT-MIB ...................................5
5.1.2. POWER-ATTRIBUTES-MIB ................................7
5.1.3. UML Diagram .........................................9
5.2. Energy Object Identity ....................................12
5.3. Power State ...............................................12
5.3.1. Power State Set ....................................13
5.4. Energy Object Usage Information ...........................13
5.5. Optional Power Usage Attributes ...........................14
5.6. Optional Energy Measurement ...............................14
5.7. Fault Management ..........................................18
6. Discovery ......................................................18
7. Link with the Other IETF MIBs ..................................19
7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB ........19
7.2. Link with the ENTITY-STATE MIB ............................20
7.3. Link with the POWER-OVER-ETHERNET MIB .....................21
7.4. Link with the UPS MIB .....................................21
7.5. Link with the LLDP and LLDP-MED MIBs ......................22
8. Structure of the MIB ...........................................23
9. MIB Definitions ................................................24
9.1. The IANAPowerStateSet-MIB Module ..........................24
9.2. The ENERGY-OBJECT-MIB MIB Module ..........................27
9.3. The POWER-ATTRIBUTES-MIB MIB Module .......................50
10. Security Considerations .......................................63
11. IANA Considerations ...........................................64
11.1. IANAPowerStateSet-MIB Module .............................65
12. References ....................................................65
12.1. Normative References .....................................65
12.2. Informative References ...................................66
Acknowledgments ...................................................68
Contributors ......................................................68
Authors' Addresses ................................................691. Introduction ✨
okay so this doc defines a subset of the Management Information Base (MIB) for use in energy management of devices within or connected to communication networks 🔌. the MIB modules here are designed to give us a model for energy management, and that covers monitoring Power State and energy consumption of networked elements 🧚. this MIB takes the "Energy Management Framework" [RFC7326] into account, and that framework is itself based on the "Requirements for Energy Management" [RFC6988] 💅.
energy management can be applied to devices in communication networks, and the target devices here include (but are not limited to) routers, switches, Power over Ethernet (PoE) endpoints, protocol gateways for building management systems, intelligent meters, home energy gateways, hosts and servers, sensor proxies, etc. 🌈 the target devices and use cases for Energy Management are covered in Energy Management Applicability Statement [EMAN-AS] 📚.
where it makes sense, device monitoring reaches the individual components of the device and any attached dependent devices 🎀. for example, a device can have components that are independent from a Power State point of view, like line cards, processor cards, and hard drives. a device can also have dependent attached devices, like a switch with PoE endpoints or a power distribution unit with attached endpoints 🦋.
1.1. Conventions Used in This Document 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥. these are the official requirement words, so read them carefully bestie 🙈.
2. The Internet-Standard Management Framework 🍓
for a detailed overview of the docs that describe the current Internet-Standard Management Framework, go look at 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 usually accessed through the Simple Network Management Protocol (SNMP) 🛰️. objects in the MIB are defined with the mechanisms in the Structure of Management Information (SMI) 🧩. this memo specifies MIB modules that are compliant to SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] ✨.
3. Use Cases 🌸
requirements for power and energy monitoring of networking devices are specified in [RFC6988]. those requirements cover devices typically found in communications networks, like switches, routers, and various connected endpoints 🔌. for a power monitoring architecture to be useful, it should also apply to facility meters, power distribution units, gateway proxies for commercial building control, home automation devices, and devices that interface with the utility and/or smart grid ⚡. so the scope of the MIB modules in this document is broader than what [RFC6988] specifies 👑. several use cases for Energy Management have been identified in the "Energy Management (EMAN) Applicability Statement" [EMAN-AS] 💖.
4. Terminology 🧚
please refer to [RFC7326] for the definitions of the following terminology used in this document 📚:
Energy Management
Energy Management System (EnMS)
Energy Monitoring
Energy Control
electrical equipment
non-electrical equipment (mechanical equipment)
device
component
power inlet
power outlet
energy
power
demand
provide energy
receive energy
meter (energy meter)
battery
Power Interface
Nameplate Power
Power Attributes
Power Quality
Power State
Power State Set5. Architecture Concepts Applied to the MIB Modules 🦋
this section describes the concepts from the Energy Management Framework [RFC7326] that relate to power usage, with specific info about the MIB module in this document 💅. this subsection maps concepts developed in the Energy Management Framework [RFC7326] 🌈.
the Energy Monitoring MIB has two independent MIB modules: ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB 🔋. the first, ENERGY-OBJECT-MIB, is focused on measuring power and energy ⚡. the second, POWER-ATTRIBUTES-MIB, is focused on power quality measurements for Energy Objects ✨.
devices and their sub-components can be modeled using the containment tree of the ENTITY-MIB [RFC6933] 🎀.
5.1. Energy Object Tables 💖
5.1.1. ENERGY-OBJECT-MIB ✨
okay so the ENERGY-OBJECT-MIB module is made of five tables 💅 let's go through them!
The first one is the eoMeterCapabilitiesTable 🎀. It tells you what instrumentation each Energy Object has. Each entry says which of the other tables from ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are available for that Energy Object. It's indexed by entPhysicalIndex [RFC6933].
The second is the eoPowerTable 🔥. It reports how much power each Energy Object is consuming, plus the units, sign, measurement accuracy, and related objects. It's indexed by entPhysicalIndex.
The third is the eoPowerStateTable 🦋. For each Energy Object, it shows info and stats about the Power States it supports. It's indexed by entPhysicalIndex and eoPowerStateIndex, so it's giving two-key energy 💜.
The fourth is the eoEnergyParametersTable ⚙️. The entries here configure the parameters for energy and demand measurement collection. It's indexed by eoEnergyParametersIndex.
The fifth is the eoEnergyTable 📖. This one holds a log of the energy and demand info. It's also indexed by eoEnergyParametersIndex, so it's lowkey the diary of the whole module 🧚.
Okay, now the tree 🌳. It's a "smidump-style" presentation of the MIB modules in this document. The three symbols are a compressed way of showing each object's MAX-ACCESS clause, and they map like this:
"not-accessible" -> "---"
"accessible-for-notify" -> "--n"
"read-only" -> "r-n"
"read-write" -> "rwn"Here's the whole tree, slay 💖:
eoMeterCapabilitiesTable(1)
|
+---eoMeterCapabilitiesEntry(1)[entPhysicalIndex]
| |
| +---r-n BITS eoMeterCapability
|
eoPowerTable(2)
|
+---eoPowerEntry(1) [entPhysicalIndex]
| |
| +---r-n Integer32 eoPower(1)
| +-- r-n Unsigned32 eoPowerNamePlate(2)
| +-- r-n UnitMultiplier eoPowerUnitMultiplier(3)
| +-- r-n Integer32 eoPowerAccuracy(4)
| +-- r-n INTEGER eoPowerMeasurementCaliber(5)
| +-- r-n INTEGER eoPowerCurrentType(6)
| +-- r-n TruthValue eoPowerMeasurementLocal(7)
| +-- rwn PowerStateSet eoPowerAdminState(8)
| +-- r-n PowerStateSet eoPowerOperState(9)
| +-- r-n OwnerString eoPowerStateEnterReason(10)
|
|
|
+---eoPowerStateTable(3)
|
| +--eoPowerStateEntry(1)
| | [entPhysicalIndex, eoPowerStateIndex]
| |
| +-- --n PowerStateSet eoPowerStateIndex(1)
| +-- r-n Integer32 eoPowerStateMaxPower(2)
| +-- r-n UnitMultiplier
| eoPowerStatePowerUnitMultiplier(3)
| +-- r-n TimeTicks eoPowerStateTotalTime(4)
| +-- r-n Counter32 eoPowerStateEnterCount(5)
|
+eoEnergyParametersTable(4)
|
+---eoEnergyParametersEntry(1) [eoEnergyParametersIndex]
|
| +-- --n PhysicalIndex eoEnergyObjectIndex(1)
| + r-n Integer32 eoEnergyParametersIndex(2)
| +-- rwn TimeInterval eoEnergyParametersIntervalLength(3)
| +-- rwn Unsigned32 eoEnergyParametersIntervalNumber(4)
| +-- rwn INTEGER eoEnergyParametersIntervalMode(5)
| +-- rwn TimeInterval eoEnergyParametersIntervalWindow(6)
| +-- rwn Unsigned32 eoEnergyParametersSampleRate(7)
| +-- rwn StorageType eoEnergyParametersStorageType(8)
| +-- rwn RowStatus eoEnergyParametersStatus(9)
|
+eoEnergyTable(5)
|
+---eoEnergyEntry(1)
| [eoEnergyParametersIndex,eoEnergyCollectionStartTime]
|
| +-- r-n TimeTicks eoEnergyCollectionStartTime(1)
| +-- r-n Unsigned32 eoEnergyConsumed(2)
| +-- r-n Unsigned32 eoEnergyProvided(3)
| +-- r-n Unsigned32 eoEnergyStored(4)
| +-- r-n UnitMultiplier eoEnergyUnitMultiplier(5)
| +-- r-n Integer32 eoEnergyAccuracy(6)
| +-- r-n Unsigned32 eoEnergyMaxConsumed(7)
| +-- r-n Unsigned32 eoEnergyMaxProduced(8)
| +-- r-n TimeTicks eoEnergyDiscontinuityTime(9)5.1.2. POWER-ATTRIBUTES-MIB 🌈
The POWER-ATTRIBUTES-MIB module has three tables ⭐.
The first is the eoACPwrAttributesTable 🔌. It shows the power quality available for each Energy Object. It's indexed by entPhysicalIndex [RFC6933].
The second is the eoACPwrAttributesDelPhaseTable 🌸. Its entries are meant to configure the parameters of energy and demand measurement collection, and it's indexed by eoEnergyParametersIndex. ngl this one's a bit of a plot twist 🙈.
The third is the eoACPwrAttributesWyePhaseTable 🍓. For each Energy Object, it reports info and stats about the supported Power States. It's indexed by entPhysicalIndex and eoPowerStateIndex. yes, it says eoPowerStateTable there, and yes, that's how the original reads 💀.
Here's the tree for these tables, bestie 🫶:
eoACPwrAttributesTable(1)
|
+---eoACPwrAttributesEntry(1) [ entPhysicalIndex]
| |
| +---r-n INTEGER eoACPwrAttributesConfiguration(1)
| +-- r-n Integer32 eoACPwrAttributesAvgVoltage(2)
| +-- r-n Unsigned32 eoACPwrAttributesAvgCurrent(3)
| +-- r-n Integer32 eoACPwrAttributesFrequency(4)
| +-- r-n UnitMultiplier
| eoACPwrAttributesPowerUnitMultiplier(5)
| +-- r-n Integer32 eoACPwrAttributesPowerAccuracy(6)
| +-- r-n Integer32
| eoACPwrAttributesTotalActivePower(7)
| +-- r-n Integer32
| eoACPwrAttributesTotalReactivePower(8)
| +-- r-n Integer32
| eoACPwrAttributesTotalApparentPower(9)
| +-- r-n Integer32
| eoACPwrAttributesTotalPowerFactor(10)
| +-- r-n Integer32 eoACPwrAttributesThdCurrent(11)
| +-- r-n Integer32 eoACPwrAttributesThdVoltage(12)
|
+eoACPwrAttributesDelPhaseTable(2)
|
+-- eoACPwrAttributesDelPhaseEntry(1)
| | [entPhysicalIndex, eoACPwrAttributesDelPhaseIndex]
| |
| +-- r-n Integer32
| | eoACPwrAttributesDelPhaseIndex(1)
| +-- r-n Integer32
| | eoACPwrAttributesDelPhaseToNextPhaseVoltage(2)
| +-- r-n Integer32
| | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(3)
| |
+eoACPwrAttributesWyePhaseTable(3)
|
+-- eoACPwrAttributesWyePhaseEntry(1)
| | [entPhysicalIndex, eoACPwrAttributesWyePhaseIndex]
| |
| +-- r-n Integer32
| | eoACPwrAttributesWyePhaseIndex(1)
| +-- r-n Integer32
| | eoACPwrAttributesWyePhaseToNeutralVoltage(2)
| +-- r-n Integer32
| | eoACPwrAttributesWyeCurrent(3)
| +-- r-n Integer32
| | eoACPwrAttributesWyeActivePower(4)
| +-- r-n Integer32
| | eoACPwrAttributesWyeReactivePower(5)
| +-- r-n Integer32
| | eoACPwrAttributesWyeApparentPower(6)
| +-- r-n Integer32
| | eoACPwrAttributesWyePowerFactor(7)
| +-- r-n Integer32
| | eoACPwrAttributesWyeThdCurrent(9)
| +-- r-n Integer32
| | eoACPwrAttributesWyeThdPhaseToNeutralVoltage(10)5.1.3. UML Diagram ✨
okay so bestie, this is the UML diagram 🦋 It's a visual map of every MIB object in the two modules, ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB, so you can literally see how everything connects 💖
+-----------------------+
| Meter Capabilities |
| --------------------- |
| eoMeterCapability |
+-----------------------+
+-----------------------+
|---> | Energy Object ID (*) |
| | --------------------- |
| | entPhysicalIndex |
| | entPhysicalClass |
| | entPhysicalName |
| | entPhysicalUUID |
| +-----------------------+
|
| +---------------------------+
|---- |_ Power Table |
| | ------------------------- |
| | eoPower |
| | eoPowerNamePlate |
| | eoPowerUnitMultiplier |
| | eoPowerAccuracy |
| | eoPowerMeasurementCaliber |
| | eoPowerCurrentType |
| | eoPowerMeasurementLocal |
| | eoPowerAdminState |
| | eoPowerOperState |
| | eoPowerStateEnterReason |
| +---------------------------+
| +---------------------------------+
|---- |_Energy Object State Statistics |
| |-------------------------------- |
| | eoPowerStateIndex |
| | eoPowerStateMaxPower |
| | eoPowerStatePowerUnitMultiplier |
| | eoPowerStateTotalTime |
| | eoPowerStateEnterCount |
| +---------------------------------+
|
| +----------------------------------+
|---- | Energy ParametersTable |
| | -------------------------------- |
| | eoEnergyObjectIndex |
| | eoEnergyParametersIndex |
| | eoEnergyParametersIntervalLength |
| | eoEnergyParametersIntervalNumber |
| | eoEnergyParametersIntervalMode |
| | eoEnergyParametersIntervalWindow |
| | eoEnergyParametersSampleRate |
| | eoEnergyParametersStorageType |
| | eoEnergyParametersStatus |
| +----------------------------------+
|
| +----------------------------------+
|---- | Energy Table |
| -------------------------------- |
| eoEnergyCollectionStartTime |
| eoEnergyConsumed |
| eoEnergyProvided |
| eoEnergyStored |
| eoEnergyUnitMultiplier |
| eoEnergyAccuracy |
| eoEnergyMaxConsumed |
| eoEnergyMaxProduced |
| eoDiscontinuityTime |
+----------------------------------+
Figure 1: UML Diagram for energyObjectMibFigure 1: UML Diagram for energyObjectMib 🌈
(*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB 💅
+-----------------------+
|---> | Energy Object ID (*) |
| | --------------------- |
| | entPhysicalIndex |
| | entPhysicalName |
| | entPhysicalUUID |
| +-----------------------+
| +--------------------------------------+
|---- | Power Attributes |
| | ------------------------------------ |
| | eoACPwrAttributesConfiguration |
| | eoACPwrAttributesAvgVoltage |
| | eoACPwrAttributesAvgCurrent |
| | eoACPwrAttributesFrequency |
| | eoACPwrAttributesPowerUnitMultiplier |
| | eoACPwrAttributesPowerAccuracy |
| | eoACPwrAttributesTotalActivePower |
| | eoACPwrAttributesTotalReactivePower |
| | eoACPwrAttributesTotalApparentPower |
| | eoACPwrAttributesTotalPowerFactor |
| | eoACPwrAttributesThdCurrent |
| | eoACPwrAttributesThdVoltage |
| +--------------------------------------+
| +------------------------------------------------+
|---- | AC Input DEL Configuration |
| | ---------------------------------------------- |
| | eoACPwrAttributesDelPhaseIndex |
| | eoACPwrAttributesDelPhaseToNextPhaseVoltage |
| | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage |
| +------------------------------------------------+
|
| +----------------------------------------------+
|---- | AC Input WYE Configuration |
| -------------------------------------------- |
| eoACPwrAttributesWyePhaseIndex |
| eoACPwrAttributesWyePhaseToNeutralVoltage |
| eoACPwrAttributesWyeCurrent |
| eoACPwrAttributesWyeActivePower |
| eoACPwrAttributesWyeReactivePower |
| eoACPwrAttributesWyeApparentPower |
| eoACPwrAttributesWyePowerFactor |
| eoACPwrAttributesWyeThdCurrent |
| eoACPwrAttributesWyeThdPhaseToNeutralVoltage |
+----------------------------------------------+
Figure 2: UML Diagram for the POWER-ATTRIBUTES-MIB
(*) Compliance with the ENERGY-OBJECT-CONTEXT-MIBFigure 2: UML Diagram for the POWER-ATTRIBUTES-MIB 🎀
(*) Compliance with the ENERGY-OBJECT-CONTEXT-MIB 💜
5.2. Energy Object Identity 🌸
so the Energy Object identity info lives in the primary table of the ENERGY-OBJECT-CONTEXT-MIB module [RFC7461], which is the eoTable 📋 That's where you find the Energy Object context, like its domain, role description, and importance. The ENERGY-OBJECT-CONTEXT-MIB module also spells out how Energy Objects relate to each other. There are several possible relationships, including meteredBy, metering, poweredBy, powering, aggregatedBy, and aggregating, and they're defined in the IANA-ENERGY-RELATION-MIB module [RFC7461] ⭐
5.3. Power State 🔋
so an Energy Object can have energy-conservation modes called "Power States" 🌙 There can be a bunch of in-between energy-saving modes between fully ON and fully OFF.
The universal power management states of an Energy Object live in the eoPowerState MIB object. The state it's actually in is the eoPowerOperState MIB object, and the eoPowerAdminState MIB object holds the Power State that was requested for it 🎯 If those two values don't match, that means the Energy Object is busy switching from eoPowerAdminState over to eoPowerOperState, and once it's done, it updates eoPowerOperState. The reason for a Power State change gets reported in eoPowerStateEnterReason. For that one, management stations and Energy Objects should support any owner string format the organization's local policy calls for. It's suggested that this name include at least the reason for the change, plus one or more of these: IP address, management station name, network manager's name, location, or phone number 📞
The eoPowerOperState, eoPowerAdminState, and eoPowerStateEnterReason objects are all in the eoPowerTable 🗂️
eoPowerStateTable lists the maximum power usage in watts for every single supported Power State of each Power State Set the Energy Object supports 💡 It also gives you extra stats, like eoPowerStateEnterCount (how many times an entity has visited a particular Power State) and eoPowerStateTotalTime (the total time spent in a particular Power State of an Energy Object) ⏱️
5.3.1. Power State Set 🧩
there are a bunch of standards and implementations of Power State Sets, and an Energy Object can support one or several of them at the same time 🫶
right now there are three Power State Sets defined:
IEEE1621(256) - [IEEE1621]
DMTF(512) - [DMTF]
EMAN(768) - [RFC7326]The Power State Sets are listed in [RFC7326] along with each Power State inside each set ✨ They're specified by the PowerStateSet Textual Convention (TC), which is an IANA-maintained MIB module. The first version of this MIB module is specified in this document 🌈
5.4. Energy Object Usage Information ⚡
for an Energy Object, power usage gets reported using eoPower 🔌 The magnitude is based on the eoPowerUnitMultiplier MIB variable, which uses the UnitMultiplier TC. Power measurement magnitude should conform to the unit multiplier definitions for SI units in IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] (SI meaning the International System of Units) 🧮 Measured values come out in SI units as BaseValue * 10 raised to the power of the unit multiplier.
For example, if an Energy Object's current power usage is 3, it could be 3 W, 3 mW, 3 kW, or 3 MW, depending on eoPowerUnitMultiplier 😭 Other measurements in these two MIB modules use the same mechanism too, including eoPowerStatePowerUnitMultiplier, eoEnergyUnitMultiplier, and oACPwrAttributesPowerUnitMultiplier.
It's also really useful to know how an eoPower measurement was obtained 🕵️♀️ A Network Management System (NMS) can use that to account for the accuracy and nature of readings across different implementations. eoPowerMeasurementLocal says whether the measurements were taken at the device itself or from a remote source. eoPowerMeasurementCaliber describes the method used to measure the power, and it can tell actual values apart from estimated ones. Some devices in the network might not be able to measure or report power consumption at all 💀 For those, eoPowerMeasurementCaliber shall report that the measurement mechanism is "unavailable", and the eoPower measurement shall be "0".
The nameplate power rating of an Energy Object is in the eoPowerNameplate MIB object 🏷️
5.5. Optional Power Usage Attributes 🎀
the optional POWER-ATTRIBUTES-MIB module can be implemented to describe power attributes usage measurement in more detail 🧁 It's aligned with the IEC 61850 7-2 standard for describing alternating current (AC) measurements.
The POWER-ATTRIBUTES-MIB module has a primary table, eoACPwrAttributesTable, which defines power attributes measurements for supported entPhysicalIndex entities. It's a sparse extension of the eoPowerTable, with entPhysicalIndex as the primary index 🗝️ This table holds info like the configuration (single phase, DEL 3 phases, or WYE 3 phases), frequency, power accuracy, total active, reactive, and apparent power, amperage, and voltage.
For three-phase power, there's an extra table with power attributes measurements per phase. It's double indexed by entPhysicalIndex and a phase index 👯 This table describes attributes specific to either WYE or DEL configurations.
In a DEL configuration, eoACPwrAttributesDelPhaseTable describes the phase-to-phase power attributes measurements, i.e., voltage. In a DEL configuration, the current is equal in all three phases ⚡
In a WYE configuration, eoACPwrAttributesWyePhaseTable describes the phase-to-neutral power attributes measurements, i.e., voltage, current, active, reactive, and apparent power, and power factor 💖
5.6. Optional Energy Measurement ⚡
Okay so bestie, energy and demand numbers only mean something when they come from actual measurement hardware 🔌. If eoPowerMeasurementCaliber is unavailable, unknown, estimated, or presumed, then the energy and demand values are not useful 💀.
Two tables handle energy measurement for an Energy Object: eoEnergyTable and eoEnergyParametersTable 🧚. Energy and demand info can both be represented in eoEnergyTable, and demand information can be represented there too.
The eoEnergyParametersTable holds the settings that define the measurement:
- eoEnergyParametersIndex, the index for the Energy Object 🔑
- eoEnergyObjectIndex, which is linked to the entPhysicalIndex of the Energy Object
- eoEnergyParametersIntervalLength, the duration of the measurement intervals in seconds
- eoEnergyParametersIntervalNumber, the number of successive intervals to be stored in eoEnergyTable
- eoEnergyParametersIntervalMode, the type of measurement technique
- eoEnergyParametersSampleRate, the sample rate used to calculate the average
Judicious choice of the sampling rate will ensure accurate measurement while not imposing an excessive polling burden 🫶.
There are three eoEnergyParametersIntervalMode types for energy measurement collection: period, sliding, and total 🎀. The three modes are based on IEC standard 61850-7-4 [IEC.61850-7-4]. Multiple eoEnergyParametersIntervalMode types MAY be configured simultaneously. For a given Energy Object, multiple modes (periodic, total, sliding window) of energy measurement collection can be configured with eoEnergyParametersIndex. Simultaneous measurement in multiple modes for a given Energy Object does depend on the Energy Object's capability, though 🤓.
Here's how to read the three figures:
- The horizontal axis is the current time. The symbol
<--- L --->stands for eoEnergyParametersIntervalLength, and S1, S2, S3, S4 are eoEnergyCollectionStartTime values (for eoEnergyParametersIntervalNumber intervals). - The vertical axis is the time interval of sampling. The value of eoEnergyConsumed can be obtained at the end of the sampling period, and
===========denotes the duration of the sampling period 📊.
| | | =========== |
|============ | | |
| | | |
| |============ | |
| | | |
| <--- L ---> | <--- L ---> | <--- L ---> |
| | | |
S1 S2 S3 S4
Figure 3: Period eoEnergyParametersIntervalModeA eoEnergyParametersIntervalMode type of period specifies non-overlapping periodic measurements 📅. That means the next eoEnergyCollectionStartTime is equal to the previous eoEnergyCollectionStartTime plus eoEnergyParametersIntervalLength, so S2=S1+L; S3=S2+L, ... ✨.
|============ |
| |
| <--- L ---> |
| |
| |============ |
| | |
| | <--- L ---> |
| | |
| | |============ |
| | | |
| | | <--- L ---> |
| | | |
| | | |============ |
| | | | |
| | | | <--- L ---> |
S1 | | | |
| | | |
| | | |
S2 | | |
| | |
| | |
S3 | |
| |
| |
S4
Figure 4: Sliding eoEnergyParametersIntervalModeA eoEnergyParametersIntervalMode type of sliding specifies overlapping periodic measurements 🌀.
| |
|========================= |
| |
| |
| |
| <--- Total length ---> |
| |
S1
Figure 5: Total eoEnergyParametersIntervalModeA eoEnergyParametersIntervalMode type of total specifies a continuous measurement since the last reset 🔄. The value of eoEnergyParametersIntervalNumber should be (1) one, and eoEnergyParametersIntervalLength is ignored.
The eoEnergyParametersStatus is used to start and stop energy usage logging 🚦. The status of this variable is "active" when all the objects in eoEnergyParametersTable are appropriate, and that in turn indicates whether or not eoEnergyTable entries exist. Last but not least, the eoEnergyParametersStorageType variable indicates the storage type for this row, meaning whether the persistence is maintained across a device reload 💾.
The eoEnergyTable is where the measurements live 🍓. It holds eoEnergyConsumed, eoEnergyProvided, and eoEnergyStored, plus the unit scale of measured energy via eoEnergyUnitMultiplier, the percentage accuracy via eoEnergyAccuracy, and the maximum observed energy within a window in eoEnergyMaxConsumed, eoEnergyMaxProduced, and eoEnergyDiscontinuityTime.
Total energy consumed by an Energy Object can suffer from interruptions in the continuous measurement of energy consumption 😭. To show those interruptions, the object eoEnergyDiscontinuityTime is provided, which indicates the time of the last interruption of total energy measurement. eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418] when the device was reset.
Here's the example that puts it all together 🧁. First, to estimate energy, you need a time interval to sample energy. eoEnergyParametersIntervalLength can be set to "900 seconds" (15 minutes), and the number of consecutive intervals over which the maximum energy is calculated (eoEnergyParametersIntervalNumber) can be "10". The sampling rate internal to the Energy Object for measuring power usage (eoEnergyParametersSampleRate) can be "1000 milliseconds", as set by the Energy Object as a reasonable value. Then eoEnergyParametersStatus is set to active, which tells the Energy Object to start monitoring usage per the eoEnergyTable 🫧.
The indices for eoEnergyTable are eoEnergyParametersIndex, which identifies the setting for the energy measurement collection of the Energy Object, and eoEnergyCollectionStartTime, which denotes the start time of the energy measurement interval based on sysUpTime [RFC3418] 🕰️. The value of eoEnergyComsumed is the measured energy consumption over the time interval specified (eoEnergyParametersIntervalLength), based on the Energy Object's internal sampling rate (eoEnergyParametersSampleRate). When choosing values for eoEnergyParametersIntervalLength and eoEnergyParametersSampleRate, it is recommended to consider both the network element resources adequate to process and store the sample values and the mechanism used to calculate eoEnergyConsumed 🧠. The units are derived from eoEnergyUnitMultiplier. For example, if eoEnergyConsumed is "100" with eoEnergyUnitMultiplier equal to 0, the measured energy consumption of the Energy Object is 100 watt-hours ⚡. The eoEnergyMaxConsumed is the maximum energy observed, which can be "150 watt-hours" 💪.
The eoEnergyTable has a buffer that retains a certain number of intervals, as defined by eoEnergyParametersIntervalNumber. If the default value of "10" is kept, the eoEnergyTable contains 10 energy measurements, including the maximum 📚.
Here's a quick look at how the maximum energy gets calculated 👀. The first observed energy measurement is taken as the initial maximum. With each subsequent measurement, the maximum energy may be updated based on numerical comparison. The maximum value is retained for as long as measurements are taking place. Based on periodic polling of this table, an NMS could compute the maximum over a longer period, e.g., a month, 3 months, or a year 📈.
5.7. Fault Management 🚨
[RFC6988] specifies requirements about Power States, such as "the current Power State", "the time of the last state change", "the total time spent in each state", "the number of transitions to each state", and so on 🔋. Some of these requirements are fulfilled explicitly by MIB objects such as eoPowerOperState, eoPowerStateTotalTime, and eoPowerStateEnterCount. The rest are met via the SNMP NOTIFICATION mechanism. The eoPowerStateChange SNMP notification is generated when the value of ePowerStateIndex, eoPowerOperState, or eoPowerAdminState has changed 🔔.
6. Discovery 🔍
It is probable that most Energy Objects will require the implementation of the ENERGY-OBJECT-CONTEXT-MIB [RFC7461] as a prerequisite for this MIB module 💅. In that case, the eoPowerTable of the EMAN-ENERGY-OBJECT-MIB is cross-referenced with the eoTable of ENERGY-OBJECT-CONTEXT-MIB via entPhysicalIndex. Every Energy Object MUST implement entPhysicalIndex, entPhysicalClass, entPhysicalName, and entPhysicalUUID from the ENTITY-MIB [RFC6933]. entPhysicalIndex is the primary index for the Energy Object, and it characterizes the Energy Object in the ENERGY-OBJECT-MIB and the POWER-ATTRIBUTES-MIB MIB modules (this document) 🦋.
The NMS must first poll the ENERGY-OBJECT-CONTEXT-MIB MIB module [RFC7461], if it's available, to discover all the Energy Objects and the relationships between them 🗺️. In the ENERGY-OBJECT-CONTEXT-MIB module tables, the Energy Objects are indexed by entPhysicalIndex.
From there, the NMS must poll the eoPowerStateTable (specified in the ENERGY-OBJECT-MIB module in this document), which enumerates, among other things, the maximum power usage 🌈. The entries in the eoPowerStateTable are indexed by the Energy Object (entPhysicalIndex) and by the Power State Set (eoPowerStateIndex). So the maximum power usage is discovered per Energy Object, and the power usage per Power State of the Power State Set is discovered too. In other words, reading the eoPowerStateTable lets you discover each Power State within every Power State Set supported by the Energy Object 👑.
The MIB module may be populated with Energy Object relationship information, which has its own Energy Object index value (entPhysicalIndex). However, the Energy Object relationship must be discovered via the ENERGY-OBJECT-CONTEXT-MIB module 🧩.
Finally, the NMS can monitor the power attributes with the POWER-ATTRIBUTES-MIB MIB module, which reuses entPhysicalIndex to index the Energy Object 📊.
7. Link with the Other IETF MIBs ✨
7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB ✨
okay so [RFC6933] defines the ENTITY-MIB module, which lists the physical entities of a networking device (router, switch, etc.) and indexes those physical entities by entPhysicalIndex. bestie, from an energy-management standpoint, the physical entities that consume or produce energy are the ones we care about 🔌💅
[RFC3433] defines the ENTITY-SENSOR MIB module, which gives us a standardized way to get info (the current value of the sensor, the operational status of the sensor, and the data-unit precision) from sensors built into networking devices 🌸 Sensors are associated with each index of the entPhysicalIndex of the ENTITY-MIB [RFC6933]. The focus of the Monitoring and Control MIB for Power and Energy is measuring power usage of networking equipment indexed by the ENTITY-MIB, and lowkey this MIB also supports a customized power scale for power measurement, different Power States of networking equipment, and the functionality to configure those Power States 🦋
The Energy Objects are modeled by the entPhysicalIndex through the entPhysicalEntity MIB object specified in the eoTable in the ENERGY-OBJECT-CONTEXT-MIB MIB module [RFC7461] 🧚
Okay, the ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x accuracy classes that electricity needs (e.g., 1%, 2%, and 0.5% accuracy classes). Indeed, entPhySensorPrecision [RFC3433] represents "The number of decimal places of precision in fixed-point sensor values returned by the associated entPhySensorValue object". ngl that's not it for power. The ANSI and IEC standards are used for power measurement, and these standards require an accuracy class, not the scientific-number precision model specified in RFC3433. That's where the eoPowerAccuracy MIB object comes in, since it models this accuracy 💜
Also, eoPowerUnitMultipler represents the scale factor per IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22]. This is a more logical representation for power measurements than entPhySensorScale, with the mantissa and the exponent values X * 10 ^ Y 🎀
Power measurements that specify the qualifier 'UNITS' for each measured value in watts are used in the LLDP-EXT-MED-MIB, Power Ethernet [RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier is used for the power measurement values ✨
Real talk, one cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIBs are implemented for all Energy Objects that need to be monitored 🙈 A typical example is a converged building gateway, which can monitor other devices in a building and provides a proxy between SNMP and a protocol like BACnet. Another example is the home energy controller. In cases like these, the eoPhysicalEntity value contains the zero value, using the PhysicalIndexOrZero Textual Convention.
The eoPower is similar to entPhySensorValue [RFC3433], and the eoPowerUnitMultipler is similar to entPhySensorScale 💖
7.2. Link with the ENTITY-STATE MIB
For each entity in the ENTITY-MIB [RFC6933], the ENTITY-STATE MIB [RFC4268] specifies the operational states (entStateOper: unknown, enabled, disabled, testing), the alarm (entStateAlarm: unknown, underRepair, critical, major, minor, warning, indeterminate), and the possible values of standby states (entStateStandby: unknown, hotStandby, coldStandby, providingService) 🌈
From a power-monitoring point of view, it's different from the entity operational states. Power States are required, as proposed in the Monitoring and Control MIB for Power and Energy 🔥 Those Power States can be mapped to the different operational states in the ENTITY-STATE MIB, if a formal mapping is required. For example, the entStateStandby "unknown", "hotStandby", and "coldStandby" states could map to the Power State "unknown", "ready", "standby", respectively, while the entStateStandby "providingService" could map to any "low" to "high" Power State ⭐
7.3. Link with the POWER-OVER-ETHERNET MIB
The Power-over-Ethernet MIB [RFC3621] provides an energy monitoring and configuration framework for power over Ethernet devices. RFC 3621 defines a port group entity on a switch for power monitoring and management policy, and it does not use the entPhysicalIndex index. Indeed, pethMainPseConsumptionPower is indexed by the pethMainPseGroupIndex, which has no mapping with the entPhysicalIndex 🦋
If the Power-over-Ethernet MIB [RFC3621] is supported, the Energy Object eoethPortIndex and eoethPortGrpIndex contain the pethPsePortIndex and pethPsePortGroupIndex, respectively. However, one cannot assume that the Power-over-Ethernet MIB is implemented for most or all Energy Objects. In those cases, the eoethPortIndex and eoethPortGrpIndex values contain the zero value, via the new PethPsePortIndexOrZero and PethPsePortGroupIndexOrZero TCs 🍓
In either case, the entPhysicalIndex MIB object is used as the unique Energy Object index 💅
Note that, even though the Power-over-Ethernet MIB [RFC3621] was created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse the precision notion from the ENTITY-SENSOR MIB, i.e., the entPhySensorPrecision MIB object. Plot twist 😭
7.4. Link with the UPS MIB
To protect against unexpected power disruption, data centers and buildings make use of Uninterruptible Power Supplies (UPS) 🔋 To protect critical assets, a UPS can be restricted to a particular subset or domain of the network. UPS usage typically lasts only for a finite period of time, until normal power supply is restored. Planning is required to decide on the capacity of the UPS based on output power and the duration of probable power outage. To properly provision UPS power in a data center or building, it's important to first understand the total demand required to support all the entities in the site. This demand can be assessed and monitored via the Monitoring and Control MIB for Power and Energy 👑
The UPS MIB [RFC1628] provides information on the state of the UPS network. Implementing the UPS MIB is useful at the aggregate level of a data center or a building. The MIB module contains several groups of variables:
upsIdent: Identifies the UPS entity (name, model, etc.).upsBatterygroup: Indicates the battery state (upsbatteryStatus,upsEstimatedMinutesRemaining, etc.)upsInputgroup: Characterizes the input load to the UPS (number of input lines, voltage, current, etc.).upsOutput: Characterizes the output from the UPS (number of output lines, voltage, current, etc.)upsAlarms: Indicates the various alarm events.
The measurement of power in the UPS MIB is in volts, amperes, and watts. The units of power measurement are root mean square (RMS) volts and RMS amperes. They are not based on the EntitySensorDataScale and EntitySensorDataPrecision of ENTITY-SENSOR-MIB 🫶
Both the Monitoring and Control MIB for Power and Energy and the UPS MIB may be implemented on the same UPS SNMP agent, without conflict. In this case, the UPS device itself is the Energy Object, and any of the UPS meters or submeters are the Energy Objects, with a possible relationship as defined in [RFC7326] 🌸
7.5. Link with the LLDP and LLDP-MED MIBs
The Link Layer Discovery Protocol (LLDP) is a Data Link Layer protocol used by network devices to advertise their identities, capabilities, and interconnections on a LAN network 📡
The Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED. The LLDP-MED enhancements specifically address voice applications. LLDP-MED covers six basic areas: capability discovery, LAN speed and duplex discovery, network policy discovery, location identification discovery, inventory discovery, and power discovery 🎀
Of particular interest to the current MIB module is power discovery, which allows the endpoint device (such as a PoE phone) to convey power requirements to the switch. In power discovery, LLDP-MED has four Type-Length-Values (TLVs): power type, power source, power priority, and power value. Those TLVs provide information about the type of power (power sourcing entity versus powered device), how the device is powered (from the line, from a backup source, from external power source, etc.), the power priority (how important is it that this device has power?), and how much power the device needs. main character energy 💜
The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB] actually comes from the Power-over-Ethernet MIB [RFC3621]. If the Power-over-Ethernet MIB [RFC3621] is supported, the exact value from the pethPsePortPowerPriority [RFC3621] is copied over into the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]. Otherwise, the value in lldpXMedRemXPoEPDPowerPriority is "unknown". From the Monitoring and Control MIB for Power and Energy, it's possible to identify the pethPsePortPowerPriority [RFC3621] via the eoethPortIndex and eoethPortGrpIndex 🧚
The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to eoPowerMeasurementLocal in indicating if the power for an attached device is local or from a remote device. If the LLDP-MED MIB is supported, the following mapping can be applied to eoPowerMeasurementLocal: lldpXMedLocXPoEPDPowerSource fromPSE(2) and local(3) can be mapped to false and true, respectively 🌈
8. Structure of the MIB
The primary MIB object in the energyObjectMib MIB module is the energyObjectMibObjects root. The eoPowerTable table of energyObjectMibObjects describes the power measurement attributes of an Energy Object entity. The identity of a device in terms of uniquely identifying the Energy Object, and its relationship to other entities in the network, are addressed in [RFC7461] 🦋
Logically, this MIB module is a sparse extension of the ENERGY-OBJECT-CONTEXT-MIB module [RFC7461]. Thus, the following requirements that are applied to [RFC7461] are also applicable. As a requirement for this MIB module, [RFC7461] SHOULD be implemented, and as Module Compliance of ENTITY-MIB V4 [RFC6933] with respect to entity4CRCompliance MUST be supported. That requires four MIB objects: entPhysicalIndex, entPhysicalClass, entPhysicalName, and entPhysicalUUID MUST be implemented 🔥
The eoMeterCapabilitiesTable is useful for enabling applications to determine the capabilities supported by the local management agent. This table indicates the energy-monitoring MIB groups that are supported by the local management system. By reading the value of this object, applications can know which tables contain the information and are usable, without walking through the table and querying every element, which would be a trial-and-error process 🍓
The power measurement of an Energy Object contains information describing its power usage (eoPower) and its current Power State (eoPowerOperState). In addition to power usage, additional information is described: the units of measurement (eoPowerAccuracy, eoPowerUnitMultiplier), how the power usage measurement was obtained (eoPowerMeasurementCaliber), the source of the power measurement (eoPowerMeasurementLocal), and the type of power (eoPowerCurrentType) 💖
An Energy Object may contain an optional eoEnergyTable to describe energy measurement information over time ⭐
An Energy Object may contain an optional eoACPwrAttributesTable table (specified in the POWER-ATTRIBUTES-MIB module) that describes the electrical characteristics associated with the current Power State and usage ✨
An Energy Object may also contain optional battery information associated with this entity 🌸
9. MIB Definitions ✨
9.1. The IANAPowerStateSet-MIB Module ✨
okay so this first one is the IANA-run MIB, and it's basically the official list of power state sets 💅 It only holds one Textual Convention, called PowerStateSet, which is the list of the power state sets and power state values an Energy Object can support. Here it is, exactly as published:
-- ************************************************************
--
--
-- This MIB, maintained by IANA, contains a single Textual
-- Convention: PowerStateSet
--
-- ************************************************************
IANAPowerStateSet-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
ianaPowerStateSet MODULE-IDENTITY
LAST-UPDATED "201502090000Z" -- 9 February 2015
ORGANIZATION "IANA"
CONTACT-INFO "
Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
United States
Tel: +1-310-301 5800
EMail: iana@iana.org"
DESCRIPTION
"Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This MIB module defines the PowerStateSet Textual
Convention, which specifies the Power State Sets and
Power State Set Values an Energy Object supports.
The initial version of this MIB module was published in
RFC 7460; for full legal notices see the RFC itself."
-- revision history
REVISION "201502090000Z" -- 9 February 2015
DESCRIPTION
"Initial version of this MIB module, as published as RFC
7460."
::= { mib-2 228 }
PowerStateSet ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"IANAPowerState is a textual convention that describes
Power State Sets and Power State Set Values an Energy
Object supports. IANA has created a registry of Power
State supported by an Energy Object and IANA shall
administer the list of Power State Sets and Power
States.
The Textual Convention assumes that Power States in a
Power State Set are limited to 255 distinct values. For
a Power State Set S, the named number with the value S *
256 is allocated to indicate the Power State Set. For a
Power State X in the Power State Set S, the named number
with the value S * 256 + X + 1 is allocated to represent
the Power State.
Requests for new values should be made to IANA via email
(iana@iana.org)."
REFERENCE
"http://www.iana.org/assignments/power-state-sets"
SYNTAX INTEGER {
other(0), -- indicates other set
unknown(255), -- unknown
ieee1621(256), -- indicates IEEE1621 set
ieee1621Off(257),
ieee1621Sleep(258),
ieee1621On(259),
dmtf(512), -- indicates DMTF set
dmtfOn(513),
dmtfSleepLight(514),
dmtfSleepDeep(515),
dmtfOffHard(516),
dmtfOffSoft(517),
dmtfHibernate(518),
dmtfPowerOffSoft(519),
dmtfPowerOffHard(520),
dmtfMasterBusReset(521),
dmtfDiagnosticInterrapt(522),
dmtfOffSoftGraceful(523),
dmtfOffHardGraceful(524),
dmtfMasterBusResetGraceful(525),
dmtfPowerCycleOffSoftGraceful(526),
dmtfPowerCycleHardGraceful(527),
eman(1024), -- indicates EMAN set
emanMechOff(1025),
emanSoftOff(1026),
emanHibernate(1027),
emanSleep(1028),
emanStandby(1029),
emanReady(1030),
emanLowMinus(1031),
emanLow(1032),
emanMediumMinus(1033),
emanMedium(1034),
emanHighMinus(1035),
emanHigh(1036)
}
END9.2. The ENERGY-OBJECT-MIB MIB Module 🔌
next up is the big one, the ENERGY-OBJECT-MIB 🤩 this is the MIB you use to keep an eye on how much power network devices are pulling. The module header, the contact list, and the copyright notice all come first, and then the object definitions start. Here's the first chunk, verbatim:
-- ************************************************************
--
--
-- This MIB is used to monitor power usage of network
-- devices
--
-- *************************************************************
ENERGY-OBJECT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
mib-2,
Integer32, Counter32, Unsigned32, TimeTicks
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TimeInterval,
TimeStamp, TruthValue, StorageType
FROM SNMPv2-TC
MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
FROM SNMPv2-CONF
OwnerString
FROM RMON-MIB
entPhysicalIndex
FROM ENTITY-MIB
PowerStateSet
FROM IANAPowerStateSet-MIB;
energyObjectMib MODULE-IDENTITY
LAST-UPDATED "201502090000Z" -- 9 February 2015
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"WG charter:
http://datatracker.ietf.org/wg/eman/charter/
Mailing Lists:
General Discussion: eman@ietf.org
To Subscribe:
https://www.ietf.org/mailman/listinfo/eman
Archive:
http://www.ietf.org/mail-archive/web/eman
Editors:
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
United States
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe, Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-115
Email: quittek@neclab.eu
Thomas Dietz
NEC Europe, Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com"
DESCRIPTION
"Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This MIB is used to monitor power and energy in
devices.
The tables eoMeterCapabilitiesTable and eoPowerTable
are a sparse extension of the eoTable from the
ENERGY-OBJECT-CONTEXT-MIB. As a requirement,
[RFC7461] SHOULD be implemented.
Module Compliance of ENTITY-MIB v4 with respect to
entity4CRCompliance MUST be supported which requires
implementation of 4 MIB objects: entPhysicalIndex,
entPhysicalClass, entPhysicalName and entPhysicalUUID."
REVISION "201502090000Z" -- 9 February 2015
DESCRIPTION
"Initial version, published as RFC 7460."
::= { mib-2 229 }
energyObjectMibNotifs OBJECT IDENTIFIER
::= { energyObjectMib 0 }
energyObjectMibObjects OBJECT IDENTIFIER
::= { energyObjectMib 1 }
energyObjectMibConform OBJECT IDENTIFIER
::= { energyObjectMib 2 }
-- Textual Conventions
UnitMultiplier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Unit Multiplier is an integer value that represents
the IEEE 61850 Annex A units multiplier associated with
the integer units used to measure the power or energy.
For example, when used with eoPowerUnitMultiplier, -3
represents 10^-3 or milliwatts."
REFERENCE
"The International System of Units (SI), National
Institute of Standards and Technology, Spec. Publ. 330,
August 1991."
SYNTAX INTEGER {
yocto(-24), -- 10^-24
zepto(-21), -- 10^-21
atto(-18), -- 10^-18
femto(-15), -- 10^-15
pico(-12), -- 10^-12
nano(-9), -- 10^-9
micro(-6), -- 10^-6
milli(-3), -- 10^-3
units(0), -- 10^0
kilo(3), -- 10^3
mega(6), -- 10^6
giga(9), -- 10^9
tera(12), -- 10^12
peta(15), -- 10^15
exa(18), -- 10^18
zetta(21), -- 10^21
yotta(24) -- 10^24
}
-- Objects
eoMeterCapabilitiesTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoMeterCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is useful for helping applications determine
the monitoring capabilities supported by the local
management agents. It is possible for applications to
know which tables are usable without going through a
trial-and-error process."
::= { energyObjectMibObjects 1 }
eoMeterCapabilitiesEntry OBJECT-TYPE
SYNTAX EoMeterCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the metering capability of an Energy
Object."
INDEX { entPhysicalIndex }
::= { eoMeterCapabilitiesTable 1 }
EoMeterCapabilitiesEntry ::= SEQUENCE {
eoMeterCapability BITS
}
eoMeterCapability OBJECT-TYPE
SYNTAX BITS {
none(0),
powermetering(1), -- power measurement
energymetering(2), -- energy measurement
powerattributes(3) -- power attributes
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the energy-monitoring capabilities
supported by this agent. This object use a BITS syntax
and indicates the MIB groups supported by the probe. By
reading the value of this object, it is possible to
determine the MIB tables supported."
::= { eoMeterCapabilitiesEntry 1 }
eoPowerTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Energy Objects."
::= { energyObjectMibObjects 2 }
eoPowerEntry OBJECT-TYPE
SYNTAX EoPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the power usage of an Energy Object."
INDEX { entPhysicalIndex }
::= { eoPowerTable 1 }okay so this is where the energy object table gets really juicy 💅 every line below is copied exactly, because the MIB has to stay perfect 🫶
EoPowerEntry ::= SEQUENCE {
eoPower Integer32,
eoPowerNameplate Unsigned32,
eoPowerUnitMultiplier UnitMultiplier,
eoPowerAccuracy Integer32,
eoPowerMeasurementCaliber INTEGER,
eoPowerCurrentType INTEGER,
eoPowerMeasurementLocal TruthValue,
eoPowerAdminState PowerStateSet,
eoPowerOperState PowerStateSet,
eoPowerStateEnterReason OwnerString
}
eoPower OBJECT-TYPE
SYNTAX Integer32
UNITS "watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the power measured for the Energy
Object. For alternating current, this value is obtained
as an average over fixed number of AC cycles. This value
is specified in SI units of watts with the magnitude of
watts (milliwatts, kilowatts, etc.) indicated separately
in eoPowerUnitMultiplier. The accuracy of the measurement
is specified in eoPowerAccuracy. The direction of power
flow is indicated by the sign on eoPower. If the Energy
Object is consuming power, the eoPower value will be
positive. If the Energy Object is producing power, the
eoPower value will be negative.
The eoPower MUST be less than or equal to the maximum
power that can be consumed at the Power State specified
by eoPowerState.
The eoPowerMeasurementCaliber object specifies how the
usage value reported by eoPower was obtained. The eoPower
value must report 0 if the eoPowerMeasurementCaliber is
'unavailable'. For devices that cannot measure or
report power, this option can be used."
::= { eoPowerEntry 1 }
eoPowerNameplate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the rated maximum consumption for
the fully populated Energy Object. The nameplate power
requirements are the maximum power numbers given in SI
watts and, in almost all cases, are well above the
expected operational consumption. Nameplate power is
widely used for power provisioning. This value is
specified in either units of watts or voltage and
current. The units are therefore SI watts or equivalent
Volt-Amperes with the magnitude (milliwatts, kilowatts,
etc.) indicated separately in eoPowerUnitMultiplier."
::= { eoPowerEntry 2 }
eoPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in eoPower
and eoPowerNameplate."
::= { eoPowerEntry 3 }
eoPowerAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates a percentage value, in hundredths of a
percent, representing the assumed accuracy of the usage
reported by eoPower. For example, the value 1010 means
the reported usage is accurate to +/- 10.1 percent. This
value is zero if the accuracy is unknown or not
applicable based upon the measurement method.
ANSI and IEC define the following accuracy classes for
power measurement:
IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3.
ANSI C12.20 class 0.2, 0.5"
::= { eoPowerEntry 4 }
eoPowerMeasurementCaliber OBJECT-TYPE
SYNTAX INTEGER {
unavailable(1) ,
unknown(2),
actual(3) ,
estimated(4),
static(5) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies how the usage value reported by
eoPower was obtained:
- unavailable(1): Indicates that the usage is not
available. In such a case, the eoPower value must be 0
for devices that cannot measure or report power this
option can be used.
- unknown(2): Indicates that the way the usage was
determined is unknown. In some cases, entities report
aggregate power on behalf of another device. In such
cases it is not known whether the usage reported is
actual, estimated, or static.
- actual(3): Indicates that the reported usage was
measured by the entity through some hardware or direct
physical means. The usage data reported is not estimated
or static but is the measured consumption rate.
- estimated(4): Indicates that the usage was not
determined by physical measurement. The value is a
derivation based upon the device type, state, and/or
current utilization using some algorithm or heuristic. It
is presumed that the entity's state and current
configuration were used to compute the value.
- static(5): Indicates that the usage was not determined
by physical measurement, algorithm, or derivation. The
usage was reported based upon external tables,
specifications, and/or model information. For example, a
PC Model X draws 200W, while a PC Model Y draws 210W."
::= { eoPowerEntry 5 }
eoPowerCurrentType OBJECT-TYPE
SYNTAX INTEGER {
ac(1),
dc(2),
unknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates whether the eoPower for the
Energy Object reports alternating current 'ac', direct
current 'dc', or that the current type is unknown."
::= { eoPowerEntry 6 }
eoPowerMeasurementLocal OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the source of power measurement
and can be useful when modeling the power usage of
attached devices. The power measurement can be performed
by the entity itself or the power measurement of the
entity can be reported by another trusted entity using a
protocol extension. A value of true indicates the
measurement is performed by the entity, whereas false
indicates that the measurement was performed by another
entity."
::= { eoPowerEntry 7 }
eoPowerAdminState OBJECT-TYPE
SYNTAX PowerStateSet
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the desired Power State and the
Power State Set for the Energy Object. Note that other(0)
is not a Power State Set and unknown(255) is not a Power
State as such, but simply an indication that the Power
State of the Energy Object is unknown.
Possible values of eoPowerAdminState within the Power
State Set are registered at IANA.
A current list of assignments can be found at
<http://www.iana.org/assignments/power-state-sets>"
::= { eoPowerEntry 8 }
eoPowerOperState OBJECT-TYPE
SYNTAX PowerStateSet
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the current operational Power
State and the Power State Set for the Energy Object.
other(0) is not a Power State Set and unknown(255) is not
a Power State as such, but simply an indication that the
Power State of the Energy Object is unknown.
Possible values of eoPowerOperState within the Power
State Set are registered at IANA. A current list of
assignments can be found at
<http://www.iana.org/assignments/power-state-sets>"
::= { eoPowerEntry 9 }
eoPowerStateEnterReason OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This string object describes the reason for the
eoPowerAdminState transition. Alternatively, this string
may contain with the entity that configured this Energy
Object to this Power State."
DEFVAL { "" }
::= { eoPowerEntry 10 }
eoPowerStateTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoPowerStateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table enumerates the maximum power usage, in watts,
for every single supported Power State of each Energy
Object.
This table has cross-reference with the eoPowerTable,
containing rows describing each Power State for the
corresponding Energy Object. For every Energy Object in
the eoPowerTable, there is a corresponding entry in this
table."
::= { energyObjectMibObjects 3 }
eoPowerStateEntry OBJECT-TYPE
SYNTAX EoPowerStateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A eoPowerStateEntry extends a corresponding
eoPowerEntry. This entry displays max usage values at
every single possible Power State supported by the Energy
Object.
For example, given the values of a Energy Object
corresponding to a maximum usage of 0 W at the
state emanmechoff, 8 W at state 6 (ready), 11 W at state
emanmediumMinus, and 11 W at state emanhigh:
State MaxUsage Units
emanmechoff 0 W
emansoftoff 0 W
emanhibernate 0 W
emansleep 0 W
emanstandby 0 W
emanready 8 W
emanlowMinus 8 W
emanlow 11 W
emanmediumMinus 11 W
emanmedium 11 W
emanhighMinus 11 W
emnanhigh 11 W
Furthermore, this table also includes the total time in
each Power State, along with the number of times a
particular Power State was entered."
INDEX { entPhysicalIndex, eoPowerStateIndex }
::= { eoPowerStateTable 1 }
EoPowerStateEntry ::= SEQUENCE {
eoPowerStateIndex PowerStateSet,
eoPowerStateMaxPower Integer32,
eoPowerStatePowerUnitMultiplier UnitMultiplier,
eoPowerStateTotalTime TimeTicks,
eoPowerStateEnterCount Counter32
}
eoPowerStateIndex OBJECT-TYPE
SYNTAX PowerStateSet
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object specifies the index of the Power State of
the Energy Object within a Power State Set. The semantics
of the specific Power State can be obtained from the
Power State Set definition."
::= { eoPowerStateEntry 1 }okay bestie, the MIB keeps going and the energy tables are lowkey iconic 💜 here's the rest of the module:
eoPowerStateMaxPower OBJECT-TYPE
SYNTAX Integer32
UNITS "watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum power for the Energy
Object at the particular Power State. This value is
specified in SI units of watts with the magnitude of the
units (milliwatts, kilowatts, etc.) indicated separately
in eoPowerStatePowerUnitMultiplier. If the maximum power
is not known for a certain Power State, then the value is
encoded as 0xFFFFFFFF.
For Power States not enumerated, the value of
eoPowerStateMaxPower might be interpolated by using the
next highest supported Power State."
::= { eoPowerStateEntry 2 }
eoPowerStatePowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
eoPowerStateMaxPower."
::= { eoPowerStateEntry 3 }
eoPowerStateTotalTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the total time in hundredths
of a second that the Energy Object has been in this power
state since the last reset, as specified in the
sysUpTime."
::= { eoPowerStateEntry 4 }
eoPowerStateEnterCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates how often the Energy Object has
entered this power state, since the last reset of the
device as specified in the sysUpTime."
::= { eoPowerStateEntry 5 }
eoEnergyParametersTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is used to configure the parameters for
energy measurement collection in the table eoEnergyTable.
This table allows the configuration of different
measurement settings on the same Energy Object.
Implementation of this table only makes sense for Energy
Objects that an eoPowerMeasurementCaliber of actual."
::= { energyObjectMibObjects 4 }
eoEnergyParametersEntry OBJECT-TYPE
SYNTAX EoEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls an energy measurement in
eoEnergyTable."
INDEX { entPhysicalIndex, eoEnergyParametersIndex }
::= { eoEnergyParametersTable 1 }
EoEnergyParametersEntry ::= SEQUENCE {
eoEnergyParametersIndex Integer32,
eoEnergyParametersIntervalLength TimeInterval,
eoEnergyParametersIntervalNumber Unsigned32,
eoEnergyParametersIntervalMode INTEGER,
eoEnergyParametersIntervalWindow TimeInterval,
eoEnergyParametersSampleRate Unsigned32,
eoEnergyParametersStorageType StorageType,
eoEnergyParametersStatus RowStatus
}
eoEnergyParametersIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object specifies the index of the Energy Parameters
setting for collection of energy measurements for an
Energy Object. An Energy Object can have multiple
eoEnergyParametersIndex, depending on the capabilities of
the Energy Object"
::= { eoEnergyParametersEntry 2 }
eoEnergyParametersIntervalLength OBJECT-TYPE
SYNTAX TimeInterval
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the length of time in hundredths
of a second over which to compute the average
eoEnergyConsumed measurement in the eoEnergyTable table.
The computation is based on the Energy Object's internal
sampling rate of power consumed or produced by the Energy
Object. The sampling rate is the rate at which the Energy
Object can read the power usage and may differ based on
device capabilities. The average energy consumption is
then computed over the length of the interval. The
default value of 15 minutes is a common interval used in
industry."
DEFVAL { 90000 }
::= { eoEnergyParametersEntry 3 }
eoEnergyParametersIntervalNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of intervals maintained in the eoEnergyTable.
Each interval is characterized by a specific
eoEnergyCollectionStartTime, used as an index to the
table eoEnergyTable. Whenever the maximum number of
entries is reached, the measurement over the new interval
replaces the oldest measurement. There is one exception
to this rule: when the eoEnergyMaxConsumed and/or
eoEnergyMaxProduced are in (one of) the two oldest
measurement(s), they are left untouched and the next
oldest measurement is replaced."
DEFVAL { 10 }
::= { eoEnergyParametersEntry 4 }
eoEnergyParametersIntervalMode OBJECT-TYPE
SYNTAX INTEGER {
period(1),
sliding(2),
total(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control object to define the mode of interval
calculation for the computation of the average
eoEnergyConsumed or eoEnergyProvided measurement in the
eoEnergyTable table.
A mode of period(1) specifies non-overlapping periodic
measurements.
A mode of sliding(2) specifies overlapping sliding
windows where the interval between the start of one
interval and the next is defined in
eoEnergyParametersIntervalWindow.
A mode of total(3) specifies non-periodic measurement.
In this mode only one interval is used as this is a
continuous measurement since the last reset. The value of
eoEnergyParametersIntervalNumber should be (1) one and
eoEnergyParametersIntervalLength is ignored."
::= { eoEnergyParametersEntry 5 }
eoEnergyParametersIntervalWindow OBJECT-TYPE
SYNTAX TimeInterval
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The length of the duration window between the starting
time of one sliding window and the next starting time in
hundredths of seconds, used to compute the average of
eoEnergyConsumed, eoEnergyProvided measurements in the
eoEnergyTable table. This is valid only when the
eoEnergyParametersIntervalMode is sliding(2). The
eoEnergyParametersIntervalWindow value should be a
multiple of eoEnergyParametersSampleRate."
::= { eoEnergyParametersEntry 6 }
eoEnergyParametersSampleRate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The sampling rate, in milliseconds, at which the Energy
Object should poll power usage in order to compute the
average eoEnergyConsumed, eoEnergyProvided measurements
in the table eoEnergyTable. The Energy Object should
initially set this sampling rate to a reasonable value,
i.e., a compromise between intervals that will provide
good accuracy by not being too long, but not so short
that they affect the Energy Object performance by
requesting continuous polling. If the sampling rate is
unknown, the value 0 is reported. The sampling rate
should be selected so that
eoEnergyParametersIntervalWindow is a multiple of
eoEnergyParametersSampleRate. The default value is one
second."
DEFVAL { 1000 }
::= { eoEnergyParametersEntry 7 }
eoEnergyParametersStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this row."
DEFVAL { nonVolatile }
::= {eoEnergyParametersEntry 8 }
eoEnergyParametersStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row. The eoEnergyParametersStatus is
used to start or stop energy usage logging. An entry
status may not be active(1) unless all objects in the
entry have an appropriate value. If this object is not
equal to active, all associated usage-data logged into
the eoEnergyTable will be deleted. The data can be
destroyed by setting up the eoEnergyParametersStatus to
destroy."
::= {eoEnergyParametersEntry 9 }
eoEnergyTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoEnergyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Energy Object energy measurements.
Entries in this table are only created if the
corresponding value of object eoPowerMeasurementCaliber
is active(3), i.e., if the power is actually metered."
::= { energyObjectMibObjects 5 }
eoEnergyEntry OBJECT-TYPE
SYNTAX EoEnergyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing energy measurements."
INDEX { eoEnergyParametersIndex,
eoEnergyCollectionStartTime }
::= { eoEnergyTable 1 }
EoEnergyEntry ::= SEQUENCE {
eoEnergyCollectionStartTime TimeTicks,
eoEnergyConsumed Unsigned32,
eoEnergyProvided Unsigned32,
eoEnergyStored Unsigned32,
eoEnergyUnitMultiplier UnitMultiplier,
eoEnergyAccuracy Integer32,
eoEnergyMaxConsumed Unsigned32,
eoEnergyMaxProduced Unsigned32,
eoEnergyDiscontinuityTime TimeStamp
}
eoEnergyCollectionStartTime OBJECT-TYPE
SYNTAX TimeTicks
UNITS "hundredths of a second"
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized, as specified in the sysUpTime RFC 3418.
This object specifies the start time of the energy
measurement sample."
REFERENCE
"RFC 3418: Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)"
::= { eoEnergyEntry 1 }eoEnergyConsumed, eoEnergyProvided, and friends are giving full energy-tracking girlboss 🔋💅 Watt-hours everywhere, and the multiplier object tells you whether you're looking at Wh, kWh, or MWh 🧮
eoEnergyConsumed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the energy consumed in units of
watt-hours for the Energy Object over the defined
interval. This value is specified in the common billing
units of watt-hours with the magnitude of watt-hours
kWh, MWh, etc.) indicated separately in
eoEnergyUnitMultiplier."
::= { eoEnergyEntry 2 }
eoEnergyProvided OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the energy produced in units of
watt-hours for the Energy Object over the defined
interval.
This value is specified in the common billing units of
watt-hours with the magnitude of watt-hours (kWh, MWh,
etc.) indicated separately in
eoEnergyUnitMultiplier."
::= { eoEnergyEntry 3 }
eoEnergyStored OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the difference of the energy
consumed and energy produced for an Energy Object in
units of watt-hours for the Energy Object over the
defined interval. This value is specified in the common
billing units of watt-hours with the magnitude of
watt-hours (kWh, MWh, etc.) indicated separately in
eoEnergyUnitMultiplier."
::= { eoEnergyEntry 4 }
eoEnergyUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the magnitude of watt-hours for the
energy field in eoEnergyConsumed, eoEnergyProvided,
eoEnergyStored, eoEnergyMaxConsumed, and
eoEnergyMaxProduced."
::= { eoEnergyEntry 5 }
eoEnergyAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates a percentage accuracy, in hundredths
of a percent, of Energy usage reporting. eoEnergyAccuracy
is applicable to all Energy measurements in the
eoEnergyTable.
For example, 1010 means the reported usage is accurate to
+/- 10.1 percent.
This value is zero if the accuracy is unknown."
::= { eoEnergyEntry 6 }
eoEnergyMaxConsumed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum energy observed in
eoEnergyConsumed since the monitoring started or was
reinitialized. This value is specified in the common
billing units of watt-hours with the magnitude of
watt-hours (kWh, MWh, etc.) indicated separately in
eoEnergyUnitMultiplier."
::= { eoEnergyEntry 7 }
eoEnergyMaxProduced OBJECT-TYPE
SYNTAX Unsigned32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum energy ever observed in
eoEnergyEnergyProduced since the monitoring started. This
value is specified in the units of watt-hours with the
magnitude of watt-hours (kWh, MWh, etc.) indicated
separately in eoEnergyEnergyUnitMultiplier."
::= { eoEnergyEntry 8 }
eoEnergyDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime RFC 3418 on the most recent
occasion at which any one or more of this entity's energy
counters in this table suffered a discontinuity:
eoEnergyConsumed, eoEnergyProvided or eoEnergyStored. If
no such discontinuities have occurred since the last
re-initialization of the local management subsystem, then
this object contains a zero value."
REFERENCE
"RFC 3418: Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)"
::= { eoEnergyEntry 9 }Okay, now the notifications 🔔 this is where the MIB starts talking back to you 🫶
-- Notifications
eoPowerEnableStatusNotification
OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls whether the system produces
notifications for eoPowerStateChange. A false value will
prevent these notifications from being generated."
DEFVAL { false }
::= { energyObjectMibNotifs 1 }
eoPowerStateChange NOTIFICATION-TYPE
OBJECTS {eoPowerAdminState, eoPowerOperState,
eoPowerStateEnterReason}
STATUS current
DESCRIPTION
"The SNMP entity generates the eoPowerStateChange when
the values of eoPowerAdminState or eoPowerOperState,
in the context of the Power State Set, have changed for
the Energy Object represented by the entPhysicalIndex."
::= { energyObjectMibNotifs 2 }Conformance time, bestie 🎀 This is the part where we decide who gets the full compliance crown 👑
-- Conformance
energyObjectMibCompliances OBJECT IDENTIFIER
::= { energyObjectMibConform 1 }
energyObjectMibGroups OBJECT IDENTIFIER
::= { energyObjectMibConform 2 }
energyObjectMibFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented with support for
read-create, then such an implementation can
claim full compliance. Such devices can then
be both monitored and configured with this MIB.
Module Compliance of RFC 6933
with respect to entity4CRCompliance MUST
be supported, which requires implementation
of four MIB objects: entPhysicalIndex, entPhysicalClass,
entPhysicalName and entPhysicalUUID."
REFERENCE
"RFC 6933: Entity MIB (Version 4)"
MODULE -- this module
MANDATORY-GROUPS {
energyObjectMibTableGroup,
energyObjectMibStateTableGroup,
eoPowerEnableStatusNotificationGroup,
energyObjectMibNotifGroup
}
GROUP energyObjectMibEnergyTableGroup
DESCRIPTION
"A compliant implementation does not
have to implement."
GROUP energyObjectMibEnergyParametersTableGroup
DESCRIPTION
"A compliant implementation does not
have to implement."
GROUP energyObjectMibMeterCapabilitiesTableGroup
DESCRIPTION
"A compliant implementation does not
have to implement."
::= { energyObjectMibCompliances 1 }
energyObjectMibReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-create (i.e., in read-only mode), then such an
implementation can claim read-only compliance. Such a
device can then be monitored but cannot be
configured with this MIB.
Module Compliance of [RFC6933] with respect to
entity4CRCompliance MUST be supported which requires
implementation of 4 MIB objects: entPhysicalIndex,
entPhysicalClass, entPhysicalName and entPhysicalUUID."
REFERENCE
"RFC 6933: Entity MIB (Version 4)"
MODULE -- this module
MANDATORY-GROUPS {
energyObjectMibTableGroup,
energyObjectMibStateTableGroup,
energyObjectMibNotifGroup
}
::= { energyObjectMibCompliances 2 }Last stretch of this part: the Units of Conformance groups 🧩 each group is just a bundle of objects, so these are the little packs you sign up for 🍓
-- Units of Conformance
energyObjectMibTableGroup OBJECT-GROUP
OBJECTS {
eoPower,
eoPowerNameplate,
eoPowerUnitMultiplier,
eoPowerAccuracy,
eoPowerMeasurementCaliber,
eoPowerCurrentType,
eoPowerMeasurementLocal,
eoPowerAdminState,
eoPowerOperState,
eoPowerStateEnterReason
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Object."
::= { energyObjectMibGroups 1 }
energyObjectMibStateTableGroup OBJECT-GROUP
OBJECTS {
eoPowerStateMaxPower,
eoPowerStatePowerUnitMultiplier,
eoPowerStateTotalTime,
eoPowerStateEnterCount
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Power State."
::= { energyObjectMibGroups 2 }
energyObjectMibEnergyParametersTableGroup OBJECT-GROUP
OBJECTS {
eoEnergyParametersIntervalLength,
eoEnergyParametersIntervalNumber,
eoEnergyParametersIntervalMode,
eoEnergyParametersIntervalWindow,
eoEnergyParametersSampleRate,
eoEnergyParametersStorageType,
eoEnergyParametersStatus
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the configuration of the Energy Table."
::= { energyObjectMibGroups 3 }
energyObjectMibEnergyTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object
-- eoEnergyCollectionStartTime is not
-- included since it is not-accessible
eoEnergyConsumed,
eoEnergyProvided,
eoEnergyStored,
eoEnergyUnitMultiplier,
eoEnergyAccuracy,
eoEnergyMaxConsumed,
eoEnergyMaxProduced,
eoEnergyDiscontinuityTime
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Table."
::= { energyObjectMibGroups 4 }
energyObjectMibMeterCapabilitiesTableGroup OBJECT-GROUP
OBJECTS {
eoMeterCapability
}
STATUS current
DESCRIPTION
"This group contains the object indicating the capability
of the Energy Object"
::= { energyObjectMibGroups 5 }
eoPowerEnableStatusNotificationGroup OBJECT-GROUP
OBJECTS { eoPowerEnableStatusNotification }
STATUS current
DESCRIPTION
"The collection of objects that are used to enable
notification."
::= { energyObjectMibGroups 6 }Next up, we keep going with the rest of the MIB 🦋 the plot is thickening ✨
energyObjectMibNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
eoPowerStateChange
}
STATUS current
DESCRIPTION
"This group contains the notifications for
the Monitoring and Control MIB for Power and Energy."
::= { energyObjectMibGroups 7 }
END9.3. The POWER-ATTRIBUTES-MIB MIB Module ✨
okay bestie, this is the POWER-ATTRIBUTES-MIB and it's basically the AC power glow-up 💅 it's all about monitoring power attributes on networked devices, and the header literally says it's an extension of the energyObjectMib module 🎀 the table is a sparse augmentation of eoPowerTable, so it only fills in the AC stuff 🦋 the DESCRIPTION also covers both three-phase and single-phase setups, which is so thorough of them 😭
-- ************************************************************
--
-- This MIB module is used to monitor power attributes of
-- networked devices with measurements.
--
-- This MIB module is an extension of energyObjectMib module.
--
-- *************************************************************
POWER-ATTRIBUTES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2,
Integer32, Unsigned32
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF
UnitMultiplier
FROM ENERGY-OBJECT-MIB
entPhysicalIndex
FROM ENTITY-MIB;
powerAttributesMIB MODULE-IDENTITY
LAST-UPDATED "201502090000Z" -- 9 February 2015
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"WG charter:
http://datatracker.ietf.org/wg/eman/charter/
Mailing Lists:
General Discussion: eman@ietf.org
To Subscribe:
https://www.ietf.org/mailman/listinfo/eman
Archive:
http://www.ietf.org/mail-archive/web/eman
Editors:
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
United States
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-115
Email: quittek@neclab.eu
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com"
DESCRIPTION
"Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This MIB is used to report AC power attributes in devices.
The table is a sparse augmentation of the eoPowerTable table
from the energyObjectMib module. Both three-phase and
single-phase power configurations are supported.
As a requirement for this MIB module, RFC 7461 SHOULD be
implemented.
Module Compliance of ENTITY-MIB v4 with respect to
entity4CRCompliance MUST be supported which requires
implementation of four MIB objects: entPhysicalIndex,
entPhysicalClass, entPhysicalName, and entPhysicalUUID."
REVISION "201502090000Z" -- 9 February 2015
DESCRIPTION
"Initial version, published as RFC 7460"
::= { mib-2 230 }
powerAttributesMIBConform OBJECT IDENTIFIER
::= { powerAttributesMIB 0 }
powerAttributesMIBObjects OBJECT IDENTIFIER
::= { powerAttributesMIB 1 }
-- Objects
eoACPwrAttributesTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains power attributes measurements for
supported entPhysicalIndex entities. It is a sparse
extension of the eoPowerTable."
::= { powerAttributesMIBObjects 1 }
eoACPwrAttributesEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a sparse extension of the eoPowerTable with
entries for power attributes measurements or
configuration. Each measured value corresponds to an
attribute in IEC 61850-7-4 for non-phase measurements
within the object MMXN."
INDEX { entPhysicalIndex }
::= { eoACPwrAttributesTable 1 }
EoACPwrAttributesEntry ::= SEQUENCE {
eoACPwrAttributesConfiguration INTEGER,
eoACPwrAttributesAvgVoltage Integer32,
eoACPwrAttributesAvgCurrent Unsigned32,
eoACPwrAttributesFrequency Integer32,
eoACPwrAttributesPowerUnitMultiplier UnitMultiplier,
eoACPwrAttributesPowerAccuracy Integer32,
eoACPwrAttributesTotalActivePower Integer32,
eoACPwrAttributesTotalReactivePower Integer32,
eoACPwrAttributesTotalApparentPower Integer32,
eoACPwrAttributesTotalPowerFactor Integer32,
eoACPwrAttributesThdCurrent Integer32,
eoACPwrAttributesThdVoltage Integer32
}
eoACPwrAttributesConfiguration OBJECT-TYPE
SYNTAX INTEGER {
sngl(1),
del(2),
wye(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Configuration describes the physical configurations of
the power supply lines:
* alternating current, single phase (SNGL)
* alternating current, three-phase delta (DEL)
* alternating current, three-phase Y (WYE)
Three-phase configurations can be either connected in a
triangular delta (DEL) or star Y (WYE) system. WYE
systems have a shared neutral voltage, while DEL systems
do not. Each phase is offset 120 degrees to each other."
::= { eoACPwrAttributesEntry 1 }
eoACPwrAttributesAvgVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value for average of the voltage measured
over an integral number of AC cycles. For a three-phase
system, this is the average voltage (V1+V2+V3)/3. IEC
61850-7-4 measured value attribute 'Vol'."
::= { eoACPwrAttributesEntry 2 }
eoACPwrAttributesAvgCurrent OBJECT-TYPE
SYNTAX Unsigned32
UNITS "amperes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value for average of the current measured
over an integral number of AC cycles. For a three-phase
system, this is the average current (I1+I2+I3)/3. IEC
61850-7-4 attribute 'Amp'."
::= { eoACPwrAttributesEntry 3 }
eoACPwrAttributesFrequency OBJECT-TYPE
SYNTAX Integer32 (4500..6500)
UNITS "0.01 hertz"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value for the basic frequency of the AC
circuit. IEC 61850-7-4 attribute 'Hz'."
::= { eoACPwrAttributesEntry 4 }
eoACPwrAttributesPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
eoACPwrAttributesTotalActivePower,
eoACPwrAttributesTotalReactivePower,
and eoACPwrAttributesTotalApparentPower measurements.
For three-phase power systems, this will also include
eoACPwrAttributesWyeActivePower,
eoACPwrAttributesWyeReactivePower, and
eoACPwrAttributesWyeApparentPower."
::= { eoACPwrAttributesEntry 5 }
eoACPwrAttributesPowerAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates a percentage value, in hundredths of a
percent, representing the presumed accuracy of active,
reactive, and apparent power usage reporting. For
example, 1010 means the reported usage is accurate to +/-
10.1 percent. This value is zero if the accuracy is
unknown.
ANSI and IEC define the following accuracy classes for
power measurement: IEC 62053-22 & 60044-1 class 0.1, 0.2,
0.5, 1, & 3.
ANSI C12.20 class 0.2 & 0.5"
::= { eoACPwrAttributesEntry 6 }
eoACPwrAttributesTotalActivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the actual power delivered to or
consumed by the load. IEC 61850-7-4 attribute 'TotW'."
::= { eoACPwrAttributesEntry 7 }
eoACPwrAttributesTotalReactivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "volt-amperes reactive"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the reactive portion of the apparent
power. IEC 61850-7-4 attribute 'TotVAr'."
::= { eoACPwrAttributesEntry 8 }
eoACPwrAttributesTotalApparentPower OBJECT-TYPE
SYNTAX Integer32
UNITS "volt-amperes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the voltage and current that
determines the apparent power. The apparent power is the
vector sum of real and reactive power.
Note: watts and volt-amperes are equivalent units and may
be combined. IEC 61850-7-4 attribute 'TotVA'."
::= { eoACPwrAttributesEntry 9 }
eoACPwrAttributesTotalPowerFactor OBJECT-TYPE
SYNTAX Integer32 (-10000..10000)
UNITS "hundredths"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value ratio of the real power flowing to the
load versus the apparent power. It is dimensionless and
expressed here as a percentage value in hundredths. A power
factor of 100% indicates there is no inductance load and
thus no reactive power. A Power Factor can be positive or
negative, where the sign should be in lead/lag (IEEE)
form. IEC 61850-7-4 attribute 'TotPF'."
::= { eoACPwrAttributesEntry 10 }okay so the THD readings are up next, and they're giving main character energy 💅 the wyephase and delphase tables are sparse extensions hanging off the main table, so they're kinda like side quests 🦋 and then the compliance statement lays out the rules for who gets the gold star 🌈 let's go bestie ✨
eoACPwrAttributesThdCurrent OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A calculated value for the current total harmonic
distortion (THD). Method of calculation is not
specified. IEC 61850-7-4 attribute 'ThdAmp'."
::= { eoACPwrAttributesEntry 11 }
eoACPwrAttributesThdVoltage OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A calculated value for the voltage total harmonic
distortion (THD). The method of calculation is not
specified. IEC 61850-7-4 attribute 'ThdVol'."
::= { eoACPwrAttributesEntry 12 }
eoACPwrAttributesDelPhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This optional table describes three-phase power attributes
measurements in a DEL configuration with phase-to-phase
power attributes measurements. Entities having single
phase power shall not have any entities. This is a
sparse extension of the eoACPwrAttributesTable.
These attributes correspond to measurements related to
the IEC 61850-7.4 MMXU phase and measured harmonic or
interharmonics related to the MHAI phase."
::= { powerAttributesMIBObjects 2 }
eoACPwrAttributesDelPhaseEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes power measurements of a phase in a
DEL three-phase power. Three entries are required for each
supported entPhysicalIndex entry. Voltage measurements
are provided relative to each other.
For phase-to-phase measurements, the
eoACPwrAttributesDelPhaseIndex is compared against the
following phase at +120 degrees. Thus, the possible
values are:
eoACPwrAttributesDelPhaseIndex Next Phase Angle
0 120
120 240
240 0
"
INDEX { entPhysicalIndex, eoACPwrAttributesDelPhaseIndex }
::= { eoACPwrAttributesDelPhaseTable 1}
EoACPwrAttributesDelPhaseEntry ::= SEQUENCE {
eoACPwrAttributesDelPhaseIndex Integer32,
eoACPwrAttributesDelPhaseToNextPhaseVoltage Integer32,
eoACPwrAttributesDelThdPhaseToNextPhaseVoltage Integer32
}
eoACPwrAttributesDelPhaseIndex OBJECT-TYPE
SYNTAX Integer32 (0..359)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A phase angle typically corresponding to 0, 120, 240."
::= { eoACPwrAttributesDelPhaseEntry 1 }
eoACPwrAttributesDelPhaseToNextPhaseVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of phase to next phase voltages, where
the next phase is IEC 61850-7-4 attribute 'PPV'."
::= { eoACPwrAttributesDelPhaseEntry 2 }
eoACPwrAttributesDelThdPhaseToNextPhaseVoltage OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A calculated value for the voltage total harmonic
distortion for phase to next phase. Method of calculation
is not specified. IEC 61850-7-4 attribute 'ThdPPV'."
::= { eoACPwrAttributesDelPhaseEntry 3 }
eoACPwrAttributesWyePhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This optional table describes three-phase power attributes
measurements in a WYE configuration with phase-to-neutral
power attributes measurements. Entities having single
phase power shall not have any entities. This is a sparse
extension of the eoACPwrAttributesTable.
These attributes correspond to measurements related to
the IEC 61850-7.4 MMXU phase and measured harmonic or
interharmonics related to the MHAI phase."
::= { powerAttributesMIBObjects 3 }
eoACPwrAttributesWyePhaseEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes measurements of a phase in a WYE
three-phase power system. Three entries are required for
each supported entPhysicalIndex entry. Voltage
measurements are relative to neutral.
Each entry describes power attributes of one phase of a
WYE three-phase power system."
INDEX { entPhysicalIndex, eoACPwrAttributesWyePhaseIndex }
::= { eoACPwrAttributesWyePhaseTable 1}
EoACPwrAttributesWyePhaseEntry ::= SEQUENCE {
eoACPwrAttributesWyePhaseIndex Integer32,
eoACPwrAttributesWyePhaseToNeutralVoltage Integer32,
eoACPwrAttributesWyeCurrent Integer32,
eoACPwrAttributesWyeActivePower Integer32,
eoACPwrAttributesWyeReactivePower Integer32,
eoACPwrAttributesWyeApparentPower Integer32,
eoACPwrAttributesWyePowerFactor Integer32,
eoACPwrAttributesWyeThdCurrent Integer32,
eoACPwrAttributesWyeThdPhaseToNeutralVoltage Integer32
}
eoACPwrAttributesWyePhaseIndex OBJECT-TYPE
SYNTAX Integer32 (0..359)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A phase angle typically corresponding to 0, 120, 240."
::= { eoACPwrAttributesWyePhaseEntry 1 }
eoACPwrAttributesWyePhaseToNeutralVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of phase to neutral voltage. IEC
61850-7-4 attribute 'PNV'."
::= { eoACPwrAttributesWyePhaseEntry 2 }
eoACPwrAttributesWyeCurrent OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 amperes AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of phase currents. IEC 61850-7-4
attribute 'A'."
::= { eoACPwrAttributesWyePhaseEntry 3 }
eoACPwrAttributesWyeActivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the actual power delivered to or
consumed by the load with the magnitude indicated
separately in eoPowerUnitMultiplier. IEC 61850-7-4
attribute 'W'."
::= { eoACPwrAttributesWyePhaseEntry 4 }
eoACPwrAttributesWyeReactivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "volt-amperes reactive"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the reactive portion of the apparent
power with the magnitude of indicated separately in
eoPowerUnitMultiplier. IEC 61850-7-4 attribute 'VAr'."
::= { eoACPwrAttributesWyePhaseEntry 5 }
eoACPwrAttributesWyeApparentPower OBJECT-TYPE
SYNTAX Integer32
UNITS "volt-amperes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the voltage and current determines
the apparent power with the indicated separately in
eoPowerUnitMultiplier. Active plus reactive power equals
the total apparent power.
Note: Watts and volt-amperes are equivalent units and may
be combined. IEC 61850-7-4 attribute 'VA'."
::= { eoACPwrAttributesWyePhaseEntry 6 }
eoACPwrAttributesWyePowerFactor OBJECT-TYPE
SYNTAX Integer32 (-10000..10000)
UNITS "hundredths"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value ratio of the real power flowing to the
load versus the apparent power for this phase. IEC
61850-7-4 attribute 'PF'. Power Factor can be positive or
negative where the sign should be in lead/lag (IEEE)
form."
::= { eoACPwrAttributesWyePhaseEntry 7 }
eoACPwrAttributesWyeThdCurrent OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A calculated value for the voltage total harmonic
distortion (THD) for phase to phase. Method of
calculation is not specified.
IEC 61850-7-4 attribute 'ThdA'."
::= { eoACPwrAttributesWyePhaseEntry 8 }
eoACPwrAttributesWyeThdPhaseToNeutralVoltage OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A calculated value of the voltage total harmonic
distortion (THD) for phase to neutral. IEC 61850-7-4
attribute 'ThdPhV'."
::= { eoACPwrAttributesWyePhaseEntry 9 }
-- Conformance
powerAttributesMIBCompliances OBJECT IDENTIFIER
::= { powerAttributesMIB 2 }
powerAttributesMIBGroups OBJECT IDENTIFIER
::= { powerAttributesMIB 3 }
powerAttributesMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented with support for read-
create, then such an implementation can claim full
compliance. Such devices can then be both monitored and
configured with this MIB.
Module Compliance of RFC 6933 with respect to
entity4CRCompliance MUST be supported which requires
implementation of four MIB objects: entPhysicalIndex,
entPhysicalClass, entPhysicalName, and entPhysicalUUID."
REFERENCE
"RFC 6933: Entity MIB (Version 4)"
MODULE -- this module
MANDATORY-GROUPS {
powerACPwrAttributesMIBTableGroup
}
GROUP powerACPwrAttributesOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have
to implement."
GROUP powerACPwrAttributesDelPhaseMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to implement."
GROUP powerACPwrAttributesWyePhaseMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to implement."
::= { powerAttributesMIBCompliances 1 }
-- Units of Conformance powerACPwrAttributesMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object entPhysicalIndex is NOT
-- included since it is not-accessible
eoACPwrAttributesAvgVoltage,
eoACPwrAttributesAvgCurrent,
eoACPwrAttributesFrequency,
eoACPwrAttributesPowerUnitMultiplier,
eoACPwrAttributesPowerAccuracy,
eoACPwrAttributesTotalActivePower,
eoACPwrAttributesTotalReactivePower,
eoACPwrAttributesTotalApparentPower,
eoACPwrAttributesTotalPowerFactor
}
STATUS current
DESCRIPTION
"This group contains the collection of all the power
attributes objects related to the Energy Object."
::= { powerAttributesMIBGroups 1 }
powerACPwrAttributesOptionalMIBTableGroup OBJECT-GROUP
OBJECTS {
eoACPwrAttributesConfiguration,
eoACPwrAttributesThdCurrent,
eoACPwrAttributesThdVoltage
}
STATUS current
DESCRIPTION
"This group contains the collection of all the power
attributes objects related to the Energy Object."
::= { powerAttributesMIBGroups 2 }
powerACPwrAttributesDelPhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object entPhysicalIndex and
-- eoACPwrAttributesDelPhaseIndex are NOT
-- included since they are not-accessible
eoACPwrAttributesDelPhaseToNextPhaseVoltage,
eoACPwrAttributesDelThdPhaseToNextPhaseVoltage
}
STATUS current
DESCRIPTION
"This group contains the collection of all power
attributes of a phase in a DEL three-phase power system."
::= { powerAttributesMIBGroups 3 }
powerACPwrAttributesWyePhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object entPhysicalIndex and
-- eoACPwrAttributesWyePhaseIndex are NOT
-- included since they are not-accessible
eoACPwrAttributesWyePhaseToNeutralVoltage,
eoACPwrAttributesWyeCurrent,
eoACPwrAttributesWyeActivePower,
eoACPwrAttributesWyeReactivePower,
eoACPwrAttributesWyeApparentPower,
eoACPwrAttributesWyePowerFactor,
eoACPwrAttributesWyeThdPhaseToNeutralVoltage,
eoACPwrAttributesWyeThdCurrent
}
STATUS current
DESCRIPTION
"This group contains the collection of all power
attributes of a phase in a WYE three-phase power system."
::= { powerAttributesMIBGroups 4 }
END10. Security Considerations 🔐
Okay bestie, this part is serious, so let's get into it 🫶. There are a bunch of management objects in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. These objects can be sensitive or vulnerable in some network environments 🙈. Supporting SET operations in a non-secure environment, without proper protection, opens devices up to attack 💀. Here are the tables and objects, plus how sensitive or vulnerable they are:
- Unauthorized changes to the eoPowerOperState (via the eoPowerAdminState ) MAY disrupt the power settings of the differentEnergy Objects and, therefore, the state of functionality of the respective Energy Objects.
- Unauthorized changes to the eoEnergyParametersTable MAY disrupt energy measurement in the eoEnergyTable table.
Real talk, SNMP versions before SNMPv3 did not have adequate security 😭. Even if the network itself is secure (for example, by using IPsec), there is no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not me being like "wait, anyone can just change it?" 💅
Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]). Implementations that claim compliance with the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353] 🦋.
Further, deploying 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 that the SNMP entity giving access to an instance of this MIB module is properly configured, so access to the objects is only given to those principals (users) who have legitimate rights to actually GET or SET (change/create/delete) them 👑.
Energy and power monitoring can reveal sensitive information about individuals' activities and habits. That's giving privacy alarm 🚨. Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988, and monitoring of individuals and homes should only occur with proper authorization 🌸.
11. IANA Considerations 🌈
The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values, which are recorded in the SMI Numbers registry 🧚:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
IANAPowerStateSet-MIB { mib-2 228 }
energyObjectMIB { mib-2 229 }
powerAttributesMIB { mib-2 230 }11.1. IANAPowerStateSet-MIB Module 🍓
The initial set of Power State Sets is specified in [RFC7326]. IANA maintains a Textual Convention PowerStateSet in the IANAPowerStateSet-MIB module (see Section 9.1), with the initial set of Power State Sets and the Power States within those Power State Sets as proposed in [RFC7326]. The current version of the PowerStateSet Textual Convention can be accessed at <http://www.iana.org/assignments/power-state-sets>.
New assignments (and potential deprecation) to Power State Sets shall be administered by IANA. The guidelines and procedures are specified in [RFC7326], and they will, as a consequence, update the PowerStateSet Textual Convention ✨.
12. References 📚
12.1. Normative References 💜
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>. - [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>. - [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999,
<http://www.rfc-editor.org/info/rfc2580>. - [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>. - [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003,
<http://www.rfc-editor.org/info/rfc3621>. - [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004,
<http://www.rfc-editor.org/info/rfc3826>. - [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, June 2009,
<http://www.rfc-editor.org/info/rfc5591>. - [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009,
<http://www.rfc-editor.org/info/rfc5592>. - [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, July 2011,
<http://www.rfc-editor.org/info/rfc6353>. - [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013,
<http://www.rfc-editor.org/info/rfc6933>. - [RFC7461] Parello, J., Claise, B., and M. Chandramouli, "Energy Object Context MIB", RFC 7461, March 2015,
<http://www.rfc-editor.org/info/rfc7461>. - [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005.
12.2. Informative References ✨
okay bestie, these are the "extra reading" refs 📚 they're not required to implement the thing, but they're the background the whole spec is built on. they're all in the code block below, copied exactly as written so nothing gets lost 💅
[RFC1628] Case, J., Ed., "UPS Management Information Base", RFC
1628, May 1994,
<http://www.rfc-editor.org/info/rfc1628>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002,
<http://www.rfc-editor.org/info/rfc3410>.
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB)
for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3418, December 2002,
<http://www.rfc-editor.org/info/rfc3418>.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity
Sensor Management Information Base", RFC 3433,
December 2002,
<http://www.rfc-editor.org/info/rfc3433>.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC
4268, November 2005,
<http://www.rfc-editor.org/info/rfc4268>.
[RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R.,
Dietz, T., and B. Claise, "Requirements for Energy
Management", RFC 6988, September 2013,
<http://www.rfc-editor.org/info/rfc6988>.
[RFC7326] Parello, J., Claise, B., Schoening, B., and J.
Quittek, "Energy Management Framework", RFC 7326,
September 2014,
<http://www.rfc-editor.org/info/rfc7326>.
[DMTF] DMTF, "Power State Management Profile", DSP1027,
Version 2.0, December 2009,
http://www.dmtf.org/sites/default/files/standards
/documents/DSP1027_2.0.0.pdf
[EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
"Energy Management (EMAN) Applicability Statement",
Work in Progress, draft-ietf-eman-applicability-
statement-08, December 2014.
[IEC.61850-7-4] International Electrotechnical Commission,
"Communication networks and systems for power utility
automation -- Part 7-4: Basic communication
structure -- Compatible logical node classes and
data object classes", March 2010.
[IEC.62053-21] International Electrotechnical Commission,
"Electricity metering equipment (a.c.) -- Particular
requirements -- Part 21: Static meters for active
energy (classes 1 and 2)", January 2003.
[IEC.62053-22] International Electrotechnical Commission,
"Electricity metering equipment (a.c.) -- Particular
requirements -- Part 22: Static meters for active
energy (classes 0,2 S and 0,5 S)", January 2003.
[IEEE1621] "Standard for User Interface Elements in Power
Control of Electronic Devices Employed in
Office/Consumer Environments", IEEE 1621, December
2004.Acknowledgments 🫶
okay the shoutouts 🥹 the authors want to thank Shamita Pisal for her prototype of this MIB module and her super valuable feedback 💖 they also want to thank Michael Brown for making the text so much better, like dramatically better ✨
Juergen Schoenwalder gets a big thank you for proposing the design of the Textual Convention for PowerStateSet, and Ira McDonald gets one for his feedback 🌸 Laurent Guise deserves special appreciation for reviewing and weighing in on power quality measurements ⚡ and Minoru Teraoka and Hiroto Ogaki get thanks for all the comments on the design of the EnergyTable 🎀
Alan Luchuk gets a huge thank you for the detailed review of the MIB and his comments 🔥
And finally, thanks to the EMAN chairs, Nevil Brownlee and Tom Nadeau 👑 the real MVPs 🧚
Contributors 🌈
this document is literally the result of two separate starter proposals getting merged together 🦋 the people below made big contributions, either to one of the original proposals or to this document itself:
John Parello
Rolf Winter
Dominique DudkowskiAuthors' Addresses 💅
and here are the people who actually wrote it, with their addresses and contact info, copied exactly so you can reach them 📬
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2409
EMail: moulchan@cisco.com
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
United States
EMail: brad.schoening@verizon.net
Juergen Quittek
NEC Europe, Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-115
EMail: quittek@neclab.eu
Thomas Dietz
NEC Europe, Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@neclab.euand that's the whole spec, bestie 🌈✨ you made it through all 13 parts 😭🫶
📦 where this page comes from
- ietf: rfc7460 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms