| Network Working Group | B. Nordman |
| Internet-Draft | Lawrence Berkeley National Laboratory |
| Intended status: Informational | R. Winter |
| Expires: September 16, 2011 | NEC Labs Europe |
| March 15, 2011 |
Considerations for Power and Energy Management
draft-norwin-energy-consider-02
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.
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 (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 (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.
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].
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.
The following are topics that seem settled in eman discussions, recognizing that this draft has no authority on that point.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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:
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.
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.
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.
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.
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.
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.
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 can correctly account only for energy consumed on its premises.
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.
For the device power state, the following information is considered to be relevant:
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.
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.
Use cases include a facility manager or an NMS in an automated fashion:
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:
None.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |