Network Working Group M. Chandramouli
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track B. Schoening
Expires: October 22, 2013 Independent Consultant
J. Quittek
T. Dietz
NEC Europe Ltd.
B. Claise
Cisco Systems, Inc.
April 22, 2013
Power and Energy Monitoring MIB
draft-ietf-eman-energy-monitoring-mib-05
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 October 2013.
<Claise, et. Al> Expires October 22, 2013 [Page 1]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Copyright Notice
Copyright (c) 2011 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............................................ 3
2. The Internet-Standard Management Framework.............. 4
3. Use Cases............................................... 4
4. Terminology............................................. 5
5. Architecture Concepts Applied to the MIB Module......... 6
5.1. Energy Object Information............................ 13
5.2. Power State.......................................... 13
5.2.1. Power State Set...............................14
5.2.2. IEEE1621 Power State Set......................15
5.2.3. DMTF Power State Set..........................15
5.2.4. EMAN Power State Set..........................16
5.3. Energy Object Usage Information...................... 19
5.4. Optional Power Usage Attributes...................... 20
5.5. Optional Energy Measurement.......................... 21
<Claise, et. Al> Expires October 22, 2013 [Page 2]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
5.6. Fault Management..................................... 25
6. Discovery.............................................. 25
7. Link with the other IETF MIBs.......................... 26
7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB..26
7.2. Link with the ENTITY-STATE MIB......................27
7.3. Link with the POWER-OVER-ETHERNET MIB...............28
7.4. Link with the UPS MIB...............................29
7.5. Link with the LLDP and LLDP-MED MIBs................30
8. Implementation Scenario................................ 30
9. Structure of the MIB................................... 33
10. MIB Definitions....................................... 34
11. Security Considerations............................... 74
12. IANA Considerations................................... 75
12.1. IANA Considerations for the MIB Modules............. 75
12.2. IANA Registration of new Power State Set............ 75
12.2.1. IANA Registration of the IEEE1621 Power State Set.76
12.2.2. IANA Registration of the DMTF Power State Set.....76
12.2.3. IANA Registration of the EMAN Power State Set.....77
12.3. Updating the Registration of Existing Power State
Sets...................................................... 77
12. Contributors.......................................... 77
13. Acknowledgment........................................ 78
14. Open Issues........................................... 78
15. References............................................ 78
15.2. Normative References..............................78
15.3. Informative References............................79
1. 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 [EMAN-REQ].
Energy management is applicable 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
<Claise, et. Al> Expires October 22, 2013 [Page 3]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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.
Devices and their sub-components may be characterized by the
power-related attributes of a physical entity present in the
ENTITY-MIB, even though the ENTITY-MIB compliance is not a
requirement due to the variety and broad base of devices
concerned with energy management.
2. 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 [EMAN-REQ]. The requirements in [EMAN-
REQ] 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 is broader than that specified in [EMAN-REQ]. Several
use cases for Energy Management have been identified in the
<Claise, et. Al> Expires October 22, 2013 [Page 4]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"Energy Management (EMAN) Applicability Statement" [EMAN-AS]. An
illustrative example scenario is presented in Section 8.
4. Terminology
Please refer to [EMAN-FMWK] for the definitions of the
following terminology used in this draft.
Device
Component
Energy Management
Energy Management System (EnMS)
ISO Energy Management System
Energy
Power
Demand
Power Attributes
Electrical Equipment
Non-Electrical Equipment (Mechanical Equipment)
Energy Object
Electrical Energy Object
Non-Electrical Energy Object
Energy Monitoring
Energy Control
Provide Energy:
Receive Energy:
Power Interface
<Claise, et. Al> Expires October 22, 2013 [Page 5]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Power Inlet
Power Outlet
Energy Management Domain
Energy Object Identification
Energy Object Context
Energy Object Relationship
Aggregation Relationship
Metering Relationship
Power Source Relationship
Proxy Relationship
Energy Object Parent
Energy Object Child
Power State
Power State Set
Nameplate Power
5. Architecture Concepts Applied to the MIB Module
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 to the section
"Architecture High Level Concepts" in the Power Monitoring
Architecture [EMAN-FMWK].
The Energy Monitoring MIB has 2 independent MIB modules. The
first MIB module energyObjectMib is focused on measurement of
power and energy. The second MIB module powerCharMIB is focused
on Power Attributes measurements.
The energyObjectMib MIB module consists of five tables.
<Claise, et. Al> Expires October 22, 2013 [Page 6]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
The first table is the eoMeterCapabilitiesTable. It indicates
the instrumentation available for each energy object. Thus, the
entries in this table indicate to the EnMS which other tables
from the ENERGY-OBJECT-MIB and POWER-ATTRIBUTES-MIB are
available for each energy object. The eoMeterCapabilitiesTable
is indexed by entPhysicalIndex.
The second table is the eoPowerTable. It returns the power
consumption of each energy object, as well as the units, sign,
measurement accuracy, and related objects. The eoPowerTable is
indexed by entPhysicalIndex.
The third table is the eoPowerStateTable. For each energy
object, it provides 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 the log the energy and demand information. This table
is indexed by eoEnergyParametersIndex.
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 eoMeasurementCaliber(5)
| +-- r-n INTEGER eoPowerCurrentType(6)
| +-- r-n INTEGER eoPowerOrigin(7)
| +-- rwn IANAPowerStateSet eoPowerAdminState(8)
| +-- r-n IANAPowerStateSet eoPowerOperState(9)
| +-- r-n OwnerString eoPowerStateEnterReason(10)
<Claise, et. Al> Expires October 22, 2013 [Page 7]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
|
|
+---eoPowerStateTable(3)
| +--eoPowerStateEntry(1)
| | [entPhysicalIndex, eoPowerStateIndex]
| |
| +-- --n IANAPowerStateSet eoPowerStateIndex(1)
| +-- r-n Interger32 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)
| +-- r-n TimeInterval
| eoEnergyParametersIntervalLength (3)
| +-- r-n Integer32
| eoEnergyParametersIntervalNumber (4)
| +-- r-n Integer32
| eoEnergyParametersIntervalMode (5)
| +-- r-n TimeInterval
| eoEnergyParametersIntervalWindow (6)
| +-- r-n Integer32
| eoEnergyParametersSampleRate (7)
| +-- r-n RowStatus eoEnergyParametersStatus (8)
|
+eoEnergyTable(5)
+---eoEnergyEntry(1) [ eoEnergyParametersIndex,
eoEnergyCollectionStartTime]
|
| +-- r-n TimeTicks eoEnergyCollectionStartTime (1)
| +-- r-n Integer32 eoEnergyConsumed (2)
| +-- r-n Integer32 eoEnergyProduced (3)
| +-- r-n Integer32 eoEnergyNet (4)
| +-- r-n UnitMultiplier
| eoEnergyUnitMultiplier (5)
| +-- r-n Integer32 eoEnergyAccuracy(6)
| +-- r-n Integer32 eoEnergyMaxConsumed (7)
| +-- r-n Integer32 eoEnergyMaxProduced (8)
| +-- r-n TimeTicks
| eoEnergyDiscontinuityTime(9)
<Claise, et. Al> Expires October 22, 2013 [Page 8]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
The powerAttributesMIB consists of four tables.
eoACPwrAttributesTable is indexed by entPhysicalIndex.
eoACPwrAttributesPhaseTable is indexed by entPhysicalIndex and
eoPhaseIndex. eoACPwrAttributesWyePhaseTable and
eoACPwrAttributesDelPhaseTable are indexed by entPhysicalIndex
and eoPhaseIndex.
eoACPwrAttributesTable(1)
|
+---eoACPwrAttributesEntry(1) [ entPhysicalIndex]
| |
| |
| +---r-n INTEGER eoACPwrAttributesConfiguration (1)
| +-- r-n Interger32 eoACPwrAttributesAvgVoltage (2)
| +-- r-n Integer32 eoACPwrAttributesAvgCurrent (3)
| +-- r-n Integer32 eoACPwrAttributesFrequency (4)
| +-- r-n UnitMultiplier
| eoACPwrAttributesPowerUnitMultiplier (5)
| +-- r-n Integer32 eoACPwrAttributesPowerAccuracy (6)
| +-- r-n Interger32
eoACPwrAttributesTotalActivePower (7)
| +-- r-n Integer32
| eoACPwrAttributesTotalReactivePower (8)
| +-- r-n Integer32
eoACPwrAttributesTotalApparentPower (9)
| +-- r-n Integer32
eoACPwrAttributesTotalPowerFactor (10)
| +-- r-n Integer32 eoACPwrAttributesThdAmpheres (11)
|
+eoACPwrAttributesPhaseTable(2)
+---EoACPwrAttributesPhaseEntry(1)[ entPhysicalIndex,
| | eoPhaseIndex]
| |
| +-- r-n Integer32 eoPhaseIndex (1)
| +-- r-n Integer32
| | eoACPwrAttributesPhaseAvgCurrent (2)
| +-- r-n Integer32
| | eoACPwrAttributesPhaseActivePower (3)
| +-- r-n Integer32
| | eoACPwrAttributesPhaseReactivePower (4)
| +-- r-n Integer32
| | eoACPwrAttributesPhaseApparentPower (5)
| +-- r-n Integer32
| | eoACPwrAttributesPhasePowerFactor (6)
| +-- r-n Integer32
| | eoACPwrAttributesPhaseImpedance (7)
| |
<Claise, et. Al> Expires October 22, 2013 [Page 9]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
+eoACPwrAttributesDelPhaseTable(3)
+-- eoACPwrAttributesDelPhaseEntry(1)
| | [entPhysicalIndex,
| | eoPhaseIndex]
| +-- r-n Integer32
| | eoACPwrAttributesDelPhaseToNextPhaseVoltage (1)
| +-- r-n Integer32
| |eoACPwrAttributesDelThdPhaseToNextPhaseVoltage (2)
| +-- r-n Integer32
eoACPwrAttributesDelThdCurrent (3)
| |
+eoACPwrAttributesWyePhaseTable(4)
+-- eoACPwrAttributesWyePhaseEntry(1)
| | [entPhysicalIndex,
| | eoPhaseIndex]
| +-- r-n Integer32
| | eoACPwrAttributesWyePhaseToNeutralVoltage (1)
| +-- r-n Integer32
| | eoACPwrAttributesWyePhaseCurrent (2)
| +-- r-n Integer32
| | eoACPwrAttributesWyeThdPhaseToNeutralVoltage (3)
| .
A UML representation of the MIB objects in the two MIB modules
are energyObjectMib and powerAttributesMIB are presented.
+-------------------------+
| Energy Object State |
| ----------------------- |
| eoPowerAdminState |
| eoPowerOperState |
| eoPowerStateEnterReason |
+-------------------------+
|
|
v
+-----------------------+
|---> | Energy Object ID (*) |
| | --------------------- |
| | entPhysicalIndex |
| | entPhysicalName |
| | entPhysicalUUID |
| +-----------------------+
|
| +-----------------------------+
<Claise, et. Al> Expires October 22, 2013 [Page 10]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
|---- | Energy Object Measurement |
| | --------------------------- |
| | eoPower |
| | eoPowerUnitMultiplier |
| | eoPowerAccuracy |
| +-----------------------------+
|
| +---------------------------+
|---- | Energy Object Attributes |
| | ------------------------- |
| | eoPowerNamePlate |
| | eoPowerMeasurementCaliber |
| | eoPowerCurrentType |
| | eoPowerOrigin |
| +---------------------------+
|
| +---------------------------------+
|---- |_Energy Object State Statistics |
|-------------------------------- |
| eoPowerStateMaxPower |
| eoPowerStatePowerUnitMultiplier |
| eoPowerStateTotalTime |
| eoPowerStateEnterCount |
+---------------------------------+
Figure 1:UML diagram for energyObjectMib
(*) Compliance with the ENERGY-AWARE-MIB
+----------------------------------+
| Energy ParametersTable |
| -------------------------------- |
| eoEnergyObjectIndex |
| eoEnergyParametersIndex |
| eoEnergyParametersIntervalLength |
| eoEnergyParametersIntervalNumber |
| eoEnergyParametersIntervalMode |
| eoEnergyParametersIntervalWindow |
| eoEnergyParametersSampleRate |
| eoEnergyParametersStatus |
+----------------------------------+
|
V
+----------------------------------+
| Energy Table |
| -------------------------------- |
| eoEnergyCollectionStartTime |
<Claise, et. Al> Expires October 22, 2013 [Page 11]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
| eoEnergyConsumed |
| eoEnergyProduced |
| eoEnergyNet |
| eoEnergyUnitMultiplier |
| eoEnergyAccuracy |
| eoEnergyMaxConsumed |
| eoEnergyMaxProduced |
| eoDiscontinuityTime |
+----------------------------------+
+-----------------------+
|---> | Energy Object ID (*) |
| | --------------------- |
| | entPhysicalIndex |
| | entPhysicalName |
| | entPhysicalUUID |
| +-----------------------+
|
| +-------------------------------------------+
|---- | Power Attributes |
| | ----------------------------------------- |
| | eoACPwrAttributesConfiguration |
| | eoACPwrAttributesAvgVoltage |
| | eoACPwrAttributesAvgCurrent |
| | eoACPwrAttributesFrequency |
| | eoACPwrAttributesPowerUnitMultiplier |
| | eoACPwrAttributesPowerAccuracy |
| | eoACPwrAttributesTotalActivePower |
| | eoACPwrAttributesTotalReactivePower |
| | eoACPwrAttributesTotalApparentPower |
| | eoACPwrAttributesTotalPowerFactor |
| | eoACPwrAttributesThdAmpheres |
| +-------------------------------------------+
|
|
| +-------------------------------------------+
|---- | Power Phase Attributes |
| | ----------------------------------------- |
| | eoPhaseIndex |
| | eoACPwrAttributesPhaseAvgCurrent |
| | eoACPwrAttributesPhaseActivePower |
| | eoACPwrAttributesPhaseReactivePower |
| | eoACPwrAttributesPhaseApparentPower |
| | eoACPwrAttributesPhasePowerFactor |
<Claise, et. Al> Expires October 22, 2013 [Page 12]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
| | eoACPwrAttributesPhaseImpedance |
| +-------------------------------------------+
|
|
| +-----------------------------------------------------+
|---- | AC Input DEL Configuration |
| | --------------------------------------------------- |
| | eoACPwrAttributesDelPhaseToNextPhaseVoltage |
| | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage |
| | eoACPwrAttributesDelThdCurrent |
| +-----------------------------------------------------+
|
| +---------------------------------------------------+
|---- | AC Input WYE Configuration |
| ------------------------------------------------- |
| eoACPwrAttributesWyePhaseToNeutralVoltage |
| eoACPwrAttributesWyePhaseCurrent |
| eoACPwrAttributesWyeThdPhaseToNeutralVoltage |
+---------------------------------------------------+
Figure 2: UML diagram for the powerAttributesMIB
(*) Compliance with the ENERGY-AWARE-MIB
5.1. Energy Object Information
Refer to the "Energy Object Information" section in [EMAN-FMWK]
for background information. An energy aware device is
considered as an instance of a Energy Object as defined in the
[EMAN-FMWK].
The Energy Object identity information is specified in the MIB
ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] primary table, i.e. the
eoTable. In this table, the context of the Energy Object such as
Domain, Role Description, Importance are specified. In addition,
the ENERGY-AWARE-MIB module returns the relationship between
Objects. There are several possible relationships between Parent
and Child as defined in [EMAN-AWARE-MIB] such as MeteredBy,
PoweredBy, AggregatedBy and ProxyedBy.
5.2. Power State
Refer to the "Power States" section in [EMAN-FMWK] for
background information.
<Claise, et. Al> Expires October 22, 2013 [Page 13]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 as 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 can be attributed 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:
eoPowerStateEnterCount, the number of 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.2.1. Power State Set
There are several standards and implementations of Power State
Sets. A Energy Object can support one or multiple Power State
Set implementation(s) concurrently.
There are currently three Power State Sets advocated:
unknown(0)
IEEE1621(256) - [IEEE1621]
<Claise, et. Al> Expires October 22, 2013 [Page 14]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
DMTF(512) - [DMTF]
EMAN(1024) - [EMAN-MONITORING-MIB]
The respective specific states related to each Power State Set
are specified in the following sections. The guidelines for
addition of new Power State Sets have been specified in the IANA
Considerations Section.
5.2.2. IEEE1621 Power State Set
The IEEE1621 Power State Set [IEEE1621] consists of 3
rudimentary states : on, off or sleep.
on(0) - The device is fully On and all features of the
device are in working mode.
off(1) - The device is mechanically switched off and does
not consume energy.
sleep(2) - The device is in a power saving mode, and some
features may not be available immediately.
The Textual Convention IANAPowerStateSet provides the proposed
numbering of the Power States within the IEEE1621 Power State
Set.
5.2.3. DMTF Power State Set
DMTF [DMTF] standards organization has defined a power profile
standard based on the CIM (Common Information Model) model that
consists of 15 power states ON (2), SleepLight (3), SleepDeep
(4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off-
Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10),
Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard
Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off-
Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF
standard is targeted for hosts and computers. Details of the
semantics of each Power State within the DMTF Power State Set
can be obtained from the DMTF Power State Management Profile
specification [DMTF].
DMTF power profile extends ACPI power states. The following
table provides a mapping between DMTF and ACPI Power State Set:
---------------------------------------------------
| DMTF | ACPI |
| Power State | Power State |
---------------------------------------------------
<Claise, et. Al> Expires October 22, 2013 [Page 15]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
| Reserved(0) | |
---------------------------------------------------
| Reserved(1) | |
---------------------------------------------------
| ON (2) | G0-S0 |
--------------------------------------------------
| Sleep-Light (3) | G1-S1 G1-S2 |
--------------------------------------------------
| Sleep-Deep (4) | G1-S3 |
--------------------------------------------------
| Power Cycle (Off-Soft) (5) | G2-S5 |
---------------------------------------------------
| Off-hard (6) | G3 |
---------------------------------------------------
| Hibernate (Off-Soft) (7) | G1-S4 |
---------------------------------------------------
| Off-Soft (8) | G2-S5 |
---------------------------------------------------
| Power Cycle (Off-Hard) (9) | G3 |
---------------------------------------------------
| Master Bus Reset (10) | G2-S5 |
---------------------------------------------------
| Diagnostic Interrupt (11) | G2-S5 |
---------------------------------------------------
| Off-Soft Graceful (12) | G2-S5 |
---------------------------------------------------
| Off-Hard Graceful (13) | G3 |
---------------------------------------------------
| MasterBus Reset Graceful (14) | G2-S5 |
---------------------------------------------------
| Power Cycle off-soft Graceful (15)| G2-S5 |
---------------------------------------------------
| Power Cycle off-hard Graceful (16)| G3 |
---------------------------------------------------
Figure 3: DMTF and ACPI Powe State Set Mapping
The Textual Convention IANAPowerStateSet contains the proposed
numbering of the Power States within the DMTF Power State Set.
5.2.4. EMAN Power State Set
The EMAN Power State Set represents an attempt for a uniform
standard approach to model the different levels of power
consumption of a device. The EMAN Power States are an expansion
of the basic Power States as defined in IEEE1621 that also
incorporate the Power States defined in ACPI and DMTF.
<Claise, et. Al> Expires October 22, 2013 [Page 16]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Therefore, in addition to the non-operational states as defined
in ACPI and DMTF standards, several intermediate operational
states have been defined.
There are twelve Power States, that expand on IEEE1621 on, sleep
and off. The expanded list of Power States are divided into six
operational states, and six non-operational states. The lowest
non-operational state is 1 and the highest is 6. Each non-
operational state corresponds to an ACPI state [ACPI]
corresponding to Global and System states between G3 (hard-off)
and G1 (sleeping). For Each operational state represent a
performance state, and may be mapped to ACPI states P0 (maximum
performance power) through P5 (minimum performance and minimum
power).
An Energy Object may have fewer Power States than twelve and
would then map several policy states to the same power state.
Energy Object with more than twelve states, would choose which
twelve to represent as power policy states.
In each of the non-operational states (from mechoff(1) to
ready(6)), the Power State preceding it is expected to have a
lower power consumption and a longer delay in returning to an
operational state:
IEEE1621 Power(off):
mechoff(1) : An off state where no entity features are
available. The entity is unavailable.
No energy is being consumed and the power
connector can be removed. This
corresponds to ACPI state G3.
softoff(2) : Similar to mechoff(1), but some
components remain powered or receive
trace power so that the entity
can be awakened from its off state. In
softoff(2), no context is saved and the
device typically requires a complete boot
when awakened. This corresponds to ACPI
state G2.
IEEE1621 Power(sleep)
hibernate(3): No entity features are available. The
entity may be awakened without requiring
a complete boot, but the time for
<Claise, et. Al> Expires October 22, 2013 [Page 17]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
availability is longer than sleep(4). An
example for state hibernate(3) is a save
to-disk state where DRAM context is not
maintained. Typically, energy consumption
is zero or close to zero. This
corresponds to state G1, S4 in ACPI.
sleep(4) : No entity features are available, except
for out-of-band management, for example
wake-up mechanisms. The time for
availability is longer than standby(5).
An example for state sleep(4) is a save-
to-RAM state, where DRAM context is
maintained. Typically, energy
consumption is close to zero. This
corresponds to state G1, S3 in ACPI.
standby(5) : No entity features are available, except
for out-of-band management, for example
wake-up mechanisms. This mode is analogous
to cold-standy. The time for availability
is longer than ready(6). For example, the
processor context is not maintained.
Typically, energy consumption is close to
zero. This corresponds to state G1, S2 in
ACPI.
ready(6) : No entity features are available, except
for out-of-band management, for example
wake-up mechanisms. This mode is
analogous to hot-standby. The entity can
be quickly transitioned into an
operational state. For example,
processors are not executing, but
processor context is maintained. This
corresponds to state G1, S1 in ACPI.
IEEE1621 Power(on):
lowMinus(7) : Indicates some entity features may not be
available and the entity has selected
measures/options to provide less than
low(8) usage. This corresponds to
ACPI State G0. This includes operational
states lowMinus(7) to full(12).
low(8) : Indicates some features may not be
available and the entity has taken
<Claise, et. Al> Expires October 22, 2013 [Page 18]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
measures or selected options to provide
less than mediumMinus(9) usage.
mediumMinus(9): Indicates all entity features are
available but the entity has taken
measures or selected options to provide
less than medium(10) usage.
medium(10) : Indicates all entity features are
available but the entity has taken
measures or selected options to provide
less than highMinus(11) usage.
highMinus(11): Indicates all entity features are
available and power usage is less
than high(12).
high(12) : Indicates all entity features are
available and the entity is consuming the
highest power.
The Textual Convention IANAPowerStateSet contains the proposed
numbering of the Power States within the EMAN Power State Set.
5.3. Energy Object Usage Information
Refer to the "Energy Object Usage Measurement" section in [EMAN-
FMWK] for background 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 scale.
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.
<Claise, et. Al> Expires October 22, 2013 [Page 19]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
In addition to knowing the usage and magnitude, it is useful to
know how a eoPower measurement was obtained. An NMS can use
this to account for the accuracy and nature of the reading
between different implementations. For this eoPowerOrigin
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 measurement
mechanism is "unavailable" and the eoPower measurement shall be
"0".
The nameplate power rating of an Energy Object is specified in
eoPowerNameplate MIB object.
5.4. Optional Power Usage Attributes
Refer to the "Optional Power Usage Attributes" section in
[EMAN-FMWK] for background information.
The optional powerAttributesMIB MIB module can be implemented to
further describe power usage attributes measurement. The
powerAttributesMIB MIB module adheres closely to the IEC 61850
7-2 standard to describe AC measurements.
The powerAttributesMIB MIB module contains a primary table, the
eoACPwrAttributesTable table, 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, the eoACPwrAttributesPhaseTable
additional table is populated with Power Attributes measurements
per phase (so double indexed by the entPhysicalIndex and
eoPhaseIndex). This table, which describes attributes common to
both WYE and DEL configurations, contains the average current,
active/reactive/apparent power, power factor, and impedance.
In case of 3-phase power with a DEL configuration, the
eoACPwrAttributesDelPhaseTable table describes the phase-to-
phase power attributes measurements, i.e., voltage and current.
<Claise, et. Al> Expires October 22, 2013 [Page 20]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
In case of 3-phase power with a Wye configuration, the
eoACPwrAttributesWyePhaseTable table describes the phase-to-
neutral power attributes measurements, i.e., voltage and
current.
5.5. Optional Energy Measurement
Refer to the "Optional Energy and demand Measurement" section in
[EMAN-FMWK] for the definition and terminology information.
It is relevant to measure energy and demand only 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
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 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.
<Claise, et. Al> Expires October 22, 2013 [Page 21]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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
Figure 4 : Period eoEnergyParametersIntervalMode
A eoEnergyParametersIntervalMode type of 'period' specifies non-
overlapping periodic measurements. Therefore, the next
eoEnergyCollectionStartTime is equal to the previous
eoEnergyCollectionStartTime plus
eoEnergyParametersIntervalLength. S2=S1+L; S3=S2+L, ...
|============ |
| |
| <--- L ---> |
| |
| |============ |
| | |
| | <--- L ---> |
| | |
| | |============ |
| | | |
| | | <--- L ---> |
| | | |
<Claise, et. Al> Expires October 22, 2013 [Page 22]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
| | | |============ |
| | | | |
| | | | <--- L ---> |
S1 | | | |
| | | |
| | | |
S2 | | |
| | |
| | |
S3 | |
| |
| |
S4
Figure 5 : Sliding eoEnergyParametersIntervalMode
A eoEnergyParametersIntervalMode type of 'sliding' specifies
overlapping periodic measurements.
| |
|========================= |
| |
| |
| |
| <--- Total length ---> |
| |
S1
Figure 6 : 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, eoEnergyProduced and eoEnergyNet, the units of
the measured energy eoEnergyUnitMultiplier, and the maximum
observed energy within a window eoEnergyMaxConsumed,
eoEnergyMaxProduced.
<Claise, et. Al> Expires October 22, 2013 [Page 23]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 (value 1) 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
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.
<Claise, et. Al> Expires October 22, 2013 [Page 24]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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, i.e. a month, 3 months, or a year.
5.6. Fault Management
[EMAN-REQ] 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(s) of ,eoPowerStateIndex, eoPowerOperState,
eoPowerAdminState have changed.
6. Discovery
It is foreseen that most Energy Objects will require the
implementation of the ENERGY-AWARE MIB [EMAN-AWARE-MIB] as a
prerequisite for this MIB module. In such a case, eoPowerTable
of the EMAN-MON-MIB is a sparse extension of the eoTable of
ENERGY-AWARE-MIB. Every Energy Object MUST implement
entPhysicalIndex, entPhysicalUUID and entPhysicalName from the
ENTITY-MIB [EMAN-ENTITY]. As the primary index for the Energy
Object, entPhysicalIndex is used.
The NMS must first poll the ENERGY-AWARE-MIB module [EMAN-AWARE-
MIB], if available, in order to discover all the Energy Objects
and the relationships between those (notion of Parent/Child).
In the ENERGY-AWARE-MIB module tables, the Energy Objects are
indexed by the entPhysicalIndex.
If an implementation of the ENERGY-AWARE-MIB module is available
in the local SNMP context, for the same Energy Object, the
entPhysicalIndex value (EMAN-AWARE-MIB) shall be used. The
entPhysicalIndex characterizes the Energy Object in the
energyObjectMib and the powerAttributesMIB MIB modules (this
document).
<Claise, et. Al> Expires October 22, 2013 [Page 25]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
From there, the NMS must poll the eoPowerStateTable (specified
in the energyObjectMib 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), 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, polling 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 or a Proxy, the MIB module
would be populated with the Energy Object Parent and Children
information, which have their own Energy Object index value
(entPhysicalIndex). However, the parent/child relationship must
be discovered thanks to the ENERGY-AWARE-MIB module.
Finally, the NMS can monitor the power attributes thanks to the
powerAttributesMIB MIB module, which reuses the 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
RFC 4133 [RFC4133] 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 [RFC4133]. While the focus
of the Power and Energy Monitoring MIB is on measurement of
power usage of networking equipment indexed by the ENTITY-MIB,
this MIB proposes a customized power scale for power measurement
and different power state states of networking equipment, and
functionality to configure the power state states.
When this MIB module is used to monitor the power usage of
devices like routers and switches, the ENTITY-MIB and ENTITY-
SENSOR MIB SHOULD be implemented. In such cases, the Energy
<Claise, et. Al> Expires October 22, 2013 [Page 26]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Objects are modeled by the entPhysicalIndex through the
entPhysicalEntity MIB object specified in the eoTable in the
ENERGY-AWARE-MIB MIB module [EMAN-AWARE-MIB].
However, the ENTITY-SENSOR MIB [RFC3433] does not have the ANSI
C12.x accuracy classes required for electricity (i.e., 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, monitoring
several other devices in the building, doing the 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, thanks to 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 [RFC4133], 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).
<Claise, et. Al> Expires October 22, 2013 [Page 27]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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.
The RFC introduces a concept of a port group on a switch to
define power monitoring and management policy and does not use
the entPhysicalIndex as the index. Indeed, the
pethMainPseConsumptionPower is indexed by the
pethMainPseGroupIndex, which has no mapping with the
entPhysicalIndex.
One cannot assume that the Power-over-Ethernet MIB is
implemented for all Energy Objects that need to be monitored.
A typical example is a converged building gateway, monitoring
several other devices in the building, doing the proxy between
SNMP and a protocol like BACNET. Another example is the home
energy controller. In such cases, the eoethPortIndex and
eoethPortGrpIndex values contain the zero value, thanks to new
PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero
conventions.
However, if the Power-over-Ethernet MIB [RFC3621] is supported,
the Energy Object eoethPortIndex and eoethPortGrpIndex contain
the pethPsePortIndex and pethPsePortGroupIndex, respectively.
As a consequence, the entPhysicalIndex MIB object has been kept
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.
<Claise, et. Al> Expires October 22, 2013 [Page 28]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 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 Parent and
any of the UPS meters or submeters are the Energy Object
Children.
<Claise, et. Al> Expires October 22, 2013 [Page 29]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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
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
in 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], thanks to the
eoethPortIndex and eoethPortGrpIndex.
The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to
eoPowerOrigin 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
eoPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and
local(3) can be mapped to remote(2) and self(1), respectively.
8. Implementation Scenario
<Claise, et. Al> Expires October 22, 2013 [Page 30]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
This section provides an illustrative example scenario for the
implementation of the Energy Object, including Energy Object
Parent and Energy Object Child relationships.
Example Scenario of a campus network: Switch with PoE Endpoints
with further connected devices.
The campus network consists of switches that provide LAN
connectivity. The switch with PoE ports is located in wiring
closet. PoE IP phones are connected to the switch. The IP
phones draw power from the PoE ports of the switch. In
addition, a PC is daisy-chained from the IP phone for LAN
connectivity.
The IP phone consumes power from the PoE switch, while the PC
consumes power from the wall outlet.
The switch has implementations of ENTITY-MIB [EMAN-ENTITY ] and
ENERGY-AWARE MIB [EMAN-AWARE-MIB] while the PC does not have
implementation of the ENTITY-MIB, but has an implementation of
ENERGY-AWARE MIB [EMAN-AWARE-MIB]. The switch has the following
attributes, entPhysicalIndex "1", and entPhysicalUUID "UUID
1000". The power usage of the switch is "440 Watts". The
switch does not have an Energy Object Parent.
The PoE switch port has the following attributes: The switch
port has entPhysicalIndex "3", and entPhysicalUUID is "UUID
1000:3". The power metered at the POE switch port is "12
watts". In this example, the POE switch port has the switch as
the Energy Object Parent, with its eoParentID of "1000".
The attributes of the PC are given below. The PC does not have
an entPhysicalIndex, and the entPhysicalUUID is "UUID 1000:57 ".
The PC has an Energy Object Parent, i.e. the switch port whose
entPhysicalUUID is "UUID 1000:3". The power usage of the PC is
"120 Watts" and is communicated to the switch port.
This example illustrates the important distinction between the
Energy Object Children: The IP phone draws power from the
switch, while the PC has LAN connectivity from the phone, but is
powered from the wall outlet. However, the Energy Object Parent
sends power control messages to both the Energy Object Children
(IP phone and PC) and the Children react to those messages.
<Claise, et. Al> Expires October 22, 2013 [Page 31]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
|-------------------------------------------------------|
| Switch |
|=======================================================|
| Switch | Switch | Switch | Switch |
| entPhyIndx | UUID |eoParentId | eoPower |
| ===================================================== |
| 1 | UUID 1000 | null | 440 |
| ===================================================== |
| |
| SWITCH PORT |
| ===================================================== |
| | Switch | Switch | Switch | Switch |
| | Port | Port | Port | Port |
| | entPhyIndx | UUID | eoParentId | eoPower |
| ===================================================== |
| | 3 | UUID 1000:3 | 1000 | 12 |
| ======================================================|
| ^
| |
|-----------------------------------|-------------------
|
|
POE IP PHONE |
|
|
======================================================
| IP phone | IP phone | IP phone | IP phone |
| entPhyIndx | UUID | eoParentID | eoPower |
======================================================
| Null | UUID 1000:31| UUID 1000:3 | 12 |
=======================================================
|
|
PC connected to switch via IP phone |
|
=====================================================
| PC | PC | PC | PC |
|entPhyIndx | UUID | eoParentID | eoPower |
=====================================================
| 7 | UUID 1000:57| UUID 1000:3 | 120 |
=====================================================
Figure 1: Example scenario
<Claise, et. Al> Expires October 22, 2013 [Page 32]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
9. Structure of the MIB
The primary MIB object in this MIB module is the
energyObjectMibObject. The eoPowerTable table of
energyObjectMibObject describes the power measurement attributes
of an Energy Object entity. The notion of identity of the 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
[EMAN-AWARE-MIB] module. 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 [EMAN-
ENTITY] with respect to entity4CRCompliance should be supported
which requires 3 MIB objects (entPhysicalIndex, entPhysicalName
and entPhysicalUUID ) MUST be implemented.
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 (eoPowerOrigin) and the type of power
(eoPowerCurrentTtype) 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.
<Claise, et. Al> Expires October 22, 2013 [Page 33]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
10. 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
TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval,
TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
FROM SNMPv2-CONF
OwnerString
FROM RMON-MIB
entPhysicalIndex, PhysicalIndex
FROM ENTITY-MIB;
energyObjectMib MODULE-IDENTITY
LAST-UPDATED "201210220000Z" -- 22 October 2012
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
<Claise, et. Al> Expires October 22, 2013 [Page 34]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Archive:
http://www.ietf.org/mail-archive/web/eman
Editors:
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
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
DE
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
<Claise, et. Al> Expires October 22, 2013 [Page 35]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"This MIB is used to monitor power and energy in
devices.
This table sparse extension of the eoTable
from the ENERGY-AWARE-MIB. As a requirement
[EMAN-AWARE-MIB] should be implemented.
Module Compliance of ENTITY-MIB v4
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
REVISION
"201210220000Z" -- 22 October 2012
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 xxx }
energyObjectMibNotifs OBJECT IDENTIFIER
::= { energyObjectMib 0 }
energyObjectMibObjects OBJECT IDENTIFIER
::= { 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.
<Claise, et. Al> Expires October 22, 2013 [Page 36]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 power state
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),
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),
<Claise, et. Al> Expires October 22, 2013 [Page 37]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
emanmedium(1034),
emanhighMinus(1035),
emanhigh(1036)
}
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
<Claise, et. Al> Expires October 22, 2013 [Page 38]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"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 indicate 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 }
<Claise, et. Al> Expires October 22, 2013 [Page 39]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 }
EoPowerEntry ::= SEQUENCE {
eoPower Integer32,
eoPowerNameplate Integer32,
eoPowerUnitMultiplier UnitMultiplier,
eoPowerAccuracy Integer32,
eoPowerMeasurementCaliber INTEGER,
eoPowerCurrentType INTEGER,
eoPowerOrigin INTEGER,
eoPowerAdminState IANAPowerStateSet,
eoPowerOperState IANAPowerStateSet,
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 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.
<Claise, et. Al> Expires October 22, 2013 [Page 40]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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. The eoPowerNameplate 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 100ths of a
percent, representing the assumed accuracy of the usage
reported by eoPower. For example: The value 1010 means
<Claise, et. Al> Expires October 22, 2013 [Page 41]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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),
presumed(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(2), estimated(3) or presumed (4).
- 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 presumed
(4) or estimated (3) 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.
<Claise, et. Al> Expires October 22, 2013 [Page 42]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
- presumed(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(1), direct
current DC(2), or that the current type is unknown(3)."
::= { eoPowerEntry 6 }
eoPowerOrigin OBJECT-TYPE
SYNTAX INTEGER {
self (1),
remote (2)
}
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 self(1) indicates the
measurement is performed by the entity, whereas remote(2)
indicates that the measurement was performed by another
entity."
::= { eoPowerEntry 7 }
eoPowerAdminState OBJECT-TYPE
SYNTAX IANAPowerStateSet
MAX-ACCESS read-write
STATUS current
DESCRIPTION
<Claise, et. Al> Expires October 22, 2013 [Page 43]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"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/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 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 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
<Claise, et. Al> Expires October 22, 2013 [Page 44]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 an expansion-dependent relationship on 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 1 (mechoff), 8 W at state 6 (ready), 11 W at state
8 (mediumMinus),and 11 W at state 12 (high):
State MaxUsage Units
1 (mechoff 0 W
2 (softoff) 0 W
3 (hibernate) 0 W
4 (sleep) 0 W
5 (standby) 0 W
6 (ready) 8 W
7 (lowMinus) 8 W
8 (low) 11 W
9 (medimMinus) 11 W
10 (medium) 11 W
11 (highMinus) 11 W
12 (high) 11 W
Furthermore, this table extends to return the total time
in each Power State, along with the number of times a
particular Power State was entered."
INDEX { entPhysicalIndex,
eoPowerStateIndex
<Claise, et. Al> Expires October 22, 2013 [Page 45]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
}
::= { eoPowerStateTable 1 }
EoPowerStateEntry ::= SEQUENCE {
eoPowerStateIndex IANAPowerStateSet,
eoPowerStateMaxPower Integer32,
eoPowerStatePowerUnitMultiplier UnitMultiplier,
eoPowerStateTotalTime TimeTicks,
eoPowerStateEnterCount Counter32
}
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 0xFFFF.
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
<Claise, et. Al> Expires October 22, 2013 [Page 46]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"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 hundredth
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 sense for energy
objects that an eoPowerMeasurementCaliber of actual(3)."
::= { energyObjectMibObjects 4 }
eoEnergyParametersEntry OBJECT-TYPE
SYNTAX EoEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls an energy measurement in
eoEnergyTable."
<Claise, et. Al> Expires October 22, 2013 [Page 47]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
INDEX { eoEnergyObjectIndex, eoEnergyParametersIndex }
::= { eoEnergyParametersTable 1 }
EoEnergyParametersEntry ::= SEQUENCE {
eoEnergyObjectIndex PhysicalIndex,
eoEnergyParametersIndex Integer32,
eoEnergyParametersIntervalLength TimeInterval,
eoEnergyParametersIntervalNumber Integer32,
eoEnergyParametersIntervalMode INTEGER,
eoEnergyParametersIntervalWindow TimeInterval,
eoEnergyParametersSampleRate Integer32,
eoEnergyParametersStatus RowStatus
}
eoEnergyObjectIndex OBJECT-TYPE
SYNTAX PhysicalIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique value, to identify the specific Energy Object
on which the measurement is applied, the same index used
in the eoPowerTable to identify the Energy Object."
::= { eoEnergyParametersEntry 1 }
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 capability 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 hundredth 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
<Claise, et. Al> Expires October 22, 2013 [Page 48]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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."
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
replacesthe 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
eoEnergyProduced 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
<Claise, et. Al> Expires October 22, 2013 [Page 49]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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
hundredth of seconds, in order to compute the average of
eoEnergyConsumed, eoEnergyProduced 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
"The sampling rate, in milliseconds, at which the Energy
Object should poll power usage in order to compute the
average eoEnergyConsumed, eoEnergyProduced 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."
DEFVAL { 1000 }
::= { eoEnergyParametersEntry 7 }
eoEnergyParametersStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
<Claise, et. Al> Expires October 22, 2013 [Page 50]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"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(1), all associated usage-data logged into
the eoEnergyTable will be deleted. The data can be
destroyed by setting up the eoEnergyParametersStatus to
destroy(2)."
::= {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
"An entry describing energy measurements."
INDEX { eoEnergyParametersIndex,
eoEnergyCollectionStartTime }
::= { eoEnergyTable 1 }
EoEnergyEntry ::= SEQUENCE {
eoEnergyCollectionStartTime TimeTicks,
eoEnergyConsumed Integer32,
eoEnergyProduced Integer32,
eoEnergyNet Integer32,
eoEnergyUnitMultiplier UnitMultiplier,
eoEnergyAccuracy Integer32,
eoEnergyMaxConsumed Integer32,
eoEnergyMaxProduced Integer32,
eoEnergyDiscontinuityTime TimeStamp
}
eoEnergyCollectionStartTime OBJECT-TYPE
SYNTAX TimeTicks
UNITS "hundredths of seconds"
<Claise, et. Al> Expires October 22, 2013 [Page 51]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 [RFC3418].
This object specifies the start time of the energy
measurement sample. "
::= { eoEnergyEntry 1 }
eoEnergyConsumed OBJECT-TYPE
SYNTAX Integer32
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 (kW-Hr, MW-Hr, etc.)
indicated separately in eoEnergyUnitMultiplier."
::= { eoEnergyEntry 2 }
eoEnergyProduced OBJECT-TYPE
SYNTAX Integer32
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 (kW-Hr, MW-Hr, etc.)
indicated separately in eoEnergyUnitMultiplier."
::= { eoEnergyEntry 3 }
eoEnergyNet OBJECT-TYPE
SYNTAX Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the resultant 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.)
<Claise, et. Al> Expires October 22, 2013 [Page 52]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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, eoEnergyProduced,
eoEnergyNet, 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 value, in 100ths of a
percent, representing the presumed accuracy 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 Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum energy ever observed in
eoEnergyConsumed since the monitoring started. 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
<Claise, et. Al> Expires October 22, 2013 [Page 53]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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, eoEnergyProduced or eoEnergyNet. 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
eoPowerStateChange NOTIFICATION-TYPE
OBJECTS {eoPowerAdminState, eoPowerOperState,
eoPowerStateEnterReason}
STATUS current
DESCRIPTION
"The SNMP entity generates the eoPowerStateChange when
the value(s) of eoPowerAdminState or eoPowerOperState,
in the context of the Power State Set, have changed for
the Energy Object represented by the entPhysicalIndex."
::= { energyObjectMibNotifs 1 }
-- Conformance
energyObjectMibCompliances OBJECT IDENTIFIER
::= { energyObjectMib 3 }
energyObjectMibGroups OBJECT IDENTIFIER
::= { energyObjectMib 4 }
<Claise, et. Al> Expires October 22, 2013 [Page 54]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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 [EMAN-ENTITY]
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
MODULE -- this module
MANDATORY-GROUPS {
energyObjectMibTableGroup,
energyObjectMibStateTableGroup,
energyObjectMibNotifGroup
}
GROUP energyObjectMibEnergyTableGroup
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of [EMAN-ENTITY]
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
GROUP energyObjectMibEnergyParametersTableGroup
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of {EMAN-ENTITY]
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
GROUP energyObjectMibMeterCapabilitiesTableGroup
<Claise, et. Al> Expires October 22, 2013 [Page 55]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
DESCRIPTION "A compliant implementation does not
have to implement.
Module Compliance of [EMAN-ENTITY]
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
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 [EMAN-ENTITY]
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
MODULE -- this module
MANDATORY-GROUPS {
energyObjectMibTableGroup,
energyObjectMibStateTableGroup,
energyObjectMibNotifGroup
}
OBJECT eoPowerOperState
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { energyObjectMibCompliances 2 }
-- Units of Conformance
energyObjectMibTableGroup OBJECT-GROUP
OBJECTS {
eoPower,
eoPowerNameplate,
eoPowerUnitMultiplier,
<Claise, et. Al> Expires October 22, 2013 [Page 56]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
eoPowerAccuracy,
eoPowerMeasurementCaliber,
eoPowerCurrentType,
eoPowerOrigin,
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 {
eoEnergyObjectIndex,
eoEnergyParametersIndex,
eoEnergyParametersIntervalLength,
eoEnergyParametersIntervalNumber,
eoEnergyParametersIntervalMode,
eoEnergyParametersIntervalWindow,
eoEnergyParametersSampleRate,
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
<Claise, et. Al> Expires October 22, 2013 [Page 57]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
OBJECTS {
-- Note that object
-- eoEnergyCollectionStartTime is not
-- included since it is not-accessible
eoEnergyConsumed,
eoEnergyProduced,
eoEnergyNet,
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 }
energyObjectMibNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
eoPowerStateChange
}
STATUS current
DESCRIPTION
"This group contains the notifications for the power and
energy monitoring MIB Module."
::= { energyObjectMibGroups 6 }
END
-- ************************************************************
--
-- This MIB module is used to monitor power attributes of
<Claise, et. Al> Expires October 22, 2013 [Page 58]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
-- 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
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF
UnitMultiplier
FROM ENERGY-OBJECT-MIB
OwnerString
FROM RMON-MIB
entPhysicalIndex
FROM ENTITY-MIB;
powerAttributesMIB MODULE-IDENTITY
LAST-UPDATED "201210220000Z" -- 22 October 2012
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
<Claise, et. Al> Expires October 22, 2013 [Page 59]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
IN
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
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
DE
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
"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,
[EMAN-AWARE-MIB] should be implemented.
<Claise, et. Al> Expires October 22, 2013 [Page 60]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Module Compliance of ENTITY-MIB v4
with respect to entity4CRCompliance should
be supported which requires implementation
of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
REVISION
"201210220000Z" -- 22 2012
DESCRIPTION
"Initial version, published as RFC YYY."
::= { mib-2 yyy }
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 defines 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 MMUX."
<Claise, et. Al> Expires October 22, 2013 [Page 61]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
INDEX {entPhysicalIndex }
::= { eoACPwrAttributesTable 1 }
EoACPwrAttributesEntry ::= SEQUENCE {
eoACPwrAttributesConfiguration INTEGER,
eoACPwrAttributesAvgVoltage Integer32,
eoACPwrAttributesAvgCurrent Integer32,
eoACPwrAttributesFrequency Integer32,
eoACPwrAttributesPowerUnitMultiplier UnitMultiplier,
eoACPwrAttributesPowerAccuracy Integer32,
eoACPwrAttributesTotalActivePower Integer32,
eoACPwrAttributesTotalReactivePower Integer32,
eoACPwrAttributesTotalApparentPower Integer32,
eoACPwrAttributesTotalPowerFactor Integer32,
eoACPwrAttributesThdAmpheres 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
<Claise, et. Al> Expires October 22, 2013 [Page 62]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"A measured value for average of the voltage measured
over an integral number of AC cycles For a 3-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 Integer32
UNITS "Ampheres"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the current per phase. IEC 61850-
7-4 attribute 'Amp'"
::= { eoACPwrAttributesEntry 3 }
eoACPwrAttributesFrequency OBJECT-TYPE
SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz
UNITS "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 3-phase power systems, this will also include
eoACPwrAttributesPhaseActivePower,
eoACPwrAttributesPhaseReactivePower and
eoACPwrAttributesPhaseApparentPower"
::= { eoACPwrAttributesEntry 5 }
eoACPwrAttributesPowerAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires October 22, 2013 [Page 63]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"This object indicates a percentage value, in 100ths 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 mesured 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 which
determines the apparent power. The apparent power is
the vector sum of real and reactive power.
Note: watts and volt-ampheres are equivalent units and
may be combined. IEC 61850-7-4 attribute 'TotVA'."
::= { eoACPwrAttributesEntry 9 }
eoACPwrAttributesTotalPowerFactor OBJECT-TYPE
<Claise, et. Al> Expires October 22, 2013 [Page 64]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
SYNTAX Integer32 (-10000..10000)
UNITS "hundredths of percent"
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 100ths of a
percent. A power factor of 100% indicates there is no
inductance load and thus no reactive power. 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 }
eoACPwrAttributesThdAmpheres 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). Method of calculation is not
specified. IEC 61850-7-4 attribute 'ThdVol'."
::= { eoACPwrAttributesEntry 12 }
eoACPwrAttributesPhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes 3-phase power attributes
measurements. It is a sparse extension of the
eoACPwrAttributesTable."
::= { powerAttributesMIBObjects 2 }
<Claise, et. Al> Expires October 22, 2013 [Page 65]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
eoACPwrAttributesPhaseEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes common 3-phase power attributes
measurements.
This optional table describes 3-phase power attributes
measurements, with three entries for each supported
entPhysicalIndex entity. Entities having single phase
power shall not have any entities.
This table describes attributes common to both WYE and
DEL. Entities having single phase power shall not have
any entries here. It is a sparse extension of the
eoACPwrAttributesTable.
These attributes correspond to IEC 61850-7.4 MMXU phase
measurements."
INDEX { entPhysicalIndex, eoPhaseIndex }
::= { eoACPwrAttributesPhaseTable 1 }
EoACPwrAttributesPhaseEntry ::= SEQUENCE {
eoPhaseIndex Integer32,
eoACPwrAttributesPhaseAvgCurrent Integer32,
eoACPwrAttributesPhaseActivePower Integer32,
eoACPwrAttributesPhaseReactivePower Integer32,
eoACPwrAttributesPhaseApparentPower Integer32,
eoACPwrAttributesPhasePowerFactor Integer32,
eoACPwrAttributesPhaseImpedance Integer32
}
eoPhaseIndex OBJECT-TYPE
SYNTAX Integer32 (0..359)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A phase angle typically corresponding to 0, 120, 240."
::= { eoACPwrAttributesPhaseEntry 1 }
eoACPwrAttributesPhaseAvgCurrent OBJECT-TYPE
SYNTAX Integer32
UNITS "Ampheres"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires October 22, 2013 [Page 66]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
"A measured value of the current per phase. IEC 61850-
7-4 attribute 'A'"
::= { eoACPwrAttributesPhaseEntry 2 }
eoACPwrAttributesPhaseActivePower 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 'W'"
::= { eoACPwrAttributesPhaseEntry 3 }
eoACPwrAttributesPhaseReactivePower 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 'VAr'"
::= { eoACPwrAttributesPhaseEntry 4 }
eoACPwrAttributesPhaseApparentPower 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. Active plus reactive power equals
the total apparent power.
Note: Watts and volt-ampheres are equivalent units and
may be combined. IEC 61850-7-4 attribute 'VA'."
::= { eoACPwrAttributesPhaseEntry 5 }
eoACPwrAttributesPhasePowerFactor OBJECT-TYPE
SYNTAX Integer32 (-10000..10000)
UNITS "hundredths of percent"
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
<Claise, et. Al> Expires October 22, 2013 [Page 67]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
or negative where the sign should be in lead/lag (IEEE)
form."
::= { eoACPwrAttributesPhaseEntry 6 }
eoACPwrAttributesPhaseImpedance OBJECT-TYPE
SYNTAX Integer32
UNITS "volt-amperes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of the impedance. IEC 61850-7-4 attribute
'Z'."
::= { eoACPwrAttributesPhaseEntry 7 }
eoACPwrAttributesDelPhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes DEL configuration phase-to-phase
power attributes measurements. This is a sparse
extension of the eoACPwrAttributesPhaseTable."
::= { powerAttributesMIBObjects 3 }
eoACPwrAttributesDelPhaseEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes power attributes attributes of a
phase in a DEL 3-phase power system. Voltage
measurements are provided both relative to each other
and zero.
Measured values are from IEC 61850-7-2 MMUX and THD from
MHAI objects.
For phase-to-phase measurements, the eoPhaseIndex is
compared against the following phase at +120 degrees.
Thus, the possible values are:
eoPhaseIndex Next Phase Angle
0 120
120 240
240 0
"
INDEX { entPhysicalIndex, eoPhaseIndex}
::= { eoACPwrAttributesDelPhaseTable 1}
<Claise, et. Al> Expires October 22, 2013 [Page 68]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
EoACPwrAttributesDelPhaseEntry ::= SEQUENCE {
eoACPwrAttributesDelPhaseToNextPhaseVoltage Integer32,
eoACPwrAttributesDelThdPhaseToNextPhaseVoltage Integer32,
eoACPwrAttributesDelThdCurrent Integer32
}
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
disortion for phase to next phase. Method of calculation
is not specified. IEC 61850-7-4 attribute 'ThdPPV'."
::= { eoACPwrAttributesDelPhaseEntry 3 }
eoACPwrAttributesDelThdCurrent 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
disortion (THD) for phase to phase. Method of
calculation is not specified.
IEC 61850-7-4 attribute 'ThdPPV'."
::= { eoACPwrAttributesDelPhaseEntry 4 }
eoACPwrAttributesWyePhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoACPwrAttributesWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes WYE configuration phase-to-neutral
power attributes measurements. This is a sparse
extension of the eoACPwrAttributesPhaseTable."
<Claise, et. Al> Expires October 22, 2013 [Page 69]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
::= { powerAttributesMIBObjects 4 }
eoACPwrAttributesWyePhaseEntry OBJECT-TYPE
SYNTAX EoACPwrAttributesWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes measurements of WYE configuration
with phase to neutral power attributes attributes. Three
entries are required for each supported entPhysicalIndex
entry. Voltage measurements are relative to neutral.
This is a sparse extension of the
eoACPwrAttributesPhaseTable.
Each entry describes power attributes attributes of one
phase of a WYE 3-phase power system.
Measured values are from IEC 61850-7-2 MMUX and THD from
MHAI objects."
INDEX { entPhysicalIndex, eoPhaseIndex }
::= { eoACPwrAttributesWyePhaseTable 1}
EoACPwrAttributesWyePhaseEntry ::= SEQUENCE {
eoACPwrAttributesWyePhaseToNeutralVoltage Integer32,
eoACPwrAttributesWyePhaseCurrent Integer32,
eoACPwrAttributesWyeThdPhaseToNeutralVoltage Integer32
}
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 'PhV'."
::= { eoACPwrAttributesWyePhaseEntry 1 }
eoACPwrAttributesWyePhaseCurrent OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 ampheres AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value of phase currents. IEC 61850-7-4
attribute 'A'."
<Claise, et. Al> Expires October 22, 2013 [Page 70]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
::= { eoACPwrAttributesWyePhaseEntry 2 }
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 3 }
-- 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 [EMAN-ENTITY] with respect to
entity4CRCompliance should be supported which requires
implementation of 3 MIB objects (entPhysicalIndex,
entPhysicalName and entPhysicalUUID)."
MODULE -- this module
MANDATORY-GROUPS {
powerACPwrAttributesMIBTableGroup
}
GROUP powerACPwrAttributesOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have
to implement."
<Claise, et. Al> Expires October 22, 2013 [Page 71]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
GROUP powerACPwrAttributesPhaseMIBTableGroup
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,
eoACPwrAttributesThdAmpheres,
<Claise, et. Al> Expires October 22, 2013 [Page 72]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
eoACPwrAttributesThdVoltage
}
STATUS current
DESCRIPTION
"This group contains the collection of all the power
attributes objects related to the Energy Object."
::= { powerAttributesMIBGroups 2 }
powerACPwrAttributesPhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object entPhysicalIndex is
-- NOT included since it is
-- not-accessible
eoACPwrAttributesPhaseAvgCurrent,
eoACPwrAttributesPhaseActivePower,
eoACPwrAttributesPhaseReactivePower,
eoACPwrAttributesPhaseApparentPower,
eoACPwrAttributesPhasePowerFactor,
eoACPwrAttributesPhaseImpedance
}
STATUS current
DESCRIPTION
"This group contains the collection of all 3-phase power
attributes objects related to the Power State."
::= { powerAttributesMIBGroups 3 }
powerACPwrAttributesDelPhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object entPhysicalIndex and
-- eoPhaseIndex are NOT included
-- since they are not-accessible
eoACPwrAttributesDelPhaseToNextPhaseVoltage,
eoACPwrAttributesDelThdPhaseToNextPhaseVoltage,
eoACPwrAttributesDelThdCurrent
}
STATUS current
DESCRIPTION
"This group contains the collection of all power
characteristic attributes of a phase in a DEL 3-phase
power system."
::= { powerAttributesMIBGroups 4 }
powerACPwrAttributesWyePhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
<Claise, et. Al> Expires October 22, 2013 [Page 73]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
-- Note that object entPhysicalIndex and
-- eoPhaseIndex are NOT included
-- since they are not-accessible
eoACPwrAttributesWyePhaseToNeutralVoltage,
eoACPwrAttributesWyePhaseCurrent,
eoACPwrAttributesWyeThdPhaseToNeutralVoltage
}
STATUS current
DESCRIPTION
"This group contains the collection of all WYE
configuration phase-to-neutral power attributes
measurements."
::= { powerAttributesMIBGroups 5 }
END
11. 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 October 22, 2013 [Page 74]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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
12.1. IANA Considerations for the MIB Modules
The MIB modules in this document uses 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 }
Additions to the MIB modules are subject to Expert Review
[RFC5226], i.e., review by one of a group of experts designated
by an IETF Area Director. The group of experts MUST check the
requested MIB objects for completeness and accuracy of the
description. Requests for MIB objects that duplicate the
functionality of existing objects SHOULD be declined. The
smallest available OIDs SHOULD be assigned to the new MIB
objects. The specification of new MIB objects SHOULD follow the
structure specified in Section 10. and MUST be published using
a well-established and persistent publication medium.
12.2. IANA Registration of new Power State Set
This document specifies an initial set of Power State Sets. The
list of these Power State Sets with their numeric identifiers is
given in Section 5.2.1. IANA maintains a Textual Convention
IANAPowerStateSet with the initial set of Power State Sets and
<Claise, et. Al> Expires October 22, 2013 [Page 75]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
the Power States within those Power State Sets. The current
version of Textual convention can be accessed
http://www.iana.org/assignments/IANAPowerStateSet
New Assignments to Power State Sets shall be administered by
IANA and the guidelines and procedures are listed in this
Section.
New assignments for Power State Set will be administered by IANA
through Expert Review [RFC5226], i.e., review by one of a group
of experts designated by an IETF Area Director. The group of
experts MUST check the requested state for completeness and
accuracy of the description. A pure vendor specific
implementation of Power State Set shall not be adopted; since it
would lead to proliferation of Power State Sets.
12.2.1. IANA Registration of the IEEE1621 Power State Set
This document specifies a set of values for the IEEE1621 Power
State Set [IEEE1621]. The list of these values with their
identifiers is given in Section 5.2.1. The Internet Assigned
Numbers Authority (IANA) created a new registry for IEEE1621
Power State Set identifiers and filled it with the initial
listin the Textual Convention IANAPowerStateSet..
New assignments (or potentially deprecation) for IEEE1621 Power
State Set will be administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts designated
by an IETF Area Director. The group of experts MUST check the
requested state for completeness and accuracy of the
description.
12.2.2. IANA Registration of the DMTF Power State Set
This document specifies a set of values for the DMTF Power State
Set. The list of these values with their identifiers is given
in Section 5.2.1. The Internet Assigned Numbers Authority
(IANA) has created a new registry for DMTF Power State Set
identifiers and filled it with the initial list in the Textual
Convention IANAPowerStateSet.
New assignments (or potentially deprecation) for DMTF Power
State Set will be administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts designated
by an IETF Area Director. The group of experts MUST check the
conformance with the DMTF standard [DMTF], on the top of
<Claise, et. Al> Expires October 22, 2013 [Page 76]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
checking for completeness and accuracy of the description.
12.2.3. IANA Registration of the EMAN Power State Set
This document specifies a set of values for the EMAN Power State
Set. The list of these values with their identifiers is given
in Section 5.2.1. The Internet Assigned Numbers Authority
(IANA) has created a new registry for EMAN Power State Set
identifiers and filled it with the initial list in the Textual
Convention IANAPowerStateSet.
New assignments (or potentially deprecation) for EMAN Power
State Set will be administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts designated
by an IETF Area Director. The group of experts MUST check the
requested state for completeness and accuracy of the
description.
12.3. Updating the Registration of Existing Power State Sets
IANA maintains a Textual Convention IANAPowerStateSet with the
initial set of Power State Sets and the Power States within
those Power State Sets. The current version of Textual
convention can be accessed
http://www.iana.org/assignments/IANAPowerStateSet
With the evolution of standards, over time, it may be important
to deprecate of some of the existing the Power State Sets or
some of the states within a Power State Set.
The registrant shall publish an Internet-draft or an individual
submission with the clear specification on deprecation of Power
State Sets or Power States registered with IANA. The
deprecation shall be administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts designated
by an IETF Area Director. The process should also allow for a
mechanism for cases where others have significant objections to
claims on deprecation of a registration. In cases, where the
registrant cannot be reached, IESG can designate an Expert to
modify the IANA registry for the deprecation.
12. 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
<Claise, et. Al> Expires October 22, 2013 [Page 77]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Rolf Winter
Dominique Dudkowski
13. 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.
We would like to thank Juergen Schoenwalder for proposing the
design of the Textual Convention for IANAPowerStateSet and Ira
McDonald for his feedback. Thanks for the many comments on the
design of the EnergyTable from Minoru Teraoka and Hiroto Ogaki.
14. Open Issues
OPEN ISSUE 1 check if all the requirements from [EMAN-REQ] are
covered. Nominal Voltage to be reported as a range ?
OPEN ISSUE 2 IANA Registered Power State Sets deferred to [EMAN-
FMWK]
OPEN ISSUE 3 Disabling eoPowerStateNotification
OPEN ISSUE 4 Units for eoParametersSampleRate in centiseconds to
match the same time scale
OPEN ISSUE 5 Windowing mechanism to determine the
eoEnergyMaxConsumed
15. References
15.2. Normative References
<Claise, et. Al> Expires October 22, 2013 [Page 78]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
[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.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version
3)", RFC 4133, August 2005.
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information
Base extension module for TIA-TR41.4 media endpoint
discovery information", July 2005.
[EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman-
energy-aware-mib-08 ", work in progress, April 2013.
15.3. Informative References
[RFC1628] S. Bradner, "UPS Management Information Base", RFC
1628, May 1994
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework ", RFC 3410, December
2002.
[RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", RFC3418,
December 2002.
<Claise, et. Al> Expires October 22, 2013 [Page 79]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity
Sensor Management Information Base", RFC 3433, December
2002.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC
4268, November 2005.
[RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,
"Guidelines for Writing an IANA Considerations Section
in RFCs ", BCP 26, RFC 5226, May 2008.
[EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
M. Chandramouli, " Requirements for Energy Management",
draft-ietf-eman-requirements-12, February 2013.
[EMAN-FMWK] Claise, B., Parello, J., Schoening, B., Quittek, J.
and Nordman, B, "Energy Management Framework", draft-
ietf-eman-framework-07, February 2013.
[EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz, T.,
Quittek, J. and B. Claise "Energy and Power Monitoring
MIB ", draft-ietf-eman-energy-monitoring-mib-04,
October 2012.
[EMAN-AS] Schoening, B., Chandramouli, M. and Nordman, B.
"Energy Management (EMAN) Applicability Statement",
draft-ietf-eman-applicability-statement-03, April 2013.
[EMAN-ENTITY] A. Bierman, D. Romascanu, J. Quittek and M.
Chandramouli " Entity MIB (Version 4)", draft-ietf-
eman-rfc4133bis-06, February 2013.
[EMAN-TERMINOLOGY] J. Parello, "Energy Management Terminology",
draft-parello-eman-definitions-07, work in progress,
October 2012.
[ACPI] "Advanced Configuration and Power Interface
Specification",http://www.acpi.info/DOWNLOADS/ACPIspec3
0b.pdf
[DMTF] "Power State Management Profile DMTF DSP1027 Version
2.0" December 2009
http://www.dmtf.org/sites/default/files/standards/docum
ents/DSP1027_2.0.0.pdf
[IEEE1621] "Standard for User Interface Elements in Power
Control of Electronic Devices Employed in
<Claise, et. Al> Expires October 22, 2013 [Page 80]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
Office/Consumer Environments", IEEE 1621, December
2004.
[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", 2010.
[IEC.62053-21] International Electrotechnical Commission,
"Electricity metering equipment (a.c.) Particular
requirements Part 22: Static meters for active energy
(classes 1 and 2)", 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)", 2003.
Authors' Addresses
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
<Claise, et. Al> Expires October 22, 2013 [Page 81]
Internet-Draft <Power and Energy Monitoring MIB> April 2013
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
DE
Phone: +49 6221 4342-128
Email: Thomas.Dietz@neclab.eu
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
<Claise, et. Al> Expires October 22, 2013 [Page 82]