Network Working Group B. Nordman
Internet-Draft Lawrence Berkeley National
Intended status: Informational Laboratory
Expires: January 6, 2011 R. Winter
NEC Labs Europe
July 5, 2010
Considerations for Power and Energy Management
draft-norwin-energy-consider-00
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 January 6, 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
Nordman & Winter Expires January 6, 2011 [Page 1]
Internet-Draft Consider Energy July 2010
(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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Scope of devices . . . . . . . . . . . . . . . . . . . . . . . 6
5. Energy Manangement . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Device Considerations . . . . . . . . . . . . . . . . . . 7
5.2. NMS Considerations . . . . . . . . . . . . . . . . . . . . 7
5.3. MIB Considerations . . . . . . . . . . . . . . . . . . . . 8
5.4. Power State Monitoring . . . . . . . . . . . . . . . . . . 8
6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Nordman & Winter Expires January 6, 2011 [Page 2]
Internet-Draft Consider Energy July 2010
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 January 6, 2011 [Page 3]
Internet-Draft Consider Energy July 2010
2. Overview/Goals
This document aims at framing and recording the discussions on power
and energy management within the IETF. To this end, it clarifies
terminology that most people believe have a well-defined meaning,
which in practice however can mean vastly different things. The
document further describes how energy and power reporting differs
from other reporting tasks that have been defined by the IETF (e.g.
IPFIX) and the resulting implications for mechanisms the IETF will
define in the future. This document is intended to be a living
document that also tries to capture why certain decisions were made
in the process of defining power and energy management mechanisms.
Another goal is to present use cases that go beyond the 'traditional'
IETF ones to keep emerging standards open with respect to these use
cases. In this memo, we focus on power monitoring only.
Participating entities are monitoring systems that receive
information and networked devices that provide information on energy
consumption and power state information concerning themselves or
potentially also other devices. Not in the scope of this memo are
means for controlling the energy consumption and the power state of
monitored devices. It is assumed that devices will manage their own
power state, or if done externally, by proprietary and standardized
solutions (that are or will become available), or as a consequence of
functional applications.
Nordman & Winter Expires January 6, 2011 [Page 4]
Internet-Draft Consider Energy July 2010
3. Terminology
Discussions about energy consumptions and device power states are
often confusing as different products define states such as
'stand-by' quite differently. Even the same class of devices often
implement such 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. To avoid confusion
based on a different understanding of certain terms, we first define
the meaning of certain terminology used in this document.
In this document, we synonymously use the terms Power Mode and Power
State; named modes are general categories. Some well-known power
states have been used and have been (re-)defined in different
contexts over the years, which make them unsuitable for discussion in
a general context. Most prominently 'standby' has very different
meanings and implications across a broad set of devices from TV sets
to servers. We therefore deliberately do not refer to standby in
this document. Within this document we restrict ourselves to a small
set of named power state categories which are broadly understood,
which however contain a large potential set of different power states
themselves. These categories are on, off and sleep.
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.
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 January 6, 2011 [Page 5]
Internet-Draft Consider Energy July 2010
4. Scope of devices
All devices that have a network connection should be in scope. 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 need such capability too.
These devices may have different ways of accomplishing discovery and
management for functional purposes, but will share the common energy/
power reporting capability. While some of these will directly
measure power, other devices will not measure their power, but may be
able to reliably estimate it. These devices are still in scope.
Nordman & Winter Expires January 6, 2011 [Page 6]
Internet-Draft Consider Energy July 2010
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), this document focusses on the reporting side of things.
5.1. Device Considerations
There should not be an assumption that power state management of
devices is done externally/centrally as ideally most devices will
manage their own power state (distributed intelligence). This
document does not address the power consumption levels of internal
components of a product, only the energy inputs to the entire product
(and net consumption if it provides power to other products).
Simple devices from a network perspective such as appliances would
benefit from a simple identification capability that would directly
or indirectly reveal the brand/model of the device, and possible a
URL to further information about the device. An example of this is
the "Universal Product Code" on many products. Subsequent documents
should identify the appropriate mechanism to accomplish this, e.g. an
existing MIB. 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.2. NMS Considerations
A Network Management System is the entity which collects the reported
energy and power reporting data and uses it for 'advanced'
applications. One such application could be to correlate energy
consumption with some other metric to display some form of efficiency
metric (like watthours/bit) if deemed useful. A second role an NMS
could fulfill is to set device policies to control larger networked
systems such as a data center. (Note: unclear whether the same
channel should be used for setting and reporting).
An NMS will usually query MIB data on a periodic basis, with that
period dictated by its needs, possibly being dynamic. MIBs can
provide an energy "meter reading" to lead to energy use for each
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.
Nordman & Winter Expires January 6, 2011 [Page 7]
Internet-Draft Consider Energy July 2010
The first core function of the power monitoring are 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.3. MIB Considerations
The MIB should be generic as there are a large number of devices yet
to come and power states are and will be more so in the future very
diverse. Power state categories ("buckets") are on/sleep/off with
freely definable power states therein (example ACPI). A fourth basic
power state of 'ready' may be more appropriate for some devices,
particularly appliances.
Reporting should cover both AC and DC power sources (and devices may
have more than one power source). However, other types should be
provided for, and the type of energy one of the reported values.
Standard low-voltage DC (e.g. USB, Power over Ethernet, eMerge) is
immediately useful. Eventually, there should be values for wireless
power, battery power, and natural gas. 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.
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.
It is tempting to add a lot of descriptive information (e.g. on
highly specific power states and periodic energy consumption) into
the MIB; however, this information will greatly vary across device
types. It appears that the best place for such information, if
indeed it is needed for the power reporting task, is the NMS and not
the MIB itself.
5.4. 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:
Nordman & Winter Expires January 6, 2011 [Page 8]
Internet-Draft Consider Energy July 2010
o the current state
o the time of the last change
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
Nordman & Winter Expires January 6, 2011 [Page 9]
Internet-Draft Consider Energy July 2010
6. Use Cases
The following are some different use cases that this facility might
be used in. These are not necessarily mutually exclusive.
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.
Nordman & Winter Expires January 6, 2011 [Page 10]
Internet-Draft Consider Energy July 2010
7. Security Considerations
None.
Nordman & Winter Expires January 6, 2011 [Page 11]
Internet-Draft Consider Energy July 2010
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Nordman & Winter Expires January 6, 2011 [Page 12]
Internet-Draft Consider Energy July 2010
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 January 6, 2011 [Page 13]