Energy Management Framework
draft-ietf-eman-framework-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7326.
|
|
|---|---|---|---|
| Authors | Benoît Claise , John Parello , Little Silver , Juergen Quittek | ||
| Last updated | 2011-10-30 (Latest revision 2011-07-08) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
SECDIR Last Call review
(of
-15)
by Yoav Nir
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Dan Romascanu | ||
| IESG | IESG state | Became RFC 7326 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-eman-framework-03
Network Working Group B. Claise
Internet-Draft J. Parello
Intended Status: Informational Cisco Systems, Inc.
Expires: April 30, 2012 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd.
October 31, 2011
Energy Management Framework
draft-ietf-eman-framework-03
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> Oct 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 an Energy Management Domain as
a set of Energy Objects, for which each Energy Object is
identified, classified and given context. Energy Objects can
be monitored and/or controlled with respect to Power, Power
State, Energy, Demand, Power Quality, and battery. Additionally
the framework models relationships and capabilities between
Energy Objects.
<Claise, et. Al> Expires April 30, 2012 [Page 2]
Internet-Draft <EMAN Framework> Oct 2011
Table of Contents
1. Introduction................................................4
1.1. Energy Management Document Overview....................5
2. Requirements & Use Cases....................................6
3. Terminology.................................................6
4. Energy Management Reference Model...........................9
5. Framework High Level Concepts and Scope....................12
5.1. Energy Object and Energy Management Domain............13
5.2. Energy Object Identification and Context..............13
5.2.1 Energy Object Identification......................13
5.2.2 Context in General................................14
5.2.3 Context: Importance...............................14
5.2.4 Context: Keywords.................................15
5.2.5 Context: Role.....................................16
5.3. Energy Object Relationships...........................17
5.3.1 Energy Object Children Discovery..................17
5.4. Energy Monitoring.....................................18
5.4.1 Power Measurement.................................19
5.5. Energy Control........................................21
5.5.1 IEEE1621 Power State Series.......................21
5.5.2 DMTF Power State Series...........................22
5.5.3 EMAN Power State Set..............................23
6. Structure of the Information Model: UML Representation.....25
7. Configuration..............................................30
8. Fault Management...........................................31
9. Relationship with Other Standards Development
Organizations.................................................31
9.1. Information Modeling..................................31
10. Security Considerations...................................32
10.1. Security Considerations for SNMP........................32
11. IANA Considerations.......................................33
12. Acknowledgments...........................................33
13. References................................................33
Normative References.......................................33
Informative References.....................................34
TO DO/OPEN ISSUE
- Do we want to add some examples such as
http://www.ietf.org/proceedings/81/slides/eman-4.pdf slide 14
to 1]? Proposal: add it to [EMAN-AS]
- Do we need variable range of states (i.e. dimmer)? Is this a
requirement? How to model the batteries, as a component or a
relationship? See the meeting minutes:
<Claise, et. Al> Expires April 30, 2012 [Page 3]
Internet-Draft <EMAN Framework> Oct 2011
o "Modeling of the battery? If we are not modeling
components then why model batteries? Use the Entity MIB"
- Comment from Prantl on the list, related to energy control:
non-discrete power-states are not supported -> Section 5.5.
specifies the possibility of mapping
"Manufacturer" Power States to the 12 Eman Power states,
where there can be more than 12 Manufacturer Power States.
However, in the context of power-capping of Servers we have a
"non-discrete" floating cap corresponding to the Manufacturer
Power State.
The Problem is that different Servers will have completely
different ranges of supported cap-values, e.g. Server 1 has a
dynamic range of 300-500Watt, Server2 has a range of 70-
270Watts. Now let's assume Powerstate 9=400 Watts for
Server1, but would be 170Watts for Server2. Which would mean
I have to specify a Mapping for each Server-Model.
It would be far more practical if it would be possible to
supply a key-value-pair with a certain power-state in Case
the State needs context such as a power-cap, I would then
specify a state of e.g. 7 and supply the desired Cap in the
kvp-field.
PROPOSAL:
1. decide if we need a variable power state that is a
percent of maximum.
2. Power-capping can be done by the EnMS. [EMAN-AS] to
document this use case.
1. Introduction
Network management is divided into the five main areas defined
in the ISO Telecommunications Management Network model: Fault,
Configuration, Accounting, Performance, and Security Management
(FCAPS) [X.700]. Absent from this management model is any
consideration of Energy Management, which is now becoming a
critical area of concern worldwide as seen in [ISO50001].
Note that Energy Management has particular challenges in that a
power distribution network is responsible for the supply of
energy to various devices and components, while a separate
communication network is typically used to monitor and control
the power distribution network.
This document defines a framework for providing Energy
Management for devices within or connected to communication
<Claise, et. Al> Expires April 30, 2012 [Page 4]
Internet-Draft <EMAN Framework> Oct 2011
networks. The framework describes how to identify, classify and
provide context for a device in a communications network from
the point of view of Energy Management.
The identified device, called Energy Objects, can then be
monitored for Energy Management by obtaining measurements for
Power, Energy, Demand and Power Quality. If a device contains a
battery(s) the characteristics and performance of the battery(s)
can also be managed. An Energy Object state can be monitored or
controlled by providing an interface expressed as one or more
Power State Sets. The most basic example of Energy Management
is a single Energy Object reporting information about itself.
However, in many cases, Energy is not measured by the Energy
Object itself, but by a meter located upstream in the power
distribution tree. An example is a power distribution unit
(PDU) that measures Energy consumption of attached devices and
may report this to an Energy Management System (EnMS).
Therefore, Energy Objects are recognized as having relationships
to other devices in the network from the point of view of Energy
Management. These relationships include Aggregation
Relationship, Metering Relationship, Power Source Relationship ,
Proxy Relationship , and Dependency Relationship.
1.1. Energy Management Document Overview
The EMAN standard provides a set of specifications for Energy
Management. This document specifies the framework, per the
Energy Management requirements specified in [EMAN-REQ]
The applicability statement document [EMAN-AS] provides a list
of use cases, cross-reference between existing standards and the
EMAN standard, and shows how the this relates to other
frameworks.
The [EMAN-AWARE-MIB] specifies objects for addressing Energy
Object 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, Power 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.
<Claise, et. Al> Expires April 30, 2012 [Page 5]
Internet-Draft <EMAN Framework> Oct 2011
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.
Target devices for the Energy Management are all Energy Objects
that can directly or indirectly be monitored or controlled by an
Energy Management System (EnMS) using the Internet protocol, for
example:
- Simple electrical appliances / fixtures
- Hosts, such as a PC, a datacenter server, or a printer
- Routers
- Switches
- Switches with line card components
- Power over Ethernet (PoE) endpoints,
- Power Distribution Units (PDU)
- Protocol gateways devices for Building Management Systems
(BMS)
- Electrical Meters
- Sensor controllers with subtended sensors
There may also exist varying protocols deployed among these
power distributions and communication networks.
For an Energy Management framework to be useful, it should also
apply to these types of separate networks as they connect and
interact with a communications network.
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.
<Claise, et. Al> Expires April 30, 2012 [Page 6]
Internet-Draft <EMAN Framework> Oct 2011
Energy Management System (EnMS)
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Management
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Monitoring
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Power
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Demand
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Power Quality
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Control
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Object
<Claise, et. Al> Expires April 30, 2012 [Page 7]
Internet-Draft <EMAN Framework> Oct 2011
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Electrical Equipement
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Object Identification
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
EDITOR'S NOTE: the uniqueness must be clarified in [EMAN-REQ]
Energy Object Context
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Management Domain
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Object Relationships
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Aggregation Relationship
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Metering Relationship
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Power Source Relationship
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
<Claise, et. Al> Expires April 30, 2012 [Page 8]
Internet-Draft <EMAN Framework> Oct 2011
Proxy Relationship
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Dependency Relationship
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Object Parent
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Energy Managed Object Child
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Power State
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Manufacturer Power State
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Power State Set
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
Nameplate Power
EDITOR'S NOTE: use the latest definition from the [draft-
parello-eman-definitions-03] definitions
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
<Claise, et. Al> Expires April 30, 2012 [Page 9]
Internet-Draft <EMAN Framework> Oct 2011
framework recognizes that in complex deployments Energy Objects
may communicate over varying protocols. For example the
communications network may use IP Protocols (SNMP) but attached
Energy Object Parent may communicate to Energy Object Children
over serial communication protocols like BACNET, MODBUS etc.
The likelihood of getting these different topologies to convert
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 EnMS that obtains Energy Management
information from Energy Objects. The Energy Object (EO) returns
information for Energy Management directly to the EnMS.
The protocol of choice for Energy Management is SNMP, as three
MIBs are specified for Energy Management: the energy-aware MIB
[EMAN-AWARE-MIB], the energy monitoring MIB [EMAN-MON-MIB], and
the battery MIB [EMAN-BATTERY-MIB]. However, the EMAN
requirement document [EMAN-REQ] also require the push of time
series of power values. Therefore, IPFIX [RFC5101] is also
mentioned as the appropriate solution in the following figures,
even if there are no documents describing the IPFIX solution at
the time of writing these lines. Note that this framework
doesn't exclude another solution than IPFIX.
+---------------+
| EnMS | - -
+-----+---+-----+ ^ ^
| | | |
| | |S |I
+---------+ +----------+ |N |P
| | |M |F
| | |P |I
+-----------------+ +--------+--------+ | |X
| EO 1 | ... | EO 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 April 30, 2012 [Page 10]
Internet-Draft <EMAN Framework> Oct 2011
+---------------+
| EnMS | - -
+-----+--+------+ ^ ^
| | | |
| | |S |I
+------------+ +--------+ |N |P
| | |M |F
| | |P |I
+------------------+ +------+-----------+ | |X
| EO | | EO | v |
| Parent 1 | ... | Parent N | - -
+------------------+ +------------------+
||| .
One or ||| .
Multiple ||| .
Energy ||| .
Object ||| .
Relationship(s): |||
- Aggregation ||| +-----------------------+
- Metering |||------| EO Child 1 |
- Power Source || +-----------------------+
- Proxy ||
- Dependency || +-----------------------+
||-------| EO Child 2 |
| +-----------------------+
|
|
|-------- ...
|
|
| +-----------------------+
|--------| EO Child M |
+-----------------------+
Figure 2: Complex Energy Management Model
While both the simple and complex Energy Management models
contain an EnMS, this framework doesn't impose any requirements
regarding a topology with a centralize EnMS or one with a
distributed Energy Management via the Energy Objects within the
deployment.
<Claise, et. Al> Expires April 30, 2012 [Page 11]
Internet-Draft <EMAN Framework> Oct 2011
Given the pattern in figure 2, the complex relationships between
Energy Objects can be modeled (refer also to section 5.3):
- A PoE device modeled as an Energy Object Parent with the
Power Source, Metering, and Proxy Relationships for this
Energy Object Child
- A PDU modeled as an Energy Object Parent with the Power
Source and Metering Relationships for the plugged in
host (the Energy Object Children)
- A PC with line cards modeled as an Energy Object Parent
with Dependency Relationships for the line cards (the
Energy Object Children)
- Building management gateway, used as proxy for non IP
protocols, is modeled as an Energy Object Parent with
the Proxy Relationship, and potentially the Aggregation
Relationship
- Etc.
The communication between the Energy Object Parent and Energy
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 Object Identification and Context - for modeling and
planning
- Energy Monitoring - for energy measurements
- Energy Control - for optimization
- Energy Procurement - for optimization of resources
While an EnMS may be a central point for corporate reporting,
cost, environmental impact, and regulatory compliance, Energy
Management in this framework excludes Energy procurement and the
environmental impact of energy use. As such the framework does
not include:
- Manufacturing costs of an Energy Object in currency or
environmental units
- Embedded carbon or environmental equivalences of an Energy
Object
- Cost in currency or environmental impact to dismantle or
recycle an Energy Object
- Relationship or capabilities of an Energy Object to an
electrical or smart grid
- Supply chain analysis of energy sources or Energy Object
deployment
<Claise, et. Al> Expires April 30, 2012 [Page 12]
Internet-Draft <EMAN Framework> Oct 2011
- Conversion of the usage or production of energy to units
expressed from the source of that energy (such as the greenhouse
gas emissions associated with 1000kW from a diesel source).
The next sections describe Energy Management organized into the
following areas:
- Energy Object and Energy Management Domain
- Energy Object Identification and Context
- Energy Object Relationships
- Energy Monitoring
- Energy Control
- Deployment Topologies
5.1. Energy Object and Energy Management Domain
In building management, a meter refers to the meter provided by
the utility used for billing and measuring power to an entire
building or unit within a building. A sub-meter refers to a
customer or user installed meter that is not used by the utility
to bill but instead used to get readings from sub portions of a
building.
An Energy Management Domain should map 1-1 with a metered or
sub-metered portion of the site. An Energy Object is part of a
single Energy Management Domain. The Energy Management Domain
should be configured on an Energy Object. An Energy Object
Child may inherit the domain value from an Energy Object Parent
or the Energy Management Domain may be configured directly in an
Energy Object Child.
5.2. Energy Object Identification and Context
5.2.1 Energy Object Identification
Energy Objects MUST contain a value that uniquely identifies the
Energy Object among all the Energy Management Domains within an
EnMS. A universal identifier (UUID) [RFC4122] MUST be used to
uniquely identify an Energy Object.
Every Energy 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
<Claise, et. Al> Expires April 30, 2012 [Page 13]
Internet-Draft <EMAN Framework> Oct 2011
identifying the Energy Object. As an example, in the case of IP
phones, the Energy 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 Objects, each Energy Object optionally contains
information establishing its business, site, or organizational
context within a deployment, i.e. the Energy Object Context.
5.2.3 Context: Importance
An Energy 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 EnMS and administrators can establish their own
ranking, the following is a broad recommendation:
. 90 to 100 Emergency response
. 80 to 90 Executive or business-critical
. 70 to 79 General or Average
. 60 to 69 Staff or support
. 40 to 59 Public or guest
. 1 to 39 Decorative or hospitality
<Claise, et. Al> Expires April 30, 2012 [Page 14]
Internet-Draft <EMAN Framework> Oct 2011
5.2.4 Context: Keywords
An Energy Object can provide a set of keywords. These keywords
are a list of tags that can be used for grouping 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
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
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 Object 1, keywords: gangA
<Claise, et. Al> Expires April 30, 2012 [Page 15]
Internet-Draft <EMAN Framework> Oct 2011
Outlet 2 Energy Object 2, keywords: gangA
Outlet 3 Energy Object 3, keywords: gangA, gangB
Outlet 4 Energy 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 Object can provide a "role description" string that
indicates the purpose the Energy Object serves in the EnMS.
This could be a string describing the context the device
fulfills in deployment.
Administrators can define any naming scheme for the role of a
device. As guidance a two-word role that combines the service
the device provides along with type can be used [IPENERGY]
Example types of devices: Router, Switch, Light, Phone,
WorkStation, Server, Display, Kiosk, HVAC.
Example Services by Line of Business:
Line of Business Service
Education Student, Faculty, Administration,
Athletic
Finance Trader, Teller, Fulfillment
Manufacturing Assembly, Control, Shipping
Retail Advertising, Cashier
Support Helpdesk, Management
Medical Patient, Administration, Billing
<Claise, et. Al> Expires April 30, 2012 [Page 16]
Internet-Draft <EMAN Framework> Oct 2011
Role as a two-word string: "Faculty Desktop", "Teller Phone",
"Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
"Administration Switch".
5.3. Energy Object Relationships
Two Energy Objects MAY establish an Energy Object Relationship.
Within a relationship one Energy Object becomes an Energy Object
Parent while the other becomes an Energy Object Child. .
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 Object Parent is the switch, and the Energy Object Child
is the device attached to the switch.
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.
The Energy Object Child MUST keep track of its Energy Object
Parent(s) along with the Energy Object Relationships type. The
Energy Object Parent MUST keep track of its Energy Object
Child(ren).
While the Energy Object Relationships provide the different
topologies information to all the EnMS in a consistent way,
their implementation is optional.
5.3.1 Energy Object Children Discovery
There are multiple ways that the Energy Object Parent can
discover its Energy Object Children, if they are not present on
the same physical network:
. In case of PoE, the Energy Object Parent automatically
discovers an Energy Object Child when the Child requests
power.
. The Energy Object Parent and Children may run the Link
Layer Discovery Protocol [LLDP], or any other discovery
<Claise, et. Al> Expires April 30, 2012 [Page 17]
Internet-Draft <EMAN Framework> Oct 2011
protocol, such as Cisco Discovery Protocol (CDP). The
Energy Object Parent might even support the LLDP-MED MIB
[LLDP-MED-MIB], which returns extra information on the
Energy Object Children.
. The Energy Object Parent may reside on a network connected
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 Object Parent/Energy Object Child relationships may
be set by manual or automatic network configuration
functions.
Note that the communication specifications between the Energy
Object Parent and Children is out of the scope of this document.
When an Energy Object Parent is a Proxy, the Energy Object
Parent should enumerate the capabilities it is providing for the
Energy Object Child. The child would express that it wants its
parent to proxy capabilities such as, energy 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 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.
Each Energy Object will have information that describes Power
information along with how that measurement was obtained or
derived. For Energy Objects that can report actual Power
readings an optional Energy measurement can be provided.
Optionally, an Energy Object can further describe the Power
information with Power Quality information reflecting the
electrical characteristics of the measurement.
Optionally, an Energy Object that can report actual Power
readings can have odometers that provide the Energy used,
produced, and net Energy in Kwh. These values are odometers
that accumulate the Power readings. If Energy values are
returned then the three odometers must be provided along a
description of accuracy.
<Claise, et. Al> Expires April 30, 2012 [Page 18]
Internet-Draft <EMAN Framework> Oct 2011
Optionally, an Energy Object can provide Demand information over
time
5.4.1 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 Object should describe how it intends to
measure Power as one of consumer, producer or meter of usage.
Given the intent readings can be summarized or analyzed by an
EnMS. For example metered usage reported by a meter and
consumption usage reported by a device connected to that meter
may naturally measure the same usage. With the two measurements
identified by intent a proper summarization can be made by an
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 Object is 3, it
could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of the
scaling factor. Energy is often billed in kilowatt-hours
instead of megajoules from the SI units. Similarly, battery
charge is often measured as miliamperes-hour (mAh) instead of
coulombs from the SI units. The units used in this framework
are: W, A, Wh, Ah, V. A conversion from Wh to Joule and from Ah
to Coulombs is obviously possible, and can be described if
required.
In addition to knowing the usage and magnitude, it is useful to
know how an Energy Object usage measurement was obtained:
. Whether the measurements were made at the device itself or
from a remote source.
. Description of the method that was used to measure the power
and whether this method can distinguish actual or estimated
values.
An EMS can use this information to account for the accuracy and
nature of the reading between different implementations.
<Claise, et. Al> Expires April 30, 2012 [Page 19]
Internet-Draft <EMAN Framework> Oct 2011
The EMS can use the Nameplate Power for provisioning, capacity
planning and potentially billing.
5.4.2 Optional Power Quality
Given a Power measurement, it may in certain circumstances be
desirable to know the Power Quality associated with that
measurement. The information model must adhere to the IEC 61850
7-2 standard for describing AC measurements. Note that the
Power Quality include two sets of characteristics:
characteristics as received from the utility, and
characteristics depending on how the Power is used.
In some Energy Management Domains, the power quality may not be
needed, available, or relevant to the 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 Object, and not when the power measurement is assumed or
predicted.
Optional Battery
Some Energy Objects may use batteries for storing Energy and for
receiving power supply. These Energy Objects should report
their current power supply (battery, power line, etc.) and the
battery status for each contained battery. Battery-specific
information to be reported should include the number of
batteries contained in the device and per battery
. battery type
. nominal and remaining capacity
. current charge
. current state (charging, discharging, not in use, etc.)
. number of charging cycles
<Claise, et. Al> Expires April 30, 2012 [Page 20]
Internet-Draft <EMAN Framework> Oct 2011
. 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 Objects can be controlled by setting it to a Power State.
Power States Sets can be seen as an interface by which an Energy
Object can be controlled. Each Energy Object should indicate
the Power State Sets that it implements. Well known Power State
Sets should be registered with IANA
When and individual Power State is configured from a specific
Power State Set, an Energy Object may be busy at the request
time. The Energy Object will set the desired state and then
update the actual Power State when the priority task is
finished. This mechanism implies two different Power State
variables: actual versus desired
There are several standards and implementations of Power State
Set. An Energy 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 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 April 30, 2012 [Page 21]
Internet-Draft <EMAN Framework> Oct 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
<Claise, et. Al> Expires April 30, 2012 [Page 22]
Internet-Draft <EMAN Framework> Oct 2011
Figure 3: DMTF / ACPI Power State Mapping
5.5.3 EMAN Power State Set
The EMAN Power State Set 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 Object
features are available. The Energy Object is unavailable. No
energy is being consumed and the power connector can be removed.
This corresponds to ACPI state G3.
softoff(2) : Similar to mechoff(1), but some components
remain powered or receive trace power so that the Energy Object
can be awakened from its off state. In softoff(2), no context
is saved and the device typically requires a complete boot when
awakened. This corresponds to ACPI state G2.
IEEE1621 Power(sleep)
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
<Claise, et. Al> Expires April 30, 2012 [Page 23]
Internet-Draft <EMAN Framework> Oct 2011
example for state hibernate(3) is a save to-disk state where
DRAM context is not maintained. Typically, energy consumption
is zero or close to zero. This corresponds to state G1, S4 in
ACPI.
sleep(4) : No Energy Object features are available,
except for out-of-band management, 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 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 Object features are available,
except for out-of-band management, for example wake-up
mechanisms. This mode is analogous to hot-standby. The Energy
Object can be quickly transitioned into an operational state.
For example, processors are not executing, but processor context
is maintained. This corresponds to state G1, S1 in ACPI.
IEEE1621 Power(on):
lowMinus(7) : Indicates some Energy Object features may
not be available and the Energy Object has selected
measures/options to provide less than low(8) usage. This
corresponds to ACPI State G0. This includes operational states
lowMinus(7) to full(12).
low(8) : Indicates some features may not be
available and the Energy Object has taken measures or selected
options to provideless than mediumMinus(9) usage.
mediumMinus(9): Indicates all Energy Object features
are available but the Energy Object has taken measures or
selected options to provide less than medium(10) usage.
medium(10) : Indicates all Energy Object features are
available but the Energy Object has taken measures or selected
options to provide less than highMinus(11) usage.
<Claise, et. Al> Expires April 30, 2012 [Page 24]
Internet-Draft <EMAN Framework> Oct 2011
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.
6. Structure of the Information Model: UML Representation
The following basic UML represents an information model
expression of the concepts in this framework. This information
model, provided as a reference for implementers, is represented
as 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
EDITOR'S NOTE: the first part of the UML must be aligned with
the latest [EMAN-AWARE-MIB] document version.
EO 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 |
+---------------------------+ +----------------------------+
| |
| |
| |
<Claise, et. Al> Expires April 30, 2012 [Page 25]
Internet-Draft <EMAN Framework> Oct 2011
v v
+-----------------------------------------+
| Energy Object Information |
|-----------------------------------------|
| index : int |
| energyObjectId | UUID |
| name : string |
| meterDomainName | string |
| alternateKey | string |
+-----------------------------------------+
^
|
|
|
+-------------------------+
| Links Object |
|-------------------------|
| physicalEntity : int |
| ethPortIndex : int |
| ethPortGrpIndex : int |
| lldpPortNumber : int |
+-------------------------+
EO AND MEASUREMENTS
+-----------------------------------------------+
| Energy Object |
|-----------------------------------------------|
| nameplate : Measurement |
| battery[0..n]: Battery |
| measurements[0..n]: Measurement |
| --------------------------------------------- |
| Measurement instantaneousUsage() |
| DemandMeasurement historicalUsage() |
+-----------------------------------------------+
+-----------------------------------+
| Measurements |
| __________________________________|
+-----------------------------------+
^
|
|
+------------------+----------------------------+
| PowerMeasurement |
<Claise, et. Al> Expires April 30, 2012 [Page 26]
Internet-Draft <EMAN Framework> Oct 2011
|-----------------------------------------------|
| value : long |
| rate : enum {0,millisecond,seconds, |
| minutes,hours,...} |
| multiplier : enum {-24..24} |
| units : "watts" |
| caliber : enum { actual, estimated, |
| trusted, assumed...} |
| accuracy : enum { 0..10000} |
| current : enum {AC, DC} |
| origin : enum { self, remote } |
| time : timestamp |
| quality : PowerQuality |
+-----------------------------------------------+
|
|
+------------------+----------------------------+
| EnergyMeasurement |
|-----------------------------------------------|
| consumed : long |
| generated : long |
| net : long |
| accuracy : enum { 0..10000} |
+-----------------------------------------------+
+-----------------------------------------------+
| TimeMeasurement |
|-----------------------------------------------|
| startTime : timestamp |
| usage : Measurement |
| maxUsage : Measurement |
+-----------------------------------------------+
|
|
+----------------------------------------+
| TimeInterval |
|--------------------------------------- |
|value : long |
|units : enum { seconds, miliseconds..} |
+----------------------------------------+
|
|
+----------------------------------------+
| DemandMeasurement |
|----------------------------------------|
|intervalLength : TimeInterval |
|intervalNumbers: long |
<Claise, et. Al> Expires April 30, 2012 [Page 27]
Internet-Draft <EMAN Framework> Oct 2011
|intervalMode : enum { period, sliding, |
|total } |
|intervalWindow : TimeInterval |
|sampleRate : TimeInterval |
|status : enum {active, inactive } |
|measurements : TimedMeasurement[] |
+----------------------------------------+
QUALITY
+----------------------------------------+
| PowerQuality |
|----------------------------------------|
| |
+----------------------------------------+
^
|
|
+------------------+--------------------+
| ACQuality |
|---------------------------------------|
| acConfiguration : enum {SNGL, DEL,WYE}|
| avgVoltage : long |
| avgCurrent : long |
| frequency : long |
| unitMultiplier : int |
| accuracy : int |
| totalActivePower : long |
| totalReactivePower : long |
| totalApparentPower : long |
| totalPowerFactor : long |
+---------+-----------------------------+
| 1
|
|
|
| +------------------------------------+
| | ACPhase |
| * |------------------------------------|
+--------+ phaseIndex : long |
| avgCurrent : long |
| activePower : long |
| reactivePower : long |
| apparentPower : long |
| powerFactor : long |
+------------------------------------+
<Claise, et. Al> Expires April 30, 2012 [Page 28]
Internet-Draft <EMAN Framework> Oct 2011
^ ^
| |
| |
| |
| |
+-------------------------------+---+ |
| DelPhase | |
|-----------------------------------| |
|phaseToNextPhaseVoltage : long | |
|thdVoltage : long | |
|thdCurrent : long | |
+-----------------------------------+ |
|
+------------------+-----------+
| WYEPhase |
|------------------------------|
|phaseToNeutralVoltage : long |
|thdCurrent : long |
|thdVoltage : long |
+------------------------------+
EO & STATES
+----------------------------------------------+
| Energy Object |
|----------------------------------------------|
| currentLevel : int |
| configuredLevel : int |
| configuredTime : timestamp |
| reason: string |
| emanLevels[0..11] : State |
| levelMappings[0..n] : LevelMapping |
+----------------------------------------------+
+-------------------------------+
| State |
|-------------------------------|
| name : string |
| cardinality : int |
| maxUsage : Measurement |
+-------------------------------+
<Claise, et. Al> Expires April 30, 2012 [Page 29]
Internet-Draft <EMAN Framework> Oct 2011
Figure 8: Information Model UML Representation
7. Configuration
This power management framework allows the configuration of the
following key parameters:
. Energy Object name: A unique printable name for the Energy
Object.
. Energy Object role: An administratively assigned name to
indicate the purpose an Energy Object serves in the
network.
. Energy Object importance: A ranking of how important the
Energy Object is, on a scale of 1 to 100, compared with
other Energy Objects in the same Energy Management Domain.
. Energy Object keywords: A list of keywords that can be used
to group Energy Objects for reporting or searching.
. Energy Management Domain: Specifies the name of an Energy
Management Domain for the Energy Object.
. Energy Object Power State: Specifies the current Power
State (0..12) for the Energy Object.
. Demand parameters: For example, which interval length to
report the Deman over, the number of intervals to keep,
etc.
. Assigning an Energy Object Parent to an Energy Object Child
. Assigning an Energy Object Child to an Energy Object
Parent.
This framework supports multiple means for setting the Power
State of a specific Energy Object. However, the Energy Object
might be busy executing an important task that requires the
current Power State for some more time. For example, a PC might
have to finish a backup first, or an IP phone might be busy with
a current phone call. Therefore a second value contains the
actual Power State. A difference in values between the two
objects indicates that the Energy Object is currently in Power
State transition.
Other, already well established means for setting Power States,
such as DASH [DASH], already exist. Such a protocol may be
implemented between the Energy Object Parent and the Energy
Object Child, when the Energy Object Parent acts as a Proxy.
<Claise, et. Al> Expires April 30, 2012 [Page 30]
Internet-Draft <EMAN Framework> Oct 2011
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
notification is generated when the value(s) of Power State has
changed for the Energy Object.
Regarding high and low thresholding mechanism, the RMON alarm
and event [RFC2819] allows to periodically takes statistical
samples from Energy Object variables, compares them to
previously configured thresholds, and to generate an event (i.e.
an SNMP notification) if the monitored variable crosses a
threshold. The RMON alarm can monitor variables that resolve to
an ASN.1 primitive type of INTEGER (INTEGER, Integer32,
Counter32, Counter64, Gauge32, or TimeTicks), so basically most
the variables in [EMAN-MON-MIB].
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 Object usage
magnitude, conforms to the IEC 61850 definition of unit
multiplier for the SI (System International) units of
measure.
. The electrical characteristic is based on the ANSI and IEC
Standards, which require that we use an accuracy class for
power measurement. ANSI and IEC define the following
accuracy classes for power measurement:
<Claise, et. Al> Expires April 30, 2012 [Page 31]
Internet-Draft <EMAN Framework> Oct 2011
. 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.
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 Object may result in misreporting or
interruption of power.
. Unauthorized changes to a power state may disrupt the power
settings of the different Energy Objects, and therefore the
state of functionality of the respective Energy Objects.
. Unauthorized changes to the demand history may disrupt
proper accounting of energy usage.
With respect to data transport SNMP versions prior to SNMPv3 did
not include adequate security. Even if the network itself is
<Claise, et. Al> Expires April 30, 2012 [Page 32]
Internet-Draft <EMAN Framework> Oct 2011
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.
11. IANA Considerations
Initial values for the Power State Sets, together with the
considerations for assigning them, are defined in [EMAN-MON-
MIB].
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.
[RFC2819] S. Waldbusser, "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000
<Claise, et. Al> Expires April 30, 2012 [Page 33]
Internet-Draft <EMAN Framework> Oct 2011
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework ", RFC 3410, December
2002.
[RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005
Informative References
[RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
between Information Models and Data Models", RFC 3444,
January 2003.
[RFC5101] B. Claise, Ed., Specification of the IP Flow
Information Export (IPFIX) Protocol for the Exchange of
IP Traffic Flow Information, RFC 5101, January 2008.
[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm
[IEEE1621] "Standard for User Interface Elements in Power
Control of Electronic Devices Employed in
Office/Consumer Environments", IEEE 1621, December
2004.
[LLDP] IEEE Std 802.1AB, "Station and Media Control
Connectivity Discovery", 2005.
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information
Base extension module for TIA-TR41.4 media endpoint
discovery information", July 2005.
[EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
M. Chandramouli, "Requirements for Energy Management",
draft-ietf-eman-requirements-04, (work in progress),
July 2010.
[EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
Networks and Devices MIB", draft-ietf-eman-energy-
aware-mib-02, (work in progress), July 2011.
[EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
Dietz, T., and B. Claise, "Power and Energy Monitoring
<Claise, et. Al> Expires April 30, 2012 [Page 34]
Internet-Draft <EMAN Framework> Oct 2011
MIB", draft-ietf-eman-energy-monitoring-mib-00, (work
in progress), August 2011.
[EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
Definition of Managed Objects for Battery Monitoring",
draft-ietf-eman-battery-mib-03, (work in progress),
August 2011.
[EMAN-AS] Tychon, E., Schoening, B., Chandramouli, M., and B.
Nordman, "Energy Management (EMAN) Applicability
Statement", draft-tychon-eman-applicability-statement-
04, (work in progress), October 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
[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.
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.
<Claise, et. Al> Expires April 30, 2012 [Page 35]
Internet-Draft <EMAN Framework> Oct 2011
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 April 30, 2012 [Page 36]