One document matched: draft-ietf-eman-requirements-12.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 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.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-12"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-ietf-eman-requirements-12"
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>Germany</country>
</postal>
<phone>+49 6221 4342-115</phone>
<email>quittek@neclab.eu</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>India</country>
</postal>
<phone>+91 80 4426 3947</phone>
<email>moulchan@cisco.com</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>Germany</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>Germany</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>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author>
<date month="February" year="2013" />
<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. Monitoring functions include identification
of energy-managed devices and their components, monitoring of
their power states, power inlets, power outlets, actual power,
power properties, received energy, provided energy, and
contained batteries.
Control functions serve for controlling power supply and
power state of energy-managed devices and their components.<vspace />
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 information technology
equipment, energy management functions and interfaces are
becoming an additional basic requirement for network
management systems and devices connected to a network.</t>
<t>This document defines requirements for standards
specifications for energy management, both monitoring
functions and control functions. Subjects of energy
management are entities in the network. An entity is a device
or one of a device's components, which is subject to
individual energy monitoring and/or control.</t>
<t>In detail, the requirements listed are focused on the
following features: identification of entities; monitoring of
their power state, power inlets, power outlets, actual power,
power properties, received energy, provided energy, and
contained batteries; and control of their power supply and
power state.</t>
<t>The main subject of energy management are devices and their
components that receive and provide electric energy. Devices
may have an IP address, such as hosts, routers, and
middleboxes, or they might be connected indirectly to the Internet
via a proxy with an IP address providing a management
interface for the device. An example are devices in a building
infrastructure using non-IP protocols and a gateway to the
Internet.</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 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 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 entities and the
granularity of reporting of energy-related information.
A standard must support unique identification of
entities, reporting per entire device, and reporting
energy-related information on individual components of a
device or subtended devices.</t>
<t><xref target="properties"/> specifies requirements
related to monitoring of 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
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 entity it is not
always sufficient to communicate with the entity
only. When the 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 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 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 (sometimes called an energy management
system or controller). Requirements in this document do not cover
details of these networks and devices, but specify means
for opening IP network management towards them.</t>
<!--
<t>For monitoring entities, as their number
becomes large, it is sometimes not a scalable approach
to communicate directly with all entities directly
from a central Energy Management System.</t>
-->
</list></t>
<t>These specific issues 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 be implemented by compliant
implementations.
</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t><list style="hanging">
<t hangText="Energy"><vspace blankLines="1"/>
That which does work or is capable of doing work. As used
by electric utilities, it is generally a reference to
electrical energy and is measured in kilo-watt hours (kWh)
<xref target="IEEE-100"/>.</t>
</list></t>
<t><list style="hanging">
<t hangText="Power"><vspace blankLines="1"/>
The time rate at which Energy is emitted, transferred, or
received; usually expressed in watts (or in joules per
second) <xref target="IEEE-100"/>.</t>
</list></t>
<t><list style="hanging">
<t hangText="Energy Management"><vspace blankLines="1"/>
Energy Management is a set of functions for measuring,
modeling, planning, and optimizing networks to ensure that
the network elements and attached devices use energy
efficiently and in a manner appropriate to the nature of the
application and the cost constraints of the organization
<xref target="ITU-M.3400"/>.</t>
</list></t>
<t><list style="hanging">
<t hangText="Energy Management System"><vspace blankLines="1"/>
An Energy Management System is a combination of hardware
and software used to administer a network with the primary
purpose being Energy Management
<xref target="Fed-Std-1037C"/>.</t>
</list></t>
<t><list style="hanging">
<t hangText="Energy Monitoring"><vspace blankLines="1"/>
Energy Monitoring is a part of Energy Management that deals
with collecting or reading information from network elements
and attached devices and their components to aid in Energy
Management.</t>
</list></t>
<t><list style="hanging">
<t hangText="Energy Control"><vspace blankLines="1"/>
Energy Control is a part of Energy Management that deals
with controlling energy supply and power state of network
elements and attached devices and their components.</t>
</list></t>
<!-- <t><list style="hanging">
<t hangText="Entity"><vspace blankLines="1"/>
An entity is either a device or one of a device's
components that is subject to Energy Monitoring or Control
or both.</t>
</list></t> -->
<t><list style="hanging">
<t hangText="Power Interface"><vspace blankLines="1"/>
A Power Interface is an interface at which a device is
connected to a Power transmission medium at which it can
receive Power, provide Power, or both.</t>
</list></t>
<t><list style="hanging">
<t hangText="Power Inlet"><vspace blankLines="1"/>
A Power Inlet is a Power Interface at which a device
can receive Power from other devices.</t>
</list></t>
<t><list style="hanging">
<t hangText="Power Outlet"><vspace blankLines="1"/>
A Power Outlet is a Power Interface at which a device
can provide Power to other devices.</t>
</list></t>
<t><list style="hanging">
<t hangText="Power State"><vspace blankLines="1"/>
A Power State is a condition or mode of a device that
broadly characterizes its capabilities, Power consumption,
and responsiveness to input <xref target="IEEE-1621"/>.
</t>
</list></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>
Entities can be set to an operational state that
results in the lowest power level that still meets the
service level performance objectives. In principle, there
are three basic types of Power States for an 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 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. Examples are various operational low power
states in which a device requires less energy than in the
full power "on" state, but - compared to the sleep state -
is still operational with reduced performance or
functionality.</t>
</section>
<section anchor="tradeoffs"
title="Saving Energy Versus Maintaining Service Level">
<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 without the
consequence of a potential service (performance or capacity)
degradation. In this case, a trade-off needs to be made
between service level objectives and energy minimization.
In other cases a reduction of power can
easily be achieved while still maintaining
sufficient service level performance, for example, by
switching 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
an entity; it
monitors its usage and dynamically adapts its Power
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
Power received and provided by entities in different
Power States may be required to set policies. 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 functional load of an entity.</t>
</section>
<section anchor="monitoring"
title="Energy Monitoring Versus Energy Saving">
<t>Monitoring Energy, Power,
and Power States alone does not reduce the Energy
needed to run an entity. In fact, it may even
increase it slightly due to monitoring instrumentation that
needs 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 Energy and Power States
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 received and provided by
an entity, a network, or a service</t>
<t>predicting an entity's reliability based on
Power usage</t>
<t>choosing time of next maintenance cycle for an
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 conversion rate)</t>
<t>monitoring (accumulated) received and provided
Energy</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 received and provided
Energy can provide useful data for developing these
technologies.</t>
</section>
</section>
<!-- Requirements related to Identity of entities ========= -->
<section anchor="identity"
title="Identification Of Entities">
<t>Entities must be uniquely identified. This
includes entities that are components of managed devices
as well as entire devices.</t>
<t>For entities
that report on or control other entities it is
important to identify the entities they report on or
control, see <xref target="reportonother"/> or
<xref target="controlother"/>, respectively.</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 received and provided Energy
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 received and provided Energy
only for the entire device.</t>
<section toc="exclude" title="Identifying Entities">
<t>The standard must provide means for uniquely identifying
entities. Uniqueness must be preserved such that
collisions of identities are avoided at potential receivers
of monitored information.</t>
</section>
<section toc="exclude"
title="Persistence Of Identifiers">
<t>The standard must provide means for
indicating whether identifiers of entities are
persistent across a re-start of the entity.</t>
</section>
<section toc="exclude" title="Change Of Identifiers">
<t>The standard must provide means to indicate
any change of entity identifiers.</t>
</section>
<section toc="exclude"
title="Using Entity Identifiers Of Existing MIB Modules">
<t>The standard must provide means for
re-using entity identifiers from existing 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 entities monitoring === -->
<section anchor="properties"
title="Information On Entities">
<t>This section describes information on entities for
which the standard must provide means for retrieving and
reporting.</t>
<t>Required information can be structured
into seven 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 entities, such as type of
entity or context information. Requirements for information
on Power Inlets and Power Outlets of 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="state"/> covers requirements
related to entities' Power States. <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 Entities">
<t>For Energy Management it may be required to understand
the role and context of an entity. An Energy
Management System may aggregate values of received and
provided Energy 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 an
entity in a network, for example, it may be
important to exclude some mission critical network devices
from being switched to lower Power or even from being
switched off.</t>
<section anchor="type" toc="exclude"
title="Type Of Entity">
<t>The standard must provide means to configure, retrieve
and report a textual name or a description of an
entity.</t>
</section>
<section anchor="role" toc="exclude"
title="Context Of An Entity">
<t>The standard must provide means for retrieving and
reporting context information on entities, for
example, tags associated with an entity that
indicate the entity's role.</t>
</section>
<section anchor="importance" toc="exclude"
title="Significance Of Entities">
<t>The standard must provide means for retrieving and
reporting the significance of entities within its
context, for example, how important the entity is.
</t>
</section>
<section anchor="priority" toc="exclude"
title="Power Priority">
<t>The standard must provide means for retrieving and
reporting Power priorities of entities. Power
priorities indicate an order in which Power States of
entities are changed, for example, to lower
Power States for saving Power.</t>
</section>
<section toc="exclude" title="Grouping Of Entities">
<t>The standard must provide means for grouping entities.
This can be achieved in multiple ways, for example, by
providing means to tag entities, to assign them to
domains, or to assign device types to them.
</t>
</section>
</section>
<section anchor="inlet" title="Power Interfaces">
<t>A Power Interface is an interface at which a device is
connected to a Power transmission medium at which it can
receive Power, provide Power, or both.</t>
<t>A Power Interface is either an inlet or an outlet.
Some Power Interfaces change over time from being an inlet
to being an outlet and vice versa. However most Power
Interfaces never change.</t>
<t>Devices have Power Inlets at which they are
supplied with electric Power. Most devices 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 device, the availability of Power at inlets
and which of them are actually in use.</t>
<t>Devices can have one or more Power Outlets for
supplying other devices 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 device 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 devices.</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. Note that often the nominal voltage is not a single
value but a voltage range, such as, for example, (100V-120V),
(100V-240V), (100V-120V,220V-240V).</t>
<section toc="exclude"
title="Lists Of Power Interfaces">
<t>The standard must provide means for monitoring
the list of Power Interfaces of a device.</t>
</section>
<section toc="exclude"
title="Operational Mode Of Power Interfaces">
<t>The standard must provide means for monitoring
the operational mode of a Power Interface which is
either "Power Inlet" or "Power Outlet".</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 Interface if it is in actual use.
For inlets this means that the device actually
receives Power at the inlet. For outlets this means that
Power is actually provided from it to one or more
devices.</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 as well as
for a device.</t>
</section>
<section toc="exclude" title="Nominal Voltage Range">
<t>The standard must provide means for reporting the
nominal voltage range 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.
Entities without the ability to measure their Power
and received and provided Energy with high accuracy may just
report estimated values, for example based on load
monitoring, Power State, or even just the entity type.</t>
<t>Depending on how Power and Energy values are
obtained, the confidence in the reported value and its
accuracy will vary. 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 Power supplied to a device
are also of interest. Particularly for AC Power supply,
several Power properties beyond the real Power are of
potential interest to Energy Management Systems.
The set of these properties include the the complex
Power properties (apparent power, reactive power, and
phase angle of the current or power factor) as well as
the actual voltage, the actual AC frequency, the Total
Harmonic Distortion (THD) of voltage and current, and the
impedance of an AC phase or of the DC supply. A new
standard for monitoring these Power properties should be
in line with already existing standards, such as
<xref target="IEC.61850-7-4"/>.</t>
<t>For some network management tasks it is desirable to
receive notifications from 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 as well
as for an entity. Reporting Power includes reporting 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 indicate the
method how these values have been obtained. Based on how
the measurement was conducted, it is possible to associate
a certain degree of confidence with 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 an 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 as well as for a device.
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 an entity rise
above or fall below given thresholds.</t>
</section>
<section toc="exclude" title="Complex Power / Power Factor">
<t>The standard must provide means for reporting the
complex power for each Power Interface and for each phase
at a 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.
</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 entities have a limited number of discrete
Power States.</t>
<t>There is a need to report the actual Power State
of an 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 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 entity, the Energy
Management standard must provide means for supporting
multiple Power State sets used simultaneously at an
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 the typical Power of an entity in a
certain state.</t>
<t>There also is a need to report statistics on Power States
including the time spent and the received and provided
Energy 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 an 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 an 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 an 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 an 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 an entity for each
supported Power State set.</t>
</section>
<section toc="exclude"
title="Typical Power Per Power State">
<t>The standard must provide means for retrieving the
typical Power for each supported Power State.</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 an
entity changes.</t>
</section>
</section>
<section anchor="Energy" title="Energy">
<t>Monitoring of electrical Energy received or provided by
an 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
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 entities to record their
received and provided Energy per Power State and report
these quantities.</t>
<section toc="exclude" title="Energy">
<t>The standard must provide means for reporting measured
values of Energy and the direction of the Energy flow
received or provided by an entity. The
standard must also provide the means to report the Energy
passing through each Power Interface.</t>
</section>
<section anchor="timeintervals" toc="exclude"
title="Time Intervals">
<t>The standard must provide means for reporting the
time interval for which an Energy value is reported. </t>
</section>
<section anchor="energyperstate" toc="exclude"
title="Energy Per Power State">
<t>The standard must provide means for reporting the
received and provided Energy for each individual 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 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 entity and manually by users of the
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 entity
on which Energy-related information is reported or the
battery can be modeled as an individual 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, it's temperature, 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="Actual Battery Capacity">
<t>The standard must provide means for reporting
the actual temperature 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 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 from entities,
such as Power, Energy, battery charge, etc.</t>
<t>In general time series measurements 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>The following issues are to be considered when designing
time series measurement and reporting functions:
<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 quantity
is Energy. But a need for others, such as Power and
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, Energy
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>For reporting time series of measured values the
following requirements have been identified. Further
decisions concerning issues discussed above need to be
made when developing concrete Energy Management
standards.</t>
<section toc="exclude" title="Time Series Of Energy Values">
<t>The standard must provide means for reporting time
series of Energy values.</t>
</section>
<section toc="exclude" title="Time Series Interval Types">
<t>The standard must provide means for supporting
alternative interval types. Requirement <xref
format="counter" target="timeintervals"/> applies to every
reported time value.</t>
</section>
<section toc="exclude" title="Time Series Storage Capacity">
<t>The standard should provide means for
reporting the number of values of a time series that can
be stored for later reporting.</t>
</section>
</section>
</section>
<!-- Requirements related to Entity Control ================ -->
<section anchor="control" title="Control Of Entities">
<t>Many entities control their Power State locally.
Other entities need interfaces for an Energy
Management System to control their Power State.</t>
<t>Power supply is typically not self-managed by devices.
And controlling Power supply is typically not conducted as
interaction between Energy Management System and
the device itself. It is rather an interaction between
the management system and a device 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
device.</t>
<section toc="exclude" title="Controlling Power States">
<t>The standard must provide means for
setting Power States of 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 Interfaces
providing Power to one or more device.</t>
</section>
</section>
<section anchor="reportonother"
title="Reporting On Other Entities">
<t>As discussed in <xref target="properties"/>, not all
Energy-related information may be available at the concerned
entity. Such information may be provided by other
entities. This section covers reporting of
information only. See <xref target="controlother"/> for
requirements on controlling other entities.</t>
<t>There are cases where a Power supply unit switches Power
for several entities by turning Power on or off at a
single Power Outlet or where a Power meter measures the
accumulated Power of several entities at a single
power line. Consequently, it should be possible to report
that a monitored value does not relate to just a single
entity, but is an accumulated value for a set of
entities. All of these entities belonging to
that set need to be identified.</t>
<!--
<t>If an 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 entities.</t>
-->
<section toc="exclude"
title="Reports On Other Entities">
<t>The standard must provide means for an entity to
report information on another entity. </t>
</section>
<section toc="exclude"
title="Identity Of Other 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 entities on which information is reported.
Note that, in some situations, a manual configuration might
be required to populate this information.
</t>
</section>
<section toc="exclude"
title="Reporting Quantities Accumulated Over Multiple Entities">
<t>The standard must provide means for reporting the list
of all entities from which contributions are
included in an accumulated value.</t>
</section>
<section toc="exclude"
title="List Of All 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 entities on which Energy-related
information can be reported.</t>
</section>
<section toc="exclude"
title="Content Of Reports On Other 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 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 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 entities ====== -->
<section anchor="controlother"
title="Controlling Other Entities">
<t>This section specifies requirements for controlling
Power States and power supply of entities by
communicating with other entities that have means for
doing that control.</t>
<section anchor="statecontrol"
title="Controlling Power States Of Other Entities">
<t>Some entities have control over Power States of
other entities. For example a gateway to a building
system may have means to control the Power State of
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 an entity
that has its state controlled by other entities has
means to report the list of these other entities.
</t>
<section toc="exclude"
title="Control Of Power States Of Other Entities">
<t>The standard must provide means for an Energy
Management System to send Power State control commands to
an entity that concern the Power States of entities other
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 entities for which the reporting
entity has means to control their Power States.
Note that, in some situations, a manual configuration
might be required to populate this information.
</t>
</section>
<section toc="exclude"
title="List Of All Power State Controlled Entities">
<t>The standard must provide means for an entity to
report the list of all 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 an entity
that receives commands controlling its Power State from
other entities to report the list of all those
entities.</t>
</section>
</section>
<section anchor="supplycontrol"
title="Controlling Power Supply">
<t>Some entities may have control of the Power
supply of other entities, for example, because the
other entity is supplied via a Power Outlet of the
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 an entity that
has its supply controlled by other entities has
means to report the list of these other 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
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 an entity
addressed in Sections <xref format="counter"
target="properties"/> - <xref format="counter"
target="controlother"/> can be used to derive more information
than just the received and provided Energy, so monitored data
requires protection. This protection includes authentication
and authorization of entities requesting access to monitored
data as well as privacy protection during transmission of
monitored data. 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="Acknowledgments">
<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>
</middle>
<back>
<references title="Normative References">
&rfc3411;
&rfc3621;
&rfc4133;
<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="IEEE-100">
<front>
<title>
Authoritative Dictionary of IEEE Standards Terms,
IEEE 100, Seventh Edition
</title>
<author initials=""
surname="IEEE"
fullname="IEEE">
</author>
<date year="2000" month="December" />
</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 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="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>
</references>
<references title="Informative References">
&rfc5101;
&rfc5102;
&I-D.ietf-eman-applicability-statement;
<reference anchor="Fed-Std-1037C">
<front>
<title>
Federal Standard 1037C - Telecommunications:
Glossary of Telecommunication Terms
</title>
<author initials=""
surname="United States National Communications System Technology & Standards Division"
fullname="United States National Communications System Technology & Standards Division">
</author>
<date year="August 1996"/>
</front>
</reference>
<reference anchor="ITU-M.3400">
<front>
<title>
ITU-T Recommendation M.3400 - Series M: TMN and Network
Maintenance: International Transmission Systems,
Telephone Circuits, Telegraphy, Facsimile and Leased
Circuits - Telecommunications Management Network -
TMN management functions
</title>
<author initials=""
surname="International Telecommunication Union"
fullname="International Telecommunication Union">
</author>
<date year="February 2000"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:19 |