One document matched: draft-ietf-eman-requirements-05.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.tychon-eman-applicability-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tychon-eman-applicability-statement.xml">
<!ENTITY I-D.parello-eman-definitions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.parello-eman-definitions.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="draft-ietf-eman-requirements-05"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-ietf-eman-requirements-05" 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="November" year="2011" />
<abstract>
<t>This document defines requirements for standards specifications
for energy management. The requirements presented in this document
include 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 quality,
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 and networking equipment, energy
management is becoming an additional basic requirement for the
network devices and the associated network management systems.</t>
<t>This document defines requirements for standards specifications
for energy management. This doccument contains the requirements that
concern monitoring functions as well as control functions. In detail,
the requirements listed are focussed on the following features:
identification of powered entities, monitoring of their power
state, power inlets, power outlets, actual power, power quality,
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 are 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 a building
management infrastructure using the BACnet <xref
target="ANSI/ASHRAE-135-2010"/> or MODBUS <xref
target="MODBUS-Protocol"/> protocols.</t>
<t>The requirements specified in this document explicitly 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. But which
of the features specified by these standards will be mandatory,
recommended, or optional for compliant implementations is to be
defined by the concrete standards track document(s) and not in
this document.</t>
<t>This document first elaborates a set of general considerations
related to energy management in <xref target="goals"/>. 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 rather
conventional requirements specifying which information on
powered entities needs to be covered by an energy management
standard, and which control functions are needed.</t>
<t>Sections <xref format="counter" target="reportonother"/> and
<xref format="counter" target="controlother"/> contain requirements
that are very specific to energy management. They result from the fact
that due to the nature of power supply, some of the monitoring
and control functions are not conducted by interacting with the
powered entity of interest, but with other entities, for example,
with entities upstream in the 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. Furthermore,
it must support more than just reporting per powered device.
Support is required for also 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>At first glance the rather conventional requirements
summarized above seem to be all that would be needed for
energy management. But it turns out that there are
some significant differences between energy management and
most of the well known conventional network management functions.
The most significant difference from many other management
functions 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 in general
it is not sufficient to communicate with the powered entity
only, particularly if the powered entity has no
instrumentation for measuring power. In such cases
it might still be possible to obtain power values for the
entity by communication with other entities in the same
power distribution tree. <vspace/>
A very simple example would be retrieving power values from
a dedicated power meter at the power line of the powered entity.
More 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
communication 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 its scope beyond
powered entities with IP network interfaces, for example toward
non-IP building networks, that are accessed via an IP gateway.
Requirements in this document do not fully cover all these
networks, but they cover means for opening IP network
management towards them.</t>
<t>For monitoring of particular powered entities, it is
sometimes not a scalable approach to communicate directly
with all the powered entities directly from a central energy
management system as the number of powered entities keeps
increasing.</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>For meeting the requirements specified in these sections
first a new energy management framework needs to be specified
that gives directions on how to deal with the specific nature
of energy management. Based on such a framework, energy management
standards can be specified that meet the requirements below.
The actual standards documents, such as, for example, MIB module
specifications, will address conformance issues by specifying
which feature must, should, or may to be implemented by compliant
implementations.</t>
</section>
</section>
<!-- Terminology ==================================================== -->
<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, they will be listed here.</t>
<!--
<section toc="exclude" title="Energy">
<t>Electric Energy is needed for operating electric
entities. These powered entities "consume" electric energy by
converting it to thermal energy (heat) or other kinds of
energy while conducting their operational tasks. For energy
management, the total energy converted by a powered entity during
a time interval is of interest.</t>
<t>The definition of the term energy is to be agreed on in the EMAN WG.</t>
<t>The term 'energy consumption' is commonly used for both,
for referring to the amount of consumed energy and also
for referring to the rate of consuming energy. In the
first case it addresses consumed energy measured by joule,
watt-hour, or another energy unit, in the second one
it addresses power, typically an average power measured by watt.</t>
<t>However, in this document the term "consumed energy" always
refers to an energy quantity (measured in joule, watt-hour, etc.)
and not to a power quantity (measured in watt, etc.).</t>
</section>
<section toc="exclude" title="Power">
<t>Power is defined as energy conversion rate. For energy
management, the instantaneous power of a managed entity may
be of interest as well as the average power over a time
interval.</t>
<t>The definition of the term power is to be agreed on in the EMAN WG.</t>
</section>
<section title="Demand">
<t>The definition of the term demand is to be agreed on in the EMAN WG.</t>
</section>
<section toc="exclude" title="Powered entity">
<t>A powered entity is a consumer of energy that is subject
to energy management. In general, all managed physical
entities in a communication network consume electric energy
and thus are subject to energy management including
particularly energy monitoring and energy control.</t>
<t>A powered entity can be a managed device or a component
of a managed device, which is monitored or controlled
individually.</t>
</section>
<section toc="exclude" title="Power state">
<t>Power state of a powered entity is defined as a specific setting
of a powered entity that influences its energy consumption.
Examples of power states of a powered entity are on, off, and sleep.</t>
</section>
<section toc="exclude" title="Power monitor">
<t>Energy management requires retrieving energy-related
information on powered entities. In many cases this
information is not available at the powered entities themselves,
but at other powered entities. For example measurement of power and
energy consumption can be conducted by power meters at
other locations along the power distribution tree for
the powered entity.</t>
<t>A power monitor is a module that reports energy-related
information on powered entities. A power monitor may be
integrated into a powered entity or located remotely of
the powered entity. Instances of power monitors may report
information on, for example, power supply, power, and power
state of a powered entity. There may be multiple power
monitors reporting information on the same powered entity.
</t>
</section>
<section toc="exclude" title="Power inlet">
<t>Powered entities receive power at their power inlets.
Powered entities may have multiple inlets, for example,
servers with redundant power supply. Examples for
power inlets are AC power cords of a powered entity or an
Ethernet port at which the powered entity receives DC Power
over Ethernet (PoE).</t>
</section>
<section toc="exclude" title="Power outlet">
<t>Powered entities may have means to supply others with electrical
power. Power is delivered to other powered entities through power
outlets. Power sourcing entities often have more than one power
outlet. Examples for power outlets are AC power sockets at
a Power Distribution Unit (PDU) and Ethernet ports at a
Power over Ethernet (PoE) Power Sourcing Equipment (PSE),
that can supply powered entities with DC power using the Ethernet
cable.</t>
</section>
<section toc="exclude" title="Energy management">
<t>Energy management deals with assessing and influencing the
consumption of energy in a network of powered entities.
A typical objective of energy management is reducing the energy
consumption in the network. Ways towards achieving this
objective may be limited by other objectives of a general
network management system, such as service level objectives.</t>
<t>The definition of the term energy management is to be agreed
on in the EMAN WG.</t>
</section>
<section toc="exclude" title="Energy management standard">
<t>This term refers to a collection of documents specifying
standards for energy-related monitoring and control.
The energy management standard specifies the features that
need to be considered for possible implmentation of
energy management systems.</t>
<t>Requirements specified in this document
concern the means that an energy management standard must
provide. It does not imply that all required means must be
implemented in all energy standard scenarios. Which means and
features must be implemented by compliant implementations is to
be specified by the energy management standard itself, not by
this requirements document.</t>
<t>Note that for meeting individual requirements specified
in this document, new standards are not necessarily required.
It is recommended to rather use existing standards than
specify new ones.</t>
</section>
-->
</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 amount of energy, while maintaining
a certain level of service. A set of use cases and the target devices
for the application of energy
management can be found in
<xref target="I-D.tychon-eman-applicability-statement"></xref>.
</t>
<section anchor="powerstates" title="Power states">
<t>One approach to achieve this goal is by setting all
powered entities to an operational state that results in
lower energy consumption, but still meets the service level
performance objectives. The sufficient performance level
may vary over time and can depend on several factors.
In principle, there are four basic types of power states
for a powered entity or for a whole system:
<list style="symbols">
<t>full power state</t>
<t>reduced power states (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 imply requiring significant time
for becoming operational)</t>
</list>
In actual implementations the number of power
states and their properties vary a lot. Very simple powered
entities may just have only the extreme states, full power
and off state. Some implementations might use
the IEEE 1621 <xref target="IEEE-1621"/> model of three states
on, off, and sleep. However, more finely grained power
states can be implemented with many levels of off, sleep,
and reduced 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 efficiency.
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 can be executed locally by
a powered entity. The basic principle is that a powered
entity 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.
Potential interactions with an energy management system for
such an entity include the observation of the entity's power
state and the configuration of power saving policies, for
example, by setting thresholds or schedules for power state
changes.</t>
<t>Energy savings can also be achieved with policies
implemented by a network management system that controls
power states of managed entities. In order to make policy
decisions properly, information about the energy consumption
of powered entities in different power states is required. 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 a good choice
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 beginning and end of business hours in a
building. Local management appears often to be preferable for
dynamic 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>It should be noted that only monitoring energy consumption
and power states is obviously not a means to reduce the energy
consumption of a powered entity. In fact, it is likely to increase
the power consumption of a powered entity slightly because
monitoring energy may require instrumentation that consumes
energy when in use. And also reporting of measured quantities
over the network consumes energy. However, the
acquired energy consumption and power state information is
essential for defining energy saving policies and can be used
as input to power state control loops that in total can lead
to energy savings.</t>
<t>Monitoring operational power states and energy consumption
can also be required for other energy management purposes
including but not limited to:
<list style="symbols">
<t>investigating power 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>From the considerations described above the following
basic management functions appear to be required for energy
management:
<list style="symbols">
<t>monitoring power states</t>
<t>monitoring power (energy consumption rate)</t>
<t>monitoring (accumulated) energy consumption</t>
<t>monitoring power quality</t>
<t>setting power states</t>
<t>setting and enforcing power saving policies</t>
</list></t>
<t>It should be noted that power control is complementary
(but essential) to other energy savings measures
such as low power electronics, energy saving protocols
(for example, Energy-Efficient Ethernet <xref
target="IEEE-802.3az"/>), energy-efficient device design
(for example, sleep and low-power modes for individual
components of a device), and energy-efficient network architectures.
Measurement of energy consumption may also provide useful
input for developing these technologies.</t>
</section>
</section>
<!-- Requirements related to Identity of entities =========== -->
<section anchor="identity" title="Identification of Powered Entities">
<t>As already stated in <xref target="conventional"/>, powered entities
on which energy-related information is provided, are identified
in a sufficiently unique way. This holds in particular for
powered 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>Also stated already in <xref target="conventional"/> is the
requirement of providing means for reporting energy-related
information on components of a managed device. An entity in
this document may be an entire managed device or just a
component of it. Examples of components of interest are
a hard drive, a battery, or a line card. For controlling
entities it may be required to be able to address individual
components in order 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 times.</t>
<t>Identifiers to other devices and to components of devices
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. For energy management it is necessary
to have means for linking energy-related information to
such identifiers.</t>
<t>Instrumentation for measuring energy consumption of a
device is typically more expensive than instrumentation for
retrieving the devices power state. It may be a reasonable
compromise in many cases to provide power state information
for all individually switchable components of a device
separately, while the energy consumption is only measured for
the entire device.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Identifying powered entities">
<t>The energy management standard must provide means for
uniquely identifying powered entities that
are monitored or controlled by an energy management system.
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 energy management standard must provide means for
identifying individual sub-components of powered devices.</t>
</section>
<section toc="exclude"
title="Persistency of identifiers">
<t>The energy management 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 energy management standard must provide means for
re-using entity identifiers from other standards including
at least the following:
<list style="symbols">
<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 entPhysicalIndex in the Entity MIB module
<xref target="RFC4133"/></t>
<t>the pethPsePortIndex and the pethPsePortGroupIndex
in the Power Ethernet MIB <xref target="RFC3621"/></t>
</list>
Additionally, generic means for re-using further 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 energy-related information on powered
entities for which an energy management standard must provide
means for retrieving and reporting.</t>
<t>Required information on powered entities 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. Finally,
<xref target="battery"/> specified requirements for monitoring
batteries.</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. From the point of view of monitoring and
management of a large network perspective, it may be helpful to aggregate
the energy consumption according to a defined grouping of entities.
When controlling and setting power states it may be helpful to understand the
the grouping of the entity and role of a powered entity in a network, for example,
in order to avoid switching off vital network components.</t>
<t>Detailed Requirements:</t>
<section anchor="type" toc="exclude"
title="Type of powered entity">
<t>The energy management standard must provide means to
retrieve and report the type of powered entities according
to a standardized classification scheme.</t>
<t> YCM --- This issue has been discussed and the feeling was that type may not be needed
and thus it is better to drop this requirement. --- YCM </t>
<t>The energy management standard must provide means to
configure, retrieve and report a textual name or a description of a powered entity.
In addition to the unique identity, such a textual description shall be useful.</t>
</section>
<section anchor="context" toc="exclude"
title="Context information on powered entities">
<t>The energy management 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 toc="exclude" title="Grouping of powered entities">
<t>The energy management 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="state" title="Power state">
<t>Many powered entities have a limited number of discrete
power states, such as, for example, full power, low power, sleep,
and off.</t>
<t>Obviously, there is a need to report the actual power state
of a powered entity. Beyond that, there is also a requirement for
standardizing means for retrieving the list of all supported
power states of a powered entity.</t>
<t>Presently, different standards bodies have already defined their own
sets of power states for some powered entities. Beyond those, other
standards organizations are in the process of adding more of these power
state sets for the devices considered in their scope. Given this context,
it is desirable that the energy management standard shall be interoperable
across these multiple 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>
<t>For some network management tasks, it may be desirable to
receive notifications from powered entities, for example, when the entire
entity or some of the components of the entity change their power state.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Actual power state">
<t>The energy management 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 energy management 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 energy management 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 energy management 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>Referring to the "list of supported power state sets"
requirement, the energy management standard must provide
means for retrieving the list of all potential power states
of a powered entity that belong to a given power state set.</t>
</section>
<section toc="exclude"
title="Maximum and average power per power state">
<t>The energy management standard must provide means for
retrieving the maximum power and the average power as a
for each supported power state.
These values may be static properties of a power state.</t>
</section>
<section toc="exclude" anchor="statistics"
title="Power state statistics">
<t>The energy management standard must provide means for monitoring
statistics per power state including at least the total time spent
in a power state, the number of times a state was entered
and the last time a 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 energy management standard must provide means for
generating a notification when the actual power state
of a powered entity changes.</t>
</section>
</section>
<section anchor="inlet" title="Power inlet and power outlet">
<t>Powered entities have power inlets at which they are
supplied with electric power. Most powered entities just have a
single power inlet, while some have multiple ones.
Often different power inlets are 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>Some powered entities have power outlets for supplying
other powered entities with electric power. A powered entity
may have multiple power outlets.</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.</t>
<t>Static properties of each power inlet and each power outlet
are required information for energy management. Static properties
include the kind of electric current (Alternating Current
(AC) or Direct Current (DC)), the nominal voltage, the nominal
AC frequency, and the number of AC phases.</t>
<t>Detailed Requirements:</t>
<section toc="exclude"
title="List of power inlets and power outlets">
<t>The energy management standard must provide means for monitoring
the list of power inlets and power outlets at a powered entity.</t>
</section>
<section toc="exclude" title="Corresponding power outlet">
<t>The energy management standard must provide means for
identifying the power outlet that provides the power
received at a power inlet.</t>
</section>
<section toc="exclude" title="Corresponding power inlets">
<t>The energy management 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 energy management standard must provide means for monitoring
the availability of power at each power inlet and at each power outlet.
This information indicates whether at a power providing outlet
power supply is switched on or off.</t>
</section>
<section toc="exclude" title="Use of power">
<t>The energy management standard must provide means for monitoring
for each power inlet and each power outlet if it is in actual use.
For the inlet this means that the powered entity actually receives power
at the inlet. For the outlet this means that power is actually
provided to one or more powered entities at the outlet.</t>
</section>
<section toc="exclude" title="Type of current">
<t>The energy management standard must provide means for
reporting the type of current (Alternating Current (AC) or
Direct Current (DC)) for each power inlet and each power
outlet of a powered entity.</t>
</section>
<section toc="exclude" title="Nominal voltage">
<t>The energy management standard must provide means for
reporting the nominal voltage for each power inlet and
each power outlet of a powered entity.</t>
</section>
<section toc="exclude" title="Nominal AC frequency">
<t>The energy management standard must provide means for
reporting the nominal AC frequency for each power inlet and
each power outlet of a powered entity.</t>
</section>
<section toc="exclude" title="Number of AC phases">
<t>The energy management standard must provide means for
reporting the number of AC phases for each power inlet and
each power outlet of a powered entity.</t>
</section>
</section>
<section anchor="power" title="Power">
<t>Power is a quantity measured as instantaneous power or
as average power over a time interval. In contrast to power
state values, this quantity may change continuously.</t>
<t>Obtaining highly accurate values for power and energy may be costly.
Often dedicated metering hardware is needed for this purpose.
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.
Measuring and estimating power must be sensitive to detect and report
if the energy is consumed or produced.</t>
<t>Depending on how power and energy consumption values are
obtained the confidence in the reported value and its accuracy
may 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>In addition to the plain real power measurements,
qualitative properties of the supplied power are of interest
from a monitoring point of view. In case of AC power supply,
there are more power values beyond the real power to be reported including
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 quality is also subject of monitoring.
Power quality 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 quality 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 required to
obtain time series of power values (or energy consumption
values). In general these could be obtained in many different
ways. It should be avoided that such time series can only be
obtained by regular polling by the energy management system.
Means should be provided to either push such values from the
place they are available to the management system or to have
them stored at the powered entity for a sufficiently long period of
time such that a management system can retrieve a stored time
series of values.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Real power">
<t>The energy management standard must provide means for
reporting the real power for each power inlet and each
power outlet of a powered entity, including whether the
energy is produced or consumed.</t>
</section>
<section toc="exclude" title="Power measurement interval">
<t>The energy management 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 energy management 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 energy management standard must provide means for
reporting the accuracy of reported power values.</t>
</section>
<section toc="exclude" title="Complex power">
<t>The energy management standard must provide means for
reporting the complex power for each power inlet and each
power outlet of a powered entity. 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 voltage and current">
<t>The energy management standard must provide means for
reporting the actual voltage and actual current for each
power inlet and each power outlet of a powered entity.
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="Actual AC frequency">
<t>The energy management standard must provide means for
reporting the actual AC frequency for each power inlet and
each power outlet of a powered entity.</t>
</section>
<section toc="exclude" title="Total harmonic distortion">
<t>The energy management standard must provide means for
reporting the Total Harmonic Distortion (THD) of voltage and
current for each power inlet and each power outlet of a
powered entity. 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 energy management standard must provide means for
reporting the impedance of power supply for each power
inlet and each power outlet of a powered entity.
In case of AC power supply, means must be provided for
reporting the impedance per phase.</t>
</section>
<section toc="exclude" title="Time series of power values">
<t>The energy management standard must provide means for
collecting time series of real power values for each power
inlet and for each power outlet of a powered entity without requiring
to regularly poll the powered entity from an energy management
station. A solution for this is that the concerned powered entity
or another powered entity closely interacting with the concerned
powered entity collect time series of power values and make them
available via push or pull mechanisms to receivers of the
information.</t>
</section>
</section>
<section anchor="energy" title="Energy">
<t>Monitoring of electrical energy consumed (or converted) at
a powered entity can be done in various ways. One is collecting
time series of power values for the powered entity and calculating
the consumed energy from these values. An alternative is the
powered entity itself or another powered entity taking care of energy
measurement and reporting energy consumption values for
certain time intervals. Time intervals of interest are
the time from the last restart of the powered entity to the reporting
time, the time from another past event to the reporting time,
or the last given amount of time before the reporting time.</t>
<t>In order to monitor energy consumption in different power
states, it is useful if powered entities record their energy
consumption per power state and report these quantities.</t>
<t>For some network management tasks, it is required to
obtain time series of energy values. In general these could
be obtained in many different ways. It should be avoided that
such time series can only be obtained by regular polling by
the energy management system.
Means should be provided to either push such values from the
place they are available to the management system or to have
them stored at the powered entity for a sufficiently long period of
time such that a management system can retrieve a stored time
series of values.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Energy">
<t>The energy management standard must provide means for
reporting the consumed energy received at a power input or
provided at a power outlet of a powered entity. Reports must be
made for a clearly specified time interval.</t>
</section>
<section toc="exclude" title="Time intervals">
<t>The energy management standard must provide means for
reporting the consumed energy of a powered entity for certain 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 energy management 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 toc="exclude" title="Time series of energy values">
<t>The energy management standard must provide means for
collecting time series of energy values for each power
inlet and for each power outlet of a powered entity without requiring
to regularly poll the powered entity from an energy management
station. A solution for this is that the concerned powered entity
or another powered entity closely interacting with the concerned
powered entity collect time series of energy values and make them
available via push or pull mechanisms to receivers of the
information.</t>
</section>
</section>
<section anchor="battery" title="Battery state">
<t>Today more and more powered entities contain batteries that
supply them with power when disconnected from electrical power
distribution grids. Common examples are nomadic and mobile
devices, such as notebook computers, netbooks, and smart phones.
The status of batteries in such a powered entity, particularly the
charging status is typically controlled by automatic functions
that act locally on the powered entity and manually by users of the
powered entity. In addition to this, there is a need to monitor
the battery status of these entities by network management
systems.</t>
<t>The management requirements discussed above in Sections
<xref target="general" format="counter"/> to
<xref target="energy" format="counter"/> concern energy-related
information on powered entities. 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>In both cases 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. Also
desirable is to receive notifications if the charge of a battery
becomes very low or if a battery needs to be replaced.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" anchor="charge" title="Battery charge">
<t>The energy management standard must provide means for reporting
the current charge of a battery.</t>
</section>
<section toc="exclude" title="Battery charging state">
<t>The energy management 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 energy management 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 energy management standard must provide means for reporting
the actual capacity of a battery.</t>
</section>
<section toc="exclude" title="Static battery properties">
<t>The energy management 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 energy management 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 energy management 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 energy management 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 title="Notifications">
<t>Often it is needed to check if values of monitored energy-related
quantities rise or fall above or below certain thresholds.
In such cases, polling these values is a very inefficient way.
Preferable, values should be checked locally and notifications
should be send when thresholds get exceeded. This can be
achieved by using generic mechanism that are not specific to
energy management.</t>
<t>Detailed Requirement:</t>
<section toc="exclude" title="High/low value notifications">
<t>The energy management standard must provide means for
creating notifications if values of measured quantities are
above or below given thresholds.</t>
</section>
</section>
</section>
<!-- Requirements related to Powered Entities Configuration ============= -->
<section anchor="control" title="Control of Powered Entities">
<t>Many powered entities control their power state locally by
self-managed dynamic adaptation to the environment. But other
powered entities without that capability need interfaces for a energy
management system to control their power states in order to
save energy. 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 from an energy
management system.</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>
<t>Detailed Requirement:</t>
<section toc="exclude" title="Controlling power states">
<t>The energy management standard must provide means for
setting power states of powered entities.</t>
</section>
<section toc="exclude" title="Controlling power supply">
<t>The energy management 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 already discussed in the introduction of
<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, such as a
Power Distribution Unit (PDU), external power meter, or a
Power over Ethernet (PoE) Power Sourcing Equipment (PSE).
Some of these entities (PDU, PSE) can also control the power
provided to the other powered entities, while some can just
report on the remote powered entities (external power meter).
This section covers reporting of information (monitoring)
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 very useful if it has a way to communicate this
information to an energy management system. This applies even
if the information only provides accumulated quantities for
several powered entities.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Reports on other powered entities">
<t>The energy management standard must provide means for
a powered entity to report energy-related 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 energy management standard must provide means for
reporting the identity of another powered entity on which
energy-related information is reported.</t>
</section>
<section toc="exclude"
title="Reporting quantities accumulated over multiple powered entities">
<t>For entities that report quantities accumulated over multiple powered
entities, the energy management 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 other entities,
the energy management standard must provide means for
reporting the complete list of 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 other entities,
the energy management standard must provide means for
indicating which energy-related information it can 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 it,
the energy management standard must provide means for the entity
to indicate which information is available at which other entities.</t>
</section>
<section toc="exclude" title="Indicating content of remote information">
<t>For an entity that has one or more other entities reporting on it,
the energy management standard must provide means for indicating
the content that other designated entities can report on it.</t>
</section>
</section>
<!-- Requirements Conttrol 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 not with these powered entities themselves, but
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 may have control of power states of other
powered entities. For example a gateway to a building network 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>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Control of power states of other powered entities">
<t>The energy management 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 energy management standard must provide means for
reporting the identities of the powered entities for which the
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 energy management 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 energy management 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 of other powered entities">
<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.</t>
<t>In addition to this, 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.</t>
<t>Detailed Requirements:</t>
<section toc="exclude"
title="Control of power supply of other powered entities">
<t>The energy management standard must provide means for
an energy management system to send power supply control
commands to a powered entity that concern the power supply of other
powered entities than the one the command was sent to.</t>
</section>
<section toc="exclude"
title="Identity of other power supply controlled powered entities">
<t>The energy management standard must provide means for
reporting the identity of another powered entity for which the
reporting powered entity has means to control the power supply.</t>
</section>
<section toc="exclude"
title="List of all power supply controlled powered entities">
<t>The energy management standard must provide means for
a powered entity to report the list of all other powered entities for which
it can control the power supply.</t>
</section>
<section toc="exclude"
title="List of all power supply controllers">
<t>The energy management standard must provide means for
a powered entity that has other powered entities controlling its power
supply to report the list of all those powered entities.</t>
</section>
</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 Sections <xref
target="control"/> and <xref 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 target="properties"/> - <xref
target="controlother"/> can be used to derive more information
than just the consumed power. Therefore, monitored data requires
privacy protection. Since the monitored data may be used as
input to control, accounting, and other actions, integrity of
transmitted information and authentication of the origin may
be needed.</t>
<t>Detailed Requirements:</t>
<section toc="exclude" title="Secure energy management">
<t>The energy management standard must provide privacy,
integrity, and authentication mechanisms for all actions
addressed in Sections <xref target="properties"/> - <xref
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="Improve references">
<t>DC power quality covered by IEC standard? <vspace/>
Is there an IEC standard on DC power quality?</t>
</section>
<section title="Do we need entity types?">
<t>Or shall we remove <xref target="type"/>?
The issue is unsolved on the mailing list.</t>
</section>
</section>
</middle>
<back>
<references title="Informative References">
&rfc1628;
&rfc3411;
&rfc3433;
&rfc3621;
&rfc3805;
&rfc4133;
&rfc4268;
&I-D.parello-eman-definitions;
&I-D.tychon-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="IEC.61850-7-4">
<front>
<title>Communication networks and systems for power 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="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="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="2005" month="June" />
</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="2009" month="September" />
</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="2010" month="October" />
</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="MODBUS-Protocol">
<front>
<title>MODBUS Application Protocol Specification V1.1b</title>
<author initials="" surname="Modbus-IDA" fullname="Modbus-IDA">
</author>
<date year="2006" month="December"/>
</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 [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 <xref target="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) is an enhancement
of LLDP known as LLDP-MED <xref target="ANSI/TIA-1057"/>.
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 01:20:17 |