One document matched: draft-claise-power-management-arch-00.txt
Network Working Group
Internet-Draft B. Claise
Intended Status: Informational J. Parello
Expires: January 5, 2011 B. Schoening
Cisco Systems, Inc.
July 5, 2010
Power Management Architecture
draft-claise-power-management-arch-00
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 January 5 2011 [Page 1]
Internet-Draft <Power Management Archictecure> July 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 January 5, 2011 [Page 2]
Internet-Draft <Power Management Archictecure> July 2010
Table of Contents
1. Foreword....................................................4
2. Introduction................................................4
3. Use Cases & Requirements....................................5
4. Terminology.................................................5
5. Architecture High Level Concepts............................7
5.1. Power Monitor Information..............................8
5.2. Power Monitor Meter Domain.............................8
5.3. Power Monitor Parent and Child.........................8
5.4. Power Monitor Context.................................10
5.5. Power Monitor Levels..................................10
5.6. Power Monitor Usage Measurement.......................13
5.7. Optional Power Usage Quality..........................14
5.8. Optional Energy Measurement...........................14
5.9. Optional Battery Information..........................15
5.10. CO2 Emission.........................................15
6. Power Monitor Children Discovery...........................16
7. Configuration..............................................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...........19
Scenario 4: Network connected facilities gateway...........19
Scenario 5: Data Center Network............................19
Scenario 6: Power Consumption of UPS.......................19
Scenario 7: 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
<Claise, et. Al> Expires January 5, 2011 [Page 3]
Internet-Draft <Power Management Archictecure> July 2010
1. Foreword
This document stems from the fact that the Power and Energy
Monitoring MIB module [POWER-MON-MIB] contains elements of
architecture, which should be specified in a separate document
dedicated to the architecture concepts. Therefore, for the time
being, this document has a clear overlap with [POWER-MON-MIB].
It is foreseen that the IETF meeting in Maastricht will bring
consensus on the respective contents of the Power Monitoring
Requirements [POWER-MON-REQ], the Power Management Architecture
(this document), and the Power and Energy Monitoring MIB [POWER-
MON-MIB].
2. 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 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
<Claise, et. Al> Expires January 5, 2011 [Page 4]
Internet-Draft <Power Management Archictecure> July 2010
as a switch with PoE endpoints or a power distribution unit with
attached endpoints).
3. Use 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 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 the MIB modules in this document 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.
4. 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.
<Claise, et. Al> Expires January 5, 2011 [Page 5]
Internet-Draft <Power Management Archictecure> July 2010
Power Monitor Child
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.
User Defined 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 User Defined
Power Levels are used to enumerate and show the relationship
between the implemented power settings and the Power Level
interface.
<Claise, et. Al> Expires January 5, 2011 [Page 6]
Internet-Draft <Power Management Archictecure> July 2010
5. Architecture High Level Concepts
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 User Defined Power Levels that indicate
the specific power setting for the device implementing the Power
Monitor.
Each Power Monitor will have usage information that describes
the instantaneous power information along with how that usage
was obtained or derived.
Optionally a Power Monitor can further describe the
instantaneous 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
<Claise, et. Al> Expires January 5, 2011 [Page 7]
Internet-Draft <Power Management Archictecure> July 2010
If a Power Monitor has one or more batteries, it can provide
optional Battery information as well.
5.1. Power Monitor Information
Every Power Monitor should have a unique printable name, and 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.
5.2. Power Monitor Meter Domain
Each Power Monitor can be a member of a Power Monitor Meter
Domain. The Power Monitor Meter Domain could map 1-1 with a
metered or sub-metered portion of the site. It can be used to
further sub divide the deployment down to finer Power Monitor
Meter Domains such as a floor, lab, data center, rack, etc.
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. Note that the
specification of how to communicate this information between the
Power Monitor Parent and Children is out of the scope of this
document. One point of the parent/child design is that
typically the network is fixed and the endpoints are transient.
In some cases, Power Monitor Children may have a static non-
transient configuration. In such cases, the Power Monitor Meter
Domain MAY be configured directly in Power Monitor Child.
It should be possible to aggregate energy consumption across all
Power Monitors within a Power Monitor Meter Domain. However,
the specification of how to communicate this information between
the Power Monitor Parents is out of the scope of this document.
5.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.
<Claise, et. Al> Expires January 5, 2011 [Page 8]
Internet-Draft <Power Management Archictecure> July 2010
The use of a Power Monitor Parent is not limited to just PoE
children. A Power Monitor Child can be fully dependent on the
Power Monitor Parent or independent from the parent. 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 switch 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.
When a new Power Monitor Parent is added to the Power Monitor
Domain, it should advertise himself to the other existing Power
Monitor Parents. The mechanism could be as simple as a static
configuration, or more elaborated, in which case, this is
outside of the scope of this architecture.
Further examples of Power Monitor Parent and Child
implementations are provided in the Implementation Scenarios
section.
<Claise, et. Al> Expires January 5, 2011 [Page 9]
Internet-Draft <Power Management Archictecure> July 2010
5.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 a 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.
5.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.
<Claise, et. Al> Expires January 5, 2011 [Page 10]
Internet-Draft <Power Management Archictecure> July 2010
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, User Defined 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".
User Defined Power Level Respective Name
0 none
1 short
2 tall
3 grande
4 venti
<Claise, et. Al> Expires January 5, 2011 [Page 11]
Internet-Draft <Power Management Archictecure> July 2010
In the unlikely event of no possible mapping between these User
Defined Power Levels and the Power Levels, the Power Level will
remain 0 throughout the MIB module, as displayed below.
Power Level / Name User Defined 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 User Defined 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 User Defined Power
Level.
Power Level / Name User Defined 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 User Defined Power
Level 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
User Defined 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.
Power Level / Name User Defined Power Level / Name
1 / Mech Off 0 / off
2 / Soft Off 0 / off
3 / Hibernate 0 / off
4 / Sleep, Save-to-RAM 0 / off
<Claise, et. Al> Expires January 5, 2011 [Page 12]
Internet-Draft <Power Management Archictecure> July 2010
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...
5.6. Power Monitor Usage Measurement
For a Power Monitor, 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. 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 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
<Claise, et. Al> Expires January 5, 2011 [Page 13]
Internet-Draft <Power Management Archictecure> July 2010
. Description of the method that was used to measure the
power and can distinguish actual or estimated values.
An NMS can use these information to account for the accuracy and
nature of the reading between different implementations.
In addition to the instantaneous 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.
[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, indexed by pmPowerLevel
and pmUserDefinedPowerLevel. This SNMP notification is
generated when the value(s) of pmPowerLevel and/or
pmUserDefinedPowerLevel has/have changed for the Power Monitor
represented by the pmIndex.
5.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.
5.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
<Claise, et. Al> Expires January 5, 2011 [Page 14]
Internet-Draft <Power Management Archictecure> July 2010
are actual power measurements from a Power Monitor, and not when
the power measurement is assumed or predicted.
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.
5.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.10. CO2 Emission
The goal of energy monitoring and optimization is to reduce the
greenhouse gases, such as the CO2 emission. It proves to be
difficult to report the CO2 emission directly in the Power
Monitors. Indeed, the CO2 emission is linked to the source of
energy: coal, gasoline, fuel oil, natural gas, wind farm, solar
panel. Since the energy source may vary, and will vary more and
more in the future with new ideas such as follow-the-sun
routing, the logical solution is that each Power Monitor reports
his energy consumption, while the NMS makes the translation into
the CO2 emission, based on the different energy sources used in
the different geographical regions.
In this power management architecture, there are no requirements
to report the primary energy required to manufacture a product,
also known as the "embedded carbon" of an asset. Currently,
there is no way to get an accurate number of life cycles for a
<Claise, et. Al> Expires January 5, 2011 [Page 15]
Internet-Draft <Power Management Archictecure> July 2010
product. Indeed, part of the supply chain analysis, there are
still a number of complicated steps to go from supplier
emissions to component emissions to emissions for a specific
product.
6. 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.
7. 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.
. User Defined Power Level and name
<Claise, et. Al> Expires January 5, 2011 [Page 16]
Internet-Draft <Power Management Archictecure> July 2010
. The energy demand parameters: for example, which interval
length to report the energy on, the number of interval to
keep, etc...
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.
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
<Claise, et. Al> Expires January 5, 2011 [Page 17]
Internet-Draft <Power Management Archictecure> July 2010
non-operational state is 1 and the highest is six. Each non-
operational state corresponds to an ACPI level [ACPI].
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 OIDs.
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.
<Claise, et. Al> Expires January 5, 2011 [Page 18]
Internet-Draft <Power Management Archictecure> July 2010
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.
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: 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 January 5, 2011 [Page 19]
Internet-Draft <Power Management Archictecure> July 2010
Scenario 7: 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-00 (work in progress), October 2009.
[POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and
Schoening, B., "Power and Energy Monitoring MIB",
draft-claise-energy-monitoring-mib-03, (work in
progress), May 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.
<Claise, et. Al> Expires January 5, 2011 [Page 20]
Internet-Draft <Power Management Archictecure> July 2010
[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm
[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.
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 January 5, 2011 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 09:01:17 |