Requirements for Energy Management
draft-ietf-eman-requirements-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6988.
|
|
|---|---|---|---|
| Authors | Juergen Quittek , Rolf Winter , Thomas Dietz , Benoît Claise , Mouli Chandramouli | ||
| Last updated | 2012-03-13 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Dan Romascanu | ||
| IESG | IESG state | Became RFC 6988 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-eman-requirements-06
Network Working Group J. Quittek, Ed.
Internet-Draft R. Winter
Intended status: Informational T. Dietz
Expires: September 12, 2012 NEC Europe Ltd.
B. Claise
M. Chandramouli
Cisco Systems, Inc.
March 12, 2012
Requirements for Energy Management
draft-ietf-eman-requirements-06
Abstract
This document defines requirements for standards specifications for
energy management. The requirements defined in this document concern
monitoring functions as well as control functions. In detail, the
focus of the requirements is on the following features:
identification of powered entities, monitoring of their power state,
power inlets, power outlets, actual power, power properties, consumed
energy, and contained batteries. Further requirements are included
to enable control of powered entities' power supply and power state.
This document does not specify the features that must be implemented
by compliant implementations but rather features that must be
supported by standards for energy management.
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 14, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Quittek, et al. Expires September 14, 2012 [Page 1]
Internet-Draft Requirements for Energy Management March 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventional requirements for energy management . . . . . 5
1.2. Specific requirements for energy management . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. General Considerations Related to Energy Management . . . . . 6
3.1. Power states . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Saving energy versus maintaining service level
agreements . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Local versus network-wide energy management . . . . . . . 7
3.4. Energy monitoring versus energy saving . . . . . . . . . . 7
3.5. Overview of energy management requirements . . . . . . . . 8
4. Identification of Powered Entities . . . . . . . . . . . . . . 8
5. Information on Powered Entities . . . . . . . . . . . . . . . 9
5.1. General information on Powered Entities . . . . . . . . . 10
5.2. Power interfaces . . . . . . . . . . . . . . . . . . . . . 10
5.3. Power . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Power state . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. Battery state . . . . . . . . . . . . . . . . . . . . . . 16
5.7. Time series of measured values . . . . . . . . . . . . . . 18
6. Control of Powered Entities . . . . . . . . . . . . . . . . . 19
7. Reporting on other Powered Entities . . . . . . . . . . . . . 20
8. Controlling Other Powered Entities . . . . . . . . . . . . . . 21
8.1. Controlling power states of other Powered Entities . . . . 21
8.2. Controlling power supply . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Quittek, et al. Expires September 14, 2012 [Page 2]
Internet-Draft Requirements for Energy Management March 2012
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Standards for DC power characteristics? . . . . . . . . . 23
12.2. Directional metering of Power and Energy . . . . . . . . . 23
12.3. Drop requirements for Impedance and THD? . . . . . . . . . 23
12.4. Rime intervals for energy measurements . . . . . . . . . . 23
12.5. Reporting on other devices . . . . . . . . . . . . . . . . 23
13. Informative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Existing Standards . . . . . . . . . . . . . . . . . 25
A.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 26
A.1.1. ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 26
A.1.2. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 26
A.1.3. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 27
A.1.4. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 27
A.1.5. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 28
A.1.6. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 28
A.2. Existing standards of other bodies . . . . . . . . . . . . 28
A.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.2. OVDA . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2.3. IEEE-ISTO Printer WG . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Quittek, et al. Expires September 14, 2012 [Page 3]
Internet-Draft Requirements for Energy Management March 2012
1. Introduction
With rising energy cost and with an increasing awareness of the
ecological impact of running IT equipment, energy management is
becoming an additional basic requirement for network devices and
associated network management systems.
This document defines requirements for standards specifications for
energy management, both monitoring functions and control functions.
In detail, the requirements listed are focused on the following
features: identification of powered entities, monitoring of their
power state, power inlets, power outlets, actual power, power
properties, consumed energy, and contained batteries. Further
included is control of powered entities' power supply and power
state.
The main subject of energy management is powered entities that
consume electric energy. Powered entities include devices that have
an IP address and can be addressed directly, such as hosts, routers,
and middleboxes, as well as devices indirectly connected to an IP
network, for which a proxy with an IP address provides a management
interface, for example, devices in building infrastructure using
non-IP protocols.
These requirements concern the standards specification process and
not the implementation of specified standards. All requirements in
this document must be reflected by standards specifications to be
developed. However, which of the features specified by these
standards will be mandatory, recommended, or optional for compliant
implementations is to be defined by standards track document(s) and
not in this document.
Section 3 elaborates a set of general needs for energy management.
Requirements for an energy management standard are specified in
Sections 4 to 8.
Sections 4 to 6 contain conventional requirements specifying
information on powered entities and control functions.
Sections 7 and 8 contain requirements specific to energy management.
Due to the nature of power supply, some monitoring and control
functions are not conducted by interacting with the powered entity of
interest, but with other entities, for example, entities upstream in
a power distribution tree.
Quittek, et al. Expires September 14, 2012 [Page 4]
Internet-Draft Requirements for Energy Management March 2012
1.1. Conventional requirements for energy management
The specification of requirements for an energy management standard
starts with Section 4 addressing the identification of powered
entities and the granularity of reporting of energy-related
information. A standard must support unique identification of
powered entities, reporting per entire powered device, and reporting
energy-related information on individual components of a device or
subtended devices. This is why this draft uses the more general term
"powered entity" rather than "powered device"; a powered entity may
be a device or a component of a device.
Section 5 specifies requirements related to monitoring of powered
entities. This includes general (type, context) information and
specific information on power states, power inlets, power outlets,
power, energy, and batteries. Control power state and power supply
of powered entities is covered by requirements specified in
Section 6.
1.2. Specific requirements for energy management
While the conventional requirements summarized above seem to be all
that would be needed for energy management, there are significant
differences between energy management and most well known network
management functions. The most significant difference is the need
for some devices to report on other entities. There are three major
reasons for this.
o For monitoring a particular powered entity it is not always
sufficient to communicate with the powered entity only. When the
powered entity has no instrumentation for determining power, it
might still be possible to obtain power values for the entity by
communication with other entities in its power distribution tree.
A simple example is retrieving power values from a power meter at
the power line into the powered entity. Common examples are a
Power Distribution Unit (PDU) and a Power over Ethernet (PoE)
switch. Both supply power to other entities at sockets or ports,
respectively, and are often instrumented to measure power per
socket or port.
o Similar considerations apply to controlling power supply of a
powered entity which often needs direct or indirect communications
with another entity upstream in the power distribution tree.
Again, a PDU and a PoE switch are common examples, if they have
the capability to switch on or off power at their sockets or
ports, respectively.
o Energy management often extends beyond entities with IP network
interfaces, to non-IP building systems accessed via a gateway.
Requirements in this document do not cover details of these
networks, but specify means for opening IP network management
Quittek, et al. Expires September 14, 2012 [Page 5]
Internet-Draft Requirements for Energy Management March 2012
towards them.
o For monitoring powered entities, as their number becomes large, it
is sometimes not a scalable approach to communicate directly with
all powered entities directly from a central energy management
system.
This specific issue of energy management and a set of further ones
are covered by requirements specified in Sections 7 and 8.
The requirements in these sections need a new energy management
framework that deals with the specific nature of energy management.
The actual standards documents, such as MIB module specifications,
address conformance by specifying which feature must, should, or may
to be implemented by compliant implementations.
2. Terminology
Terminology to be used by the eman WG is currently discussed in
[I-D.parello-eman-definitions]. After final definitions of terms
have been agreed, those definitions will be listed here.
3. General Considerations Related to Energy Management
The basic objective of energy management is operating sets of devices
with minimal energy, while maintaining a certain level of service.
Use cases for energy management can be found in
[I-D.ietf-eman-applicability-statement].
3.1. Power states
Powered entities can be set to an operational state that results in
the lowest energy consumption level that still meets the service
level performance objectives. In principle, there are four basic
types of power states for a powered entity or for a whole system:
o full power state
o reduced power states (e.g. lower clock rate for processor, lower
data rate on a link, etc.)
o sleep state (not functional, but immediately available)
o off state (may require significant time to become operational)
In specific devices, the number of power states and their properties
varies considerably. Simple powered entities may just have only the
extreme states, full power and off state. Many devices have three
basic power states: on, off, and sleep. However, more finely grained
power states can be implemented with many levels of each power
states.
Quittek, et al. Expires September 14, 2012 [Page 6]
Internet-Draft Requirements for Energy Management March 2012
3.2. Saving energy versus maintaining service level agreements
While the general objective of energy management is quite clear, the
way to attain that goal is often difficult. In many cases there is
no way of reducing power consumption without the consequence of a
potential performance, service, or capacity degradation. Then a
trade-off needs to be dealt with between service level objectives and
energy minimization. In other cases a reduction of energy
consumption can easily be achieved while still maintaining sufficient
service level performance, for example, by switching powered entities
to lower power states when higher performance is not needed.
3.3. Local versus network-wide energy management
Many energy saving functions are executed locally by a powered
entity; it monitors its usage and dynamically adapts its energy
consumption according to the required performance. It may, for
example, switch to a sleep state when it is not in use or out of
scheduled business hours. An energy management system may observe an
entity's power state and configure its power saving policies.
Energy savings can also be achieved with policies implemented by a
network management system that controls power states of managed
entities. Information about the energy consumption of powered
entities in different power states may be required to set policy.
Often this information is acquired best through monitoring.
Both methods, network-wide and local energy management, have
advantages and disadvantages and often it is desirable to combine
them. Central management is often favorable for setting power states
of a large number of entities at the same time, for example, at the
beginning and end of business hours in a building. Local management
is often preferable for power saving measures based on local
observations, such as high or low load of an entity.
3.4. Energy monitoring versus energy saving
Monitoring energy consumption and power states alone does not reduce
the energy consumption of a powered entity. In fact, it may increase
the power consumption slightly due to monitoring instrumentation that
consumes energy. Reporting measured quantities over the network may
also increase energy use, though the acquired information may be an
essential input to control loops that save energy.
Monitoring power states and energy consumption can also be required
for other purposes including:
Quittek, et al. Expires September 14, 2012 [Page 7]
Internet-Draft Requirements for Energy Management March 2012
o investigating energy saving potential
o evaluating the effectiveness of energy saving policies and
measures
o deriving, implementing, and testing power management strategies
o accounting for the total power consumption of a powered entity, a
network, or a service
o predicting a powered entity's reliability based on power usage
o choosing time of next maintenance cycle for a powered entity
3.5. Overview of energy management requirements
The following basic management functions are required:
o monitoring power states
o monitoring power (energy consumption rate)
o monitoring (accumulated) energy consumption
o monitoring power properties
o setting power states
o setting and enforcing power saving policies
Power control is complementary to other energy savings measures such
as low power electronics, energy saving protocols , energy-efficient
device design (for example, low-power modes for components), and
energy-efficient network architectures. Measurement of energy
consumption can provide useful data for developing these
technologies.
4. Identification of Powered Entities
Powered entities must be uniquely identified. This includes entities
that are components of managed devices and in case that one powered
entity reports information on another one, see Section 7. For
powered entities that control other powered entities it is important
to identify the powered entities they control, see Section 8.
An entity may be an entire device or a component of it. Examples of
components of interest are a hard drive, a battery, or a line card.
It may be required to be able to control individual components to
save energy. For example, server blades can be switched off when the
overall load is low or line cards at switches may be powered down at
night.
Identifiers for devices and components are already defined in
standard MIB modules, such as the LLDP MIB module [IEEE-802.1AB] and
the LLDP-MED MIB module [ANSI-TIA-1057] for devices and the Entity
MIB module [RFC4133] and the Power Ethernet MIB [RFC3621] for
components of devices. Energy management needs means to link energy-
related information to such identifiers.
Quittek, et al. Expires September 14, 2012 [Page 8]
Internet-Draft Requirements for Energy Management March 2012
Instrumentation for measuring energy consumption of a device is
typically more expensive than instrumentation for retrieving its
power state. Many devices may provide power state information for
all individual components separately, while reporting the energy
consumption only for the entire device.
4.1. Identifying powered entities
The standard must provide means for uniquely identifying powered
entities. Uniqueness must be preserved in a domain that is large
enough to avoid collisions of identities at potential receivers of
monitored information.
4.2. Identifying components of powered devices
The standard must provide means for identifying not just entire
devices as powered entities, but also individual components.
4.3. Persistence of identifiers
The standard must provide means for indicating whether identifiers of
powered entities are persistent across a re-start of the powered
entity.
4.4. Using entity identifiers of other MIB modules
The standard must provide means for re-using entity identifiers from
other standards including at least the following:
o the entPhysicalIndex in the Entity MIB module [RFC4133]
o the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
the LLDP-MED MIB module [ANSI-TIA-1057]
o the pethPsePortIndex and the pethPsePortGroupIndex in the Power
Ethernet MIB [RFC3621]
Generic means for re-using other entity identifiers must be provided.
5. Information on Powered Entities
This section describes information on powered entities for which the
standard must provide means for retrieving and reporting.
Required information can be structured into six groups. Section 5.1
specifies requirements for general information on powered entities,
such as type of powered entity or context information. Section 5.4
covers requirements related to entities' power states. Requirements
for information on power inlets and power outlets of powered entities
are specified in Section 5.2. Monitoring of power and energy is
covered by Sections 5.3 and 5.5, respectively. Section 5.6 specifies
Quittek, et al. Expires September 14, 2012 [Page 9]
Internet-Draft Requirements for Energy Management March 2012
requirements for monitoring batteries. Finally, the reporting of
time series of values is covered by Section 5.7.
5.1. General information on Powered Entities
For energy management it may be required to understand the role and
context of a powered entity. An energy management system may
aggregate energy consumption according to a defined grouping of
entities. When controlling and setting power states it may be
helpful to understand the grouping of the entity and role of a
powered entity in a network, for example, it may be important to
exclude some vital network devices from being switched to lower power
or even from being switched off.
5.1.1. Type of powered entity
The standard must provide means to configure, retrieve and report a
textual name or a description of a powered entity.
5.1.2. Context information on powered entities
The standard must provide means for retrieving and reporting context
information on powered entities, for example, tags associated with a
powered entity that indicate the powered entity's role or importance.
5.1.3. Power priority
The standard must provide means for retrieving and reporting power
priorities of powered entities. Power priorities indicate an order
in which power states of powered entities are changed, for example,
to lower power states for saving power.
5.1.4. Grouping of powered entities
The standard must provide means for grouping powered entities, for
example, into energy monitoring domains, energy control domains,
power supply domains, groups of powered entities of the same type,
etc.
5.2. Power interfaces
A power interface is either an inlet or an outlet. A few switch
between these two but most never change.
Powered entities have power inlets at which they are supplied with
electric power. Most powered entities have a single power inlet,
while some have multiple inlets. Different power inlets on a device
are often connected to separate power distribution trees. For energy
Quittek, et al. Expires September 14, 2012 [Page 10]
Internet-Draft Requirements for Energy Management March 2012
monitoring, it is useful to retrieve information on the number of
inlets of a powered entity, the availability of power at inlets and
which of them are actually in use.
Powered entities can have one or more power outlets for supplying
other powered entities with electric power.
For identifying and potentially controlling the source of power
received at an inlet, it may be required to identify the power outlet
of another powered entity at which the received power is provided.
Analogously, for each outlet it is of interest to identify the power
inlets that receive the power provided at a certain outlet. Such
information is also required for constructing the wiring topology of
electrical power distribution to powered entities.
Static properties of each power interface are required information
for energy management. Static properties include the kind of
electric current (AC or DC), the nominal voltage, the nominal AC
frequency, and the number of AC phases.
5.2.1. Lists of power interfaces
The standard must provide means for monitoring the list of power
interfaces.
5.2.2. Corresponding power outlet
The standard must provide means for identifying the power outlet that
provides the power received at a power inlet.
5.2.3. Corresponding power inlets
The standard must provide means for identifying the list of power
inlets that receive the power provided at a power outlet.
5.2.4. Availability of power
The standard must provide means for monitoring the availability of
power at each power interface. This indicates whether at a power
interfaces power supply is switched on or off.
5.2.5. Use of power
The standard must provide means for monitoring for each power
interfaces if it is in actual use. For inlets this means that the
powered entity actually receives power at the inlet. For outlets
this means that power is actually provided from it to one or more
powered entities.
Quittek, et al. Expires September 14, 2012 [Page 11]
Internet-Draft Requirements for Energy Management March 2012
5.2.6. Type of current
The standard must provide means for reporting the type of current (AC
or DC) for each power interface.
5.2.7. Nominal voltage
The standard must provide means for reporting the nominal voltage for
each power interface.
5.2.8. Nominal AC frequency
The standard must provide means for reporting the nominal AC
frequency for each power interface.
5.2.9. Number of AC phases
The standard must provide means for reporting the number of AC phases
for each power interface.
5.3. Power
Power is measured as an instantaneous value or as the average over a
time interval.
Obtaining highly accurate values for power and energy may be costly
if it requires dedicated metering hardware. Powered entities without
the ability to measure their power and energy consumption with high
accuracy may just report estimated values, for example based on load
monitoring or even just the entity type.
Depending on how power and energy consumption values are obtained,
the confidence in the reported value and its accuracy will vary.
Powered entities reporting such values should qualify the confidence
in the reported values and quantify the accuracy of measurements.
For reporting accuracy, the accuracy classes specified in IEC
62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be
considered.
Further properties of the supplied power are also of interest. For
AC power supply, power attributes beyond the real power to be
reported include the apparent power, the reactive power, and the
phase angle of the current or the power factor. For both AC and DC
power the power characteristics are also subject of monitoring.
Power parameters include the actual voltage, the actual frequency,
the Total Harmonic Distortion (THD) of voltage and current, the
impedance of an AC phase or of the DC supply. Power monitoring
should be in line with existing standards, such as [IEC.61850-7-4].
Quittek, et al. Expires September 14, 2012 [Page 12]
Internet-Draft Requirements for Energy Management March 2012
For some network management tasks it is desirable to receive
notifications from powered entities when their power value exceeds or
falls below given thresholds.
5.3.1. Real power
The standard must provide means for reporting the real power for each
power interface, including the direction of power flow.
5.3.2. Power measurement interval
The standard must provide means for reporting the corresponding time
or time interval for which a power value is reported. The power
value can be measured at the corresponding time or averaged over the
corresponding time interval.
5.3.3. Power measurement method
The standard must provide means to indicating the method how these
values have been obtained. Based on how the measurement was
obtained, it is possible to associate a certain degree of confidence
on the reported power value. For example, there are methods of
measurement such as direct power measurement, or by estimation based
on performance values, or hard coding average power values for a
powered entity.
5.3.4. Accuracy of power and energy values
The standard must provide means for reporting the accuracy of
reported power and energy values.
5.3.5. Actual voltage and current
The standard must provide means for reporting the actual voltage and
actual current for each power interface. In case of AC power supply,
means must be provided for reporting the actual voltage and actual
current per phase.
5.3.6. High/low power notifications
The standard must provide means for creating notifications if power
values of a powered entity rise above or fall below given thresholds.
5.3.7. Complex power
The standard must provide means for reporting the complex power for
each power interface. Besides the real power, at least two out of
the following three quantities need to be reported: apparent power,
Quittek, et al. Expires September 14, 2012 [Page 13]
Internet-Draft Requirements for Energy Management March 2012
reactive power, phase angle. The phase angle can be substituted by
the power factor. In case of AC power supply, means must be provided
for reporting the complex power per phase.
5.3.8. Actual AC frequency
The standard must provide means for reporting the actual AC frequency
for each power interface.
5.3.9. Total harmonic distortion
The standard must provide means for reporting the Total Harmonic
Distortion (THD) of voltage and current for each power interface. In
case of AC power supply, means must be provided for reporting the THD
per phase.
5.3.10. Power supply impedance
The standard must provide means for reporting the impedance of power
supply for each power interface. In case of AC power supply, means
must be provided for reporting the impedance per phase.
5.4. Power state
Many powered entities have a limited number of discrete power states.
There is a need to report the actual power state of a powered entity,
and means for retrieving the list of all supported power states.
Different standards bodies have already defined sets of power states
for some powered entities, and others are creating new power state
sets. In this context, it is desirable that the standard support
many of these power state standards. In order to support multiple
management systems possibly using different power state sets, while
simultaneously interfacing with a particular powered entity, the
energy management standard must provide means for supporting multiple
power state sets used simultaneously at a powered entity.
Power states have parameters that describe its properties. It is
required to have standardized means for reporting some key
properties, such as average power and maximum power of a powered
entity in a certain state.
There also is a need to report statistics on power states including
the time spent and the energy consumed in a power state.
Quittek, et al. Expires September 14, 2012 [Page 14]
Internet-Draft Requirements for Energy Management March 2012
5.4.1. Actual power state
The standard must provide means for reporting the actual power state
of a powered entity.
5.4.2. List of supported power states
The standard must provide means for retrieving the list of all
potential power states of a powered entity.
5.4.3. Multiple power state sets
The standard must provide means for supporting multiple power state
sets simultaneously at a powered entity.
5.4.4. List of supported power state sets
The standard must provide means for retrieving the list of all power
state sets supported by a powered entity.
5.4.5. List of supported power states within a set
The standard must provide means for retrieving the list of all
potential power states of a powered entity for each supported power
state set.
5.4.6. Maximum and average power per power state
The standard must provide means for retrieving the maximum power and
the average power for each supported power state. These values may
be static.
5.4.7. Power state statistics
The standard must provide means for monitoring statistics per power
state including the total time spent in a power state, the number of
times each state was entered and the last time each state was
entered. More power state statistics are addressed by requirement
5.5.3.
5.4.8. Power state changes
The standard must provide means for generating a notification when
the actual power state of a powered entity changes.
Quittek, et al. Expires September 14, 2012 [Page 15]
Internet-Draft Requirements for Energy Management March 2012
5.5. Energy
Monitoring of electrical energy received or provided by a powered
entity is a core function of energy management. Since energy is an
accumulated quantity, it is always reported for a certain interval of
time. This can be, for example, the time from the last restart of
the powered entity to the reporting time, the time from another past
event to the reporting time, the last given amount of time before the
reporting time, or a certain interval specified by two time stamps in
the past.
It is useful for powered entities to record their energy consumption
per power state and report these quantities.
5.5.1. Energy
The standard must provide means for reporting the energy consumed or
produced of a powered entity. The standard must also provide the
means to report the energy passing through each power interface.
Reports should clearly specify the time interval for the energy
measurement.
5.5.2. Time intervals
The standard must provide means for reporting the consumed energy of
a powered entity for specified time intervals.
o Reports must be supported for the time interval starting at the
last restart of the powered entity and ending at a certain point
in time, such as the time when a report was delivered.
o Reports must be supported for a sequence of consecutive non-
overlapping time intervals of fixed size (periodic reports).
o Reports must be supported for a sequence of consecutive
overlapping time intervals of fixed size (periodic reports).
o Reports must be supported for an interval of given length ending
at a certain point in time, such as the time when a report was
delivered (sliding window)
5.5.3. Energy per power state
The standard must provide means for reporting the consumed energy
individually for each power state. This extends the requirement
5.4.7 on power state statistics.
5.6. Battery state
Many powered entities contain batteries that supply them with power
when disconnected from electrical power distribution grids. The
status of these batteries is typically controlled by automatic
Quittek, et al. Expires September 14, 2012 [Page 16]
Internet-Draft Requirements for Energy Management March 2012
functions that act locally on the powered entity and manually by
users of the powered entity. There is a need to monitor the battery
status of these entities by network management systems.
Devices containing batteries can be modeled in two ways. The entire
device can be modeled as a single powered entity on which energy-
related information is reported or the battery can be modeled as an
individual powered entity for which energy-related information is
monitored individually according to requirements in Sections 5.1 to
5.5.
Further information on batteries is of interest for energy
management, such as the current charge of the battery, the number of
completed charging cycles, the charging state of the battery, and
further static and dynamic battery properties. It is desirable to
receive notifications if the charge of a battery becomes very low or
if a battery needs to be replaced.
5.6.1. Battery charge
The standard must provide means for reporting the current charge of a
battery.
5.6.2. Battery charging state
The standard must provide means for reporting the charging state
(charging, discharging, etc.) of a battery.
5.6.3. Battery charging cycles
The standard must provide means for reporting the number of completed
charging cycles of a battery.
5.6.4. Actual battery capacity
The standard must provide means for reporting the actual capacity of
a battery.
5.6.5. Static battery properties
The standard must provide means for reporting static properties of a
battery, including the nominal capacity, the number of cells, the
nominal voltage, and the battery technology.
5.6.6. Low battery charge notification
The standard must provide means for generating a notification when
the charge of a battery decreases below a given threshold.
Quittek, et al. Expires September 14, 2012 [Page 17]
Internet-Draft Requirements for Energy Management March 2012
5.6.7. Battery replacement notification
The standard must provide means for generating a notification when
the number of charging cycles of battery exceeds a given threshold.
5.6.8. Multiple batteries
The standard must provide means for meeting requirements 5.6.1 to
5.6.7 for each individual battery contained in a single powered
entity.
5.7. Time series of measured values
For some network management tasks, it is required to obtain time
series of measured values, such as power, energy, battery charge,
etc.
In general these could be obtained in many different ways. It should
be avoided that such time series can only be obtained through regular
polling by the energy management system. Means should be provided to
either push such values from the location where they are available to
the management system or to have them stored locally for a
sufficiently long period of time such that a management system can
retrieve full time series.
While there is a common understanding that support for reporting of
time series is needed, there is no clear agreement on four issues:
1. Which quantities should be reported?
2. Which time interval type should be used (total, delta, sliding
window)?
3. Which measurement method should be used (sampled, continuous)?
4. Which reporting model should be used (push or pull)?
The most discussed and probably most needed quantities are power and
energy. But a need for others, for example, battery charge can be
identified as well.
There are three time interval types under discussion for accumulated
quantities such as energy. They can be reported as total values,
accumulated between the last restart of the measurement and a certain
timestamp. Alternatively, they can be reported as delta values
between two consecutive timestamps. Another alternative is reporting
values for sliding windows as specified in [IEC.61850-7-4].
For non-accumulative quantities, such as power, different measurement
methods are considered. Such quantities can be reported using values
sampled at certain time stamps or alternatively by mean values for
these quantities averaged between two (consecutive) time stamps or
Quittek, et al. Expires September 14, 2012 [Page 18]
Internet-Draft Requirements for Energy Management March 2012
over a sliding window.
Finally, time series can be reported using different reporting
models, particularly push-based or pull-based. Push-based reporting
can, for example, be realized by reporting power or energy values
using the IPFIX protocol [RFC5101],[RFC5102]. SNMP [RFC3411] is an
example for a protocol that can be used for realizing pull-based
reporting of time series.
All these issues are not clear at the time this document is written.
If practical experiences with the energy management standard to be
defined will be available, they may help reducing the large number of
choices and identifying and specifying commonly shared requirements
for reporting time series of energy-related quantities in a future
revision of this document.
6. Control of Powered Entities
Many powered entities control their power state locally. Other
powered entities without that capability need interfaces for an
energy management system to control their power states. Even for
self-managed powered entities such interfaces may be required for
configuring local policy parameters and for overruling local policy
decisions by global ones.
Power supply is typically not self-managed by powered entities. And
controlling power supply is typically not conducted as interaction
between energy management system and the powered entity itself. It
is rather an interaction between the management system and an entity
providing power at its power outlets. Similar to power state
control, power supply control may be policy driven. Note that
shutting down the power supply abruptly may have severe consequences
for the powered entity.
6.1. Controlling power states
The standard must provide means for setting power states of powered
entities.
6.2. Controlling power supply
The standard must provide means for switching power supply off or
turning power supply on at power outlets providing power to one or
more powered entity.
Quittek, et al. Expires September 14, 2012 [Page 19]
Internet-Draft Requirements for Energy Management March 2012
7. Reporting on other Powered Entities
As discussed in Section 5, not all energy-related information may be
available at the concerned powered entity. Such information may be
provided by other powered entities. This section covers reporting of
information only. See Section 8 for requirements on controlling
other powered entities.
There are cases where a power supply unit switches power for several
powered entities by turning power on or off at a single power outlet
or where a power meter measures the accumulated power of several
powered entities at a single power line. Consequently, it should be
possible to report that a monitored value does not relate to just a
single powered entity, but is an accumulated value for a set of
powered entities. All of these powered entities belonging to that
set need to be identified.
If a powered entity has information about where energy-related
information on itself can be retrieved, then it would be useful to
communicate this information. This applies even if the information
only provides accumulated quantities for several powered entities.
7.1. Reports on other powered entities
The standard must provide means for a powered entity to report
information on another powered entity.
7.2. Identity of other powered entities on which is reported
For entities that report on one or more other entities, the standard
must provide means for reporting the identity of other powered
entities on which information is reported.
7.3. Reporting quantities accumulated over multiple powered entities
The standard must provide means for reporting the list of all powered
entities from which contributions are included in an accumulated
value.
7.4. List of all powered entities on which is reported
For entities that report on one or more other entities, the standard
must provide means for reporting the complete list of all those
powered entities on which energy-related information can be reported.
Quittek, et al. Expires September 14, 2012 [Page 20]
Internet-Draft Requirements for Energy Management March 2012
7.5. Content of reports on other powered entities
For entities that report on one or more other entities, the standard
must provide means for indicating which energy-related information
can be reported for which of those powered entities.
7.6. Indicating source of remote information
For an entity that has one or more other entities reporting on its
behalf, the standard must provide means for the entity to to indicate
which information is available at which other entity.
7.7. Indicating content of remote information
For an entity that has one or more other entities reporting on its
behalf, the standard must provide means for indicating the content
that other designated entities can report on it.
8. Controlling Other Powered Entities
This section specifies requirements for controlling power states and
power supply of powered entities by communicating with other powered
entities that have means for controlling power state or power supply
of others.
8.1. Controlling power states of other Powered Entities
Some powered entities have control of power states of other powered
entities. For example a gateway to a building system may have means
to control the power state of powered entities in the building that
do not have an IP interface. For this scenario and other similar
cases means are needed to make this control accessible to the energy
management system.
In addition to this, it is required that a powered entity that has
its state controlled by other powered entities has means to report
the list of these other powered entities.
8.1.1. Control of power states of other Powered Entities
The standard must provide means for an energy management system to
send power state control commands to a powered entity that concern
the power states of other powered entities than the one the command
was sent to.
Quittek, et al. Expires September 14, 2012 [Page 21]
Internet-Draft Requirements for Energy Management March 2012
8.1.2. Identity of other power state controlled entities
The standard must provide means for reporting the identities of the
powered entities for which reporting powered entity has means to
control their power states.
8.1.3. List of all power state controlled entities
The standard must provide means for a powered entity to report the
list of all powered entities for which it can control the power
state.
8.1.4. List of all power state controllers
The standard must provide means for a powered entity that receives
commands controlling its power state from other powered entities to
report the list of all those entities.
8.2. Controlling power supply
Some powered entities may have control of the power supply of other
powered entities, for example, because the other powered entity is
supplied via a power outlet of the powered entity. For this and
similar cases means are needed to make this control accessible to the
energy management system. This need is already addressed by
requirement 6.2.
In addition, it is required that a powered entity that has its supply
controlled by other powered entities has means to report the list of
these other powered entities. This need is already addressed by
requirements 5.2.2 and 5.2.3.
9. Security Considerations
Controlling power state and power supply of powered entities are
highly sensitive actions since they can significantly affect the
operation of directly and indirectly affected devices. Therefore all
control actions addressed in 6 and 8 must be sufficiently protected
through authentication, authorization, and integrity protection
mechanisms.
Monitoring energy-related quantities of a powered entity addressed in
Sections 5 - 8 can be used to derive more information than just the
consumed power, so monitored data requires privacy protection.
Monitored data may be used as input to control, accounting, and other
actions, so integrity of transmitted information and authentication
of the origin may be needed.
Quittek, et al. Expires September 14, 2012 [Page 22]
Internet-Draft Requirements for Energy Management March 2012
9.1. Secure energy management
The standard must provide privacy, integrity, and authentication
mechanisms for all actions addressed in Sections 5 - 8. The security
mechanisms must address all threats listed in Section 1.4 of
[RFC3411].
10. IANA Considerations
This document has no actions for IANA.
11. Acknowledgements
The authors would like to thank Ralf Wolter for his first essay on
this draft. Many thanks to William Mielke, John Parello, Bruce
Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff
for helpful comments on the draft.
12. Open issues
12.1. Standards for DC power characteristics?
Is there a standard on DC power characteristics? Would they be
needed for EMAN?
12.2. Directional metering of Power and Energy
Still not covered consistently.
12.3. Drop requirements for Impedance and THD?
YCM === I am not certain we need this requirement. I understand the
point a requirement need not be implemented. My contention impedance
and THD are not necessary for EMAN.
12.4. Rime intervals for energy measurements
After the requirements on time series have been dropped, requirement
5.5.2 on time intervals for energy measurements may have to be
revised.
12.5. Reporting on other devices
This needs to be considered whether it is devices or interfaces or
entities that are to be reported on.
Quittek, et al. Expires September 14, 2012 [Page 23]
Internet-Draft Requirements for Energy Management March 2012
13. Informative References
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628,
May 1994.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
Management Information Base", RFC 3433, December 2002.
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB",
RFC 3621, December 2003.
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",
RFC 3805, June 2004.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
November 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.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
[I-D.parello-eman-definitions]
Parello, J., "Energy Management Terminology",
draft-parello-eman-definitions-05 (work in progress),
March 2012.
[I-D.ietf-eman-applicability-statement]
Chandramouli, M. and B. Nordman, "Energy Management (EMAN)
Applicability Statement",
draft-ietf-eman-applicability-statement-00 (work in
progress), December 2011.
[ACPI.R30b]
Hewlett-Packard Corporation, Intel Corporation, Microsoft
Corporation, Phoenix Corporation, and Toshiba Corporation,
"Advanced Configuration and Power Interface
Quittek, et al. Expires September 14, 2012 [Page 24]
Internet-Draft Requirements for Energy Management March 2012
Specification, Revision 3.0b", October 2006.
[ANSI-TIA-1057]
Telecommunications Industry Association, "ANSI-TIA-1057-
2006 - TIA Standard - Telecommunications - IP Telephony
Infrastructure - Link Layer Discovery Protocol for Media
Endpoint Devices", April 2006.
[DMTF.DSP1027]
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
"Power State Management Profile", September 2008.
[IEEE-ISTO]
Printer Working Group, "PWG 5106.4 - PWG Power Management
Model for Imaging Systems 1.0", February 2011.
[IEC.62053-21]
International Electrotechnical Commission, "Electricity
metering equipment (a.c.) - Particular requirements - Part
22: Static meters for active energy (classes 1 and 2)",
2003.
[IEC.62053-22]
International Electrotechnical Commission, "Electricity
metering equipment (a.c.) - Particular requirements - Part
22: Static meters for active energy (classes 0,2 S and
0,5 S)", 2003.
[IEC.61850-7-4]
International Electrotechnical Commission, "Communication
networks and systems forpower utility automation - Part
7-4: Basic communication structure - Compatible logical
node classes and data object classes", 2010.
[IEEE-802.1AB]
IEEE Computer Society, "IEEE Std 802.1AB-2009 - IEEE
Standard for Local and metropolitan area networks -
Station and Media Access Control Discovery", September
2009.
Appendix A. Existing Standards
This section analyzes existing standards for energy consumption and
power state monitoring. It shows that there are already several
standards that cover only some part of the requirements listed above,
but even all together they do not cover all of the requirements for
energy management.
Quittek, et al. Expires September 14, 2012 [Page 25]
Internet-Draft Requirements for Energy Management March 2012
A.1. Existing IETF Standards
There are already RFCs available that address a subset of the
requirements.
A.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
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.
A.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 for policy decisions and for
other network management tasks. However, the number of states would
cover only a small subset of the requirements for power state
Quittek, et al. Expires September 14, 2012 [Page 26]
Internet-Draft Requirements for Energy Management March 2012
monitoring and it does not provide means for energy consumption
monitoring. For associating the information conveyed by the ENTITY
STATE MIB 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].
A.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 an entity 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]
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.
A.1.4. UPS MIB
RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of
this module provide information on the current real power of entities
attached to an uninterruptible power supply (UPS) device. This
application would require identifying which entity 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 that are used to identify the
Quittek, et al. Expires September 14, 2012 [Page 27]
Internet-Draft Requirements for Energy Management March 2012
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].
A.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 entities 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 entities 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.
A.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
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.
A.2. Existing standards of other bodies
A.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 it is rather an entity 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 an entity (e.g. to shutdown the entity)
which is an aspect of but not sufficient for active energy
Quittek, et al. Expires September 14, 2012 [Page 28]
Internet-Draft Requirements for Energy Management March 2012
management.
A.2.2. OVDA
ODVA is an association consisting of members from industrial
automation companies. ODVA supports standardization of network
technologies based on the Common Industrial Protocol (CIP). Within
ODVA, there is a special interest group focused on energy and
standardization and inter-operability of energy aware entities.
A.2.3. IEEE-ISTO Printer WG
The charter of the IEEE-ISTO Printer Working Group is for open
standards that define printer related protocols, that printer
manufacturers and related software vendors shall benefit from the
interoperability provided by conformance to these standards. One
particular aspect the Printer WG is focused on is power monitoring
and management of network printers and imaging systems PWG Power
Management Model for Imaging Systems [IEEE-ISTO]. Clearly, these
devices are within the scope of energy management since these devices
consume power and are attached to the network. In addition, there is
ample scope of power management since printers and imaging systems
are not used that often. IEEE-ISTO Printer working group has defined
MIB modules for monitoring the power consumption and power state
series that can be useful for power management of printers. The
energy management framework should also take into account the
standards defined in the Printer working group. In terms of other
standards, IETF Printer MIB RFC3805 [RFC3805] has been standardized,
however, this MIB module does not address power management of
printers.
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
Quittek, et al. Expires September 14, 2012 [Page 29]
Internet-Draft Requirements for Energy Management March 2012
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
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 14, 2012 [Page 30]