Network Working Group J. Quittek, Ed.
Internet-Draft R. Winter
Intended status: Informational T. Dietz
Expires: January 13, 2011 NEC Europe Ltd.
B. Claise
M. Chandramouli
Cisco Systems, Inc.
July 12, 2010
Requirements for Power Monitoring
draft-quittek-power-monitoring-requirements-01
Abstract
This memo discusses requirements for energy management, particularly
for monitoring consumption and controlling power states of devices.
This memo further shows that existing IETF standards are not
sufficient for energy management and that energy management requires
architectural considerations that are diffenrent from common other
management functions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 13, 2011.
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
Quittek, et al. Expires January 13, 2011 [Page 1]
Internet-Draft Requirements for Power Monitoring July 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Energy management functions . . . . . . . . . . . . . . . 4
1.2. Specific aspects of energy management . . . . . . . . . . 5
2. Scenarios and target devices . . . . . . . . . . . . . . . . . 6
2.1. Scenario 1: Routers, switches, middleboxes, and hosts . . 6
2.2. Scenario 2: PoE sourcing equipment and PoE powered
devices . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Scenario 3: Power probes and Smart meters . . . . . . . . 7
2.4. Scenario 4: Mid-level managers . . . . . . . . . . . . . . 7
2.5. Scenario 5: Gateways to building networks . . . . . . . . 7
2.6. Scenario 6: Home energy gateways . . . . . . . . . . . . . 7
2.7. Scenario 7: Data center devices . . . . . . . . . . . . . 8
2.8. Scenario 8: Battery powered devices . . . . . . . . . . . 8
3. Monitoring Requirements . . . . . . . . . . . . . . . . . . . 8
3.1. Granularity of monitoring and control . . . . . . . . . . 8
3.2. Remote and Aggregated Monitoring . . . . . . . . . . . . . 9
3.3. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Required Information . . . . . . . . . . . . . . . . . . . 10
3.4.1. Power State Monitoring . . . . . . . . . . . . . . . . 10
3.4.2. Energy Consumption Monitoring . . . . . . . . . . . . 11
3.4.3. Power Quality . . . . . . . . . . . . . . . . . . . . 11
3.4.4. Battery State Monitoring . . . . . . . . . . . . . . . 11
4. Monitoring Models . . . . . . . . . . . . . . . . . . . . . . 12
5. Existing Standards . . . . . . . . . . . . . . . . . . . . . . 12
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
Quittek, et al. Expires January 13, 2011 [Page 2]
Internet-Draft Requirements for Power Monitoring July 2010
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Quittek, et al. Expires January 13, 2011 [Page 3]
Internet-Draft Requirements for Power Monitoring July 2010
1. Introduction
With rising energy cost and with an increasing awareness of the
ecological impact of running IT and networking equipment, energy
management is becoming an additional basic requirement for network
management frameworks and systems.
Different to other typical network management functions, energy
management often extends its scope beyond devices with IP network
interfaces, for example, in bulding networks, in home networks, and
in smart grids. Requirements in this document do not fully cover all
these networks, but they cover means for opening IP network
management towards them.
1.1. Energy management functions
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 components of a network as well as of
entire networks. One aproach to achieve this goal is setting all
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
several factors. There are three basic kinds of power states for a
component:
o reduced power states (lower clock rate for processor, lower data
rate on a link, etc.)
o stand-by/sleep state (not functional, but immediately available)
o power-off state (requiring significant time for becoming
operational)
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
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
sufficient service level performance, for example, by switching
components to lower power states 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 and sub-components
in different power states is required. Often this information is
Quittek, et al. Expires January 13, 2011 [Page 4]
Internet-Draft Requirements for Power Monitoring July 2010
acquired best through monitoring.
Monitoring operational power states and energy consumption is also
useful for other energy management purposes including but not limited
to
o investigating power saving potential
o evaluating the effectiveness of energy saving policies and
measures
o deriving, implementing, and testing power management strategies
o accounting the total power consumption of a network element, a
network, a service, or subcomponents of those
From the considerations described above the following basic
management functions appear to be required for energy management:
o Monitoring power states of network elements and their
subcomponents
o Monitoring actual power (energy consumption rate) of network
elements and their subcomponents
o Monitoring (accumulated) energy consumption of network elements
and their subcomponents
o Setting power states of network elements and their subcomponents
o Setting and enforcing power saving policies
Editorial note: With the extension to power state control and policy
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.
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.
1.2. Specific aspects of energy management
There are two aspects of energy mangement that makes it different
from common other management functions. The first difference is that
energy consumption is often measured remotely to the afected device.
A reason for this is that today, very few devices are instrumented
Quittek, et al. Expires January 13, 2011 [Page 5]
Internet-Draft Requirements for Power Monitoring July 2010
with hardware ans software for measuring their own current power and
accumulated energy consumption. Often 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
to networks and devices that do not communicate via IP, for example,
in building networks where besides IP several other communication
protocls are used. In these networks it may be desirable that
devices with IP interfaces report energy and power 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.
IETF standards for energy management should be defined in a way that
they can abe applied to several areas including
o Communication networks and IT systems
o Building networks
o Home networks
o Smart (power) grids
2. Scenarios and target devices
This section describes a selection of scenarios for the application
of energy management. For each scenario a list of target devices is
given in the headline, for which IETF energy management standards are
needed.
2.1. Scenario 1: Routers, switches, middleboxes, and hosts
Power management of networks is viewed as a fundamental (basic first
step) requirement. The devices listed in this scenario are some of
the components of a communication network. For these network
devices, the chassis draws power from an outlet and feeds all its
internal sub-components.
Quittek, et al. Expires January 13, 2011 [Page 6]
Internet-Draft Requirements for Power Monitoring July 2010
2.2. Scenario 2: PoE sourcing equipment and PoE powered devices
This scenario covers devices using Power ove Ethernet (PoE). A PoE
Power Sourcing Equipment (PSE), for example a PoE switch, provices
power to a PoW Powered Device (PD), for example, a PoE desktop phone.
Here, the PSE provices means for controlling power supply (switching
it on and off) and for monitoring actual power provided at a port to
a specfic PD.
2.3. Scenario 3: Power probes and Smart meters
Today, very few devices are equipped with sufficient instrumentation
to measure their own actual power and accumulated energy consumption.
Often external probes are connected to the power supply for measuring
these propoerties for a single device or for a set of devices.
Homes, buildings, and data centers have smart meters that monitor and
report accumulated power consumption of an entire home, a set of
offices or a set of devices in data enters.
Power Distribution Unit (PDUs) attached to racks in data center and
other smart power strips are evolving with smart meters and remote
controllable power switches embedded for each socket.
2.4. Scenario 4: Mid-level managers
Sometomes it is useful to have mid-level managers that provide energy
management functions not just for themselves but also for a set of
associated devices. For example, a switch can provide energy
management functions for all devices connected to its ports, even if
these devices are not PoE PDs, but have their own power supply as,
for example, PCs connected to the switch.
2.5. Scenario 5: Gateways to building networks
Due to the potential energy savings, energy management of buildings
has received significant attention. There are gateway network
elements to manage the multiple components of a building energy
management network Heating Ventilating Air Conditioning (HVAC),
lighting, electrical, fire and emergency systems, elevators etc. The
gateway device provides power monitoring and control function for
other devices in the building network.
2.6. Scenario 6: Home energy gateways
Home energy gateway can be used for energy management of a home.
This gateway can manage the appliances (refrigerator, heating/
cooling, washing machine etc.) and interface with the electrical
Quittek, et al. Expires January 13, 2011 [Page 7]
Internet-Draft Requirements for Power Monitoring July 2010
grid. The gateway can implement policies based on demand and energy
pricing from the grid.
2.7. Scenario 7: Data center devices
Energy efficiency of data centers has become a fundamental challenges
of data center opertion. Energy management is conducted on different
aggregation levels, such as network level, Power Distribution Unit
(PDU) level, and server level.
2.8. Scenario 8: Battery powered devices
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
actual charge, age, and state of a battery are required.
3. Monitoring Requirements
3.1. Granularity of monitoring and control
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 and controlled 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
Quittek, et al. Expires January 13, 2011 [Page 8]
Internet-Draft Requirements for Power Monitoring July 2010
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.
3.2. Remote and Aggregated Monitoring
There are several ways power and energy consumption can be measured
and reported. Measurements can be conducted locally at the device
that consumes energy or remotely by a device that has access to the
power supply of another device.
Instrumentation for these measurements requires additional hardware.
Some cost-eficient applications measure power and energy consumption
aggregated for a set of devices, for example a PoE PSE reporting
these values per port group instead of per port, or a power
distribution unit that eports the values for all connected devices
instead of per socket.
If aggregated measurement is conducted, it is obvious that reporting
provides aggregated values. but agregated reporting can also be
combined with local measurement. A managed node may act as mid-level
manager or protocol converter for several devices that measure power
consumption by themselves, for example a home gateway or a gateway to
building networks. In this case, the reporting node may choose to
report for each device individual values or aggregated values from
groups of devices that transmitted their power and energy consumption
values to the reporting node.
Often it is sufficient and more cost efficient having a single device
measuring and providing power state and energy consumption
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 or it measures aggregated
values per port group for a set of devices.. 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
Quittek, et al. Expires January 13, 2011 [Page 9]
Internet-Draft Requirements for Power Monitoring July 2010
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.
3.3. Accuracy
Depending on how power and energy consumption values are obtained the
confidence in the reported value and its accuracy may vary. managed
nodes reporting values concerning themselves or other devices should
qualify the confidence in reported values and quantify the accuracy
of measurements, For accuracy reporting, the accuracy classes IEC
61850 should be considered.
3.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.
3.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:
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
For some network management tasks it may be desirable to receive
Quittek, et al. Expires January 13, 2011 [Page 10]
Internet-Draft Requirements for Power Monitoring July 2010
notifications from devices when components or the entire device
change their power state.
3.4.2. Energy Consumption Monitoring
Independent of 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.
Energy consumption of a device or a device's component is a quantity
for which the value may change continuously. 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.
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.
3.4.3. Power Quality
In addition to the quantity of power or energy, also power quality
should be reported according to IEC 62053-22 and IEC 60044-1.
3.4.4. 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:
Quittek, et al. Expires January 13, 2011 [Page 11]
Internet-Draft Requirements for Power Monitoring July 2010
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.
4. 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
on power state changes and high volume time series of energy
consumption values.
5. 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 they do not cover all of the requirements for
energy management.
Quittek, et al. Expires January 13, 2011 [Page 12]
Internet-Draft Requirements for Power Monitoring July 2010
5.1. Existing IETF Standards
There are already RFCs available that address a subset of the
requirements.
5.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].
The standby status provided by the ENTITY STATE MIB module is related
to power states required for energy management, but they are too
restricted for meeting all energy management requirements. For
energy management several more power states are required, such as
different sleep and operational states as defined by the Advanced
Configuration and Power Interface (ACPI) or the DMTF Power State
Management Profile [DMTF.DSP1027].
5.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.
The ENTITY SENSOR MIB module does not support reporting accuracy of
measurements according to the IEC / ANSI accuracy classes, which are
Quittek, et al. Expires January 13, 2011 [Page 13]
Internet-Draft Requirements for Power Monitoring July 2010
commonly in use for electric power and energy mesurements. The
ENTITY SENSOR 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
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.
UPS MIB provides information on the state of the UPS network. The
MIB module contains several variables identify the UPS entity (name,
model,..), the battery state, to characterize the input load to the
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
and Watts. The units of power measurement are RMS volts, RMS Amps
and are not based on Entity-Sensor MIB [RFC3433].
5.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 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 devices are
attached to which port of the power source equipment.
The POWER ETHERNET MIB does not report power and energy consumption
on a per port base, but can report aggregated values for groups of
ports. It does not use objects of the ENTITY MIB module for
identifying entities, although this module existed already when the
POWER ETHERNET MIB modules was standardized.
5.1.5. LLDP MED MIB
The Link Layer Discovery Protocol (LLDP) defined in IEEE 802.1ab is a
data link layer protocol used by network devices for advertising of
their identities, capabilities, and interconnections on a LAN
network. The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an
enhancement of LLDP known as LLDP-MED. The LLDP-MED enhancements
specifically address voice applications. LLDP-MED covers 6 basic
areas: capabilities discovery, LAN speed and duplex discovery,
network policy discovery, location identification discovery,
inventory discovery, and power discovery.
Quittek, et al. Expires January 13, 2011 [Page 14]
Internet-Draft Requirements for Power Monitoring July 2010
5.2. Existing standards of other bodies
5.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.
6. Suggested Actions
Based on the analysis of requirements in section Section 3 and the
discussion of monitoring models in section Section 4 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 3.
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.
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 [RFC5675], 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
Quittek, et al. Expires January 13, 2011 [Page 15]
Internet-Draft Requirements for Power Monitoring July 2010
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.
7. Acknowledgements
The authors would like to thank Ralf Wolter, for his first essay on
this draft.
8. Security Considerations
This memo currently does not impose any security considerations.
9. IANA Considerations
This memo has no actions for IANA..
10. References
10.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.
[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.
Quittek, et al. Expires January 13, 2011 [Page 16]
Internet-Draft Requirements for Power Monitoring July 2010
[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,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG
Messages", RFC 5675, 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@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@neclab.eu
Quittek, et al. Expires January 13, 2011 [Page 17]
Internet-Draft Requirements for Power Monitoring July 2010
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@neclab.eu
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
BE
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
Quittek, et al. Expires January 13, 2011 [Page 18]