Skip to main content

Energy Management Framework
draft-ietf-eman-framework-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7326.
Authors Benoît Claise , John Parello , Little Silver , Juergen Quittek , Bruce Nordman
Last updated 2012-03-12
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Dan Romascanu
IESG IESG state Became RFC 7326 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-eman-framework-04
Network Working Group                                  B. Claise 
     Internet-Draft                                        J. Parello 
     Intended Status: Informational               Cisco Systems, Inc. 
     Expires: September 12, 2012                         B. Schoening 
                                               Independent Consultant 
                                                           J. Quittek 
                                                      NEC Europe Ltd. 
                                                           B. Nordman 
                                                    Lawrence Berkeley 
                                                  National Laboratory 
                                                       March 12, 2012 

                                            

      
                      Energy Management Framework 
                      draft-ietf-eman-framework-04 

     Status of this Memo 

        This Internet-Draft is submitted to IETF in full 
        conformance with the provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        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."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be 
        accessed  at http://www.ietf.org/shadow.html  
         
        This Internet-Draft will expire on September, 2012.                     


      
     <Claise, et. Al>         Expires Sept 12 2012             [Page 1] 

     Internet-Draft           <EMAN Framework>        March 2012 
      
     Copyright Notice 
      
        Copyright (c) 2012 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. 
         
      
      
     Abstract 

        This document defines a framework for providing Energy 
        Management for devices within or connected to communication 
        networks, and components thereof.  The framework defines an 
        Energy Management Domain as a set of Energy Objects, for 
        which each Energy Object is identified, classified and 
        given context.   Energy Objects can be monitored and/or 
        controlled with respect to Power, Power State, Energy, 
        Demand, Power Quality, and battery.  Additionally the 
        framework models relationships and capabilities between 
        Energy Objects.   
         
         
         
         
         
         
      
         
                                            

      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 2] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
      
     Table of Contents 
         
        1. Introduction............................................5 
           1.1. Energy Management Document Overview................6 
        2. Terminology.............................................7 
           Energy Management.......................................8 
           Energy Management System (EnMS).........................8 
           ISO Energy Management System............................9 
           Energy..................................................9 
           Power..................................................10 
           Demand.................................................10 
           Power Quality..........................................10 
           Electrical Equipment...................................11 
           Non-Electrical Equipment (Mechanical Equipment)........11 
           Energy Object..........................................11 
           Electrical Energy Object...............................11 
           Non-Electrical Energy Object...........................11 
           Energy Monitoring......................................11 
           Energy Control.........................................12 
           Energy Management Domain...............................12 
           Energy Object Identification...........................12 
           Energy Object Context..................................13 
           Energy Object Relationship.............................13 
           Energy Object Parent...................................14 
           Energy Object Child....................................15 
           Power State............................................15 
           Power State Set........................................16 
           Nameplate Power........................................16 
        3. Requirements & Use Cases...............................16 
        4. Energy Management Issues...............................18 
           4.1. Power Supply......................................19 
              4.1.1 Identification of Power Supply and Powered 
              Devices.............................................20 
              4.1.2 Multiples Devices Supplied by a Single Power 
              Line................................................21 
              4.1.3 Multiple Power Supply for a Single Powered 
              Device..............................................22 
              4.1.4 Bidirectional Power Interfaces................23 
              4.1.5 Relevance of Power Supply Issues..............23 
              4.1.6 Remote Power Supply Control...................24 
           4.2. Power and Energy Measurement......................24 
              4.2.1 Local Estimates...............................24 
              4.2.2 Management System Estimates...................25 
           4.3. Reporting Sleep and Off States....................25 
           4.4. Energy Device and Energy Device Components........25 
           4.5. Non-Electrical Equipment..........................26 
        5. Energy Management Reference Model......................26 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 3] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
           5.1. Energy Object, Energy Object Components and 
           Containment Tree.......................................29 
        6. Framework High Level Concepts and Scope................30 
           6.1. Energy Object and Energy Management Domain........31 
           6.2. Power Interface...................................31 
           6.3. Energy Object Identification and Context..........32 
              6.2.1 Energy Object Identification..................32 
              6.2.2 Context in General............................32 
              6.2.3 Context: Importance...........................32 
              6.2.4 Context: Keywords.............................33 
              6.2.5 Context: Role.................................34 
           6.4. Energy Object Relationships.......................34 
              6.4.1 Energy Object Children Discovery..............36 
              6.4.2 Energy Object Relationship Conventions and 
              Guidelines..........................................37 
           6.5. Energy Monitoring.................................37 
              6.5.1 Power Measurement.............................38 
           6.6. Energy Control....................................40 
              6.5.1 IEEE1621 Power State Series...................41 
              6.5.2 DMTF Power State Series.......................41 
              6.5.3 EMAN Power State Set..........................42 
           6.7. Energy Objects Relationship Extensions............45 
        7. Structure of the Information Model: UML 
        Representation............................................45 
        8. Configuration..........................................50 
        9. Fault Management.......................................51 
        10. Examples..............................................52 
        11. Relationship with Other Standards Development 
        Organizations.............................................55 
           11.1. Information Modeling.............................55 
        12. Security Considerations...............................56 
        12.1. Security Considerations for SNMP....................56 
        13. IANA Considerations...................................57 
        14. Acknowledgments.......................................57 
        15. References............................................57 
           Normative References...................................57 
           Informative References.................................58 
      

      
        TO DO/OPEN ISSUE 
        - Add figures to the section 10 examples 
        - The figure 5 and 6 from the framework must be updated 
          with the notion of power interfaces 
        - Aggregation Relationship is different compared to the 
          other Relationships. There are some use cases: a building 
          mediator implementing the MIB, with some subtended 
          devices, a meter for many devices, etc... However, this 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 4] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          is also a generic function. We could argue that an 
          aggregation function is something that is not particular 
          to the EMAN context. 
        - Since we speak about Power Interface now, we need to 
          double the EO Relationships here and in [EMAN-AWARE-MIB]: 
          Example: poweredBy versus providingPower. 
        - Energy Interface or Power Interface, which term is best? 
        - The UML must be aligned with the latest [EMAN-AWARE-MIB] 
          and [EMAN-AWARE-MIB] document versions. 
        - JOHN: Does the multiple URIs requirement apply to all of 
          the defined relationship fields?  For example, can 
          eoProxyBy have multiple URIs?  What about the other 
          relationships? Answer: yes, but need to be explained 
        - Needs scrub for terminology and new "provide and receive 
          energy" consensus. Power and energy also incorrectly used 
          interchangeably from merged text. 
        - Some reference in the terminology section will certainly 
          have to be removed. 
        - Complete the section "Energy Object Relationship 
          Guidelines and Conventions" 
         
         
     1. Introduction 

        Network management is divided into the five main areas 
        defined in the ISO Telecommunications Management Network 
        model: Fault, Configuration, Accounting, Performance, and 
        Security Management (FCAPS) [X.700].  Absent from this 
        management model is any consideration of Energy Management, 
        which is now becoming a critical area of concern worldwide 
        as seen in [ISO50001].  
         
        Note that Energy Management has particular challenges in 
        that a power distribution network is responsible for the 
        supply of energy to various devices and components, while a 
        separate communication network is typically used to monitor 
        and control the power distribution network. 
         
        This document defines a framework for providing Energy 
        Management for devices within or connected to communication 
        networks.  The framework describes how to identify, 
        classify and provide context for a device in a 
        communications network from the point of view of Energy 
        Management. 
      
        The identified device (Energy Device) or identified 
        components within a device (Energy Device Component) can 
        then be monitored for Energy Management by obtaining 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 5] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        measurements for Power, Energy, Demand and Power Quality.  
        If a device contains batteries, they can be also be 
        monitored and managed.  An Energy Object state can be 
        monitored or controlled by providing an interface expressed 
        as one or more Power State Sets.  The most basic example of 
        Energy Management is a single Energy Object reporting 
        information about itself.  However, in many cases, energy 
        is not measured by the Energy Object itself, but by a meter 
        located upstream in the power distribution tree.  An 
        example is a power distribution unit (PDU) that measures 
        energy received by attached devices and may report this to 
        an Energy Management System (EnMS).  Therefore, Energy 
        Objects are recognized as having relationships to other 
        devices in the network from the point of view of Energy 
        Management.  These relationships include Aggregation 
        Relationship, Metering Relationship, Power Source 
        Relationship, and Proxy Relationship.  
      
                             
     1.1. Energy Management Document Overview 

        The EMAN standard provides a set of specifications for 
        Energy Management.  This document specifies the framework, 
        per the Energy Management requirements specified in [EMAN-
        REQ]. 
         
        The applicability statement document [EMAN-AS] provides a 
        list of use cases, a cross-reference between existing 
        standards and the EMAN standard, and shows how this 
        framework relates to other frameworks. 
         
        The Energy-aware Networks and Devices MIB [EMAN-AWARE-MIB] 
        specifies objects for addressing Energy Object 
        Identification, classification, context information, and 
        relationships from the point of view of Energy Management. 
                           
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains  
        objects for monitoring of Power, Energy, Demand, Power 
        Quality and Power States. 
         
        Further, the battery monitoring MIB [EMAN-BATTERY-MIB] 
        defines managed objects that provide information on the 
        status of batteries in managed devices. 
         
         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 6] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     2. Terminology 

        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]. 
         
       EDITOR'S NOTE:  
           - All terms are copied over from the version 
           5 of the [EMAN-TERMINOLOGY] draft.  The only 
           differences in definition are  
            o Dependency Relationship is removed 
            o Energy Object Relationship improved to 
               remove the Dependency Relationship  
            o "Reference: herein" has not been copied 
               over from the terminology draft. 
           - "All" terms have been copied. Potentially, 
           some unused terms might have to be removed. 
           Alternatively, as this document is the first 
           standard track document in the EMAN WG, it 
           may become the reference document for the 
           terminology (instead of cutting/pasting the 
           terminology in all drafts) 
           - RFC-EDITOR: the Relationships need to be 
           updated. 
           - The Power Interface definition has been 
           added 
            
        Energy Device 
         
           An Energy Device is an Energy Object that may be 
           monolithic or contain Energy Device Components 
         
         
        Energy Device Component 
         
           An Energy Device Component is an Energy Object 
           contained in an Energy Device, for which the containing 
           Energy Device provides individual energy management 
           functions.  Typically, the Energy Device Component  
           is part the Energy Device physical containment tree  
           in the ENTITY-MIB [RFC4133]. 
            
      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 7] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
       Energy Management 

          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 
          is appropriate for the nature of the 
          application and the cost constraints of the 
          organization.  
          Reference: Adapted from [ITU-T-M-3400] 
          Example: A set of computer systems that will 
          poll electrical meters and store the readings  
          NOTES:  
          1. Energy management refers to the activities, 
            methods, procedures and tools that pertain 
            to measuring, modeling, planning, 
            controlling and optimizing the use of energy 
            in networked systems [NMF]. 
          2. Energy Management is a management domain 
            which is congruent to any of FCAPS areas of 
            management in the ISO/OSI Network Management 
            Model [TMN]. Energy Management for 
            communication networks and attached devices 
            is a subset or part of an organization's 
            greater Energy Management Policies. 
           
       Energy Management System (EnMS) 

          An Energy Management System is a combination of 
          hardware and software used to administer a 
          network with the primary purpose being Energy 
          Management. 
          Reference: Adapted from [1037C] 
          Example: A single computer system that polls 
          data from devices using SNMP 
          NOTES: 
          1. An Energy Management System according to 
            [ISO50001] (ISO-EnMS) is a set of systems or 
            procedures upon which organizations can 
            develop and implement an energy policy, set 
            targets, action plans and take into account 
            legal requirements related to energy use.  

      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 8] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
            An EnMS allows organizations to improve 
            energy performance and demonstrate 
            conformity to requirements, standards, 
            and/or legal requirements.   
          2. Example ISO-EnMS:  Company A defines a set 
            of policies and procedures indicating there 
            should exist multiple computerized systems 
            that will poll energy from their meters and 
            pricing / source data from their local 
            utility. Company A specifies that their CFO 
            should collect information and summarize it 
            quarterly to be sent to an accounting firm 
            to produce carbon accounting reporting as 
            required by their local government.  
          3. For the purposes of EMAN, the definition 
            from [1037C] is the preferred meaning of an 
            Energy Management System (EnMS).  The 
            definition from [ISO50001] can be referred 
            to as ISO Energy Management System (ISO-
            EnMS). 
           
       ISO Energy Management System 

         Energy Management System as defined by 
       [ISO50001]  
          
       Energy  

          That which does work or is capable of doing 
          work. As used by electric utilities, it is 
          generally a reference to electrical energy and 
          is measured in kilo-watt hours (kWh). 
          Reference: [IEEE100] 
          NOTES 
          1. Energy is the capacity of a system to 
            produce external activity or perform work 
            [ISO50001] 
           

      
      
     <Claise, et. Al>         Expires Sep 12, 2012             [Page 9] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
       Power 

          The time rate at which energy is emitted, 
          transferred, or received; usually expressed in 
          watts (or in joules per second). 
          Reference: [IEEE100] 
           
       Demand  

          The average value of power or a related 
          quantity over a specified interval of time. 
          Note: Demand is expressed in kilowatts, 
          kilovolt-amperes, kilovars, or other suitable 
          units. 
           
          Reference: [IEEE100] 
          NOTES: 
          1. typically kilowatts 
          2. Energy providers typically bill by Demand 
            measurements as well as for maximum Demand 
            per billing periods.  Power values may spike 
            during short-terms by devices, but Demand 
            measurements recognize that maximum Demand 
            does not equal maximum Power during an 
            interval. 
           
       Power Quality  

          Characteristics of the electric current, 
          voltage and frequencies at a given point in an 
          electric power system, evaluated against a set 
          of reference technical parameters. These 
          parameters might, in some cases, relate to the 
          compatibility between electricity supplied in 
          an electric power system and the loads 
          connected to that electric power system. 
          Reference: [IEC60050] 
           
           

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 10] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
       Electrical Equipment 

          A general term including materials, fittings, 
          devices, appliances, fixtures, apparatus, 
          machines, etc., used as a part of, or in 
          connection with, an electric installation. 
          Reference: [IEEE100] 
        
       Non-Electrical Equipment (Mechanical Equipment) 

           A general term including materials, fittings, 
          devices appliances, fixtures, apparatus, 
          machines, etc., used as a part of, or in 
          connection with, non-electrical power 
          installations. 
          Reference: Adapted from [IEEE100] 
        
       Energy Object      

          An Energy Object (EO) is a piece of equipment 
          that is part of or attached to a 
          communications network that is monitored, 
          controlled, or aids in the management of 
          another device for Energy Management. 
           
        
       Electrical Energy Object  

          An Electrical Energy Object (EEO) is an Energy 
          Object that is a piece of Electrical Equipment  
           
            
       Non-Electrical Energy Object  

          A Non-Electrical Energy Object (NEEO) an 
          Energy Object that is a piece of Non-
          Electrical Equipment. 
           
           
       Energy Monitoring 

          Energy Monitoring is a part of Energy 
          Management that deals with collecting or 
          reading information from Energy Objects to aid 
          in Energy Management.   
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 11] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          NOTES:  
          1. This could include Energy, Power, Demand, 
            Power Quality, Context and/or Battery 
            information. 
        
       Energy Control 

          Energy Control is a part of Energy Management 
          that deals with directing influence over 
          Energy Objects.  
        
          NOTES:  
          1. Typically in order to optimize or ensure its 
             efficiency. 
           
            
       Energy Management Domain 

          An Energy Management Domain is a set of Energy Objects 
          where all objects in the domain are considered one unit 
          of management.  
           
          For example, power distribution units and all of the 
          attached Energy Objects are part of the same Energy 
          Management Domain. 
        
          For example, all EEO's drawing power from the 
          same distribution panel with the same AC 
          voltage within a building, or all EEO's in a 
          building for which there is one main meter, 
          would comprise an Energy Management Domain.  
           
          NOTES:  
          1. Typically, this set will have as members all 
             EO's that are powered from the same source. 
              
         
           
       Energy Object Identification 

          Energy Object Identification is a set of 
          attributes that enable an Energy Object to be: 
          uniquely identified among all Energy Management 
          Domains; linked to other systems; classified as 
          to type, model, and or manufacturer 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 12] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        
       Energy Object Context 

          Energy Object Context is a set of attributes 
          that allow an Energy Management System to 
          classify the use of the Energy Object within an 
          organization.   
          NOTES:  
          1. The classification could contain the use 
            and/or the ranking of the Energy Object as 
            compared to other Energy Objects in the 
            Energy Management Domain. 
           
            
       Energy Object Relationship 

          An Energy Object Relationship is a functional association 
          among Energy Objects 
           
          NOTES 
          1. Relationships can be named and could include 
          Aggregation, Metering, Power Source, Proxy and 
          Dependency.  
          2. The Energy Object is the noun or entity in the 
          relationship with the relationship described as the verb. 
           
          Example: If EO x is a piece of Electrical Equipment and 
          EO y is an electrical meter clamped onto x's power cord, 
          then x and y have a Metering Relationship. It follows 
          that y meters x and that x is metered by y. 
          Reference: Adapted from [CHEN] 
         

        Aggregation Relationship 
         
          An Aggregation Relationship is an Energy Object 
          Relationship where one Energy Object aggregates the 
          Energy Management information of one or more other Energy 
          Objects. These Energy Objects are referred to as having 
          an Aggregation Relationship.   
           
          NOTES:  
          Aggregate values may be obtained by reading values from 
          multiple Energy Objects and producing a single value of 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 13] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          more significant meaning such as average, count, maximum, 
          median, minimum, mode and most commonly sum [SQL]. 
        

        Metering Relationship 
         
          A Metering Relationship is an Energy Object Relationship 
          where one Energy Object measures the Power or Energy of 
          one or more other Energy Objects. These Energy Objects 
          are referred to as having a Metering Relationship. 
           
          Example: a PoE port on a switch measures the Power it 
          provides to the connected Energy Object. 
           
         
       Power Source Relationship 
          A Power Source Relationship is an Energy Object 
          Relationship where one Energy Object is the source of or 
          distributor of Power to one or more other Energy Objects. 
          These Energy Objects are referred to as having a Power 
          Source Relationship.   
           
          Example: a PDU provides power for a connected device. 
           
         
        Proxy Relationship 
           
          A Proxy Relationship is an Energy Object Relationship 
          where one Energy Object provides the Energy Management 
          capabilities on behalf of one or more other Energy 
          Objects. These Energy Objects are referred to as having a 
          Proxy Relationship.  
           
          Example: a protocol gateways device for Building 
          Management Systems (BMS) with subtended devices. 
           
           
       Energy Object Parent 

          An Energy Object Parent is an Energy Object 
          that participates in an Energy Object 
          Relationships and is considered as providing 
          the capabilities in the relationship.   
           
          Example: in a Metering Relationship, the 
          Energy Object that is metering is called the 
          Energy Object Parent, while the Energy Object 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 14] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          that is metered is called the Energy Object 
          Child.  
           
        
       Energy Object Child 

          An Energy Object Child is an Energy Object 
          that participates in an Energy Object 
          Relationships and is considered as receiving 
          the capabilities in the relationship. 
           
          Example: in a Metering Relationship, the 
          Energy Object that is metering is called the 
          Energy Object Parent, while the Energy Object 
          that is metered is called the Energy Object 
          Child.  
           
           
        Power Interface 
         
          A power interface is an Energy Object that serves as a 
          interconnection among Energy Objects, and participates in 
          a  
          Power Source Relationship.  
             
        
       Power State 

          A Power State is a condition or mode of a 
          device that broadly characterizes its 
          capabilities, power consumption, and 
          responsiveness to input. 
           
          Reference: Adapted from [IEEE1621]   
           
          NOTES:  
           
          1. A Power State can be seen as a power setting 
             of an Energy Object that influences the 
             power consumption, the available 
             functionality, and the responsiveness of the 
             Energy Object.   
           
          2. A Power State can be viewed as one method 
             for Energy Control 
           
           

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 15] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
       Power State Set 

          A collection of Power States that comprise one 
          named or logical grouping of control is a 
          Power State Set.   
        
          Example: The states {on, off, and sleep} as 
          defined in [IEEE1621], or the 16 power states 
          as defined by the [DMTF] can be considered two 
          different Power State Sets. 
           
           
       Nameplate Power 

          The Nameplate Power is the maximal (nominal) 
          Power that a device can support.  
        
          NOTES:  
           
          1. This is typically determined via load 
             testing and is specified by the manufacturer 
             as the maximum value required for operating 
             the device.  This is sometimes referred to 
             as the worst-case Power.  The actual or 
             average Power may be lower.  The Nameplate 
             Power is typically used for provisioning and 
             capacity planning. 
      
      
      
     3. Requirements & Use Cases  

        Requirements for Power and Energy monitoring for networking 
        devices are specified in [EMAN-REQ].  The Energy Management 
        use cases covered by this framework are covered in the EMAN 
        applicability statement document in [EMAN-AS].  Typically 
        requirements and use cases for communication networks cover 
        the devices that make up the communication network and 
        endpoints.  
         
        With Energy Management, there exists a wide variety of 
        devices that may be contained in the same deployments as a 
        communication network but comprise a separate facility, 
        home, or power distribution network.   

        Target devices for Energy Management are all Energy Objects 
        that can directly or indirectly be monitored or controlled 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 16] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        by an Energy Management System (EnMS) using the Internet 
        protocol, for example:  
            - Simple electrical appliances / fixtures  
            - Hosts, such as a PC, a datacenter server, or a 
        printer 
            - Routers  
            - Switches 
            - A component within devices, such as a battery inside 
        a PC, a line card inside a switch, etc... 
            - Power over Ethernet (PoE) endpoints 
            - Power Distribution Units (PDU)  
            - Protocol gateway devices for Building Management 
        Systems (BMS) 
            - Electrical meters 
            - Sensor controllers with subtended sensors 
      
        There may also exist varying protocols deployed among these 
        power distributions and communication networks.  
         
        For an Energy Management framework to be useful, it should 
        also apply to these types of separate networks as they 
        connect and interact with a communications network.  
         
        This is the first version of the IETF Energy Management 
        framework.  Though it already covers a wide range of use 
        cases, there are still a lot of potential ones that are not 
        covered, yet.  A simple example is the limitation to 
        discrete power states without parameters.  Some devices 
        have energy-related properties that not well described with 
        discrete power 
        states, for example a dimmer with a continuous power range 
        from 0%-100%.  Other devices may have even more parameters 
        than just a single percentage value.   
         
        Also policy-controlled energy management functions at 
        Energy Devices are not covered.  An example would be a 
        policy telling a Energy Device not to raise its power above 
        a given power value.  These and further use cases would 
        need an extension of the framework described in this 
        document.  It is up to future updates of this document to 
        select more of such use-cases and to cover them by 
        extensions or revisions of the present framework. 
      
      
         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 17] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     4. Energy Management Issues 

        This section explains special issues of Energy Management 
        particularly concerning power supply, Power and Energy 
        metering, and the reporting of low Power States. 

        To illustrate the issues we start with a simple and basic 
        scenario with a single powered device that receives Energy 
        and that reports energy-related information about itself to 
        an Energy Management System (EnMS), see Figure 1 

         

                               +--------------------------+                           
                               | Energy Management System |                           
                               +--------------------------+                           
                                           ^  ^ 
                                monitoring |  | control 
                                           v  v 
                                    +-----------------+ 
                                    | powered device  | 
                                    +-----------------+ 

                Figure 1: Basic energy management scenario 
         

        The powered device may have local energy control 
        mechanisms, for example putting itself into a sleep mode 
        when appropriate, and it may receive energy control 
        commands for similar purposes from the EnMS.  Information 
        reported from a powered device to the EnMS includes at 
        least the Power State of the powered device (on, sleep, 
        off, etc.). 

        This and similar cases are well understood and likely to 
        become very common for Energy Management.  They can be 
        handled with well established and standardized management 
        procedures.  The only missing components today are 
        standardized information and data models for reporting and 
        configuration, such as, for example, energy-specific MIB 
        modules [RFC2578] and YANG modules [RFC6020]. 

        However, the nature of energy supply and use introduces 
        some issues that are special to Energy Management.  The 
        following subsections address these issues and illustrate 
        them by extending the basic scenario in Figure 1. 

         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 18] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     4.1. Power Supply 

        A powered device may supply itself with power.  Sensors, 
        for example, commonly have batteries or harvest Energy.  
        However, most powered devices that are managed by an EnMS 
        receive external power. 
         
        While a huge number of devices receive Power from unmanaged 
        supply systems, the number of manageable power supply 
        devices is increasing. 
         
        In datacenters, many Power Distribution Units (PDUs) allow 
        the EnMS to switch power individually for each socket and 
        also to measure the provided Power.  Here there is a big 
        difference to many other network management tasks: In such 
        and similar cases, switching power supply for a powered 
        device or monitoring its power is not done by communicating 
        with the actual powered device, but with an external power 
        supply device (in this case, the PDU). Note that those 
        external power supply devices may be an external power 
        meter). 
         
        Consequently, a standard for Energy Management must not 
        just cover the powered devices that provide services for 
        users, but also the power supply devices (which are powered 
        devices as well) that monitor or control the power supply 
        for other powered devices. 
         
        A very simple device such as a plain light bulb can be 
        switched on or off only by switching its power supply.  
        More complex devices may have the ability to switch off 
        themselves or to bring themselves to states in which they 
        consume very little power.  For these devices as well, it 
        is desirable to monitor and control their power supply. 
         
        This extends the basic scenario from Figure 1 by a power 
        supply device, see Figure 2. 
         

                    +-----------------------------------------+ 
                    |         energy management system        | 
                    +-----------------------------------------+ 
                          ^  ^                       ^  ^ 
               monitoring |  | control    monitoring |  | control 
                          v  v                       v  v 
                    +--------------+        +-----------------+ 
                    | power supply |########| powered device  | 
                    +--------------+        +-----------------+ 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 19] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                            ######## power supply line 

                          Figure 2: Power Supply 
                                      
        The power supply device can be as simple as a plain power 
        switch.  It may offer interfaces to the EnMS to monitor and 
        to control the status of its power outlets, as with PDUs 
        and Power over Ethernet (PoE) [IEEE-802.3at] switches. 
         
        The relationship between supply devices and the powered 
        devices they serve creates several problems for managing 
        power supply: 
           o  Identification of corresponding devices 
              *  A given powered device may be need to identify the  
                 supplying power supply device. 
              *  A given power supply device may need to identify 
        the 
                 corresponding supplied powered device(s). 
           o  Aggregation of monitoring and control for multiple 
        powered  
              devices 
              *  A power supply device may supply multiple powered  
                 devices with a single power supply line. 
           o  Coordination of power control for devices with 
        multiple  
              power inlets 
              *  A powered device may receive power via multiple 
        power  
                 lines controlled by the same or different power 
        supply  
                 devices. 
         

     4.1.1 Identification of Power Supply and Powered Devices 

        When a power supply device controls or monitors power 
        supply at one of its power outlets, the effect on other 
        devices is not always clear without knowledge about wiring 
        of power lines.  The same holds for monitoring.  The power 
        supplying device can report that a particular socket is 
        powered, and it may even be able to measure power and 
        conclude that there is a consumer drawing power at that 
        socket, but it may not know which powered device receives 
        the provided power. 
         
        In many cases it is obvious which other device is supplied 
        by a certain outlet, but this always requires additional 
        (reliable) information about power line wiring.  Without 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 20] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        knowing which device(s) are powered via a certain outlet, 
        monitoring data are of limited value and the consequences 
        of switching power on or off may be hard to predict. 
         
        Even in well organized operations, powered devices' power 
        cords can be plugged into the wrong socket, or wiring plans 
        changed without updating the EnMS accordingly. 
         
        For reliable monitoring and control of power supply 
        devices, additional information is needed to identify the 
        device(s) that receive power provided at a particular 
        monitored and controlled socket. 
         
        This problem also occurs in the opposite direction.  If 
        power supply control or monitoring for a certain device is 
        needed, then the supplying power supply device has to be 
        identified. 
         
        To conduct Energy Management tasks for both power supply 
        devices and other powered devices, sufficiently unique 
        identities are needed, and knowledge of their power supply 
        relationship is required. 
         

     4.1.2 Multiples Devices Supplied by a Single Power Line 

        The second fundamental problem is the aggregation of 
        monitoring and control that occurs when multiple powered 
        devices are supplied by a single power supply line.  It is 
        often required that the EnMS has the full list of powered 
        devices connected to a single outlet as in Figure 3. 
         

         

                      +---------------------------------------+ 
                      |       energy management system        | 
                      +---------------------------------------+ 
                         ^  ^                       ^  ^ 
              monitoring |  | control    monitoring |  | control 
                         v  v                       v  v 
                      +--------+        +------------------+ 
                      | power  |########| powered device 1 | 
                      | supply |   #    +------------------+-+ 
                      +--------+   #######| powered device 2 | 
                                     #    +------------------+-+ 
                                     #######| powered device 3 | 
                                            +------------------+ 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 21] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                Figure 3: Multiple Powered Devices Supplied  
                           by Single Power Line 
         

        With this list, the single status value has clear meaning 
        and is the sum of all powered devices.  Control functions 
        are limited by the fact that supply for the concerned 
        devices can only be switched on or off for all of them at 
        once.  Individual control at the supply is not possible. 
         
        If the full list of devices powered by a single supply line 
        is not known by the controlling power supply device, then 
        control of power supply is problematic, because the 
        consequences of control actions can only be partially 
        known. 
         

     4.1.3 Multiple Power Supply for a Single Powered Device 

        The third problem arises from the fact that there are 
        devices with multiple power supplies.  Some have this for 
        redundancy of power supply, some for just making internal 
        power converters (for example, from AC mains power to DC 
        internal power) redundant, and some because the capacity of 
        a single supply line is insufficient. 
         

                   +----------------------------------------------+ 
                   |          energy management system            | 
                   +----------------------------------------------+ 
                       ^  ^              ^  ^              ^  ^ 
                  mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | 
        ctrl. 
                       v  v              v  v              v  v 
                   +----------+      +----------+      +----------+ 
                   | power    |######| powered  |######| power    | 
                   | supply 1 |######| device   |      | supply 2 | 
                   +----------+      +----------+      +----------+ 

         Figure 4: Multiple Power Supply for Single Powered Device 
         
        The example in Figure 4 does not necessarily show a real 
        world scenario, but it shows the two cases to consider: 
           o  multiple power supply lines between a single power 
        supply  
              device and a powered device 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 22] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
           o  different power supply devices supplying a single 
        powered     
              device 
        In any such case there may be a need to identify the 
        supplying power supply device individually for each power 
        inlet of a powered device. 
         
        Without this information, monitoring and control of power 
        supply for the powered device may be limited. 
         
         
     4.1.4 Bidirectional Power Interfaces 

        Low wattage DC systems may allow power to be delivered bi-
        directionally.  Energy stored in batteries on one device 
        can be delivered back to a power hub which redirects the 
        current to power another device.  In this situation, the 
        interface can function as both an inlet and outlet.   
         
        The framework for Energy Management introduces the notion 
        of  Power Interface, which can model a power inlet and a 
        power outlet, depending on the conditions.  The Power 
        Interface reports power direction, as well as the energy 
        received, supplied and the net result. 
         

     4.1.5 Relevance of Power Supply Issues 

        In some scenarios, the problems with power supply do not 
        exist or can be sufficiently solved.  With Power over 
        Ethernet (PoE) [IEEE-802.3at], there is always a one-to-one 
        relationship between a Power Sourcing Equipment (PSE) and a 
        Powered Device (PD).  Also, the Ethernet link on the line 
        used for powering can be used to identify the two connected 
        devices. 
         
        For supply of AC mains power, the three problems described 
        above cannot be solved in general.  There is no commonly 
        available protocol or automatic mechanism for identifying 
        endpoints of a power line. 
         
        And, AC power lines support supplying multiple powered 
        devices with a single line and commonly do. 
         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 23] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     4.1.6 Remote Power Supply Control 

        There are three ways for an energy management system to 
        change the Power State of an powered devices.  First is for 
        the EnMS to provide policy or other useful information 
        (like the electricity price) to the powered device for it 
        to use in determining its Power State.  The second is 
        sending the powered devices a command to switch to another 
        Power State.  The third is to utilize an upstream device 
        (to the powered device) that has capabilities to switch on 
        and off power at its outlet. 
         
        Some Energy Objects do not have capabilities for receiving 
        commands or changing their Power States by themselves.  
        Such Energy Objects may be controlled by switching on and 
        off the power supply for them and so have particular need 
        for the third method. 
         
        In Figure 4, the power supply can switch on and off power 
        at its power outlet and thereby switch on and off power 
        supply for the connected powered device. 
         

     4.2. Power and Energy Measurement 

        Some devices include hardware to directly measure their 
        Power and Energy consumption.  However, most common 
        networked devices do not provide an interface that gives 
        access to Energy and Power measurements.  Hardware 
        instrumentation for this kind of measurements is typically 
        not in place and adding it incurs an additional cost. 
         
        With the increasing cost of Energy and the growing 
        importance of Energy Monitoring, it is expected that in 
        future more devices will include instrumentation for power 
        and energy measurements, but this may take quite some time. 
         

     4.2.1 Local Estimates 

        One solution to this problem is for the powered device to 
        estimate its own Power and consumed Energy.  For many 
        Energy Management tasks, getting an estimate is much better 
        than not getting any information at all. 

        Estimates can be based on actual measured activity level of 
        a device or it can just depend on the power state (on, 
        sleep, off, etc.).          
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 24] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        The advantage of estimates is that they can be realized 
        locally and with much lower cost than hardware 
        instrumentation.  Local estimates can be dealt with in 
        traditional ways.  They don't need an extension of the 
        basic scenarios above.  However, the powered device needs 
        an energy model of itself to make estimates. 

         

     4.2.2 Management System Estimates 

        Another approach to the lack of instrumentation is 
        estimation by the EnMS.  The EnMS can estimate Power based 
        on basic information on the powered device, such as the 
        type of device, or also its brand/model and functional 
        characteristics. 
         
        Energy estimates can combine the typical power level by 
        Power State with reported data about the Power State. 
         
        If the EnMS has a detailed energy model of the device, it 
        can produce better estimates including the actual power 
        state and actual activity level of the device.  Such 
        information can be obtained by monitoring the device with 
        conventional means of performance monitoring. 
         
         
     4.3. Reporting Sleep and Off States 

        Low power modes pose special challenges for energy 
        reporting because they may preclude a device from listening 
        to and responding to network requests.  Devices may still 
        be able to reliably track energy use in these modes, as 
        power levels are usually static and internal clocks can 
        track elapsed time in these modes. 
         
        Some devices do have out-of-band or proxy abilities to 
        respond to network requests in low-power modes.  Others 
        could use proxy abilities in an energy management protocol 
        to improve this reporting, particularly if the powered 
        device sends out notifications of power state changes. 
         
     4.4. Energy Device and Energy Device Components 

        While the primary focus of energy management is entire 
        powered devices, i.e. Energy Devices, sometimes it is 
        necessary or desirable to manage Energy Device Components 
        such as line cards, fans, disks, etc.   
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 25] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
         
        The concept of a Power Interface may not apply to Energy 
        Device Components since they may receive Energy from a pool 
        available from the encompassing device.  For example, a DC-
        powered blade server in a chassis may have its own identity 
        on the network and be managed as a single device but its 
        energy may be received from a shared power source among all 
        blades in the chassis. 
         
         
     4.5. Non-Electrical Equipment 

        The primary focus of this framework is for the management 
        of Electrical Equipment.  Some Non-Electrical Equipment may 
        be connected to a communication networks and could have 
        their energy managed if normalize to the electrical units 
        for power and energy. 
         
        Some examples of Non-Electrical Equipment that may be 
        connected to a communication network are: 
        1) A controller for compressed air.  The controller is 
          electrical only for its network connection.  The 
          controller is fueled by natural gas and produces 
          compressed air.  The energy transferred via compressed 
          air is distributed to devices on a factory floor via a 
          Power Interface: tools (drills, screwdrivers, assembly 
          line conveyor belts). The energy measured is non-
          electrical (compressed air).   
          EDITOR'S NOTE: Note that, in such as case, some might 
          argue that the "energy interface" term might be more 
          accurate than Power Interface. To be discussed. 
            
        2) A controller for steam. The controller is electrical for 
          its network attachment but it burns tallow and produces 
          steam to subtended boilers. The energy is non-electrical 
          (steam). 
         
     5. Energy Management Reference Model 

        The scope of this framework is to enable network and 
        network-attached devices to be administered for Energy 
        Management.  The framework recognizes that in complex 
        deployments Energy Objects may communicate over varying 
        protocols.  For example the communications network may use 
        IP Protocols (SNMP) but attached Energy Object Parent may 
        communicate to Energy Object Children over serial 
        communication protocols like BACNET, MODBUS etc.  The 
        likelihood of getting these different topologies to convert 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 26] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        to a single protocol is not very high considering the rate 
        of upgrades of facilities and energy related devices. 
        Therefore the framework must address the simple case of a 
        uniform IP network and a more complex mixed 
        topology/deployment. 
         
        As displayed in Figure 5, the most basic energy management 
        reference model is composed of an EnMS that obtains Energy 
        Management information from Energy Objects.  The Energy 
        Object (EO) returns information for Energy Management 
        directly to the EnMS.  
         
        The protocol of choice for Energy Management is SNMP, as 
        three MIBs are specified for Energy Management: the energy-
        aware MIB [EMAN-AWARE-MIB], the energy monitoring MIB 
        [EMAN-MON-MIB], and the battery MIB [EMAN-BATTERY-MIB].  
        However, the EMAN requirement document [EMAN-REQ] also 
        requires support for a push model distribution of time 
        series values.  The following diagrams mention IPFIX 
        [RFC5101] as one possible solution for implementing a push 
        mode transfer, however this is for illustration purposes 
        only.  The EMAN standard does not require the use of IPFIX 
        and acknowledges that other alternative solutions may also 
        be acceptable. 
         
                            +---------------+     
                            |      EnMS     |                -   - 
                            +-----+---+-----+                ^   ^ 
                                  |   |                      |   | 
                                  |   |                      |S  |I 
                        +---------+   +----------+           |N  |P 
                        |                        |           |M  |F 
                        |                        |           |P  |I 
               +-----------------+      +--------+--------+  |   |X 
               | EO            1 |  ... | EO            N |  v   | 
               +-----------------+      +-----------------+  -   - 
                                               
                    Figure 5: Simple Energy Management  
         
         
        As displayed in the Figure 5, a more complex energy 
        reference model includes Energy Managed Object Parents and 
        Children.  The Energy Managed Object Parent returns 
        information for themselves as well as information according 
        to the Energy Managed Object Relationships. 
         
         
                           +---------------+     
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 27] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                           |      EnMS     |               -   - 
                           +-----+--+------+               ^   ^ 
                                 |  |                      |   | 
                                 |  |                      |S  |I 
                    +------------+  +--------+             |N  |P 
                    |                        |             |M  |F 
                    |                        |             |P  |I 
            +------------------+     +------+-----------+  |   |X 
            | EO               |     | EO               |  v   | 
            | Parent 1         | ... | Parent N         |  -   - 
            +------------------+     +------------------+ 
                           |||                  .      
          One or           |||                  .      
          Multiple         |||                  .      
          Energy           |||                  .    
          Object           |||                  .      
          Relationship(s): |||                     
          - Aggregation    |||      +-----------------------+ 
          - Metering       |||------| EO Child 1            | 
          - Power Source   ||       +-----------------------+ 
          - Proxy          ||        
                           ||       +-----------------------+ 
                           ||-------| EO Child 2            | 
                           |        +-----------------------+ 
                           | 
                           |         
                           |--------           ...      
                           |         
                           |         
                           |        +-----------------------+ 
                           |--------| EO Child M            | 
                                    +-----------------------+ 
                                               
         
                                               
                 Figure 6: Complex Energy Management Model 
         
      
        While both the simple and complex Energy Management models 
        contain an EnMS, this framework doesn't impose any 
        requirements regarding a topology with a centralized EnMS 
        or one with distributed Energy Management via the Energy 
        Objects within the deployment. 
         
        Given the pattern in Figure 6, the complex relationships 
        between Energy Objects can be modeled (refer also to 
        section 5.3):     

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 28] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
             - A PoE device modeled as an Energy Object Parent with 
               the Power Source, Metering, and Proxy Relationships 
               for one or more Energy Object Children 
             - A PDU modeled as an Energy Object Parent with the 
               Power Source and Metering Relationships for the 
               plugged in Electrical Equipment (the Energy Object 
               Children) 
             - Building management gateway, used as proxy for non 
               IP protocols, is modeled as an Energy Object Parent 
               with the Proxy Relationship, and potentially the 
               Aggregation Relationship to the managed Electrical 
               Equipment  
             - Etc. 
      
     The communication between the Energy Object Parent and Energy 
     Object Children is out of the scope of this framework. 
         
     5.1. Energy Object, Energy Object Components and Containment 
        Tree 

        The framework for Energy Management manages two different 
        types of Energy Objects: Energy Device and Energy Device 
        Components.  A typical example of anEnergy Device is a 
        switch.  However, a port within the switch, which provides 
        Power to one end point, is also an Energy Object if it 
        meters the power provided.  A second example is PC, which 
        is a typical Energy Device, while the battery inside the PC 
        is a Energy Object Component, managed as an individual 
        Energy Object.  Some more examples of Energy Device 
        Components: power supply within a router,  an outlet within 
        a smart PDU, etc... 
         
        In the [EMAN-AWARE-MIB], each Energy Object is managed with 
        an unique value of the entPhysicalIndex index from the 
        ENTITY-MIB [RFC4133]  
         
        The ENTITY-MIB [RFC4133] specifies the notion of physical 
        containment tree, as: 
          "Each physical component may be modeled as 'contained' 
          within 
          another physical component.  A "containment-tree" is the 
          conceptual sequence of entPhysicalIndex values that 
          uniquely specifies the exact physical location of a 
          physical component within the managed system.  It is 
          generated by 'following and recording' each 
          'entPhysicalContainedIn' instance 'up the tree towards 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 29] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          the root', until a value of zero indicating no further 
          containment is found." 
         
        A Energy Object Component in the Energy Management context 
        is a special Energy Object that is a physical component as 
        specified by the ENTITY-MIB physical containment tree.  
         
         
         
     6. Framework High Level Concepts and Scope 

        Energy Management can be organized into areas of concern 
        that include: 
         
        - Energy Object Identification and Context - for modeling 
        and planning  
        - Energy Monitoring - for energy measurements 
        - Energy Control - for optimization 
        - Energy Procurement - for optimization of resources 
         
        While an EnMS may be a central point for corporate 
        reporting, cost, environmental impact, and regulatory 
        compliance, Energy Management in this framework excludes 
        Energy procurement and the environmental impact of energy 
        use.  As such the framework does not include: 
        - Manufacturing costs of an Energy Object in currency or 
        environmental units 
        - Embedded carbon or environmental equivalences of an 
        Energy Object 
        - Cost in currency or environmental impact to dismantle or 
        recycle an Energy Object 
        - Supply chain analysis of energy sources for Energy Object 
        deployment 
        - Conversion of the usage or production of energy to units 
        expressed from the source of that energy (such as the 
        greenhouse gas emissions associated with 1000kW from a 
        diesel source). 
         
        The next sections describe Energy Management organized into 
        the following areas: 
         
         - Energy Object and Energy Management Domain 
         - Energy Object Identification and Context  
         - Energy Object Relationships 
         - Energy Monitoring  
         - Energy Control   

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 30] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
         - Deployment Topologies 
        
         
     6.1. Energy Object and Energy Management Domain 

        In building management, a meter refers to the meter 
        provided by the utility used for billing and measuring 
        power to an entire building or unit within a building.  A 
        sub-meter refers to a customer or user installed meter that 
        is not used by the utility to bill but instead used to get 
        readings from sub portions of a building.  

        An Energy Management Domain should map 1:1 with a metered 
        or sub-metered portion of the site.  An Energy Object is 
        part of a single Energy Management Domain.  The Energy 
        Management Domain MAY be configured on an Energy Object: 
        the default value is a zero-length string. 

        If all Energy Objects in the physical containment tree (see 
        ENTITY-MIB) are part of the same Energy Management Domain, 
        then it is safe to state that the Energy Object at the root 
        of that containment tree is in that Energy Management 
        Domain. 

        An Energy Object Child may inherit the domain value from an 
        Energy Object Parent or the Energy Management Domain may be 
        configured directly in an Energy Object Child.  

         

     6.2. Power Interface 

        There are some similarities between Power Interfaces and 
        network interfaces.  A network interface can be used in 
        different modes, such as sending or receiving on an 
        attached line.  The Power Interface can be receiving or 
        providing power. 
         
        Most Power Interfaces never change their mode, but as the 
        mode is simply a recognition of the current direction of 
        electricity flow, there is no barrier to a mode change. 
         
        A power interface can have capabilities for metering power 
        and other electric quantities at the shared power 
        transmission medium. 
         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 31] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        This capability is modeled by an association to a power 
        meter. 
         
        In analogy to MAC addresses of network interfaces, a 
        globally 
        unique identifier is assigned to each Power Interface.   
         
        Physically, a Power Interface can be located at an AC power 
        socket, an AC power cord attached to a device, an 8P8C 
        (RJ45) PoE socket, etc. 
           
         

     6.3. Energy Object Identification and Context  

     6.2.1 Energy Object Identification 

        Energy Objects MUST be associated with a value that 
        uniquely identifies the Energy Object among all the Energy 
        Management Domains within an EnMS.  A Universal Unique 
        Identifier (UUID) [RFC4122] MUST be used to uniquely 
        identify an Energy Object.  

        Every Energy Object SHOULD have a unique printable name 
        within the Energy Management Domain.  Possible naming 
        conventions are: textual DNS name, MAC-address of the 
        device, interface ifName, or a text string uniquely 
        identifying the Energy Object.  As an example, in the case 
        of IP phones, the Energy Object name can be the device's 
        DNS name. 

         

     6.2.2 Context in General 

        In order to aid in reporting and in differentiation between 
        Energy Objects, each Energy Object optionally contains 
        information establishing its business, site, or 
        organizational context within a deployment, i.e. the Energy 
        Object Context. 

         

     6.2.3 Context: Importance 

        An Energy Object can provide an importance value in the 
        range of 1 to 100 to help rank a device's use or relative 
        value to the site.  The importance range is from 1 (least 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 32] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        important) to 100 (most important).  The default importance 
        value is 1.   

        For example: A typical office environment has several types 
        of phones, which can be rated according to their business 
        impact.  A public desk phone has a lower importance (for 
        example, 10) than a business-critical emergency phone (for 
        example, 100).  As another example: A company can consider 
        that a PC and a phone for a customer-service engineer is 
        more important than a PC and a phone for lobby use. 

        Although EnMS and administrators can establish their own 
        ranking, the following is a broad recommendation: 

        . 90 to 100 Emergency response  

        . 80 to 90 Executive or business-critical  

        . 70 to 79 General or Average  

        . 60 to 69 Staff or support  

        . 40 to 59 Public or guest  

        . 1  to 39 Decorative or hospitality 

         

     6.2.4 Context: Keywords 

        An Energy Object can provide a set of keywords.  These 
        keywords are a list of tags that can be used for grouping, 
        summary reporting within or between Energy Management 
        Domains, and for searching.  All alphanumeric characters 
        and symbols (other than a comma), such as #, (, $, !, and 
        &, are allowed.  Potential examples are: IT, lobby, 
        HumanResources, Accounting, StoreRoom, CustomerSpace, 
        router, phone, floor2, or SoftwareLab.  There is no default 
        value for a keyword. 

        Multiple keywords can be assigned to a device.  White 
        spaces before and after the commas are excluded, as well as 
        within a keyword itself. In such cases, the keywords are 
        separated by commas and no spaces between keywords are 
        allowed.  For example, "HR,Bldg1,Private". 

         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 33] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     6.2.5 Context: Role 

        An Energy Object can provide a "role description" string 
        that indicates the purpose the Energy Object serves in the 
        EnMS.  This could be a string describing the context the 
        device fulfills in deployment. 

        Administrators can define any naming scheme for the role of 
        a device.  As guidance a two-word role that combines the 
        service the device provides along with type can be used 
        [IPENERGY] 

        Example types of devices: Router, Switch, Light, Phone, 
        WorkStation, Server, Display, Kiosk, HVAC. 

        Example Services by Line of Business: 

          Line of Business     Service 

           Education            Student, Faculty, Administration,  
                                Athletic 

          Finance              Trader, Teller, Fulfillment 

          Manufacturing        Assembly, Control, Shipping 

          Retail               Advertising, Cashier 

          Support              Helpdesk, Management 

          Medical              Patient, Administration, Billing 

        Role as a two-word string: "Faculty Desktop", "Teller 
        Phone", "Shipping HVAC", "Advertising Display", "Helpdesk 
        Kiosk", "Administration Switch". 

         

     6.4. Energy Object Relationships 

        Two Energy Objects MAY establish an Energy Object 
        Relationship. Within a relationship one Energy Object 
        becomes an Energy Object Parent while the other becomes an 
        Energy Object Child. 

        The Power Source Relationship gives the view the wiring 
        topology.  For example: a data center server receiving 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 34] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        power from two specific Power Interfaces from two different 
        PDUs.  

        The Metering Relationship gives the view of the metering 
        topology.  Standalone meters can be placed anywhere in a 
        power distribution tree.  For example, utility meters 
        monitor and report accumulated power consumption of the 
        entire building. Logically, the metering topology overlaps 
        with the wiring topology, as meters are connected to the 
        wiring topology.  A typical example is meters that clamp 
        onto the existing wiring. 

        The Proxy Relationship allows software objects to be 
        inserted into the wiring or metering topology to aid in 
        managing (monitoring and/or control) the Energy Domain.  

        From a EnMS management point of view, this implies that 
        there is yet another management topology that EnMS will 
        need to be aware of. 

        In the ideal situation, the wiring, the metering, and the 
        management topologies overlap.  For Example: A Power-over-
        Ethernet (PoE) device (such as an IP phone or an access 
        point) is attached to a switch port.  The switch port is 
        the source of power for the attached device, so the Energy 
        Object Parent is the switch port, which acts as a Power 
        Interface, and the Energy Object Child is the device 
        attached to the switch.  This Energy Object Parent (the 
        switch) has three Energy Object Relations with this Energy 
        Object Child (the remote Energy Object): Power Source 
        Relationship, Metering Relationship, and Proxy 
        Relationship. 

        However, the three topologies (wiring, metering, and 
        management) don't always overlap.  For example, when a 
        protocol gateways device for Building Management Systems 
        (BMS) controls subtended devices, which themselves receive 
        Power from PDUs or wall sockets. 

        Note: The Aggregation Relationship is slightly different 
        compared to the other relationships (Power Source, 
        Metering, and Proxy Relationships) as this refers more to a 
        management function. 

        The communication between the parent and child for 
        monitoring or collection of power data is left to the 
        device manufacturer.  For example: A parent switch may use 
        LLDP to communicate with a connected child, and a parent 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 35] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        lighting controller may use BACNET to communicate with 
        child lighting devices. 

        The Energy Object Child MUST keep track of its Energy 
        Object Parent(s) along with the Energy Object Relationships 
        type(s).  The Energy Object Parent MUST keep track of its 
        Energy Object Child(ren), along with the Energy Object 
        Relationships type(s). 

         

     6.4.1 Energy Object Children Discovery 

        There are multiple ways that the Energy Object Parent can 
        discover its Energy Object Children: : 
         
          . In case of PoE, the Energy Object Parent automatically 
             discovers an Energy Object Child when the Child 
             requests power. 
          . The Energy Object Parent and Children may run the Link 
             Layer Discovery Protocol [LLDP], or any other 
             discovery protocol, such as Cisco Discovery Protocol 
             (CDP).  The Energy Object Parent might even support 
             the LLDP-MED MIB [LLDP-MED-MIB], which returns extra 
             information on the Energy Object Children.  
          . The Energy Object Parent may reside on a network 
             connected to a facilities gateway.  A typical example 
             is a converged building gateway, monitoring several 
             other devices in the building, and serving as a proxy 
             between SNMP and a protocol such as BACNET. 
          . A different protocol between the Energy Object Parent 
             and the Energy Object Children.  Note that the 
             communication specifications between the Energy Object 
             Parent and Children is out of the scope of this 
             document.   
          
        However, in some situations, it is not possible to discover 
        the Energy Object Relationships, and they must be set 
        manually.  For example, in today' network, an administrator 
        must assign the connected Energy Object to a specific PDU 
        Power Interface, with no means of discovery other than that 
        manual connection. 
              
         
        When an Energy Object Parent is a Proxy, the Energy Object 
        Parent SHOULD enumerate the capabilities it is providing 
        for the Energy Object Child.  The child would express that 
        it wants its parent to proxy capabilities such as, energy 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 36] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        reporting, power state configurations, non physical wake 
        capabilities (such as WoL)), or any combination of 
        capabilities. 
         

     6.4.2 Energy Object Relationship Conventions and Guidelines 

        EDITOR'S NOTE: this section needs to be completed 
         
        This Energy Management framework doesn't impose too many 
        "MUST" rules related to the Energy Object Relationships.  
        Indeed, there are always corner cases that would be 
        excluded with too strict specifications. However, this 
        Energy Management framework proposes a series of 
        guidelines, indicated with "SHOULD" and "MAY": 
        - The Energy Device SHOULD NOT establish Power Source 
          Relationship with Energy Device Component 
        - Power Source Relationship SHOULD be established with next 
          known Power Interface in the wiring topology.  It may 
          happen that the some Energy Objects in the wiring 
          topology are not known to the administrator.  Therefore, 
          it may happen that a Power Source Relationship is 
          established between two non connected Power Interfaces. 
        - If an Energy Object A has a Power Source Relationship 
          "Poweredby" with the Energy Object B, and if the Energy 
          Object B has a Power Source Relationship "Poweredby" with 
          the Energy Object C, then the Energy Object A SHOULD NOT 
          have a Power Source Relationship "PoweredBby" the Energy 
          Object C. 
         
         
     6.5. Energy Monitoring 

        For the purposes of this framework energy will be limited 
        to electrical energy in watt hours.  Other forms of Energy 
        Objects that use or produce non-electrical energy may be 
        part of an Energy Management Domain (See Section 4.5. )  
        but MUST provide information converted to and expressed in 
        watt hours. 

        Each Energy Object will have information that describes 
        power information, along with how that measurement was 
        obtained or derived (actual measurement, estimated, or 
        presumed).  For Energy Objects that can report actual power 
        readings, an optional energy measurement can be provided. 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 37] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        Optionally, an Energy Object can further describe the Power 
        information with Power Quality information reflecting the 
        electrical characteristics of the measurement. 

        Optionally, an Energy Object that can report actual power 
        readings can have odometers that provide the energy used, 
        produced, and net energy in kWh.  These values are 
        odometers that accumulate the power readings.  If energy 
        values are returned then the three odometers must be 
        provided along with a description of accuracy. 

        Optionally, an Energy Object can provide demand information 
        over time.  

         

     6.5.1 Power Measurement 

        A power measurement MUST be qualified with the units, 
        magnitude, direction of power flow, and SHOULD be qualified 
        by what means the measurement was made (ex: Root Mean 
        Square versus Nameplate). 

        In addition, the Energy Object should describe how it 
        intends to measure power as one of consumer, producer or 
        meter of usage.  Given the intent, readings can be 
        summarized or analyzed by an EnMS.  For example metered 
        usage reported by a meter and consumption usage reported by 
        a device connected to that meter may naturally measure the 
        same usage.  With the two measurements identified by intent 
        a proper summarization can be made by an EnMS. 

        Power measurement magnitude should conform to the IEC 61850 
        definition of unit multiplier for the SI (System 
        International) units of measure.  Measured values are 
        represented in SI units obtained by BaseValue * (10 ^ 
        Scale).  For example, if current power usage of an Energy 
        Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, 
        depending on the value of the scaling factor.  3W implies 
        that the BaseValue is 3 and Scale = 0, whereas 3mW implies 
        BaseValue = 3 and ScaleFactor = -3. 

        Energy is often billed in kilowatt-hours instead of 
        megajoules from the SI units.  Similarly, battery charge is 
        often measured as miliamperes-hour (mAh) instead of 
        coulombs from the SI units.  The units used in this 
        framework are: W, A, Wh, Ah, V.  A conversion from Wh to 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 38] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        Joule and from Ah to Coulombs is obviously possible, and 
        can be described if required. 

        In addition to knowing the usage and magnitude, it is 
        useful to know how an Energy Object usage measurement was 
        obtained:  

        . Whether the measurements were made at the device itself 
        or from a remote source. 

        . Description of the method that was used to measure the 
        power and whether this method can distinguish actual or 
        estimated values.  

        An EnMS can use this information to account for the 
        accuracy and nature of the reading between different 
        implementations. 

        The EnMS can use the Nameplate Power for provisioning, 
        capacity planning and potentially billing. 

         

     6.5.2 Optional Power Quality 

        Given a power measurement, it may in certain circumstances 
        be desirable to know the Power Quality associated with that 
        measurement.  The information model must adhere to the IEC 
        61850 7-2 standard for describing AC measurements.  Note 
        that the Power Quality includes two sets of 
        characteristics: characteristics as received from the 
        utility, and characteristics depending on how the power is 
        used. 

        In some Energy Management Domains, the power quality may 
        not be needed, available, or relevant to the EnMS.   

        Optional Demand  

        It is well known in commercial electrical utility rates 
        that demand is part of the calculation for billing.  The 
        highest peak demand measured over a time horizon, such as 1 
        month or 1 year, is often the basis for charges.  A single 
        window of time of high usage can penalize the consumer with 
        higher energy consumption charges.  However, it is relevant 
        to measure the demand only when there are actual power 
        measurements from an Energy Object, and not when the power 
        measurement is assumed or predicted.    
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 39] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        Optional Battery  

        Some Energy Objects may use batteries for storing energy 
        and for receiving power supply.  These Energy Objects 
        should report their current power supply (battery, power 
        line, etc.) and the battery status for each contained 
        battery.   Battery-specific information to be reported 
        should include the number of batteries contained in the 
        device and per battery the state information as defined in 
        [EMAN-REQ]. 

        Beyond that a device containing a battery should be able to 
        generate alarms when the battery charge falls below a given 
        threshold and when the battery needs to be replaced.  

         

     6.6. Energy Control  

        Energy Objects can be controlled by setting it to a 
        specific Power State. Power States Set can be seen as an 
        interface by which an Energy Object can be controlled.  
        Each Energy Object should indicate the Power State Sets 
        that it implements.  Well known Power State Sets should be 
        registered with IANA 

        When an individual Power State is configured from a 
        specific Power State Set, an Energy Object may be busy at 
        the request time.  The Energy Object will set the desired 
        state and then update the actual Power State when the 
        priority task is finished.  This mechanism implies two 
        different Power State variables: actual versus desired 

        There are several standards and implementations of Power 
        State Sets.  An Energy Object can support one or multiple 
        Power State Set implementations concurrently.  

        This framework identifies three initial possible Power 
        State Series that can be supported by an Energy Object:  

        IEEE1621 - [IEEE1621] 

        DMTF - [DMTF] 

        EMAN - Specified here 

         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 40] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
     6.5.1 IEEE1621 Power State Series 

        The IEEE1621 Power State Series [IEEE1621] consists of 3 
        rudimentary states : on, off or sleep. 

          on(0)    - The device is fully on and all features of 
        the device are in working mode.  

          off(1)   - The device is mechanically switched off and 
        does not consume energy.  

          sleep(2) - The device is in a power saving mode, and 
        some features may not be available immediately. 

         

     6.5.2 DMTF Power State Series 

        DMTF [DMTF] standards organization has defined a power 
        profile standard based on the CIM (Common Information 
        Model) model that consists of 15 power states ON (2), 
        SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), 
        Hibernate(7), PowerCycle Off-Soft (8), PowerCycle Off-Hard 
        (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-
        Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset 
        Graceful (14), Power-Cycle Off-Soft Graceful (15), 
        PowerCycle-Hard Graceful (16).  DMTF standard is targeted 
        for hosts and computers.  Details of the semantics of each 
        Power State within the DMTF Power State Series can be 
        obtained from the DMTF Power State Management Profile 
        specification [DMTF]. 

        DMTF power profile extends ACPI power states.  The 
        following table provides a mapping between DMTF and ACPI 
        Power State Series and EMAN Power State Sets (described in 
        the next section): 

         
                State      DMTF Power     ACPI            EMAN 
        Power  
                             State       State            State 
        Name 
         
        Non-operational states: 
         
                  1        Off-Hard      G3, S5           
        MechOff(1) 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 41] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                  2        Off-Soft      G2, S5           
        SoftOff(2) 
                  3        Hibernate     G1, S4           
        Hibernate(3) 
                  4        Sleep-Deep    G1, S3           Sleep(4)  
                  5        Sleep-Light   G1, S2          
        Standby(5) 
                  6        Sleep-Light   G1, S1           Ready(6)  
         
        Operational states: 
                  7        On            G0, S0, P5       
        LowMinus(7) 
                  8        On            G0, S0, P4       Low(8) 
                  9        On            G0, S0, P3       
        MediumMinus(9) 
                 10        On            G0, S0, P2       
        Medium(10) 
                 11        On            G0, S0, P1       
        HighMinus(11) 
                 12        On            G0, S0, P0       High(12) 
         
                 Figure 7: DMTF / ACPI Power State Mapping 
         

     6.5.3 EMAN Power State Set 

        The EMAN Power State Set represents an attempt for a 
        standard approach to model the different levels of power of 
        a device.  The EMAN Power States are an expansion of the 
        basic Power States as defined in [IEEE1621] that also 
        incorporates the Power States defined in [ACPI] and [DMTF].  
        Therefore, in addition to the non-operational states as 
        defined in [ACPI] and [DMTF] standards, several 
        intermediate operational states have been defined.  

        There are twelve Power States, that expand on [IEEE1621] 
        on, sleep and off.  The expanded list of Power States are 
        divided into six operational states, and six non-
        operational states.  The lowest non-operational state is 1 
        and the highest is 6.  Each non-operational state 
        corresponds to an [ACPI] Global and System states between 
        G3 (hard-off) and G1 (sleeping).  Each operational state 
        represents a performance state, and may be mapped to [ACPI] 
        states P0 (maximum performance power) through P5 (minimum 
        performance and minimum power).  

        In each of the non-operational states (from mechoff(1) to 
        ready(6)), the Power State preceding it is expected to have 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 42] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        a lower Power value and a longer delay in returning to an 
        operational state:  

                 mechoff(1) : An off state where no Energy Object 
        features are available.  The Energy Object is unavailable.  
        No energy is being consumed and the power connector can be 
        removed. This corresponds to ACPI state G3.                  

                 softoff(2) : Similar to mechoff(1), but some 
        components remain powered or receive trace power so that 
        the Energy Object can be awakened from its off state.  In 
        softoff(2), no context is saved and the device typically 
        requires a complete boot when awakened.  This corresponds 
        to ACPI state G2.         hibernate(3): No Energy Object 
        features are available.   The Energy Object may be awakened 
        without requiring a complete boot, but the time for 
        availability is longer than sleep(4). An example for state 
        hibernate(3) is a save to-disk state where DRAM context is 
        not maintained.  Typically, energy consumption is zero or 
        close to zero.  This corresponds to state G1, S4 in ACPI. 

                 sleep(4)    : No Energy Object features are 
        available, except for out-of-band management, such as wake-
        up mechanisms.  The time for availability is longer than 
        standby(5). An example for state sleep(4) is a save-to-RAM 
        state, where DRAM context is maintained.  Typically, energy 
        consumption is close to zero.  This corresponds to state 
        G1, S3 in ACPI. 

                 standby(5) : No Energy Object features are 
        available, except for out-of-band management, such as wake-
        up mechanisms.  This mode is analogous to cold-standy.  The 
        time for availability is longer than ready(6).  For 
        example, the processor context is not maintained. 
        Typically, energy consumption is close to zero.  This 
        corresponds to state G1, S2 in ACPI. 

                 ready(6)    : No Energy Object features are 
        available, except for out-of-band management, such as wake-
        up mechanisms. This mode is analogous to hot-standby.  The 
        Energy Object can be quickly transitioned into an 
        operational state.  For example, processors are not 
        executing, but processor context is maintained.  This 
        corresponds to state G1, S1 in ACPI.         lowMinus(7) : 
        Indicates some Energy Object features may not be available 
        and the Energy Object has selected measures/options to 
        provide less than low(8) usage.  This corresponds to ACPI 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 43] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        State G0.  This includes operational states lowMinus(7) to 
        full(12). 

                 low(8)      : Indicates some features may not be 
        available and the Energy Object has taken measures or 
        selected options to provideless than mediumMinus(9) usage. 

                 mediumMinus(9): Indicates all Energy Object 
        features are available but the Energy Object has taken 
        measures or selected options to provide less than 
        medium(10) usage. 

                 medium(10)  : Indicates all Energy Object features 
        are available but the Energy Object has taken measures or 
        selected options to provide less than highMinus(11) usage. 

                 highMinus(11): Indicates all Energy Object 
        features are available and power usage is less than 
        high(12). 

                 high(12)    : Indicates all Energy Object features 
        are available and the Energy Object is consuming the 
        highest power. 

        The Figure 8 displays the mappings from the IEEE1621 Power 
        State Series to the EMAN Power State Series, showing that 
        the EMAN twelve Power States expand on [IEEE1621] on, sleep 
        and off. 
         
                IEEE1621               EMAN Power State Name 
         
        Non-operational states: 
         
                Power(off)             MechOff(1) 
                Power(off)             SoftOff(2) 
                Power(sleep)            Hibernate(3) 
                Power(sleep)            Sleep(4)  
                Power(sleep)            Standby(5) 
                Power(sleep)            Ready(6)  
         
        Operational states: 
                Power(on)              LowMinus(7) 
                Power(on)               Low(8) 
                Power(on)              MediumMinus(9) 
                Power(on)              Medium(10) 
                Power(on)              HighMinus(10) 
                Power(on)              High(11) 
         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 44] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                 Figure 8: DMTF / ACPI Power State Mapping 
         

     6.7. Energy Objects Relationship Extensions  

        This framework for Energy Management, is based on four 
        Energy Objects Relationships: Aggregation Relationship, 
        Metering Relationship, Power Source Relationship, and Proxy 
        Relationship.   

        This framework is defined with possible extension of new 
        Energy Objects Relationships in mind.  For example, a Power 
        Distribution Unit (PDU) that allows physical entities like 
        outlets to be "ganged" together as a logical entity for 
        simplified management purposes, could be modeled with a 
        future extension based on "gang relationship", whose 
        semantic would specify the Energy Objects grouping. 

         
     7. Structure of the Information Model: UML Representation 

        The following basic UML represents an information model 
        expression of the concepts in this framework.  This 
        information model, provided as a reference for 
        implementers, is represented as a MIB in the different 
        related IETF Energy Monitoring documents.  However, other 
        programming structure with different data models could be 
        used as well. 
         
        Notation is a shorthand UML with lowercase types considered 
        platform or atomic types (i.e. int, string, collection). 
        Uppercase types denote classes described further.  
        Collections and cardinality are expressed via qualifier 
        notation.  Attributes labeled static are considered class 
        variables and global to the class.  Algorithms for class 
        variable initialization, constructors or destructors are 
        not shown 
      
        EDITOR'S NOTE: the first part of the UML must be aligned 
        with the latest [EMAN-AWARE-MIB] document version. Also, 
        received the following comment referring to the arrows in 
        the following figure: "It is not clear to me what UML 
        relationships are being specified here in the ASCIIfied UML 
        relationships.  Please provide a legend to make your 
        conventions for mapping to UML clear." 
         
         
                      EO RELATIONSHIPS AND CONTEXT 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 45] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
      
                                        +--------------------------
        --+ 
                                        | _Child Specific Info __    
        | 
                                        |--------------------------
        --| 
        +---------------------------+   |  parentId : UUID           
        | 
        |    Context Information    |   |  parentProxyAbilities      
        | 
        |---------------------------|   |           : bitmap         
        | 
        |  roleDescription : string |   |  mgmtMacAddress : octets   
        | 
        |  keywords[0..n] : string  |   |  mgmtAddress : 
        inetaddress | 
        |  importance : int         |   |  mgmtAddressType : enum    
        | 
        |  category :  enum         |   |  mgmtDNSName : 
        inetaddress | 
        +---------------------------+   +--------------------------
        --+ 
                  |                            |               
                  |                            |              
                  |                            | 
                  v                            v 
          +-----------------------------------------+ 
          |  Energy Object Information              | 
          |-----------------------------------------| 
          | index : int                             | 
          | energyObjectId | UUID                   | 
          | name : string                           |  
          | meterDomainName | string                | 
          | alternateKey | string                   | 
          +-----------------------------------------+ 
                  ^         
                  |                   
                  |                   
                  |                   
        +-------------------------+   
        |    Links Object         | 
        |-------------------------| 
        |  physicalEntity : int   | 
        |  ethPortIndex : int     | 
        |  ethPortGrpIndex : int  | 
        |  lldpPortNumber : int   |  

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 46] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        +-------------------------+   
         
         
         
                     EO AND MEASUREMENTS  
         
         
        +-----------------------------------------------+ 
        |                 Energy Object                 | 
        |-----------------------------------------------| 
        |  nameplate : Measurement                      | 
        |  battery[0..n]: Battery                       | 
        |  measurements[0..n]: Measurement              | 
        | --------------------------------------------- | 
        | Measurement instantaneousUsage()              | 
        | DemandMeasurement historicalUsage()           | 
        +-----------------------------------------------+ 
         
          +-----------------------------------+ 
          |  Measurements                     | 
          | __________________________________| 
          +-----------------------------------+ 
                            ^ 
                            | 
                            | 
         +------------------+----------------------------+   
         |         PowerMeasurement                      | 
         |-----------------------------------------------| 
         | value : long                                  | 
         | rate : enum {0,millisecond,seconds,           | 
         |              minutes,hours,...}               | 
         | multiplier : enum {-24..24}                   | 
         | units : "watts"                               | 
         | caliber : enum { actual, estimated,           | 
         |                  trusted, assumed...}         | 
         | accuracy : enum { 0..10000}                   | 
         | current :  enum {AC, DC}                      | 
         | origin : enum { self, remote }                | 
         | time : timestamp                              | 
         | quality : PowerQuality                        | 
         +-----------------------------------------------+                           
                            | 
                            | 
         +------------------+----------------------------+   
         |         EnergyMeasurement                     | 
         |-----------------------------------------------| 
         | consumed : long                               | 
         | generated : long                              | 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 47] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
         | net : long                                    |   
         | accuracy : enum { 0..10000}                   | 
         +-----------------------------------------------+  
          
         
         +-----------------------------------------------+ 
         |         TimeMeasurement                       | 
         |-----------------------------------------------| 
         | startTime : timestamp                         | 
         | usage : Measurement                           | 
         | maxUsage : Measurement                        | 
         +-----------------------------------------------+ 
                            | 
                            | 
         +----------------------------------------+  
         |        TimeInterval                    | 
         |--------------------------------------- | 
         |value : long                            | 
         |units : enum { seconds, miliseconds..}  | 
         +----------------------------------------+  
                            | 
                            | 
         +----------------------------------------+  
         |        DemandMeasurement               | 
         |----------------------------------------| 
         |intervalLength :  TimeInterval          | 
         |intervalNumbers: long                   | 
         |intervalMode :  enum { period, sliding, | 
         |total }                                 | 
         |intervalWindow : TimeInterval           | 
         |sampleRate : TimeInterval               | 
         |status : enum {active, inactive }       | 
         |measurements : TimedMeasurement[]       | 
         +----------------------------------------+  
                       
         
         
                       QUALITY 
         
         +----------------------------------------+          
         |            PowerQuality                | 
         |----------------------------------------| 
         |                                        | 
         +----------------------------------------+ 
                            ^ 
                            | 
                            | 
         +------------------+--------------------+  
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 48] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
         |         ACQuality                     | 
         |---------------------------------------|  
         | acConfiguration : enum {SNGL, DEL,WYE}|  
         | avgVoltage   : long                   | 
         | avgCurrent   : long                   | 
         | frequency    : long                   | 
         | unitMultiplier  : int                 | 
         | accuracy  : int                       | 
         | totalActivePower  : long              | 
         | totalReactivePower : long             | 
         | totalApparentPower : long             | 
         | totalPowerFactor : long               | 
         +---------+-----------------------------+  
                   | 1 
                   | 
                   | 
                   | 
                   |        +------------------------------------+ 
                   |        |         ACPhase                    | 
                   |     *  |------------------------------------| 
                   +--------+ phaseIndex : long                  | 
                            | avgCurrent : long                  | 
                            | activePower : long                 | 
                            | reactivePower : long               | 
                            | apparentPower : long               | 
                            | powerFactor : long                 | 
                            +------------------------------------+ 
                                        ^           ^  
                                        |           | 
                                        |           | 
                                        |           | 
                                        |           | 
        +-------------------------------+---+       | 
        |        DelPhase                   |       | 
        |-----------------------------------|       | 
        |phaseToNextPhaseVoltage  : long    |       | 
        |thdVoltage : long                  |       | 
        |thdCurrent : long                  |       | 
        +-----------------------------------+       | 
                                                    | 
                                 +------------------+-----------+ 
                                 |        WYEPhase              | 
                                 |------------------------------| 
                                 |phaseToNeutralVoltage : long  | 
                                 |thdCurrent : long             | 
                                 |thdVoltage : long             | 
                                 +------------------------------+ 
         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 49] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
      

      

                           EO & STATES 

           +----------------------------------------------+     
           |             Energy Object                    |      
           |----------------------------------------------|     
           | currentLevel : int                           |     
           | configuredLevel : int                        |     
           | configuredTime : timestamp                   |    
           | reason: string                               |   
           | emanLevels[0..11] : State                    | 
           | levelMappings[0..n] : LevelMapping           | 
           +----------------------------------------------+  
         
            +-------------------------------+              
            |        State                  |               
            |-------------------------------|                
            | name : string                 |   
            | cardinality : int             | 
            | maxUsage : Measurement        |  
            +-------------------------------+ 
                             
         
         
      

              Figure 9: Information Model UML Representation 
      

     8. Configuration 

        This power management framework allows the configuration of 
        the following key parameters: 
         
      
          . Energy Object name: A unique printable name for the 
             Energy Object.  
          . Energy Object role: An administratively assigned name 
             to indicate the purpose an Energy Object serves in the 
             network.  
          . Energy Object importance: A ranking of how important 
             the Energy Object is, on a scale of 1 to 100, compared 
             with other Energy Objects in the same Energy 
             Management Domain.  

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 50] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          . Energy Object keywords: A list of keywords that can be 
             used to group Energy Objects for reporting or 
             searching. 
          . Energy Management Domain: Specifies the name of an 
             Energy Management Domain for the Energy Object. 
          . Energy Object Power State: Specifies the current Power 
             State for the Energy Object.  
          . Demand parameters: For example, which interval length 
             to report the Demand over, the number of intervals to 
             keep, etc. 
          . Assigning an Energy Object Parent to an Energy Object 
             Child 
          . Assigning an Energy Object Child to an Energy Object 
             Parent. 
         
         
        This framework supports multiple means for setting the 
        Power State of a specific Energy Objects. However, the 
        Energy Object might be busy executing an important task 
        that requires the current Power State for some more time.  
        For example, a PC might have to finish a backup first, or 
        an IP phone might be busy with a current phone call.  
        Therefore a second value contains the actual Power State.  
        A difference in values between the two objects indicates 
        that the Energy Object is currently in Power State 
        transition.  
         
        Other, already well established means for setting Power 
        States, such as DASH [DASH], already exist.  Such a 
        protocol may be implemented between the Energy Object 
        Parent and the Energy Object Child, when the Energy Object 
        Parent acts as a Proxy.  Note that the Wake-up-on-Lan (WoL) 
        mechanism allows to transition a device out of the Off 
        Power State. 
         
        
         
     9. Fault Management 

        [EMAN-REQ] specifies some requirements about Power States 
        such as "the current state - the time of the last change", 
        "the total time spent in each state", "the number of 
        transitions to each state", etc.  Such requirements are 
        fulfilled via the pmPowerStateChange NOTIFICATION-TYPE 
        [EMAN-MON-MIB].  This SNMP notification is generated when 
        the value(s) of Power State has changed for the Energy 
        Object. 
         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 51] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        Regarding high and low thresholding mechanism, the RMON 
        alarm and event [RFC2819] allows to periodically takes 
        statistical samples from Energy Object variables, compares 
        them to previously configured thresholds, and to generate 
        an event (i.e. an SNMP notification) if the monitored 
        variable crosses a threshold. The RMON alarm can monitor 
        variables that resolve to an ASN.1 primitive type of 
        INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge32, 
        or TimeTicks), so basically most the variables in [EMAN-
        MON-MIB]. 
         
         
     10. Examples 

         
        In this section we will give examples of how to use the 
        Energy Management framework.  In each example we will show 
        how it can be applied when Energy Devices have the 
        capability to model Power Interfaces.  We will also show in 
        each example how the framework can be applied when devices 
        cannot support Power Interfaces but only monitor 
        information or control the Energy Device as a whole. For 
        instance a PDU may only be able to measure power and energy 
        for the entire unit without the ability to distinguish 
        among the inlets or outlet. 
      
        Together these examples show how the framework can be 
        adapted for Energy Devices with different capabilities 
        (typically hardware) for Energy Management. 
         
        Given for all Examples:  
         
        Energy Device W: A computer with one power supply. Power 
        interface 1 is an inlets for Device W. 
         
        Energy Device X: A computer with two power supplies. Power 
        interface 1 and power interface 2 are both inlets for 
        Device X. 
           
        Energy Device Y: A PDU with multiple Power Interfaces 
        numbered 0..10, Power interface 0 is an inlet and power 
        interface 1..10 are outlets. 
      
        Energy Device Z: A PDU with multiple Power Interfaces 
        numbered 0..10, Power interface 0 is an inlet and power 
        interface 1..10 are outlets. 
         
         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 52] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                    Example I: Simple Device with one Source 
         
        Topology:  
          Energy Device W inlet 1 is plugged into Device Y outlet 
        8. 
                   
        With Power Interfaces: 
           
          Device W has an Energy Object representing the computer 
          itself as well as one Power Interface defined as an 
          inlet.  
           
          Device Y would have an Energy Object representing the PDU 
          itself (the Energy Device) with a Power Interface 0 
          defined as an inlet and Power Interfaces 1..10 defined as 
          outlets.  
        
          The interfaces of the devices would have a Power Source 
          Relationship such that: 
          Device W inlet 1 is powered by Device Y outlet 8 
         
        Without Power Interfaces: 
                
          In this case Device W has an Energy Object representing 
          the computer.  Device Y would have an Energy Object 
          representing the PDU.  
           
          The devices would have a Power Source Relationship such 
          that: 
          Device W is powered by Device Y. 
           
         
                    Example II: Multiple Inlets 
         
        Topology:  
          Energy Device X inlet 1 is plugged into Device Y outlet 
        8. 
          Energy Device X inlet 2 is plugged into Device Y outlet 
        9. 
         
        With Power Interfaces: 
      
          Device X has an Energy Object representing the computer 
          itself. It contains two Power Interface defined as 
          inlets.  
           
          Device Y would have an Energy Object representing the PDU 
          itself  (the Energy Device) with a Power Interface 0 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 53] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
          defined as an inlet and Power Interface 1..10 defined as 
          outlets.  
        
           
          The interfaces of the devices would have a Power Source 
          Relationship such that: 
          Device X inlet 1 is powered by Device Y outlet 8 
          Device X inlet 2 is powered by Device Y outlet 9 
         
        Without Power Interfaces: 
                
          In this case Device X has an Energy Object representing 
          the computer. Device Y would have an Energy Object 
          representing the PDU.  
           
          The devices would have a Power Source Relationship such 
          that: 
          Device X is powered by Device Y. 
           
           
                    Example III: Multiple Sources 
         
        Topology:  
          Energy Device X inlet 1 is plugged into Device Y outlet 
        8. 
          Energy Device X inlet 2 is plugged into Device Z outlet 9 
         
        With Power Interfaces: 
      
          Device X has an Energy Object representing the computer 
          itself. It contains two Power Interface defined as 
          inlets.  
           
          Device Y would have an Energy Object representing the PDU 
          itself  (the Energy Device) with a Power Interface 0 
          defined as an inlet and Power Interface 1..10 defined as 
          outlets.  
        
          Device Z would have an Energy Object representing the PDU 
          itself  (the Energy Device) with a Power Interface 0 
          defined as an inlet and Power Interface 1..10 defined as 
          outlets.  
           
          The interfaces of the devices would have a Power Source 
          Relationship such that: 
          Device X inlet 1 is powered by Device Y outlet 8 
          Device X inlet 2 is powered by Device Z outlet 9 
         
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 54] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        Without Power Interfaces: 
                
          In this case Device X has an Energy Object representing 
          the computer. Device Y and Z would both have respective 
          Energy Objects representing each entire PDU.  
           
          The devices would have a Power Source Relationship such 
          that: 
          Device X is powered by Device Y and powered by Device Z. 
         
         
         
     11. Relationship with Other Standards Development 
                       Organizations 

     11.1. Information Modeling  

        This power management framework should, as much as 
        possible, reuse existing standards efforts, especially with 
        respect to information modeling and data modeling 
        [RFC3444].  
         
        The data model for power and energy related objects is 
        based on IEC 61850.   
         
        Specific examples include: 
         
          . The scaling factor, which represents Energy Object 
             usage magnitude, conforms to the IEC 61850 definition 
             of unit multiplier for the SI (System International) 
             units of measure.  
         
          . The electrical characteristic is based on the ANSI and 
             IEC Standards, which require that we use an accuracy 
             class for power measurement.  ANSI and IEC define the 
             following accuracy classes for power measurement:  
           
             . IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.    
             
             . ANSI C12.20 class 0.2, 0.5 
           
          . The electrical characteristics and quality adheres 
             closely to the IEC 61850 7-2 standard for describing 
             AC measurements.   
           
          . The power state definitions are based on the DMTF 
             Power State Profile and ACPI models, with operational 
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 55] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
             state extensions.  
              
         
     12. Security Considerations 

        Regarding the data attributes specified here, some or all 
        may be considered sensitive or vulnerable in some network 
        environments. Reading or writing these attributes without 
        proper protection such as encryption or access 
        authorization may have negative effects on the network 
        capabilities. 
         
         
     12.1. Security Considerations for SNMP 

        Readable objects in a MIB modules (i.e., objects with a 
        MAX-ACCESS other than not-accessible) may be considered 
        sensitive or vulnerable in some network environments.  It 
        is thus important to control GET and/or NOTIFY access to 
        these objects and possibly to encrypt the values of these 
        objects when sending them over the network via SNMP.   
         
        The support for SET operations in a non-secure environment 
        without proper protection can have a negative effect on 
        network operations.  For example: 
         
          . Unauthorized changes to the Power Domain or business 
             context of an Energy Object may result in misreporting 
             or interruption of power. 
          . Unauthorized changes to a power state may disrupt the 
             power settings of the different Energy Objects, and 
             therefore the state of functionality of the respective 
             Energy Objects. 
          . Unauthorized changes to the demand history may disrupt 
             proper accounting of energy usage.  
      
        With respect to data transport SNMP versions prior to 
        SNMPv3 did not include adequate security.  Even if the 
        network itself is secure (for example, by using IPsec), 
        there is still no secure control over who on the secure 
        network is allowed to access and GET/SET 
        (read/change/create/delete) the objects in these MIB 
        modules. 
         
        It is recommended that implementers consider the security 
        features as provided by the SNMPv3 framework (see 
        [RFC3410], section 8), including full support for the 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 56] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        SNMPv3 cryptographic mechanisms (for authentication and 
        privacy). 
         
        Further, deployment of SNMP versions prior to SNMPv3 is not 
        recommended.  Instead, it is recommended to deploy SNMPv3 
        and to enable cryptographic security.  It is then a 
        customer/operator responsibility to ensure that the SNMP 
        entity giving access to an instance of these MIB modules is 
        properly configured to give access to the objects only to 
        those principals (users) that have legitimate rights to GET 
        or SET (change/create/delete) them. 
         
         
         
     13. IANA Considerations 

      
        Initial values for the Power State Sets, together with the 
        considerations for assigning them, are defined in [EMAN-
        MON-MIB].   
      
         
      
     14. Acknowledgments  

        The authors would like to Michael Brown for improving the 
        text dramatically, and Rolf Winter for his feedback.  The 
        award for the best feedback and reviews goes to Bill 
        Mielke. 
      
      
     15. References 

     Normative References 

      
        [RFC2119]  Bradner, S., "Key words for use in RFCs to 
                Indicate Requirement Levels", BCP 14, RFC 2119, 
                March 1997. 
         
        [RFC2819]  S. Waldbusser, "Remote Network Monitoring 
                Management Information Base", STD 59, RFC 2819, May 
                2000 
         
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. 
                Stewart, "Introduction and Applicability Statements 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 57] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                for Internet Standard Management Framework ", RFC 
                3410, December 2002. 
         
        [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB 
                (Version3)", RFC 4133, August 2005. 
         
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A 
                Universally Unique IDentifier (UUID) URN 
                Namespace", RFC 4122, July 2005 
         
     Informative References 

         
        [RFC2578] McCloghrie, K., Perkins, D., and J. 
                Schoenwaelder, "Structure of Management Information 
                Version 2 (SMIv2", RFC 2578, April 1999 
         
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 
                between Information Models and Data Models", RFC 
                3444, January 2003. 
      
        [RFC5101] B. Claise, Ed., Specification of the IP Flow 
                Information Export (IPFIX) Protocol for the 
                Exchange of IP Traffic Flow Information, RFC 5101, 
                January 2008. 
         
        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling 
                Language for the Network Configuration Protocol 
                (NETCONF)", RFC 6020, October 2010. 
         
        [ACPI] "Advanced Configuration and Power Interface 
                Specification", http://www.acpi.info/spec30b.htm 
         
        [IEEE1621]  "Standard for User Interface Elements in Power 
                Control of Electronic Devices Employed in 
                Office/Consumer Environments", IEEE 1621, December 
                2004. 
      
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control 
                Connectivity Discovery", 2005. 
      
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management 
                Information Base extension module for TIA-TR41.4 
                media endpoint discovery information", July 2005. 
         
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 
                and M. Chandramouli, "Requirements for Energy 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 58] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
                Management", draft-ietf-eman-requirements-05, (work 
                in progress), November 2011. 
         
        [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware 
                Networks and Devices MIB", draft-ietf-eman-energy-
                aware-mib-04, (work in progress), February 2012. 
         
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., 
                Dietz, T., and B. Claise, "Power and Energy 
                Monitoring MIB", draft-ietf-eman-energy-monitoring-
                mib-02, (work in progress), March 2012. 
         
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " 
                Definition of Managed Objects for Battery 
                Monitoring", draft-ietf-eman-battery-mib-05, (work 
                in progress), March 2012. 
         
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, 
                "Energy Management (EMAN) Applicability Statement", 
                draft-ietf-eman-applicability-statement-00, (work 
                in progress), October 2011 
         
        [EMAN-TERMINOLOGY] J. Parello, "Energy Management 
                Terminology", draft-parello-eman-definitions-05, 
                (work in progress), March 2012 
         
        [ITU-T-M-3400] TMN recommandation on Management Functions 
                (M.3400), 1997 
         
        [NMF] "Network Management Fundamentals", Alexander Clemm, 
                ISBN: 1-58720-137-2, 2007 
         
        [TMN] "TMN Management Functions : Performance Management", 
                ITU-T M.3400 
         
        [1037C] US Department of Commerce, Federal Standard 1037C, 
                http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm 
         
        [IEEE100] "The Authoritative Dictionary of IEEE Standards 
                Terms" 
                http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?
                punumber=4116785 
         
        [DASH] "Desktop and mobile Architecture for System 
                Hardware", http://www.dmtf.org/standards/mgmt/dash/ 
         

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 59] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
        [ISO50001] "ISO 50001:2011 Energy management systems - 
                Requirements with guidance for use", 
                http://www.iso.org/  
         
        [IEC60050] International Electrotechnical Vocabulary 
                http://www.electropedia.org/iev/iev.nsf/welcome?ope
                nform 
         
        [SQL] ISO/IEC 9075(1-4,9-11,13,14):2008 
         
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                2009 - IEEE Standard for Information technology - 
                Telecommunications and information exchange between 
                systems - Local and metropolitan area networks - 
                Specific requirements - Part 3: Carrier Sense 
                Multiple Access with Collision Detection (CSMA/CD) 
                Access Method and Physical Layer Specifications - 
                Amendment: Data Terminal Equipment (DTE) -  Power 
                via Media Dependent Interface (MDI) Enhancements", 
                   October 2009. 
      
        [DMTF] "Power State Management Profile DMTF  DSP1027  
                Version 2.0"  December 2009     
                http://www.dmtf.org/sites/default/files/standards/d
                ocuments/DSP1027_2.0.0.pdf 
         
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 
                Management", 2010, Wiley Publishing 
         
        [X.700]  CCITT Recommendation X.700 (1992), Management 
                framework for Open Systems Interconnection (OSI) 
                for CCITT applications. 
          
        [CHEN] "The Entity-Relationship Model: Toward a Unified 
                View of Data",  Peter Pin-shan Chen, ACM 
                Transactions on Database Systems, 1976 
      
      
     Authors' Addresses 
      
      Benoit Claise 
      Cisco Systems, Inc. 
      De Kleetlaan 6a b1 
      Diegem 1813 
      BE 
          
      Phone: +32 2 704 5622 

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 60] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
      Email: bclaise@cisco.com 
      
       
      John Parello 
      Cisco Systems, Inc. 
      3550 Cisco Way  
      San Jose, California 95134  
      US 
          
      Phone: +1 408 525 2339 
      Email: jparello@cisco.com 
       
       
      Brad Schoening 
      44 Rivers Edge Drive 
      Little Silver, NJ 07739 
      US 
       
      Phone:  
      Email: brad@bradschoening.com 
      
       
     Juergen Quittek 
     NEC Europe Ltd.  
     Network Laboratories 
     Kurfuersten-Anlage 36 
     69115 Heidelberg 
     Germany 
      
     Phone: +49 6221 90511 15 
     EMail: quittek@netlab.nec.de 
      
      
     Bruce Nordman 
     Lawrence Berkeley National Laboratory 
     1 Cyclotron Road 
     Berkeley  94720 
     US 
      
     Phone: +1 510 486 7089 
     Email: bnordman@lbl.gov 
      
      
       
       
      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 61] 
         

     Internet-Draft           <EMAN Framework>        March 2012 
      
       
       

      
      
     <Claise, et. Al>         Expires Sep 12, 2012            [Page 62]