Skip to main content

Requirements for Energy Management
draft-ietf-eman-requirements-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6988.
Authors Juergen Quittek , Rolf Winter , Thomas Dietz , Benoît Claise , Mouli Chandramouli
Last updated 2012-07-03
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Dan Romascanu
IESG IESG state Became RFC 6988 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-eman-requirements-07
Network Working Group                                    J. Quittek, Ed.
Internet-Draft                                                 R. Winter
Intended status: Informational                                  T. Dietz
Expires: January 4, 2013                                 NEC Europe Ltd.
                                                               B. Claise
                                                         M. Chandramouli
                                                     Cisco Systems, Inc.
                                                            July 3, 2012

                   Requirements for Energy Management
                    draft-ietf-eman-requirements-07

Abstract

   This document defines requirements for standards specifications for
   energy management.  The requirements defined in this document concern
   monitoring functions as well as control functions.  In detail, the
   focus of the requirements is on the following features:
   identification of powered entities, monitoring of their Power State,
   power inlets, power outlets, actual power, power properties, received
   energy, provided energy, and contained batteries.  Further
   requirements are included to enable control of powered entities'
   power supply and Power State.  This document does not specify the
   features that must be implemented by compliant implementations but
   rather features that must be supported by standards for energy
   management.

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 4, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the

Quittek, et al.          Expires January 4, 2013                [Page 1]
Internet-Draft     Requirements for Energy Management          July 2012

   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.

Quittek, et al.          Expires January 4, 2013                [Page 2]
Internet-Draft     Requirements for Energy Management          July 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Conventional requirements for energy management  . . . . .  6
     1.2.  Specific requirements for energy management  . . . . . . .  6

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7

   3.  General Considerations Related to Energy Management  . . . . .  8
     3.1.  Power states . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Saving energy versus maintaining service level
           agreements . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Local versus network-wide energy management  . . . . . . .  9
     3.4.  Energy monitoring versus energy saving . . . . . . . . . . 10
     3.5.  Overview of energy management requirements . . . . . . . . 10

   4.  Identification of Powered Entities . . . . . . . . . . . . . . 10

   5.  Information on Powered Entities  . . . . . . . . . . . . . . . 11
     5.1.  General information on Powered Entities  . . . . . . . . . 12
     5.2.  Power Interfaces . . . . . . . . . . . . . . . . . . . . . 13
     5.3.  Power  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.4.  Power State  . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Energy . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.6.  Battery State  . . . . . . . . . . . . . . . . . . . . . . 19
     5.7.  Time series of measured values . . . . . . . . . . . . . . 20

   6.  Control of Powered Entities  . . . . . . . . . . . . . . . . . 21

   7.  Reporting on other Powered Entities  . . . . . . . . . . . . . 22

   8.  Controlling Other Powered Entities . . . . . . . . . . . . . . 23
     8.1.  Controlling Power States of other Powered Entities . . . . 23
     8.2.  Controlling power supply . . . . . . . . . . . . . . . . . 24

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24

   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25

   12. Informative References . . . . . . . . . . . . . . . . . . . . 25

   Appendix A.  Existing Standards  . . . . . . . . . . . . . . . . . 27
     A.1.  Existing IETF Standards  . . . . . . . . . . . . . . . . . 28
       A.1.1.  ENTITY MIB . . . . . . . . . . . . . . . . . . . . . . 28
       A.1.2.  ENTITY STATE MIB . . . . . . . . . . . . . . . . . . . 28
       A.1.3.  ENTITY SENSOR MIB  . . . . . . . . . . . . . . . . . . 29

Quittek, et al.          Expires January 4, 2013                [Page 3]
Internet-Draft     Requirements for Energy Management          July 2012

       A.1.4.  UPS MIB  . . . . . . . . . . . . . . . . . . . . . . . 29
       A.1.5.  POWER ETHERNET MIB . . . . . . . . . . . . . . . . . . 30
       A.1.6.  LLDP MED MIB . . . . . . . . . . . . . . . . . . . . . 30
     A.2.  Existing standards of other bodies . . . . . . . . . . . . 30
       A.2.1.  DMTF . . . . . . . . . . . . . . . . . . . . . . . . . 30
       A.2.2.  OVDA . . . . . . . . . . . . . . . . . . . . . . . . . 31
       A.2.3.  IEEE-ISTO Printer WG . . . . . . . . . . . . . . . . . 31

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

Quittek, et al.          Expires January 4, 2013                [Page 4]
Internet-Draft     Requirements for Energy Management          July 2012

1.  Introduction

   With rising energy cost and with an increasing awareness of the
   ecological impact of running IT equipment, energy management
   functions and interfaces are becoming an additional basic requirement
   for network management systems and devices connected to a network.

   This document defines requirements for standards specifications for
   energy management, both monitoring functions and control functions.
   In detail, the requirements listed are focused on the following
   features: identification of Powered Entities , monitoring of their
   Power State, power inlets, power outlets, actual power, power
   properties, received energy, provided energy, and contained
   batteries.  Further included is control of Powered Entities ' power
   supply and Power State.

   The main subject of energy management are devices and their
   components that receive and provide electric energy.  Devices may
   have an IP address, such as hosts, routers, and middleboxes, or they
   are connected indirectly to the Internet via a proxy with an IP
   address providing a management interface for the device.  An example
   are devices in a building infrastructure using non-IP protocols and a
   gateway to the Internet.

   These requirements concern the standards specification process and
   not the implementation of specified standards.  All requirements in
   this document must be reflected by standards specifications to be
   developed.  However, which of the features specified by these
   standards will be mandatory, recommended, or optional for compliant
   implementations is to be defined by standards track document(s) and
   not in this document.

   Section 3 elaborates a set of general needs for energy management.
   Requirements for an energy management standard are specified in
   Sections 4 to 8.

   Sections 4 to 6 contain conventional requirements specifying
   information on Powered Entities and control functions.

   Sections 7 and 8 contain requirements specific to energy management.
   Due to the nature of power supply, some monitoring and control
   functions are not conducted by interacting with the Powered Entity of
   interest, but with other entities, for example, entities upstream in
   a power distribution tree.

Quittek, et al.          Expires January 4, 2013                [Page 5]
Internet-Draft     Requirements for Energy Management          July 2012

1.1.  Conventional requirements for energy management

   The specification of requirements for an energy management standard
   starts with Section 4 addressing the identification of Powered
   Entities and the granularity of reporting of energy-related
   information.  A standard must support unique identification of
   powered entities, reporting per entire powered device, and reporting
   energy-related information on individual components of a device or
   subtended devices.

   Section 5 specifies requirements related to monitoring of Powered
   Entities .  This includes general (type, context) information and
   specific information on Power States, power inlets, power outlets,
   power, energy, and batteries.  Control Power State and power supply
   of Powered Entities is covered by requirements specified in
   Section 6.

1.2.  Specific requirements for energy management

   While the conventional requirements summarized above seem to be all
   that would be needed for energy management, there are significant
   differences between energy management and most well known network
   management functions.  The most significant difference is the need
   for some devices to report on other entities.  There are three major
   reasons for this.
   o  For monitoring a particular Powered Entity it is not always
      sufficient to communicate with the Powered Entity only.  When the
      Powered Entity has no instrumentation for determining power, it
      might still be possible to obtain power values for the entity by
      communication with other entities in its power distribution tree.
      A simple example is retrieving power values from a power meter at
      the power line into the Powered Entity.  Common examples are a
      Power Distribution Unit (PDU) and a Power over Ethernet (PoE)
      switch.  Both supply power to other entities at sockets or ports,
      respectively, and are often instrumented to measure power per
      socket or port.
   o  Similar considerations apply to controlling power supply of a
      Powered Entity which often needs direct or indirect communications
      with another entity upstream in the power distribution tree.
      Again, a PDU and a PoE switch are common examples, if they have
      the capability to switch on or off power at their sockets or
      ports, respectively.
   o  Energy management often extends beyond entities with IP network
      interfaces, to non-IP building systems accessed via a gateway.
      Requirements in this document do not cover details of these
      networks, but specify means for opening IP network management
      towards them.

Quittek, et al.          Expires January 4, 2013                [Page 6]
Internet-Draft     Requirements for Energy Management          July 2012

   These specific issues of energy management and a set of further ones
   are covered by requirements specified in Sections 7 and 8.

   The requirements in these sections need a new energy management
   framework that deals with the specific nature of energy management.
   The actual standards documents, such as MIB module specifications,
   address conformance by specifying which feature must, should, or may
   be implemented by compliant implementations.

2.  Terminology

   Energy

      That which does work or is capable of doing work.  As used by
      electric utilities, it is generally a reference to electrical
      energy and is measured in kilo-watt hours (kWh) [IEEE-100].

   Power

      The time rate at which energy is emitted, transferred, or
      received; usually expressed in watts (or in joules per second)
      [IEEE-100].

   Energy management

      Energy Management is a set of functions for measuring, modeling,
      planning, and optimizing networks to ensure that the network
      elements and attached devices use energy efficiently and is
      appropriate for the nature of the application and the cost
      constraints of the organization [ITU-M.3400].

   Energy management system

      An Energy Management System is a combination of hardware and
      software used to administer a network with the primary purpose
      being energy management [Fed-Std-1037C].

   Energy monitoring

      Energy monitoring is a part of energy management that deals with
      collecting or reading information from network elements and
      attached devices and their components to aid in energy management.

Quittek, et al.          Expires January 4, 2013                [Page 7]
Internet-Draft     Requirements for Energy Management          July 2012

   Energy control

      Energy control is a part of energy management that deals with
      directing influence over network elements and attached devices and
      their components.

   Powered Entity

      A Powered Entity is either a device or one of a device's
      components that is subject to energy monitoring or control or
      both.

   Power Interface

      A Power Interface is an interface at which a device is connected
      to a power transmission medium at which it can receive power,
      provice power, or both.

   Power inlet

      A power inlet is a Power Interface at which a device can receive
      power fro other devices.

   Power outlet

      A power outlet is a Power Interface at which a device can provide
      power to other devices.

   Power State

      A Power State is a condition or mode of a device that broadly
      characterizes its capabilities, power consumption, and
      responsiveness to input [IEEE-1621].

3.  General Considerations Related to Energy Management

   The basic objective of energy management is operating sets of devices
   with minimal energy, while maintaining a certain level of service.
   Use cases for energy management can be found in
   [I-D.ietf-eman-applicability-statement].

3.1.  Power states

   Powered Entities can be set to an operational state that results in
   the lowest power level that still meets the service level performance
   objectives.  In principle, there are four basic types of Power States
   for a Powered Entity or for a whole system:

Quittek, et al.          Expires January 4, 2013                [Page 8]
Internet-Draft     Requirements for Energy Management          July 2012

   o  full Power State
   o  reduced Power States (e.g. lower clock rate for processor, lower
      data rate on a link, etc.)
   o  sleep state (not functional, but immediately available)
   o  off state (may require significant time to become operational)
   In specific devices, the number of Power States and their properties
   varies considerably.  Simple powered entities may just have only the
   extreme states, full power and off state.  Many devices have three
   basic Power States: on, off, and sleep.  However, more finely grained
   Power States can be implemented with many levels of each Power State.

3.2.  Saving energy versus maintaining service level agreements

   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 without the consequence of a potential
   performance, service, or capacity degradation.  Then a trade-off
   needs to be dealt with between service level objectives and energy
   minimization.  In other cases a reduction of power can easily be
   achieved while still maintaining sufficient service level
   performance, for example, by switching Powered Entities to lower
   Power States when higher performance is not needed.

