| Network Working Group | B. Nordman |
| Internet-Draft | S. Lanzisera |
| Intended status: Standards Track | Lawrence Berkeley National Laboratory |
| Expires: April 26, 2012 | October 24, 2011 |
Power Locator
draft-nordman-power-locator-00
This specification addresses how to request that a device should enter a "power locator" mode for a limited period of time. The mode involves a device cycling between a low and high power level in a predictable manner so that a power metering device upstream in the power distribution system can sense the signal and so determine where the device draws its power from. This will be useful in many types of buildings, particularly data centers and large commercial buildings. This draft addresses operation of the device carrying out the request, but not detailed operation of the device that makes the request and interprets the results.
This draft is an initial discussion document to generate feedback and improvement.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
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 26, 2012.
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.
Management of energy use in buildings is often impeded by not knowing basic information about where the energy is used and for what purpose. The quantity of electricity used is being addressed by the Energy Management Working Group, but there is no existing mechanism to help identify where in a power distribution tree a particular device is located. In data centers, Power Distribution Units commonly have metering capability for each individual outlet. Metering for commercial buildings is becoming less expensive each year, so that measurement of entire electrical panels, or individual circuits, is increasingly common.
As metering within buildings becomes more sophisticated, it is important to know what devices are on each metered circuit. While this can be entered into a management system manually (if known), an automated solution would be much less costly, more reliable, and much easier to keep current.
Many devices and components can modulate their own power use dynamically. For example, processors can be sped up or slowed down; disks can be spun up or spun down; displays can be made brighter or dimmer (or even not lit at all); heaters in a printer can be engaged or disengaged; fans can be turned on or off, etc. These changes normally occur for functional purposes, with components powered up as needed, and down when not, to save energy or reduce thermal burdens. However, they can be engaged for other purposes; in this case, to create a very low bit rate signal on the power line.
This mechanism is cleanest if the device in question is otherwise completely idle, but can still be usefully invoked if it is engaging in modest, random utilization that induces power levels above the normal idle level.
This draft describes a simple mechanism to aid device location for any device that has the ability to modulate its own power consumption on a timely basis.
The scope of this draft is any entity which is reachable via SNMP.
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 RFC 2119 [RFC2119].
This mechanism covers a building which has a management system (MS), meters, and individual devices. The devices can receive power locator requests.
Devices that support this mechanism recieve an SNMP request, and if granted, alter their behavior for a specified period of time.
Meters may measure power for an individual outlet, an individual circuit breaker, or an entire section of a building. That is, they may power one device, or many. The meter reports power or energy data to the MS on a known fixed periodic basis.
The management system has the ability to identify devices that are or may be in the target building, has access to the data reported by meters in the building, and can send power locator requests to individual devices.
The SNMP request is accomplished by a SET of each of the following values:
The device may return any of the data items above via in SNMP GET. The following are also available:
A management system has access to data from a series of meters that measure discrete portions of the electricity distribution system in a building. It also has access to a list of IP addresses that may correspond to devices in the building. Usually a subnet will cover a building (or portion thereof) and so all addresses in the subnet can be queried. Alternatively, the router can be queried for all addresses it knows of, etc.
The management system will direct one or more devices to modulate their power with a Period value typically twice the length of each meter reading period. This ensures that every other reading will reflect only a maximum or minimum for the target device (the intermediate readings will be some combination of adjacent periods). If timing of devices and meters can be aligned, then devices may have a Period value equal to the meter reading period.
The simplest bitmap would be simply "01" so that the device would alternate between low and high on a fixed period. However, more complex patterns will provide a better signal, particularly in the face of periodic ordinary consumption. In addition, complex patterns facilitate searching for multiple devices at the same time.
Once a device is in its modulation mode, the management system will scan data from each meter to try to find which meter the signal is visible on. The signal processing algorithm(s) used by management systems are outside the scope of this draft. Once the device is localized to a particular meter, the management system may set the duration value to zero to terminate the test, or may simply let it run its course. If the device cannot be located, the test can be re-run.
A management system may periodically re-run the test to track any devices that have moved. The type of device may inform how often the test is re-run.
For devices with internal batteries, there is the possibility of going to battery-only mode for low-power, and to battery charging for high power? This would make the delta much larger for something like a notebook.
This draft does not address how a device could or should modulate its power use.
SNMP uses a series of SETs. I assume that the various values should be set with the duration being the last one. The duration will count down to zero during the course of operation. Is this the right way to use SNMP for this purpose?
Should Period be measured in milliseconds or microseconds? Four bytes at 1ms is a really long time; three bytes is odd. Options seem to be milliseconds at 3B or 4B, or microseconds at 4B. Note that one AC cycle is 17 or 20 ms long (60 Hz and 50 Hz), so presumably no value less than this would be used, at least for AC power distribution. The microsecond case would be the same but a higher starting value. Should there be a aximum value for "Period"?
Should any facility be provided for an IP device to proxy this ability for a non-IP device? (Probably not) .
How about devices with multiple power supplies? Generally the signal will show up on both meters (if they are fed by different meters). If the device has the ability to shut off all but one supply, then each could be located separately, but this draft does not consider how to signal that behavior.
SNMP is convenient, but alternative protocols could also be used. Are there any particularly suited to this?
Should there be an explicit error variable? In addition to the device rejecting the request, it may be or become disconnected from mains power distribution (e.g. a notebook running on battery).
Is "test" the right word to use?
This mechanism introduces no information security vulnerabilities. It does create the possibility of limited extra energy use when invoked. Invoking this mechanism on a large number of devices in synchrony could introduce instability into the local power distribution system.
TBD
We would like to thank <get your name here>.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |