Network Working Group B. Claise
Internet-Draft M. Chandramouli
Intended Status: Standards Track J. Parello
Expires: January 12, 2010 B. Schoening
Cisco Systems, Inc.
July 12, 2010
Power and Energy Monitoring MIB
draft-claise-energy-monitoring-mib-04
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, 2010.
<Claise, et. Al> Expires January 12 2010 [Page 1]
Internet-Draft <Energy Monitoring MIB> July 2010
Copyright Notice
Copyright (c) 2010 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", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction............................................. 4
2. The Internet-Standard Management Framework............... 4
3. Use Cases................................................ 5
4. Terminology.............................................. 5
5. Concepts................................................. 7
5.1 Summary.............................................. 7
5.2 Power Monitor Information............................ 8
5.3 Power Monitor Meter Domain........................... 9
5.4 Power Monitor Parent and Child....................... 9
5.5 Power Monitor Context............................... 10
5.6 Power Monitor Levels................................ 10
5.7 Power Monitor Usage Measurement..................... 14
5.8 Optional Power Usage Quality........................ 15
5.9 Optional Energy Measurement......................... 15
5.10 Optional Battery Information....................... 18
<Claise, et. Al> Expires January 12, 2010 [Page 2]
Internet-Draft <Energy Monitoring MIB> July 2010
6. Implementation Scenarios................................ 18
Scenario 1: Switch with PoE endpoints................... 18
Scenario 2: Switch with PoE endpoints with further
connected device(s)..................................... 19
Scenario 3: A switch with Wireless Access Points........ 21
Scenario 4: Network connected facilities gateway........ 23
Scenario 5: Data Center Network......................... 24
Scenario 6: Power Consumption of UPS.................... 26
Scenario 7: Power Consumption of Battery-based Devices.. 27
7. Link with the other IETF MIBs........................... 27
7.1. Link with the ENTITY MIB and the ENTITY-SENSOR MIB. 27
7.2. Link with the ENTITY-STATE MIB..................... 28
7.3. Link with the POWER-OVER-ETHERNET MIB.............. 29
7.4. Link with the UPS MIB.............................. 29
7.5. Link with the LLDP and LLDP-MED MIBs............... 30
8. Structure of the MIB.................................... 31
9. MIB Definitions......................................... 32
10. Security Considerations................................ 72
11. IANA Considerations.................................... 73
12. References............................................. 74
12.1. Normative References.............................. 74
12.2. Informative References............................ 74
13. Authors' Addresses..................................... 75
<Claise, et. Al> Expires January 12, 2010 [Page 3]
Internet-Draft <Energy Monitoring MIB> July 2010
1. Introduction
Network management is typically divided into areas of concerns
according to the ISO Telecommunications Management Network
model. The model defines Fault, Configuration, Accounting,
Performance, and Security Management. Notably missing is an
area of concern specifically covering energy management at an
equal level to these areas.
With energy becoming a more critical area of concern, this
document defines a subset of the Management Information Base
(MIB) for use with devices in and connected to communication
networks for energy management. 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
requirements specified in [POWER-MON-REQ].
Energy management is applicable to devices that comprise and
that are connected to a communication network. Target devices
for this specification include (but are not limited to):
routers, switches, Power over Ethernet (PoE) endpoints, protocol
gateways for building management systems, intelligent meters,
home energy gateway, hosts and servers, sensor proxy, etc.
Where applicable, monitoring of a device is extended to the
individual components of the device and/or to any attached
dependent device(s). An example of such a case could be when a
device contains components that are independent from a power
state point of view (such as line cards, processor cards, hard
drives) or when a devices has 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].
<Claise, et. Al> Expires January 12, 2010 [Page 4]
Internet-Draft <Energy Monitoring MIB> July 2010
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
the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD
58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
3. Use Cases
The requirements for power and energy monitoring for networking
devices are specified in [POWER-MON-REQ]. The requirements in
[POWER-MON-REQ] cover devices that typically make up a
communications network such as such as switches, routers, and
various connected endpoints. For power monitoring to be useful,
a specification should also be applicable 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. Due to this fact,
the scope of the MIB modules in this document is broader than
that specified in [POWER-MON-REQ]. Several scenarios that cover
these broader use cases are presented later in Section 6 -
Implementation Scenarios.
4. Terminology
This section contains definitions of major terms used in
explaining the concepts, examples, and the MIB definitions.
Power Monitor
A Power Monitor is a system of one or more components that
provide power, draws power, or reports energy consumption on
behalf of another Power Monitor. It can be independently
managed from a power monitoring and power state configuration
point of view. This Power Monitor may be represented by a
physical component referenced using the EntPhysicalTable from
the ENTITY MIB [RFC4133], or by a port and group in the Power
over Ethernet MIB [RFC3621]. Examples of Power Monitors are: a
router line card, a motherboard with a CPU, an IP phone
connected with a switch, etc.
Power Monitor Parent
<Claise, et. Al> Expires January 12, 2010 [Page 5]
Internet-Draft <Energy Monitoring MIB> July 2010
A Power Monitor Parent is a Power Monitor that is the root of
one or multiple subtending Power Monitors, called Power Monitor
Children. The Power Monitor Parent is able to report the power
state and energy consumption for his Power Monitor Child(ren).
For example, in case of Power-over-Ethernet (PoE) device such as
an IP phone or an access point attached to a switch port, the
switch is the source of power for the attached device. In such
a case, the Power Monitor Parent is the port of the switch,
while the attached device is the Power Monitor Child.
Power Monitor Child
A Power Monitor Child is a Power Monitor associated to a Power
Monitor Parent, which draws power from its Power Monitor Parent
or reports its power usage and power state to its Power Monitor
Parent.
Power Monitor Meter Domain
A Power Monitor Meter Domain is a name or name space that
logically groups together Power Monitors that comprises a zone
of manageable power usage. Typically, this will comprise all
Power Monitors that are powered from the same electrical panel
or panels for which there is a meter or sub meter. For example,
all Power Monitors receiving power from the same distribution
panel of a building, or all Power Monitors in a building for
which there is one main meter. From the point of monitoring
power use, it is useful to report the total power usage as the
sum of power consumed by all the Power Monitors within a Power
Monitor Meter Domain and then correlate that value to the
metered usage.
Power Level
A uniform way to classify power settings on a Power Monitor
(e.g., shut, hibernate, sleep, high). Power Levels can be
viewed as an interface for interacting with the underlying
device implemented power settings.
User Defined Power Level
A device specific way to classify power settings implemented on
a Power Monitor. For cases where the implemented power setting
<Claise, et. Al> Expires January 12, 2010 [Page 6]
Internet-Draft <Energy Monitoring MIB> July 2010
cannot be directly mapped to a Power Level(s), the User Defined
Power Levels are used to enumerate and show the relationship
between the implemented power settings and the Power Level
interface.
5. Concepts
This section will go over the basic concepts of the Power
Monitor MIB. The basic concepts are summarized and then each is
listed with notable descriptions that give background before
reading the actual MIB definitions.
Examples will be provided in a later section to show how these
concepts can be fulfilled in an implementation.
5.1 Summary
Given a Power Monitor, we can describe the information about the
Power Monitor through various data. A Power Monitor will have
basic naming and informational descriptors to identify it in the
network.
A Power Monitor can be part of a Power Monitor Meter Domain. A
Power Monitor Meter Domain is a manageable set of devices that
has a meter or sub-meter attached and typically corresponds to a
power distribution point or panel.
A Power Monitor can be a parent (Power Monitor Parent) or child
(Power Monitor Child) of another Power Monitor. This allows for
devices to aggregate reporting and/or control of power
information.
Each Power Monitor can have information to allow it to be
described in the context of the business or ultimate use. This
is in addition to its networked information. This allows for
tagging, grouping and differentiation between Power Monitors for
NMS.
For control and universal monitoring each Power Monitor will
implement or declare a set of known Power Levels. The Power
Levels can be mapped to User Defined Power Levels that indicate
the specific power setting for the device implementing the Power
Monitor.
<Claise, et. Al> Expires January 12, 2010 [Page 7]
Internet-Draft <Energy Monitoring MIB> July 2010
Each Power Monitor will have usage information that describes
the instantaneous power information along with how that usage
was obtained or derived.
Optionally a Power Monitor can further describe the
instantaneous power information with power quality information
reflecting the electrical characteristics of the measurement.
Optionally a Power Monitor can provide power usage over time to
describe energy consumption
If a Power Monitor has one or more batteries, it can provide
optional Battery information as well.
5.2 Power Monitor Information
Every Power Monitor should have a printable name pmName, and a
unique Power Monitor index pmIndex.
pmIndex is an unique index greater than zero for each Power
Monitor. It is recommended that values be assigned sequentially
starting from 1. The value for each pmIndex must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization. In
addition, that Power Monitor can potentially have an
entityPhysicalIndex from the ENTITY MIB [RFC4133] in the
pmPhysicalEntity, if supported by the Power Monitor. In case of
Power over Ethernet (if the Power over Ethernet MIB is supported
on the Power Monitor), the Power Monitor pmethPortIndex and
pmethPortGrpIndex must contain the values of pethPsePortIndex
and pethPsePortGroupIndex, respectively. In case of LLDP-MED
(if the LLDP-MED MIB is supported on the Power Monitor), the
Power Monitor pmLldpPortNumber must contain the lldpLocPortNum
from the LLDP MIB.
Possible pmName conventions are: textual DNS name, MAC-address
of the device, interface ifName, or a text string uniquely
identifying the Power Monitor. However, if entPhysicalName is
present for the respective pmPhysicalEntity (i.e. if the ENTITY-
MIB is supported), then the pmName SHOULD be identical to the
entPhysicalName. The pmName SHOULD be unique. As an example,
in the case of IP phones, pmName can be the device DNS name,
while in the case of router/switch line cards, the pmName should
contain the entPhysicalName.
<Claise, et. Al> Expires January 12, 2010 [Page 8]
Internet-Draft <Energy Monitoring MIB> July 2010
To distinguish if a Power Monitor is producing, consuming or
metering power, the pmPowerCategory MIB object must be
implemented.
5.3 Power Monitor Meter Domain
Each Power Monitor can be a member of a Power Monitor Meter
Domain. The Power Monitor Meter Domain could map 1-1 with a
metered or sub-metered portion of the site. It can be used to
further sub divide the deployment down to finer Power Monitor
Meter Domains such as a floor, lab, data center, rack, etc.
With the possible evolution of this draft to a framework
document the notion of Power Monitor Meter Domain will be useful
to provide a name space for power distribution points.
The Power Monitor Meter Domain MUST be configured on the Power
Monitor Parent. The Power Monitor Children may inherit its
domain value from the Power Monitor Parent. Note that the
specification of how to communicate this information between the
Power Monitor Parent and Children is out of the scope of this
document. One point of the parent/child design is that
typically the network is fixed and the endpoints are transient.
In some cases, Power Monitor Children may have a static non-
transient configuration. In such cases, the Power Monitor Meter
Domain MAY be configured directly in Power Monitor Child.
5.4 Power Monitor Parent and Child
A Power Monitor can be connected to another Power Monitor and
either draw power from that entity or report power usage to that
entity.
The use of a Power Monitor Parent is not limited to just PoE
children. A Power Monitor Child can be fully dependent on the
Power Monitor Parent or independent from the parent. In the
dependent case, the Power Monitor Parent provides power for the
Power Monitor Child (the PoE case). In the independent case,
the Power Monitor Child draws power from another source
(typically a wall outlet). Since the switch is not the source
of power supply, the power usage cannot be measured at the Power
Monitor Parent. However, an independent Power Monitor Child
may report Power Monitor information to the Power Monitor
Parent. The Power Monitor Child may listen to the power control
settings from a Power Monitor Parent and could react to the
control messages. Note that the communication between the Power
<Claise, et. Al> Expires January 12, 2010 [Page 9]
Internet-Draft <Energy Monitoring MIB> July 2010
Monitor Parent and Power Monitor Child is out of scope of this
document.
In order to link the Power Monitor Child and the Power Monitor
Parent the pmParentId is introduced.
Further examples of Power Monitor Parent and Child
implementations are provided in the Implementation Scenarios
section.
5.5 Power Monitor Context
Monitored power will ultimately be collected to and reported
from a NMS. In order to aid in the reporting and
differentiation between Power Monitors, each Power Monitor will
contain information to establish a business or site context.
A Power Monitor can provide a pmImportance value in the range of
1..100 to help differentiate the use or relative value to the
site.
A Power Monitor can provide a set of pmKeywords. These keywords
are a list of tags that can be used for grouping and summary
reporting within or between Power Monitor Meter Domains.
Additionally, a Power Monitor can provide a pmRoleDescription
string that indicates the purpose the Power Monitor serves in
the network or to site/business.
5.6 Power Monitor Levels
Power Levels represent universal states of power management of a
Power Monitor. The higher the Power Level, the higher the power
consumed. Each Power Level corresponds to a global, system, and
performance state in the ACPI model.
Level ACPI Global/System Name
State
Non-operational states:
1 G3, S5 Mech Off
2 G2, S5 Soft Off
3 G1, S4 Hibernate
4 G1, S3 Sleep
5 G1, S2 Standby
<Claise, et. Al> Expires January 12, 2010 [Page 10]
Internet-Draft <Energy Monitoring MIB> July 2010
6 G1, S1 Ready
Operational states:
7 G0, S0, P5 LowMinus
8 G0, S0, P4 Low
9 G0, S0, P3 MediumMinus
10 G0, S0, P2 Medium
11 G0, S0, P1 HighMinus
12 G0, S0, P0 High
For example, a Power Monitor with a Power Level of 9 would
indicate an operational state with MediumMinus Power Level.
The Power Levels can be considered as guidelines for an
interface in order to promote interoperability across device
types. Realistically, it is foreseen that each specific feature
requiring Power Levels will require a complete recommendation of
its own. For example, designing IP phones with consistent Power
Levels across vendors requires a specification for IP phone
design, along with the Power Levels mapping.
In some situations, the Power Monitor Child cannot immediately
be set to a specific Power Level, even if supports this specific
Power Level. For example, a phone must wait until the call is
finished to reduce his Power Level. For example, a PC must
finish his backup before going into a hibernate state. Another
reason why the Power Monitor Child cannot immediately be set to
a specific Power Level is that the MIB module is supported on
the Power Monitor Parent while the configuration refers to a
remote Power Monitor Child.
Therefore, there are actually two MIB variables related to the
Power Levels: one for the requested Power Level (pmPowerLevel)
and the other one for the actual Power Level
(pmPowerActualLevel). pmPowerLevel is read-write, while
pmPowerActualLevel is read-only. In order to change the Power
Level, the NMS sets the pmPowerLevel to the new value. At this
point in time, the Power Monitor Child MUST transition to the
Power Level as soon as possible. Once done, the
pmPowerActualLevel is changed to the new Power Level.
When polling from the NMS, a difference in values between the
pmPowerLevel and pmPowerActualLevel implies that this specific
Power Monitor Child is currently in transition.
In some situation, User Defined Power Levels are required, for
example, when no mappings with the existing Power Levels are
possible or when more levels than the twelve specified Power
<Claise, et. Al> Expires January 12, 2010 [Page 11]
Internet-Draft <Energy Monitoring MIB> July 2010
Levels are required. In such cases, this MIB module, via the
pmUserDefinedPowerLevel MIB variable, gives the possibility to
specify those User Defined Power Levels. Like for the Power
Level, the higher the User Defined Power Level, the higher the
power consumed. Finally, the User Defined Power Level name can
be set with the pmUserDefinedPowerLevelName MIB variable.
A first example would be an imaginary device type, with only
five levels: "none", "short", "tall", "grande", and "venti".
User Defined Power Level Respective Name
0 none
1 short
2 tall
3 grande
4 venti
In the unlikely event of no possible mapping between these User
Defined Power Levels and the Power Levels, the pmPowerLevel will
remain 0 throughout the MIB module, as displayed below.
Power Level / Name User Defined Power Level / Name
0 / unknown 0 / none
0 / unknown 1 / short
0 / unknown 2 / tall
0 / unknown 3 / grande
0 / unknown 4 / venti
If a mapping between the User Defined Power Levels and the Power
Levels is achievable, both series of levels exist in the MIB
module, allowing the NMS to understand the mapping between them
by correlating the pmPowerLevel with the
(pmUserDefinedPowerLevel, pmUserDefinedPowerLevelName).
Power Level / Name User Defined Power Level / Name
1 / Mech Off 0 / none
2 / Soft Off 0 / none
3 / Hibernate 0 / none
4 / Sleep, Save-to-RAM 0 / none
5 / Standby 0 / none
6 / Ready 1 / short
7 / LowMinus 1 / short
8 / Low 1 / short
9 / MediumMinus 2 / tall
10 / Medium 2 / tall
11 / HighMinus 3 / grande
12 / High 4 / venti
<Claise, et. Al> Expires January 12, 2010 [Page 12]
Internet-Draft <Energy Monitoring MIB> July 2010
How the Power Monitor Levels are then mapped, i.e. assigning the
directly lower or directly higher level, is an implementation
choice. However, its recommended that the User Defined Power
Level maps to the directly lower Power Level, so that setting
all Power Meters to a Power Level would be conservative in terms
of disabled functionality on the Power Monitor implementing the
User Defined Power Levels.
A second example would be a device type, such as a dimmer or a
motor, with a high number of operational levels. For the sake
of the example, 100 operational states are assumed.
Power Level / Name User Defined Power Level / Name
1 / Mech Off 0 / off
2 / Soft Off 0 / off
3 / Hibernate 0 / off
4 / Sleep, Save-to-RAM 0 / off
5 / Standby 0 / off
6 / Ready 0 / off
7 / LowMinus 1 / 1%
7 / LowMinus 2 / 2%
7 / LowMinus 3 / 3%
. .
. .
. .
8 / Low 15 / 15%
8 / Low 16 / 16%
8 / Low 17 / 17%
. .
. .
. .
9 / MediumMinus 30 / 30%
9 / MediumMinus 31 / 31%
9 / MediumMinus 32 / 32%
. .
. .
. .
10 / Medium 45 / 45%
10 / Medium 46 / 46%
10 / Medium 47 / 47%
. .
. .
. .
etc...
Regarding the pmPowerLevelTable population, which enumerates the
maximum power usage in watts, for every single supported Power
Level and User Defined Power Level of each Power Monitor, if
<Claise, et. Al> Expires January 12, 2010 [Page 13]
Internet-Draft <Energy Monitoring MIB> July 2010
both the Power Level and User Defined Power Level are used in
the Power Monitor (non 0 values), then it might be advantageous
to populate all Power Level entries. This would allow an NMS to
set all Power Monitors to a certain Power Level, regardless of
the mapping to a User Define Power Level or not.
5.7 Power Monitor Usage Measurement
For a Power Monitor, instantaneous power usage is reported using
pmPower. The magnitude of measurement is based on the
pmPowerUnitMultiplier MIB variable, based on the UnitMultiplier
Textual Convention (TC).
pmPowerUnitMultiplier is a scaling factor used to represent the
magnitude of Power Monitor usage. It conforms to the IEC 61850
definition of unit multiplier for the SI (System International)
units of measure. Measured values are represented in SI units
obtained by BaseValue * 10 raised to the power of Scale. For
example, if current power usage of a Power Monitor is 3, it
could be 3 W, 3 mW, 3 KW, 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 pmPowerLevelPowerUnitMultiplier,
pmDemandIntervalEnergyUnitMultiplier, 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 pmPowerCaliber describes
the method that was used to measure the power and can
distinguish actual or estimated values.
In addition to the instantaneous usage the nameplate power
rating of a Power Monitor is typically specified by the vendor
as the capacity required to power the device. Often this label
is a conservative number and is the worst-case power draw.
While the actual utilization of an entity can be lower,
pmPowerNameplate is important for provisioning, capacity
planning and billing.
[POWER-MON-REQ] specifies some requirements about power states
such as "the current state - the time of the last change", "the
total time spent in each state", "the number of transitions to
each state", etc... Such requirements are fulfilled via the
<Claise, et. Al> Expires January 12, 2010 [Page 14]
Internet-Draft <Energy Monitoring MIB> July 2010
pmPowerLevelChange NOTIFICATION-TYPE, indexed by pmPowerLevel
and pmUserDefinedPowerLevel. This SNMP notification is
generated when the value(s) of pmPowerLevel and/or
pmUserDefinedPowerLevel has/have changed for the Power Monitor
represented by the pmIndex.
5.8 Optional Power Usage Quality
Given an instantaneous power measurement of a Power Monitor, it
may in certain circumstances be desirable to know the power
quality associated with that measurement. An optional
powerQualityMIB MIB module can be implemented to further
describe the measurement. The powerQualityMIB MIB module
adheres closely to the IEC 61850 7-2 standard to describe AC
measurements. In some Power Monitor Domains, the power quality
may not be needed, available, nor relevant to the Power Monitor.
In those cases, the powerQualityMIB need not be provided.
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 pmTable (so with pmIndex as primary index).
This pmACPwrQualityTable table contains information such as the
configuration (single phase, DEL 3 phases, WYE 3 phases), the
voltage, frequency, power accuracy, total active/reactive
power/apparent power, the amphere, and the voltage.
In case of 3-phase power, the pmACPwrQualityPhaseTable
additional table is populated with power quality measurements
per phase (so double indexed by the pmIndex 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 the 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.9 Optional Energy Measurement
In addition to reporting the Power Level, an approach to
characterize the energy demand is also presented in the MIB
<Claise, et. Al> Expires January 12, 2010 [Page 15]
Internet-Draft <Energy Monitoring MIB> July 2010
module. It is well known in commercial electrical utility
rates, that demand charges can be on par with actual power
charges. So, it is useful to characterize the demand. The
demand can be described as the average energy of an Power
Monitor over a time window, called a demand interval, typically
15 minutes. The highest peak energy demand measured over a time
horizon, say 1 month or 1 year is often the basis for usage
charges. A single window of time of high usage can penalize the
energy consumption charges. However, it is relevant to measure
the demand only 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
PowerMeasurementCaliber.
Two tables are introduced to characterize the energy demand -
pmDemandEnergyTable and pmDemandEnergyParametersTable. The
pmDemandEnergyParametersTable table consists of parameters
defining: the duration of the demand intervals in seconds,
pmDemandEnergyParametersIntervalLength; the number of demand
intervals kept in the pmDemandEnergyTable,
pmDemandEnergyParametersIntervalNumber; the type of demand
intervals, pmDemandEnergyParametersIntervalMode, and a same rate
used to calculate the average,
pmDemandEnergyParametersSampleRate. Judicious choice of the
SamplingRate will ensure accurate measurement of power while not
imposing an excessive polling burden. If the interval mode is
'sliding', pmDemandEnergyParametersIntervalWindow specifies the
interval between windows. The pmDemandEnergyParametersStatus is
useful to specify the energy measurement is actual and thus to
indicate if the pmDemandEnergyTable entries exist or not.
The pmDemand Table consists of energy measurements in
pmDemandIntervalEnergyUsed, the scale of energy measured,
pmDemandIntervalEnergyUnitMultiplier, and the maximum observed
demand in a window - pmDemandIntervalMax.
Several efficiency metrics can be derived and tracked with the
usage data present in this MIB module.
. For example, per-packet power costs for a networking device
(router or switch) can be calculated by an network
management system. The packets count can be determined
from the traffic usage in the ifTable [RFC2863] from the
forwarding plane figure, or from the platform
specifications.
<Claise, et. Al> Expires January 12, 2010 [Page 16]
Internet-Draft <Energy Monitoring MIB> July 2010
. Watt-hour power use from this MIB can be combined with
utility energy sources to estimate carbon footprint and
other emission statistics.
The pmDemandEnergyTable and pmDemandEnergyParametersTable will
be illustrated with the following example. First, in order to
estimate demand, an interval to sample energy should be
specified, i.e. pmDemandEnergyParametersIntervalLength can be
"900 seconds" and the number of consecutive intervals over which
the maximum demand is calculated
pmDemandEnergyParametersIntervalNumber as "10". The sampling
rate internal to the Power Monitor for measurement of power
usage, pmDemandEnergyParametersSampleRate, can be "1000
milliseconds", as set by the Power Monitor as a reasonable
value. Then, the pmDemandEnergyParametersStatus is set to
active (value 1) to indicate that the Power Monitor should start
monitor the usage as per the pmDemandEnergyTable.
The indices in the pmDemandEnergyTable are pmIndex, which
identifies the Power Monitor, and pmDemandIntervalStartTime,
which denotes the start time of the demand measurement interval
based on sysUpTime. The value of pmDemandIntervalEnergyUsed is
the measured energy consumption over the time interval specified
(pmDemandEnergyParametersIntervalLength) based on the Power
Monitor internal sampling rate
(pmDemandEnergyParametersSampleRate). The units are derived
from pmDemandIntervalPowerUnitMultiplier. For example,
pmDemandIntervalPowerUsed can be "100" with
pmDemandIntervalPowerUnits equal to 0, the demand is 100 watt-
hours. pmDemandIntervalMax is the maximum demand observed can
be "150 watt-hours".
The pmDemandEnergyTable has a buffer to retain a certain number
of intervals, as defined by
pmDemandEnergyParametersIntervalNumber. If the default value of
"10" is kept, then the pmDemandEnergyTable contains 10 demand
measurements, including the maximum. A brief explanation on how
the maximum demand can be calculated is presented. The first
observed demand measurement value is taken to be the initial
maximum. With each subsequent measurement, based on numerical
comparison, maximum demand may be updated. The maximum value is
retained as long as the measurements are taking place. Based on
periodic polling of this table, a NMS could compute the maximum
over a longer period, i.e. a month, 3 months, or a year.
<Claise, et. Al> Expires January 12, 2010 [Page 17]
Internet-Draft <Energy Monitoring MIB> July 2010
5.10 Optional Battery Information
EDITOR NOTE: since a merge between this draft and [QUITTEK-
POWER-MIB] seems to be the direction that the OPSAWG IETF WG
wants to go, one idea is to copy the battery MIB module from
[QUITTEK-POWER-MIB].
6. Implementation Scenarios
The scope of power and energy monitoring consists of devices
that consume power within and connected to a communications
network. These devices include:
- Network devices and sub-components: devices such as routers
and switches and their sub-components.
- Network attached endpoints: devices that use the
communications network such as endpoints, PCs, or facility
gateways that proxy energy monitor and control for commercial
buildings or home automation,
- Network attached meters or supplies: devices that can monitor
the electrical supply such as smart meters or Universal Power
Supplies (UPS) that meter and provide availability.
This section provides illustrative examples that model different
scenarios for implementation of the Power Monitor including
Power Monitor Parent and Power Monitor Child relationships.
Scenario 1: Switch with PoE endpoints
Consider a PoE IP phone connected to a switch, as displayed on
figure 1. The IP phone draws power from the PoE switch. The
switch has the following attributes, also illustrated in Figure
1: pmIndex "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 pmIndex "3", pmPhysicalEntity is "12" and
pmPowerMonitorId is "UUID 1003". The power usage of the POE
switch port is "12 watts". The POE switch port has the switch
as the Power Monitor Parent, with its pmParentID of "1000".
The IP phone has the following attributes: the IP phone has
pmIndex "31" and pmPowerMonitorId "UUID 2003", but doesn't have
<Claise, et. Al> Expires January 12, 2010 [Page 18]
Internet-Draft <Energy Monitoring MIB> July 2010
an entry for pmPhysicalEntity, as the ENTITY MIB is not
supported on this device. The IP phone has a Power Monitor
Parent; the POE switch port whose pmPowerMonitorId is "UUID
1003". The power usage of the IP phone is measured at the POE
switch port and the pmUsage on the PoE IP phone reports 0.
|--------------------------------------------------------------|
| Switch |
|==============================================================|
| |Switch | Switch | Switch | Switch | Switch | |
| |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| | 1 | 2 | UUID 1000 | null | 440 | |
| ============================================================ |
| |
| SWITCH PORT |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch | |
| | Port | Port | Port | Port | Port | |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| | 3 | 12 | UUID 1003 | UUID 1000 | 12 | |
| ============================================================ |
| ^ |
| | |
|-------------------------------|----------------------------- |
|
|
POE IP PHONE |
|
==============================================================
| IP phone| IP phone | IP phone | IP phone | IP phone|
| pmIndex | EntPhyIdx| pmPowerMonitorId| pmParentID| pmUsage |
==============================================================
| 31 | 0 | UUID 2003 | UUID 1003 | 0 |
==============================================================
Figure 1: Scenario 1
Scenario 2: Switch with PoE endpoints with further connected
device(s)
Consider the same scenario as example 1 with an IP phone
connected to PoE port of a switch. Now, in addition, a PC is
also daisy-chained from the IP phone for LAN connectivity. The
<Claise, et. Al> Expires January 12, 2010 [Page 19]
Internet-Draft <Energy Monitoring MIB> July 2010
phone draws power from PoE port of the switch, while the PC
draws power from the wall outlet.
The attributes of the switch, switch port and IP phone are the
same as in Scenario 1. The attributes of the PC are given
below. The PC does not have pmPhysicalEntity. The pmIndex of
the PC "57", the pmPowerMonitorId is "UUID 3003". The PC has a
Power Monitor Parent, i.e. the switch port whose
pmPowerMonitorId is "UUID 1003". The power usage of the PC is
"120 Watts" and is communicated to the switch port.
This example is used to illustrate the 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 upon those messages.
|--------------------------------------------------------------|
| Switch |
|==============================================================|
| Switch | Switch | Switch | Switch | Switch |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| 1 | 2 | UUID 1000 | null | 440 |
| ============================================================ |
| |
| SWITCH PORT |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port | Port | Port | Port | Port | |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| | 3 | 12 | UUID 1003 | UUID 1000 | 12 | |
| ============================================================ |
| ^ |
| | |
|-----------------------------------|--------------------------|
|
|
POE IP PHONE |
|
|
=============================================================
| IP phone | IP phone |IP phone |IP phone |IP phone|
| pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmUsage |
============================================================
| 31 | 0 | UUID 2003 | UUID 1003 | 0 |
<Claise, et. Al> Expires January 12, 2010 [Page 20]
Internet-Draft <Energy Monitoring MIB> July 2010
============================================================
|
|
PC connected to switch via IP phone |
|
=============================================================
| PC | PC |PC |PC | PC |
| pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
============================================================
| 57 | 0 | UUID 3003 | UUID 1003 | 120 |
=============================================================
Figure 2: Scenario 2
Scenario 3: A switch with Wireless Access Points
Consider a Wireless Access Point connected to the PoE port of a
switch. There are several PCs connected to the Wireless Access
Point over Wireless protocols. All PCs draw power from the wall
outlets.
The switch port is the Power Monitor Parent for the Wireless
Access Point (WAP) and the PCs. There is a distinction, between
the Power Monitor Children, as the WAP draws power from the PoE
port of the switch and the PCs draw power from the wall outlet.
The switch has pmIndex "1", pmPhysicalEntity is "2" and
pmPowerMonitorId is "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 pmIndex "3", pmPhysicalEntity is "12" and
pmPowerMonitorId is "UUID 1003". The power usage of the POE
switch port is "20 watts". The POE switch port has the switch
as the parent and the pmParentID is "UUID 1000".
The WAP has the following attributes. The WAP doesn't have an
entry for pmPhysicalEntity. The WAP has pmIndex "47" and
pmPowerMonitorId "UUID 2004" and WAP has a parent; the POE
switch port whose pmPowerMonitorId is "UUID 1003". The power
usage of the WAP is measured at the PoE switch port.
The PC1 and PC2 does not have pmPhysicalEntity. The pmIndex of
the PC "53", the pmPowerMonitorId is "UUID 3". The PC has a
<Claise, et. Al> Expires January 12, 2010 [Page 21]
Internet-Draft <Energy Monitoring MIB> July 2010
parent; i.e., the switch PoE port whose pmPowerMonitorId is
"UUID 3004". The power usage of the PC is "120 Watts" and is
communicated to the switch port.
The pmIndex of the PC2 "58", the pmPowerMonitorId is "UUID 5".
The PC has a parent; the switch port whose pmPowerMonitorId is
"UUID 4004". The power usage of the PC is "120 Watts" and is
communicated to the switch port.
|--------------------------------------------------------------|
| Switch |
|==============================================================|
| Switch | Switch | Switch | Switch | Switch |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| 1 | 2 | UUID 1000 | null | 440 |
| ============================================================ |
| |
| SWITCH PORT |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch | |
| | Port | Port | Port | Port | Port | |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| | 3 | 12 | UUID 1003 | UUID 1000 | 20 | |
| ============================================================ |
| ^ |
| | |
|-----------------------------------------------|--------------|
|
POE Wireless Access Point |
|
|
==============================================================
| WAP | WAP | WAP | WAP | WAP |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentID | pmUsage |
==============================================================
| 47 | 0 | UUID 2004 | UUID 1003 | 0 |
==============================================================
.
.
.
.
PC1 connected to WAP .
.
==============================================================
| PC | PC |PC | PC | PC |
<Claise, et. Al> Expires January 12, 2010 [Page 22]
Internet-Draft <Energy Monitoring MIB> July 2010
| pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage |
==============================================================
| 53 | 0 | UUID 3004 | UUID 1003 | 120 |
==============================================================
.
.
PC2 connected to WAP .
.
================================================================
| PC | PC |PC | PC | PC |
| pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage |
===============================================================
| 58 | 0 | UUID 4004 | UUID 1003 | 120 |
================================================================
Figure 3: Scenario 3
Scenario 4: Network connected facilities gateway
At the top of the network hierarchy of a building network is a
gateway device that can perform protocol conversion between many
facility management devices, such as BACNET, MODBUS, DALI, LON,
etc. There are power meters associated with power consuming
entities (Heating Ventilation & Air Conditioning - HVAC,
lighting, electrical, fire control, elevators, etc). The
proposed MIB can be implemented on the gateway device. The
gateway can be considered as the Power Monitor Parent, while the
power meters associated with the energy consuming entities such
can be considered as Power Monitor Children. EntPhysicalIndex
is not defined for these Power Monitor Parent or the Children,
as the ENTITY MIB is generally not implemented in such an
environment. Hence the gateway, meter 1, and meter 2 have
pmPhysicalEntities of value zero. The pmIndex of the gateway is
"5", and the pmPowerMonitorId is "UUID 1004". The gateway does
not have a Power Monitor Parent; The total power usage of the
gateway and its children is "9000 Watts".
Meter 1 has pmIndex "100", and pmPowerMonitorId is "UUID 2005".
Meter 1 shall report a power usage of "6000 watts". Meter 1 has
the gateway as the parent and its pmParentID is "UUID 1004".
Meter 2 has pmIndex "101", and pmPowerMonitorId is "UUID 3005".
Meter 2 shall report a power usage of "1500 watts". Meter 2 has
the gateway as the Power Monitor Parent and its pmParentID is
"UUID 1004".
<Claise, et. Al> Expires January 12, 2010 [Page 23]
Internet-Draft <Energy Monitoring MIB> July 2010
---------------------------------------------------------------
| Building Gateway |
| |
|==============================================================|
| Mediat | Mediat | Mediat | Mediat | Mediat |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| 5 | None | UUID 1004 | Null | 9000 |
| ============================================================ |
| |
| |
----------------------------------------------------------------
|
|
|
| Meter 1
|
| =============================================================
| | Meter1 | Meter1 |Meter1 |Meter1 | Meter1 |
| | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
|=>|============================================================
| | 100 | 0 | UUID 2005 | UUID 1004 | 6000 |
| =============================================================
|
| Meter 2
| ============================================================
|=>| Meter2 | Meter2 |Meter2 |Meter2 | Meter2 |
| pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
=============================================================
| 101 | 0 | UUID 3005 | UUID 1004| 1500 |
=============================================================
Figure 4: Scenario 4
Scenario 5: Data Center Network
A typical data center network consists of a hierarchy of
switches. At the bottom of hierarchy there are servers mounted
on a rack, and those are connected to the top of the rack
switches. The top switches are connected to aggregation
switches that are in turn connected to core switches. As an
example, Server 1 and Server 2 are connected to different switch
ports of the top switch.
<Claise, et. Al> Expires January 12, 2010 [Page 24]
Internet-Draft <Energy Monitoring MIB> July 2010
The proposed MIB can be implemented on the switches. The switch
can be considered as the Power Monitor Parent. The servers can
be considered as the Power Monitor Children.
The switch has pmIndex "1", pmPhysicalEntity is "2", and the
pmPowerMonitorId is "UUID 1000". The power usage of the switch
is "440 Watts". The switch does not have a parent.
Firstly, the switch ports are non-PoE and have the following
attributes - Server 1 is connected to Switch port 1. Switch
port 1 has pmIndex "3", pmPhysicalEntity is "12" and
pmPowerMonitorId is "UUID 1003". Switch port 2 has pmIndex "4",
pmPhysicalEntity is "13" and pmPowerMonitorId is "UUID 1004".
The power usage of the non-POE switch port cannot be measured.
The switch ports have the switch as the Power Monitor Parent and
its pmParentID is "1000".
The Server 1 has a value of zero for pmPhysicalEntity. The
pmIndex of the Server 1 is "5", and the pmPowerMonitorId is
"UUID 2006". Server 1 has a Power Monitor Parent; i.e., the
switch port whose pmPowerMonitorId is "1003". The power usage
of the Server 1 is "200 Watts" and is communicated to the switch
port.
The Server 2 has a value of zero for pmPhysicalEntity. The
pmIndex of the Server 2 is "6", and the pmPowerMonitorId is
"UUID 3006". Server 1 has a parent; i.e., the switch port whose
pmPowerMonitorId is "1054". The power usage of the Server 2 is
"140 Watts" and is communicated to the switch port.
Communication of power usage of Server1 and Server2 to the
switch is out of scope of this document.
|--------------------------------------------------------------|
| Switch |
|==============================================================|
| |Switch | Switch | Switch | Switch | Switch | |
| |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| | 1 | 2 | UUID 1000 | null | 440 | |
| ============================================================ |
| |
| |
| SWITCH PORT 1 |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
<Claise, et. Al> Expires January 12, 2010 [Page 25]
Internet-Draft <Energy Monitoring MIB> July 2010
| | Port1 | Port1 | Port1 | Port1 | Port1 |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| | 3 | 12 | UUID 1003 | UUID 1000 | NULL ||
| ============================================================ |
| |
| SWITCH PORT 2 |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port2 | Port2 | Port2 | Port2 | Port2 |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| | 4 | 13 | UUID 1004 | UUID 1000 | NULL |
| ============================================================ |
| |
| |
|--------------------------------------------------------------|
|
|
| Server 1 connected to switch (Non-POE)
| =============================================================
| | Server 1| Server 1 | Server 1 | Server 1 | Server 1 |
| | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage |
|=>|============================================================
| | 5 | 0 | UUID 2006 | UUID 1003 | 200 |
| =============================================================
|
| Server 2 connected to switch (Non-POE)
| ============================================================
|=>| Server 2| Server 2 | Server 2 | Server 2 | Server 2 |
| pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage |
=============================================================
| 6 | 0 | UUID 3006 | UUID 1004 | 140 |
=============================================================
Figure 5: Scenario 5
Scenario 6: Power Consumption of UPS
Data centers and commercial buildings can have Uninterruptible
Power Supplies (UPS) connected to the network. The Power Monitor
can be used to model a UPS as a Power Monitor Parent with the
connected devices as Power Monitor Children.
EDITOR'S NOTE: the example will be completed in the future.
<Claise, et. Al> Expires January 12, 2010 [Page 26]
Internet-Draft <Energy Monitoring MIB> July 2010
Scenario 7: Power Consumption of Battery-based Devices
As specified in [POWER-MON-REQ], battery state monitoring is a
requirement for the Power and Energy Monitoring MIB.
EDITOR NOTE: since a merge between this draft and [QUITTEK-
POWER-MIB] seems to be the direction that the OPSAWG IETF WG
wants to go, one idea is to copy the battery MIB module from
[QUITTEK-POWER-MIB].
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 listed indexed by
entPhysicalIndex. From an energy management point of view, 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 level states of networking equipment and a
functionality to configure the power level states.
When this MIB module is used to monitor the power usage of
devices such as 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.
However, the ENTITY-SENSOR MIB [RFC3433] doesn't have the ANSI
C12.x accuracy classes required for electricity, i.e., 1%, 2%,
0.5% accuracy classes: indeed, the entPhySensorPrecision
[RFC3433] represents "The number of decimal places of precision
in fixed-point sensor values returned by the associated
entPhySensorValue object". The ANSI and IEC Standards are used
for power measurement and these standards require that we use an
accuracy class, and not the scientific number precision model as
<Claise, et. Al> Expires January 12, 2010 [Page 27]
Internet-Draft <Energy Monitoring MIB> July 2010
specified in RFC3433. The pmPowerAccuracy MIB object models
this accuracy. Note that the 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 by 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 Monitor that needs 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 such as BACNET. Another example is the home
energy controller. In such cases, the pmPhysicalEntity value
contains the zero value, thanks to PhysicalIndexOrZero textual
convention.
The pmIndex 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 Levels are required, as
proposed in the Power and Energy Monitoring MIB module. Those
Power Levels 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 Level "unknown",
"ready", "standby", respectively, while the entStateStandby
"providingService" could map to any "low" to "high" Power Level.
<Claise, et. Al> Expires January 12, 2010 [Page 28]
Internet-Draft <Energy Monitoring MIB> July 2010
7.3. Link with the POWER-OVER-ETHERNET MIB
Power-over-Ethernet MIB [RFC3621] provides 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 index.
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 such as 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 pmIndex MIB object has been kept as the
unique Power Monitor index.
Note that, even 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 can last
only for a finite period of time, until normal power supply is
restored. Planning is required to decide on the capacity of UPS
based on output power and duration of probable power outage.
From a power provisioning point of view of a data center or
building, it is important to understand the total demand
required to support all the entities in order to plan on the
capacity of the UPS to be installed. This demand can be
monitored via the Power and Energy Monitoring MIB.
UPS MIB [RFC1628] provides information on the state of the UPS
network. Implementation of UPS MIB is useful at the aggregate
<Claise, et. Al> Expires January 12, 2010 [Page 29]
Internet-Draft <Energy Monitoring MIB> July 2010
level of a data center or a building. The MIB module contains
several groups of variables - upsIdent - to identify the UPS
entity (name, model,..), the upsBattery group - to indicate the
battery state, (upsbatteryStatus, upsEstimatedMinutesRemaining,
...), upsInput group - to characterize the input load to the UPS
(number of input lines, voltage, current,...) , upsOutput - to
characterize the output from the UPS (number of output lines,
voltage, current,...), upsAlarms - to indicate the various alarm
events. The measurement of power in UPS MIB are in Volts, Amps
and Watts. The units of power measurement are RMS volts, RMS
Amps and are not based on 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
such a case, the UPS device itself would be the Power Monitor
Parent and any the UPS meters or submeters would be 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 for advertising of 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 - capabilities
discovery, LAN speed and duplex discovery, network policy
discovery, location identification discovery, inventory
discovery, and power discovery.
Of particular interest to the current MIB module is the power
discovery, which allows the end device such as a PoE phone to
convey power requirement to the switch. In the power discovery,
the LLDP-MED has four Type Length Value (TLV): 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
<Claise, et. Al> Expires January 12, 2010 [Page 30]
Internet-Draft <Energy Monitoring MIB> July 2010
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 to indicate if the power for an attached device is
local or from a remote device. If 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. Structure of the MIB
The primary MIB object in this MIB module is the
PowerMonitorMIBObject. The pmTable table of
PowerMonitorMibObject describes an entity in the network that is
a Power Monitor.
A Power Monitor contains information to describe the entity in
the context of the network (such as its Power Monitor Meter
Domain pmDomainName) and attributes for describing its business
context (such as pmImportance, pmRoleDescription and
pmKeywords).
A Power Monitor contains information describing its
instantaneous power usage (pmPower) along with its instantaneous
power state (pmPowerLevel). Along with the power usage is
information describing how the power usage was determined (such
as pmPowerMeasurementCaliber and pmPowerOrigin)
A Power Monitor may also 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 pmDemandEnergyTable to
describe energy information over time.
A Power Monitor may also contain optional battery information
associated with this entity.
EDITOR NOTE: since a merge between this draft and [QUITTEK-
POWER-MIB] seems to be the direction that the OPSAWG IETF WG
wants to go, one idea is to copy the battery MIB module from
[QUITTEK-POWER-MIB].
<Claise, et. Al> Expires January 12, 2010 [Page 31]
Internet-Draft <Energy Monitoring MIB> July 2010
9. 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, TimeTicks
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval
FROM SNMPv2-TC
MODULE-COMPLIANCE,
NOTIFICATION-GROUP,
OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
PhysicalIndexOrZero
FROM ENTITY-MIB;
powerMonitorMIB MODULE-IDENTITY
LAST-UPDATED "201005300000Z"
ORGANIZATION "Cisco Systems, Inc."
CONTACT-INFO
"Cisco Systems
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
USA
Tel: +1 800 553-NETS
<Claise, et. Al> Expires January 12, 2010 [Page 32]
Internet-Draft <Energy Monitoring MIB> July 2010
E-mail: cs-snmp@cisco.com"
DESCRIPTION
"This MIB is used to monitor power and energy in
devices."
REVISION
"201005300000Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 xxxxx }
powerMonitorMIBNotifs OBJECT IDENTIFIER
::= { powerMonitorMIB 0 }
powerMonitorMIBObjects OBJECT IDENTIFIER
::= { powerMonitorMIB 1 }
powerMonitorMIBConform OBJECT IDENTIFIER
::= { powerMonitorMIB 2 }
-- Textual Conventions
PowerMonitorLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An enumerated integer value that represents the value of the
power policy level, a current power setting at which a Power
Monitor uses power.
There are twelve power policy levels; divided into six
operational states, and six non-operational states. The lowest
non-operational state is 1 and the highest is six. Each non-
operational state corresponds to an ACPI level [ACPI].
Global and System level state between G3 (hard-off) and G1
(sleeping). For operational levels, 6 is the lowest, and 12 the
highest (full power). Each operational level represent a
performance state, and may be mapped to ACPI states P0 (maximum
performance & power) through P5 (minimum performance and minimum
power).
An entity may have fewer power levels than twelve and would then
map several policy levels to the same power state. Entities
<Claise, et. Al> Expires January 12, 2010 [Page 33]
Internet-Draft <Energy Monitoring MIB> July 2010
with more than twelve levels, would choose which twelve to
represent as power policy levels.
Note that Power Monitor Parent MUST report some of the non
operational Power Levels of its Power Monitor Children who are
unable to report their Power Level. A typical example a phone
which may notify its Power Monitor Parent that it will go into a
mechoff(1) or hibernate(3) state so that the Power Monitor
Parent can report the phone's current state, for example either
zero or 1 watt. Conversely, a PC with Desktop and mobile
Architecture for System Hardware [DASH] out-of-band management
is an example where a Power Monitor Child can report its usage
and level even when in a non-operational state.
In each of the non operational levels (from mechoff(1) to
ready(6)), the Power Level preceding it is expected to have a
lower power consumption and a longer delay in returning to an
operational state.
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 the level G3 in ACPI.
softoff(2) : Similar to mechoff(1), but some
components remain powered or receive
trace power so that the entity
can be woken from its off state. In
softoff(2), no context is saved and the
device typically requires a complete boot
when awakened. This corresponds to level
G2 in ACPI.
hibernate(3): No entity features are available. The
entity may be woken up 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 level 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
<Claise, et. Al> Expires January 12, 2010 [Page 34]
Internet-Draft <Energy Monitoring MIB> July 2010
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 level 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 longerthan ready(6). For example, the
processor context is not maintained.
Typically, energy consumption is close to
zero. This corresponds to level G1, S2 in
ACPI.
ready(6) : No entity features are available, except
for out-of-band management, for example
wake-up mechanisms. This mode is
analogous to hot-standy. The entity can
be quickly transitioned into an
operational state. For example,
processors are not executing, but
processor context is maintained. This
corresponds to level G1, S1 in ACPI.
lowMinus(7) : Indicates some entity features may not be
available and the entity has taken
measures/options to provide less than
low(8) usage. This corresponds to
ACPI State G0; which includes operational
levels 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/options to provide less than
medium(10) usage.
medium(10) : Indicates all entity features are
available but the entity has taken
measures/options to provide less than
highMinus(11) usage.
<Claise, et. Al> Expires January 12, 2010 [Page 35]
Internet-Draft <Energy Monitoring MIB> July 2010
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.
Note that unknown(0) is not a Power Level as such, but
simply an indication that the Power Level unavailable. "
SYNTAX INTEGER {
unknown(0),
mechoff(1),
softoff(2),
hibernate(3),
sleep(4),
standby(5),
ready(6),
lowMinus(7),
low(8),
mediumMinus(9),
medium(10),
highMinus(11),
high(12)
}
PowerMonitorId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the Power Monitor Universally
Unique Identifier."
REFERENCE
"IETF RFC 4122"
SYNTAX OCTET STRING (SIZE (16))
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.
<Claise, et. Al> Expires January 12, 2010 [Page 36]
Internet-Draft <Energy Monitoring MIB> July 2010
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
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
}
PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
pethPsePortIndex convention, which defines a greater than
zero value used to identify a power Ethernet PSE port.
This extension permits the additional value of zero. The
semantics of the value zero are object-specific and must,
therefore, be defined as part of the description of any
object that uses this syntax. Examples of the usage of
this extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32 (0..2147483647)
PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 37]
Internet-Draft <Energy Monitoring MIB> July 2010
"This textual convention is an extension of the
pethPsePortGroupIndex convention, which defines a greater
than zero value used to identify group containing the
port to which a power Ethernet PSE is connected. This
extension permits the additional value of zero. The
semantics of the value zero are object-specific and must,
therefore, be defined as part of the description of any
object that uses this syntax. Examples of the usage of
this extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32 (0..2147483647)
LldpPortNumberOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
LldpPortNumber convention specified in the LLDP MIB,
which defines a greater than zero value used to uniquely
identify each port contained in the chassis (that is
known to the LLDP agent) by a port number. This
extension permits the additional value of zero. The
semantics of the value zero are object-specific and must,
therefore, be defined as part of the description of any
object that uses this syntax. Examples of the usage of
this extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32(0..4096)
PowerMonitorKeywordList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A list of keywords that can be used to group Power
Monitors for reporting or searching. If multiple keywords
are present, then this string will contain all the
keywords separated by ',' character.
For example, If a Power Monitor were to be tagged with a
values of 'hospitality' and 'guest' then the keyword list
will be 'hospitality,guest'."
SYNTAX OCTET STRING (SIZE (0..255))
<Claise, et. Al> Expires January 12, 2010 [Page 38]
Internet-Draft <Energy Monitoring MIB> July 2010
-- Objects
pmTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Power Monitors."
::= { powerMonitorMIBObjects 1 }
pmEntry OBJECT-TYPE
SYNTAX PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the attributes of a Power Monitor.
Whenever a new Power Monitor is added or deleted a row in
the pmTable is added or deleted."
INDEX { pmIndex }
::= { pmTable 1 }
PmEntry ::= SEQUENCE {
pmIndex Integer32,
pmPowerMonitorId PowerMonitorId,
pmPhysicalEntity PhysicalIndexOrZero,
pmEthPortIndex PethPsePortIndexOrZero,
pmEthPortGrpIndex PethPsePortGroupIndexOrZero,
pmLldpPortNumber LldpPortNumberOrZero,
pmDomainName SnmpAdminString,
pmName SnmpAdminString,
pmRoleDescription SnmpAdminString,
pmPowerUnitMultiplier UnitMultiplier,
pmPower Integer32,
pmCurrentType INTEGER,
pmPowerOrigin INTEGER,
pmPowerNameplate Integer32,
pmPowerAccuracy Integer32,
pmPowerMeasurementCaliber INTEGER,
pmPowerLevel PowerMonitorLevel,
pmPowerActualLevel PowerMonitorLevel,
pmUserDefinedPowerLevel Integer32,
pmUserDefinedPowerLevelName DisplayString,
pmPowerCategory BITS,
pmParentId PowerMonitorId,
pmImportance Integer32,
<Claise, et. Al> Expires January 12, 2010 [Page 39]
Internet-Draft <Energy Monitoring MIB> July 2010
pmKeywords PowerMonitorKeywordList
}
pmIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each Power
Monitor. It is recommended that values be assigned
sequentially starting from 1. The value for each pmIndex
must remain constant at least from one re-initialization
of the entity's network management system to the next re-
initialization."
::= { pmEntry 1 }
pmPowerMonitorId OBJECT-TYPE
SYNTAX PowerMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the Power Monitor UUID
identifier."
::= { pmEntry 2 }
pmPhysicalEntity OBJECT-TYPE
SYNTAX PhysicalIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the index of a physical entity in
the ENTITY MIB. This physical entity is the given
observation point. If such a physical entity cannot be
specified or is not known then the object is zero."
::= { pmEntry 3 }
pmEthPortIndex OBJECT-TYPE
SYNTAX PethPsePortIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the power Ethernet
port to which the attached device is connected [RFC3621].
If such a power Ethernet port cannot be specified or is
not known then the object is zero."
::= { pmEntry 4 }
<Claise, et. Al> Expires January 12, 2010 [Page 40]
Internet-Draft <Energy Monitoring MIB> July 2010
pmEthPortGrpIndex OBJECT-TYPE
SYNTAX PethPsePortGroupIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the group containing
the port to which a power Ethernet PSE is connected
[RFC3621]. If such a group cannot be specified or is not
known then the object is zero."
::= { pmEntry 5 }
pmLldpPortNumber OBJECT-TYPE
SYNTAX LldpPortNumberOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the port component
(contained in the local chassis with the LLDP agent) as
defined by the lldpLocPortNum in the [LLDP-MIB] and
[LLDP-MED-MIB]. If such a port number cannot be specified
or is not known then the object is zero."
::= { pmEntry 6 }
pmDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of a Power Monitor Meter
Domain for the Power Monitor. This object specifies a
null string if no Power Monitor Domain name is
configured. The value of pmDomainName must remain
constant at least from one re-initialization of the
entity's network management system to the next re-
initialization."
::= { pmEntry 7 }
pmName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a printable name, a text string,
for the Power Monitor. The pmName SHOULD be unique.If
pmPhysicalName is present for the respective
pmPhysicalEntity (i.e. if the ENTITY-MIB is supported),
then the pmName SHOULD be identical to the
pmPhysicalName. If pmPhysicalName is not present, the
<Claise, et. Al> Expires January 12, 2010 [Page 41]
Internet-Draft <Energy Monitoring MIB> July 2010
process to assign the pmName can be implementation
specific. Example: DNS Name, MAC address in canonical
form, ifName, etc
However, if pmPhysicalName is present for the respective
pmPhysicalEntity (i.e. if the ENTITY-MIB is supported),
then the pmName should be identical to the
pmPhysicalName"
::= { pmEntry 8 }
pmRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned name
to indicate the purpose a Power Monitor serves in the
network.
For example, we can have a phone deployed to a lobby with
pmRoleDescription as 'Lobby IP phone'.
This object specifies a null string if no role
description is configured."
::= { pmEntry 9 }
pmPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in pmPower
and pmPowerNameplate."
::= { pmEntry 10 }
pmPower OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the 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 a
consuming power the pmPower value will be positive. If
<Claise, et. Al> Expires January 12, 2010 [Page 42]
Internet-Draft <Energy Monitoring MIB> July 2010
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 the power level specified by
pmPowerLevel."
::= { pmEntry 11 }
pmCurrentType 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 whether the value is unknown(3)."
::= { pmEntry 12 }
pmPowerOrigin OBJECT-TYPE
SYNTAX INTEGER {
self (1),
remote (2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the source of power measurement
and can be useful when modeling the power usage of
attached devices. The power measurement can be performed
by the entity itself or the power measurement of the
entity can be reported by another trusted entity using a
protocol extension. A value of self(1) indicates the
measurement is performed by the entity, whereas remote(2)
indicates that the measurement was performed by another
entity."
::= { pmEntry 13 }
pmPowerNameplate OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 43]
Internet-Draft <Energy Monitoring MIB> July 2010
"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."
::= { pmEntry 14 }
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 accuracy to which the usage,
reported by the pmPower can be assumed. Example 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"
::= { pmEntry 15 }
pmPowerMeasurementCaliber OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
actual(2) ,
estimated(3),
presumed(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies how the usage value, reported by
pmPower, is obtained.
- unknown: This indicates that the way the usage is
determined is unknown. In some cases, entities report
aggregate power on behalf of another device. In such
<Claise, et. Al> Expires January 12, 2010 [Page 44]
Internet-Draft <Energy Monitoring MIB> July 2010
cases it is not known whether the usage reported is
actual(2), estimated(3) or presumed (4).
- actual: This caliber rating indicates that usage was
measured by the entity presumably 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: This 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.
The entity's state and current configuration was
presumably used to compute the value.
- presumed: This indicates that the usage was not
determine 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."
::= { pmEntry 16 }
pmPowerLevel OBJECT-TYPE
SYNTAX PowerMonitorLevel
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the current Power Level (0..12)
that was requested for the Power Monitor. The
pmPowerLevel values are increasing with the power
consumption. A difference in values between the
pmPowerLevel and pmPowerActualLevel indicates that Power
Monitor SHOULD go into the pmPowerLevel, at which point
it will update the content of pmPowerActualLevel.
If the Power Monitor is unable to report its Power
Level, it must report the value unknown(0). Note that
unknown(0) is not a Power Level as such, but simply an
indication that the Power Level is unknown."
::= { pmEntry 17 }
pmPowerActualLevel OBJECT-TYPE
SYNTAX PowerMonitorLevel
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 45]
Internet-Draft <Energy Monitoring MIB> July 2010
"This object specifies the current Power Level (0..12)
for the Power Monitor. If the Power Monitor is unable to
report its Power Level, it must report the value
unknown(0). Note that unknown(0) is not a Power Level
as such, but simply an indication that the Power Level
is unknown."
::= { pmEntry 18 }
pmUserDefinedPowerLevel OBJECT-TYPE
SYNTAX Integer32 (0..10000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the User Defined Power Level
(0..10000) for the Power Monitor. The
pmUserDefinedPowerLevel values are increasing with the
power consumption. If the User Defined Power Level is
not defined, the pmUserDefinedPowerLevel will report 0.
If the Power Monitor is unable to report its User
Defined Power Level, it must report the value 0."
::= { pmEntry 19 }
pmUserDefinedPowerLevelName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The textual name of the User Defined Power Level name
for the Power Monitor. If there is no local name, or
this object is otherwise not applicable, then this
object contains a zero-length string."
::= { pmEntry 20 }
pmPowerCategory OBJECT-TYPE
SYNTAX BITS {
consumer(0),
provider(1),
meter(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the power usage type of the Power
Monitor. A Power Monitor could be producing power when
pmPowerCategory is provider(1) or a consumer of power
consumer(0) or a meter(2). Negative values of power usage
are used to indicate the entity is a power source.
<Claise, et. Al> Expires January 12, 2010 [Page 46]
Internet-Draft <Energy Monitoring MIB> July 2010
Consumer: This indicates that the Power Monitor
consumes power.
Provider: This indicates that the Power Monitor
generates or provides power.
Meter: This indicates that the Power Monitor is a
meter which reads the power provided or
consumed by other sources."
::= { pmEntry 21 }
pmParentId OBJECT-TYPE
SYNTAX PowerMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the current Power Monitor has a Power Monitor Parent,
then its Power Monitor Id value is set in pmParentId.
Otherwise, the pmParentId value is the null string."
::= { pmEntry 22 }
pmImportance OBJECT-TYPE
SYNTAX Integer32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a ranking of how important the
Power Monitor is on a scale of 1 to 100 compared to other
Power Monitors in the same Power Monitor Meter Domain.
The ranking should provide a business or operational
context for the Power Monitor as compared to other
similar Power Monitors: this ranking could be used as
input for policy-based network management.
Although network managers must establish their own
ranking the following is a broad recommendation:
90 to 100 Emergency response
80 to 90 Executive or business critical
70 to 79 General or Average
60 to 69 Staff or support
40 to 59 Public or guest
1 to 39 Decorative or hospitality"
DEFVAL { 1 }
::= { pmEntry 23 }
pmKeywords OBJECT-TYPE
<Claise, et. Al> Expires January 12, 2010 [Page 47]
Internet-Draft <Energy Monitoring MIB> July 2010
SYNTAX PowerMonitorKeywordList
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a list of keywords that can be
used to group Power Monitors for reporting or searching.
PowerMonitorKeywordList This object specifies the null
string if no keywords have been configured.
For example, if the Power Monitors were to be tagged with
the value of 'hospitality' and 'guest' then the keyword
list will be hospitality, guest.
If write access is implemented and a value is written
into the instance, the agent must retain the supplied
value in the pmKeywords instance associated with
the same physical entity for as long as that entity
remains instantiated. This includes instantiations
across all re-initializations/reboots of the network
management system."
::= { pmEntry 24 }
pmPowerLevelTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmPowerLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table enumerates the maximum power usage in watts,
for every single supported Power Level and User Defined
Power Level of each Power Monitor.
This table has an expansion dependent relationship on the
pmTable, containing rows describing each Power Level for
the corresponding Power Monitor. For every Power Monitor
in the pmTable, there is a corresponding entry in this
table.
If the User Defined Power Level are not in used (0
value), the rows in this table for a given pmIndex should
be populated with values only for levels supported by the
Power Monitor. However, if both the Power Level and User
Defined Power Level are used in the Power Monitor (non 0
values), then it might be advantageous to populate all
Power Levels."
::= { powerMonitorMIBObjects 2 }
pmPowerLevelEntry OBJECT-TYPE
SYNTAX PmPowerLevelEntry
<Claise, et. Al> Expires January 12, 2010 [Page 48]
Internet-Draft <Energy Monitoring MIB> July 2010
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A pmPowerLevelEntry extends a corresponding pmEntry.
This entry displays max usage and delta values at every
single possible Power Monitor Level supported by the
Power Monitor.
For example, given the values of a Power Monitor
corresponds to a maximum usage of 11W at the
level 1 (off), 6 (low), 8 (medium), 12 (full):
Level MaxUsage Units
1 0 0
5 0 0
6 8 0
7 8 0
8 11 0
12 11 0"
INDEX {
pmIndex,
pmPowerLevelIndex,
pmUserDefinedPowerLevel
}
::= { pmPowerLevelTable 1 }
PmPowerLevelEntry ::= SEQUENCE {
pmPowerLevelIndex PowerMonitorLevel,
pmPowerLevelMaxPower Integer32,
pmPowerLevelPowerUnitMultiplier UnitMultiplier
}
pmPowerLevelIndex OBJECT-TYPE
SYNTAX PowerMonitorLevel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the level for which this entry
describes the power usage."
::= { pmPowerLevelEntry 1 }
pmPowerLevelMaxPower OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
<Claise, et. Al> Expires January 12, 2010 [Page 49]
Internet-Draft <Energy Monitoring MIB> July 2010
DESCRIPTION
"This object indicates the maximum power for the Power
Monitor at the particular Power Level. This value is
specified in SI units of watts with the magnitude of the
units (milliwatts, kilowatts, etc.) indicated separately
in pmPowerLevelPowerUnitMultiplier. If the maximum power
is not known for a certain Power Level, then the value is
encoded as 0xFFFF.
For Power Levels not enumerated, the value of
pmPowerLevelMaxPower might be interpolated by using the
next highest supported Power Level."
::= { pmPowerLevelEntry 2 }
pmPowerLevelPowerUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
pmPowerLevelMaxPower."
::= { pmPowerLevelEntry 3 }
pmDemandEnergyParametersTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmDemandEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls and configures the demand table
pmDemandEnergyTable." ::= { powerMonitorMIBObjects 3 }
pmDemandEnergyParametersEntry OBJECT-TYPE
SYNTAX PmDemandEnergyParametersEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls energy measurements."
INDEX { pmIndex }
::= { pmDemandEnergyParametersTable 1 }
PmDemandEnergyParametersEntry ::= SEQUENCE {
pmDemandEnergyParametersIntervalLength TimeInterval,
pmDemandEnergyParametersIntervalNumber Integer32,
pmDemandEnergyParametersIntervalMode Integer32,
pmDemandEnergyParametersIntervalWindow TimeInterval,
pmDemandEnergyParametersSampleRate Integer32,
<Claise, et. Al> Expires January 12, 2010 [Page 50]
Internet-Draft <Energy Monitoring MIB> July 2010
pmDemandEnergyParametersStatus RowStatus
}
pmDemandEnergyParametersIntervalLength OBJECT-TYPE
SYNTAX TimeInterval
UNITS "Seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates the length of time in seconds over
which to compute the average pmDemandIntervalEnergyUsed
measurement in the pmDemandEnergyTable table. The
computation is based on Power Monitor internal sampling
rate of power usage of the Power Monitor. The sampling
rate may differ based on device capabilities. The average
energy consumption is computed over the length of the
demand interval."
DEFVAL { 900 }
::= { pmDemandEnergyParametersEntry 1 }
pmDemandEnergyParametersIntervalNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The number of demand intervals maintained in the
pmDemandEnergyTable table. Each interval is characterized
by a specific pmDemandIntervalStartTime, used as an index
in the the table pmDemandEnergyTable table
pmDemandIntervalStartTime. Whenever the maximum number of
entry is reached, the new demand interval replaces the
oldest one, except if the oldest one is the
pmDemandIntervalMax. In which case, the next oldest
interval is replaced."
DEFVAL { 10 }
::= { pmDemandEnergyParametersEntry 2 }
pmDemandEnergyParametersIntervalMode OBJECT-TYPE
SYNTAX INTEGER {
period(1),
sliding(2),
total(3)
}
MAX-ACCESS read-write
STATUS current
<Claise, et. Al> Expires January 12, 2010 [Page 51]
Internet-Draft <Energy Monitoring MIB> July 2010
DESCRIPTION
"A control object to define the mode of interval calculation
for the computation of the average
pmDemandIntervalEnergyUsed measurement in the
pmDemandEnergyTable 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
pmDemandEnergyParametersIntervalWindow.
A mode of total(3) specifies non-periodic measurement. In
this mode only one interval is used and the value of
pmDemandEnergyParametersIntervalNumber should be (1) one
and pmDemandEnergyParametersIntervalLength is ignored. "
::= { pmDemandEnergyParametersEntry 3 }
pmDemandEnergyParametersIntervalWindow OBJECT-TYPE
SYNTAX TimeInterval
UNITS "Seconds"
MAX-ACCESS read-write
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
pmDemandIntervalEnergyUsed measurement in the
pmDemandEnergyTable table This is valid only when the
pmDemandEnergyParametersIntervalMode is sliding(2)."
::= { pmDemandEnergyParametersEntry 4 }
pmDemandEnergyParametersSampleRate OBJECT-TYPE
SYNTAX Integer32
UNITS "Milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The sampling rate in milliseconds at which the Power
Monitor should poll the instantaneous power usage in
order to compute the average pmDemandIntervalEnergyUsed
measurement in the table pmDemandEnergyTable. The Power
Monitor should initially set this sample 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 it would impact the Power Monitor
<Claise, et. Al> Expires January 12, 2010 [Page 52]
Internet-Draft <Energy Monitoring MIB> July 2010
performance by requesting continuous polling. If the
sample rate is unknown, the value 0 is reported"
DEFVAL { 1000 }
::= { pmDemandEnergyParametersEntry 5 }
pmDemandEnergyParametersStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row. An entry may not exist in the
active state unless all objects in the entry have an
appropriate value. If this object is not equal to
active(1), all associated entries in the
pmDemandEnergyTable shall be deleted. A row can be
destroyed by setting up the
pmDemandEnergyParametersStatus to destroy(6)."
::= {pmDemandEnergyParametersEntry 6 }
pmDemandEnergyTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmDemandEnergyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Power Monitor energy measurements.
Entries in this table are only created if the
corresponding value of object pmPowerCaliber is
active(2)i.e. if the power is actually metered. "
::= { powerMonitorMIBObjects 4 }
pmDemandEnergyEntry OBJECT-TYPE
SYNTAX PmDemandEnergyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing energy measurements "
INDEX { pmIndex, pmDemandEnergyIntervalStartTime }
::= { pmDemandEnergyTable 1 }
PmDemandEnergyEntry ::= SEQUENCE {
pmDemandEnergyIntervalStartTime TimeTicks,
pmDemandEnergyIntervalEnergyUsed Integer32,
pmDemandEnergyIntervalEnergyUnitMultiplier UnitMultiplier,
pmDemandEnergyIntervalMax Integer32
}
<Claise, et. Al> Expires January 12, 2010 [Page 53]
Internet-Draft <Energy Monitoring MIB> July 2010
pmDemandEnergyIntervalStartTime 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 period
for which the demand is measured. "
::= { pmDemandEnergyEntry 1 }
pmDemandEnergyIntervalEnergyUsed 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
watts-hours with the magnitude of watt-hours (kW-Hr, MW-
Hr, etc.) indicated separately in
pmDemandEnergyIntervalEnergyUnitMultiplier."
::= { pmDemandEnergyEntry 2 }
pmDemandEnergyIntervalEnergyUnitMultiplier OBJECT-TYPE
SYNTAX UnitMultiplier
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This magnitude of watt-hours for the energy field in
pmDemandEnergyIntervalEnergyUsed."
::= { pmDemandEnergyEntry 3 }
pmDemandEnergyIntervalMax OBJECT-TYPE
SYNTAX Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum demand ever observed in
pmDemandEnergyIntervalEnergyUsed since the monitoring
started. This value is specified in the common billing
units of watts-hours with the magnitude of watt-hours
<Claise, et. Al> Expires January 12, 2010 [Page 54]
Internet-Draft <Energy Monitoring MIB> July 2010
(kW-Hr, MW-Hr, etc.) indicated separately in
pmDemandEnergyIntervalEnergyUnits."
::= { pmDemandEnergyEntry 4 }
-- Notifications
pmPowerLevelChange NOTIFICATION-TYPE
OBJECTS { pmPowerLevel, pmUserDefinedPowerLevel }
STATUS current
DESCRIPTION
"The SNMP entity generates the PmPowerLevelChange when
the value(s) of pmPowerLevel and/or
pmUserDefinedPowerLevel has changed for the Power
Monitor represented by the pmIndex"
::= { 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,
powerMonitorMIBLevelTableGroup,
powerMonitorMIBDemandEnergyTableGroup,
powerMonitorMIBDemandEnergyParametersTableGroup,
powerMonitorMIBNotifGroup
}
::= { powerMonitorMIBCompliances 1 }
powerMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
<Claise, et. Al> Expires January 12, 2010 [Page 55]
Internet-Draft <Energy Monitoring MIB> July 2010
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,
powerMonitorMIBLevelTableGroup,
powerMonitorMIBNotifGroup
}
OBJECT pmDomainName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmRoleDescription
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmPowerLevel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmUserDefinedPowerLevel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmImportance
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmKeywords
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmUserDefinedPowerLevelName
MIN-ACCESS read-only
<Claise, et. Al> Expires January 12, 2010 [Page 56]
Internet-Draft <Energy Monitoring MIB> July 2010
DESCRIPTION
"Write access is not required."
::= { powerMonitorMIBCompliances 2 }
-- Units of Conformance
powerMonitorMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmIndex is NOT
-- included since it is not-accessible
pmPowerMonitorId,
pmPhysicalEntity,
pmEthPortIndex,
pmEthPortGrpIndex,
pmLldpPortNumber,
pmDomainName,
pmName,
pmRoleDescription,
pmPowerUnitMultiplier,
pmPower,
pmCurrentType,
pmPowerOrigin,
pmPowerNameplate,
pmPowerAccuracy,
pmPowerMeasurementCaliber,
pmPowerLevel,
pmPowerActualLevel,
pmUserDefinedPowerLevel,
pmUserDefinedPowerLevelName,
pmPowerCategory,
pmParentId,
pmImportance,
pmKeywords
} STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the PowerMonitor."
::= { powerMonitorMIBGroups 1 }
powerMonitorMIBLevelTableGroup OBJECT-GROUP
OBJECTS {
pmPowerLevelMaxPower,
pmPowerLevelPowerUnitMultiplier
}
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 57]
Internet-Draft <Energy Monitoring MIB> July 2010
"This group contains the collection of all the objects
related to the Power Level. "
::= { powerMonitorMIBGroups 2 }
powerMonitorMIBDemandEnergyParametersTableGroup OBJECT-GROUP
OBJECTS {
pmDemandEnergyParametersIntervalLength,
pmDemandEnergyParametersIntervalNumber,
pmDemandEnergyParametersIntervalMode,
pmDemandEnergyParametersIntervalWindow,
pmDemandEnergyParametersSampleRate,
pmDemandEnergyParametersStatus
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the configuration of the Demand Table."
::= { powerMonitorMIBGroups 3 }
powerMonitorMIBDemandEnergyTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object
-- pmDemandIntervalStartTime is not
-- included since it is not-accessible
pmDemandEnergyIntervalEnergyUsed,
pmDemandEnergyIntervalEnergyUnitMultiplier,
pmDemandEnergyIntervalMax
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Demand Table."
::= { powerMonitorMIBGroups 4 }
powerMonitorMIBNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
pmPowerLevelChange
}
STATUS current
DESCRIPTION
"This group contains the notifications for the power and
energy monitoring MIB Module."
::= { powerMonitorMIBGroups 5 }
END
<Claise, et. Al> Expires January 12, 2010 [Page 58]
Internet-Draft <Energy Monitoring MIB> July 2010
-- ************************************************************
--
-- This MIB module is used to monitor power quality of networked
-- devices with instantaneous measurements.
--
-- This MIB module is an extension of powerMonitorMIB module.
--
-- *************************************************************
POWER-QUALITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
mib-2,
Integer32
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
NOTIFICATION-GROUP,
OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION
FROM SNMPv2-TC
UnitMultiplier, pmTable, pmIndex
FROM POWER-MONITOR-MIB
;
powerQualityMIB MODULE-IDENTITY
LAST-UPDATED "201005300000Z"
ORGANIZATION "Cisco Systems, Inc."
CONTACT-INFO
"Cisco Systems
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
USA
Tel: +1 800 553-NETS
E-mail: cs-snmp@cisco.com"
DESCRIPTION
"This MIB is used to report AC power quality in devices. These
quality attributes are instantaneous values and the table is a
sparse augmentation of the pmTable table from the
<Claise, et. Al> Expires January 12, 2010 [Page 59]
Internet-Draft <Energy Monitoring MIB> July 2010
powerMonitorMIB module. Both three phase and single phase power
configurations are supported."
REVISION
"201005300000Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 yyyyy }
powerQualityMIBConform OBJECT IDENTIFIER
::= { powerQualityMIB 0 }
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 pmIndex entities. It is a sparse extension of
the pmTable."
::= { powerQualityMIBObjects 1 }
pmACPwrQualityEntry OBJECT-TYPE
SYNTAX PmACPwrQualityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This is a sparse extension of the pmTable 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 { pmIndex }
::= { pmACPwrQualityTable 1 }
PmACPwrQualityEntry ::= SEQUENCE {
pmACPwrQualityConfiguration INTEGER,
pmACPwrQualityAvgVoltage Integer32,
pmACPwrQualityAvgCurrent Integer32,
pmACPwrQualityFrequency Integer32,
pmACPwrQualityPowerUnitMultiplier UnitMultiplier,
<Claise, et. Al> Expires January 12, 2010 [Page 60]
Internet-Draft <Energy Monitoring MIB> July 2010
pmACPwrQualityPowerAccuracy Integer32,
pmACPwrQualityTotalActivePower Integer32,
pmACPwrQualityTotalReactivePower Integer32,
pmACPwrQualityTotalApparentPower Integer32,
pmACPwrQualityTotalPowerFactor Integer32,
pmACPwrQualityThdAmpheres Integer32,
pmACPwrQualityThdVoltage Integer32
}
pmACPwrQualityConfiguration OBJECT-TYPE
SYNTAX INTEGER {
sngl(1),
del(2),
wye(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Configuration describes the physical configurations
of the power supply lines:
* alternating current, single phase (SNGL)
* alternating current, three phase delta (DEL)
* alternating current, three phase Y (WYE)
Three phase configurations can be either connected in
a triangular delta (DEL) or star Y (WYE) system. WYE
systems have a shared neutral voltage, while DEL
systems do not. Each phase is offset 120 degrees to
each other."
::= { pmACPwrQualityEntry 1 }
pmACPwrQualityAvgVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A measured value for average 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
<Claise, et. Al> Expires January 12, 2010 [Page 61]
Internet-Draft <Energy Monitoring MIB> July 2010
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
"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 accuracy of active,
reactive, and
apparent power can be assumed. 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.
<Claise, et. Al> Expires January 12, 2010 [Page 62]
Internet-Draft <Energy Monitoring MIB> July 2010
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 }
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 vs. 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.
<Claise, et. Al> Expires January 12, 2010 [Page 63]
Internet-Draft <Energy Monitoring MIB> July 2010
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
"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
pmIndex entity. Entities having single phase power
shall not have any entities.
<Claise, et. Al> Expires January 12, 2010 [Page 64]
Internet-Draft <Energy Monitoring MIB> July 2010
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 { pmIndex, pmPhaseIndex }
::= { pmACPwrQualityPhaseTable 1 }
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 }
<Claise, et. Al> Expires January 12, 2010 [Page 65]
Internet-Draft <Energy Monitoring MIB> July 2010
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 }
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 vs. 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 }
<Claise, et. Al> Expires January 12, 2010 [Page 66]
Internet-Draft <Energy Monitoring MIB> July 2010
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 }
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 { pmIndex, pmPhaseIndex}
::= { pmACPwrQualityDelPhaseTable 1}
PmACPwrQualityDelPhaseEntry ::= SEQUENCE {
pmACPwrQualityDelPhaseToZeroVoltage Integer32,
pmACPwrQualityDelPhaseToNextPhaseVoltage Integer32,
pmACPwrQualityDelThdPhaseToNextPhaseVoltage Integer32,
pmACPwrQualityDelThdCurrent Integer32
}
pmACPwrQualityDelPhaseToZeroVoltage OBJECT-TYPE
SYNTAX Integer32
UNITS "0.1 Volt AC"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 67]
Internet-Draft <Energy Monitoring MIB> July 2010
"A measured value of phase to zero voltages. IEC 61850-
7-4 attribute 'PZV'"
::= { pmACPwrQualityDelPhaseEntry 1 }
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
"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
<Claise, et. Al> Expires January 12, 2010 [Page 68]
Internet-Draft <Energy Monitoring MIB> July 2010
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 pmIndex 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 { pmIndex, pmPhaseIndex }
::= { pmACPwrQualityWyePhaseTable 1}
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)
<Claise, et. Al> Expires January 12, 2010 [Page 69]
Internet-Draft <Energy Monitoring MIB> July 2010
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
"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 pmIndex is NOT
-- included since it is not-accessible
<Claise, et. Al> Expires January 12, 2010 [Page 70]
Internet-Draft <Energy Monitoring MIB> July 2010
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
OBJECTS {
-- Note that object pmIndex is NOT
-- included since it is not-accessible
pmACPwrQualityPhaseActivePower,
pmACPwrQualityPhaseReactivePower,
pmACPwrQualityPhaseApparentPower,
pmACPwrQualityPhasePowerFactor,
pmACPwrQualityPhaseImpedance
}
STATUS current
DESCRIPTION
"This group contains the collection of all 3-phase power
quality objects related to the Power Level."
::= { powerQualityMIBGroups 2 }
powerACPwrQualityDelPhaseMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmIndex and
-- pmPhaseIndex are NOT included
-- since they are not-accessible
pmACPwrQualityDelPhaseToZeroVoltage,
pmACPwrQualityDelPhaseToNextPhaseVoltage ,
pmACPwrQualityDelThdPhaseToNextPhaseVoltage,
pmACPwrQualityDelThdCurrent
}
STATUS current
DESCRIPTION
<Claise, et. Al> Expires January 12, 2010 [Page 71]
Internet-Draft <Energy Monitoring MIB> July 2010
"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 pmIndex 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 }
END
10. 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 pmDomainName, pmName,
pmRoleDescription, and/or pmUserDefinedPowerLevelName MAY
disrupt the power and energy collection, and therefore any
predefined policies defined in the network.
. Unauthorized changes to the pmPowerLevel and/or
pmUserDefinedPowerLevel MAY disrupt the power settings of
<Claise, et. Al> Expires January 12, 2010 [Page 72]
Internet-Draft <Energy Monitoring MIB> July 2010
the different Power Monitor, and therefore the level of
functionality of the respective Power Monitors.
. Unauthorized changes to the pmDemandControlTable MAY
disrupt the energy measurement in the pmDemandEnergyTable
table.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using
IPsec), even then, there is no control as to 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 indeed GET or SET (change/create/delete)
them.
11. IANA Considerations
The MIB module 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 }
Additions to this MIB module 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 OID SHOULD be assigned to a new MIB objects.
The specification of new MIB objects SHOULD follow the structure
specified in Section 6 and MUST be published using a well-
established and persistent publication medium.
<Claise, et. Al> Expires January 12, 2010 [Page 73]
Internet-Draft <Energy Monitoring MIB> July 2010
12. References
12.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version
3)", RFC 4133, August 2005.
[LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base
module for LLDP configuration, statistics, local system
data and remote systems data components", May 2005.
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information
Base extension module for TIA-TR41.4 media endpoint
discovery information", July 2005.
12.2. Informative References
[RFC1628] S. Bradner, "UPS Management Information Base", RFC
1628, May 1994
[RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
<Claise, et. Al> Expires January 12, 2010 [Page 74]
Internet-Draft <Energy Monitoring MIB> July 2010
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.
[POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
and M. Chandramouli, "Requirements for Power
Monitoring", draft-quittek-power-monitoring-
requirements-00 (work in progress), October 2009.
[QUITTEK-POWER-MIB] Quittek, J., Winter, R., Dietz, T., and
Dudkowski, D., "Requirements for Power Monitoring",
draft-quittek-power-mib-01.txt(work in progress), April
2010.
[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm
[DASH] "Desktop and mobile Architecture for System Hardware",
http://www.dmtf.org/standards/mgmt/dash/
13. Authors' Addresses
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 January 12, 2010 [Page 75]
Internet-Draft <Energy Monitoring MIB> July 2010
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
John Parello
Cisco Systems Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Brad Schoening
Cisco Systems Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: braschoe@cisco.com
<Claise, et. Al> Expires January 12, 2010 [Page 76]