< draft-quittek-power-monitoring-requirements-01.txt   draft-quittek-power-monitoring-requirements-02.txt >
Network Working Group J. Quittek, Ed. Network Working Group J. Quittek, Ed.
Internet-Draft R. Winter Internet-Draft R. Winter
Intended status: Informational T. Dietz Intended status: Informational T. Dietz
Expires: January 13, 2011 NEC Europe Ltd. Expires: April 25, 2011 NEC Europe Ltd.
B. Claise B. Claise
M. Chandramouli M. Chandramouli
Cisco Systems, Inc. Cisco Systems, Inc.
July 12, 2010 October 22, 2010
Requirements for Power Monitoring Requirements for Power Monitoring
draft-quittek-power-monitoring-requirements-01 draft-quittek-power-monitoring-requirements-02
Abstract Abstract
This memo discusses requirements for energy management, particularly This memo discusses requirements for energy management, particularly
for monitoring consumption and controlling power states of devices. for monitoring energy consumption and controlling power states of
This memo further shows that existing IETF standards are not managed devices. This memo further shows that existing IETF
sufficient for energy management and that energy management requires standards are not sufficient for energy management and that energy
architectural considerations that are diffenrent from common other management requires architectural considerations that are diffenrent
management functions. from common other management functions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Energy management functions . . . . . . . . . . . . . . . 4 1.1. Energy management functions . . . . . . . . . . . . . . . 4
1.2. Specific aspects of energy management . . . . . . . . . . 5 1.2. Specific aspects of energy management . . . . . . . . . . 6
2. Scenarios and target devices . . . . . . . . . . . . . . . . . 6 2. Scenarios and target devices . . . . . . . . . . . . . . . . . 6
2.1. Scenario 1: Routers, switches, middleboxes, and hosts . . 6 2.1. Scenario 1: Routers, switches, middleboxes, and hosts . . 6
2.2. Scenario 2: PoE sourcing equipment and PoE powered 2.2. Scenario 2: PoE sourcing equipment and PoE powered
devices . . . . . . . . . . . . . . . . . . . . . . . . . 7 devices . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Scenario 3: Power probes and Smart meters . . . . . . . . 7 2.3. Scenario 3: Power probes and Smart meters . . . . . . . . 7
2.4. Scenario 4: Mid-level managers . . . . . . . . . . . . . . 7 2.4. Scenario 4: Mid-level managers . . . . . . . . . . . . . . 7
2.5. Scenario 5: Gateways to building networks . . . . . . . . 7 2.5. Scenario 5: Gateways to building networks . . . . . . . . 7
2.6. Scenario 6: Home energy gateways . . . . . . . . . . . . . 7 2.6. Scenario 6: Home energy gateways . . . . . . . . . . . . . 8
2.7. Scenario 7: Data center devices . . . . . . . . . . . . . 8 2.7. Scenario 7: Data center devices . . . . . . . . . . . . . 8
2.8. Scenario 8: Battery powered devices . . . . . . . . . . . 8 2.8. Scenario 8: Battery powered devices . . . . . . . . . . . 8
3. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 8 3. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 8
3.1. Granularity of monitoring and control . . . . . . . . . . 8 3.1. Granularity of monitoring and control . . . . . . . . . . 8
3.2. Remote and Aggregated Monitoring . . . . . . . . . . . . . 9 3.2. Remote and Aggregated Monitoring . . . . . . . . . . . . . 9
3.3. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Required Information . . . . . . . . . . . . . . . . . . . 10 3.4. Required Information . . . . . . . . . . . . . . . . . . . 10
3.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 10 3.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 10
3.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 11 3.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 11
3.4.3. Power Quality . . . . . . . . . . . . . . . . . . . . 11 3.4.3. Power Quality . . . . . . . . . . . . . . . . . . . . 11
3.4.4. Battery State Monitoring . . . . . . . . . . . . . . . 11 3.4.4. Battery State Monitoring . . . . . . . . . . . . . . . 12
4. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 12 4. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 12
5. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 12 5. Control Requirements . . . . . . . . . . . . . . . . . . . . . 13
5.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 13
5.1.1. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 13
5.1.2. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 13
5.1.3. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.4. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 14
5.1.5. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 14
5.2. Existing standards of other bodies . . . . . . . . . . . . 15
5.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Suggested Actions . . . . . . . . . . . . . . . . . . . . . . 15 6. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 13
6.1.1. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 13
6.1.2. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 14
6.1.3. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 15
6.1.5. LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 15
6.2. Existing standards of other bodies . . . . . . . . . . . . 15
6.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Suggested Actions . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
With rising energy cost and with an increasing awareness of the With rising energy cost and with an increasing awareness of the
ecological impact of running IT and networking equipment, energy ecological impact of running IT and networking equipment, energy
management is becoming an additional basic requirement for network management is becoming an additional basic requirement for network
management frameworks and systems. management frameworks and systems.
Different to other typical network management functions, energy Different to other typical network management functions, energy
management often extends its scope beyond devices with IP network management often extends its scope beyond devices with IP network
interfaces, for example, in bulding networks, in home networks, and interfaces. Requirements in this document do not fully cover all
in smart grids. Requirements in this document do not fully cover all
these networks, but they cover means for opening IP network these networks, but they cover means for opening IP network
management towards them. management towards them.
In general, IETF Standards for energy management should be defined in
such a way that they can be applied to several areas including
o Communication networks and IT systems
o Building networks
o Home networks
o Smart (power) grids
1.1. Energy management functions 1.1. Energy management functions
The basic objective of energy management is operating communication The basic objective of energy management is operating communication
networks and other equipment with a minimal amount of energy. An networks and other equipment with a minimal amount of energy. An
energy management system should provide means for reducing power energy management system should provide means for reducing the power
consumption of individual components of a network as well as of consumption of individual components of a network as well as of the
entire networks. One aproach to achieve this goal is setting all whole network.
components to an operational state that that results in lower energy
consumption but still meets service level performance objectives.
The sufficient performance level may vary over time and can depend on One approach to achieve this goal is setting all components to an
several factors. There are three basic kinds of power states for a operational state that results in lower energy consumption but still
component: meets service level performance objectives. The sufficient
performance level may vary over time and can depend on several
factors. In principle, there are four basic types of power states
for a component or for a whole system:
o full power state
o reduced power states (lower clock rate for processor, lower data o reduced power states (lower clock rate for processor, lower data
rate on a link, etc.) rate on a link, etc.)
o stand-by/sleep state (not functional, but immediately available) o stand-by/sleep state (not functional, but immediately available)
o power-off state (requiring significant time for becoming o power-off state (requiring significant time for becoming
operational) operational)
In actual implementations the number of power states and their
properties vary a lot. Very simple devices may just have a full
power and a power off state, while other devices may have a high
number of different reduced power and sleep states.
While the general objective of energy management is quite clear, the While the general objective of energy management is quite clear, the
way to get there is often difficult to find. In many cases there is way to attain that goal is often difficult. In many cases there is
no way of reducing power consumption without an effective performance no way of reducing power consumption without the consequence of a
degradation. Then a trade-off needs to be dealt with between service potential performance degradation. Then a trade-off needs to be
level objectives and energy efficiency. In other cases a reduction dealt with between service level objectives and energy efficiency.
of energy comsumption can easily be achieved while still maintaining In other cases a reduction of energy consumption can easily be
sufficient service level performance, for example, by switching achieved while still maintaining sufficient service level
components to lower power states when higher performance is not performance, for example, by switching components to lower power
needed. states when higher performance is not needed.
Network management systems can control such situations by Network management systems can control such situations by
implementing policies to achieve a certain degree of energy implementing policies to achieve a certain degree of energy
efficiency. In order to make policy decisions properly, information efficiency. In order to make policy decisions properly, information
about the energy consumption of network components and sub-components about the energy consumption of network components and sub-components
in different power states is required. Often this information is in different power states is required. Often this information is
acquired best through monitoring. acquired best through monitoring.
Monitoring operational power states and energy consumption is also Monitoring operational power states and energy consumption is also
useful for other energy management purposes including but not limited useful for other energy management purposes including but not limited
to to
o investigating power saving potential o investigating power saving potential
o evaluating the effectiveness of energy saving policies and o evaluating the effectiveness of energy saving policies and
measures measures
o deriving, implementing, and testing power management strategies o deriving, implementing, and testing power management strategies
o accounting the total power consumption of a network element, a o accounting the total power consumption of a network element, a
network, a service, or subcomponents of those network, a service, or subcomponents of those
From the considerations described above the following basic From the considerations described above the following basic
management functions appear to be required for energy management: management functions appear to be required for energy management:
o Monitoring power states of network elements and their o monitoring power states of network elements and their
subcomponents subcomponents
o Monitoring actual power (energy consumption rate) of network o monitoring actual power (energy consumption rate) of network
elements and their subcomponents elements and their subcomponents
o Monitoring (accumulated) energy consumption of network elements o monitoring (accumulated) energy consumption of network elements
and their subcomponents and their subcomponents
o Setting power states of network elements and their subcomponents o setting power states of network elements and their subcomponents
o Setting and enforcing power saving policies o setting and enforcing power saving policies
Editorial note: With the extension to power state control and policy Editorial note: With the extension to power state control and policy
enforcement, the title of the draft does not anymore match the scope enforcement, the title of the draft does not anymore match the scope
well. The name of the draft will be updated in a future revision. well. The name of the draft will be updated in a future revision.
It should be noted that monitoring energy consumption and power It should be noted that monitoring energy consumption and power
states itself is obviously not in itself a means to reduce the energy states itself is obviously not in itself a means to reduce the energy
consumption of a device. On the contrary, it likely will slightly consumption of a device. In fact, it is likely to increase the power
increase the power consumption of a device. However, the acquired consumption of a device slightly. However, the acquired energy
information is required to enable measures that in total lead to consumption and power state information is essential fordefining
energy savings. energy saving policies and can be used as input to power state
control loops that in total can lead to energy savings.
It should further be noted that active power control is complimentary It should further be noted that active power control is complementary
(but essential) to other energy savings measures such as low power (but essential) to other energy savings measures such as low power
electronics, energy saving protocols (e.g. 802.3az), and energy- electronics, energy saving protocols (e.g. IEEE 802.3az), and
efficient device design (for example, stand-by and low-power modes energy-efficient device design (for example, stand-by and low-power
for individual components of a device), and energy-efficient network modes for individual components of a device), and energy-efficient
architectures. Measurement of energy consumption may also provide network architectures. Measurement of energy consumption may also
input for developing these technologies. provide input for developing these technologies.
1.2. Specific aspects of energy management 1.2. Specific aspects of energy management
There are two aspects of energy mangement that makes it different There are two aspects of energy management that make it different
from common other management functions. The first difference is that from other common network management functions. The first difference
energy consumption is often measured remotely to the afected device. is that energy consumption is often measured remotely to the device
A reason for this is that today, very few devices are instrumented under consideration. A reason for this is that today very few
with hardware ans software for measuring their own current power and devices are instrumented with the hardware and software for measuring
accumulated energy consumption. Often power and energy for such their own current power and accumulated energy consumption. Often
devices is measured by other devices. power and energy for such devices is measured by other devices.
A very common examples is a Power over Ethernet (PoE) sourcing device
that provides means for measuring provided power per port. If the
device connected to a port is known, power and energy measurements
for that device can be conducted by the PoE sourcing device. Another
example is a smart power strip. Again, if it is known which devices
are plugged into which outlets of the smart power strip, then the
power strip can provide measured values for these devices.
The second difference is that energy management is often also applied A common example is a Power over Ethernet (PoE) sourcing device that
to networks and devices that do not communicate via IP, for example, provides means for measuring provided power per port. If the device
in building networks where besides IP several other communication connected to a port is known, power and energy measurements for that
protocls are used. In these networks it may be desirable that device can be conducted by the PoE sourcing device. Another example
devices with IP interfaces report energy and power values for other is a smart power strip. Again, if it is known which devices are
devices. Reports may be based on measurements at the reporting plugged into which outlets of the smart power strip, then the power
device, similar to the PoE sourcing device and the smart strip. But strip can provide measured values for these devices.
reports may also be just relayed from non-IP communication to IP
communication.
IETF standards for energy management should be defined in a way that The second difference is that often it is desirable to apply energy
they can abe applied to several areas including management also to networks and devices that do not communicate via
o Communication networks and IT systems IP, for example, in building networks where besides IP several other
o Building networks communication protocols are used. In these networks, it may be
o Home networks desirable that devices with IP interfaces report energy and power
o Smart (power) grids values for other devices. Reports may be based on measurements at
the reporting device, similar to the PoE sourcing device and the
smart strip. But reports may also be just relayed from non-IP
communication to IP communication.
2. Scenarios and target devices 2. Scenarios and target devices
This section describes a selection of scenarios for the application This section describes a selection of scenarios for the application
of energy management. For each scenario a list of target devices is of energy management. For each scenario a list of target devices is
given in the headline, for which IETF energy management standards are given in the headline, for which IETF energy management standards are
needed. needed.
2.1. Scenario 1: Routers, switches, middleboxes, and hosts 2.1. Scenario 1: Routers, switches, middleboxes, and hosts
Power management of networks is viewed as a fundamental (basic first Power management of network devices is considered as a fundamental
step) requirement. The devices listed in this scenario are some of (basic first step) requirement. The devices listed in this scenario
the components of a communication network. For these network are some of the components of a communication network. For these
devices, the chassis draws power from an outlet and feeds all its network devices, the chassis draws power from an outlet and feeds all
internal sub-components. its internal sub-components.
2.2. Scenario 2: PoE sourcing equipment and PoE powered devices 2.2. Scenario 2: PoE sourcing equipment and PoE powered devices
This scenario covers devices using Power ove Ethernet (PoE). A PoE This scenario covers devices using Power over Ethernet (PoE). A PoE
Power Sourcing Equipment (PSE), for example a PoE switch, provices Power Sourcing Equipment (PSE), for example, a PoE switch, provices
power to a PoW Powered Device (PD), for example, a PoE desktop phone. power to a PoW Powered Device (PD), for example, a PoE desktop phone.
Here, the PSE provices means for controlling power supply (switching Here, the PSE provides means for controlling power supply (switching
it on and off) and for monitoring actual power provided at a port to it on and off) and for monitoring actual power provided at a port to
a specfic PD. a specific PD.
2.3. Scenario 3: Power probes and Smart meters 2.3. Scenario 3: Power probes and Smart meters
Today, very few devices are equipped with sufficient instrumentation Today, very few devices are equipped with sufficient instrumentation
to measure their own actual power and accumulated energy consumption. to measure their own actual power and accumulated energy consumption.
Often external probes are connected to the power supply for measuring Often external probes are connected to the power supply for measuring
these propoerties for a single device or for a set of devices. these properties for a single device or for a set of devices.
Homes, buildings, and data centers have smart meters that monitor and Homes, buildings, and data centers have smart meters that monitor and
report accumulated power consumption of an entire home, a set of report accumulated power consumption of an entire home, a set of
offices or a set of devices in data enters. offices or a set of devices in data centers.
Power Distribution Unit (PDUs) attached to racks in data center and Power Distribution Unit (PDUs) attached to racks in data center and
other smart power strips are evolving with smart meters and remote other smart power strips are evolving with smart meters and remote
controllable power switches embedded for each socket. controllable power switches embedded for each socket.
2.4. Scenario 4: Mid-level managers 2.4. Scenario 4: Mid-level managers
Sometomes it is useful to have mid-level managers that provide energy Sometimes it is useful to have mid-level managers that provide energy
management functions not just for themselves but also for a set of management functions not just for themselves but also for a set of
associated devices. For example, a switch can provide energy associated devices. For example, a switch can provide energy
management functions for all devices connected to its ports, even if management functions for all devices connected to its ports, even if
these devices are not PoE PDs, but have their own power supply as, these devices are not PoE PDs, but have their own power supply as,
for example, PCs connected to the switch. for example, PCs connected to the switch.
2.5. Scenario 5: Gateways to building networks 2.5. Scenario 5: Gateways to building networks
Due to the potential energy savings, energy management of buildings Due to the potential energy savings, energy management of buildings
has received significant attention. There are gateway network has received significant attention. There are gateway network
skipping to change at page 8, line 10 skipping to change at page 8, line 16
Home energy gateway can be used for energy management of a home. Home energy gateway can be used for energy management of a home.
This gateway can manage the appliances (refrigerator, heating/ This gateway can manage the appliances (refrigerator, heating/
cooling, washing machine etc.) and interface with the electrical cooling, washing machine etc.) and interface with the electrical
grid. The gateway can implement policies based on demand and energy grid. The gateway can implement policies based on demand and energy
pricing from the grid. pricing from the grid.
2.7. Scenario 7: Data center devices 2.7. Scenario 7: Data center devices
Energy efficiency of data centers has become a fundamental challenges Energy efficiency of data centers has become a fundamental challenges
of data center opertion. Energy management is conducted on different of data center operation. Energy management is conducted on
aggregation levels, such as network level, Power Distribution Unit different aggregation levels, such as network level, Power
(PDU) level, and server level. Distribution Unit (PDU) level, and server level.
2.8. Scenario 8: Battery powered devices 2.8. Scenario 8: Battery powered devices
Some devices have a battery as a back-up source of power. Given the Some devices have a battery as a back-up source of power. Given the
finite capacity and lifetime of a battery, means for reporting the finite capacity and lifetime of a battery, means for reporting the
actual charge, age, and state of a battery are required. actual charge, age, and state of a battery are required.
3. Monitoring Requirements 3. Monitoring Requirements
3.1. Granularity of monitoring and control 3.1. Granularity of monitoring and control
skipping to change at page 8, line 37 skipping to change at page 8, line 43
for server backup), but most other ports could be entirely switched for server backup), but most other ports could be entirely switched
off under some policies (for example at night or the weekend in an off under some policies (for example at night or the weekend in an
office). office).
As illustrated by this example, it is often desirable to monitor As illustrated by this example, it is often desirable to monitor
power state and energy consumption on a granularity level that is power state and energy consumption on a granularity level that is
finer than just the device level. Monitoring should be available for finer than just the device level. Monitoring should be available for
individual components of devices, such as line cards, processor individual components of devices, such as line cards, processor
cards, hard drives, etc. For example, for IP routers the following cards, hard drives, etc. For example, for IP routers the following
list of views of a router gives an idea of components that list of views of a router gives an idea of components that
potentially should be monitored and controlled individually: potentially could be monitored and controlled individually:
o Physical view: chassis (or stack), central control engine, line o Physical view: chassis (or stack), central control engine, line
cards, service cards, etc. cards, service cards, etc.
o Component view: CPU, ASICs, fans, power supply, ports (single o Component view: CPU, ASICs, fans, power supply, ports (single
ports and port groups), storage and memory ports and port groups), storage and memory
o Feature view: L2 forwarding, L3 routing, security features, load o Feature view: L2 forwarding, L3 routing, security features, load
balancing features, network management, etc. balancing features, network management, etc.
o Logical view: system, data-plane, control-plane, etc. o Logical view: system, data-plane, control-plane, etc.
o Relationship view: line cards, ports and the correlation between o Relationship view: line cards, ports and the correlation between
transmission speed and power consumption, relationship of system transmission speed and power consumption, relationship of system
load and total power consumption load and total power consumption
Instrumentation for measuring energy consumption of a device is Instrumentation for measuring energy consumption of a device is
potentially much more expensive than instrumentation for retrieving typically more expensive than instrumentation for retrieving the
the devices power state. It may be a reasonable compromise in many devices power state. It may be a reasonable compromise in many cases
cases to provide power state information for all individually to provide power state information for all individually switchable
switchable components of a device separately, while the energy components of a device separately, while the energy consumption is
consumption is only measured for the entire device. only measured for the entire device.
3.2. Remote and Aggregated Monitoring 3.2. Remote and Aggregated Monitoring
There are several ways power and energy consumption can be measured There are several ways power and energy consumption can be measured
and reported. Measurements can be conducted locally at the device and reported. Measurements can be performed locally at the device
that consumes energy or remotely by a device that has access to the that consumes energy or remotely by a device that has access to the
power supply of another device. power supply of another device.
Instrumentation for these measurements requires additional hardware. Instrumentation for power and energy measurements at a device
Some cost-eficient applications measure power and energy consumption requires additional hardware. A cost-efficient alternative is
aggregated for a set of devices, for example a PoE PSE reporting measuring power and energy consumption aggregated for a set of
these values per port group instead of per port, or a power devices, for example a PoE PSE reporting these values per port group
distribution unit that eports the values for all connected devices instead of per port, or a power distribution unit that reports the
instead of per socket. values for all connected devices instead of per socket.
If aggregated measurement is conducted, it is obvious that reporting If aggregated measurement is conducted, it is obvious that reporting
provides aggregated values. but agregated reporting can also be provides aggregated values. but aggregated reporting can also be
combined with local measurement. A managed node may act as mid-level combined with local measurements. A managed node may act as mid-
manager or protocol converter for several devices that measure power level manager or protocol converter for several devices that measure
consumption by themselves, for example a home gateway or a gateway to power consumption by themselves, for example a home gateway or a
building networks. In this case, the reporting node may choose to gateway to building networks. In this case, the reporting node may
report for each device individual values or aggregated values from choose to report for each device individual values or aggregated
groups of devices that transmitted their power and energy consumption values from groups of devices that transmitted their power and energy
values to the reporting node. consumption values to the reporting node.
Often it is sufficient and more cost efficient having a single device Often it is sufficient and more cost efficient having a single device
measuring and providing power state and energy consumption measuring and providing power state and energy consumption
information not just for itself but also for several further devices information not just for itself but also for several further devices
that are in some way attached to it. If the measuring and reporting that are in some way attached to it. If the measuring and reporting
device has access to individual power supply lines for each device, device has access to individual power supply lines for each device,
then it can measure energy consumption per device. If it only has then it can measure energy consumption per device. If it only has
access to a joint power supply for several devices, then it will access to a joint power supply for several devices, then it will
measure aggregated values. measure aggregated values.
skipping to change at page 10, line 15 skipping to change at page 10, line 22
device if connected to the devices' individual power supply. But in device if connected to the devices' individual power supply. But in
many common cases it measures the aggregated energy consumption of many common cases it measures the aggregated energy consumption of
several devices, for example, as part of an uninterruptible power several devices, for example, as part of an uninterruptible power
supply (UPS) that serves several devices at a single power cord, or supply (UPS) that serves several devices at a single power cord, or
as a smart electric meter for a set of machines in a rack, in an as a smart electric meter for a set of machines in a rack, in an
office building or at a residence. office building or at a residence.
3.3. Accuracy 3.3. Accuracy
Depending on how power and energy consumption values are obtained the Depending on how power and energy consumption values are obtained the
confidence in the reported value and its accuracy may vary. managed confidence in the reported value and its accuracy may vary. Managed
nodes reporting values concerning themselves or other devices should nodes reporting values concerning themselves or other devices should
qualify the confidence in reported values and quantify the accuracy qualify the confidence in reported values and quantify the accuracy
of measurements, For accuracy reporting, the accuracy classes IEC of measurements. For accuracy reporting, the accuracy classes
61850 should be considered. specified in IEC 61850 should be considered.
3.4. Required Information 3.4. Required Information
This section lists requirements for information to be retrieved. This section lists requirements for information to be retrieved.
Because of the different nature of power state monitoring and energy Because of the different nature of power state monitoring and energy
consumption monitoring, these are discussed separately. In addition, consumption monitoring, these are discussed separately. In addition,
a section on battery monitoring is included which again comes with a a section on battery monitoring is included which again comes with a
set of very different requirements. set of very different requirements.
Not all of the individual requirements listed in subsections below Not all of the individual requirements listed in subsections below
skipping to change at page 12, line 40 skipping to change at page 13, line 5
sending a data stream of values without explicit request for each sending a data stream of values without explicit request for each
value from the network management system. For notifications on value from the network management system. For notifications on
events, only the push model is considered to be appropriate. events, only the push model is considered to be appropriate.
Applying these considerations to the required information leads to Applying these considerations to the required information leads to
the conclusion that most of the information can appropriately be the conclusion that most of the information can appropriately be
reported using the pull model. The only exceptions are notifications reported using the pull model. The only exceptions are notifications
on power state changes and high volume time series of energy on power state changes and high volume time series of energy
consumption values. consumption values.
5. Existing Standards 5. Control Requirements
To realize the envisioned benefits of energy savings, just monitoring
power states and energy consumption would not be sufficient. Energy
efficiency can be realized only by setting the network entities or
components to energy saving power states when appropriate.
With means for power state control, energy saving policies and
control loops can be realized. Policies may, for example, define
different power state settings based on the time-of-day. Control
loops may, for example, change power states based on actual network
load.
Trivially, all entities being subject of energy management should
have at least two power states, such as "on" and "off" or "on" and
"sleep" to be set. In many cases, it may be desirable to have more
operational ("on" mode") and non-operational ("off"/"sleep" mode)
power states. This applies particularly to devices with a lot of
configuration parameters that influence their energy consumption.
Examples for specifications of power states of managed devices can be
found in the Advanced Configuration and Power Interface (ACPI)
[ACPI.R30b] or the DMTF Power State Management Profile
[DMTF.DSP1027].
6. Existing Standards
This section analyzes existing standards for energy consumption and This section analyzes existing standards for energy consumption and
power state monitoring. It shows that there are already several power state monitoring. It shows that there are already several
standards that cover some part of the requirements listed above, but standards that cover some part of the requirements listed above, but
even all together they do not cover all of the requirements for even all together they do not cover all of the requirements for
energy management. energy management.
5.1. Existing IETF Standards 6.1. Existing IETF Standards
There are already RFCs available that address a subset of the There are already RFCs available that address a subset of the
requirements. requirements.
5.1.1. ENTITY STATE MIB 6.1.1. ENTITY STATE MIB
RFC 4268 [RFC4268] defines the ENTITY STATE MIB module. RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.
Implementations of this module provide information on entities Implementations of this module provide information on entities
including the standby status (hotStandby, coldStandby, including the standby status (hotStandby, coldStandby,
providingService), the operational status (disabled, enabled, providingService), the operational status (disabled, enabled,
testing), the alarm status (underRepair, critical, major, minor, testing), the alarm status (underRepair, critical, major, minor,
warning), and the usage status (idle, active, busy). This warning), and the usage status (idle, active, busy). This
information is already useful as input to policy decisions and for information is already useful as input to policy decisions and for
other network monitoring tasks. However, it cover only a small other network monitoring tasks. However, the number of states would
subset of the requirements for power state monitoring and it does not cover only a small subset of the requirements for power state
provide means for energy consumption monitoring. For relating monitoring and it does not provide means for energy consumption
provided information to components of a device, the ENTITY STATE MIB monitoring. For associating the provided information to specific
module makes use of the means provided by the ENTITY MIB module components of a device, the ENTITY STATE MIB module makes use of the
[RFC4133]. means provided by the ENTITY MIB module [RFC4133]. Particularly, it
uses the entPhysicalIndex for identifying entities.
The standby status provided by the ENTITY STATE MIB module is related The standby status provided by the ENTITY STATE MIB module is related
to power states required for energy management, but they are too to power states required for energy management, but the number of
restricted for meeting all energy management requirements. For states is too restricted for meeting all energy management
energy management several more power states are required, such as requirements. For energy management several more power states are
different sleep and operational states as defined by the Advanced required, such as different sleep and operational states as defined
Configuration and Power Interface (ACPI) or the DMTF Power State by the Advanced Configuration and Power Interface (ACPI) [ACPI.R30b]
Management Profile [DMTF.DSP1027]. or the DMTF Power State Management Profile [DMTF.DSP1027].
5.1.2. ENTITY SENSOR MIB 6.1.2. ENTITY SENSOR MIB
RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module. RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.
Implementations of this module offer a generic way to provide data Implementations of this module offer a generic way to provide data
collected by a sensor. A sensor could be an energy consumption meter collected by a sensor. A sensor could be an energy consumption meter
delivering measured values in Watt. This could be used for reporting delivering measured values in Watt. This could be used for reporting
current power of a device and its components. Furthermore, the current power of a device and its components. Furthermore, the
ENTITY SENSOR MIB can be used to retrieve the precision of the used ENTITY SENSOR MIB can be used to retrieve the precision of the used
power meter. power meter.
However, there is no unit available for reporting energy quantities,
such as, for example, watt seconds or kilowatt hours.
Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module
makes use of the means provided by the ENTITY MIB module [RFC4133] makes use of the means provided by the ENTITY MIB module [RFC4133]
for relating provided information to components of a device. for relating provided information to components of a device.
The ENTITY SENSOR MIB module does not support reporting accuracy of However, there is no unit available for reporting energy quantities,
measurements according to the IEC / ANSI accuracy classes, which are such as, for example, watt seconds or kilowatt hours, and the ENTITY
commonly in use for electric power and energy mesurements. The SENSOR MIB module does not support reporting accuracy of measurements
ENTITY SENSOR MIB modules only provides a coarse-grained method for according to the IEC / ANSI accuracy classes, which are commonly in
indicating accuracy by stating the number of correct digits of fixed use for electric power and energy measurements. The ENTITY SENSOR
point values. MIB modules only provides a coarse-grained method for indicating
accuracy by stating the number of correct digits of fixed point
values.
5.1.3. UPS MIB 6.1.3. UPS MIB
RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of
this module provide information on the current real power of devices this module provide information on the current real power of devices
attached to an uninterruptible power supply (UPS) device. This attached to an uninterruptible power supply (UPS) device. This
application would require to identify which device is attached to application would require identifying which device is attached to
which port of the UPS device. which port of the UPS device.
UPS MIB provides information on the state of the UPS network. The UPS MIB provides information on the state of the UPS network. The
MIB module contains several variables identify the UPS entity (name, MIB module contains several variables identify the UPS entity (name,
model,..), the battery state, to characterize the input load to the model,..), the battery state, to characterize the input load to the
UPS, to characterize the output from the UPS, to indicate the various UPS, to characterize the output from the UPS, to indicate the various
alarm events. The measurement of power in UPS MIB are in Volts, Amps alarm events. The measurements of power in UPS MIB are in Volts,
and Watts. The units of power measurement are RMS volts, RMS Amps Amperes and Watts. The units of power measurement are RMS volts, RMS
and are not based on Entity-Sensor MIB [RFC3433]. Amperes and are not based on Entity-Sensor MIB [RFC3433].
5.1.4. POWER ETHERNET MIB 6.1.4. POWER ETHERNET MIB
Similar to the UPS MIB, implementations of the POWER ETHERNET MIB Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
module defined in RFC3621 [RFC3621] provide information on the module defined in RFC3621 [RFC3621] provide information on the
current power of devices that receive Power over Ethernet (PoE). The current energy consumption of the devices that receive Power over
information can be retrieved at the power sourcing equipment. Like Ethernet (PoE). This information can be retrieved at the power
for the UPS MIB, it is required to identify which devices are sourcing equipment. Analogous to the UPS MIB, it is required to
attached to which port of the power source equipment. identify which devices are attached to which port of the power
sourcing equipment.
The POWER ETHERNET MIB does not report power and energy consumption The POWER ETHERNET MIB does not report power and energy consumption
on a per port base, but can report aggregated values for groups of on a per port basis, but can report aggregated values for groups of
ports. It does not use objects of the ENTITY MIB module for ports. It does not use objects of the ENTITY MIB module for
identifying entities, although this module existed already when the identifying entities, although this module existed already when the
POWER ETHERNET MIB modules was standardized. POWER ETHERNET MIB modules was standardized.
5.1.5. LLDP MED MIB 6.1.5. LLDP MED MIB
The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a
data link layer protocol used by network devices for advertising of data link layer protocol used by network devices for advertising of
their identities, capabilities, and interconnections on a LAN their identities, capabilities, and interconnections on a LAN
network. The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an network. The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an
enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements
specifically address voice applications. LLDP-MED covers 6 basic specifically address voice applications. LLDP-MED covers 6 basic
areas: capabilities discovery, LAN speed and duplex discovery, areas: capabilities discovery, LAN speed and duplex discovery,
network policy discovery, location identification discovery, network policy discovery, location identification discovery,
inventory discovery, and power discovery. inventory discovery, and power discovery.
5.2. Existing standards of other bodies 6.2. Existing standards of other bodies
5.2.1. DMTF 6.2.1. DMTF
The DMTF has defined a power state management profile [DMTF.DSP1027] The DMTF has defined a power state management profile [DMTF.DSP1027]
that is targeted at computer systems. It is based on the DMTF's that is targeted at computer systems. It is based on the DMTF's
Common Information Model (CIM) and rather a device profile than an Common Information Model (CIM) and rather a device profile than an
actual energy consumption monitoring standard. actual energy consumption monitoring standard.
The power state management profile is used to describe and to manage The power state management profile is used to describe and to manage
the power state of computer systems. This includes e.g. means to the power state of computer systems. This includes e.g. means to
change the power state of a device (e.g. to shutdown the device) change the power state of a device (e.g. to shutdown the device)
which is an aspect of but not sufficient for active energy which is an aspect of but not sufficient for active energy
managagement. management.
6. Suggested Actions 7. Suggested Actions
Based on the analysis of requirements in section Section 3 and the Based on the analysis of requirements in Section 3 and the discussion
discussion of monitoring models in section Section 4 this memo of monitoring models in Section 4 this memo proposes to develop a
proposes to develop a standard for pull-based monitoring of power standard for pull-based monitoring of power states, energy
state montoring and energy consumption. Particularly, it suggest to consumption, and battery states. The analysis of existing MIB
develop a MIB module for this purpose. Such a MIB module could also modules in the previous section shows that they are not sufficient to
cover push-based reporting of power state changes using SNMP meet the requirements discussed in Section 3.
notification. The analysis of existing MIB modules in the previous
section shows that they are not sufficient to meet the requirements
discussed in section Section 3.
The only aspect that is not covered well by a MIB/SNMP solution is As a consequence, it suggested to develop one or more MIB modules for
the reporting of large time series of energy consumption values. For this purpose. Such MIB modules could also cover push-based reporting
of power state changes using SNMP notifications. The only aspect
that would not be covered well by a MIB/SNMP solution is the
reporting of large time series of energy consumption values. For
this purpose SNMP does not appear to be an optimal choice. this purpose SNMP does not appear to be an optimal choice.
Particularly for supporting smart meter functionality, a push-based Particularly for supporting smart meter functionality, a push-based
protocol appears to be more appropriate. Within the IP protocol protocol appears to be more appropriate. Within the IP protocol
family the Syslog and IPFIX protocols seem to be the most suitable family the Syslog and IPFIX protocols seem to be the most suitable
candidates. There are more standard protocols with the capability to candidates. There are more standard protocols with the capability to
transfer measurement series, for example, DIAMETER, but these transfer measurement series, for example, DIAMETER, but these
protocols are designed and well suited for other application areas protocols are designed and well suited for other application areas
than network monitoring. than network monitoring.
Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be
the better suited one. While Syslog is optimized for the the better suited one. While Syslog is optimized for the
transmission of text messages, IPFIX is better equipped for transmission of text messages, IPFIX is better equipped for
tranmitting sequences of numerical values. Encoding numerical values transmitting sequences of numerical values. Encoding numerical
into syslog is well feasible, see, for example, the mapping of SNMP values into syslog is well feasible, see, for example, the mapping of
notifications to Syslog messages in [RFC5675], but IPFIX provides SNMP notifications to Syslog messages in [RFC5675], but IPFIX
better means. With the extensible IPFIX information model [RFC5102] provides better means. With the extensible IPFIX information model
no protocol extension would be required for transmitting energy [RFC5102] no protocol extension would be required for transmitting
consumption information. Only a set of new information elements energy consumption information. Only a set of new information
would need to be registered at IANA. However, this memo suggest that elements would need to be registered at IANA. However, this memo
the definition of such information elements should be conducted suggests that the definition of such information elements should be
within the IETF and they should be documented in a standards track conducted within the IETF and they should be documented in a
RFC. standards track RFC.
7. Acknowledgements 8. Acknowledgements
The authors would like to thank Ralf Wolter, for his first essay on The authors would like to thank Ralf Wolter, for his first essay on
this draft. this draft.
8. Security Considerations 9. Security Considerations
This memo currently does not impose any security considerations. This memo currently does not impose any security considerations.
9. IANA Considerations 10. IANA Considerations
This memo has no actions for IANA.. This memo has no actions for IANA..
10. References 11. Informative References
10.1. Normative References
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
November 2005. November 2005.
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB",
RFC 3621, December 2003. RFC 3621, December 2003.
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628, [RFC1628] Case, J., "UPS Management Information Base", RFC 1628,
May 1994. May 1994.
skipping to change at page 17, line 5 skipping to change at page 17, line 34
RFC 4133, August 2005. RFC 4133, August 2005.
[RFC5101] Claise, B., "Specification of the IP Flow Information [RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008. Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export", Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008. RFC 5102, January 2008.
[DMTF.DSP1027]
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
"Power State Management Profile", September 2008.
10.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG Management Protocol (SNMP) Notifications to SYSLOG
Messages", RFC 5675, October 2009. Messages", RFC 5675, October 2009.
[ACPI.R30b]
Hewlett-Packard Corporation, Intel Corporation, Microsoft
Corporation, Phoenix Corporation, and Toshiba Corporation,
"Advanced Configuration and Power Interface Specification,
Revision 3.0b", October 2006.
[DMTF.DSP1027]
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
"Power State Management Profile", September 2008.
Authors' Addresses Authors' Addresses
Juergen Quittek (editor) Juergen Quittek (editor)
NEC Europe Ltd. NEC Europe Ltd.
NEC Laboratories Europe NEC Laboratories Europe
Network Research Division Network Research Division
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
DE DE
 End of changes. 74 change blocks. 
205 lines changed or deleted 240 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/