Network Working Group J. Parello
Internet-Draft B. Claise
Intended Status: Informational Cisco Systems, Inc.
Expires: March 9, 2014 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd
September 9, 2013
Energy Management Framework
draft-ietf-eman-framework-09.txt
Status of this Memo
This Internet-Draft is submitted 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 March 9, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Claise et al Expires March 9, 2014 [Page 1]
Internet-Draft EMAN Framework September 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document defines a framework for providing Energy Management for
devices and device components within or connected to communication
networks. The framework defines both a physical reference model and
information model. The information model consists of an Energy
Management Domain as a set of Energy Objects. Each Energy Object is
identified, classified and given context. Energy Objects can be
monitored and controlled with respect to Power, Power State, Energy,
Demand, Power Attributes, and Battery. Additionally the framework
models relationships and capabilities between Energy Objects.
Table of Contents
1. Introduction...................................................3
1.1. Energy Management Documents Overview......................4
2. Terminology....................................................4
3. Concerns Specific to Energy Management........................10
3.1. Target Devices...........................................10
3.2. Physical Reference Model.................................10
3.3. Concerns Differing from Network Management...............12
3.4. Concerns Not Addressed...................................12
4. Energy Management Abstraction.................................13
4.1. Conceptual Model.........................................13
4.2. Energy Object............................................14
4.3. Energy Object Attributes.................................14
4.4. Measurements.............................................17
4.5. Control..................................................18
4.6. Relationships............................................23
5. Energy Management Information Model...........................26
6. Modeling Relationships between Devices........................30
6.1. Power Source Relationship................................30
6.2. Metering Relationship....................................33
6.3. Aggregation Relationship.................................35
7. Relationship to Other Standards...............................35
8. Security Considerations.......................................36
8.1. Security Considerations for SNMP.........................36
9. IANA Considerations...........................................37
9.1. IANA Registration of new Power State Sets................37
9.2. Updating the Registration of Existing Power State Sets...38
10. References...................................................38
11. Acknowledgments..............................................41
Claise et al. Expires March 9, 2014 [Page 2]
Internet-Draft EMAN Framework September 2013
1. Introduction
Network management is often divided into the five main areas defined
in the ISO Telecommunications Management Network model: Fault,
Configuration, Accounting, Performance, and Security Management
(FCAPS) [X.700]. Not covered by this traditional management model is
Energy Management, which is rapidly becoming a critical area of
concern worldwide, as seen in [ISO50001].
This document defines an energy management framework for devices
within or connected to communication networks. The devices, or
components of these devices (such as router line cards, fans, disks),
can then be monitored and controlled. Monitoring includes measuring
power, energy, demand, and attributes of power. Energy control can
be performed by setting devices' or components' power state. If a
device contains batteries, these can also be monitored and
controlled.
This framework further describes how to identify, classify and
provide context for such devices. While the context information is
not specific to Energy Management, some context attributes are
specified in the framework, addressing the following use cases: how
important is a device in terms of its business impact, how should
devices be grouped for reporting and searching, and how should a
device role be described. These context attributes help in fault
management and impact analysis while controlling the power states.
Guidelines for using context for energy management are described.
The framework introduces the concept of a power interface that is
analogous to a network interface. A power interface is defined as an
interconnection among devices where energy can be provided, received,
or both.
The most basic example of Energy Management is a single device
reporting information about itself. In many cases, however, energy
is not measured by the device itself, but measured upstream in the
power distribution tree. For example, a power distribution unit
(PDU) may measure the energy it supplies to attached devices and
report this to an energy management system. Therefore, devices often
have relationships to other devices or components in the power
network. An EnMS generally requires an understanding of the power
topology (who provides power to whom), the metering topology (who
meters whom), and an understanding of the potential aggregation (does
a meter aggregate values from other devices).
The relationships build on the power interface concept. The different
relationships among devices and components, specified in this
document, include: power source relationship, metering relationship,
and aggregation relationship.
Claise et al. Expires March 9, 2014 [Page 3]
Internet-Draft EMAN Framework September 2013
1.1. Energy Management Documents Overview
The EMAN standard provides a set of specifications for Energy
Management. This document specifies the framework, per the Energy
Management requirements specified in [EMAN-REQ].
The applicability statement document [EMAN-AS] includes use cases, a
cross-reference between existing standards and the EMAN standard, and
a description of this frameworks relationship to other frameworks.
The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies objects for
addressing Energy Object Identification, classification, context
information, and relationships from the point of view of Energy
Management.
The Power and Energy Monitoring MIB [EMAN-MON-MIB] specifies objects
for monitoring of Power, Energy, Demand, Power Attributes, and Power
States.
The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines managed objects
that provide information on the status of batteries in managed
devices.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this section some terms have a NOTE that is not part of the
definition itself, but accounts for differences between terminologies
of different standards organizations or further clarifies the
definition.
Claise et al. Expires March 9, 2014 [Page 4]
Internet-Draft EMAN Framework September 2013
$ Energy Management
Energy Management is a set of functions for measuring, modeling,
planning, and optimizing networks to ensure that the network and
network attached devices use energy efficiently and appropriately
for the nature of the application and the cost constraints of the
organization.
Reference: Adapted from [ITU-T-M-3400]
NOTES:
1. Energy management refers to the activities, methods, procedures
and tools that pertain to measuring, modeling, planning,
controlling and optimizing the use of energy in networked systems
[NMF].
2. Energy Management is a management domain which is congruent to
any of the FCAPS areas of management in the ISO/OSI Network
Management Model [TMN]. Energy Management for communication
networks and attached devices is a subset or part of an
organization's greater Energy Management Policies.
$ Energy Management System (EnMS)
An Energy Management System is a combination of hardware and
software used to administer a network with the primary purpose of
energy management.
Reference: Adapted from [1037C]
NOTES:
1. An Energy Management System according to [ISO50001] (ISO-EnMS)
is a set of systems or procedures upon which organizations can
develop and implement an energy policy, set targets, action plans
and take into account legal requirements related to energy use. An
ISO-EnMS allows organizations to improve energy performance and
demonstrate conformity to requirements, standards, and/or legal
requirements.
2. Example ISO-EnMS: Company A defines a set of policies and
procedures indicating there should exist multiple computerized
systems that will poll energy from their meters and pricing /
source data from their local utility. Company A specifies that
their CFO should collect information and summarize it quarterly to
be sent to an accounting firm to produce carbon accounting
reporting as required by their local government.
3. For the purposes of EMAN, the definition from [1037C] is the
preferred meaning of an Energy Management System (EnMS). The
Claise et al. Expires March 9, 2014 [Page 5]
Internet-Draft EMAN Framework September 2013
definition from [ISO50001] can be referred to as ISO Energy
Management System (ISO-EnMS).
$ 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.
$ Energy Control
Energy Control is a part of Energy Management that deals with
directing influence over Energy Objects.
$ 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]
$ Device
A piece of electrical or non-electrical equipment.
Reference: Adapted from [IEEE100]
$ Component
A part of an electrical or non-electrical equipment (Device).
Reference: Adapted from [ITU-T-M-3400]
$ Power Inlet
A Power Inlet (or simply inlet) is an interface at which a device
or component receives energy from another device or component.
$ Power Outlet
A Power Outlet (or simply outlet) is an interface at which a device
or component provides energy to another device or component.
$ Energy
That which does work or is capable of doing work. As used by
electric utilities, it is generally a reference to electrical
energy and is measured in kilowatt hours (kWh).
Reference: [IEEE100]
NOTES
Claise et al. Expires March 9, 2014 [Page 6]
Internet-Draft EMAN Framework September 2013
1. Energy is the capacity of a system to produce external activity
or perform work [ISO50001]
$ Provide Energy
A device (or component) "provides" energy to another device if
there is an energy flow from this device to the other one.
$ Receive Energy
A device (or component) "receives" energy from another device if
there is an energy flow from the other device to this one.
$ Meter (energy meter)
a device intended to measure electrical energy by integrating power
with respect to time.
Reference: Adapted from [IEC60050]
$ Battery
one or more cells (consisting of an assembly of electrodes,
electrolyte, container, terminals and usually separators) that are
a source and/or store of electric energy.
Reference: Adapted from [IEC60050]
$ Power
The time rate at which energy is emitted, transferred, or received;
usually expressed in watts (joules per second).
Reference: [IEEE100]
$ Nameplate Power
The Nameplate Power is the nominal Power of a device as specified
by the device manufacturer.
$ Power Attributes
Measurements of the electrical current, voltage, phase and
frequencies at a given point in an electrical power system.
Reference: Adapted from [IEC60050]
NOTES:
1. Power Attributes are not intended to be judgmental with respect
to a reference or technical value and are independent of any usage
context.
$ Power Quality
Characteristics of the electrical current, voltage, phase and
frequencies at a given point in an electric power system, evaluated
against a set of reference technical parameters. These parameters
might, in some cases, relate to the compatibility between
Claise et al. Expires March 9, 2014 [Page 7]
Internet-Draft EMAN Framework September 2013
electricity supplied in an electric power system and the loads
connected to that electric power system.
Reference: [IEC60050]
NOTES:
1. Electrical characteristics representing power quality
information are typically required by customer facility energy
management systems. It is not intended to satisfy the detailed
requirements of power quality monitoring. Standards typically also
give ranges of allowed values; the information attributes are the
raw measurements, not the "yes/no" determination by the various
standards.
Reference: [ASHRAE-201]
$ Demand
The average value of power or a related quantity over a specified
interval of time. Note: Demand is expressed in kilowatts, kilovolt-
amperes, kilovars, or other suitable units.
Reference: [IEEE100]
NOTES:
1. For EMAN we use kilowatts.
$ Power State
A Power State is a condition or mode of a device that broadly
characterizes its capabilities, power consumption, and
responsiveness to input.
Reference: Adapted from [IEEE1621]
$ Power State Set
A Power State Set is a collection of Power States that comprises a
named or logical control grouping.
$ Energy Object
An Energy Object (EO) is an information model (class) that
represents a piece of equipment that is part of, or attached to, a
communications network which is monitored, controlled, or aids in
the management of another device for Energy Management.
$ Power Interface
A Power Interface (or simply interface) is an information model
(class) that represents the interconnections among devices or
components where energy can be provided, received, or both.
$ Energy Management Domain
Claise et al. Expires March 9, 2014 [Page 8]
Internet-Draft EMAN Framework September 2013
An Energy Management Domain is a set of Energy Objects that is
considered one unit of management.
$ Energy Object Identification
Energy Object Identification is a set of attributes that enable an
Energy Object to be universally unique or linked to other systems.
$ Energy Object Context
Energy Object Context is a set of attributes that allow an Energy
Management System to classify an Energy Object within an
organization.
$ Energy Object Relationship
An Energy Object Relationship is an association among Energy
Objects.
NOTES
1. Relationships can be named and could include Aggregation,
Metering, and Power Source.
Reference: Adapted from [CHEN]
$ Power Source Relationship
A Power Source Relationship is an Energy Object Relationship where
one Energy Object provides power to one or more Energy Objects.
These Energy Objects are referred to as having a Power Source
Relationship.
$ Metering Relationship
A Metering Relationship is an Energy Object Relationship where one
Energy Object measures power, energy, demand or power attributes of
one or more other Energy Objects. The measuring Energy Object has a
Metering Relationship with each of the measured objects.
$ Aggregation Relationship
An Aggregation Relationship is an Energy Object Relationship where
one Energy Object aggregates Energy Management information of one
or more other Energy Objects. The aggregating Energy Object has an
Aggregation Relationship with each of the other Energy Objects.
Claise et al. Expires March 9, 2014 [Page 9]
Internet-Draft EMAN Framework September 2013
3. Concerns Specific to Energy Management
This section explains areas of concern for Energy Management that do
not exist in traditional Network Management. This section describes
target devices, outlines physical reference models, and lists the
major concerns specific to Energy Management.
3.1. Target Devices
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.
Energy Management has special challenges because a power distribution
network supplies energy to devices and components, while a separate
communications network monitors and controls the power distribution
network.
The target devices for Energy Management are all devices that can be
monitored or controlled (directly or indirectly) by an Energy
Management System (EnMS) using the Internet protocol. These target
devices include:
o Simple electrical appliances and fixtures
o Hosts, such as a PC, a server, or a printer
o Switches, routers, base stations, and other network
equipment and middle boxes
o Components within devices, such as a battery inside a PC, a
line card inside a switch, etc.
o Power over Ethernet (PoE) endpoints
o Power Distribution Units (PDU)
o Protocol gateway devices for Building Management Systems
(BMS)
o Electrical meters
o Sensor controllers with subtended sensors
The target devices may also include those communicating via non-IP
protocols deployed among the power distribution and IP communication
network.
3.2. Physical Reference Model
The following reference models describe physical power topologies
that exist in parallel to the communication topology. While many more
permutations of topologies can be created the following are some
basic ones that show how Energy Management topologies differ from
Network Management topologies.
Claise et al. Expires March 9, 2014 [Page 10]
Internet-Draft EMAN Framework September 2013
Basic Energy Management
+--------------------------+
| Energy Management System |
+--------------------------+
^ ^
monitoring | | control
v v
+---------+
| device |
+---------+
Basic Power Supply
+-----------------------------------------+
| energy management system |
+-----------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------------+ +-----------------+
| power supply |########| device |
+--------------+ +-----------------+
Single Power Supply with Multiple Devices
+---------------------------------------+
| energy management system |
+---------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------+ +------------------+
| power |########| device 1 |
| supply | # +------------------+-+
+--------+ #######| device 2 |
# +------------------+-+
#######| device 3 |
+------------------+
Multiple Power Supply with Single Devices
+----------------------------------------------+
| energy management system |
+----------------------------------------------+
^ ^ ^ ^ ^ ^
mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
v v v v v v
+----------+ +----------+ +----------+
| power |######| device |######| power |
| supply 1 |######| | | supply 2 |
+----------+ +----------+ +----------+
Claise et al. Expires March 9, 2014 [Page 11]
Internet-Draft EMAN Framework September 2013
3.3. Concerns Differing from Network Management
o Identification of the power source of a device may be
independent of the communication network and require unique
identifiers.
o Controlling power for a device may have to be fulfilled by
addressing the power source as opposed to directing control to
the device. For example controlling a device by controlling the
outlet of the PDU or controlling a simple light by controlling
its outlet.
o Control of a device may need to be coordinated if there are
multiple power supplies.
o Modeling of power when the flow of energy can be bi-directional
and require a separate interface model from Network Management.
For example energy received into a battery or energy provided
from battery).
o Some devices may need out-of-band or proxy capabilities to
respond to communications request even though it is in a non-
operational power state.
o Estimates and source of measurements may vary among devices.
For example when devices do not have the capability to measure
power an estimate can be provided from the device or estimated
by the EnMS. This may require annotation of a measurement.
o A device may require a separate abstract model to describe its
components and interconnections than a model used to describe
it for Network Management.
3.4. Concerns Not Addressed
Non-Electrical Equipment
The primary focus of this framework is the management of Electrical
Equipment. Some Non-Electrical Equipment may be connected to
communication networks and could have their energy managed if
normalized to the electrical units for power and energy. Non-
Electrical equipment that do not convert-to or present-as equivalent
to Electrical Equipment is not addressed.
Energy Procurement and Manufacturing
While an EnMS may be a central point for corporate reporting, cost,
environmental impact, and regulatory compliance, Energy Management in
Claise et al. Expires March 9, 2014 [Page 12]
Internet-Draft EMAN Framework September 2013
this framework excludes energy procurement and the environmental
impact of energy use.
As such the framework does not include:
o Cost in currency or environmental units of manufacturing a
device.
o Embedded carbon or environmental equivalences of a device
o Cost in currency or environmental impact to dismantle or
recycle a device.
o Supply chain analysis of energy sources for device deployment
o 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).
4. Energy Management Abstraction
Network management is often divided into the five main areas defined
in the ISO Telecommunications Management Network model: Fault,
Configuration, Accounting, Performance, and Security Management
(FCAPS) [X.700]. This traditional management model does not cover
Energy Management.
This section describes a conceptual model of information that can be
used for Energy Management. The classes and categories of attributes
in the model are described with rationale for each.
4.1. Conceptual Model
To address Energy Management this specification describes an
information model that can exist along with Network Management while
addressing issues specific to Energy Management.
An information model for Energy Management will need to describe a
means to report information, provide control, and model the
interconnections among physical entities (equipment).
Therefore, this section proposes a similar conceptual model for
physical entities to that used in Network Management: devices,
components, and interfaces. This section then defines the additional
attributes specific to Energy Management for those entities that are
not available in existing Network Management models.
For modeling the physical entities this section describes three
classes: a Device, a Component, and a Power Interface. These classes
are sub-types of an abstract Energy Object class.
For modeling additional attributes, this section describes attributes
of an Energy Object for: identification, classification, context,
control, power and energy.
Claise et al. Expires March 9, 2014 [Page 13]
Internet-Draft EMAN Framework September 2013
Since the interconnections between physical entities for Energy
Management may have no relation to the interconnections for Network
Management the Energy Object classes contain a separate Relationships
class as an attribute to model these types of interconnections.
The remainder of this section describes the conceptual model of the
classes and categories of attributes in the information model. The
formal definitions of the classes and attributes are specified in
Section 5.
4.2. Energy Object
An Energy Object is an abstract class that contains the base
attributes for Energy Management. There are three types of Energy
Objects: Device, Component and Power Interface.
4.2.1. Device Class
The Device Class is a sub-class of Energy Object that represents a
physical piece of equipment.
A Device Class instance may represent a device that is a consumer,
producer, or meter, distributor, or store of energy.
A Device Class instance may represent a physical device that contains
other components.
4.2.2. Component Class
The Component Class is a sub-class of Energy Object that represents a
part of a physical piece of equipment.
4.2.3. Power Interface Class
The power interface class is a sub-class of Energy Object that
represents the interconnection among devices and components.
There are some similarities between Power Interfaces and network
interfaces. A network interface can be set to different states, such
as sending or receiving data on an attached line. Similarly, a Power
Interface can be receiving or providing power.
Physically, a Power Interface instance can represent an AC power
socket, an AC power cord attached to a device, or an 8P8C (RJ45) PoE
socket, etc.
4.3. Energy Object Attributes
This section describes categories of attributes for an Energy Object.
4.3.1. Identification
A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely
and persistently identify an Energy Object. Ideally the UUID is used
to distinguish the Energy Object within the EnMS.
Claise et al. Expires March 9, 2014 [Page 14]
Internet-Draft EMAN Framework September 2013
Every Energy Object has an optional unique printable name. Possible
naming conventions are: textual DNS name, MAC address of the device,
interface ifName, or a text string uniquely identifying the Energy
Object. As an example, in the case of IP phones, the Energy Object
name can be the device's DNS name.
Additionally an alternate key is provided to allow an Energy Object
to be optionally linked with models in different systems.
4.3.2. Context in General
In order to aid in reporting and in differentiation between Energy
Objects, each object optionally contains information establishing its
business, site, or organizational context within a deployment.
Energy Objects contain a category attributed that broadly describes
how the object is used in a deployment. The category indicates if the
Energy Object is primarily functioning as a consumer, producer,
meter, distributor or store of energy.
Given the category and context of an object, an EnMS can summarize or
analyze measurements. For example, metered usage reported by a meter
and consumption usage reported by a device connected to that meter
may measure the same usage. With the two measurements identified by
category and context an EnMS can make summarizations and inferences.
4.3.3. Context: Importance
An Energy Object can provide an importance value in the range of 1 to
100 to help rank a device's use or relative value to the site. The
importance range is from 1 (least important) to 100 (most important).
The default importance value is 1.
For example: A typical office environment has several types of
phones, which can be rated according to their business impact. A
public desk phone has a lower importance (for example, 10) than a
business-critical emergency phone (for example, 100). As another
example: A company can consider that a PC and a phone for a customer-
service engineer are more important than a PC and a phone for lobby
use.
Although EnMS and administrators can establish their own ranking, the
following example is a broad recommendation for commercial
deployments [CISCO-EW]:
90 to 100 Emergency response
80 to 90 Executive or business-critical
70 to 79 General or Average
60 to 69 Staff or support
40 to 59 Public or guest
1 to 39 Decorative or hospitality
Claise et al. Expires March 9, 2014 [Page 15]
Internet-Draft EMAN Framework September 2013
4.3.4. Context: Keywords
An Energy Object can provide a set of keywords. These keywords are a
list of tags that can be used for grouping, summary reporting within
or between Energy Management Domains, and for searching. All
alphanumeric characters and symbols (other than a comma), such as #,
(, $, !, and &, are allowed. Potential examples are: IT, lobby,
HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone,
floor2, or SoftwareLab. There is no default value for a keyword.
Multiple keywords can be assigned to a device. White spaces before
and after the commas are excluded, as well as within a keyword
itself. In such cases, commas separate the keywords and no spaces
between keywords are allowed. For example, "HR,Bldg1,Private".
4.3.5. Context: Role
An Energy Object contains a "role description" string that indicates
the purpose the Energy Object serves in the EnMS. This could be a
string describing the context the device fulfills in deployment.
Administrators can define any naming scheme for the role of a device.
As guidance, a two-word role that combines the service the device
provides along with type can be used [IPENERGY].
Example types of devices: Router, Switch, Light, Phone, WorkStation,
Server, Display, Kiosk, HVAC.
Example Services by Line of Business:
Line of Business Service
Education Student, Faculty, Administration,
Athletic
Finance Trader, Teller, Fulfillment
Manufacturing Assembly, Control, Shipping
Retail Advertising, Cashier
Support Helpdesk, Management
Medical Patient, Administration, Billing
Role as a two-word string: "Faculty Desktop", "Teller Phone",
"Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
"Administration Switch".
4.3.6. Context: Domain
An Energy Object contains a string to indicate membership in an
Energy Management Domain. An Energy Management Domain can be any
collection of devices in a deployment, but it is recommended to map
1:1 with a metered or sub-metered portion of the site.
In building management, a meter refers to the meter provided by the
utility used for billing and measuring power to an entire building or
Claise et al. Expires March 9, 2014 [Page 16]
Internet-Draft EMAN Framework September 2013
unit within a building. A sub-meter refers to a customer- or user-
installed meter that is not used by the utility to bill but is
instead used to get measurements from sub portions of a building.
An Energy Object should be a member of a single Energy Management
Domain therefore one attribute is provided. The Energy Management
Domain may be configured on an Energy Object.
4.4. Measurements
An Energy Object contains attributes to describe power, energy and
demand measurements.
For the purposes of this framework, energy will be limited to
electrical energy in watt-hours. Other forms of Energy Objects that
use or produce non-electrical energy may be modeled as an Energy
Object but must provide information converted to and expressed in
watt-hours.
An analogy for understanding power versus energy measurements can be
made to speed and distance in automobiles. Just as a speedometer
indicates the rate of change of distance (speed), a power measurement
indicates the rate of transfer of energy. The odometer in an
automobile measures the cumulative distance traveled and similarly an
energy measurement indicates the accumulated energy transferred.
Demand measurements are averages of power measurements over time. So
using the same analogy to an automobile: measuring the average
vehicle speed over multiple intervals of time for a given distance
travelled, demand is the average power measured over multiple time
intervals for a given energy value.
4.4.1. Measurements: Power
Each Energy Object contains a Nameplate Power attribute that
describes the nominal power as specified by the manufacturer.
Power Measurement. The EnMS can use the Nameplate Power for
provisioning, capacity planning and (potentially) billing.
Each Energy Object will have information that describes the present
power information, along with how that measurement was obtained or
derived (e.g., actual, estimated, or static).
A power measurement is qualified with the units, magnitude and
direction of power flow, and is qualified as to the means by which
the measurement was made.
Power measurement magnitude conforms to the IEC 61850 definition of
unit multiplier for the SI (System International) units of measure.
Measured values are represented in SI units obtained by BaseValue *
(10 ^ Scale). For example, if current power usage of an Energy
Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the
Claise et al. Expires March 9, 2014 [Page 17]
Internet-Draft EMAN Framework September 2013
value of the scaling factor. 3W implies that the BaseValue is 3 and
Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor = -3.
An Energy Object indicates how the power measurement was obtained
with a caliber attribute that indicates:
o Whether the measurements were made at the device itself or at a
remote source.
o Description of the method that was used to measure the power
and whether this method can distinguish actual or estimated
values.
o Accuracy for actual measured values
4.4.2. Measurements: Power Attributes
Optionally, an Energy Object describes the Power measurements with
Power Attribute information reflecting the electrical characteristics
of the measurement. These Power Attributes adhere to the IEC 61850 7-
2 standard for describing AC measurements.
4.4.3. Measurements: Energy
Optionally, an Energy Object that can report actual power readings
will have energy attributes that provide the energy used, produced,
or stored in kWh.
4.4.4. Measurements: Demand
Optionally, an Energy Object will provide demand information over
time. Demand measurements can be provided when the Energy Object is
capable of measuring actual power.
4.5. Control
An Energy Object can be controlled by setting a Power State. An
Energy Object implements at least one set of Power States consisting
of at least two states, an on state and an off state.
Each Energy Object should indicate the sets of Power States that it
implements. Well-known Power States Sets are registered with IANA.
When a device is set to a particular Power State, it may be busy. The
device will set the desired Power State and then update the actual
Power State when it changes. There are then two Power State control
variables: actual and requested.
There are many existing standards for and implementations of Power
States. An Energy Object can support a mixed set of Power States
defined in different standards. A basic example is given by the three
Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The
DMTF [DMTF], ACPI [ACPI], and PWG define larger numbers of Power
States.
The semantics of a Power State are specified by
a) the functionality provided by an Energy Object in this state,
Claise et al. Expires March 9, 2014 [Page 18]
Internet-Draft EMAN Framework September 2013
b) a limitation of the power that an Energy Object uses in this
state,
c) a combination of a) and b)
The semantics of a Power State should be clearly defined. Limitation
(curtailment) of the power used by an Energy Object in a state is
specified by:
o an absolute power value
o a percentage value of power relative to the energy object's
nameplate power
o an indication of power relative to another power state. For
example: Specify that power in state A is less than in state B.
o For supporting Power State management an Energy Object provides
statistics on Power States including the time an Energy Object
spent in a certain Power State and the number of times an
Energy Object entered a power state.
When requesting an Energy Object to enter a Power State an indication
of the Power State's name or number can be used. Optionally an
absolute or percentage of Nameplate Power can be provided to allow
the Energy Object to transition to a nearest or equivalent Power
State.
4.5.1. Power State Sets
There are several standards and implementations of Power State Sets.
An Energy Object can support one or multiple Power State Set
implementation(s) concurrently.
There are currently three Power State Sets advocated:
IEEE1621(256) - [IEEE1621]
DMTF(512) - [DMTF]
EMAN(768) - [EMAN-MONITORING-MIB]
The respective specific states related to each Power State Set are
specified in the following sections. The guidelines for the
modification of Power State Sets are specified in the IANA
Considerations Section.
4.5.2. Power State Set: IEEE1621
The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary
states: on, off or sleep.
o on(0) - The device is fully On and all features of the
device are in working mode.
o off(1) - The device is mechanically switched off and does not
consume energy.
o sleep(2) - The device is in a power saving mode, and some
features may not be available immediately.
Claise et al. Expires March 9, 2014 [Page 19]
Internet-Draft EMAN Framework September 2013
4.5.3. Power State Set: DMTF
The 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)}
The DMTF standard is targeted for hosts and computers. Details of
the semantics of each Power State within the DMTF Power State Set can
be obtained from the DMTF Power State Management Profile
specification [DMTF].
The DMTF power profile extends ACPI power states. The following table
provides a mapping between DMTF and ACPI Power State Set:
DMTF ACPI
Reserved(0)
Reserved(1)
ON (2) G0-S0
Sleep-Light (3) G1-S1 G1-S2
Sleep-Deep (4) G1-S3
Power Cycle (Off-Soft) (5) G2-S5
Off-hard (6) G3
Hibernate (Off-Soft) (7) G1-S4
Off-Soft (8) G2-S5
Power Cycle (Off-Hard) (9) G3
Master Bus Reset (10) G2-S5
Diagnostic Interrupt (11) G2-S5
Off-Soft Graceful (12) G2-S5
Off-Hard Graceful (13) G3
MasterBus Reset Graceful (14) G2-S5
Power Cycle off-soft Graceful (15) G2-S5
Power Cycle off-hard Graceful (16) G3
4.5.4. Power State Set: IETF EMAN
An EMAN Power State Set represents an attempt at a standard approach
for modeling the different levels of power of a device. The EMAN
Power States are an expansion of the basic Power States as defined in
[IEEE1621] that also incorporates the Power States defined in [ACPI]
and [DMTF]. Therefore, in addition to the non-operational states as
defined in [ACPI] and [DMTF] standards, several intermediate
operational states have been defined.
An Energy Object may implement fewer or more Power States than a
particular EMAN Power State Set specifies. In this case, the Energy
Claise et al. Expires March 9, 2014 [Page 20]
Internet-Draft EMAN Framework September 2013
Object implementation can determine its own mapping to the predefined
EMAN Power States within the EMAN Power State Set.
There are twelve EMAN Power States that expand on [IEEE1621]. The
expanded list of Power States is derived from [CISCO-EW] and is
divided into six operational states and six non-operational states.
The lowest non-operational state is 1 and the highest is 6. Each
non-operational state corresponds to an [ACPI] Global and System
state between G3 (hard-off) and G1 (sleeping). Each operational
state represents a performance state, and may be mapped to [ACPI]
states P0 (maximum performance power) through P5 (minimum performance
and minimum power).
In each of the non-operational states (from mechoff(1) to ready(6)),
the Power State preceding it is expected to have a lower Power value
and a longer delay in returning to an operational state:
mechoff(1) : An off state where no Energy Object features
are available. The Energy Object is unavailable. No energy is being
consumed and the power connector can be removed.
softoff(2) : Similar to mechoff(1), but some components
remain powered or receive trace power so that the Energy Object can
be awakened from its off state. In softoff(2), no context is saved
and the device typically requires a complete boot when awakened.
hibernate(3): No Energy Object features are available. The
Energy Object may be awakened without requiring a complete boot, but
the time for availability is longer than sleep(4). An example for
state hibernate(3) is a save to-disk state where DRAM context is not
maintained. Typically, energy consumption is zero or close to zero.
sleep(4) : No Energy Object features are available,
except for out-of-band management, such as wake-up mechanisms. The
time for availability is longer than standby(5). An example for state
sleep(4) is a save-to-RAM state, where DRAM context is maintained.
Typically, energy consumption is close to zero.
standby(5) : No Energy Object features are available, except
for out-of-band management, such as wake-up mechanisms. This mode is
analogous to cold-standby. The time for availability is longer than
ready(6). For example processor context is may not be maintained.
Typically, energy consumption is close to zero.
ready(6) : No Energy Object features are available,
except for out-of-band management, such as wake-up mechanisms. This
mode is analogous to hot-standby. The Energy Object can be quickly
Claise et al. Expires March 9, 2014 [Page 21]
Internet-Draft EMAN Framework September 2013
transitioned into an operational state. For example, processors are
not executing, but processor context is maintained.
lowMinus(7) : Indicates some Energy Object features may not
be available and the Energy Object has taken measures or selected
options to provide less than low(8) usage.
low(8) : Indicates some features may not be available
and the Energy Object has taken measures or selected options to
provide less than mediumMinus(9) usage.
mediumMinus(9): Indicates all Energy Object features are
available but the Energy Object has taken measures or selected
options to provide less than medium(10) usage.
medium(10) : Indicates all Energy Object features are
available but the Energy Object has taken measures or selected
options to provide less than highMinus(11) usage.
highMinus(11): Indicates all Energy Object features are
available and power usage is less than high(12).
high(12) : Indicates all Energy Object features are
available and the Energy Object is consuming the highest power.
4.5.5. Power State Sets Comparison
A comparison of Power States from different Power State Sets can be
seen in the following table:
IEEE1621 DMTF ACPI EMAN
Non-operational states
off Off-Hard G3, S5 MechOff(1)
off Off-Soft G2, S5 SoftOff(2)
sleep Hibernate G1, S4 Hibernate(3)
sleep Sleep-Deep G1, S3 Sleep(4)
sleep Sleep-Light G1, S2 Standby(5)
sleep Sleep-Light G1, S1 Ready(6)
Operational states:
on on G0, S0, P5 LowMinus(7)
on on G0, S0, P4 Low(8)
on on G0, S0, P3 MediumMinus(9)
on on G0, S0, P2 Medium(10)
on on G0, S0, P1 HighMinus(11)
on on G0, S0, P0 High(12)
Claise et al. Expires March 9, 2014 [Page 22]
Internet-Draft EMAN Framework September 2013
4.6. Relationships
Two Energy Objects can establish an Energy Object Relationship to
model the deployment topology with respect to Energy Management.
Relationships are modeled with a Relationship class that contains the
UUID of the participants in the relationship and a description of the
type of relationship. The types of relationships are: power source.
metering, and aggregations.
o The Power Source Relationship gives a view of the physical
wiring topology. For example: a data center server receiving
power from two specific Power Interfaces from two different
PDUs.
Note: A power source relationship may or may not change as the
direction of power changes between two Energy Objects. The
relationship may remain to indicate the change of power
direction was unintended or an error condition.
o The Metering Relationship gives the view of the metering
topology. Physical 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.
o The Aggregation Relationship gives a model of devices that may
aggregate (sum, average, etc) values for other devices. The
Aggregation Relationship is slightly different compared to the
other relationships as this refers more to a management
function.
In some situations, it is not possible to discover the Energy Object
Relationships, and they must be set by an EnMS or administrator.
Given that relationships can be assigned manually, the following
sections describes guidelines for use.
4.6.1. Relationship Conventions and Guidelines
This Energy Management framework does not impose many "MUST" rules
related to Energy Object Relationships. There are always corner cases
that could be excluded with too strict specifications of
relationships. However, this Energy Management framework proposes a
series of guidelines, indicated with "SHOULD" and "MAY".
Claise et al. Expires March 9, 2014 [Page 23]
Internet-Draft EMAN Framework September 2013
4.6.2. Guidelines: Power Source
Power Source relationships are intended to identify the connections
between Power Interfaces. This is analogous to a Layer 2 connection
in networking devices (a "one-hop connection").
The preferred modeling would be for Power Interfaces to participate
in Power Source Relationships. It some cases Energy Objects may not
have the capability to model Power Interfaces. Therefore a Power
Source Relationship can be established between two Energy Objects or
two non-connected Power Interfaces.
While strictly speaking Components and Power Interfaces on the same
device do provide or receive energy from each other, the Power Source
relationship is intended to show energy transfer between Devices.
Therefore the relationship is implied when on the same Device.
An Energy Object SHOULD NOT establish a Power Source Relationship
with a Component.
o A Power Source Relationship SHOULD be established with the next
known Power Interface in the wiring topology.
o The next known Power Interface in the wiring topology would be
the next device implementing the framework. In some cases the
domain of devices under management may include some devices
that do not implement the framework. In these cases, the Power
Source relationship can be established with the next device in
the topology that implements the framework and logically shows
the Power Source of the device.
o Transitive Power Source relationships SHOULD NOT be
established. For example, if an Energy Object A has a Power
Source Relationship "Poweredby" with the Energy Object B, and
if the Energy Object B has a Power Source Relationship
"Poweredby" with the Energy Object C, then the Energy Object A
SHOULD NOT have a Power Source Relationship "Poweredby" with
the Energy Object C.
4.6.3. Guidelines: Metering Relationship
Metering Relationships are intended to show when one Device acting as
a Meter is measuring the power or energy at a point in a power
distribution system. Since one point of a power distribution system
may cover many Devices with a complex wiring topology, this
relationship type can be seen as an arbitrary set.
Devices may include measuring hardware for components and Power
Interfaces or for the entire Device. For example, some PDUs may have
the ability to measure Power for each Power Interface (metered by
outlet). Others may be able to control power at each Power Interface
Claise et al. Expires March 9, 2014 [Page 24]
Internet-Draft EMAN Framework September 2013
but can only measure Power at the Power Inlet and a total for all
Power Interfaces (metered by device).
In such cases the Device SHOULD be modeled as an Energy Object that
meters all of its Power Outlets and each Power Outlet MAY be metered
by the Energy Object representing the Device.
In general:
o A Metering Relationship MAY be established with any other
Energy Object, Component, or Power Interface.
o Transitive Metering relationships MAY be used.
o When there is a series of meters for one Energy Object, the
Energy Object MAY establish a Metering relationship with one or
more of the meters.
4.6.4. Guidelines: Aggregation
Aggregation relationships are intended to identify when one device is
used to accumulate values from other devices. Typically this is for
energy or power values among devices and not for Components or Power
Interfaces on the same device.
The intent of Aggregation relationships is to indicate when one
device is providing aggregate values for a set of other devices when
it is not obvious from the power source or simple containment within
a device.
Establishing aggregation relationships within the same device would
make modeling more complex and the aggregated values can be implied
from the use of Power Inlets, outlet and Energy Object values on the
same device.
Since an EnMS is naturally a point of aggregation it is not necessary
to model aggregation for Energy Management Systems.
Aggregation SHOULD be used for power and energy. It MAY be used for
aggregation of other values from the information model, but the rules
and logical ability to aggregate each attribute is out of scope for
this document.
In general:
o A Device SHOULD NOT establish an Aggregation Relationship with
Components contained on the same device.
o A Device SHOULD NOT establish an Aggregation Relationship with
the Power Interfaces contained on the same device.
o A Device SHOULD NOT establish an Aggregation Relationship with
an EnMS.
Claise et al. Expires March 9, 2014 [Page 25]
Internet-Draft EMAN Framework September 2013
o Aggregators SHOULD log or provide notification in the case of
errors or missing values while performing aggregation.
4.6.5. Energy Object Relationship Extensions
This framework for Energy Management is based on three relationship
types: Aggregation , Metering, and Power Source.
This framework is defined with possible future extension of new
Energy Object Relationships in mind.
For example:
o Some Devices that may not be IP connected. This can be modeled
with a proxy relationship to an Energy Object within the
domain. This type of proxy relationship is left for further
development.
o A Power Distribution Unit (PDU) that allows physical entities
like outlets to be "ganged" together as a logical entity for
simplified management purposes, could be modeled with an
extension called a "gang relationship", whose semantics would
specify the Energy Objects' grouping.
5. Energy Management Information Model
This section presents an information model expression of the concepts
in this framework as a reference for implementers. The information
model is implemented as a MIB in the different related IETF EMAN
documents. However, other programming structures with different data
models could be used as well.
Data modeling specifications of this information model may where
needed specify which attributes are required or optional.
EDITORs NOTE: The working group is converging on the use of
code/pseudo-code rather than ascii UML diagram. If agreeable we can
either indicate a BNF syntax in a formal syntax section or use the
following table if obvious:
Syntax
UML Construct
[ISO-IEC-19501-2005] Equivalent Notation
-------------------- --------------------------------------------
Notes // Notes
Class
(Generalization) CLASS name {member..}
Sub-Class
(Specialization) CLASS subclass EXTENDS superclass {member..}
Class Member
(Attribute) attribute : type
Claise et al. Expires March 9, 2014 [Page 26]
Internet-Draft EMAN Framework September 2013
Model
CLASS EnergyObject {
// identification / classification
index : int
identifier : uuid
alternatekey : string
// context
domainName : string
role : string
keywords [0..n] : string
importance : int
// relationship
relationships [0..n] : Relationship
// measurements
nameplate : Nameplate
power : PowerMeasurement
energy : EnergyMeasurment
demand : DemandMeasurement
// control
powerControl [0..n] : PowerStateSet
}
CLASS Device EXTENDS EnergyObject {
eocategory : enum { producer, consumer, meter, distributor,
store }
}
CLASS Component EXTENDS EnergyObject
eocategory : enum { producer, consumer, meter, distributor,
store }
}
CLASS Interface EXTENDS EnergyObject{
eoIfType : enum ( inlet, outlet, both}
}
CLASS Nameplate {
nominalPower : PowerMeasurement
details : URI
}
Claise et al. Expires March 9, 2014 [Page 27]
Internet-Draft EMAN Framework September 2013
CLASS Relationship {
relationshipType : enum { meters, meteredby, powers,
poweredby, aggregates, aggregatedby }
relationshipObject : uuid
}
CLASS Measurement {
multiplier: enum { -24..24}
caliber : enum { actual, estimated, static }
accuracy : enum { 0..10000} // hundreds of percent
}
CLASS PowerMeasurement EXTENDS Measurement {
value : long
units : "W"
powerAttribute : PowerAttribute
}
CLASS EnergyMeasurement EXTENDS Measurement {
startTime : time
units : "kWh"
provided : long
used : long
produced : long
stored : long
}
CLASS TimedMeasurement EXTENDS Measurement {
startTime : timestamp
value : Measurement
maximum : Measurement
}
CLASS TimeInterval {
value : long
units : enum { seconds, miliseconds,...}
}
CLASS DemandMeasurement EXTENDS Measurement {
intervalLength : TimeInterval
interval : long
intervalMode : enum { periodic, sliding, total }
intervalWindow : TimeInterval
sampleRate : TimeInterval
status : enum { active, inactive }
measurements[0..n] : TimedMeasurements
}
Claise et al. Expires March 9, 2014 [Page 28]
Internet-Draft EMAN Framework September 2013
CLASS PowerStateSet {
powerSetIdentifier : int
name : string
powerStates [0..n] : PowerState
operState : int
adminState : int
reason : string
configuredTime : timestamp
}
CLASS PowerState {
powerStateIdentifier : int
name : string
cardinality : int
maximumPower : PowerMeasurement
totalTimeInState : time
entryCount : long
}
CLASS PowerAttribute {
// container for attributes
acQuality : ACQuality
}
CLASS ACQuality {
acConfiguration : enum {SNGL, DEL,WYE}
avgVoltage : long
avgCurrent : long
frequency : long
unitMultiplier : int
accuracy : int
totalActivePower : long
totalReactivePower : long
totalApparentPower : long
totalPowerFactor : long
phases [0..2] : ACPhase
}
CLASS ACPhase {
phaseIndex : long
avgCurrent : long
activePower : long
reactivePower : long
apparentPower : long
powerFactor : long
}
Claise et al. Expires March 9, 2014 [Page 29]
Internet-Draft EMAN Framework September 2013
CLASS DelPhase EXTENDS ACPhase {
phaseToNextPhaseVoltage : long
thdVoltage : long
thdCurrent : long
}
CLASS WYEPhase EXTENDS ACPhase {
phaseToNeutralVoltage : long
thdCurrent : long
thdVoltage : long
}
6. Modeling Relationships between Devices
In this section we give examples of how to use the Energy Management
framework relationships to model physical topologies. Where
applicable, we show how the framework can be applied when Devices
have the capability to model Power Interfaces. We also show how the
framework can be applied when devices cannot support Power Interfaces
but only monitor information or control the Device as a whole. For
instance, a PDU may only be able to measure power and energy for the
entire unit without the ability to distinguish among the inlets or
outlet.
6.1. Power Source Relationship
The Power Source relationship is used to model the interconnections
between Devices, Components and/Power Interfaces to indicate the
source of energy for an Energy Object. Given the following examples
Devices we can show various types of configurations that would model
the reference or other topologies.
Given for all cases:
Device W: A computer with one power supply. Power interface 1 is an
inlet for Device W.
Device X: A computer with two power supplies. Power interface 1 and
power interface 2 are both inlets for Device X.
Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power
interface 0 is an inlet and power interface 1..10 are outlets.
Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power
interface 0 is an inlet and power interface 1..10 are outlets.
Claise et al. Expires March 9, 2014 [Page 30]
Internet-Draft EMAN Framework September 2013
Case 1: Simple Device with one Source
Physical Topology:
o Device W inlet 1 is plugged into Device Y outlet 8.
With Power Interfaces:
o Device W has an Energy Object representing the computer itself
as well as one Power Interface defined as an inlet.
o Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
The interfaces of the devices would have a Power Source Relationship
such that:
Device W inlet 1 is powered by Device Y outlet 8.
+-------+------+ poweredBy +------+----------+
| PDU Y | PI 8 |-----------------| PI 1 | Device W |
+-------+------+ powers +------+----------+
Without Power Interfaces:
o Device W has an Energy Object representing the computer.
o 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.
+----------+ poweredBy +------------+
| PDU Y |-----------------| Device W |
+----------+ powers +------------+
Case 2: Multiple Inlets
Physical Topology:
o Device X inlet 1 is plugged into Device Y outlet 8.
o Device X inlet 2 is plugged into Device Y outlet 9.
With Power Interfaces:
o Device X has an Energy Object representing the computer itself.
It contains two Power Interfaces defined as inlets.
Claise et al. Expires March 9, 2014 [Page 31]
Internet-Draft EMAN Framework September 2013
o Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
The interfaces of the devices would have a Power Source Relationship
such that:
Device X inlet 1 is powered by Device Y outlet 8.
Device X inlet 2 is powered by Device Y outlet 9.
+-------+------+ poweredBy+------+----------+
| | PI 8 |-----------------| PI 1 | |
| | |powers | | |
| PDU Y +------+ poweredBy+------+ Device X |
| | PI 9 |-----------------| PI 2 | |
| | |powers | | |
+-------+------+ +------+----------+
Without Power Interfaces:
o Device X has an Energy Object representing the computer. Device
Y has an Energy Object representing the PDU.
The devices would have a Power Source Relationship such that:
Device X is powered by Device Y.
+----------+ poweredBy +------------+
| PDU Y |-----------------| Device X |
+----------+ powers +------------+
Case 3: Multiple Sources
Physical Topology:
o Device X inlet 1 is plugged into Device Y outlet 8.
o Device X inlet 2 is plugged into Device Z outlet 9.
With Power Interfaces:
o Device X has an Energy Object representing the computer itself.
It contains two Power Interface defined as inlets.
o Device Y would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
o Device Z would have an Energy Object representing the PDU
itself (the Device), with a Power Interface 0 defined as an
inlet and Power Interfaces 1..10 defined as outlets.
Claise et al. Expires March 9, 2014 [Page 32]
Internet-Draft EMAN Framework September 2013
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.
+-------+------+ poweredBy+------+----------+
| PDU Y | PI 8 |-----------------| PI 1 | |
| | |powers | | |
+-------+------+ +------+ |
| Device X |
+-------+------+ poweredBy+------+ |
| PDU Z | PI 9 |-----------------| PI 2 | |
| | |powers | | |
+-------+------+ +------+----------+
Without Power Interfaces:
o 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.
+----------+ poweredBy +------------+
| PDU Y |---------------------| Device X |
+----------+ powers +------------+
+----------+ poweredBy +------------+
| PDU Z |---------------------| Device X |
+----------+ powers +------------+
6.2. Metering Relationship
Case 1: Metering between two Devices
The metering topology between two devices is closely related to the
power source topology. It is based on the assumption that in many
cases the power provided and the power received is the same for both
peers of a power source relationship.
We define in this case a Metering Relationship between two Devices or
Power Interfaces of Devices that have a power source relationship.
Power and energy values measured at one peer of the power source
relationship are reported for the other peer as well.
Claise et al. Expires March 9, 2014 [Page 33]
Internet-Draft EMAN Framework September 2013
The Metering Relationship is independent of the direction of the
Power Source Relationship. The most common case is that values
measured at the power provider are reported for the power receiver.
+-----+---+ meteredBy +--------+ poweredBy +-------+
|Meter| PI|--------------| switch |-------------| phone |
+-----+---+ meters +--------+ powers +-------+
| |
| meteredBy |
+-------------------------------------------+
meters
Case 2: Metering among many Devices
A Sub-meter in a power distribution system can logically measure the
power or energy for all devices downstream from the meter in the
power distribution system. As such, a Power metering relationship
can be seen as a relationship between a meter DEvice and all of the
devices downstream from the meter.
We define in this case a Power Source relationship between a metering
device and devices downstream from the meter.
In cases where the Power Source topology cannot be discovered or
derived from the information available in the Energy Management
Domain, the Metering Topology can be used to relate the upstream
meter to the downstream devices in the absence of specific power
source relationships.
A Metering Relationship can occur between devices that are not
directly connected, as shown in the following figure:
+---------------+
| Device 1 |
+---------------+
| PI |
+---------------+
|
+---------------+
| Meter |
+---------------+
.
.
.
meters meters meters
+----------+ +----------+ +-----------+
| Device A | | Device B | | Device C |
+----------+ +----------+ +-----------+
Claise et al. Expires March 9, 2014 [Page 34]
Internet-Draft EMAN Framework September 2013
An analogy to communications networks would be modeling connections
between servers (meters) and clients (devices) when the complete
Layer 2 topology between the servers and clients is not known.
6.3. Aggregation Relationship
Some devices can act as aggregation points for other devices. For
example, a PDU controller device may contain the summation of power
and energy readings for many PDU devices. The PDU controller will
have aggregate values for power and energy for a group of PDU
devices.
This aggregation is independent of the physical power or
communication topology.
An Aggregation Relationship is an Energy Object Relationship where
one Energy Object (called the Aggregate Energy Object) aggregates the
Energy Management information of one or more other Energy Objects.
These Energy Objects are said to have an Aggregation Relationship.
The functions that the aggregation point may perform include the
calculation of values such as average, count, maximum, median,
minimum, or the listing (collection) of the aggregation values, etc.
Based on the experience gained on aggregations at the IETF [draft-
ietf-ipfix-a9n-08], the aggregation function in the EMAN framework is
limited to the summation.
When aggregation occurs across a set of entities, values to be
aggregated may be missing for some entities. The EMAN framework does
not specify how these should be treated, as different implementations
may have good reason to take different approaches. One common
treatment is to define the aggregation as missing if any of the
constituent elements are missing (useful to be most precise). Another
is to treat the missing value as zero (useful to have continuous data
streams).
The specifications of aggregation functions are out of scope of the
EMAN framework, but must be clearly specified by the equipment
vendor.
7. Relationship to Other Standards
This Energy Management framework uses, as much as possible, existing
standards 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:
Claise et al. Expires March 9, 2014 [Page 35]
Internet-Draft EMAN Framework September 2013
o 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.
o 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:
o IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3.
o ANSI C12.20 class 0.2, 0.5
o The electrical characteristics and quality adhere closely to
the IEC 61850 7-2 standard for describing AC measurements.
o The power state definitions are based on the DMTF Power State
Profile and ACPI models, with operational state extensions.
8. Security Considerations
Regarding the data attributes specified here, some or all may be
considered sensitive or vulnerable in some network environments.
Reading or writing these attributes without proper protection such as
encryption or access authorization may have negative effects on the
network capabilities.
8.1. Security Considerations for SNMP
Readable objects in MIB modules (i.e., objects with a MAX-ACCESS
other than not-accessible) may be considered sensitive or vulnerable
in some network environments. It is 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:
o Unauthorized changes to the Energy Management Domain or
business context of a device may result in misreporting or
interruption of power.
o Unauthorized changes to a power state may disrupt the power
settings of the different devices, and therefore the state of
functionality of the respective devices.
o 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.
Claise et al. Expires March 9, 2014 [Page 36]
Internet-Draft EMAN Framework September 2013
It is recommended that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is not
recommended. Instead, it is recommended to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of these MIB modules is properly configured to give access
to the objects only to those principals (users) that have legitimate
rights to GET or SET (change/create/delete) them.
9. IANA Considerations
9.1. IANA Registration of new Power State Sets
This document specifies an initial set of Power State Sets. The list
of these Power State Sets with their numeric identifiers is given is
Section 4. IANA maintains the lists of Power State Sets.
New assignments for Power State Set are administered by IANA through
Expert Review [RFC5226], i.e., review by one of a group of experts
designated by an IETF Area Director. The group of experts MUST check
the requested state for completeness and accuracy of the
description. A pure vendor specific implementation of Power State
Set shall not be adopted; since it would lead to proliferation of
Power State Sets.
Power states in a Power State Set are limited to 255 distinct
values. New Power State Set must be assigned the next available
numeric identifier that is a multiple of 256.
9.1.1. IANA Registration of the IEEE1621 Power State Set
This document specifies a set of values for the IEEE1621 Power State
Set [IEEE1621]. The list of these values with their identifiers is
given in Section 4.6.2. IANA created a new registry for IEEE1621
Power State Set identifiers and filled it with the initial list of
identifiers.
New assignments (or potentially deprecation) for the IEEE1621 Power
State Set is administered by IANA through Expert Review [RFC5226],
i.e., review by one of a group of experts designated by an IETF Area
Director. The group of experts must check the requested state for
completeness and accuracy of the description.
9.1.2. IANA Registration of the DMTF Power State Set
This document specifies a set of values for the DMTF Power State
Set. The list of these values with their identifiers is given in
Section 4. IANA has created a new registry for DMTF Power State Set
identifiers and filled it with the initial list of identifiers.
Claise et al. Expires March 9, 2014 [Page 37]
Internet-Draft EMAN Framework September 2013
New assignments (or potentially deprecation) for the DMTF Power
State Set is administered by IANA through Expert Review [RFC5226],
i.e., review by one of a group of experts designated by an IETF Area
Director. The group of experts must check the conformance with the
DMTF standard [DMTF], on the top of checking for completeness and
accuracy of the description.
9.1.3. IANA Registration of the EMAN Power State Set
This document specifies a set of values for the EMAN Power State
Set. The list of these values with their identifiers is given in
Section 4.6.4. IANA has created a new registry for EMAN Power State
Set identifiers and filled it with the initial list of identifiers.
New assignments (or potentially deprecation) for the EMAN Power
State Set is administered by IANA through Expert Review [RFC5226],
i.e., review by one of a group of experts designated by an IETF Area
Director. The group of experts must check the requested state for
completeness and accuracy of the description.
9.1.4. Batteries Power State Set
Batteries have operational and administrational states that could be
represented as a power state set. Since the work for battery
management is parallel to this document, we are not proposing any
Power State Sets for batteries at this time.
9.2. Updating the Registration of Existing Power State Sets
With the evolution of standards, over time, it may be important to
deprecate some of the existing the Power State Sets, or to add or
deprecate some Power States within a Power State Set.
The registrant shall publish an Internet-draft or an individual
submission with the clear specification on deprecation of Power
State Sets or Power States registered with IANA. The deprecation or
addition shall be administered by IANA through Expert Review
[RFC5226], i.e., review by one of a group of experts designated by
an IETF Area Director. The process should also allow for a mechanism
for cases where others have significant objections to claims on
deprecation of a registration.
10. References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework ", RFC 3410, December 2002
Claise et al. Expires March 9, 2014 [Page 38]
Internet-Draft EMAN Framework September 2013
[RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique
Identifier (UUID) URN Namespace", RFC 4122, July 2005
[RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008
[RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB (Version4)",
RFC 6933, May 2013
[RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between
Information Models and Data Models", RFC 3444, January 2003
[ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information technology, Open
Distributed Processing -- Unified Modeling Language (UML),
January 2005
Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2", RFC
2578, April 1999
[RFC5101bis] Claise, B., Ed., and Trammel, T., Ed., "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of IP Traffic Flow Information ", draft-ietf-
ipfix-protocol-rfc5101bis-08, (work in progress), June 2013
[RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010
[ACPI] "Advanced Configuration and Power Interface Specification",
http://www.acpi.info/spec30b.htm
[IEEE1621] "Standard for User Interface Elements in Power Control of
Electronic Devices Employed in Office/Consumer
Environments", IEEE 1621, December 2004
[LLDP] IEEE Std 802.1AB, "Station and Media Control Connectivity
Discovery", 2005
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base
extension module for TIA-TR41.4 media endpoint discovery
information", July 2005
Claise et al. Expires March 9, 2014 [Page 39]
Internet-Draft EMAN Framework September 2013
[EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.
Chandramouli, "Requirements for Energy Management", draft-
ietf-eman-requirements-14, (work in progress), May 2013
[EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy Object Contet
MIB", draft-ietf-eman-energy-aware-mib-08, (work in
progress), April 2013
[EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., Dietz,
T., and B. Claise, "Power and Energy Monitoring MIB",
draft-ietf-eman-energy-monitoring-mib-05, (work in
progress), April 2013
[EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
Definition of Managed Objects for Battery Monitoring",
draft-ietf-eman-battery-mib-08, (work in progress),
February 2013
[EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, "Energy
Management (EMAN) Applicability Statement", draft-ietf-
eman-applicability-statement-03, (work in progress), April
2013
[ITU-T-M-3400] TMN recommandation on Management Functions (M.3400),
1997
[NMF] "Network Management Fundamentals", Alexander Clemm, ISBN: 1-
58720-137-2, 2007
[TMN] "TMN Management Functions : Performance Management", ITU-T
M.3400
[1037C] US Department of Commerce, Federal Standard 1037C,
http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm
[IEEE100] "The Authoritative Dictionary of IEEE Standards Terms"
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber
=4116785
[ISO50001] "ISO 50001:2011 Energy management systems - Requirements
with guidance for use", http://www.iso.org/
[IEC60050] International Electrotechnical Vocabulary
http://www.electropedia.org/iev/iev.nsf/welcome?openform
Claise et al. Expires March 9, 2014 [Page 40]
Internet-Draft EMAN Framework September 2013
[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/documents
/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
[ASHRAE-201] "ASHRAE Standard Project Committee 201
(SPC 201)Facility Smart Grid Information
Model", http://spc201.ashraepcs.org
[CHEN] "The Entity-Relationship Model: Toward a Unified View of
Data", Peter Pin-shan Chen, ACM Transactions on Database
Systems, 1976
[CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, Roland
Saville, Steve Kramling, Cisco Validated Designs, September
2010,
http://www.cisco.com/en/US/docs/solutions/Enterprise/Border
less_Networks/Energy_Management/energywisedg.html
11. Acknowledgments
The authors would like to Michael Brown for his editorial work
improving the text dramatically. Thanks to Rolf Winter for his
feedback and to Bill Mielke for feedback and very detailed review.
Thanks to Bruce Nordman for brainstorming with numerous conference
calls and discussions. Finally, the authors would like to thank the
EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.
This document was prepared using 2-Word-v2.0.template.dot.
Claise et al. Expires March 9, 2014 [Page 41]
Internet-Draft EMAN Framework September 2013
Authors' Addresses
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
Phone:
Email: brad.schoening@verizon.net
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Claise et al. Expires March 9, 2014 [Page 42]