<?xml version="1.0" encoding="US-ASCII"?>

<!-- xml2rfc2 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY rfc3621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3621.xml">
<!ENTITY rfc6933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6933.xml">
<!ENTITY rfc5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY rfc5102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">

]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<rfc category="info" number="6988" consensus="yes" submissionType="IETF" 
     ipr="trust200902">

  <front>
    <title>Requirements for Energy Management</title>

    <author fullname="Juergen Quittek" initials="J." 
            role="editor" surname="Quittek">
      <organization>NEC Europe Ltd.</organization>

      <address>
        <postal>
          <street>NEC Laboratories Europe</street>

          <street>Network Research Division</street>

          <street>Kurfuersten-Anlage 36</street>

          <code>69115</code>

          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342-115</phone>

        <email>quittek@neclab.eu</email>
      </address>
    </author>

    <author fullname="Mouli Chandramouli" initials="M." 
            surname="Chandramouli">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Sarjapur Outer Ring Road</street>

          <city>Bangalore</city>

          <region></region>

          <code></code>

          <country>India</country>
        </postal>

        <phone>+91 80 4426 3947</phone>

        <email>moulchan@cisco.com</email>
      </address>
    </author>

    <author fullname="Rolf Winter" initials="R." surname="Winter">
      <organization>NEC Europe Ltd.</organization>

      <address>
        <postal>
          <street>NEC Laboratories Europe</street>

          <street>Network Research Division</street>

          <street>Kurfuersten-Anlage 36</street>

          <code>69115</code>

          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342-121</phone>

        <email>Rolf.Winter@neclab.eu</email>
      </address>
    </author>

    <author fullname="Thomas Dietz" initials="T." surname="Dietz">
      <organization>NEC Europe Ltd.</organization>

      <address>
        <postal>
          <street>NEC Laboratories Europe</street>

          <street>Network Research Division</street>

          <street>Kurfuersten-Anlage 36</street>

          <code>69115</code>

          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342-128</phone>

        <email>Thomas.Dietz@neclab.eu</email>
      </address>
    </author>

    <author fullname="Benoit Claise" initials="B." surname="Claise">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>De Kleetlaan 6a b1</street>

          <city>Diegem</city>

          <code>1831</code>

          <country>Belgium</country>
        </postal>

        <phone>+32 2 704 5622</phone>

        <email>bclaise@cisco.com</email>
      </address>
    </author>

    <date month="September" year="2013" />

<!-- [rfced] FYI, we have used xml2rfc v2 (available from 
http://xml.resource.org) to convert this document to text. -->

    <abstract>
      <t>This document defines requirements for standards specifications for
      Energy Management. The requirements defined in this document
      are concerned with monitoring functions as well as 
      control functions.  Monitoring functions include identifying
      energy-managed devices and their components, as well as monitoring
      their Power States, Power Inlets, Power Outlets, actual power,
      Power Attributes, received energy, provided 
      energy, and contained batteries.  
      Control functions include such functions as controlling power
      supply and Power State of energy-managed devices and
      their components.</t>

      <t>This document does not specify the features that must be 
      implemented by compliant implementations but rather lists features 
      that must be supported by standards for Energy Management.</t>
    </abstract>
  </front>

  <middle>  
    <!-- Introduction ========================================== -->
    <section title="Introduction">
      <t>With rising energy costs and an increasing awareness of 
      the ecological impact of running information technology 
      equipment, Energy Management (EMAN) functions and interfaces are 
      becoming an additional basic requirement for network 
      management systems and devices connected to a network.</t>

      <t>This document defines requirements for standards specifications for
      Energy Management, both monitoring functions and control functions.
      Energy Management functions focus mainly on devices and their components
      that receive and provide electrical energy. Devices such as hosts,
      routers, and middleboxes may have an IP address or may be
      connected indirectly to the Internet via a proxy with an IP address
      providing a management interface for the device, for example,
      devices in a building infrastructure using non-IP protocols and a
      gateway to the Internet.</t>

      <t>These requirements are concerned with the standards specification
      process and not the implementation of specified standards. All
      requirements in this document must be reflected by standards
      specifications to be developed. However, which of the features
      specified by these standards will be mandatory, recommended, or
      optional for compliant implementations is to be defined by
      Standards Track document(s) and not in this document.</t>

      <t><xref target="goals"/> elaborates on a set of general needs 
      for Energy Management. Requirements
      for an Energy Management standard are specified in
      Sections <xref format="counter" target="identity"/> through
      <xref format="counter" target="controlother"/>.</t>
      
      <t>Sections <xref format="counter" target="identity"/> through
      <xref format="counter" target="control"/> contain  
      conventional requirements specifying information on entities   
      and control functions.</t>
      
      <t>Sections <xref format="counter" target="reportonother"/> 
      and <xref format="counter" target="controlother"/> contain 
      requirements specific to Energy Management.  Due to the nature
      of power supply, some monitoring and control functions are not 
      conducted by interacting with the entity of interest but rather
      with other entities, for example, entities upstream in a power distribution
      tree.</t>

      <section anchor="conventional" 
        title="Conventional Requirements for Energy Management">
        <t>The specification of requirements for an Energy Management
        standard starts with <xref target="identity"/>,
        which addresses the identification of entities and the 
        granularity of reporting of energy-related information. 
        A standard must support the unique identification of entities,
        reporting per entire device, and reporting 
        energy-related information on individual components of a 
        device or attached devices.</t>

        <t><xref target="properties"/> specifies requirements 
        related to the monitoring of entities. This includes 
        general (type, context) information and specific information
        on Power States, Power Inlets, Power Outlets, power, energy, 
        and batteries. The control of Power State and power supply
        by entities is covered by requirements specified in 
        <xref target="control"/>.</t>
      </section>

      <section title="Specific Requirements for Energy Management">

        <t>While the conventional requirements summarized above seem
        to be all that would be needed for Energy Management, there 
        are significant differences between Energy Management and 
        most well-known network management functions.
        The most significant difference 
        is the need for some devices to report on other
        entities. There are three major reasons for this.
                
        <list style="symbols">
          <t>For monitoring a particular entity, it is not 
          always sufficient to communicate only with that entity.
          When the entity has no instrumentation for determining power,
          it might still be possible to obtain power values for the
          entity via communication with other entities in its
          power distribution tree.  A simple example of this would be
          the retrieval of power values from a power meter at the
          power line into the entity. A Power Distribution Unit (PDU) and
          a Power over Ethernet (PoE) switch are common examples.
          Both supply power to other entities at sockets or ports,
          respectively, and are often instrumented to measure power
          per socket or port.
          </t>
      
          <t>Similar considerations apply to controlling the power 
          supply of an entity that often needs direct or 
          indirect communications with 
          another entity upstream in the power distribution tree. 
          Again, a PDU and a PoE switch are common examples, if they 
          have the capability to switch power on or off at their 
          sockets or ports, respectively.</t>
      
          <t>Energy Management often extends beyond entities with IP network
          interfaces to non-IP building systems accessed via a gateway 
          (sometimes called an Energy Management System or controller).
          Requirements in this document do not cover the details of these
          networks and energy devices but specify means for opening 
          IP network management towards them.</t>
        </list></t>
        
        <t>These specific issues of Energy Management, as well as other
        issues, are covered by requirements specified in 
        Sections <xref format="counter" target="reportonother"/> and
        <xref format="counter" target="controlother"/>.</t>
        
        <t>The requirements in these sections need a new Energy Management
        framework that deals with the specific nature of Energy Management. 
        The actual standards documents, such as MIB module 
        specifications, address conformance by specifying which 
        features must, should, or may be implemented by compliant 
        implementations.
        </t>
      </section>

    </section>
    
    <section anchor="terminology" title="Terminology">
        
      <t>
  The terms specified in the terminology section are capitalized
  throughout the document; the exceptions are the well-known terms
  "energy" and "power".  These terms are generic and are used in
  generated terms such as "energy-saving", "low-power", etc.

<list style="hanging">
        <t hangText="Energy"><vspace blankLines="1"/>
        Energy is the capacity of a system to do work.  As used 
        by electric utilities, it is generally a reference to 
        electrical energy and is measured in kilowatt-hours (kWh)
        <xref target="IEEE-100"/>.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Power"><vspace blankLines="1"/> 
           Power is the time rate at which energy is emitted, transferred, or
           received; power is usually expressed in watts (or in joules per
           second) <xref target="IEEE-100"/>. (The term "power" does not
           refer to the concept of demand, which is an averaged
           power value.)</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Power Attributes"><vspace blankLines="1"/> 
          Power Attributes are measurements of electric current,
          voltage, phase, and frequencies at a given point in an
          electrical power system (adapted from <xref target="IEC.60050"/>).</t>
        <t>NOTE: Power Attributes are not intended to be "judgmental"
          with respect to a reference or technical value and are
          independent of any usage context.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Energy Management"><vspace blankLines="1"/> 
        Energy Management is a set of functions for measuring, 
        modeling, planning, and optimizing networks to ensure that 
        the network elements and attached devices use energy 
        efficiently and in a manner appropriate to the nature of the
        application and the cost constraints of the organization  
        <xref target="ITU-M.3400"/>.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Energy Management System"><vspace blankLines="1"/> 
        An Energy Management System is a combination of hardware 
        and software used to administer a network with the primary
        purpose being Energy Management.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Energy Monitoring"><vspace blankLines="1"/> 
        Energy Monitoring is a part of Energy Management that deals 
        with collecting or reading information from network elements
        and attached devices and their components to aid in
        Energy Management.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Energy Control"><vspace blankLines="1"/> 
        Energy Control is a part of Energy Management that deals 
        with controlling energy supply and Power State of network 
        elements, as well as attached devices and their components.</t>
      </list></t>

      <t><list style="hanging">
        <t hangText="Power Interface"><vspace blankLines="1"/> 
        A Power Interface is an interface at which a device is 
        connected to a power transmission medium, at which it can in turn
        receive power, provide power, or both.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Power Inlet"><vspace blankLines="1"/> 
        A Power Inlet is a Power Interface at which a device
        can receive power from other devices.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Power Outlet"><vspace blankLines="1"/> 
        A Power Outlet is a Power Interface at which a device
        can provide power to other devices.</t>
      </list></t>
      <t><list style="hanging">
        <t hangText="Power State"><vspace blankLines="1"/> 
        A Power State is a condition or mode of a device that 
        broadly characterizes its capabilities, power consumption, 
        and responsiveness to input <xref target="IEEE-1621"/>.
        </t>
      </list></t>
   
    </section>
    

    <!-- Objectives ============================================ -->

    <section anchor="goals" 
      title="General Considerations Related to Energy Management">
      <t>The basic objective of Energy Management is to operate
      sets of devices using minimal energy, while maintaining 
      a certain level of service.  
      <xref target="EMAN-STATEMENT"></xref>
      presents the applicability of the EMAN framework to a variety of 
      scenarios and also lists use cases and target devices.</t>  

      <section anchor="powerstates" title="Power States">
        <t>
        Entities can be set to an operational state that 
        results in the lowest power level that still meets the 
        service-level performance objectives.  In principle, there 
        are three basic types of Power States for an entity 
        or for a whole system:
        <list style="symbols">
          <t>full Power State</t>

          <t>sleep state (not functional but immediately available)</t>

          <t>off state (may require significant time to become operational)</t>
        </list>
        In specific devices, the number of Power States and their 
        properties vary considerably. Simple entities may only
        have the extreme states: full Power State and off state. 
        Many devices have three basic Power States: on, off, and 
        sleep.  However, more finely grained Power States can be 
        implemented. Examples are various operational low Power States
        in which a device requires less energy than in the
        full power "on" state, but -- compared to the sleep state -- 
        is still operational with reduced performance or 
        functionality.</t>
      </section>

      <section anchor="tradeoffs" 
        title="Saving Energy versus Maintaining Service Level">
        <t>One of the objectives of Energy Management is to reduce 
        energy consumption. While this objective is clear, attaining
        that goal is often difficult.   
        In many cases, there is no way to reduce power without the 
        consequence of a potential service (performance or capacity) 
        degradation.  In this case, a trade-off needs to be made 
        between service-level objectives and energy minimization.  
        In other cases, a reduction of power can 
        easily be achieved while still maintaining 
        sufficient service-level performance, for example, by 
        switching entities to lower Power States when higher
        performance is not needed.</t> 
      </section>

      <section anchor="localglobal" 
               title="Local versus Network-Wide Energy Management">
        <t>Many energy-saving functions are executed locally by 
        an entity; it 
        monitors its usage and dynamically adapts its power 
        according to the required performance. It may, 
        for example, switch to a sleep state when it is not in use,
        or outside of scheduled business hours. 
        An Energy Management System may observe an entity's Power State
        and configure its power-saving policies.</t>

        <t>Energy savings can also be achieved with policies 
        implemented by a network management system that controls 
        Power States of managed entities.  Information about the 
        power received and provided by entities in different
        Power States may be required in order to set such policies.
        Often, this information is best acquired through monitoring.</t>
        
        <t>Network-wide and local Energy Management methods both
        have advantages and disadvantages, and it is often desirable 
        to combine them. Central management is often favorable for 
        setting Power States of a large number of entities at the 
        same time, for example, at the beginning and end of business
        hours in a building. Local management is often preferable 
        for power-saving measures based on local observations, such 
        as the high or low functional load of an entity.</t>
      </section>

      <section anchor="monitoring" 
               title="Energy Monitoring versus Energy Saving">
        <t>Monitoring energy, power, 
        and Power States alone does not reduce the energy
        needed to run an entity. In fact, it may even
        increase it slightly due to monitoring instrumentation that 
        needs energy. Reporting measured quantities
        over the network may also increase energy use, though the 
        acquired information may be an essential 
        input to control loops that save energy.</t>

        <t>Monitoring energy and Power States  
        can also be required for other purposes,
        including:
        <list style="symbols">
          <t>investigating energy-saving potential</t>
          <t>evaluating the effectiveness of energy-saving policies 
          and measures</t>
          <t>deriving, implementing, and testing power management
          strategies</t>
          <t>accounting for the total power received and provided by
          an entity, a network, or a service</t>
          <t>predicting an entity's reliability based on 
          power usage</t>
          <t>choosing the time of the next maintenance cycle for an 
          entity</t>
        </list></t>
      </section>

      <section anchor="requirements" 
               title="Overview of Energy Management Requirements">
        <t>The following basic management functions are required: 
        <list style="symbols">
          <t>monitoring Power States</t>
          <t>monitoring power (energy conversion rate)</t>
          <t>monitoring (accumulated) received and provided 
          energy</t>
          <t>monitoring Power Attributes</t>
          <t>setting Power States</t>
        </list></t>
      
        <t>Power control is complementary to other energy-saving
        measures, such as low-power electronics, energy-saving 
        protocols, energy-efficient device design (for example, 
        low-power modes for components), and energy-efficient 
        network architectures.  Measurement of received and provided
        energy can provide useful data for developing these 
        technologies.</t>
      </section>

    </section>

    <!-- ===== Requirements related to Identity of entities =========  -->

    <section anchor="identity" 
             title="Identification of Entities">
      <t>Entities must be capable of being uniquely identified within
      the context of the management system.  This 
      includes entities that are components of managed devices 
      as well as entire devices.</t> 
      
      <t>Entities that report on or control other entities 
      must identify the entities they report on or control: 
      see <xref target="reportonother"/> or 
      <xref target="controlother"/>, respectively, for the 
      detailed requirements.</t>      
      
      <t> An entity may be an entire device or a 
      component of it. Examples of components of interest are 
      a hard drive, a battery, or a line card. 
      The ability to control individual components to save energy may be
      required. For example, server blades 
      can be switched off when the overall load is low, or line cards
      at switches may be powered down at night.</t>

      <t>Identifiers for devices and components  
      are already defined in standard MIB modules, such as the Link Layer Discovery Protocol (LLDP) 
      MIB module <xref target="IEEE-802.1AB"/> and the Link Layer Discovery
      Protocol -- Media Endpoint Discovery (LLDP-MED) MIB 
      module <xref target="ANSI-TIA-1057"/> for devices, and the 
      Entity MIB module <xref target="RFC6933"/> and the power 
      Ethernet MIB <xref target="RFC3621"/> for components of 
      devices.  Energy Management needs a means to link 
      energy-related information to such identifiers.</t>
        
      <t>Instrumentation for measuring the received and provided energy 
      of a device is typically more expensive than instrumentation 
      for retrieving its Power State.  Many devices may provide 
      Power State information for all individual components  
      separately, while reporting the received and provided energy 
      only for the entire device.</t>

      <section toc="exclude" title="Identifying Entities">
        <t>The standard must provide means for  uniquely identifying
        entities.  Uniqueness must be preserved such that
        collisions of identities are avoided at potential receivers 
        of monitored information.</t>
       </section> 

      <section toc="exclude" 
               title="Persistence of Identifiers">
        <t>The standard must provide means for 
        indicating whether identifiers of entities are 
        persistent across a restart of the entity.</t>
      </section>

      <section toc="exclude" title="Change of Identifiers">
        <t>The standard must provide means to indicate 
        any change of entity identifiers.</t>
      </section>

      <section toc="exclude" 
              title="Using Entity Identifiers of Existing MIB Modules">
        <t>The standard must provide means for 
        reusing entity identifiers from existing standards, including 
        at least the following:        
        <list style="symbols">
          <t>the entPhysicalIndex in the Entity MIB module 
          <xref target="RFC6933"/></t>
          <t>the LldpPortNumber in the LLDP MIB module 
          <xref target="IEEE-802.1AB"/> and in the LLDP-MED MIB 
          module <xref target="ANSI-TIA-1057"/></t>
          <t>the pethPsePortIndex and the pethPsePortGroupIndex 
          in the Power Ethernet MIB <xref target="RFC3621"/></t>
        </list> 
        Generic means for reusing other entity identifiers must be
        provided.</t>
      </section>
    </section>

    
    <!-- ===== Requirements related to entities monitoring === -->

    <section anchor="properties" 
             title="Information on Entities">
      <t>This section describes information on entities for 
      which the standard must provide means for retrieving and 
      reporting.</t>
      
      <t>Required information can be structured 
      into seven groups. 

      <xref target="general"/> specifies requirements for general
      information on entities, such as type of  
      entity or context information.  Requirements for information 
      on Power Inlets and Power Outlets of entities are 
      specified in <xref target="inlet"/>.  The monitoring of power and 
      energy is covered by Sections <xref format="counter" 
      target="Power"/> and <xref format="counter" target="Energy"/>, 
      respectively.  <xref target="state"/> covers requirements 
      related to entities' Power States.  <xref target="battery"/> 
      specifies requirements for monitoring batteries.  Finally, 
      the reporting of time series of values is covered by <xref 
      target="timeseries"/>.</t>
      
      <section anchor="general" 
               title="General Information on Entities">
        <t>For Energy Management, understanding the role and context of
        an entity may be required.  An Energy Management System
        may aggregate values of received and provided energy according
        to a defined grouping of entities.  
        When controlling and setting Power States, it may be helpful  
        to understand the grouping of the entity and role of an
        entity in a network. For example, it may be 
        important to exclude some mission-critical network devices 
        from being switched to lower power or even from being 
        switched off.</t>
        
        <section anchor="type" toc="exclude" 
                 title="Type of Entity">
              <t>The standard must provide means to configure, retrieve,
              and report a textual name or a description of an entity.</t>
        </section>
       
        <section anchor="role" toc="exclude" 
                 title="Context of an Entity">
          <t>The standard must provide means for retrieving and 
          reporting context information on entities, for 
          example, tags associated with an entity that
          indicate the entity's role.</t>
        </section> 

              
        <section anchor="importance" toc="exclude" 
                 title="Significance of Entities">
          <t>The standard must provide means for retrieving and 
          reporting the significance of entities within its 
          context, for example, how important the entity is.
          </t>
        </section> 

        <section anchor="priority" toc="exclude" 
                 title="Power Priority">
          <t>The standard must provide means for retrieving and 
          reporting power priorities of entities. Power 
          priorities indicate an order in which Power States of
          entities are changed, for example, to lower Power States
          for saving power.</t>
        </section> 

        <section toc="exclude" title="Grouping of Entities">
          <t>The standard must provide means for grouping entities.  
          This can be achieved in multiple ways, for example, by 
          providing means to tag entities, assign them to domains, or
          assign device types to them.
          </t>
        </section> 
      </section> 
   
      <section anchor="inlet" title="Power Interfaces">
        <t>A Power Interface is an interface at which a device is 
        connected to a power transmission medium, at which it can in
        turn receive power, provide power, or both.</t>

        <t>A Power Interface is either an inlet or an outlet.  
        Some Power Interfaces change over time from being an inlet 
        to being an outlet and vice versa.  However, most Power 
        Interfaces never change.</t>
        
        <t>Devices have Power Inlets at which they are 
        supplied with electric power. Most devices have a 
        single Power Inlet, while some have multiple inlets. 
        Different Power Inlets on a device are often connected to 
        separate power distribution trees. For Energy Monitoring, 
        it is useful to retrieve information on the number of inlets 
        of a device, the availability of power at inlets, 
        and which inlets are actually in use.</t>
        
        <t>Devices can have one or more Power Outlets for 
        supplying other devices with electric power. </t>

        <t>For identifying and potentially controlling the source of 
        power received at an inlet, identifying the Power Outlet of
        another device at which the received power is provided may be
        required. Analogously, for each outlet, it 
        is of interest to identify the Power Inlets that receive the
        power provided at a certain outlet.  Such information is 
        also required for constructing the wiring topology of 
        electrical power distribution to devices.</t>
        
        <t>Static properties of each Power Interface are required 
        information for Energy Management. Static properties 
        include the kind of electric current (AC or DC), the nominal 
        voltage, the nominal AC frequency, and the number of AC 
        phases.  Note that the nominal voltage is often not a single 
        value but a voltage range, such as, for example, (100V-120V), 
        (100V-240V), (100V-120V,220V-240V).</t>
        
        <section toc="exclude" 
                 title="List of Power Interfaces">
          <t>The standard must provide means for monitoring 
          the list of Power Interfaces of a device.</t>
        </section>

        <section toc="exclude" 
                 title="Operational Mode of Power Interfaces">
          <t>The standard must provide means for monitoring 
          the operational mode of a Power Interface, which is 
          either "Power Inlet" or "Power Outlet".</t>
        </section>

         <section anchor="powersupplier" toc="exclude" 
                  title="Corresponding Power Outlet">
          <t>The standard must provide means for 
          identifying the Power Outlet that provides the power
          received at a Power Inlet.</t>
        </section>

         <section anchor="powersuppliee" toc="exclude" 
                  title="Corresponding Power Inlets">
          <t>The standard must provide means for identifying the 
          list of Power Inlets that receive the power provided at a 
          Power Outlet.</t>
        </section>

        <section anchor="availability" toc="exclude" 
                 title="Availability of Power">
          <t>If the Power States allow it, the standard must provide 
          means for monitoring the availability of power at each Power 
          Interface. This includes indicating whether a power supply
          at a Power Interface is switched on or off.</t>
        </section>

        <section toc="exclude" title="Use of Power">
          <t>The standard must provide means for monitoring 
          each Power Interface if it is actually in use.
          For inlets, this means that the device actually 
          receives power at the inlet. For outlets, this means that 
          power is actually provided from the outlet to one or more 
          devices.</t>
        </section>

        <section toc="exclude" title="Type of Current">
          <t>The standard must provide means for reporting the type 
          of current (AC or DC) for each Power Interface as well as 
          for a device.</t>
        </section> 

        <section toc="exclude" title="Nominal Voltage Range">
          <t>The standard must provide means for reporting the 
          nominal voltage range for each Power Interface.</t>
        </section> 

        <section toc="exclude" title="Nominal AC Frequency">
          <t>The standard must provide means for reporting the 
          nominal AC frequency for each Power Interface.</t>
        </section> 

        <section toc="exclude" title="Number of AC Phases">
          <t>The standard must provide means for reporting the 
          number of AC phases for each Power Interface.</t>
        </section> 

      </section>

      <section anchor="Power" title="Power">
        <t>Power is measured as an instantaneous value or 
        as the average over a time interval. </t>

        <t>Obtaining highly accurate values for power and energy may 
        be costly if dedicated metering hardware is required.
        Entities without the ability to measure with high accuracy
        their power, received energy, and provided energy may just 
        report estimated values, for example, based on load
        monitoring, Power State, or even just the entity type.</t>
        
        <t>Depending on how power and energy values are 
        obtained, the confidence in a reported value and its 
        accuracy will vary.  Entities reporting such values 
        should qualify the confidence in the reported values and
        quantify the accuracy of measurements. For reporting 
        accuracy, the accuracy classes specified in <xref 
        target="IEC.62053-21">IEC 62053-21</xref> and <xref 
        target="IEC.62053-22">IEC 62053-22</xref> should be 
        considered.</t>

        <t>Further properties of the power supplied to a device
        are also of interest. For AC power supply in particular,
        several Power Attributes beyond the real power are of
        potential interest to Energy Management Systems. 
        The set of these properties includes the complex 
        Power Attributes (apparent power, reactive power, and 
        phase angle of the current or power factor) as well as 
        the actual voltage, the actual AC frequency, the Total 
        Harmonic Distortion (THD) of voltage and current, and the 
        impedance of an AC phase or of the DC supply. A new 
        standard for monitoring these Power Attributes should be 
        in line with already-existing standards, such as 
        <xref target="IEC.61850-7-4"/>.</t>
        
        <t>For some network management tasks, it is desirable to 
        receive notifications from entities when their power
        value exceeds or falls below given thresholds.</t>
        
        <section toc="exclude" title="Real Power / Power Factor">
          <t>The standard must provide means for 
          reporting the real power for each Power Interface as well 
          as for an entity.  Reporting power includes reporting the 
          direction of power flow.</t>
        </section>

        <section toc="exclude" title="Power Measurement Interval">
          <t>The standard must provide means for 
          reporting the corresponding time or time interval for 
          which a power value is reported.  The power value can be 
          measured at the corresponding time or averaged over the 
          corresponding time interval.</t>
        </section>

        <section toc="exclude" title="Power Measurement Method">
          <t>The standard must provide means to indicate the 
          method used to obtain these values. Based on how 
          the measurement was conducted, it is possible to associate 
          a certain degree of confidence with the reported power 
          value.  For example, there are methods of measurement such
          as direct power measurement, estimation based on 
          performance values, or hard-coding average power values 
          for an entity.</t>
        </section>

        <section toc="exclude" 
                 title="Accuracy of Power and Energy Values">
          <t>The standard must provide means for reporting the 
          accuracy of reported power and energy values.</t>
        </section>

        <section toc="exclude" title="Actual Voltage and Current">
          <t>The standard must provide means for reporting the 
          actual voltage and actual current for each Power 
          Interface as well as for a device.  
          For AC power supply, means must be 
          provided for reporting the actual voltage and actual 
          current per phase.</t>
        </section> 

        <section toc="exclude" title="High-Power/Low-Power Notifications">
          <t>The standard must provide means for creating
          notifications if power values of an entity rise 
          above or fall below given thresholds.</t>
       </section>

        <section toc="exclude" title="Complex Power / Power Factor">
          <t>The standard must provide means for reporting the 
          complex power for each Power Interface and for each phase 
          at a Power Interface.  In addition to the real power, at least 
          two of the following three quantities need to be 
          reported: apparent power, reactive power, and phase angle.  
          The phase angle can be substituted by the power factor.
          </t>
        </section> 

        <section toc="exclude" title="Actual AC Frequency">
          <t>The standard must provide means for
          reporting the actual AC frequency for each Power Interface. 
          </t>
        </section> 

        <section toc="exclude" title="Total Harmonic Distortion">
          <t>The standard must provide means for
          reporting the Total Harmonic Distortion (THD) of voltage 
          and current for each Power Interface.
          For AC power supply, means must be 
          provided for reporting the THD per phase.</t>

        </section> 

        <section toc="exclude" title="Power Supply Impedance">
          <t>The standard must provide means for reporting the 
          impedance of a power supply for each Power Interface.
          For AC power supply, means must be provided for 
          reporting the impedance per phase.</t>
        </section> 

      </section>

      <section anchor="state" title="Power State">
        <t>Many entities have a limited number of discrete 
        Power States.</t>
        
        <t>There is a need to report the actual Power State
        of an entity and to provide the means for retrieving the list of 
        all supported Power States.</t>
        
        <t>Different standards bodies have already defined sets of 
        Power States for some entities, and others are 
        creating new Power State sets.  In this context, it is 
        desirable that the standard support many of these Power State
        standards. In order to support multiple management
        systems that possibly use different Power State sets while
        simultaneously interfacing with a particular entity, the Energy
        Management System must provide means for supporting multiple 
        Power State sets used simultaneously at an entity.</t>

        <t>Power States have parameters that describe their properties. 
        It is required to have a standardized means for reporting some key
        properties, such as the typical power of an entity in a certain
        state.</t>

        <t>There is also a need to report statistics on Power States,
        including the time spent as well as the received and provided 
        energy in a Power State.</t>

        <section toc="exclude" title="Actual Power State">
          <t>The standard must provide means for 
          reporting the actual Power State of an entity.</t>
        </section>

        <section toc="exclude" 
                 title="List of Supported Power States">
          <t>The standard must provide means for retrieving the list
          of all potential Power States of an entity.</t>
        </section>

        <section toc="exclude" title="Multiple Power State Sets">
          <t>The standard must provide means for supporting multiple
          Power State sets simultaneously at an entity. </t>
        </section>
     
        <section toc="exclude" 
                 title="List of Supported Power State Sets">
          <t>The standard must provide means for retrieving the list
          of all Power State sets supported by an entity.</t>
        </section>

        <section toc="exclude" 
                title="List of Supported Power States within a Set">
          <t>The standard must provide means for retrieving the list
          of all potential Power States of an entity for each
          supported Power State set.</t>
        </section>

        <section toc="exclude" 
                 title="Typical Power Per Power State">
          <t>The standard must provide means for retrieving the
            typical power for each supported Power State.</t>
        </section>

        <section toc="exclude" anchor="statistics" 
                 title="Power State Statistics">
          <t>The standard must provide means for monitoring 
          statistics per Power State, including the total time spent 
          in a Power State, the number of times each state was 
          entered, and the last time each state was entered.  More 
          Power State statistics are addressed by the requirements in
          <xref target="energyperstate"/>.</t>
        </section>

        <section toc="exclude" title="Power State Changes">
          <t>The standard must provide means for generating a 
          notification when the actual Power State of an 
          entity changes.</t>
        </section>        
      </section>

      <section anchor="Energy" title="Energy">
        <t>The monitoring of electrical energy received or provided by
        an entity is a core function of Energy Management.
        Since energy is an accumulated quantity, it is always 
        reported for a certain interval of time.  This can be, 
        for example, the time from the last restart of the  
        entity to the reporting time, the time from another past 
        event to the reporting time, the last given amount of time 
        before the reporting time, or a certain interval specified 
        by two timestamps in the past.</t>
        
        <t>It is useful for entities to record their 
        received and provided energy per Power State and report 
        these quantities.</t>

        <section toc="exclude" title="Energy Measurement">
          <t>The standard must provide means for reporting measured 
          values of energy and the direction of the energy flow 
          received or provided by an entity.  The 
          standard must also provide the means to report the energy
          passing through each Power Interface.</t>
        </section>
          
        <section anchor="timeintervals" toc="exclude" 
            title="Time Intervals">
          <t>The standard must provide means for reporting the 
          time interval for which an energy value is reported. </t>
        </section>

        <section anchor="energyperstate" toc="exclude" 
                 title="Energy Per Power State">
          <t>The standard must provide means for reporting the 
          received and provided energy for each individual Power 
          State.  This extends the requirements on Power State statistics
described in <xref target="statistics"/>.</t>
        </section>

      </section>


      <section anchor="battery" title="Battery State">
        <t>Batteries are special entities that supply power.  
        The status of these batteries is typically controlled by 
        automatic functions that act locally on the entity, and 
        manually by users of the entity. There is a need to monitor 
        the battery status of these entities by network management 
        systems.</t>
        
        <t>Devices containing batteries can be modeled in two ways. 
        The entire device can be modeled as a single entity 
        on which energy-related information is reported, or the 
        battery can be modeled as an individual entity for 
        which energy-related information is monitored individually
        according to requirements in
        Sections <xref target="general" format="counter"/> through
        <xref target="Energy" format="counter"/>.</t>
        
        <t>Further information on batteries is of interest for 
        Energy Management, such as the current charge of the 
        battery, the number of completed charging cycles, the 
        charging state of the battery, its temperature, and 
        additional static and dynamic battery properties. It is 
        desirable to receive notifications if the charge of a 
        battery becomes very low or if a battery needs to be 
        replaced.</t>    
        
        <section toc="exclude" anchor="charge" 
                 title="Battery Charge">
          <t>The standard must provide means for reporting 
          the current charge of a battery, in units of
          milliampere-hours (mAh).</t>
        </section>
        
        <section toc="exclude" title="Battery Charging State">
          <t>The standard must provide means for reporting the 
          charging state (charging, discharging, etc.) of a 
          battery.</t>
        </section>
        
        <section toc="exclude" title="Battery Charging Cycles">
          <t>The standard must provide means for reporting 
          the number of completed charging cycles of a battery.</t>
        </section>

        <section toc="exclude" title="Actual Battery Capacity">
          <t>The standard must provide means for reporting 
          the actual capacity of a battery.</t>
        </section>
        
        <section toc="exclude" title="Actual Battery Temperature">
          <t>The standard must provide means for reporting 
          the actual temperature of a battery.</t>
        </section>
        
        <section toc="exclude" title="Static Battery Properties">
          <t>The standard must provide means for reporting  static 
          properties of a battery, including the nominal capacity, 
          the number of cells, the nominal voltage, and the battery 
          technology.</t>
        </section>
        
        <section toc="exclude" 
                 title="Low Battery Charge Notification">
          <t>The standard must provide means for generating a
          notification when the charge of a battery decreases below
          a given threshold. Note that the threshold may depend on 
          the battery technology.</t>
        </section>        
        
        <section toc="exclude" anchor="replacement" 
                 title="Battery Replacement Notification">
          <t>The standard must provide means for generating a
          notification when the number of charging cycles of a battery 
          exceeds a given threshold.</t>
        </section>        

        <section toc="exclude" title="Multiple Batteries">
          <t>If the battery technology allows, the standard must 
          provide means for meeting requirements in
          Sections <xref format="counter" target="charge"/> through
          <xref format="counter" target="replacement"/> for each 
          individual battery contained in a single entity.
          </t>
        </section>        
      </section>

      <section anchor="timeseries" 
               title="Time Series of Measured Values">
        <t>For some network management tasks, obtaining time series
        of measured values from entities, such as power, energy,
        battery charge, etc., is required.</t>
        
        <t>In general, time series measurements could be obtained in 
        many different ways. Means should be provided to either 
        push such values from the location where they are available 
        to the management system or to have them stored locally for 
        a sufficiently long period of time such that a management 
        system can retrieve the full time series.</t> 
        
        <t>The following issues are to be considered when designing
        time series measurement and reporting functions:
        <list style="numbers">
          <t>Which quantities should be reported?</t>
          <t>Which time interval type should be used (total, delta, 
          sliding window)?</t>
          <t>Which measurement method should be used (sampled, 
          continuous)?</t>
          <t>Which reporting model should be used (push or pull)?
          </t>
        </list>
        </t>
        
        <t>The most discussed and probably most needed quantity 
        is energy. But a need for others, such as power and 
        battery charge, can be identified as well.</t>

        <t>There are three time interval types under discussion for 
        accumulated quantities such as energy.  They can be reported 
        as total values, accumulated between the last restart of the 
        measurement and a certain timestamp. Alternatively, energy 
        can be reported as delta values between two consecutive 
        timestamps.  Another alternative is reporting values for 
        sliding windows as specified in <xref 
        target="IEC.61850-7-4"/>.</t>

        <t>For non-accumulative quantities, such as power, different 
        measurement methods are considered. Such quantities can be 
        reported using values sampled at certain timestamps or,
        alternatively, by mean values for these quantities averaged 
        between two (consecutive) timestamps or over a sliding 
        window.</t>

        <t>Finally, time series can be reported using different 
        reporting models, particularly push-based or pull-based.  
        Push-based reporting can, for example, be realized by 
        reporting power or energy values using the
        IP Flow Information Export (IPFIX) protocol 
        <xref target="RFC5101"/> <xref target="RFC5102"/>.
        The Simple Network Management Protocol (SNMP) 
        <xref target="RFC3411"/> is an example of a protocol that 
        can be used for realizing pull-based reporting of time 
        series.</t> 
        
        <t>For reporting time series of measured values, the 
        following requirements have been identified.  Further 
        decisions concerning issues discussed above need to be 
        made when developing concrete Energy Management 
        standards.</t>

       <section toc="exclude" title="Time Series of Energy Values">
          <t>The standard must provide means for reporting time series
           of energy values. If the comparison of time series between
           multiple entities is required, then time synchronization 
           between those entities must be provided (for example, with 
           the Network Time Protocol <xref target="RFC5905"/>).</t>
        </section>


        <section toc="exclude" title="Time Series Interval Types">
          <t>The standard must provide means for supporting 
          alternative interval types. The requirement in <xref  target="timeintervals"/> applies to every
          reported time value.</t>
        </section>

        <section toc="exclude" title="Time Series Storage Capacity">
          <t>The standard should provide means for
          reporting the number of values of a time series that can 
          be stored for later reporting.</t> 
        </section>
      </section>

    </section>
    

    <!-- ===== Requirements related to Entity Control ================ -->

    <section anchor="control" title="Control of Entities">
      <t>Many entities control their Power State locally.
      Other entities need interfaces for an Energy Management System
      to control their Power State.</t>

      <t>A power supply is typically not self-managed by devices,
      and control of a power supply is typically not conducted as 
      an interaction between an Energy Management System and 
      the device itself. It is rather an interaction between
      the management system and a device providing power at its 
      Power Outlets.  Similar to Power State control, power supply 
      control may be policy driven. Note that shutting down the 
      power supply abruptly may have severe consequences for the 
      device.</t>

      <section toc="exclude" title="Controlling Power States">
        <t>The standard must provide means for 
        setting Power States of entities.</t>
      </section>

      <section anchor="outletcontrol" toc="exclude" 
               title="Controlling Power Supply">
        <t>The standard must provide means for switching a power 
        supply off or turning a power supply on at Power Interfaces 
        providing power to one or more devices.</t>
      </section>
    </section>

    <section anchor="reportonother" 
             title="Reporting on Other Entities">
      <t>As discussed in <xref target="properties"/>, not all 
      energy-related information may be available at the entity
      in question. Such information may be provided by other 
      entities.  This section covers only the reporting of 
      information. See <xref target="controlother"/> for 
      requirements on controlling other entities.</t>
            
      <t>There are cases where a power supply unit switches power 
      for several entities by turning power on or off at a 
      single Power Outlet or where a power meter measures the 
      accumulated power of several entities at a single 
      power line.  Consequently, it should be possible to report 
      that a monitored value does not relate to just a single 
      entity but is an accumulated value for a set of 
      entities.  All of the entities belonging to
      that set need to be identified.</t>
      
      <section toc="exclude" title="Reports on Other Entities">
        <t>The standard must provide means for an entity to 
        report information on another entity. </t>
      </section>

      <section toc="exclude" 
        title="Identity of Other Entities on Which Information Is Reported">
        <t>For entities that report on one or more other entities, 
        the standard must provide means for reporting the identity 
        of other entities on which information is reported.  
        Note that, in some situations, a manual configuration might 
        be required to populate this information.
        </t>
      </section>

      <section toc="exclude" 
        title="Reporting Quantities Accumulated over Multiple Entities">
        <t>The standard must provide means for reporting the list 
        of all entities from which contributions are 
        included in an accumulated value.</t>
      </section>

      <section toc="exclude" 
          title="List of All Entities on Which Information Is Reported">
        <t>For entities that report on one or more other entities,
        the standard must provide means for reporting the complete 
        list of all those entities on which energy-related 
        information can be reported.</t>
      </section>

      <section toc="exclude" 
               title="Content of Reports on Other Entities">
        <t>For entities that report on one or more other entities,
        the standard must provide means for indicating what type or types
        of energy-related information can be reported, and for which
        entities.</t>
      </section>
    </section>

    <!-- ==== Requirements Control of entities ====== -->
    <section anchor="controlother" 
             title="Controlling Other Entities">
      <t>This section specifies requirements for controlling
      Power States and power supply of entities by
      communicating with other entities that have the means for 
      doing that control.</t>
      
      <section anchor="statecontrol" 
        title="Controlling Power States of Other Entities">
        <t>Some entities have control over Power States of 
        other entities. For example, a gateway to a building 
        system may have the means to control the Power State of 
        entities in the building that do not have an IP interface. 
        For this scenario and other similar cases, a way to make
        this control accessible to the Energy Management System is needed.</t>
        
        <t>In addition, it is required that an entity
        that has its state controlled by other entities has the
        means to report the list of these other entities.
        </t>

        <section toc="exclude" 
          title="Control of Power States of Other Entities">
          <t>The standard must provide means for an Energy Management System
          to send Power State control commands to an entity that
          controls the Power States of entities other than the entity to which
          the command was sent.</t>
        </section>

        <section toc="exclude" 
          title="Identity of Other Power State Controlled Entities">
          <t>The standard must provide means for reporting the 
          identities of the entities for which the reporting 
          entity has the means to control their Power States.
          Note that, in some situations, a manual configuration 
          might be required to populate this information.
          </t>
        </section>

        <section toc="exclude" 
                title="List of All Power State Controlled Entities">
          <t>The standard must provide means for an entity to
          report the list of all entities for which it can 
          control the Power State.</t>
        </section>

        <section toc="exclude" 
                 title="List of All Power State Controllers">
          <t>The standard must provide means for an entity 
          that receives commands controlling its Power State from 
          other entities to report the list of all those
          entities.</t>
        </section>
      </section>

      <section anchor="supplycontrol" 
         title="Controlling Power Supply">
        <t>Some entities may have control of the power 
        supply of other entities, for example, because the 
        other entity is supplied via a Power Outlet of the 
        entity. For this and similar cases, means are needed 
        to make this control accessible to the Energy Management System.
        This need is already addressed by the requirement in
        <xref target="outletcontrol"/>.</t>
        
        <t>In addition, it is required that an entity that 
        has its supply controlled by other entities has the
        means to report the list of these other entities.  
        This need is already addressed by requirements in
        Sections <xref format="counter" target="powersupplier"/> and 
        <xref format="counter" target="powersuppliee"/>.</t>
      </section>

   </section>

    <section title="Security Considerations">
      
      <t>Controlling Power State and power supply of  
      entities are considered highly sensitive actions, since they can 
      significantly affect the operation of directly and indirectly 
      connected devices.  Therefore, all control actions addressed in 
      Sections <xref format="counter" target="control"/> and  <xref 
      format="counter" target="controlother"/> must be sufficiently 
      protected through authentication, authorization, and integrity
      protection mechanisms.</t>

      <t>Entities that are not sufficiently secure to operate directly 
      on the public Internet do exist and can be a significant cause 
      of risk, for example, if the remote control functions described 
      in Sections <xref format="counter" target="control"/> and  <xref 
      format="counter" target="controlother"/> can be exercised on 
      those devices from anywhere on the Internet.  The standard needs 
      to provide means for dealing with such cases.  One solution is 
      providing means that allow the isolation of such devices, e.g.,
      behind a sufficiently secured gateway. Another solution is
      to allow compliant implementations to disable sensitive functions,
      or to not implement such functions at all.</t>

      <t>The monitoring of energy-related quantities of an entity as
      addressed in Sections <xref format="counter" target="properties"/>
      through <xref format="counter" target="controlother"/> can be used
      to derive more information
      than just the received and provided energy; therefore, monitored data 
      requires protection. This protection includes authentication 
      and authorization of entities requesting access to monitored 
      data as well as confidentiality protection during transmission 
      of monitored data.  Privacy of stored data in an entity
      must be taken into account. Monitored data may be used as
      input to control, accounting, and other actions, so integrity of
      transmitted information and authentication of the origin may be
      needed.</t>

      <section toc="exclude" title="Secure Energy Management">
        <t>The standard must provide privacy, integrity, and 
        authentication mechanisms for all actions addressed in 
        Sections <xref format="counter" target="properties"/> 
        through <xref format="counter" target="controlother"/>.  
        The security mechanisms must meet the security requirements 
        detailed in Section 1.4 of <xref target="RFC3411"/>.</t>
      </section>

      <section toc="exclude" title="Isolation of Insufficiently Secure Entities">
        <t>The standard must provide means to allow the isolation of 
        entities that are not sufficiently secure to operate on the 
        public Internet, e.g., behind a gateway that implements
        sufficient security that the vulnerable entities are not 
        directly exposed to the Internet.</t>
      </section>

      <section toc="exclude" title="Optional Restriction of Functions">
        <t>The standard must allow compliant implementations to disable
        sensitive functions, or to not implement such functions at all, when
        operating in environments that are not sufficiently secured.
        This applies particularly to
        the control functions described in Sections <xref format="counter" 
        target="control"/> and  <xref format="counter" target="controlother"/>.</t>
      </section>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to thank Ralf Wolter for his first 
      essay on this document. Many thanks to William Mielke, 
      John Parello, JinHyeock Choi, Georgios Karagiannis,
      and Michael Suchoff for their helpful comments on the document.
      Many thanks to Stephen Farrell, Robert Sparks, Adrian Farrel, 
      Barry Leiba, Brian Haberman, Peter Resnick, Sean Turner, 
      Stewart Bryant, and Ralph Droms for their IESG reviews.
      Finally, special thanks to the document shepherd, Nevil Brownlee,
      and to the EMAN working group chairs: Nevil Brownlee and Bruce Nordman. 
      </t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

      &rfc3411;

      &rfc3621;

      &rfc6933;

      <reference anchor="ANSI-TIA-1057">
        <front>
          <title>TIA Standard -- Telecommunications -- IP Telephony Infrastructure -- Link Layer Discovery Protocol for Media Endpoint Devices</title> 
          <author><organization>Telecommunications Industry Association, ANSI-TIA-1057-2006</organization></author>
          <date year="2006" month="April" /> 
        </front>
      </reference>

      <reference anchor="IEEE-100">
        <front>
          <title>The Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition</title>
          <author><organization>IEEE</organization></author>
          <date year="2000" month="December" /> 
        </front>
      </reference>

      <reference anchor="IEC.62053-21">
        <front>
          <title>Electricity metering equipment (a.c.) -- Particular requirements -- Part 21: Static meters for active energy (classes 1 and 2)</title> 
          <author><organization>International Electrotechnical Commission</organization></author>
          <date month="January" year="2003"/> 
        </front>
      </reference>      

      <reference anchor="IEC.62053-22">
        <front>
          <title>Electricity metering equipment (a.c.) -- Particular requirements -- Part 22: Static meters for active energy (classes 0,2 S and 0,5 S)</title> 
          <author><organization>International Electrotechnical Commission</organization></author>
          <date month="January" year="2003"/> 
        </front>
      </reference>      

      <reference anchor="IEC.61850-7-4">
        <front>
          <title>Communication networks and systems for power utility automation -- Part 7-4: Basic communication structure -- Compatible logical node classes and data object classes</title> 
          <author><organization>International Electrotechnical Commission</organization></author>
          <date month="March" year="2010"/> 
        </front>
      </reference>

      <reference anchor="IEEE-1621">
        <front>
        <title>IEEE 1621-2004 - IEEE Standard for User Interface Elements in
Power Control of Electronic Devices Employed in Office/Consumer Environments</title>
          <author><organization>Institute of Electrical and Electronics Engineers</organization></author>
          <date year="2004"/> 
              </front>
      </reference>

      <reference anchor="IEEE-802.1AB">
        <front>
          <title>IEEE Std 802.1AB-2009 -- IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Discovery</title> 
          <author><organization>IEEE Computer Society</organization></author>
          <date month="September" year="2009"/> 
        </front>
      </reference>   

    </references>
    
    <references title="Informative References">

      &rfc5101;

      &rfc5102;

      &rfc5905;

<!-- draft-ietf-eman-applicability-statement (ID exists) -->
<reference anchor='EMAN-STATEMENT'>
<front>
<title>Energy Management (EMAN) Applicability Statement</title>
<author initials='B' surname='Schoening' fullname='Brad Schoening'>
    <organization />
</author>
<author initials='M' surname='Chandramouli' fullname='Mouli Chandramouli'>
    <organization />
</author>
<author initials='B' surname='Nordman' fullname='Bruce Nordman'>
    <organization />
</author>
<date month='April' year='2013' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

      <reference anchor="IEC.60050" target="http://www.electropedia.org/iev/iev.nsf/welcome?openform">
        <front>
          <title>Electropedia: The World's Online Electrotechnical Vocabulary</title>
          <author><organization>International Electrotechnical Commission</organization></author>
          <date year="2013"/> 
        </front>
      </reference> 

      <reference anchor="ITU-M.3400">
        <front>
          <title>ITU-T Recommendation M.3400 -- Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits -- Telecommunications Management Network - TMN management functions</title>
          <author><organization>International Telecommunication Union</organization></author>
          <date month="February" year="2000"/> 
        </front>
      </reference>   

    </references>
     
  </back>
</rfc>
