Network Working Group B. Claise
Internet-Draft J. Parello
Intended Status: Informational B. Schoening
Expires: March 17, 2011 Cisco Systems, Inc.
September 17, 2010
Power Management Architecture
draft-claise-power-management-arch-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on September, 2010.
<Claise, et. Al> Expires March 17 2011 [Page 1]
Internet-Draft <Power Management Archictecure> Sept 2010
Copyright Notice
Copyright (c) 2010 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 the power management architecture.
Conventions used in this document
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].
<Claise, et. Al> Expires March 17, 2011 [Page 2]
Internet-Draft <Power Management Archictecure> Sept 2010
Table of Contents
1. Introduction............................................... 4
2. Uses Cases & Requirements.................................. 5
3. Terminology................................................ 5
4. Architecture High Level Concepts and Scope................. 6
4.1. Power Monitor Information............................. 8
4.2. Power Monitor Meter Domain............................ 8
4.3. Power Monitor Parent and Child........................ 9
4.4. Power Monitor Context................................ 10
4.5. Power Monitor Levels................................. 11
4.6. Power Monitor Usage Measurement...................... 13
4.7. Optional Power Usage Quality......................... 14
4.8. Optional Energy Measurement.......................... 14
4.9. Optional Battery Information......................... 15
5. Power Monitor Children Discovery.......................... 15
6. Configuration............................................. 16
7. Fault Management.......................................... 16
8. Relationship with Other Standard Development
Organizations................................................ 17
8.1. Information Modeling................................. 17
8.2. Power Levels......................................... 17
9. Implementation Scenarios.................................. 18
Scenario 1: Switch with PoE endpoints..................... 18
Scenario 2: Switch with PoE endpoints with further connected
device(s)................................................. 18
Scenario 3: A switch with Wireless Access Points.......... 18
Scenario 4: Network connected facilities gateway.......... 19
Scenario 5: Data Center Network........................... 19
Scenario 6: Building Gateway Device....................... 19
Scenario 7: Power Consumption of UPS...................... 19
Scenario 8: Power Consumption of Battery-based Devices.... 20
10. Security Considerations.................................. 20
11. IANA Considerations...................................... 20
12. References............................................... 20
Normative References...................................... 20
Informative References.................................... 20
13. Authors' Addresses....................................... 21
TO DO:
. Since we have the notion of desired versus actual Power
Level, we must deal with the notion of transition state:
<Claise, et. Al> Expires March 17, 2011 [Page 3]
Internet-Draft <Power Management Archictecure> Sept 2010
Gracefully versus hard way. Note: the transition states are
apparently described in the DMTF model.
. In terms of other SDOs, discuss DMTF?
. Do we need the pmIndex persistence?
. Security Considerations to be done
1. Introduction
Network management is typically divided into areas of concerns
according to the ISO Telecommunications Management Network
model. The model defines Fault, Configuration, Accounting,
Performance, and Security Management. Notably missing is an
area of concern specifically covering energy management at an
equal level to these areas.
With energy becoming a more critical area of concern, this
document defines an architecture for power management for use
with devices in and connected to communication networks. This
architecture includes monitoring for power state and energy
consumption of networked elements, taking into account the
requirements specified in [POWER-MON-REQ]. However, this
architecture goes one step further, as it includes some elements
of elements of configuration.
Energy management is applicable to devices that comprise and
that are connected to a communication network. Target devices
for this specification include (but are not limited to):
routers, switches, Power over Ethernet (PoE) endpoints, protocol
gateways for building management systems, intelligent meters,
home energy gateway, hosts and servers, sensor proxy, etc.
Where applicable, monitoring of a device is extended to the
individual components of the device and/or to any attached
dependent device(s). An example of such a case could be when a
device contains components that are independent from a power
state point of view (such as line cards, processor cards, hard
drives) or when a devices has dependent attached devices (such
as a switch with PoE endpoints or a power distribution unit with
attached endpoints).
<Claise, et. Al> Expires March 17, 2011 [Page 4]
Internet-Draft <Power Management Archictecure> Sept 2010
2. Uses Cases & Requirements
The requirements for power and energy monitoring for networking
devices are specified in [POWER-MON-REQ]. The requirements in
[POWER-MON-REQ] cover devices that typically make up a
communications network such as switches, routers, and various
connected endpoints. For power monitoring to be useful, a
specification should also be applicable to facility meters,
power distribution units, gateway proxies for commercial
building control, home automation devices and devices that
interface with the utility and/or smart grid. Due to this fact,
the scope of this architecture is broader than that specified in
[POWER-MON-REQ]. Several scenarios that cover these broader use
cases are presented later in Section 9. - Implementation
Scenarios.
3. Terminology
This section contains definitions of major terms used in
explaining the concepts, examples, and the MIB definitions.
Power Monitor
A Power Monitor is a system of one or more components that
provide power, draws power, or reports energy consumption on
behalf of another Power Monitor. It can be independently
managed from a power monitoring and power state configuration
point of view. Examples of Power Monitors are: a router line
card, a motherboard with a CPU, an IP phone connected with a
switch, etc.
Power Monitor Parent
A Power Monitor Parent is a Power Monitor that is the root of
one or multiple subtending Power Monitors, called Power Monitor
Children. The Power Monitor Parent is able to report the power
state and energy consumption for his Power Monitor Child(ren).
For example, in case of Power-over-Ethernet (PoE) device such as
an IP phone or an access point attached to a switch port, the
switch is the source of power for the attached device. In such
a case, the Power Monitor Parent is the port of the switch,
while the attached device is the Power Monitor Child.
Power Monitor Child
<Claise, et. Al> Expires March 17, 2011 [Page 5]
Internet-Draft <Power Management Archictecure> Sept 2010
A Power Monitor Child is a Power Monitor associated to a Power
Monitor Parent, which draws power from its Power Monitor Parent
or reports its power usage and power state to its Power Monitor
Parent.
Power Monitor Meter Domain
A Power Monitor Meter Domain is a name or name space that
logically groups together Power Monitors that comprises a zone
of manageable power usage. Typically, this will comprise all
Power Monitors that are powered from the same electrical panel
or panels for which there is a meter or sub meter. For example,
all Power Monitors receiving power from the same distribution
panel of a building, or all Power Monitors in a building for
which there is one main meter. From the point of monitoring
power use, it is useful to report the total power usage as the
sum of power consumed by all the Power Monitors within a Power
Monitor Meter Domain and then correlate that value to the
metered usage.
Power Level
A uniform way to classify power settings on a Power Monitor
(e.g., shut, hibernate, sleep, high). Power Levels can be
viewed as an interface for interacting with the underlying
device implemented power settings.
Manufacturer Power Level
A device specific way to classify power settings implemented on
a Power Monitor. For cases where the implemented power setting
cannot be directly mapped to a Power Level(s), the Manufacturer
Power Levels are used to enumerate and show the relationship
between the implemented power settings and the Power Level
interface.
4. Architecture High Level Concepts and Scope
The scope of this architecture is to enable networking and
network attached devices to be managed with respect to their
energy consumption or production. The goal is to make devices
energy aware.
<Claise, et. Al> Expires March 17, 2011 [Page 6]
Internet-Draft <Power Management Archictecure> Sept 2010
The architecture describes how to make a device aware of its
consumption or production of energy expressed as usage in watts.
This does not include:
- Manufacturing costs in currency or environmental units
- Embedded carbon or environmental equivalences of the device
itself
- Cost in currency or environmental impact to dismantle or
recycle the device
- Relationship to an electrical or smart grid
- Supply chain analysis
- Conversion of the usage or production of energy to units
expressed from the source of that energy - for example the
greenhouse gas emissions associated with 1000kW from a diesel
source.
This remainder of this section will go over the basic concepts
of the architecture. Each concept is then listed with notable
descriptions in subsequent sections.
Examples will be provided in a later section to show how these
concepts can be fulfilled in an implementation.
Given a Power Monitor, we can describe the information about the
Power Monitor through various data. A Power Monitor will have
basic naming and informational descriptors to identify it in the
network.
A Power Monitor can be part of a Power Monitor Meter Domain. A
Power Monitor Meter 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.
A Power Monitor can be a parent (Power Monitor Parent) or child
(Power Monitor Child) of another Power Monitor. This allows for
devices to aggregate reporting and/or control of power
information.
Each Power Monitor can have information to allow it to be
described in the context of the business or ultimate use. This
is in addition to its networked information. This allows for
tagging, grouping and differentiation between Power Monitors for
NMS.
For control and universal monitoring each Power Monitor will
implement or declare a set of known Power Levels. The Power
Levels can be mapped to Manufacturer Power Levels that indicate
the specific power setting for the device implementing the Power
<Claise, et. Al> Expires March 17, 2011 [Page 7]
Internet-Draft <Power Management Archictecure> Sept 2010
Monitor, in case that Power Monitor doesn't implement yet the
standard Power Levels [POWER-MON-MIB].
The desired Power Level variable is set, when setting the Power
Level. If the Power Monitor is busy at the request time, it
might update the actual Power Level when his priority task is
finished. This mechanism implies two different Power Level
variables: actual versus desired.
EDITOR'S NOTE: the transition state will have to be specified.
Each Power Monitor will have usage information that describes
the power information along with how that usage was obtained or
derived.
Optionally a Power Monitor can further describe the power
information with power quality information reflecting the
electrical characteristics of the measurement.
Optionally a Power Monitor can provide power usage over time to
describe energy consumption
If a Power Monitor has one or more batteries, it can provide
optional Battery information as well.
4.1. Power Monitor Information
Every Power Monitor SHOULD have a unique printable name, and
MUST have a unique Power Monitor index.
Possible naming conventions are: textual DNS name, MAC-address
of the device, interface ifName, or a text string uniquely
identifying the Power Monitor. As an example, in the case of IP
phones, the Power Monitor name can be the device DNS name.
4.2. Power Monitor Meter Domain
Each Power Monitor MUST be a member of a Power Monitor Meter
Domain. The Power Monitor Meter Domain SHOULD map 1-1 with a
metered or sub-metered portion of the site. The Power Monitor
Meter Domain MUST be configured on the Power Monitor Parent.
The Power Monitor Children MAY inherit its domain value from the
Power Monitor Parent or the Power Monitor Meter Domain MAY be
configured directly in Power Monitor Child.
<Claise, et. Al> Expires March 17, 2011 [Page 8]
Internet-Draft <Power Management Archictecure> Sept 2010
4.3. Power Monitor Parent and Child
A Power Monitor can be connected to another Power Monitor and
either draw power from that entity or report power usage to that
entity.
A Power Monitor Child can be fully dependent on the Power
Monitor Parent (as in the case of Power Over Ethernet) or
independent from the parent (such as a PC connected to a
switch). In the dependent case, the Power Monitor Parent
provides power for the Power Monitor Child (the PoE case). In
the independent case, the Power Monitor Child draws power from
another source (typically a wall outlet). Since the Power
Monitor Parent is not the source of power supply, the power
usage cannot be measured at the Power Monitor Parent. However,
an independent Power Monitor Child may report Power Monitor
information to the Power Monitor Parent. The Power Monitor
Child may listen to the power control settings from a Power
Monitor Parent and could react to the control messages. Note
that the communication between the Power Monitor Parent and
Power Monitor Child is out of scope of this document.
A Power Monitor cannot be at the same time a Power Monitor
Parent and a Power Monitor Child. Indeed such configuration
would lead to double counting the energy consumed within a
specific Power Monitor Domain.
A mechanism, outside of the scope of this document, should be in
place to verify the connectivity between the Power Monitor
Parent and its Power Monitor Children. If the Power Monitor
Child is unavailable, the Power Monitor Parent must follow some
rules to determine how long it should wait before removing the
Power Monitor Child entry, along with all associated statistics,
from his database. In some situations, such as connected
building, in which the Power Monitor Children are pretty static,
this removal timer might be pretty long. The persistence across
a Power Monitor Parent reload could even make sense. However,
in a networking environment, where endpoints could come and go,
there is not much sense to configure a long removal timer. In
all cases, the removal timer or persistence must be clearly
specified.
Further examples of Power Monitor Parent and Child
implementations are provided in the Implementation Scenarios
section.
<Claise, et. Al> Expires March 17, 2011 [Page 9]
Internet-Draft <Power Management Archictecure> Sept 2010
4.4. Power Monitor Context
Monitored power will ultimately be collected to and reported
from a NMS. In order to aid in the reporting and
differentiation between Power Monitors, each Power Monitor will
contain information to establish a business or site context.
A Power Monitor can provide an importance value in the range of
1..100 to help differentiate the 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 the 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 network managers must 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
A Power Monitor 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 Power Monitor Meter 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 the 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".
Additionally, a Power Monitor can provide a "role description"
string that indicates the purpose the Power Monitor serves in
the network or to site/business. This could be a string
describing the context the device fulfils 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.
<Claise, et. Al> Expires March 17, 2011 [Page 10]
Internet-Draft <Power Management Archictecure> Sept 2010
4.5. Power Monitor Levels
Power Levels represent universal states of power management of a
Power Monitor. Each Power Level corresponds to a global,
system, and performance state in the ACPI model.
Level ACPI Global/System Name
State
Non-operational states:
1 G3, S5 Mech Off
2 G2, S5 Soft Off
3 G1, S4 Hibernate
4 G1, S3 Sleep
5 G1, S2 Standby
6 G1, S1 Ready
Operational states:
7 G0, S0, P5 LowMinus
8 G0, S0, P4 Low
9 G0, S0, P3 MediumMinus
10 G0, S0, P2 Medium
11 G0, S0, P1 HighMinus
12 G0, S0, P0 High
For example, a Power Monitor with a Power Level of 9 would
indicate an operational state with MediumMinus Power Level.
The Power Levels can be considered as guidelines for an
interface in order to promote interoperability across device
types. Realistically, it is foreseen that each specific feature
requiring Power Levels will require a complete recommendation of
its own. For example, designing IP phones with consistent Power
Levels across vendors requires a specification for IP phone
design, along with the Power Levels mapping.
In some situation, Manufacturer Power Levels are required, for
example, when no mappings with the existing Power Levels are
possible or when more levels than the twelve specified Power
Levels are required.
A first example would be an imaginary device type, with only
five levels: "none", "short", "tall", "grande", and "venti".
Manufacturer Power Level Respective Name
0 none
<Claise, et. Al> Expires March 17, 2011 [Page 11]
Internet-Draft <Power Management Archictecure> Sept 2010
1 short
2 tall
3 grande
4 venti
In the unlikely event of no possible mapping between these
Manufacturer Power Levels and the Power Levels, the Power Level
will remain 0 throughout the MIB module, as displayed below.
Power Level / Name Manufacturer Power Level / Name
0 / unknown 0 / none
0 / unknown 1 / short
0 / unknown 2 / tall
0 / unknown 3 / grande
0 / unknown 4 / venti
If a mapping between the Manufacturer Power Levels and the Power
Levels is achievable, both series of levels exist in the MIB
module, allowing the NMS to understand the mapping between them
by correlating the Power Level with the Manufacturer Power
Levels.
Power Level / Name Manufacturer Power Level / Name
1 / Mech Off 0 / none
2 / Soft Off 0 / none
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
How the Power Monitor Levels are then mapped, i.e. assigning the
directly lower or directly higher level, is an implementation
choice. However, its recommended that the Manufacturer Power
Levels l maps to the directly lower Power Level, so that setting
all Power Meters to a Power Level would be conservative in terms
of disabled functionality on the Power Monitor implementing the
Manufacturer Power Levels.
A second example would be a device type, such as a dimmer or a
motor, with a high number of operational levels. For the sake
of the example, 100 operational states are assumed.
<Claise, et. Al> Expires March 17, 2011 [Page 12]
Internet-Draft <Power Management Archictecure> Sept 2010
Power Level / Name Manufacturer Power Level / Name
1 / Mech Off 0 / off
2 / Soft Off 0 / off
3 / Hibernate 0 / off
4 / Sleep, Save-to-RAM 0 / off
5 / Standby 0 / off
6 / Ready 0 / off
7 / LowMinus 1 / 1%
7 / LowMinus 2 / 2%
7 / LowMinus 3 / 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%
. .
. .
. .
10 / Medium 45 / 45%
10 / Medium 46 / 46%
10 / Medium 47 / 47%
. .
. .
. .
etc...
4.6. Power Monitor Usage Measurement
For a Power Monitor, RMS (Root Mean Square) or RMS equivalent
(for example, after conversion to DC power) power usage must be
reported, including the magnitude of measurement, as multiple
scaling factors can be used.
The power usage measurement should conform to the IEC 61850
definition of unit multiplier for the SI (System International)
units of measure. The power usage measurement is considered an
instantaneous usage value and does not include the usage over
time.
Measured values are represented in SI units obtained by
BaseValue * 10 raised to the power of scale. For example, if
current power usage of a Power Monitor is 3, it could be 3 W, 3
<Claise, et. Al> Expires March 17, 2011 [Page 13]
Internet-Draft <Power Management Archictecure> Sept 2010
mW, 3 KW, 3 MW depending on the value of scaling factor (called
pmPowerUnitMultiplier in the MIB module).
In addition to knowing the usage and magnitude it is useful to
know how a Power Monitor 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 can distinguish actual or estimated values.
An NMS can use this information to account for the accuracy and
nature of the reading between different implementations.
In addition to the power usage the nameplate power rating of a
Power Monitor is typically specified by the vendor as the
capacity required to power the device. Often this label is a
conservative number and is the worst-case power draw. While the
actual utilization of an entity can be lower, the nameplate
power is important for provisioning, capacity planning and
billing.
4.7. Optional Power Usage Quality
Given a power measurement of a Power Monitor, 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 to describe AC measurements. In some
Power Monitor Domains, the power quality may not be needed,
available, nor relevant to the Power Monitor.
4.8. Optional Energy Measurement
In addition to reporting the Power Level, an approach to
characterize the energy demand is required. It is well known in
commercial electrical utility rates, that demand charges can be
on par with actual power charges. So, it is useful to
characterize the demand. The demand can be described as the
average energy of an Power Monitor over a time window, called a
demand interval, typically 15 minutes. The highest peak energy
demand measured over a time horizon, say 1 month or 1 year is
often the basis for usage charges. A single window of time of
high usage can penalize the energy consumption charges.
However, it is relevant to measure the demand only when there
are actual power measurements from a Power Monitor, and not when
the power measurement is assumed or predicted.
<Claise, et. Al> Expires March 17, 2011 [Page 14]
Internet-Draft <Power Management Archictecure> Sept 2010
Several efficiency metrics can be derived and tracked with the
demand usage data.
. For example, per-packet power costs for a networking device
(router or switch) can be calculated by an network
management system. The packets count can be determined
from the traffic usage in the ifTable [RFC2863] from the
forwarding plane figure, or from the platform
specifications.
. Watt-hour power can be combined with utility energy sources
to estimate carbon footprint and other emission statistics.
4.9. Optional Battery Information
Some Power Monitors might be running on batteries. Therefore
information such as the battery status (charging or
discharging), remaining capacity, etc... must be available.
5. Power Monitor Children Discovery
There are multiple ways that the Power Monitor Parent can
discover its Power Monitor Children, if not present on the same
physical network element.
. In case of PoE, the Power Monitor Parent automatically
discovers that a Power Monitor Child requests some power.
. The Power Monitor Parent and Children may run the Link
Layer Discovery Protocol [LLDP], or any proprietary similar
protocols such as Cisco Discovery Protocol (CDP). The
Power Monitor Parent might even support the LLDP-MED MIB
[LLDP-MED-MIB], which returns some extra information on the
Power Monitor Children.
. The Power Monitor Parent might reside on a network
connected facilities gateway. A typical example is a
converged building gateway, monitoring several other
devices in the building, doing the proxy between SNMP and a
protocol such as BACNET.
When a Power Monitor Child doesn't support the Power Levels, but
its own Manufacturer Power Levels, the Power Monitor Parent will
have to discover those Manufacturer Power Levels. Note that the
communication specifications between the Power Monitor Parent
and Children is out of the scope of this document. This
includes the Manufacturer Power Levels discovery, which is
protocol-specific.
<Claise, et. Al> Expires March 17, 2011 [Page 15]
Internet-Draft <Power Management Archictecure> Sept 2010
6. Configuration
This power management architecture allows the configuration of a
couple of key parameters:
. Power Monitor name: an unique printable name for the Power
Monitor.
. Power Monitor Role: an administratively assigned name to
indicate the purpose a Power Monitor serves in the network.
. Power Monitor Importance: a ranking of how important the
Power Monitor is on a scale of 1 to 100 compared to other
Power Monitors in the same Power Monitor Meter Domain.
. Power Monitor Keywords: a list of keywords that can be used
to group Power Monitors for reporting or searching.
. Power Monitor Domain: specifies the name of a Power Monitor
Meter Domain for the Power Monitor.
. The Power Monitor Level: specifies the current Power Level
(0..12) for the Power Monitor.
. Manufacturer Power Level and name
. The energy demand parameters: for example, which interval
length to report the energy on, the number of interval to
keep, etc...
Interactions with established open protocols such as Wake-up-on-
Lan (WoL) and DASH [DASH] may require configuration in the Power
Monitor as well, facilitating the communication between Power
Monitor Parent and remote Power Monitor Children.
Note that the communication specifications between the Power
Monitor Parent and Children is out of the scope of this
document. This includes the communication of the power settings
and configuration information such as the Power Monitor Domain.
7. Fault Management
[POWER-MON-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
pmPowerLevelChange NOTIFICATION-TYPE [POWER-MON-MIB]. This SNMP
notification is generated when the value(s) of Power Level has
changed for the Power Monitor.
<Claise, et. Al> Expires March 17, 2011 [Page 16]
Internet-Draft <Power Management Archictecure> Sept 2010
A push based mechanism such as IPFIX might be required to export
high volume time series of energy consumption values, as
mentioned in [POWER-MON-REQ].
8. Relationship with Other Standard Development Organizations
8.1. Information Modeling
This power management architecture should reuse as much as
possible existing standard efforts and not re-invent something
new, specifically in terms of information modeling and data
modeling [RFC3444].
The data model for power, energy related objects is based on the
IEC 61850.
Specific examples include:
. The scaling factor, which represent the magnitude of Power
Monitor usage, conforms to the IEC 61850 definition of unit
multiplier for the SI (System International) units of
measure.
. The power accuracy model 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 powerQualityMIB MIB module adheres closely to the IEC
61850 7-2 standard to describe AC measurements.
8.2. Power Levels
There are twelve Power Monitor Levels; divided into six
operational states, and six non-operational states. The lowest
non-operational state is 1 and the highest is six. Each non-
operational state corresponds to an ACPI level [ACPI].
<Claise, et. Al> Expires March 17, 2011 [Page 17]
Internet-Draft <Power Management Archictecure> Sept 2010
9. Implementation Scenarios
The scope of power and energy monitoring consists of devices
that consume power within and connected to a communications
network. These devices include:
- Network devices and sub-components: devices such as routers
and switches and their sub-components.
- Network attached endpoints: devices that use the
communications network such as endpoints, PCs, or facility
gateways that proxy energy monitor and control for commercial
buildings or home automation,
- Network attached meters or supplies: devices that can monitor
the electrical supply such as smart meters or Universal Power
Supplies (UPS) that meter and provide availability.
This section provides illustrative examples that model different
scenarios for implementation of the Power Monitor including
Power Monitor Parent and Power Monitor Child relationships.
Each of the scenarios below is explained in more details in the
Power Monitor MIB document [POWER-MON-MIB], with a mapping to
the MIB Objects.
Scenario 1: Switch with PoE endpoints
Consider a PoE IP phone connected to a switch, as displayed on
figure 1. The IP phone draws power from the PoE switch.
Scenario 2: Switch with PoE endpoints with further connected
device(s)
Consider the same scenario as example 1 with an IP phone
connected to PoE port of a switch. Now, in addition, a PC is
also daisy-chained from the IP phone for LAN connectivity. The
phone draws power from PoE port of the switch, while the PC
draws power from the wall outlet.
Scenario 3: A switch with Wireless Access Points
Consider a Wireless Access Point connected to the PoE port of a
switch. There are several PCs connected to the Wireless Access
Point over Wireless protocols. All PCs draw power from the wall
outlets.
<Claise, et. Al> Expires March 17, 2011 [Page 18]
Internet-Draft <Power Management Archictecure> Sept 2010
The switch port is the Power Monitor Parent for the Wireless
Access Point (WAP) and the PCs. There is a distinction, between
the Power Monitor Children, as the WAP draws power from the PoE
port of the switch and the PCs draw power from the wall outlet.
Scenario 4: Network connected facilities gateway
At the top of the network hierarchy of a building network is a
gateway device that can perform protocol conversion between many
facility management devices, such as BACNET, MODBUS, DALI, LON,
etc. There are power meters associated with power consuming
entities (Heating Ventilation & Air Conditioning - HVAC,
lighting, electrical, fire control, elevators, etc). The
proposed MIB can be implemented on the gateway device. The
gateway can be considered as the Power Monitor Parent, while the
power meters associated with the energy consuming entities such
can be considered as Power Monitor Children.
Scenario 5: Data Center Network
A typical data center network consists of a hierarchy of
switches. At the bottom of hierarchy there are servers mounted
on a rack, and those are connected to the top of the rack
switches. The top switches are connected to aggregation
switches that are in turn connected to core switches. As an
example, Server 1 and Server 2 are connected to different switch
ports of the top switch.
The proposed MIB can be implemented on the switches. The switch
can be considered as the Power Monitor Parent. The servers can
be considered as the Power Monitor Children.
Scenario 6: Building Gateway Device
Similar scenario as the scenario 4.
Scenario 7: Power Consumption of UPS
Data centers and commercial buildings can have Uninterruptible
Power Supplies (UPS) connected to the network. The Power Monitor
can be used to model a UPS as a Power Monitor Parent with the
connected devices as Power Monitor Children.
<Claise, et. Al> Expires March 17, 2011 [Page 19]
Internet-Draft <Power Management Archictecure> Sept 2010
Scenario 8: Power Consumption of Battery-based Devices
A PC is typical example of a battery-based device.
10. Security Considerations
TO DO
11. IANA Considerations
This document has no actions for IANA.
12. References
Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
and M. Chandramouli, "Requirements for Power
Monitoring", draft-quittek-power-monitoring-
requirements-01 (work in progress), July 2010.
[POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and
Schoening, B., "Power and Energy Monitoring MIB",
draft-claise-energy-monitoring-mib-04, (work in
progress), Sept 2010.
Informative References
[RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group
MIB", RFC 2863, June 2000.
[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
<Claise, et. Al> Expires March 17, 2011 [Page 20]
Internet-Draft <Power Management Archictecure> Sept 2010
[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.
[DASH] "Desktop and mobile Architecture for System Hardware",
http://www.dmtf.org/standards/mgmt/dash/
13. 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
Cisco Systems Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: braschoe@cisco.com
<Claise, et. Al> Expires March 17, 2011 [Page 21]