One document matched: draft-nordman-eman-energy-perspective-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY id.draft-ietf-eman-framework-00 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-framework-00.xml">
<!ENTITY id.draft-ietf-eman-requirements-00 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-requirements-00.xml">
<!ENTITY id.draft-quittek-eman-reference-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-quittek-eman-reference-model-01.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="draft-nordman-energy-perspective-00"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-nordman-eman-energy-perspective-01" ipr="trust200902">
<front>
<title>Energy perspective on applicability</title>
<author fullname="Bruce Nordman" initials="B."
surname="Nordman">
<organization>Lawrence Berkeley National Laboratory</organization>
<address>
<postal>
<street>1 Cyclotron Road, 90-4000</street>
<code>94720-8136</code>
<city>Berkeley</city>
<country>US</country>
</postal>
<phone>+1 510 486 7089</phone>
<email>bnordman@lbl.gov</email>
</address>
</author>
<date month="March" year="2011" />
<abstract>
<t>This memo discusses applicability for energy management features
to various types of devices and buildings.
It describes the variety of applications that can use the EMAN energy framework
and associated MIB modules. P otential examples are building networks, home energy
gateway, etc. Finally, the document will also discuss relationships of
the framework to other architectures and frameworks (such as smartgrid).
The applicability statement will explain the relationship between the
work in this WG and the other existing standards such as those from the
IEC, ANSI, DMTF, and others.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The EMAN framework describes functionality for reporting of
energy information in an Internet Protocol network.
Monitoring is a critical
first step towards energy management more generally, including control.
Other Internet Drafts describe the requirements, framework, and implementation
of this system. This document reviews how it is expected to be used, and
how it relates to other activities regarding energy and information technology.</t>
<t>This document is intended to be useful to a wide set of audiences, including
those with energy as a primary interest (who do not necessarily have any background
in networking), the more usual network-centric audience in the IETF (who may have
not connection to energy issues), and many whose knowledge and interest is
intermediate.</t>
<section title="Eman overview">
<t>The most basic example of energy management is a single device reporting only basic information
about its own energy status; these "simple devices".
The information is reported directly to a Network Management System (NMS).
</t>
<t>The framework also provides additional features for collecting information from devices
intermediate between the NMS and end-use devices.
These intermediate devices ("complex devices") may have
capabilities for monitoring or control, may serve to collect information from many
devices for more efficient data transfer, may process the data (e.g. by summing across
many devices), or any combination of these. The same protocol is used whether the NMS
is communicating with an intermediate or end use device. The same protocol may be used
between an intermediate and end use device.</t>
<t>This protocol does not define anything about the network management system,
but only identifies it as the recipient of information.
The NMS will commonly have an entire single building as its scope, though in
some cases will cover only a part of a building, or multiple buildings.
Usually the NMS will be scoped to match the reach of the local area network
it is part of.</t>
<t>All devices are in scope, whether they are traditional IT products like computers or
network equipment, or other energy-using devices that are only now beginning to get
IP connections, such as appliances, lighting, and climate control systems.
(Devices that are only ever powered by batteries, such as sensor nodes, could use
this protocol, but are not a target).</t>
<t>The other eman documents are authoritative for specific technical content.</t>
</section>
<section title="Usage overview">
<t>The basic usage of the eman protocol is a building operator installing software
for collecting eman informatin on an existing device in the building, e.g. a personal
computer, a server, or piece of network equipment. This software is the Network
Management System (NMS) for eman; it can be implemented by extending an existing
NMS that performs other functions, or by software that only deals with energy issues. </t>
<t>The NMS begins by probing the local area network to discover devices that respond to
eman queries. It first discovers what devices are on the network at all, then determines
the subset that implement eman. It then requests all information from each eman reporting
device; much of which is static so does not need to be requested again.</t>
<t>The NMS then determines how often to query each device for updates to the energy
information. This will likely vary by building type and device type, and the
period could range from monthly to once per minute. The frequency of interrogation
is entirely up to the NMS and can change dynamically as the NMS deems necessary.
Only a small amount of data needs to be provided for the periodic reporting.</t>
<t>Some devices will fail to report some of the time, either because they are in
a low-power state which does not include the ability to do eman reporting, or
because they are portable and only sometimes in the building (e.g. a notebook computer).
Occasionally, a device will leave the building permanently.</t>
<t>The NMS needs to periodically scan for new eman devices, and query for all devices
for characteristics that could in principle change, but do so infrequently or never.</t>
<t>Finally, the NMS will digest the reported information into forms readily understood
by people. Esxample include summaries by type of device ("energy end uses") based on
the reported identity information, or by location within the building.
Also, a NMS may detect suspected or known anomalous energy usage and highlight
that, in case it represents equipment malfunction or inefficient or insufficient operation.
Electricity pricing is becoming increasingly dynamic, so that the simple translation
from quantity of energy to economic cost is becoming more complex.
The ability of eman to enable tracking energy use over time provides for
incorporating the time dimension of electricity use into both monitoring and control.</t>
</section>
</section>
<section title="Terminology">
<t>This section reviews select terms used in this draft.
</t>
<section title="Building Network">
<t>Traditional IT local networks are made up of entities that provide
information services. Future Building Networks will not be separate
from the IT network, but will incorporate many devices whose primary
function is not information, such as those that provide light, regulate
temperature or ventilation, and appliances. A building network is IP-based
and enables full inter-operation of IT and non-IT devices.</t>
<t>Traditional building control systems were developed before IP networking,
often have limited scope in the services they address, and are often based
on proprietary technologies.
</t></section>
<section title="Network Management System">
<t>A Network Management System (NMS) is the entity which requests information
from energy-using devices. It may be a system which also implements other
network management functions, or one that only deals with energy.
It may be limited to monitoring energy use, or it may implement control
functions (based on eman, other protocols, or both).
</t></section>
<section title="Energy">
<t>At present, the eman framework only addresses electricity use.
It is plausible, and likely, that a future version of it will extend to
other forms of energy (e.g. methane, steam, and hot/cold water), and
even to non-energy quantities (e.g. temperature and flow).
</t></section>
</section>
<section title="Use Contexts">
<t>This section reviews the applications that the framework is intended
to be suitable for. These vary according to the nature of devices involved,
and the institutional environment (building type, management approach,
and purpose).
The other documents specify nothing about the network management system (NMS).</t>
<section title="Management context">
<t>Buildings vary in scale from those with thousands of occupants, down
to those with few or even none, with similar ranges in relevant floor areas.
Some of these buildings have people with a job function that specifically covers
energy management, and in others, no one actively pays attention to the topic.</t>
<section title="Highly managed">
<t>Some network environments are closely monitored for what devices are introduced to it,
their characteristics and capabilities, and the functions they provide; many data centers
are managed this way. These are more likely to use advanced features of energy management
technology, including accounting for multiple power supplies for products, use of power
control, and more attention to power distribution. They also are more likely to be
concerned with power quality characteristics.</t>
<t>The NMS in these contexts may be integrated with systems for functional control of
devices. For a data center, the primary focus is the IT equipment it contains, though
the devices that provide power (reliability, conditioning, distribution, and/or control)
and those that do space conditioning are also likely to be monitored through the NMS.
Monitoring data may be obtained frequently to closely track a dynamic usage environment.</t>
</section>
<section title="Loosely managed">
<t>Other environments are not actively managed at all. Devices enter or leave the network
on their own terms, and are fundamentally autonomous. Power control is not utilized at all,
and the goal of the energy management facility is to simply understand what is going on,
not to actively manage it. Most residential buildings are an example of this type of network,
where there is no personnel or procedures for active network management. Power quality and
capacity are essentially never a concern.</t>
<t>The NMS in a loosely managed environment should be as automatic as possible, so that the
user can get useful information with little or no effort. No functional control is involved.
Such environments will have a mixture of devices that can report power information as well as many
that cannot. The NMS is principally tracking long-term trends and so information gathering
is usually not frequent. </t>
</section>
<section title="Hybrids">
<t>Most network environments have elements of these two extremes, both sets of devices
of each sort, as well as devices that are managed in an intermediate form.
Commercial buildings are commonly of this form, with some devices being highly
managed, and others only loosely tracked.</t>
<t>The NMS for a hybrid must be able to accomodate a diverse set of devices and is likely
to track some closely, and others much less so.</t>
</section>
</section>
<section title="Building types">
<t>The EMAN facility is designed to be used in any building type (though the specific
needs of industrial buildings have not yet been considered). Core building types are
residential, commercial, and vehicle. In the United States, buildings account for just
over 70% of electricity use, with this split almost evenly between residential and
commercial.</t>
<t>The cases of multi-tenant buildings (residential and commercial) noted below
raise the possibility of a device reporting to more than one NMS.</t>
<section title="Residential">
<t>Residential buildings usually have no existing infrastructure for reporting
energy use of devices within them. There are products available that can monitor
and track whole-building use, either from added hardware, or by leveraging a
communicating meter. However, this gives no visibilty to how much electricity is
being consumed by each device. There are expensive systems available for houses
that integrate control of many systems (e.g. climate control, lighting, security,
entertainment) that can incorporate tracking of usage times and so well approximate
energy use, but these are generally proprietary and not IP-based.</t>
<t>Residential buildings that incorporate multiple units are best dealt with
as each unit being a separate building for NMS purposes. Privacy and security
both preclude sharing much information outside the NMS, except for services that
are centrally provided (e.g. hot water or space conditioning). Such buildings also have
energy used in common areas and for common functions.
</t>
<t>The term Home Energy Gateway is sometimes used to denote a demarcation point
between devices in a building and the outside world. These gateways can also
perform some active monitoring and control functions.
There is no need for the architecture of a building network to be different
in houses from other building types so that this is really just a specific
example of a building network gateway.</t>
</section>
<section title="Commercial">
<t>Commercial buildings vary enormously in scale, with some smaller than a
typical house, to entire campuses of multi-story buildings. Smaller buildings
share many characteristics with houses in terms of technology and management
styles. Larger buildings usually have some sorts of building control systems,
though usually there are several systems for individual types of functions,
and most are not IP-based. Thus, while some energy information can usually
be extracted digitally, it is usually not comprehensive, and often derived
from proprietary systems.
With increasing building size, it is more likely that someone has energy management
as an explicit job function.</t>
<t>Some commercial buildings have the multi-tenant character of some residential
buildings, though the degree to which services are the responsibility of the
building owner is usually greater than with residential.</t>
</section>
<section title="Data Centers">
<t>A data center is technically an industrial building, but for eman purposes it has
special interest and so is treated separately.
These are highly managed environments and are most likely to use the most advanced
and complex features of eman, and have more sophisticated mechanisms for power
distribution and control, including use of power distribution units.
They are also likely to see the quickest uptake of the protocol.
Thus, their importance for eman is out of scale with their portion of
global electricity use (a few percent).</t>
</section>
<section title="Other industrial buildings">
<t>Industrial buildings in general use electricity for both process and non-process
loads. Non-process loads are similar to those in other building types.
Process loads have not yet been considered in the eman process.</t>
</section>
<section title="Vehicles">
<t>While it may initially seem curious to treat automobiles, airplanes, and boats
as types of buildings, for purposes of energy management, it is quite appropriate.
They are generally self-contained structures with electricity distribution for a
variety of uses (some infrastructure and some occupant oriented). Electricity is
typically more expensive in energy and carbon terms than for fixed buildings and
may have constrained capacity, so the reason to be concerned with energy
management is even greater with vehicles.
Many vehicles can connect to the electricity grid when stationary.</t>
</section>
</section>
<section title="Device types">
<t>The EMAN facility is designed to be used for any device type.
Its design and usage specifically takes account of two primary types: electronic
devices, and all others.</t>
<section title="Information technology">
<t>For many years, the only devices on IP networks were computers
and network equipment. To these were added other types of information
technology devices, such as printers and storage.
These devices are at the core of EMAN and
will see the widest initial use of EMAN reporting.</t></section>
<section title="Other electronic devices"><t>
Information technology is a specific subset of the general category of
"electronic" devices - those which have information as their primary function.
Even televisions have a primary purpose of displaying information, and thus
the traditional category of entertainment consumer electronics can be logically
grouped under information technology.
These devices are seeing rapid uptake of IP connectivity, and the distinction
between IT and other electronic devices blurring.</t>
</section>
<section title="Non-electronic devices">
<t>"Electronics" are devices whose primary function is information so that
"non-electronics" is everything else in buildings, such as lighting, appliances,
and equipment for space conditioning. This term does not imply that they have
no electronic components.</t>
</section> </section>
</section>
<section title="Other topics">
<t>This section explores other topics relevant to energy management and eman.</t>
<t>
</t>
<section title="Power distribution">
<t>An aspect of energy reporting that may not be initially apparent is how it can support
understanding of power distribution systems. That is, different collections of devices
in a building may be in different 'domains' of electricity distribution, with a common
fate (e.g. downstream of a circuit breaker), or under the same electricity meter.
This is accomplished two ways: via reporting by products which have a power distribution
function themselves (e.g. a Power Distribution Unit or an Ethernet switch that supports
Power over Ethernet), or by products self-identifying the domain they are a part of (usually
by manual configuration).</t>
<t>In the past, few buildings had complex power distribution, with most simply a tree
of circuit breakers, and just a few levels of AC power utilized.
Today, an increasing number have additional features, such as uninterruptable
power supplies, low-voltage DC powered devices, local generation, and storage.
Power reporting mechanisms such as eman will need to have some understanding of these
features.</t>
</section>
<section title="Discovery">
<t>
A Network Management System requires some method of collecting a list of the entities on the
network that it needs to be cognizant of, both when it initially begins operation, and maintaining
this on an ongoing basis as the population of devices evolves.
There are three basic methods: protocol, manual, and opportunistic. A NMS can utilize more than
one method.</t>
<t>In the protocol approach, the NMS periodically broadcasts a request for any EMAN reporting entity to
identify itself to the NMS. For each entity that replies, the NMS queries it for the specific
information it has. </t>
<t>In the manual approach, the identity of each device to be managed is provided to the NMS.
Usually, additional information will also be provided, such as functional relationships among
devices, policies to be employed (e.g. prioritization of the importance of each device), and
control strategies (e.g. under what conditions a device should be have its power supply removed
or reinstated). </t>
<t>In the opportunistic approach, the NMS observes the network to notice when a new device appears,
then queries it for EMAN capabilities. </t>
<t>A NMS may also participate in one or more service discovery protocols to determine when a
new device appears, though as none of these protocols are universal, this will always be an
incomplete method. A NMS also has to deal with the fact that some devices will eventually
disappear from the network and need to be expired from its databases. Also, some devices will
be only intermittently on the network, either from being physically absent some of the time,
or powered down to a low-power state in which they can't respond to EMAN queries. </t>
</section>
<section title="Identity">
<t>Eman needs to report basic characteristics of the "identity" of a device for the NMS
to know how to interpret the information.
That is, while the IP and MAC addresses of a device are essential to know, they are
by no means sufficient.
Other aspects of identity include what a device is (a general category as a person would
describe it), its brand and model, and a locally determined name useful for building occupants.
</t>
</section>
</section>
<section title="Related Standards and Activities">
<t>This section reviews related standards and other activities that have some relationship
to the EMAN protocol.
A key point is that eman reports data on individual devices.
Many standards are oriented to entire buildings or other large entities.</t>
<section title="Standards that inform measurement">
<t>There are many energy test procedures for specific products. These generally are for
tests conducted in laboratory conditions in specified configurations to assess energy
performance for comparison to other models or criteria levels. However, EMAN measurements
are not conducted in a laboratory, not under such specified conditions, and need to be
universal across all products, so a "horizontal" test procedure is more relevant.
The most widely used of these is <xref target="IEC-62301">IEC 62301</xref> on measurement of standby power
.
While 62301 was created by a committee with a mandate on household appliances, it has
been designed to be universal for any product commonly found in residential or commercial
buildings, and is referenced in test procedures for appliances, electronics, and other
devices.
It was originally published in 2005, with a second edition finalized in 2011.</t>
</section>
<section title="Standards that inform reporting">
<t>Energy reporting over networks is a relatively new service. Few devices had the hardware
ability to measure power, and few of the rest made an attempt to estimate it. Further,
for power state, devices could only report when they were fully on, so never could report
themselves when in a low power state. Finally, the ability to remotely apply or remove
power from a device has been confined to very specific usage environments.</t>
<section title="DMTF">
<t>The Distributed Management Task Force (DMTF) has specified communication of power state
information.</t>
<t>The DMTF Common Information Model (CIM) includes information about power states.</t>
</section>
<section title="Ecma SDC">
<t>The Ecma International committee on Smart Data Centre (<xref target="Ecma-SDC">TC38-SDC</xref>)
is in the process of
defining semantics for management of entities in a data center such as servers, storage,
network equipment, etc.
It covers energy as one of many functional resources or attributes of systems
for measurement and/or control. It only defines terms and variables, and does not reference
any specific protocol. Its goal is to enable interoperability of such protocols by ensuring
a common semantic model across them.</t>
<t>The SDC process is still underway, with a timeframe similar to EMAN. There seems to be
no fundamental barrier to the two efforts to harmonize on aspects they have in common.
These include identity, power states, power levels, accumulated energy use, and tracking
of time.</t>
</section>
</section>
<section title="Other Standards and Activities">
<t>While manufacturers may implement EMAN capabilities in their products, their are other
organizations that may also do this.
Future standards may reference EMAN as functionality that more comprehensive systems rely
on (e.g. using reported power state for functional purposes).
They may also define extensions to or particular uses of the EMAN facility.</t>
<t>In future, energy standards, both voluntary and mandatory, may reward or require use
of EMAN capabilities. For example, the Energy Star program already references other specific
network technologies in a variety of its specifications. In fact, the initial
<xref target="ESTAR">framework document for revising the Energy Star Computer specification</xref> references
the IETF eman activity .
The most likely use of EMAN would
be simply for a device to be able to report on its own basic status as defined by EMAN,
such as identity, power state, power level, and accumulated energy. </t>
<section title="Smart Grid">
<t>There are many definitions of what constitutes the "Smart Grid". In the most general
sense, it is the application of information technology to our electricity system, so that the
EMAN framework is an excellent example of that. Alternatively, it can describe using
information technology to improve the electricity grid, from the power plant through
transmission and distribution systems and ending at the meter. In this case, the EMAN
framework has no connection to the Smart Grid. The most common definitions of the
Smart Grid acknowledge that what occurs in buildings is different from the utility-managed
grid, but specify some communication directly between the grid and end-use devices.
The EMAN framework does not anticipate communication with entities outside the building,
but rather only with a local NMS. The NMS could communicate with the grid, but that is
well outside the EMAN scope and framework.
End-use devices can still coordinate with the grid through other protocols, either in
one-way communication (receiving demand response or direct price signals from the grid),
or in two-way communication with the grid.
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>The energy management facilities discussed here raise a number of security considerations.
While not a part of the current drafts, the ability of one device to control the power state
of a second connected device can be a problem if they do not share the same management goal.
This can be either the act of powering down a device (e.g. from on to sleep or off), rendering
it unable to perform ordinary services it might otherwise accomplish, or powering the device
up, and consequently using energy resources not otherwise desired. Beyond control, simple
information about the current or historic energy use of a device can indicate details of
occupancy of the main person using the device, or of applications running on the device.
</t>
<t>The capabilities described in this document do not introduce any new capabilities for security.
Rather, any device that implements them must use existing security intrastructure and
policies.
</t>
</section>
<section title="IANA Considerations">
<t>This memo creates several possible actions for IANA.
First is a single canonical listing of "identity" of a device, in terms of what it is.
Second is possible enumeration of power states, and/or functional states.</t>
</section>
<section title="Acknowledgements">
<t>This memo was inspired by discussions with Benoit Claise,
Emmanual Tychon, Juergen Quittek, Chris Verges,
John Parello, Rolf Winter, and
Bill Mielke.</t>
</section>
</middle>
<back>
<references title="Informative References">
&id.draft-quittek-power-monitoring-requirements;
&id.draft-claise-power-management-arch;
&rfc3410;
<reference anchor="IEC-62301">
<front>
<title>IEC 63301 - Measurement of Standby Power</title>
<author initials="" surname="IEC TC 59 / MT 9"
fullname="IEC 62301 Maintenance Team"></author>
<date year="2011" month="February" />
</front>
</reference>
<!-- <reference anchor="IEEE-1621">
<front>
<title>IEEE Std 1621 - Power Control User Interfaces</title>
<author initials="" surname="IEEE 1621 Working Group"
fullname="IEEE 1621 Working Group"></author>
<date year="2009" month="December" />
</front>
</reference>
-->
<reference anchor="Ecma-SDC">
<front>
<title>Smart Data Centre Resource Monitoring and Control (DRAFT)</title>
<author initials="" surname="Ecma TC38 / SDC Task Group"
fullname="Ecma TC38 / SDC Task Group"></author>
<date year="2011" month="March" />
</front>
</reference>
<reference anchor="ESTAR">
<front>
<title>Energy Star Computer Specification Discussion Document,
http://energystar.gov/ia/partners/prod_development/revisions/downloads/computer/Computers_V6_Discussion_Document.pdf</title>
<author initials="" surname="US EPA"
fullname="US EPA, ENERGY STAR Program"></author>
<date year="2011" month="March" />
</front>
</reference>
</references>
</back>
</rfc>
<!-- <figure>
<artwork><![CDATA[
xxx
]]></artwork>
</figure>
-->| PAFTECH AB 2003-2026 | 2026-04-24 10:32:54 |