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

The information below is for an old version of the document
Document Type Active Internet-Draft (eman WG)
Last updated 2013-10-18
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: April 18, 2014                          B. Schoening 
                                            Independent Consultant 
                                                        J. Quittek 
                                                    NEC Europe Ltd 
      
                                                  October 18, 2013 
      
                                      
                        Energy Management Framework 
                       draft-ietf-eman-framework-11 

     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 April 18, 2014. 

     Claise et al            Expires April 18, 2014        [Page 1] 
      


     Internet-Draft              EMAN Framework        October 2013 
         
         
     Copyright Notice 
         
        Copyright (c) 2013 IETF Trust and the persons identified as 
        the document authors. All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's 
        Legal Provisions Relating to IETF Documents 
        (http://trustee.ietf.org/license-info) in effect on the 
        date of publication of this document. Please review these 
        documents carefully, as they describe your rights and 
        restrictions with respect 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 April 18, 2014       [Page 2] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
     Table of Contents 
         
        1. Introduction.......................................... 3 
           1.1. Energy Management Documents Overview............. 4 
        2. Terminology........................................... 5 
        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............... 34 
           8.1. Power Source Relationship....................... 34 
           8.2. Metering Relationship........................... 38 
           8.3. Aggregation Relationship........................ 39 
        9. Relationship to Other Standards...................... 39 
        10. Security Considerations............................. 40 
           10.1. Security Considerations for SNMP............... 40 
        11. IANA Considerations................................. 41 
           11.1. IANA Registration of new Power State Sets...... 41 
           11.2. Updating the Registration...Power State Sets... 43 
        12. References.......................................... 43 
        13. Acknowledgments..................................... 46 
         
     1. Introduction 
         
        Network management is often divided into the five main 
        areas defined in the ISO Telecommunications Management 
        Network model: Fault, Configuration, Accounting, 
        Performance, and Security Management (FCAPS) [X.700].  Not 
        covered by this traditional management model is Energy 
        Management, which is rapidly becoming a critical area of 
        concern worldwide, as seen in [ISO50001].  
         
        This document defines an Energy Management framework for 
        devices within or connected to communication networks.  The 
        devices, or components of these devices (such as line 
        cards, fans, disks) can then be monitored and controlled.  
        Monitoring includes measuring power, energy, demand, and 
        attributes of power.  Energy control can be performed by 
        setting a devices' or components' state. The framework also 
        covers monitoring and control of batteries contained in 
        devices. 
      
      
     Claise et al.           Expires April 18, 2014       [Page 3] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        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. 
         
     1.1. Energy Management Documents Overview 
         
        The EMAN standard provides a set of specifications for 
        Energy Management.  This document specifies the framework, 
        per the Energy Management requirements specified in [EMAN-
        REQ]. 
         
        The applicability statement document [EMAN-AS] includes use 
        cases, a cross-reference between existing standards and the 
        EMAN standard, and a description of this framework's 
        relationship to other frameworks. 
         
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies 
        objects for addressing device/component identification, 
      
      
     Claise et al.           Expires April 18, 2014       [Page 4] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        classification, context information, and relationships from 
        the point of view of Energy Management. 
         
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] 
        specifies objects for monitoring of power, energy, demand, 
        and control. 
         
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines 
        managed objects that provide information on the status and 
        condition of batteries in managed devices. 
         
     2. Terminology 
         
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
        and "OPTIONAL" in this document are to be interpreted as 
        described in RFC-2119 [RFC2119].  
         
        In this document these words will appear with that 
        interpretation only when in ALL CAPS. Lower case uses of 
        these words are not to be interpreted as carrying RFC-
        2119 significance. 
         
        In this section some terms have a NOTE that is not part of 
        the definition itself, but accounts for differences between 
        terminologies of different standards organizations or 
        further clarifies the definition. 
         
        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]. 
           
      
      
     Claise et al.           Expires April 18, 2014       [Page 5] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          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.   
           
          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 
      
      
     Claise et al.           Expires April 18, 2014       [Page 6] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          a part of, or in connection with, an electric 
          installation. 
          Reference: [IEEE100] 
         
        non-electrical equipment (mechanical equipment) 
          A general term including materials, fittings, devices, 
          appliances, fixtures, apparatus, machines, etc., used as 
          a part of, or in connection with, non-electrical power 
          installations. 
           
          Reference: Adapted from [IEEE100] 
         
        device 
          A piece of electrical or non-electrical equipment. 
           
          Reference: Adapted from [IEEE100]  
         
        component 
          A part of an electrical or non-electrical equipment 
          (device).  
           
          Reference: Adapted from [ITU-T-M-3400] 
         
        power inlet  
          A power inlet (or simply inlet) is an interface at which 
          a device or component receives energy from another device 
          or component. 
         
        power outlet  
          A power outlet (or simply outlet) is an interface at 
          which a device or component provides energy to another 
          device or component. 
           
        energy  
          That which does work or is capable of doing work. As used 
          by electric utilities, it is generally a reference to 
          electrical energy and is measured in kilowatt hours 
          (kWh). 
           
          Reference: [IEEE100] 
           
          NOTES 
          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). 
           
      
      
     Claise et al.           Expires April 18, 2014       [Page 7] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          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 
          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. 
      
      
     Claise et al.           Expires April 18, 2014       [Page 8] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          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:  
          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 April 18, 2014       [Page 9] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
     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 April 18, 2014      [Page 10] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
     4. Physical Reference Model 
         
        The following reference model describes physical power 
        topologies that exist in parallel to the 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 April 18, 2014      [Page 11] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
                                     #    +------------------+-+ 
                                     #######|         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 

      
      
     Claise et al.           Expires April 18, 2014      [Page 12] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
           o  Cost in currency or environmental impact to dismantle 
              or recycle a device. 
           o  Supply chain analysis of energy sources for device 
              deployment 
           o  Conversion of the usage or production of energy to 
              units expressed from the source of that energy (such 
              as the greenhouse gas emissions associated 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 April 18, 2014      [Page 13] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          
        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 of the classes 
        and categories of attributes in the information model. 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) 
         
        The Component (Class) is a sub-class of Energy Object 
        (Class) that represents a part of a physical piece of 
        equipment. 
         

      
      
     Claise et al.           Expires April 18, 2014      [Page 14] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
     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 
        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 
      
      
     Claise et al.           Expires April 18, 2014      [Page 15] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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.   
         
        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.   
      
      
     Claise et al.           Expires April 18, 2014      [Page 16] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        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 
         
        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.  
         

      
      
     Claise et al.           Expires April 18, 2014      [Page 17] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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. 
         
        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). 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 18] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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 [IEC-61850-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 
         
        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. 
          
         

      
      
     Claise et al.           Expires April 18, 2014      [Page 19] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
     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. 
         
        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. 
      
      
     Claise et al.           Expires April 18, 2014      [Page 20] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        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)     - [EMAN-MON-MIB] 
         
        The respective specific states related to each Power State 
        Set are specified in the following sections. The guidelines 
        for the modification of Power State Sets are specified in 
        the IANA Considerations Section.  
         
     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 
         
        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), 
      
      
     Claise et al.           Expires April 18, 2014      [Page 21] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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.  
         
        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. 
      
      
     Claise et al.           Expires April 18, 2014      [Page 22] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        There are twelve EMAN Power States that expand on 
        [IEEE1621]. The expanded list of Power States is derived 
        from [CISCO-EW] and is divided into six operational states 
        and six non-operational states. 
         
        The lowest non-operational state is 1 and the highest is 6.  
        Each non-operational state corresponds to an [ACPI] Global 
        and System state between G3 (hard-off) and G1 (sleeping).  
        Each operational state represents a performance state, and 
        may be mapped to [ACPI] states P0 (maximum performance 
        power) through P5 (minimum performance and minimum power).  
         
        In each of the non-operational states (from mechoff(1) to 
        ready(6)), the Power State preceding it is expected to have 
        a lower Power value and a longer delay in returning to an 
        operational state:  
         
                 mechoff(1) : An off state where no Energy Object 
        features are available.  The Energy Object is unavailable.  
        No energy is being consumed and the power connector can be 
        removed.  
                         
                 softoff(2) : Similar to mechoff(1), but some 
        components remain powered or receive trace power so that 
        the Energy Object can be awakened from its off state.  In 
        softoff(2), no context is saved and the device typically 
        requires a complete boot when awakened.  
         
                 hibernate(3): No Energy Object features are 
        available.   The Energy Object may be awakened without 
        requiring a complete boot, but the time for availability is 
        longer than sleep(4). An example for state hibernate(3) is 
        a save to-disk state where DRAM context is not maintained.  
        Typically, energy consumption is zero or close to zero. 
           
                 sleep(4)    : No Energy Object features are 
        available, except for out-of-band management, such as wake-
        up mechanisms.  The time for availability is longer than 
        standby(5). An example for state sleep(4) is a save-to-RAM 
        state, where DRAM context is maintained.  Typically, energy 
        consumption is close to zero. 
           
                 standby(5) : No Energy Object features are 
        available, except for out-of-band management, such as wake-
        up mechanisms.  This mode is analogous to cold-standby.  
        The time for availability is longer than ready(6).  For 
        example processor context is may not be maintained. 
        Typically, energy consumption is close to zero.  
      
      
     Claise et al.           Expires April 18, 2014      [Page 23] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
          
                 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 April 18, 2014      [Page 24] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
         
     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.  
               

      
      
     Claise et al.           Expires April 18, 2014      [Page 25] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
              Note: A Power Source Relationship may or may not 
              change as the direction of power changes between two 
              Energy Objects. The relationship may remain to 
              indicate the change of power direction was unintended 
              or an error condition.  
               
           o  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 
      
      
     Claise et al.           Expires April 18, 2014      [Page 26] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        a Layer 2 connection in networking devices (a "one-hop 
        connection"). 
         
        The preferred modeling would be for Power Interfaces to 
        participate in Power Source Relationships. It some cases 
        Energy Objects may not have the capability to model Power 
        Interfaces.  Therefore a Power Source Relationship can be 
        established between two Energy Objects or two non-connected 
        Power Interfaces. 
         
        While strictly speaking Components and Power Interfaces on 
        the same Device do provide or receive energy from each 
        other, the Power Source relationship is intended to show 
        energy transfer between Devices. Therefore the relationship 
        is implied when on the same Device. 
         
        An Energy Object SHOULD NOT establish a Power Source 
        Relationship with a Component.  
           o  A Power Source Relationship SHOULD be established 
              with the next known Power Interface in the wiring 
              topology.  
                
           o  The next known Power Interface in the wiring topology 
              would be the next device implementing the framework. 
              In some cases the domain of devices under management 
              may include some devices that do not implement the 
              framework. In these cases, the Power Source 
              relationship can be established with the next device 
              in the topology that implements the framework and 
              logically shows the Power Source of the device. 
      
           o  Transitive Power Source relationships SHOULD NOT be 
              established.  For example, if an Energy Object A has 
              a Power Source Relationship "Poweredby" with the 
              Energy Object B, and if the Energy Object B has a 
              Power Source Relationship "Poweredby" with the Energy 
              Object C, then the Energy Object A SHOULD NOT have a 
              Power Source Relationship "Poweredby" with the Energy 
              Object C. 
         
     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. 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 27] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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 
        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 

      
      
     Claise et al.           Expires April 18, 2014      [Page 28] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        the information model, but the rules and logical ability to 
        aggregate each attribute is out of scope for this document. 
         
        In general: 
           o  A Device SHOULD NOT establish an Aggregation 
              Relationship with Components contained on the same 
              device. 
           o  A Device SHOULD NOT establish an Aggregation 
              Relationship with the Power Interfaces contained on 
              the same device. 
           o  A Device SHOULD NOT establish an Aggregation 
              Relationship with an EnMS.  
           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. 
         

      
      
     Claise et al.           Expires April 18, 2014      [Page 29] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        EDITORs NOTE:  The working group is converging on the use 
        of code/pseudo-code rather than ascii UML diagram. If so we 
        would have to define primitive type as reference (eg. Int, 
        string, etc)If agreeable we can indicate a BNF syntax in a 
        formal syntax section, use a schema definition from 
        JSON/XML, or use the following table if obvious: 
         
        Syntax 
          
          UML Construct          
          [ISO-IEC-19501-2005] Equivalent Notation 
          -------------------- ------------------------------------ 
          Notes                // Notes 
          Class  
          (Generalization)     CLASS name {member..} 
          Sub-Class   
          (Specialization)     CLASS subclass  
                                     EXTENDS superclass {member..}   
          Class Member  
          (Attribute)          attribute : type  

      
      
     Claise et al.           Expires April 18, 2014      [Page 30] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        Model 
         
        CLASS EnergyObject { 
         
           // identification / classification 
           index        : int 
           identifier   : uuid 
           alternatekey : string 
         
           // context 
           domainName      : string 
           role            : string 
           keywords [0..n] : string 
           importance      : int 
         
           // relationship 
           relationships [0..n] : Relationship 
         
           // measurements  
           nameplate    : Nameplate 
           power     : PowerMeasurement 
           energy    : EnergyMeasurment 
           demand    : DemandMeasurement 
         
           // control 
           powerControl [0..n] : PowerStateSet 
        }  
         
        CLASS 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  
         
        } 
        // EDITOR NOTE: Component could sub-class from Device 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 31] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
      
        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 
        } 
         
        CLASS TimedMeasurement EXTENDS Measurement { 
              startTime  : timestamp 
              value      : Measurement 
              maximum    : Measurement 
        } 
         
        CLASS TimeInterval { 
              value      : long 
              units      : enum { seconds, miliseconds,...} 
        } 
         
        CLASS DemandMeasurement EXTENDS Measurement { 
              intervalLength : TimeInterval 
              interval       : long 
              intervalMode   : enum { periodic, sliding, total } 
      
      
     Claise et al.           Expires April 18, 2014      [Page 32] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
              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    
           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   
      
      
     Claise et al.           Expires April 18, 2014      [Page 33] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
           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. 
        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. 
      
      
     Claise et al.           Expires April 18, 2014      [Page 34] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
        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.  
           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:  
      
      
     Claise et al.           Expires April 18, 2014      [Page 35] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
           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.  
         
         
        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. 
      

      
      
     Claise et al.           Expires April 18, 2014      [Page 36] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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: 
                
           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              +------------+ 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 37] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
     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       |  
                           +---------------+  
                                   |          
                           +---------------+  
                           |     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. 
      
      
     Claise et al.           Expires April 18, 2014      [Page 38] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
         
     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 
        [draft-ietf-ipfix-a9n-08], the aggregation function in the 
        EMAN framework is limited to the summation. 
         
        When aggregation occurs across a set of entities, values to 
        be aggregated may be missing for some entities.  The EMAN 
        framework does not specify how these should be treated, as 
        different implementations may have good reason to take 
        different approaches.  One common treatment is to define 
        the aggregation as missing if any of the constituent 
        elements are missing (useful to be most precise). Another 
        is to treat the missing value as zero (useful to have 
        continuous data streams). 
         
        The specifications of aggregation functions are out of 
        scope of the EMAN framework, but must be clearly specified 
        by the equipment vendor. 
         
     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.  

      
      
     Claise et al.           Expires April 18, 2014      [Page 39] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
           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-2] standard for describing 
              AC measurements.   
           o  The power state definitions are based on the DMTF 
              Power State Profile and ACPI models, with operational 
              state extensions.        
         
     10. Security Considerations 
         
        Regarding the data attributes specified here, some or all 
        may be considered sensitive or vulnerable in some network 
        environments. Reading or writing these attributes without 
        proper protection such as encryption or access 
        authorization may have negative effects on the network 
        capabilities. 
         
     10.1. Security Considerations for SNMP 
         
        Readable objects in MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered 
        sensitive or vulnerable in some network environments.  It 
        is important to control GET and/or NOTIFY access to these 
        objects and possibly to encrypt the values of these objects 
        when sending them over the network via SNMP.   
         
        The support for SET operations in a non-secure environment 
        without proper protection can have a negative effect on 
        network operations. 
         
        For example: 
           o  Unauthorized changes to the Energy Management Domain 
              or business context of a device may result in 
              misreporting or interruption of power. 
           o  Unauthorized changes to a power state may disrupt the 
              power settings of the different devices, and 
              therefore the state of functionality of the 
              respective devices. 
           o  Unauthorized changes to the demand history may 
              disrupt proper accounting of energy usage.  
         
        With respect to data transport, SNMP versions prior to 
        SNMPv3 did not include adequate security.  Even if the 
      
      
     Claise et al.           Expires April 18, 2014      [Page 40] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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. 
         
         
     11. IANA Considerations 
     11.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 
        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. 
         
     11.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 

      
      
     Claise et al.           Expires April 18, 2014      [Page 41] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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. 
         
     11.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. 
         
     11.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 
        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. 
         
     11.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.  
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 42] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
     11.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. 
         
     12. 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 
         
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A 
                  Universally Unique Identifier (UUID) URN 
                  Namespace", RFC 4122, July 2005 
         
        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for 
                  Writing an IANA Considerations Section in RFCs", 
                  RFC 5226, May 2008 
         
        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB 
                  (Version4)", RFC 6933, May 2013 
         
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 
                  between Information Models and Data Models", RFC 
                  3444, January 2003 
         
        [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information 
                  technology, Open Distributed Processing -- 
                  Unified Modeling Language (UML), January 2005 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 43] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
     Informative References 
         
        [RFC2578] McCloghrie, K., Perkins, D., and J. 
                  Schoenwaelder, "Structure of Management 
                  Information Version 2 (SMIv2", RFC 2578, April 
                  1999 
         
         
        [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed., 
                  "Specification of the IP Flow Information Export 
                  (IPFIX) Protocol for the Exchange of IP Traffic 
                  Flow Information ", draft-ietf-ipfix-protocol-
                  rfc5101bis-08, (work in progress), June 2013 
         
        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling 
                  Language for the Network Configuration Protocol 
                  (NETCONF)", RFC 6020, October 2010 
         
        [ACPI] "Advanced Configuration and Power Interface 
                  Specification", http://www.acpi.info/spec30b.htm 
         
        [IEEE1621]  "Standard for User Interface Elements in Power 
                  Control of Electronic Devices Employed in 
                  Office/Consumer Environments", IEEE 1621, 
                  December 2004 
         
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control 
                  Connectivity Discovery", 2005 
         
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management 
                  Information Base extension module for TIA-TR41.4 
                  media endpoint discovery information", July 2005 
         
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 
                  and M. Chandramouli, "Requirements for Energy 
                  Management", draft-ietf-eman-requirements-14, 
                  (work in progress), May 2013 
         
        [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy 
                  Object Contet MIB", draft-ietf-eman-energy-aware-
                  mib-08, (work in progress), April 2013 
         
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., 
                  Dietz, T., and B. Claise, "Power and Energy 
                  Monitoring MIB", draft-ietf-eman-energy-
                  monitoring-mib-05, (work in progress), April 2013 
         

      
      
     Claise et al.           Expires April 18, 2014      [Page 44] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " 
                  Definition of Managed Objects for Battery 
                  Monitoring", draft-ietf-eman-battery-mib-08, 
                  (work in progress), February 2013 
         
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, 
                  "Energy Management (EMAN) Applicability 
                  Statement", draft-ietf-eman-applicability-
                  statement-03, (work in progress), April 2013 
         
        [ITU-T-M-3400] TMN Recommendation on Management Functions 
                  (M.3400), 1997 
         
        [NMF] "Network Management Fundamentals", Alexander Clemm, 
                  ISBN: 1-58720-137-2, 2007 
         
        [TMN] "TMN Management Functions : Performance Management", 
                  ITU-T M.3400 
         
        [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/ 
         
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                  2009 - IEEE Standard for Information technology - 
                  Telecommunications and information exchange 
                  between systems - Local and metropolitan area 
                  networks - Specific requirements - Part 3: 
                  Carrier Sense Multiple Access with Collision 
                  Detection (CSMA/CD) Access Method and Physical 
                  Layer Specifications - Amendment: Data Terminal 
                  Equipment (DTE) -  Power via Media Dependent 
                  Interface (MDI) Enhancements", October 2009 
         
      
      
     Claise et al.           Expires April 18, 2014      [Page 45] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        [DMTF] "Power State Management Profile DMTF  DSP1027  
                  Version 2.0"  December 2009     
                  http://www.dmtf.org/sites/default/files/standards
                  /documents/DSP1027_2.0.0.pdf 
         
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 
                  Management", 2010, Wiley Publishing 
         
        [X.700]  CCITT Recommendation X.700 (1992), Management 
                  framework for Open Systems Interconnection (OSI) 
                  for CCITT applications 
          
        [ASHRAE-201] "ASHRAE Standard Project Committee 201  
                        (SPC 201)Facility Smart Grid Information  
                        Model", http://spc201.ashraepcs.org 
         
        [CHEN] "The Entity-Relationship Model: Toward a Unified 
                  View of Data",  Peter Pin-shan Chen, ACM 
                  Transactions on Database Systems, 1976 
         
        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello, 
                  Roland Saville, Steve Kramling, Cisco Validated 
                  Designs, September 2010, 
                  http://www.cisco.com/en/US/docs/solutions/Enterpr
                  ise/Borderless_Networks/Energy_Management/energyw
                  isedg.html 
         
         
         
     13. 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. 
         
     Authors' Addresses 
      
        John Parello 
        Cisco Systems, Inc. 
        3550 Cisco Way  
        San Jose, California 95134  
        US 
            
      
      
     Claise et al.           Expires April 18, 2014      [Page 46] 
         


     Internet-Draft              EMAN Framework        October 2013 
         
        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 April 18, 2014      [Page 47]