One document matched: draft-claise-energy-monitoring-mib-02.txt
Differences from draft-claise-energy-monitoring-mib-01.txt
Network Working Group B. Claise
Internet-Draft M. Chandramouli
Intended Status: Standards Track J. Parello
Expires: September 8, 2010 B. Schoening
Cisco Systems, Inc.
March 8, 2010
Energy Monitoring MIB
draft-claise-energy-monitoring-mib-02
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 March 8 2010 [Page 1]
Internet-Draft <Energy Monitoring MIB> Sep 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 BSD License.
Abstract
This document defines the Management Information Base (MIB)
for the power monitoring of network elements.
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].
<Claise, et. Al> Expires March 8, 2011 [Page 2]
Internet-Draft <Energy Monitoring MIB> Sep 2010
Table of Contents
1. Introduction.............................................. 4
2. The Internet-Standard Management Framework................ 4
3. Terminology............................................... 5
4. Concepts.................................................. 6
4.1. Parent/Child Concept..................................10
5. Examples................................................. 11
6. Link with the other IETF MIBs............................ 20
6.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB....20
6.2. Link with the ENTITY-STATE-MIB........................21
6.3. Link with the POWER-OVER-ETHERNET MIB.................21
7. Structure of the MIB..................................... 22
8. MIB Definitions.......................................... 22
9. Security Considerations.................................. 42
10. IANA Considerations..................................... 43
11. References.............................................. 44
11.1. Normative References.................................44
11.2. Informative References...............................44
12. Authors' Addresses...................................... 45
<Claise, et. Al> Expires March 8, 2011 [Page 3]
Internet-Draft <Energy Monitoring MIB> Sep 2010
1. Introduction
This document defines a subset of the Management Information
Base (MIB) for use with network management protocols for
monitoring the power state and the power consumption of network
elements, taking into account the requirements specified in
[POWER-MON-REQ]. In addition to power monitoring, functionality
to configure the power state of network elements is proposed.
The MIB module in this document has been designed to be highly
flexible, with twelve different power levels, in accordance to
the Advanced Configuration and Power Interface SPECIFICATION
(ACPI) specifications [ACPI].
The target devices include: routers, switches, attached devices
such as Power over Ethernet (PoE) devices (but not limited to
PoE devices), proxy for building energy management, intelligent
meters, home energy gateway, hosts and servers, sensor proxy,
etc. However, the monitoring and configuration should be
available for individual components of devices as well, such as
line cards, processor cards, hard drives, etc. when those
components are independent from a power state point of view.
Those targets devices and components may be characterized by the
power related attributes of a physical entity present in ENTITY-
MIB, even though the ENTITY-MIB compliance is not a requirement.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. MIB objects are
generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information
(SMI). This memo specifies MIB modules that are compliant to
the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD
58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
<Claise, et. Al> Expires March 8, 2011 [Page 4]
Internet-Draft <Energy Monitoring MIB> Sep 2010
3. Terminology
PowerMonitor Entity
A PowerMonitor Entity is a system of one or more components,
that provides power, draws power, or reports power
consumption on behalf of another PowerMonitor Entity. It can
be independently managed from a power monitoring and power
state configuration point of view. This PowerMonitor Entity
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 PowerMonitor Entities are: a router line card, a
motherboard with a CPU, an IP Phone connected with a switch,
etc.
PowerState Level
A uniform way to classify power settings on a PowerMonitor
Entity (e.g., shut, hibernate, sleep, standby). Levels are
software setting for interacting with the underlying hardware
supported power settings.
PowerMonitor Unit Scale
A scaling factor used to represent the magnitude of
PowerMonitor Entity usage. It conforms to the standard
prefixes 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 usage of a PowerMonitor Entity is 3,
it could be 3 W, 3 mW, 3 KW, 3 MW depending on the value of
PowerMonitor Scale.
PowerMonitor Domain
A PowerMonitor Domain is a name or name space which logically
groups together PowerMonitor Entities that comprises a unit
of manageable power consumption. For example, all phones in
a floor, all PowerMonitor Entities from a specific building,
or all PowerMonitor Entities of a specific device type for
which a common profile is deployed. From the point of
monitoring power consumption, it is useful to report the
total power consumed as the sum of power consumed by all the
PowerMonitor Entities within a PowerMonitor Domain.
<Claise, et. Al> Expires March 8, 2011 [Page 5]
Internet-Draft <Energy Monitoring MIB> Sep 2010
PowerMonitor Parent
A PowerMonitor Parent is a PowerMonitor Entity that is the
root of one or multiple subtending PowerMonitor Entities,
called a PowerMonitor Children. The PowerMonitor Parent is
able to report the power consumption for his PowerMonitor
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 PowerMonitor Parent is the port of the
switch, while the attached device is the PowerMonitor Child.
PowerMonitor Child
A PowerMonitor Child is a PowerMonitor Entity associated to a
PowerMonitor Parent, which draws power from its PowerMonitor
Parent or reports its power usage and power state to its
PowerMonitor Parent.
4. Concepts
PowerState Levels represent one of twelve power management
states of an PowerMonitor Entity. Each PowerState 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 G2, S3 Sleep, Save-to-RAM
5 G2, S2 Standby
6 G2, S1 Ready
Operational states:
7 G0, S0, P5 Low
8 G0, S0, P4 Frugal
9 G0, S0, P3 Medium
<Claise, et. Al> Expires March 8, 2011 [Page 6]
Internet-Draft <Energy Monitoring MIB> Sep 2010
10 G0, S0, P2 Reduced
11 G0, S0, P1 High
12 G0, S0, P0 Full
For example, a PowerMonitor Entity with a power state of 9 would
indicate an operational state with medium power consumption.
The pmPowerUsageCategory MIB object, specified as a read-only
object, indicates the power usage type of the PowerMonitor
Entity: power consumer, power producer, or meter. The value of
pmPowerUsage, specified as Integer32, can be positive or
negative, and must corresponding with the usage type in
pmPowerUsageCategory.
A PowerMonitor Entity should have a pmName, a unique
PowerMonitor index pmIndex, and potentially an
entityPhysicalIndex from the ENTITY-MIB [RFC4133] in the
pmPhysicalEntity, if supported by the PowerMonitor Entity. In
case of Power over Ethernet, the PowerMonitor Entity
pmethPortIndex and pmethPortGrpIndex may contain the
pethPsePortIndex and pethPsePortGroupIndex. The pmName can be
configured or defined by DNS. Possible pmName are: textual DNS
name, MAC-address of the device, interface ifName, or a text
string uniquely identifying the PowerMonitor Entity. The pmName
should ideally be unique. As an example, in the case of IP
phones, pmName can be the devices DNS name. In the case of
router/switch line cards, the pmName could be the
entPhysicalName. Each PowerMonitor Entity can be a member of a
PowerMonitor Domain. The PowerMonitor Domain could map 1-1 with
a metered or sub-metered portion of the customers site. It can
be used to further sub divide the deployment down to finer
PowerMonitor Domains such as a lab, data center, rack, etc. With
the possible evolution of this draft, to a framework document,
the notion of PowerMonitor Domain shall be useful.
For a PowerMonitor Entity, instantaneous power usage is reported
using pmPowerUsage and the magnitude of measurement is specified
in pmPowerUnits which is based on MonitorScale.
Nameplate power consumption of a PowerMonitor Entity is
specified by the vendor as the maximum capacity required to
safely power the device. Often this label is a conservative
<Claise, et. Al> Expires March 8, 2011 [Page 7]
Internet-Draft <Energy Monitoring MIB> Sep 2010
number and is the worst case power draw of all elements in a
fully configured system. While the actual utilization of an
entity can be lower, Nameplate power consumption is important
for power provisioning, capacity planning and billing.
In addition to measuring power consumption, an approach to
characterize the energy demand is also presented in the MIB. It
is well-known in commercial electrical utility rates, that
demand charges can be on par with actual power charges. So, in
addition to measuring power consumption, it is useful to
characterize the demand. The demand can be described as average
energy usage of an PowerMonitor Entity 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 charge. A single window of
time of high usage can penalize the power consumption charges.
However, it is relevant to measure the demand only when there
are actual power measurements from a PowerMonitor Entity, and
not when the power measurement is assumed or predicted as
specified in the MIB OID PowerUsageCaliber.
Two tables are introduced to characterize the energy demand -
emDemandTable and emDemandControlTable. The emDemandControl
Table consists of parameters defining: the duration of the
demand intervals in seconds, emDemandControlIntervalLength; the
number of demand intervals kept in the emDemandTable,
emDemandControlIntervalNumber; and a same rate used to calculate
the average, emDemandControlSampleRate. Judicious choice of the
SamplingRate will ensure accurate measurement of power while not
imposing an excessive polling burden. The emDemandControlStatus
is useful to specify the energy measurement is actual and thus
to indicate if the emDemandTable entries exist or not.
The emDemand Table consists of energy measurements in
DemandIntervalEnergyUsed, the scale of energy measured,
DemandIntervalEnergyScale, and the maximum observed demand in a
window - emDemandIntervalMax
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
- Watt-hour power use from this MIB can be combined with
utility energy sources to estimate carbon footprint and other
emission statistics.
<Claise, et. Al> Expires March 8, 2011 [Page 8]
Internet-Draft <Energy Monitoring MIB> Sep 2010
An example is provided to illustrate the concepts. For example,
a given PowerMonitor Entity as described by the pmIndex "7"
pmPhysicalEntity "5" and pmName "switch2.foo.com". For that
PowerMonitor Entity, the power measurement and power state is
reported as follows: the units of measurement pmPowerUnits is
"watts" (value 0), the instantaneous power usage enPowerUsage is
100 watts, while the maximum power consumption as prescribed by
the vendor pmPowerNamePlate is 300 watts. The
pmPowerUsageCaliber indicates that the power measurement is
"actual". The power state of that PowerMonitor Entity
PmPowerLevel is "9" to indicate medium power usage and
pmPowerUsageCategory indicates the device is a consumer of
power. In addition, the maximum power consumption at the
current level is indicated as 150 watts in pmLevelMaxUsage.
The emDemandTable and emDemandControlTable will be illustrated
following the same example. First, in order to estimate demand,
an interval to sample energy usage should be specified, i.e.
emDemandControlIntervalLength can be "900 seconds" and the
number of consecutive intervals over which the maximum demand is
calculated emDemandControlIntervalNumber as "10". The sampling
rate internal to the PowerMonitor Entity for measurement of
power usage, emDemandControlSampleRate, can be "1000
milliseconds", as set by the PowerMonitor Entity as a reasonable
value. Then, the emDemandControlStatus is set to active (value
1) to indicate that the PowerMonitor Entity should start monitor
the usage as per the emDemandTable.
The indices in the emDemandTable are pmIndex, which identifies
the PowerMonitor Entity, and emDemandIntervalStartTime, which
denotes the start time of the demand measurement interval based
on sysUpTime. The value of emDemandIntervalEnergyUsed is the
measured of the energyconsumption over the time interval
specified (emDemandControlIntervalLength) based on the
PowerMonitor Entity internal sampling rate
(emDemandControlSampleRate). The units are derived from
emDemandIntervalPowerScale. For example,
emDemandIntervalPowerUsed can be "100" with
emDemandIntervalPowerUnits equal to 0, the demand is 100
watt-hours. emDemandIntervalMax is the maximum demand observed
can be "150 watt-hours".
The emDemandTable has a buffer to retain a certain number of
intervals, as defined by emDemandControlIntervalNumber. If the
default value of "10" is kept, then the emDemandTable contains
10 demand measurements, including the maximum. A brief
<Claise, et. Al> Expires March 8, 2011 [Page 9]
Internet-Draft <Energy Monitoring MIB> Sep 2010
explanation on how the maximum demand is calculated. 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 Network Management System
could compute the maximum over a longer period, i.e. a month, 3
months, or a year.
[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 thanks to
the pmLevelChange NOTIFICATION-TYPE, indexed by the pmIndex and
the pmPowerLevel, which is generated when the value of
pmPowerLevel has changed for the PowerMonitor Entity represented
by the pmIndex. Indeed, assuming that the SNMP notification
arrives at the Network Management Station (NMS), the NMS can
deduce all the information.
4.1. Parent/Child Concept
A PowerMonitor Entity can be connected to another PowerMonitor
Entity and either draw power from that entity or report power
usage to the Entity.
EnergyMonitor Child can be fully dependent on the EnergyMonitor
Parent or independent. In the dependent case, EnergyMonitor
Parent provides power for the EnergyMonitor Child and the power
consumption of the child can be measured at the EnergyMonitor
parent. Also, the PowerMonitor Levels can be set by the
EnergyMonitor Parent. In the independent case, an EnergyMonitor
Child draws power from another source (typically a wall outlet).
However, the EnergyMonitor Child does not have a separate
network management presence and instead reports the power usage
and PowerMonitoring Level on to the EnergyMonitor Parent. The
EnergyMonitor Child may listen to the power control settings
from a EnergyMonitor Parent and the EnergyMonitor Child could
react to the control messages. Note that the communication
between the EnergyMonitor Parent and EnergyMonitor Child is out
of scope of this document.
In order to link the PowerMonitor Child and the PowerMonitor
Parent, the notion of pmParentId is introduced.
<Claise, et. Al> Expires March 8, 2011 [Page 10]
Internet-Draft <Energy Monitoring MIB> Sep 2010
Consider the example of a PoE device attached to a switch where
the switch can measure the power at the switch port level. For
example, a PoE device with an pmIndex of 100 and a pmParentId
value of 20 representing the parent pmIndex. This PowerMonitor
parent will report the power usage for the attached PoE device
while the PoE port reports zero for power usage. Furthermore,
if the pmPhysicalEntity value is non zero, the switch port to
which the PoE device is connected to can be deduced.
The use of a PowerMonitor parent is not limited to just PoE
children. However, in the case of non-POE devices, the power
usage cannot be measured at the switch port; since the switch is
not source of power supply. In that case, proprietary
communication of power usage between the child (PC) and the
parent (switch) could be established, the form of which is
outside of scope of this document. Consider a PC attached to a
switch port, powered from a wall outlet. In this example, the
PC would appear as a PowerMonitor child Entity and report his
usage in the parents emEntry table. Similarly to the previous
PoE example, the PC PowerMonitor parent and switch port can be
deduced through cross-references.
It is not possible to have multiple PoE devices on a single PoE
port. However, it is possible to have a single PoE device on a
switch port and another non-PoE device such a PC can be daisy-
chained from the phone for the LAN connection. In this
scenario, the switch port parent has two children; the IP phone
and PC. As stated before, for the PoE device, it is possible to
measure the power consumption at the switch port, whereas for
the non-POE device (PC), there must be out-of-band communication
of power usage and power levels between the non-PoE device and
the switch. The communication between the parent and a child is
out of scope of this document and is not discussed here.
5. Examples
A PowerMonitor Entity is a fundamental concept from the point of
view of power monitoring application considered in this
document. Some illustrative examples are presented to model
different network scenarios of the PowerMonitor Parent and
PowerMonitor Child relationship.
Example 1: Consider an PoE IP Phone connected to the switch
port, as displayed on figure 1. The IP phone draws power from
the Power over Ethernet switch port. The switch has the
following attributes that are illustrated in Figure 1.
<Claise, et. Al> Expires March 8, 2011 [Page 11]
Internet-Draft <Energy Monitoring MIB> Sep 2010
The switch has pmIndex "1", pmPhysicalEntity is "2" and
pmPowerMonitorID is "UUID 1000". The power consumption of the
switch is "440 Watts". The switch does not have a 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 consumption of the
POE switch port is "12 watts". The POE switch port has the
switch as the 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
an entry for pmPhysicalEntity, as the ENTITY-MIB is not
supported on this device. The IP Phone has a parent; the POE
switch port whose pmPowerMonitorID is "UUID 1003". The power
consumption 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 |
==============================================================
<Claise, et. Al> Expires March 8, 2011 [Page 12]
Internet-Draft <Energy Monitoring MIB> Sep 2010
| 31 | 0 | UUID 2003 | UUID 1003 | 0 |
==============================================================
Figure 1: Example 1
Example 2: 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 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 Example 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 5004". The PC has a parent
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
PowerMonitor 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 PowerMonitor Parent sends
power control messages to both the PowerMonitor 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 | |
| ============================================================ |
| ^ |
<Claise, et. Al> Expires March 8, 2011 [Page 13]
Internet-Draft <Energy Monitoring MIB> Sep 2010
| | |
|-----------------------------------|--------------------------|
|
|
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 |
============================================================
|
|
PC connected to switch via IP phone |
|
============================================================
| PC | PC |PC |PC | PC |
| pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
============================================================
| 57 | 0 | UUID 5004 | UUID 1003 | 120 |
============================================================
Figure 2: Example 2
Example 3: 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 PowerMonitor Parent for the Wireless
Access Point and the PCs. There is a distinction, between the
children, as the Wireless Access Point 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 1". The power consumption of the
switch is "440 Watts". The switch does not have a parent.
The POE switch port has the following attributes - The switch
port has pmIndex "7", pmPhysicalEntity is "18" and
pmPowerMonitorID is "UUID 2". The power consumption of the POE
switch port is "20 watts". The POE switch port has the switch
as the parent and the pmParentID is "UUID 1000".
<Claise, et. Al> Expires March 8, 2011 [Page 14]
Internet-Draft <Energy Monitoring MIB> Sep 2010
The Wireless Access Point has the following attributes. The WAP
doesn't have an entry for pmPhysicalEntity. The WAP has pmIndex
"47" and pmPowerMonitorID "UUID 3" and WAP has a parent; the POE
switch port whose pmPowerMonitorID is "UUID 2". The power
consumption 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
parent; i.e., the switch POE port whose pmPowerMonitorID is
"UUID 2". 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 2". 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 1 | null | 440 |
| ============================================================ |
| |
| SWITCH PORT |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port | Port | Port | Port | Port | |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | |
| ============================================================ |
| 7 | 18 | UUID 2 | UUID 1 | 20 | |
| ============================================================ |
| ^ |
| | |
|----------------------------------------------|---------------|
|
POE Wireless Access Point |
|
|
==============================================================
| WAP | WAP | WAP | WAP | WAP |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentID | pmUsage |
==============================================================
| 47 | 0 | UUID 3 | UUID 2 | 0 |
==============================================================
.
<Claise, et. Al> Expires March 8, 2011 [Page 15]
Internet-Draft <Energy Monitoring MIB> Sep 2010
.
.
.
PC1 connected to WAP .
.
==============================================================
| PC | PC |PC |PC | PC |
| pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
==============================================================
| 53 | 0 | UUID 4 | UUID 2 | 120 |
==============================================================
.
.
PC2 connected to WAP .
.
================================================================
| PC | PC |PC | PC | PC |
| pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage |
===============================================================
| 58 | 0 | UUID 5 | UUID 2 | 120 |
================================================================
Figure 3: Example 3
Example 4: An example of the proposed MIB on how to model
monitoring the energy consumption of buildings is presented.
At the top of the network hierarchy of building network is
mediator device that does protocol conversion between many
facility management protocols such as BACNET, MODBUS, DALI, LON,
etc. There are power meters associated with power consuming
entities (HVAC, lighting, electrical, fire control, elevators,
...). The proposed MIB can be implemented on the mediator
device. The mediator can be considered as the PowerMonitor
Parent, while the power meters associated with the energy
consuming entities such (HVAC, electrical, lighting, ...) can be
considered as PowerMonitor Childen. EntPhysicalIndex is not
defined for these EnergyMonitor Parent or the Children, as the
ENTITY-MIB is generally not implemented in such an environment.
Hence the mediator, Meter 1, and Meter 2 have pmPhysicalEntities
of value zero. The pmIndex of the Mediator is "5", and the
pmPowerMonitorID is "UUID 1008". The mediator does not have a
parent; The total power usage of the Mediator and its children
is "9000 Watts".
<Claise, et. Al> Expires March 8, 2011 [Page 16]
Internet-Draft <Energy Monitoring MIB> Sep 2010
Meter 1 has pmIndex "2051", and pmPowerMonitorID is "UUID 2004".
Meter 1 shall report a power consumption of "6000 watts". Meter
1 has the Mediator as the parent and its pmParentID is "UUID
1008".
Meter 2 has pmIndex "2072", and pmPowerMonitorID is "UUID 2007".
Meter 2 shall report a power consumption of "1500 watts". Meter
2 has the Mediator as the parent and its pmParentID is "UUID
1008".
---------------------------------------------------------------
| Building Mediator |
| |
|==============================================================|
| Mediat | Mediat | Mediat | Mediat | Mediat |
| pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| 5 | None | UUID 1008 | Null | 9000 |
| ============================================================ |
| |
| |
----------------------------------------------------------------
|
|
|
| Meter 1
|
| =============================================================
| | Meter1 | Meter1 |Meter1 |Meter1 | Meter1 |
| | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
|=>|============================================================
| | 2051 | 0 | UUID 2004 | UUID 1008 | 6000 |
| =============================================================
|
| Meter 2
| ============================================================
|=>| Meter2 | Meter2 |Meter2 |Meter2 | Meter2 |
| pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage |
=============================================================
| 2072 | 0 | UUID 2007 | UUID 1008 | 1500 |
=============================================================
Figure 4: Example 4
Example 5: An example of the proposed MIB on how to model a
data center network is presented. In summary, a typical data
<Claise, et. Al> Expires March 8, 2011 [Page 17]
Internet-Draft <Energy Monitoring MIB> Sep 2010
center network consists of a hierarchy of switches. At the
bottom of hierarchy there are servers mounted on rack, and those
are connected to the top of the row switches. Top of the row
switches are connected to aggregation switches, who are in turn
connected to core switches. As an example, Server 1 and Server
2 are connected to different switch ports of the top of the row
switch.
The proposed MIB can be implemented on the switches. The switch
can be considered as the PowerMonitor Parent. The servers can
be considered as the children.
The switch has pmIndex "1", pmPhysicalEntity is "2" and the
pmPowerMonitorID is "1000". The power consumption 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 "8", pmPhysicalEntity is "15" and
pmPowerMonitorID is "1041". The power consumption of the non-POE
switch port cannot be measured. The switch port has the switch
as the parent and its pmParentID is "1000".
The Server 1 has a value of zero for pmPhysicalEntity. The
pmIndex of the Server 1 is "53", and the pmPowerMonitorID is
"5016". Server 1 has a parent; i.e., the switch port whose
pmPowerMonitorID is "1041". The power usage of the Server 1 is
"200 Watts" and is communicated to the switch port.
Server 2 is connected to Switch port 2. Switch port 2 has
pmIndex "6", pmPhysicalEntity is "16" and pmPowerMonitorID is
"1054". The power consumption of the non-POE switch port cannot
be measured. The switch port has the switch as the parent and
its pmParentID is "1000".
The Server 2 has a value of zero for pmPhysicalEntity. The
pmIndex of the Server 2 is "72", and the pmPowerMonitorID is
"5043". 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 | |
<Claise, et. Al> Expires March 8, 2011 [Page 18]
Internet-Draft <Energy Monitoring MIB> Sep 2010
| ============================================================ |
| | 1 | 2 | UUID 1000 | null | 440 | |
| ============================================================ |
| |
| |
| SWITCH PORT 1 |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port1 | Port1 | Port1 | Port1 | Port1 |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| | 8 | 15 | UUID 1041 | UUID 1000 | NULL ||
| ============================================================ |
| |
| SWITCH PORT 2 |
| ============================================================ |
| | Switch | Switch | Switch | Switch | Switch |
| | Port2 | Port2 | Port2 | Port2 | Port2 |
| | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage |
| ============================================================ |
| | 6 | 16 | UUID 1054 | 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 |
|=>|============================================================
| | 64 | 0 | UUID 5016 | UUID 1041 | 200 |
| =============================================================
|
| Server 2 connected to switch (Non-POE)
| ============================================================
|=>| Server 2| Server 2 | Server 2 | Server 2 | Server 2 |
| pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage |
=============================================================
| 72 | 0 | UUID 5043 | UUID 1054 | 140 |
=============================================================
Figure 5: Example 5
<Claise, et. Al> Expires March 8, 2011 [Page 19]
Internet-Draft <Energy Monitoring MIB> Sep 2010
6. Link with the other IETF MIBs
6.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) and
those physical entities listed indexed by entPhysicalIndex.
From an energy management point of view, of interest are the
physical entities that consume or produce energy.
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 Monitoring MIB, is on measurement of power
consumption by 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 consumption of
devices such as routers and switches, the ENTITY-MIB and ENTITY-
SENSOR-MIB should be implemented. In such cases, the
PowerMonitor Entities are modeled by the entPhysicalIndex
through the pmPhysicalEntity MIB object specified in the
pmTable.
However, the ENTITY-SENSOR-MIB doesn't have the ANSI C12.x
accuracy classes required for electricity, i.e., 1%, 2%, 0.5%
accuracy classes. These ANSI and IEC Standards require that we
use an accuracy class, and not the precision model in RFC3433.
The pmPowerUsageAccuracy MIB object models this accuracy. Note
that the emEntPowerScale represents the scale is a more logical
representation (compared to entPhySensorScale), with the
mantissa and the exponent values X * 10 ^ Y.
Finally, one cannot assume that the ENTITY-MIB and ENTITY-
SENSOR-MIB are implemented for all PowerMonitor Entity 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.
<Claise, et. Al> Expires March 8, 2011 [Page 20]
Internet-Draft <Energy Monitoring MIB> Sep 2010
As a consequence, the pmIndex MIB object has been kept as the
unique PowerMonitor Entity index. Finally, not that
the emEntPowerUsage is similar to entPhySensorValue [RFC3433]
and the emEntPowerScale is similar to entPhySensorScale
6.2. Link with the ENTITY-STATE-MIB
RFC 4268 [RFC4268] defines the Entity State MIB module that
gives the operational states (enabled, disabled, testing) and
alarm states and usage states (idle, active, busy) of the
entities in the entity MIB. From a Power monitoring point of
view, different power states to indicate the power state of the
entities models need to be developed. The Power Monitoring MIB
proposes the power states of entities in the Entity MIB.
6.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 PowerMonitor Entity 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
pmethPortIndex and pmethPortGrpIndex values contain the zero
value, thanks to new PethPsePortIndexOrZero and textual
PethPsePortGroupIndexOrZero conventions.
However, if the Power-over-Ethernet is supported, the
PowerMonitor Entity pmethPortIndex and pmethPortGrpIndex contain
the pethPsePortIndex and pethPsePortGroupIndex, respectively.
As a consequence, the pmIndex MIB object has been kept as the
unique PowerMonitor Entity index.
<Claise, et. Al> Expires March 8, 2011 [Page 21]
Internet-Draft <Energy Monitoring MIB> Sep 2010
7. Structure of the MIB
The primary MIB object in this MIB module is
PowerMonitorMIBObjects.
The pmTable table defines the PowerMonitor Entities, with
references to the entPhysicalIndex, pmethPortIndex and
pmethPortGrpIndex when available. The PowerMonitor Entities are
used for describing and configuring the entities that are
possible candidates for power management. The specific
PowerState Level can be configured in the pmTable.
The pmLevelTable table lists the maximum power usage at each
PowerState Level for each PowerMonitor Entity.
Finally, the monitoring of all the PowerMonitor Entities on the
SNMP agent can be turned on/off with the pmEnable MIB object.
8. MIB Definitions
-- ************************************************************
--
--
-- This MIB is used to monitor Power Consumption of network
-- devices
--
-- *************************************************************
POWER-MONITOR-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
mib-2,
Integer32, TimeTicks
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
NOTIFICATION-GROUP,
OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
<Claise, et. Al> Expires March 8, 2011 [Page 22]
Internet-Draft <Energy Monitoring MIB> Sep 2010
RowStatus, TimeInterval
FROM SNMPv2-TC
PhysicalIndexOrZero
FROM ENTITY-MIB;
pethPsePortIndex, pethPsePortGroupIndex
FROM POWER-ETHERNET-MIB;
powerMonitorMIB MODULE-IDENTITY
LAST-UPDATED "201001130000Z"
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 monitor power usage in network
Devices."
REVISION
"201001130000Z"
DESCRIPTION
"This Latest draft of this MIB module."
::= { 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
<Claise, et. Al> Expires March 8, 2011 [Page 23]
Internet-Draft <Energy Monitoring MIB> Sep 2010
DESCRIPTION
"An enumerated integer value that represents the value
of PowerState Level, a power setting at which a
PowerMonitor Entity uses power.
The PowerState Levels are divided into six operational
states, and six non-operational states. Each non-
operational state corresponds to an ACPI (Advanced
Configuration and Power Interface Specification,
http://www.acpi.info/spec30b.htm)
Global and System level state between G3 (hard-off) and
G1 (sleeping). The operational levels represent a
performance state, and correspond to ACPI states P0
(maximum performance & power) through P5 (minimum
performance and minimum power).
PowerMonitor Entities need not support all levels, but a
subset of the levels that can be mapped to their system
state.
mechoff(1) : An off state. No entity features are
available. The entity is unavailable.
No power is being consumed and the power
connector can be removed. This maps to
the level G3 in ACPI.
softoff(2) : Similar to off, but some components
remain powered so the device can be woken
from its off state. In soft-off, no
context is saved and the device requires
a complete boot when awakened. This maps
to level G2 in ACPI.
hibernate(3): No entity features are available. The
entity may be awoken without requiring a
complete boot, but the time for
availability is longer than sleep.
This is generally the same as save-to-
disk where DRAM context is not
maintained. Minimal, nearly zero, or zero
power is consumed. This maps to level
G1, S4 in ACPI.
sleep(4) : No entity features are available. The
entity may be available but the time
for availability is longer than
standby. This is generally the same as
save-to-RAM, where DRAM context is
<Claise, et. Al> Expires March 8, 2011 [Page 24]
Internet-Draft <Energy Monitoring MIB> Sep 2010
maintained. Minimal power is consumed.
This maps to level G1, S3 in ACPI.
standby(5) : Indicates some entity features may not be
available. The entity may be available
but the time for availability is longer
than ready. Processor context is not
maintained. Minimal power is consumed.
This maps to level G1, S2 in ACPI.
ready(6) : Indicates some entity features may not
be available. The entity itself may be
available but there may be a time delay
for availability. Processors are not
executing, but their context is
maintained. Low or less power is
consumed. This maps to level G1, S1 in
ACPI.
low(7) : Indicates some features may not be
available and the entity has taken
measures/options to provide less than
frugal usage. This maps to ACPI State
G0; which includes operational levels
low to full.
frugal(8) : Indicates some features may not be
available and the entity has take
measures/options to provide less than
medium usage.
medium(9) : Indicates all entity features are
available but the entity has taken
measures/options to provide less than
reduced usage.
reduced(10) : Indicates all entity features are
available but the entity has taken
measures/options to provide less than
high usage.
high(11) : Indicates all entity features are
available and power consumption is less
than full.
full(12) : Indicates all entity features are
available and the entity is consuming the
highest power."
<Claise, et. Al> Expires March 8, 2011 [Page 25]
Internet-Draft <Energy Monitoring MIB> Sep 2010
SYNTAX INTEGER {
mechoff(1),
softoff(2),
hibernate(3),
sleep(4),
standby(5),
ready(6),
low(7),
frugal(8),
medium(9),
reduced(10),
high(11),
full(12)
}
PowerMonitorId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for the PowerMonitor Entity in the
PowerMonitor Domain. Implementation must ensure that the
ID for each PowerMonitor Entity is unique among all
entities within the PowerMonitor Domain. A Universally
Unique Identifier (UUID) is typically used."
REFERENCE
"IETF RFC 4122"
SYNTAX OCTET STRING (SIZE (16))
MonitorScale ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Monitor Scale: an integer value that represents the
scale factor associated with the units used to measure
the power or energy.
For example, when used with pmPowerUnits, 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
<Claise, et. Al> Expires March 8, 2011 [Page 26]
Internet-Draft <Energy Monitoring MIB> Sep 2010
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
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
STATUS current
DESCRIPTION
"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)
<Claise, et. Al> Expires March 8, 2011 [Page 27]
Internet-Draft <Energy Monitoring MIB> Sep 2010
-- Objects
pmTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists PowerMonitor Entities."
::= { powerMonitorMIBObjects 1 }
pmEntry OBJECT-TYPE
SYNTAX PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes attributes of a PowerMonitor
Entity. Whenever the device creates/destroys a
PowerMonitor Entity, the device creates/destroys
a row in the pmTable."
INDEX { pmIndex }
::= { pmTable 1 }
PmEntry ::= SEQUENCE {
pmIndex Integer32,
pmPowerMonitorId PowerMonitorId,
pmPhysicalEntity PhysicalIndexOrZero,
pmethPortIndex PethPsePortIndexOrZero,
pmethPortGrpIndex PethPsePortGroupIndexOrZero,
pmDomainName SnmpAdminString,
pmName SnmpAdminString,
pmRoleDescription SnmpAdminString,
pmPowerUnits MonitorScale,
pmPowerUsage Integer32,
pmPowerUsageNameplate Integer32,
pmPowerUsageAccuracy Integer32,
pmPowerUsageCaliber INTEGER,
pmPowerLevel PowerMonitorLevel,
pmPowerUsageCategory BITS,
pmParentId PowerMonitorId
}
pmIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
<Claise, et. Al> Expires March 8, 2011 [Page 28]
Internet-Draft <Energy Monitoring MIB> Sep 2010
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each PowerMonitor
Entity. It is recommended that values are assigned
contiguously 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 PowerMonitor UUID identifier.
This object value must be unique within the PowerMonitor
Domain."
::= { 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
ACCESS read-only
STATUS mandatoty
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 }
pmethPortGrpIndex OBJECT-TYPE
SYNTAX PethPsePortGroupIndexOrZero
ACCESS read-only
STATUS mandatory
DESCRIPTION
<Claise, et. Al> Expires March 8, 2011 [Page 29]
Internet-Draft <Energy Monitoring MIB> Sep 2010
"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 }
pmDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of a PowerMonitor Domain
for the PowerMonitor Entity. This object specifies a
null string if no PowerMonitor 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 6 }
pmName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write STATUS current
DESCRIPTION
"This object specifies a printable name, a text string,
for the PowerMonitor Entity. It is preferred, but not
required that pmName be unique.
The process to assign the pmName is implementation
specific. Example: DNS Name, MAC address in canonical
form, ifName, etc..."
::= { pmEntry 7 }
pmRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned name
to indicate the purpose a PowerMonitor Entity 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 8 }
<Claise, et. Al> Expires March 8, 2011 [Page 30]
Internet-Draft <Energy Monitoring MIB> Sep 2010
pmPowerUnits OBJECT-TYPE
SYNTAX MonitorScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of Watts for the usage value in
pmPowerUsage and pmPowerUsageNameplate."
::= { pmEntry 9 }
pmPowerUsage OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the instantaneous consumption for
the PowerMonitor Entity. This value is specified in SI
units of watts with the magnitude of watts (milliwatts,
kilowatts, etc.) indicated separately in pmPowerUnits.
If the PowerMonitor Entity is a consumer (bit value 1 in
pmPowerUsageCategory, the usage value will be positive.
If the PowerMonitor Entity is a producer (bit value 2 in
pmPowerUsageCategory, the usage value will be negative.
This should be less than or equal to the maximum power
that can be consumed at the specified level."
::= { pmEntry 10 }
pmPowerUsageNameplate OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the rated maximum consumption for
the fully populated PowerMonitor Entity. The nameplate
power requirements are the worst-case power consumption
numbers and in almost all cases, are well above the
expected operating level. Nameplate power is widely used
for power provisioning. This value is specified in SI
units of watts with the magnitude of watts (milliwatts,
kilowatts, etc.) indicated separately in pmPowerUnits.
Nameplate power is widely used for capacity and
provisioning planning. It is typically a value provided
via experimentation and prediction from the manufacturer
of the entity."
<Claise, et. Al> Expires March 8, 2011 [Page 31]
Internet-Draft <Energy Monitoring MIB> Sep 2010
::= { pmEntry 11 }
pmPowerUsageAccuracy 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 pmPowerUsage 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.
ANSI C12.20 class 0.2 & 0.5"
::= { pmEntry 12 }
pmPowerUsageCaliber OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
actual(2) ,
trusted(3),
predicted(4),
presumed(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies how the usage value, reported by
pmPowerUsage, is obtained.
- unknown: This indicates that the way the usage is
determined is unknown. In some cases, entities report
aggregate power like what a lighting controller or
aggregate controller does. In such cases it is not known
whether the usage reported is actual or presumed.
- actual: This indicates that the usage data reported is
not presumed or predicted but the real power drawn. A
PoE phone drawing X amount of power can be determined by
reading from the port.
- trusted: This indicates that the usage data reported
was reported from another source. For example, a PoE
<Claise, et. Al> Expires March 8, 2011 [Page 32]
Internet-Draft <Energy Monitoring MIB> Sep 2010
phone can report the actual usage as X W, but this is not
typically as accurate as port level metering on the
switch. Trusted is higher caliber than predicted.
- predicted: This indicates that the actual power drawn
cannot be determined. The value is an estimate based upon
the device type, state, and/or utilization. Predicted is
a higher caliber than presumed. For example, a switch is
known to draw 200w when PoE on all interfaces is
disabled, and 600w when PoE is fully enabled.
- presumed: This indicates that the actual power drawn
cannot be determined but can be presumed from a model.
Presumed is the lowest caliber. For example, a PC Model
X draws 200W, while a PC Model Y draws 210W."
::= { pmEntry 13 }
pmParentId OBJECT-TYPE
SYNTAX PowerMonitorID
ACCESS read-only
STATUS mandatory
DESCRIPTION
"If the current PowerMonitor Entity has a PowerMonitor
Parent, then its PowerMonitor Id value is set in
pmParentId. Otherwise, the pmParentId value is the null
string."
::= { pmEntry 14 }
pmPowerLevel OBJECT-TYPE
SYNTAX PowerMonitorLevel
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the current power level (1..12)
for the PowerMonitor Entity."
::= { pmEntry 15 }
pmPowerUsageCategory OBJECT-TYPE
SYNTAX BITS {
consumer(1),
producer(2),
meter(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Claise, et. Al> Expires March 8, 2011 [Page 33]
Internet-Draft <Energy Monitoring MIB> Sep 2010
"This object specifies the power usage type of the
entity. An entity could be producing power when
pmPowerUsageCategory is producer(2) or a consumer of
power consumer (1) or a hybrid - consumer and
producer(3). Negative values of power usage are
permissible to indicate the entities as power sources.
Consumer: This indicates that the entity
consumes power.
Producer: This indicates that the entity
generates power.
Meter: This indicates that the entity is a
meter which reads the power consumed
or produced."
::= { pmEntry 16 }
pmLevelTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table enumerates the maximum power usage in watts
at each PowerState Level for each PowerMonitor Entity.
This table has an expansion dependent relationship on the
pmTable, containing rows describing each PowerState Level
for the corresponding PowerMonitor Entity."
::= { powerMonitorMIBObjects 2 }
pmLevelEntry OBJECT-TYPE
SYNTAX PmLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A pmLevelEntry extends a corresponding pmEntry. This
entry displays max usage and delta values at each
possible power level.
For example, given the values of a PowerMonitor
Entity 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
<Claise, et. Al> Expires March 8, 2011 [Page 34]
Internet-Draft <Energy Monitoring MIB> Sep 2010
12 11 0"
INDEX {
pmIndex,
pmLevelIndex
}
::= { pmLevelTable 1 }
PmLevelEntry ::= SEQUENCE {
pmLevelIndex PowerMonitorLevel,
pmLevelMaxUsage Integer32,
pmLevelPowerUnits MonitorScale
}
pmLevelIndex OBJECT-TYPE
SYNTAX PowerMonitorLevel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the level for which this entry
describes the power usage."
::= { pmLevelEntry 1 }
pmLevelMaxUsage OBJECT-TYPE
SYNTAX Integer32
UNITS "Watts"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum power usage for the
PowerMonitor Entity at the particular PowerState Level.
This value is specified in SI units of watts with the
magnitude of the units (milliwatts, kilowatts, etc.)
indicated separately in pmLevelPowerUnits."
::= { pmLevelEntry 2 }
pmLevelPowerUnits OBJECT-TYPE
SYNTAX MonitorScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of watts for the usage value in
pmLevelMaxUsage."
::= { pmLevelEntry 3 }
<Claise, et. Al> Expires March 8, 2011 [Page 35]
Internet-Draft <Energy Monitoring MIB> Sep 2010
emDemandControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmDemandControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls and configures the demand table emDemandTable."
::= { powerMonitorMIBObjects 3 }
emDemandControlEntry OBJECT-TYPE
SYNTAX EmDemandControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls energy usage measurements."
INDEX { pmIndex }
::= { emDemandControlTable 1 }
EmDemandControlEntry ::= SEQUENCE {
emDemandControlIntervalLength TimeInterval,
emDemandControlIntervalNumber Integer32,
emDemandControlSampleRate Integer32,
emDemandControlStatus RowStatus
}
emDemandControlIntervalLength OBJECT-TYPE
SYNTAX TimeInterval
UNITS "Seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object indicates the length of time in seconds
over which the average demand is computed. The
computation is based on PowerMonitor Entity internal
sampling rate of power consumption of the entity. The
sampling rate may differ based on device capabilities.
The average power consumption is computed over the length
of the demand interval."
DEFVAL { 900 }
::= { emDemandControlEntry 1 }
emDemandControlIntervalNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
<Claise, et. Al> Expires March 8, 2011 [Page 36]
Internet-Draft <Energy Monitoring MIB> Sep 2010
DESCRIPTION
"The number of demand intervals maintained. Whenever the
maximum number of entry is reached, the new demand
interval replaces the oldest one, except if the oldest
one is the emDemandIntervalMax. In which case, the next
oldest interval is replaced."
DEFVAL { 10 }
::= { emDemandControlEntry 2 }
emDemandControlSampleRate OBJECT-TYPE
SYNTAX Integer32
UNITS "Milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The sampling rate in milliseconds at which the
PowerMonitor Entity should poll the instantaneous power
usage in order to compute the average
emDemandIntervalEnergyUsed measurement in the table
emDemandTable. The PowerMonitor 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
PowerMonitor Entity performance by requesting continuous
polling."
DEFVAL { 1000 }
::= { emDemandControlEntry 3 }
emDemandControlStatus 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 emDemandTable
shall be deleted."
::= {emDemandControlEntry 4 }
emDemandTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmDemandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<Claise, et. Al> Expires March 8, 2011 [Page 37]
Internet-Draft <Energy Monitoring MIB> Sep 2010
"This table lists PowerMonitor Entity energy usage
measurements. Only when the PowerMonitor Entity has the
pmPowerUsageCaliber value set to actual(2) will this
table be populated."
::= { powerMonitorMIBObjects 4 }
emDemandEntry OBJECT-TYPE
SYNTAX EmDemandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes energy usage measurements."
INDEX { pmIndex, emDemandIntervalStartTime }
::= { emDemandTable 1 }
EmDemandEntry ::= SEQUENCE {
emDemandIntervalStartTime TimeTicks,
emDemandIntervalEnergyUsed Integer32,
emDemandIntervalEnergyUnits MonitorScale,
emDemandIntervalMax Integer32
}
emDemandIntervalStartTime 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. "
::= { emDemandEntry 1 }
emDemandIntervalEnergyUsed 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 PowerMonitor Entity over the defined
interval. This value is specified in the common billing
units of watts-hours with the magnitude of watt-hours
<Claise, et. Al> Expires March 8, 2011 [Page 38]
Internet-Draft <Energy Monitoring MIB> Sep 2010
(kW-Hr, MW-Hr, etc.) indicated separately in
emDemandIntervalPowerScale."
::= { emDemandEntry 2 }
emDemandIntervalEnergyUnits OBJECT-TYPE
SYNTAX MonitorScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This magnitude of watt-hours for the energy field in
emDemandIntervalEnergyUsed."
::= { emDemandEntry 3 }
emDemandIntervalMax OBJECT-TYPE
SYNTAX Integer32
UNITS "Watt-hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is the maximum demand ever observed in
emDemandIntervalEnergyUsed since the monitoring started.
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
emDemandIntervalEnergyUnits."
::= { emDemandEntry 4 }
pmEnable OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control object to activate or de-activate all
PowerMonitor Entities on the SNMP agent (e.g. Switch).
enable: enables all PowerMonitor Entities.
disable: disables all PowerMonitor Entities"
::= { powerMonitorMIBObjects 5 }
pmVersion OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
<Claise, et. Al> Expires March 8, 2011 [Page 39]
Internet-Draft <Energy Monitoring MIB> Sep 2010
STATUS current
DESCRIPTION
"This object specifies the current version of the
PowerMonitor software running on a PowerMonitor
Entity."
::= { powerMonitorMIBObjects 6 }
-- Notifications
pmLevelChange NOTIFICATION-TYPE
OBJECTS { pmIndex, pmPowerLevel }
STATUS current
DESCRIPTION
"The SNMP entity generates the PmLevelChange when
the value of pmPowerLevel has changed for the
PowerMonitor Entity 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,
powerMonitorMIBNotifGroup
}
::= { powerMonitorMIBCompliances 1 }
powerMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-create (i.e. in read-only mode), then such an
<Claise, et. Al> Expires March 8, 2011 [Page 40]
Internet-Draft <Energy Monitoring MIB> Sep 2010
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 pmName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmRoleDescription
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmDomainName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmEnable
MIN-ACCESS read-only
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,
pmDomainName,
pmName,
pmRoleDescription,
pmPowerUnits,
pmPowerUsage,
pmPowerUsageNameplate,
pmPowerUsageAccuracy,
pmPowerUsageCaliber,
<Claise, et. Al> Expires March 8, 2011 [Page 41]
Internet-Draft <Energy Monitoring MIB> Sep 2010
pmPowerLevel,
pmPowerUsageCategory,
pmEnable,
pmVersion
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the PowerMonitor Entity."
::= { powerMonitorMIBGroups 1 }
powerMonitorMIBLevelTableGroup OBJECT-GROUP
OBJECTS {
-- pmLevelIndex,
pmLevelMaxUsage,
pmLevelPowerUnits
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the PowerState Level."
::= { powerMonitorMIBGroups 2 }
powerMonitorMIBNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
pmLevelChange
-- pmLevelIndex
}
STATUS current
DESCRIPTION
"This group contains the notifications for the power
monitoring MIB Module."
::= { powerMonitorMIBGroups 3 }
END
9. 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
<Claise, et. Al> Expires March 8, 2011 [Page 42]
Internet-Draft <Energy Monitoring MIB> Sep 2010
when sending them over the network via SNMP. These are the
tables and objects and their sensitivity/vulnerability:
All other objects and tables contain no data that is considered
sensitive.
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.
10. 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 March 8, 2011 [Page 43]
Internet-Draft <Energy Monitoring MIB> Sep 2010
11. References
11.1. Normative References
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version
3)", RFC 4133, August 2005.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
[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.
[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.
[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm
11.2. Informative 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.
<Claise, et. Al> Expires March 8, 2011 [Page 44]
Internet-Draft <Energy Monitoring MIB> Sep 2010
[RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,
"Guidelines for Writing an IANA Considerations Section
in RFCs ", BCP 26, RFC 5226, May 2008.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework ", RFC 3410, December
2002.
[RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group
MIB", RFC 2863, June 2000.
[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.
12. Authors' Addresses
Benoit Claise
Cisco Systems Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
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
<Claise, et. Al> Expires March 8, 2011 [Page 45]
Internet-Draft <Energy Monitoring MIB> Sep 2010
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 March 8, 2011 [Page 46]
| PAFTECH AB 2003-2026 | 2026-04-24 07:24:48 |