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

The information below is for an old version of the document
Document Type Active Internet-Draft (eman WG)
Last updated 2014-01-20
Stream IETF
Intended RFC status Informational
Formats plain text pdf html bibtex
Reviews
Stream WG state WG Document
Awaiting External Review/Resolution of Issues Raised
Document shepherd Thomas Nadeau
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD Joel Jaeggli
Send notices to (None)
Network Working Group                             J. Parello 
    Internet-Draft                                     B. Claise 
    Intended Status: Informational             Cisco Systems, Inc. 
    Expires: October 30, 2015                       B. Schoening 
                                          Independent Consultant 
                                                      J. Quittek 
                                                  NEC Europe Ltd 
     
                                                January 20, 2014 
     
                                     
                       Energy Management Framework 
                       draft-ietf-eman-framework-14 

    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 October 30 2015. 
                           


    Claise et al          Expires October 30, 2015       [Page 1] 
     

    Internet-Draft             EMAN Framework        January 2014 
        
    Copyright Notice 
        
       Copyright (c) 2014 IETF Trust and the persons identified as 
       the document authors. All rights reserved. 
        
       This document is subject to BCP 78 and the IETF Trust's 
       Legal Provisions Relating to IETF Documents 
       (http://trustee.ietf.org/license-info) in effect on the 
       date of publication of this document. Please review these 
       documents carefully, as they describe your rights and 
       restrictions with respect to this document. Code Components 
       extracted from this document must include Simplified BSD 
       License text as described in Section 4.e of the Trust Legal 
       Provisions and are provided without warranty as described 
       in the Simplified BSD License. 
        
    Abstract 
     
       This document defines a framework for Energy Management for 
       devices and device components within or connected to 
       communication networks.  The framework presents 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 can be attributed with 
       identity, classification, and 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. 
                           

     
     
    Claise et al.          Expires October 30 2015       [Page 2] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
    Table of Contents 
        
       1. Introduction ............................................... 3 
       2. Terminology ................................................ 4 
       3. Target Devices ............................................ 10 
       4. Physical Reference Model .................................. 11 
       5. Not Covered by the Framework .............................. 12 
       6. Energy Management Abstraction ............................. 13 
          6.1. Conceptual Model ..................................... 13 
          6.2. Energy Object (Class) ................................ 14 
          6.3. Energy Object Attributes ............................. 15 
          6.4. Measurements ......................................... 18 
          6.5. Control .............................................. 20 
          6.6. Relationships ........................................ 25 
       7. Energy Management Information Model ....................... 29 
       8. Modeling Relationships between Devices .................... 33 
          8.1. Power Source Relationship ............................ 33 
          8.2. Metering Relationship ................................ 37 
          8.3. Aggregation Relationship ............................. 38 
       9. Relationship to Other Standards ........................... 39 
       10. Implementation Status .................................... 39 
       11. Security Considerations .................................. 40 
          11.1. Security Considerations for SNMP .................... 40 
       12. IANA Considerations....................................... 41 
          12.1. IANA Registration of new Power State Sets ........... 41 
          12.2. Updating the Registration of Existing Power State 
          Sets ...................................................... 43 
       13. References ............................................... 43 
       14. Acknowledgments .......................................... 46 
       Appendix A. Information Model Listing ........................ 46 
       Authors' Addresses ........................................... 56 
        
    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, per 
       the Energy Management requirements specified in [RFC6988]. 
       The devices, or components of these devices (such as line 
       cards, fans, and disks) can then be monitored and 
       controlled.  Monitoring includes measuring power, energy, 
       demand, and attributes of power.  Energy control can be 
     
     
    Claise et al.          Expires October 30 2015       [Page 3] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       performed by setting a devices' or components' state. The 
       framework also covers monitoring and control of batteries 
       contained in devices. 
        
       This framework further describes how to identify, classify 
       and provide context for such devices.  While 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. 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 (Energy Management System) 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 
       (who aggregates values of others). 
        
       The relationships build on the Power Interface concept. The 
       different relationships among devices and components, 
       specified in this document, include: power source, 
       metering, and aggregation relationships. 
        
    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. 
     
     
    Claise et al.          Expires October 30 2015       [Page 4] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       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. 
        
       The terms are listing in an order that aids in reading 
       where terms may build off a previous term as opposed to an 
       alphabetical ordering. Some terms that are common in 
       electrical engineering or that describe common physical 
       items use a lower case notation. 
        
       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. 
          
         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.   
          
     
     
    Claise et al.          Expires October 30 2015       [Page 5] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
         2. Example ISO-EnMS:  Company A defines a set of policies 
         and procedures indicating there should exist multiple 
         computerized systems that will poll energy measurements 
         from their meters and pricing / source data from their 
         local utility. Company A specifies that their CFO (Chief 
         Financial Officer) 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 herein is the 
         preferred meaning of an Energy Management System (EnMS). 
         The definition from [ISO50001] can be referred to as ISO 
         Energy Management System (ISO-EnMS). 
        
       Energy Monitoring 
         Energy Monitoring is a part of Energy Management that 
         deals with collecting or reading information from devices 
         to aid in Energy Management.  
        
       Energy Control 
         Energy Control is a part of Energy Management that deals 
         with directing influence over devices.  
        
       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] 
     
     
    Claise et al.          Expires October 30 2015       [Page 6] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       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 
         1. Energy is the capacity of a system to produce external 
         activity or perform work [ISO50001] 
        
       power 
         The time rate at which energy is emitted, transferred, or 
         received; usually expressed in watts (joules per second). 
          
         Reference: [IEEE100] 
          
       demand  
         The average value of power or a related quantity over a 
         specified interval of time. Note: Demand is expressed in 
         kilowatts, kilovolt-amperes, kilovars, or other suitable 
         units. 
          
         Reference: [IEEE100]  
          
         NOTES: 
         1. While IEEE100 defines demand in kilo measurements, for 
         EMAN we use watts with any suitable metric prefix.  
        
       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 

     
     
    Claise et al.          Expires October 30 2015       [Page 7] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
         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 Interface  
         A power inlet, outlet, or both. 
        
       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 electricity supplied in an 
         electric power system and the loads connected to that 
         electric power system. 
          
         Reference: [IEC60050] 
          
         NOTES:  

     
     
    Claise et al.          Expires October 30 2015       [Page 8] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
         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] 
        
       Power State 
         A Power State is a condition or mode of a device (or 
         component) that broadly characterizes its capabilities, 
         power, 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.   
        
                           

     
     
    Claise et al.          Expires October 30 2015       [Page 9] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
    3. Target Devices 
        
       With Energy Management, there exists a wide variety of 
       devices that may be contained in the same deployment 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). These 
       target devices include, for example:  
          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 
        
       Target devices include devices that communicate via the 
       Internet Protocol (IP) as well as devices using other means 
       for communication. The latter are managed through gateways 
       or proxies that can communicate using IP. 
                           

     
     
    Claise et al.          Expires October 30 2015      [Page 10] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
    4. Physical Reference Model 
        
       The following reference model describes physical power 
       topologies that exist in parallel to a communication 
       topology. While many more topologies can be created with 
       combination of devices, the following are some basic ones 
       that show how Energy Management topologies differ from 
       Network Management topologies. 
        
       NOTE: "###" is used to denote a transfer of energy. 
              - >  is used to denote a transfer of information. 
                  
      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 source |########|      device     | 
                   +--------------+        +-----------------+ 
                            
      Single Power Supply with Multiple Devices 
        
                     +---------------------------------------+ 
                     |       Energy Management System        | 
                     +---------------------------------------+ 
                        ^  ^                       ^  ^ 
             monitoring |  | control    monitoring |  | control 
                        v  v                       v  v 
                     +--------+        +------------------+ 
                     | power  |########|         device 1 | 
                     | source |   #    +------------------+-+ 
                     +--------+   #######|         device 2 | 
                                    #    +------------------+-+ 
     
     
    Claise et al.          Expires October 30 2015      [Page 11] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                                    #######|         device 3 | 
                                           +------------------+ 
     
      Multiple Power Supplies with Single Devices 
        
            +----------------------------------------------+ 
            |          Energy Management System            | 
            +----------------------------------------------+ 
                ^  ^              ^  ^              ^  ^ 
           mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl. 
                v  v              v  v              v  v 
            +----------+      +----------+      +----------+ 
            | power    |######|  device  |######| power    | 
            | source 1 |######|          |      | source 2 | 
            +----------+      +----------+      +----------+ 
        
        
        
    5. Not Covered by the Framework  
        
       While this framework is intended as a framework for Energy 
       Management in general, there are some areas that are not 
       covered. 
         
      Non-Electrical Equipment 
        
       The primary focus of this framework is the management of 
       electrical equipment. Non-Electrical equipment can be 
       covered by the framework by providing interfaces that 
       comply with the framework. For example, using the same 
       units for power and energy. Therefore, non-electrical 
       equipment that do not convert-to or present-as equivalent 
       to electrical equipment are not addressed. 
        
      Energy Procurement and Manufacturing 
        
       While an EnMS may be a central point for corporate 
       reporting, cost computation, environmental impact analysis, 
       and regulatory compliance reporting - Energy Management in 
       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. 
     
     
    Claise et al.          Expires October 30 2015      [Page 12] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
          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 the 
             transfer of energy from a diesel source). 
     
    6. Energy Management Abstraction 
        
       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.  
        
    6.1. Conceptual Model 
        
       This section describes an information model that addressing 
       issues specific to Energy Management, which complements 
       existing Network Management models. 
     
       An information model for Energy Management will need to 
       describe a means to monitor and control devices and 
       components. The model will also need to describe the 
       relationships among and connections between devices and 
       components. 
        
       This section proposes a similar conceptual model for 
       devices and components 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 devices and components this section 
       describes three classes:  a Device (Class), a Component 
       (Class), and a Power Interface (Class). These classes are 
       sub-types of an abstract Energy Object (Class). 
        
           Summary of Notation for Modeling Physical Equipment 
        
       Physical         Modeling (Meta Data)     Model Instance 
       --------------------------------------------------------- 
       equipment        Energy Object (Class)    Energy Object  
       device           Device (Class)           Device 
       component        Component (Class)        Component 
       inlet / outlet   Power Interface (Class)  Power Interface 
     
         

     
     
    Claise et al.          Expires October 30 2015      [Page 13] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       This section then describes the attributes of an Energy 
       Object (Class) for identification, classification, context, 
       control, power and energy.  
        
       Since the interconnections between devices and components 
       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 next sections describe the each of the classes and 
       categories of attributes in the information model.  
        
       Not all of the attributes are mandatory for 
       implementations. Specifications describing implementations 
       of the information model in this framework need to be 
       explicit about which are mandatory and which are optional 
       to implement 
        
       The formal definitions of the classes and attributes are 
       specified in Section 7.  
        
    6.2. Energy Object (Class) 
        
       An Energy Object (Class) 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. 
        
       The Energy Object (Class) is an abstract class that 
       contains the base attributes to represent a piece of 
       equipment for Energy Management.  There are three types of 
       Energy Object (Class)'s: Device (Class), Component 
       (Component) and Power Interface (Class). 
        
        
    6.2.1. Device (Class) 
        
       The Device (Class) is a sub-class of Energy Object (Class) 
       that represents a physical piece of equipment. 
        
       A Device (Class) instance represents a device that is a 
       consumer, producer, meter, distributor, or store of energy.  
        
       A Device (Class) instance may represent a physical device 
       that contains other components. 
        
    6.2.2. Component (Class) 
        
     
     
    Claise et al.          Expires October 30 2015      [Page 14] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       The Component (Class) is a sub-class of Energy Object 
       (Class) that represents a part of a physical piece of 
       equipment. 
        
    6.2.3. Power Interface (Class) 
        
       A Power Interface (Class) represents the interconnections 
       (inlet, outlet) among devices or components where energy 
       can be provided, received, or both.  
        
       The Power Interface (Class) is a sub-class of Energy Object 
       (Class) that represents a physical inlet or outlet. 
        
       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 energy. 
        
       A Power Interface (Class) instance can represent 
       (physically) an AC power socket, an AC power cord attached 
       to a device, or an 8P8C (RJ45) PoE socket, etc. 
        
    6.3. Energy Object Attributes 
        
       This section describes categories of attributes for an 
       Energy Object (Class). 
         
    6.3.1. Identification 
        
       A Universal Unique Identifier (UUID) [RFC4122] is used to 
       uniquely and persistently identify an Energy Object.  
        
       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. 
        
    6.3.2. Context in General 
        
       In order to aid in reporting and in differentiation between 
       Energy Objects, each object optionally contains information 

     
     
    Claise et al.          Expires October 30 2015      [Page 15] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       establishing its business, site, or organizational context 
       within a deployment. 
        
       The Energy Object (Class) contains a category attribute 
       that broadly describes how an instance 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 the site.  
         
    6.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 
        
    6.3.4. Context: Keywords 
        
       The Energy Object (Class) contains an attribute with 
       context keywords. 
        
       An Energy Object can provide a set of keywords that are a 
       list of tags that can be used for grouping, for summary 
       reporting (within or between Energy Management Domains), 
       and for searching.   
        
     
     
    Claise et al.          Expires October 30 2015      [Page 16] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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 an Energy Object.  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". 
        
    6.3.5. Context: Role 
        
       The Energy Object (Class) contains a role attribute. The 
       "role description" string indicates the primary purpose the 
       Energy Object serves in the deployment.  This could be a 
       string representing the purpose the Energy Object fulfills 
       in the deployment. 
        
       Administrators can define any naming scheme for the role.  
       As guidance, a two-word role that combines the service the 
       Energy Object provides along with type can be used 
       [IPENERGY]. 
        
       Example types of devices: Router, Switch, Light, Phone, 
       WorkStation, Server, Display, Kiosk, HVAC. 
        
       Example Services by Line of Business: 
        
         Line of Business   Service 
          ----------------------------------------------------- 
         Education           Student, Faculty, 
       Administration,  
                               Athletic 
         Finance         Trader, Teller, Fulfillment 
         Manufacturing     Assembly, Control, Shipping 
         Retail          Advertising, Cashier 
         Support         Helpdesk, Management 
         Medical         Patient, Administration, Billing 
        
       Role as a two-word string: "Faculty Desktop", "Teller 
       Phone", "Shipping HVAC", "Advertising Display", "Helpdesk 
       Kiosk", "Administration Switch". 
        
    6.3.6. Context: Domain 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 17] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       The Energy Object (Class) contains a string attribute to 
       indicate membership in an Energy Management Domain. An 
       Energy Management Domain can be any collection of Energy 
       Objects 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 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.   
        
    6.4. Measurements 
        
       The Energy Object (Class) contains attributes to describe 
       power, energy and demand measurements. 
        
       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. 
        
       Within this framework, energy will only be quantified in 
       units of watt-hours. Physical devices measuring energy in 
       other units must convert values to watt-hours or be 
       represented by Energy Objects that convert to watt-hours. 
        
    6.4.1. Measurements: Power  
        
       The Energy Object (Class) contains a Nameplate Power 
       attribute that describes the nominal power as specified by 
       the manufacturer of the device. The EnMS can use the 
       Nameplate Power for provisioning, capacity planning and 
       (potentially) billing. 
     
     
    Claise et al.          Expires October 30 2015      [Page 18] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       The Energy Object (Class) has attributes that describe 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 [IEC61850] 
       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 17, it could be 17 W, 17 mW, 17 kW, or 17 mW, 
       depending on the value of the scaling factor.  17 W implies 
       that the BaseValue is 17 and Scale = 0, whereas 17 mW 
       implies BaseValue = 17 and ScaleFactor = -3. 
        
       An Energy Object (Class) indicates how the power 
       measurement was obtained with a caliber and accuracy 
       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 
        
    6.4.2. Measurements: Power Attributes 
        
       The Energy Object (Class) contains an optional attribute 
       that describes Power Attribute information reflecting the 
       electrical characteristics of the measurement. These Power 
       Attributes adhere to the [IEC61850-7-2] standard for 
       describing AC measurements. 
        
    6.4.3. Measurements: Energy 
        
       The Energy Object (Class) contains optional attributes that 
       represent the energy used, received, produced and or 
       stored.  Typically only devices or components that can 
       measure actual power will have the ability to measure 
       energy. 
        
    6.4.4. Measurements: Demand 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 19] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       The Energy Object (Class) contains optional attributes that  
       represent demand information over time. Typically only 
       devices or components that can report actual power are 
       capable of measuring demand. 
         
        
    6.5. Control 
        
       The Energy Object (Class) contains a Power State Set 
       (Class) attribute that represents the set of Power States a 
       device or component supports.  
        
       A Power State describes a condition or mode of a device or 
       component. While Power States are typically used for 
       control they may be used for monitoring only.  
        
       A device or component is expected to support at least one 
       set of Power States consisting of at least two states, an 
       on state and an off state. 
        
       There are many existing standards describing device and 
       component Power States.  The framework supports modeling 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 all 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, 
          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 may be 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. 
     
     
    Claise et al.          Expires October 30 2015      [Page 20] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       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. 
        
       When an Energy Object is set to a particular Power State, 
       the represented device or component may be busy. The Energy 
       Object should set the desired Power State and then update 
       the actual Power State when the device or component 
       changes. There are then two Power State (Class) control 
       attributes: actual and requested. 
        
       The following sections describe well-known Power States for 
       devices and components that should be modeled in the 
       information model. 
         
    6.5.1. Power State Sets 
        
       There are several standards and implementations of Power 
       State Sets.  The Energy Object (Class) support modeling one 
       or multiple Power State Set implementation(s) on the device 
       or component concurrently.  
        
       There are currently three Power State Sets advocated:   
         IEEE1621(256) - [IEEE1621] 
         DMTF(512)     - [DMTF] 
         EMAN(768)     - [this document] 
        
       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.  
        
    6.5.2. Power State Set: IEEE1621 
        
       The IEEE1621 Power State Set [IEEE1621] consists of 3 
       rudimentary states: on, off or sleep. 
        
       In IEEE1621 devices are limited to the three basic power 
       states - on, sleep, and off. Any additional power states 
       are variants of one of the basic states rather than a 
       fourth state [IEEE1621]. 
        
    6.5.3. Power State Set: DMTF 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 21] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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  
             
    6.5.4. Power State Set: IETF EMAN 
        
       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.  
        

     
     
    Claise et al.          Expires October 30 2015      [Page 22] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       Physical devices and components are expected to support the 
       EMAN Power State Set or to be modeled via an Energy Object 
       the supports these states.  
        
       An Energy Object may implement fewer or more Power States 
       than a particular EMAN Power State Set specifies. In that 
       case, the Energy 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 
     
     
    Claise et al.          Expires October 30 2015      [Page 23] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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 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 use less energy than 
       low(8).  
        
                low(8)      : Indicates some features may not be 
       available and the Energy Object has taken measures or 
       selected options to use less energy than mediumMinus(9). 
        
                mediumMinus(9): Indicates all Energy Object 
       features are available but the Energy Object has taken 
       measures or selected options to use less energy than 
       medium(10). 
        
                medium(10)  : Indicates all Energy Object features 
       are available but the Energy Object has taken measures or 
       selected options to use less energy than highMinus(11). 
        
                highMinus(11): Indicates all Energy Object 
       features are available and has taken measures or selected 
       options to use less energy than high(12). 
        
                high(12)    : Indicates all Energy Object features 
       are available and the Energy Object may use the maximum 
       energy as indicated by the Nameplate Power. 
                           

     
     
    Claise et al.          Expires October 30 2015      [Page 24] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
    6.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) 
         off       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) 
     
    6.6. Relationships 
        
       The Energy Object (Class) contains a set of Relationship 
       (Class) attributes to model the relationships between 
       devices and components.  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 other participant in the 
       relationship and a name that describes the type of 
       relationship [CHEN]. The types of relationships are:  Power 
       Source, Metering, and Aggregations.  
        
          o A Power Source Relationship is relationship where one 
             Energy Object provides power to one or more Energy 
             Objects. 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.  
     
     
    Claise et al.          Expires October 30 2015      [Page 25] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
              
          o A Metering Relationship is relationship where one 
             Energy Object measures power, energy, demand or Power 
             Attributes of one or more other Energy Objects. 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 An Aggregation Relationship is a relationship where 
             one Energy Object aggregates Energy Management 
             information of one or more other Energy Objects. 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 an EnMS or administrator 
       must set them.  Given that relationships can be assigned 
       manually, the following sections describe guidelines for 
       use. 
        
        
    6.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, the 
       framework proposes a series of guidelines, indicated with 
       "SHOULD" and "MAY". 
        
    6.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 
     
     
    Claise et al.          Expires October 30 2015      [Page 26] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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. 
        
    6.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 within a  
       wiring topology, this relationship type can be seen as a 
       set. 
        
       Some devices, however, may include measuring hardware for 
       components, and outlets or for the entire device. For 
       example, some PDUs may have the ability to measure power 
       for each outlet and are commonly referred to as metered-by-
       outlet. Others may be able to control power at each power 
     
     
    Claise et al.          Expires October 30 2015      [Page 27] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       outlet but can only measure power at the power inlet - 
       commonly referred to as metered-by-device.    
           
       While the Metering Relationship could be used to represent 
       a device as metered-by-outlet or metered-by-device, the 
       Metering Relationship SHOULD be used to model the 
       relationship between a meter and all devices covered by the 
       meter downstream in the power distribution system 
        
       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.   
        
    6.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. 
        
       The Aggregation Relationship is intended 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: 

     
     
    Claise et al.          Expires October 30 2015      [Page 28] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
          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.  
          o Aggregators SHOULD log or provide notification in the 
             case of errors or missing values while performing 
             aggregation. 
              
    6.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 devices 
             and components 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. 
        
    7. 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. 
        
      Syntax 
         
         UML Construct          
         [ISO-IEC-19501-2005] Equivalent Notation 
         -------------------- ------------------------------------ 
     
     
    Claise et al.          Expires October 30 2015      [Page 29] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
         Notes                // Notes 
         Class  
         (Generalization)     CLASS name {member..} 
         Sub-Class   
         (Specialization)     CLASS subclass  
                                    EXTENDS superclass {member..}  
         Class Member  
         (Attribute)          attribute : type  
        
      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 
       }  
                           

     
     
    Claise et al.          Expires October 30 2015      [Page 30] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       CLASS PowerInterface EXTENDS EnergyObject{ 
             eoIfType : enum { inlet, outlet, both} 
       } 
        
       CLASS Device EXTENDS EnergyObject { 
             eocategory   : enum { producer, consumer, meter, 
       distributor, store } 
             powerInterfaces[0..n]: PowerInterface 
             components [0..n]    : Component  
       } 
        
       CLASS Component EXTENDS EnergyObject 
             eocategory   : enum { producer, consumer, meter, 
       distributor, store }  
             powerInterfaces[0..n]: PowerInterface 
             components [0..n]    : Component 
        
       } 
        
       CLASS Nameplate { 
             nominalPower : PowerMeasurement 
             details      : URI 
       }  
        
       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 
     
     
    Claise et al.          Expires October 30 2015      [Page 31] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       } 
        
       CLASS TimedMeasurement EXTENDS Measurement { 
             startTime  : timestamp 
             value      : Measurement 
             maximum    : Measurement 
       } 
        
       CLASS TimeInterval { 
             value      : long 
             units      : enum { seconds, miliseconds,...} 
       } 
        
       CLASS DemandMeasurement EXTENDS Measurement { 
             intervalLength : TimeInterval 
             intervals      : long 
             intervalMode   : enum { periodic, sliding, total } 
             intervalWindow : TimeInterval 
             sampleRate     : TimeInterval 
             status         : enum { active, inactive } 
             measurements[0..n] : TimedMeasurements 
       } 
        
       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 { 
             acQuality  : ACQuality 
       } 
     
       CLASS ACQuality { 
             acConfiguration : enum {SNGL, DEL,WYE} 
             avgVoltage         : long 
     
     
    Claise et al.          Expires October 30 2015      [Page 32] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
             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 
       } 
        
       CLASS DelPhase EXTENDS ACPhase { 
             phaseToNextPhaseVoltage  : long 
             thdVoltage : long 
             thdCurrent : long 
       } 
        
       CLASS WYEPhase EXTENDS ACPhase { 
             phaseToNeutralVoltage : long 
             thdCurrent : long 
             thdVoltage : long 
       } 
        
    8. Modeling Relationships between Devices 
        
       In this section we give examples of how to use the EMAN 
       information model to model physical topologies.  Where 
       applicable, we show how the framework can be applied when 
       devices can be modeled with Power Interfaces.  We also show 
       how the framework can be applied when devices cannot be 
       modeled with Power Interfaces but only monitored or control 
       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 outlets. 
        
    8.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 a device. 
     
     
    Claise et al.          Expires October 30 2015      [Page 33] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       In the following examples we show variations on modeling 
       the reference topologies using relationships. 
        
       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. 
     
      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.  
     
     
    Claise et al.          Expires October 30 2015      [Page 34] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
          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.  
          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.  
        

     
     
    Claise et al.          Expires October 30 2015      [Page 35] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       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.  
        
       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: 
               

     
     
    Claise et al.          Expires October 30 2015      [Page 36] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
          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              +------------+ 
        
    8.2. Metering Relationship 
        
       A 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 
       Metering relationship can be seen as a relationship between 
       a meter and all of the devices downstream from the meter. 
        
       We define in this case a Metering relationship between a 
       meter and devices downstream from the meter. 
        
       +-----+---+    meteredBy +--------+   poweredBy +-------+ 
       |Meter| PI|--------------| switch |-------------| phone | 
       +-----+---+ meters       +--------+ powers      +-------+ 
               |                                           | 
               |                                 meteredBy | 
               +-------------------------------------------+ 
                meters                
        
       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       |  
     
     
    Claise et al.          Expires October 30 2015      [Page 37] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                          +---------------+  
                                  |          
                          +---------------+  
                          |     Meter     |  
                          +---------------+  
                                  . 
                                  . 
                                  . 
                 meters        meters           meters 
           +----------+   +----------+   +-----------+   
           | Device A |   | Device B |   | Device C  |   
           +----------+   +----------+   +-----------+   
        
       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. 
        
    8.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.  
        
       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 
       [RFC7015], 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). 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 38] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       The specifications of aggregation functions are out of 
       scope of the EMAN framework, but must be clearly specified 
       by the equipment vendor. 
        
    9. 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 [IEC61850].   
        
       Specific examples include: 
          o The scaling factor, which represents Energy Object 
             usage magnitude, conforms to the [IEC61850] 
             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 [IEC61850-7-4] 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.      
        
    10. Implementation Status 
        
       RFC Editor Note: Please remove this section and the 
       reference to [RFC6982] before publication. 
        
       This section records the status of known implementations of 
       the protocol defined by this specification at the time of 
       posting of this Internet-Draft, and is based on a proposal 
       described in [RFC6982].  The description of implementations 
       in this section is intended to assist the IETF in its 
       decision processes in progressing drafts to RFCs.  Please 
       note that the listing of any individual implementation here 
       does not imply endorsement by the IETF.  Furthermore, no 
       effort has been spent to verify the information presented 
       here that was supplied by IETF contributors. This is not 
       intended as, and must not be construed to be, a catalog of 

     
     
    Claise et al.          Expires October 30 2015      [Page 39] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       available implementations or their features.  Readers are 
       advised to note that other implementations may exist. 
        
       According to RFC 6982, "this will allow reviewers and 
       working groups to assign due consideration to documents 
       that have the benefit of running code, which may serve as 
       evidence of valuable experimentation and feedback that have 
       made the implemented protocols more mature. 
        
       Implementation descriptions for this document are 
       maintained at: 
       http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations 
        
    11. 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 network 
       capabilities. 
        
       The information and control capabilities specified in this 
       framework could be exploited with detriment to a site or 
       deployment. Implementers of the framework SHOULD examine 
       and mitigate security threats with respect to these new 
       capabilities. 
        
       [RFC3410] User Security Model for SNMPv3 presents a good 
       description of threats and mitigations for the SNMPv3 
       protocol that can be used as a guide for implementations of 
       this framework using other protocols. 
        
    11.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: 

     
     
    Claise et al.          Expires October 30 2015      [Page 40] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
          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. 
        
       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. 
        
        
    12. IANA Considerations 
    12.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 6. 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 

     
     
    Claise et al.          Expires October 30 2015      [Page 41] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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. 
        
    12.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 6.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. 
        
    12.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 6. IANA has created a new registry for 
       DMTF Power State Set identifiers and filled it with the 
       initial list of identifiers. 
     
       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. 
        
    12.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 6.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 
     
     
    Claise et al.          Expires October 30 2015      [Page 42] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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. 
        
    12.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.  
        
    12.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. 
        
    13. 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 
        
       [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 
                 between Information Models and Data Models", RFC 
                 3444, January 2003 
        
        

     
     
    Claise et al.          Expires October 30 2015      [Page 43] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       [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 
        
       [RFC6988]  Quittek, J., Chandramouli, M., Winter, R., 
                 Dietz, T., and B. Claise, "Requirements for 
                 Energy Management", RFC 6988, Septembre 2013 
        
        
       [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information 
                 technology, Open Distributed Processing -- 
                 Unified Modeling Language (UML), January 2005 
        
    Informative References 
        
       [RFC3986] T. Berners-Lee, Ed., " Uniform Resource 
                 Identifier (URI): Generic Syntax", RFC3 986, 
                 January 2005 
        
       [RFC6982] Y. Sheffer, and Adrian Farrel, "Improving 
                 Awareness of Running Code: The Implementation 
                 Status Section", RFC 6982, July 2013 
        
       [RFC7015] B. Trammell, A. Wagner, and B. Claise, "Flow 
                 Aggregation for the IP Flow Information Export 
                 (IPFIX) Protocol", RFC 7015, September 2013 
     
       [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 
     
       [ITU-T-M-3400] TMN Recommendation on Management Functions 
                 (M.3400), 1997 
        
       [NMF] "Network Management Fundamentals", Alexander Clemm, 
                 ISBN: 1-58720-137-2, 2007 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 44] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       [TMN] "TMN Management Functions : Performance Management", 
                 ITU-T M.3400 
        
       [IEEE100] "The Authoritative Dictionary of IEEE Standards 
                 Terms" 
                 http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
                 p?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?o
                 penform 
        
       [IEC61850] Power Utility Automation, 
                 http://www.iec.ch/smartgrid/standards/ 
        
        
       [IEC61850-7-2] Abstract communication service interface 
                 (ACSI), http://www.iec.ch/smartgrid/standards/ 
         
       [IEC61850-7-4] Compatible logical node classes and data 
                 classes, http://www.iec.ch/smartgrid/standards/ 
     
       [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 
        

     
     
    Claise et al.          Expires October 30 2015      [Page 45] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       [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/Enterpr
                 ise/Borderless_Networks/Energy_Management/energyw
                 isedg.html 
        
        
        
        
    14. Acknowledgments 
        
       The authors would like to thank 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. 
        
    Appendix A. 
                Information Model Listing 
        
       EnergyObject (Class) 
        
       r  index         Integer           An RFC6933 
                                           entPhysicalIndex 

       w  name          String            An RFC6933 
                                           entPhysicalName 

       r  identifier    uuid              An [RFC6933] 
                                           entPhysicalUUID 

       r  alternatekey  String            A manufacturer defined 
       w                                   string that can be 
                                           used to identify the 
                                           Energy Object 

       r  domainName    String            The name of an Energy 
       w                                   Management domain for 
                                           the Energy Object 

       r  role          String            An administratively 
       w                                   assigned name to 
                                           indicate the purpose 
                                           an Energy Object 

     
     
    Claise et al.          Expires October 30 2015      [Page 46] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                                           serves in the network 

       r  keywords      String            A list of keywords or 
       w  [0..n]                          tags that can be used 
                                           to group Energy 
                                           Objects for reporting 
                                           or searching 

       r  importance    Integer           Specifies a ranking of 
       w                                   how important the 
                                           Energy Object is (on a 
                                           scale of 1 to 100) 
                                           compared with other 
                                           Energy Objects  

       r  relationships Relationship      A list of 
       w  [0..n]                          relationships between 
                                           this Energy Object and 
                                           other Energy Objects 

       r  nameplate     Nameplate         The nominal 
                                           PowerMeasurement of 
                                           the Energy Object as 
                                           specified by the 
                                           device manufacturer 

       r  power         PowerMeasurement  The present power 
                                           measurement of the 
                                           Energy Object 

       r  energy        EnergyMeasurment  The present energy 
                                           measurement for the 
                                           Energy Object 

       r  demand        DemandMeasurement The present demand 
                                           measurement for the 
                                           Energy Object 

       r  powerControl  PowerStateSet     A list of Power States 
           [0..n]                          Sets the Energy Object 
                                           supports 

        
        
       PowerInterface (Class) inherits from and specializes 
       EnergyObject 
        
       r  eoIfType      Enumeration      Indicates if the Power 
                                          Interface is an - 
     
     
    Claise et al.          Expires October 30 2015      [Page 47] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                                          inlet; outlet; both 

        
                           

     
     
    Claise et al.          Expires October 30 2015      [Page 48] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       Device (Class) inherits from and specializes EnergyObject 
        
       r  eocategory      Enumeration    Broadly indicates if 
       w                                 the Device is a 
                                          producer consumer meter 
                                          distributor or store of 
                                          energy  

       r  powerInterfaces PowerInterface A list of 
           [0..n]                         PowerInterfaces 
                                          contained in this 
                                          Device 

       r  components      Component      A list of Components 
           [0..n]                         contained in this 
                                          Device 

        
        
       Component (Class) inherits from and specializes 
       EnergyObject 
        
       r  eocategory      Enumeration    Broadly indicates if 
       w                                 the Component is a 
                                          producer consumer meter 
                                          distributor or store of 
                                          energy 

       r  powerInterfaces PowerInterface A list of 
           [0..n]                         PowerInterfaces 
                                          contained in this 
                                          Component 

       r  components      Component      A list of Components 
           [0..n]                         contained in this 
                                          Component 

        
                           

     
     
    Claise et al.          Expires October 30 2015      [Page 49] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       Nameplate (Class)  
        
       r  nominalPower  PowerMeasuremen  The nominal power of 
                         t                the Energy Object as 
                                          specified by the device 
                                          manufacturer 

       r  details       URI              an [RFC3986] URI that 
       w                                 links to manufacturer 
                                          information about the 
                                          nominal power of a 
                                          device 

         
       Relationship (Class)  
        
       rw relationshipType   Enumeratio  A description of the 
                               n           relationhip indicating 
                                           - meters; meteredby; 
                                           powers; poweredby; 
                                           aggregates; 
                                           aggregatedby  

       rw relationshipObject uuid        An [RFC6933] 
                                           entPhysicalUUID that 
                                           indicates the other 
                                           participating Energy 
                                           Object in the 
                                           relationship 

        
        
       Measurement (Class)  
        
       r  multiplier  Enumeration  The magnitude of the 
                                     Measurement in the range -
                                     24..24 

       r  caliber     Enumeration  Specifies how the Measurement 
                                     was obtained - actual; 
                                     estimated; static  

       r  accuracy    Enumeration  Specifies the accuracy of the 
                                     measurement if applicable as 
                                     0..10000 indicating hundreds 
                                     of percent 

        
        
     
     
    Claise et al.          Expires October 30 2015      [Page 50] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       PowerMeasurement (Class) inherits from and specializes 
       Measurement  
        
       r value          Long           A measurement value of 
                                         power 

       r units          "W"            The units of measure for 
                                         the power - "Watts" 

       r powerAttribute PowerAttribute  Measurement of the 
                                         electrical current; 
                                         voltage; phase and/or 
                                         frequencies for the 
                                         PowerMeasurement 

        
        
       EnergyMeasurement (Class) inherits from and specializes 
       Measurement  
        
       r startTime  Time         Specifies the start time of the 
                                  EnergyMeasurement interval 

       r units      "kWh"        The units of measure for the 
                                  energy - kilowatt hours  

       r provided   Long         A measurement of energy 
                                  provided 

       r used       Long         A measurement of energy used / 
                                  consumed 

       r produced   Long         A measurement of energy 
                                  produced  

       r stored     Long         A measurement of energy stores 

        
        
       TimedMeasurement (Class) inherits from and specializes 
       Measurement  
        
       r  startTime timestamp    A start time of a measurement 

       r  value     Measurement  A measurement value 

       r  maximum   Measurement  A maximum value measured since a 
                                  previous timestamp 

     
     
    Claise et al.          Expires October 30 2015      [Page 51] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
        
       TimeInterval (Class) 
        
       r  value     Long        a value of time 

       r  units     Enumeration  a magnitude of time express as 
                                  seconds with an SI prefix 
                                  (miliseconds etc) 

        
        
       DemandMeasurement (Class) inherits from and specializes 
       Measurement  
        
       r  intervalLengt  TimeInterval     The length of time 
       w  h                               over which to compute 
                                           average energy 

       r  intervals      Long             The number of 
       w                                  intervals that can be 
                                           measured  

       r  intervalMode   Enumeration      The mode of interval 
       w                                  measurement as - 
                                           periodic; sliding; 
                                           total  

       r  intervalWindo  TimeInterval     The duration between 
       w  w                               the starting time of 
                                           one sliding window and 
                                           the next starting time 

       r  sampleRate     TimeInterval     The sampling rate at 
       w                                  which to poll power in 
                                           order to compute 
                                           demand 

       r  status         Enumeration      a control to start or 
       w                                  stop demand 
                                           measurement as - 
                                           active; inactive  

       r  measurements[  TimedMeasuremen  a collection of 
           0..n]          t                TimedMeasurements to 
                                           compute demand 

        
        
     
     
    Claise et al.          Expires October 30 2015      [Page 52] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
        
       PowerStateSet (Class) 
        
       r  powerSetIdentifier Integer      an IANA assigned value 
                                           indicating a Power 
                                           State Set 

       r  name               String       A Power State Set name 

       r  powerStates [0..n] PowerState   a set of Power States 
                                           for the given 
                                           identifier  

       rw operState          Integer      The current 
                                           operational Power 
                                           State 

       rw adminState         Integer      The desired Power 
                                           State 

       rw reason             String       Describes the reason 
                                           for the adminState 

       r  configuredTime     timestamp    Indicates the time of 
                                           the desired Power 
                                           State  

        
        
       PowerState (Class) 
        
       r  powerStateIdentifier Integer  an IANA assigned value 
                                          indicating a Power State 

       r  name                 String   A name for the Power 
                                          State 

       r  cardinality          Integer  A value indicating an 
                                          ordering of the Power 
                                          State 

       r  maximumPower         PowerMea indicates the maximum 
       w                       surement power for the Energy 
                                          Object at this Power 
                                          State   

       r  totalTimeInState     Time     Indicates the total time 
                                          an Energy Object has 
                                          been in this Power State 
     
     
    Claise et al.          Expires October 30 2015      [Page 53] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                                          since last reset 

       r  entryCount           Long     Indicates the number of 
                                          time the Energy Object 
                                          has entered changed to 
                                          this state 

        
        
       PowerAttribute (Class) 
        
       r acQuality  ACQuality  Describes AC Power Attributes for 
                                a Measurement 

        
        
       ACQuality (Class) 
        
       r acConfiguration    Enumera Describes the physical 
                             tion    configuration of 
                                      alternating current as 
                                      single phase (SNGL) three 
                                      phase delta (DEL) or three 
                                      phase Y (WYE) 

       r avgVoltage         Long    The average of the voltage 
                                      measured over an integral 
                                      number of AC cycles 
                                      [IEC61850-7-4] 'Vol' 

       r avgCurrent         Long    The current per phase 
                                      [IEC61850-7-4] 'Amp' 

       r frequency          Long    Basic frequency of the AC 
                                      circuit [IEC61850-7-4] 'Hz' 

       r unitMultiplier     Integer Magnitude of watts for the 
                                      usage value in this 
                                      instance 

       r accuracy           Integer Percentage value in 100ths 
                                      of a percent representing 
                                      the presumed accuracy of 
                                      active; reactive; and 
                                      apparent power in this 
                                      instance 

       r totalActivePower   Long    A measured value of the 
                                      actual power delivered to 
     
     
    Claise et al.          Expires October 30 2015      [Page 54] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                                      or consumed by the load 
                                      [IEC61850-7-4] 'TotW' 

       r totalReactivePower Long    A measured value of the 
                                      reactive portion of the 
                                      apparent power [IEC61850-7-
                                      4] 'TotVAr' 

       r totalApparentPower Long    A measured value of the 
                                      voltage and current which 
                                      determines the apparent 
                                      power as the vector sum of 
                                      real and reactive power 
                                      [IEC61850-7-4] 'TotVA' 

       r totalPowerFactor   Long    A measured value of the 
                                      ratio of the real power 
                                      flowing to the load versus 
                                      the apparent power 
                                      [IEC61850-7-4] 'TotPF' 

       r phases [0..2]      ACPhase A description of the three 
                                      phase power 

        
        
       ACPhase (Class) 
        
       r phaseIndex    Long  A phase angle typically 
                               corresponding to - 0; 120; 240 

       r avgCurrent    Long  A measured value of the current per 
                               phase [IEC61850-7-4] 'A' 

       r activePower   Long  A measured value of the actual 
                               power delivered to or consumed by 
                               the load [IEC61850-7-4] 'W' 

       r reactivePower Long  A measured value of the reactive 
                               portion of the apparent power 
                               [IEC61850-7-4] 'VAr' 

       r apparentPower Long  A measured value of the active plus 
                               reactive power [IEC61850-7-4] 'VA' 

       r powerFactor   Long  A measure ratio of the real power 
                               flowing to the load versus the 
                               apparent power for this phase 

     
     
    Claise et al.          Expires October 30 2015      [Page 55] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
                               [IEC61850-7-4] 'PF' 

        
        
        
        
        
       DelPhase (Class) inherits from and specializes ACPhase  
        
       r phaseToNextPhas  Long  A measured value of phase to 
          eVoltage               next phase voltages where the 
                                 next phase is [IEC61850-7-4] 
                                 'PPV' 

       r thdVoltage       Long  A calculated value for the 
                                 voltage total harmonic disortion 
                                 for phase to next phase. Method 
                                 of calculation is not specified 
                                 [IEC61850-7-4] 'ThdPPV' 

       r thdCurrent       Long  A calculated value for the 
                                 voltage total harmonic disortion 
                                 (THD) for phase to phase. Method 
                                 of calculation is not specified 
                                 [IEC61850-7-4] 'ThdPPV' 

        
        
       WYEPhase (Class) inherits from and specializes ACPhase  
        
       r phaseToNeutral  Long A measured value of phase to 
          Voltage              neutral voltage [IEC61850-7-4] 
                               'PhV' 

       r thdCurrent      Long A measured value of phase currents 
                               [IEC61850-7-4] 'A' 

       r thdVoltage      Long A calculated value of the voltage 
                               total harmonic distortion (THD) 
                               for phase to neutral [IEC61850-7-
                               4] 'ThdPhV' 

        
    Authors' Addresses 
     
       John Parello 
       Cisco Systems, Inc. 
       3550 Cisco Way  
       San Jose, California 95134  
     
     
    Claise et al.          Expires October 30 2015      [Page 56] 
        

    Internet-Draft             EMAN Framework        January 2014 
        
       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 October 30 2015      [Page 57]