Network Working Group M. Chandramouli
B. Claise
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track B. Schoening
Expires: August 14 2014 Independent Consultant
J. Quittek
T. Dietz
NEC Europe Ltd.
February 14, 2014
Power and Energy Monitoring MIBdraft-ietf-eman-energy-monitoring-mib-09
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 2014.
<Claise, et. Al> Expires August 14, 2014 [Page 1]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Abstract
This document defines a subset of the Management Information
Base (MIB) for power and energy monitoring of devices.
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].
Table of Contents
1. Introduction.............................................. 32. The Internet-Standard Management Framework................ 43. Use Cases................................................. 44. Terminology............................................... 45. Architecture Concepts Applied to the MIB Modules.......... 55.1. Energy Object Tables.................................... 55.1.1. ENERGY-OBJECT-MIB..................................... 55.1.2. POWER-ATTRIBUTES-MIB.................................. 75.1.3. UML Diagram........................................... 95.2. Energy Object Identity................................. 115.3. Power State............................................ 125.3.1. Power State Set.................................135.4. Energy Object Usage Information........................ 135.5. Optional Power Usage Attributes........................ 145.6. Optional Energy Measurement............................ 145.7. Fault Management....................................... 18<Claise, et. Al> Expires August 14, 2014 [Page 2]

Internet-Draft <Power and Energy Monitoring MIB> February 20146. Discovery................................................ 187. Link with the other IETF MIBs............................ 197.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB...197.2. Link with the ENTITY-STATE MIB.......................207.3. Link with the POWER-OVER-ETHERNET MIB................217.4. Link with the UPS MIB................................217.5. Link with the LLDP and LLDP-MED MIBs.................228. Structure of the MIB..................................... 239. MIB Definitions.......................................... 2410. Implementation Status................................... 6210.1. SNMP Research......................................... 6210.2. Cisco Systems......................................... 6211. Security Considerations................................. 6312. IANA Considerations..................................... 6413. Contributors............................................ 6414. Acknowledgment.......................................... 6515. References.............................................. 6515.1. Normative References.................................. 6515.2. Informative References................................ 661. Introduction
This document 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 in this
document are designed to provide a model for energy management,
which includes monitoring for Power State and energy consumption
of networked elements. This MIB takes into account the Energy
Management Framework [EMAN-FMWK], which, in turn, is based on
the Requirements for Energy Management [RFC6988].
Energy management can be applied to devices in communication
networks. Target devices for this specification 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. Target devices and the use cases for Energy
Management are discussed in Energy Management Applicability
Statement [EMAN-AS].
Where applicable, device monitoring extends to the individual
components of the device and to any attached dependent devices.
For example: A device can contain components that are
independent from a power-state point of view, such as line
cards, processor cards, hard drives. A device can also have
dependent attached devices, such as a switch with PoE endpoints
or a power distribution unit with attached endpoints.
<Claise, et. Al> Expires August 14, 2014 [Page 3]

