One document matched: draft-ietf-eman-framework-02.txt
Differences from draft-ietf-eman-framework-01.txt
Network Working Group B. Claise
Internet-Draft J. Parello
Intended Status: Informational Cisco Systems, Inc.
Expires: January 8, 2012 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd.
July 8, 2011
Energy Management Framework
draft-ietf-eman-framework-02
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 October, 2011.
Internet-Draft <EMAN Framework> July 2011
Copyright Notice
Copyright (c) 2011 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. The framework defines a domain of Energy Management
devices that is a logical unit of Energy Management. Within a
domain each device is identified, classified and given context.
Devices can be monitored and/or controlled with respect to
power, power state, energy, demand, electrical quality, and
battery. Additionally the framework models relationships and
capabilities between devices in a domain.
<Claise, et. Al> Expires January 8, 2012 [Page 2]
Internet-Draft <EMAN Framework> July 2011
Table of Contents
1. Introduction........................................... 4
1.1. Energy Management Document Overview............... 4
2. Requirements & Use Cases............................... 5
3. Terminology............................................ 6
4. Energy Management Reference Model..................... 11
5. Framework High Level Concepts and Scope............... 14
5.1. Energy Managed Object and Energy Management Domain15
5.2. Energy Managed Object Identification and Context. 15
5.2.1 Identification .............................. 15
5.2.2 Context in General .......................... 16
5.2.3 Context: Importance ......................... 16
5.2.4 Context: Keywords............................ 17
5.2.5 Context: Role ............................... 18
5.3. Energy Managed Object Relationships.............. 18
5.3.1 Energy Managed Object Children Discovery .... 19
5.4. Energy Monitoring ............................... 19
5.5. Energy Control................................... 22
5.5.1 IEEE1621 Power State Series ................. 22
5.5.2 DMTF Power State Series...................... 23
5.5.3 EMAN Power State Series...................... 24
6. Structure of the Information Model: UML Representation 28
7. Configuration ........................................ 33
8. Fault Management ..................................... 34
9. Relationship with Other Standards Development
Organizations............................................ 35
9.1. Information Modeling............................. 35
10. Security Considerations.............................. 35
10.1. Security Considerations for SNMP .................. 36
11. IANA Considerations ................................. 37
12. Acknowledgments ..................................... 37
13. References .......................................... 37
Normative References ................................. 37
Informative References ............................... 37
TO DO/OPEN ISSUE
- IPFIX or not? Initially IPFIX was mentioned in [EMAN-REQ],
then we see now: "A solution for this is that the concerned
entity or another entity closely interacting with the concerned
entity collect time series of power values and make them
available via push or pull mechanisms to receivers of the
information.". So, the questions are: Is IPFIX a requirement?
What other mechanism do we have to PUSH time series of power
<Claise, et. Al> Expires January 8, 2012 [Page 3]
Internet-Draft <EMAN Framework> July 2011
values (no, SNMP notifications are not suitable)? So should we
or not include IPFIX in this document?
- Power Monitor has been renamed to Energy Managed Object. Get
consensus on the terminology. Another example is Power
Quality
- A couple of EDITOR'S NOTES in the draft
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). 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].
This document defines a framework for providing Energy
Management for devices within or connected to communication
networks. The framework describes how to identity, classify and
provide context for a device in a communications network from
the point of view of Energy Management.
The identified device can then be monitored for Energy
Management by obtaining measurements for power, energy, demand
and electrical quality. If a device contains a battery(s) the
characteristics and performance of the battery(s) can also be
managed. A device's 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
device reporting information about itself. However, in many
cases, energy is not measured by the device itself, but by a
meter located upstream in the power distribution tree. An
example is a power distribution unit (PDU) that measures energy
consumption of attached devices and may report this to an Energy
Management System. Therefore, devices are recognized as having
relationships to other devices in the network from the point of
view of Energy Management. These relationships include
Aggregation, Metering, Power Source(s), Proxy, and Dependency.
1.1. Energy Management Document Overview
The EMAN standard provides a set of specifications that together
provide Energy Management. This document specifies the
framework, per the Energy Management requirements specified in
[EMAN-REQ]
<Claise, et. Al> Expires January 8, 2012 [Page 4]
Internet-Draft <EMAN Framework> July 2011
The applicability statement document [EMAN-AS] provides a list
of use cases, cross-reference between existing standards and the
EMAN standard, and shows how the this relates to other
frameworks.
The [EMAN-AWARE-MIB] provides objects for addressing
identification, classification, context information, and
relationships form the point of view of Energy Management.
The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains
objects for monitoring of Power, Energy, Demand, Electrical
Quality and Power State Sets.
Definition of Managed Objects for Battery Monitoring [EMAN-
BATTERY-MIB] defines managed objects that provide information on
the status of batteries in managed devices.
EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
group documents. Hence, these references will be changed in the
future.
2. 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.
For example, target devices for this specification can include
(but are not limited to):
- Simple electrical appliances / fixtures
- Hosts, such as a PC or a datacenter server
- Routers
- Switches
- Switches with line card components
- Power over Ethernet (PoE) endpoints,
- Power Distribution Units (PDU)
- Protocol gateways devices for Building Management Systems
(BMS)
- Electrical Meters
<Claise, et. Al> Expires January 8, 2012 [Page 5]
Internet-Draft <EMAN Framework> July 2011
- Sensor controllers with subtended sensors
There may also exist varying protocols deployed among these
parallel 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.
3. 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].
This section contains definitions of terms used throughout this
specification. Defined terms have their first letter
capitalized. Entities, relationships and or capabilities are
defined with respect to well known software patterns as
described in [GAMMA] and [EIPATT]
Energy Management System (EnMS)
An 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 EnMS allows organizations to improve
energy performance and demonstrate conformity to requirements,
standards and/or legal requirements. This definition is in line
with the definition of "Energy management systems - Requirements
with guidance for use" [ISO50001].
With respect to communication networks these same goals will
apply to the communications networks and attached devices within
an organization.
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
<Claise, et. Al> Expires January 8, 2012 [Page 6]
Internet-Draft <EMAN Framework> July 2011
constraints of the organization. In that light, Energy
Management is a system congruent to any of FCAPS area 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 EnMS.
Energy Management Systems
An Energy Management System (EMS) is congruent to a Network
Management System (NMS) and is a combination of hardware and
software used to administer a network with the primarily purpose
being Energy Management.
Energy Monitoring
Energy Monitoring is a part of Energy Management that deals with
collecting or reading measurements from devices to aid in Energy
Management. This could include Energy, Power, Demand, Quality,
Context and/or Battery information.
Energy
Energy
Energy is the capacity of a system to produce external activity
or perform work and can be electricity, fuels, steam, heat,
compressed air, and other like media. Energy is typically
expressed in watt hours or joules.
Power
Power is a rate of energy conversion. As the unit of time
approaches zero a power measurement is called an instantaneous
power reading. Typically when implementing Power monitoring in
hardware, a measuring device may have to compute an average
value per some unit of time to express a reading to approximate
an instantaneous power measurement.
Demand
Demand is an average of Power measurements over an interval(s)
of time and typically expressed in kilowatt hours. This
measurement is significant because some utilities or energy
providers bill by Demand measurements as well as for maximum
<Claise, et. Al> Expires January 8, 2012 [Page 7]
Internet-Draft <EMAN Framework> July 2011
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
EDITOR'S NOTE: This may be rephrased as Electrical
Characteristics.
Power Quality is defined as a set of values to describe the
electrical characteristics of Power as provided by an electrical
source as seen by the Energy Managed Object. For example: AC
phase, apparent and reactive power, etc.
Energy Control
Energy Control is a part of Energy Management that deals with
modifying or setting the state of an Energy Managed Object in
order to optimize or ensure its efficiency.
Energy Managed Object
An Energy Managed Object (EMO) is a device 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.
Energy Aware Object
An Energy Managed Object may not have the capability to provide
information necessary for Energy Management itself. If an Energy
Managed Object can provide Energy Management Context, Energy
Monitor and optionally Energy Control values for itself then the
Energy Managed Object is said to be an Energy Aware Object
For example: as the most simplistic example, a set of light
bulbs where all values are provided by an EMS through estimation
and or catalogue information are not Energy Aware. In contrast a
set of network switches that can report the same information
based upon hardware sensing is said to be Energy Aware.
Energy Managed Object Identification
<Claise, et. Al> Expires January 8, 2012 [Page 8]
Internet-Draft <EMAN Framework> July 2011
Energy Managed Object Identification is a set of attributes that
enable an Energy Managed Object to be: uniquely identified among
all Energy Management Domains; linked to other systems;
classified as to type model and or manufacturer.
RFC EDITOR'S: the uniqueness must be clarified in [EMAN-REQ]
Energy Managed Object Context
Energy Managed Object Context is a set of attributes that allow
an Energy Management system to classify the use of the Energy
Managed Object within an organization. The classification
contains use and/or ranking of the Energy Managed Object as
compared to other Energy Managed Objects in the Energy
Management Domain.
Energy Management Domain
An Energy Management Domain is a name or name space that
logically groups Energy Managed Objects into a zone of Energy
Management. Typically, this zone will have as members all
Energy Managed Objects that are powered from the same electrical
panel(s) for which there is a meter or sub meter.
For example: All Energy Managed Objects drawing power from the
same distribution panel with the same AC voltage within a
building, or all Energy Managed Objects in a building for which
there is one main meter, would comprise an Energy Management
Domain.
From the standpoint of Energy Management, it is useful to report
Energy as the sum of the Energy of all the Energy Managed
Objects within an Energy Management Domain and then correlate
that value with metered values.
Energy Managed Object Relationships
Energy Managed Objects may have functional relationships to each
other within an Energy Management Domain. The functional
relationships include Aggregation, Metering, Power Source(s),
Proxy, and Dependency. One device will provide a capability or
functional value in the relationship and another will be the
receiver of the capability. These capabilities include
Aggregation, Metering, Power Source, Proxy and Dependency.
Aggregation Relationship
<Claise, et. Al> Expires January 8, 2012 [Page 9]
Internet-Draft <EMAN Framework> July 2011
An Energy Managed Object may aggregate the Energy Management
information of one or more Energy Managed Objects and is
referred to as an Aggregation Relationship. An Energy Managed
Object may be aggregated by another Energy Managed Object(s).
Aggregate values are obtained by reading values from multiple
Energy Managed Objects and producing a single value of more
significant meaning such as average, count, maximum, median,
minimum, mode and most commonly sum.
Metering Relationship
An Energy Managed Object may measure the Energy of another
Energy Managed Object(s) and is referred to as a Metering
Relationship. An Energy Managed Object may be metered by
another Energy Managed Object(s). Example: a PoE port on a
switch measure the Power it provides to the connected Energy
Managed Object.
Power Source Relationship
An Energy Managed Object may be the source of or distributor of
power to another Energy Managed Object(s) and is referred to as
a Power Source Relationship. An Energy Managed Object may be
powered by another Energy Managed Object(s). Example: a PDU
provides power for a connected host.
Proxy Relationship
An Energy Managed Object that provides Energy Management
capabilities on behalf of another Energy Managed Object so that
is appears to be Energy Aware is referred to a Proxy
Relationship. An Energy Managed Object may be proxied by
another Energy Managed Object(s). Example: a protocol gateways
device for Building Management Systems (BMS) with subtended
devices.
Dependency Relationship
An Energy Managed Object may be a component of or rely
completely upon another Energy Managed Object to operate and is
referred to as a Dependency Relationship. An Energy Managed
Object may be dependent on another Energy Managed Object(s).
Example: A Switch chassis with multiple line cards
Energy Managed Object Parent
<Claise, et. Al> Expires January 8, 2012 [Page 10]
Internet-Draft <EMAN Framework> July 2011
An Energy Managed Object Parent is an Energy Managed Object that
provides one or more of the Energy Managed Object Relationships
capabilities.
Energy Managed Object Child
An Energy Managed Object Child is an Energy Managed Object that
has at least one Energy Managed Object Relationship capability
provided by another Energy Managed Object.
Power State
A Power State is a way to classify a Power setting on an Energy
Managed Object (e.g., on, off, or sleep). A Power State can be
viewed as a method for Energy Control
Manufacturer Power State
A Manufacturer Power State is a device-specific way to classify
a Power setting implemented on an Energy Managed Object.
Power State Set
A collection of Power States that comprise one named or logical
grouping of control is a Power State Set. For 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. This is typically determined via load testing and
is specified by the manufacturer as the maximum value required
to operate 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.
4. 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 Managed
<Claise, et. Al> Expires January 8, 2012 [Page 11]
Internet-Draft <EMAN Framework> July 2011
Objects may communicate over varying protocols. For example the
communications network may use IP Protocols (SNMP) but attached
Energy Managed Object Parent may communicate to Energy Managed
Object Children over serial communication protocols like BACNET,
MODBUS etc. The likelihood of getting these different
topologies to convert 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 the Figure 1, the most basic energy reference
model is composed of an Energy Management System (EMS) that
obtains Energy Management information from Energy Managed
Objects. The Energy Managed Object returns information for
Energy Management directly to the EMS.
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 require the push of time
series of power values. Therefore, IPFIX [RFC5101] is also
mentioned in the following figures.
+---------------+
| EMS | - -
+-----+---+-----+ ^ ^
| | | |
| | |S |I
+---------+ +----------+ |N |P
| | |M |F
| | |P |I
+-----------------+ +--------+--------+ | |X
| EMO 1 | ... | EMO N | v |
+-----------------+ +-----------------+ - -
Figure 1: Simple Energy Management
As displayed in the Figure 2, 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 January 8, 2012 [Page 12]
Internet-Draft <EMAN Framework> July 2011
+---------------+
| EMS | - -
+-----+--+------+ ^ ^
| | | |
| | |S |I
+------------+ +--------+ |N |P
| | |M |F
| | |P |I
+------------------+ +------+-----------+ | |X
| EMO | | EMO | v |
| Parent 1 | ... | Parent N | - -
+------------------+ +------------------+
||| .
One or ||| .
Multiple ||| .
Enery Managed ||| .
Object ||| .
Relationship(s): |||
- Aggregation ||| +-----------------------+
- Metering |||------| EMO Child 1 |
- Power Source || +-----------------------+
- Proxy ||
- Dependency || +-----------------------+
||-------| EMO Child 2 |
| +-----------------------+
|
|
|-------- ...
|
|
| +-----------------------+
|--------| EMO Child M |
+-----------------------+
Figure 2: Complex Energy Management Model
While both the simple and complex Energy Management models
contain an EMS, this framework doesn't impose any requirements
regarding a topology with a centralize EMS or one with a
distributed Energy Management via the Energy Managed Objects
within the deployment.
<Claise, et. Al> Expires January 8, 2012 [Page 13]
Internet-Draft <EMAN Framework> July 2011
Given the pattern in figure 2, the complex relationships between
Energy Managed Objects can be modeled (refer also to section
5.3):
- A PoE device modeled as an Energy Managed Object Parent
with the Power Source, Metering, and Proxy Relationships
for this powered device
- A PDU modeled as an Energy Managed Object Parent with
the Power Source and Metering for the plugged in host
- A PC with line cards modeled as an Energy Managed Object
Parent with Dependency Relationships for the line cards
- Building management gateway, used as proxy for non IP
protocols, is modeled as an Energy Managed Object Parent
with the Proxy Relationship, and potentially the
Aggregation Relationship
- Etc.
The communication between the Energy Managed Object Parent and
Energy Managed Object Children is out of the scope of this
framework.
5. Framework High Level Concepts and Scope
Energy Management can be organized into areas of concern that
include:
- Energy Managed Object Identification and Context - for
modeling and planning
- Energy Monitoring - for energy measurements
- Energy Control - for optimization
- Energy Procurement - for optimization of resources
The framework addresses Energy Management but excludes Energy
Procurement and the environmental impact of energy use. As such
the framework does not include:
- Manufacturing costs of an Energy Managed Object in currency or
environmental units
- Embedded carbon or environmental equivalences of an Energy
Managed Object
- Cost in currency or environmental impact to dismantle or
recycle an Energy Managed Object
- Relationship or capabilities of an Energy Managed Object to an
electrical or smart grid
<Claise, et. Al> Expires January 8, 2012 [Page 14]
Internet-Draft <EMAN Framework> July 2011
- Supply chain analysis of energy sources or Energy Managed
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 Managed Object and Energy Management Domain
- Energy Managed Object Identification and Context
- Energy Managed Object Relationships
- Energy Monitoring
- Energy Control
- Deployment Topologies
5.1. Energy Managed Object and Energy Management Domain
An Energy Management Domain is a manageable set of devices that
has a meter or sub-meter attached and typically corresponds to a
power distribution point or panel.
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. The Energy Management Domain
should be configured on an Energy Managed Object. An Energy
Managed Object Child may inherit the domain value from an Energy
Managed Object Parent or the Energy Management Domain may be
configured directly in an Energy Managed Object Child.
5.2. Energy Managed Object Identification and Context
5.2.1 Identification
Energy Managed Objects MUST contain a value that uniquely
identifies the Energy Managed Object among all the Energy
Management Domains within an EnMS. It is recommended that a
<Claise, et. Al> Expires January 8, 2012 [Page 15]
Internet-Draft <EMAN Framework> July 2011
universal identifier (UUID) be used to uniquely identify the
Energy Managed Object.
Every Energy Managed Object should have a 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 Managed Object. As an example, in the
case of IP phones, the Energy Managed Object name can be the
device DNS name.
5.2.2 Context in General
In order to aid in reporting and in differentiation between
Energy Managed Objects, each Energy Managed Object optionally
contains information establishing its business, site, or
organizational context within a deployment.
5.2.3 Context: Importance
An Energy Managed Object can provide an importance value in the
range of 1 to 100 to help differentiate 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 is more important than a PC and
a phone for lobby use.
Although Energy Management Systems 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
<Claise, et. Al> Expires January 8, 2012 [Page 16]
Internet-Draft <EMAN Framework> July 2011
. 40 to 59 Public or guest
. 1 to 39 Decorative or hospitality
5.2.4 Context: Keywords
An Energy Managed Object can provide a set of keywords. These
keywords are a list of tags that can be used for grouping and
summary reporting within or between Energy Management Domains.
All alphanumeric characters and symbols, 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. In such cases,
the keywords are separated by commas and no spaces between
keywords are allowed. For example, "HR,Bldg1,Private".
Another keyword use case is the virtual grouping of Energy
Managed Objects. 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.
This is particularly useful for servers with multiple power
supplies, where each power supply is connected to a different
physical outlet. Other implementations allow "gangs" to be
created based on common ownership of outlets, such as business
units or load shed priority or other non-physical relationships.
For example, current PDU implementations allow for an "M-to-N"
mapping between outlet "gangs" and physical outlets:
Outlet 1 (physical entity)
Outlet 2 (physical entity)
Outlet 3 (physical entity)
Outlet 4 (physical entity)
Outlet Gang A (virtual entity)
Outlet Gang B (virtual entity)
Gang A -> Outlets 1, 2 and 3
Gang B -> Outlets 3 and 4
<Claise, et. Al> Expires January 8, 2012 [Page 17]
Internet-Draft <EMAN Framework> July 2011
Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
both "gangs". The keywords concept for this specific example
would be used as such:
Outlet 1 Energy Managed Object 1, keywords: gangA
Outlet 2 Energy Managed Object 2, keywords: gangA
Outlet 3 Energy Managed Object 3, keywords: gangA,
gangB
Outlet 4 Energy Managed Object 4, keywords: gangB
Each "Outlet Gang" virtual entity, aggregated based on the value
of the keywords, reports the aggregated data from the individual
outlet entities that comprise it. The same concept enables a
single point of control for all the individual outlet entities.
For example, turning "Outlet Gang A" to the "off" state would
turn outlets 1, 2, and 3 "off" in some implementations. Note
that the impact of this action on "Outlet Gang B" is out of
scope of this document.
5.2.5 Context: Role
An Energy Managed Object can provide a "role description" string
that indicates the purpose the Energy Managed Object serves in
the EnMS. This could be a string describing the context the
device fulfills in deployment. For example, a lighting fixture
in a kitchen area could have a role of "Hospitality Lighting" to
provide context for the use of the device.
5.3. Energy Managed Object Relationships
An Energy Managed Object MAY be an Energy Managed Object Parent
or Energy Managed Object Child of another Energy Managed Object.
Energy Managed Objects establish a parent and child relationship
when one Energy Managed Object provides capabilities for another
Energy Managed Object.
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 is the source of power for the attached device, so the
Energy Managed Object Parent is the switch, and the Energy
Managed Object Child is the device attached to the switch.
<Claise, et. Al> Expires January 8, 2012 [Page 18]
Internet-Draft <EMAN Framework> July 2011
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 lighting controller may use BACNET
to communicate with child lighting devices.
5.3.1 Energy Managed Object Children Discovery
There are multiple ways that the Energy Managed Object Parent
can discover its Energy Managed Object Children, if they are not
present on the same physical network:
. In case of PoE, the Energy Managed Object Parent
automatically discovers an Energy Managed Object Child when
the Child requests power.
. The Energy Managed 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 Managed Object Parent might even support the
LLDP-MED MIB [LLDP-MED-MIB], which returns extra
information on the Energy Managed Object Children.
. The Energy Managed Object Parent may reside on a network
connected 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.
. Energy Managed Object Parent/Energy Managed Object Child
relationships may be set by manual or automatic network
configuration functions.
Note that the communication specifications between the Energy
Managed Object Parent and Children is out of the scope of this
document.
When an Energy Managed Object Parent is a Proxy, the Energy
Managed Object Parent should enumerate the capabilities it is
providing for the Energy Managed Object Child. The child would
express that it wants its parent to proxy capabilities such as,
energy reporting, power state configurations, non physical wake
capabilities (such as WoL)), or any combination of capabilities.
5.4. Energy Monitoring
For the purposes of this framework energy will be limited to
electrical energy in watt hours. Other forms of Energy Managed
Objects that use or produce non-electrical energy may be part of
an Energy Management Domain but MUST provide information
converted to and expressed in watt hours.
<Claise, et. Al> Expires January 8, 2012 [Page 19]
Internet-Draft <EMAN Framework> July 2011
Each Energy Managed Object will have information that describes
Power and Energy information along with how that measurement was
obtained or derived.
Optionally, an Energy Managed Object can further describe the
power information with power quality information reflecting the
electrical characteristics of the measurement.
Optionally, an Energy Managed Object can provide Demand
information over time
Power Measurement
A Power measurement must be qualified with the units, magnitude,
direction of power flow, and by what means the measurement was
made (ex: Root Mean Square versus Nameplate).
In addition, the Energy Managed 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 EMS. 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 EMS.
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 raised to the power of the scale.
For example, if current power usage of an Energy Managed Object
is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the
value of the scaling factor. Electric 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. An conversion from Wh to
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 Managed Object usage measurement was
obtained:
. Whether the measurements were made at the device itself or
from a remote source.
<Claise, et. Al> Expires January 8, 2012 [Page 20]
Internet-Draft <EMAN Framework> July 2011
. Description of the method that was used to measure the power
and whether this method can distinguish actual or estimated
values.
An EMS can use this information to account for the accuracy and
nature of the reading between different implementations.
The EMS can use the Nameplate Power for provisioning, capacity
planning and potentially billing.
Optional Power Quality
Given a Power measurement it may in certain circumstances be
desirable to know the electrical characteristics associated with
that measurement. The information model must adhere to the IEC
61850 7-2 standard for describing AC measurements. In some
Energy Management Domains, the power quality may not be needed,
available, or relevant to the EMS.
Optional Demand
It is well known in commercial electrical utility rates that
Demand is used as a measurement for billing. Also 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 Managed Object, and not when the power measurement is
assumed or predicted.
Optional Battery
Some Energy Managed Objects may use batteries for storing energy
and for receiving power supply. These Energy Managed 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
. battery type
. nominal and remaining capacity
. current charge
. current state (charging, discharging, not in use, etc.)
<Claise, et. Al> Expires January 8, 2012 [Page 21]
Internet-Draft <EMAN Framework> July 2011
. number of charging cycles
. expected remaining time that the battery can serve as power
supply
. expected remaining lifetime of the battery
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.
5.5. Energy Control
Energy Managed Objects can be controlled by setting it to a
Power State. Sets of Power States can be seen as an interface by
which an Energy Managed Object can be controlled. Each Energy
Managed Object should indicate the Power State Sets that is
implements. Well known Power State Sets should be registered
with IANA
When and individual Power State is configured from a specific
Power State Set, an Energy Managed Object may be busy at the
request time. The Energy Managed 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
Set. An Energy Managed Object can support one or multiple Power
State Set implementations concurrently.
This framework list three initial possible Power State Series
that can be supported by an Energy Managed Object:
IEEE1621 - [IEEE1621]
DMTF - [DMTF]
EMAN - Specified here
5.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.
<Claise, et. Al> Expires January 8, 2012 [Page 22]
Internet-Draft <EMAN Framework> July 2011
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.
5.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
2 Off-Soft G2, S5 SoftOff
3 Hibernate G1, S4 Hibernate
4 Sleep-Deep G1, S3 Sleep
5 Sleep-Light G1, S2 Standby
6 Sleep-Light G1, S1 Ready
Operational states:
7 On G0, S0, P5 LowMinus
8 On G0, S0, P4 Low
9 On G0, S0, P3 MediumMinus
10 On G0, S0, P2 Medium
11 On G0, S0, P1 HighMinus
12 On G0, S0, P0 High
Figure 3: DMTF / ACPI Power State Mapping
<Claise, et. Al> Expires January 8, 2012 [Page 23]
Internet-Draft <EMAN Framework> July 2011
5.5.3 EMAN Power State Series
The EMAN Power State Series represents an attempt for a uniform
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 incorporate 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). For each
operational state represent 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:
IEEE1621 Power(off):
mechoff(1) : An off state where no Energy Managed
Object features are available. The Energy Managed 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 Managed
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.
IEEE1621 Power(sleep)
hibernate(3): No Energy Managed Object features are
available. The Energy Managed 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.
<Claise, et. Al> Expires January 8, 2012 [Page 24]
Internet-Draft <EMAN Framework> July 2011
Typically, energy consumption is zero or close to zero. This
corresponds to state G1, S4 in ACPI.
sleep(4) : No Energy Managed Object features are
available, except for out-of-band management, for example 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 Managed Object features are
available, except for out-of-band management, for example 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 Managed Object features are
available, except for out-of-band management, for example wake-
up mechanisms. This mode is analogous to hot-standby. The
Energy Managed 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.
IEEE1621 Power(on):
lowMinus(7) : Indicates some Energy Managed Object
features may not be available and the Energy Managed Object has
selected measures/options to provide less than low(8) usage.
This corresponds to ACPI State G0. This includes operational
states lowMinus(7) to full(12).
low(8) : Indicates some features may not be
available and the Energy Managed Object has taken measures or
selected options to provideless than mediumMinus(9) usage.
mediumMinus(9): Indicates all Energy Managed Object
features are available but the Energy Managed Object has taken
measures or selected options to provide less than medium(10)
usage.
medium(10) : Indicates all Energy Managed Object
features are available but the Energy Managed Object has taken
measures or selected options to provide less than highMinus(11)
usage.
<Claise, et. Al> Expires January 8, 2012 [Page 25]
Internet-Draft <EMAN Framework> July 2011
highMinus(11): Indicates all Energy Managed Object
features are available and power usage is less than high(12).
high(12) : Indicates all Energy Managed Object
features are available and the Energy Managed Object is
consuming the highest power.
Energy Managed Objects may have Manufacturer Power States Sets
and can map these to the EMAN Power State Sets. The follow
shows examples when Manufacturer Power State Sets have fewer or
more states than the EMAN Power State Set
A first example would be an imaginary device type, with only
five states: "none", "short", "tall", "grande", and "venti".
Manufacturer Power State Respective Name
0 none
1 short
2 tall
3 grande
4 venti
Figure 4: Mapping Example 1
In the unlikely event that there is no possible mapping between
these Manufacturer Power States and the proposed Energy Managed
Object States, the Power State will remain 0 throughout, as
displayed below.
Power State / Name Manufacturer Power State / Name
0 / unknown 0 / none
0 / unknown 1 / short
0 / unknown 2 / tall
0 / unknown 3 / grande
0 / unknown 4 / venti
Figure 5: Mapping Example 2
If a mapping between the Manufacturer Power States and the
Energy Managed Object Power States is achievable, both series of
states must exist in the MIB module in the Energy Managed Object
Parent, allowing the EMS to understand the mapping between them
by correlating the Power State with the Manufacturer Power
States.
Power State / Name Manufacturer Power State / Name
1 / MechOff 0 / none
2 / SoftOff 0 / none
<Claise, et. Al> Expires January 8, 2012 [Page 26]
Internet-Draft <EMAN Framework> July 2011
3 / Hibernate 0 / none
4 / Sleep, Save-to-RAM 0 / none
5 / Standby 0 / none
6 / Ready 1 / short
7 / LowMinus 1 / short
8 / Low 1 / short
9 / MediumMinus 2 / tall
10 / Medium 2 / tall
11 / HighMinus 3 / grande
12 / High 4 / venti
Figure 6: Mapping Example 3
How the Energy Managed Object States are then mapped is an
implementation choice. However, it is recommended that the
Manufacturer Power States map to the lowest applicable Power
States, so that setting all Energy Managed Objects to a Power
State would be conservative in terms of disabled functionality
on the Energy Managed Object.
A second example would be a device type, such as a dimmer or a
motor, with a high number of operational states. For the sake
of the example, 100 operational states are assumed.
Power State / Name Manufacturer Power State / Name
1 / MechOff 0 / off
2 / SoftOff 0 / off
3 / Hibernate 0 / off
4 / Sleep, Save-to-RAM 0 / off
5 / Standby 1 / off
6 / Ready 2 / off
7 / LowMinus 11 / 1%
7 / LowMinus 12 / 2%
7 / LowMinus 13 / 3%
. .
. .
. .
8 / Low 15 / 15%
8 / Low 16 / 16%
8 / Low 17 / 17%
. .
. .
. .
9 / MediumMinus 30 / 30%
9 / MediumMinus 31 / 31%
9 / MediumMinus 32 / 32%
. .
<Claise, et. Al> Expires January 8, 2012 [Page 27]
Internet-Draft <EMAN Framework> July 2011
. .
. .
10 / Medium 45 / 45%
10 / Medium 46 / 46%
10 / Medium 47 / 47%
. .
. .
. .
etc...
Figure 7: Mapping Example 4
As specified in section 6, this framework allows the
configuration of the Power State, while configuring the
Manufacturer Power State from the MIB directly is not possible.
6. Structure of the Information Model: UML Representation
EDITOR'S NOTE: right place here or in the appendix?
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 an 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
<Claise, et. Al> Expires January 8, 2012 [Page 28]
Internet-Draft <EMAN Framework> July 2011
EMO RELATIONSHIPS AND CONTEXT
+----------------------------+
| _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 Managed Object Information |
|-----------------------------------------|
| index : int |
| powerMonitorId | UUID |
| name : string |
| meterDomainName | string |
| alternateKey | string |
+-----------------------------------------+
^
|
|
|
+-------------------------+
| Links Object |
|-------------------------|
| physicalEntity : int |
| ethPortIndex : int |
| ethPortGrpIndex : int |
| lldpPortNumber : int |
+-------------------------+
EMO AND MEASUREMENTS
+-----------------------------------------------+
| Energy Managed Object |
|-----------------------------------------------|
<Claise, et. Al> Expires January 8, 2012 [Page 29]
Internet-Draft <EMAN Framework> July 2011
| 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 : MeasurementQuality |
+-----------------------------------------------+
+-----------------------------------------------+
| TimeMeasurement |
|-----------------------------------------------|
| startTime : timestamp |
| usage : Measurement |
| maxUsage : Measurment |
+-----------------------------------------------+
+----------------------------------------+
| TimeInterval |
|--------------------------------------- |
|value : long |
|units : enum { seconds, miliseconds..} |
+----------------------------------------+
<Claise, et. Al> Expires January 8, 2012 [Page 30]
Internet-Draft <EMAN Framework> July 2011
+----------------------------------------+
| DemandMeasurement |
|----------------------------------------|
|intervalLength : TimeInterval |
|intervalNumbers: long |
|intervalMode : enum { period, sliding, |
|total } |
|intervalWindow : TimeInterval |
|sampleRate : TimeInterval |
|status : enum {active, inactive } |
|measurements : TimedMeasurement[] |
+----------------------------------------+
QUALITY
+----------------------------------------+
| MeasurementQuality |
|----------------------------------------|
| |
+----------------------------------------+
^
|
|
+------------------+--------------------+
| 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 |
<Claise, et. Al> Expires January 8, 2012 [Page 31]
Internet-Draft <EMAN Framework> July 2011
| avgCurrent : long |
| activePower : long |
| reactivePower : long |
| apparentPower : long |
| powerFactor : long |
+------------------------------------+
^ ^
| |
| |
| |
| |
+-------------------------------+---+ |
| DelPhase | |
|-----------------------------------| |
|phaseToNextPhaseVoltage : long | |
|thdVoltage : long | |
|thdCurrent : long | |
+-----------------------------------+ |
|
+------------------+-----------+
| WYEPhase |
|------------------------------|
|phaseToNeutralVoltage : long |
|thdCurrent : long |
|thdVoltage : long |
+------------------------------+
EMO & STATES
+----------------------------------------------+
| Energy Managed Object |
|----------------------------------------------|
<Claise, et. Al> Expires January 8, 2012 [Page 32]
Internet-Draft <EMAN Framework> July 2011
| currentLevel : int |
| configuredLevel : int |
| configuredTime : timestamp |
| reason: string |
| manufacturerLevels[0..n]: State |
| emanLevels[0..11] : State |
| levelMappings[0..n] : LevelMapping |
+----------------------------------------------+
+-------------------------------+
| State |
|-------------------------------|
| name : string |
| cardinality : int |
| maxUsage : Measurement |
+-------------------------------+
+-----------------------------------------------+
| Level Mapping |
|-----------------------------------------------|
| emanLevelIndex: int |
| manufacturerLevelIndex : int |
+-----------------------------------------------+
7. Configuration
This power management framework allows the configuration of the
following key parameters:
. Energy Managed Object name: A unique printable name for the
Energy Managed Object.
. Energy Managed Object Role: An administratively assigned
name to indicate the purpose an Energy Managed Object
serves in the network.
. Energy Managed Object Importance: A ranking of how
important the Energy Managed Object is, on a scale of 1 to
100, compared with other Energy Managed Objects in the same
Energy Management Domain.
. Energy Managed Object Keywords: A list of keywords that can
be used to group Energy Managed Objects for reporting or
searching.
. Energy Management Domain: Specifies the name of an Energy
Management Domain for the Energy Managed Object.
<Claise, et. Al> Expires January 8, 2012 [Page 33]
Internet-Draft <EMAN Framework> July 2011
. Energy Managed Object State: Specifies the current Power
State (0..12) for the Energy Managed Object.
. Demand parameters: For example, which interval length to
report the Deman over, the number of intervals to keep,
etc.
. Assigning an Energy Managed Object Parent to an Energy
Managed Object Child
. Assigning an Energy Managed Object Child to an Energy
Managed Object Parent.
When an Energy Managed Object requires a mapping with the
Manufacturer Power State, the Energy Managed Object
configuration is done via the Power State settings, and not
directly via the Manufacturer Power States, which are read-only.
Taking into account Figure 7, where the LowMinus Power State
corresponds to three different Manufacturer Power States (11 for
1%, 12 for 2%, and 13 for 3%), the implication is that this
framework will not set the Manufacturer Power State to one
percent granularity without communicating over or configuring
the proprietary protocol for this Energy Managed Object.
This framework supports multiple means for setting the Power
State of a specific Energy Managed Object. However, the Energy
Managed 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 Managed
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 Managed Object Parent and the
Energy Managed Object Child, when the Energy Managed 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.
8. 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
<Claise, et. Al> Expires January 8, 2012 [Page 34]
Internet-Draft <EMAN Framework> July 2011
notification is generated when the value(s) of Power State has
changed for the Energy Managed Object.
9. Relationship with Other Standards Development Organizations
9.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, energy related objects is based on IEC
61850.
Specific examples include:
. The scaling factor, which represents Energy Managed Object
usage magnitude, conforms to the IEC 61850 definition of
unit multiplier for the SI (System International) units of
measure.
. The electrical characterisitc 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 state
extensions.
10. 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.
<Claise, et. Al> Expires January 8, 2012 [Page 35]
Internet-Draft <EMAN Framework> July 2011
10.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 Managed Object may result in
misreporting or interruption of power.
. Unauthorized changes to a power state may disrupt the power
settings of the different Energy Managed Objects, and
therefore the state of functionality of the respective
Energy Managed Objects.
. Unauthorized changes to the demand history may disrupt
proper accounting of energy usage.
With respect to data transport SNMP versions prior to SNMPv3 did
not include adequate security. Even if the network itself is
secure (for example, by using IPsec), there is still no secure
control over who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in these MIB
modules.
It is recommended that implementers consider the security
features as provided by the SNMPv3 framework (see [RFC3410],
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is not
recommended. Instead, it is recommended to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of these MIB modules is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to GET or SET (change/create/delete) them.
<Claise, et. Al> Expires January 8, 2012 [Page 36]
Internet-Draft <EMAN Framework> July 2011
11. IANA Considerations
EDITOR'S NOTE: Add power states
12. Acknowledgments
The authors would like to Michael Brown for improving the text
dramatically, and Bruce Nordman for his excellent feedback.
13. 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.
[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.
Informative References
[RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
between Information Models and Data Models", RFC 3444,
January 2003.
[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.
<Claise, et. Al> Expires January 8, 2012 [Page 37]
Internet-Draft <EMAN Framework> July 2011
[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 Managed
Objecting", draft-ietf-eman-requirements-03, (work in
progress), June 2010.
[EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
Networks and Devices MIB", draft-ietf-eman-energy-
aware-mib-01, (work in progress), March 2011.
[EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
Dietz, T., and B. Claise, "Power and Energy Monitoring
MIB", draft-claise-energy-monitoring-mib-08, (work in
progress), May 2011.
[EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
Definition of Managed Objects for Battery Monitoring",
draft-ietf-eman-battery-mib-02, (work in progress),
July 2011.
[EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy
Management (EMAN) Applicability Statement", draft-
tychon-eman-applicability-statement-02, (work in
progress), June 2011
[DASH] "Desktop and mobile Architecture for System Hardware",
http://www.dmtf.org/standards/mgmt/dash/
[ISO50001] "ISO 50001:2011 Energy management systems -
Requirements with guidance for use",
http://www.iso.org/
[DMTF] "Power State Management Profile DMTF DSP1027 Version
2.0" December 2009
http://www.dmtf.org/sites/default/files/standards/docum
ents/DSP1027_2.0.0.pdf
[TMN] "TMN Management Functions : Performance Management.", ITU-
T M.3400
[GAMMA] Eric Gamma et al. "Design Patterns: Element of Reusable
Object-Oriented Software", 1994
<Claise, et. Al> Expires January 8, 2012 [Page 38]
Internet-Draft <EMAN Framework> July 2011
[EIPATT] Gregor Hohpe, Bobby Woolf, "Enterprise Integration
Patterns: Designing Building and Deploying Messaging
Solutions" 2004, http://eaipatterns.com/index.html
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US
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
<Claise, et. Al> Expires January 8, 2012 [Page 39]
Internet-Draft <EMAN Framework> July 2011
<Claise, et. Al> Expires January 8, 2012 [Page 40]
| PAFTECH AB 2003-2026 | 2026-04-24 04:52:19 |