Network Working Group J. Quittek, Ed.
Internet-Draft R. Winter
Intended status: Informational T. Dietz
Expires: April 22, 2010 NEC Europe Ltd.
B. Claise
M. Chandramouli
Cisco Systems, Inc.
October 19, 2009
Requirements for Power Monitoring
draft-quittek-power-monitoring-requirements-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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Quittek, et al. Expires April 22, 2010 [Page 1]
Internet-Draft Requirements for Power Monitoring October 2009
Abstract
This memo discusses requirements for monitoring the energy
consumption and the power state of devices. It shows that these
requirements are not covered by existing standards and proposes
directions for new work items on this subject at the IETF.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 4
2.1. Target Devices . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Granularity . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Remote and Aggregated Monitoring . . . . . . . . . . . . . 5
2.4. Required Information . . . . . . . . . . . . . . . . . . . 6
2.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 6
2.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 7
2.4.3. Battery State Monitoring . . . . . . . . . . . . . . . 8
3. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 8
4. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Existing IETF Standards . . . . . . . . . . . . . . . . . 9
4.1.1. ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 9
4.1.2. ENTITY SENSOR MIB . . . . . . . . . . . . . . . . . . 9
4.1.3. UPS MIB . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4. POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 10
4.2. Existing standards of other bodies . . . . . . . . . . . . 10
4.2.1. DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Suggested Actions . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Quittek, et al. Expires April 22, 2010 [Page 2]
Internet-Draft Requirements for Power Monitoring October 2009
1. Introduction
With rising energy costs and an increasing awareness of the
ecological impact of running IT and networking equipment, active
energy management is becoming an additional requirement for network
management systems.
The basic objective of energy management is operating communication
networks and other equipment with a minimal amount of energy. An
energy management system should provide means for reducing power
consumption of individual network components and IT components.
An essential step to achieve this goal is setting all components to
an operational mode that consumes as little power as possible while
still providing sufficient performance to meet service level
objectives. The suitable performance level setting may vary over
time-of-day and may depend on several circumstances. There are three
basic kinds of power saving modes for a component:
o reduced power modes (lower clock rate for processor, lower data
rate on a link, etc.)
o stand-by modes (not functional, but immediately available)
o power off modes (requiring significant time for becoming
operational)
While the goal is quite clear, the way to get there is often
complicated. In many cases there is no way of reducing power
consumption without an effective performance degradation. Then a
trade-off needs to be dealt with between service level objectives and
energy efficiency. In other cases a reduction of energy comsumption
can easily be achieved while still maintaining all service level
objectives, for exampe, by switching components to a lower power mode
when higher performance is not needed.
Network management systems can control such situations by
implementing policies to achieve a certain degree of energy
efficiency. In order to make policy decisions properly, information
about the energy consumption of network components in different modes
is required. Often this information is acquired best through
monitoring.
Monitoring operational power states and energy consumption is also
needed for other purposes including but not limited to
o investigating of power saving potential
o evaluating the effectiveness of energy saving policies and
measures
o deriving, implementing, and testing power management strategies
Quittek, et al. Expires April 22, 2010 [Page 3]
Internet-Draft Requirements for Power Monitoring October 2009
o accounting the total power consumption of a network element, a
network, a service, or subcomponents of those
Energy efficiency, not only of networks, has received a lot attention
recently. Given the potential gains, there are numerous industry
efforts that are concentrating on energy efficiency in several areas
such as:
o Energy efficiency of communication networks and IT systems
o Energy efficiency of buildings
o Efficient delivery of electricity from suppliers to consumers
(smart [power] grids)
In this memo however, we focus on power monitoring only.
Participating entities are monitoring systems that receive
information and networked devices that provide information on energy
consumption and power state information concerning themselves or
potentially also concerning other devices. Not in the scope of this
memo are means for controlling the energy consumption and the power
state of monitored devices. But it is assumed that proprietary and
standardized solutions for this purpose are (or will become)
available.
It should be noted that monitoring energy consumption and power
states itself is obviously not in itself a means to reduce the energy
consumption of a device. On the contrary, it likely will slightly
increase the power consumption of a device. However, the acquired
information is required to enable measures that in total lead to
energy savings.
It should further be noted that active power control is complimentary
(but essential) to other energy savings measures such as low power
electronics, energy saving protocols (e.g. 802.3az), and energy-
efficient device design (for example, stand-by and low-power modes
for individual components of a device), and energy-efficient network
architectures. Measurement of energy consumption may also provide
input for developing these technologies.
2. Monitoring Requirements
2.1. Target Devices
Considering the basic objective described in the previous section,
energy monitoring should be applied to all components of a
communication network including routers, switches, middleboxes,
hosts, etc.
Typically, the total power consumption of hosts is much larger than
Quittek, et al. Expires April 22, 2010 [Page 4]
Internet-Draft Requirements for Power Monitoring October 2009
the total consumption of all other kinds of network devices, but
still the contribution of routers, switches, and middleboxes, etc. is
not negligible. Therefore, monitoring capabilities should be
provided for all kinds of network devices.
Monitoring support should also be provided for certain components
that do not have means for measuring energy consumption by
themselves, but for which their power supply can be monitored by
other devices. For examples see section Section 2.3.
2.2. Granularity
Often it is desirable to switch off individual components of a device
but not the entire device. The switch may need to continue serving a
few ports (for example, the ports serving an email server or needed
for server backup), but most other ports could be entirely switched
off under some policies (for example at night or the weekend in an
office).
As illustrated by this example, it is often desirable to monitor
power state and energy consumption on a granularity level that is
finer than just the device level. Monitoring should be available for
individual components of devices, such as line cards, processor
cards, hard drives, etc. For example, for IP routers the following
list of views of a router gives an idea of components that
potentially should be monitored individually:
o physical view: chassis (or stack), central control engine, line
cards, service cards, etc.
o component view: CPU, ASICs, fans, power supply, ports (single
ports and port groups), storage and memory
o feature view: L2 forwarding, L3 routing, security features, load
balancing features, network management, etc.
o logical view: system, data-plane, control-plane, etc.
o relationship view: line cards, ports and the correlation between
transmission speed and power consumption, relationship of system
load and total power consumption
Instrumentation for measuring energy consumption of a device is
potentially much more expensive than instrumentation for retrieving
the devices power state. It may be a reasonable compromise in many
cases to provide power state information for all individually
switchable components of a device separately, while the energy
consumption is only measured for the entire device.
2.3. Remote and Aggregated Monitoring
Often it is sufficient and more cost efficient having a single device
measuring and providing power state and energy consumption
Quittek, et al. Expires April 22, 2010 [Page 5]
Internet-Draft Requirements for Power Monitoring October 2009
information not just for itself but also for several further devices
that are in some way attached to it. If the measuring and reporting
device has access to individual power supply lines for each device,
then it can measure energy consumption per device. If it only has
access to a joint power supply for several devices, then it will
measure aggregated values.
One example for the first case is a switch acting as power sourcing
equipment for several IP phones using Power over Ethernet (PoE). The
switch can measure the power consumption for each phone individually
at the port the phone is connected to. The phones do not need to
provide means for energy consumption measurement and reporting by
themselves.
Another example is a smart meter that just measures and reports the
energy transmitted through attached electric cables. Such a smart
meter can be used to monitor energy consumption of an individual
device if connected to the devices' individual power supply. But in
many common cases it measures the aggregated energy consumption of
several devices, for example, as part of an uninterruptible power
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
office building or at a residence.
2.4. Required Information
This section lists requirements for information to be retrieved.
Because of the different nature of power state monitoring and energy
consumption monitoring, these are discussed separately. In addition,
a section on battery monitoring is included which again comes with a
set of very different requirements.
Not all of the individual requirements listed in subsections below
are equally relevant. A classification into 'required' and
'optional' is still in progress.
2.4.1. Power State Monitoring
The power state of a device or component typically can only have a
small number of discrete values such as, for example, full power, low
power, standby, hibernating, off. However, some of these states may
have one or more sub-states or state parameters. For example, in low
power state, a reduced clock rate may be set to a large number of
different values. For the device power state, the following
information is considered to be relevant:
Quittek, et al. Expires April 22, 2010 [Page 6]
Internet-Draft Requirements for Power Monitoring October 2009
o the current state - the time of the last change
o the cause for the last transition
o time to transit from one stage to another
o the total time spent in each state
o the duration of the last period spent in each state
o the number of transitions to each state
o the current power source
If the number of discreet sub-states is small, then is may be
desirable to collect the same information as listed above for the
main device state.
For state parameters with many potential values, other information is
more relevant:
o the current parameter value(s)
o the time of the last change (if parameters are to be adapted
continuously)
o the average value(s) per state
o the standard deviation from the mean value(s) per state
o the number of policy-based changes of the parameter(s) (if not
expected to be too many)
For some network management tasks it may be desirable to receive
notifications from devices when components or the entire device
change their power state.
2.4.2. Energy Consumption Monitoring
Different to the power state, energy consumption of a device or a
device's component is a quantity for which the value may change
continuously. Therefore, the information that needs to be retrieved
concerning this quantity is quite different:
o the current real power (energy consumption rate) averaged over a
short time interval
o total energy consumption
o energy consumption since the last report or for the last
configured time interval
o total energy consumption per power state
o energy consumption per power state since the last report
For some network management tasks it may be desirable to receive
notifications from devices when the current power consumption of a
component or of the entire device exceeds or falls below certain
thresholds.
For some network management tasks it is required to measure the power
over time with a relatively high time resolution. In such a case not
just single values for the current power of a component is needed,
but a series of power values reporting on consecutive time intervals.
Quittek, et al. Expires April 22, 2010 [Page 7]
Internet-Draft Requirements for Power Monitoring October 2009
In order to put measured data into perspective, the precision of the
measured data, i.e. the potential error in the measured data, needs
to be known as well.
2.4.3. Battery State Monitoring
An increasing number of networked devices are expected to be battery
powered. This includes e.g. smart meters that report meter readings
and are installed in places where external power supply is not always
possible or costly. But also other devices might have internal/
external batteries to power devices for short periods of time when
the main power fails, to power parts of the device when the main
device is switches off etc. Knowing the state of these batteries is
important for the operation of these devices and includes information
such as:
o the current charge of the battery
o the age of the battery
o the state of the battery (e.g. being re-charged)
o last usage of the battery
o maximum energy provided by the battery
It is possible for devices that are only battery-powered to send
notifications when the current battery charge has dropped below a
certain threshold in order to inform the management system of needed
replacement. The same applies for the age of a battery.
3. Monitoring Models
Monitoring of power states and energy consumption can be performed in
pull mode (for example, SNMP GET [RFC3410]) or in push mode (for
example SNMP notification [RFC3410], Syslog [RFC5424], or IPFIX
[RFC5101]).
Pull mode monitoring is often easier to handle for a network
management systems, because it can determine when it gets certain
information from a certain device. However, the overhead of pull
model monitoring is typically higher than for push model monitoring,
particularly when large numbers of values are to be collected, such
as time series of power values.
In such cases, push model monitoring may be preferable with a device
sending a data stream of values without explicit request for each
value from the network management system. For notifications on
events, only the push model is considered to be appropriate.
Applying these considerations to the required information leads to
the conclusion that most of the information can appropriately be
reported using the pull model. The only exceptions are notifications
Quittek, et al. Expires April 22, 2010 [Page 8]
Internet-Draft Requirements for Power Monitoring October 2009
on power state changes and high volume time series of energy
consumption values.
4. Existing Standards
This section analyzes existing standards for energy consumption and
power state monitoring. It shows that there are already several
standards that cover some part of the requirements listed above, but
even all together do not cover all of the requirements.
4.1. Existing IETF Standards
There are already RFCs available that address a subset of the
requirements.
4.1.1. ENTITY STATE MIB
RFC 4268 [RFC4268] defines the ENTITY STATE MIB module.
Implementations of this module provide information on entities
including the standby status (hotStandby, coldStandby,
providingService), the operational status (disabled, enabled,
testing), the alarm status (underRepair, critical, major, minor,
warning), and the usage status (idle, active, busy). This
information is already useful as input to policy decisions and for
other network monitoring tasks. However, it cover only a small
subset of the requirements for power state monitoring and it does not
provide means for energy consumption monitoring. For relating
provided information to components of a device, the ENTITY STATE MIB
module makes use of the means provided by the ENTITY MIB module
[RFC4133].
4.1.2. ENTITY SENSOR MIB
RFC 3433 [RFC3433] defines the ENTITY SENSOR MIB module.
Implementations of this module offer a generic way to provide data
collected by a sensor. A sensor could be an energy consumption meter
delivering measured values in Watt. This could be used for reporting
current power of a device and its components. Furthermore, the
ENTITY SENSOR MIB can be used to retrieve the precision of the used
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
makes use of the means provided by the ENTITY MIB module [RFC4133]
for relating provided information to components of a device.
Quittek, et al. Expires April 22, 2010 [Page 9]
Internet-Draft Requirements for Power Monitoring October 2009
4.1.3. UPS MIB
RFC 1628 [RFC1628] defines the UPS MIB module. Implementations of
this module provide information on the current real power of devices
attached to an uninterruptible power supply (UPS) device. This
application would require to identify which device is attached to
which port of the UPS device.
4.1.4. POWER ETHERNET MIB
Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
module defined in RFC3621 [RFC3621] provide information on the
current power of individual devices that receive Power over Ethernet
(PoE). The information can be retrieved at the power sourcing
equipment. Like for the UPS MIB, it is required to identify which
device is attached to which port of the power source equipment.
4.2. Existing standards of other bodies
4.2.1. DMTF
The DMTF has defined a power state management profile [DMTF.DSP1027]
that is targeted at computer systems. It is based on the DMTF's
Common Information Model (CIM) and rather a device profile than an
actual energy consumption monitoring standard.
The power state management profile is used to describe and to manage
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)
which is an aspect of but not sufficient for active energy
managagement.
5. Suggested Actions
Based on the analysis of requirements in section Section 2 and the
discussion of monitoring models in section Section 3 this memo
proposes to develop a standard for pull-based monitoring of power
state montoring and energy consumption. Particularly, it suggest to
develop a MIB module for this purpose. Such a MIB module could also
cover push-based reporting of power state changes using SNMP
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 2.
The only aspect that is not 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.
Quittek, et al. Expires April 22, 2010 [Page 10]
Internet-Draft Requirements for Power Monitoring October 2009
Particularly for supporting smart meter functionality, a push-based
protocol appears to be more appropriate. Within the IP protocol
family the Syslog and IPFIX protocols seem to be the most suitable
candidates. There are more standard protocols with the capability to
transfer measurement series, for example, DIAMETER, but these
protocols are designed and well suited for other application areas
than network monitoring.
Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be
the better suited one. While Syslog is optimized for the
transmission of text messages, IPFIX is better equipped for
tranmitting sequences of numerical values. Encoding numerical values
into syslog is well feasible, see, for example, the mapping of SNMP
notifications to Syslog messages in [I-D.ietf-opsawg-syslog-snmp],
but IPFIX provides better means. With the extensible IPFIX
information model [RFC5102] no protocol extension would be required
for transmitting energy consumption information. Only a set of new
information elements would need to be registered at IANA. However,
this memo suggest that the definition of such information elements
should be conducted within the IETF and they should be documented in
a standards track RFC.
6. Acknowledgements
The authors would like to thank Ralf Wolter, for his first essay on
this draft.
7. Security Considerations
This memo currently does not impose any security considerations.
8. IANA Considerations
This memo has no actions for IANA..
9. References
9.1. Normative References
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
November 2005.
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB",
RFC 3621, December 2003.
Quittek, et al. Expires April 22, 2010 [Page 11]
Internet-Draft Requirements for Power Monitoring October 2009
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628,
May 1994.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
Management Information Base", RFC 3433, December 2002.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
[DMTF.DSP1027]
Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
"Power State Management Profile", September 2008.
9.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[I-D.ietf-opsawg-syslog-snmp]
Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG
Messages", draft-ietf-opsawg-syslog-snmp-05 (work in
progress), August 2009.
Quittek, et al. Expires April 22, 2010 [Page 12]
Internet-Draft Requirements for Power Monitoring October 2009
Authors' Addresses
Juergen Quittek (editor)
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-115
Email: quittek@nw.neclab.eu
Rolf Winter
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-121
Email: Rolf.Winter@nw.neclab.eu
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Quittek, et al. Expires April 22, 2010 [Page 13]
Internet-Draft Requirements for Power Monitoring October 2009
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
Quittek, et al. Expires April 22, 2010 [Page 14]