Internet-Draft <Power and Energy Monitoring MIB> February 20142. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. MIB objects are
generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information
(SMI). This memo specifies MIB modules that are compliant to
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 for networking
devices are specified in [RFC6988]. The requirements in
[RFC6988] cover devices typically found in communications
networks, such as 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. Accordingly, the scope of the MIB modules in this
document are broader than that specified in [RFC6988]. Several
use cases for Energy Management have been identified in the
"Energy Management (EMAN) Applicability Statement" [EMAN-AS].
4. Terminology
Please refer to [EMAN-FMWK] for the definitions of the
following terminology used in this draft.
Energy Management
Energy Management System (EnMS)
Energy Monitoring
Energy Control
electrical equipment
non-electrical equipment (mechanical equipment)
device
component
power inlet
<Claise, et. Al> Expires August 14, 2014 [Page 4]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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 Set
5. Architecture Concepts Applied to the MIB Modules
This section describes the concepts specified in the Energy
Management Framework [EMAN-FMWK] that pertain to power usage,
with specific information related to the MIB module specified in
this document. This subsection maps concepts developed in the
Energy Management Framework [EMAN-FMWK].
The Energy Monitoring MIB has 2 independent MIB modules, ENERGY-
OBJECT-MIB and POWER-ATTRIBUTES-MIB. The first, ENERGY-OBJECT-
MIB, is focused on measurement of 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 Tables5.1.1. ENERGY-OBJECT-MIB
The ENERGY-OBJECT-MIB module consists of five tables.
The first table is the eoMeterCapabilitiesTable. It indicates
the instrumentation available for each Energy Object. Entries
in this table indicate which other tables from the ENERGY-
OBJECT-MIB and POWER-ATTRIBUTES-MIB are available for each
Energy Object. The eoMeterCapabilitiesTable is indexed by
entPhysicalIndex [RFC6933].
The second table is the eoPowerTable. It reports the power
consumption of each Energy Object, as well as the units, sign,
measurement accuracy, and related objects. The eoPowerTable is
indexed by entPhysicalIndex.
<Claise, et. Al> Expires August 14, 2014 [Page 5]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
The third table is the eoPowerStateTable. For each Energy
Object, it reports information and statistics about the
supported Power States. The eoPowerStateTable is indexed by
entPhysicalIndex and eoPowerStateIndex.
The fourth table is the eoEnergyParametersTable. The entries in
this table configure the parameters of energy and demand
measurement collection. This table is indexed by
eoEnergyParametersIndex.
The fifth table is the eoEnergyTable. The entries in this table
provide a log of the energy and demand information. This table
is indexed by eoEnergyParametersIndex.
A "smidump-style" tree presentation of the MIB modules contained
in the draft is presented. The meaning of the three symbols in
is a compressed representation of the object's MAX-ACCESS clause
which may have the following values:
"not-accessible"->"---"
"accessible-for-notify"->"--n"
"read-only"->"r-n"
"read-write"->"rwn"
eoMeterCapabilitiesTable(1)
|
+---eoMeterCapabilitiesEntry(1)[entPhysicalIndex]
| |
| +---r-n BITS eoMeterCapability
|
eoPowerTable(2)
|
+---eoPowerEntry(1) [entPhysicalIndex]
| |
| +---r-n Integer32 eoPower(1)
| +-- r-n Integer32 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 IANAPowerStateSet eoPowerAdminState(8)
| +-- r-n IANAPowerStateSet eoPowerOperState(9)
| +-- r-n OwnerString eoPowerStateEnterReason(10)
|
|
+---eoPowerStateTable(3)
<Claise, et. Al> Expires August 14, 2014 [Page 6]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
domain, role description, and importance are specified. In
addition, the ENERGY-OBJECT-CONTEXT-MIB module specifies the
relationship between Energy Objects. There are several possible
relationships between Energy Objects, such as meteredBy,
metering, poweredBy, powering, aggregatedBy, and aggregating as
defined in the IANA-ENERGY-RELATION-MIB module [EMAN-AWARE-MIB].
5.3. Power State
An Energy Object may have energy conservation modes called Power
States. Between the ON and OFF states of a device, there can be
several intermediate energy saving modes. Those energy saving
modes are called Power States.
Power States, which represent universal states of power
management of an Energy Object, are specified by the
eoPowerState MIB object. The actual Power State is specified by
the eoPowerOperState MIB object, while the eoPowerAdminState MIB
object specifies the Power State requested for the Energy
Object. The difference between the values of eoPowerOperState
and eoPowerAdminState indicate that the Energy Object is busy
transitioning from eoPowerAdminState into the eoPowerOperState,
at which point it will update the content of eoPowerOperState.
In addition, the possible reason for change in Power State is
reported in eoPowerStateEnterReason. Regarding
eoPowerStateEnterReason, management stations and Energy Objects
should support any format of the owner string dictated by the
local policy of the organization. It is suggested that this
name contain at least the reason for the transition change, and
one or more of the following: IP address, management station
name, network manager's name, location, or phone number.
The MIB objects eoPowerOperState, eoPowerAdminState , and
eoPowerStateEnterReason are contained in the eoPowerTable MIB
table.
The eoPowerStateTable table enumerates the maximum power usage
in watts for every single supported Power State of each Power
State Set supported by the Energy Object. In addition,
PowerStateTable provides additional statistics such as
eoPowerStateEnterCount, i.e., the number of times an entity has
visited a particular Power State, and eoPowerStateTotalTime,
i.e., the total time spent in a particular Power State of an
Energy Object.
<Claise, et. Al> Expires August 14, 2014 [Page 12]

Internet-Draft <Power and Energy Monitoring MIB> February 20145.3.1. Power State Set
There are several standards and implementations of Power State
Sets. An Energy Object can support one or multiple Power State
Set implementations concurrently.
There are currently three Power State Sets defined:
IEEE1621(256) - [IEEE1621]
DMTF(512) - [DMTF]
EMAN(768) - [EMAN-FMWK]
The Power State Sets are listed in [EMAN-FMWK] along with each
Power State within the Power Set.
5.4. Energy Object Usage Information
For an Energy Object, power usage is reported using eoPower.
The magnitude of measurement is based on the
eoPowerUnitMultiplier MIB variable, based on the UnitMultiplier
Textual Convention (TC). Power measurement magnitude should
conform to the IEC 62053-21 [IEC.62053-21] and IEC 62053-22
[IEC.62053-22] definition of unit multiplier for the SI (System
International) units of measure. Measured values are
represented in SI units obtained by BaseValue * 10 raised to the
power of the unit multiplier.
For example, if current power usage of an Energy Object is 3, it
could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of
eoPowerUnitMultiplier. Note that other measurements throughout
the two MIB modules in this document use the same mechanism,
including eoPowerStatePowerUnitMultiplier,
eoEnergyUnitMultiplier, and
eoACPwrAttributesPowerUnitMultiplier.
In addition to knowing the usage and magnitude, it is useful to
know how an eoPower measurement was obtained. An NMS can use
this to account for the accuracy and nature of the reading
between different implementations. For this
eoPowerMeasurementLocal describes whether the measurements were
made at the device itself or from a remote source. The
eoPowerMeasurementCaliber describes the method that was used to
measure the power and can distinguish actual or estimated
values. There may be devices in the network, which may not be
able to measure or report power consumption. For those devices,
the object eoPowerMeasurementCaliber shall report that the
measurement mechanism is "unavailable" and the eoPower
measurement shall be "0".
<Claise, et. Al> Expires August 14, 2014 [Page 13]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
The nameplate power rating of an Energy Object is specified in
eoPowerNameplate MIB object.
5.5. Optional Power Usage Attributes
The optional POWER-ATTRIBUTES-MIB module can be implemented to
further describe power usage attributes measurement. The POWER-
ATTRIBUTES-MIB module is aligned with IEC 61850 7-2 standard to
describe AC measurements.
The POWER-ATTRIBUTES-MIB module contains a primary table,
eoACPwrAttributesTable, that defines power attributes
measurements for supported entPhysicalIndex entities, as a
sparse extension of the eoPowerTable (with entPhysicalIndex as
primary index). This eoACPwrAttributesTable table contains such
information as the configuration (single phase, DEL 3 phases,
WYE 3 phases), voltage, frequency, power accuracy, total
active/reactive power/apparent power, amperage, and voltage.
In case of 3-phase power, an additional table is populated with
Power Attributes measurements per phase (hence, double indexed
by the entPhysicalIndex and a phase index). This table,
describes attributes specific to either WYE or DEL
configurations.
In a DEL configuration, the 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, the eoACPwrAttributesWyePhaseTable
describes the phase-to-neutral power attributes measurements,
i.e., voltage, current, active/reactive/apparent power, and
power factor.
5.6. Optional Energy Measurement
It is only relevant to measure energy and demand when there are
actual power measurements obtained from measurement hardware. If
the eoPowerMeasurementCaliber MIB object has values of
unavailable, unknown, estimated, or presumed, then the energy
and demand values are not useful.
Two tables are introduced to characterize energy measurement of
an Energy Object: eoEnergyTable and eoEnergyParametersTable.
Both energy and demand information can be represented via the
eoEnergyTable. Energy information will be an accumulation with
no interval. Demand information can be represented.
The eoEnergyParametersTable consists of the parameters defining
<Claise, et. Al> Expires August 14, 2014 [Page 14]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
eoEnergyParametersIndex - an index of that specifies the setting
for collection of energy measurements for an Energy Object,
eoEnergyObjectIndex - linked to the entPhysicalIndex of the
Energy Object, the duration of measurement intervals in seconds,
(eoEnergyParametersIntervalLength), the number of successive
intervals to be stored in the eoEnergyTable,
(eoEnergyParametersIntervalNumber), the type of measurement
technique (eoEnergyParametersIntervalMode), and a sample rate
used to calculate the average (eoEnergyParametersSampleRate).
Judicious choice of the sampling rate will ensure accurate
measurement of energy while not imposing an excessive polling
burden.
There are three eoEnergyParametersIntervalMode types used for
energy measurement collection: period, sliding, and total. The
choices of the three different modes of collection are based on
IEC standard 61850-7-4. Note that multiple
eoEnergyParametersIntervalMode types MAY be configured
simultaneously. It is important to note that for a given Energy
Object, multiple modes (periodic, total, sliding window) of
energy measurement collection can be configured with the use of
eoEnergyParametersIndex. However, simultaneous measurement in
multiple modes for a given Energy Object depends on the Energy
Object capability.
These three eoEnergyParametersIntervalMode types are illustrated
by the following three figures, for which:
- The horizontal axis represents the current time, with the
symbol <--- L ---> expressing the
eoEnergyParametersIntervalLength, and the
eoEnergyCollectionStartTime is represented by S1, S2, S3, S4,
..., Sx where x is the value of
eoEnergyParametersIntervalNumber.
- The vertical axis represents the time interval of sampling and
the value of eoEnergyConsumed can be obtained at the end of the
sampling period. The symbol =========== denotes the duration of
the sampling period.
| | | =========== |
|============ | | |
| | | |
| |============ | |
| | | |
| <--- L ---> | <--- L ---> | <--- L ---> |
| | | |
S1 S2 S3 S4
<Claise, et. Al> Expires August 14, 2014 [Page 15]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
Figure 5 : Total eoEnergyParametersIntervalMode
A 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 which in
turn indicates if eoEnergyTable entries exist or not.
The eoEnergyTable consists of energy measurements in
eoEnergyConsumed, eoEnergyProvided and eoEnergyStored, the units
of the measured energy eoEnergyUnitMultiplier, and the maximum
observed energy within a window eoEnergyMaxConsumed,
eoEnergyMaxProduced.
Measurements of the total energy consumed by an Energy Object
may suffer from interruptions in the continuous measurement of
energy consumption. In order to indicate such interruptions,
the object eoEnergyDiscontinuityTime is provided for indicating
the time of the last interruption of total energy measurement.
eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418]
when the device was reset.
The following example illustrates the eoEnergyTable and
eoEnergyParametersTable:
First, in order to estimate energy, a time interval to sample
energy should be specified, i.e.,
eoEnergyParametersIntervalLength can be set to "900 seconds" or
15 minutes and the number of consecutive intervals over which
the maximum energy is calculated
(eoEnergyParametersIntervalNumber) as "10". The sampling rate
internal to the Energy Object for measurement of power usage
(eoEnergyParametersSampleRate) can be "1000 milliseconds", as
set by the Energy Object as a reasonable value. Then, the
eoEnergyParametersStatus is set to active to indicate that the
Energy Object should start monitoring the usage per the
eoEnergyTable.
The indices for the eoEnergyTable are eoEnergyParametersIndex,
which identifies the index for the setting of energy measurement
collection 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
<Claise, et. Al> Expires August 14, 2014 [Page 17]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
internal sampling rate (eoEnergyParametersSampleRate). While
choosing the values for the eoEnergyParametersIntervalLength and
eoEnergyParametersSampleRate, it is recommended to take into
consideration either the network element resources adequate to
process and store the sample values, and the mechanism used to
calculate the eoEnergyConsumed. The units are derived from
eoEnergyUnitMultiplier. For example, eoEnergyConsumed can be
"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 and that can
be "150 watt-hours".
The eoEnergyTable has a buffer to retain a certain number of
intervals, as defined by eoEnergyParametersIntervalNumber.
If the default value of "10" is kept, then the eoEnergyTable
contains 10 energy measurements, including the maximum.
Here is a brief explanation of how the maximum energy can be
calculated. The first observed energy measurement value is
taken to be the initial maximum. With each subsequent
measurement, based on numerical comparison, maximum energy may
be updated. The maximum value is retained as long as the
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" etc. Some of these requirements are fulfilled
explicitly by MIB objects such as eoPowerOperState,
eoPowerStateTotalTime and eoPowerStateEnterCount. Some of the
other requirements are met via the SNMP NOTIFICATION mechanism.
eoPowerStateChange SNMP notification which is generated when the
value of oPowerStateIndex, eoPowerOperState, or
eoPowerAdminState have changed.
6. Discovery
It is probable that most Energy Objects will require the
implementation of the ENERGY-OBJECT-CONTEXT-MIB [EMAN-AWARE-MIB]
as a prerequisite for this MIB module. In such a case,
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
<Claise, et. Al> Expires August 14, 2014 [Page 18]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
entPhysicalUUID from the ENTITY-MIB [RFC6933]. As the primary
index for the Energy Object, entPhysicalIndex is used: 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
[EMAN-AWARE-MIB], if available, in order to discover all the
Energy Objects and the relationships between those Energy
Objects. In the ENERGY-OBJECT-CONTEXT-MIB module tables, the
Energy Objects are indexed by the entPhysicalIndex.
From there, the NMS must poll the eoPowerStateTable (specified
in the ENERGY-OBJECT-MIB module in this document), which
enumerates, amongst other things, the maximum power usage. As
the entries in eoPowerStateTable table are indexed by the
Energy Object ( entPhysicalIndex) and by the Power State Set
(eoPowerStateIndex), the maximum power usage is discovered per
Energy Object, and the power usage per Power State of the Power
State Set. In other words, reading the eoPowerStateTable allows
the discovery of each Power State within every Power State Set
supported by the Energy Object.
If the Energy Object is an Aggregator, the MIB module would be
populated with the Energy Object relationship information, which
have 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 the
entPhysicalIndex to index the Energy Object.
7. Link with the other IETF MIBs7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIBRFC 6933 [RFC6933] defines the ENTITY-MIB module that lists the
physical entities of a networking device (router, switch, etc.)
and those physical entities indexed by entPhysicalIndex. From
an energy-management standpoint, the physical entities that
consume or produce energy are of interest.
RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that
provides a standardized way of obtaining information (current
value of the sensor, operational status of the sensor, and the
data units precision) from sensors embedded in networking
devices. Sensors are associated with each index of
entPhysicalIndex of the ENTITY-MIB [RFC6933]. While the focus
<Claise, et. Al> Expires August 14, 2014 [Page 19]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
of the Power and Energy Monitoring MIB is on measurement of
power usage of networking equipment indexed by the ENTITY-MIB,
this MIB supports a customized power scale for power measurement
and different Power States of networking equipment, and
functionality to configure the 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 [EMAN-AWARE-MIB].
The ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x
accuracy classes required for electricity (e.g., 1%, 2%, 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". The ANSI and IEC Standards are used for power
measurement and these standards require that we use an accuracy
class, not the scientific-number precision model specified in
RFC3433. The eoPowerAccuracy MIB object models this accuracy.
Note that eoPowerUnitMultipler represents the scale factor per
IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22],
which is a more logical representation for power measurements
(compared to entPhySensorScale), with the mantissa and the
exponent values X * 10 ^ Y.
Power measurements specifying the qualifier 'UNITS' for each
measured value in watts are used in the LLDP-EXT-MED-MIB, POE
[RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier
is used for the power measurement values.
One cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIB 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 such cases, 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
<Claise, et. Al> Expires August 14, 2014 [Page 20]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
(entStateStandby: unknown, hotStandby, coldStandby,
providingService).
From a power monitoring point of view, in contrast to the entity
operational states of entities, Power States are required, as
proposed in the Power and Energy Monitoring MIB module. 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",
"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
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 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 such cases, the
eoethPortIndex and eoethPortGrpIndex values contain the zero
value, via the new PethPsePortIndexOrZero and textual
PethPsePortGroupIndexOrZero conventions.
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.
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
<Claise, et. Al> Expires August 14, 2014 [Page 21]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
UPS based on output power and duration of probable power outage.
To properly provision UPS power in a data center or building, it
is 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 Power and Energy Monitoring MIB.
UPS MIB [RFC1628] provides information on the state of the UPS
network. Implementation of 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.).
- upsBattery group: Indicates the battery state
(upsbatteryStatus, upsEstimatedMinutesRemaining, etc.)
- upsInput group: 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 RMS volts and RMS
Amperes. They are not based on the EntitySensorDataScale and
EntitySensorDataPrecision of ENTITY-SENSOR-MIB.
Both the Power and Energy Monitoring MIB 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 [EMAN-FMWK].
7.5. Link with the LLDP and LLDP-MED MIBs
The LLDP Protocol 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 6 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 the power
discovery, which allows the endpoint device (such as a PoE
<Claise, et. Al> Expires August 14, 2014 [Page 22]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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.
Respectively, those TLVs provide information related to 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.
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 Power and Energy Monitoring MIB, it is
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
the 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 this 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 identification of the Energy Object and its
relationship to other entities in the network are addressed in
[EMAN-AWARE-MIB].
Logically, this MIB module is a sparse extension of the
ENERGY-OBJECT-CONTEXT-MIB module [EMAN-AWARE-MIB]. Thus the
following requirements which are applied to [EMAN-AWARE-MIB] are
also applicable. As a requirement for this MIB module, [EMAN-
AWARE-MIB] SHOULD be implemented and as Module Compliance of
ENTITY-MIB V4 [RFC6933] with respect to entity4CRCompliance MUST
be supported which requires 4 MIB objects: entPhysicalIndex,
entPhysicalClass, entPhysicalName and entPhysicalUUID MUST be
implemented.
<Claise, et. Al> Expires August 14, 2014 [Page 23]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
eoMeterCapabilitiesTable is useful to enable 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, it is possible for applications to
know which tables contain the information and are usable without
walking through the table and querying every element which
involves 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 describing the units of measurement
(eoPowerAccuracy, eoPowerUnitMultiplier), how power usage
measurement was obtained (eoPowerMeasurementCaliber), the
source of power measurement (eoPowerMeasurementLocal) and the
type of power (eoPowerCurrentType) are described.
An Energy Object may contain an optional eoPowerAttributes table
that describes the electrical characteristics associated with
the current Power State and usage.
An Energy Object may contain an optional eoEnergyTable to
describe energy measurement information over time.
An Energy Object may also contain optional battery information
associated with this entity.
9. MIB Definitions
-- ************************************************************
--
--
-- 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, TimeTicks
FROM SNMPv2-SMI
<Claise, et. Al> Expires August 14, 2014 [Page 24]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
::= { energyObjectMib 1 }
energyObjectMibConform OBJECT IDENTIFIER
::= { energyObjectMib 2 }
-- Textual Conventions
IANAPowerStateSet ::= 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 S, the named number with the value S * 256
+ X + 1 is allocated to represent the Power State."
REFERENCE
"http://www.iana.org/assignments/eman
RFC EDITOR NOTE: please change the previous URL if this is
not the correct one after IANA assigned it."
SYNTAX INTEGER {
other(0), -- indicates other set
unknown(255), -- unknown
ieee1621(256), -- indicates IEEE1621 set
ieee1621On(257),
ieee1621Off(258),
ieee1621Sleep(259),
dmtf(512), -- indicates DMTF set
dmtfOn(513),
dmtfSleepLight(514),
dmtfSleepDeep(515),
dmtfOffHard(516),
dmtfOffSoft(517),
dmtfHibernate(518),
dmtfPowerOffSoft(519),
<Claise, et. Al> Expires August 14, 2014 [Page 27]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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 specfied 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 can not measure or
report power, this option can be used."
::= { eoPowerEntry 1 }
eoPowerNameplate OBJECT-TYPE
SYNTAX Integer32
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 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)
<Claise, et. Al> Expires August 14, 2014 [Page 31]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates a percentage value, in 100ths 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 can not 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
<Claise, et. Al> Expires August 14, 2014 [Page 32]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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 IANAPowerStateSet
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
<Claise, et. Al> Expires August 14, 2014 [Page 33]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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/eman>
RFC-EDITOR: please check the location after IANA"
::= { eoPowerEntry 8 }
eoPowerOperState OBJECT-TYPE
SYNTAX IANAPowerStateSet
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/eman>
RFC-EDITOR: please check the location after IANA"
::= { 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.
<Claise, et. Al> Expires August 14, 2014 [Page 34]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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 IANAPowerStateSet,
eoPowerStateMaxPower INTEGER,
eoPowerStatePowerUnitMultiplier UnitMultiplier,
eoPowerStateTotalTime TimeTicks,
eoPowerStateEnterCount Counter32
<Claise, et. Al> Expires August 14, 2014 [Page 35]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
}
eoPowerStateIndex OBJECT-TYPE
SYNTAX IANAPowerStateSet
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 }
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
<Claise, et. Al> Expires August 14, 2014 [Page 36]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
of 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 Integer32,
eoEnergyParametersIntervalMode INTEGER,
eoEnergyParametersIntervalWindow TimeInterval,
eoEnergyParametersSampleRate Integer32,
eoEnergyParametersStatus RowStatus
}
<Claise, et. Al> Expires August 14, 2014 [Page 37]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
eoEnergyParametersIndex OBJECT-TYPE
SYNTAX Integer32 (0..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 seconds 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 Integer32
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 }
<Claise, et. Al> Expires August 14, 2014 [Page 38]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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, in order 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 Integer32
UNITS "Milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
<Claise, et. Al> Expires August 14, 2014 [Page 39]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
"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 }
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 8 }
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
<Claise, et. Al> Expires August 14, 2014 [Page 40]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
"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 (kW-Hr, MW-Hr, etc.)
indicated separately in eoEnergyUnitMultiplier."
::= { eoEnergyEntry 3 }
eoEnergyStored OBJECT-TYPE
SYNTAX Integer32
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 (kW-Hr, MW-Hr, 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 100ths
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 }
<Claise, et. Al> Expires August 14, 2014 [Page 42]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
eoEnergyMaxConsumed OBJECT-TYPE
SYNTAX Integer32
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 (kW-Hr, MW-Hr, etc.) indicated separately in
eoEnergyUnitMultiplier."
::= { eoEnergyEntry 7 }
eoEnergyMaxProduced OBJECT-TYPE
SYNTAX Integer32
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 (kW-Hr, MW-Hr, etc.) indicated
separately in eoEnergyEnergyUnitMultiplier."
::= { eoEnergyEntry 8 }
eoEnergyDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime [RFC3418] 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."
::= { eoEnergyEntry 9 }
-- Notifications
eoPowerEnableStatusNotification OBJECT-TYPE
SYNTAX TruthValue
<Claise, et. Al> Expires August 14, 2014 [Page 43]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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
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 [RFC6933]
with respect to entity4CRCompliance MUST
be supported which requires implementation
of 4 MIB objects: entPhysicalIndex, entPhysicalClass,
entPhysicalName and entPhysicalUUID."
MODULE -- this module
MANDATORY-GROUPS {
energyObjectMibTableGroup,
energyObjectMibStateTableGroup,
eoPowerEnableStatusNotificationGroup,
energyObjectMibNotifGroup
<Claise, et. Al> Expires August 14, 2014 [Page 44]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
}
GROUP energyObjectMibEnergyTableGroup
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of [RFC6933]
with respect to entity4CRCompliance MUST
be supported which requires implementation
of 4 MIB objects: entPhysicalIndex, entPhysicalClass,
entPhysicalName and entPhysicalUUID."
GROUP energyObjectMibEnergyParametersTableGroup
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of {RFC6933]
with respect to entity4CRCompliance MUST
be supported which requires implementation
of 4 MIB objects: entPhysicalIndex, entPhysicalClass,
entPhysicalName and entPhysicalUUID."
GROUP energyObjectMibMeterCapabilitiesTableGroup
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of [RFC6933]
with respect to entity4CRCompliance MUST
be supported which requires implementation
of 4 MIB objects: entPhysicalIndex, entPhysicalClass,
entPhysicalName and entPhysicalUUID."
::= { 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]
<Claise, et. Al> Expires August 14, 2014 [Page 45]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
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 3-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 3-phase power system."
::= { powerAttributesMIBGroups 4 }
END
<Claise, et. Al> Expires August 14, 2014 [Page 61]

