One document matched: draft-norwin-energy-consider-01.txt
Differences from draft-norwin-energy-consider-00.txt
Network Working Group B. Nordman
Internet-Draft Lawrence Berkeley National
Intended status: Informational Laboratory
Expires: April 28, 2011 R. Winter
NEC Labs Europe
October 25, 2010
Considerations for Power and Energy Management
draft-norwin-energy-consider-01
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Nordman & Winter Expires April 28, 2011 [Page 1]
Internet-Draft Consider Energy October 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. Scope of Devices . . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Power States . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Power Levels . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Devices . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Energy Manangement . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Control . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. NMS Considerations . . . . . . . . . . . . . . . . . . . . 7
5.4. Proxy Considerations . . . . . . . . . . . . . . . . . . . 8
5.5. MIB Considerations . . . . . . . . . . . . . . . . . . . . 8
5.6. Power Considerations . . . . . . . . . . . . . . . . . . . 8
5.7. Power State Monitoring . . . . . . . . . . . . . . . . . . 9
5.8. Power Distribution . . . . . . . . . . . . . . . . . . . . 9
6. Use Context and Use Cases . . . . . . . . . . . . . . . . . . 10
7. Outstanding Questions and Future Directions . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Nordman & Winter Expires April 28, 2011 [Page 2]
Internet-Draft Consider Energy October 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 April 28, 2011 [Page 3]
Internet-Draft Consider Energy October 2010
2. Overview/Goals
This document aims at framing discussions on power and energy
management within the IETF and recording their results. To this end,
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 (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 captures why certain decisions were made in the
process of defining power and energy management mechanisms.
Another goal is to cover use cases that go beyond the traditional
IETF ones to keep emerging standards open with respect to diverse
product types. 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; we focus on power monitoring and basic identity
only. It is assumed that most devices will manage their own power
state. This may be informed by external devices, by proprietary and
standardized solutions (that are or will become available), or as a
consequence of functional applications.
Nordman & Winter Expires April 28, 2011 [Page 4]
Internet-Draft Consider Energy October 2010
3. 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 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.
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).
Nordman & Winter Expires April 28, 2011 [Page 5]
Internet-Draft Consider Energy October 2010
4. Terminology
4.1. Power States
We synonymously use the terms Power Mode and Power State; named modes
are general categories only, 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 deliberately
do not refer to standby in this document. 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.
4.2. 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.
4.3. 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 April 28, 2011 [Page 6]
Internet-Draft Consider Energy October 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).
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. This
mechanism should 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.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
Nordman & Winter Expires April 28, 2011 [Page 7]
Internet-Draft Consider Energy October 2010
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. Proxy Considerations
Devices usually will report on their own input power, but may also
report Power supplied to other devices. Those other devices may also
have an IP address and so report some information themselves. Other
devices may not have an IP presence and so all information will be
from the proxy.
5.5. 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.
5.6. 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.
It is tempting to add a lot of descriptive information (e.g. on
Nordman & Winter Expires April 28, 2011 [Page 8]
Internet-Draft Consider Energy October 2010
highly specific power states and periodic energy consumption) into
the MIB; however, this information will greatly vary across device
types.
5.7. 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.8. 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 April 28, 2011 [Page 9]
Internet-Draft Consider Energy October 2010
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 April 28, 2011 [Page 10]
Internet-Draft Consider Energy October 2010
7. Outstanding Questions and Future Directions
Questions that need to be answered in the course of developing RFCs
for energy management include:
o What unit(s) of measurement should the MIB use?
Future directions include:
o other energy media such as wireless power, non-electric energy
(e.g. natural gas)
o support for devices with multiple power sources (the initial MIB
should cover only the total input power).
Nordman & Winter Expires April 28, 2011 [Page 11]
Internet-Draft Consider Energy October 2010
8. Security Considerations
None.
Nordman & Winter Expires April 28, 2011 [Page 12]
Internet-Draft Consider Energy October 2010
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 April 28, 2011 [Page 13]
Internet-Draft Consider Energy October 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 April 28, 2011 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 13:40:56 |