Network Working Group B. Claise
Internet-Draft J. Parello
Intended Status: Informational Cisco Systems, Inc.
Expires: September 12, 2012 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd.
B. Nordman
Lawrence Berkeley
National Laboratory
March 12, 2012
Energy Management Framework
draft-ietf-eman-framework-04
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 September, 2012.
<Claise, et. Al> Expires Sept 12 2012 [Page 1]
Internet-Draft <EMAN Framework> March 2012
Copyright Notice
Copyright (c) 2012 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 within or connected to communication
networks, and components thereof. The framework defines an
Energy Management Domain as a set of Energy Objects, for
which each Energy Object is identified, classified and
given context. Energy Objects can be monitored and/or
controlled with respect to Power, Power State, Energy,
Demand, Power Quality, and battery. Additionally the
framework models relationships and capabilities between
Energy Objects.
<Claise, et. Al> Expires Sep 12, 2012 [Page 2]
Internet-Draft <EMAN Framework> March 2012
Table of Contents
1. Introduction............................................5
1.1. Energy Management Document Overview................6
2. Terminology.............................................7
Energy Management.......................................8
Energy Management System (EnMS).........................8
ISO Energy Management System............................9
Energy..................................................9
Power..................................................10
Demand.................................................10
Power Quality..........................................10
Electrical Equipment...................................11
Non-Electrical Equipment (Mechanical Equipment)........11
Energy Object..........................................11
Electrical Energy Object...............................11
Non-Electrical Energy Object...........................11
Energy Monitoring......................................11
Energy Control.........................................12
Energy Management Domain...............................12
Energy Object Identification...........................12
Energy Object Context..................................13
Energy Object Relationship.............................13
Energy Object Parent...................................14
Energy Object Child....................................15
Power State............................................15
Power State Set........................................16
Nameplate Power........................................16
3. Requirements & Use Cases...............................16
4. Energy Management Issues...............................18
4.1. Power Supply......................................19
4.1.1 Identification of Power Supply and Powered
Devices.............................................20
4.1.2 Multiples Devices Supplied by a Single Power
Line................................................21
4.1.3 Multiple Power Supply for a Single Powered
Device..............................................22
4.1.4 Bidirectional Power Interfaces................23
4.1.5 Relevance of Power Supply Issues..............23
4.1.6 Remote Power Supply Control...................24
4.2. Power and Energy Measurement......................24
4.2.1 Local Estimates...............................24
4.2.2 Management System Estimates...................25
4.3. Reporting Sleep and Off States....................25
4.4. Energy Device and Energy Device Components........25
4.5. Non-Electrical Equipment..........................26
5. Energy Management Reference Model......................26
<Claise, et. Al> Expires Sep 12, 2012 [Page 3]
Internet-Draft <EMAN Framework> March 2012
5.1. Energy Object, Energy Object Components and
Containment Tree.......................................29
6. Framework High Level Concepts and Scope................30
6.1. Energy Object and Energy Management Domain........31
6.2. Power Interface...................................31
6.3. Energy Object Identification and Context..........32
6.2.1 Energy Object Identification..................32
6.2.2 Context in General............................32
6.2.3 Context: Importance...........................32
6.2.4 Context: Keywords.............................33
6.2.5 Context: Role.................................34
6.4. Energy Object Relationships.......................34
6.4.1 Energy Object Children Discovery..............36
6.4.2 Energy Object Relationship Conventions and
Guidelines..........................................37
6.5. Energy Monitoring.................................37
6.5.1 Power Measurement.............................38
6.6. Energy Control....................................40
6.5.1 IEEE1621 Power State Series...................41
6.5.2 DMTF Power State Series.......................41
6.5.3 EMAN Power State Set..........................42
6.7. Energy Objects Relationship Extensions............45
7. Structure of the Information Model: UML
Representation............................................45
8. Configuration..........................................50
9. Fault Management.......................................51
10. Examples..............................................52
11. Relationship with Other Standards Development
Organizations.............................................55
11.1. Information Modeling.............................55
12. Security Considerations...............................56
12.1. Security Considerations for SNMP....................56
13. IANA Considerations...................................57
14. Acknowledgments.......................................57
15. References............................................57
Normative References...................................57
Informative References.................................58
TO DO/OPEN ISSUE
- Add figures to the section 10 examples
- The figure 5 and 6 from the framework must be updated
with the notion of power interfaces
- Aggregation Relationship is different compared to the
other Relationships. There are some use cases: a building
mediator implementing the MIB, with some subtended
devices, a meter for many devices, etc... However, this
<Claise, et. Al> Expires Sep 12, 2012 [Page 4]
Internet-Draft <EMAN Framework> March 2012
is also a generic function. We could argue that an
aggregation function is something that is not particular
to the EMAN context.
- Since we speak about Power Interface now, we need to
double the EO Relationships here and in [EMAN-AWARE-MIB]:
Example: poweredBy versus providingPower.
- Energy Interface or Power Interface, which term is best?
- The UML must be aligned with the latest [EMAN-AWARE-MIB]
and [EMAN-AWARE-MIB] document versions.
- JOHN: Does the multiple URIs requirement apply to all of
the defined relationship fields? For example, can
eoProxyBy have multiple URIs? What about the other
relationships? Answer: yes, but need to be explained
- Needs scrub for terminology and new "provide and receive
energy" consensus. Power and energy also incorrectly used
interchangeably from merged text.
- Some reference in the terminology section will certainly
have to be removed.
- Complete the section "Energy Object Relationship
Guidelines and Conventions"
1. Introduction
Network management is divided into the five main areas
defined in the ISO Telecommunications Management Network
model: Fault, Configuration, Accounting, Performance, and
Security Management (FCAPS) [X.700]. Absent from this
management model is any consideration of Energy Management,
which is now becoming a critical area of concern worldwide
as seen in [ISO50001].
Note that Energy Management has particular challenges in
that a power distribution network is responsible for the
supply of energy to various devices and components, while a
separate communication network is typically used to monitor
and control the power distribution network.
This document defines a framework for providing Energy
Management for devices within or connected to communication
networks. The framework describes how to identify,
classify and provide context for a device in a
communications network from the point of view of Energy
Management.
The identified device (Energy Device) or identified
components within a device (Energy Device Component) can
then be monitored for Energy Management by obtaining
<Claise, et. Al> Expires Sep 12, 2012 [Page 5]
Internet-Draft <EMAN Framework> March 2012
measurements for Power, Energy, Demand and Power Quality.
If a device contains batteries, they can be also be
monitored and managed. An Energy Object state can be
monitored or controlled by providing an interface expressed
as one or more Power State Sets. The most basic example of
Energy Management is a single Energy Object reporting
information about itself. However, in many cases, energy
is not measured by the Energy Object itself, but by a meter
located upstream in the power distribution tree. An
example is a power distribution unit (PDU) that measures
energy received by attached devices and may report this to
an Energy Management System (EnMS). Therefore, Energy
Objects are recognized as having relationships to other
devices in the network from the point of view of Energy
Management. These relationships include Aggregation
Relationship, Metering Relationship, Power Source
Relationship, and Proxy Relationship.
1.1. Energy Management Document 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] provides a
list of use cases, a cross-reference between existing
standards and the EMAN standard, and shows how this
framework relates to other frameworks.
The Energy-aware Networks and Devices MIB [EMAN-AWARE-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] contains
objects for monitoring of Power, Energy, Demand, Power
Quality and Power States.
Further, the battery monitoring MIB [EMAN-BATTERY-MIB]
defines managed objects that provide information on the
status of batteries in managed devices.
<Claise, et. Al> Expires Sep 12, 2012 [Page 6]
Internet-Draft <EMAN Framework> March 2012
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].
EDITOR'S NOTE:
- All terms are copied over from the version
5 of the [EMAN-TERMINOLOGY] draft. The only
differences in definition are
o Dependency Relationship is removed
o Energy Object Relationship improved to
remove the Dependency Relationship
o "Reference: herein" has not been copied
over from the terminology draft.
- "All" terms have been copied. Potentially,
some unused terms might have to be removed.
Alternatively, as this document is the first
standard track document in the EMAN WG, it
may become the reference document for the
terminology (instead of cutting/pasting the
terminology in all drafts)
- RFC-EDITOR: the Relationships need to be
updated.
- The Power Interface definition has been
added
Energy Device
An Energy Device is an Energy Object that may be
monolithic or contain Energy Device Components
Energy Device Component
An Energy Device Component is an Energy Object
contained in an Energy Device, for which the containing
Energy Device provides individual energy management
functions. Typically, the Energy Device Component
is part the Energy Device physical containment tree
in the ENTITY-MIB [RFC4133].
<Claise, et. Al> Expires Sep 12, 2012 [Page 7]
Internet-Draft <EMAN Framework> March 2012
Energy Management
Energy Management is a set of functions for
measuring, modeling, planning, and optimizing
networks to ensure that the network elements
and attached devices use energy efficiently and
is appropriate for the nature of the
application and the cost constraints of the
organization.
Reference: Adapted from [ITU-T-M-3400]
Example: A set of computer systems that will
poll electrical meters and store the readings
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 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 being Energy
Management.
Reference: Adapted from [1037C]
Example: A single computer system that polls
data from devices using SNMP
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.
<Claise, et. Al> Expires Sep 12, 2012 [Page 8]
Internet-Draft <EMAN Framework> March 2012
An 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).
ISO Energy Management System
Energy Management System as defined by
[ISO50001]
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 kilo-watt 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 Sep 12, 2012 [Page 9]
Internet-Draft <EMAN Framework> March 2012
Power
The time rate at which energy is emitted,
transferred, or received; usually expressed in
watts (or in 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. typically kilowatts
2. Energy providers typically bill by Demand
measurements as well as for maximum Demand
per billing periods. Power values may spike
during short-terms by devices, but Demand
measurements recognize that maximum Demand
does not equal maximum Power during an
interval.
Power Quality
Characteristics of the electric current,
voltage 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]
<Claise, et. Al> Expires Sep 12, 2012 [Page 10]
Internet-Draft <EMAN Framework> March 2012
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 a piece of equipment
that is part of or attached to a
communications network that is monitored,
controlled, or aids in the management of
another device for Energy Management.
Electrical Energy Object
An Electrical Energy Object (EEO) is an Energy
Object that is a piece of Electrical Equipment
Non-Electrical Energy Object
A Non-Electrical Energy Object (NEEO) an
Energy Object that is a piece of Non-
Electrical Equipment.
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 Sep 12, 2012 [Page 11]
Internet-Draft <EMAN Framework> March 2012
NOTES:
1. This could include Energy, Power, Demand,
Power Quality, Context and/or Battery
information.
Energy Control
Energy Control is a part of Energy Management
that deals with directing influence over
Energy Objects.
NOTES:
1. Typically in order to optimize or ensure its
efficiency.
Energy Management Domain
An Energy Management Domain is a set of Energy Objects
where all objects in the domain are considered one unit
of management.
For example, power distribution units and all of the
attached Energy Objects are part of the same Energy
Management Domain.
For example, all EEO's drawing power from the
same distribution panel with the same AC
voltage within a building, or all EEO's in a
building for which there is one main meter,
would comprise an Energy Management Domain.
NOTES:
1. Typically, this set will have as members all
EO's that are powered from the same source.
Energy Object Identification
Energy Object Identification is a set of
attributes that enable an Energy Object to be:
uniquely identified among all Energy Management
Domains; linked to other systems; classified as
to type, model, and or manufacturer
<Claise, et. Al> Expires Sep 12, 2012 [Page 12]
Internet-Draft <EMAN Framework> March 2012
Energy Object Context
Energy Object Context is a set of attributes
that allow an Energy Management System to
classify the use of the Energy Object within an
organization.
NOTES:
1. The classification could contain the use
and/or the ranking of the Energy Object as
compared to other Energy Objects in the
Energy Management Domain.
Energy Object Relationship
An Energy Object Relationship is a functional association
among Energy Objects
NOTES
1. Relationships can be named and could include
Aggregation, Metering, Power Source, Proxy and
Dependency.
2. The Energy Object is the noun or entity in the
relationship with the relationship described as the verb.
Example: If EO x is a piece of Electrical Equipment and
EO y is an electrical meter clamped onto x's power cord,
then x and y have a Metering Relationship. It follows
that y meters x and that x is metered by y.
Reference: Adapted from [CHEN]
Aggregation Relationship
An Aggregation Relationship is an Energy Object
Relationship where one Energy Object aggregates the
Energy Management information of one or more other Energy
Objects. These Energy Objects are referred to as having
an Aggregation Relationship.
NOTES:
Aggregate values may be obtained by reading values from
multiple Energy Objects and producing a single value of
<Claise, et. Al> Expires Sep 12, 2012 [Page 13]
Internet-Draft <EMAN Framework> March 2012
more significant meaning such as average, count, maximum,
median, minimum, mode and most commonly sum [SQL].
Metering Relationship
A Metering Relationship is an Energy Object Relationship
where one Energy Object measures the Power or Energy of
one or more other Energy Objects. These Energy Objects
are referred to as having a Metering Relationship.
Example: a PoE port on a switch measures the Power it
provides to the connected Energy Object.
Power Source Relationship
A Power Source Relationship is an Energy Object
Relationship where one Energy Object is the source of or
distributor of Power to one or more other Energy Objects.
These Energy Objects are referred to as having a Power
Source Relationship.
Example: a PDU provides power for a connected device.
Proxy Relationship
A Proxy Relationship is an Energy Object Relationship
where one Energy Object provides the Energy Management
capabilities on behalf of one or more other Energy
Objects. These Energy Objects are referred to as having a
Proxy Relationship.
Example: a protocol gateways device for Building
Management Systems (BMS) with subtended devices.
Energy Object Parent
An Energy Object Parent is an Energy Object
that participates in an Energy Object
Relationships and is considered as providing
the capabilities in the relationship.
Example: in a Metering Relationship, the
Energy Object that is metering is called the
Energy Object Parent, while the Energy Object
<Claise, et. Al> Expires Sep 12, 2012 [Page 14]
Internet-Draft <EMAN Framework> March 2012
that is metered is called the Energy Object
Child.
Energy Object Child
An Energy Object Child is an Energy Object
that participates in an Energy Object
Relationships and is considered as receiving
the capabilities in the relationship.
Example: in a Metering Relationship, the
Energy Object that is metering is called the
Energy Object Parent, while the Energy Object
that is metered is called the Energy Object
Child.
Power Interface
A power interface is an Energy Object that serves as a
interconnection among Energy Objects, and participates in
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]
NOTES:
1. A Power State can be seen as a power setting
of an Energy Object that influences the
power consumption, the available
functionality, and the responsiveness of the
Energy Object.
2. A Power State can be viewed as one method
for Energy Control
<Claise, et. Al> Expires Sep 12, 2012 [Page 15]
Internet-Draft <EMAN Framework> March 2012
Power State Set
A collection of Power States that comprise one
named or logical grouping of control is a
Power State Set.
Example: The states {on, off, and sleep} as
defined in [IEEE1621], or the 16 power states
as defined by the [DMTF] can be considered two
different Power State Sets.
Nameplate Power
The Nameplate Power is the maximal (nominal)
Power that a device can support.
NOTES:
1. This is typically determined via load
testing and is specified by the manufacturer
as the maximum value required for operating
the device. This is sometimes referred to
as the worst-case Power. The actual or
average Power may be lower. The Nameplate
Power is typically used for provisioning and
capacity planning.
3. Requirements & Use Cases
Requirements for Power and Energy monitoring for networking
devices are specified in [EMAN-REQ]. The Energy Management
use cases covered by this framework are covered in the EMAN
applicability statement document in [EMAN-AS]. Typically
requirements and use cases for communication networks cover
the devices that make up the communication network and
endpoints.
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 directly or indirectly be monitored or controlled
<Claise, et. Al> Expires Sep 12, 2012 [Page 16]
Internet-Draft <EMAN Framework> March 2012
by an Energy Management System (EnMS) using the Internet
protocol, for example:
- Simple electrical appliances / fixtures
- Hosts, such as a PC, a datacenter server, or a
printer
- Routers
- Switches
- A component within devices, such as a battery inside
a PC, a line card inside a switch, etc...
- 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 distributions and communication networks.
For an Energy Management framework to be useful, it should
also apply to these types of separate networks as they
connect and interact with a communications network.
This is the first version of the IETF Energy Management
framework. Though it already covers a wide range of use
cases, there are still a lot of potential ones that are not
covered, yet. A simple example is the limitation to
discrete power states without parameters. Some devices
have energy-related properties that not well described with
discrete power
states, for example a dimmer with a continuous power range
from 0%-100%. Other devices may have even more parameters
than just a single percentage value.
Also policy-controlled energy management functions at
Energy Devices are not covered. An example would be a
policy telling a Energy Device not to raise its power above
a given power value. These and further use cases would
need an extension of the framework described in this
document. It is up to future updates of this document to
select more of such use-cases and to cover them by
extensions or revisions of the present framework.
<Claise, et. Al> Expires Sep 12, 2012 [Page 17]
Internet-Draft <EMAN Framework> March 2012
4. Energy Management Issues
This section explains special issues of Energy Management
particularly concerning power supply, Power and Energy
metering, and the reporting of low Power States.
To illustrate the issues we start with a simple and basic
scenario with a single powered device that receives Energy
and that 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, for example 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.).
This and similar cases are well understood and likely to
become very common for 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, for example, energy-specific MIB
modules [RFC2578] and YANG modules [RFC6020].
However, the nature of energy supply and use introduces
some issues that are special to Energy Management. The
following subsections address these issues and illustrate
them by extending the basic scenario in Figure 1.
<Claise, et. Al> Expires Sep 12, 2012 [Page 18]
Internet-Draft <EMAN Framework> March 2012
4.1. Power Supply
A powered device may supply itself with power. Sensors,
for example, commonly have batteries or harvest Energy.
However, most powered devices that are managed by an EnMS
receive external power.
While a huge number of devices receive Power from unmanaged
supply systems, the number of manageable power supply
devices is increasing.
In datacenters, many Power Distribution Units (PDUs) allow
the EnMS to switch power individually for each socket and
also to measure the provided Power. Here there is a big
difference to many other network management tasks: In such
and similar cases, switching power supply for a powered
device or monitoring its power is not done by communicating
with the actual powered device, but with an external power
supply device (in this case, the PDU). Note that those
external power supply devices may be an external power
meter).
Consequently, a standard for Energy Management must not
just cover the powered devices that provide services for
users, but also the power supply devices (which are powered
devices as well) that monitor or control the power supply
for other powered devices.
A very simple device such as a plain 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 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 a power
supply device, see Figure 2.
+-----------------------------------------+
| energy management system |
+-----------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------------+ +-----------------+
| power supply |########| powered device |
+--------------+ +-----------------+
<Claise, et. Al> Expires Sep 12, 2012 [Page 19]
Internet-Draft <EMAN Framework> March 2012
######## power supply line
Figure 2: Power Supply
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 be need to identify the
supplying power supply device.
* A given power supply device may need to identify
the
corresponding supplied powered device(s).
o Aggregation of monitoring and control for multiple
powered
devices
* A power supply device may supply multiple powered
devices with 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.
4.1.1 Identification of Power Supply and Powered Devices
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 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
<Claise, et. Al> Expires Sep 12, 2012 [Page 20]
Internet-Draft <EMAN Framework> March 2012
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.
4.1.2 Multiples 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 required that the EnMS has the full list of powered
devices connected to a single outlet as in Figure 3.
+---------------------------------------+
| energy management system |
+---------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------+ +------------------+
| power |########| powered device 1 |
| supply | # +------------------+-+
+--------+ #######| powered device 2 |
# +------------------+-+
#######| powered device 3 |
+------------------+
<Claise, et. Al> Expires Sep 12, 2012 [Page 21]
Internet-Draft <EMAN Framework> March 2012
Figure 3: Multiple Powered Devices Supplied
by Single Power Line
With this list, the single status value has 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
consequences of control actions can only be partially
known.
4.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 just making internal
power converters (for example, from AC mains power to DC
internal power) redundant, 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 |
+----------+ +----------+ +----------+
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
<Claise, et. Al> Expires Sep 12, 2012 [Page 22]
Internet-Draft <EMAN Framework> March 2012
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.
4.1.4 Bidirectional Power Interfaces
Low wattage DC systems may allow power to be delivered bi-
directionally. Energy stored in batteries on one device
can be delivered back to a power hub which redirects the
current to power another device. In this situation, the
interface can function as both an inlet and outlet.
The framework for Energy Management introduces the notion
of Power Interface, which can model a power inlet and a
power outlet, depending on the conditions. The Power
Interface reports power direction, as well as the energy
received, supplied and the net result.
4.1.5 Relevance of Power Supply Issues
In some scenarios, the problems with power supply do not
exist or can be sufficiently solved. 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 two connected
devices.
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.
And, AC power lines support supplying multiple powered
devices with a single line and commonly do.
<Claise, et. Al> Expires Sep 12, 2012 [Page 23]
Internet-Draft <EMAN Framework> March 2012
4.1.6 Remote Power Supply Control
There are three ways for an energy management system to
change the Power State of an 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 devices a command to switch to another
Power State. The third is to utilize an upstream device
(to the powered device) that has capabilities to switch on
and off power at its outlet.
Some Energy Objects do not have capabilities for receiving
commands or changing their Power States by themselves.
Such Energy Objects may be controlled by switching on and
off the power supply for them and so have particular need
for the third method.
In Figure 4, the power supply can switch on and off power
at its power outlet and thereby switch on and off power
supply for the connected powered device.
4.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 measurements 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 expected that in
future more devices will include instrumentation for power
and energy measurements, but this may take quite some time.
4.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 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.).
<Claise, et. Al> Expires Sep 12, 2012 [Page 24]
Internet-Draft <EMAN Framework> March 2012
The 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.
4.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 also 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. Such
information can be obtained by monitoring the device with
conventional means of performance monitoring.
4.3. Reporting Sleep and Off States
Low power modes 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 modes, as
power levels are usually static and internal clocks can
track elapsed time in these modes.
Some devices do have out-of-band or proxy abilities to
respond to network requests in low-power modes. 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.
4.4. Energy Device and Energy Device Components
While the primary focus of energy management is entire
powered devices, i.e. Energy Devices, sometimes it is
necessary or desirable to manage Energy Device Components
such as line cards, fans, disks, etc.
<Claise, et. Al> Expires Sep 12, 2012 [Page 25]
Internet-Draft <EMAN Framework> March 2012
The concept of a Power Interface may not apply to Energy
Device Components since they may receive Energy from a pool
available from the encompassing device. For example, a DC-
powered blade server in a chassis may have its own identity
on the network and be managed as a single device but its
energy may be received from a shared power source among all
blades in the chassis.
4.5. Non-Electrical Equipment
The primary focus of this framework is for the management
of Electrical Equipment. Some Non-Electrical Equipment may
be connected to a communication networks and could have
their energy managed if normalize to the electrical units
for power and energy.
Some examples of Non-Electrical Equipment that may be
connected to a communication network are:
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: tools (drills, screwdrivers, assembly
line conveyor belts). The energy measured is non-
electrical (compressed air).
EDITOR'S NOTE: Note that, in such as case, some might
argue that the "energy interface" term might be more
accurate than Power Interface. To be discussed.
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).
5. Energy Management Reference Model
The scope of this framework is to enable network and
network-attached devices to be administered for Energy
Management. The framework recognizes that in complex
deployments Energy Objects may communicate over varying
protocols. For example the communications network may use
IP Protocols (SNMP) but attached Energy Object Parent may
communicate to Energy Object Children over serial
communication protocols like BACNET, MODBUS etc. The
likelihood of getting these different topologies to convert
<Claise, et. Al> Expires Sep 12, 2012 [Page 26]
Internet-Draft <EMAN Framework> March 2012
to a single protocol is not very high considering the rate
of upgrades of facilities and energy related devices.
Therefore the framework must address the simple case of a
uniform IP network and a more complex mixed
topology/deployment.
As displayed in Figure 5, the most basic energy management
reference model is composed of an EnMS that obtains Energy
Management information from Energy Objects. The Energy
Object (EO) returns information for Energy Management
directly to the EnMS.
The protocol of choice for Energy Management is SNMP, as
three MIBs are specified for Energy Management: the energy-
aware MIB [EMAN-AWARE-MIB], the energy monitoring MIB
[EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB].
However, the EMAN requirement document [EMAN-REQ] also
requires support for a push model distribution of time
series values. The following diagrams mention IPFIX
[RFC5101] as one possible solution for implementing a push
mode transfer, however this is for illustration purposes
only. The EMAN standard does not require the use of IPFIX
and acknowledges that other alternative solutions may also
be acceptable.
+---------------+
| EnMS | - -
+-----+---+-----+ ^ ^
| | | |
| | |S |I
+---------+ +----------+ |N |P
| | |M |F
| | |P |I
+-----------------+ +--------+--------+ | |X
| EO 1 | ... | EO N | v |
+-----------------+ +-----------------+ - -
Figure 5: Simple Energy Management
As displayed in the Figure 5, a more complex energy
reference model includes Energy Managed Object Parents and
Children. The Energy Managed Object Parent returns
information for themselves as well as information according
to the Energy Managed Object Relationships.
+---------------+
<Claise, et. Al> Expires Sep 12, 2012 [Page 27]
Internet-Draft <EMAN Framework> March 2012
| EnMS | - -
+-----+--+------+ ^ ^
| | | |
| | |S |I
+------------+ +--------+ |N |P
| | |M |F
| | |P |I
+------------------+ +------+-----------+ | |X
| EO | | EO | v |
| Parent 1 | ... | Parent N | - -
+------------------+ +------------------+
||| .
One or ||| .
Multiple ||| .
Energy ||| .
Object ||| .
Relationship(s): |||
- Aggregation ||| +-----------------------+
- Metering |||------| EO Child 1 |
- Power Source || +-----------------------+
- Proxy ||
|| +-----------------------+
||-------| EO Child 2 |
| +-----------------------+
|
|
|-------- ...
|
|
| +-----------------------+
|--------| EO Child M |
+-----------------------+
Figure 6: Complex Energy Management Model
While both the simple and complex Energy Management models
contain an EnMS, this framework doesn't impose any
requirements regarding a topology with a centralized EnMS
or one with distributed Energy Management via the Energy
Objects within the deployment.
Given the pattern in Figure 6, the complex relationships
between Energy Objects can be modeled (refer also to
section 5.3):
<Claise, et. Al> Expires Sep 12, 2012 [Page 28]
Internet-Draft <EMAN Framework> March 2012
- A PoE device modeled as an Energy Object Parent with
the Power Source, Metering, and Proxy Relationships
for one or more Energy Object Children
- A PDU modeled as an Energy Object Parent with the
Power Source and Metering Relationships for the
plugged in Electrical Equipment (the Energy Object
Children)
- Building management gateway, used as proxy for non
IP protocols, is modeled as an Energy Object Parent
with the Proxy Relationship, and potentially the
Aggregation Relationship to the managed Electrical
Equipment
- Etc.
The communication between the Energy Object Parent and Energy
Object Children is out of the scope of this framework.
5.1. Energy Object, Energy Object Components and Containment
Tree
The framework for Energy Management manages two different
types of Energy Objects: Energy Device and Energy Device
Components. A typical example of anEnergy Device is a
switch. However, a port within the switch, which provides
Power to one end point, is also an Energy Object if it
meters the power provided. A second example is PC, which
is a typical Energy Device, while the battery inside the PC
is a Energy Object Component, managed as an individual
Energy Object. Some more examples of Energy Device
Components: power supply within a router, an outlet within
a smart PDU, etc...
In the [EMAN-AWARE-MIB], each Energy Object is managed with
an unique value of the entPhysicalIndex index from the
ENTITY-MIB [RFC4133]
The ENTITY-MIB [RFC4133] specifies the notion of physical
containment tree, as:
"Each physical component may be modeled as 'contained'
within
another physical component. A "containment-tree" is the
conceptual sequence of entPhysicalIndex values that
uniquely specifies the exact physical location of a
physical component within the managed system. It is
generated by 'following and recording' each
'entPhysicalContainedIn' instance 'up the tree towards
<Claise, et. Al> Expires Sep 12, 2012 [Page 29]
Internet-Draft <EMAN Framework> March 2012
the root', until a value of zero indicating no further
containment is found."
A Energy Object Component in the Energy Management context
is a special Energy Object that is a physical component as
specified by the ENTITY-MIB physical containment tree.
6. Framework High Level Concepts and Scope
Energy Management can be organized into areas of concern
that include:
- Energy Object Identification and Context - for modeling
and planning
- Energy Monitoring - for energy measurements
- Energy Control - for optimization
- Energy Procurement - for optimization of resources
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:
- Manufacturing costs of an Energy Object in currency or
environmental units
- 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).
The next sections describe Energy Management organized into
the following areas:
- Energy Object and Energy Management Domain
- Energy Object Identification and Context
- Energy Object Relationships
- Energy Monitoring
- Energy Control
<Claise, et. Al> Expires Sep 12, 2012 [Page 30]
Internet-Draft <EMAN Framework> March 2012
- Deployment Topologies
6.1. Energy Object and Energy Management Domain
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 instead used to get
readings from sub portions of a building.
An Energy Management Domain should map 1:1 with a metered
or sub-metered portion of the site. An Energy Object is
part of a single Energy Management Domain. The Energy
Management Domain MAY be configured on an Energy Object:
the default value is a zero-length string.
If all Energy Objects in the physical containment tree (see
ENTITY-MIB) are part of the same Energy Management Domain,
then it is safe to state that the Energy Object at the root
of that containment tree is in that Energy Management
Domain.
An Energy Object Child may inherit the domain value from an
Energy Object Parent or the Energy Management Domain may be
configured directly in an Energy Object Child.
6.2. Power Interface
There are some similarities between Power Interfaces and
network interfaces. A network interface can be used in
different modes, such as sending or receiving on an
attached line. The Power Interface can be receiving or
providing power.
Most Power Interfaces never change their mode, but as the
mode is simply a recognition of the current direction of
electricity flow, there is no barrier to a mode change.
A power interface can have capabilities for metering power
and other electric quantities at the shared power
transmission medium.
<Claise, et. Al> Expires Sep 12, 2012 [Page 31]
Internet-Draft <EMAN Framework> March 2012
This capability is modeled by an association to a power
meter.
In analogy to MAC addresses of network interfaces, a
globally
unique identifier is assigned to each Power Interface.
Physically, a Power Interface can be located at an AC power
socket, an AC power cord attached to a device, an 8P8C
(RJ45) PoE socket, etc.
6.3. Energy Object Identification and Context
6.2.1 Energy Object Identification
Energy Objects MUST be associated with a value that
uniquely identifies the Energy Object among all the Energy
Management Domains within an EnMS. A Universal Unique
Identifier (UUID) [RFC4122] MUST be used to uniquely
identify an Energy Object.
Every Energy Object SHOULD have a unique printable name
within the Energy Management Domain. 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.
6.2.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, i.e. the Energy
Object Context.
6.2.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
<Claise, et. Al> Expires Sep 12, 2012 [Page 32]
Internet-Draft <EMAN Framework> March 2012
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 is
more important than a PC and a phone for lobby use.
Although EnMS and administrators can establish their own
ranking, the following is a broad recommendation:
. 90 to 100 Emergency response
. 80 to 90 Executive or business-critical
. 70 to 79 General or Average
. 60 to 69 Staff or support
. 40 to 59 Public or guest
. 1 to 39 Decorative or hospitality
6.2.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, the keywords are
separated by commas and no spaces between keywords are
allowed. For example, "HR,Bldg1,Private".
<Claise, et. Al> Expires Sep 12, 2012 [Page 33]
Internet-Draft <EMAN Framework> March 2012
6.2.5 Context: Role
An Energy Object can provide 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
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".
6.4. Energy Object Relationships
Two Energy Objects MAY establish an Energy Object
Relationship. Within a relationship one Energy Object
becomes an Energy Object Parent while the other becomes an
Energy Object Child.
The Power Source Relationship gives the view the wiring
topology. For example: a data center server receiving
<Claise, et. Al> Expires Sep 12, 2012 [Page 34]
Internet-Draft <EMAN Framework> March 2012
power from two specific Power Interfaces from two different
PDUs.
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 Proxy Relationship allows software objects to be
inserted into the wiring or metering topology to aid in
managing (monitoring and/or control) the Energy Domain.
From a EnMS management point of view, this implies that
there is yet another management topology that EnMS will
need to be aware of.
In the ideal situation, the wiring, the metering, and the
management topologies overlap. For Example: A Power-over-
Ethernet (PoE) device (such as an IP phone or an access
point) is attached to a switch port. The switch port is
the source of power for the attached device, so the Energy
Object Parent is the switch port, which acts as a Power
Interface, and the Energy Object Child is the device
attached to the switch. This Energy Object Parent (the
switch) has three Energy Object Relations with this Energy
Object Child (the remote Energy Object): Power Source
Relationship, Metering Relationship, and Proxy
Relationship.
However, the three topologies (wiring, metering, and
management) don't always overlap. For example, when a
protocol gateways device for Building Management Systems
(BMS) controls subtended devices, which themselves receive
Power from PDUs or wall sockets.
Note: The Aggregation Relationship is slightly different
compared to the other relationships (Power Source,
Metering, and Proxy Relationships) as this refers more to a
management function.
The communication between the parent and child for
monitoring or collection of power data is left to the
device manufacturer. For example: A parent switch may use
LLDP to communicate with a connected child, and a parent
<Claise, et. Al> Expires Sep 12, 2012 [Page 35]
Internet-Draft <EMAN Framework> March 2012
lighting controller may use BACNET to communicate with
child lighting devices.
The Energy Object Child MUST keep track of its Energy
Object Parent(s) along with the Energy Object Relationships
type(s). The Energy Object Parent MUST keep track of its
Energy Object Child(ren), along with the Energy Object
Relationships type(s).
6.4.1 Energy Object Children Discovery
There are multiple ways that the Energy Object Parent can
discover its Energy Object Children: :
. In case of PoE, the Energy Object Parent automatically
discovers an Energy Object Child when the Child
requests power.
. The Energy Object Parent and Children may run the Link
Layer Discovery Protocol [LLDP], or any other
discovery protocol, such as Cisco Discovery Protocol
(CDP). The Energy Object Parent might even support
the LLDP-MED MIB [LLDP-MED-MIB], which returns extra
information on the Energy Object Children.
. The Energy Object Parent may reside on a network
connected to a facilities gateway. A typical example
is a converged building gateway, monitoring several
other devices in the building, and serving as a proxy
between SNMP and a protocol such as BACNET.
. A different protocol between the Energy Object Parent
and the Energy Object Children. Note that the
communication specifications between the Energy Object
Parent and Children is out of the scope of this
document.
However, in some situations, it is not possible to discover
the Energy Object Relationships, and they must be set
manually. For example, in today' network, an administrator
must assign the connected Energy Object to a specific PDU
Power Interface, with no means of discovery other than that
manual connection.
When an Energy Object Parent is a Proxy, the Energy Object
Parent SHOULD enumerate the capabilities it is providing
for the Energy Object Child. The child would express that
it wants its parent to proxy capabilities such as, energy
<Claise, et. Al> Expires Sep 12, 2012 [Page 36]
Internet-Draft <EMAN Framework> March 2012
reporting, power state configurations, non physical wake
capabilities (such as WoL)), or any combination of
capabilities.
6.4.2 Energy Object Relationship Conventions and Guidelines
EDITOR'S NOTE: this section needs to be completed
This Energy Management framework doesn't impose too many
"MUST" rules related to the Energy Object Relationships.
Indeed, there are always corner cases that would be
excluded with too strict specifications. However, this
Energy Management framework proposes a series of
guidelines, indicated with "SHOULD" and "MAY":
- The Energy Device SHOULD NOT establish Power Source
Relationship with Energy Device Component
- Power Source Relationship SHOULD be established with next
known Power Interface in the wiring topology. It may
happen that the some Energy Objects in the wiring
topology are not known to the administrator. Therefore,
it may happen that a Power Source Relationship is
established between two non connected Power Interfaces.
- 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 "PoweredBby" the Energy
Object C.
6.5. Energy Monitoring
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
part of an Energy Management Domain (See Section 4.5. )
but MUST provide information converted to and expressed in
watt hours.
Each Energy Object will have information that describes
power information, along with how that measurement was
obtained or derived (actual measurement, estimated, or
presumed). For Energy Objects that can report actual power
readings, an optional energy measurement can be provided.
<Claise, et. Al> Expires Sep 12, 2012 [Page 37]
Internet-Draft <EMAN Framework> March 2012
Optionally, an Energy Object can further describe the Power
information with Power Quality information reflecting the
electrical characteristics of the measurement.
Optionally, an Energy Object that can report actual power
readings can have odometers that provide the energy used,
produced, and net energy in kWh. These values are
odometers that accumulate the power readings. If energy
values are returned then the three odometers must be
provided along with a description of accuracy.
Optionally, an Energy Object can provide demand information
over time.
6.5.1 Power Measurement
A power measurement MUST be qualified with the units,
magnitude, direction of power flow, and SHOULD be qualified
by what means the measurement was made (ex: Root Mean
Square versus Nameplate).
In addition, the Energy Object should describe how it
intends to measure power as one of consumer, producer or
meter of usage. Given the intent, readings can be
summarized or analyzed by an EnMS. For example metered
usage reported by a meter and consumption usage reported by
a device connected to that meter may naturally measure the
same usage. With the two measurements identified by intent
a proper summarization can be made by an EnMS.
Power measurement magnitude should conform 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.
Energy is often billed in kilowatt-hours instead of
megajoules from the SI units. Similarly, battery charge is
often measured as miliamperes-hour (mAh) instead of
coulombs from the SI units. The units used in this
framework are: W, A, Wh, Ah, V. A conversion from Wh to
<Claise, et. Al> Expires Sep 12, 2012 [Page 38]
Internet-Draft <EMAN Framework> March 2012
Joule and from Ah to Coulombs is obviously possible, and
can be described if required.
In addition to knowing the usage and magnitude, it is
useful to know how an Energy Object usage measurement was
obtained:
. Whether the measurements were made at the device itself
or from 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.
The EnMS can use the Nameplate Power for provisioning,
capacity planning and potentially billing.
6.5.2 Optional Power Quality
Given a power measurement, it may in certain circumstances
be desirable to know the Power Quality associated with that
measurement. The information model must adhere to the IEC
61850 7-2 standard for describing AC measurements. Note
that the Power Quality includes two sets of
characteristics: characteristics as received from the
utility, and characteristics depending on how the power is
used.
In some Energy Management Domains, the power quality may
not be needed, available, or relevant to the EnMS.
Optional Demand
It is well known in commercial electrical utility rates
that demand is part of the calculation for billing. The
highest peak demand measured over a time horizon, such as 1
month or 1 year, is often the basis for charges. A single
window of time of high usage can penalize the consumer with
higher energy consumption charges. However, it is relevant
to measure the demand only when there are actual power
measurements from an Energy Object, and not when the power
measurement is assumed or predicted.
<Claise, et. Al> Expires Sep 12, 2012 [Page 39]
Internet-Draft <EMAN Framework> March 2012
Optional Battery
Some Energy Objects may use batteries for storing energy
and for receiving power supply. These Energy Objects
should report their current power supply (battery, power
line, etc.) and the battery status for each contained
battery. Battery-specific information to be reported
should include the number of batteries contained in the
device and per battery the state information as defined in
[EMAN-REQ].
Beyond that a device containing a battery should be able to
generate alarms when the battery charge falls below a given
threshold and when the battery needs to be replaced.
6.6. Energy Control
Energy Objects can be controlled by setting it to a
specific Power State. Power States Set can be seen as an
interface by which an Energy Object can be controlled.
Each Energy Object should indicate the Power State Sets
that it implements. Well known Power State Sets should be
registered with IANA
When an individual Power State is configured from a
specific Power State Set, an Energy Object may be busy at
the request time. The Energy Object will set the desired
state and then update the actual Power State when the
priority task is finished. This mechanism implies two
different Power State variables: actual versus desired
There are several standards and implementations of Power
State Sets. An Energy Object can support one or multiple
Power State Set implementations concurrently.
This framework identifies three initial possible Power
State Series that can be supported by an Energy Object:
IEEE1621 - [IEEE1621]
DMTF - [DMTF]
EMAN - Specified here
<Claise, et. Al> Expires Sep 12, 2012 [Page 40]
Internet-Draft <EMAN Framework> March 2012
6.5.1 IEEE1621 Power State Series
The IEEE1621 Power State Series [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.
6.5.2 DMTF Power State Series
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 Series 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 Series and EMAN Power State Sets (described in
the next section):
State DMTF Power ACPI EMAN
Power
State State State
Name
Non-operational states:
1 Off-Hard G3, S5
MechOff(1)
<Claise, et. Al> Expires Sep 12, 2012 [Page 41]
Internet-Draft <EMAN Framework> March 2012
2 Off-Soft G2, S5
SoftOff(2)
3 Hibernate G1, S4
Hibernate(3)
4 Sleep-Deep G1, S3 Sleep(4)
5 Sleep-Light G1, S2
Standby(5)
6 Sleep-Light G1, S1 Ready(6)
Operational states:
7 On G0, S0, P5
LowMinus(7)
8 On G0, S0, P4 Low(8)
9 On G0, S0, P3
MediumMinus(9)
10 On G0, S0, P2
Medium(10)
11 On G0, S0, P1
HighMinus(11)
12 On G0, S0, P0 High(12)
Figure 7: DMTF / ACPI Power State Mapping
6.5.3 EMAN Power State Set
The EMAN Power State Set represents an attempt for a
standard approach to model 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.
There are twelve Power States, that expand on [IEEE1621]
on, sleep and off. The expanded list of Power States are
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 states 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
<Claise, et. Al> Expires Sep 12, 2012 [Page 42]
Internet-Draft <EMAN Framework> March 2012
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. This corresponds to ACPI state G3.
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. This corresponds
to ACPI state G2. 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. This corresponds to state G1, S4 in ACPI.
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. This corresponds to state
G1, S3 in ACPI.
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-standy. The
time for availability is longer than ready(6). For
example, the processor context is not maintained.
Typically, energy consumption is close to zero. This
corresponds to state G1, S2 in ACPI.
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. This
corresponds to state G1, S1 in ACPI. lowMinus(7) :
Indicates some Energy Object features may not be available
and the Energy Object has selected measures/options to
provide less than low(8) usage. This corresponds to ACPI
<Claise, et. Al> Expires Sep 12, 2012 [Page 43]
Internet-Draft <EMAN Framework> March 2012
State G0. This includes operational states lowMinus(7) to
full(12).
low(8) : Indicates some features may not be
available and the Energy Object has taken measures or
selected options to provideless 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).
high(12) : Indicates all Energy Object features
are available and the Energy Object is consuming the
highest power.
The Figure 8 displays the mappings from the IEEE1621 Power
State Series to the EMAN Power State Series, showing that
the EMAN twelve Power States expand on [IEEE1621] on, sleep
and off.
IEEE1621 EMAN Power State Name
Non-operational states:
Power(off) MechOff(1)
Power(off) SoftOff(2)
Power(sleep) Hibernate(3)
Power(sleep) Sleep(4)
Power(sleep) Standby(5)
Power(sleep) Ready(6)
Operational states:
Power(on) LowMinus(7)
Power(on) Low(8)
Power(on) MediumMinus(9)
Power(on) Medium(10)
Power(on) HighMinus(10)
Power(on) High(11)
<Claise, et. Al> Expires Sep 12, 2012 [Page 44]
Internet-Draft <EMAN Framework> March 2012
Figure 8: DMTF / ACPI Power State Mapping
6.7. Energy Objects Relationship Extensions
This framework for Energy Management, is based on four
Energy Objects Relationships: Aggregation Relationship,
Metering Relationship, Power Source Relationship, and Proxy
Relationship.
This framework is defined with possible extension of new
Energy Objects 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 a
future extension based on "gang relationship", whose
semantic would specify the Energy Objects grouping.
7. Structure of the Information Model: UML Representation
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 structure with different data models could be
used as well.
Notation is a 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
variables and global to the class. Algorithms for class
variable initialization, constructors or destructors are
not shown
EDITOR'S NOTE: the first part of the UML must be aligned
with the latest [EMAN-AWARE-MIB] document version. Also,
received the following comment referring to the arrows in
the following figure: "It is not clear to me what UML
relationships are being specified here in the ASCIIfied UML
relationships. Please provide a legend to make your
conventions for mapping to UML clear."
EO RELATIONSHIPS AND CONTEXT
<Claise, et. Al> Expires Sep 12, 2012 [Page 45]
Internet-Draft <EMAN Framework> March 2012
+--------------------------
--+
| _Child Specific Info __
|
|--------------------------
--|
+---------------------------+ | parentId : UUID
|
| Context Information | | parentProxyAbilities
|
|---------------------------| | : bitmap
|
| roleDescription : string | | mgmtMacAddress : octets
|
| keywords[0..n] : string | | mgmtAddress :
inetaddress |
| importance : int | | mgmtAddressType : enum
|
| category : enum | | mgmtDNSName :
inetaddress |
+---------------------------+ +--------------------------
--+
| |
| |
| |
v v
+-----------------------------------------+
| Energy Object Information |
|-----------------------------------------|
| index : int |
| energyObjectId | UUID |
| name : string |
| meterDomainName | string |
| alternateKey | string |
+-----------------------------------------+
^
|
|
|
+-------------------------+
| Links Object |
|-------------------------|
| physicalEntity : int |
| ethPortIndex : int |
| ethPortGrpIndex : int |
| lldpPortNumber : int |
<Claise, et. Al> Expires Sep 12, 2012 [Page 46]
Internet-Draft <EMAN Framework> March 2012
+-------------------------+
EO AND MEASUREMENTS
+-----------------------------------------------+
| Energy Object |
|-----------------------------------------------|
| nameplate : Measurement |
| battery[0..n]: Battery |
| measurements[0..n]: Measurement |
| --------------------------------------------- |
| Measurement instantaneousUsage() |
| DemandMeasurement historicalUsage() |
+-----------------------------------------------+
+-----------------------------------+
| Measurements |
| __________________________________|
+-----------------------------------+
^
|
|
+------------------+----------------------------+
| PowerMeasurement |
|-----------------------------------------------|
| value : long |
| rate : enum {0,millisecond,seconds, |
| minutes,hours,...} |
| multiplier : enum {-24..24} |
| units : "watts" |
| caliber : enum { actual, estimated, |
| trusted, assumed...} |
| accuracy : enum { 0..10000} |
| current : enum {AC, DC} |
| origin : enum { self, remote } |
| time : timestamp |
| quality : PowerQuality |
+-----------------------------------------------+
|
|
+------------------+----------------------------+
| EnergyMeasurement |
|-----------------------------------------------|
| consumed : long |
| generated : long |
<Claise, et. Al> Expires Sep 12, 2012 [Page 47]
Internet-Draft <EMAN Framework> March 2012
| net : long |
| accuracy : enum { 0..10000} |
+-----------------------------------------------+
+-----------------------------------------------+
| TimeMeasurement |
|-----------------------------------------------|
| startTime : timestamp |
| usage : Measurement |
| maxUsage : Measurement |
+-----------------------------------------------+
|
|
+----------------------------------------+
| TimeInterval |
|--------------------------------------- |
|value : long |
|units : enum { seconds, miliseconds..} |
+----------------------------------------+
|
|
+----------------------------------------+
| DemandMeasurement |
|----------------------------------------|
|intervalLength : TimeInterval |
|intervalNumbers: long |
|intervalMode : enum { period, sliding, |
|total } |
|intervalWindow : TimeInterval |
|sampleRate : TimeInterval |
|status : enum {active, inactive } |
|measurements : TimedMeasurement[] |
+----------------------------------------+
QUALITY
+----------------------------------------+
| PowerQuality |
|----------------------------------------|
| |
+----------------------------------------+
^
|
|
+------------------+--------------------+
<Claise, et. Al> Expires Sep 12, 2012 [Page 48]
Internet-Draft <EMAN Framework> March 2012
| ACQuality |
|---------------------------------------|
| acConfiguration : enum {SNGL, DEL,WYE}|
| avgVoltage : long |
| avgCurrent : long |
| frequency : long |
| unitMultiplier : int |
| accuracy : int |
| totalActivePower : long |
| totalReactivePower : long |
| totalApparentPower : long |
| totalPowerFactor : long |
+---------+-----------------------------+
| 1
|
|
|
| +------------------------------------+
| | ACPhase |
| * |------------------------------------|
+--------+ phaseIndex : long |
| avgCurrent : long |
| activePower : long |
| reactivePower : long |
| apparentPower : long |
| powerFactor : long |
+------------------------------------+
^ ^
| |
| |
| |
| |
+-------------------------------+---+ |
| DelPhase | |
|-----------------------------------| |
|phaseToNextPhaseVoltage : long | |
|thdVoltage : long | |
|thdCurrent : long | |
+-----------------------------------+ |
|
+------------------+-----------+
| WYEPhase |
|------------------------------|
|phaseToNeutralVoltage : long |
|thdCurrent : long |
|thdVoltage : long |
+------------------------------+
<Claise, et. Al> Expires Sep 12, 2012 [Page 49]
Internet-Draft <EMAN Framework> March 2012
EO & STATES
+----------------------------------------------+
| Energy Object |
|----------------------------------------------|
| currentLevel : int |
| configuredLevel : int |
| configuredTime : timestamp |
| reason: string |
| emanLevels[0..11] : State |
| levelMappings[0..n] : LevelMapping |
+----------------------------------------------+
+-------------------------------+
| State |
|-------------------------------|
| name : string |
| cardinality : int |
| maxUsage : Measurement |
+-------------------------------+
Figure 9: Information Model UML Representation
8. Configuration
This power management framework allows the configuration of
the following key parameters:
. Energy Object name: A unique printable name for the
Energy Object.
. Energy Object role: An administratively assigned name
to indicate the purpose an Energy Object serves in the
network.
. Energy Object importance: A ranking of how important
the Energy Object is, on a scale of 1 to 100, compared
with other Energy Objects in the same Energy
Management Domain.
<Claise, et. Al> Expires Sep 12, 2012 [Page 50]
Internet-Draft <EMAN Framework> March 2012
. Energy Object keywords: A list of keywords that can be
used to group Energy Objects for reporting or
searching.
. Energy Management Domain: Specifies the name of an
Energy Management Domain for the Energy Object.
. Energy Object Power State: Specifies the current Power
State for the Energy Object.
. Demand parameters: For example, which interval length
to report the Demand over, the number of intervals to
keep, etc.
. Assigning an Energy Object Parent to an Energy Object
Child
. Assigning an Energy Object Child to an Energy Object
Parent.
This framework supports multiple means for setting the
Power State of a specific Energy Objects. However, the
Energy Object might be busy executing an important task
that requires the current Power State for some more time.
For example, a PC might have to finish a backup first, or
an IP phone might be busy with a current phone call.
Therefore a second value contains the actual Power State.
A difference in values between the two objects indicates
that the Energy Object is currently in Power State
transition.
Other, already well established means for setting Power
States, such as DASH [DASH], already exist. Such a
protocol may be implemented between the Energy Object
Parent and the Energy Object Child, when the Energy Object
Parent acts as a Proxy. Note that the Wake-up-on-Lan (WoL)
mechanism allows to transition a device out of the Off
Power State.
9. Fault Management
[EMAN-REQ] specifies some requirements about Power States
such as "the current state - the time of the last change",
"the total time spent in each state", "the number of
transitions to each state", etc. Such requirements are
fulfilled via the pmPowerStateChange NOTIFICATION-TYPE
[EMAN-MON-MIB]. This SNMP notification is generated when
the value(s) of Power State has changed for the Energy
Object.
<Claise, et. Al> Expires Sep 12, 2012 [Page 51]
Internet-Draft <EMAN Framework> March 2012
Regarding high and low thresholding mechanism, the RMON
alarm and event [RFC2819] allows to periodically takes
statistical samples from Energy Object variables, compares
them to previously configured thresholds, and to generate
an event (i.e. an SNMP notification) if the monitored
variable crosses a threshold. The RMON alarm can monitor
variables that resolve to an ASN.1 primitive type of
INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge32,
or TimeTicks), so basically most the variables in [EMAN-
MON-MIB].
10. Examples
In this section we will give examples of how to use the
Energy Management framework. In each example we will show
how it can be applied when Energy Devices have the
capability to model Power Interfaces. We will also show in
each example how the framework can be applied when devices
cannot support Power Interfaces but only monitor
information or control the Energy Device as a whole. For
instance a PDU may only 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 Energy Devices with different capabilities
(typically hardware) for Energy Management.
Given for all Examples:
Energy Device W: A computer with one power supply. Power
interface 1 is an inlets for Device W.
Energy Device X: A computer with two power supplies. Power
interface 1 and power interface 2 are both inlets for
Device X.
Energy Device Y: A PDU with multiple Power Interfaces
numbered 0..10, Power interface 0 is an inlet and power
interface 1..10 are outlets.
Energy Device Z: A PDU with multiple Power Interfaces
numbered 0..10, Power interface 0 is an inlet and power
interface 1..10 are outlets.
<Claise, et. Al> Expires Sep 12, 2012 [Page 52]
Internet-Draft <EMAN Framework> March 2012
Example I: Simple Device with one Source
Topology:
Energy 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 Energy 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:
In this case Device W has an Energy Object representing
the computer. Device Y would have an Energy Object
representing the PDU.
The devices would have a Power Source Relationship such
that:
Device W is powered by Device Y.
Example II: Multiple Inlets
Topology:
Energy Device X inlet 1 is plugged into Device Y outlet
8.
Energy 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 Interface defined as
inlets.
Device Y would have an Energy Object representing the PDU
itself (the Energy Device) with a Power Interface 0
<Claise, et. Al> Expires Sep 12, 2012 [Page 53]
Internet-Draft <EMAN Framework> March 2012
defined as an inlet and Power Interface 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:
In this case Device X has an Energy Object representing
the computer. Device Y would have an Energy Object
representing the PDU.
The devices would have a Power Source Relationship such
that:
Device X is powered by Device Y.
Example III: Multiple Sources
Topology:
Energy Device X inlet 1 is plugged into Device Y outlet
8.
Energy 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.
Device Y would have an Energy Object representing the PDU
itself (the Energy Device) with a Power Interface 0
defined as an inlet and Power Interface 1..10 defined as
outlets.
Device Z would have an Energy Object representing the PDU
itself (the Energy Device) with a Power Interface 0
defined as an inlet and Power Interface 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
<Claise, et. Al> Expires Sep 12, 2012 [Page 54]
Internet-Draft <EMAN Framework> March 2012
Without Power Interfaces:
In this case 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.
11. Relationship with Other Standards Development
Organizations
11.1. Information Modeling
This power management framework should, as much as
possible, reuse existing standards efforts, especially with
respect to information modeling and data modeling
[RFC3444].
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 adheres
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
<Claise, et. Al> Expires Sep 12, 2012 [Page 55]
Internet-Draft <EMAN Framework> March 2012
state extensions.
12. 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.
12.1. Security Considerations for SNMP
Readable objects in a 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.
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 Power 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
<Claise, et. Al> Expires Sep 12, 2012 [Page 56]
Internet-Draft <EMAN Framework> March 2012
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.
13. IANA Considerations
Initial values for the Power State Sets, together with the
considerations for assigning them, are defined in [EMAN-
MON-MIB].
14. 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.
15. References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2819] S. Waldbusser, "Remote Network Monitoring
Management Information Base", STD 59, RFC 2819, May
2000
[RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability Statements
<Claise, et. Al> Expires Sep 12, 2012 [Page 57]
Internet-Draft <EMAN Framework> March 2012
for Internet Standard Management Framework ", RFC
3410, December 2002.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB
(Version3)", RFC 4133, August 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz," A
Universally Unique IDentifier (UUID) URN
Namespace", RFC 4122, July 2005
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.
[RFC5101] B. Claise, Ed., Specification of the IP Flow
Information Export (IPFIX) Protocol for the
Exchange of IP Traffic Flow Information, RFC 5101,
January 2008.
[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
<Claise, et. Al> Expires Sep 12, 2012 [Page 58]
Internet-Draft <EMAN Framework> March 2012
Management", draft-ietf-eman-requirements-05, (work
in progress), November 2011.
[EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
Networks and Devices MIB", draft-ietf-eman-energy-
aware-mib-04, (work in progress), February 2012.
[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-02, (work in progress), March 2012.
[EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
Definition of Managed Objects for Battery
Monitoring", draft-ietf-eman-battery-mib-05, (work
in progress), March 2012.
[EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
"Energy Management (EMAN) Applicability Statement",
draft-ietf-eman-applicability-statement-00, (work
in progress), October 2011
[EMAN-TERMINOLOGY] J. Parello, "Energy Management
Terminology", draft-parello-eman-definitions-05,
(work in progress), March 2012
[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?
punumber=4116785
[DASH] "Desktop and mobile Architecture for System
Hardware", http://www.dmtf.org/standards/mgmt/dash/
<Claise, et. Al> Expires Sep 12, 2012 [Page 59]
Internet-Draft <EMAN Framework> March 2012
[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?ope
nform
[SQL] ISO/IEC 9075(1-4,9-11,13,14):2008
[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/d
ocuments/DSP1027_2.0.0.pdf
[IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
Management", 2010, Wiley Publishing
[X.700] CCITT Recommendation X.700 (1992), Management
framework for Open Systems Interconnection (OSI)
for CCITT applications.
[CHEN] "The Entity-Relationship Model: Toward a Unified
View of Data", Peter Pin-shan Chen, ACM
Transactions on Database Systems, 1976
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
<Claise, et. Al> Expires Sep 12, 2012 [Page 60]
Internet-Draft <EMAN Framework> March 2012
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
Phone:
Email: brad@bradschoening.com
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Bruce Nordman
Lawrence Berkeley National Laboratory
1 Cyclotron Road
Berkeley 94720
US
Phone: +1 510 486 7089
Email: bnordman@lbl.gov
<Claise, et. Al> Expires Sep 12, 2012 [Page 61]
Internet-Draft <EMAN Framework> March 2012
<Claise, et. Al> Expires Sep 12, 2012 [Page 62]