Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7326.
Authors Benoît Claise , John Parello , Brad Schoening , Juergen Quittek
Last updated 2013-07-09
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Awaiting External Review/Resolution of Issues Raised
Document shepherd Eliot Lear
IESG IESG state Became RFC 7326 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Joel Jaeggli
Send notices to (None)
draft-ietf-eman-framework-08
Network Working Group                                  B. Claise 
     Internet-Draft                                        J. Parello 
     Intended Status: Informational               Cisco Systems, Inc. 
     Expires: July 12, 2013                              B. Schoening 
                                                Independent Consultant 
                                                            J. Quittek 
                                                        NEC Europe Ltd 

                                                         July 9, 2013 

                                            

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

     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as  
        "work in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed 
        at http://www.ietf.org/shadow.html  
         
        This Internet-Draft will expire on July, 2013.                     

      

     <Claise, et. Al>         Expires Jul 12 2013          [Page 1] 

     Internet-Draft           <EMAN Framework>        February 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 providing Energy 
        Management for devices and device components within or 
        connected to communication networks.  The framework defines an 
        Energy Management Domain as a set of Energy Objects. Each 
        Energy Object is identified, classified and given context.   
        Energy Objects can be monitored and controlled with respect to 
        Power, Power State, Energy, Demand, Power Attributes, and 
        Battery.  Additionally the framework models relationships and 
        capabilities between Energy Objects.   
         
         
         
         
         
         
      
         
                                            


      
      
     <Claise, et. Al>         Expires August, 2013         [Page 2] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
      
     Table of Contents 
         
        1. Introduction .......................................... 5 
           1.1. Energy Management Documents Overview ............. 6 
        2. Terminology ........................................... 6 
           Device................................................. 7 
           Component.............................................. 7 
           Energy Management...................................... 7 
           Energy Management System (EnMS)........................ 7 
           Power.................................................. 9 
           Demand................................................. 9 
           Power Attributes....................................... 9 
           Power Quality.......................................... 9 
           Electrical Equipment.................................. 10 
           Non-Electrical Equipment (Mechanical Equipment)....... 10 
           Energy Object......................................... 10 
           Energy Monitoring..................................... 10 
           Energy Control........................................ 11 
           Provide Energy........................................ 11 
           Receive Energy........................................ 11 
           Power Interface....................................... 11 
           Energy Management Domain.............................. 11 
           Energy Object Identification.......................... 12 
           Energy Object Context................................. 12 
           Energy Object Relationship............................ 12 
           Aggregation Relationship.............................. 12 
           Metering Relationship................................. 12 
           Power Source Relationship............................. 13 
           Power State........................................... 13 
           Power State Set....................................... 13 
           Nameplate Power....................................... 13 
        3. Concerns Specific to Energy Management ............... 13 
           3.1. Concern #1: Power Supply ........................ 15 
           3.2. Concern #2: Power and Energy Measurement ........ 20 
           3.3. Concern #3: Reporting Sleep and Off States ...... 21 
           3.4. Concern #4: Devices and Components .............. 22 
           3.5. Concern #5: Non-Electrical Equipment ............ 22 
           3.6. Concern #6: Energy Procurement .................. 23 
        4. Energy Management Abstraction ........................ 24 
           4.1 Conceptual Model.................................. 24 
           4.2 Energy Object..................................... 25 
           4.3 Energy Object Attributes.......................... 25 
           4.4 Measurements...................................... 28 
           4.5 Control........................................... 31 
           4.6 Power State Sets Comparison....................... 37 
           4.7 Relationships..................................... 38 
           4.8 Relationship Conventions and Guidelines........... 38 
      
      
     <Claise, et. Al>         Expires August, 2013         [Page 3] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
           4.9 Energy Object Relationship Extensions............. 41 
        5. Energy Management Information Model................... 41 
        6. Example Topologies.................................... 46 
           6.1 Example I: Simple Device with one Source.......... 47 
           6.2 Example II: Multiple Inlets....................... 48 
           6.3 Example III: Multiple Sources..................... 48 
           6.4 Relationships Between Devices..................... 49 
        7. Relationship with Other Standards .................... 54 
        8. Security Considerations .............................. 55 
        9. IANA Considerations .................................. 56 
           9.1 IANA Registration of new Power State Set.......... 56 
           9.2 Updating the Registration......................... 58 
        10. Acknowledgments ..................................... 59 
        11. References .......................................... 59 
           Normative References.................................. 59 
           Informative References................................ 59 
         

      

        OPEN ISSUES: 
        - Are Tracked via Issue Tracker. See 
          https://trac.tools.ietf.org/wg/eman/trac/report/1 
         
                          


      
      
     <Claise, et. Al>         Expires August, 2013         [Page 4] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
         
         
     1. Introduction 

        Network management is often divided into the five main areas 
        defined in the ISO Telecommunications Management Network 
        model: Fault, Configuration, Accounting, Performance, and 
        Security Management (FCAPS) [X.700].  Not covered by this 
        traditional management model is Energy Management, which is 
        rapidly becoming a critical area of concern worldwide, as seen 
        in [ISO50001].  
         
        This document defines an energy management framework for 
        devices within or connected to communication networks.  The 
        devices, or components of these devices (such as router line 
        cards, fans, disks), can then be monitored and controlled.  
        Monitoring includes power, energy, demand, and attributes of 
        power.  Energy control can be performed by setting devices' or 
        components' power state. If a device contains batteries, these 
        can also be monitored and controlled.  
         
        This framework further describes how to identify, classify and 
        provide context for such devices.  While the context 
        information is not specific to Energy Management, some context 
        attributes are specified in the framework, addressing the 
        following use cases: how important is a device in terms of its 
        business impact, how should devices be grouped for reporting 
        and searching, and how should a device role be described.  
        These context attributes help in fault management and impact 
        analysis while controlling the power states.  Guidelines for 
        using context for energy management are described. 
          
        The framework introduces the concept of a power interface that 
        is analogous to a network interface. A power interface is 
        defined as an interconnection among devices where energy can 
        be provided, received, or both.  
      
        The most basic example of Energy Management is a single device 
        reporting information about itself.  In many cases, however, 
        energy is not measured by the device itself, but metered 
        upstream in the power distribution tree.  For example, a power 

        distribution unit (PDU) may measure the energy it supplies to 
        attached devices and report this to an energy management 
        system.  Therefore, devices often have relationships to other 
        devices or components in the power network.  An EnMS generally 
        requires an understanding of the power topology (who provides 
        power to whom), the metering topology (who meters whom), and 

      
      
     <Claise, et. Al>         Expires August, 2013         [Page 5] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
        an understanding of the potential aggregation (does a meter 
        aggregate values from other devices). 
         
        The relationships build on the power interface concept. The 
        different relationships among devices and components, 
        specified in this document, include: power source 
        relationship, metering relationship, and aggregation 
        relationship.  
         
         
       1.1.  Energy Management Documents Overview 

      
        The EMAN standard provides a set of specifications for Energy 
        Management.  This document specifies the framework, per the 
        Energy Management requirements specified in [EMAN-REQ]. 
         
        The applicability statement document [EMAN-AS] includes use 
        cases, a cross-reference between existing standards and the 
        EMAN standard, and a description of this frameworks 
        relationship to other frameworks. 
         
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies  
        objects for addressing Energy Object Identification, 
        classification, context information, and relationships from 
        the point of view of Energy Management. 
                           
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] specifies 
        objects for monitoring of Power, Energy,  Demand, Power 
        Attributes, and Power States. 
         
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines managed 
        objects that provide information on the status of batteries in 
        managed devices. 

      
         
     2.    Terminology 

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
        "OPTIONAL" in this document are to be interpreted as described 
        in RFC 2119 [RFC2119]. 
         
       Some terms have a NOTE that is not part of the 
       definition itself, but accounts for differences 
       between terminologies of different standards 
       organizations or further clarifies the definition. 

      
      
     <Claise, et. Al>         Expires August, 2013         [Page 6] 
         

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

       Energy Management 

          Energy Management is a set of functions for 
          measuring, modeling, planning, and optimizing 
          networks to ensure that the network and network 
          attached devices use energy efficiently and 
          appropriately for the nature of the application 
          and the cost constraints of the organization.  
          Reference: Adapted from [ITU-T-M-3400] 
          NOTES:  
          1. Energy management refers to the activities, 
            methods, procedures and tools that pertain to 

            measuring, modeling, planning, controlling and 
            optimizing the use of energy in networked 
            systems [NMF]. 
          2. Energy Management is a management domain which 
            is congruent to any of the FCAPS areas of 
            management in the ISO/OSI Network Management 
            Model [TMN]. Energy Management for 
            communication networks and attached devices is 
            a subset or part of an organization's greater 
            Energy Management Policies. 
           
       Energy Management System (EnMS) 

          An Energy Management System is a combination of 
          hardware and software used to administer a 
          network with the primary purpose of energy 
          management. 

      
      
     <Claise, et. Al>         Expires August, 2013         [Page 7] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
          Reference: Adapted from [1037C] 
          NOTES: 
          1. An Energy Management System according to 
            [ISO50001] (ISO-EnMS) is a set of systems or 
            procedures upon which organizations can develop 
            and implement an energy policy, set targets, 
            action plans and take into account legal 
            requirements related to energy use.  An ISO-
            EnMS allows organizations to improve energy 
            performance and demonstrate conformity to 
            requirements, standards, and/or legal 
            requirements.   
          2. Example ISO-EnMS:  Company A defines a set of 
            policies and procedures indicating there should 
            exist multiple computerized systems that will 
            poll energy from their meters and pricing / 
            source data from their local utility. Company A 
            specifies that their CFO should collect 
            information and summarize it quarterly to be 
            sent to an accounting firm to produce carbon 
            accounting reporting as required by their local 
            government.  
          3. For the purposes of EMAN, the definition from 

            [1037C] is the preferred meaning of an Energy 
            Management System (EnMS). The definition from 
            [ISO50001] can be referred to as ISO Energy 
            Management System (ISO-EnMS). 
           
       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] 
           

      
      
     <Claise, et. Al>         Expires August, 2013         [Page 8] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
       Power 

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

          The average value of power or a related quantity 
          over a specified interval of time. Note: Demand 
          is expressed in kilowatts, kilovolt-amperes, 
          kilovars, or other suitable units. 
          Reference: [IEEE100]  
          NOTES: 
          1.  For EMAN we use kilowatts.  
      

        Power Attributes 

          Measurements of the electrical current, voltage, phase and 

          frequencies at a given point in an electrical power system. 

          Reference: Adapted from [IEC60050] 

          NOTES:  

          1. Power Attributes are not intended to be judgmental with 
          respect to a reference or technical value and are 
          independent of any usage context. 

        Power Quality  

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

          Reference: [IEC60050] 

          NOTES:  
      
      
     <Claise, et. Al>         Expires August, 2013         [Page 9] 
         

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

         

       Electrical Equipment 

          A general term including materials, fittings, 
          devices, appliances, fixtures, apparatus, 
          machines, etc., used as a part of, or in 
          connection with, an electric installation. 

          Reference: [IEEE100] 
        
       Non-Electrical Equipment (Mechanical Equipment) 

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

          An Energy Object (EO) is an information model 
          (class) that represents a piece of equipment that 
          is part of, or attached to, a communications 
          network which is monitored, controlled, or aids 
          in the management of another device for Energy 
          Management. 
      
           
       Energy Monitoring 

          Energy Monitoring is a part of Energy Management 
          that deals with collecting or reading information 
          from Energy Objects to aid in Energy Management.  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 10] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
             
       Energy Control 

          Energy Control is a part of Energy Management 
          that deals with directing influence over Energy 
          Objects.  
        

       Provide Energy 

          An Energy Object "provides" energy to another Energy Object 
          if there is an energy flow from this Energy Object to the 
          other one. 
           

        Receive Energy 

          An Energy Object "receives" energy from another Energy 
          Object if there is an energy flow from the other Energy 
          Object to this one. 
           

        Power Interface 

           A Power Interface (or simply interface) is an information 
           model (class) that represents the interconnections among 
           devices or components where energy can be provided, 
           received, or both.  
            

        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 Management Domain 

          An Energy Management Domain is a set of Energy Objects that 
          is considered one unit of management.  
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 11] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
           
           
       Energy Object Identification 

          Energy Object Identification is a set of 
          attributes that enable an Energy Object to be 
          universally unique or linked to other systems. 
        
       Energy Object Context 

          Energy Object Context is a set of attributes that 
          allow an Energy Management System to classify an 
          Energy Object within an organization.   
            
       Energy Object Relationship 

          An Energy Object Relationship is an association among 
          Energy Objects. 
           
          NOTES 
          1. Relationships can be named and could include 
          Aggregation, Metering, and Power Source. 
           
          Reference: Adapted from [CHEN] 
         

        Aggregation Relationship 

          An Aggregation Relationship is an Energy Object 
          Relationship where one Energy Object aggregates Energy 
          Management information of one or more other Energy Objects. 
          The aggregating Energy Object has an Aggregation 
          Relationship with each of the other Energy Objects.   
           
           
        Metering Relationship 

          A Metering Relationship is an Energy Object Relationship 
          where one Energy Object measures power, energy, demand or 
          power attributes of one or more other Energy Objects. The 
          measuring Energy Object has a Metering Relationship with 
          each of the measured objects. 
           
         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 12] 
         

     Internet-Draft           <EMAN Framework>        February 2013 
      
        Power Source Relationship 

          A Power Source Relationship is an Energy Object 
          Relationship where one Energy Object provides power to one 
          or more Energy Objects. These Energy Objects are referred 

          to as having a Power Source Relationship.   
           
      
       Power State 

          A Power State is a condition or mode of a device 
          that broadly characterizes its capabilities, 
          power consumption, and responsiveness to input. 
           
          Reference: Adapted from [IEEE1621]   
           
           
       Power State Set 

          A Power State Set is a collection of Power States 
          that comprises a named or logical control 
          grouping.   
        
           
       Nameplate Power 

          The Nameplate Power is the nominal Power of a 
          device as specified by the device manufacturer.  
        
      
      
     3.    Concerns Specific to Energy Management 

        With Energy Management, there exists a wide variety of devices 
        that may be contained in the same deployments as a 
        communication network but comprise a separate facility, home, 
        or power distribution network.   

        Target devices for Energy Management are all Energy Objects 
        that can be monitored or controlled (directly or indirectly) 
        by an Energy Management System (EnMS) using the Internet 
        protocol. These target devices include:  
            - Simple electrical appliances and fixtures 
            - Hosts, such as a PC, a server, or a printer 
            - Switches, routers, base stations, and other network 
        equipment and middle boxes 
            - Components within devices, such as a battery inside a 
        PC, a line card inside a switch, etc. 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 13] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
            - Power over Ethernet (PoE) endpoints 
            - Power Distribution Units (PDU)  
            - Protocol gateway devices for Building Management Systems 
        (BMS) 
            - Electrical meters 
            - Sensor controllers with subtended sensors 
      
        There may also exist varying protocols deployed among these 
        power distribution and communication networks.  
         
        An Energy Management framework should also apply to these 
        types of separate networks as they connect to and interact 
        with a communications network.  
         
        This section explains special issues of Energy Management 
        concerning power supply, Power and Energy metering, and the 
        reporting of Power States. 

        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. 
         
        To illustrate this point, consider the basic scenario where a 
        single powered device receives Energy and reports energy-
        related information about itself to an Energy Management 
        System (EnMS) (see Figure 1). 

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

                  Figure 1: Basic energy management scenario 
         

        The powered device may have local energy control mechanisms, 
        such as putting itself into a sleep mode when appropriate, and 
        it may receive energy control commands for similar purposes 
        from the EnMS. Information reported from a powered device to 
        the EnMS includes at least the Power State of the powered 
        device (on, sleep, off, etc.). 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 14] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        This and similar cases are well understood and common in 
        Energy Management.  They can be handled with well-established 
        and standardized management procedures.  The only missing 
        components today are standardized information and data models 
        for reporting and configuration, such as energy-specific MIB 
        modules [RFC2578] and YANG modules [RFC6020]. 

        Energy Management presents no new issues for fault, 
        configuration, performance or security management. We can re-
        use standard network management procedures to handle these 
        issues in an EnMS. For example, with faults we can re-use rmon 
        or SNMP traps. For security, existing means like SNMPv3 
        security can be used. 

        But when there are issues specific to Energy Management then 
        this framework adds them. The following subsections address 
        these issues and illustrate them by extending the basic 
        scenario in Figure 1. 

         

       3.1.  Concern #1: Power Supply 

        Most powered devices that are managed by an EnMS receive 
        external power. 
         
        While many devices receive Power from unmanaged supply 
        systems, the number of manageable power supply devices is 
        increasing. 
         
        In datacenters, for example, many Power Distribution Units 
        (PDUs) allow the EnMS to switch power individually for each 
        socket and also to measure the provided Power.  This is very 
        different from many other network management tasks. In this 
        and similar cases, switching the power supply for a powered 
        device or monitoring its power is not done by communicating 
        with the actual powered device itself, but with an external 
        device (in this case, the PDU). 
         
        Consequently, a standard for Energy Management must not only 
        cover the powered devices that provide services for users, but 
        also the power supply devices (which are themselves powered 
        devices) that monitor or control the power supply for other 
        powered devices. 
         
        A simple device such as a light bulb can be switched on or off 
        only by switching its power supply.  More complex devices may 
        have the ability to switch off themselves or to bring 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 15] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        themselves to states in which they consume very little power.  
        For these devices as well, it is desirable to monitor and 
        control their power supply. 
         
        This extends the basic scenario from Figure 1 by adding a 
        power supply device (see Figure 2). 
         

                    +-----------------------------------------+ 
                    |         energy management system        | 
                    +-----------------------------------------+ 
                          ^  ^                       ^  ^ 
               monitoring |  | control    monitoring |  | control 
                          v  v                       v  v 
                    +--------------+        +-----------------+ 
                    | power supply |########| powered device  | 
                    +--------------+        +-----------------+ 

                            ######## power supply line 

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

        3.1.1 Identification of Power Supply and Powered Devices 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 16] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        When a power supply device controls or monitors power supply 
        at one of its power outlets, the effect on other devices is 
        not always clear without knowledge about wiring of power 
        lines.  The same holds for monitoring.  The power supplying 
        device can report that a particular socket is powered, and it 
        may even be able to measure power and conclude that there is a 
        consumer drawing power at that socket, but it may not know 
        which powered device(s)receives the provided power. 
         
        In many cases it is obvious which other device is supplied by 
        a certain outlet, but this always requires additional 
        (reliable) information about power line wiring.  Without 
        knowing which device(s) are powered via a certain outlet, 
        monitoring data are of limited value and the consequences of 
        switching power on or off may be hard to predict. 
         
        Even in well-organized operations, powered devices' power 
        cords can be plugged into the wrong socket, or wiring plans 
        changed without updating the EnMS accordingly. 
         
        For reliable monitoring and control of power supply devices, 
        additional information is needed to identify the device(s) 
        that receive power provided at a particular monitored and 
        controlled socket. 
         
        This problem also occurs in the opposite direction.  If power 
        supply control or monitoring for a certain device is needed, 
        then the supplying power supply device has to be identified. 
         
        To conduct Energy Management tasks for both power supply 
        devices and other powered devices, sufficiently unique 
        identities are needed, and knowledge of their power supply 
        relationship is required. 
         

        3.1.2 Multiple Devices Supplied by a Single Power Line 

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

                      +---------------------------------------+ 
                      |       energy management system        | 
                      +---------------------------------------+ 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 17] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
                         ^  ^                       ^  ^ 
              monitoring |  | control    monitoring |  | control 
                         v  v                       v  v 
                      +--------+        +------------------+ 
                      | power  |########| powered device 1 | 
                      | supply |   #    +------------------+-+ 
                      +--------+   #######| powered device 2 | 
                                     #    +------------------+-+ 
                                     #######| powered device 3 | 
                                            +------------------+ 

                 Figure 3: Multiple Powered Devices Supplied  
                             by Single Power Line 
         

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

        3.1.3 Multiple Power Supply for a Single Powered Device 

        The third problem arises from the fact that there are devices 
        with multiple power supplies.  Some have this for redundancy 
        of power supply, some for redundancy of internal power 
        converters (for example, from AC mains power to DC internal 
        power), and some because the capacity of a single supply line 
        is insufficient. 
         
                   +----------------------------------------------+ 
                   |          energy management system            | 
                   +----------------------------------------------+ 
                       ^  ^              ^  ^              ^  ^ 
                  mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl. 
                       v  v              v  v              v  v 
                   +----------+      +----------+      +----------+ 
                   | power    |######| powered  |######| power    | 
                   | supply 1 |######| device   |      | supply 2 | 
                   +----------+      +----------+      +----------+ 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 18] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
          Figure 4: Multiple Power Supply for Single Powered Device 
         
        The example in Figure 4 does not necessarily show a real world 
        scenario, but it shows the two cases to consider: 
           o  Multiple power supply lines between a single power  
              supply device and a powered device 
           o  Different power supply devices supplying a single  
              powered device 
        In any such case, there may be a need to identify the 
        supplying power supply device individually for each power 
        inlet of a powered device. 
         
        Without this information, monitoring and control of power 
        supply for the powered device may be limited. 
         
         

        3.1.4 Bidirectional Power Interfaces 

        Some power technologies (mostly low power DC) allow power to 
        be delivered bi-directionally.  For example, energy stored in 
        batteries on one device can be delivered back to a power hub, 
        which redirects the power to another device.  In this 
        situation, the interface can function as both an inlet and 
        outlet at different times.   
         
        A Power Interface can model a power inlet or a power outlet, 
        depending on the conditions.  Information of interest for 
        Power Interfaces includes the power direction, as well as the 
        energy received, provided, and the net result. 
         

        3.1.5 Relevance of Power Supply Concerns 

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

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 19] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        In addition, AC power lines support supplying multiple powered 
        devices with a single line, and are commonly used in this 
        fashion. 
         
         

        3.1.6 Remote Power Supply Control 

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

       3.2.  Concern #2: Power and Energy Measurement 

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

        3.2.1 Local Estimates 

        One solution to this problem is for the powered device to 
        estimate its own Power and consumed Energy.  For many Energy 
        Management tasks, getting an estimate is much better than not 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 20] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        getting any information at all.  Estimates can be based on 
        actual measured activity level of a device or it can just 
        depend on the power state (on, sleep, off, etc.). 

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

         

        3.2.2 Management System Estimates 

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

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

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 21] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
       3.4.  Concern #4: Devices and Components 

        While the typical focus of energy management is entire powered 
        devices, sometimes it is desirable to manage individual 
        components of devices, such as line cards, fans, disks, etc.   
         
        This framework uses a much simpler model for components than 
        for entire devices.  The concept of Power Interfaces is not 
        used between a device and its contained components.  Reporting 
        of energy-related quantities for individual components is 
        limited to the most important ones.  Simplifications for 
        components in this framework include 
           o  identifying components like devices but without   
              distinct context information, 
           o  reporting a containment relationship to the containing  
              device, 
           o  inheriting all context information from the containing  
              device, 
           o  not modeling power interfaces and power lines between  
              a component and its containing device or other  
              components, and 
           o  only reporting real power and energy values for  
              components. 
            
         
        Power state monitoring and control are not simplified.  These 
        have the same functionality for devices and components.  In 
        rare cases where there is a need to model components of a 
        device in more detail, components of a device can be modeled 
        as individual devices.  Then all considerations for devices 
        also apply to these components.  This model has a higher 
        overhead and should be used only when needed. If used, it is 
        not necessarily visible whether a set of components belongs to 
        a single device or not, but for energy management purposes 
        this might not be of high relevance. 
         
         
         
       3.5.  Concern #5: Non-Electrical Equipment 

        The primary focus of this framework is the management of 
        Electrical Equipment.  Some Non-Electrical Equipment may be 
        connected to communication networks and could have their 
        energy managed if normalized to the electrical units for power 
        and energy. 
         
        Some examples of Non-Electrical Equipment that may be 
        connected to a communication network are: 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 22] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         
        1) A controller for compressed air.  The controller is 
          electrical only for its network connection.  The controller 
          is fueled by natural gas and produces compressed air.  The 
          energy transferred via compressed air is distributed to 
          devices on a factory floor via a Power Interface which 
          consists of tools (drills, screwdrivers, assembly line 
          conveyor belts). The energy measured is non-electrical 
          (compressed air). 
            
        2) A controller for steam. The controller is electrical for its 
          network attachment but it burns tallow and produces steam to 
          subtended boilers. The energy is non-electrical (steam). 
           
        3) A controller or regulator for gas. The controller is 
          electrical for its network attachment but it has physical 
          non-electrical components for control. The energy is non-
          electrical (BTU). 
           
         
       3.6.  Concern #6: Energy Procurement 

        While an EnMS may be a central point for corporate reporting, 
        cost, environmental impact, and regulatory compliance, Energy 
        Management in this framework excludes Energy procurement and 
        the environmental impact of energy use.  As such the framework 
        does not include: 
        - Cost in currency or environmental units of manufacturing an 
        Energy Object 
        - Embedded carbon or environmental equivalences of an Energy 
        Object 
        - Cost in currency or environmental impact to dismantle or 
        recycle an Energy Object 
        - Supply chain analysis of energy sources for Energy Object 
        deployment 
        - Conversion of the usage or production of energy to units 
        expressed from the source of that energy (such as the 
        greenhouse gas emissions associated with 1000kW from a diesel 
        source) 
         
                          

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 23] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         
     4. Energy Management Abstraction 

        Network management is often divided into the five main areas 
        defined in the ISO Telecommunications Management Network 
        model: Fault, Configuration, Accounting, Performance, and 
        Security Management (FCAPS) [X.700].  This traditional 
        management model does not cover Energy Management. 
         
        This section describes a conceptual model of information that 
        can be used for Energy Management. The classes and categories 
        of attributes in the model are described with rationale for 
        each. A UML description of the model can be found in Section 
        5. 

        4.1 Conceptual Model 

        To address Energy Management this specification describes an 
        information model that can exist along with Network Management 
        while addressing issues specific to Energy Management (Section 
        3).  

        An information model for Energy Management will need to 
        describe a means to report information, provide control, and 
        model the interconnections among physical entities.  

        Therefore, this section proposes a similar conceptual model 
        for physical entities to that used in Network Management: 
        devices, components, and interfaces. This section then defines 
        the additional attributes specific to Energy Management for 
        those entities that are not available in existing Network 
        Management models. 

        For modeling the physical entities this section describes 
        three classes:  a Device, a Component, and a Power Interface. 
        These classes are sub-types of an abstract Energy Object 
        class. 

        For modeling the additional attributes, this section describes 
        attributes of an Energy Object for: identification, 
        classification, context, control, power and energy. 

        Since the interconnections between physical entities for 
        Energy Management may have no relation to the interconnections 
        for Network Management the Energy Object classes contain a 
        separate Relationships class as an attribute to model these 
        types of interconnections.  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 24] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        The remainder of this section describes the conceptual model 
        of the classes and categories of attributes in the information 
        model. The exact definitions of the classes and attributes are 
        specified using UML in Section 5.  

        4.2 Energy Object 

        An Energy Object is an abstract class that contains the base 
        attributes for Energy Management.  There are three types of 
        Energy Objects: Device, Component and Power Interface. 

        4.2.1 Device Class 

        The Device Class is a sub-class of Energy Object that 
        represents a physical piece of equipment. 

        A Device Class instance may represent a device that is a 
        consumer, producer, or meter of energy.  

        A Device Class instance may represent a physical device that 
        contains other components. 

        4.2.2 Component Class 

        The Component Class is a sub-class of Energy Object that 
        represents a part of a physical piece of equipment. 

        4.2.3 Power Interface Class 

        The power interface class is a sub-class of Energy Object that 
        represents the interconnection among devices and components. 

        There are some similarities between Power Interfaces and 
        network interfaces.  A network interface can be set to 
        different states, such as sending or receiving data on an 
        attached line.  Similarly, a Power Interface can be receiving 
        or providing power. 

        Physically, a Power Interface instance can represent an AC 
        power socket, an AC power cord attached to a device, or an 
        8P8C (RJ45) PoE socket, etc. 

        4.3 Energy Object Attributes 

        This section describes categories of attributes for an Energy 
        Object. Section 5 contains the specific UML definitions of the 
        modeled attribute. 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 25] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        4.3.1 Identification 

        A Universal Unique Identifier (UUID) [RFC4122] is used to 
        uniquely and persistently identify an Energy Object. Ideally 
        the UUID is used to distinguish the Energy Object within the 
        EnMS. 

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

        Additionally an alternate key is provided to allow an Energy 
        Object to be optionally linked with models in different 
        systems. 

        4.3.2 Context in General 

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

        4.3.3 Context: Importance 

        An Energy Object can provide an importance value in the range 
        of 1 to 100 to help rank a device's use or relative value to 
        the site.  The importance range is from 1 (least important) to 
        100 (most important).  The default importance value is 1.   

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

        Although EnMS and administrators can establish their own 
        ranking, the following example is a broad recommendation for 
        commercial deployments [CISCO-EW]: 

        .  90 to 100 Emergency response  

        .  80 to 90 Executive or business-critical  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 26] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        .  70 to 79 General or Average  

        .  60 to 69 Staff or support  

        .  40 to 59 Public or guest  

        .  1  to 39 Decorative or hospitality 

         

        4.3.4 Context: Keywords 

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

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

         

        4.3.5 Context: Role 

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

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

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

        Example Services by Line of Business: 

           Line of Business     Service 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 27] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
           Education            Student, Faculty, Administration,  

                                Athletic 

           Finance              Trader, Teller, Fulfillment 

           Manufacturing        Assembly, Control, Shipping 

           Retail               Advertising, Cashier 

           Support              Helpdesk, Management 

           Medical              Patient, Administration, Billing 

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

         

        4.3.6 Context: Domain 

        An Energy Object contains a string to indicate membership in 
        an Energy Management Domain. An Energy Management Domain can 
        be any collection of devices in a deployment, but it is 
        recommended to map 1:1 with a metered or sub-metered portion 
        of the site.  

        In building management, a meter refers to the meter provided 
        by the utility used for billing and measuring power to an 
        entire building or 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 readings from sub 
        portions of a building. 

        A meter is a type Energy Object and any Energy Object can 
        perform metering. 

        An Energy Object should be a member of a single Energy 
        Management Domain therefore one field is provided.  The Energy 
        Management Domain may be configured on an Energy Object. 

        4.4 Measurements 

        An Energy Object contains attributes to describe power, energy 
        and demand measurements. 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 28] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        For the purposes of this framework, energy will be limited to 
        electrical energy in watt-hours.  Other forms of Energy 
        Objects that use or produce non-electrical energy may be 
        modeled as an Energy Object but must provide information 
        converted to and expressed in watt-hours. 

        An analogy for understanding power versus energy measurements 
        can be made to speed and distance in automobiles. Just as a 
        speedometer indicates the rate of change of distance (speed), 
        a power meter indicates the rate of transfer of energy. The 
        odometer in an automobile measures the cumulative distance 
        traveled and an energy meter 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 device power 
        over multiple time intervals for a given energy value. 

        4.4.1 Measurements: Power  

        Each Energy Object contains a Nameplate Power attribute that 
        describes the nominal power as specified by the manufacturer. 

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

        Each Energy Object will have information that describes  
        present power information, along with how that measurement was 
        obtained or derived (e.g., measured, estimated, or presumed). 

        A power measurement is be qualified with the units, magnitude 
        and direction of power flow, and is be qualified as to the 
        means by which the measurement was made (e.g., Root Mean 
        Square versus Nameplate). 

        In addition, the Energy Object describes how it intends to 
        measure power. This intention can be described as one of the 
        following: consumer, producer,  meter or distributir of power. 
        Given the intent, the EnMS can summarize or analyze the 
        measurement. For example, metered usage reported by a meter 
        and consumption usage reported by a device connected to that 
        meter will naturally measure the same usage. With the two 
        measurements identified by intent, the EnMS can make a proper 
        summarization. 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 29] 
         


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

        In addition to knowing the power and magnitude an Energy 
        Object indicates how the  measurement was obtained:  

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

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

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

        4.4.2 Measurements: Power Attributes 

        Optionally, an Energy Object describes the Power measurements 
        with Power Attribute information reflecting the electrical 
        characteristics of the measurement. These Power Attributes 
        adhere to the IEC 61850 7-2 standard for describing AC 
        measurements. 

        4.4.3 Measurements: Energy 

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

        4.4.4 Measurements: Demand 

        Optionally, an Energy Object will provide demand information 
        over time. Demand measurements can be provided when the Energy 
        Object is capable of measuring actual power  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 30] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        4.5 Control 

        An Energy Object can be controlled by setting it to a specific 
        Power State.  An Energy Object implements at least one set of 
        Power States consisting of at least two states, an on state 
        and an off state. 

        Each Energy Object should indicate the sets of Power States 
        that it implements.  Well known Power States / Sets are 
        registered with IANA.   

        When a device is set to a particular Power State, it may be 
        busy. The device will set the desired Power State and then 
        update the actual Power State when it changes.  There are then 
        two Power State control variables: actual and requested. 

        There are many existing standards for and implementations of 
        Power States.  An Energy Object can support a mixed set of 
        Power States defined in different standards. A basic example 
        is given by the three Power States defined in IEEE1621 
        [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], 
        and PWG define larger numbers of Power States. 

        The semantics of a power state are specified by 

           a) the functionality provided by an Energy Object in this 
        state, 

           b) a limitation of the power that an Energy Object uses in 
        this state, 

           c) a combination of a) and b) 

        The semantics of a Power State should be clearly defined. 
        Limitation (curtailment) of the power used by an Energy Object 
        in a state is be specified by 

           - an absolute power value 

           - a percentage value of power relative to the energy 
        object's nameplate power 

           - an indication of used power relative to another power 
        state. For example: Specify that used power in state A is less 
        than in state B. 

        For supporting Power State management an Energy Object 
        provides statistics on Power States including the time an 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 31] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        Energy Object spent in a certain Power State and the number of 
        times an Energy Object entered a power state. 

        When requesting an Energy Object to enter a Power State an 
        indication of the Power State's name or number can be used. 
        Optionally an absolute or percentage of Nameplate Power can be 
        provided to allow the Energy Object to transition to a nearest 
        or equivalent Power State. 

         

        4.5.1 Power State Sets 

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

        There are currently three Power State Sets advocated:   

        IEEE1621(256) - [IEEE1621] 

        DMTF(512)     - [DMTF] 

        EMAN(768)     - [EMAN-MONITORING-MIB] 

        The respective specific states related to each Power State Set 
        are specified in the following sections. The guidelines for 
        addition of new Power State Sets are specified in the IANA 
        Considerations Section.  

        4.5.2 IEEE1621 Power State Set 

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

         

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

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

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

         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 32] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        4.5.3 DMTF Power State Set 

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

        DMTF power profile extends ACPI power states. The following 
        table provides a mapping between DMTF and ACPI Power State 
        Set: 

         

           --------------------------------------------------- 

           |  DMTF                             | ACPI        | 

           |  Power State                      | Power State | 

           --------------------------------------------------- 

           | Reserved(0)                       |             | 

           --------------------------------------------------- 

           | Reserved(1)                       |             | 

           --------------------------------------------------- 

           | ON (2)                            | G0-S0       | 

           -------------------------------------------------- 

           | Sleep-Light (3)                   | G1-S1 G1-S2 | 

           -------------------------------------------------- 

           | Sleep-Deep (4)                    | G1-S3       | 

           -------------------------------------------------- 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 33] 
         


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

           --------------------------------------------------- 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 34] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         

                Figure 5: DMTF and ACPI Powe State Set Mapping 

        4.5.4 EMAN Power State Set 

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

        An Energy Object may implement fewer or more Power States than 
        a particular EMAN Power State Set specifies. In this case, the 
        Energy Object implementation can determine its own mapping to 
        the predefined EMAN Power States within the EMAN Power State 
        Set. 

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

        In each of the non-operational states (from mechoff(1) to 
        ready(6)), the Power State preceding it is expected to have a 
        lower Power value and a longer delay in returning to an 
        operational state:  

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

                 softoff(2) : Similar to mechoff(1), but some 
        components remain powered or receive trace power so that the 
        Energy Object can be awakened from its off state.  In 
        softoff(2), no context is saved and the device typically 
        requires a complete boot when awakened.  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 35] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
                 hibernate(3): No Energy Object features are 
        available.   The Energy Object may be awakened without 
        requiring a complete boot, but the time for availability is 
        longer than sleep(4). An example for state hibernate(3) is a 
        save to-disk state where DRAM context is not maintained.  
        Typically, energy consumption is zero or close to zero.   

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

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

                 ready(6)    : No Energy Object features are 
        available, except for out-of-band management, such as wake-up 
        mechanisms. This mode is analogous to hot-standby.  The Energy 
        Object can be quickly transitioned into an operational state.  
        For example, processors are not executing, but processor 
        context is maintained.   

                 lowMinus(7) : Indicates some Energy Object features 
        may not be available and the Energy Object has taken measures 
        or selected options to provide less than low(8) usage.  

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

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

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

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

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 36] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
                 high(12)    : Indicates all Energy Object features 
        are available and the Energy Object is consuming the highest 
        power. 

         

        4.6 Power State Sets Comparison 

        A comparison of Power States from different Power State Sets 
        can be seen in the following table: 

         

          IEEE1621  DMTF         ACPI           EMAN      

          Non-operational states 

          off       Off-Hard     G3, S5         MechOff(1) 

          off       Off-Soft     G2, S5         SoftOff(2) 

          sleep     Hibernate    G1, S4         Hibernate(3) 

          sleep     Sleep-Deep   G1, S3         Sleep(4)  

          sleep     Sleep-Light  G1, S2         Standby(5) 

          sleep     Sleep-Light  G1, S1         Ready(6)  

         

          Operational states: 

          on        on           G0, S0, P5     LowMinus(7) 

          on        on           G0, S0, P4     Low(8) 

          on        on           G0, S0, P3     MediumMinus(9) 

          on        on           G0, S0, P2     Medium(10) 

          on        on           G0, S0, P1     HighMinus(11) 

          on        on           G0, S0, P0     High(12) 

         

                     Figure 6: Comparison of Power States 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 37] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         

        4.7 Relationships 

        Two Energy Objects can establish an Energy Object 
        Relationship.  

        Relationships are modeled with a Relationship class that 
        contains the UUID of the participants in the relationship and 
        a description of the type of relationship. The types of 
        relationships are:  power source. metering, and aggregations.  

        The Power Source Relationship gives a view of the wiring 
        topology.  For example: a data center server receiving power 
        from two specific Power Interfaces from two different PDUs.  

        Note: A power source relationship may or may not change as the 
        direction of power changes between two Energy Objects. The 
        relationship may remain to indicate the change of power 
        direction was unintended or an error condition.  

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

        The Aggregation Relationship gives a model of devices that may 
        aggregate (sum, average, etc) values for other devices.  The 
        Aggregation Relationship is slightly different compared to the 
        other relationships as this refers more to a management 
        function. 

        In some situations, it is not possible to discover the Energy 
        Object Relationships, and they must be set by an EnMS or 
        administrator.  Given that relationships can be assigned 
        manually, the following sections describes guidelines for use. 

        4.8 Energy Object Relationship Conventions and Guidelines 

        This Energy Management framework does not impose many "MUST" 
        rules related to Energy Object Relationships. There are always 
        corner cases that could be excluded with too strict 
        specifications of relationships. However, this Energy 
        Management framework proposes a series of guidelines, 
        indicated with "SHOULD" and "MAY". 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 38] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        4.8.1 Guidelines: Power Source 

        Power Source relationships are intended to identify the 
        connections between Power Interfaces. This is analogous to a 
        Layer 2 connection in networking devices (a "one-hop 
        connection"). 

        The preferred modeling would be for Power Interfaces to 
        participate in Power Source Relationships.  

        It may happen that some Energy Objects may not have the 
        capability to model Power Interfaces.  Therefore, it may 
        happen that a Power Source Relationship is 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 on the 
        same Device. 

        -  An Energy Object SHOULD NOT establish a Power Source 
        Relationship with a Component.  

        -  A Power Source Relationship SHOULD be established with 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. 

        -  Transitive Power Source relationships SHOULD NOT be 
        established.  For example, if an Energy Object A has a Power 
        Source Relationship "Poweredby" with the Energy Object B, and 
        if the Energy Object B has a Power Source Relationship 
        "Poweredby" with the Energy Object C, then the Energy Object A 
        SHOULD NOT have a Power Source Relationship "Poweredby" with 
        the Energy Object C. 

         

        4.8.2 Guidelines: Metering Relationship 

         
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 39] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        Metering Relationships are intended to show when one Device is 
        measuring the power or energy at a point in a power 
        distribution system. Since one point of a power distribution 
        system may cover many Devices with a complex wiring topology, 
        this relationship type can be seen as an arbitrary set. 

        Devices may include metering hardware for components and Power 
        Interfaces or for the entire Device. For example, some PDUs 
        may have the ability to measure Power for each Power Interface 
        (metered by outlet). Others may be able to control power at 
        each Power Interface but can only measure Power at the Power 
        Inlet and a total for all Power Interfaces (metered by 
        device).       

        In such cases a Device SHOULD be modeled as an Energy Object 
        that meters all of its Power Outlets and each Power Outlet MAY 
        be metered by the Energy Object representing the Device. 

        -  A Metering Relationship MAY be established with any other 
        Energy Object, Component, or Power Interface. 

        -  Transitive Metering relationships MAY be used. 

        -  When there is a series of meters for one Energy Object, the 
        Energy Object MAY establish a Metering relationship with one 
        or more of the meters.   

         

        4.8.3 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. 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 40] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        Aggregation SHOULD be used for power and energy. It MAY be 
        used for aggregation of other values from the information 
        model, but the rules and logical ability to aggregate each 
        attribute is out of scope for this document. 

        -  A Device SHOULD NOT establish an Aggregation Relationship 
        with a Component. 

        -  A Device SHOULD NOT establish an Aggregation Relationship 
        with the Power Interfaces contained on the same device. 

        -  A Device SHOULD NOT establish an Aggregation Relationship 
        with an EnMS.  

        -  Aggregators SHOULD log or provide notification in the case 
        of errors or missing values while performing aggregation. 

        4.9 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, a Power 
        Distribution Unit (PDU) that allows physical entities like 
        outlets to be "ganged" together as a logical entity for 
        simplified management purposes, could be modeled with an 
        extension called a "gang relationship", whose semantics would 
        specify the Energy Objects' grouping. 

     5. Energy Management Information Model 

        The following basic UML represents an information model 
        expression of the concepts in this framework.  This 
        information model, provided as a reference for implementers, 
        is represented as a MIB in the different related IETF Energy 
        Monitoring documents.  However, other programming 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. 
         
        The notation use here is shorthand UML with lowercase types 
        considered platform or atomic types (i.e., int, string, 
        collection). Uppercase types denote classes described further.  
        Collections and cardinality are expressed via qualifier 
        notation.  Attributes labeled static are considered class 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 41] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        variables and global to the class.  Arrows indicate 
        inheritance. Algorithms for class variable initialization, 
        constructors, or destructors are not shown. Attributes and 
        structures are considered readable and writeable unless 
        prefixed by a dash (-) that indicates read-only. 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 42] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
      
        EDITOR's NOTE:  Pseudo-code used until consensus then UML 
        diagram will be substituted 
         
        class EnergyObject { 
         
           // identification / classification 
           index        : int 
           identifier   : uuid 
           alternatekey : string 
         
           // context 
           domainName      : string 
           role            : string 
           keywords [0..n] : string 
           importance      : int 
         
           // relationship 
         
           relationships [0..n] : Relationship 
         
           // measurements  
           nameplate    : Nameplate 
           power     : PowerMeasurement 
           energy    : EnergyMeasurment 
           demand    : DemandMeasurement 
         
           // control 
           powerControl [0..n] : PowerStateSet 
         
        }  
         
        class Device extends EnergyObject { 
              eocategory   : enum { producer, consumer, meter, 
        distributor }  
        } 
         
        class Component extends EnergyObject 
              eocategory   : enum { producer, consumer, meter, 
        distributor }  
        } 
         
        classInterface extends EnergyObject{ 
              eoIfType : enum ( inlet, outlet, both} 
        } 
         
         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 43] 
         


     Internet-Draft           <EMAN Framework>        February 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, trusted, assumed }  
              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   
        } 
         
         
        class TimedMeasurement extends Measurement { 
              startTime  : timestamp 
              value      : Measurement 
              maximum    : Measurement 
        } 
         
         
        class TimeInterval { 
              value      : long 
              units      : enum { seconds, miliseconds,...} 
        } 
         
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 44] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         
        class DemandMeasurement extends Measurement { 
              intervalLength : TimeInterval 
              interval       : long 
              intervalMode   : enum { periodic, sliding, total } 
              intervalWindow : TimeInterval 
              sampleRate     : TimeInterval 
              status         : enum { active, inactive } 
              measurements[0..n] : TimedMeasurements 
        } 
         
         
        class PowerStateSet { 
              powerSetIdentifier : int   
              name               : string 
              powerStates [0..n] : PowerState  
              operState          : int 
              adminState         : int 
              reason             : string 
              configuredTime     : timestamp 
        } 
         
         
        class PowerState { 
              powerStateIdentifier  : int 
              name             : string 
              cardinality      : int 
              maximumPower     : PowerMeasurement 
              totalTimeInState : time 
              entryCount       : long 
        } 
         
        class PowerAttribute { 
         
          // container for attributes 
               acQuality      : ACQuality 
         
        } 
         
         
        class ACQuality { 
          acConfiguration : enum {SNGL, DEL,WYE}  
          avgVoltage   : long    
          avgCurrent   : long  
          frequency    : long   
          unitMultiplier  : int  
          accuracy       : int   
          totalActivePower   : long   
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 45] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
          totalReactivePower : long  
          totalApparentPower : long   
          totalPowerFactor : long 
          phases [0..2]  : ACPhase  
         
          // Could have abstract class Phase to be clear it's ACPhase 
        or one of the subclasses               
         
        } 
         
        class ACPhase { 
          phaseIndex : long  
          avgCurrent : long  
          activePower : long   
          reactivePower : long   
          apparentPower : long   
          powerFactor : long  
        } 
         
        class DelPhase extends ACPhase {                 
          phaseToNextPhaseVoltage  : long   
          thdVoltage : long                   
          thdCurrent : long 
        } 
         
         
        class WYEPhase extends ACPhase { 
          phaseToNeutralVoltage : long   
          thdCurrent : long              
          thdVoltage : long              
        } 
         
         

                 Figure 7: Information Model UML Representation 
            
      

     6. Example Topologies 

        In this section we give examples of how to use the Energy 
        Management framework relationships to model topologies.  In 
        each example we show how it can be applied when Devices have 
        the capability to model Power Interfaces.  We also show in 
        each example how the framework can be applied when devices 
        cannot support Power Interfaces but only monitor information 
        or control the Device as a whole. For instance, a PDU may only 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 46] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        be able to measure power and energy for the entire unit 
        without the ability to distinguish among the inlets or outlet. 
      
        Together, these examples show how the framework can be adapted 
        for Devices with different capabilities (typically hardware) 
        for Energy Management. 
         
        Given for all Examples:  
         
        Device W: A computer with one power supply. Power interface 1 
        is an inlet for Device W. 
         
        Device X: A computer with two power supplies. Power interface 
        1 and power interface 2 are both inlets for Device X. 
           
        Device Y: A PDU with multiple Power Interfaces numbered 0..10. 
        Power interface 0 is an inlet and power interface 1..10 are 
        outlets. 
      
        Device Z: A PDU with multiple Power Interfaces numbered 0..10. 
        Power interface 0 is an inlet and power interface 1..10 are 
        outlets. 
         
         
        6.1 Example I: Simple Device with one Source 

         
        Topology:  
          Device W inlet 1 is plugged into Device Y outlet 8. 
                   
        With Power Interfaces: 
           
          Device W has an Energy Object representing the computer 
          itself as well as one Power Interface defined as an inlet.  
           
          Device Y would have an Energy Object representing the PDU 
          itself (the Device), with a Power Interface 0 defined as an 
          inlet and Power Interfaces 1..10 defined as outlets.  
        
          The interfaces of the devices would have a Power Source 
          Relationship such that: 
          Device W inlet 1 is powered by Device Y outlet 8. 
         
        Without Power Interfaces: 
                
          Device W has an Energy Object representing the computer.  
          Device Y would have an Energy Object representing the PDU.  
           
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 47] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
          The devices would have a Power Source Relationship such 
          that:  
          Device W is powered by Device Y. 
           
         
        6.2 Example II: Multiple Inlets 

         
        Topology:  
          Device X inlet 1 is plugged into Device Y outlet 8. 
          Device X inlet 2 is plugged into Device Y outlet 9. 
         
        With Power Interfaces: 
      
          Device X has an Energy Object representing the computer 
          itself. It contains two Power Interfaces defined as inlets.  
           
          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. 
         
        Without Power Interfaces: 
                
          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. 
           
           
        6.3 Example III: Multiple Sources 

         
        Topology:  
          Device X inlet 1 is plugged into Device Y outlet 8. 
          Device X inlet 2 is plugged into Device Z outlet 9. 
         
        With Power Interfaces: 
      
          Device X has an Energy Object representing the computer 
          itself. It contains two Power Interface defined as inlets.  
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 48] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
           
          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.  
        
          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. 
         
        Without Power Interfaces: 
                
          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. 
         
         
         
        6.4 Relationships Between Devices 

        6.4.1 Power Source Topology 

        As described in Section 4, the power source(s) of a device is 
        important for energy management.  The Energy Management 
        reference model addresses this by a Power Source Relationship.  
        This is a relationship among devices providing energy and 
        devices receiving energy. 

        A simple example is a PoE PSE, such as an Ethernet switch 
        providing power to a PoE PD, such as a desktop phone.  Here 
        the switch provides energy and the phone receives energy.  
        This relationship can be seen in the figure below. 

              +----------+   power source  +---------+ 

              |  switch  | <-------------- |  phone  | 

              +----------+                 +---------+ 

        Figure 8: Simple Power Source  
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 49] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         

        A single power provider can act as power source for multiple 
        power receivers.  An example is a power distribution unit 
        (PDU) providing AC power for multiple switches. 

              +-------+   power source  +----------+ 

              |  PDU  | <----------+--- | switch 1 | 

              +-------+            |    +----------+ 

                                   | 

                                   |    +----------+ 

                                   +--- | switch 2 | 

                                   |    +----------+ 

                                   | 

                                   |    +----------+ 

                                   +--- | switch 3 | 

                                        +----------+ 

        Figure 10: Multiple Power Source  

                            

        This level of modeling is sufficient if there is no need to 
        distinguish in monitoring and control between the individual 
        receivers at the switch. 

        However, if there is a need to monitor or control power supply 
        for individual receivers at the power provider, then a more 
        detailed level of modeling is needed. 

        Devices receive or provide energy at power interfaces 
        connecting them to a transmission medium.  The Power Source 
        relationship can be used between power interfaces at the power 
        provider side as well as at the power receiver side.  Figure 9 
        shows a power-providing device with one power interface (PI) 
        per connected receiving device. 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 50] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
              +-------+------+   power source  +----------+ 
              |       | PI 1 | <-------------- | switch 1 | 
              |       +------+                 +----------+ 
              |       |     
              |       +------+   power source  +----------+ 
              |  PDU  | PI 2 | <-------------- | switch 2 | 
              |       +------+                 +----------+ 
              |       |     
              |       +------+   power source  +----------+ 
              |       | PI 3 | <-------------- | switch 3 | 
              +-------+------+                 +----------+ 

        Figure 11: Power Source with Power interfaces 

        When required for consistency, Power interfaces may also be 
        modeled at the receiving device, as shown in Figure 10. 

              +-------+------+   power source  +----+----------+ 
              |       | PI 1 | <-------------- | PI | switch 1 | 
              |       +------+                 +----+----------+ 
              |       |     
              |       +------+   power source  +----+----------+ 
              |  PDU  | PI 2 | <-------------- | PI | switch 2 | 
              |       +------+                 +----+----------+ 
              |       |     
              |       +------+   power source  +----+----------+ 
              |       | PI 3 | <-------------- | PI | switch 3 | 
              +-------+------+                 +----+----------+ 

        Figure 12: Power Interfaces at Receiving Device 

         

        Power Source relationships are between devices and their 
        interfaces.  They are not transitive.  In the examples below 
        there is a PDU powering a switch powering a phone. 
         

              +-------+   power   +--------+   power   +---------+ 
              |  PDU  | <-------- | switch | <-------- |  phone  | 
              +-------+   source  +--------+   source  +---------+ 

        Figure 13: Power Source Non-Transitive  

         

        Power Source Relationships are between the PDU and the switch 
        and between the switch and the phone.  Transitively, there 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 51] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        exists a Power Source Relationship between the PDU and the 
        phone.  . 

              +-------+   power   +--------+   power   +---------+ 
              |  PDU  | <-------- | switch | <-------- |  phone  | 
              +-------+   source  +--------+   source  +---------+ 
                  ^                                          | 
                  |              power source                | 
                  +------------------------------------------+ 

        Figure 14: Power Source Transitive  

         

        6.4.2 Metering Topology 

        Case 1: Metering between two devices 

        The metering topology between two devices is closely related 
        to the power source topology.  It is based on the assumption 
        that in many cases the power provided and the power received 
        is the same for both peers of a power source relationship.  
        Then power measured at one end can be taken as the actual 
        power value at the other end.  Obviously, the same applies to 
        energy at both ends. 

        We define in this case a Metering Relationship between two 
        devices or power interfaces of devices that have a power 
        source relationship.  Power and energy values measured at one 
        peer of the power source relationship are reported for the 
        other peer as well. 

        The Metering Relationship is independent of the direction of 
        the Power Source Relationship.  The more common case is that 
        values measured at the power provider are reported for the 
        power receiver, but also the reverse case is possible with 
        values measured at the power receiver being reported for the 
        power provider. 

                                Power                Power 
           +-----+----------+   Source  +--------+   Source +-------+ 
           | PDU |PI + meter| <-------- | switch | <------- | phone | 
           +-----+----------+  Metering +--------+          +-------+ 
                       ^                                           | 
                       |                                           | 
                       +-------------------------------------------+ 
                                       metering 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 52] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        Figure 15: Direct and One Hop Metering  

         

        Case 2: Metering at a point in power distribution 

        A Sub-meter in a power distribution system can logically 
        measure the power or energy for all devices downstream from 
        the meter in the power distribution system.  As such, a Power 
        metering relationship can be seen as a relationship between a 
        meter and all of the devices downstream from the meter. 

        We define in this case a Power Source relationship between a 
        metering device and devices downstream from the meter. 

        In cases where the Power Source topology cannot be discovered 
        or derived from the information available in the Energy 
        Management Domain, the Metering Topology can be used to relate 
        the upstream meter to the downstream devices in the absence of 
        specific power source relationships.  

        A Metering Relationship can occur between devices that are not 
        directly connected, as shown in Figure 16. 

                           +---------------+     
                           |   Device 1    |             
                           +---------------+  
                           |      PI       |  
                           +---------------+           
                                   |                  
                           +---------------+  
                           |     Meter     |  
                           +---------------+  
                                   . 
                                   . 
                                   . 
            +----------+   +----------+   +-----------+   
            | Device A |   | Device B |   | Device C  |  
            +----------+   +----------+   +-----------+   

        Figure 16: Complex Metering Topology 

        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 August, 2013        [Page 53] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        6.4.3 Aggregation Topology 

        Some devices can act as aggregation points for other devices.  
        For example, a PDU controller device may contain the summation 
        of power and energy readings for many PDU devices.  The PDU 
        controller will have aggregate values for power and energy for 
        a group of PDU devices.  

        This aggregation is independent of the physical power or 
        communication topology.  

        An Aggregation Relationship is an Energy Object Relationship 
        where one Energy Object (called the Aggregate Energy Object) 
        aggregates the Energy Management information of one or more 
        other Energy Objects.  These Energy Objects are said to have 
        an Aggregation Relationship.   

        The functions that the aggregation point may perform include 
        the calculation of values such as average, count, maximum, 
        median, minimum, or the listing (collection) of the 
        aggregation values, etc.   

        Based on the experience gained on aggregations at the IETF 
        [draft-ietf-ipfix-a9n-08], the aggregation function in the 
        EMAN framework is limited to the summation. 

        When aggregation occurs across a set of entities, values to be 
        aggregated may be missing for some entities.  The EMAN 
        framework does not specify how these should be treated, as 
        different implementations may have good reason to take 
        different approaches.  One common treatment is to define the 
        aggregation as missing if any of the constituent elements are 
        missing (useful to be most precise). Another is to treat the 
        missing value as zero (useful to have continuous data 
        streams). 

        The specifications of aggregation functions are out of scope 
        of the EMAN framework, but must be clearly specified by the 
        equipment vendor. 

     7. Relationship with Other Standards  

      

        This energy management framework uses, as much as possible, 
        existing standards efforts, especially with respect to 
        information modeling and data modeling [RFC3444].  

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 54] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         

        The data model for power- and energy-related objects is based 
        on IEC 61850.   

        Specific examples include: 

        The scaling factor, which represents Energy Object usage 
        magnitude, conforms to the IEC 61850 definition of unit 
        multiplier for the SI (System International) units of measure.  

        The electrical characteristic is based on the ANSI and IEC 
        Standards, which require that we use an accuracy class for 
        power measurement.  ANSI and IEC define the following accuracy 
        classes for power measurement:  

        IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.    

        ANSI C12.20 class 0.2, 0.5 

        The electrical characteristics and quality adhere closely to 
        the IEC 61850 7-2 standard for describing AC measurements.   

        The power state definitions are based on the DMTF Power State 
        Profile and ACPI models, with operational state extensions.  
         

     8.       Security Considerations 

        Regarding the data attributes specified here, some or all may 
        be considered sensitive or vulnerable in some network 
        environments. Reading or writing these attributes without 
        proper protection such as encryption or access authorization 
        may have negative effects on the network capabilities. 
         
        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 thus 
        important to control GET and/or NOTIFY access to these objects 
        and possibly to encrypt the values of these objects when 
        sending them over the network via SNMP.   

         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 55] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        The support for SET operations in a non-secure environment 
        without proper protection can have a negative effect on 
        network operations.  For example: 

        Unauthorized changes to the Energy Management Domain or 
        business context of an Energy Object may result in 
        misreporting or interruption of power. 

        Unauthorized changes to a power state may disrupt the power 
        settings of the different Energy Objects, and therefore the 
        state of functionality of the respective Energy Objects. 

        Unauthorized changes to the demand history may disrupt proper 
        accounting of energy usage.  

        With respect to data transport, SNMP versions prior to SNMPv3 
        did not include adequate security.  Even if the network itself 
        is secure (for example, by using IPsec), there is still no 
        secure control over who on the secure network is allowed to 
        access and GET/SET (read/change/create/delete) the objects in 
        these MIB modules. 

        It is recommended that implementers consider the security 
        features as provided by the SNMPv3 framework (see [RFC3410], 
        section 8), including full support for the SNMPv3 
        cryptographic mechanisms (for authentication and privacy). 

        Further, deployment of SNMP versions prior to SNMPv3 is not 
        recommended.  Instead, it is recommended to deploy SNMPv3 and 
        to enable cryptographic security.  It is then a 
        customer/operator responsibility to ensure that the SNMP 
        entity giving access to an instance of these MIB modules is 
        properly configured to give access to the objects only to 
        those principals (users) that have legitimate rights to GET or 
        SET (change/create/delete) them. 

         

     9.       IANA Considerations 

     9.1 IANA Registration of new Power State Set 

        This document specifies an initial set of Power State Sets. 
        The list of these Power State Sets with their numeric 
        identifiers is given is Section 4. IANA maintains the lists of 
        Power State Sets.  

         
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 56] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        New assignments for Power State Set are administered by IANA 
        through Expert Review [RFC5226], i.e., review by one of a 
        group of experts designated by an IETF Area Director. The 
        group of experts MUST check the requested state for 
        completeness and accuracy of the description. A pure vendor 
        specific implementation of Power State Set shall not be 
        adopted; since it would lead to proliferation of Power State 
        Sets.  

         

        Power states in a Power State Set are limited to 255 distinct 
        values. New Power State Set must be assigned the next 
        available numeric identifier that is a multiple of 256. 

         

     9.1.1 IANA Registration of the IEEE1621 Power State Set 

        This document specifies a set of values for the IEEE1621 Power 
        State Set [IEEE1621].  The list of these values with their 
        identifiers is given in Section 4.6.2.  IANA created a new 
        registry for IEEE1621 Power State Set identifiers and filled 
        it with the initial list of identifiers. 
         
        New assignments (or potentially deprecation) for the IEEE1621 
        Power State Set is administered by IANA through Expert Review 
        [RFC5226], i.e., review by one of a group of experts 
        designated by an IETF Area Director.  The group of experts 
        must check the requested state for completeness and accuracy 
        of the description. 
         
     9.1.2 IANA Registration of the DMTF Power State Set 

        This document specifies a set of values for the DMTF Power 
        State Set.  The list of these values with their identifiers is 
        given in Section 4. IANA has created a new registry for DMTF 
        Power State Set identifiers and filled it with the initial 
        list of identifiers 
        . 
        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. 
         
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 57] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
         
     9.1.3 IANA Registration of the EMAN Power State Set 

        This document specifies a set of values for the EMAN Power 
        State Set.  The list of these values with their identifiers is 
        given in Section 4.6.4.  IANA has created a new registry for 
        EMAN Power State Set identifiers and filled it with the 
        initial list of identifiers. 
         
        New assignments (or potentially deprecation) for the EMAN 
        Power State Set is administered by IANA through Expert Review 
        [RFC5226], i.e., review by one of a group of experts 
        designated by an IETF Area Director.  The group of experts 
        must check the requested state for completeness and accuracy 
        of the description. 
         
     9.1.4 Batteries Power State Set 

        Batteries have operational and administrational states that 
        could be represented as a power state set. Since the work for 
        battery management is parallel to this document, we are not 
        proposing any Power State Sets for batteries at this time.  
         
         
     9.2 Updating the Registration of Existing Power State Sets  

        With the evolution of standards, over time, it may be 
        important to deprecate some of the existing the Power State 
        Sets, or to add or deprecate some Power States within a Power 
        State Set.  

         

        The registrant shall publish an Internet-draft or an 
        individual submission with the clear specification on 
        deprecation of Power State Sets or Power States registered 
        with IANA.  The deprecation or addition shall be administered 
        by IANA through Expert Review [RFC5226], i.e., review by one 
        of a group of experts designated by an IETF Area Director. The 
        process should also allow for a mechanism for cases where 
        others have significant objections to claims on deprecation of 
        a registration.  

         

         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 58] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
      

     10.      Acknowledgments  

        The authors would like to Michael Brown for improving the text 
        dramatically, and Rolf Winter for his feedback.  The award for 
        the best feedback and reviews goes to Bill Mielke.  Bruce 
        Nordman helped a lot in the framework brainstorming with 
        numerous conference calls and discussions. Finally, the 
        authors would like to thank the EMAN chairs: Nevil Brownlee, 
        Bruce Nordman, and Tom Nadeau. 
      
      
     11.      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 
         
         
     Informative References 

         
        [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
                "Structure of Management Information Version 2 
                (SMIv2", RFC 2578, April 1999 
         
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 
                between Information Models and Data Models", RFC 
                3444, January 2003 
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 59] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
      
        [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 
         
        [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", 

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 60] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
                draft-ietf-eman-applicability-statement-03, (work in 
                progress), April 2013 
      
        [ITU-T-M-3400] TMN recommandation on Management Functions 
                (M.3400), 1997 
         
        [NMF] "Network Management Fundamentals", Alexander Clemm, 
                ISBN: 1-58720-137-2, 2007 
         
        [TMN] "TMN Management Functions : Performance Management", 
                ITU-T M.3400 
         
        [1037C] US Department of Commerce, Federal Standard 1037C, 
                http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm 
         
        [IEEE100] "The Authoritative Dictionary of IEEE Standards 
                Terms" 
                http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?pu
                number=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?openf
                orm 
      
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                2009 - IEEE Standard for Information technology - 
                Telecommunications and information exchange between 
                systems - Local and metropolitan area networks - 
                Specific requirements - Part 3: Carrier Sense 
                Multiple Access with Collision Detection (CSMA/CD) 
                Access Method and Physical Layer Specifications - 
                Amendment: Data Terminal Equipment (DTE) -  Power via 
                Media Dependent Interface (MDI) Enhancements", 
                   October 2009 
      
        [DMTF] "Power State Management Profile DMTF  DSP1027  Version 
                2.0"  December 2009     
                http://www.dmtf.org/sites/default/files/standards/doc
                uments/DSP1027_2.0.0.pdf 
         
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 
                Management", 2010, Wiley Publishing 
         

      
      
     <Claise, et. Al>         Expires August, 2013        [Page 61] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
        [X.700]  CCITT Recommendation X.700 (1992), Management 
                framework for Open Systems Interconnection (OSI) for 
                CCITT applications 
          
        [ASHRAE-201] "ASHRAE Standard Project Committee 201  
                        (SPC 201)Facility Smart Grid Information  
                        Model", http://spc201.ashraepcs.org 
         
        [CHEN] "The Entity-Relationship Model: Toward a Unified View 
                of Data",  Peter Pin-shan Chen, ACM Transactions on 
                Database Systems, 1976 
         
        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello, 
                Roland Saville, Steve Kramling, Cisco Validated 
                Designs, September 2010, 
                http://www.cisco.com/en/US/docs/solutions/Enterprise/
                Borderless_Networks/Energy_Management/energywisedg.ht
                ml 
         
      
      
     Authors' Addresses 
      
     Benoit Claise 
     Cisco Systems, Inc. 
     De Kleetlaan 6a b1 
     Diegem 1813 
     BE 
          
     Phone: +32 2 704 5622 
     Email: bclaise@cisco.com 
      
      
     John Parello 
     Cisco Systems, Inc. 
     3550 Cisco Way  
     San Jose, California 95134  
     US 
          
     Phone: +1 408 525 2339 
     Email: jparello@cisco.com 
      
      
     Brad Schoening 
     44 Rivers Edge Drive 
     Little Silver, NJ 07739 
     US 
      
      
      
     <Claise, et. Al>         Expires August, 2013        [Page 62] 
         


     Internet-Draft           <EMAN Framework>        February 2013 
      
     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 August, 2013        [Page 63]