One document matched: draft-ietf-eman-requirements-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc4133 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4133.xml">
<!ENTITY rfc4268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4268.xml">
<!ENTITY rfc3621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3621.xml">
<!ENTITY rfc3805 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3805.xml">
<!ENTITY rfc1628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1628.xml">
<!ENTITY rfc3433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3433.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY rfc1628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1628.xml">
<!ENTITY rfc3433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3433.xml">
<!ENTITY rfc3621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3621.xml">
<!ENTITY rfc3805 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3805.xml">
<!ENTITY rfc4133 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4133.xml">
<!ENTITY rfc4268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4268.xml">
<!ENTITY rfc5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY rfc5102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
<!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
<!ENTITY I-D.parello-eman-definitions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.parello-eman-definitions.xml">
<!ENTITY I-D.ietf-eman-applicability-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eman-applicability-statement.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="draft-ietf-eman-requirements-06"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-ietf-eman-requirements-06" ipr="trust200902">
<front>
<title>Requirements for Energy Management</title>
<author fullname="Jürgen Quittek" initials="J." role="editor"
surname="Quittek">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-115</phone>
<email>quittek@neclab.eu</email>
</address>
</author>
<author fullname="Rolf Winter" initials="R." surname="Winter">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-121</phone>
<email>Rolf.Winter@neclab.eu</email>
</address>
</author>
<author fullname="Thomas Dietz" initials="T." surname="Dietz">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-128</phone>
<email>Thomas.Dietz@neclab.eu</email>
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>Degem</city>
<code>1831</code>
<country>BE</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author>
<author fullname="Mouli Chandramouli" initials="M."
surname="Chandramouli">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Sarjapur Outer Ring Road</street>
<city>Bangalore</city>
<region></region>
<code></code>
<country>IN</country>
</postal>
<phone>+91 80 4426 3947</phone>
<email>moulchan@cisco.com</email>
</address>
</author>
<date month="March" year="2012" />
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- Introduction =========================================== -->
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t><xref target="goals"/> elaborates a set of general needs
for energy management. Requirements
for an energy management standard are specified in Sections
<xref format="counter" target="identity"/> to
<xref format="counter" target="controlother"/>.</t>
<t>Sections <xref format="counter" target="identity"/> to
<xref format="counter" target="control"/> contain
conventional requirements specifying information on
powered entities
and control functions.</t>
<t>Sections <xref format="counter" target="reportonother"/>
and <xref format="counter" target="controlother"/> 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.</t>
<section anchor="conventional"
title="Conventional requirements for energy management">
<t>The specification of requirements for an energy
management standard starts with <xref target="identity"/>
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.</t>
<t><xref target="properties"/> 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
<xref target="control"/>.</t>
</section>
<section title="Specific requirements for energy management">
<t>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.
<!-- A new framework is necessary. -->
<list style="symbols">
<t>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.
<vspace/>
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.
</t>
<t>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.</t>
<t>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 towards them.</t>
<t>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.</t>
</list></t>
<t>This specific issue of energy management and a set of
further ones are covered by requirements specified in
Sections <xref format="counter" target="reportonother"/> and
<xref format="counter" target="controlother"/>.</t>
<t>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.
</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t> Terminology to be used by the eman WG is currently
discussed in <xref target="I-D.parello-eman-definitions"/>.
After final definitions of terms have been agreed, those
definitions will be listed here.</t>
</section>
<!-- Objectives ============================================ -->
<section anchor="goals"
title="General Considerations Related to Energy Management">
<t>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
<xref target="I-D.ietf-eman-applicability-statement"></xref>.
</t>
<section anchor="powerstates" title="Power states">
<t>
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:
<list style="symbols">
<t>full power state</t>
<t>reduced power states (e.g. lower clock rate for
processor, lower data rate on a link, etc.)</t>
<t>sleep state (not functional, but immediately
available)</t>
<t>off state (may require significant time
to become operational)</t>
</list>
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.</t>
</section>
<section anchor="tradeoffs"
title="Saving energy versus maintaining service level agreements">
<t>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.</t>
</section>
<section anchor="localglobal"
title="Local versus network-wide energy management">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="monitoring"
title="Energy monitoring versus energy saving">
<t>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.</t>
<t>Monitoring power states and energy consumption
can also be required for other purposes
including:
<list style="symbols">
<t>investigating energy saving potential</t>
<t>evaluating the effectiveness of energy saving policies
and measures</t>
<t>deriving, implementing, and testing power management
strategies</t>
<t>accounting for the total power consumption of a powered
entity, a network, or a service</t>
<t>predicting a powered entity's reliability based on
power usage</t>
<t>choosing time of next maintenance cycle for a powered
entity</t>
</list></t>
</section>
<section anchor="requirements"
title="Overview of energy management requirements">
<t>The following
basic management functions are required:
<list style="symbols">
<t>monitoring power states</t>
<t>monitoring power (energy consumption rate)</t>
<t>monitoring (accumulated) energy consumption</t>
<t>monitoring power properties</t>
<t>setting power states</t>
<t>setting and enforcing power saving policies</t>
</list></t>
<t>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.</t>
</section>
</section>
<!-- Requirements related to Identity of entities ========= -->
<section anchor="identity"
title="Identification of Powered Entities">
<t>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 <xref target="reportonother"/>. For powered entities
that control other powered entities it is important to
identify the powered entities they control, see
<xref target="controlother"/>.</t>
<t> 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.</t>
<t>Identifiers for devices and components
are already defined in standard MIB modules, such as the LLDP
MIB module <xref target="IEEE-802.1AB"/> and the LLDP-MED MIB
module <xref target="ANSI-TIA-1057"/> for devices and the
Entity MIB module <xref target="RFC4133"/> and the Power
Ethernet MIB <xref target="RFC3621"/> for components of
devices. Energy management needs means to link
energy-related information to such identifiers.</t>
<t>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.</t>
<section toc="exclude" title="Identifying powered entities">
<t>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.</t>
</section>
<section toc="exclude"
title="Identifying components of powered devices">
<t>The standard must provide means for
identifying not just entire devices as powered entities, but
also individual components.</t>
</section>
<section toc="exclude"
title="Persistence of identifiers">
<t>The standard must provide means for
indicating whether identifiers of powered entities are
persistent across a re-start of the powered entity.</t>
</section>
<section toc="exclude"
title="Using entity identifiers of other MIB modules">
<t>The standard must provide means for
re-using entity identifiers from other standards including
at least the following:
<list style="symbols">
<t>the entPhysicalIndex in the Entity MIB module
<xref target="RFC4133"/></t>
<t>the LldpPortNumber in the LLDP MIB module
<xref target="IEEE-802.1AB"/> and in the LLDP-MED MIB
module <xref target="ANSI-TIA-1057"/></t>
<t>the pethPsePortIndex and the pethPsePortGroupIndex
in the Power Ethernet MIB <xref target="RFC3621"/></t>
</list>
Generic means for re-using other entity identifiers
must be provided.</t>
</section>
</section>
<!-- Requirements related to powered entities monitoring === -->
<section anchor="properties"
title="Information on Powered Entities">
<t>This section describes information on powered entities for
which the standard must provide means for retrieving and
reporting.</t>
<t>Required information can be structured
into six groups.
<!-- <list style="symbols">
<t>general information</t>
<t>power states</t>
<t>power inlets and outlets</t>
<t>power</t>
<t>energy</t>
<t>batteries</t>
</list> -->
<xref target="general"/> specifies requirements for general
information on powered entities, such as type of powered
entity or context information. <xref target="state"/> covers
requirements related to entities' power states. Requirements
for information on power inlets and power outlets of powered
entities are specified in <xref target="inlet"/>. Monitoring
of power and energy is covered by Sections <xref
format="counter" target="power"/> and <xref format="counter"
target="energy"/>, respectively. <xref target="battery"/>
specifies requirements for monitoring batteries. Finally,
the reporting of time series of values is covered by <xref
target="timeseries"/>.</t>
<section anchor="general"
title="General information on Powered Entities">
<t>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.</t>
<section anchor="type" toc="exclude"
title="Type of powered entity">
<t>The standard must provide means to configure, retrieve
and report a textual name or a description of a powered
entity.</t>
</section>
<section anchor="context" toc="exclude"
title="Context information on powered entities">
<t>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.</t>
</section>
<section anchor="priority" toc="exclude"
title="Power priority">
<t>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.</t>
</section>
<section toc="exclude" title="Grouping of powered entities">
<t>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.</t>
</section>
</section>
<section anchor="inlet" title="Power interfaces">
<t>A power interface is either an inlet or an outlet.
A few switch between these two but most never change.</t>
<t>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 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.</t>
<t>Powered entities can have one or more power outlets for
supplying other powered entities with electric power. </t>
<t>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.</t>
<t>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.</t>
<section toc="exclude"
title="Lists of power interfaces">
<t>The standard must provide means for monitoring
the list of power interfaces.</t>
</section>
<section anchor="powersupplier" toc="exclude"
title="Corresponding power outlet">
<t>The standard must provide means for
identifying the power outlet that provides the power
received at a power inlet.</t>
</section>
<section anchor="powersuppliee" toc="exclude"
title="Corresponding power inlets">
<t>The standard must provide means for identifying the
list of power inlets that receive the power provided at a
power outlet.</t>
</section>
<!-- It would be useful to explain the context of this
requirement. This seems tracing the power
distribution tree.
Yes, good point. Let's add such text to the next
version.
-->
<section anchor="availability" toc="exclude"
title="Availability of power">
<t>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.</t>
</section>
<section toc="exclude" title="Use of power">
<t>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.</t>
</section>
<section toc="exclude" title="Type of current">
<t>The standard must provide means for reporting the type
of current (AC or DC) for each power interface.
</t>
</section>
<section toc="exclude" title="Nominal voltage">
<t>The standard must provide means for reporting the
nominal voltage for each power interface.</t>
</section>
<section toc="exclude" title="Nominal AC frequency">
<t>The standard must provide means for reporting the
nominal AC frequency for each power interface.</t>
</section>
<section toc="exclude" title="Number of AC phases">
<t>The standard must provide means for reporting the
number of AC phases for each power interface.</t>
</section>
</section>
<section anchor="power" title="Power">
<t>Power is measured as an instantaneous value or
as the average over a time interval. </t>
<t>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.</t>
<t>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 <xref
target="IEC.62053-21">IEC 62053-21</xref> and <xref
target="IEC.62053-22">IEC 62053-22</xref> should be
considered.</t>
<t>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 <xref target="IEC.61850-7-4"/>.</t>
<t>For some network management tasks it is desirable to
receive notifications from powered entities when their power
value exceeds or falls below given thresholds.</t>
<section toc="exclude" title="Real power">
<t>The standard must provide means for
reporting the real power for each power interface,
including the direction of power flow.</t>
</section>
<section toc="exclude" title="Power measurement interval">
<t>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.</t>
</section>
<section toc="exclude" title="Power measurement method">
<t>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. </t>
</section>
<section toc="exclude"
title="Accuracy of power and energy values">
<t>The standard must provide means for reporting the
accuracy of reported power and energy values.</t>
</section>
<section toc="exclude" title="Actual voltage and current">
<t>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.</t>
</section>
<section toc="exclude" title="High/low power notifications">
<t>The standard must provide means for creating
notifications if power values of a powered entity rise
above or fall below given thresholds.</t>
</section>
<section toc="exclude" title="Complex power">
<t>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, 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.</t>
</section>
<section toc="exclude" title="Actual AC frequency">
<t>The standard must provide means for
reporting the actual AC frequency for each power interface.
</t>
</section>
<section toc="exclude" title="Total harmonic distortion">
<t>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.</t>
</section>
<section toc="exclude" title="Power supply impedance">
<t>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.</t>
</section>
</section>
<section anchor="state" title="Power state">
<t>Many powered entities have a limited number of discrete
power states.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>There also is a need to report statistics on power states
including the time spent and the energy consumed in a power
state.</t>
<section toc="exclude" title="Actual power state">
<t>The standard must provide means for
reporting the actual power state of a powered entity.</t>
</section>
<section toc="exclude"
title="List of supported power states">
<t>The standard must provide means for retrieving the list
of all potential power states of a powered entity.</t>
</section>
<section toc="exclude" title="Multiple power state sets">
<t>The standard must provide means for supporting multiple
power state sets simultaneously at a powered entity. </t>
</section>
<section toc="exclude"
title="List of supported power state sets">
<t>The standard must provide means for retrieving the list
of all power state sets supported by a powered entity.</t>
</section>
<section toc="exclude"
title="List of supported power states within a set">
<t>The standard must provide means for retrieving the list
of all potential power states of a powered entity for each
supported power state set.</t>
</section>
<section toc="exclude"
title="Maximum and average power per power state">
<t>The standard must provide means for retrieving the
maximum power and the average power for each supported
power state. These values may be static.</t>
</section>
<section toc="exclude" anchor="statistics"
title="Power state statistics">
<t>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
<xref format="counter" target="energyperstate"/>.</t>
</section>
<section toc="exclude" title="Power state changes">
<t>The standard must provide means for generating a
notification when the actual power state of a powered
entity changes.</t>
</section>
</section>
<section anchor="energy" title="Energy">
<t>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.</t>
<t>It is useful for powered entities to record their energy
consumption per power state and report these quantities.</t>
<section toc="exclude" title="Energy">
<t>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.</t>
</section>
<section toc="exclude" title="Time intervals">
<t>The standard must provide means for reporting the
consumed energy of a powered entity for specified time
intervals.
<list style="symbols">
<t>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.</t>
<t>Reports must be supported for a sequence of
consecutive non-overlapping time intervals of fixed size
(periodic reports).</t>
<t>Reports must be supported for a sequence of
consecutive overlapping time intervals of fixed size
(periodic reports).</t>
<t>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)</t>
</list></t>
</section>
<section anchor="energyperstate" toc="exclude"
title="Energy per power state">
<t>The standard must provide means for reporting the
consumed energy individually for each power state. This
extends the requirement <xref format="counter"
target="statistics"/> on power state statistics.</t>
</section>
</section>
<section anchor="battery" title="Battery state">
<t>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 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.</t>
<t>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
<xref target="general" format="counter"/> to
<xref target="energy" format="counter"/>.</t>
<t>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.</t>
<section toc="exclude" anchor="charge"
title="Battery charge">
<t>The standard must provide means for reporting
the current charge of a battery.</t>
</section>
<section toc="exclude" title="Battery charging state">
<t>The standard must provide means for reporting the
charging state (charging, discharging, etc.) of a
battery.</t>
</section>
<section toc="exclude" title="Battery charging cycles">
<t>The standard must provide means for reporting
the number of completed charging cycles of a battery.</t>
</section>
<section toc="exclude" title="Actual battery capacity">
<t>The standard must provide means for reporting
the actual capacity of a battery.</t>
</section>
<section toc="exclude" title="Static battery properties">
<t>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.</t>
</section>
<section toc="exclude"
title="Low battery charge notification">
<t>The standard must provide means for generating a
notification when the charge of a battery decreases below
a given threshold.</t>
</section>
<section toc="exclude" anchor="replacement"
title="Battery replacement notification">
<t>The standard must provide means for generating a
notification when the number of charging cycles of battery
exceeds a given threshold.</t>
</section>
<section toc="exclude" title="Multiple batteries">
<t>The standard must provide means for meeting
requirements <xref format="counter" target="charge"/> to
<xref format="counter" target="replacement"/> for each
individual battery contained in a single powered entity.
</t>
</section>
</section>
<section anchor="timeseries"
title="Time series of measured values">
<t>For some network management tasks, it is required to
obtain time series of measured values, such as power,
energy, battery charge, etc.</t>
<t>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.</t>
<t>While there is a common understanding that support for
reporting of time series is needed, there is no clear
agreement on four issues:
<list style="numbers">
<t>Which quantities should be reported?</t>
<t>Which time interval type should be used (total, delta,
sliding window)?</t>
<t>Which measurement method should be used (sampled,
continuous)?</t>
<t>Which reporting model should be used (push or pull)?
</t>
</list>
</t>
<t>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.</t>
<t>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 <xref
target="IEC.61850-7-4"/>.</t>
<t>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 over a sliding
window.</t>
<t>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
<xref target="RFC5101"/>,<xref target="RFC5102"/>. SNMP
<xref target="RFC3411"/> is an example for a protocol that
can be used for realizing pull-based reporting of time
series.</t>
<t>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.</t>
</section>
</section>
<!-- Requirements related to Entity Control ================ -->
<section anchor="control" title="Control of Powered Entities">
<t>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.</t>
<t>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.</t>
<section toc="exclude" title="Controlling power states">
<t>The standard must provide means for
setting power states of powered entities.</t>
</section>
<section anchor="outletcontrol" toc="exclude"
title="Controlling power supply">
<t>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.</t>
</section>
</section>
<section anchor="reportonother"
title="Reporting on other Powered Entities">
<t>As discussed in <xref target="properties"/>, 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 <xref target="controlother"/> for
requirements on controlling other powered entities.</t>
<t>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.</t>
<t>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.</t>
<section toc="exclude"
title="Reports on other powered entities">
<t>The standard must provide means for a powered entity to
report information on another powered entity. </t>
</section>
<section toc="exclude"
title="Identity of other powered entities on which is reported">
<t>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.
</t>
</section>
<section toc="exclude"
title="Reporting quantities accumulated over multiple powered entities">
<t>The standard must provide means for reporting the list
of all powered entities from which contributions are
included in an accumulated value.</t>
</section>
<section toc="exclude"
title="List of all powered entities on which is reported">
<t>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.</t>
</section>
<section toc="exclude"
title="Content of reports on other powered entities">
<t>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.</t>
</section>
<section toc="exclude"
title="Indicating source of remote information">
<t>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.</t>
</section>
<section toc="exclude"
title="Indicating content of remote information">
<t>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.</t>
</section>
</section>
<!-- Requirements Control of Powered Entities ====== -->
<section anchor="controlother"
title="Controlling Other Powered Entities">
<t>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.</t>
<section anchor="statecontrol"
title="Controlling power states of other Powered Entities">
<t>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.</t>
<t>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.
</t>
<section toc="exclude"
title="Control of power states of other Powered Entities">
<t>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.</t>
</section>
<section toc="exclude"
title="Identity of other power state controlled entities">
<t>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.
</t>
</section>
<section toc="exclude"
title="List of all power state controlled entities">
<t>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.</t>
</section>
<section toc="exclude"
title="List of all power state controllers">
<t>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.</t>
</section>
</section>
<section anchor="supplycontrol"
title="Controlling power supply">
<t>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
<xref format="counter" target="outletcontrol"/>.</t>
<t>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 <xref
format="counter" target="powersupplier"/> and
<xref format="counter" target="powersuppliee"/>.</t>
</section>
</section>
<section title="Security Considerations">
<t>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
<xref format="counter" target="control"/> and <xref
format="counter" target="controlother"/> must be sufficiently
protected through authentication, authorization, and integrity
protection mechanisms.</t>
<t>Monitoring energy-related quantities of a powered entity
addressed in Sections <xref format="counter"
target="properties"/> - <xref format="counter"
target="controlother"/> 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.</t>
<section toc="exclude" title="Secure energy management">
<t>The standard must provide privacy, integrity, and
authentication mechanisms for all actions addressed in
Sections <xref format="counter" target="properties"/>
- <xref format="counter" target="controlother"/>.
The security mechanisms must address all threats listed in
Section 1.4 of <xref target="RFC3411"/>.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
<section title="Open issues">
<section title="Standards for DC power characteristics?">
<t>Is there a standard on DC power characteristics?
Would they be needed for EMAN?</t>
</section>
<section title="Directional metering of Power and Energy">
<t>Still not covered consistently.</t>
</section>
<section title="Drop requirements for Impedance and THD?">
<t> 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.</t>
</section>
<section title="Rime intervals for energy measurements">
<t>After the requirements on time series have been dropped,
requirement 5.5.2 on time intervals for energy measurements
may have to be revised.</t>
</section>
<section title="Reporting on other devices">
<t>This needs to be considered whether it is devices or
interfaces or entities that are to be reported on.</t>
</section>
</section>
</middle>
<back>
<references title="Informative References">
&rfc1628;
&rfc3411;
&rfc3433;
&rfc3621;
&rfc3805;
&rfc4133;
&rfc4268;
&rfc5101;
&rfc5102;
&I-D.parello-eman-definitions;
&I-D.ietf-eman-applicability-statement;
<reference anchor="ACPI.R30b">
<front>
<title>
Advanced Configuration and Power Interface
Specification, Revision 3.0b
</title>
<author initials=""
surname="Hewlett-Packard Corporation"
fullname="Hewlett-Packard Corporation">
</author>
<author initials=""
surname="Intel Corporation"
fullname="Intel Corporation">
</author>
<author initials=""
surname="Microsoft Corporation"
fullname="Microsoft Corporation">
</author>
<author initials=""
surname="Phoenix Corporation"
fullname="Phoenix Corporation">
</author>
<author initials=""
surname="Toshiba Corporation"
fullname="Toshiba Corporation">
</author>
<date year="2006" month="October" />
</front>
</reference>
<reference anchor="ANSI-TIA-1057">
<front>
<title>
ANSI-TIA-1057-2006 - TIA Standard - Telecommunications -
IP Telephony Infrastructure - Link Layer Discovery
Protocol for Media Endpoint Devices
</title>
<author initials=""
surname="Telecommunications Industry Association"
fullname="Telecommunications Industry Association">
</author>
<date year="2006" month="April" />
</front>
</reference>
<!--
<reference anchor="ANSI-ASHRAE-135-2010">
<front>
<title>
Standard 135-2010 - BACnet A Data Communication Protocol
for Building Automation and Control Networks (ANSI
Approved) - SSPC 135 and TC 1.4, Control Theory and
Application
</title>
<author initials=""
surname="American Society of Heating, Refrigerating
and Air-Conditioning Engineers"
fullname="American Society of Heating, Refrigerating
and Air-Conditioning Engineers">
</author>
<date year="2011"/>
</front>
</reference>
-->
<reference anchor="DMTF.DSP1027">
<front>
<title>Power State Management Profile</title>
<author initials="R.R."
surname="Dasari (ed.)"
fullname="RadhaKrishna R. Dasari (ed.)">
</author>
<author initials="J."
surname="Davis (ed.)"
fullname="Jim Davis (ed.)">
</author>
<author initials="J."
surname="Hilland (ed.)"
fullname="Jeff Hilland (ed.)">
</author>
<date year="2008" month="September" />
</front>
</reference>
<reference anchor="IEEE-ISTO">
<front>
<title>
PWG 5106.4 - PWG Power Management Model for Imaging
Systems 1.0
</title>
<author initials=""
surname="Printer Working Group"
fullname="IEEE-ISTO">
</author>
<date year="2011" month="February" />
</front>
</reference>
<reference anchor="IEC.62053-21">
<front>
<title>
Electricity metering equipment (a.c.) - Particular
requirements - Part 22: Static meters for active energy
(classes 1 and 2)
</title>
<author initials=""
surname="International Electrotechnical Commission"
fullname="International Electrotechnical Commission">
</author>
<date year="2003"/>
</front>
</reference>
<reference anchor="IEC.62053-22">
<front>
<title>
Electricity metering equipment (a.c.) - Particular
requirements - Part 22: Static meters for active energy
(classes 0,2 S and 0,5 S)
</title>
<author initials=""
surname="International Electrotechnical Commission"
fullname="International Electrotechnical Commission">
</author>
<date year="2003"/>
</front>
</reference>
<reference anchor="IEC.61850-7-4">
<front>
<title>
Communication networks and systems forpower utility
automation - Part 7-4: Basic communication structure -
Compatible logical node classes and data object classes
</title>
<author initials=""
surname="International Electrotechnical Commission"
fullname="International Electrotechnical Commission">
</author>
<date year="2010"/>
</front>
</reference>
<!--
<reference anchor="IEEE-1621">
<front>
<title>
IEEE P1621-2004 -Draft Standard for User Interface
Elements in Power Control of Electronic Devices Employed
in Office Consumer Environments
</title>
<author initials=""
surname="Institute of Electrical and Electronics
Engineers"
fullname="Institute of Electrical and Electronics
Engineers">
</author>
<date year="June 2005"/>
</front>
</reference>
-->
<reference anchor="IEEE-802.1AB">
<front>
<title>
IEEE Std 802.1AB-2009 - IEEE Standard for Local and
metropolitan area networks - Station and Media Access
Control Discovery
</title>
<author initials=""
surname="IEEE Computer Society"
fullname="IEEE Computer Society">
</author>
<date year="September 2009"/>
</front>
</reference>
<!--
<reference anchor="IEEE-802.3az">
<front>
<title>
IEEE-802.3az-2010 - IEEE Standard
for Local and Metropolitan Area Networks - Specific
requirements Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications - Amendment 5: Media
Access Control Parameters, Physical Layers, and
Management Parameters for Energy-Efficient Ethernet
</title>
<author initials=""
surname="IEEE Computer Society"
fullname="IEEE Computer Society">
</author>
<date year="October 2010"/>
</front>
</reference>
-->
<!--
<reference anchor="MODBUS-Protocol">
<front>
<title>
MODBUS Application Protocol Specification V1.1b
</title>
<author initials=""
surname="Modbus-IDA"
fullname="Modbus-IDA">
</author>
<date year="December 2006"/>
</front>
</reference>
-->
</references>
<section anchor="standards" title="Existing Standards">
<t>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.</t>
<section title="Existing IETF Standards">
<t>There are already RFCs available that address a subset of the
requirements.</t>
<section title="ENTITY MIB">
<t>The ENTITY-MIB module defined in <xref target="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 <xref target="RFC4133">RFC 4133</xref>
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.</t>
<t>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 <xref target="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.</t>
<t>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.</t>
</section>
<section title="ENTITY STATE MIB">
<t><xref target="RFC4268">RFC 4268</xref> 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 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
<xref target="RFC4133">ENTITY MIB module</xref>. Particularly, it
uses the entPhysicalIndex for identifying entities.</t>
<t>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
<xref target="ACPI.R30b">Advanced Configuration and Power Interface (ACPI)</xref>
or the
<xref target="DMTF.DSP1027">DMTF Power State Management Profile</xref>.</t>
</section>
<section title="ENTITY SENSOR MIB">
<t><xref target="RFC3433">RFC 3433</xref> 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.</t>
<t>Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB
module makes use of the means provided by the <xref
target="RFC4133">ENTITY MIB module</xref> for relating provided
information to components of a device. </t>
<t>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.</t>
</section>
<section title="UPS MIB">
<t><xref target="RFC1628">RFC 1628</xref> 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.</t>
<t>UPS MIB provides information on the state of the UPS network.
The MIB module contains several variables that are used to 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 <xref target="RFC3433"/>.</t>
</section>
<section title="POWER ETHERNET MIB">
<t>Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
module defined in <xref target="RFC3621">RFC3621</xref> 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.</t>
<t>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.</t>
</section>
<section title="LLDP MED MIB">
<t>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.</t>
</section>
</section>
<section title="Existing standards of other bodies">
<t></t>
<section title="DMTF">
<t>The DMTF has defined a <xref target="DMTF.DSP1027">power state
management profile</xref> 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.</t>
<t>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 management.
</t>
</section>
<section title="OVDA">
<t>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. </t>
</section>
<section title="IEEE-ISTO Printer WG">
<t> 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 <xref target="IEEE-ISTO">PWG Power Management Model for Imaging Systems </xref>.
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 <xref target="RFC3805">RFC3805</xref> has been
standardized, however, this MIB module does not address power management of printers. </t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:30 |