Network Working Group B. Claise
Internet-Draft M. Chandramouli
Intended Status: Standards Track J. Parello
Expires: July 13, 2010 B. Schoening
Cisco Systems, Inc.
January 13, 2010
Energy Monitoring MIB
draft-claise-energy-monitoring-mib-00
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 July 13 2010 [Page 1]
Internet-Draft <Energy Monitoring MIB> Jan 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they
describe your rights and restrictions with respect to this
document.
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 Jan 13, 2011 [Page 2]
Internet-Draft <Energy Monitoring MIB> Jan 2010
Table of Contents
1. Introduction 4
2. The Internet-Standard Management Framework 4
3. Terminology 4
4. Concepts 5
5. Structure of the MIB 7
5.1. Link with the other IETF MIBs 7
6. MIB Definitions 8
7. Security Considerations 22
8. IANA Considerations 23
9. References 23
9.1. Normative References 23
9.2. Informative References 24
10. Authors' Addresses 24
<Claise, et. Al> Expires Jan 13, 2011 [Page 3]
Internet-Draft <Energy Monitoring MIB> Jan 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 Jan 13, 2011 [Page 4]
Internet-Draft <Energy Monitoring MIB> Jan 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. The
value represents an exponent of 10.
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.
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
<Claise, et. Al> Expires Jan 13, 2011 [Page 5]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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, meter-only, or energy
consumer-producer. The emEnergyUsage, specified as Integer32,
can have a positive and negative value, allowing to double-check
the usage type in emEnergyUsageCategory, or determining whether
the EnergyMonitor Entity consumes or produces power in case of
"consumer-producer".
An Energy Monitor Entity can have a user defined name - emName,
an entityPhysicalIndex from the ENTITY-MIB [RFC4133] and its a
unique energyMonitor index, emIndex. That EnergyMonitor Entity
can be a member of a domain (a logical group).
A domain is a logical grouping of EnergyMonitor Entities from
the point of monitoring power consumption and also from the
point of control of those EnergyMonitor Entities. Thus diverse
policies can be configured for EnergyMonitor Entities belonging
to different domains.
For example, a given EnergyMonitor Entity as described by the
emIndex, emPhysicalEntity and enName. 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 "presumed" (in other
words not 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.
<Claise, et. Al> Expires Jan 13, 2011 [Page 6]
Internet-Draft <Energy Monitoring MIB> Jan 2010
5. Structure of the MIB
The primary MIB object in this MIB module is
EnergyMonitorMIBObjects.
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
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. The
EnergyMonitor Entities that are not modeled by entPhysicalIndex
(for e.g. CPU, Memory, storage systems, ...) can be indexed with
zero value in emPhysicalEntity, thanks to PhysicalIndexOrZero
textual convention. If there are multiple entities with zero as
an index, in order to distinguish between multiple entities, a
extra index emDeviceId has been proposed, which would ensure
uniqueness.
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.
RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module provides
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
<Claise, et. Al> Expires Jan 13, 2011 [Page 7]
Internet-Draft <Energy Monitoring MIB> Jan 2010
on measurement of energy consumption by networking equipment
indexed by the entity MIB, this MIB proposes different power
level states of networking equipment and a functionality to
configure the power level states.
RFC 4268 [RFC4268] 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 state models need to be
developed. The Energy Monitoring MIB proposes the power states
of entities in the Entity MIB.
6. MIB Definitions
-- ************************************************************
--
--
-- 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
FROM SNMPv2-SMI
MODULE-COMPLIANCE,
NOTIFICATION-GROUP,
OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
PhysicalIndexOrZero
FROM ENTITY-MIB;
energyMonitorMIB MODULE-IDENTITY
LAST-UPDATED "201001130000Z"
ORGANIZATION "Cisco Systems, Inc."
<Claise, et. Al> Expires Jan 13, 2011 [Page 8]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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 }
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
<Claise, et. Al> Expires Jan 13, 2011 [Page 9]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
to level G2 in ACPI.
hibernate(3): No entity features are available. The
entity may be available 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
<Claise, et. Al> Expires Jan 13, 2011 [Page 10]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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."
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)
}
<Claise, et. Al> Expires Jan 13, 2011 [Page 11]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
"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
exa(15), -- 10^15
peta(18), -- 10^18
zetta(21), -- 10^21
yotta(24) -- 10^24
}
-- Objects
<Claise, et. Al> Expires Jan 13, 2011 [Page 12]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
EnergyMonitor Entity, the device creates/destroys
a row in the emTable."
INDEX { emIndex }
::= { emTable 1 }
EmEntry ::= SEQUENCE {
emIndex Integer32,
emDeviceId EnergyMonitorId,
emPhysicalEntity PhysicalIndexOrZero,
emDomainName SnmpAdminString,
emName SnmpAdminString,
emRoleDescription SnmpAdminString,
emEnergyUnits EnergyMonitorPowerScale,
emEnergyUsage Integer32,
emEnergyUsageNameplate Integer32,
emEnergyUsageAccuracy Integer32,
emEnergyUsageCaliber INTEGER,
emEnergyLevel EnergyMonitorLevel,
emEnergyUsageCategory INTEGER
}
emIndex OBJECT-TYPE
SYNTAX Integer32 (0..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-
<Claise, et. Al> Expires Jan 13, 2011 [Page 13]
Internet-Draft <Energy Monitoring MIB> Jan 2010
initialization of the entity's network management system
to the next re-initialization."
::= { emEntry 1 }
emDeviceId OBJECT-TYPE
SYNTAX EnergyMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the EnergyMonitor identifier
assigned to the device. This object value must be unique
within the domain and non-null."
::= { emEntry 2 }
emPhysicalEntity 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."
::= { emEntry 3 }
emDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of a domain for the
EnergyMonitor Entity. This object specifies a null
string if no domain name is configured."
::= { emEntry 4 }
emName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned human
readable name to the EnergyMonitor Entity. This object
specifies a null string if no name is configured."
::= { emEntry 5 }
emRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
<Claise, et. Al> Expires Jan 13, 2011 [Page 14]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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 }
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.
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 maximum consumption for the
fully populated EnergyMonitor Entity. This value is
specified in SI units of watts with the magnitude of
watts (milliwatts, kilowatts, etc.) indicated separately
in emEnergyUnits.
This value can by used for capacity and provisioning
planning. It is typically a value provided via
<Claise, et. Al> Expires Jan 13, 2011 [Page 15]
Internet-Draft <Energy Monitoring MIB> Jan 2010
experimentation and prediction from the manufacturer of
the entity."
::= { emEntry 9 }
emEnergyUsageAccuracy OBJECT-TYPE
SYNTAX Integer32 (0..1000)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates a percentage value in 10ths of a
percent representing the accuracy to which the reported
usage, reported by the emEnergyUsage can be assumed.
Example 101 means the reported usage is accurate to +/-
10.1 percent. This value is zero if the accuracy is
unknown."
::= { 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.
- 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. 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.
For example, a PC Model X draws 200W, while a PC Model Y
draws 210W.
- 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.
<Claise, et. Al> Expires Jan 13, 2011 [Page 16]
Internet-Draft <Energy Monitoring MIB> Jan 2010
- 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.
- trusted: This indicates that the usage data reported
was reported from another source."
::= { emEntry 11 }
emEnergyLevel OBJECT-TYPE
SYNTAX EnergyMonitorLevel
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the current power level for the
EnergyMonitor Entity."
::= { emEntry 12 }
emEnergyUsageCategory OBJECT-TYPE
SYNTAX INTEGER {
consumer(1),
producer(2),
meteronly(3),
consumerproducer(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the energy usage type of the
entity.
Consumer: This indicates that the entity is
consumes energy.
Producer: This indicates that the entity
generates energy.
Meteronly: This indicates that the entity is a
meter which reads the energy consumed
or produced.
Consumerproducer: This indicates that the entity is
both a consumer and producer."
::= { emEntry 13 }
emLevelTable OBJECT-TYPE
SYNTAX SEQUENCE OF EmLevelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<Claise, et. Al> Expires Jan 13, 2011 [Page 17]
Internet-Draft <Energy Monitoring MIB> Jan 2010
"This table lists the power usage 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 }
emLevelMaxUsage OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
<Claise, et. Al> Expires Jan 13, 2011 [Page 18]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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 }
emEnable OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
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 3 }
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 4 }
-- Notifications
emLevelChange NOTIFICATION-TYPE
<Claise, et. Al> Expires Jan 13, 2011 [Page 19]
Internet-Draft <Energy Monitoring MIB> Jan 2010
OBJECTS { emEnergyLevel }
STATUS current
DESCRIPTION
"The SNMP entity generates the EmLevelChange when
the value of emEnergyLevel has changed."
::= { 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
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
<Claise, et. Al> Expires Jan 13, 2011 [Page 20]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
energyMonitorMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object emIndex is NOT
-- included since it is not-accessiblej
emDeviceId,
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 }
<Claise, et. Al> Expires Jan 13, 2011 [Page 21]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
"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],
<Claise, et. Al> Expires Jan 13, 2011 [Page 22]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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 }
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.
<Claise, et. Al> Expires Jan 13, 2011 [Page 23]
Internet-Draft <Energy Monitoring MIB> Jan 2010
[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.
[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.
10. Authors' Addresses
Benoit Claise
Cisco Systems Inc.
De Kleetlaan 6a b1
<Claise, et. Al> Expires Jan 13, 2011 [Page 24]
Internet-Draft <Energy Monitoring MIB> Jan 2010
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
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 Jan 13, 2011 [Page 25]