Network Working Group B. Claise
Internet-Draft J. Parello
Intended Status: Informational Cisco Systems, Inc.
Expires: July 12, 2013 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd
July 9, 2013
Energy Management Framework
draft-ietf-eman-framework-08
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on July, 2013.
<Claise, et. Al> Expires Jul 12 2013 [Page 1]
Internet-Draft <EMAN Framework> February 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as
the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date
of publication of this document. Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in
the Simplified BSD License.
Abstract
This document defines a framework for providing Energy
Management for devices and device components within or
connected to communication networks. The framework defines an
Energy Management Domain as a set of Energy Objects. Each
Energy Object is identified, classified and given context.
Energy Objects can be monitored and controlled with respect to
Power, Power State, Energy, Demand, Power Attributes, and
Battery. Additionally the framework models relationships and
capabilities between Energy Objects.
<Claise, et. Al> Expires August, 2013 [Page 2]
Internet-Draft <EMAN Framework> February 2013
Table of Contents
1. Introduction .......................................... 5
1.1. Energy Management Documents Overview ............. 6
2. Terminology ........................................... 6
Device................................................. 7
Component.............................................. 7
Energy Management...................................... 7
Energy Management System (EnMS)........................ 7
Power.................................................. 9
Demand................................................. 9
Power Attributes....................................... 9
Power Quality.......................................... 9
Electrical Equipment.................................. 10
Non-Electrical Equipment (Mechanical Equipment)....... 10
Energy Object......................................... 10
Energy Monitoring..................................... 10
Energy Control........................................ 11
Provide Energy........................................ 11
Receive Energy........................................ 11
Power Interface....................................... 11
Energy Management Domain.............................. 11
Energy Object Identification.......................... 12
Energy Object Context................................. 12
Energy Object Relationship............................ 12
Aggregation Relationship.............................. 12
Metering Relationship................................. 12
Power Source Relationship............................. 13
Power State........................................... 13
Power State Set....................................... 13
Nameplate Power....................................... 13
3. Concerns Specific to Energy Management ............... 13
3.1. Concern #1: Power Supply ........................ 15
3.2. Concern #2: Power and Energy Measurement ........ 20
3.3. Concern #3: Reporting Sleep and Off States ...... 21
3.4. Concern #4: Devices and Components .............. 22
3.5. Concern #5: Non-Electrical Equipment ............ 22
3.6. Concern #6: Energy Procurement .................. 23
4. Energy Management Abstraction ........................ 24
4.1 Conceptual Model.................................. 24
4.2 Energy Object..................................... 25
4.3 Energy Object Attributes.......................... 25
4.4 Measurements...................................... 28
4.5 Control........................................... 31
4.6 Power State Sets Comparison....................... 37
4.7 Relationships..................................... 38
4.8 Relationship Conventions and Guidelines........... 38
<Claise, et. Al> Expires August, 2013 [Page 3]
Internet-Draft <EMAN Framework> February 2013
4.9 Energy Object Relationship Extensions............. 41
5. Energy Management Information Model................... 41
6. Example Topologies.................................... 46
6.1 Example I: Simple Device with one Source.......... 47
6.2 Example II: Multiple Inlets....................... 48
6.3 Example III: Multiple Sources..................... 48
6.4 Relationships Between Devices..................... 49
7. Relationship with Other Standards .................... 54
8. Security Considerations .............................. 55
9. IANA Considerations .................................. 56
9.1 IANA Registration of new Power State Set.......... 56
9.2 Updating the Registration......................... 58
10. Acknowledgments ..................................... 59
11. References .......................................... 59
Normative References.................................. 59
Informative References................................ 59
OPEN ISSUES:
- Are Tracked via Issue Tracker. See
https://trac.tools.ietf.org/wg/eman/trac/report/1
<Claise, et. Al> Expires August, 2013 [Page 4]
Internet-Draft <EMAN Framework> February 2013
1. Introduction
Network management is often divided into the five main areas
defined in the ISO Telecommunications Management Network
model: Fault, Configuration, Accounting, Performance, and
Security Management (FCAPS) [X.700]. Not covered by this
traditional management model is Energy Management, which is
rapidly becoming a critical area of concern worldwide, as seen
in [ISO50001].
This document defines an energy management framework for
devices within or connected to communication networks. The
devices, or components of these devices (such as router line
cards, fans, disks), can then be monitored and controlled.
Monitoring includes power, energy, demand, and attributes of
power. Energy control can be performed by setting devices' or
components' power state. If a device contains batteries, these
can also be monitored and controlled.
This framework further describes how to identify, classify and
provide context for such devices. While the context
information is not specific to Energy Management, some context
attributes are specified in the framework, addressing the
following use cases: how important is a device in terms of its
business impact, how should devices be grouped for reporting
and searching, and how should a device role be described.
These context attributes help in fault management and impact
analysis while controlling the power states. Guidelines for
using context for energy management are described.
The framework introduces the concept of a power interface that
is analogous to a network interface. A power interface is
defined as an interconnection among devices where energy can
be provided, received, or both.
The most basic example of Energy Management is a single device
reporting information about itself. In many cases, however,
energy is not measured by the device itself, but metered
upstream in the power distribution tree. For example, a power
distribution unit (PDU) may measure the energy it supplies to
attached devices and report this to an energy management
system. Therefore, devices often have relationships to other
devices or components in the power network. An EnMS generally
requires an understanding of the power topology (who provides
power to whom), the metering topology (who meters whom), and
<Claise, et. Al> Expires August, 2013 [Page 5]
Internet-Draft <EMAN Framework> February 2013
an understanding of the potential aggregation (does a meter
aggregate values from other devices).
The relationships build on the power interface concept. The
different relationships among devices and components,
specified in this document, include: power source
relationship, metering relationship, and aggregation
relationship.
1.1. Energy Management Documents Overview
The EMAN standard provides a set of specifications for Energy
Management. This document specifies the framework, per the
Energy Management requirements specified in [EMAN-REQ].
The applicability statement document [EMAN-AS] includes use
cases, a cross-reference between existing standards and the
EMAN standard, and a description of this frameworks
relationship to other frameworks.
The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies
objects for addressing Energy Object Identification,
classification, context information, and relationships from
the point of view of Energy Management.
The Power and Energy Monitoring MIB [EMAN-MON-MIB] specifies
objects for monitoring of Power, Energy, Demand, Power
Attributes, and Power States.
The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines managed
objects that provide information on the status of batteries in
managed devices.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
Some terms have a NOTE that is not part of the
definition itself, but accounts for differences
between terminologies of different standards
organizations or further clarifies the definition.
<Claise, et. Al> Expires August, 2013 [Page 6]
Internet-Draft <EMAN Framework> February 2013
Device
A piece of electrical or non-electrical equipment.
Reference: Adapted from [IEEE100]
Component
A part of an electrical or non-electrical equipment
(Device).
Reference: Adapted from [ITU-T-M-3400]
Energy Management
Energy Management is a set of functions for
measuring, modeling, planning, and optimizing
networks to ensure that the network and network
attached devices use energy efficiently and
appropriately for the nature of the application
and the cost constraints of the organization.
Reference: Adapted from [ITU-T-M-3400]
NOTES:
1. Energy management refers to the activities,
methods, procedures and tools that pertain to
measuring, modeling, planning, controlling and
optimizing the use of energy in networked
systems [NMF].
2. Energy Management is a management domain which
is congruent to any of the FCAPS areas of
management in the ISO/OSI Network Management
Model [TMN]. Energy Management for
communication networks and attached devices is
a subset or part of an organization's greater
Energy Management Policies.
Energy Management System (EnMS)
An Energy Management System is a combination of
hardware and software used to administer a
network with the primary purpose of energy
management.
<Claise, et. Al> Expires August, 2013 [Page 7]
Internet-Draft <EMAN Framework> February 2013
Reference: Adapted from [1037C]
NOTES:
1. An Energy Management System according to
[ISO50001] (ISO-EnMS) is a set of systems or
procedures upon which organizations can develop
and implement an energy policy, set targets,
action plans and take into account legal
requirements related to energy use. An ISO-
EnMS allows organizations to improve energy
performance and demonstrate conformity to
requirements, standards, and/or legal
requirements.
2. Example ISO-EnMS: Company A defines a set of
policies and procedures indicating there should
exist multiple computerized systems that will
poll energy from their meters and pricing /
source data from their local utility. Company A
specifies that their CFO should collect
information and summarize it quarterly to be
sent to an accounting firm to produce carbon
accounting reporting as required by their local
government.
3. For the purposes of EMAN, the definition from
[1037C] is the preferred meaning of an Energy
Management System (EnMS). The definition from
[ISO50001] can be referred to as ISO Energy
Management System (ISO-EnMS).
Energy
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
kilowatt hours (kWh).
Reference: [IEEE100]
NOTES
1. Energy is the capacity of a system to produce
external activity or perform work [ISO50001]
<Claise, et. Al> Expires August, 2013 [Page 8]
Internet-Draft <EMAN Framework> February 2013
Power
The time rate at which energy is emitted,
transferred, or received; usually expressed in
watts (joules per second).
Reference: [IEEE100]
Demand
The average value of power or a related quantity
over a specified interval of time. Note: Demand
is expressed in kilowatts, kilovolt-amperes,
kilovars, or other suitable units.
Reference: [IEEE100]
NOTES:
1. For EMAN we use kilowatts.
Power Attributes
Measurements of the electrical current, voltage, phase and
frequencies at a given point in an electrical power system.
Reference: Adapted from [IEC60050]
NOTES:
1. Power Attributes are not intended to be judgmental with
respect to a reference or technical value and are
independent of any usage context.
Power Quality
Characteristics of the electrical current, voltage, phase
and frequencies at a given point in an electric power
system, evaluated against a set of reference technical
parameters. These parameters might, in some cases, relate to
the compatibility between electricity supplied in an
electric power system and the loads connected to that
electric power system.
Reference: [IEC60050]
NOTES:
<Claise, et. Al> Expires August, 2013 [Page 9]
Internet-Draft <EMAN Framework> February 2013
1. Electrical characteristics representing power quality
information are typically required by customer facility
energy management systems. It is not intended to satisfy the
detailed requirements of power quality monitoring. Standards
typically also give ranges of allowed values; the
information attributes are the raw measurements, not the
"yes/no" determination by the various standards.
Reference: [ASHRAE-201]
Electrical Equipment
A general term including materials, fittings,
devices, appliances, fixtures, apparatus,
machines, etc., used as a part of, or in
connection with, an electric installation.
Reference: [IEEE100]
Non-Electrical Equipment (Mechanical Equipment)
A general term including materials, fittings,
devices appliances, fixtures, apparatus,
machines, etc., used as a part of, or in
connection with, non-electrical power
installations.
Reference: Adapted from [IEEE100]
Energy Object
An Energy Object (EO) is an information model
(class) that represents a piece of equipment that
is part of, or attached to, a communications
network which is monitored, controlled, or aids
in the management of another device for Energy
Management.
Energy Monitoring
Energy Monitoring is a part of Energy Management
that deals with collecting or reading information
from Energy Objects to aid in Energy Management.
<Claise, et. Al> Expires August, 2013 [Page 10]
Internet-Draft <EMAN Framework> February 2013
Energy Control
Energy Control is a part of Energy Management
that deals with directing influence over Energy
Objects.
Provide Energy
An Energy Object "provides" energy to another Energy Object
if there is an energy flow from this Energy Object to the
other one.
Receive Energy
An Energy Object "receives" energy from another Energy
Object if there is an energy flow from the other Energy
Object to this one.
Power Interface
A Power Interface (or simply interface) is an information
model (class) that represents the interconnections among
devices or components where energy can be provided,
received, or both.
Power Inlet
A Power Inlet (or simply inlet) is an interface at which a
device or component receives energy from another device or
component.
Power Outlet
A Power Outlet (or simply outlet) is an interface at which
a device or component provides energy to another device or
component.
Energy Management Domain
An Energy Management Domain is a set of Energy Objects that
is considered one unit of management.
<Claise, et. Al> Expires August, 2013 [Page 11]
Internet-Draft <EMAN Framework> February 2013
Energy Object Identification
Energy Object Identification is a set of
attributes that enable an Energy Object to be
universally unique or linked to other systems.
Energy Object Context
Energy Object Context is a set of attributes that
allow an Energy Management System to classify an
Energy Object within an organization.
Energy Object Relationship
An Energy Object Relationship is an association among
Energy Objects.
NOTES
1. Relationships can be named and could include
Aggregation, Metering, and Power Source.
Reference: Adapted from [CHEN]
Aggregation Relationship
An Aggregation Relationship is an Energy Object
Relationship where one Energy Object aggregates Energy
Management information of one or more other Energy Objects.
The aggregating Energy Object has an Aggregation
Relationship with each of the other Energy Objects.
Metering Relationship
A Metering Relationship is an Energy Object Relationship
where one Energy Object measures power, energy, demand or
power attributes of one or more other Energy Objects. The
measuring Energy Object has a Metering Relationship with
each of the measured objects.
<Claise, et. Al> Expires August, 2013 [Page 12]
Internet-Draft <EMAN Framework> February 2013
Power Source Relationship
A Power Source Relationship is an Energy Object
Relationship where one Energy Object provides power to one
or more Energy Objects. These Energy Objects are referred
to as having a Power Source Relationship.
Power State
A Power State is a condition or mode of a device
that broadly characterizes its capabilities,
power consumption, and responsiveness to input.
Reference: Adapted from [IEEE1621]
Power State Set
A Power State Set is a collection of Power States
that comprises a named or logical control
grouping.
Nameplate Power
The Nameplate Power is the nominal Power of a
device as specified by the device manufacturer.
3. Concerns Specific to Energy Management
With Energy Management, there exists a wide variety of devices
that may be contained in the same deployments as a
communication network but comprise a separate facility, home,
or power distribution network.
Target devices for Energy Management are all Energy Objects
that can be monitored or controlled (directly or indirectly)
by an Energy Management System (EnMS) using the Internet
protocol. These target devices include:
- Simple electrical appliances and fixtures
- Hosts, such as a PC, a server, or a printer
- Switches, routers, base stations, and other network
equipment and middle boxes
- Components within devices, such as a battery inside a
PC, a line card inside a switch, etc.
<Claise, et. Al> Expires August, 2013 [Page 13]
Internet-Draft <EMAN Framework> February 2013
- Power over Ethernet (PoE) endpoints
- Power Distribution Units (PDU)
- Protocol gateway devices for Building Management Systems
(BMS)
- Electrical meters
- Sensor controllers with subtended sensors
There may also exist varying protocols deployed among these
power distribution and communication networks.
An Energy Management framework should also apply to these
types of separate networks as they connect to and interact
with a communications network.
This section explains special issues of Energy Management
concerning power supply, Power and Energy metering, and the
reporting of Power States.
Energy Management has special challenges because a power
distribution network supplies energy to devices and
components, while a separate communications network monitors
and controls the power distribution network.
To illustrate this point, consider the basic scenario where a
single powered device receives Energy and reports energy-
related information about itself to an Energy Management
System (EnMS) (see Figure 1).
+--------------------------+
| Energy Management System |
+--------------------------+
^ ^
monitoring | | control
v v
+-----------------+
| powered device |
+-----------------+
Figure 1: Basic energy management scenario
The powered device may have local energy control mechanisms,
such as putting itself into a sleep mode when appropriate, and
it may receive energy control commands for similar purposes
from the EnMS. Information reported from a powered device to
the EnMS includes at least the Power State of the powered
device (on, sleep, off, etc.).
<Claise, et. Al> Expires August, 2013 [Page 14]
Internet-Draft <EMAN Framework> February 2013
This and similar cases are well understood and common in
Energy Management. They can be handled with well-established
and standardized management procedures. The only missing
components today are standardized information and data models
for reporting and configuration, such as energy-specific MIB
modules [RFC2578] and YANG modules [RFC6020].
Energy Management presents no new issues for fault,
configuration, performance or security management. We can re-
use standard network management procedures to handle these
issues in an EnMS. For example, with faults we can re-use rmon
or SNMP traps. For security, existing means like SNMPv3
security can be used.
But when there are issues specific to Energy Management then
this framework adds them. The following subsections address
these issues and illustrate them by extending the basic
scenario in Figure 1.
3.1. Concern #1: Power Supply
Most powered devices that are managed by an EnMS receive
external power.
While many devices receive Power from unmanaged supply
systems, the number of manageable power supply devices is
increasing.
In datacenters, for example, many Power Distribution Units
(PDUs) allow the EnMS to switch power individually for each
socket and also to measure the provided Power. This is very
different from many other network management tasks. In this
and similar cases, switching the power supply for a powered
device or monitoring its power is not done by communicating
with the actual powered device itself, but with an external
device (in this case, the PDU).
Consequently, a standard for Energy Management must not only
cover the powered devices that provide services for users, but
also the power supply devices (which are themselves powered
devices) that monitor or control the power supply for other
powered devices.
A simple device such as a light bulb can be switched on or off
only by switching its power supply. More complex devices may
have the ability to switch off themselves or to bring
<Claise, et. Al> Expires August, 2013 [Page 15]
Internet-Draft <EMAN Framework> February 2013
themselves to states in which they consume very little power.
For these devices as well, it is desirable to monitor and
control their power supply.
This extends the basic scenario from Figure 1 by adding a
power supply device (see Figure 2).
+-----------------------------------------+
| energy management system |
+-----------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------------+ +-----------------+
| power supply |########| powered device |
+--------------+ +-----------------+
######## power supply line
Figure 2: Basic Scenario with Power Supply Device
The power supply device can be as simple as a plain power
switch. It may offer interfaces to the EnMS to monitor and to
control the status of its power outlets, as with PDUs and
Power over Ethernet (PoE) [IEEE-802.3at] switches.
The relationship between supply devices and the powered
devices they serve creates several problems for managing power
supply:
o Identification of corresponding devices:
* A given powered device may need to identify the
device supplying power.
* A given power supply device may need to identify the
corresponding power-supplied device(s).
o Aggregation of monitoring and control for multiple
powered devices:
* A power supply device may supply multiple
devices from a single power supply line.
o Coordination of power control for devices with multiple
power inlets:
* A powered device may receive power via multiple power
lines controlled by the same or different power
supply devices.
3.1.1 Identification of Power Supply and Powered Devices
<Claise, et. Al> Expires August, 2013 [Page 16]
Internet-Draft <EMAN Framework> February 2013
When a power supply device controls or monitors power supply
at one of its power outlets, the effect on other devices is
not always clear without knowledge about wiring of power
lines. The same holds for monitoring. The power supplying
device can report that a particular socket is powered, and it
may even be able to measure power and conclude that there is a
consumer drawing power at that socket, but it may not know
which powered device(s)receives the provided power.
In many cases it is obvious which other device is supplied by
a certain outlet, but this always requires additional
(reliable) information about power line wiring. Without
knowing which device(s) are powered via a certain outlet,
monitoring data are of limited value and the consequences of
switching power on or off may be hard to predict.
Even in well-organized operations, powered devices' power
cords can be plugged into the wrong socket, or wiring plans
changed without updating the EnMS accordingly.
For reliable monitoring and control of power supply devices,
additional information is needed to identify the device(s)
that receive power provided at a particular monitored and
controlled socket.
This problem also occurs in the opposite direction. If power
supply control or monitoring for a certain device is needed,
then the supplying power supply device has to be identified.
To conduct Energy Management tasks for both power supply
devices and other powered devices, sufficiently unique
identities are needed, and knowledge of their power supply
relationship is required.
3.1.2 Multiple Devices Supplied by a Single Power Line
The second fundamental problem is the aggregation of
monitoring and control that occurs when multiple powered
devices are supplied by a single power supply line. It is
often necessary for the EnMS to discover the full list of
powered devices connected to a power supply line, as in Figure
3.
+---------------------------------------+
| energy management system |
+---------------------------------------+
<Claise, et. Al> Expires August, 2013 [Page 17]
Internet-Draft <EMAN Framework> February 2013
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------+ +------------------+
| power |########| powered device 1 |
| supply | # +------------------+-+
+--------+ #######| powered device 2 |
# +------------------+-+
#######| powered device 3 |
+------------------+
Figure 3: Multiple Powered Devices Supplied
by Single Power Line
With this list, the single status value has a clear meaning
and is the sum of all powered devices. Control functions are
limited by the fact that supply for the concerned devices can
only be switched on or off for all of them at once.
Individual control at the supply is not possible.
If the full list of devices powered by a single supply line is
not known by the controlling power supply device, then control
of power supply is problematic, because the complete
consequences of a control action cannot be known.
3.1.3 Multiple Power Supply for a Single Powered Device
The third problem arises from the fact that there are devices
with multiple power supplies. Some have this for redundancy
of power supply, some for redundancy of internal power
converters (for example, from AC mains power to DC internal
power), and some because the capacity of a single supply line
is insufficient.
+----------------------------------------------+
| energy management system |
+----------------------------------------------+
^ ^ ^ ^ ^ ^
mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
v v v v v v
+----------+ +----------+ +----------+
| power |######| powered |######| power |
| supply 1 |######| device | | supply 2 |
+----------+ +----------+ +----------+
<Claise, et. Al> Expires August, 2013 [Page 18]
Internet-Draft <EMAN Framework> February 2013
Figure 4: Multiple Power Supply for Single Powered Device
The example in Figure 4 does not necessarily show a real world
scenario, but it shows the two cases to consider:
o Multiple power supply lines between a single power
supply device and a powered device
o Different power supply devices supplying a single
powered device
In any such case, there may be a need to identify the
supplying power supply device individually for each power
inlet of a powered device.
Without this information, monitoring and control of power
supply for the powered device may be limited.
3.1.4 Bidirectional Power Interfaces
Some power technologies (mostly low power DC) allow power to
be delivered bi-directionally. For example, energy stored in
batteries on one device can be delivered back to a power hub,
which redirects the power to another device. In this
situation, the interface can function as both an inlet and
outlet at different times.
A Power Interface can model a power inlet or a power outlet,
depending on the conditions. Information of interest for
Power Interfaces includes the power direction, as well as the
energy received, provided, and the net result.
3.1.5 Relevance of Power Supply Concerns
In some scenarios, the problems with power supply do not exist
or can be solved sufficiently. With Power over Ethernet (PoE)
[IEEE-802.3at], there is always a one-to-one relationship
between a Power Sourcing Equipment (PSE) and a Powered Device
(PD). Also, the Ethernet link on the line used for powering
can be used to identify the PD and in many cases also the PSE.
For supply of AC mains power, the three problems described
above cannot be solved in general. There is no commonly
available protocol or automatic mechanism for identifying
endpoints of a power line.
<Claise, et. Al> Expires August, 2013 [Page 19]
Internet-Draft <EMAN Framework> February 2013
In addition, AC power lines support supplying multiple powered
devices with a single line, and are commonly used in this
fashion.
3.1.6 Remote Power Supply Control
There are three ways for an energy management system to change
the Power State of powered devices. First is for the EnMS to
provide policy or other useful information (like the
electricity price) to the powered device for it to use in
determining its Power State. The second is sending the
powered device a command to switch to another Power State.
The third is to use an upstream (to the powered device) device
that can switch on and off power at its outlet.
Some devices cannot receive commands or change their Power
State by themselves. Such Energy Objects may be controlled by
switching on and off their power supply, and so have a
particular need for the third method.
In Figure 4, the power supply can switch power at its power
outlet and thereby switch on and off power for the connected
powered device.
3.2. Concern #2: Power and Energy Measurement
Some devices include hardware to directly measure their Power
and Energy consumption. However, most common networked
devices do not provide an interface that gives access to
Energy and Power measurements. Hardware instrumentation for
this kind of measurement is typically not in place and adding
it incurs an additional cost.
With the increasing cost of Energy and the growing importance
of Energy Monitoring, it is likely that more devices in future
will include instrumentation for power and energy
measurements. It is also likely that it will take a long time
for this to become commonplace.
3.2.1 Local Estimates
One solution to this problem is for the powered device to
estimate its own Power and consumed Energy. For many Energy
Management tasks, getting an estimate is much better than not
<Claise, et. Al> Expires August, 2013 [Page 20]
Internet-Draft <EMAN Framework> February 2013
getting any information at all. Estimates can be based on
actual measured activity level of a device or it can just
depend on the power state (on, sleep, off, etc.).
An advantage of estimates is that they can be realized locally
and with much lower cost than hardware instrumentation. Local
estimates can be dealt with in traditional ways. They don't
need an extension of the basic scenarios above. However, the
powered device needs an energy model of itself to make
estimates.
3.2.2 Management System Estimates
Another approach to the lack of instrumentation is estimation
by the EnMS. The EnMS can estimate Power based on basic
information on the powered device, such as the type of device,
or its brand/model and functional characteristics.
Energy estimates can combine the typical power level by Power
State with reported data about the Power State.
If the EnMS has a detailed energy model of the device, it can
produce better estimates, including the actual power state and
actual activity level of the device. This information can be
obtained by monitoring the device with conventional means of
performance monitoring.
3.3. Concern #3: Reporting Sleep and Off States
Low-power states pose special challenges for energy reporting
because they may preclude a device from listening to and
responding to network requests. Devices may still be able to
reliably track energy use in these states, as power levels are
usually static and internal clocks can track elapsed time in
these states.
Some devices have out-of-band or proxy abilities to respond to
network requests in low-power states. Others could use proxy
abilities in an energy management protocol to improve this
reporting, particularly if the powered device sends out
notifications of power state changes.
<Claise, et. Al> Expires August, 2013 [Page 21]
Internet-Draft <EMAN Framework> February 2013
3.4. Concern #4: Devices and Components
While the typical focus of energy management is entire powered
devices, sometimes it is desirable to manage individual
components of devices, such as line cards, fans, disks, etc.
This framework uses a much simpler model for components than
for entire devices. The concept of Power Interfaces is not
used between a device and its contained components. Reporting
of energy-related quantities for individual components is
limited to the most important ones. Simplifications for
components in this framework include
o identifying components like devices but without
distinct context information,
o reporting a containment relationship to the containing
device,
o inheriting all context information from the containing
device,
o not modeling power interfaces and power lines between
a component and its containing device or other
components, and
o only reporting real power and energy values for
components.
Power state monitoring and control are not simplified. These
have the same functionality for devices and components. In
rare cases where there is a need to model components of a
device in more detail, components of a device can be modeled
as individual devices. Then all considerations for devices
also apply to these components. This model has a higher
overhead and should be used only when needed. If used, it is
not necessarily visible whether a set of components belongs to
a single device or not, but for energy management purposes
this might not be of high relevance.
3.5. Concern #5: Non-Electrical Equipment
The primary focus of this framework is the management of
Electrical Equipment. Some Non-Electrical Equipment may be
connected to communication networks and could have their
energy managed if normalized to the electrical units for power
and energy.
Some examples of Non-Electrical Equipment that may be
connected to a communication network are:
<Claise, et. Al> Expires August, 2013 [Page 22]
Internet-Draft <EMAN Framework> February 2013
1) A controller for compressed air. The controller is
electrical only for its network connection. The controller
is fueled by natural gas and produces compressed air. The
energy transferred via compressed air is distributed to
devices on a factory floor via a Power Interface which
consists of tools (drills, screwdrivers, assembly line
conveyor belts). The energy measured is non-electrical
(compressed air).
2) A controller for steam. The controller is electrical for its
network attachment but it burns tallow and produces steam to
subtended boilers. The energy is non-electrical (steam).
3) A controller or regulator for gas. The controller is
electrical for its network attachment but it has physical
non-electrical components for control. The energy is non-
electrical (BTU).
3.6. Concern #6: Energy Procurement
While an EnMS may be a central point for corporate reporting,
cost, environmental impact, and regulatory compliance, Energy
Management in this framework excludes Energy procurement and
the environmental impact of energy use. As such the framework
does not include:
- Cost in currency or environmental units of manufacturing an
Energy Object
- Embedded carbon or environmental equivalences of an Energy
Object
- Cost in currency or environmental impact to dismantle or
recycle an Energy Object
- Supply chain analysis of energy sources for Energy Object
deployment
- Conversion of the usage or production of energy to units
expressed from the source of that energy (such as the
greenhouse gas emissions associated with 1000kW from a diesel
source)
<Claise, et. Al> Expires August, 2013 [Page 23]
Internet-Draft <EMAN Framework> February 2013
4. Energy Management Abstraction
Network management is often divided into the five main areas
defined in the ISO Telecommunications Management Network
model: Fault, Configuration, Accounting, Performance, and
Security Management (FCAPS) [X.700]. This traditional
management model does not cover Energy Management.
This section describes a conceptual model of information that
can be used for Energy Management. The classes and categories
of attributes in the model are described with rationale for
each. A UML description of the model can be found in Section
5.
4.1 Conceptual Model
To address Energy Management this specification describes an
information model that can exist along with Network Management
while addressing issues specific to Energy Management (Section
3).
An information model for Energy Management will need to
describe a means to report information, provide control, and
model the interconnections among physical entities.
Therefore, this section proposes a similar conceptual model
for physical entities to that used in Network Management:
devices, components, and interfaces. This section then defines
the additional attributes specific to Energy Management for
those entities that are not available in existing Network
Management models.
For modeling the physical entities this section describes
three classes: a Device, a Component, and a Power Interface.
These classes are sub-types of an abstract Energy Object
class.
For modeling the additional attributes, this section describes
attributes of an Energy Object for: identification,
classification, context, control, power and energy.
Since the interconnections between physical entities for
Energy Management may have no relation to the interconnections
for Network Management the Energy Object classes contain a
separate Relationships class as an attribute to model these
types of interconnections.
<Claise, et. Al> Expires August, 2013 [Page 24]
Internet-Draft <EMAN Framework> February 2013
The remainder of this section describes the conceptual model
of the classes and categories of attributes in the information
model. The exact definitions of the classes and attributes are
specified using UML in Section 5.
4.2 Energy Object
An Energy Object is an abstract class that contains the base
attributes for Energy Management. There are three types of
Energy Objects: Device, Component and Power Interface.
4.2.1 Device Class
The Device Class is a sub-class of Energy Object that
represents a physical piece of equipment.
A Device Class instance may represent a device that is a
consumer, producer, or meter of energy.
A Device Class instance may represent a physical device that
contains other components.
4.2.2 Component Class
The Component Class is a sub-class of Energy Object that
represents a part of a physical piece of equipment.
4.2.3 Power Interface Class
The power interface class is a sub-class of Energy Object that
represents the interconnection among devices and components.
There are some similarities between Power Interfaces and
network interfaces. A network interface can be set to
different states, such as sending or receiving data on an
attached line. Similarly, a Power Interface can be receiving
or providing power.
Physically, a Power Interface instance can represent an AC
power socket, an AC power cord attached to a device, or an
8P8C (RJ45) PoE socket, etc.
4.3 Energy Object Attributes
This section describes categories of attributes for an Energy
Object. Section 5 contains the specific UML definitions of the
modeled attribute.
<Claise, et. Al> Expires August, 2013 [Page 25]
Internet-Draft <EMAN Framework> February 2013
4.3.1 Identification
A Universal Unique Identifier (UUID) [RFC4122] is used to
uniquely and persistently identify an Energy Object. Ideally
the UUID is used to distinguish the Energy Object within the
EnMS.
Every Energy Object has an optional unique printable name.
Possible naming conventions are: textual DNS name, MAC address
of the device, interface ifName, or a text string uniquely
identifying the Energy Object. As an example, in the case of
IP phones, the Energy Object name can be the device's DNS
name.
Additionally an alternate key is provided to allow an Energy
Object to be optionally linked with models in different
systems.
4.3.2 Context in General
In order to aid in reporting and in differentiation between
Energy Objects, each Energy Object optionally contains
information establishing its business, site, or organizational
context within a deployment
4.3.3 Context: Importance
An Energy Object can provide an importance value in the range
of 1 to 100 to help rank a device's use or relative value to
the site. The importance range is from 1 (least important) to
100 (most important). The default importance value is 1.
For example: A typical office environment has several types of
phones, which can be rated according to their business impact.
A public desk phone has a lower importance (for example, 10)
than a business-critical emergency phone (for example, 100).
As another example: A company can consider that a PC and a
phone for a customer-service engineer are more important than
a PC and a phone for lobby use.
Although EnMS and administrators can establish their own
ranking, the following example is a broad recommendation for
commercial deployments [CISCO-EW]:
. 90 to 100 Emergency response
. 80 to 90 Executive or business-critical
<Claise, et. Al> Expires August, 2013 [Page 26]
Internet-Draft <EMAN Framework> February 2013
. 70 to 79 General or Average
. 60 to 69 Staff or support
. 40 to 59 Public or guest
. 1 to 39 Decorative or hospitality
4.3.4 Context: Keywords
An Energy Object can provide a set of keywords. These
keywords are a list of tags that can be used for grouping,
summary reporting within or between Energy Management Domains,
and for searching. All alphanumeric characters and symbols
(other than a comma), such as #, (, $, !, and &, are allowed.
Potential examples are: IT, lobby, HumanResources, Accounting,
StoreRoom, CustomerSpace, router, phone, floor2, or
SoftwareLab. There is no default value for a keyword.
Multiple keywords can be assigned to a device. White spaces
before and after the commas are excluded, as well as within a
keyword itself. In such cases, commas separate the keywords
and no spaces between keywords are allowed. For example,
"HR,Bldg1,Private".
4.3.5 Context: Role
An Energy Object contains a "role description" string that
indicates the purpose the Energy Object serves in the EnMS.
This could be a string describing the context the device
fulfills in deployment.
Administrators can define any naming scheme for the role of a
device. As guidance, a two-word role that combines the
service the device provides along with type can be used
[IPENERGY].
Example types of devices: Router, Switch, Light, Phone,
WorkStation, Server, Display, Kiosk, HVAC.
Example Services by Line of Business:
Line of Business Service
<Claise, et. Al> Expires August, 2013 [Page 27]
Internet-Draft <EMAN Framework> February 2013
Education Student, Faculty, Administration,
Athletic
Finance Trader, Teller, Fulfillment
Manufacturing Assembly, Control, Shipping
Retail Advertising, Cashier
Support Helpdesk, Management
Medical Patient, Administration, Billing
Role as a two-word string: "Faculty Desktop", "Teller Phone",
"Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
"Administration Switch".
4.3.6 Context: Domain
An Energy Object contains a string to indicate membership in
an Energy Management Domain. An Energy Management Domain can
be any collection of devices in a deployment, but it is
recommended to map 1:1 with a metered or sub-metered portion
of the site.
In building management, a meter refers to the meter provided
by the utility used for billing and measuring power to an
entire building or unit within a building. A sub-meter refers
to a customer- or user-installed meter that is not used by the
utility to bill but is instead used to get readings from sub
portions of a building.
A meter is a type Energy Object and any Energy Object can
perform metering.
An Energy Object should be a member of a single Energy
Management Domain therefore one field is provided. The Energy
Management Domain may be configured on an Energy Object.
4.4 Measurements
An Energy Object contains attributes to describe power, energy
and demand measurements.
<Claise, et. Al> Expires August, 2013 [Page 28]
Internet-Draft <EMAN Framework> February 2013
For the purposes of this framework, energy will be limited to
electrical energy in watt-hours. Other forms of Energy
Objects that use or produce non-electrical energy may be
modeled as an Energy Object but must provide information
converted to and expressed in watt-hours.
An analogy for understanding power versus energy measurements
can be made to speed and distance in automobiles. Just as a
speedometer indicates the rate of change of distance (speed),
a power meter indicates the rate of transfer of energy. The
odometer in an automobile measures the cumulative distance
traveled and an energy meter indicates the accumulated energy
transferred.
Demand measurements are averages of power measurements over
time. So using the same analogy to an automobile: measuring
the average vehicle speed over multiple intervals of time for
a given distance travelled, demand is the average device power
over multiple time intervals for a given energy value.
4.4.1 Measurements: Power
Each Energy Object contains a Nameplate Power attribute that
describes the nominal power as specified by the manufacturer.
Power Measurement. The EnMS can use the Nameplate Power for
provisioning, capacity planning and (potentially) billing.
Each Energy Object will have information that describes
present power information, along with how that measurement was
obtained or derived (e.g., measured, estimated, or presumed).
A power measurement is be qualified with the units, magnitude
and direction of power flow, and is be qualified as to the
means by which the measurement was made (e.g., Root Mean
Square versus Nameplate).
In addition, the Energy Object describes how it intends to
measure power. This intention can be described as one of the
following: consumer, producer, meter or distributir of power.
Given the intent, the EnMS can summarize or analyze the
measurement. For example, metered usage reported by a meter
and consumption usage reported by a device connected to that
meter will naturally measure the same usage. With the two
measurements identified by intent, the EnMS can make a proper
summarization.
<Claise, et. Al> Expires August, 2013 [Page 29]
Internet-Draft <EMAN Framework> February 2013
Power measurement magnitude conforms to the IEC 61850
definition of unit multiplier for the SI (System
International) units of measure. Measured values are
represented in SI units obtained by BaseValue * (10 ^ Scale).
For example, if current power usage of an Energy Object is 3,
it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value
of the scaling factor. 3W implies that the BaseValue is 3 and
Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor =
-3.
In addition to knowing the power and magnitude an Energy
Object indicates how the measurement was obtained:
- Whether the measurements were made at the device itself or
at a remote source.
- Description of the method that was used to measure the power
and whether this method can distinguish actual or estimated
values.
An EnMS can use this information to account for the accuracy
and nature of the reading between different implementations.
4.4.2 Measurements: Power Attributes
Optionally, an Energy Object describes the Power measurements
with Power Attribute information reflecting the electrical
characteristics of the measurement. These Power Attributes
adhere to the IEC 61850 7-2 standard for describing AC
measurements.
4.4.3 Measurements: Energy
Optionally, an Energy Object that can report actual power
readings will have energy attributes that provide the energy
used, produced, and net energy in kWh. These values are energy
measurements that accumulate the power readings. If energy
values are returned, then the three measurements are provided
along with a description of accuracy.
4.4.4 Measurements: Demand
Optionally, an Energy Object will provide demand information
over time. Demand measurements can be provided when the Energy
Object is capable of measuring actual power
<Claise, et. Al> Expires August, 2013 [Page 30]
Internet-Draft <EMAN Framework> February 2013
4.5 Control
An Energy Object can be controlled by setting it to a specific
Power State. An Energy Object implements at least one set of
Power States consisting of at least two states, an on state
and an off state.
Each Energy Object should indicate the sets of Power States
that it implements. Well known Power States / Sets are
registered with IANA.
When a device is set to a particular Power State, it may be
busy. The device will set the desired Power State and then
update the actual Power State when it changes. There are then
two Power State control variables: actual and requested.
There are many existing standards for and implementations of
Power States. An Energy Object can support a mixed set of
Power States defined in different standards. A basic example
is given by the three Power States defined in IEEE1621
[IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI],
and PWG define larger numbers of Power States.
The semantics of a power state are specified by
a) the functionality provided by an Energy Object in this
state,
b) a limitation of the power that an Energy Object uses in
this state,
c) a combination of a) and b)
The semantics of a Power State should be clearly defined.
Limitation (curtailment) of the power used by an Energy Object
in a state is be specified by
- an absolute power value
- a percentage value of power relative to the energy
object's nameplate power
- an indication of used power relative to another power
state. For example: Specify that used power in state A is less
than in state B.
For supporting Power State management an Energy Object
provides statistics on Power States including the time an
<Claise, et. Al> Expires August, 2013 [Page 31]
Internet-Draft <EMAN Framework> February 2013
Energy Object spent in a certain Power State and the number of
times an Energy Object entered a power state.
When requesting an Energy Object to enter a Power State an
indication of the Power State's name or number can be used.
Optionally an absolute or percentage of Nameplate Power can be
provided to allow the Energy Object to transition to a nearest
or equivalent Power State.
4.5.1 Power State Sets
There are several standards and implementations of Power State
Sets. An Energy Object can support one or multiple Power
State Set implementation(s) concurrently.
There are currently three Power State Sets advocated:
IEEE1621(256) - [IEEE1621]
DMTF(512) - [DMTF]
EMAN(768) - [EMAN-MONITORING-MIB]
The respective specific states related to each Power State Set
are specified in the following sections. The guidelines for
addition of new Power State Sets are specified in the IANA
Considerations Section.
4.5.2 IEEE1621 Power State Set
The IEEE1621 Power State Set [IEEE1621] consists of 3
rudimentary states: on, off or sleep.
on(0) - The device is fully On and all features of the
device are in working mode.
off(1) - The device is mechanically switched off and does
not consume energy.
sleep(2) - The device is in a power saving mode, and some
features may not be available immediately.
<Claise, et. Al> Expires August, 2013 [Page 32]
Internet-Draft <EMAN Framework> February 2013
4.5.3 DMTF Power State Set
DMTF [DMTF] standards organization has defined a power profile
standard based on the CIM (Common Information Model) model
that consists of 15 power states ON (2), SleepLight (3),
SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7),
PowerCycle Off-Soft (8), PowerCycle Off-Hard (9), MasterBus
reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12),
Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-
Cycle Off-Soft Graceful (15), PowerCycle-Hard Graceful (16).
DMTF standard is targeted for hosts and computers. Details of
the semantics of each Power State within the DMTF Power State
Set can be obtained from the DMTF Power State Management
Profile specification [DMTF].
DMTF power profile extends ACPI power states. The following
table provides a mapping between DMTF and ACPI Power State
Set:
---------------------------------------------------
| DMTF | ACPI |
| Power State | Power State |
---------------------------------------------------
| Reserved(0) | |
---------------------------------------------------
| Reserved(1) | |
---------------------------------------------------
| ON (2) | G0-S0 |
--------------------------------------------------
| Sleep-Light (3) | G1-S1 G1-S2 |
--------------------------------------------------
| Sleep-Deep (4) | G1-S3 |
--------------------------------------------------
<Claise, et. Al> Expires August, 2013 [Page 33]
Internet-Draft <EMAN Framework> February 2013
| Power Cycle (Off-Soft) (5) | G2-S5 |
---------------------------------------------------
| Off-hard (6) | G3 |
---------------------------------------------------
| Hibernate (Off-Soft) (7) | G1-S4 |
---------------------------------------------------
| Off-Soft (8) | G2-S5 |
---------------------------------------------------
| Power Cycle (Off-Hard) (9) | G3 |
---------------------------------------------------
| Master Bus Reset (10) | G2-S5 |
---------------------------------------------------
| Diagnostic Interrupt (11) | G2-S5 |
---------------------------------------------------
| Off-Soft Graceful (12) | G2-S5 |
---------------------------------------------------
| Off-Hard Graceful (13) | G3 |
---------------------------------------------------
| MasterBus Reset Graceful (14) | G2-S5 |
---------------------------------------------------
| Power Cycle off-soft Graceful (15)| G2-S5 |
---------------------------------------------------
| Power Cycle off-hard Graceful (16)| G3 |
---------------------------------------------------
<Claise, et. Al> Expires August, 2013 [Page 34]
Internet-Draft <EMAN Framework> February 2013
Figure 5: DMTF and ACPI Powe State Set Mapping
4.5.4 EMAN Power State Set
An EMAN Power State Set represents an attempt at a standard
approach for modeling the different levels of power of a
device. The EMAN Power States are an expansion of the basic
Power States as defined in [IEEE1621] that also incorporates
the Power States defined in [ACPI] and [DMTF]. Therefore, in
addition to the non-operational states as defined in [ACPI]
and [DMTF] standards, several intermediate operational states
have been defined.
An Energy Object may implement fewer or more Power States than
a particular EMAN Power State Set specifies. In this case, the
Energy Object implementation can determine its own mapping to
the predefined EMAN Power States within the EMAN Power State
Set.
There are twelve EMAN Power States that expand on [IEEE1621].
The expanded list of Power States is derived from [CISCO-EW]
and is divided into six operational states and six non-
operational states. The lowest non-operational state is 1 and
the highest is 6. Each non-operational state corresponds to
an [ACPI] Global and System state between G3 (hard-off) and G1
(sleeping). Each operational state represents a performance
state, and may be mapped to [ACPI] states P0 (maximum
performance power) through P5 (minimum performance and minimum
power).
In each of the non-operational states (from mechoff(1) to
ready(6)), the Power State preceding it is expected to have a
lower Power value and a longer delay in returning to an
operational state:
mechoff(1) : An off state where no Energy Object
features are available. The Energy Object is unavailable. No
energy is being consumed and the power connector can be
removed.
softoff(2) : Similar to mechoff(1), but some
components remain powered or receive trace power so that the
Energy Object can be awakened from its off state. In
softoff(2), no context is saved and the device typically
requires a complete boot when awakened.
<Claise, et. Al> Expires August, 2013 [Page 35]
Internet-Draft <EMAN Framework> February 2013
hibernate(3): No Energy Object features are
available. The Energy Object may be awakened without
requiring a complete boot, but the time for availability is
longer than sleep(4). An example for state hibernate(3) is a
save to-disk state where DRAM context is not maintained.
Typically, energy consumption is zero or close to zero.
sleep(4) : No Energy Object features are
available, except for out-of-band management, such as wake-up
mechanisms. The time for availability is longer than
standby(5). An example for state sleep(4) is a save-to-RAM
state, where DRAM context is maintained. Typically, energy
consumption is close to zero.
standby(5) : No Energy Object features are available,
except for out-of-band management, such as wake-up mechanisms.
This mode is analogous to cold-standby. The time for
availability is longer than ready(6). For example processor
context is may not be maintained. Typically, energy
consumption is close to zero.
ready(6) : No Energy Object features are
available, except for out-of-band management, such as wake-up
mechanisms. This mode is analogous to hot-standby. The Energy
Object can be quickly transitioned into an operational state.
For example, processors are not executing, but processor
context is maintained.
lowMinus(7) : Indicates some Energy Object features
may not be available and the Energy Object has taken measures
or selected options to provide less than low(8) usage.
low(8) : Indicates some features may not be
available and the Energy Object has taken measures or selected
options to provide less than mediumMinus(9) usage.
mediumMinus(9): Indicates all Energy Object features
are available but the Energy Object has taken measures or
selected options to provide less than medium(10) usage.
medium(10) : Indicates all Energy Object features
are available but the Energy Object has taken measures or
selected options to provide less than highMinus(11) usage.
highMinus(11): Indicates all Energy Object features
are available and power usage is less than high(12).
<Claise, et. Al> Expires August, 2013 [Page 36]
Internet-Draft <EMAN Framework> February 2013
high(12) : Indicates all Energy Object features
are available and the Energy Object is consuming the highest
power.
4.6 Power State Sets Comparison
A comparison of Power States from different Power State Sets
can be seen in the following table:
IEEE1621 DMTF ACPI EMAN
Non-operational states
off Off-Hard G3, S5 MechOff(1)
off Off-Soft G2, S5 SoftOff(2)
sleep Hibernate G1, S4 Hibernate(3)
sleep Sleep-Deep G1, S3 Sleep(4)
sleep Sleep-Light G1, S2 Standby(5)
sleep Sleep-Light G1, S1 Ready(6)
Operational states:
on on G0, S0, P5 LowMinus(7)
on on G0, S0, P4 Low(8)
on on G0, S0, P3 MediumMinus(9)
on on G0, S0, P2 Medium(10)
on on G0, S0, P1 HighMinus(11)
on on G0, S0, P0 High(12)
Figure 6: Comparison of Power States
<Claise, et. Al> Expires August, 2013 [Page 37]
Internet-Draft <EMAN Framework> February 2013
4.7 Relationships
Two Energy Objects can establish an Energy Object
Relationship.
Relationships are modeled with a Relationship class that
contains the UUID of the participants in the relationship and
a description of the type of relationship. The types of
relationships are: power source. metering, and aggregations.
The Power Source Relationship gives a view of the wiring
topology. For example: a data center server receiving power
from two specific Power Interfaces from two different PDUs.
Note: A power source relationship may or may not change as the
direction of power changes between two Energy Objects. The
relationship may remain to indicate the change of power
direction was unintended or an error condition.
The Metering Relationship gives the view of the metering
topology. Standalone meters can be placed anywhere in a power
distribution tree. For example, utility meters monitor and
report accumulated power consumption of the entire building.
Logically, the metering topology overlaps with the wiring
topology, as meters are connected to the wiring topology. A
typical example is meters that clamp onto the existing wiring.
The Aggregation Relationship gives a model of devices that may
aggregate (sum, average, etc) values for other devices. The
Aggregation Relationship is slightly different compared to the
other relationships as this refers more to a management
function.
In some situations, it is not possible to discover the Energy
Object Relationships, and they must be set by an EnMS or
administrator. Given that relationships can be assigned
manually, the following sections describes guidelines for use.
4.8 Energy Object Relationship Conventions and Guidelines
This Energy Management framework does not impose many "MUST"
rules related to Energy Object Relationships. There are always
corner cases that could be excluded with too strict
specifications of relationships. However, this Energy
Management framework proposes a series of guidelines,
indicated with "SHOULD" and "MAY".
<Claise, et. Al> Expires August, 2013 [Page 38]
Internet-Draft <EMAN Framework> February 2013
4.8.1 Guidelines: Power Source
Power Source relationships are intended to identify the
connections between Power Interfaces. This is analogous to a
Layer 2 connection in networking devices (a "one-hop
connection").
The preferred modeling would be for Power Interfaces to
participate in Power Source Relationships.
It may happen that some Energy Objects may not have the
capability to model Power Interfaces. Therefore, it may
happen that a Power Source Relationship is established between
two Energy Objects or two non-connected Power Interfaces.
While strictly speaking Components and Power Interfaces on the
same device do provide or receive energy from each other, the
Power Source relationship is intended to show energy transfer
between Devices. Therefore the relationship is implied on the
same Device.
- An Energy Object SHOULD NOT establish a Power Source
Relationship with a Component.
- A Power Source Relationship SHOULD be established with next
known Power Interface in the wiring topology.
o The next known Power Interface in the wiring topology would
be the next device implementing the framework. In some cases
the domain of devices under management may include some
devices that do not implement the framework. In these cases,
the Power Source relationship can be established with the next
device in the topology that implements the framework and
logically shows the Power Source of the device.
- Transitive Power Source relationships SHOULD NOT be
established. For example, if an Energy Object A has a Power
Source Relationship "Poweredby" with the Energy Object B, and
if the Energy Object B has a Power Source Relationship
"Poweredby" with the Energy Object C, then the Energy Object A
SHOULD NOT have a Power Source Relationship "Poweredby" with
the Energy Object C.
4.8.2 Guidelines: Metering Relationship
<Claise, et. Al> Expires August, 2013 [Page 39]
Internet-Draft <EMAN Framework> February 2013
Metering Relationships are intended to show when one Device is
measuring the power or energy at a point in a power
distribution system. Since one point of a power distribution
system may cover many Devices with a complex wiring topology,
this relationship type can be seen as an arbitrary set.
Devices may include metering hardware for components and Power
Interfaces or for the entire Device. For example, some PDUs
may have the ability to measure Power for each Power Interface
(metered by outlet). Others may be able to control power at
each Power Interface but can only measure Power at the Power
Inlet and a total for all Power Interfaces (metered by
device).
In such cases a Device SHOULD be modeled as an Energy Object
that meters all of its Power Outlets and each Power Outlet MAY
be metered by the Energy Object representing the Device.
- A Metering Relationship MAY be established with any other
Energy Object, Component, or Power Interface.
- Transitive Metering relationships MAY be used.
- When there is a series of meters for one Energy Object, the
Energy Object MAY establish a Metering relationship with one
or more of the meters.
4.8.3 Guidelines: Aggregation
Aggregation relationships are intended to identify when one
device is used to accumulate values from other devices.
Typically this is for energy or power values among devices and
not for Components or Power Interfaces on the same device.
The intent of Aggregation relationships is to indicate when
one device is providing aggregate values for a set of other
devices when it is not obvious from the power source or simple
containment within a device.
Establishing aggregation relationships within the same device
would make modeling more complex and the aggregated values can
be implied from the use of Power Inlets, outlet and Energy
Object values on the same device.
Since an EnMS is naturally a point of aggregation it is not
necessary to model aggregation for Energy Management Systems.
<Claise, et. Al> Expires August, 2013 [Page 40]
Internet-Draft <EMAN Framework> February 2013
Aggregation SHOULD be used for power and energy. It MAY be
used for aggregation of other values from the information
model, but the rules and logical ability to aggregate each
attribute is out of scope for this document.
- A Device SHOULD NOT establish an Aggregation Relationship
with a Component.
- A Device SHOULD NOT establish an Aggregation Relationship
with the Power Interfaces contained on the same device.
- A Device SHOULD NOT establish an Aggregation Relationship
with an EnMS.
- Aggregators SHOULD log or provide notification in the case
of errors or missing values while performing aggregation.
4.9 Energy Object Relationship Extensions
This framework for Energy Management is based on three
relationship types: Aggregation , Metering, and Power Source.
This framework is defined with possible future extension of
new Energy Object Relationships in mind. For example, a Power
Distribution Unit (PDU) that allows physical entities like
outlets to be "ganged" together as a logical entity for
simplified management purposes, could be modeled with an
extension called a "gang relationship", whose semantics would
specify the Energy Objects' grouping.
5. Energy Management Information Model
The following basic UML represents an information model
expression of the concepts in this framework. This
information model, provided as a reference for implementers,
is represented as a MIB in the different related IETF Energy
Monitoring documents. However, other programming structures
with different data models could be used as well.
Data modeling specifications of this information model may
where needed specify which attributes are required or
optional.
The notation use here is shorthand UML with lowercase types
considered platform or atomic types (i.e., int, string,
collection). Uppercase types denote classes described further.
Collections and cardinality are expressed via qualifier
notation. Attributes labeled static are considered class
<Claise, et. Al> Expires August, 2013 [Page 41]
Internet-Draft <EMAN Framework> February 2013
variables and global to the class. Arrows indicate
inheritance. Algorithms for class variable initialization,
constructors, or destructors are not shown. Attributes and
structures are considered readable and writeable unless
prefixed by a dash (-) that indicates read-only.
<Claise, et. Al> Expires August, 2013 [Page 42]
Internet-Draft <EMAN Framework> February 2013
EDITOR's NOTE: Pseudo-code used until consensus then UML
diagram will be substituted
class EnergyObject {
// identification / classification
index : int
identifier : uuid
alternatekey : string
// context
domainName : string
role : string
keywords [0..n] : string
importance : int
// relationship
relationships [0..n] : Relationship
// measurements
nameplate : Nameplate
power : PowerMeasurement
energy : EnergyMeasurment
demand : DemandMeasurement
// control
powerControl [0..n] : PowerStateSet
}
class Device extends EnergyObject {
eocategory : enum { producer, consumer, meter,
distributor }
}
class Component extends EnergyObject
eocategory : enum { producer, consumer, meter,
distributor }
}
classInterface extends EnergyObject{
eoIfType : enum ( inlet, outlet, both}
}
<Claise, et. Al> Expires August, 2013 [Page 43]
Internet-Draft <EMAN Framework> February 2013
class Nameplate {
nominalPower : PowerMeasurement
details : URI
}
class Relationship {
relationshipType : enum { meters, meteredby, powers,
poweredby, aggregates, aggregatedby }
relationshipObject : uuid
}
class Measurement {
multiplier: enum { -24..24}
caliber : enum { actual, estimated, trusted, assumed }
accuracy : enum { 0..10000} // hundreds of percent
}
class PowerMeasurement extends Measurement {
value : long
units : "W"
powerAttribute : PowerAttribute
}
class EnergyMeasurement extends Measurement {
startTime : time
units : "kWh"
provided : long
used : long
produced : long
}
class TimedMeasurement extends Measurement {
startTime : timestamp
value : Measurement
maximum : Measurement
}
class TimeInterval {
value : long
units : enum { seconds, miliseconds,...}
}
<Claise, et. Al> Expires August, 2013 [Page 44]
Internet-Draft <EMAN Framework> February 2013
class DemandMeasurement extends Measurement {
intervalLength : TimeInterval
interval : long
intervalMode : enum { periodic, sliding, total }
intervalWindow : TimeInterval
sampleRate : TimeInterval
status : enum { active, inactive }
measurements[0..n] : TimedMeasurements
}
class PowerStateSet {
powerSetIdentifier : int
name : string
powerStates [0..n] : PowerState
operState : int
adminState : int
reason : string
configuredTime : timestamp
}
class PowerState {
powerStateIdentifier : int
name : string
cardinality : int
maximumPower : PowerMeasurement
totalTimeInState : time
entryCount : long
}
class PowerAttribute {
// container for attributes
acQuality : ACQuality
}
class ACQuality {
acConfiguration : enum {SNGL, DEL,WYE}
avgVoltage : long
avgCurrent : long
frequency : long
unitMultiplier : int
accuracy : int
totalActivePower : long
<Claise, et. Al> Expires August, 2013 [Page 45]
Internet-Draft <EMAN Framework> February 2013
totalReactivePower : long
totalApparentPower : long
totalPowerFactor : long
phases [0..2] : ACPhase
// Could have abstract class Phase to be clear it's ACPhase
or one of the subclasses
}
class ACPhase {
phaseIndex : long
avgCurrent : long
activePower : long
reactivePower : long
apparentPower : long
powerFactor : long
}
class DelPhase extends ACPhase {
phaseToNextPhaseVoltage : long
thdVoltage : long
thdCurrent : long
}
class WYEPhase extends ACPhase {
phaseToNeutralVoltage : long
thdCurrent : long
thdVoltage : long
}
Figure 7: Information Model UML Representation
6. Example Topologies
In this section we give examples of how to use the Energy
Management framework relationships to model topologies. In
each example we show how it can be applied when Devices have
the capability to model Power Interfaces. We also show in
each example how the framework can be applied when devices
cannot support Power Interfaces but only monitor information
or control the Device as a whole. For instance, a PDU may only
<Claise, et. Al> Expires August, 2013 [Page 46]
Internet-Draft <EMAN Framework> February 2013
be able to measure power and energy for the entire unit
without the ability to distinguish among the inlets or outlet.
Together, these examples show how the framework can be adapted
for Devices with different capabilities (typically hardware)
for Energy Management.
Given for all Examples:
Device W: A computer with one power supply. Power interface 1
is an inlet for Device W.
Device X: A computer with two power supplies. Power interface
1 and power interface 2 are both inlets for Device X.
Device Y: A PDU with multiple Power Interfaces numbered 0..10.
Power interface 0 is an inlet and power interface 1..10 are
outlets.
Device Z: A PDU with multiple Power Interfaces numbered 0..10.
Power interface 0 is an inlet and power interface 1..10 are
outlets.
6.1 Example I: Simple Device with one Source
Topology:
Device W inlet 1 is plugged into Device Y outlet 8.
With Power Interfaces:
Device W has an Energy Object representing the computer
itself as well as one Power Interface defined as an inlet.
Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
The interfaces of the devices would have a Power Source
Relationship such that:
Device W inlet 1 is powered by Device Y outlet 8.
Without Power Interfaces:
Device W has an Energy Object representing the computer.
Device Y would have an Energy Object representing the PDU.
<Claise, et. Al> Expires August, 2013 [Page 47]
Internet-Draft <EMAN Framework> February 2013
The devices would have a Power Source Relationship such
that:
Device W is powered by Device Y.
6.2 Example II: Multiple Inlets
Topology:
Device X inlet 1 is plugged into Device Y outlet 8.
Device X inlet 2 is plugged into Device Y outlet 9.
With Power Interfaces:
Device X has an Energy Object representing the computer
itself. It contains two Power Interfaces defined as inlets.
Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
The interfaces of the devices would have a Power Source
Relationship such that:
Device X inlet 1 is powered by Device Y outlet 8.
Device X inlet 2 is powered by Device Y outlet 9.
Without Power Interfaces:
Device X has an Energy Object representing the computer.
Device Y has an Energy Object representing the PDU.
The devices would have a Power Source Relationship such
that:
Device X is powered by Device Y.
6.3 Example III: Multiple Sources
Topology:
Device X inlet 1 is plugged into Device Y outlet 8.
Device X inlet 2 is plugged into Device Z outlet 9.
With Power Interfaces:
Device X has an Energy Object representing the computer
itself. It contains two Power Interface defined as inlets.
<Claise, et. Al> Expires August, 2013 [Page 48]
Internet-Draft <EMAN Framework> February 2013
Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
Device Z would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
The interfaces of the devices would have a Power Source
Relationship such that:
Device X inlet 1 is powered by Device Y outlet 8.
Device X inlet 2 is powered by Device Z outlet 9.
Without Power Interfaces:
Device X has an Energy Object representing the computer.
Device Y and Z would both have respective Energy Objects
representing each entire PDU.
The devices would have a Power Source Relationship such
that:
Device X is powered by Device Y and powered by Device Z.
6.4 Relationships Between Devices
6.4.1 Power Source Topology
As described in Section 4, the power source(s) of a device is
important for energy management. The Energy Management
reference model addresses this by a Power Source Relationship.
This is a relationship among devices providing energy and
devices receiving energy.
A simple example is a PoE PSE, such as an Ethernet switch
providing power to a PoE PD, such as a desktop phone. Here
the switch provides energy and the phone receives energy.
This relationship can be seen in the figure below.
+----------+ power source +---------+
| switch | <-------------- | phone |
+----------+ +---------+
Figure 8: Simple Power Source
<Claise, et. Al> Expires August, 2013 [Page 49]
Internet-Draft <EMAN Framework> February 2013
A single power provider can act as power source for multiple
power receivers. An example is a power distribution unit
(PDU) providing AC power for multiple switches.
+-------+ power source +----------+
| PDU | <----------+--- | switch 1 |
+-------+ | +----------+
|
| +----------+
+--- | switch 2 |
| +----------+
|
| +----------+
+--- | switch 3 |
+----------+
Figure 10: Multiple Power Source
This level of modeling is sufficient if there is no need to
distinguish in monitoring and control between the individual
receivers at the switch.
However, if there is a need to monitor or control power supply
for individual receivers at the power provider, then a more
detailed level of modeling is needed.
Devices receive or provide energy at power interfaces
connecting them to a transmission medium. The Power Source
relationship can be used between power interfaces at the power
provider side as well as at the power receiver side. Figure 9
shows a power-providing device with one power interface (PI)
per connected receiving device.
<Claise, et. Al> Expires August, 2013 [Page 50]
Internet-Draft <EMAN Framework> February 2013
+-------+------+ power source +----------+
| | PI 1 | <-------------- | switch 1 |
| +------+ +----------+
| |
| +------+ power source +----------+
| PDU | PI 2 | <-------------- | switch 2 |
| +------+ +----------+
| |
| +------+ power source +----------+
| | PI 3 | <-------------- | switch 3 |
+-------+------+ +----------+
Figure 11: Power Source with Power interfaces
When required for consistency, Power interfaces may also be
modeled at the receiving device, as shown in Figure 10.
+-------+------+ power source +----+----------+
| | PI 1 | <-------------- | PI | switch 1 |
| +------+ +----+----------+
| |
| +------+ power source +----+----------+
| PDU | PI 2 | <-------------- | PI | switch 2 |
| +------+ +----+----------+
| |
| +------+ power source +----+----------+
| | PI 3 | <-------------- | PI | switch 3 |
+-------+------+ +----+----------+
Figure 12: Power Interfaces at Receiving Device
Power Source relationships are between devices and their
interfaces. They are not transitive. In the examples below
there is a PDU powering a switch powering a phone.
+-------+ power +--------+ power +---------+
| PDU | <-------- | switch | <-------- | phone |
+-------+ source +--------+ source +---------+
Figure 13: Power Source Non-Transitive
Power Source Relationships are between the PDU and the switch
and between the switch and the phone. Transitively, there
<Claise, et. Al> Expires August, 2013 [Page 51]
Internet-Draft <EMAN Framework> February 2013
exists a Power Source Relationship between the PDU and the
phone. .
+-------+ power +--------+ power +---------+
| PDU | <-------- | switch | <-------- | phone |
+-------+ source +--------+ source +---------+
^ |
| power source |
+------------------------------------------+
Figure 14: Power Source Transitive
6.4.2 Metering Topology
Case 1: Metering between two devices
The metering topology between two devices is closely related
to the power source topology. It is based on the assumption
that in many cases the power provided and the power received
is the same for both peers of a power source relationship.
Then power measured at one end can be taken as the actual
power value at the other end. Obviously, the same applies to
energy at both ends.
We define in this case a Metering Relationship between two
devices or power interfaces of devices that have a power
source relationship. Power and energy values measured at one
peer of the power source relationship are reported for the
other peer as well.
The Metering Relationship is independent of the direction of
the Power Source Relationship. The more common case is that
values measured at the power provider are reported for the
power receiver, but also the reverse case is possible with
values measured at the power receiver being reported for the
power provider.
Power Power
+-----+----------+ Source +--------+ Source +-------+
| PDU |PI + meter| <-------- | switch | <------- | phone |
+-----+----------+ Metering +--------+ +-------+
^ |
| |
+-------------------------------------------+
metering
<Claise, et. Al> Expires August, 2013 [Page 52]
Internet-Draft <EMAN Framework> February 2013
Figure 15: Direct and One Hop Metering
Case 2: Metering at a point in power distribution
A Sub-meter in a power distribution system can logically
measure the power or energy for all devices downstream from
the meter in the power distribution system. As such, a Power
metering relationship can be seen as a relationship between a
meter and all of the devices downstream from the meter.
We define in this case a Power Source relationship between a
metering device and devices downstream from the meter.
In cases where the Power Source topology cannot be discovered
or derived from the information available in the Energy
Management Domain, the Metering Topology can be used to relate
the upstream meter to the downstream devices in the absence of
specific power source relationships.
A Metering Relationship can occur between devices that are not
directly connected, as shown in Figure 16.
+---------------+
| Device 1 |
+---------------+
| PI |
+---------------+
|
+---------------+
| Meter |
+---------------+
.
.
.
+----------+ +----------+ +-----------+
| Device A | | Device B | | Device C |
+----------+ +----------+ +-----------+
Figure 16: Complex Metering Topology
An analogy to communications networks would be modeling
connections between servers (meters) and clients (devices)
when the complete Layer 2 topology between the servers and
clients is not known.
<Claise, et. Al> Expires August, 2013 [Page 53]
Internet-Draft <EMAN Framework> February 2013
6.4.3 Aggregation Topology
Some devices can act as aggregation points for other devices.
For example, a PDU controller device may contain the summation
of power and energy readings for many PDU devices. The PDU
controller will have aggregate values for power and energy for
a group of PDU devices.
This aggregation is independent of the physical power or
communication topology.
An Aggregation Relationship is an Energy Object Relationship
where one Energy Object (called the Aggregate Energy Object)
aggregates the Energy Management information of one or more
other Energy Objects. These Energy Objects are said to have
an Aggregation Relationship.
The functions that the aggregation point may perform include
the calculation of values such as average, count, maximum,
median, minimum, or the listing (collection) of the
aggregation values, etc.
Based on the experience gained on aggregations at the IETF
[draft-ietf-ipfix-a9n-08], the aggregation function in the
EMAN framework is limited to the summation.
When aggregation occurs across a set of entities, values to be
aggregated may be missing for some entities. The EMAN
framework does not specify how these should be treated, as
different implementations may have good reason to take
different approaches. One common treatment is to define the
aggregation as missing if any of the constituent elements are
missing (useful to be most precise). Another is to treat the
missing value as zero (useful to have continuous data
streams).
The specifications of aggregation functions are out of scope
of the EMAN framework, but must be clearly specified by the
equipment vendor.
7. Relationship with Other Standards
This energy management framework uses, as much as possible,
existing standards efforts, especially with respect to
information modeling and data modeling [RFC3444].
<Claise, et. Al> Expires August, 2013 [Page 54]
Internet-Draft <EMAN Framework> February 2013
The data model for power- and energy-related objects is based
on IEC 61850.
Specific examples include:
The scaling factor, which represents Energy Object usage
magnitude, conforms to the IEC 61850 definition of unit
multiplier for the SI (System International) units of measure.
The electrical characteristic is based on the ANSI and IEC
Standards, which require that we use an accuracy class for
power measurement. ANSI and IEC define the following accuracy
classes for power measurement:
IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3.
ANSI C12.20 class 0.2, 0.5
The electrical characteristics and quality adhere closely to
the IEC 61850 7-2 standard for describing AC measurements.
The power state definitions are based on the DMTF Power State
Profile and ACPI models, with operational state extensions.
8. Security Considerations
Regarding the data attributes specified here, some or all may
be considered sensitive or vulnerable in some network
environments. Reading or writing these attributes without
proper protection such as encryption or access authorization
may have negative effects on the network capabilities.
Security Considerations for SNMP
Readable objects in MIB modules (i.e., objects with a MAX-
ACCESS other than not-accessible) may be considered sensitive
or vulnerable in some network environments. It is thus
important to control GET and/or NOTIFY access to these objects
and possibly to encrypt the values of these objects when
sending them over the network via SNMP.
<Claise, et. Al> Expires August, 2013 [Page 55]
Internet-Draft <EMAN Framework> February 2013
The support for SET operations in a non-secure environment
without proper protection can have a negative effect on
network operations. For example:
Unauthorized changes to the Energy Management Domain or
business context of an Energy Object may result in
misreporting or interruption of power.
Unauthorized changes to a power state may disrupt the power
settings of the different Energy Objects, and therefore the
state of functionality of the respective Energy Objects.
Unauthorized changes to the demand history may disrupt proper
accounting of energy usage.
With respect to data transport, SNMP versions prior to SNMPv3
did not include adequate security. Even if the network itself
is secure (for example, by using IPsec), there is still no
secure control over who on the secure network is allowed to
access and GET/SET (read/change/create/delete) the objects in
these MIB modules.
It is recommended that implementers consider the security
features as provided by the SNMPv3 framework (see [RFC3410],
section 8), including full support for the SNMPv3
cryptographic mechanisms (for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is not
recommended. Instead, it is recommended to deploy SNMPv3 and
to enable cryptographic security. It is then a
customer/operator responsibility to ensure that the SNMP
entity giving access to an instance of these MIB modules is
properly configured to give access to the objects only to
those principals (users) that have legitimate rights to GET or
SET (change/create/delete) them.
9. IANA Considerations
9.1 IANA Registration of new Power State Set
This document specifies an initial set of Power State Sets.
The list of these Power State Sets with their numeric
identifiers is given is Section 4. IANA maintains the lists of
Power State Sets.
<Claise, et. Al> Expires August, 2013 [Page 56]
Internet-Draft <EMAN Framework> February 2013
New assignments for Power State Set are administered by IANA
through Expert Review [RFC5226], i.e., review by one of a
group of experts designated by an IETF Area Director. The
group of experts MUST check the requested state for
completeness and accuracy of the description. A pure vendor
specific implementation of Power State Set shall not be
adopted; since it would lead to proliferation of Power State
Sets.
Power states in a Power State Set are limited to 255 distinct
values. New Power State Set must be assigned the next
available numeric identifier that is a multiple of 256.
9.1.1 IANA Registration of the IEEE1621 Power State Set
This document specifies a set of values for the IEEE1621 Power
State Set [IEEE1621]. The list of these values with their
identifiers is given in Section 4.6.2. IANA created a new
registry for IEEE1621 Power State Set identifiers and filled
it with the initial list of identifiers.
New assignments (or potentially deprecation) for the IEEE1621
Power State Set is administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts
designated by an IETF Area Director. The group of experts
must check the requested state for completeness and accuracy
of the description.
9.1.2 IANA Registration of the DMTF Power State Set
This document specifies a set of values for the DMTF Power
State Set. The list of these values with their identifiers is
given in Section 4. IANA has created a new registry for DMTF
Power State Set identifiers and filled it with the initial
list of identifiers
.
New assignments (or potentially deprecation) for the DMTF
Power State Set is administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts
designated by an IETF Area Director. The group of experts
must check the conformance with the DMTF standard [DMTF], on
the top of checking for completeness and accuracy of the
description.
<Claise, et. Al> Expires August, 2013 [Page 57]
Internet-Draft <EMAN Framework> February 2013
9.1.3 IANA Registration of the EMAN Power State Set
This document specifies a set of values for the EMAN Power
State Set. The list of these values with their identifiers is
given in Section 4.6.4. IANA has created a new registry for
EMAN Power State Set identifiers and filled it with the
initial list of identifiers.
New assignments (or potentially deprecation) for the EMAN
Power State Set is administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts
designated by an IETF Area Director. The group of experts
must check the requested state for completeness and accuracy
of the description.
9.1.4 Batteries Power State Set
Batteries have operational and administrational states that
could be represented as a power state set. Since the work for
battery management is parallel to this document, we are not
proposing any Power State Sets for batteries at this time.
9.2 Updating the Registration of Existing Power State Sets
With the evolution of standards, over time, it may be
important to deprecate some of the existing the Power State
Sets, or to add or deprecate some Power States within a Power
State Set.
The registrant shall publish an Internet-draft or an
individual submission with the clear specification on
deprecation of Power State Sets or Power States registered
with IANA. The deprecation or addition shall be administered
by IANA through Expert Review [RFC5226], i.e., review by one
of a group of experts designated by an IETF Area Director. The
process should also allow for a mechanism for cases where
others have significant objections to claims on deprecation of
a registration.
<Claise, et. Al> Expires August, 2013 [Page 58]
Internet-Draft <EMAN Framework> February 2013
10. Acknowledgments
The authors would like to Michael Brown for improving the text
dramatically, and Rolf Winter for his feedback. The award for
the best feedback and reviews goes to Bill Mielke. Bruce
Nordman helped a lot in the framework brainstorming with
numerous conference calls and discussions. Finally, the
authors would like to thank the EMAN chairs: Nevil Brownlee,
Bruce Nordman, and Tom Nadeau.
11. References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet Standard Management Framework ", RFC 3410,
December 2002
[RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005
[RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC
5226, May 2008
[RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB
(Version4)", RFC 6933, May 2013
Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2
(SMIv2", RFC 2578, April 1999
[RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
between Information Models and Data Models", RFC
3444, January 2003
<Claise, et. Al> Expires August, 2013 [Page 59]
Internet-Draft <EMAN Framework> February 2013
[RFC5101bis] Claise, B., Ed., and Trammel, T., Ed.,
"Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information ", draft-ietf-ipfix-protocol-rfc5101bis-
08, (work in progress), June 2013
[RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling Language
for the Network Configuration Protocol (NETCONF)",
RFC 6020, October 2010
[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm
[IEEE1621] "Standard for User Interface Elements in Power
Control of Electronic Devices Employed in
Office/Consumer Environments", IEEE 1621, December
2004
[LLDP] IEEE Std 802.1AB, "Station and Media Control
Connectivity Discovery", 2005
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management
Information Base extension module for TIA-TR41.4
media endpoint discovery information", July 2005
[EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
M. Chandramouli, "Requirements for Energy
Management", draft-ietf-eman-requirements-14, (work
in progress), May 2013
[EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy Object
Contet MIB", draft-ietf-eman-energy-aware-mib-08,
(work in progress), April 2013
[EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
Dietz, T., and B. Claise, "Power and Energy
Monitoring MIB", draft-ietf-eman-energy-monitoring-
mib-05, (work in progress), April 2013
[EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
Definition of Managed Objects for Battery
Monitoring", draft-ietf-eman-battery-mib-08, (work in
progress), February 2013
[EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
"Energy Management (EMAN) Applicability Statement",
<Claise, et. Al> Expires August, 2013 [Page 60]
Internet-Draft <EMAN Framework> February 2013
draft-ietf-eman-applicability-statement-03, (work in
progress), April 2013
[ITU-T-M-3400] TMN recommandation on Management Functions
(M.3400), 1997
[NMF] "Network Management Fundamentals", Alexander Clemm,
ISBN: 1-58720-137-2, 2007
[TMN] "TMN Management Functions : Performance Management",
ITU-T M.3400
[1037C] US Department of Commerce, Federal Standard 1037C,
http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm
[IEEE100] "The Authoritative Dictionary of IEEE Standards
Terms"
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?pu
number=4116785
[ISO50001] "ISO 50001:2011 Energy management systems -
Requirements with guidance for use",
http://www.iso.org/
[IEC60050] International Electrotechnical Vocabulary
http://www.electropedia.org/iev/iev.nsf/welcome?openf
orm
[IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
2009 - IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - 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: Data Terminal Equipment (DTE) - Power via
Media Dependent Interface (MDI) Enhancements",
October 2009
[DMTF] "Power State Management Profile DMTF DSP1027 Version
2.0" December 2009
http://www.dmtf.org/sites/default/files/standards/doc
uments/DSP1027_2.0.0.pdf
[IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
Management", 2010, Wiley Publishing
<Claise, et. Al> Expires August, 2013 [Page 61]
Internet-Draft <EMAN Framework> February 2013
[X.700] CCITT Recommendation X.700 (1992), Management
framework for Open Systems Interconnection (OSI) for
CCITT applications
[ASHRAE-201] "ASHRAE Standard Project Committee 201
(SPC 201)Facility Smart Grid Information
Model", http://spc201.ashraepcs.org
[CHEN] "The Entity-Relationship Model: Toward a Unified View
of Data", Peter Pin-shan Chen, ACM Transactions on
Database Systems, 1976
[CISCO-EW] "Cisco EnergyWise Design Guide", John Parello,
Roland Saville, Steve Kramling, Cisco Validated
Designs, September 2010,
http://www.cisco.com/en/US/docs/solutions/Enterprise/
Borderless_Networks/Energy_Management/energywisedg.ht
ml
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
<Claise, et. Al> Expires August, 2013 [Page 62]
Internet-Draft <EMAN Framework> February 2013
Phone:
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
<Claise, et. Al> Expires August, 2013 [Page 63]