3.3.  Local versus network-wide energy management

   Many energy saving functions are executed locally by a Powered
   Entity; it monitors its usage and dynamically adapts its power
   according to the required performance.  It may, for example, switch
   to a sleep state when it is not in use or out of scheduled business
   hours.  An energy management system may observe an entity's power
   state and configure its power saving policies.

   Energy savings can also be achieved with policies implemented by a
   network management system that controls Power States of managed
   entities.  Information about the power received and provided by
   Powered Entities in different Power States may be required to set
   policies.  Often this information is acquired best through
   monitoring.

   Both methods, network-wide and local energy management, have
   advantages and disadvantages and often it is desirable to combine
   them.  Central management is often favorable for setting Power States
   of a large number of entities at the same time, for example, at the
   beginning and end of business hours in a building.  Local management
   is often preferable for power saving measures based on local
   observations, such as high or low load of an entity.

Quittek, et al.          Expires January 4, 2013                [Page 9]
Internet-Draft     Requirements for Energy Management          July 2012

3.4.  Energy monitoring versus energy saving

   Monitoring energy, power, and Power States alone does not reduce the
   energy needed to run a Powered Entity.  In fact, it may even increase
   it slightly due to monitoring instrumentation that needs energy.
   Reporting measured quantities over the network may also increase
   energy use, though the acquired information may be an essential input
   to control loops that save energy.

   Monitoring energy and Power States can also be required for other
   purposes including:
   o  investigating energy saving potential
   o  evaluating the effectiveness of energy saving policies and
      measures
   o  deriving, implementing, and testing power management strategies
   o  accounting for the total power received and provided by a Powered
      Entity, a network, or a service
   o  predicting a Powered Entity's reliability based on power usage
   o  choosing time of next maintenance cycle for a powered entity

3.5.  Overview of energy management requirements

   The following basic management functions are required:
   o  monitoring Power States
   o  monitoring power (energy conversion rate)
   o  monitoring (accumulated) received and provided energy
   o  monitoring power properties
   o  setting Power States

   Power control is complementary to other energy savings measures such
   as low power electronics, energy saving protocols, energy-efficient
   device design (for example, low-power modes for components), and
   energy-efficient network architectures.  Measurement of received and
   provided energy can provide useful data for developing these
   technologies.

4.  Identification of Powered Entities

   Powered Entities must be uniquely identified.  This includes entities
   that are components of managed devices as well as entire devices.

   For Powered Entities that report on or control other Powered Entities
   it is important to identify the Powered Entities they report on or
   control, see Section 7 or Section 8, respectively.

   An entity may be an entire device or a component of it.  Examples of
   components of interest are a hard drive, a battery, or a line card.

Quittek, et al.          Expires January 4, 2013               [Page 10]
Internet-Draft     Requirements for Energy Management          July 2012

   It may be required to be able to control individual components to
   save energy.  For example, server blades can be switched off when the
   overall load is low or line cards at switches may be powered down at
   night.

   Identifiers for devices and components are already defined in
   standard MIB modules, such as the LLDP MIB module [IEEE-802.1AB] and
   the LLDP-MED MIB module [ANSI-TIA-1057] for devices and the Entity
   MIB module [RFC4133] and the Power Ethernet MIB [RFC3621] for
   components of devices.  Energy management needs means to link energy-
   related information to such identifiers.

   Instrumentation for measuring received and provided energy of a
   device is typically more expensive than instrumentation for
   retrieving its Power State.  Many devices may provide Power State
   information for all individual components separately, while reporting
   the received and provided energy only for the entire device.

4.1.  Identifying Powered Entities

   The standard must provide means for uniquely identifying Powered
   Entities .  Uniqueness must be preserved such that collisions of
   identities are avoided at potential receivers of monitored
   information.

4.2.  Persistence of identifiers

   The standard must provide means for indicating whether identifiers of
   Powered Entities are persistent across a re-start of the Powered
   Entity.

4.3.  Using entity identifiers of other MIB modules

   The standard must provide means for re-using entity identifiers from
   other standards including at least the following:
   o  the entPhysicalIndex in the Entity MIB module [RFC4133]
   o  the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in
      the LLDP-MED MIB module [ANSI-TIA-1057]
   o  the pethPsePortIndex and the pethPsePortGroupIndex in the Power
      Ethernet MIB [RFC3621]
   Generic means for re-using other entity identifiers must be provided.

5.  Information on Powered Entities

   This section describes information on Powered Entities for which the
   standard must provide means for retrieving and reporting.

Quittek, et al.          Expires January 4, 2013               [Page 11]
Internet-Draft     Requirements for Energy Management          July 2012

   Required information can be structured into seven groups.
   Section 5.1 specifies requirements for general information on Powered
   Entities , such as type of powered entity or context information.
   Requirements for information on power inlets and power outlets of
   Powered Entities are specified in Section 5.2.  Monitoring of power
   and energy is covered by Sections 5.3 and 5.5, respectively.
   Section 5.4 covers requirements related to entities' Power States.
   Section 5.6 specifies requirements for monitoring batteries.
   Finally, the reporting of time series of values is covered by
   Section 5.7.

5.1.  General information on Powered Entities

   For energy management it may be required to understand the role and
   context of a Powered Entity.  An energy management system may
   aggregate values of received and provided energy according to a
   defined grouping of entities.  When controlling and setting Power
   States it may be helpful to understand the grouping of the entity and
   role of a Powered Entity in a network, for example, it may be
   important to exclude some vital network devices from being switched
   to lower power or even from being switched off.

5.1.1.  Type of Powered Entity

   The standard must provide means to configure, retrieve and report a
   textual name or a description of a powered entity.

