[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                    J. Quittek, Ed.
Internet-Draft                                                 R. Winter
Intended status: Informational                                  T. Dietz
Expires: April 25, 2011                                  NEC Europe Ltd.
                                                               B. Claise
                                                         M. Chandramouli
                                                     Cisco Systems, Inc.
                                                        October 22, 2010


                   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 25, 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 April 25, 2011                 [Page 1]


Internet-Draft      Requirements for Power Monitoring       October 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  . . . . . . . . . .  6

   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 . . . . . . . . . . . . .  8
     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 . . . . . . . . . . . . . . . 12

   4.  Monitoring Models  . . . . . . . . . . . . . . . . . . . . . . 12

   5.  Control Requirements . . . . . . . . . . . . . . . . . . . . . 13

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




Quittek, et al.          Expires April 25, 2011                 [Page 2]


Internet-Draft      Requirements for Power Monitoring       October 2010


   7.  Suggested Actions  . . . . . . . . . . . . . . . . . . . . . . 16

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17

   11. Informative References . . . . . . . . . . . . . . . . . . . . 17

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18








































Quittek, et al.          Expires April 25, 2011                 [Page 3]


Internet-Draft      Requirements for Power Monitoring       October 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.  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
   o  Communication networks and IT systems
   o  Building networks
   o  Home networks
   o  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:
   o  full power state
   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)
   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



Quittek, et al.          Expires April 25, 2011                 [Page 4]


Internet-Draft      Requirements for Power Monitoring       October 2010


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



Quittek, et al.          Expires April 25, 2011                 [Page 5]


Internet-Draft      Requirements for Power Monitoring       October 2010


   (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



Quittek, et al.          Expires April 25, 2011                 [Page 6]


Internet-Draft      Requirements for Power Monitoring       October 2010


   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.






Quittek, et al.          Expires April 25, 2011                 [Page 7]


Internet-Draft      Requirements for Power Monitoring       October 2010


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





Quittek, et al.          Expires April 25, 2011                 [Page 8]


Internet-Draft      Requirements for Power Monitoring       October 2010


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



Quittek, et al.          Expires April 25, 2011                 [Page 9]


Internet-Draft      Requirements for Power Monitoring       October 2010


   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:






Quittek, et al.          Expires April 25, 2011                [Page 10]


Internet-Draft      Requirements for Power Monitoring       October 2010


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






Quittek, et al.          Expires April 25, 2011                [Page 11]


Internet-Draft      Requirements for Power Monitoring       October 2010


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





Quittek, et al.          Expires April 25, 2011                [Page 12]


Internet-Draft      Requirements for Power Monitoring       October 2010


5.  Control Requirements

   To realize the envisioned benefits of energy savings, just monitoring
   power states and energy consumption would not be sufficient.  Energy
   efficiency can be realized only by setting the network entities or
   components to energy saving power states when appropriate.

   With means for power state control, energy saving policies and
   control loops can be realized.  Policies may, for example, define
   different power state settings based on the time-of-day.  Control
   loops may, for example, change power states based on actual network
   load.

   Trivially, all entities being subject of energy management should
   have at least two power states, such as "on" and "off" or "on" and
   "sleep" to be set.  In many cases, it may be desirable to have more
   operational ("on" mode") and non-operational ("off"/"sleep" mode)
   power states.  This applies particularly to devices with a lot of
   configuration parameters that influence their energy consumption.
   Examples for specifications of power states of managed devices can be
   found in the Advanced Configuration and Power Interface (ACPI)
   [ACPI.R30b] or the DMTF Power State Management Profile
   [DMTF.DSP1027].


6.  Existing Standards

   This section analyzes existing standards for energy consumption and
   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 [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



Quittek, et al.          Expires April 25, 2011                [Page 13]


Internet-Draft      Requirements for Power Monitoring       October 2010


   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 [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) [ACPI.R30b]
   or the DMTF Power State Management Profile [DMTF.DSP1027].

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

   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.

   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 [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,



Quittek, et al.          Expires April 25, 2011                [Page 14]


Internet-Draft      Requirements for Power Monitoring       October 2010


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



Quittek, et al.          Expires April 25, 2011                [Page 15]


Internet-Draft      Requirements for Power Monitoring       October 2010


7.  Suggested Actions

   Based on the analysis of requirements in Section 3 and the discussion
   of monitoring models in Section 4 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.

   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], 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
   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.




Quittek, et al.          Expires April 25, 2011                [Page 16]


Internet-Draft      Requirements for Power Monitoring       October 2010


10.  IANA Considerations

   This memo has no actions for IANA..


11.  Informative 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.

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

   [ACPI.R30b]
              Hewlett-Packard Corporation, Intel Corporation, Microsoft
              Corporation, Phoenix Corporation, and Toshiba Corporation,
              "Advanced Configuration and Power Interface Specification,
              Revision 3.0b", October 2006.

   [DMTF.DSP1027]
              Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),



Quittek, et al.          Expires April 25, 2011                [Page 17]


Internet-Draft      Requirements for Power Monitoring       October 2010


              "Power State Management Profile", September 2008.


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


   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












Quittek, et al.          Expires April 25, 2011                [Page 18]


Internet-Draft      Requirements for Power Monitoring       October 2010


   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 April 25, 2011                [Page 19]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/