Requirements for Power Monitoring
draft-quittek-power-monitoring-requirements-02

Abstract

This memo discusses requirements for energy management, particularly for monitoring energy consumption and controlling power states of managed 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 April 28, 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 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
    1.1.  Energy management functions
    1.2.  Specific aspects of energy management

2.  Scenarios and target devices
    2.1.  Scenario 1: Routers, switches, middleboxes, and hosts
    2.2.  Scenario 2: PoE sourcing equipment and PoE powered devices
    2.3.  Scenario 3: Power probes and Smart meters
    2.4.  Scenario 4: Mid-level managers
    2.5.  Scenario 5: Gateways to building networks
    2.6.  Scenario 6: Home energy gateways
    2.7.  Scenario 7: Data center devices
    2.8.  Scenario 8: Battery powered devices

3.  Monitoring Requirements
    3.1.  Granularity of monitoring and control
    3.2.  Remote and Aggregated Monitoring
    3.3.  Accuracy
    3.4.  Required Information
        3.4.1.  Power State Monitoring
        3.4.2.  Energy Consumption Monitoring
        3.4.3.  Power Quality
        3.4.4.  Battery State Monitoring

4.  Monitoring Models

5.  Control Requirements

6.  Existing Standards
    6.1.  Existing IETF Standards
        6.1.1.  ENTITY STATE MIB
        6.1.2.  ENTITY SENSOR MIB
        6.1.3.  UPS MIB
        6.1.4.  POWER ETHERNET MIB
        6.1.5.  LLDP MED MIB
    6.2.  Existing standards of other bodies
        6.2.1.  DMTF

7.  Suggested Actions

8.  Acknowledgements

9.  Security Considerations

10.  IANA Considerations

11.  Informative References

§  Authors' Addresses

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. Requirements in this document do not fully cover all these networks, but they cover means for opening IP network 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

• Communication networks and IT systems
• Building networks
• Home networks
• Smart (power) grids

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 the power consumption of individual components of a network as well as of the whole network.

One approach to achieve this goal is setting all components to an operational state 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. In principle, there are four basic types of power states for a component or for a whole system:

• full power state
• reduced power states (lower clock rate for processor, lower data rate on a link, etc.)
• stand-by/sleep state (not functional, but immediately available)
• power-off state (requiring significant time for becoming 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 way to attain that goal is often difficult. In many cases there is no way of reducing power consumption without the consequence of a potential 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 consumption 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 acquired best through monitoring.

Monitoring operational power states and energy consumption is also useful for other energy management purposes including but not limited to

• investigating power saving potential
• evaluating the effectiveness of energy saving policies and measures
• deriving, implementing, and testing power management strategies
• 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:

• monitoring power states of network elements and their subcomponents
• monitoring actual power (energy consumption rate) of network elements and their subcomponents
• monitoring (accumulated) energy consumption of network elements and their subcomponents
• setting power states of network elements and their subcomponents
• 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. In fact, it is likely to increase the power consumption of a device slightly. However, the acquired energy consumption and power state information is essential fordefining 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 complementary (but essential) to other energy savings measures such as low power electronics, energy saving protocols (e.g. IEEE 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 management that make it different from other common network management functions. The first difference is that energy consumption is often measured remotely to the device under consideration. A reason for this is that today very few devices are instrumented with the hardware and software for measuring their own current power and accumulated energy consumption. Often power and energy for such devices is measured by other devices.

A common example 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 often it is desirable to apply energy management also to networks and devices that do not communicate via IP, for example, in building networks where besides IP several other communication protocols 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.

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 network devices is considered 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.

2.2.  Scenario 2: PoE sourcing equipment and PoE powered devices

This scenario covers devices using Power over 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 provides means for controlling power supply (switching it on and off) and for monitoring actual power provided at a port to a specific 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 properties 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 centers.

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

Sometimes 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 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 operation. 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 could be monitored and controlled individually:

• Physical view: chassis (or stack), central control engine, line cards, service cards, etc.
• Component view: CPU, ASICs, fans, power supply, ports (single ports and port groups), storage and memory
• Feature view: L2 forwarding, L3 routing, security features, load balancing features, network management, etc.
• Logical view: system, data-plane, control-plane, etc.
• 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 typically 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.

3.2.  Remote and Aggregated Monitoring

There are several ways power and energy consumption can be measured and reported. Measurements can be performed locally at the device that consumes energy or remotely by a device that has access to the power supply of another device.

Instrumentation for power and energy measurements at a device requires additional hardware. A cost-efficient alternative is measuring 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 reports the values for all connected devices instead of per socket.

If aggregated measurement is conducted, it is obvious that reporting provides aggregated values. but aggregated reporting can also be combined with local measurements. 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 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 specified in 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:

• the current state - the time of the last change
• the cause for the last transition
• time to transit from one stage to another
• the total time spent in each state
• the duration of the last period spent in each state
• the number of transitions to each state
• the current power source

For some network management tasks it may be desirable to receive 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:

• the current real power (energy consumption rate) averaged over a short time interval
• total energy consumption
• energy consumption since the last report or for the last configured time interval
• total energy consumption per power state
• 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:

• the current charge of the battery
• the age of the battery
• the state of the battery (e.g. being re-charged)
• last usage of the battery
• 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] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.)) or in push mode (for example SNMP notification [RFC3410] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.), Syslog [RFC5424] (Gerhards, R., “The Syslog Protocol,” March 2009.), or IPFIX [RFC5101] (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.)).

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.  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) (Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Corporation, and Toshiba Corporation, “Advanced Configuration and Power Interface Specification, Revision 3.0b,” October 2006.) [ACPI.R30b] or the DMTF Power State Management Profile (Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), “Power State Management Profile,” September 2008.) [DMTF.DSP1027].

