One document matched: draft-norwin-energy-consider-02.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-norwin-energy-consider-02">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev='Consider Energy'>Considerations for Power and Energy Management</title>
        <author initials='B.' surname="Nordman" fullname='Bruce Nordman'>
        <organization>Lawrence Berkeley National Laboratory</organization>
        <address>
				<email>bnordman@lbl.gov</email>   
				</address> 
        </author>
        <author initials='R.' surname="Winter" fullname='Rolf Winter'>
        <organization>NEC Labs Europe</organization>
        <address>
        <email>rolf.winter@neclab.eu</email>
        </address>
        </author>
        <date/>
        <abstract><t>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.
				</t></abstract>
    </front>
    <middle>
    <section title="Requirements notation">
            <t>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 <xref target="RFC2119"/>.</t>
        </section>
				
				<section title="Overview/Goals">
					<t>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.</t>

				</section>
				
				<section title="Settled topics">
				<t>
				The following are topics that seem settled in eman discussions, recognizing
				that this draft has no authority on that point.
				</t>
				
				<section title="Scope of Devices">
					<t>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.
					</t>
					
					<t>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.</t>

  				
				</section>
				<section title="Identity">
				  <t>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.
				  </t>
				  </section>
				<section title="Power Levels">
					<t>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.</t>
				</section>
					
				<section title="Devices">
					<t>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.</t>
				</section>
				
				<section title="Intervals">
					<t>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.</t>
				</section>
				
				<section title="Presentation to non-IETF audiences">
					<t>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.</t>
				</section>				
				
				<section title="Functions vs. Entities">
					<t>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.</t>
				</section>		
				
				
				<section title="Simple and Complex Devices">
					<t>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.</t>
				</section>		
				
				</section>
				
				<section title="Topics under discussion">
				
					<section title="Power States">
					<t>We synonymously use the terms Power Mode and Power
   				State; named modes are general categories only ("buckets"), not individual states
   				with highly-specific meaning.</t> 

   				<t>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.  
  				</t>
  				<t>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.</t>

   				<t>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.</t>
   				
   				<t>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).
   				</t>
					</section>
					

				</section>
				
				<section title="Energy Manangement">
				<t>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).</t>
   			
					<section title="Control">
					<t>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.</t>
					</section>
				
					<section title="Identity">
					<t>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.
   				</t>
   				<t>
   				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:
   					<list style='symbols'>
						<t>"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.
						</t>
						<t>"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.</t>
						<t>Name:  A human-readable name, locally specified when the device is
						configured or installed.  </t>
						<t>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.</t>
					</list>
   				</t>	  

   				<t>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.</t>
					</section>
					
					<section title="NMS Considerations">
					<t>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.</t>

   				<t>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.</t>

   				<t>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.</t>
					</section>
					
						
					<section title="MIB Considerations">
					<t>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.</t> 
 
 					<t>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.</t>
   				
   				<t>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.
   				</t>
					</section>	
					
					<section title="Power Considerations">
					<t>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.</t>

   				<t>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.</t>

					</section>
				
					<section title="Incomplete data">
					<t>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.</t>

					</section>
					
					<section title="Time reporting">
					<t>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.</t>
					
					<t>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.
					</t>
					
					<t>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.
					</t>
					</section>
					
						<section title="Portable devices">
					<t>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.</t>

					</section>
					
					<section title="Beyond energy">
					<t>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.
					</t>

					</section>
				
					<section title="Power State Monitoring">
					<t>For the device power state, the following information is considered 
						to be relevant:
					
					<list style='symbols'>
						<t>the current state</t>
						<t>the time of (or time since) the last change</t>
						<t>the current real power (energy consumption rate)</t>
						<t>accumulated energy consumption</t>
					</list>
					
					</t>
					</section>
					
					<section title="Power Distribution">
					<t>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.</t>
					</section>

				</section>		
						
				<section title="Use Context and Use Cases">
				<t>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.
				
				<list style='symbols'>
					<t>A data center, with a NMS which is integrated with application
      		functionality, and also manages energy use.</t>
				
					<t>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.</t>

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

					<t>A vehicle, which uses the reporting only for automatic management,
      		not for reporting to the user.</t>
				</list>
				</t>
   			
   			<t>Use cases include a facility manager or an NMS in an automated fashion:
				
				<list style='symbols'>
					<t>Understand costs for billing purposes.</t>
				
					<t>Assess savings potentials.</t>

   				<t>Identify possible device malfunctions.</t>

   				<t>Reveal unexpected usage patterns.</t>

   				<t>Plan for future capacity needs.</t>

   				<t>Understand heat production in a building or space.</t>

   				<t>A NMS which deals with draws on current power use to deal with
     			an actual or potential shortfall in power supply.</t>
				</list>
				
				</t>
				</section>	
					
							
				<section title="Future Directions">

   			<t>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:
   				
   			<list style='symbols'>
					<t>other energy media such as wireless power, non-electric energy 
					(e.g. natural gas, steam, hot/cold water).</t>
						
					<t>more features for control.</t>
					
					<t>other energy-relevant quantities (e.g. temperatures, flow rates).</t>
					
					<t>other resources (e.g. water).</t>
				</list>
				</t>
				</section>
				
				
        <section title="Security Considerations">
        <t>None.</t>
        </section>
    </middle>

    <back>
        <references title='Normative References'>&rfc2119;</references>
    </back>

</rfc>