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

Versions: 00 01 02

Network Working Group                                         B. Nordman
Internet-Draft                                Lawrence Berkeley National
Intended status: Informational                                Laboratory
Expires: September 16, 2011                                    R. Winter
                                                         NEC Labs Europe
                                                          March 15, 2011


             Considerations for Power and Energy Management
                    draft-norwin-energy-consider-02

Abstract

   With rising cost and an increasing awareness of the environmental
   impact of energy consumption, a desirable feature of networked
   devices is to be able to assess their power state and energy
   consumption at will.  With this data available, one can build
   sophisticated applications such as monitoring applications or even
   active energy management systems.  These systems themselves are out
   of scope of this memo, as it discusses only considerations for the
   monitored devices.  Implementation specifics such as the definition
   of a Management Information Base are also outside the scope of this
   document.

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 September 16, 2011.

Copyright Notice

   Copyright (c) 2011 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



Nordman & Winter       Expires September 16, 2011               [Page 1]


Internet-Draft               Consider Energy                  March 2011


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview/Goals . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Settled topics . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Scope of Devices . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Identity . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Power Levels . . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Devices  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.5.  Intervals  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Presentation to non-IETF audiences . . . . . . . . . . . .  6
     3.7.  Functions vs. Entities . . . . . . . . . . . . . . . . . .  6
     3.8.  Simple and Complex Devices . . . . . . . . . . . . . . . .  6
   4.  Topics under discussion  . . . . . . . . . . . . . . . . . . .  7
     4.1.  Power States . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Energy Manangement . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Control  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Identity . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  NMS Considerations . . . . . . . . . . . . . . . . . . . .  9
     5.4.  MIB Considerations . . . . . . . . . . . . . . . . . . . .  9
     5.5.  Power Considerations . . . . . . . . . . . . . . . . . . . 10
     5.6.  Incomplete data  . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Time reporting . . . . . . . . . . . . . . . . . . . . . . 10
     5.8.  Portable devices . . . . . . . . . . . . . . . . . . . . . 10
     5.9.  Beyond energy  . . . . . . . . . . . . . . . . . . . . . . 11
     5.10. Power State Monitoring . . . . . . . . . . . . . . . . . . 11
     5.11. Power Distribution . . . . . . . . . . . . . . . . . . . . 11
   6.  Use Context and Use Cases  . . . . . . . . . . . . . . . . . . 12
   7.  Future Directions  . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16










Nordman & Winter       Expires September 16, 2011               [Page 2]


Internet-Draft               Consider Energy                  March 2011


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Nordman & Winter       Expires September 16, 2011               [Page 3]


Internet-Draft               Consider Energy                  March 2011


2.  Overview/Goals

   This document aims at framing discussions on power and energy
   management within the IETF and recording their results.  It clarifies
   terminology that is routinely used to have multiple contrary
   meanings, which results in unnecessary confusion.  The document
   further describes how energy and power reporting differs from other
   reporting tasks that have been defined by the IETF and the resulting
   implications for mechanisms the IETF will define.  This document is
   intended to be a living document that also captures why certain
   decisions were made in the process of defining power and energy
   management mechanisms.







































Nordman & Winter       Expires September 16, 2011               [Page 4]


Internet-Draft               Consider Energy                  March 2011


3.  Settled topics

   The following are topics that seem settled in eman discussions,
   recognizing that this draft has no authority on that point.

3.1.  Scope of Devices

   All energy-using devices that have a network connection are in scope.
   The eman mechanisms also provide for non-IP devices that are supplied
   with power or that have power metered by an IP device, or are brought
   into the eman context by a gateway/proxy.

   While first adopters will surely be devices such as switches,
   routers, and servers (some of which already report power levels and
   power state through proprietary means), in the future networked
   electronic devices, appliances, and even lights will also need such
   capability.  These devices may have different ways of accomplishing
   discovery and management for functional purposes, but will share the
   common energy and power reporting capability.  While some devices
   will directly measure power, other devices will not be able to
   measure their power, but may be able to reliably estimate it.  These
   devices are still in scope.

3.2.  Identity

   Some universal mechanisms for identity are needed so that the NMS
   knows what the devices are that are using energy.  The nature of
   these mechanisms, whether they are existing ones to be referenced or
   new ones to be created (almost certainly some of both) has not yet
   been determined.

3.3.  Power Levels

   The power level of a device is its current electricity demand.  It is
   an important complement to power mode, providing articulation of
   power level within the basic mode.  It also avoids the need for a
   large number of named modes.  Basic modes are distinguished by
   important functional differences or power levels.  Core power modes
   are an abstraction from individual implementations.

3.4.  Devices

   The organizing unit for power is a single device with one or more
   power sources.  The term "product" is sometimes used as a synonym,
   and also covers the case in which a device proxies network presence
   including power reporting for a second device.





Nordman & Winter       Expires September 16, 2011               [Page 5]


Internet-Draft               Consider Energy                  March 2011


3.5.  Intervals

   A common feature of energy monitoring is to track energy use over
   time.  Recording of energy use for intervals of time is the
   responsibility of a network management system (or whatever entity
   requests data via the eman protocol), not the monitored device
   itself.  The monitored device always reports accumulated energy use
   with an associated timestamp.

3.6.  Presentation to non-IETF audiences

   Many people and organizations who have not in the past understood or
   interacted with the IETF will be interested in eman results.  They
   need to be provided with easily understandable explanations of what
   eman does and why.  How this presentation will be accomplished is
   still to be determined.

3.7.  Functions vs. Entities

   Eman is concerned with exposing information to Network Management
   Systems (NMSs).  Providing information is a function.  The various
   functions may be implemented by a single device, or distributed among
   several devices.

3.8.  Simple and Complex Devices

   We will support both.  Simple devices want to avoid complexity that
   burdens both implementation on the monitored device, and the
   monitoring system.  Complex devices need to have access to additional
   data fields and capabilities.





















Nordman & Winter       Expires September 16, 2011               [Page 6]


Internet-Draft               Consider Energy                  March 2011


4.  Topics under discussion

4.1.  Power States

   We synonymously use the terms Power Mode and Power State; named modes
   are general categories only ("buckets"), not individual states with
   highly-specific meaning.

   Discussions about energy consumptions and device power states are
   often confusing as different products define states such as "standby"
   quite differently.  Even the same class of devices often implement
   named states differently.  Named power states are intrinsically
   difficult to define consistently as they imply not only something
   about a device's energy consumption but also something about the
   device's capabilities in that state, and are implementation-
   dependent.  All of this makes highly-specific named modes unsuitable
   for use in a general context.  The term with by far the most
   different definitions is "standby" and so we therefore do not refer
   to standby in this document and believe it unsuitable for use in
   eman.

   We believe that the three named power state categories, on, off and
   sleep, are broadly understood.  These mode categories may each
   contain a large set of power sub-states.  A fourth basic power state
   of 'ready' may be more appropriate for some devices, particularly
   appliances.

   In general, devices that are asleep will be able to wake quickly and
   will retain network connectivity.  Devices that are off usually take
   much more time to turn on than the wake time and usually lack network
   connectivity.  Devices that are on are fully functional but
   potentially with reduced performance.

   A critical feature of the set of basic power states is that they
   should be universally applicable to any device eman is applied to.
   This does not mean that each device has every state, but that the
   model is sufficiently general that it can be applied to all.  When
   the level of detail rises, the set of states usually is then
   applicable to only certain types of products, and/or to specific
   implementations.  In addition, these detailed states generally embody
   specific functional characteristics of the state, and so are better
   embodied in other variables (that may be delivered by an energy
   management protocol).








Nordman & Winter       Expires September 16, 2011               [Page 7]


Internet-Draft               Consider Energy                  March 2011


5.  Energy Manangement

   First and foremost, the task of power and energy management is
   reporting.  While a more active role in energy management is
   conceivable by e.g. putting devices into power states based on
   policies or other predefined schemes at a network management system
   (NMS).

5.1.  Control

   There should not be an assumption that power state management of
   devices is done externally/centrally.  Ideally most devices will
   manage their own power state, implementing distributed intelligence.
   The control function is accomplished separately from power reporting.
   A core mechanism many devices will use to manage power consumption is
   a price (and price forecast) for electricity.

5.2.  Identity

   All devices on a network need to expose identity to others.  While
   some protocols accomplish this for particular applications or
   contexts, it is desirable to have a simple universal mechanism.  This
   is particularly true for devices that may have a fairly limited
   degree of participation in the network, such as appliances.

   For energy management purposes, the it is important to know "what" a
   device is, and "who" it is.  Each of these has two parts as follows:

   o  "Species".  This is the fundamental classification that a device
      is a member of due to its design and capabilities.  This property
      is determined by the manufacturer before it is sold.  Examples are
      server, router, notebook PC, display, TV, refrigerator, light,
      etc.

   o  "Origin".  The brand and model of the device.  Primarily a method
      to find out more information about a device, such as its
      specifications for requirements and capabilities.  It would be
      advantageous to include a URL for detailed information from the
      manufacturer.  An example of this is the "Universal Product Code"
      on many products.

   o  Name: A human-readable name, locally specified when the device is
      configured or installed.

   o  Network ID: A globally unique identifier for the NMS to use to
      recognize a device.  This should be based on one or more existing
      IETF mechanisms.




Nordman & Winter       Expires September 16, 2011               [Page 8]


Internet-Draft               Consider Energy                  March 2011


   An energy management application could then obtain current energy use
   for a device like a refrigerator, and compare it to what it is
   expected to use under normal operation, and alert the building
   manager if it is significantly out of range.  This also can be used
   to quickly inventory energy-using products in a building, and to
   summarize by product type where energy is being used.

5.3.  NMS Considerations

   A Network Management System is an entity which collects energy and
   power reporting data and uses it for advanced applications.  One such
   application correlates energy consumption with other metrics to
   display efficiency metrics (like watthours/bit).  An NMS can also set
   device policies to control larger networked systems such as a data
   center.

   An NMS will query energy MIB data on a periodic basis, with that
   period dictated by its needs, possibly being dynamic.  MIBs should
   provide an energy "meter reading" to allow computing of energy use
   for any period.  Thus, the NMS does most of the work to generate time
   series energy data, and this minimizes burden on the host and the
   complexity of the Power MIB.

   The core function of power monitoring is to maintain meters of energy
   use and of time in different power states (and through summing, total
   energy and time).  The second is to be able to report current power
   consumption and power state.

5.4.  MIB Considerations

   The MIB should be generic as there are a large number of devices yet
   to come and power states are and will become more diverse.

   The MIB should be structured so that the smallest possible set of
   values/information is applicable to a large range of devices, can be
   implemented efficiently and is extensible to accommodate additional
   information objects.  As an example, many devices will not be battery
   powered but it should be easy to add battery monitoring to the basic
   set of energy-related information.

   The proposed MIB structures enable reporting on components of
   products (e.g. linecards in a chassis) in addition to entire
   products.  Doing this is not part of the eman charter, so while there
   is no reason to preclude the capability, it should not be a
   distraction to completing the chartered eman scope.






Nordman & Winter       Expires September 16, 2011               [Page 9]


Internet-Draft               Consider Energy                  March 2011


5.5.  Power Considerations

   Reporting should cover both AC and DC power sources.  However, other
   types should be provided for, and the type of energy is one of the
   reported values.  Standard low-voltage DC (e.g.  USB, Power over
   Ethernet, eMerge) is immediately useful.  A core set of values should
   be available from any device that implements the Power MIB at all so
   that an NMS can quickly obtain and aggregate uniform data for all
   devices.

   There is a fundamental distinction between supplied power from a
   device And input power to a device, notably losses that occur in
   transmission, as well as other (possibly unknown) devices that are
   also using the power.  The effect of internal batteries is not
   revealed by the MIB, as it only reports on net power into or out of a
   device.

5.6.  Incomplete data

   Energy reporting will cover a wide variety of information about a
   device, its status, and energy usage.  Sometimes, particularly for
   legacy or non-IP products, this will be incomplete.  It is critical
   that the fact that some data are missing does not undermine the
   ability to report the data that are present.

