Skip to main content

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

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 John Parello , Benoît Claise , Brad Schoening , Juergen Quittek
Last updated 2013-09-09
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Awaiting External Review/Resolution of Issues Raised
Document shepherd Eliot Lear
IESG IESG state Became RFC 7326 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Joel Jaeggli
Send notices to (None)
draft-ietf-eman-framework-09
Network Working Group                                        J. Parello 
     Internet-Draft                                                B. Claise 
     Intended Status: Informational                      Cisco Systems, Inc. 
     Expires: March 9, 2014                                     B. Schoening 
                                                      Independent Consultant 
                                                                  J. Quittek 
                                                              NEC Europe Ltd 
      
                                                           September 9, 2013 
      
                                           
                             Energy Management Framework 
                          draft-ietf-eman-framework-09.txt 

         
     Status of this Memo 
         
        This Internet-Draft is submitted in full conformance with the 
        provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet Engineering 
        Task Force (IETF), 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 March 9, 2014. 
         
     Copyright Notice 
         
        Copyright (c) 2013 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 
      
      
      
     Claise et al            Expires March 9, 2014                  [Page 1] 
      


     Internet-Draft              EMAN Framework               September 2013 
         
        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 and device components within or connected to communication 
        networks.  The framework defines both a physical reference model and 
        information model. The information model consists of an Energy 
        Management Domain as a set of Energy Objects. Each Energy Object is 
        identified, classified and given context.   Energy Objects can be 
        monitored and controlled with respect to Power, Power State, Energy, 
        Demand, Power Attributes, and Battery.  Additionally the framework 
        models relationships and capabilities between Energy Objects. 
         
     Table of Contents 
         
        1. Introduction...................................................3 
           1.1. Energy Management Documents Overview......................4 
        2. Terminology....................................................4 
        3. Concerns Specific to Energy Management........................10 
           3.1. Target Devices...........................................10 
           3.2. Physical Reference Model.................................10 
           3.3. Concerns Differing from Network Management...............12 
           3.4. Concerns Not Addressed...................................12 
        4. Energy Management Abstraction.................................13 
           4.1. Conceptual Model.........................................13 
           4.2. Energy Object............................................14 
           4.3. Energy Object Attributes.................................14 
           4.4. Measurements.............................................17 
           4.5. Control..................................................18 
           4.6. Relationships............................................23 
        5. Energy Management Information Model...........................26 
        6. Modeling Relationships between Devices........................30 
           6.1. Power Source Relationship................................30 
           6.2. Metering Relationship....................................33 
           6.3. Aggregation Relationship.................................35 
        7. Relationship to Other Standards...............................35 
        8. Security Considerations.......................................36 
           8.1. Security Considerations for SNMP.........................36 
        9. IANA Considerations...........................................37 
           9.1. IANA Registration of new Power State Sets................37 
           9.2. Updating the Registration of Existing Power State Sets...38 
        10. References...................................................38 
        11. Acknowledgments..............................................41 
         

      
      
     Claise et al.           Expires March 9, 2014                  [Page 2] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
     1. Introduction 
         
        Network management is often divided into the five main areas defined 
        in the ISO Telecommunications Management Network model: Fault, 
        Configuration, Accounting, Performance, and Security Management 
        (FCAPS) [X.700].  Not covered by this traditional management model is 
        Energy Management, which is rapidly becoming a critical area of 
        concern worldwide, as seen in [ISO50001].  
         
        This document defines an energy management framework for devices 
        within or connected to communication networks.  The devices, or 
        components of these devices (such as router line cards, fans, disks), 
        can then be monitored and controlled.  Monitoring includes measuring 
        power, energy, demand, and attributes of power.  Energy control can 
        be performed by setting devices' or components' power state. If a 
        device contains batteries, these can also be monitored and 
        controlled.  
         
        This framework further describes how to identify, classify and 
        provide context for such devices.  While the context information is 
        not specific to Energy Management, some context attributes are 
        specified in the framework, addressing the following use cases: how 
        important is a device in terms of its business impact, how should 
        devices be grouped for reporting and searching, and how should a 
        device role be described.  These context attributes help in fault 
        management and impact analysis while controlling the power states.  
        Guidelines for using context for energy management are described. 
         
        The framework introduces the concept of a power interface that is 
        analogous to a network interface. A power interface is defined as an 
        interconnection among devices where energy can be provided, received, 
        or both.  
         
        The most basic example of Energy Management is a single device 
        reporting information about itself.  In many cases, however, energy 
        is not measured by the device itself, but measured upstream in the 
        power distribution tree.  For example, a power distribution unit 
        (PDU) may measure the energy it supplies to attached devices and 
        report this to an energy management system.  Therefore, devices often 
        have relationships to other devices or components in the power 
        network.  An EnMS generally requires an understanding of the power 
        topology (who provides power to whom), the metering topology (who 
        meters whom), and an understanding of the potential aggregation (does 
        a meter aggregate values from other devices). 
         
        The relationships build on the power interface concept. The different 
        relationships among devices and components, specified in this 
        document, include: power source relationship, metering relationship, 
        and aggregation relationship. 
      
      
     Claise et al.           Expires March 9, 2014                  [Page 3] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
     1.1. Energy Management Documents 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] includes use cases, a 
        cross-reference between existing standards and the EMAN standard, and 
        a description of this frameworks relationship to other frameworks. 
         
        The Energy Object Context MIB [EMAN-OBJECT-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] specifies objects 
        for monitoring of Power, Energy, Demand, Power Attributes, and Power 
        States. 
         
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines managed objects 
        that provide information on the status of batteries in managed 
        devices. 
         
     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].  
         
        In this document these words will appear with that interpretation   
        only when in ALL CAPS. Lower case uses of these words are not to be    
        interpreted as carrying RFC-2119 significance. 
         
        In this section some terms have a NOTE that is not part of the 
        definition itself, but accounts for differences between terminologies 
        of different standards organizations or further clarifies the 
        definition. 

      
      
     Claise et al.           Expires March 9, 2014                  [Page 4] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
        $ Energy Management 
          Energy Management is a set of functions for measuring, modeling, 
          planning, and optimizing networks to ensure that the network and 
          network attached devices use energy efficiently and appropriately 
          for the nature of the application and the cost constraints of the 
          organization.  
           
          Reference: Adapted from [ITU-T-M-3400] 
           
          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 the 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 of 
          energy management. 
           
          Reference: Adapted from [1037C] 
           
          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.  An 
          ISO-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 

      
      
     Claise et al.           Expires March 9, 2014                  [Page 5] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
          definition from [ISO50001] can be referred to as ISO Energy 
          Management System (ISO-EnMS). 
         
        $ 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.  
         
        $ Energy Control 
          Energy Control is a part of Energy Management that deals with 
          directing influence over Energy Objects.  
         
        $ 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] 
         
        $ Device 
          A piece of electrical or non-electrical equipment. 
          Reference: Adapted from [IEEE100]  
         
        $ Component 
          A part of an electrical or non-electrical equipment (Device).  
          Reference: Adapted from [ITU-T-M-3400] 
         
        $ Power Inlet  
          A Power Inlet (or simply inlet) is an interface at which a device 
          or component receives energy from another device or component. 
         
        $ Power Outlet  
          A Power Outlet (or simply outlet) is an interface at which a device 
          or component provides energy to another device or component. 
         
        $ 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 kilowatt hours (kWh). 
           
          Reference: [IEEE100] 
           
          NOTES 
      
      
     Claise et al.           Expires March 9, 2014                  [Page 6] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
          1. Energy is the capacity of a system to produce external activity 
          or perform work [ISO50001] 
         
        $ Provide Energy 
          A device (or component) "provides" energy to another device if 
          there is an energy flow from this device to the other one. 
         
        $ Receive Energy 
          A device (or component) "receives" energy from another device if 
          there is an energy flow from the other device to this one. 
         
        $ Meter (energy meter) 
          a device intended to measure electrical energy by integrating power 
          with respect to time. 
           
          Reference: Adapted from [IEC60050]  
         
        $ Battery 
          one or more cells (consisting of an assembly of electrodes, 
          electrolyte, container, terminals and usually separators)  that are 
          a source and/or store of electric energy.  
           
          Reference: Adapted from [IEC60050]  
         
        $ Power 
          The time rate at which energy is emitted, transferred, or received; 
          usually expressed in watts (joules per second). 
           
          Reference: [IEEE100] 
         
        $ Nameplate Power 
          The Nameplate Power is the nominal Power of a device as specified 
          by the device manufacturer.  
         
        $ Power Attributes 
          Measurements of the electrical current, voltage, phase and 
          frequencies at a given point in an electrical power system. 
          Reference: Adapted from [IEC60050] 
           
          NOTES:  
          1. Power Attributes are not intended to be judgmental with respect 
          to a reference or technical value and are independent of any usage 
          context. 
         
        $ Power Quality  
          Characteristics of the electrical current, voltage, phase 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 
      
      
     Claise et al.           Expires March 9, 2014                  [Page 7] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
          electricity supplied in an electric power system and the loads 
          connected to that electric power system. 
           
          Reference: [IEC60050] 
           
          NOTES:  
          1. Electrical characteristics representing power quality 
          information are typically required by customer facility energy 
          management systems. It is not intended to satisfy the detailed 
          requirements of power quality monitoring. Standards typically also 
          give ranges of allowed values; the information attributes are the 
          raw measurements, not the "yes/no" determination by the various 
          standards.  
           
          Reference: [ASHRAE-201] 
         
        $ 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. For EMAN we use kilowatts.  
         
        $ 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]   
         
        $ Power State Set 
          A Power State Set is a collection of Power States that comprises a 
          named or logical control grouping.   
         
        $ Energy Object      
          An Energy Object (EO) is an information model (class) that 
          represents a piece of equipment that is part of, or attached to, a 
          communications network which is monitored, controlled, or aids in 
          the management of another device for Energy Management. 
         
        $ Power Interface 
          A Power Interface (or simply interface) is an information model 
          (class) that represents the interconnections among devices or 
          components where energy can be provided, received, or both.  
         
        $ Energy Management Domain 
      
      
     Claise et al.           Expires March 9, 2014                  [Page 8] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
          An Energy Management Domain is a set of Energy Objects that is 
          considered one unit of management.  
         
        $ Energy Object Identification 
          Energy Object Identification is a set of attributes that enable an 
          Energy Object to be universally unique or linked to other systems. 
         
        $ Energy Object Context 
          Energy Object Context is a set of attributes that allow an Energy 
          Management System to classify an Energy Object within an 
          organization.   
         
        $ Energy Object Relationship 
          An Energy Object Relationship is an association among Energy 
          Objects. 
           
          NOTES 
          1. Relationships can be named and could include Aggregation, 
          Metering, and Power Source. 
          Reference: Adapted from [CHEN] 
         
        $ Power Source Relationship 
          A Power Source Relationship is an Energy Object Relationship where 
          one Energy Object provides power to one or more Energy Objects. 
          These Energy Objects are referred to as having a Power Source 
          Relationship.   
         
        $ Metering Relationship 
          A Metering Relationship is an Energy Object Relationship where one 
          Energy Object measures power, energy, demand or power attributes of 
          one or more other Energy Objects. The measuring Energy Object has a 
          Metering Relationship with each of the measured objects. 
         
        $ Aggregation Relationship 
          An Aggregation Relationship is an Energy Object Relationship where 
          one Energy Object aggregates Energy Management information of one 
          or more other Energy Objects. The aggregating Energy Object has an 
          Aggregation Relationship with each of the other Energy Objects.   

      
      
     Claise et al.           Expires March 9, 2014                  [Page 9] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
     3. Concerns Specific to Energy Management 
         
        This section explains areas of concern for Energy Management that do 
        not exist in traditional Network Management. This section describes 
        target devices, outlines physical reference models, and lists the 
        major concerns specific to Energy Management. 
          
         
     3.1. Target Devices 
        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.   
         
        Energy Management has special challenges because a power distribution 
        network supplies energy to devices and components, while a separate 
        communications network monitors and controls the power distribution 
        network. 
      
        The target devices for Energy Management are all devices that can be 
        monitored or controlled (directly or indirectly) by an Energy 
        Management System (EnMS) using the Internet protocol. These target 
        devices include:  
           o     Simple electrical appliances and fixtures 
           o     Hosts, such as a PC, a server, or a printer 
           o     Switches, routers, base stations, and other network 
              equipment and middle boxes 
           o     Components within devices, such as a battery inside a PC, a 
              line card inside a switch, etc. 
           o     Power over Ethernet (PoE) endpoints 
           o     Power Distribution Units (PDU)  
           o     Protocol gateway devices for Building Management Systems 
              (BMS) 
           o     Electrical meters 
           o     Sensor controllers with subtended sensors 
         
        The target devices may also include those communicating via non-IP 
        protocols deployed among the power distribution and IP communication 
        network.  
         
     3.2. Physical Reference Model 
         
        The following reference models describe physical power topologies 
        that exist in parallel to the communication topology. While many more 
        permutations of topologies can be created the following are some 
        basic ones that show how Energy Management topologies differ from 
        Network Management topologies. 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 10] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        Basic Energy Management 
                               +--------------------------+                           
                               | Energy Management System |                           
                               +--------------------------+                           
                                           ^  ^ 
                                monitoring |  | control 
                                           v  v 
                                       +---------+ 
                                       | device  | 
                                       +---------+                                    
         
        Basic Power Supply 
                    +-----------------------------------------+ 
                    |         energy management system        | 
                    +-----------------------------------------+ 
                          ^  ^                       ^  ^ 
               monitoring |  | control    monitoring |  | control 
                          v  v                       v  v 
                    +--------------+        +-----------------+ 
                    | power supply |########|      device     | 
                    +--------------+        +-----------------+ 
                             
        Single Power Supply with Multiple Devices 
                      +---------------------------------------+ 
                      |       energy management system        | 
                      +---------------------------------------+ 
                         ^  ^                       ^  ^ 
              monitoring |  | control    monitoring |  | control 
                         v  v                       v  v 
                      +--------+        +------------------+ 
                      | power  |########|         device 1 | 
                      | supply |   #    +------------------+-+ 
                      +--------+   #######|         device 2 | 
                                     #    +------------------+-+ 
                                     #######|         device 3 | 
                                            +------------------+ 
         
        Multiple Power Supply with Single Devices 
                   +----------------------------------------------+ 
                   |          energy management system            | 
                   +----------------------------------------------+ 
                       ^  ^              ^  ^              ^  ^ 
                  mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl. 
                       v  v              v  v              v  v 
                   +----------+      +----------+      +----------+ 
                   | power    |######|  device  |######| power    | 
                   | supply 1 |######|          |      | supply 2 | 
                   +----------+      +----------+      +----------+ 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 11] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
     3.3. Concerns Differing from Network Management 
         
           o  Identification of the power source of a device may be 
              independent of the communication network and require unique 
              identifiers. 
               
           o  Controlling power for a device may have to be fulfilled by 
              addressing the power source as opposed to directing control to 
              the device. For example controlling a device by controlling the 
              outlet of the PDU or controlling a simple light by controlling 
              its outlet. 
               
           o  Control of a device may need to be coordinated if there are 
              multiple power supplies. 
               
           o  Modeling of power when the flow of energy can be bi-directional 
              and require a separate interface model from Network Management. 
              For example energy received into a battery or energy provided 
              from battery). 
               
           o  Some devices may need out-of-band or proxy capabilities to 
              respond to communications request even though it is in a non-
              operational power state.  
               
           o  Estimates and source of measurements may vary among devices. 
              For example when devices do not have the capability to measure 
              power an estimate can be provided from the device or estimated 
              by the EnMS. This may require annotation of a measurement. 
               
           o  A device may require a separate abstract model to describe its 
              components and interconnections than a model used to describe 
              it for Network Management. 
         
         
     3.4. Concerns Not Addressed 
         
        Non-Electrical Equipment 
         
        The primary focus of this framework is the management of Electrical 
        Equipment.  Some Non-Electrical Equipment may be connected to 
        communication networks and could have their energy managed if 
        normalized to the electrical units for power and energy. Non- 
        Electrical equipment that do not convert-to or present-as equivalent 
        to Electrical Equipment is not addressed. 
         
        Energy Procurement and Manufacturing 
         
        While an EnMS may be a central point for corporate reporting, cost, 
        environmental impact, and regulatory compliance, Energy Management in 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 12] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        this framework excludes energy procurement and the environmental 
        impact of energy use.   
         
        As such the framework does not include: 
           o  Cost in currency or environmental units of manufacturing a 
              device. 
           o  Embedded carbon or environmental equivalences of a device 
           o  Cost in currency or environmental impact to dismantle or 
              recycle a device. 
           o  Supply chain analysis of energy sources for device deployment 
           o  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). 
      
     4. Energy Management Abstraction 
        Network management is often divided into the five main areas defined 
        in the ISO Telecommunications Management Network model: Fault, 
        Configuration, Accounting, Performance, and Security Management 
        (FCAPS) [X.700].  This traditional management model does not cover 
        Energy Management. 
         
        This section describes a conceptual model of information that can be 
        used for Energy Management. The classes and categories of attributes 
        in the model are described with rationale for each.  
         
     4.1. Conceptual Model 
        To address Energy Management this specification describes an 
        information model that can exist along with Network Management while 
        addressing issues specific to Energy Management. 
         
        An information model for Energy Management will need to describe a 
        means to report information, provide control, and model the 
        interconnections among physical entities (equipment). 
         
        Therefore, this section proposes a similar conceptual model for 
        physical entities to that used in Network Management: devices, 
        components, and interfaces. This section then defines the additional 
        attributes specific to Energy Management for those entities that are 
        not available in existing Network Management models. 
         
        For modeling the physical entities this section describes three 
        classes:  a Device, a Component, and a Power Interface. These classes 
        are sub-types of an abstract Energy Object class. 
         
        For modeling additional attributes, this section describes attributes 
        of an Energy Object for: identification, classification, context, 
        control, power and energy. 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 13] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        Since the interconnections between physical entities for Energy 
        Management may have no relation to the interconnections for Network 
        Management the Energy Object classes contain a separate Relationships 
        class as an attribute to model these types of interconnections.  
         
        The remainder of this section describes the conceptual model of the 
        classes and categories of attributes in the information model. The 
        formal definitions of the classes and attributes are specified in 
        Section 5.  
         
     4.2. Energy Object 
        An Energy Object is an abstract class that contains the base 
        attributes for Energy Management.  There are three types of Energy 
        Objects: Device, Component and Power Interface. 
         
     4.2.1. Device Class 
        The Device Class is a sub-class of Energy Object that represents a 
        physical piece of equipment. 
         
        A Device Class instance may represent a device that is a consumer, 
        producer, or meter, distributor, or store of energy.  
         
        A Device Class instance may represent a physical device that contains 
        other components. 
         
     4.2.2. Component Class 
        The Component Class is a sub-class of Energy Object that represents a 
        part of a physical piece of equipment. 
         
     4.2.3. Power Interface Class 
        The power interface class is a sub-class of Energy Object that 
        represents the interconnection among devices and components. 
        There are some similarities between Power Interfaces and network 
        interfaces.  A network interface can be set to different states, such 
        as sending or receiving data on an attached line.  Similarly, a Power 
        Interface can be receiving or providing power. 
         
        Physically, a Power Interface instance can represent an AC power 
        socket, an AC power cord attached to a device, or an 8P8C (RJ45) PoE 
        socket, etc. 
         
     4.3. Energy Object Attributes 
        This section describes categories of attributes for an Energy Object. 
          
     4.3.1. Identification 
        A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely 
        and persistently identify an Energy Object. Ideally the UUID is used 
        to distinguish the Energy Object within the EnMS. 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 14] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        Every Energy Object has an optional unique printable name.  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. 
         
        Additionally an alternate key is provided to allow an Energy Object 
        to be optionally linked with models in different systems. 
         
     4.3.2. Context in General 
        In order to aid in reporting and in differentiation between Energy 
        Objects, each object optionally contains information establishing its 
        business, site, or organizational context within a deployment. 
         
        Energy Objects contain a category attributed that broadly describes 
        how the object is used in a deployment. The category indicates if the 
        Energy Object is primarily functioning as a consumer, producer, 
        meter, distributor or store of energy.  
         
        Given the category and context of an object, an EnMS can summarize or 
        analyze measurements. For example, metered usage reported by a meter 
        and consumption usage reported by a device connected to that meter 
        may measure the same usage. With the two measurements identified by 
        category and context an EnMS can make summarizations and inferences. 
          
     4.3.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 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 are more important than a PC and a phone for lobby 
        use. 
         
        Although EnMS and administrators can establish their own ranking, the 
        following example is a broad recommendation for commercial 
        deployments [CISCO-EW]: 
         
           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 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 15] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
     4.3.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, commas separate the keywords and no spaces 
        between keywords are allowed.  For example, "HR,Bldg1,Private". 
         
     4.3.5. Context: Role 
        An Energy Object contains 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". 
         
     4.3.6. Context: Domain 
        An Energy Object contains a string to indicate membership in an 
        Energy Management Domain. An Energy Management Domain can be any 
        collection of devices in a deployment, but it is recommended to map 
        1:1 with a metered or sub-metered portion of the site.  
         
        In building management, a meter refers to the meter provided by the 
        utility used for billing and measuring power to an entire building or 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 16] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        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 is 
        instead used to get measurements from sub portions of a building. 
        An Energy Object should be a member of a single Energy Management 
        Domain therefore one attribute is provided.  The Energy Management 
        Domain may be configured on an Energy Object. 
         
     4.4. Measurements 
        An Energy Object contains attributes to describe power, energy and 
        demand measurements. 
         
        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 modeled as an Energy 
        Object but must provide information converted to and expressed in 
        watt-hours. 
         
        An analogy for understanding power versus energy measurements can be 
        made to speed and distance in automobiles. Just as a speedometer 
        indicates the rate of change of distance (speed), a power measurement 
        indicates the rate of transfer of energy. The odometer in an 
        automobile measures the cumulative distance traveled and similarly an 
        energy measurement indicates the accumulated energy transferred.  
         
        Demand measurements are averages of power measurements over time. So 
        using the same analogy to an automobile: measuring the average 
        vehicle speed over multiple intervals of time for a given distance 
        travelled, demand is the average power measured over multiple time 
        intervals for a given energy value. 
         
     4.4.1. Measurements: Power  
        Each Energy Object contains a Nameplate Power attribute that 
        describes the nominal power as specified by the manufacturer. 
        Power Measurement. The EnMS can use the Nameplate Power for 
        provisioning, capacity planning and (potentially) billing. 
         
        Each Energy Object will have information that describes the present 
        power information, along with how that measurement was obtained or 
        derived (e.g., actual, estimated, or static). 
         
        A power measurement is qualified with the units, magnitude and 
        direction of power flow, and is qualified as to the means by which 
        the measurement was made. 
         
        Power measurement magnitude conforms 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 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 17] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        value of the scaling factor.  3W implies that the BaseValue is 3 and 
        Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor = -3. 
         
        An Energy Object indicates how the power measurement was obtained 
        with a caliber attribute that indicates:  
           o  Whether the measurements were made at the device itself or at a 
              remote source. 
           o  Description of the method that was used to measure the power  
              and whether this method can distinguish actual or estimated 
              values.  
           o  Accuracy for actual measured values 
         
     4.4.2. Measurements: Power Attributes 
        Optionally, an Energy Object describes the Power measurements with 
        Power Attribute information reflecting the electrical characteristics 
        of the measurement. These Power Attributes adhere to the IEC 61850 7-
        2 standard for describing AC measurements. 
         
     4.4.3. Measurements: Energy 
        Optionally, an Energy Object that can report actual power readings 
        will have energy attributes that provide the energy used, produced, 
        or stored in kWh.  
         
     4.4.4. Measurements: Demand 
        Optionally, an Energy Object will provide demand information over 
        time. Demand measurements can be provided when the Energy Object is 
        capable of measuring actual power. 
          
     4.5. Control 
        An Energy Object can be controlled by setting a Power State.  An 
        Energy Object implements at least one set of Power States consisting 
        of at least two states, an on state and an off state. 
         
        Each Energy Object should indicate the sets of Power States that it 
        implements.  Well-known Power States Sets are registered with IANA. 
           
        When a device is set to a particular Power State, it may be busy. The 
        device will set the desired Power State and then update the actual 
        Power State when it changes.  There are then two Power State control 
        variables: actual and requested. 
        There are many existing standards for and implementations of Power 
        States.  An Energy Object can support a mixed set of Power States 
        defined in different standards. A basic example is given by the three 
        Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The 
        DMTF [DMTF], ACPI [ACPI], and PWG define larger numbers of Power 
        States. 
         
        The semantics of a Power State are specified by 
           a) the functionality provided by an Energy Object in this state, 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 18] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
           b) a limitation of the power that an Energy Object uses in this 
        state, 
           c) a combination of a) and b) 
         
        The semantics of a Power State should be clearly defined. Limitation 
        (curtailment) of the power used by an Energy Object in a state is 
        specified by: 
           o  an absolute power value 
           o  a percentage value of power relative to the energy object's 
              nameplate power 
           o  an indication of power relative to another power state. For 
              example: Specify that power in state A is less than in state B. 
           o  For supporting Power State management an Energy Object provides 
              statistics on Power States including the time an Energy Object 
              spent in a certain Power State and the number of times an 
              Energy Object entered a power state. 
         
        When requesting an Energy Object to enter a Power State an indication 
        of the Power State's name or number can be used. Optionally an 
        absolute or percentage of Nameplate Power can be provided to allow 
        the Energy Object to transition to a nearest or equivalent Power 
        State. 
         
     4.5.1. Power State Sets 
        There are several standards and implementations of Power State Sets.  
        An Energy Object can support one or multiple Power State Set 
        implementation(s) concurrently.  
         
        There are currently three Power State Sets advocated:   
          IEEE1621(256) - [IEEE1621] 
          DMTF(512)     - [DMTF] 
          EMAN(768)     - [EMAN-MONITORING-MIB] 
         
        The respective specific states related to each Power State Set are 
        specified in the following sections. The guidelines for the 
        modification of Power State Sets are specified in the IANA 
        Considerations Section.  
         
     4.5.2. Power State Set: IEEE1621 
        The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary 
        states: on, off or sleep. 
         
           o  on(0)    - The device is fully On and all features of the 
              device are in working mode.  
           o  off(1)   - The device is mechanically switched off and does not 
              consume energy.  
           o  sleep(2) - The device is in a power saving mode, and some 
              features may not be available immediately. 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 19] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
     4.5.3. Power State Set: DMTF 
        The 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)}  
         
        The DMTF standard is targeted for hosts and computers.  Details of 
        the semantics of each Power State within the DMTF Power State Set can 
        be obtained from the DMTF Power State Management Profile 
        specification [DMTF]. 
         
        The DMTF power profile extends ACPI power states. The following table 
        provides a mapping between DMTF and ACPI Power State Set: 
         
             DMTF                              ACPI         
            Reserved(0)                                     
            Reserved(1)                                     
            ON (2)                             G0-S0        
            Sleep-Light (3)                    G1-S1 G1-S2  
            Sleep-Deep (4)                     G1-S3        
            Power Cycle (Off-Soft) (5)         G2-S5        
            Off-hard (6)                       G3           
            Hibernate (Off-Soft) (7)           G1-S4        
            Off-Soft (8)                       G2-S5        
            Power Cycle (Off-Hard) (9)         G3           
            Master Bus Reset (10)              G2-S5        
            Diagnostic Interrupt (11)          G2-S5        
            Off-Soft Graceful (12)             G2-S5        
            Off-Hard Graceful (13)             G3           
            MasterBus Reset Graceful (14)      G2-S5        
            Power Cycle off-soft Graceful (15) G2-S5        
            Power Cycle off-hard Graceful (16) G3  
              
     4.5.4. Power State Set: IETF EMAN 
        An EMAN Power State Set represents an attempt at a standard approach 
        for modeling 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.  
         
        An Energy Object may implement fewer or more Power States than a 
        particular EMAN Power State Set specifies. In this case, the Energy 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 20] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        Object implementation can determine its own mapping to the predefined 
        EMAN Power States within the EMAN Power State Set. 
         
        There are twelve EMAN Power States that expand on [IEEE1621]. The 
        expanded list of Power States is derived from [CISCO-EW] and is 
        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 
        state 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 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.  
                         
                 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.  
         
                 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. 
           
                 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. 
           
                 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-standby.  The time for availability is longer than 
        ready(6).  For example processor context is may not be maintained. 
        Typically, energy consumption is close to zero.  
          
                 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 

      
      
     Claise et al.           Expires March 9, 2014                 [Page 21] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        transitioned into an operational state.  For example, processors are 
        not executing, but processor context is maintained.  
          
                 lowMinus(7) : Indicates some Energy Object features may not 
        be available and the Energy Object has taken measures or selected 
        options to provide less than low(8) usage.  
         
                 low(8)      : Indicates some features may not be available 
        and the Energy Object has taken measures or selected options to 
        provide less 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. 
         
     4.5.5. Power State Sets Comparison 
        A comparison of Power States from different Power State Sets can be 
        seen in the following table: 
         
          IEEE1621  DMTF         ACPI           EMAN  
             
          Non-operational states 
          off       Off-Hard     G3, S5         MechOff(1) 
          off       Off-Soft     G2, S5         SoftOff(2) 
          sleep     Hibernate    G1, S4         Hibernate(3) 
          sleep     Sleep-Deep   G1, S3         Sleep(4)  
          sleep     Sleep-Light  G1, S2         Standby(5) 
          sleep     Sleep-Light  G1, S1         Ready(6)  
         
          Operational states: 
          on        on           G0, S0, P5     LowMinus(7) 
          on        on           G0, S0, P4     Low(8) 
          on        on           G0, S0, P3     MediumMinus(9) 
          on        on           G0, S0, P2     Medium(10) 
          on        on           G0, S0, P1     HighMinus(11) 
          on        on           G0, S0, P0     High(12) 

      
      
     Claise et al.           Expires March 9, 2014                 [Page 22] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
      
     4.6. Relationships 
        Two Energy Objects can establish an Energy Object Relationship to 
        model the deployment topology with respect to Energy Management. 
          
        Relationships are modeled with a Relationship class that contains the 
        UUID of the participants in the relationship and a description of the 
        type of relationship. The types of relationships are:  power source. 
        metering, and aggregations.  
         
           o  The Power Source Relationship gives a view of the physical 
              wiring topology.  For example: a data center server receiving 
              power from two specific Power Interfaces from two different 
              PDUs.  
               
              Note: A power source relationship may or may not change as the 
              direction of power changes between two Energy Objects. The 
              relationship may remain to indicate the change of power 
              direction was unintended or an error condition.  
               
           o  The Metering Relationship gives the view of the metering 
              topology.  Physical 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. 
               
           o  The Aggregation Relationship gives a model of devices that may 
              aggregate (sum, average, etc) values for other devices.  The 
              Aggregation Relationship is slightly different compared to the 
              other relationships as this refers more to a management 
              function. 
         
        In some situations, it is not possible to discover the Energy Object 
        Relationships, and they must be set by an EnMS or administrator.  
        Given that relationships can be assigned manually, the following 
        sections describes guidelines for use. 
         
         
     4.6.1. Relationship Conventions and Guidelines 
        This Energy Management framework does not impose many "MUST" rules 
        related to Energy Object Relationships. There are always corner cases 
        that could be excluded with too strict specifications of 
        relationships. However, this Energy Management framework proposes a 
        series of guidelines, indicated with "SHOULD" and "MAY". 
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 23] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
     4.6.2. Guidelines: Power Source 
        Power Source relationships are intended to identify the connections 
        between Power Interfaces. This is analogous to a Layer 2 connection 
        in networking devices (a "one-hop connection"). 
         
        The preferred modeling would be for Power Interfaces to participate 
        in Power Source Relationships. It some cases Energy Objects may not 
        have the capability to model Power Interfaces.  Therefore a Power 
        Source Relationship can be established between two Energy Objects or 
        two non-connected Power Interfaces. 
         
        While strictly speaking Components and Power Interfaces on the same 
        device do provide or receive energy from each other, the Power Source 
        relationship is intended to show energy transfer between Devices. 
        Therefore the relationship is implied when on the same Device. 
         
        An Energy Object SHOULD NOT establish a Power Source Relationship 
        with a Component.  
           o  A Power Source Relationship SHOULD be established with the next 
              known Power Interface in the wiring topology.  
                
           o  The next known Power Interface in the wiring topology would be 
              the next device implementing the framework. In some cases the 
              domain of devices under management may include some devices 
              that do not implement the framework. In these cases, the Power 
              Source relationship can be established with the next device in 
              the topology that implements the framework and logically shows 
              the Power Source of the device. 
      
           o  Transitive Power Source relationships SHOULD NOT be 
              established.  For example, 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 "Poweredby" with 
              the Energy Object C. 
         
     4.6.3. Guidelines: Metering Relationship 
        Metering Relationships are intended to show when one Device acting as 
        a Meter is measuring the power or energy at a point in a power 
        distribution system. Since one point of a power distribution system 
        may cover many Devices with a complex wiring topology, this 
        relationship type can be seen as an arbitrary set. 
         
        Devices may include measuring hardware for components and Power 
        Interfaces or for the entire Device. For example, some PDUs may have 
        the ability to measure Power for each Power Interface (metered by 
        outlet). Others may be able to control power at each Power Interface 

      
      
     Claise et al.           Expires March 9, 2014                 [Page 24] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        but can only measure Power at the Power Inlet and a total for all 
        Power Interfaces (metered by device).    
            
        In such cases the Device SHOULD be modeled as an Energy Object that 
        meters all of its Power Outlets and each Power Outlet MAY be metered 
        by the Energy Object representing the Device. 
         
        In general: 
           o  A Metering Relationship MAY be established with any other 
              Energy Object, Component, or Power Interface. 
               
           o  Transitive Metering relationships MAY be used. 
      
           o  When there is a series of meters for one Energy Object, the 
              Energy Object MAY establish a Metering relationship with one or 
              more of the meters.   
         
     4.6.4. Guidelines: Aggregation  
        Aggregation relationships are intended to identify when one device is 
        used to accumulate values from other devices. Typically this is for 
        energy or power values among devices and not for Components or Power 
        Interfaces on the same device.  
         
        The intent of Aggregation relationships is to indicate when one 
        device is providing aggregate values for a set of other devices when 
        it is not obvious from the power source or simple containment within 
        a device. 
         
        Establishing aggregation relationships within the same device would 
        make modeling more complex and the aggregated values can be implied 
        from the use of Power Inlets, outlet and Energy Object values on the 
        same device. 
         
        Since an EnMS is naturally a point of aggregation it is not necessary 
        to model aggregation for Energy Management Systems. 
         
        Aggregation SHOULD be used for power and energy. It MAY be used for 
        aggregation of other values from the information model, but the rules 
        and logical ability to aggregate each attribute is out of scope for 
        this document. 
         
        In general: 
           o  A Device SHOULD NOT establish an Aggregation Relationship with 
              Components contained on the same device. 
           o  A Device SHOULD NOT establish an Aggregation Relationship with 
              the Power Interfaces contained on the same device. 
           o  A Device SHOULD NOT establish an Aggregation Relationship with 
              an EnMS.  

      
      
     Claise et al.           Expires March 9, 2014                 [Page 25] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
           o  Aggregators SHOULD log or provide notification in the case of 
              errors or missing values while performing aggregation. 
               
     4.6.5. Energy Object Relationship Extensions  
        This framework for Energy Management is based on three  relationship 
        types: Aggregation , Metering, and Power Source. 
        This framework is defined with possible future extension of new 
        Energy Object Relationships in mind.  
        For example: 
           o  Some Devices that may not be IP connected. This can be modeled 
              with a proxy relationship to an Energy Object within the 
              domain. This type of proxy relationship is left for further 
              development.  
           o  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 an 
              extension called a "gang relationship", whose semantics would 
              specify the Energy Objects' grouping. 
         
     5. Energy Management Information Model 
         
        This section presents an information model expression of the concepts 
        in this framework as a reference for implementers. The information 
        model is implemented as a MIB in the different related IETF EMAN 
        documents.  However, other programming structures with different data 
        models could be used as well. 
         
        Data modeling specifications of this information model may where 
        needed specify which attributes are required or optional. 
         
        EDITORs NOTE:  The working group is converging on the use of 
        code/pseudo-code rather than ascii UML diagram. If agreeable we can 
        either indicate a BNF syntax in a formal syntax section or use the 
        following table if obvious: 
         
        Syntax 
          
          UML Construct          
          [ISO-IEC-19501-2005] Equivalent Notation 
          -------------------- -------------------------------------------- 
          Notes                // Notes 
          Class  
          (Generalization)     CLASS name {member..} 
          Sub-Class   
          (Specialization)     CLASS subclass EXTENDS superclass {member..} 
          Class Member  
          (Attribute)          attribute : type  
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 26] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        Model 
         
        CLASS EnergyObject { 
         
           // identification / classification 
           index        : int 
           identifier   : uuid 
           alternatekey : string 
         
           // context 
           domainName      : string 
           role            : string 
           keywords [0..n] : string 
           importance      : int 
         
           // relationship 
           relationships [0..n] : Relationship 
         
           // measurements  
           nameplate    : Nameplate 
           power     : PowerMeasurement 
           energy    : EnergyMeasurment 
           demand    : DemandMeasurement 
         
           // control 
           powerControl [0..n] : PowerStateSet 
        }  
         
        CLASS Device EXTENDS EnergyObject { 
              eocategory   : enum { producer, consumer, meter, distributor, 
        store }  
        } 
         
        CLASS Component EXTENDS EnergyObject 
              eocategory   : enum { producer, consumer, meter, distributor, 
        store }  
        } 
         
        CLASS Interface EXTENDS EnergyObject{ 
              eoIfType : enum ( inlet, outlet, both} 
        } 
      
        CLASS Nameplate { 
              nominalPower : PowerMeasurement 
              details      : URI 
        }  
         
         
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 27] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        CLASS Relationship { 
              relationshipType    : enum { meters, meteredby, powers, 
        poweredby, aggregates, aggregatedby } 
              relationshipObject  : uuid 
        } 
         
        CLASS Measurement { 
              multiplier: enum { -24..24} 
              caliber   : enum { actual, estimated, static }  
              accuracy  : enum { 0..10000} // hundreds of percent  
        } 
         
        CLASS PowerMeasurement EXTENDS Measurement {  
              value          : long 
              units          : "W" 
              powerAttribute : PowerAttribute 
        }    
      
        CLASS EnergyMeasurement EXTENDS Measurement { 
              startTime : time 
              units     : "kWh" 
              provided  : long 
              used      : long 
              produced  : long  
              stored    : long 
        } 
         
        CLASS TimedMeasurement EXTENDS Measurement { 
              startTime  : timestamp 
              value      : Measurement 
              maximum    : Measurement 
        } 
         
        CLASS TimeInterval { 
              value      : long 
              units      : enum { seconds, miliseconds,...} 
        } 
         
        CLASS DemandMeasurement EXTENDS Measurement { 
              intervalLength : TimeInterval 
              interval       : long 
              intervalMode   : enum { periodic, sliding, total } 
              intervalWindow : TimeInterval 
              sampleRate     : TimeInterval 
              status         : enum { active, inactive } 
              measurements[0..n] : TimedMeasurements 
        } 
         
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 28] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        CLASS PowerStateSet { 
              powerSetIdentifier : int   
              name               : string 
              powerStates [0..n] : PowerState  
              operState          : int 
              adminState         : int 
              reason             : string 
              configuredTime     : timestamp 
        } 
         
        CLASS PowerState { 
              powerStateIdentifier  : int 
              name             : string 
              cardinality      : int 
              maximumPower     : PowerMeasurement 
              totalTimeInState : time 
              entryCount       : long 
        } 
         
        CLASS PowerAttribute { 
         
           // container for attributes 
                 acQuality   : ACQuality 
        } 
         
        CLASS ACQuality { 
           acConfiguration : enum {SNGL, DEL,WYE}  
           avgVoltage   : long    
           avgCurrent   : long  
           frequency    : long   
           unitMultiplier  : int  
           accuracy    : int   
           totalActivePower   : long   
           totalReactivePower : long  
           totalApparentPower : long   
           totalPowerFactor : long 
           phases [0..2]  : ACPhase   
        } 
         
        CLASS ACPhase { 
           phaseIndex : long  
           avgCurrent : long  
           activePower : long   
           reactivePower : long   
           apparentPower : long   
           powerFactor : long  
        } 
         
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 29] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        CLASS DelPhase EXTENDS ACPhase {                 
           phaseToNextPhaseVoltage  : long   
           thdVoltage : long                   
           thdCurrent : long 
        } 
         
        CLASS WYEPhase EXTENDS ACPhase { 
           phaseToNeutralVoltage : long   
           thdCurrent : long              
           thdVoltage : long              
        } 
         
     6. Modeling Relationships between Devices 
        In this section we give examples of how to use the Energy Management 
        framework relationships to model physical topologies.  Where 
        applicable, we show how the framework can be applied when Devices 
        have the capability to model Power Interfaces.  We also show how the 
        framework can be applied when devices cannot support Power Interfaces 
        but only monitor information or control the 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. 
         
     6.1. Power Source Relationship 
         
        The Power Source relationship is used to model the interconnections 
        between Devices, Components and/Power Interfaces to indicate the 
        source of energy for an Energy Object. Given the following examples 
        Devices we can show various types of configurations that would model 
        the reference or other topologies. 
         
        Given for all cases: 
         
        Device W: A computer with one power supply. Power interface 1 is an 
        inlet for Device W. 
         
        Device X: A computer with two power supplies. Power interface 1 and 
        power interface 2 are both inlets for Device X. 
           
        Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power 
        interface 0 is an inlet and power interface 1..10 are outlets. 
         
        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 March 9, 2014                 [Page 30] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
        Case 1: Simple Device with one Source 
         
        Physical Topology:  
         
           o  Device W inlet 1 is plugged into Device Y outlet 8. 
                   
        With Power Interfaces: 
         
           o  Device W has an Energy Object representing the computer itself 
              as well as one Power Interface defined as an inlet.  
           o  Device Y would have an Energy Object representing the PDU 
              itself (the 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. 
           
           +-------+------+       poweredBy +------+----------+ 
           | PDU Y | PI 8 |-----------------| PI 1 | Device W | 
           +-------+------+ powers          +------+----------+ 
         
        Without Power Interfaces: 
                
           o  Device W has an Energy Object representing the computer.  
           o  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. 
         
         
           +----------+       poweredBy +------------+ 
           |  PDU Y   |-----------------|  Device W  | 
           +----------+ powers          +------------+ 
         
        Case 2: Multiple Inlets 
         
        Physical Topology:  
           o  Device X inlet 1 is plugged into Device Y outlet 8. 
           o  Device X inlet 2 is plugged into Device Y outlet 9. 
         
        With Power Interfaces: 
         
           o  Device X has an Energy Object representing the computer itself. 
              It contains two Power Interfaces defined as inlets.  

      
      
     Claise et al.           Expires March 9, 2014                 [Page 31] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
           o  Device Y would have an Energy Object representing the PDU 
              itself (the 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 X inlet 1 is powered by Device Y outlet 8. 
        Device X inlet 2 is powered by Device Y outlet 9. 
         
           +-------+------+        poweredBy+------+----------+ 
           |       | PI 8 |-----------------| PI 1 |          | 
           |       |      |powers           |      |          | 
           | PDU Y +------+        poweredBy+------+ Device X | 
           |       | PI 9 |-----------------| PI 2 |          | 
           |       |      |powers           |      |          | 
           +-------+------+                 +------+----------+ 
         
        Without Power Interfaces: 
                
           o  Device X has an Energy Object representing the computer. Device 
              Y has an Energy Object representing the PDU.  
         
         
        The devices would have a Power Source Relationship such that: 
        Device X is powered by Device Y. 
         
           +----------+       poweredBy +------------+ 
           |  PDU Y   |-----------------|  Device X  | 
           +----------+ powers          +------------+ 
         
        Case 3: Multiple Sources 
         
        Physical Topology:  
           o  Device X inlet 1 is plugged into Device Y outlet 8. 
           o  Device X inlet 2 is plugged into Device Z outlet 9. 
         
         
        With Power Interfaces: 
         
           o  Device X has an Energy Object representing the computer itself. 
              It contains two Power Interface defined as inlets.  
           o  Device Y would have an Energy Object representing the PDU 
              itself  (the Device), with a Power Interface 0 defined as an 
              inlet and Power Interfaces 1..10 defined as outlets.  
           o  Device Z would have an Energy Object representing the PDU 
              itself  (the Device), with a Power Interface 0 defined as an 
              inlet and Power Interfaces 1..10 defined as outlets.  

      
      
     Claise et al.           Expires March 9, 2014                 [Page 32] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
        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. 
         
           +-------+------+        poweredBy+------+----------+ 
           | PDU Y | PI 8 |-----------------| PI 1 |          | 
           |       |      |powers           |      |          | 
           +-------+------+                 +------+          | 
                                                   | Device X | 
           +-------+------+        poweredBy+------+          | 
           | PDU Z | PI 9 |-----------------| PI 2 |          | 
           |       |      |powers           |      |          | 
           +-------+------+                 +------+----------+ 
         
         
        Without Power Interfaces: 
                
           o  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. 
         
           +----------+           poweredBy +------------+ 
           |  PDU Y   |---------------------|  Device X  | 
           +----------+ powers              +------------+ 
         
           +----------+           poweredBy +------------+ 
           |  PDU Z   |---------------------|  Device X  | 
           +----------+ powers              +------------+ 
     6.2. Metering Relationship 
         
        Case 1: Metering between two Devices 
         
        The metering topology between two devices is closely related to the 
        power source topology.  It is based on the assumption that in many 
        cases the power provided and the power received is the same for both 
        peers of a power source relationship.   
         
        We define in this case a Metering Relationship between two Devices or 
        Power Interfaces of Devices that have a power source relationship.  
        Power and energy values measured at one peer of the power source 
        relationship are reported for the other peer as well. 
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 33] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        The Metering Relationship is independent of the direction of the 
        Power Source Relationship.  The most common case is that values 
        measured at the power provider are reported for the power receiver. 
                            
           +-----+---+    meteredBy +--------+   poweredBy +-------+ 
           |Meter| PI|--------------| switch |-------------| phone | 
           +-----+---+ meters       +--------+ powers      +-------+ 
                   |                                           | 
                   |                                 meteredBy | 
                   +-------------------------------------------+ 
                    meters                
         
        Case 2: Metering among many Devices 
         
        A Sub-meter in a power distribution system can logically measure the  
        power or energy for all devices downstream from the meter in the 
        power distribution system.  As such, a Power metering relationship 
        can be seen as a relationship between a meter DEvice and all of the 
        devices downstream from the meter. 
         
        We define in this case a Power Source relationship between a metering 
        device and devices downstream from the meter. 
         
        In cases where the Power Source topology cannot be discovered or 
        derived from the information available in the Energy Management 
        Domain, the Metering Topology can be used to relate the upstream 
        meter to the downstream devices in the absence of specific power 
        source relationships.  
         
        A Metering Relationship can occur between devices that are not 
        directly connected, as shown in the following figure: 
         
                           +---------------+     
                           |   Device 1    |             
                           +---------------+  
                           |      PI       |  
                           +---------------+           
                                   |                  
                           +---------------+  
                           |     Meter     |  
                           +---------------+  
                                   . 
                                   . 
                                   . 
                  meters        meters           meters 
            +----------+   +----------+   +-----------+   
            | Device A |   | Device B |   | Device C  |  
            +----------+   +----------+   +-----------+   
         
      
      
     Claise et al.           Expires March 9, 2014                 [Page 34] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        An analogy to communications networks would be modeling connections 
        between servers (meters) and clients (devices) when the complete 
        Layer 2 topology between the servers and clients is not known. 
         
     6.3. Aggregation Relationship 
         
        Some devices can act as aggregation points for other devices.  For 
        example, a PDU controller device may contain the summation of power 
        and energy readings for many PDU devices.  The PDU controller will 
        have aggregate values for power and energy for a group of PDU 
        devices.  
         
        This aggregation is independent of the physical power or 
        communication topology.  
        An Aggregation Relationship is an Energy Object Relationship where 
        one Energy Object (called the Aggregate Energy Object) aggregates the 
        Energy Management information of one or more other Energy Objects.  
        These Energy Objects are said to have an Aggregation Relationship.   
         
        The functions that the aggregation point may perform include the 
        calculation of values such as average, count, maximum, median, 
        minimum, or the listing (collection) of the aggregation values, etc.   
        Based on the experience gained on aggregations at the IETF [draft-
        ietf-ipfix-a9n-08], the aggregation function in the EMAN framework is 
        limited to the summation. 
         
        When aggregation occurs across a set of entities, values to be 
        aggregated may be missing for some entities.  The EMAN framework does 
        not specify how these should be treated, as different implementations 
        may have good reason to take different approaches.  One common 
        treatment is to define the aggregation as missing if any of the 
        constituent elements are missing (useful to be most precise). Another 
        is to treat the missing value as zero (useful to have continuous data 
        streams). 
         
        The specifications of aggregation functions are out of scope of the 
        EMAN framework, but must be clearly specified by the equipment 
        vendor. 
         
     7. Relationship to Other Standards 
        This Energy Management framework uses, as much as possible, existing 
        standards 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: 

      
      
     Claise et al.           Expires March 9, 2014                 [Page 35] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
           o  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.  
           o  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:  
           o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.    
           o  ANSI C12.20 class 0.2, 0.5 
           o  The electrical characteristics and quality adhere closely to 
              the IEC 61850 7-2 standard for describing AC measurements.   
           o  The power state definitions are based on the DMTF Power State 
              Profile and ACPI models, with operational state extensions.  
                  
         
     8. 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. 
         
     8.1. Security Considerations for SNMP 
        Readable objects in 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 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: 
           o  Unauthorized changes to the Energy Management Domain or 
              business context of a device may result in misreporting or 
              interruption of power. 
           o  Unauthorized changes to a power state may disrupt the power 
              settings of the different devices, and therefore the state of 
              functionality of the respective devices. 
           o  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. 
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 36] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        It is recommended that implementers consider the security features as 
        provided by the SNMPv3 framework (see [RFC3410], section 8), 
        including full support for the 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. 
         
     9. IANA Considerations 
     9.1. IANA Registration of new Power State Sets 
        This document specifies an initial set of Power State Sets. The list 
        of these Power State Sets with their numeric identifiers is given is 
        Section 4. IANA maintains the lists of Power State Sets.  
         
        New assignments for Power State Set are administered by IANA through 
        Expert Review [RFC5226], i.e., review by one of a group of experts 
        designated by an IETF Area Director. The group of experts MUST check 
        the requested state for completeness and accuracy of the 
        description. A pure vendor specific implementation of Power State 
        Set shall not be adopted; since it would lead to proliferation of 
        Power State Sets.  
         
        Power states in a Power State Set are limited to 255 distinct 
        values. New Power State Set must be assigned the next available 
        numeric identifier that is a multiple of 256. 
         
     9.1.1. IANA Registration of the IEEE1621 Power State Set 
        This document specifies a set of values for the IEEE1621 Power State 
        Set [IEEE1621].  The list of these values with their identifiers is 
        given in Section 4.6.2.  IANA created a new registry for IEEE1621 
        Power State Set identifiers and filled it with the initial list of 
        identifiers. 
         
        New assignments (or potentially deprecation) for the IEEE1621 Power 
        State Set is administered by IANA through Expert Review [RFC5226], 
        i.e., review by one of a group of experts designated by an IETF Area 
        Director.  The group of experts must check the requested state for 
        completeness and accuracy of the description. 
         
     9.1.2. IANA Registration of the DMTF Power State Set 
        This document specifies a set of values for the DMTF Power State 
        Set.  The list of these values with their identifiers is given in 
        Section 4. IANA has created a new registry for DMTF Power State Set 
        identifiers and filled it with the initial list of identifiers. 
      
      
      
     Claise et al.           Expires March 9, 2014                 [Page 37] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        New assignments (or potentially deprecation) for the DMTF Power 
        State Set is administered by IANA through Expert Review [RFC5226], 
        i.e., review by one of a group of experts designated by an IETF Area 
        Director.  The group of experts must check the conformance with the 
        DMTF standard [DMTF], on the top of checking for completeness and 
        accuracy of the description. 
         
     9.1.3. IANA Registration of the EMAN Power State Set 
        This document specifies a set of values for the EMAN Power State 
        Set.  The list of these values with their identifiers is given in 
        Section 4.6.4.  IANA has created a new registry for EMAN Power State 
        Set identifiers and filled it with the initial list of identifiers. 
         
        New assignments (or potentially deprecation) for the EMAN Power 
        State Set is administered by IANA through Expert Review [RFC5226], 
        i.e., review by one of a group of experts designated by an IETF Area 
        Director.  The group of experts must check the requested state for 
        completeness and accuracy of the description. 
         
     9.1.4. Batteries Power State Set 
        Batteries have operational and administrational states that could be 
        represented as a power state set. Since the work for battery 
        management is parallel to this document, we are not proposing any 
        Power State Sets for batteries at this time.  
         
     9.2. Updating the Registration of Existing Power State Sets  
        With the evolution of standards, over time, it may be important to 
        deprecate some of the existing the Power State Sets, or to add or 
        deprecate some Power States within a Power State Set.  
         
        The registrant shall publish an Internet-draft or an individual 
        submission with the clear specification on deprecation of Power 
        State Sets or Power States registered with IANA.  The deprecation or 
        addition shall be administered by IANA through Expert Review 
        [RFC5226], i.e., review by one of a group of experts designated by 
        an IETF Area Director. The process should also allow for a mechanism 
        for cases where others have significant objections to claims on 
        deprecation of a registration. 
         
     10. References 
         
     Normative References 
         
        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
                  Requirement Levels", BCP 14, RFC 2119, March 1997 
         
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart, 
                  "Introduction and Applicability Statements for Internet 
                  Standard Management Framework ", RFC 3410, December 2002 
      
      
     Claise et al.           Expires March 9, 2014                 [Page 38] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
         
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique 
                  Identifier (UUID) URN Namespace", RFC 4122, July 2005 
         
        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an 
                  IANA Considerations Section in RFCs", RFC 5226, May 2008 
         
        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB (Version4)", 
                  RFC 6933, May 2013 
         
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between 
                  Information Models and Data Models", RFC 3444, January 2003 
         
        [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information technology, Open 
                  Distributed Processing -- Unified Modeling Language (UML), 
                  January 2005 
         
     Informative References 
         
        [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
                  "Structure of Management Information Version 2 (SMIv2", RFC 
                  2578, April 1999 
         
         
        [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed., "Specification of 
                  the IP Flow Information Export (IPFIX) Protocol for the 
                  Exchange of IP Traffic Flow Information ", draft-ietf-
                  ipfix-protocol-rfc5101bis-08, (work in progress), June 2013 
         
        [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 
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 39] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. 
                  Chandramouli, "Requirements for Energy Management", draft-
                  ietf-eman-requirements-14, (work in progress), May 2013 
         
        [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy Object Contet 
                  MIB", draft-ietf-eman-energy-aware-mib-08, (work in 
                  progress), April 2013 
         
        [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-05, (work in 
                  progress), April 2013 
         
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " 
                  Definition of Managed Objects for Battery Monitoring", 
                  draft-ietf-eman-battery-mib-08, (work in progress), 
                  February 2013 
         
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, "Energy 
                  Management (EMAN) Applicability Statement", draft-ietf-
                  eman-applicability-statement-03, (work in progress), April 
                  2013 
         
        [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 
         
        [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?openform 
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 40] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
        [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/documents
                  /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 
          
        [ASHRAE-201] "ASHRAE Standard Project Committee 201  
                        (SPC 201)Facility Smart Grid Information  
                        Model", http://spc201.ashraepcs.org 
         
        [CHEN] "The Entity-Relationship Model: Toward a Unified View of 
                  Data",  Peter Pin-shan Chen, ACM Transactions on Database 
                  Systems, 1976 
         
        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello, Roland 
                  Saville, Steve Kramling, Cisco Validated Designs, September 
                  2010, 
                  http://www.cisco.com/en/US/docs/solutions/Enterprise/Border
                  less_Networks/Energy_Management/energywisedg.html 
         
         
         
     11. Acknowledgments 
         
        The authors would like to Michael Brown for his editorial work 
        improving the text dramatically. Thanks to Rolf Winter for his 
        feedback and to Bill Mielke for feedback and very detailed review. 
        Thanks to Bruce Nordman for brainstorming with numerous conference 
        calls and discussions. Finally, the authors would like to thank the 
        EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau. 
         
        This document was prepared using 2-Word-v2.0.template.dot. 
         

      
      
     Claise et al.           Expires March 9, 2014                 [Page 41] 
         


     Internet-Draft              EMAN Framework               September 2013 
         
     Authors' Addresses 
      
        John Parello 
        Cisco Systems, Inc. 
        3550 Cisco Way  
        San Jose, California 95134  
        US 
            
        Phone: +1 408 525 2339 
        Email: jparello@cisco.com 
         
        Benoit Claise 
        Cisco Systems, Inc. 
        De Kleetlaan 6a b1 
        Diegem 1813 
        BE 
            
        Phone: +32 2 704 5622 
        Email: bclaise@cisco.com 
         
         
        Brad Schoening 
        44 Rivers Edge Drive 
        Little Silver, NJ 07739 
        US 
         
        Phone:  
        Email: brad.schoening@verizon.net 
         
         
        Juergen Quittek 
        NEC Europe Ltd.  
        Network Laboratories 
        Kurfuersten-Anlage 36 
        69115 Heidelberg 
        Germany 
         
        Phone: +49 6221 90511 15 
        EMail: quittek@netlab.nec.de 

      
      
     Claise et al.           Expires March 9, 2014                 [Page 42]