5.1.2.  Context of Powered Entities

   The standard must provide means for retrieving and reporting context
   information on Powered Entities , for example, tags associated with a
   Powered Entity that indicate the Powered Entity's role.

5.1.3.  Significance of Powered Entities

   The standard must provide means for retrieving and reporting the
   significance of Powered Entities within its context, for example, how
   important the Powered Entity is.

5.1.4.  Power priority

   The standard must provide means for retrieving and reporting power
   priorities of Powered Entities .  Power priorities indicate an order
   in which Power States of Powered Entities are changed, for example,
   to lower Power States for saving power.

Quittek, et al.          Expires January 4, 2013               [Page 12]
Internet-Draft     Requirements for Energy Management          July 2012

5.1.5.  Grouping of Powered Entities

   The standard must provide means for grouping powered entities.  This
   can be achieved in multiple ways, for example, by providing means to
   tag Powered Entities , to assign them to domains, or to assign device
   types to them.

5.2.  Power Interfaces

   A Power Interface is either an inlet or an outlet.  Some Power
   Interfaces can change over time from being an inlet to being an
   outlet and vice versa.  However most power interfaces never change.

   Powered Entities have power inlets at which they are supplied with
   electric power.  Most Powered Entities have a single power inlet,
   while some have multiple inlets.  Different power inlets on a device
   are often connected to separate power distribution trees.  For energy
   monitoring, it is useful to retrieve information on the number of
   inlets of a Powered Entity, the availability of power at inlets and
   which of them are actually in use.

   Powered Entities can have one or more power outlets for supplying
   other Powered Entities with electric power.

   For identifying and potentially controlling the source of power
   received at an inlet, it may be required to identify the power outlet
   of another Powered Entity at which the received power is provided.
   Analogously, for each outlet it is of interest to identify the power
   inlets that receive the power provided at a certain outlet.  Such
   information is also required for constructing the wiring topology of
   electrical power distribution to Powered Entities .

   Static properties of each Power Interface are required information
   for energy management.  Static properties include the kind of
   electric current (AC or DC), the nominal voltage, the nominal AC
   frequency, and the number of AC phases.

5.2.1.  Lists of Power Interfaces

   The standard must provide means for monitoring the list of Power
   Interfaces.

5.2.2.  Corresponding power outlet

   The standard must provide means for identifying the power outlet that
   provides the power received at a power inlet.

Quittek, et al.          Expires January 4, 2013               [Page 13]
Internet-Draft     Requirements for Energy Management          July 2012

5.2.3.  Corresponding power inlets

   The standard must provide means for identifying the list of power
   inlets that receive the power provided at a power outlet.

5.2.4.  Availability of power

   The standard must provide means for monitoring the availability of
   power at each Power Interface.  This indicates whether at a Power
   Interfaces power supply is switched on or off.

5.2.5.  Use of power

   The standard must provide means for monitoring for each Power
   Interfaces if it is in actual use.  For inlets this means that the
   Powered Entity actually receives power at the inlet.  For outlets
   this means that power is actually provided from it to one or more
   powered entities.

5.2.6.  Type of current

   The standard must provide means for reporting the type of current (AC
   or DC) for each Power Interface as well as for an entire Powered
   Entity.

5.2.7.  Nominal voltage

   The standard must provide means for reporting the nominal voltage for
   each Power Interface.

5.2.8.  Nominal AC frequency

   The standard must provide means for reporting the nominal AC
   frequency for each Power Interface.

5.2.9.  Number of AC phases

   The standard must provide means for reporting the number of AC phases
   for each Power Interface.

5.3.  Power

   Power is measured as an instantaneous value or as the average over a
   time interval.

   Obtaining highly accurate values for power and energy may be costly
   if it requires dedicated metering hardware.  Powered Entities without
   the ability to measure their power and received and provided energy