5.7.  Time reporting

   At the core of energy reporting is data from energy meters that are
   meter readings associated with timestamps.  A variety of issues arise
   on the meaning of that time.

   Without strong syncronization, the NMS and the devices it queries
   will have different absolute times.  However, the NMS knows when it
   asked for each meter reading so can account for this difference.

   For some devices, when they are off they will be unable to accumulate
   their energy consumption.  The fact that some consumption may be
   missing needs to be communicated to the NMS.  One possibility is to
   record the last time that a period of missing energy occurred, and
   report that to the NMS.

5.8.  Portable devices

   Devices that are routinely moved from one building to another (or
   even within a building) pose special challenges for energy reporting.
   The question arises whether it is the energy into the device, or from
   the building, which is dominant.  It may be important to record the
   time a device most recently changed power domain to ensure that a NMS



Nordman & Winter       Expires September 16, 2011              [Page 10]


Internet-Draft               Consider Energy                  March 2011


   can correctly account only for energy consumed on its premises.

5.9.  Beyond energy

   The charter references "energy" but virtually all discussion has been
   limited to electricity.  Other forms of energy should be included at
   some point; we should discuss whether this is readily feasible now,
   or needs to be postponed to future work.

5.10.  Power State Monitoring

   For the device power state, the following information is considered
   to be relevant:

   o  the current state

   o  the time of (or time since) the last change

   o  the current real power (energy consumption rate)

   o  accumulated energy consumption

5.11.  Power Distribution

   Wired networks enable power distribution that is co-incident with
   network Communication.  However, many devices will not communicate on
   the same Medium that they are powered on, or may lack connectivity
   entirely (though with the power provider knowing of their identity).
   Devices can report power for another device only if they are the
   entity providing the power.





















Nordman & Winter       Expires September 16, 2011              [Page 11]


Internet-Draft               Consider Energy                  March 2011


6.  Use Context and Use Cases

   The following are some use contexts that this facility is intended
   for.  These are not necessarily mutually exclusive, and a device can
   report the same data regardless of the context.

   o  A data center, with a NMS which is integrated with application
      functionality, and also manages energy use.

   o  A commercial building, in which the energy reporting is separate
      from any management of devices, and more as background to help
      understand building operation (including occupancy) and identify
      inefficiencies or equipment failures.

   o  A house, which shares some of the commercial building
      characteristics, but with different management approach and
      security concerns.

   o  A vehicle, which uses the reporting only for automatic management,
      not for reporting to the user.

   Use cases include a facility manager or an NMS in an automated
   fashion:

   o  Understand costs for billing purposes.

   o  Assess savings potentials.

   o  Identify possible device malfunctions.

   o  Reveal unexpected usage patterns.

   o  Plan for future capacity needs.

   o  Understand heat production in a building or space.

   o  A NMS which deals with draws on current power use to deal with an
      actual or potential shortfall in power supply.













Nordman & Winter       Expires September 16, 2011              [Page 12]


Internet-Draft               Consider Energy                  March 2011


7.  Future Directions

   The current effort to create a protocol for energy management is
   unlikely to be the last word on the topic.  In fact, there are many
   directions that need to be explored for potential addition to the
   features enabled by this mechanism or others.  These include:

   o  other energy media such as wireless power, non-electric energy
      (e.g. natural gas, steam, hot/cold water).

   o  more features for control.

   o  other energy-relevant quantities (e.g. temperatures, flow rates).

   o  other resources (e.g. water).




































Nordman & Winter       Expires September 16, 2011              [Page 13]


Internet-Draft               Consider Energy                  March 2011


8.  Security Considerations

   None.
















































Nordman & Winter       Expires September 16, 2011              [Page 14]


Internet-Draft               Consider Energy                  March 2011


9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.















































Nordman & Winter       Expires September 16, 2011              [Page 15]


Internet-Draft               Consider Energy                  March 2011


Authors' Addresses

   Bruce Nordman
   Lawrence Berkeley National Laboratory

   Email: bnordman@lbl.gov


   Rolf Winter
   NEC Labs Europe

   Email: rolf.winter@neclab.eu







































Nordman & Winter       Expires September 16, 2011              [Page 16]


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