Internet-Draft <Power and Energy Monitoring MIB> February 201410. Implementation Status
[Note to RFC Editor: Please remove this section and the
reference to [RFC6982] before publication.]
This section records the status of known implementations of the
EMAN-Monitoring MIB at the time of posting of this Internet-
Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended
to assist the IETF in its decision processes in progressing
drafts to RFCs.
10.1. SNMP Research
Organization: SNMP Research, Inc.
Maturity: Prototype based upon early drafts of the MIBs.
We anticipate updating it to more recent
documents as development schedules allow.
Coverage: Code was generated to implement all MIB objects
in ENTITY-MIB (Version 4),
ENERGY-OBJECT-CONTEXT-MIB,
ENERGY-OBJECT-MIB,
POWER-ATTRIBUTES-MIB,
and BATTERY-MIB.
Implementation experience: The documents are implementable.
Comments: Technical comments about the
ENERGY-OBJECT-CONTEXT-MIB,
ENERGY-OBJECT-MIB, and
BATTERY-MIB
were submitted to the EMAN Working Group
E-mail list.
Licensing: Proprietary, royalty licensing
Contact: Alan Luchuk, luchuk at snmp.com
URL: http://www.snmp.com/10.2. Cisco Systems
Organization: Cisco Systems, Inc.
<Claise, et. Al> Expires August 14, 2014 [Page 62]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
Maturity: Prototype based upon early version drafts of
the MIBs. We anticipate updating the MIB
modules as when the drafts are updated.
Coverage: Code was generated to implement all MIB objects
in the ENTITY-MIB (Version 4), and
ENERGY-OBJECT-MIB.
Implementation experience: The MIB modules are implemented
on Cisco router platforms to measure and report
router energy measurements. The documents are
implementable.
Licensing: Proprietary
URL: http://www.cisco.com11. Security Considerations
Some of the readable objects in these MIB modules (i.e., objects
with a MAX-ACCESS other than not-accessible) may be considered
sensitive or vulnerable in some network environments. It is
thus important to control even GET and/or NOTIFY access to these
objects and possibly to even encrypt the values of these objects
when sending them over the network via SNMP.
There are a number of management objects defined in these MIB
modules with a MAX-ACCESS clause of read-write and/or read-
create. Such objects MAY be considered sensitive or vulnerable
in some network environments. The support for SET operations in
a non-secure environment without proper protection can have a
negative effect on network operations. The following are the
tables and objects and their sensitivity/vulnerability:
- Unauthorized changes to the eoPowerOperState (via
theeoPowerAdminState ) 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.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example, by using
IPsec), there is still no secure control over who on the secure
network is allowed to access and GET/SET
(read/change/create/delete) the objects in these MIB modules.
<Claise, et. Al> Expires August 14, 2014 [Page 63]

