Network Working Group B. Claise
Internet-Draft M. Chandramouli
Intended Status: Standards Track J. Parello
Expires: August 5, 2010 B. Schoening
Cisco Systems, Inc.
February 5, 2010
Energy Monitoring MIB
draft-claise-energy-monitoring-mib-01
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 July, 2010.
<Claise, et. Al> Expires August 5 2010 [Page 1]
Internet-Draft <Energy Monitoring MIB> Feb 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may
not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
Abstract
This document defines the Management Information Base (MIB)
for the energy 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 August 5, 2011 [Page 2]
Internet-Draft <Energy Monitoring MIB> Feb 2010
Table of Contents
1. Introduction............................................... 4
2. The Internet-Standard Management Framework................. 4
3. Terminology................................................ 4
4. Concepts................................................... 6
5. Structure of the MIB....................................... 9
5.1. Link with the other IETF MIBs............................10
5.1.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB.....10
5.1.2. Link with the ENTITY-STATE-MIB.........................11
5.1.3. Link with the POWER-OVER-ETHERNET MIB..................11
6. MIB Definitions........................................... 11
7. Security Considerations................................... 30
8. IANA Considerations....................................... 30
9. References................................................ 31
9.1. Normative References.....................................31
9.2. Informative References...................................31
10. Authors' Addresses....................................... 32
<Claise, et. Al> Expires August 5, 2011 [Page 3]
Internet-Draft <Energy Monitoring MIB> Feb 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 energy consumption of network
elements, taking into account the requirements specified in
[POWER-MON-REQ]. In addition to energy monitoring,
functionality to configure the power state of network elements
is proposed.
The MIB module in this document has been designed in order to be
as flexible as possible, 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, middle boxes, 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].
3. Terminology
EnergyMonitor Entity
<Claise, et. Al> Expires August 5, 2011 [Page 4]
Internet-Draft <Energy Monitoring MIB> Feb 2010
An EnergyMonitor Entity is a system of one or more
components, that provides power or draws power. It can be
independently managed from a power monitoring and power state
configuration point of view. This entity may be represented
by a physical component referenced using the EntPhysicalTable
from the Entity MIB RFC 2737.
Examples of EnergyMonitor Entities are a router line card, a
motherboard with a CPU, etc.
EnergyMonitor Level
A uniform way to classify power settings on an EnergyMonitor
Entity. Levels are guidelines for the manufacturers of
entity (e.g., shut, hibernate, sleep, standby).
EnergyMonitor Scale
A scale used to represent smaller or larger quantities of
EnergyMonitor 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 an EnergyMonitor Entity is
3, it could be 3 W, 3 mW, 3 KW, 3 MW depending on the value
of EnergyMonitor Scale.
EnergyMonitor Domain
A EnergyMonitor Domain is a name or name space which
logically groups together EnergyMonitor Entities that
comprises a unit of manageable power consumption. For
example, all phones in a floor, all EnergyMonitor Entities
from a specific building, or all EnergyMonitor 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 energy consumed as the sum of energy
consumed by all the EnergyMonitor Entities of the
EnergyMonitor Domain.
<Claise, et. Al> Expires August 5, 2011 [Page 5]
Internet-Draft <Energy Monitoring MIB> Feb 2010
4. Concepts
EnergyMonitor Levels represent the one of twelve power
management states of an entity. Each EnergyMonitor 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
10 G0, S0, P2 Reduced
11 G0, S0, P1 High
12 G0, S0, P0 Full
For example, the energy state of the EnergyMonitor Entity is 9,
to indicate the entity is medium power consumption operational
state.
The emEnergyUsageCategory MIB object, specified as a read-only
object, specifies the energy usage type of the EnergyMonitor
Entity: energy consumer, energy producer, or meter. The
emEnergyUsage, specified as Integer32, can have a positive or
negative value, corresponding with the usage type in
emEnergyUsageCategory, determining whether the EnergyMonitor
Entity consumes or produces power in case of "consumer" and
"producer".
An Energy Monitor Entity should have an emName, and a unique
EnergyMonitor index emIndex, and potentially an
entityPhysicalIndex from the ENTITY-MIB [RFC4133], if supported
by the EnergyMonitor Entity. The emName can be configured or
discovered by DNS. Possible emName are: textual DNS name, MAC-
<Claise, et. Al> Expires August 5, 2011 [Page 6]
Internet-Draft <Energy Monitoring MIB> Feb 2010
address of the device, interface ifName, or a text string
uniquely identifying the entity. The emName should ideally be
unique. As an example, in the case of phones, emName can be
discovered by DNS and can be the IP address or MAC-address. In
the case of router/switch line cards, the emName shall be text
string. That EnergyMonitor Entity can be a member of a
EnergyMonitor Domain. The EnergyMonitor 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
EnergyMonitor Domains such as a lab, data center, rack, etc.
With the possible evolution of this draft, to a framework
document, the notion of EnergyMonitor Domain shall be useful.
For an EnergyMonitor Entity, instantaneous energy usage is
reported using emEnergyUsage and the unit magnitude of
measurement is specified in emEnergyUnits which is based on
EnergyMonitorPowerScale.
Nameplate power consumption of an EnergyMonitor Entity is
specified by the vendor as the maximum capacity required to
safely power the device. Often this label is a conservative
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 measurement of power consumption, an approach to
characterize the power demand is also presented in the MIB. It
is well-known, in the electrical utility perspective, the demand
charges can weigh on par with actual energy charges. So, in
addition to measuring power consumption, it is useful to
characterize the demand. The demand can be described as average
power usage of an entity over a time window, called demand
interval, typically 15 minutes. The highest peak demand
measured over a time horizon, say 1 month or 1 year is often the
basis for usage charge. For example, a single window of time of
high usage can penalize the power consumption charges. It is
relevant to measure the demand, only when there are actual power
measurements from an EnergyMonitor Entity. There are cases,
wherein the power measurement of an EnergyMonitor Entity is
assumed, or predicted as pointed in the MIB OID
EnergyUsageCaliber.
Two tables are introduced to characterize the energy demand -
emDemandTable and emDemandControlTable. emDemandControl Table
consists of parameters of the duration of the demand interval
specified in seconds, emDemandControlIntervalLength, (for e.g.
<Claise, et. Al> Expires August 5, 2011 [Page 7]
Internet-Draft <Energy Monitoring MIB> Feb 2010
15 minutes); The number of demand intervals kept in the
emDemandTable, emDemandControlIntervalNumber, ;
emDemandControlSampleRate which is internal to the device to
calculate energy usage. Judicious choice of SamplingRate would
help in accurate measurement of energy and ensure that it does
impose excessive polling burden. The emDemandControlStatus is
useful to specify the power measurement is actual and thus to
indicate if the emDemandTable entries exist or not.
emDemand Table consists of measurements of energy
DemandIntervalEnergyUsed, the scale of energy measurement -
DemandIntervalEnergyScale and the maximum observed demand in a
window - emDemandIntervalMaxf
Various efficiency metrics can be derived and tracked with the
usage data present in this MIB module. For example,
- Per-packet energy 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 energy use from this MIB can be combined with
utility energy sources to estimate carbon footprint and other
emission statistics.
An example is provided to illustrate the concepts. For example,
a given EnergyMonitor Entity as described by the emIndex "7"
emPhysicalEntity "5" and emName "switch2.foo.com". For that
EnergyMonitor Entity, the energy measurement and power state is
reported as follows: the units of measurement emEnergyUnits is
"watts" (value 1), the instantaneous power usage enEnergyUsage
is 100 watts, while the maximum power consumption as prescribed
by the vendor emEnergyNamePlate is 300 watts. The
emEnergyUsageCaliber indicates that the energy measurement is
"actual". The power state of that EnergyMonitor Entity
EmEnergyLevel is "9" to indicate medium power usage and
emEnergyUsageCategory indicates the type of EnergyMonitor Entity
consumer or producer of power or both. In addition, the maximum
power consumption at the level emLevelMaxUsage is indicated as
150 watts.
emDemandTable and emDemandControlTable are illustrated,
following the same example. Firstly, in order to estimate
demand, an interval to sample power 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 EnergyMonitor Entity for measurement of
<Claise, et. Al> Expires August 5, 2011 [Page 8]
Internet-Draft <Energy Monitoring MIB> Feb 2010
energy usage, emDemandControlSampleRate, can be "1000
milliseconds", as set by the EnergyMonitor Entity as a
reasonable value. Then, the emDemandControlStatus is set to
active (value 1) to indicate that the EnergyMonitor Entity
should start monitor the usage as per the emDemandTable.
For the indexes in the emDemandTable are the emIndex, which
identifies the EnergyMonitor Entity and the
emDemandIntervalStartTime, which denotes the start time of the
demand measurement interval based on the sysUpTime.
emDemandIntervalEnergyUsed is the measurement of the energy
consumption over the time interval specified
(emDemandControlIntervalLength) based on the EnergyMonitor
Entity internal sampling rate (emDemandControlSampleRate). The
units are derived from emDemandIntervalEnergyScale is based
EnergyMonitorScale. For example, emDemandIntervalEnergyUsed can
be "100" with emDemandIntervalEnergyScale 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
explanation on how the maximum demand is calculated. The first
observed demand measurement value is taken to be the maximum.
With each measurement, based on numerical comparison, maximum
demand may be updated. The maximum value is retained as long as
the measurement is taking place. Based on periodic polling, the
Network Management System can 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 emLevelChange NOTIFICATION-TYPE, indexed by the emIndex and
the emEnergyLevel, which is generated when the value of
emEnergyLevel has changed for the EnergyMonitor Entity
represented by the emIndex. Indeed, assuming that the SNMP
notifications arrives to Network Management Station (NMS), the
NMS can deduce all the information.
5. Structure of the MIB
The primary MIB object in this MIB module is
EnergyMonitorMIBObjects.
<Claise, et. Al> Expires August 5, 2011 [Page 9]
Internet-Draft <Energy Monitoring MIB> Feb 2010
The emTable table defines the EnergyMonitor Entities, with a
potential link to the entPhysicalIndex, when available. The
EnergyMonitor Entities are used for describing and configuring
the entities that are possible candidates for power management.
The specific EnergyMonitor Level can be configured in the
emTable.
The emLevelTable table lists the maximum power usage at each
EnergyMonitor Level for each EnergyMonitor Entity.
Finally, the monitoring of all the EnergyMonitor Entities on the
SNMP agent can be turned on/off with the emEnable MIB object.
5.1. Link with the other IETF MIBs
5.1.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 Energy Monitoring MIB, is on measurement of energy
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 energy consumption
of devices such as routers and switches, the ENTITY-MIB and
ENTITY-SENSOR-MIB should be implemented. In such cases, the
EnergyMonitor Entities are modeled by the entPhysicalIndex
through the emPhysicalEntity MIB object specified in the
emTable.
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 emEnergyUsageAccuracy MIB object models this accuracy. Note
that the emEntEnergyScale represents the scale is a more logical
<Claise, et. Al> Expires August 5, 2011 [Page 10]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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 EnergyMonitor 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 emPhysicalEntity value contains the zero
value, thanks to PhysicalIndexOrZero textual convention.
As a consequence, the emEnergyMonitorId MIB object has been kept
as the unique Energy Monitor Entity index. Finally, not that
the emEntEnergyUsage is similar to entPhySensorValue [RFC3433]
and the emEntEnergyScale is similar to entPhySensorScale
[EDITOR NOTE: the proxy table will be added in the next version
of the draft].
5.1.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 an energy monitoring point of
view, different power states to indicate the power state of the
entities models need to be developed. The Energy Monitoring MIB
proposes the power states of entities in the Entity MIB.
5.1.3. Link with the POWER-OVER-ETHERNET MIB
Power-over-Ethernet MIB [RFC-3621] provides energy monitoring
and configuration framework for power over Ethernet devices.
The RFC uses a concept of group of ports of a switch to define
power monitoring and management policy and does not use the
entPhysicalIndex as index. For the purpose on hand, power
monitoring of components of networking devices, RFC 3621 can not
be applied.
6. MIB Definitions
-- ************************************************************
--
<Claise, et. Al> Expires August 5, 2011 [Page 11]
Internet-Draft <Energy Monitoring MIB> Feb 2010
--
-- This MIB is used to monitor Energy Consumption of network
-- devices
--
-- *************************************************************
ENERGY-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
RowStatus, TimeInterval
FROM SNMPv2-TC
PhysicalIndexOrZero
FROM ENTITY-MIB;
energyMonitorMIB 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. "
<Claise, et. Al> Expires August 5, 2011 [Page 12]
Internet-Draft <Energy Monitoring MIB> Feb 2010
::= { mib-2 xxxxx }
energyMonitorMIBNotifs OBJECT IDENTIFIER
::= { energyMonitorMIB 0 }
energyMonitorMIBObjects OBJECT IDENTIFIER
::= { energyMonitorMIB 1 }
energyMonitorMIBConform OBJECT IDENTIFIER
::= { energyMonitorMIB 2 }
-- Textual Conventions
EnergyMonitorLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An enumerated integer value that represents the value
of EnergyMonitor Level, a power setting at which a
EnergyMonitor Entity uses power.
The EnergyMonitor 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).
EnergyMonitor 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
<Claise, et. Al> Expires August 5, 2011 [Page 13]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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
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
<Claise, et. Al> Expires August 5, 2011 [Page 14]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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."
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)
}
EnergyMonitorId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for the EnergyMonitor Entity in the
EnergyMonitor Domain. Implementation must ensure that the
ID for each EnergyMonitor Entity is unique among all
entities within the EnergyMonitor Domain. A Universally
Unique Identifier (UUID) is typically used."
REFERENCE
"IETF RFC 4122"
SYNTAX OCTET STRING (SIZE (16))
EnergyMonitorPowerScale ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
<Claise, et. Al> Expires August 5, 2011 [Page 15]
Internet-Draft <Energy Monitoring MIB> Feb 2010
"The EnergyMonitor Scale: an integer value that
represents the units used to measure the power.
The units are expressed in watts.
I.e., -3 represents 10^-3 or milliwatts"
REFERENCE
"The International System of Units (SI),
National Institute of Standards and Technology,
Spec. Publ. 330, August 1991."
SYNTAX INTEGER {
yocto(-24), -- 10^-24
zepto(-21), -- 10^-21
atto(-18), -- 10^-18
femto(-15), -- 10^-15
pico(-12), -- 10^-12
nano(-9), -- 10^-9
micro(-6), -- 10^-6
milli(-3), -- 10^-3
units(0), -- 10^0
kilo(3), -- 10^3
mega(6), -- 10^6
giga(9), -- 10^9
tera(12), -- 10^12
peta(15), -- 10^15
exa(18), -- 10^18
zetta(21), -- 10^21
yotta(24) -- 10^24
}
-- Objects
emTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists EnergyMonitor Entities."
::= { energyMonitorMIBObjects 1 }
emEntry OBJECT-TYPE
SYNTAX EmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes attributes of a EnergyMonitor
Entity. Whenever the device creates/destroys a
<Claise, et. Al> Expires August 5, 2011 [Page 16]
Internet-Draft <Energy Monitoring MIB> Feb 2010
EnergyMonitor Entity, the device creates/destroys
a row in the emTable."
INDEX { emIndex }
::= { emTable 1 }
EmEntry ::= SEQUENCE {
emIndex Integer32,
emEnergyMonitorId EnergyMonitorId,
emPhysicalEntity PhysicalIndexOrZero,
emDomainName SnmpAdminString,
emName SnmpAdminString,
emRoleDescription SnmpAdminString,
emEnergyUnits EnergyMonitorPowerScale,
emEnergyUsage Integer32,
emEnergyUsageNameplate Integer32,
emEnergyUsageAccuracy Integer32,
emEnergyUsageCaliber INTEGER,
emEnergyLevel EnergyMonitorLevel,
emEnergyUsageCategory BITS
}
emIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each
EnergyMonitor Entity. It is recommended that values are
assigned contiguously starting from 1. The value for
each emIndex must remain constant at least from one re-
initialization of the entity's network management system
to the next re-initialization."
::= { emEntry 1 }
emEnergyMonitorId OBJECT-TYPE
SYNTAX EnergyMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the EnergyMonitor UUID identifier.
This object value must be unique within the EnergyMonitor
Domain."
::= { emEntry 2 }
emPhysicalEntity OBJECT-TYPE
SYNTAX PhysicalIndexOrZero
MAX-ACCESS read-only
STATUS current
<Claise, et. Al> Expires August 5, 2011 [Page 17]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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."
::= { emEntry 3 }
emDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of a EnergyMonitor Domain
for the EnergyMonitor Entity. This object specifies a
null string if no EnergyMonitor Domain name is
configured. The value of emDomainName must remain
constant at least from one re-initialization of the
entity's network management system to the next re-
initialization."
::= { emEntry 4 }
emName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write STATUS current
DESCRIPTION
"This object specifies a printable name, a text string,
for the EnergyMonitor Entity. It is preferred, but not
required that emName be unique.
The process to assign the emName is implementation
specific. Example: DNS Name, MAC address in canonical
form, ifName, etc..."
::= { emEntry 5 }
emRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned name
to indicate the purpose an EnergyMonitor Entity serves in
the network.
For example, we can have switches deployed to a lobby
with emName as 'Lobby Switch' and emRoleDescription as
'IP Phones'.
This object specifies a null string if no role
description is configured."
::= { emEntry 6 }
<Claise, et. Al> Expires August 5, 2011 [Page 18]
Internet-Draft <Energy Monitoring MIB> Feb 2010
emEnergyUnits OBJECT-TYPE
SYNTAX EnergyMonitorPowerScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of Watts for the usage value in
emEnergyUsage and emEnergyUsageNameplate."
::= { emEntry 7 }
emEnergyUsage OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the instantaneous consumption for
the EnergyMonitor Entity. This value is specified in SI
units of watts with the magnitude of watts (milliwatts,
kilowatts, etc.) indicated separately in emEnergyUnits.
If the EnergyMonitor Entity is a consumer (bit value 1 in
emEnergyUsageCategory, the usage value will be positive.
If the EnergyMonitor Entity is a producer (bit value 2 in
emEnergyUsageCategory, the usage value will be negative.
This should be less than or equal to the power that can
be consumed at that specified level.
"
::= { emEntry 8 }
emEnergyUsageNameplate OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the rated maximum consumption for
the fully populated EnergyMonitor 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 emEnergyUnits.
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."
::= { emEntry 9 }
<Claise, et. Al> Expires August 5, 2011 [Page 19]
Internet-Draft <Energy Monitoring MIB> Feb 2010
emEnergyUsageAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..10000)
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 emEnergyUsage 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"
::= { emEntry 10 }
emEnergyUsageCaliber 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
emEnergyUsage, 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. For example, a PoE phone can
report the actual usage as X W.
- trusted: This indicates that the usage data reported
was reported from another source. Trusted is higher
caliber than predicted.
<Claise, et. Al> Expires August 5, 2011 [Page 20]
Internet-Draft <Energy Monitoring MIB> Feb 2010
- 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 disable,
and 600w when POE is fully enabled.
- presumed: This indicates that the actual power drawn
cannot be determined but can be presumed from the model.
Presumed is the lowest caliber. For example, a PC Model
X draws 200W, while a PC Model Y draws 210W."
::= { emEntry 11 }
emEnergyLevel OBJECT-TYPE
SYNTAX EnergyMonitorLevel
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the current power level (1..12)
for the EnergyMonitor Entity."
::= { emEntry 12 }
emEnergyUsageCategory OBJECT-TYPE
SYNTAX BITS {
consumer(1),
producer(2),
meter(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the energy usage type of the
entity. An entity could be producing power when
emEnergyUsageCategory is producer(2) or a consumer of
power consumer (1) or a hybrid - consumer and
producer(3). Negative values of energy usage are
permissible to indicate the entities as energy sources.
Consumer: This indicates that the entity is
consumes energy.
Producer: This indicates that the entity
generates energy.
Meter: This indicates that the entity is a
meter which reads the energy consumed
or produced."
::= { emEntry 13 }
<Claise, et. Al> Expires August 5, 2011 [Page 21]
Internet-Draft <Energy Monitoring MIB> Feb 2010
emLevelTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table enumerates the maximum power usage in watts
at each EnergyMonitor Level for each EnergyMonitor
Entity.
This table has an expansion dependent relationship on the
emTable, containing rows describing each EnergyMonitor
Level for the corresponding EnergyMonitor Entity."
::= { energyMonitorMIBObjects 2 }
emLevelEntry OBJECT-TYPE
SYNTAX EmLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A emLevelEntry extends a corresponding emEntry. This
entry displays max usage and delta values at each level.
For example, the given the values of a EnergyMonitor
Entity corresponds to a maximum usage of 11W at the
level 2:
Level MaxUsage Units
2 11 1"
INDEX {
emIndex,
emLevelIndex
}
::= { emLevelTable 1 }
EmLevelEntry ::= SEQUENCE {
emLevelIndex EnergyMonitorLevel,
emLevelMaxUsage Integer32,
emLevelEnergyUnits EnergyMonitorPowerScale
}
emLevelIndex OBJECT-TYPE
SYNTAX EnergyMonitorLevel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indicates the level for which this entry
describes the power usage."
::= { emLevelEntry 1 }
<Claise, et. Al> Expires August 5, 2011 [Page 22]
Internet-Draft <Energy Monitoring MIB> Feb 2010
emLevelMaxUsage OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the maximum power usage for the
EnergyMonitor Entity at the particular EnergyMonitor
Level. This value is specified in SI units of watts with
the magnitude of watts (milliwatts, kilowatts, etc.)
indicated separately in emLevelEnergyUnits."
::= { emLevelEntry 2 }
emLevelEnergyUnits OBJECT-TYPE
SYNTAX EnergyMonitorPowerScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The magnitude of the watts for the usage value in
emLevelMaxUsage."
::= { emLevelEntry 3 }
emDemandControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmDemandControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls the setup of the demand table emDemandTable."
::= { energyMonitorMIBObjects 3 }
emDemandControlEntry OBJECT-TYPE
SYNTAX EmDemandControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry controls energy usage measurements."
INDEX { emIndex }
::= { emDemandControlTable 1 }
EmDemandControlEntry ::= SEQUENCE {
emDemandControlIntervalLength TimeInterval,
emDemandControlIntervalNumber Integer32,
emDemandControlSampleRate Integer32,
emDemandControlStatus RowStatus
<Claise, et. Al> Expires August 5, 2011 [Page 23]
Internet-Draft <Energy Monitoring MIB> Feb 2010
}
emDemandControlIntervalLength OBJECT-TYPE
SYNTAX TimeInterval
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 EnergyMonitor 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
DESCRIPTION
"The number of demand intervals over which the maximum
demand is computed. Whenever the maximum number of entry
is reached, the new demand interval replaces the oldest
one, except if the oldest one is the
emDemandIntervalMax."
DEFVAL { 10 }
::= { emDemandControlEntry 2 }
emDemandControlSampleRate OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The sampling rate in milliseconds at which the
EnergyMonitor Entity would poll the instantaneous value
power value in order to compute the energy usage
measurements in the emDemandTable. The EnergyMonitor
should initially set up this sample rate to a reasonable
value, i.e. a compromise between a low value that will
give a good accuracy, and a too low value that will
impact the EnergyMonitor Entity performance by requesting
continuous polling."
DEFVAL { 1000 }
::= { emDemandControlEntry 3 }
<Claise, et. Al> Expires August 5, 2011 [Page 24]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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
"This table lists EnergyMonitor energy usage
measurements. Only when the Energy Monitor Entity has
the emEnergyUsageCaliber value set to actual(2), this
table will be populated."
::= { energyMonitorMIBObjects 4 }
emDemandEntry OBJECT-TYPE
SYNTAX EmDemandEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes energy usage measurements."
INDEX { emIndex, emDemandIntervalStartTime }
::= { emDemandTable 1 }
EmDemandEntry ::= SEQUENCE {
emDemandIntervalStartTime TimeTicks,
emDemandIntervalEnergyUsed Integer32,
emDemandIntervalEnergyScale EnergyMonitorPowerScale,
emDemandIntervalMax Integer32
}
emDemandIntervalStartTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS not-accessible
STATUS current
<Claise, et. Al> Expires August 5, 2011 [Page 25]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the energy used in units of watt-
hours for the EnergyMonitor Entity 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
emDemandIntervalEnergyScale."
::= { emDemandEntry 2 }
emDemandIntervalEnergyScale OBJECT-TYPE
SYNTAX EnergyMonitorPowerScale
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
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
emDemandIntervalEnergyScale."
::= { emDemandEntry 4 }
emEnable OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
<Claise, et. Al> Expires August 5, 2011 [Page 26]
Internet-Draft <Energy Monitoring MIB> Feb 2010
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A control object to activate/de-activate all
EnergyMonitor Entities on the SNMP agent (e.g. Switch).
enable: enables all EnergyMonitor Entities.
disable: disables all EnergyMonitor Entities"
::= { energyMonitorMIBObjects 5 }
emVersion OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the current version of the
EnergyMonitor software running on a EnergyMonitor
Entity."
::= { energyMonitorMIBObjects 6 }
-- Notifications
emLevelChange NOTIFICATION-TYPE
OBJECTS { emIndex, emEnergyLevel }
STATUS current
DESCRIPTION
"The SNMP entity generates the EmLevelChange when
the value of emEnergyLevel has changed for the
EnergyMonitor Entity represented by the emIndex"
::= { energyMonitorMIBNotifs 1 }
-- Conformance
energyMonitorMIBCompliances OBJECT IDENTIFIER
::= { energyMonitorMIB 3 }
energyMonitorMIBGroups OBJECT IDENTIFIER
::= { energyMonitorMIB 4 }
energyMonitorMIBFullCompliance 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
<Claise, et. Al> Expires August 5, 2011 [Page 27]
Internet-Draft <Energy Monitoring MIB> Feb 2010
be both monitored and configured with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
energyMonitorMIBTableGroup,
energyMonitorMIBLevelTableGroup,
energyMonitorMIBNotifGroup
}
::= { energyMonitorMIBCompliances 1 }
energyMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-create (i.e. in read-only mode), then such an
implementation can claim read-only compliance. Such a
device can then be monitored but can not be configured
with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
energyMonitorMIBTableGroup,
energyMonitorMIBLevelTableGroup,
energyMonitorMIBNotifGroup
}
OBJECT emName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT emRoleDescription
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT emDomainName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT emEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { energyMonitorMIBCompliances 2 }
-- Units of Conformance
<Claise, et. Al> Expires August 5, 2011 [Page 28]
Internet-Draft <Energy Monitoring MIB> Feb 2010
energyMonitorMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object emIndex is NOT
-- included since it is not-accessible
emEnergyMonitorId,
emPhysicalEntity,
emDomainName,
emName,
emRoleDescription,
emEnergyUnits,
emEnergyUsage,
emEnergyUsageNameplate,
emEnergyUsageAccuracy,
emEnergyUsageCaliber,
emEnergyLevel,
emEnergyUsageCategory,
emEnable,
emVersion
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Monitor Entity."
::= { energyMonitorMIBGroups 1 }
energyMonitorMIBLevelTableGroup OBJECT-GROUP
OBJECTS {
-- emLevelIndex,
emLevelMaxUsage,
emLevelEnergyUnits
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Monitor level."
::= { energyMonitorMIBGroups 2 }
energyMonitorMIBNotifGroup NOTIFICATION-GROUP
NOTIFICATIONS {
emLevelChange
-- emLevelIndex
}
STATUS current
DESCRIPTION
<Claise, et. Al> Expires August 5, 2011 [Page 29]
Internet-Draft <Energy Monitoring MIB> Feb 2010
"This group contains the notifications for the energy
monitoring MIB Module."
::= { energyMonitorMIBGroups 3 }
END
7. 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. 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.
8. 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
---------- -----------------------
EnergyMonitorMIB { mib-2 xxxxx }
<Claise, et. Al> Expires August 5, 2011 [Page 30]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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.
9. References
9.1. Normative References
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version
3)", RFC 4133, August 2005.
[RFC-3621] 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
9.2. Informative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
<Claise, et. Al> Expires August 5, 2011 [Page 31]
Internet-Draft <Energy Monitoring MIB> Feb 2010
[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.
[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.
10. 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
<Claise, et. Al> Expires August 5, 2011 [Page 32]
Internet-Draft <Energy Monitoring MIB> Feb 2010
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 August 5, 2011 [Page 33]