Network Working Group M. Chandramouli
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track B. Schoening
Expires: November 23, 2011 Independent Consultant
J. Quittek
T. Dietz
NEC Europe Ltd.
B. Claise
Cisco Systems, Inc.
May 23, 2011
Power and Energy Monitoring MIB
draft-claise-energy-monitoring-mib-08
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 September, 2011.
<Claise, et. Al> Expires November 23 2011 [Page 1]
Internet-Draft <Energy Monitoring MIB> May 2011
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........... 5
5.1. Power Monitor Information.............................. 11
5.2. Power State............................................ 11
5.2.1. Power State Series............................. 12
5.2.2. IEEE1621 Power State Series.................... 12
5.2.3. DMTF Power State Series........................ 13
5.2.4. EMAN Power State Series........................ 14
5.3. Power Monitor Usage Information........................ 16
5.4. Optional Power Usage Quality........................... 17
5.5. Optional Energy Measurement............................ 18
5.6. Fault Management....................................... 22
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 2]
Internet-Draft <Energy Monitoring MIB> May 2011
6. Discovery................................................ 22
6.1. ENERGY-AWARE-MIB Module Implemented.................... 22
6.2. ENERGY-AWARE-MIB Module Not Implemented, ENTITY-MIB
Implemented................................................. 23
6.3. ENERGY-AWARE-MIB Module and ENTITY-MIB Not Implemented. 24
7. Link with the other IETF MIBs............................ 24
7.1. Link with the ENTITY MIB and the ENTITY-SENSOR MIB.. 24
7.2. Link with the ENTITY-STATE MIB...................... 25
7.3. Link with the POWER-OVER-ETHERNET MIB............... 26
7.4. Link with the UPS MIB............................... 26
7.5. Link with the LLDP and LLDP-MED MIBs................ 27
8. Implementation Scenarios................................. 28
9. Structure of the MIB..................................... 30
10. MIB Definitions......................................... 31
11. Security Considerations................................. 66
12. IANA Considerations..................................... 67
12.1. IANA Considerations for the MIB Modules............... 67
12.2. IANA Registration of new Power State Series........... 67
12.2.1. IANA Registration of the IEEE1621 Power State
Series................................................ 68
12.2.2. IANA Registration of the DMTF Power State Series68
12.2.3. IANA Registration of the EMAN Power State Series68
12. Contributors............................................ 69
13. Acknowledgment.......................................... 69
14. References.............................................. 69
14.2. Normative References............................... 69
14.3. Informative References............................. 70
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 Power
Management Architecture [EMAN-FRAMEWORK], which in turn, is
based on the Power Monitoring Requirements [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
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 3]
Internet-Draft <Energy Monitoring MIB> May 2011
systems, intelligent meters, home energy gateways, hosts and
servers, sensor proxies, etc.
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
"Energy Management (EMAN) Applicability Statement" [EMAN-AS].
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 4]
Internet-Draft <Energy Monitoring MIB> May 2011
Some of these scenarios are presented later in Section 8. "
Implementation Scenarios".
4. Terminology
The definitions of basic terms like Power Monitor, Power Monitor
Parent, Power Monitor Child, Power Monitor Meter Domain, Power
State can be found in the Power Management Architecture [EMAN-
FRAMEWORK].
EDITOR'S NOTE: it is foreseen that some more term will follow
such a Proxy, Aggregator, Energy Management, etc...
Power State Series
A Power State Series is defined as a well known sequence of
incremental energy saving modes of a device. This can be
viewed as an interface for the underlying device-implemented
power settings of a device. Examples of Power State Series
include DTMF [DMTF], IEEE1621 [IEEE1621], ACPI [ACPI] and
EMAN.
Power State
A Power State is defined as a specific power settings for a
Power Monitor (e.g., shut, hibernate, sleep, high). Within the
context of a Power State Series, the Power State of a device
is one of the power saving modes in that Power State Series.
EDITOR'S NOTE: the definitions of Power State Series and Power
State should be copied over in [EMAN-FRAMEWORK], and referenced
here.
5. Architecture Concepts Applied to the MIB Module
This section describes the concepts specified in the Power
Monitor Architecture [EMAN-FRAMEWORK] 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-FRAMEWORK].
The Energy Monitoring MIB has 2 independent MIB modules. The
first MIB module powerMonitorMIB is focused on measurement of
power and energy. The second MIB module powerQualityMIB is
focused on Power Quality measurement.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 5]
Internet-Draft <Energy Monitoring MIB> May 2011
The powerMonitorMIB MIB module consists of four tables. The
first table pmPowerTable is indexed by pmPowerIndex and
pmPowerStateSeriesIndex. The second table pmPowerStateTable
indexed by pmPowerIndex, pmPowerStateSeriesIndex and
pmPowerStateIndex. pmEnergyParametersTable and pmEnergyTable are
indexed by pmPowerIndex.
pmPowerTable(1)
|
+---pmPowerEntry(1) [pmPowerIndex, pmPowerStateSeries]
| |
| +-- --- Integer32 pmPowerIndex(1)
| +-- --- PowerStateSeries pmPowerStateSeries(2)
| +-- r-n Integer32 pmPower(3)
| +-- r-n Integer32 pmPowerNamePlate(4)
| +-- r-n UnitMultiplier pmPowerUnitMultiplier(5)
| +-- r-n Integer32 pmPowerAccuracy(6)
| +-- r-n INTEGER pmMeasurementCaliber(7)
| +-- r-n INTEGER pmPowerCurrentType(8)
| +-- r-n INTEGER pmPowerOrigin(9)
| +-- rwn Integer32 pmPowerAdminState(10)
| +-- r-n Integer32 pmPowerOperState(11)
| +-- r-n OwnerString pmPowerStateEnterReason(12)
| |
| |
+---pmPowerStateTable(2)
| +--pmPowerStateEntry(1)
| | [pmPowerIndex,
| | pmPowerStateSeries,
| | pmpowerStateIndex]
| +-- --- Integer32 pmPowerStateIndex(1)
| +-- r-n Interger32 pmPowerStateMaxPower (2)
| +-- r-n UnitMultiplier
| pmPowerStatePowerUnitMultiplier (3)
| +-- r-n TimeTicks pmPowerStateTotalTime(4)
| +-- r-n Counter64 pmPowerStateEnterCount(5)
|
+pmEnergyParametersTable(1)
+---pmEnergyParametersEntry(1) [pmPowerIndex]
|
| +-- r-n TimeInterval
| pmEnergyParametersIntervalLength (1)
| +-- r-n Integer32
| pmEnergyParametersIntervalNumber (2)
| +-- r-n Integer32
| pmEnergyParametersIntervalMode (3)
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 6]
Internet-Draft <Energy Monitoring MIB> May 2011
| +-- r-n TimeInterval
| pmEnergyParametersIntervalWindow (4)
| +-- r-n Integer32
| pmEnergyParametersSampleRate (5)
| +-- r-n RowStatus pmEnergyParametersStatus (6)
|
+pmEnergyTable(1)
+---pmEnergyEntry(1) [pmPowerIndex]
|
| +-- r-n TimeInterval pmEnergyIntervalStartTime (1)
| +-- r-n Integer32 pmEnergyIntervalEnergyUsed (2)
| +-- r-n UnitMultiplier
| pmEnergyIntervalEnergyUnitMultiplier (3)
| +-- r-n Integer32 pmEnergyIntervalMax (4)
| +-- r-n TimeTicks
| pmEnergyIntervalDiscontinuityTime(5)
| +-- r-n RowStatus pmEnergyParametersStatus (6)
The powerQualityMIB consists of four tables. PmACPwrQualityTable
is indexed by pmPowerIndex. PmACPwrQualityPhaseTable is indexed
by pmPowerIndex and pmPhaseIndex. pmACPwrQualityWyePhaseTable
and pmACPwrQualityDelPhaseTable are indexed by pmPowerIndex and
pmPhaseIndex.
pmPowerTable(1)
|
+---PmACPwrQualityEntry (1) [pmPowerIndex]
| |
| |
| +----- INTEGER pmACPwrQualityConfiguration (1)
| +-- r-n Interger32 pmACPwrQualityAvgVoltage (2)
| +-- r-n Integer32 pmACPwrQualityAvgCurrent (3)
| +-- r-n Integer32 pmACPwrQualityFrequency (4)
| +-- r-n UnitMultiplier
| pmACPwrQualityPowerUnitMultiplier (5)
| +-- r-n Integer32 pmACPwrQualityPowerAccuracy (6)
| +-- r-n Interger32 pmACPwrQualityTotalActivePower (7)
| +-- r-n Integer32
| pmACPwrQualityTotalReactivePower (8)
| +-- r-n Integer32 pmACPwrQualityTotalApparentPower (9)
| +-- r-n Integer32 pmACPwrQualityTotalPowerFactor(10)
| +-- r-n Integer32 pmACPwrQualityThdAmpheres (11)
|
+pmACPwrQualityPhaseTable (1)
+---PmACPwrQualityPhaseEntry(1)[pmPowerIndex,
| | pmPhaseIndex]
| |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 7]
Internet-Draft <Energy Monitoring MIB> May 2011
| +-- r-n Integer32 pmPhaseIndex (1)
| +-- r-n Integer32
| | pmACPwrQualityPhaseAvgCurrent (2)
| +-- r-n Integer32
| | pmACPwrQualityPhaseActivePower (3)
| +-- r-n Integer32
| | pmACPwrQualityPhaseReactivePower (4)
| +-- r-n Integer32
| | pmACPwrQualityPhaseApparentPower (5)
| +-- r-n Integer32
| | pmACPwrQualityPhasePowerFactor (6)
| +-- r-n Integer32
| | pmACPwrQualityPhaseImpedance (7)
| |
+pmACPwrQualityDelPhaseTable (1)
+-- pmACPwrQualityDelPhaseEntry(1)
| | [pmPowerIndex,
| | pmPhaseIndex]
| +-- r-n Integer32
| | pmACPwrQualityDelPhaseToNextPhaseVoltage (1)
| +-- r-n Integer32
| | pmACPwrQualityDelThdPhaseToNextPhaseVoltage (2)
| +-- r-n Integer32 pmACPwrQualityDelThdCurrent (3)
| |
+pmACPwrQualityWyePhaseTable (1)
+-- pmACPwrQualityWyePhaseEntry (1)
| | [pmPowerIndex,
| | pmPhaseIndex]
| +-- r-n Integer32
| | pmACPwrQualityWyePhaseToNeutralVoltage (1)
| +-- r-n Integer32
| | pmACPwrQualityWyePhaseCurrent (2)
| +-- r-n Integer32
| | pmACPwrQualityWyeThdPhaseToNeutralVoltage (3)
| .
A UML representation of the MIB objects in the two MIB modules
are powerMonitorMIB and powerQualityMIB are presented.
+--------------------------+
| PowerMonitor ID |
| |
| Energy-aware-MIB (*) |_ _
| | +---------------------------+
| | | |
| pmPowerIndex | |_ PowerMonitor Attributes |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 8]
Internet-Draft <Energy Monitoring MIB> May 2011
| pmPowerStateSeriesIndex | | |
+--------------------------+ | pmPowerNamePlate |
| | pmPowerMeasurementCaliber |
| | pmPowerOrigin |
_ | | pmPowerCurrentType____ _ |
| +---------------------------+
| |
| |
v v
+-----------------------------------------+
| PowerMonitor Measurement |
|_______________________________________ |
| pmPower |
| pmPowerUnitMultiplier |
| pmPowerAccuracy |
+-----------------------------------------+
^ | |
| | |
+-------------------------+ | v
| PowerMonitor State | | +------------------------+
| _______________________ | | | PowerMonitor State |
| pmPowerAdminState | | | Statistics |
| pmPowerOperState | | | |
| pmPowerStateEnterReason | | | pmPowerStateMaxPower |
+-------------------------+ | | pmPowerStateTotalTime |
| | pmPowerStateEnterCount |
| +------------------------+
|
|
v
+------------------------------------+
| Energy Table |
| _______________________ |
| pmEnergyIntervalStartTime |
| pmEnergyIntervalEnergyUsed |
| pmEnergyIntervalMax |
| pmEnergyIntervalDiscontinuityTime |
+------------------------------------+
Figure 1:UML diagram for powerMonitor MIB
(*) Link with the ENERGY-AWARE-MIB
+-------------------------------------+
| Power Quality |
| |
| pmACPwrQualityConfiguration |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 9]
Internet-Draft <Energy Monitoring MIB> May 2011
| pmACPwrQualityAvgVoltage |
| pmACPwrQualityAvgCurrent
| pmACPwrQualityFrequency |
| pmACPwrQualityPowerUnitMultiplier |
| pmACPwrQualityPowerAccuracy |
| pmACPwrQualityTotalActivePower |
| pmACPwrQualityTotalReactivePower |
| pmACPwrQualityTotalApparentPower |
| pmACPwrQualityTotalPowerFactor |
| pmACPwrQualityThdAmpheres |
+-------------------------------------+ ^
^ ^ |
| | -------
| ---- |
| | |
| | |
| | |
| | |
+-------------------------------------+ | |
| Power Phase Quality | | |
| | | |
| pmPhaseIndex | | |
| pmACPwrQualityPhaseAvgCurrent | | |
| pmACPwrQualityAvgCurrent | | |
| pmACPwrQualityFrequency | | |
| pmACPwrQualityPowerUnitMultiplier | | |
| pmACPwrQualityPowerAccuracy | | |
| pmACPwrQualityPhaseActivePower | | |
| pmACPwrQualityPhaseReactivePower | | |
| pmACPwrQualityPhaselApparentPower | | |
| pmACPwrQualityPhaseImpedance | | |
+-------------------------------------+ | |
| |
| |
+---------------------------------------------+ |
| Power Quality DEL Configuration | |
| | |
| pmACPwrQualityDelPhaseToNextPhaseVoltage | |
| pmACPwrQualityDelThdPhaseToNextPhaseVoltage | |
| pmACPwrQualityDelThdCurrent | |
+---------------------------------------------+ |
|
|
+---------------------------------------------+
| Power Quality WYE Configuration |
| |
| pmACPwrQualityWyePhaseToNeutralVoltage |
| pmACPwrQualityWyePhaseCurrent |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 10]
Internet-Draft <Energy Monitoring MIB> May 2011
| pmACPwrQualityWyeThdPhaseToNeutralVoltage |
+---------------------------------------------+
Figure 2: UML diagram for the powerQualityMIB
5.1. Power Monitor Information
Refer to the "Power Monitor Information" section in [EMAN-
FRAMEWORK] for background information. An energy aware device
is considered an instance of a Power Monitor as defined in the
[EMAN-FRAMEWORK].
The Power Monitor identity information is specified in the MIB
ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] primary table, i.e. the
pmTable.In this table, every Power Monitor SHOULD have a
printable name pmName, and MUST HAVE a unique Power Monitor
index pmIndex. The ENERGY-AWARE-MIB module returns the
relationship (parent/child) between Power Monitors.
EDITOR'S NOTE: this last sentence will have to be updated with
terms such as Aggregator, Proxy, etc... when the [EMAN-
FRAMEWORK] will stabilize.
5.2. Power State
Refer to the "Power Monitor States" section in [EMAN-FRAMEWORK]
for background information.
A Power Monitor 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 a Power Monitor, are specified by the pmPowerState
MIB object. The actual Power State is specified by the
pmPowerOperState MIB object, while the pmPowerAdminState MIB
object specifies the Power State requested for the Power
Monitor. The difference between the values of pmPowerOperState
and pmPowerAdminState can be attributed that the Power Monitor
is busy transitioning from pmPowerAdminState into the
pmPowerOperState, at which point it will update the content of
pmPowerOperState. In addition, the possible reason for change
in Power State is reported in pmPowerStateEnterReason.
Regarding pmPowerStateEnterReason, management stations and Power
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 11]
Internet-Draft <Energy Monitoring MIB> May 2011
Monitors 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 pmPowerOperState, pmPowerAdminState , and
pmPowerStateEnterReason are contained in the pmPowerTable MIB
table.
The pmPowerStateTable table enumerates the maximum power usage
in watts, for every single supported Power State of each Power
State Series supported by the Power Monitor In addition,
PowerStateTable provides additional statistics:
pmPowerStateEnterCount, the number of times an entity has
visited a particular Power State, and pmPowerStateTotalTime, the
total time spent in a particular Power State of a Power Monitor.
5.2.1. Power State Series
There are several standards and implementations of Power State
Series. A Power Monitor can support one or multiple Power State
Series implementation(s) concurrently.
There are currently three Power State Series supported:
Reserved(0)
IEEE1621(1) - [IEEE1621]
DMTF(2) - [DMTF]
EMAN(3) - [EMAN-MONITORING-MIB]
The respective specific states related to each Power State
Series are specified in the following sections.
5.2.2. IEEE1621 Power State Series
The IEEE1621 Power State Series [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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 12]
Internet-Draft <Energy Monitoring MIB> May 2011
5.2.3. DMTF Power State Series
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 Series
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
Series:
---------------------------------------------------
| DMTF | ACPI |
| Power State | Power State |
---------------------------------------------------
| 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 |
---------------------------------------------------
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 13]
Internet-Draft <Energy Monitoring MIB> May 2011
| 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 Series Mapping
5.2.4. EMAN Power State Series
The EMAN Power State Series 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.
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 Power Monitor may have fewer Power States than twelve and
would then map several policy states to the same power state.
Power Monitor 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):
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 14]
Internet-Draft <Energy Monitoring MIB> May 2011
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
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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 15]
Internet-Draft <Energy Monitoring MIB> May 2011
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
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.
5.3. Power Monitor Usage Information
Refer to the "Power Monitor Usage Measurement" section in [EMAN-
FRAMEWORK] for background information.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 16]
Internet-Draft <Energy Monitoring MIB> May 2011
For a Power Monitor, power usage is reported using pmPower. The
magnitude of measurement is based on the pmPowerUnitMultiplier
MIB variable, based on the UnitMultiplier Textual Convention
(TC).
For example, if current power usage of a Power Monitor is 3, it
could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of
pmPowerUnitMultiplier. Note that other measurements throughout
the two MIB modules in this document use the same mechanism,
including pmPowerStatePowerUnitMultiplier,
pmEnergyIntervalEnergyUnitMultiplier, and
pmACPwrQualityPowerUnitMultiplier.
In addition to knowing the usage and magnitude, it is useful to
know how a pmPower measurement was obtained. An NMS can use
this to account for the accuracy and nature of the reading
between different implementations. For this pmPowerOrigin
describes whether the measurements were made at the device
itself or from a remote source. The pmPowerMeasurementCaliber
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
pmPowerMeasurementCaliber shall report that measurement
mechanism is "unavailable" and the pmPower measurement shall be
"0".
The nameplate power rating of a Power Monitor is specified in
pmPowerNameplate MIB object.
5.4. Optional Power Usage Quality
Refer to the "Optional Power Usage Quality" section in [EMAN-
FRAMEWORK] for background information.
The optional powerQualityMIB MIB module can be implemented to
further describe power usage quality measurement. The
powerQualityMIB MIB module adheres closely to the IEC 61850 7-2
standard to describe AC measurements.
The powerQualityMIB MIB module contains a primary table, the
pmACPwrQualityTable table, that defines power quality
measurements for supported pmIndex entities, as a sparse
extension of the pmPowerTable (with pmPowerIndex as primary
index). This pmACPwrQualityTable table contains such
information as the configuration (single phase, DEL 3 phases,
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 17]
Internet-Draft <Energy Monitoring MIB> May 2011
WYE 3 phases), voltage, frequency, power accuracy, total
active/reactive power/apparent power, amperage, and voltage.
In case of 3-phase power, the pmACPwrQualityPhaseTable
additional table is populated with power quality measurements
per phase (so double indexed by the pmPowerIndex and
pmPhaseIndex). 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
pmACPwrQualityDelPhaseTable table describes the phase-to-phase
power quality measurements, i.e., voltage and current.
In case of 3-phase power with a Wye configuration, the
pmACPwrQualityWyePhaseTable table describes the phase-to-neutral
power quality measurements, i.e., voltage and current.
5.5. Optional Energy Measurement
Refer to the "Optional Energy and demand Measurement" section in
[EMAN-FRAMEWORK] for the definition and terminology
information.
It is relevant to measure energy when there are actual power
measurements from a Power Monitor, and not when the power
measurement is assumed or predicted as specified in the
description clause of the object pmPowerMeasurementCaliber.
Two tables are introduced to characterize energy measurement of
a Power Monitor: pmEnergyTable and pmEnergyParametersTable.
Both energy and demand information can be represented via the
pmEnergyTable. Energy information will be an accumulation with
no interval. Demand information can be represented as an
average accumulation per interval of time.
The pmEnergyParametersTable consists of the parameters defining
the duration of measurement intervals in seconds,
(pmEnergyParametersIntervalLength), the number of successive
intervals to be stored in the pmEnergyTable,
(pmEnergyParametersIntervalNumber), the type of measurement
technique (pmEnergyParametersIntervalMode), and a sample rate
used to calculate the average (pmEnergyParametersSampleRate).
Judicious choice of the sampling rate will ensure accurate
measurement of energy while not imposing an excessive polling
burden.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 18]
Internet-Draft <Energy Monitoring MIB> May 2011
There are three pmEnergyParametersIntervalMode types used for
energy measurement collection: period, sliding, and total. Note
that multiple pmEnergyParametersIntervalMode types MAY be
configured simultaneously.
These three pmEnergyParametersIntervalMode types are illustrated
by the following three figures, for which:
- The horizontal axis represents the current time, with the
symbol <--- L ---> expressing the
pmEnergyParametersIntervalLength, and the
pmEnergyIntervalStartTime is represented by S1, S2, S3, S4, ...,
Sx where x is the value of pmEnergyParametersIntervalNumber.
- The vertical axis represents the time interval of sampling and
the value of pmEnergyIntervalEnergyUsed 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 pmEnergyParametersIntervalMode
A pmEnergyParametersIntervalMode type of 'period' specifies non-
overlapping periodic measurements. Therefore, the next
pmEnergyIntervalStartTime is equal to the previous
pmEnergyIntervalStartTime plus pmEnergyParametersIntervalLength.
S2=S1+L; S3=S2+L, ...
|============ |
| |
| <--- L ---> |
| |
| |============ |
| | |
| | <--- L ---> |
| | |
| | |============ |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 19]
Internet-Draft <Energy Monitoring MIB> May 2011
| | | |
| | | <--- L ---> |
| | | |
| | | |============ |
| | | | |
| | | | <--- L ---> |
S1 | | | |
| | | |
| | | |
S2 | | |
| | |
| | |
S3 | |
| |
| |
S4
Figure 5 : Sliding pmEnergyParametersIntervalMode
A pmEnergyParametersIntervalMode type of 'sliding' specifies
overlapping periodic measurements.
| |
|========================= |
| |
| |
| |
| <--- Total length ---> |
| |
S1
Figure 4 : Total pmEnergyParametersIntervalMode
A pmEnergyParametersIntervalMode type of 'total' specifies a
continuous measurement since the last reset. The value of
pmEnergyParametersIntervalNumber should be (1) one and
pmEnergyParametersIntervalLength is ignored.
The pmEnergyParametersStatus is used to start and stop energy
usage logging. The status of this variable is "active" when
all the objects in pmEnergyParametersTable are appropriate which
in turn indicates if pmEnergyTable entries exist or not.
The pmEnergyTable consists of energy measurements
inpmEnergyIntervalEnergyUsed , the units of the measured energy
pmEnergyIntervalEnergyUnitMultiplier, and the maximum observed
energy within a window - pmEnergyIntervalMax.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 20]
Internet-Draft <Energy Monitoring MIB> May 2011
Measurements of the total energy consumed by a Power Monitor may
suffer from interruptions in the continuous measurement of
energy consumption. In order to indicate such interruptions,
the object pmEnergyIntervalDiscontinuityTime is provided for
indicating the time of the last interruption of total energy
measurement. pmEnergyIntervalDiscontinuityTime shall indicate
the sysUpTime [RFC3418] when the device was reset.
The following example illustrates the pmEnergyTable and
pmEnergyParametersTable:
First, in order to estimate energy, a time interval to sample
energy should be specified, i.e.
pmEnergyParametersIntervalLength can be set to "900 seconds" or
15 minutes and the number of consecutive intervals over which
the maximum energy is calculated
(pmEnergyParametersIntervalNumber) as "10". The sampling rate
internal to the Power Monitor for measurement of power usage
(pmEnergyParametersSampleRate) can be "1000 milliseconds", as
set by the Power Monitor as a reasonable value. Then, the
pmEnergyParametersStatus is set to active (value 1) to indicate
that the Power Monitor should start monitoring the usage per the
pmEnergyTable.
The indices in the pmEnergyTable are pmPowerIndex, which
identifies the Power Monitor, and pmEnergyIntervalStartTime,
which denotes the start time of the energy measurement interval
based on sysUpTime [RFC3418]. The value of
pmEnergyIntervalEnergyUsed is the measured energy consumption
over the time interval specified
(pmEnergyParametersIntervalLength) based on the Power Monitor
internal sampling rate (pmEnergyParametersSampleRate). While
choosing the values for the pmEnergyParametersIntervalLength and
pmEnergyParametersSampleRate, 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 pmEnergyIntervalEnergyUsed. The units are derived
from pmEnergyIntervalPowerUnitMultiplier. For example,
pmEnergyIntervalPowerUsed can be "100" with
pmEnergyIntervalPowerUnits equal to 0, the measured energy
consumption of the Power Monitor is 100 watt-hours. The
pmEnergyIntervalMax is the maximum energyobserved and that can
be "150 watt-hours".
The pmEnergyTable has a buffer to retain a certain number of
intervals, as defined by pmEnergyParametersIntervalNumber. If
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 21]
Internet-Draft <Energy Monitoring MIB> May 2011
the default value of "10" is kept, then the pmEnergyTable
contains 10 energymeasurements, including the maximum.
Here is a brief explanation of how the maximum energy can be
calculated. The first observed energy measurement value is
taken to be the initial maximum. With each subsequent
measurement, based on numerical comparison, maximum energy may
be updated. The maximum value is retained as long as the
measurements are taking place. Based on periodic polling of
this table, an NMS could compute the maximum over a longer
period, 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 pmPowerOperState,
pmPowerStateTotalTime and pmPowerStateEnterCount. Some of the
other requirements are met via the SNMP NOTIFICATION mechanism.
pmPowerStateChange SNMP notification which is generated when the
value(s) of pmPowerStateSeries, pmPowerOperState,
pmPowerAdminState have changed.
6. Discovery
6.1. ENERGY-AWARE-MIB Module Implemented
The NMS must first poll the ENERGY-AWARE-MIB module [EMAN-AWARE-
MIB], if available, in order to discover all the Power Monitors
and the relationships between those (notion of Parent/Child).
In the ENERGY-AWARE-MIB module tables, the Power Monitors are
indexed by the pmIndex.
If an implementation of the ENERGY-AWARE-MIB module is available
in the local SNMP context, for the same Power Monitor, the
pmIndex value (EMAN-AWARE-MIB) MUST be assigned to the
pmPowerIndex for The pmPowerIndex characterizes the Power
Monitor in the powerMonitorMIB and powerQualityMIB MIB modules
(this document).
From there, the NMS must poll the pmPowerStateTable (specified
in the powerMonitorMIB module in this document), which
enumerates, amongst other things, the maximum power usage. As
the entries in pmPowerStateTable table are indexed by the Power
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 22]
Internet-Draft <Energy Monitoring MIB> May 2011
Monitor (pmPowerIndex), by the Power State Series
(pmPowerStateSeriesIndex), and by the Power State
(pmPowerStateIndex), the maximum power usage is discovered per
Power Monitor, per Power State Series, and per Power Usage. In
other words, polling the pmPowerStateTable allows the discovery
of each Power State within every Power State Series supported by
the Power Monitor.
If the Power Monitor is an Aggregator or a Proxy, the MIB module
would be populated with the Power Monitor Parent and Children
information, which have their own Power Monitor index value
(pmPowerIndex). However, the parent/child relationship must be
discovered thanks to the ENERGY-AWARE-MIB module.
Finally, the NMS can monitor the Power Quality thanks to the
powerQualityMIB MIB module, which reuses the pmPowerIndex to
index the Power Monitor.
6.2. ENERGY-AWARE-MIB Module Not Implemented, ENTITY-MIB
Implemented
When the ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] is not
implemented, the NMS must poll the ENTITY-MIB [RFC4133] in order
to discover some more information about the Power Monitors.
Indeed, the index for the Power Monitors in the MIB modules
specified in this document is the pmPowerIndex, which specifies:
"If there is no implementation of the ENERGY-AWARE-MIB module
but one of the ENTITY MIB module is available in the local SNMP
context, then the same index of an entity MUST be chosen as
assigned to the entity by object entPhysicalIndex in the ENTITY
MIB module."
As the Section 6.1. , the NMS must then poll the
pmPowerStateTable (specified in the powerMonitorMIB module in
this document), indexed by the Power Monitor (pmPowerIndex that
inherited the entPhysicalIndex value), by the Power State Series
(pmPowerStateSeriesIndex), and by the Power State
(pmPowerStateIndex). Then the NMS has discovered every Power
State within each Power State Series supported by the Power
Monitor.
Note that, without the ENERGY-AWARE-MIB module, the Power
Monitor acts as an standalone device, i.e. the notion of
parent/child can't be specified.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 23]
Internet-Draft <Energy Monitoring MIB> May 2011
6.3. ENERGY-AWARE-MIB Module and ENTITY-MIB Not Implemented
If neither the ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] nor of
the ENTITY MIB module [RFC4133] are available in the local SNMP
context, then this MIB module may choose identity values from a
further MIB module providing entity identities.
Note that, without the ENERGY-AWARE-MIB module, the Power
Monitor acts as an standalone device, i.e. the notion of
parent/child can't be specified.
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 Power
Monitors are modeled by the entPhysicalIndex through the
pmPhysicalEntity MIB object specified in the pmTable 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-
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 24]
Internet-Draft <Energy Monitoring MIB> May 2011
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 pmPowerAccuracy MIB object models this accuracy.
Note that pmPowerUnitMultipler represents the scale factor per
IEC 61850, 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 Power Monitors 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 pmPhysicalEntity value
contains the zero value, thanks to PhysicalIndexOrZero textual
convention.
The pmPowerIndex MIB object has been kept as the unique Power
Monitor index. The pmPower is similar to entPhySensorValue
[RFC3433] and the pmPowerUnitMultipler 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).
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",
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 25]
Internet-Draft <Energy Monitoring MIB> May 2011
"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 Power Monitors 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 pmethPortIndex and
pmethPortGrpIndex values contain the zero value, thanks to new
PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero
conventions.
However, if the Power-over-Ethernet MIB [RFC3621] is supported,
the Power Monitor pmethPortIndex and pmethPortGrpIndex contain
the pethPsePortIndex and pethPsePortGroupIndex, respectively.
As a consequence, the pmPowerIndex MIB object has been kept as
the unique Power Monitor index.
Note that, even though the Power-over-Ethernet MIB [RFC3621] was
created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse
the precision notion from the ENTITY-SENSOR MIB, i.e. the
entPhySensorPrecision MIB object.
7.4. Link with the UPS MIB
To protect against unexpected power disruption, data centers and
buildings make use of Uninterruptible Power Supplies (UPS). To
protect critical assets, a UPS can be restricted to a particular
subset or domain of the network. UPS usage typically lasts only
for a finite period of time, until normal power supply is
restored. Planning is required to decide on the capacity of the
UPS based on output power and duration of probable power outage.
To properly provision UPS power in a data center or building, it
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 26]
Internet-Draft <Energy Monitoring MIB> May 2011
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 Power Monitor Parent and
any of the UPS meters or submeters are the Power Monitor
Children.
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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 27]
Internet-Draft <Energy Monitoring MIB> May 2011
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
pmethPortIndex and pmethPortGrpIndex.
The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to
pmPowerOrigin 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
pmPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and
local(3) can be mapped to remote(2) and self(1), respectively.
8. Implementation Scenarios
This section provides an illustrative example scenario for the
implementation of the Power Monitor, including Power Monitor
Parent and Power Monitor 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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 28]
Internet-Draft <Energy Monitoring MIB> May 2011
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 [RFC4133] 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. The switch has the following attributes,
pmPowerIndex "1", pmPhysicalEntity "2", and pmPowerMonitorId
"UUID 1000". The power usage of the switch is "440 Watts". The
switch does not have a Power Monitor Parent.
The PoE switch port has the following attributes: The switch
port has pmPowerIndex "3", pmPhysicalEntity is "12" and
pmPowerMonitorId 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 Power Monitor Parent, with its pmParentID
of "1000".
The attributes of the PC are given below. The PC does not
implementation of Entity MIB, and thus does not have
pmPhysicalEntity. The pmPowerIndex (pmPIndex) of the PC is
"57", the pmPowerMonitorId is "UUID 1000:57 ". The PC has a
Power Monitor Parent, i.e. the switch port whose
pmPowerMonitorId 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
Power Monitor 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 Power Monitor Parent
sends power control messages to both the Power Monitor Children
(IP phone and PC) and the Children react to those messages.
|--------------------------------------------------------------|
| Switch |
|==============================================================|
| Switch | Switch | Switch | Switch | Switch |
| pmPIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmPower |
| ============================================================ |
| 1 | 2 | UUID 1000 | null | 440 |
| ============================================================ |
| |
| SWITCH PORT |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port | Port | Port | Port | Port | |
| | pmPIndex| pmPhyIdx | pmPowerMonId | pmParentId | pmPower | |
| ============================================================ |
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 29]
Internet-Draft <Energy Monitoring MIB> May 2011
| | 3 | 12 | UUID 1000:3 | UUID 1000 | 12 | |
| ============================================================ |
| ^ |
| | |
|-----------------------------------|--------------------------|
|
|
POE IP PHONE |
|
|
=============================================================
| IP phone | IP phone |IP phone |IP phone |IP phone|
| pmPIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmPower|
===========================================================
| 31 | 0 | UUID 1000:31 | UUID 1000:3 | 12 |
============================================================
|
|
PC connected to switch via IP phone |
|
=============================================================
| PC | PC |PC |PC | PC |
|pmPIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmPower |
============================================================
| 57 | 0 | UUID 1000:57 | UUID 1000:3 | 120 |
=============================================================
Figure 1: Example scenario
9. Structure of the MIB
The primary MIB object in this MIB module is the
PowerMonitorMIBObject. The pmPowerTable table of
PowerMonitorMibObject describes the power measurement attributes
of a Power Monitor entity. The notion of identity of the device
in terms of uniquely identification of the Power Monitor and its
relationship to other entities in the network are addressed in
[EMAN-AWARE-MIB].
The power measurement of Power Monitor contains information
describing its power usage (pmPower) and its current power state
(pmPowerOperState). In addition to power usage, additional
information describing the units of measurement
(pmPowerAccuracy, pmPowerUnitMultiplier), how power usage
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 30]
Internet-Draft <Energy Monitoring MIB> May 2011
measurement was obtained (pmPowerMeasurementCaliber), the
source of power (pmPowerOrigin) and the type of power
(pmPowerCurrentTtype) are described.
A Power Monitor may contain an optional pmPowerQuality table
that describes the electrical characteristics associated with
the current power state and usage.
A Power Monitor may contain an optional pmEnergyTable to
describe energy measurement information over time.
A Power Monitor may also contain optional battery information
associated with this entity.
10. MIB Definitions
-- ************************************************************
--
--
-- This MIB is used to monitor power usage of network
-- devices
--
-- *************************************************************
POWER-MONITOR-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
mib-2,
Integer32, Counter64, TimeTicks
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval
FROM SNMPv2-TC
MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP
FROM SNMPv2-CONF
OwnerString
FROM RMON-MIB;
powerMonitorMIB MODULE-IDENTITY
LAST-UPDATED "201105010000Z" -- 1 May 2011
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"WG charter:
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 31]
Internet-Draft <Energy Monitoring MIB> May 2011
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,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad@bradschoening.com
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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 32]
Internet-Draft <Energy Monitoring MIB> May 2011
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com"
DESCRIPTION
"This MIB is used to monitor power and energy in
devices."
REVISION
"201105010000Z" -- 1 May 2011
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 xxx }
EDITOR'S NOTE: editors, please replace xxx by the new RFC. IANA,
please replace xxx by the new MIB OID.
powerMonitorMIBNotifs OBJECT IDENTIFIER
::= { powerMonitorMIB 0 }
powerMonitorMIBObjects OBJECT IDENTIFIER
::= { powerMonitorMIB 1 }
powerMonitorMIBConform OBJECT IDENTIFIER
::= { powerMonitorMIB 2 }
-- Textual Conventions
PowerStateSeries ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"PowerStateSeries is a TC that describes the Power State
Series a Power Monitor supports. IANA has created a
registry of Power State Series supported by a Power
Monitor entity and IANA shall administer the list of
Power State Series.
One byte is used to represent the Power State Series.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 33]
Internet-Draft <Energy Monitoring MIB> May 2011
field octets contents range
----- ------ -------- -----
1 1 Power State Series 1..255
Note:
the value of Power State Series in network byte
order
1 in the first byte indicates IEEE1621 Power State
Series
2 in the first byte indicates DMTF Power State Series
3 in the first byte indicates EMAN Power State Series
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 OCTETSTRING (SIZE(1))
}
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 pmPowerUnitMultiplier, -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
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 34]
Internet-Draft <Energy Monitoring MIB> May 2011
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
pmPowerTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Power Monitors."
::= { powerMonitorMIBObjects 1 }
pmPowerEntry OBJECT-TYPE
SYNTAX PmPowerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the power usage of a Power Monitor."
INDEX { pmPowerIndex, pmPowerStateSeriesIndex}
::= { pmPowerTable 1 }
PmPowerEntry ::= SEQUENCE {
pmPowerIndex Integer32,
pmPowerStateSeriesIndex PowerStateSeries,
pmPower Integer32,
pmPowerNameplate Integer32,
pmPowerUnitMultiplier UnitMultiplier,
pmPowerAccuracy Integer32,
pmPowerMeasurementCaliber INTEGER,
pmPowerCurrentType INTEGER,
pmPowerOrigin INTEGER,
pmPowerAdminState Integer32,
pmPowerOperState Integer32,
pmPowerStateEnterReason OwnerString
}
pmPowerIndex OBJECT-TYPE
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 35]
Internet-Draft <Energy Monitoring MIB> May 2011
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, for each Power Monitor.
If an implementation of the ENERGY-AWARE-MIB module is
available in the local SNMP context, then the same index
as the one in the ENERGY-AWARE-MIB MUST be assigned for
the identical Power Monitor. In this case, entities
without an assigned value for pmIndex cannot be indexed
by the pmPowerStateTable.
If there is no implementation of the ENERGY-AWARE-MIB
module but one of the ENTITY MIB module is available in
the local SNMP context, then the same index of an entity
MUST be chosen as assigned to the entity by object
entPhysicalIndex in the ENTITY MIB module. In this case,
entities without an assigned value for entPhysicalIndex
cannot be indexed by the pmPowerStateTable.
If neither the ENERGY-AWARE-MIB module nor of the ENTITY
MIB module are available in the local SNMP context, then
this MIB module may choose identity values from a further
MIB module providing entity identities. In this case the
value for each pmPowerIndex must remain constant at least
from one re-initialization of the entity's network
management system to the next re-initialization.
In case that no other MIB modules have been chosen for
providing entity identities, Power States can be reported
exclusively for the local device on which this table is
instantiated. Then this table will have a single entry
only and an index value of 0 MUST be used."
::= { pmPowerEntry 1 }
pmPowerStateSeries OBJECT-TYPE
SYNTAX PowerStateSeries
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the Power State Series supported
by the Power Monitor. The list of Power State Series and
their numbering are administered by IANA"
::= { pmPowerEntry 2 }
pmPower OBJECT-TYPE
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 36]
Internet-Draft <Energy Monitoring MIB> May 2011
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the 'instantaneous' RMS
consumption for the Power Monitor. This value is
specified in SI units of watts with the magnitude of
watts (milliwatts, kilowatts, etc.) indicated separately
in pmPowerUnitMultiplier. The accuracy of the measurement
is specfied in pmPowerAccuracy. The direction of power
flow is indicated by the sign on pmPower. If the Power
Monitor is consuming power, the pmPower value will be
positive. If the Power Monitor is producing power, the
pmPower value will be negative.
The pmPower MUST be less than or equal to the maximum
power that can be consumed at the power state specified
by pmPowerState.
The pmPowerMeasurementCaliber object specifies how the
usage value reported by pmPower was obtained. The pmPower
value must report 0 if the pmPowerMeasurementCaliber is
'unavailable'. For devices that can not measure or
report power, this option can be used."
::= { pmPowerEntry 3 }
pmPowerNameplate OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the rated maximum consumption for
the fully populated Power Monitor. The nameplate power
requirements are the maximum power numbers and, in almost
all cases, are well above the expected operational
consumption. The pmPowerNameplate 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 pmPowerUnitMultiplier."
::= { pmPowerEntry 4 }
pmPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 37]
Internet-Draft <Energy Monitoring MIB> May 2011
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in pmPower
and pmPowerNameplate."
::= { pmPowerEntry 5 }
pmPowerAccuracy 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 pmPower. For example: The value 1010 means
the reported usage is accurate to +/- 10.1 percent. This
value is zero if the accuracy is unknown or not
applicable based upon the measurement method.
ANSI and IEC define the following accuracy classes for
power measurement:
IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3.
ANSI C12.20 class 0.2, 0.5"
::= { pmPowerEntry 6 }
pmPowerMeasurementCaliber 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
pmPower was obtained:
- unavailable(1): Indicates that the usage is not
available. In such a case, the pmPower 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
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 38]
Internet-Draft <Energy Monitoring MIB> May 2011
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 the real apparent current energy
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.
- 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"
::= { pmPowerEntry 7 }
pmPowerCurrentType OBJECT-TYPE
SYNTAX INTEGER {
ac(1),
dc(2),
unknown(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates whether the pmUsage for the Power
Monitor reports alternative current AC(1), direct current
DC(2), or that the current type is unknown(3)."
::= { pmPowerEntry 8 }
pmPowerOrigin OBJECT-TYPE
SYNTAX INTEGER {
self (1),
remote (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 39]
Internet-Draft <Energy Monitoring MIB> May 2011
"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."
::= { pmPowerEntry 9 }
pmPowerAdminState OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the desired Power State for the
Power Monitor, in the context of the Power State Series
specified by pmPowerStateSeriesIndex in this table.
Possible values of pmPowerAdminState are registered at
IANA, per Power States Series. A current list of
assignments can be found at
<http://www.iana.org/assignments/eman>
RFC-EDITOR: please check the location after IANA"
::= { pmPowerEntry 10 }
pmPowerOperState OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the current operational Power
State for the Power Monitor, in the context of the Power
State Series specified by pmPowerStateSeriesIndex in
this table. Possible values of pmPowerOperState are
registered at IANA, per Power States Series. A current
list of assignments can be found at
<http://www.iana.org/assignments/eman>
RFC-EDITOR: please check the list"
::= { pmPowerEntry 11 }
pmPowerStateEnterReason OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 40]
Internet-Draft <Energy Monitoring MIB> May 2011
"This string object describes the reason for the
pmPowerAdminState
transition Alternatively, this string may contain with
the entity that configured this Power Monitor to this
Power State."
DEFVAL { "" }
::= { pmPowerEntry 12 }
pmPowerStateTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmPowerStateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table enumerates the maximum power usage, in watts,
for every single supported Power State of each Power
Monitor.
This table has an expansion-dependent relationship on the
pmPowerTable, containing rows describing each Power State
for the corresponding Power Monitor. For every Power
Monitor in the pmPowerTable, there is a corresponding
entry in this table."
::= { powerMonitorMIBObjects 2 }
pmPowerStateEntry OBJECT-TYPE
SYNTAX PmPowerStateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A pmPowerStateEntry extends a corresponding
pmPowerEntry. This entry displays max usage values at
every single possible Power State supported by the Power
Monitor.
For example, given the values of a Power Monitor
corresponding to a maximum usage of 11W at the
state 1 (mechoff), 6 (ready), 8 (mediumMinus), 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
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 41]
Internet-Draft <Energy Monitoring MIB> May 2011
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 {
pmPowerIndex,
pmPowerStateSeriesIndex,
pmPowerStateIndex
}
::= { pmPowerStateTable 1 }
PmPowerStateEntry ::= SEQUENCE {
pmPowerStateIndex Integer32,
pmPowerStateMaxPower Integer32,
pmPowerStatePowerUnitMultiplier UnitMultiplier,
pmPowerStateTotalTime TimeTicks,
pmPowerStateEnterCount Counter64
}
pmPowerStateIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object specifies the Power State for the Power
Monitor, in the context of the Power State Series
specified by pmPowerStateSeries index in this table.
This object specifies the index of the Power State of
the Power Monitor within a Power State Series. The
semantics of the specific Power State can be obtained
from the Power State Series definition."
::= { pmPowerStateEntry 1 }
pmPowerStateMaxPower OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum power for the Power
Monitor 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
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 42]
Internet-Draft <Energy Monitoring MIB> May 2011
in pmPowerStatePowerUnitMultiplier. 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
pmPowerStateMaxPower might be interpolated by using the
next highest supported Power State."
::= { pmPowerStateEntry 3 }
pmPowerStatePowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
pmPowerStateMaxPower."
::= { pmPowerStateEntry 4 }
pmPowerStateTotalTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the total time in hundreds
of seconds that the Power Monitor has been in this power
state since the last reset, as specified in the
sysUpTime."
::= { pmPowerStateEntry 5 }
pmPowerStateEnterCount OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates how often the Power Monitor has
entered this power state, since the last reset of the
device as specified in the sysUpTime."
::= { pmPowerStateEntry 6 }
pmEnergyParametersTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is used to configure the parameters for Energy
measurement collection in the table pmEnergyTable."
::= { powerMonitorMIBObjects 4 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 43]
Internet-Draft <Energy Monitoring MIB> May 2011
pmEnergyParametersEntry OBJECT-TYPE
SYNTAX PmEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls an energy measurement in
pmEnergyTable."
INDEX { pmPowerIndex }
::= { pmEnergyParametersTable 1 }
PmEnergyParametersEntry ::= SEQUENCE {
pmEnergyParametersIntervalLength TimeInterval,
pmEnergyParametersIntervalNumber Integer32,
pmEnergyParametersIntervalMode Integer32,
pmEnergyParametersIntervalWindow TimeInterval,
pmEnergyParametersSampleRate Integer32,
pmEnergyParametersStatus RowStatus
}
pmEnergyParametersIntervalLength OBJECT-TYPE
SYNTAX TimeInterval
UNITS "Seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the length of time in seconds over
which to compute the average pmEnergyIntervalEnergyUsed
measurement in the pmEnergyTable table. The computation
is based on the Power Monitor's internal sampling rate of
power consumed or produced by the Power Monitor. The
sampling rate is the rate at which the power monitor 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 { 900 }
::= { pmEnergyParametersEntry 1 }
pmEnergyParametersIntervalNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of intervals maintained in the pmEnergyTable.
Each interval is characterized by a specific
pmEnergyIntervalStartTime, used as an index to the table
pmEnergyTable . Whenever the maximum number of entries is
reached, the measurement over the new interval replaces
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 44]
Internet-Draft <Energy Monitoring MIB> May 2011
the oldest measurement , except if the oldest measurement
were to be the maximum pmEnergyIntervalMax, in which case
the measurement the measurement over the next oldest
interval is replaced."
DEFVAL { 10 }
::= { pmEnergyParametersEntry 2 }
pmEnergyParametersIntervalMode 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
pmEnergyIntervalEnergyUsed measurement in the pmEnergyTable
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 pmEnergyParametersIntervalWindow.
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
pmEnergyParametersIntervalNumber should be (1) one and
pmEnergyParametersIntervalLength is ignored. "
::= { pmEnergyParametersEntry 3 }
pmEnergyParametersIntervalWindow OBJECT-TYPE
SYNTAX TimeInterval
UNITS "Seconds"
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
seconds, in order to compute the average
pmEnergyIntervalEnergyUsed measurement in the pmEnergyTable
table This is valid only when the
pmEnergyParametersIntervalMode is sliding(2). The
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 45]
Internet-Draft <Energy Monitoring MIB> May 2011
pmEnergyParametersIntervalWindow value should be a multiple
of pmEnergyParametersSampleRate."
::= { pmEnergyParametersEntry 4 }
pmEnergyParametersSampleRate OBJECT-TYPE
SYNTAX Integer32
UNITS "Milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The sampling rate, in milliseconds, at which the Power
Monitor should poll power usage in order to compute the
average pmEnergyIntervalEnergyUsed measurement in the
table pmEnergyTable. The Power Monitor 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 Power Monitor performance by requesting
continuous polling. If the sampling rate is unknown, the
value 0 is reported. The sampling rate should be selected
so that pmEnergyParametersIntervalWindow is a multiple of
pmEnergyParametersSampleRate."
DEFVAL { 1000 }
::= { pmEnergyParametersEntry 5 }
pmEnergyParametersStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row. The pmEnergyParametersStatus 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 pmEnergyTable will be deleted. The data can be
destroyed by setting up the pmEnergyParametersStatus to
destroy(2)."
::= {pmEnergyParametersEntry 6 }
pmEnergyTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmEnergyIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 46]
Internet-Draft <Energy Monitoring MIB> May 2011
"This table lists Power Monitor energy measurements.
Entries in this table are only created if the
corresponding value of object pmPowerMeasurementCaliber
is active(2), i.e., if the power is actually metered."
::= { powerMonitorMIBObjects 5 }
pmEnergyIntervalEntry OBJECT-TYPE
SYNTAX PmEnergyIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing energy measurements."
INDEX { pmPowerIndex, pmEnergyParametersIntervalMode,
pmEnergyIntervalStartTime }
::= { pmEnergyTable 1 }
PmEnergyIntervalEntry ::= SEQUENCE {
pmEnergyIntervalStartTime TimeTicks,
pmEnergyIntervalEnergyUsed Integer32,
pmEnergyIntervalEnergyUnitMultiplier UnitMultiplier,
pmEnergyIntervalMax Integer32,
pmEnergyIntervalDiscontinuityTime TimeTicks
}
pmEnergyIntervalStartTime OBJECT-TYPE
SYNTAX TimeTicks
UNITS "hundredths of seconds"
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 is useful for reference of interval periods
for which the energy is measured."
::= { pmEnergyIntervalEntry 1 }
pmEnergyIntervalEnergyUsed OBJECT-TYPE
SYNTAX Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the energy used in units of watt-
hours for the Power Monitor 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-
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 47]
Internet-Draft <Energy Monitoring MIB> May 2011
Hr, etc.) indicated separately in
pmEnergyIntervalEnergyUnitMultiplier."
::= { pmEnergyIntervalEntry 2 }
pmEnergyIntervalEnergyUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the magnitude of watt-hours for the
energy field in pmEnergyIntervalEnergyUsed."
::= { pmEnergyIntervalEntry 3 }
pmEnergyIntervalMax OBJECT-TYPE
SYNTAX Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum energy ever observed in
pmEnergyIntervalEnergyUsed 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
pmEnergyIntervalEnergyUnits."
::= { pmEnergyIntervalEntry 4 }
pmEnergyIntervalDiscontinuityTime OBJECT-TYPE
SYNTAX TimeTicks
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
consumption counters suffered a discontinuity. If no such
discontinuities have occurred since the last re-
initialization of the local management subsystem, then
this object contains a zero value."
::= { pmEnergyIntervalEntry 5 }
-- Notifications
pmPowerStateChange NOTIFICATION-TYPE
OBJECTS { pmPowerStateSeries, pmPowerAdminState,
pmPowerOperState, pmPowerStateEnterReason}
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 48]
Internet-Draft <Energy Monitoring MIB> May 2011
"The SNMP entity generates the PmPowerStateChange when
the value(s) of pmPowerAdminState or pmPowerOperState,
in the context of the Power State Series, have changed
for the Power Monitor represented by the pmPowerIndex."
::= { powerMonitorMIBNotifs 1 }
-- Conformance
powerMonitorMIBCompliances OBJECT IDENTIFIER
::= { powerMonitorMIB 3 }
powerMonitorMIBGroups OBJECT IDENTIFIER
::= { powerMonitorMIB 4 }
powerMonitorMIBFullCompliance 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 -- this module
MANDATORY-GROUPS {
powerMonitorMIBTableGroup,
powerMonitorMIBStateTableGroup,
powerMonitorMIBEnergyTableGroup,
powerMonitorMIBEnergyParametersTableGroup,
powerMonitorMIBNotifGroup
}
::= { powerMonitorMIBCompliances 1 }
powerMonitorMIBReadOnlyCompliance 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 can not be configured
with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
powerMonitorMIBTableGroup,
powerMonitorMIBStateTableGroup,
powerMonitorMIBNotifGroup
}
OBJECT pmPowerState
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 49]
Internet-Draft <Energy Monitoring MIB> May 2011
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { powerMonitorMIBCompliances 2 }
-- Units of Conformance
powerMonitorMIBTableGroup OBJECT-GROUP
OBJECTS {
pmPower,
pmPowerNameplate,
pmPowerUnitMultiplier,
pmPowerAccuracy,
pmPowerMeasurementCaliber,
pmPowerCurrentType,
pmPowerOrigin,
pmPowerAdminState pmPowerOperState
pmPowerStateEnterReason
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the PowerMonitor."
::= { powerMonitorMIBGroups 1 }
powerMonitorMIBStateTableGroup OBJECT-GROUP
OBJECTS {
pmPowerStateMaxPower,
pmPowerStatePowerUnitMultiplier,
pmPowerStateTotalTime,
pmPowerStateEnterCount
}
STATUS current
DESCRIPTION
"This group contains the collection of all the
objects related to the Power State."
::= { powerMonitorMIBGroups 2 }
powerMonitorMIBEnergyParametersTableGroup OBJECT-GROUP
OBJECTS {
pmEnergyParametersIntervalLength,
pmEnergyParametersIntervalNumber,
pmEnergyParametersIntervalMode,
pmEnergyParametersIntervalWindow,
pmEnergyParametersSampleRate,
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 50]
Internet-Draft <Energy Monitoring MIB> May 2011
pmEnergyParametersStatus
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the configuration of the Energy Table."
::= { powerMonitorMIBGroups 3 }
powerMonitorMIBEnergyTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object
-- pmEnergyIntervalStartTime is not
-- included since it is not-accessible
pmEnergyIntervalEnergyUsed,
pmEnergyIntervalEnergyUnitMultiplier,
pmEnergyIntervalMax,
pmEnergyIntervalDiscontinuityTime
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Table."
::= { powerMonitorMIBGroups 4 }
powerMonitorMIBNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
pmPowerStateChange
}
STATUS current
DESCRIPTION
"This group contains the notifications for the power and
energy monitoring MIB Module."
::= { powerMonitorMIBGroups 5 }
END
-- ************************************************************
--
-- This MIB module is used to monitor power quality of networked
-- devices with measurements.
--
-- This MIB module is an extension of powerMonitorMIB module.
--
-- *************************************************************
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 51]
Internet-Draft <Energy Monitoring MIB> May 2011
POWER-QUALITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2,
Integer32
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF
UnitMultiplier, pmPowerIndex
FROM POWER-MONITOR-MIB
OwnerString
FROM RMON-MIB;
powerQualityMIB MODULE-IDENTITY
LAST-UPDATED "201105010000Z" -- 1 May 2011
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,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad@bradschoening.com
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 52]
Internet-Draft <Energy Monitoring MIB> May 2011
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 quality in
devices. The table is a sparse augmentation of the
pmPowerTable table from the powerMonitorMIB module.
Both three-phase and single-phase power
configurations are supported."
REVISION
"201105010000Z" -- 1 May 2011
DESCRIPTION
"Initial version, published as RFC YYY."
::= { mib-2 yyy }
EDITOR'S NOTE: editors, please replace YYY by the new RFC. IANA,
please replace yyy by the new MIB OID.
powerQualityMIBConform OBJECT IDENTIFIER
::= { powerQualityMIB 0 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 53]
Internet-Draft <Energy Monitoring MIB> May 2011
powerQualityMIBObjects OBJECT IDENTIFIER
::= { powerQualityMIB 1 }
-- Objects
pmACPwrQualityTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmACPwrQualityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table defines power quality measurements for
supported pmPowerIndex entities. It is a sparse
extension of the pmPowerTable."
::= { powerQualityMIBObjects 1 }
pmACPwrQualityEntry OBJECT-TYPE
SYNTAX PmACPwrQualityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a sparse extension of the pmPowerTable with
entries for power quality measurements or
configuration. Each measured value corresponds to an
attribute in IEC 61850-7-4 for non-phase measurements
within the object MMUX."
INDEX { pmPowerIndex }
::= { pmACPwrQualityTable 1 }
PmACPwrQualityEntry ::= SEQUENCE {
pmACPwrQualityConfiguration INTEGER,
pmACPwrQualityAvgVoltage Integer32,
pmACPwrQualityAvgCurrent Integer32,
pmACPwrQualityFrequency Integer32,
pmACPwrQualityPowerUnitMultiplier UnitMultiplier,
pmACPwrQualityPowerAccuracy Integer32,
pmACPwrQualityTotalActivePower Integer32,
pmACPwrQualityTotalReactivePower Integer32,
pmACPwrQualityTotalApparentPower Integer32,
pmACPwrQualityTotalPowerFactor Integer32,
pmACPwrQualityThdAmpheres Integer32,
pmACPwrQualityThdVoltage Integer32
}
pmACPwrQualityConfiguration OBJECT-TYPE
SYNTAX INTEGER {
sngl(1),
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 54]
Internet-Draft <Energy Monitoring MIB> May 2011
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."
::= { pmACPwrQualityEntry 1 }
pmACPwrQualityAvgVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value for average 'instantaneous' RMS line
voltage. For a 3-phase system, this is the average
voltage (V1+V2+V3)/3. IEC 61850-7-4 measured value
attribute 'Vol'"
::= { pmACPwrQualityEntry 2 }
pmACPwrQualityAvgCurrent 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'"
::= { pmACPwrQualityEntry 3 }
pmACPwrQualityFrequency OBJECT-TYPE
SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz
UNITS "hertz"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 55]
Internet-Draft <Energy Monitoring MIB> May 2011
"A measured value for the basic frequency of the AC
circuit. IEC 61850-7-4 attribute 'Hz'."
::= { pmACPwrQualityEntry 4 }
pmACPwrQualityPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
pmACPwrQualityTotalActivePower,
pmACPwrQualityTotalReactivePower
and pmACPwrQualityTotalApparentPower measurements. For
3-phase power systems, this will also include
pmACPwrQualityPhaseActivePower,
pmACPwrQualityPhaseReactivePower and
pmACPwrQualityPhaseApparentPower"
::= { pmACPwrQualityEntry 5 }
pmACPwrQualityPowerAccuracy 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
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"
::= { pmACPwrQualityEntry 6 }
pmACPwrQualityTotalActivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "RMS 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'."
::= { pmACPwrQualityEntry 7 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 56]
Internet-Draft <Energy Monitoring MIB> May 2011
pmACPwrQualityTotalReactivePower 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'."
::= { pmACPwrQualityEntry 8 }
pmACPwrQualityTotalApparentPower 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'."
::= { pmACPwrQualityEntry 9 }
pmACPwrQualityTotalPowerFactor 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. 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'."
::= { pmACPwrQualityEntry 10 }
pmACPwrQualityThdAmpheres OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 57]
Internet-Draft <Energy Monitoring MIB> May 2011
"A calculated value for the current total harmonic
distortion (THD). Method of calculation is not
specified. IEC 61850-7-4 attribute 'ThdAmp'."
::= { pmACPwrQualityEntry 11 }
pmACPwrQualityThdVoltage 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'."
::= { pmACPwrQualityEntry 12 }
pmACPwrQualityPhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmACPwrQualityPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes 3-phase power quality
measurements. It is a sparse extension of the
pmACPwrQualityTable."
::= { powerQualityMIBObjects 2 }
pmACPwrQualityPhaseEntry OBJECT-TYPE
SYNTAX PmACPwrQualityPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes common 3-phase power quality
measurements.
This optional table describes 3-phase power quality
measurements, with three entries for each supported
pmPowerIndex 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
pmACPwrQualityTable.
These attributes correspond to IEC 61850-7.4 MMXU phase
measurements."
INDEX { pmPowerIndex, pmPhaseIndex }
::= { pmACPwrQualityPhaseTable 1 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 58]
Internet-Draft <Energy Monitoring MIB> May 2011
PmACPwrQualityPhaseEntry ::= SEQUENCE {
pmPhaseIndex Integer32,
pmACPwrQualityPhaseAvgCurrent Integer32,
pmACPwrQualityPhaseActivePower Integer32,
pmACPwrQualityPhaseReactivePower Integer32,
pmACPwrQualityPhaseApparentPower Integer32,
pmACPwrQualityPhasePowerFactor Integer32,
pmACPwrQualityPhaseImpedance Integer32
}
pmPhaseIndex OBJECT-TYPE
SYNTAX Integer32 (0..359)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A phase angle typically corresponding to 0, 120, 240."
::= { pmACPwrQualityPhaseEntry 1 }
pmACPwrQualityPhaseAvgCurrent 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 'A'"
::= { pmACPwrQualityPhaseEntry 2 }
pmACPwrQualityPhaseActivePower OBJECT-TYPE
SYNTAX Integer32
UNITS "RMS 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'"
::= { pmACPwrQualityPhaseEntry 3 }
pmACPwrQualityPhaseReactivePower 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'"
::= { pmACPwrQualityPhaseEntry 4 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 59]
Internet-Draft <Energy Monitoring MIB> May 2011
pmACPwrQualityPhaseApparentPower 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 powwer.
Note: Watts and volt-ampheres are equivalent units and
may be combined. IEC 61850-7-4 attribute 'VA'."
::= { pmACPwrQualityPhaseEntry 5 }
pmACPwrQualityPhasePowerFactor 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
or negative where the sign should be in lead/lag (IEEE)
form."
::= { pmACPwrQualityPhaseEntry 6 }
pmACPwrQualityPhaseImpedance 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'."
::= { pmACPwrQualityPhaseEntry 7 }
pmACPwrQualityDelPhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmACPwrQualityDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes DEL configuration phase-to-phase
power quality measurements. This is a sparse extension
of the pmACPwrQualityPhaseTable."
::= { powerQualityMIBObjects 3 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 60]
Internet-Draft <Energy Monitoring MIB> May 2011
pmACPwrQualityDelPhaseEntry OBJECT-TYPE
SYNTAX PmACPwrQualityDelPhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes quality 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 pmPhaseIndex is
compared against the following phase at +120 degrees.
Thus, the possible values are:
pmPhaseIndex Next Phase Angle
0 120
120 240
240 0
"
INDEX { pmPowerIndex, pmPhaseIndex}
::= { pmACPwrQualityDelPhaseTable 1}
PmACPwrQualityDelPhaseEntry ::= SEQUENCE {
pmACPwrQualityDelPhaseToNextPhaseVoltage Integer32,
pmACPwrQualityDelThdPhaseToNextPhaseVoltage Integer32,
pmACPwrQualityDelThdCurrent Integer32
}
pmACPwrQualityDelPhaseToNextPhaseVoltage 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'."
::= { pmACPwrQualityDelPhaseEntry 2 }
pmACPwrQualityDelThdPhaseToNextPhaseVoltage OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "hundredths of percent"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 61]
Internet-Draft <Energy Monitoring MIB> May 2011
"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'."
::= { pmACPwrQualityDelPhaseEntry 3 }
pmACPwrQualityDelThdCurrent 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'."
::= { pmACPwrQualityDelPhaseEntry 4 }
pmACPwrQualityWyePhaseTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmACPwrQualityWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes WYE configuration phase-to-neutral
power quality measurements. This is a sparse extension
of the pmACPwrQualityPhaseTable."
::= { powerQualityMIBObjects 4 }
pmACPwrQualityWyePhaseEntry OBJECT-TYPE
SYNTAX PmACPwrQualityWyePhaseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes measurements of WYE configuration
with phase to neutral power quality attributes. Three
entries are required for each supported pmPowerIndex
entry. Voltage measurements are relative to neutral.
This is a sparse extension of the
pmACPwrQualityPhaseTable.
Each entry describes quality 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 { pmPowerIndex, pmPhaseIndex }
::= { pmACPwrQualityWyePhaseTable 1}
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 62]
Internet-Draft <Energy Monitoring MIB> May 2011
PmACPwrQualityWyePhaseEntry ::= SEQUENCE {
pmACPwrQualityWyePhaseToNeutralVoltage Integer32,
pmACPwrQualityWyePhaseCurrent Integer32,
pmACPwrQualityWyeThdPhaseToNeutralVoltage Integer32
}
pmACPwrQualityWyePhaseToNeutralVoltage 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'."
::= { pmACPwrQualityWyePhaseEntry 1 }
pmACPwrQualityWyePhaseCurrent 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'."
::= { pmACPwrQualityWyePhaseEntry 2 }
pmACPwrQualityWyeThdPhaseToNeutralVoltage 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'."
::= { pmACPwrQualityWyePhaseEntry 3 }
-- Conformance
powerQualityMIBCompliances OBJECT IDENTIFIER
::= { powerQualityMIB 2 }
powerQualityMIBGroups OBJECT IDENTIFIER
::= { powerQualityMIB 3 }
powerQualityMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 63]
Internet-Draft <Energy Monitoring MIB> May 2011
"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 -- this module
MANDATORY-GROUPS {
powerACPwrQualityMIBTableGroup,
powerACPwrQualityPhaseMIBTableGroup
}
GROUP powerACPwrQualityDelPhaseMIBTableGroup
DESCRIPTION
"This group must only be implemented for a DEL phase
configuration."
GROUP powerACPwrQualityWyePhaseMIBTableGroup
DESCRIPTION
"This group must only be implemented for a WYE phase
configuration."
::= { powerQualityMIBCompliances 1 }
-- Units of Conformance
powerACPwrQualityMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmPowerIndex is NOT
-- included since it is not-accessible
pmACPwrQualityConfiguration,
pmACPwrQualityAvgVoltage,
pmACPwrQualityAvgCurrent,
pmACPwrQualityFrequency,
pmACPwrQualityPowerUnitMultiplier,
pmACPwrQualityPowerAccuracy,
pmACPwrQualityTotalActivePower,
pmACPwrQualityTotalReactivePower,
pmACPwrQualityTotalApparentPower,
pmACPwrQualityTotalPowerFactor,
pmACPwrQualityThdAmpheres,
pmACPwrQualityThdVoltage
} STATUS current
DESCRIPTION
"This group contains the collection of all the power
quality objects related to the Power Monitor."
::= { powerQualityMIBGroups 1 }
powerACPwrQualityPhaseMIBTableGroup OBJECT-GROUP
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 64]
Internet-Draft <Energy Monitoring MIB> May 2011
OBJECTS {
-- Note that object pmPowerIndex is NOT
-- included since it is not-accessible
pmACPwrQualityPhaseAvgCurrent,
pmACPwrQualityPhaseActivePower,
pmACPwrQualityPhaseReactivePower,
pmACPwrQualityPhaseApparentPower,
pmACPwrQualityPhasePowerFactor,
pmACPwrQualityPhaseImpedance
}
STATUS current
DESCRIPTION
"This group contains the collection of all 3-phase power
quality objects related to the Power State."
::= { powerQualityMIBGroups 2 }
powerACPwrQualityDelPhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmPowerIndex and
-- pmPhaseIndex are NOT included
-- since they are not-accessible
pmACPwrQualityDelPhaseToNextPhaseVoltage ,
pmACPwrQualityDelThdPhaseToNextPhaseVoltage,
pmACPwrQualityDelThdCurrent
}
STATUS current
DESCRIPTION
"This group contains the collection of all quality
attributes of a phase in a DEL 3-phase power system."
::= { powerQualityMIBGroups 3 }
powerACPwrQualityWyePhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmPowerIndex and
-- pmPhaseIndex are NOT included
-- since they are not-accessible
pmACPwrQualityWyePhaseToNeutralVoltage,
pmACPwrQualityWyePhaseCurrent,
pmACPwrQualityWyeThdPhaseToNeutralVoltage
}
STATUS current
DESCRIPTION
"This group contains the collection of all WYE
configuration phase-to-neutral power quality
measurements."
::= { powerQualityMIBGroups 4 }
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 65]
Internet-Draft <Energy Monitoring MIB> May 2011
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 pmPowerOperState (via
thepmPowerAdminState ) MAY disrupt the power settings of the
different Power Monitors, and therefore the state of
functionality of the respective Power Monitors.
- Unauthorized changes to the pmEnergyParametersTable MAY
disrupt energy measurement in the pmEnergyTable 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.
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.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 66]
Internet-Draft <Energy Monitoring MIB> May 2011
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
---------- -----------------------
PowerMonitorMIB { mib-2 xxx }
powerQualityMIB { 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 Series
This document specifies an initial set of Power State Series.
The list of these Power State Series with their numeric
identifiers is given in Section 5.2.1. The Internet Assigned
Numbers Authority (IANA) has created a new registry for Power
State Series numeric identifiers and filled it with the initial
list as in Section 5.2.1. New Assignments to Power State Series
shall be administered by IANA and the guidelines and procedures
are listed in this Section.
New assignments in Power State Series require a Standards Action
[RFC5226], i.e., they are to be made via Standards Track RFCs
approved by the IESG. The new Power State Series based on the
following guidelines; firstly check if there are devices or
entities that have implementations of the proposed Power State
Series or secondly, if the new Power State Series has been
adopted or approved by the respective energy management
standards organizations. A pure vendor specific implementation
of Power State Series shall not be adopted; since it would lead
to proliferation of Power State Series.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 67]
Internet-Draft <Energy Monitoring MIB> May 2011
12.2.1. IANA Registration of the IEEE1621 Power State Series
This document specifies a set of values for the IEEE1621 Power
State Series [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 Series identifiers and filled it with the initial
list in Section 5.2.2.
New assignments (or potentially deprecation) for IEEE1621 Power
State Series 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 Series
This document specifies a set of values for the DMTF Power State
Series. 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 Series
identifiers and filled it with the initial list in Section
5.2.1.
New assignments (or potentially deprecation) for DMTF Power
State Series 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
checking for completeness and accuracy of the description.
12.2.3. IANA Registration of the EMAN Power State Series
This document specifies a set of values for the EMAN Power State
Series. 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 Series
identifiers and filled it with the initial list in Section
5.2.1.
New assignments (or potentially deprecation) for EMAN Power
State Series New assignments in Power State Series require a
Standards Action , i.e., they are to be made via Standards Track
RFCs approved by the IESG.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 68]
Internet-Draft <Energy Monitoring MIB> May 2011
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
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.
14. References
14.2. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 69]
Internet-Draft <Energy Monitoring MIB> May 2011
[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-01 ", work in progress, March 2011.
14.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.
[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-01 (work in
progress),March 2011. .
[EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and J.
Quittek, "Energy Management Framework", draft-ietf-
eman-framework-01 , March 2011.
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 70]
Internet-Draft <Energy Monitoring MIB> May 2011
[EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz, T.,
Quittek, J. and B. Claise "Energy and Power Monitoring
MIB ", draft-claise-energy-monitoring-mib-08, May 2011.
[EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy
Management (EMAN) Applicability Statement", draft-
tychon-eman-applicability-statement-01, work in
progress, March 2011.
[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
Office/Consumer Environments", IEEE 1621, December
2004.
Authors' Addresses
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Email: brad@bradschoening.com
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
<Claise, et. Al> Expires Novmeber 23, 2011 [Page 71]
Internet-Draft <Energy Monitoring MIB> May 2011
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
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 Novmeber 23, 2011 [Page 72]