Quittek, et al.          Expires January 4, 2013               [Page 14]
Internet-Draft     Requirements for Energy Management          July 2012

   with high accuracy may just report estimated values, for example
   based on load monitoring, Power State, or even just the entity type.

   Depending on how power and energy values are obtained, the confidence
   in the reported value and its accuracy will vary.  Powered Entities
   reporting such values should qualify the confidence in the reported
   values and quantify the accuracy of measurements.  For reporting
   accuracy, the accuracy classes specified in IEC 62053-21
   [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered.

   Further properties of the supplied power are also of interest.  For
   AC power supply, power attributes beyond the real power to be
   reported include the apparent power, the reactive power, and the
   phase angle of the current or the power factor.  For both AC and DC
   power the power characteristics are also subject of monitoring.
   Power parameters include the actual voltage, the actual frequency,
   the Total Harmonic Distortion (THD) of voltage and current, the
   impedance of an AC phase or of the DC supply.  Power monitoring
   should be in line with existing standards, such as [IEC.61850-7-4].

   For some network management tasks it is desirable to receive
   notifications from Powered Entities when their power value exceeds or
   falls below given thresholds.

5.3.1.  Real power

   The standard must provide means for reporting the real power for each
   Power Interface as well as for an entire Powered Entity.  Reporting
   power includes reporting the direction of power flow.

5.3.2.  Power measurement interval

   The standard must provide means for reporting the corresponding time
   or time interval for which a power value is reported.  The power
   value can be measured at the corresponding time or averaged over the
   corresponding time interval.

5.3.3.  Power measurement method

   The standard must provide means to indicate the method how these
   values have been obtained.  Based on how the measurement was
   conducted, it is possible to associate a certain degree of confidence
   with the reported power value.  For example, there are methods of
   measurement such as direct power measurement, or by estimation based
   on performance values, or hard coding average power values for a
   Powered Entity.

Quittek, et al.          Expires January 4, 2013               [Page 15]
Internet-Draft     Requirements for Energy Management          July 2012

5.3.4.  Accuracy of power and energy values

   The standard must provide means for reporting the accuracy of
   reported power and energy values.

5.3.5.  Actual voltage and current

   The standard must provide means for reporting the actual voltage and
   actual current for each power interface as well as for an entire
   Powered Entity.  In case of AC power supply, means must be provided
   for reporting the actual voltage and actual current per phase.

5.3.6.  High/low power notifications

   The standard must provide means for creating notifications if power
   values of a Powered Entity rise above or fall below given thresholds.

5.3.7.  Complex power

   The standard must provide means for reporting the complex power for
   each Power Interface and for each phase at a Power Interface.
   Besides the real power, at least two out of the following three
   quantities need to be reported: apparent power, reactive power, phase
   angle.  The phase angle can be substituted by the power factor.

5.3.8.  Actual AC frequency

   The standard must provide means for reporting the actual AC frequency
   for each Power Interface.

5.3.9.  Total harmonic distortion

   The standard must provide means for reporting the Total Harmonic
   Distortion (THD) of voltage and current for each Power Interface.  In
   case of AC power supply, means must be provided for reporting the THD
   per phase.

5.3.10.  Power supply impedance

   The standard must provide means for reporting the impedance of power
   supply for each Power Interface.  In case of AC power supply, means
   must be provided for reporting the impedance per phase.

5.4.  Power State

   Many Powered Entities have a limited number of discrete Power States.

   There is a need to report the actual Power State of a Powered Entity,

Quittek, et al.          Expires January 4, 2013               [Page 16]
Internet-Draft     Requirements for Energy Management          July 2012

   and means for retrieving the list of all supported Power States.

   Different standards bodies have already defined sets of Power States
   for some Powered Entities , and others are creating new Power State
   sets.  In this context, it is desirable that the standard support
   many of these power state standards.  In order to support multiple
   management systems possibly using different Power State sets, while
   simultaneously interfacing with a particular Powered Entity, the
   energy management standard must provide means for supporting multiple
   Power State sets used simultaneously at a powered entity.

   Power States have parameters that describe its properties.  It is
   required to have standardized means for reporting some key
   properties, such as average power and maximum power of a Powered
   Entity in a certain state.

   There also is a need to report statistics on Power States including
   the time spent and the received and provided energy in a Power State.

5.4.1.  Actual Power State

   The standard must provide means for reporting the actual Power State
   of a Powered Entity.

5.4.2.  List of supported Power States

   The standard must provide means for retrieving the list of all
   potential Power States of a Powered Entity.

5.4.3.  Multiple Power State sets

   The standard must provide means for supporting multiple Power State
   sets simultaneously at a Powered Entity.

5.4.4.  List of supported Power State sets

   The standard must provide means for retrieving the list of all Power
   State sets supported by a Powered Entity.

5.4.5.  List of supported Power States within a set

   The standard must provide means for retrieving the list of all
   potential Power States of a Powered Entity for each supported Power
   State set.

Quittek, et al.          Expires January 4, 2013               [Page 17]
Internet-Draft     Requirements for Energy Management          July 2012

5.4.6.  Maximum and average power per Power State

   The standard must provide means for retrieving the maximum power and
   the average power for each supported Power State.  These values may
   be static.

5.4.7.  Power State statistics

   The standard must provide means for monitoring statistics per Power
   State including the total time spent in a Power State, the number of
   times each state was entered and the last time each state was
   entered.  More Power State statistics are addressed by requirement
   5.5.3.

5.4.8.  Power State changes

   The standard must provide means for generating a notification when
   the actual Power State of a powered entity changes.

5.5.  Energy

   Monitoring of electrical energy received or provided by a Powered
   Entity is a core function of energy management.  Since energy is an
   accumulated quantity, it is always reported for a certain interval of
   time.  This can be, for example, the time from the last restart of
   the powered entity to the reporting time, the time from another past
   event to the reporting time, the last given amount of time before the
   reporting time, or a certain interval specified by two time stamps in
   the past.

   It is useful for Powered Entities to record their received and
   provided energy per Power State and report these quantities.

5.5.1.  Energy

   The standard must provide means for reporting measured values of
   energy and the direction of the energy flow received or provided by a
   Powered Entity.  The standard must also provide the means to report
   the energy passing through each Power Interface.

5.5.2.  Time intervals

   The standard must provide means for reporting the time interval for
   which an energy value is reported.

Quittek, et al.          Expires January 4, 2013               [Page 18]
Internet-Draft     Requirements for Energy Management          July 2012

5.5.3.  Energy per Power State

   The standard must provide means for reporting the received and
   provided energy for each individual power state.  This extends the
   requirement 5.4.7 on Power State statistics.

5.6.  Battery State

   Many Powered Entities contain batteries that supply them with power
   when disconnected from electrical power distribution grids.  The
   status of these batteries is typically controlled by automatic
   functions that act locally on the Powered Entity and manually by
   users of the powered entity.  There is a need to monitor the battery
   status of these entities by network management systems.

   Devices containing batteries can be modeled in two ways.  The entire
   device can be modeled as a single Powered Entity on which energy-
   related information is reported or the battery can be modeled as an
   individual Powered Entity for which energy-related information is
   monitored individually according to requirements in Sections 5.1 to
   5.5.

   Further information on batteries is of interest for energy
   management, such as the current charge of the battery, the number of
   completed charging cycles, the charging state of the battery, and
   further static and dynamic battery properties.  It is desirable to
   receive notifications if the charge of a battery becomes very low or
   if a battery needs to be replaced.

5.6.1.  Battery charge

   The standard must provide means for reporting the current charge of a
   battery.

5.6.2.  Battery charging state

   The standard must provide means for reporting the charging state
   (charging, discharging, etc.) of a battery.

5.6.3.  Battery charging cycles

   The standard must provide means for reporting the number of completed
   charging cycles of a battery.

5.6.4.  Actual battery capacity

   The standard must provide means for reporting the actual capacity of
   a battery.

Quittek, et al.          Expires January 4, 2013               [Page 19]
Internet-Draft     Requirements for Energy Management          July 2012

5.6.5.  Static battery properties

   The standard must provide means for reporting static properties of a
   battery, including the nominal capacity, the number of cells, the
   nominal voltage, and the battery technology.

5.6.6.  Low battery charge notification

   The standard must provide means for generating a notification when
   the charge of a battery decreases below a given threshold.

5.6.7.  Battery replacement notification

   The standard must provide means for generating a notification when
   the number of charging cycles of battery exceeds a given threshold.

5.6.8.  Multiple batteries

   The standard must provide means for meeting requirements 5.6.1 to
   5.6.7 for each individual battery contained in a single Powered
   Entity.

5.7.  Time series of measured values

   For some network management tasks, it is required to obtain time
   series of measured values from Powered Entities , such as power,
   energy, battery charge, etc.

   In general time series measurements could be obtained in many
   different ways.  It should be avoided that such time series can only
   be obtained through regular polling by the energy management system.
   Means should be provided to either push such values from the location
   where they are available to the management system or to have them
   stored locally for a sufficiently long period of time such that a
   management system can retrieve full time series.

   The following issues are to be considered when designing time series
   measurement and reporting functions:
   1.  Which quantities should be reported?
   2.  Which time interval type should be used (total, delta, sliding
       window)?
   3.  Which measurement method should be used (sampled, continuous)?
   4.  Which reporting model should be used (push or pull)?

   The most discussed and probably most needed quantity is energy.  But
   a need for others, such as power and battery charge can be identified
   as well.

Quittek, et al.          Expires January 4, 2013               [Page 20]
Internet-Draft     Requirements for Energy Management          July 2012

   There are three time interval types under discussion for accumulated
   quantities such as energy.  They can be reported as total values,
   accumulated between the last restart of the measurement and a certain
   timestamp.  Alternatively, energy can be reported as delta values
   between two consecutive timestamps.  Another alternative is reporting
   values for sliding windows as specified in [IEC.61850-7-4].

   For non-accumulative quantities, such as power, different measurement
   methods are considered.  Such quantities can be reported using values
   sampled at certain time stamps or alternatively by mean values for
   these quantities averaged between two (consecutive) time stamps or
   over a sliding window.

   Finally, time series can be reported using different reporting
   models, particularly push-based or pull-based.  Push-based reporting
   can, for example, be realized by reporting power or energy values
   using the IPFIX protocol [RFC5101],[RFC5102].  SNMP [RFC3411] is an
   example for a protocol that can be used for realizing pull-based
   reporting of time series.

   For reporting time series of measured values the following
   requirements have been identified.  Further decisions concerning
   issues discussed above need to be made when developing concrete
   energy management standards.

5.7.1.  Time series of energy values

   The standard must provide means for reporting time series of energy
   values.

5.7.2.  Time series storage capacity

   The management standard should provide means for reporting the number
   of values of a time series that can be stored for later reporting.

6.  Control of Powered Entities

   Many Powered Entities control their Power State locally.  Other
   Powered Entities need interfaces for an energy management system to
   control their Power State.

   Power supply is typically not self-managed by powered entities.  And
   controlling power supply is typically not conducted as interaction
   between energy management system and the Powered Entity itself.  It
   is rather an interaction between the management system and an entity
   providing power at its power outlets.  Similar to Power State
   control, power supply control may be policy driven.  Note that

Quittek, et al.          Expires January 4, 2013               [Page 21]
Internet-Draft     Requirements for Energy Management          July 2012

   shutting down the power supply abruptly may have severe consequences
   for the Powered Entity.

6.1.  Controlling Power States

   The standard must provide means for setting Power States of Powered
   Entities .

6.2.  Controlling power supply

   The standard must provide means for switching power supply off or
   turning power supply on at power outlets providing power to one or
   more Powered Entity.

7.  Reporting on other Powered Entities

   As discussed in Section 5, not all energy-related information may be
   available at the concerned Powered Entity.  Such information may be
   provided by other Powered Entities .  This section covers reporting
   of information only.  See Section 8 for requirements on controlling
   other Powered Entities .

   There are cases where a power supply unit switches power for several
   Powered Entities by turning power on or off at a single power outlet
   or where a power meter measures the accumulated power of several
   Powered Entities at a single power line.  Consequently, it should be
   possible to report that a monitored value does not relate to just a
   single Powered Entity, but is an accumulated value for a set of
   Powered Entities .  All of these Powered Entities belonging to that
   set need to be identified.

   If a Powered Entity has information about where energy-related
   information on itself can be retrieved, then it would be useful to
   communicate this information.  This applies even if the information
   only provides accumulated quantities for several Powered Entities .

7.1.  Reports on other Powered Entities

   The standard must provide means for a Powered Entity to report
   information on another Powered Entity.

7.2.  Identity of other Powered Entities  on which is reported

   For entities that report on one or more other entities, the standard
   must provide means for reporting the identity of other Powered
   Entities on which information is reported.

Quittek, et al.          Expires January 4, 2013               [Page 22]
Internet-Draft     Requirements for Energy Management          July 2012

7.3.  Reporting quantities accumulated over multiple Powered Entities

   The standard must provide means for reporting the list of all Powered
   Entities from which contributions are included in an accumulated
   value.

7.4.  List of all Powered Entities  on which is reported

   For entities that report on one or more other entities, the standard
   must provide means for reporting the complete list of all those
   Powered Entities on which energy-related information can be reported.

7.5.  Content of reports on other Powered Entities

   For entities that report on one or more other entities, the standard
   must provide means for indicating which energy-related information
   can be reported for which of those Powered Entities .

7.6.  Indicating source of remote information

   For an entity that has one or more other entities reporting on its
   behalf, the standard must provide means for the entity to indicate
   which information is available at which other entity.

8.  Controlling Other Powered Entities

   This section specifies requirements for controlling Power States and
   power supply of Powered Entities by communicating with other Powered
   Entities that have means for controlling Power State or power supply
   of others.

8.1.  Controlling Power States of other Powered Entities

   Some Powered Entities have control over Power States of other Powered
   Entities .  For example a gateway to a building system may have means
   to control the Power State of powered entities in the building that
   do not have an IP interface.  For this scenario and other similar
   cases means are needed to make this control accessible to the energy
   management system.

   In addition to this, it is required that a Powered Entity that has
   its state controlled by other Powered Entities has means to report
   the list of these other Powered Entities .

Quittek, et al.          Expires January 4, 2013               [Page 23]
Internet-Draft     Requirements for Energy Management          July 2012

8.1.1.  Control of Power States of other Powered Entities

   The standard must provide means for an energy management system to
   send Power State control commands to a Powered Entity that concern
   the Power States of other Powered Entities than the one the command
   was sent to.

8.1.2.  Identity of other Power State controlled entities

   The standard must provide means for reporting the identities of the
   Powered Entities for which the reporting Powered Entity has means to
   control their Power States.

8.1.3.  List of all Power State controlled entities

   The standard must provide means for a Powered Entity to report the
   list of all Powered Entities for which it can control the Power
   State.

8.1.4.  List of all Power State controllers

   The standard must provide means for a Powered Entity that receives
   commands controlling its Power State from other Powered Entities to
   report the list of all those entities.

8.2.  Controlling power supply

   Some Powered Entities may have control of the power supply of other
   Powered Entities , for example, because the other Powered Entity is
   supplied via a power outlet of the Powered Entity.  For this and
   similar cases means are needed to make this control accessible to the
   energy management system.  This need is already addressed by
   requirement 6.2.

   In addition, it is required that a Powered Entity that has its supply
   controlled by other Powered Entities has means to report the list of
   these other Powered Entities .  This need is already addressed by
   requirements 5.2.2 and 5.2.3.

9.  Security Considerations

   Controlling Power State and power supply of powered entities are
   highly sensitive actions since they can significantly affect the
   operation of directly and indirectly affected devices.  Therefore all
   control actions addressed in 6 and 8 must be sufficiently protected
   through authentication, authorization, and integrity protection
   mechanisms.

Quittek, et al.          Expires January 4, 2013               [Page 24]
Internet-Draft     Requirements for Energy Management          July 2012

   Monitoring energy-related quantities of a Powered Entity addressed in
   Sections 5 - 8 can be used to derive more information than just the
   received and provided energy, so monitored data requires privacy
   protection.  Monitored data may be used as input to control,
   accounting, and other actions, so integrity of transmitted
   information and authentication of the origin may be needed.

9.1.  Secure energy management

   The standard must provide privacy, integrity, and authentication
   mechanisms for all actions addressed in Sections 5 - 8.  The security
   mechanisms must address all threats listed in Section 1.4 of
   [RFC3411].

10.  IANA Considerations

   This document has no actions for IANA.

11.  Acknowledgements

   The authors would like to thank Ralf Wolter for his first essay on
   this draft.  Many thanks to William Mielke, John Parello, Bruce
   Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff
   for helpful comments on the draft.

12.  Informative References

   [RFC1628]  Case, J., "UPS Management Information Base", RFC 1628,
              May 1994.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
              Management Information Base", RFC 3433, December 2002.

   [RFC3621]  Berger, A. and D. Romascanu, "Power Ethernet MIB",
              RFC 3621, December 2003.

   [RFC3805]  Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",
              RFC 3805, June 2004.

   [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",

Quittek, et al.          Expires January 4, 2013               [Page 25]
Internet-Draft     Requirements for Energy Management          July 2012

              RFC 4133, August 2005.

   [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
              November 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.

   [I-D.ietf-eman-applicability-statement]
              Silver, L., Chandramouli, M., and B. Nordman, "Energy
              Management (EMAN) Applicability Statement",
              draft-ietf-eman-applicability-statement-01 (work in
              progress), June 2012.

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

   [ANSI-TIA-1057]
              Telecommunications Industry Association, "ANSI-TIA-1057-
              2006 - TIA Standard - Telecommunications -  IP Telephony
              Infrastructure - Link Layer Discovery  Protocol for Media
              Endpoint Devices", April 2006.

   [DMTF.DSP1027]
              Dasari (ed.), R., Davis (ed.), J., and J. Hilland (ed.),
              "Power State Management Profile", September 2008.

   [Fed-Std-1037C]
              United States National Communications System Technology &
              Standards Division, "Federal Standard 1037C -
              Telecommunications:  Glossary of Telcommunication Terms",
              August 1996.

   [IEEE-ISTO]
              Printer Working Group, "PWG 5106.4 - PWG Power Management
              Model for Imaging  Systems 1.0", February 2011.

   [IEEE-100]
              IEEE, "Authoritative Dictionary of IEEE Standards Terms,
              IEEE 100, Seventh Edition", December 2000.

Quittek, et al.          Expires January 4, 2013               [Page 26]
Internet-Draft     Requirements for Energy Management          July 2012

   [IEC.62053-21]
              International Electrotechnical Commission, "Electricity
              metering equipment (a.c.) - Particular requirements - Part
              22: Static meters for active energy  (classes 1 and 2)",
              2003.

   [IEC.62053-22]
              International Electrotechnical Commission, "Electricity
              metering equipment (a.c.) - Particular requirements - Part
              22: Static meters for active energy  (classes 0,2 S and
              0,5 S)", 2003.

   [IEC.61850-7-4]
              International Electrotechnical Commission, "Communication
              networks and systems for power utility automation - Part
              7-4: Basic communication structure - Compatible logical
              node classes and data object classes", 2010.

   [IEEE-1621]
              Institute of Electrical and Electronics  Engineers, "IEEE
              P1621-2004 -Draft Standard for User Interface   Elements
              in Power Control of Electronic Devices Employed in Office
              Consumer Environments", June 2005.

   [IEEE-802.1AB]
              IEEE Computer Society, "IEEE Std 802.1AB-2009 - IEEE
              Standard for Local and metropolitan area networks -
              Station and Media Access Control Discovery", September
              2009.

   [ITU-M.3400]
              International Telcommunication Union, "ITU-T
              Recommendation M.3400 - Series M: TMN and Network
              Maintenance: International Transmission Systems,
              Telephone Circuits, Telegraphy, Facsimile and Leased
              Circuits - Telecommunications Management Network -  TMN
              management functions", February 2000.

Appendix A.  Existing Standards

   This section analyzes existing standards for energy and Power State
   monitoring.  It shows that there are already several standards that
   cover only 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 4, 2013               [Page 27]
Internet-Draft     Requirements for Energy Management          July 2012

A.1.  Existing IETF Standards

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

A.1.1.  ENTITY MIB

   The ENTITY-MIB module defined in [RFC4133] was designed to model
   physical and logical entities of a managed system.  A physical entity
   is an identifiable physical component.  A logical entity can use one
   or more physical entities.  From an energy monitoring perspective of
   a managed system, the ENTITY-MIB modeling framework can be reused and
   whenever RFC 4133 [RFC4133] has been implemented.  The
   entPhysicalIndex from entPhysicalTable can be used to identify an
   entity/component.  However, there are use cases of energy monitoring,
   where the application of the ENTITY-MIB does not seem readily
   apparent and some of those entities could be beyond the original
   scope and intent of the ENTITY-MIB.

   Consider the case of remote devices attached to the network, and the
   network device could collect the energy measurement and report on
   behalf of such attached devices.  Some of the remote devices such as
   PoE phones attached to a switch port have been considered in the
   Power-over-Ethernet MIB module [RFC3621].  However, there are many
   other devices such as a computer, which draw power from a wall outlet
   or building HVAC devices which seem to be beyond the original scope
   of the ENTITY-MIB.

   Yet another example, is smart-PDUs, which can report the energy
   provided to the device attached to the power outlet of the PDU.  In
   some cases, the device can be attached to multiple to power outlets.
   Thus, the energy measured at multiple outlets need to be aggregated
   to determine the energy provided to a single device.  From mapping
   perspective, between the PDU outlets and the device this is a many-
   to-one mapping.  It is not clear if such a many-to-one mapping is
   feasible within the ENTITY-MIB framework.

A.1.2.  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 for policy decisions and for
   other network management tasks.  However, the number of states would
   cover only a small subset of the requirements for Power State

Quittek, et al.          Expires January 4, 2013               [Page 28]
Internet-Draft     Requirements for Energy Management          July 2012

   monitoring and it does not provide means for energy monitoring.  For
   associating the information conveyed by the ENTITY STATE MIB 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].

A.1.3.  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 meter delivering
   measured values in Watt.  This could be used for reporting current
   power of an entity and its components.  Furthermore, the ENTITY
   SENSOR MIB can be used to retrieve the accuracy 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.

A.1.4.  UPS MIB

   RFC 1628 [RFC1628] defines the UPS MIB module.  Implementations of
   this module provide information on the current real power of entities
   attached to an uninterruptible power supply (UPS) device.  This
   application would require identifying which entity 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 that are used to identify the
   UPS entity (name, model,..), the Battery State, to characterize the

Quittek, et al.          Expires January 4, 2013               [Page 29]
Internet-Draft     Requirements for Energy Management          July 2012

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

A.1.5.  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 the entities 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 entities
   are attached to which port of the power sourcing equipment.

   The POWER ETHERNET MIB does not report power and energy 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.

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

A.2.  Existing standards of other bodies

A.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 it is rather an entity profile
   than an actual energy 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 an entity (e.g. to shutdown the entity)
   which is an aspect of but not sufficient for active energy
   management.

Quittek, et al.          Expires January 4, 2013               [Page 30]
Internet-Draft     Requirements for Energy Management          July 2012

A.2.2.  OVDA

   ODVA is an association consisting of members from industrial
   automation companies.  ODVA supports standardization of network
   technologies based on the Common Industrial Protocol (CIP).  Within
   ODVA, there is a special interest group focused on energy and
   standardization and inter-operability of energy aware entities.

A.2.3.  IEEE-ISTO Printer WG

   The charter of the IEEE-ISTO Printer Working Group is for open
   standards that define printer related protocols, that printer
   manufacturers and related software vendors shall benefit from the
   interoperability provided by conformance to these standards.  One
   particular aspect the Printer WG is focused on is power monitoring
   and management of network printers and imaging systems PWG Power
   Management Model for Imaging Systems [IEEE-ISTO].  Clearly, these
   devices are within the scope of energy management since these devices
   receive power and are attached to the network.  In addition, there is
   ample scope of power management since printers and imaging systems
   are not used that often.  IEEE-ISTO Printer working group has defined
   MIB modules for monitoring power and Power State series that can be
   useful for power management of printers.  The energy management
   framework should also take into account the standards defined in the
   Printer working group.  In terms of other standards, IETF Printer MIB
   RFC3805 [RFC3805] has been standardized, however, this MIB module
   does not address power management of printers.

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

Quittek, et al.          Expires January 4, 2013               [Page 31]
Internet-Draft     Requirements for Energy Management          July 2012

   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

   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 4, 2013               [Page 32]