Network Working Group J. Quittek, Ed.
Internet-Draft R. Winter
Intended status: Informational T. Dietz
Expires: September 15, 2011 NEC Europe Ltd.
B. Claise
M. Chandramouli
Cisco Systems, Inc.
March 14, 2011
Requirements for Energy Management
draft-ietf-eman-requirements-01
Abstract
This memo discusses requirements for energy management, particularly
for monitoring energy consumption and controlling power states of
managed devices. This memo further shows that existing IETF
standards are not sufficient for energy management and that energy
management requires architectural considerations that are different
from common other management functions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Quittek, et al. Expires September 15, 2011 [Page 1]
Internet-Draft Requirements for Energy Management March 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Quittek, et al. Expires September 15, 2011 [Page 2]
Internet-Draft Requirements for Energy Management March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Energy management functions . . . . . . . . . . . . . . . 5
1.2. Specific aspects of energy management . . . . . . . . . . 7
2. Scenarios and target devices . . . . . . . . . . . . . . . . . 7
2.1. Scenario 1: Routers, switches, middleboxes, and hosts . . 7
2.2. Scenario 2: PoE sourcing equipment and PoE powered
devices . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Scenario 3: Power probes and Smart meters . . . . . . . . 8
2.4. Scenario 4: Mid-level managers . . . . . . . . . . . . . . 8
2.5. Scenario 5: Gateways to building networks . . . . . . . . 8
2.6. Scenario 6: Home energy gateways . . . . . . . . . . . . . 8
2.7. Scenario 7: Data center devices . . . . . . . . . . . . . 9
2.8. Scenario 8: Battery powered devices . . . . . . . . . . . 9
2.9. Scenario 9: Ganged outlets on a smart power strip . . . . 9
3. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 10
3.1. Granularity of monitoring and control . . . . . . . . . . 10
3.2. Remote and Aggregated Monitoring . . . . . . . . . . . . . 10
3.3. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Required Information . . . . . . . . . . . . . . . . . . . 12
3.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 12
3.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 12
3.4.3. Power Quality . . . . . . . . . . . . . . . . . . . . 13
3.4.4. Battery State Monitoring . . . . . . . . . . . . . . . 13
3.4.5. Multiple Power Sources . . . . . . . . . . . . . . . . 14
4. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 14
5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Identification . . . . . . . . . . . . . . . . . . . . . . 15
6. Control Requirements . . . . . . . . . . . . . . . . . . . . . 15
7. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 16
7.1.1. ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 16
7.1.2. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 17
7.1.3. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 17
7.1.4. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.5. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 18
7.1.6. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 18
7.2. Existing standards of other bodies . . . . . . . . . . . . 19
7.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Quittek, et al. Expires September 15, 2011 [Page 3]
Internet-Draft Requirements for Energy Management March 2011
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Quittek, et al. Expires September 15, 2011 [Page 4]
Internet-Draft Requirements for Energy Management March 2011
1. Introduction
With rising energy cost and with an increasing awareness of the
ecological impact of running IT and networking equipment, energy
management is becoming an additional basic requirement for network
management frameworks and systems.
Different to other typical network management functions, energy
management often extends its scope beyond devices with IP network
interfaces. Requirements in this document do not fully cover all
these networks, but they cover means for opening IP network
management towards them.
In general, IETF Standards for energy management should be defined in
such a way that they can be applied to several areas including but
not limited to
o Communication networks and IT systems
o Building networks
o Home networks
o Smart (power) grids
1.1. Energy management functions
The basic objective of energy management is operating communication
networks and other equipment with a minimal amount of energy. An
energy management system should provide means for reducing the power
consumption of individual components of a network as well as of the
whole network.
One approach to achieve this goal is setting all components to an
operational state that results in lower energy consumption but still
meets service level performance objectives. The sufficient
performance level may vary over time and can depend on several
factors. In principle, there are four basic types of power states
for a component or for a whole system:
o full power state
o reduced power states (lower clock rate for processor, lower data
rate on a link, etc.)
o stand-by/sleep state (not functional, but immediately available)
o power-off state (requiring significant time for becoming
operational)
In actual implementations the number of power states and their
properties vary a lot. Very simple devices may just have a full
power and a power off state, while other devices may have a high
number of different reduced power and sleep states.
While the general objective of energy management is quite clear, the
way to attain that goal is often difficult. In many cases there is
Quittek, et al. Expires September 15, 2011 [Page 5]
Internet-Draft Requirements for Energy Management March 2011
no way of reducing power consumption without the consequence of a
potential performance or capacity degradation. Then a trade-off
needs to be dealt with between service level objectives and energy
efficiency. In other cases a reduction of energy consumption can
easily be achieved while still maintaining sufficient service level
performance, for example, by switching components to lower power
states when higher performance is not needed.
Network management systems can control such situations by
implementing policies to achieve a certain degree of energy
efficiency. In order to make policy decisions properly, information
about the energy consumption of network components and sub-components
in different power states is required. Often this information is
acquired best through monitoring.
Monitoring operational power states and energy consumption is also
useful for other energy management purposes including but not limited
to
o investigating power saving potential
o evaluating the effectiveness of energy saving policies and
measures
o deriving, implementing, and testing power management strategies
o accounting the total power consumption of a network element, a
network, a service, or subcomponents of those
From the considerations described above the following basic
management functions appear to be required for energy management:
o monitoring power states of network elements and their
subcomponents
o monitoring actual power (energy consumption rate) of network
elements and their subcomponents
o monitoring (accumulated) energy consumption of network elements
and their subcomponents
o setting power states of network elements and their subcomponents
o setting and enforcing power saving policies
It should be noted that monitoring energy consumption and power
states itself is obviously not in itself a means to reduce the energy
consumption of a device. In fact, it is likely to increase the power
consumption of a device slightly. However, the acquired energy
consumption and power state information is essential for defining
energy saving policies and can be used as input to power state
control loops that in total can lead to energy savings.
It should further be noted that active power control is complementary
(but essential) to other energy savings measures such as low power
electronics, energy saving protocols (e.g. IEEE 802.3az), and
energy-efficient device design (for example, stand-by and low-power
Quittek, et al. Expires September 15, 2011 [Page 6]
Internet-Draft Requirements for Energy Management March 2011
modes for individual components of a device), and energy-efficient
network architectures. Measurement of energy consumption may also
provide input for developing these technologies.
1.2. Specific aspects of energy management
There are two aspects of energy management that make it different
from other common network management functions. The first difference
is that energy consumption is often measured remotely to the device
under consideration. A reason for this is that today very few
devices are instrumented with the hardware and software for measuring
their own current power and accumulated energy consumption. Often
power and energy for such devices is measured by other devices.
A common example is a Power over Ethernet (PoE) sourcing device that
provides means for measuring provided power per port. If the device
connected to a port is known, power and energy measurements for that
device can be conducted by the PoE sourcing device. Another example
is a smart power strip. Again, if it is known which devices are
plugged into which outlets of the smart power strip, then the power
strip can provide measured values for these devices.
The second difference is that often it is desirable to apply energy
management also to networks and devices that do not communicate via
IP, for example, in building networks where besides IP several other
communication protocols are used. In these networks, it may be
desirable that devices with IP interfaces report energy and power
values for other devices. Reports may be based on measurements at
the reporting device, similar to the PoE sourcing device and the
smart strip. But reports may also be just relayed from non-IP
communication to IP communication.
2. Scenarios and target devices
This section describes a selection of scenarios for the application
of energy management. For each scenario a list of target devices is
given in the headline, for which IETF energy management standards are
needed.
2.1. Scenario 1: Routers, switches, middleboxes, and hosts
Power management of network devices is considered as a fundamental
(basic first step) requirement. The devices listed in this scenario
are some of the components of a communication network. For these
network devices, the chassis draws power from an outlet and feeds all
its internal sub-components.
Quittek, et al. Expires September 15, 2011 [Page 7]
Internet-Draft Requirements for Energy Management March 2011
2.2. Scenario 2: PoE sourcing equipment and PoE powered devices
This scenario covers devices using Power over Ethernet (PoE). A PoE
Power Sourcing Equipment (PSE), for example, a PoE switch, provides
power to a PoW Powered Device (PD), for example, a PoE desktop phone.
Here, the PSE provides means for controlling power supply (switching
it on and off) and for monitoring actual power provided at a port to
a specific PD.
2.3. Scenario 3: Power probes and Smart meters
Today, very few devices are equipped with sufficient instrumentation
to measure their own actual power and accumulated energy consumption.
Often external probes are connected to the power supply for measuring
these properties for a single device or for a set of devices.
Homes, buildings, and data centers have smart meters that monitor and
report accumulated power consumption of an entire home, a set of
offices or a set of devices in data centers.
Power Distribution Unit (PDUs) attached to racks in data center and
other smart power strips are evolving with smart meters and remote
controllable power switches embedded for each socket.
2.4. Scenario 4: Mid-level managers
Sometimes it is useful to have mid-level managers that provide energy
management functions not just for themselves but also for a set of
associated devices. For example, a switch can provide energy
management functions for all devices connected to its ports, even if
these devices are not PoE PDs, but have their own power supply as,
for example, PCs connected to the switch.
2.5. Scenario 5: Gateways to building networks
Due to the potential energy savings, energy management of buildings
has received significant attention. There are gateway network
elements to manage the multiple components of a building energy
management network Heating Ventilating Air Conditioning (HVAC),
lighting, electrical, fire and emergency systems, elevators etc. The
gateway device provides power monitoring and control function for
other devices in the building network.
2.6. Scenario 6: Home energy gateways
Home energy gateway can be used for energy management of a home.
This gateway can manage the appliances (refrigerator, heating/
cooling, washing machine etc.) and interface with the electrical
Quittek, et al. Expires September 15, 2011 [Page 8]
Internet-Draft Requirements for Energy Management March 2011
grid. The gateway can implement policies based on demand and energy
pricing from the grid.
2.7. Scenario 7: Data center devices
Energy efficiency of data centers has become a fundamental challenges
of data center operation. Energy management is conducted on
different aggregation levels, such as network level, Power
Distribution Unit (PDU) level, and server level.
2.8. Scenario 8: Battery powered devices
Some devices have a battery as a back-up source of power. Given the
finite capacity and lifetime of a battery, means for reporting the
actual charge, age, and state of a battery are required.
2.9. Scenario 9: Ganged outlets on a smart power strip
Some PDUs allow physical entities like outlets to be "ganged"
together as a logical entity for simplified management purposes.
This is particularly useful for servers with multiple power supplies,
where each power supply is connected to a different physical outlet.
Other implementations allow "gangs" to be created based on common
ownership of outlets, such as business units or load shed priority or
other non-physical relationships.
Current implementations allow for an "M-to-N" mapping between outlet
"gangs" and physical outlets. An example of this mapping includes
the following:
Outlet 1 (physical entity)
Outlet 2 (physical entity)
Outlet 3 (physical entity)
Outlet 4 (physical entity)
Outlet Gang A (virtual entity)
Outlet Gang B (virtual entity)
Gang A -> Outlets 1, 2 and 3
Gang B -> Outlets 3 and 4
Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both
"gangs."
Each "Outlet Gang" entity reports the aggregated data from the
individual outlet entities that comprise it and enables a single
point of control for all the individual outlet entities. For
example, turning "Outlet Gang A" to the "off" state would turn
outlets 1, 2, and 3 "off" in some implementations. (The impact of
Quittek, et al. Expires September 15, 2011 [Page 9]
Internet-Draft Requirements for Energy Management March 2011
this action on "Outlet Gang B" is to be defined by the equipment
manufacturer.).
3. Monitoring Requirements
3.1. Granularity of monitoring and control
Often it is desirable to switch off individual components of a device
but not the entire device. The switch may need to continue serving a
few ports (for example, the ports serving an email server or needed
for server backup), but most other ports could be entirely switched
off under some policies (for example at night or the weekend in an
office).
As illustrated by this example, it is often desirable to monitor
power state and energy consumption on a granularity level that is
finer than just the device level. Monitoring should be available for
individual components of devices, such as line cards, processor
cards, hard drives, etc. For example, for IP routers the following
list of views of a router gives an idea of components that
potentially could be monitored and controlled individually:
o Physical view: chassis (or stack), central control engine, line
cards, service cards, etc.
o Component view: CPU, ASICs, fans, power supply, ports (single
ports and port groups), storage and memory
o Feature view: L2 forwarding, L3 routing, security features, load
balancing features, network management, etc.
o Logical view: system, data-plane, control-plane, etc.
o Relationship view: line cards, ports and the correlation between
transmission speed and power consumption, relationship of system
load and total power consumption
Instrumentation for measuring energy consumption of a device is
typically more expensive than instrumentation for retrieving the
devices power state. It may be a reasonable compromise in many cases
to provide power state information for all individually switchable
components of a device separately, while the energy consumption is
only measured for the entire device.
3.2. Remote and Aggregated Monitoring
There are several ways power and energy consumption can be measured
and reported. Measurements can be performed locally at the device
that consumes energy or remotely by a device that has access to the
power supply of another device.
Instrumentation for power and energy measurements at a device
Quittek, et al. Expires September 15, 2011 [Page 10]
Internet-Draft Requirements for Energy Management March 2011
requires additional hardware. A cost-efficient alternative is
measuring power and energy consumption aggregated for a set of
devices, for example a PoE PSE reporting these values per port group
instead of per port, or a power distribution unit that reports the
values for all connected devices instead of per socket.
If aggregated measurement is conducted, it is obvious that reporting
provides aggregated values. but aggregated reporting can also be
combined with local measurements. A managed node may act as mid-
level manager or protocol converter for several devices that measure
power consumption by themselves, for example a home gateway or a
gateway to building networks. In this case, the reporting node may
choose to report for each device individual values or aggregated
values from groups of devices that transmitted their power and energy
consumption values to the reporting node.
Often it is sufficient and more cost efficient having a single device
measuring and providing power state and energy consumption
information not just for itself but also for several further devices
that are in some way attached to it. If the measuring and reporting
device has access to individual power supply lines for each device,
then it can measure energy consumption per device. If it only has
access to a joint power supply for several devices, then it will
measure aggregated values.
One example for the first case is a switch acting as power sourcing
equipment for several IP phones using Power over Ethernet (PoE). The
switch can measure the power consumption for each phone individually
at the port the phone is connected to or it measures aggregated
values per port group for a set of devices.. The phones do not need
to provide means for energy consumption measurement and reporting by
themselves.
Another example is a smart meter that just measures and reports the
energy transmitted through attached electric cables. Such a smart
meter can be used to monitor energy consumption of an individual
device if connected to the devices' individual power supply. But in
many common cases it measures the aggregated energy consumption of
several devices, for example, as part of an uninterruptible power
supply (UPS) that serves several devices at a single power cord, or
as a smart electric meter for a set of machines in a rack, in an
office building or at a residence.
3.3. Accuracy
Depending on how power and energy consumption values are obtained the
confidence in the reported value and its accuracy may vary. Managed
nodes reporting values concerning themselves or other devices should
Quittek, et al. Expires September 15, 2011 [Page 11]
Internet-Draft Requirements for Energy Management March 2011
qualify the confidence in reported values and quantify the accuracy
of measurements. For accuracy reporting, the accuracy classes
specified in IEC 61850 should be considered.
3.4. Required Information
This section lists requirements for information to be retrieved.
Because of the different nature of power state monitoring and energy
consumption monitoring, these are discussed separately. In addition,
a section on battery monitoring is included which again comes with a
set of very different requirements.
Not all of the individual requirements listed in subsections below
are equally relevant. A classification into 'required' and
'optional' is still in progress.
3.4.1. Power State Monitoring
The power state of a device or component typically can only have a
small number of discrete values such as, for example, full power, low
power, standby, hibernating, off. However, some of these states may
have one or more sub-states or state parameters. For example, in low
power state, a reduced clock rate may be set to a large number of
different values. For the device power state, the following
information is considered to be relevant:
o the current state - the time of the last change
o the cause for the last transition
o time to transit from one stage to another
o the total time spent in each state
o the duration of the last period spent in each state
o the number of transitions to each state
o the current power source
For some network management tasks it may be desirable to receive
notifications from devices when components or the entire device
change their power state.
3.4.2. Energy Consumption Monitoring
Independent of the power state, energy consumption of a device or a
device's component is a quantity for which the value may change
continuously. Therefore, the information that needs to be retrieved
concerning this quantity is quite different:
o the current real power (energy consumption rate) averaged over a
short time interval
Quittek, et al. Expires September 15, 2011 [Page 12]
Internet-Draft Requirements for Energy Management March 2011
o total energy consumption
o energy consumption since the last report or for the last
configured time interval
o total energy consumption per power state
o energy consumption per power state since the last report
For some network management tasks it may be desirable to receive
notifications from devices when the current power consumption of a
component or of the entire device exceeds or falls below certain
thresholds.
Energy consumption of a device or a device's component is a quantity
for which the value may change continuously. For some network
management tasks it is required to measure the power over time with a
relatively high time resolution. In such a case not just single
values for the current power of a component is needed, but a series
of power values reporting on consecutive time intervals.
In order to put measured data into perspective, the accuracy of the
measured data, i.e. the potential error in the measured data, needs
to be known as well.
3.4.3. Power Quality
In addition to the quantity of power or energy, also power quality
should be reported according to IEC 62053-22 and IEC 60044-1.
3.4.4. Battery State Monitoring
An increasing number of networked devices are expected to be battery
powered. This includes e.g. smart meters that report meter readings
and are installed in places where external power supply is not always
possible or costly. But also other devices might have internal/
external batteries to power devices for short periods of time when
the main power fails, to power parts of the device when the main
device is switches off etc. Knowing the state of these batteries is
important for the operation of these devices and includes information
such as:
o the current charge of the battery
o the age of the battery
o the state of the battery (e.g. being re-charged)
o last usage of the battery
o maximum energy provided by the battery
It is possible for devices that are only battery-powered to send
notifications when the current battery charge has dropped below a
certain threshold in order to inform the management system of needed
replacement. The same applies for the age of a battery.
An open issue is modeling power states of devices that contain
Quittek, et al. Expires September 15, 2011 [Page 13]
Internet-Draft Requirements for Energy Management March 2011
batteries. These devices can consume energy when turned off or to
sleep mode, because in these modes they still can charge their
batteries. Also thaey can be turned on without consuming any energy
when running on battery. How to model these cases is currently under
discussion in the eman working group. Anyway, it should be avoided
that energy is accounted twice, once when the battery is charged and
once when the device runs on battery.
3.4.5. Multiple Power Sources
Most devices have a single source of power only. But there are
several devices, for example, highly reliable servers, that have two
or more power sources. Dual power supply servers often receive power
from two different PDUs in two different power distribution trees.
Some devices with multiple power sources use only one source at a
time, while others make use of all sources at the same time. In any
case, the total power of the device is given by the sum of power
values at all supply lines of a device. However, in some scenarios
individual reporting per power inlet is required.
4. Monitoring Models
Monitoring of power states and energy consumption can be performed in
pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
[RFC5101]).
The protocol choice for energy monitoring often depends on the
characteristics and requirements of the network management
application. It is important to note that no specific protocol
mechanism has been explicitly mandated as a requirement for energy
monitoring. A discussion of some of the use cases, and possible
protocol candidates that can be considered for monitoring in those
situations are presented.
Pull mode monitoring is often easier to handle for a network
management systems, because it can determine when it gets certain
information from a certain device. However, the overhead of pull
model monitoring is typically higher than for push model monitoring,
particularly when large numbers of values are to be collected, such
as time series of power values.
In such cases, push model monitoring may be preferable with a device
sending a data stream of values without explicit request for each
value from the network management system. For notifications on
events, only the push model is considered to be appropriate.
Quittek, et al. Expires September 15, 2011 [Page 14]
Internet-Draft Requirements for Energy Management March 2011
Applying these considerations to the required information leads to
the conclusion that most of the information can appropriately be
reported using the pull model. The only exceptions are notifications
on power state changes and high volume time series of energy
consumption values.
5. Discovery
In order to measure and monitor the energy consumption of a network
it is important to discover the network elements, the components of
the network elements and the devices attached to the network. Since
the required discovery protocol depends on the environment (full IP
end-to-end devices, 6lowpan environments, non IP end devices,
etc...), the discovery protocol is out of the scope of this
requirement document. Note that there many well-known and widely
deployed protocol options for network discovery for IP networks such
as LLDP. Upon discovery, it must possible to measure the energy
consumption of the entire network, a breakdown of the energy
consumption of the components of the network elements and the energy
consumption of the devices attached to the network.
5.1. Identification
Upon discovery of an entity within the network or attached to the
network, it is important to identify the discovered entity uniquely.
As an energy monitoring requirement, the identity of the discovered
device should be unique within a management domain so that the
correct device is monitored and possibly controlled. In addition to
an unique ID, descriptive tags about the entity can be associated
with the device. It is useful that this unique ID of the device is
linked to the well-deployed MIBs if there exists an index for the
device and the MIB has been implemented on the device. For example,
the linking the unique with the index of the Entity MIB index or the
Power over Ethernet MIB or the LLDP MIB would be useful.
6. Control Requirements
To realize the envisioned benefits of energy savings, just monitoring
power states and energy consumption would not be sufficient. Energy
efficiency can be realized only by setting the network entities or
components to energy saving power states when appropriate.
With means for power state control, energy saving policies and
control loops can be realized. Policies may, for example, define
different power state settings based on the time-of-day. Control
loops may, for example, change power states based on actual network
Quittek, et al. Expires September 15, 2011 [Page 15]
Internet-Draft Requirements for Energy Management March 2011
load.
Trivially, all entities being subject of energy management should
have at least two power states, such as "on" and "off" or "on" and
"sleep" to be set. In many cases, it may be desirable to have more
operational ("on" mode") and non-operational ("off"/"sleep" mode)
power states. This applies particularly to devices with a lot of
configuration parameters that influence their energy consumption.
Examples for specifications of power states of managed devices can be
found in the Advanced Configuration and Power Interface (ACPI)
[ACPI.R30b] or the DMTF Power State Management Profile
[DMTF.DSP1027].
7. Existing Standards
This section analyzes existing standards for energy consumption and
power state monitoring. It shows that there are already several
standards that cover some part of the requirements listed above, but
even all together they do not cover all of the requirements for
energy management.
7.1. Existing IETF Standards
There are already RFCs available that address a subset of the
requirements.
7.1.1. ENTITY MIB
The ENTITY-MIB module defined in [RFC4133] was designed to model
physical and logical entities of a managed system. A physical entity
is an identifiable physical component. A logical entity can use one
or more physical entities. From an energy monitoring perspective of
a managed system, the ENTITY-MIB modeling framework can be reused and
whenever RFC 4133 [RFC4133] has been implemented. The
entPhysicalIndex from entPhysicalTable can be used to identify an
entity/component. However, there are use cases of energy monitoring,
where the application of the ENTITY-MIB does not seem readily
apparent and some of those entities could be beyond the original
scope and intent of the ENTITY-MIB.
Consider the case of remote devices attached to the network, and the
network device could collect the energy measurement and report on
behalf of such attached devices. Some of the remote devices such as
PoE phones attached to a switch port have been considered in the
Power-over-Ethernet MIB module [RFC3621]. However, there are many
other devices such as a computer, which draw power from a wall outlet
or building HVAC devices which seem to be beyond the original scope
Quittek, et al. Expires September 15, 2011 [Page 16]
Internet-Draft Requirements for Energy Management March 2011
of the ENTITY-MIB.
Yet another example, is smart-PDUs, which can report the energy
consumption of the device attached to the power outlet of the PDU.
In some cases, the device can be attached to multiple to power
outlets. Thus, the energy measured at multiple outlets need to be
aggregated to determine the consumption of a single device. From
mapping perspective, between the PDU outlets and the device this is a
many-to-one mapping. It is not clear if such a many-to-one mapping
is feasible within the ENTITY-MIB framework.
7.1.2. ENTITY STATE MIB
RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.
Implementations of this module provide information on entities
including the standby status (hotStandby, coldStandby,
providingService), the operational status (disabled, enabled,
testing), the alarm status (underRepair, critical, major, minor,
warning), and the usage status (idle, active, busy). This
information is already useful as input to policy decisions and for
other network monitoring tasks. However, the number of states would
cover only a small subset of the requirements for power state
monitoring and it does not provide means for energy consumption
monitoring. For associating the provided information to specific
components of a device, the ENTITY STATE MIB module makes use of the
means provided by the ENTITY MIB module [RFC4133]. Particularly, it
uses the entPhysicalIndex for identifying entities.
The standby status provided by the ENTITY STATE MIB module is related
to power states required for energy management, but the number of
states is too restricted for meeting all energy management
requirements. For energy management several more power states are
required, such as different sleep and operational states as defined
by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b]
or the DMTF Power State Management Profile [DMTF.DSP1027].
7.1.3. ENTITY SENSOR MIB
RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.
Implementations of this module offer a generic way to provide data
collected by a sensor. A sensor could be an energy consumption meter
delivering measured values in Watt. This could be used for reporting
current power of a device and its components. Furthermore, the
ENTITY SENSOR MIB can be used to retrieve the accuracy of the used
power meter.
Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module
makes use of the means provided by the ENTITY MIB module [RFC4133]
Quittek, et al. Expires September 15, 2011 [Page 17]
Internet-Draft Requirements for Energy Management March 2011
for relating provided information to components of a device.
However, there is no unit available for reporting energy quantities,
such as, for example, watt seconds or kilowatt hours, and the ENTITY
SENSOR MIB module does not support reporting accuracy of measurements
according to the IEC / ANSI accuracy classes, which are commonly in
use for electric power and energy measurements. The ENTITY SENSOR
MIB modules only provides a coarse-grained method for indicating
accuracy by stating the number of correct digits of fixed point
values.
7.1.4. UPS MIB
RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of
this module provide information on the current real power of devices
attached to an uninterruptible power supply (UPS) device. This
application would require identifying which device is attached to
which port of the UPS device.
UPS MIB provides information on the state of the UPS network. The
MIB module contains several variables identify the UPS entity (name,
model,..), the battery state, to characterize the input load to the
UPS, to characterize the output from the UPS, to indicate the various
alarm events. The measurements of power in UPS MIB are in Volts,
Amperes and Watts. The units of power measurement are RMS volts, RMS
Amperes and are not based on Entity-Sensor MIB [RFC3433].
7.1.5. POWER ETHERNET MIB
Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
module defined in RFC3621 [RFC3621] provide information on the
current energy consumption of the devices that receive Power over
Ethernet (PoE). This information can be retrieved at the power
sourcing equipment. Analogous to the UPS MIB, it is required to
identify which devices are attached to which port of the power
sourcing equipment.
The POWER ETHERNET MIB does not report power and energy consumption
on a per port basis, but can report aggregated values for groups of
ports. It does not use objects of the ENTITY MIB module for
identifying entities, although this module existed already when the
POWER ETHERNET MIB modules was standardized.
7.1.6. LLDP MED MIB
The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a
data link layer protocol used by network devices for advertising of
their identities, capabilities, and interconnections on a LAN
Quittek, et al. Expires September 15, 2011 [Page 18]
Internet-Draft Requirements for Energy Management March 2011
network. The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an
enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements
specifically address voice applications. LLDP-MED covers 6 basic
areas: capabilities discovery, LAN speed and duplex discovery,
network policy discovery, location identification discovery,
inventory discovery, and power discovery.
7.2. Existing standards of other bodies
7.2.1. DMTF
The DMTF has defined a power state management profile [DMTF.DSP1027]
that is targeted at computer systems. It is based on the DMTF's
Common Information Model (CIM) and rather a device profile than an
actual energy consumption monitoring standard.
The power state management profile is used to describe and to manage
the power state of computer systems. This includes e.g. means to
change the power state of a device (e.g. to shutdown the device)
which is an aspect of but not sufficient for active energy
management.
8. Acknowledgements
The authors would like to thank Ralf Wolter for his first essay on
this draft. Many thanks to William Mielke for helpful comments on
the draft and Juergen Schoenwaelder for stimulating discussions on
use of ENTITY-MIB and thanks Chris Verges for suggesting the PDU
usecase of a device with multiple power sources.
9. Security Considerations
The typical security threats for the management protocol for energy
monitoring are similar to the ones specified in the SNMP security
framework. In other words, from an energy monitoring point of view,
no additional security requirements have been imposed.
Link layer discovery mechanisms need to ensure that only the trusted
entities shall be discovered during discovery and detect/discard
devices without a trusted relationship to be included among the
devices for energy monitoring.
In terms of monitoring, considering that there can be some network
entities which shall be entitled to collect the measured data on
behalf of other devices, then it is important to authenticate and/or
authorize such devices. In addition, in the case of control of other
Quittek, et al. Expires September 15, 2011 [Page 19]
Internet-Draft Requirements for Energy Management March 2011
devices, it would be highly desirable to have some form of an
authentication mechanism to ensure that only the designated devices
shall control the devices within its control domain. It should be
possible to prevent designated devices contolling devices not present
in its control domain/purview. Secondly, it should be possible to
prevent malicious network devices exercising control over network
devices.
10. IANA Considerations
This memo has no actions for IANA..
11. Informative References
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
November 2005.
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB",
RFC 3621, December 2003.
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628,
May 1994.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
Management Information Base", RFC 3433, December 2002.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[ACPI.R30b]
Hewlett-Packard Corporation, Intel Corporation, Microsoft
Corporation, Phoenix Corporation, and Toshiba Corporation,
"Advanced Configuration and Power Interface Specification,
Revision 3.0b", October 2006.
[DMTF.DSP1027]
Quittek, et al. Expires September 15, 2011 [Page 20]
Internet-Draft Requirements for Energy Management March 2011
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
"Power State Management Profile", September 2008.
Authors' Addresses
Juergen Quittek (editor)
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-115
Email: quittek@neclab.eu
Rolf Winter
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-121
Email: Rolf.Winter@neclab.eu
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-128
Email: Thomas.Dietz@neclab.eu
Quittek, et al. Expires September 15, 2011 [Page 21]
Internet-Draft Requirements for Energy Management March 2011
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
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
Quittek, et al. Expires September 15, 2011 [Page 22]