Internet-Draft <Power and Energy Monitoring MIB> February 2014
It is RECOMMENDED that implementers consider the security
features as provided by the SNMPv3 framework (see [RFC3410],
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of these MIB modules is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to GET or SET (change/create/delete) them.
12. IANA Considerations
The MIB modules in this document use the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
energyObjectMIB { mib-2 xxx }
powerAttributesMIB { mib-2 yyy }
Editor's Note (to be removed prior to publication): IANA is
requested to assign a value for "XXX" and "YYY" under the 'mib-
2' subtree and to record the assignment in the SMI Numbers
registry. When the assignment has been made, the RFC Editor is
asked to replace "XXX" and "YYY"(here and in the MIB module)
with the assigned value and to remove this note.
13. Contributors
This document results from the merger of two initial proposals.
The following persons made significant contributions either in
one of the initial proposals or in this document.
John Parello
Rolf Winter
Dominique Dudkowski
<Claise, et. Al> Expires August 14, 2014 [Page 64]

Internet-Draft <Power and Energy Monitoring MIB> February 201414. Acknowledgment
The authors would like to thank Shamita Pisal for her prototype
of this MIB module, and her valuable feedback. The authors
would like to Michael Brown for improving the text dramatically.
The authors would like to thank Juergen Schoenwalder for
proposing the design of the Textual Convention for
IANAPowerStateSet and Ira McDonald for his feedback. Special
appreciation to Laurent Guise for his review and input on power
quality measurements. Thanks for the many comments on the design
of the EnergyTable from Minoru Teraoka and Hiroto Ogaki.
Many thanks to Alan Luchuk for the detailed review of the MIB
and his comments.
And finally, thanks to the EMAN chairs: Nevil Brownlee and Tom
Nadeau.
15. References15.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
[RFC6933] A. Bierman, D. Romascanu, J. Quittek and M.
Chandramouli " Entity MIB (Version 4)", RFC 6933, May
2013.
[EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili,
"draft-ietf-eman-energy-aware-mib-14", work in
progress, February 10 2013.
<Claise, et. Al> Expires August 14, 2014 [Page 65]