6.  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.

6.1.  Existing IETF Standards

There are already RFCs available that address a subset of the requirements.

6.1.1.  ENTITY STATE MIB

RFC 4268 (Chisholm, S. and D. Perkins, “Entity State MIB,” November 2005.) [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, the number of states would cover only a small subset of the requirements for power state monitoring and it does not provide means for energy consumption monitoring. For associating the provided information to specific components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module (Bierman, A. and K. McCloghrie, “Entity MIB (Version 3),” August 2005.) [RFC4133]. Particularly, it uses the entPhysicalIndex for identifying entities.

The standby status provided by the ENTITY STATE MIB module is related to power states required for energy management, but the number of states is 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) (Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Corporation, and Toshiba Corporation, “Advanced Configuration and Power Interface Specification, Revision 3.0b,” October 2006.) [ACPI.R30b] or the DMTF Power State Management Profile (Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), “Power State Management Profile,” September 2008.) [DMTF.DSP1027].

6.1.2.  ENTITY SENSOR MIB

RFC 3433 (Bierman, A., Romascanu, D., and K. Norseth, “Entity Sensor Management Information Base,” December 2002.) [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.

Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB module makes use of the means provided by the ENTITY MIB module (Bierman, A. and K. McCloghrie, “Entity MIB (Version 3),” August 2005.) [RFC4133] for relating provided information to components of a device.

However, there is no unit available for reporting energy quantities, such as, for example, watt seconds or kilowatt hours, and the ENTITY SENSOR MIB module does not support reporting accuracy of measurements according to the IEC / ANSI accuracy classes, which are commonly in use for electric power and energy measurements. 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.

6.1.3.  UPS MIB

RFC 1628 (Case, J., “UPS Management Information Base,” May 1994.) [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 identifying 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 measurements of power in UPS MIB are in Volts, Amperes and Watts. The units of power measurement are RMS volts, RMS Amperes and are not based on Entity-Sensor MIB [RFC3433].

6.1.4.  POWER ETHERNET MIB

Similar to the UPS MIB, implementations of the POWER ETHERNET MIB module defined in RFC3621 (Berger, A. and D. Romascanu, “Power Ethernet MIB,” December 2003.) [RFC3621] provide information on the current energy consumption of the devices that receive Power over Ethernet (PoE). This information can be retrieved at the power sourcing equipment. Analogous to the UPS MIB, it is required to identify which devices are attached to which port of the power sourcing equipment.

The POWER ETHERNET MIB does not report power and energy consumption 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 identifying entities, although this module existed already when the POWER ETHERNET MIB modules was standardized.

6.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.

6.2.  Existing standards of other bodies

6.2.1.  DMTF

The DMTF has defined a power state management profile (Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.), “Power State Management Profile,” September 2008.) [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 management.

7.  Suggested Actions

Based on the analysis of requirements in Section 3 (Monitoring Requirements) and the discussion of monitoring models in Section 4 (Monitoring Models) this memo proposes to develop a standard for pull-based monitoring of power states, energy consumption, and battery states. The analysis of existing MIB modules in the previous section shows that they are not sufficient to meet the requirements discussed in Section 3 (Monitoring Requirements).

As a consequence, it suggested to develop one or more MIB modules 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. 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 transmitting 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] (Marinov, V. and J. Schoenwaelder, “Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages,” October 2009.), but IPFIX provides better means. With the extensible IPFIX information model [RFC5102] (Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, “Information Model for IP Flow Information Export,” January 2008.) 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 suggests that the definition of such information elements should be conducted within the IETF and they should be documented in a standards track RFC.

8.  Acknowledgements

The authors would like to thank Ralf Wolter, for his first essay on this draft.

9.  Security Considerations

This memo currently does not impose any security considerations.

10.  IANA Considerations

This memo has no actions for IANA..

11. Informative References

Authors' Addresses