[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 7326

     Network Working Group                                  B. Claise
     Internet-Draft                                        J. Parello
     Intended Status: Informational               Cisco Systems, Inc.
     Expires: March 12, 2013                             B. Schoening
                                                Independent Consultant
                                                            J. Quittek
                                                       NEC Europe Ltd.
                                                            B. Nordman
                                                     Lawrence Berkeley
                                                   National Laboratory
     
                                                     October 21, 2012
     
     
     
     
                        Energy Management Framework
                       draft-ietf-eman-framework-06
     
     
     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 March, 2013.
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12 2013          [Page 1]


     Internet-Draft           <EMAN Framework>        October 2012
     
     Copyright Notice
     
        Copyright (c) 2012 IETF Trust and the persons identified as
        the document authors.  All rights reserved.
     
        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the date
        of publication of this document.  Please review these
        documents carefully, as they describe your rights and
        restrictions with respect to this document.  Code Components
        extracted from this document must include Simplified BSD
        License text as described in Section 4.e of the Trust Legal
        Provisions and are provided without warranty as described in
        the Simplified BSD License.
     
     
     
     Abstract
     
        This document defines a framework for providing Energy
        Management for devices within or connected to communication
        networks, and components thereof.  The framework defines an
        Energy Management Domain as a set of Energy Objects, for which
        each Energy Object is identified, classified and given
        context.   Energy Objects can be monitored and/or controlled
        with respect to Power, Power State, Energy, Demand, Power
        Quality, and battery.  Additionally the framework models
        relationships and capabilities between Energy Objects.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 2]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
     Table of Contents
     
        1. Introduction............................................ 5
           1.1. Energy Management Document Overview................ 6
        2. Terminology............................................. 6
           Device.................................................. 6
           Component............................................... 6
           Energy Management....................................... 7
           Energy Management System (EnMS)......................... 7
           ISO Energy Management System............................ 8
           Energy.................................................. 8
           Power................................................... 8
           Demand.................................................. 9
           Power Characteristics................................... 9
           Power Quality........................................... 9
           Electrical Equipment................................... 10
           Non-Electrical Equipment (Mechanical Equipment)........ 10
           Energy Object.......................................... 10
           Electrical Energy Object............................... 10
           Non-Electrical Energy Object........................... 11
           Energy Monitoring...................................... 11
           Energy Control......................................... 11
           Provide Energy:........................................ 11
           Receive Energy:........................................ 11
           Power Interface........................................ 11
           Energy Management Domain............................... 12
           Energy Object Identification........................... 12
           Energy Object Context.................................. 12
           Energy Object Relationship............................. 13
           Aggregation Relationship............................... 13
           Metering Relationship.................................. 13
           Power Source Relationship.............................. 14
           Proxy Relationship..................................... 14
           Energy Object Parent................................... 14
           Energy Object Child.................................... 14
           Power State............................................ 15
           Power State Set........................................ 15
           Nameplate Power........................................ 15
        3. Requirements & Use Cases............................... 16
        4. Energy Management Issues............................... 17
           4.1. Power Supply...................................... 18
           4.2. Power and Energy Measurement...................... 23
           4.3. Reporting Sleep and Off States.................... 24
           4.4. Device and Device Components...................... 25
           4.5. Non-Electrical Equipment.......................... 25
        5. Energy Management Reference Model...................... 26
           5.1. Reference Topologies.............................. 26
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 3]


     Internet-Draft           <EMAN Framework>        October 2012
     
           5.2. Generalized Relationship Model.................... 35
           5.3. Energy Object, Energy Object Components and
           Containment Tree....................................... 37
        6. Framework High Level Concepts and Scope................ 38
           6.1. Energy Object and Energy Management Domain........ 39
           6.2. Power Interface................................... 39
           6.3. Energy Object Identification and Context.......... 40
           6.4. Energy Object Relationships....................... 42
           6.5. Energy Monitoring................................. 47
           6.6. Energy Control.................................... 50
        7. Structure of the Information Model: UML Representation. 54
        8. Configuration.......................................... 59
        9. Fault Management....................................... 60
        10. Examples.............................................. 60
           Example I: Simple Device with one Source............... 61
           Example II: Multiple Inlets............................ 62
           Example III: Multiple Sources.......................... 62
        11. Relationship with Other Standards Development
        Organizations............................................. 63
           11.1. Information Modeling............................. 63
        12. Security Considerations............................... 64
           12.1 Security Considerations for SNMP.................. 64
        13. IANA Considerations................................... 65
        14. Acknowledgments....................................... 65
        15. References............................................ 66
           Normative References................................... 66
           Informative References................................. 66
     
     
     
     
        OPEN ISSUES:
        Are Tracked via Issue Tracker. See
        https://trac.tools.ietf.org/wg/eman/trac/report/1
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 4]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
     
     1. Introduction
     
        Network management is divided into the five main areas defined
        in the ISO Telecommunications Management Network model: Fault,
        Configuration, Accounting, Performance, and Security
        Management (FCAPS) [X.700].  Absent from this management model
        is any consideration of Energy Management, which is now
        becoming a critical area of concern worldwide as seen in
        [ISO50001].
     
        Note that Energy Management has particular challenges in that
        a power distribution network is responsible for the supply of
        energy to various devices and components, while a separate
        communication network is typically used to monitor and control
        the power distribution network.
     
        This document defines a framework for providing Energy
        Management for devices within or connected to communication
        networks.  The framework describes how to identify, classify
        and provide context for a device in a communications network
        from the point of view of Energy Management.
     
        The identified device or identified components within a device
        can then be monitored for Energy Management by obtaining
        measurements for Power, Energy, Demand and Power Quality.  If
        a device contains batteries, they can be also be monitored and
        managed.  An Energy Object state can be monitored or
        controlled by providing an interface expressed as one or more
        Power State Sets.  The most basic example of Energy Management
        is a single Energy Object reporting information about itself.
        However, in many cases, energy is not measured by the Energy
        Object itself, but by a meter located upstream in the power
        distribution tree.  An example is a power distribution unit
        (PDU) that measures energy received by attached devices and
        may report this to an Energy Management System (EnMS).
        Therefore, Energy Objects are recognized as having
        relationships to other devices in the network from the point
        of view of Energy Management.  These relationships include
        Aggregation Relationship, Metering Relationship, Power Source
        Relationship, and Proxy Relationship.
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 5]


     Internet-Draft           <EMAN Framework>        October 2012
     
     1.1. Energy Management Document Overview
     
        The EMAN standard provides a set of specifications for Energy
        Management.  This document specifies the framework, per the
        Energy Management requirements specified in [EMAN-REQ].
     
        The applicability statement document [EMAN-AS] provides a list
        of use cases, a cross-reference between existing standards and
        the EMAN standard, and shows how this framework relates to
        other frameworks.
     
        The Energy-aware Networks and Devices MIB [EMAN-AWARE-MIB]
        specifies objects for addressing Energy Object Identification,
        classification, context information, and relationships from
        the point of view of Energy Management.
     
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains
        objects for monitoring of Power, Energy, Demand, Power Quality
        and Power States.
     
        Further, the battery monitoring MIB [EMAN-BATTERY-MIB] defines
        managed objects that provide information on the status of
        batteries in managed devices.
     
     
     2. Terminology
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described
        in RFC 2119 [RFC2119].
     
       EDITOR'S NOTE:
        All terms are copied over from the version 6 of the [EMAN-
        TERMINOLOGY] draft.
     
     
       Device
     
          A piece of electrical or non-electrical equipment.
          Reference: Adapted from [IEEE100]
     
     
       Component
     
          A part of an electrical or non-electrical equipment
          (Device).
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 6]


     Internet-Draft           <EMAN Framework>        October 2012
     
          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 elements and
          attached devices use energy efficiently and is
          appropriate for the nature of the application and
          the cost constraints of the organization.
          Reference: Adapted from [ITU-T-M-3400]
          Example: A set of computer systems that will poll
          electrical meters and store the readings
          NOTES:
          1. Energy management refers to the activities,
            methods, procedures and tools that pertain to
            measuring, modeling, planning, controlling and
            optimizing the use of energy in networked
            systems [NMF].
          2. Energy Management is a management domain which
            is congruent to any of FCAPS areas of
            management in the ISO/OSI Network Management
            Model [TMN]. Energy Management for
            communication networks and attached devices is
            a subset or part of an organization's greater
            Energy Management Policies.
     
       Energy Management System (EnMS)
     
          An Energy Management System is a combination of
          hardware and software used to administer a
          network with the primary purpose being Energy
          Management.
          Reference: Adapted from [1037C]
          Example: A single computer system that polls data
          from devices using SNMP
          NOTES:
          1. An Energy Management System according to
            [ISO50001] (ISO-EnMS) is a set of systems or
            procedures upon which organizations can develop
            and implement an energy policy, set targets,
            action plans and take into account legal
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 7]


     Internet-Draft           <EMAN Framework>        October 2012
     
            requirements related to energy use.  An EnMS
            allows organizations to improve energy
            performance and demonstrate conformity to
            requirements, standards, and/or legal
            requirements.
          2. Example ISO-EnMS:  Company A defines a set of
            policies and procedures indicating there should
            exist multiple computerized systems that will
            poll energy from their meters and pricing /
            source data from their local utility. Company A
            specifies that their CFO should collect
            information and summarize it quarterly to be
            sent to an accounting firm to produce carbon
            accounting reporting as required by their local
            government.
          3. For the purposes of EMAN, the definition from
            [1037C] is the preferred meaning of an Energy
            Management System (EnMS).  The definition from
            [ISO50001] can be referred to as ISO Energy
            Management System (ISO-EnMS).
     
       ISO Energy Management System
     
         Energy Management System as defined by [ISO50001]
     
       Energy
     
          That which does work or is capable of doing work.
          As used by electric utilities, it is generally a
          reference to electrical energy and is measured in
          kilo-watt hours (kWh).
          Reference: [IEEE100]
          NOTES
          1. Energy is the capacity of a system to produce
            external activity or perform work [ISO50001]
     
       Power
     
          The time rate at which energy is emitted,
          transferred, or received; usually expressed in
          watts (or in joules per second).
          Reference: [IEEE100]
     
     
     <Claise, et. Al>         Expires Mar 12,2013          [Page 8]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
       Demand
     
          The average value of power or a related quantity
          over a specified interval of time. Note: Demand
          is expressed in kilowatts, kilovolt-amperes,
          kilovars, or other suitable units.
     
          Reference: [IEEE100]
          NOTES:
          1.  Typically kilowatts.
          2.  Energy providers typically bill by Demand
          measurements as well as for maximum Demand per
          billing periods.  Power values may spike during
          short-terms by devices, but Demand measurements
          recognize that maximum Demand does not equal
          maximum Power during an interval.
     
        Power Characteristics
     
          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 Characteristics is 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 electric 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 Mar 12,2013          [Page 9]


     Internet-Draft           <EMAN Framework>        October 2012
     
          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 a piece of equipment
          that is part of or attached to a communications
          network that is monitored, controlled, or aids in
          the management of another device for Energy
          Management.
     
     
       Electrical Energy Object
     
          An Electrical Energy Object (EEO) is an Energy
          Object that is a piece of Electrical Equipment
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 10]


     Internet-Draft           <EMAN Framework>        October 2012
     
       Non-Electrical Energy Object
     
          A Non-Electrical Energy Object (NEEO) an Energy
          Object that is a piece of Non-Electrical
          Equipment.
     
     
       Energy Monitoring
     
          Energy Monitoring is a part of Energy Management
          that deals with collecting or reading information
          from Energy Objects to aid in Energy Management.
          NOTES:
          1. This could include Energy, Power, Demand, Power
            Quality, Context and/or Battery information.
     
       Energy Control
     
          Energy Control is a part of Energy Management
          that deals with directing influence over Energy
          Objects.
     
          NOTES:
          1. Typically in order to optimize or ensure its
             efficiency.
     
       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
           interconnection among devices or components where energy
           can be provided, received or both.
     
        Power Inlet
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 11]


     Internet-Draft           <EMAN Framework>        October 2012
     
           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
          where all objects in the domain are considered one unit of
          management.
     
          For example, power distribution units and all of the
          attached Energy Objects are part of the same Energy
          Management Domain.
     
          For example, all EEO's drawing power from the
          same distribution panel with the same AC voltage
          within a building, or all EEO's in a building for
          which there is one main meter, would comprise an
          Energy Management Domain.
     
          NOTES:
          1. Typically, this set will have as members all
             EO's that are powered from the same source.
     
     
       Energy Object Identification
     
          Energy Object Identification is a set of
          attributes that enable an Energy Object to be:
          uniquely identified among all Energy Management
          Domains; linked to other systems; classified as
          to type, model, and or manufacturer
     
       Energy Object Context
     
          Energy Object Context is a set of attributes that
          allow an Energy Management System to classify the
          use of the Energy Object within an organization.
          NOTES:
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 12]


     Internet-Draft           <EMAN Framework>        October 2012
     
          1. The classification could contain the use and/or
            the ranking of the Energy Object as compared to
            other Energy Objects in the Energy Management
            Domain.
     
     
       Energy Object Relationship
     
          An Energy Object Relationship is a functional association
          among Energy Objects
     
          NOTES
          1. Relationships can be named and could include
          Aggregation, Metering, Power Source, and Proxy.
          2. The Energy Object is the noun or entity in the
          relationship with the relationship described as the verb.
     
          Example: If EO x is a piece of Electrical Equipment and EO
          y is an electrical meter clamped onto x's power cord, then
          x and y have a Metering Relationship. It follows that y
          meters x and that x is metered by y.
          Reference: Adapted from [CHEN]
     
     
        Aggregation Relationship
     
     
          An Aggregation Relationship is an Energy Object
          Relationship where one Energy Object aggregates the Energy
          Management information of one or more other Energy Objects.
          These Energy Objects are referred to as having an
          Aggregation Relationship.
     
          NOTES:
          Aggregate values may be obtained by collecting values from
          multiple Energy Objects and producing a single value of
          more significant meaning such as average, count, maximum,
          median, minimum, mode and most commonly sum [SQL].
     
        Metering Relationship
     
     
          A Metering Relationship is an Energy Object Relationship
          where one Energy Object measures the Power or Energy of one
          or more other Energy Objects. These Energy Objects are
          referred to as having a Metering Relationship.
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 13]


     Internet-Draft           <EMAN Framework>        October 2012
     
          Example: a PoE port on a switch measures the Power it
          provides to the connected Energy Object.
     
     
        Power Source Relationship
     
     
          A Power Source Relationship is an Energy Object
          Relationship where one Energy Object is the source of or
          distributor of Power to one or more other Energy Objects.
          These Energy Objects are referred to as having a Power
          Source Relationship.
     
          Example: a PDU provides power for a connected device.
     
     
        Proxy Relationship
     
     
          A Proxy Relationship is an Energy Object Relationship where
          one Energy Object provides the Energy Management
          capabilities on behalf of one or more other Energy Objects.
          These Energy Objects are referred to as having a Proxy
          Relationship.
     
          Example: a protocol gateways device for Building Management
          Systems (BMS) with subtended devices.
     
     
       Energy Object Parent
     
          An Energy Object Parent is an Energy Object that
          participates in an Energy Object Relationships
          and is considered as providing the capabilities
          in the relationship.
     
          Example: in a Metering Relationship, the Energy
          Object that is metering is called the Energy
          Object Parent, while the Energy Object that is
          metered is called the Energy Object Child.
     
     
       Energy Object Child
     
          An Energy Object Child is an Energy Object that
          participates in an Energy Object Relationships
          and is considered as receiving the capabilities
          in the relationship.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 14]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
          Example: in a Metering Relationship, the Energy
          Object that is metering is called the Energy
          Object Parent, while the Energy Object that is
          metered is called the Energy Object Child.
     
     
       Power State
     
          A Power State is a condition or mode of a device
          that broadly characterizes its capabilities,
          power consumption, and responsiveness to input.
     
          Reference: Adapted from [IEEE1621]
     
          NOTES:
     
          1. A Power State can be seen as a power setting
             of an Energy Object that influences the power
             consumption, the available functionality, and
             the responsiveness of the Energy Object.
     
          2. A Power State can be viewed as one method for
             Energy Control
     
     
       Power State Set
     
          A collection of Power States that comprise one
          named or logical grouping of control is a Power
          State Set.
     
          Example: The states {on, off, and sleep} as
          defined in [IEEE1621], or the 16 power states as
          defined by the [DMTF] can be considered two
          different Power State Sets.
     
     
       Nameplate Power
     
          The Nameplate Power is the nominal Power of a
          device as specified by the device manufacturer.
     
          NOTES:
     
          1. This is typically determined via load testing
             and is specified by the manufacturer as the
             maximum value required for operating the
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 15]


     Internet-Draft           <EMAN Framework>        October 2012
     
             device.  This is sometimes referred to as the
             worst-case Power.  The actual or average Power
             may be lower.  The Nameplate Power is
             typically used for provisioning and capacity
             planning.
     
     
     
     3. Requirements & Use Cases
     
        Requirements for Power and Energy monitoring for networking
        devices are specified in [EMAN-REQ].  The Energy Management
        use cases covered by this framework are covered in the EMAN
        applicability statement document in [EMAN-AS].  Typically
        requirements and use cases for communication networks cover
        the devices that make up the communication network and
        endpoints.
     
        With Energy Management, there exists a wide variety of devices
        that may be contained in the same deployments as a
        communication network but comprise a separate facility, home,
        or power distribution network.
     
        Target devices for Energy Management are all Energy Objects
        that can directly or indirectly be monitored or controlled by
        an Energy Management System (EnMS) using the Internet
        protocol, for example:
            - Simple electrical appliances / fixtures
            - Hosts, such as a PC, a datacenter server, or a printer
            - Routers
            - Switches
            - A component within devices, such as a battery inside a
        PC, a line card inside a switch, etc...
            - Power over Ethernet (PoE) endpoints
            - Power Distribution Units (PDU)
            - Protocol gateway devices for Building Management Systems
        (BMS)
            - Electrical meters
            - Sensor controllers with subtended sensors
     
        There may also exist varying protocols deployed among these
        power distributions and communication networks.
     
        For an Energy Management framework to be useful, it should
        also apply to these types of separate networks as they connect
        and interact with a communications network.
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 16]


     Internet-Draft           <EMAN Framework>        October 2012
     
        This is the first version of the IETF Energy Management
        framework.  Though it already covers a wide range of use
        cases, there are still a lot of potential ones that are not
        covered, yet.  A simple example is the limitation to discrete
        power states without parameters.  Some devices have energy-
        related properties that not well described with discrete power
        states, for example a dimmer with a continuous power range
        from 0%-100%.  Other devices may have even more parameters
        than just a single percentage value.
     
        This framework definces an informtion model containing various
        values that are measured on a device for the purpose of
        monitor and control. The framework does not cover setting
        bounds or conditions for these values for the purpose of
        policy management - for example specifying that power MUST NOT
        exceed a limit. While implementations can set bounds and
        notification when exceeding those bounds while monitored,
        physically preventing a device to not exceed the bound is
        beyond the scope of this framework. It is up to future updates
        of this document to select more of such use-cases and to cover
        them by extensions or revisions of the present framework.
     
     
     
     4. Energy Management Issues
     
        This section explains special issues of Energy Management
        particularly concerning power supply, Power and Energy
        metering, and the reporting of low Power States.
     
        To illustrate the issues we start with a simple and basic
        scenario with a single powered device that receives Energy and
        that reports energy-related information about itself to an
        Energy Management System (EnMS), see Figure 1
     
     
     
                               +--------------------------+
                               | Energy Management System |
                               +--------------------------+
                                           ^  ^
                                monitoring |  | control
                                           v  v
                                    +-----------------+
                                    | powered device  |
                                    +-----------------+
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 17]


     Internet-Draft           <EMAN Framework>        October 2012
     
                  Figure 1: Basic energy management scenario
     
     
        The powered device may have local energy control mechanisms,
        for example putting itself into a sleep mode when appropriate,
        and it may receive energy control commands for similar
        purposes from the EnMS.  Information reported from a powered
        device to the EnMS includes at least the Power State of the
        powered device (on, sleep, off, etc.).
     
        This and similar cases are well understood and likely to
        become very common for Energy Management.  They can be handled
        with well established and standardized management procedures.
        The only missing components today are standardized information
        and data models for reporting and configuration, such as, for
        example, energy-specific MIB modules [RFC2578] and YANG
        modules [RFC6020].
     
        However, the nature of energy supply and use introduces some
        issues that are special to Energy Management.  The following
        subsections address these issues and illustrate them by
        extending the basic scenario in Figure 1.
     
     
     
     4.1. Power Supply
     
        A powered device may supply itself with power.  Sensors, for
        example, commonly have batteries or harvest Energy.  However,
        most powered devices that are managed by an EnMS receive
        external power.
     
        While a huge number of devices receive Power from unmanaged
        supply systems, the number of manageable power supply devices
        is increasing.
     
        In datacenters, many Power Distribution Units (PDUs) allow the
        EnMS to switch power individually for each socket and also to
        measure the provided Power.  Here there is a big difference to
        many other network management tasks: In such and similar
        cases, switching power supply for a powered device or
        monitoring its power is not done by communicating with the
        actual powered device, but with an external power supply
        device (in this case, the PDU). Note that those external power
        supply devices may be an external power meter).
     
        Consequently, a standard for Energy Management must not just
        cover the powered devices that provide services for users, but
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 18]


     Internet-Draft           <EMAN Framework>        October 2012
     
        also the power supply devices (which are powered devices as
        well) that monitor or control the power supply for other
        powered devices.
     
        A very simple device such as a plain light bulb can be
        switched on or off only by switching its power supply.  More
        complex devices may have the ability to switch off themselves
        or to bring themselves to states in which they consume very
        little power.  For these devices as well, it is desirable to
        monitor and control their power supply.
     
        This extends the basic scenario from Figure 1 by a power
        supply device, see Figure 2.
     
     
                    +-----------------------------------------+
                    |         energy management system        |
                    +-----------------------------------------+
                          ^  ^                       ^  ^
               monitoring |  | control    monitoring |  | control
                          v  v                       v  v
                    +--------------+        +-----------------+
                    | power supply |########| powered device  |
                    +--------------+        +-----------------+
     
                            ######## power supply line
     
                            Figure 2: Power Supply
     
        The power supply device can be as simple as a plain power
        switch.  It may offer interfaces to the EnMS to monitor and to
        control the status of its power outlets, as with PDUs and
        Power over Ethernet (PoE) [IEEE-802.3at] switches.
     
        The relationship between supply devices and the powered
        devices they serve creates several problems for managing power
        supply:
           o  Identification of corresponding devices
              *  A given powered device may be need to identify the
                 supplying power supply device.
              *  A given power supply device may need to identify the
                 corresponding supplied powered device(s).
           o  Aggregation of monitoring and control for multiple
        powered
              devices
              *  A power supply device may supply multiple powered
                 devices with a single power supply line.
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 19]


     Internet-Draft           <EMAN Framework>        October 2012
     
           o  Coordination of power control for devices with multiple
              power inlets
              *  A powered device may receive power via multiple power
                 lines controlled by the same or different power
        supply devices.
     
     
     4.1.1 Identification of Power Supply and Powered Devices
     
        When a power supply device controls or monitors power supply
        at one of its power outlets, the effect on other devices is
        not always clear without knowledge about wiring of power
        lines.  The same holds for monitoring.  The power supplying
        device can report that a particular socket is powered, and it
        may even be able to measure power and conclude that there is a
        consumer drawing power at that socket, but it may not know
        which powered device receives the provided power.
     
        In many cases it is obvious which other device is supplied by
        a certain outlet, but this always requires additional
        (reliable) information about power line wiring.  Without
        knowing which device(s) are powered via a certain outlet,
        monitoring data are of limited value and the consequences of
        switching power on or off may be hard to predict.
     
        Even in well organized operations, powered devices' power
        cords can be plugged into the wrong socket, or wiring plans
        changed without updating the EnMS accordingly.
     
        For reliable monitoring and control of power supply devices,
        additional information is needed to identify the device(s)
        that receive power provided at a particular monitored and
        controlled socket.
     
        This problem also occurs in the opposite direction.  If power
        supply control or monitoring for a certain device is needed,
        then the supplying power supply device has to be identified.
     
        To conduct Energy Management tasks for both power supply
        devices and other powered devices, sufficiently unique
        identities are needed, and knowledge of their power supply
        relationship is required.
     
     
     4.1.2 Multiples Devices Supplied by a Single Power Line
     
        The second fundamental problem is the aggregation of
        monitoring and control that occurs when multiple powered
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 20]


     Internet-Draft           <EMAN Framework>        October 2012
     
        devices are supplied by a single power supply line.  It is
        often required that the EnMS has the full list of powered
        devices connected to a single outlet as in Figure 3.
     
     
     
     
                      +---------------------------------------+
                      |       energy management system        |
                      +---------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                      +--------+        +------------------+
                      | power  |########| powered device 1 |
                      | supply |   #    +------------------+-+
                      +--------+   #######| powered device 2 |
                                     #    +------------------+-+
                                     #######| powered device 3 |
                                            +------------------+
     
                 Figure 3: Multiple Powered Devices Supplied
                             by Single Power Line
     
     
        With this list, the single status value has clear meaning and
        is the sum of all powered devices.  Control functions are
        limited by the fact that supply for the concerned devices can
        only be switched on or off for all of them at once.
        Individual control at the supply is not possible.
     
        If the full list of devices powered by a single supply line is
        not known by the controlling power supply device, then control
        of power supply is problematic, because the consequences of
        control actions can only be partially known.
     
     
     4.1.3 Multiple Power Supply for a Single Powered Device
     
        The third problem arises from the fact that there are devices
        with multiple power supplies.  Some have this for redundancy
        of power supply, some for just making internal power
        converters (for example, from AC mains power to DC internal
        power) redundant, and some because the capacity of a single
        supply line is insufficient.
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 21]


     Internet-Draft           <EMAN Framework>        October 2012
     
                   +----------------------------------------------+
                   |          energy management system            |
                   +----------------------------------------------+
                       ^  ^              ^  ^              ^  ^
                  mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                       v  v              v  v              v  v
                   +----------+      +----------+      +----------+
                   | power    |######| powered  |######| power    |
                   | supply 1 |######| device   |      | supply 2 |
                   +----------+      +----------+      +----------+
     
          Figure 4: Multiple Power Supply for Single Powered Device
     
        The example in Figure 4 does not necessarily show a real world
        scenario, but it shows the two cases to consider:
           o  multiple power supply lines between a single power
        supply
              device and a powered device
           o  different power supply devices supplying a single
        powered
              device
        In any such case there may be a need to identify the supplying
        power supply device individually for each power inlet of a
        powered device.
     
        Without this information, monitoring and control of power
        supply for the powered device may be limited.
     
     
     4.1.4 Bidirectional Power Interfaces
     
        Low wattage DC systems may allow power to be delivered bi-
        directionally.  Energy stored in batteries on one device can
        be delivered back to a power hub which redirects the current
        to power another device.  In this situation, the interface can
        function as both an inlet and outlet.
     
        The framework for Energy Management introduces the notion of
        Power Interface, which can model a power inlet and a power
        outlet, depending on the conditions.  The Power Interface
        reports power direction, as well as the energy received,
        supplied and the net result.
     
     
     4.1.5 Relevance of Power Supply Issues
     
        In some scenarios, the problems with power supply do not exist
        or can be sufficiently solved.  With Power over Ethernet (PoE)
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 22]


     Internet-Draft           <EMAN Framework>        October 2012
     
        [IEEE-802.3at], there is always a one-to-one relationship
        between a Power Sourcing Equipment (PSE) and a Powered Device
        (PD).  Also, the Ethernet link on the line used for powering
        can be used to identify the two connected devices.
     
        For supply of AC mains power, the three problems described
        above cannot be solved in general.  There is no commonly
        available protocol or automatic mechanism for identifying
        endpoints of a power line.
     
        And, AC power lines support supplying multiple powered devices
        with a single line and commonly do.
     
     
     4.1.6 Remote Power Supply Control
     
        There are three ways for an energy management system to change
        the Power State of an powered devices.  First is for the EnMS
        to provide policy or other useful information (like the
        electricity price) to the powered device for it to use in
        determining its Power State.  The second is sending the
        powered devices a command to switch to another Power State.
        The third is to utilize an upstream device (to the powered
        device) that has capabilities to switch on and off power at
        its outlet.
     
        Some Energy Objects do not have capabilities for receiving
        commands or changing their Power States by themselves.  Such
        Energy Objects may be controlled by switching on and off the
        power supply for them and so have particular need for the
        third method.
     
        In Figure 4, the power supply can switch on and off power at
        its power outlet and thereby switch on and off power supply
        for the connected powered device.
     
     
     4.2. Power and Energy Measurement
     
        Some devices include hardware to directly measure their Power
        and Energy consumption.  However, most common networked
        devices do not provide an interface that gives access to
        Energy and Power measurements.  Hardware instrumentation for
        this kind of measurements is typically not in place and adding
        it incurs an additional cost.
     
        With the increasing cost of Energy and the growing importance
        of Energy Monitoring, it is expected that in future more
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 23]


     Internet-Draft           <EMAN Framework>        October 2012
     
        devices will include instrumentation for power and energy
        measurements, but this may take quite some time.
     
     
     4.2.1 Local Estimates
     
        One solution to this problem is for the powered device to
        estimate its own Power and consumed Energy.  For many Energy
        Management tasks, getting an estimate is much better than not
        getting any information at all.
     
        Estimates can be based on actual measured activity level of a
        device or it can just depend on the power state (on, sleep,
        off, etc.).
     
        The advantage of estimates is that they can be realized
        locally and with much lower cost than hardware
        instrumentation.  Local estimates can be dealt with in
        traditional ways.  They don't need an extension of the basic
        scenarios above.  However, the powered device needs an energy
        model of itself to make estimates.
     
     
     
     4.2.2 Management System Estimates
     
        Another approach to the lack of instrumentation is estimation
        by the EnMS.  The EnMS can estimate Power based on basic
        information on the powered device, such as the type of device,
        or also its brand/model and functional characteristics.
     
        Energy estimates can combine the typical power level by Power
        State with reported data about the Power State.
     
        If the EnMS has a detailed energy model of the device, it can
        produce better estimates including the actual power state and
        actual activity level of the device.  Such information can be
        obtained by monitoring the device with conventional means of
        performance monitoring.
     
     
     4.3. Reporting Sleep and Off States
     
        Low power modes pose special challenges for energy reporting
        because they may preclude a device from listening to and
        responding to network requests.  Devices may still be able to
        reliably track energy use in these modes, as power levels are
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 24]


     Internet-Draft           <EMAN Framework>        October 2012
     
        usually static and internal clocks can track elapsed time in
        these modes.
     
        Some devices do have out-of-band or proxy abilities to respond
        to network requests in low-power modes.  Others could use
        proxy abilities in an energy management protocol to improve
        this reporting, particularly if the powered device sends out
        notifications of power state changes.
     
     4.4. Device and Device Components
     
        While the primary focus of energy management is entire powered
        Devices,  sometimes it is necessary or desirable to manage
        Components such as line cards, fans, disks, etc.
     
        The concept of a Power Interface may not apply to Components
        since they may receive Energy from a pool available from the
        encompassing device.  For example, a DC-powered blade server
        in a chassis may have its own identity on the network and be
        managed as a single device but its energy may be received from
        a shared power source among all blades in the chassis.
     
     
     4.5. Non-Electrical Equipment
     
        The primary focus of this framework is for the management of
        Electrical Equipment.  Some Non-Electrical Equipment may be
        connected to a communication networks and could have their
        energy managed if normalize to the electrical units for power
        and energy.
     
        Some examples of Non-Electrical Equipment that may be
        connected to a communication network are:
        1) A controller for compressed air.  The controller is
          electrical only for its network connection.  The controller
          is fueled by natural gas and produces compressed air.  The
          energy transferred via compressed air is distributed to
          devices on a factory floor via a Power Interface: tools
          (drills, screwdrivers, assembly line conveyor belts). The
          energy measured is non-electrical (compressed air).
          EDITOR'S NOTE: Note that, in such as case, some might argue
          that the "energy interface" term might be more accurate than
          Power Interface. To be discussed.
     
        2) A controller for steam. The controller is electrical for its
          network attachment but it burns tallow and produces steam to
          subtended boilers. The energy is non-electrical (steam).
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 25]


     Internet-Draft           <EMAN Framework>        October 2012
     
        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).
     
     5. Energy Management Reference Model
     
        The scope of this framework is to enable network and network-
        attached devices to be administered for Energy Management.
        The framework recognizes that in complex deployments Energy
        Objects may communicate over varying protocols.  For example
        the communications network may use IP Protocols (SNMP) but
        attached Energy Object Parent may communicate to Energy Object
        Children over serial communication protocols like BACNET,
        MODBUS etc.  The likelihood of getting these different
        topologies to convert to a single protocol is not very high
        considering the rate of upgrades of facilities and energy
        related devices. Therefore the framework must address the
        simple case of a uniform IP network and a more complex mixed
        topology/deployment.
     
        In this section we will describe the topologies that can exist
        when describing a device, components and the relationships
        among them in an Energy Management Domain.
     
        We will then generalize those topologies by using an
        information model based upon relationships. The most abstract
        and general relationship between devices is a Parent and Child
        relationship. Specific types of relationships are defined and
        used in concert to describe the topologies of an Energy
        Management Domain.
     
     5.1. Reference Topologies
     
        The reference model defines physical and logical topologies of
        devices and the relationship among them in a communication
        network.
     
        The physical topology defined by the model defines
        relationships between devices that reflect provisioning,
        transfer of energy, and aid in management.
     
        Logical topologies concern monitoring and controlling devices
        and covers metering of energy and power, reporting information
        relevant for energy management, and energy-related control of
        devices.
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 26]


     Internet-Draft           <EMAN Framework>        October 2012
     
     5.1.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, for example, an Ethernet
        switch, providing power to a PoE PD, for example, 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 5: Simple Power Source
     
        A single power provider can act as power source of 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 |
     
                                        +----------+
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 27]


     Internet-Draft           <EMAN Framework>        October 2012
     
                       Figure 6: 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 also between power interfaces at the
        power provider side as well as at the power receiver side.
        The example below shows a power providing device with a power
        interface (PI) per connected receiving device.
     
     
     
              +-------+------+   power source  +----------+
     
              |       | PI 1 | <-------------- | switch 1 |
     
              |       +------+                 +----------+
     
              |       |
     
              |       +------+   power source  +----------+
     
              |  PDU  | PI 2 | <-------------- | switch 2 |
     
              |       +------+                 +----------+
     
              |       |
     
              |       +------+   power source  +----------+
     
              |       | PI 3 | <-------------- | switch 3 |
     
              +-------+------+                 +----------+
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 28]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
     
                 Figure 7: Power Source with Power interfaces
     
        Power interfaces may also be modeled at the receiving device,
        for examples for consistency.
     
     
     
              +-------+------+   power source  +----+----------+
     
              |       | PI 1 | <-------------- | PI | switch 1 |
     
              |       +------+                 +----+----------+
     
              |       |
     
              |       +------+   power source  +----+----------+
     
              |  PDU  | PI 2 | <-------------- | PI | switch 2 |
     
              |       +------+                 +----+----------+
     
              |       |
     
              |       +------+   power source  +----+----------+
     
              |       | PI 3 | <-------------- | PI | switch 3 |
     
              +-------+------+                 +----+----------+
     
                Figure 8: Power Interfaces at Receiving Device
     
     
     
     
        Power Source relationships are between peering 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  +---------+
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 29]


     Internet-Draft           <EMAN Framework>        October 2012
     
                    Figure 9: Power Source Non-Transitive
     
     
        Power Source Relationships are between the PDU and the switch
        and between the switch and the phone.
     
        Power Source Relationships are between the PDU and the
        switchand between the switch and the phone.  Consequently,
        there is logically exists a power source relation between the
        PDU and the phone.
     
              +-------+   power   +--------+   power   +---------+
     
              |  PDU  | <-------- | switch | <-------- |  phone  |
     
              +-------+   source  +--------+   source  +---------+
     
                  ^                                          |
     
                  |              power source                |
     
                  +------------------------------------------+
     
                      Figure 10: Power Source Transitive
     
     
     5.1.2 Metering Topology
     
        Metering Between Two Device
     
        The power 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 Power 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 Power 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
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 30]


     Internet-Draft           <EMAN Framework>        October 2012
     
        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
     
                    Figure 11: Direct and One Hop Metering
     
        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 Metering 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
        notdirectly connected as shown by the figure below.
     
     
     
        An analogy to communication 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 Mar 12,2013         [Page 31]


     Internet-Draft           <EMAN Framework>        October 2012
     
                           +---------------+
     
                           |   Device 1    |
     
                           +---------------+
     
                           |      PI       |
     
                           +---------------+
     
                                   |
     
                           +---------------+
     
                           |   Meter       |
     
                           +---------------+
     
                                   .
     
                                   :
     
            +----------+   +----------+   +-----------+
     
            | Device A |   | Device B |   | Device C  |
     
            +----------+   +----------+   +-----------+
     
                     Figure 12: Complex Metering Topology
     
     5.1.3 Proxy Topology
     
        Some devices may provide energy management capabilities on
        behalf of other devices. For example a controller may
        logically model power interfaces but the physical topology may
        require that the controller communicate to another device
        using a BMS protocol. These subtended devices that are
        represented as power interfaces may be directly connected or
        may be controlled over a communication network with no direct
        connection.
     
        While the EnMS may look at the logical representation of the
        controller as a device with power interfaces, it may require
        to report the physical topology and relationship to the
        subtended devices. To model this we define a proxy
        relationship to provide this visibility.
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 32]


     Internet-Draft           <EMAN Framework>        October 2012
     
              +-------+------+
     
              |       | PI 1 |
     
              |       +------+
     
              |       |
     
              |       +------+
     
              |  PDU  | PI 2 |
     
              |       +------+
     
              |       |
     
              |       +------+
     
              |       | PI 3 |
     
              +-------+------+
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 33]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
     
              +-------+  proxy   +----+----------+
     
              |       |<-------- | PI 1 Physical |
     
              |       +          +----+----------+
     
              |       |
     
              |       +   proxy   +----+----------+
     
              |  PDU  |<--------- | PI 2 Physical |
     
              |       +           +----+----------+
     
              |       |
     
              |       +   proxy   +----+----------+
     
              |       |<--------- | PI 3 Physical |
     
              +-------+           +----+----------+
     
     
     
              Figure 13: Proxy Relationship Virtual and Physical
     
     5.1.4 Aggregation Topology
     
        Some devices in a domain can act as aggregation points for
        other devices. For example a PDU contoller device may contain
        the summation of power and energy readings for many PDU
        devices. The PDU controller will have aggregate values for
        power and energy for a  group of PDU devices.
     
        This aggregation is independent of the physical power or
        communication topology.
     
        The functions that the aggregation point may perform include
        values such as average, count, maximum, median, minimum or
        listing (collection) of the aggregation.
     
        We define in this case an Aggregation Relationship between a
        device containing aggregate values for arbitrary groups of
        other devices.
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 34]


     Internet-Draft           <EMAN Framework>        October 2012
     
        While any power or energy values monitored from a device/power
        interface can be seen as a summation for all devices
        downstream from the monitoring device, the aggregation
        relationship is used to represent a summation when it is not
        obvious from the powering topology or a device to component
        containment.
     
     
     5.2. Generalized Relationship Model
     
        As displayed in Figure 5, the most basic energy management
        reference model is composed of an EnMS that obtains Energy
        Management information from Energy Objects.  The Energy Object
        (EO) returns information for Energy Management directly to the
        EnMS.
     
        The protocol of choice for Energy Management is SNMP, as three
        MIBs are specified for Energy Management: the energy-aware MIB
        [EMAN-AWARE-MIB], the energy monitoring MIB [EMAN-MON-MIB],
        and the battery MIB [EMAN-BATTERY-MIB].  However, the EMAN
        requirement document [EMAN-REQ] also requires support for a
        push model distribution of time series values.  The following
        diagrams mention IPFIX [RFC5101] as one possible solution for
        implementing a push mode transfer, however this is for
        illustration purposes only.  The EMAN standard does not
        require the use of IPFIX and acknowledges that other
        alternative solutions may also be acceptable.
     
                            +---------------+
                            |      EnMS     |                -   -
                            +-----+---+-----+                ^   ^
                                  |   |                      |   |
                                  |   |                      |S  |I
                        +---------+   +----------+           |N  |P
                        |                        |           |M  |F
                        |                        |           |P  |I
               +-----------------+      +--------+--------+  |   |X
               | EO            1 |  ... | EO            N |  v   |
               +-----------------+      +-----------------+  -   -
     
                     Figure 14: Simple Energy Management
     
     
        As displayed in the Figure 5, a more complex energy reference
        model includes Energy Managed Object Parents and Children.
        The Energy Managed Object Parent returns information for
        themselves as well as information according to the Energy
        Managed Object Relationships.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 35]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
     
     
     
                           +---------------+
                           |      EnMS     |               -   -
                           +-----+--+------+               ^   ^
                                 |  |                      |   |
                                 |  |                      |S  |I
                    +------------+  +--------+             |N  |P
                    |                        |             |M  |F
                    |                        |             |P  |I
            +------------------+     +------+-----------+  |   |X
            | EO               |     | EO               |  v   |
            | Parent 1         | ... | Parent N         |  -   -
            +------------------+     +------------------+
                           |||                  .
          One or           |||                  .
          Multiple         |||                  .
          Energy           |||                  .
          Object           |||                  .
          Relationship(s): |||
          - Aggregation    |||      +-----------------------+
          - Metering       |||------| EO Child 1            |
          - Power Source   ||       +-----------------------+
          - Proxy          ||
                           ||       +-----------------------+
                           ||-------| EO Child 2            |
                           |        +-----------------------+
                           |
                           |
                           |--------           ...
                           |
                           |
                           |        +-----------------------+
                           |--------| EO Child M            |
                                    +-----------------------+
     
     
     
                  Figure 15: Complex Energy Management Model
     
     
        While both the simple and complex Energy Management models
        contain an EnMS, this framework doesn't impose any
        requirements regarding a topology with a centralized EnMS or
        one with distributed Energy Management via the Energy Objects
        within the deployment.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 36]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        Given the pattern in Figure 6, the complex relationships
        between Energy Objects can be modeled (refer also to section
        5.3):
             - A PoE device modeled as an Energy Object Parent with
               the Power Source, Metering, and Proxy Relationships for
               one or more Energy Object Children
             - A PDU modeled as an Energy Object Parent with the Power
               Source and Metering Relationships for the plugged in
               Electrical Equipment (the Energy Object Children)
             - Building management gateway, used as proxy for non IP
               protocols, is modeled as an Energy Object Parent with
               the Proxy Relationship, and potentially the Aggregation
               Relationship to the managed Electrical Equipment
             - Etc.
     
     The communication between the Energy Object Parent and Energy
     Object Children is out of the scope of this framework.
     
     5.3. Energy Object, Energy Object Components and Containment Tree
     
        The framework for Energy Management manages two different
        types of Energy Objects: Devices and Components. A typical
        example of an Device is a switch.  However, a port within the
        switch, which provides Power to one end point, is also an
        Energy Object if it meters the power provided.  A second
        example is PC, which is a typical Device, while the battery
        inside the PC is a Component, managed as an individual Energy
        Object.  Some more examples of Components: power supply within
        a router,  an outlet within a smart PDU, etc...
     
        In the [EMAN-AWARE-MIB], each Energy Object is managed with an
        unique value of the entPhysicalIndex index from the ENTITY-MIB
        [RFC4133]
     
        The ENTITY-MIB [RFC4133] specifies the notion of physical
        containment tree, as:
          "Each physical component may be modeled as 'contained'
          within
          another physical component.  A "containment-tree" is the
          conceptual sequence of entPhysicalIndex values that uniquely
          specifies the exact physical location of a physical
          component within the managed system.  It is generated by
          'following and recording' each 'entPhysicalContainedIn'
          instance 'up the tree towards the root', until a value of
          zero indicating no further containment is found."
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 37]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        A Energy Object Component in the Energy Management context is
        a special Energy Object that is a physical component as
        specified by the ENTITY-MIB physical containment tree.
     
     
     
     6. Framework High Level Concepts and Scope
     
        Energy Management can be organized into areas of concern that
        include:
     
        - Energy Object Identification and Context - for modeling and
        planning
        - Energy Monitoring - for energy measurements
        - Energy Control - for optimization
        - Energy Procurement - for optimization of resources
     
        While an EnMS may be a central point for corporate reporting,
        cost, environmental impact, and regulatory compliance, Energy
        Management in this framework excludes Energy procurement and
        the environmental impact of energy use.  As such the framework
        does not include:
        - Manufacturing costs of an Energy Object in currency or
        environmental units
        - Embedded carbon or environmental equivalences of an Energy
        Object
        - Cost in currency or environmental impact to dismantle or
        recycle an Energy Object
        - Supply chain analysis of energy sources for Energy Object
        deployment
        - Conversion of the usage or production of energy to units
        expressed from the source of that energy (such as the
        greenhouse gas emissions associated with 1000kW from a diesel
        source).
     
        The next sections describe Energy Management organized into
        the following areas:
     
         - Energy Object and Energy Management Domain
         - Energy Object Identification and Context
         - Energy Object Relationships
         - Energy Monitoring
         - Energy Control
         - Deployment Topologies
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 38]


     Internet-Draft           <EMAN Framework>        October 2012
     
     6.1. Energy Object and Energy Management Domain
     
        In building management, a meter refers to the meter provided
        by the utility used for billing and measuring power to an
        entire building or unit within a building.  A sub-meter refers
        to a customer or user installed meter that is not used by the
        utility to bill but instead used to get readings from sub
        portions of a building.
     
        An Energy Management Domain should map 1:1 with a metered or
        sub-metered portion of the site.  An Energy Object is part of
        a single Energy Management Domain.  The Energy Management
        Domain MAY be configured on an Energy Object: the default
        value is a zero-length string.
     
        If all Energy Objects in the physical containment tree (see
        ENTITY-MIB) are part of the same Energy Management Domain,
        then it is safe to state that the Energy Object at the root of
        that containment tree is in that Energy Management Domain.
     
        An Energy Object Child may inherit the domain value from an
        Energy Object Parent or the Energy Management Domain may be
        configured directly in an Energy Object Child.
     
     
     
     6.2. Power Interface
     
        There are some similarities between Power Interfaces and
        network interfaces.  A network interface can be used in
        different modes, such as sending or receiving on an attached
        line.  The Power Interface can be receiving or providing
        power.
     
        Most Power Interfaces never change their mode, but as the mode
        is simply a recognition of the current direction of
        electricity flow, there is no barrier to a mode change.
     
        A power interface can have capabilities for metering power and
        other electric quantities at the shared power transmission
        medium.
     
        This capability is modeled by an association to a power meter.
     
        In analogy to MAC addresses of network interfaces, a globally
        unique identifier is assigned to each Power Interface.
     
        Physically, a Power Interface can be located at an AC power
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 39]


     Internet-Draft           <EMAN Framework>        October 2012
     
        socket, an AC power cord attached to a device, an 8P8C (RJ45)
        PoE socket, etc.
     
     
     
     6.3. Energy Object Identification and Context
     
     6.3.1 Energy Object Identification
     
        Energy Objects MUST be associated with a value that uniquely
        identifies the Energy Object among all the Energy Management
        Domains within an EnMS.  A Universal Unique Identifier (UUID)
        [RFC4122] MUST be used to uniquely and persistently identify
        an Energy Object.
     
        Every Energy Object SHOULD have a unique printable name within
        the Energy Management Domain.  Possible naming conventions
        are: textual DNS name, MAC-address of the device, interface
        ifName, or a text string uniquely identifying the Energy
        Object.  As an example, in the case of IP phones, the Energy
        Object name can be the device's DNS name.
     
     
     
     6.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, i.e. the Energy Object Context.
     
     
     
     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 is more important than a
        PC and a phone for lobby use.
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 40]


     Internet-Draft           <EMAN Framework>        October 2012
     
        Although EnMS and administrators can establish their own
        ranking, the following is a broad recommendation:
     
        . 90 to 100 Emergency response
     
        . 80 to 90 Executive or business-critical
     
        . 70 to 79 General or Average
     
        . 60 to 69 Staff or support
     
        . 40 to 59 Public or guest
     
        . 1  to 39 Decorative or hospitality
     
     
     
     Context: Keywords
     
        An Energy Object can provide a set of keywords.  These
        keywords are a list of tags that can be used for grouping,
        summary reporting within or between Energy Management Domains,
        and for searching.  All alphanumeric characters and symbols
        (other than a comma), such as #, (, $, !, and &, are allowed.
        Potential examples are: IT, lobby, HumanResources, Accounting,
        StoreRoom, CustomerSpace, router, phone, floor2, or
        SoftwareLab.  There is no default value for a keyword.
     
        Multiple keywords can be assigned to a device.  White spaces
        before and after the commas are excluded, as well as within a
        keyword itself. In such cases, the keywords are separated by
        commas and no spaces between keywords are allowed.  For
        example, "HR,Bldg1,Private".
     
     
     
     Context: Role
     
        An Energy Object can provide a "role description" string that
        indicates the purpose the Energy Object serves in the EnMS.
        This could be a string describing the context the device
        fulfills in deployment.
     
        Administrators can define any naming scheme for the role of a
        device.  As guidance a two-word role that combines the service
        the device provides along with type can be used [IPENERGY]
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 41]


     Internet-Draft           <EMAN Framework>        October 2012
     
        Example types of devices: Router, Switch, Light, Phone,
        WorkStation, Server, Display, Kiosk, HVAC.
     
        Example Services by Line of Business:
     
          Line of Business     Service
     
           Education            Student, Faculty, Administration,
                                Athletic
     
          Finance              Trader, Teller, Fulfillment
     
          Manufacturing        Assembly, Control, Shipping
     
          Retail               Advertising, Cashier
     
          Support              Helpdesk, Management
     
          Medical              Patient, Administration, Billing
     
        Role as a two-word string: "Faculty Desktop", "Teller Phone",
        "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
        "Administration Switch".
     
     
     
     6.4. Energy Object Relationships
     
        Two Energy Objects MAY establish an Energy Object
        Relationship. Within a relationship one Energy Object becomes
        an Energy Object Parent while the other becomes an Energy
        Object Child.
     
        The Power Source Relationship gives the view the wiring
        topology.  For example: a data center server receiving power
        from two specific Power Interfaces from two different PDUs.
     
        The Metering Relationship gives the view of the metering
        topology.  Standalone meters can be placed anywhere in a power
        distribution tree.  For example, utility meters monitor and
        report accumulated power consumption of the entire building.
        Logically, the metering topology overlaps with the wiring
        topology, as meters are connected to the wiring topology.  A
        typical example is meters that clamp onto the existing wiring.
     
        The Proxy Relationship allows software objects to be inserted
        into the wiring or metering topology to aid in managing
        (monitoring and/or control) the Energy Domain.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 42]


     Internet-Draft           <EMAN Framework>        October 2012
     
        From a EnMS management point of view, this implies that there
        is yet another management topology that EnMS will need to be
        aware of.
     
        In the ideal situation, the wiring, the metering, and the
        management topologies overlap.  For Example: A Power-over-
        Ethernet (PoE) device (such as an IP phone or an access point)
        is attached to a switch port.  The switch port is the source
        of power for the attached device, so the Energy Object Parent
        is the switch port, which acts as a Power Interface, and the
        Energy Object Child is the device attached to the switch.
        This Energy Object Parent (the switch) has three Energy Object
        Relations with this Energy Object Child (the remote Energy
        Object): Power Source Relationship, Metering Relationship, and
        Proxy Relationship.
     
        However, the three topologies (wiring, metering, and
        management) don't always overlap.  For example, when a
        protocol gateways device for Building Management Systems (BMS)
        controls subtended devices, which themselves receive Power
        from PDUs or wall sockets.
     
        Note: The Aggregation Relationship is slightly different
        compared to the other relationships (Power Source, Metering,
        and Proxy Relationships) as this refers more to a management
        function.
     
        The communication between the parent and child for monitoring
        or collection of power data is left to the device
        manufacturer.  For example: A parent switch may use LLDP to
        communicate with a connected child, and a parent lighting
        controller may use BACNET to communicate with child lighting
        devices.
     
        The Energy Object Child MUST keep track of its Energy Object
        Parent(s) along with the Energy Object Relationships type(s).
        The Energy Object Parent MUST keep track of its Energy Object
        Child(ren), along with the Energy Object Relationships
        type(s).
     
     
     
     6.4.1 Energy Object Children Discovery
     
        There are multiple ways that the Energy Object Parent can
        discover its Energy Object Children: :
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 43]


     Internet-Draft           <EMAN Framework>        October 2012
     
          . In case of PoE, the Energy Object Parent automatically
             discovers an Energy Object Child when the Child requests
             power.
          . The Energy Object Parent and Children may run the Link
             Layer Discovery Protocol [LLDP], or any other discovery
             protocol, such as Cisco Discovery Protocol (CDP).  The
             Energy Object Parent might even support the LLDP-MED MIB
             [LLDP-MED-MIB], which returns extra information on the
             Energy Object Children.
          . The Energy Object Parent may reside on a network
             connected to a facilities gateway.  A typical example is
             a converged building gateway, monitoring several other
             devices in the building, and serving as a proxy between
             SNMP and a protocol such as BACNET.
          . A different protocol between the Energy Object Parent and
             the Energy Object Children.  Note that the communication
             specifications between the Energy Object Parent and
             Children is out of the scope of this document.
     
        However, in some situations, it is not possible to discover
        the Energy Object Relationships, and they must be set
        manually.  For example, in today' network, an administrator
        must assign the connected Energy Object to a specific PDU
        Power Interface, with no means of discovery other than that
        manual connection.
     
     
        When an Energy Object Parent is a Proxy, the Energy Object
        Parent SHOULD enumerate the capabilities it is providing for
        the Energy Object Child.  The child would express that it
        wants its parent to proxy capabilities such as, energy
        reporting, power state configurations, non physical wake
        capabilities (such as WoL)), or any combination of
        capabilities.
     
     
     6.4.2 Energy Object Relationship Conventions and Guidelines
     
     
        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".
     
        Aggregation
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 44]


     Internet-Draft           <EMAN Framework>        October 2012
     
        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 form 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 form the use of Power Inlets, outlet and Energy
        Object value son the same device.
     
        Additionally since an EnMS is naturally a point of aggregation
        for information in an Energy Management Domain it is not
        necessary to model aggregation for an EnMS(s).
     
        Aggregation SHOULD be used for power and energy. It MAY be
        used for aggregation of other values from the information
        model for example but the rules and logical ability to
        aggregated 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 the an EnMS.
        - Aggregators SHOULD log or provide notification in the case
          of errors or missing values while performing aggregation.
     
     
        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 the 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.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 45]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        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 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 As such 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 examples if an Energy Object A has a Power
          Source Relationship "Poweredby" with the Energy Object B,
          and if the Energy Object B has a Power Source Relationship
          "Poweredby" with the Energy Object C, then the Energy Object
          A SHOULD NOT have a Power Source Relationship "PoweredBby"
          the Energy Object C.
     
        Metering Relationship
     
        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.
     
        Additionally, Devices may include metering hardware for
        components and Power Interfaces or for the entire Device.
     
        For example some PDU's may have the ability to measure Power
        for each Power Interface (metered by outlet). Others may only
        be able to control power at each Power Interface but 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.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 46]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        - A Meter Relationship MAY be established with any other
          Energy Object, Component, or Power Interface.
        - Transitive Meter relationships MAY be used.
        - When there is a series of meters for one Enegry Object, the
          Energy Object MAY establish a relationship with one or more
          of the meters.
     
        Proxy
     
        A Proxy relationship is intended to show when one Device is
        providing the Energy Object capabilities for another Device
        typically for protocol translations. Strictly speaking a  a
        Component of a Device may provide the Energy Object
        capabilities for that Device (and vice versa) this
        relationship is intended to model relationships between
        Devices.
     
        - A Proxy relationship SHOULD be limited when possible to
          Energy Objects of different Devices.
     
     6.4.3 Energy Objects Relationship Extensions
     
        This framework for Energy Management, is based on four Energy
        Objects Relationships: Aggregation Relationship, Metering
        Relationship, Power Source Relationship, and Proxy
        Relationship.
     
        This framework is defined with possible extension of new
        Energy Objects Relationships in mind.  For example, a Power
        Distribution Unit (PDU) that allows physical entities like
        outlets to be "ganged" together as a logical entity for
        simplified management purposes, could be modeled with a future
        extension based on "gang relationship", whose semantic would
        specify the Energy Objects grouping.
     
     
     
     6.5. Energy Monitoring
     
        For the purposes of this framework energy will be limited to
        electrical energy in watt hours.  Other forms of Energy
        Objects that use or produce non-electrical energy may be part
        of an Energy Management Domain (See Section 4.5. )  but MUST
        provide information converted to and expressed in watt hours.
     
        An analogy for understanding power versus energy measurements
        can be made to speed and distance in automobiles. Just as a
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 47]


     Internet-Draft           <EMAN Framework>        October 2012
     
        speedometer indicates the rate of change of distance, 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 accumulate energy transferred.
        So a less formal statement of the analogy is that power meters
        measures "speed" while energy meters measure "distance".
     
        Each Energy Object will have information that describes power
        information, along with how that measurement was obtained or
        derived (actual measurement, estimated, or presumed).  For
        Energy Objects that can report actual power readings, an
        optional energy measurement can be provided.
     
        Optionally, an Energy Object can further describe the Power
        information with Power Quality information reflecting the
        electrical characteristics of the measurement.
     
        Optionally, an Energy Object that can report actual power
        readings can have energy meters that provide the energy used,
        produced, and net energy in kWh. These values are energy
        meters that accumulate the power readings.  If energy values
        are returned then the three energy meters must be provided
        along with a description of accuracy.
     
        Optionally, an Energy Object can provide demand information
        over time.
     
     
     
     6.5.1 Power Measurement
     
        A power measurement MUST be qualified with the units,
        magnitude, direction of power flow, and SHOULD be qualified by
        what means the measurement was made (ex: Root Mean Square
        versus Nameplate).
     
        In addition, the Energy Object should describe how it intends
        to measure power as one of consumer, producer or meter of
        usage.  Given the intent, readings can be summarized or
        analyzed by an EnMS.  For example metered usage reported by a
        meter and consumption usage reported by a device connected to
        that meter may naturally measure the same usage.  With the two
        measurements identified by intent a proper summarization can
        be made by an EnMS.
     
        Power measurement magnitude should conform to the IEC 61850
        definition of unit multiplier for the SI (System
        International) units of measure.  Measured values are
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 48]


     Internet-Draft           <EMAN Framework>        October 2012
     
        represented in SI units obtained by BaseValue * (10 ^ Scale).
        For example, if current power usage of an Energy Object is 3,
        it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value
        of the scaling factor.  3W implies that the BaseValue is 3 and
        Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor =
        -3.
     
        Energy is often billed in kilowatt-hours instead of megajoules
        from the SI units.  Similarly, battery charge is often
        measured as miliamperes-hour (mAh) instead of coulombs from
        the SI units.  The units used in this framework are: W, A, Wh,
        Ah, V.  A conversion from Wh to Joule and from Ah to Coulombs
        is obviously possible, and can be described if required.
     
        In addition to knowing the usage and magnitude, it is useful
        to know how an Energy Object usage measurement was obtained:
     
        . Whether the measurements were made at the device itself or
        from a remote source.
     
        . Description of the method that was used to measure the
        power and whether this method can distinguish actual or
        estimated values.
     
        An EnMS can use this information to account for the accuracy
        and nature of the reading between different implementations.
     
        The EnMS can use the Nameplate Power for provisioning,
        capacity planning and potentially billing.
     
     
     
     6.5.2 Optional Power Quality
     
        Given a power measurement, it may in certain circumstances be
        desirable to know the Power Quality associated with that
        measurement.  The information model must adhere to the IEC
        61850 7-2 standard for describing AC measurements.  Note that
        the Power Quality includes two sets of characteristics:
        characteristics as received from the utility, and
        characteristics depending on how the power is used.
     
        In some Energy Management Domains, the power quality may not
        be needed, available, or relevant to the EnMS.
     
        Optional Demand
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 49]


     Internet-Draft           <EMAN Framework>        October 2012
     
        It is well known in commercial electrical utility rates that
        demand is part of the calculation for billing.  The highest
        peak demand measured over a time horizon, such as 1 month or 1
        year, is often the basis for charges.  A single window of time
        of high usage can penalize the consumer with higher energy
        consumption charges.  However, it is relevant to measure the
        demand only when there are actual power measurements from an
        Energy Object, and not when the power measurement is assumed
        or predicted.
     
        Optional Battery
     
        Some Energy Objects may use batteries for storing energy and
        for receiving power supply.  These Energy Objects should
        report their current power supply (battery, power line, etc.)
        and the battery status for each contained battery.   Battery-
        specific information to be reported should include the number
        of batteries contained in the device and per battery the state
        information as defined in [EMAN-REQ].
     
        Beyond that a device containing a battery should be able to
        generate alarms when the battery charge falls below a given
        threshold and when the battery needs to be replaced.
     
     
     
     6.6. Energy Control
     
        An Energy Object can be controlled by setting it to a specific
        Power State.  An Object implements a set of Power States
        consisting of at least two states, an on state and an off
        state.
     
        A Power State is an interface by which an Energy Object can be
        controlled.  Each Energy Object should indicate the set of
        Power States that it implements.  Well known Power States /
        Sets should be 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 desired.
     
        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
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 50]


     Internet-Draft           <EMAN Framework>        October 2012
     
        [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI],
        and PWG define larger numbers of Power States.
     
        The semantics of a power state is 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 can 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: by stating used power in state A is less
        than in state B.
     
        For supporting Power State management it is useful to provide
        statistics on Power States including the time an Energy Object
        spent in a certain Power State and/or the number of times an
        Energy Object entered a power state.
     
        Power States should be registered at IANA with a name and a
        number.
     
        When requesting an Energy object to enter a Power State an
        indication of its name or its 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.
     
     6.6.1 EMAN Power State Set
     
        An EMAN Power State Set represents an attempt for a standard
        approach to model the different levels of power of a device.
        The EMAN Power States are an expansion of the basic Power
        States as defined in [IEEE1621] that also incorporates the
        Power States defined in [ACPI] and [DMTF].  Therefore, in
        addition to the non-operational states as defined in [ACPI]
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 51]


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


     Internet-Draft           <EMAN Framework>        October 2012
     
        This mode is analogous to cold-standy.  The time for
        availability is longer than ready(6).  For example, the
        processor context is not maintained. Typically, energy
        consumption is close to zero.  This corresponds to state G1,
        S2 in ACPI.
     
                 ready(6)    : No Energy Object features are
        available, except for out-of-band management, such as wake-up
        mechanisms. This mode is analogous to hot-standby.  The Energy
        Object can be quickly transitioned into an operational state.
        For example, processors are not executing, but processor
        context is maintained.  This corresponds to state G1, S1 in
        ACPI.         lowMinus(7) : Indicates some Energy Object
        features may not be available and the Energy Object has
        selected measures/options to provide less than low(8) usage.
        This corresponds to ACPI State G0.  This includes operational
        states lowMinus(7) to full(12).
     
                 low(8)      : Indicates some features may not be
        available and the Energy Object has taken measures or selected
        options to provideless than mediumMinus(9) usage.
     
                 mediumMinus(9): Indicates all Energy Object features
        are available but the Energy Object has taken measures or
        selected options to provide less than medium(10) usage.
     
                 medium(10)  : Indicates all Energy Object features
        are available but the Energy Object has taken measures or
        selected options to provide less than highMinus(11) usage.
     
                 highMinus(11): Indicates all Energy Object features
        are available and power usage is less than high(12).
     
                 high(12)    : Indicates all Energy Object features
        are available and the Energy Object is consuming the highest
        power.
     
        A comparison of Power States 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)
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 53]


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


     Internet-Draft           <EMAN Framework>        October 2012
     
        |  roleDescription : string |   |  mgmtMacAddress : octets   |
        |  keywords[0..n] : string  |   |  mgmtAddress : inetaddress |
        |  importance : int         |   |  mgmtAddressType : enum    |
        |  category :  enum         |   |  mgmtDNSName : inetaddress |
        +---------------------------+   +----------------------------+
                  |                            |
                  |                            |
                  |                            |
                  v                            v
          +-----------------------------------------+
          |  Energy Object Information              |
          |-----------------------------------------|
          | index : int                             |
          | energyObjectId | UUID                   |
          | name : string                           |
          | meterDomainName | string                |
          | alternateKey | string                   |
          +-----------------------------------------+
                  ^
                  |
                  |
                  |
        +-------------------------+
        |    Links Object         |
        |-------------------------|
        |  physicalEntity : int   |
        |  ethPortIndex : int     |
        |  ethPortGrpIndex : int  |
        |  lldpPortNumber : int   |
        +-------------------------+
     
     
     
                     EO AND MEASUREMENTS
     
     
        +-----------------------------------------------+
        |                 Energy Object                 |
        |-----------------------------------------------|
        |  nameplate : Measurement                      |
        |  battery[0..n]: Battery                       |
        |  measurements[0..n]: Measurement              |
        | --------------------------------------------- |
        | Measurement instantaneousUsage()              |
        | DemandMeasurement historicalUsage()           |
        +-----------------------------------------------+
     
          +-----------------------------------+
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 55]


     Internet-Draft           <EMAN Framework>        October 2012
     
          |  Measurements                     |
          | __________________________________|
          +-----------------------------------+
                            ^
                            |
                            |
         +------------------+----------------------------+
         |         PowerMeasurement                      |
         |-----------------------------------------------|
         | value : long                                  |
         | rate : enum {0,millisecond,seconds,           |
         |              minutes,hours,...}               |
         | multiplier : enum {-24..24}                   |
         | units : "watts"                               |
         | caliber : enum { actual, estimated,           |
         |                  trusted, assumed...}         |
         | accuracy : enum { 0..10000}                   |
         | current :  enum {AC, DC}                      |
         | origin : enum { self, remote }                |
         | time : timestamp                              |
         | quality : PowerQuality                        |
         +-----------------------------------------------+
                            |
                            |
         +------------------+----------------------------+
         |         EnergyMeasurement                     |
         |-----------------------------------------------|
         | consumed : long                               |
         | generated : long                              |
         | net : long                                    |
         | accuracy : enum { 0..10000}                   |
         +-----------------------------------------------+
     
     
         +-----------------------------------------------+
         |         TimeMeasurement                       |
         |-----------------------------------------------|
         | startTime : timestamp                         |
         | usage : Measurement                           |
         | maxUsage : Measurement                        |
         +-----------------------------------------------+
                            |
                            |
         +----------------------------------------+
         |        TimeInterval                    |
         |--------------------------------------- |
         |value : long                            |
         |units : enum { seconds, miliseconds..}  |
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 56]


     Internet-Draft           <EMAN Framework>        October 2012
     
         +----------------------------------------+
                            |
                            |
         +----------------------------------------+
         |        DemandMeasurement               |
         |----------------------------------------|
         |intervalLength :  TimeInterval          |
         |intervalNumbers: long                   |
         |intervalMode :  enum { period, sliding, |
         |total }                                 |
         |intervalWindow : TimeInterval           |
         |sampleRate : TimeInterval               |
         |status : enum {active, inactive }       |
         |measurements : TimedMeasurement[]       |
         +----------------------------------------+
     
     
     
     
     
     
     
                       QUALITY
     
         +----------------------------------------+
         |            PowerQuality                |
         |----------------------------------------|
         |                                        |
         +----------------------------------------+
                            ^
                            |
                            |
         +------------------+--------------------+
         |         ACQuality                     |
         |---------------------------------------|
         | acConfiguration : enum {SNGL, DEL,WYE}|
         | avgVoltage   : long                   |
         | avgCurrent   : long                   |
         | frequency    : long                   |
         | unitMultiplier  : int                 |
         | accuracy  : int                       |
         | totalActivePower  : long              |
         | totalReactivePower : long             |
         | totalApparentPower : long             |
         | totalPowerFactor : long               |
         +---------+-----------------------------+
                   | 1
                   |
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 57]


     Internet-Draft           <EMAN Framework>        October 2012
     
                   |
                   |
                   |        +------------------------------------+
                   |        |         ACPhase                    |
                   |     *  |------------------------------------|
                   +--------+ phaseIndex : long                  |
                            | avgCurrent : long                  |
                            | activePower : long                 |
                            | reactivePower : long               |
                            | apparentPower : long               |
                            | powerFactor : long                 |
                            +------------------------------------+
                                        ^           ^
                                        |           |
                                        |           |
                                        |           |
                                        |           |
        +-------------------------------+---+       |
        |        DelPhase                   |       |
        |-----------------------------------|       |
        |phaseToNextPhaseVoltage  : long    |       |
        |thdVoltage : long                  |       |
        |thdCurrent : long                  |       |
        +-----------------------------------+       |
                                                    |
                                 +------------------+-----------+
                                 |        WYEPhase              |
                                 |------------------------------|
                                 |phaseToNeutralVoltage : long  |
                                 |thdCurrent : long             |
                                 |thdVoltage : long             |
                                 +------------------------------+
     
     
     
     
     
                           EO & STATES
     
           +----------------------------------------------+
           |             Energy Object                    |
           |----------------------------------------------|
           | currentLevel : int                           |
           | configuredLevel : int                        |
           | configuredTime : timestamp                   |
           | reason: string                               |
           | emanLevels[0..11] : State                    |
           | levelMappings[0..n] : LevelMapping           |
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 58]


     Internet-Draft           <EMAN Framework>        October 2012
     
           +----------------------------------------------+
     
            +-------------------------------+
            |        State                  |
            |-------------------------------|
            | name : string                 |
            | cardinality : int             |
            | maxUsage : Measurement        |
            +-------------------------------+
     
     
     
     
     
               Figure 17: Information Model UML Representation
     
     
     8. Configuration
     
        This power management framework allows the configuration of
        the following key parameters:
     
     
          . Energy Object name: A unique printable name for the
             Energy Object.
          . Energy Object role: An administratively assigned name to
             indicate the purpose an Energy Object serves in the
             network.
          . Energy Object importance: A ranking of how important the
             Energy Object is, on a scale of 1 to 100, compared with
             other Energy Objects in the same Energy Management
             Domain.
          . Energy Object keywords: A list of keywords that can be
             used to group Energy Objects for reporting or searching.
          . Energy Management Domain: Specifies the name of an Energy
             Management Domain for the Energy Object.
          . Energy Object Power State: Specifies the current Power
             State for the Energy Object.
          . Demand parameters: For example, which interval length to
             report the Demand over, the number of intervals to keep,
             etc.
          . Assigning an Energy Object Parent to an Energy Object
             Child
          . Assigning an Energy Object Child to an Energy Object
             Parent.
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 59]


     Internet-Draft           <EMAN Framework>        October 2012
     
        This framework supports multiple means for setting the Power
        State of a specific Energy Objects. However, the Energy Object
        might be busy executing an important task that requires the
        current Power State for some more time.  For example, a PC
        might have to finish a backup first, or an IP phone might be
        busy with a current phone call.  Therefore a second value
        contains the actual Power State.  A difference in values
        between the two objects indicates that the Energy Object is
        currently in Power State transition.
     
        Other, already well established means for setting Power
        States, such as DASH [DASH], already exist.  Such a protocol
        may be implemented between the Energy Object Parent and the
        Energy Object Child, when the Energy Object Parent acts as a
        Proxy.  Note that the Wake-up-on-Lan (WoL) mechanism allows to
        transition a device out of the Off Power State.
     
     
     
     9. Fault Management
     
        [EMAN-REQ] specifies some requirements about Power States such
        as "the current state - the time of the last change", "the
        total time spent in each state", "the number of transitions to
        each state", etc.  Such requirements are fulfilled via the
        pmPowerStateChange NOTIFICATION-TYPE [EMAN-MON-MIB].  This
        SNMP notification is generated when the value(s) of Power
        State has changed for the Energy Object.
     
        Regarding high and low thresholding mechanism, the RMON alarm
        and event [RFC2819] allows to periodically takes statistical
        samples from Energy Object variables, compares them to
        previously configured thresholds, and to generate an event
        (i.e. an SNMP notification) if the monitored variable crosses
        a threshold. The RMON alarm can monitor variables that resolve
        to an ASN.1 primitive type of INTEGER (INTEGER, Integer32,
        Counter32, Counter64, Gauge32, or TimeTicks), so basically
        most the variables in [EMAN-MON-MIB].
     
     
     10. Examples
     
     
        In this section we will give examples of how to use the Energy
        Management framework.  In each example we will show how it can
        be applied when Devices have the capability to model Power
        Interfaces.  We will also show in each example how the
        framework can be applied when devices cannot support Power
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 60]


     Internet-Draft           <EMAN Framework>        October 2012
     
        Interfaces but only monitor information or control the Device
        as a whole. For instance a PDU may only be able to measure
        power and energy for the entire unit without the ability to
        distinguish among the inlets or outlet.
     
        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 inlets 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.
     
     
     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:
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 61]


     Internet-Draft           <EMAN Framework>        October 2012
     
          In this case Device W has an Energy Object representing the
          computer.  Device Y would have an Energy Object representing
          the PDU.
     
          The devices would have a Power Source Relationship such
          that:
          Device W is powered by Device Y.
     
     
     Example II: Multiple Inlets
     
     
        Topology:
          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 Interface 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 Interface 1..10 defined as outlets.
     
     
          The interfaces of the devices would have a Power Source
          Relationship such that:
          Device X inlet 1 is powered by Device Y outlet 8
          Device X inlet 2 is powered by Device Y outlet 9
     
        Without Power Interfaces:
     
          In this case Device X has an Energy Object representing the
          computer. Device Y would have an Energy Object representing
          the PDU.
     
          The devices would have a Power Source Relationship such
          that:
          Device X is powered by Device Y.
     
     
     Example III: Multiple Sources
     
     
        Topology:
          Device X inlet 1 is plugged into Device Y outlet 8.
          Device X inlet 2 is plugged into Device Z outlet 9
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 62]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        With Power Interfaces:
     
          Device X has an Energy Object representing the computer
          itself. It contains two Power Interface defined as inlets.
     
          Device Y would have an Energy Object representing the PDU
          itself  (the Device) with a Power Interface 0 defined as an
          inlet and Power Interface 1..10 defined as outlets.
     
          Device Z would have an Energy Object representing the PDU
          itself  (the Device) with a Power Interface 0 defined as an
          inlet and Power Interface 1..10 defined as outlets.
     
          The interfaces of the devices would have a Power Source
          Relationship such that:
          Device X inlet 1 is powered by Device Y outlet 8
          Device X inlet 2 is powered by Device Z outlet 9
     
        Without Power Interfaces:
     
          In this case Device X has an Energy Object representing the
          computer. Device Y and Z would both have respective Energy
          Objects representing each entire PDU.
     
          The devices would have a Power Source Relationship such
          that:
          Device X is powered by Device Y and powered by Device Z.
     
     
     
     11. Relationship with Other Standards Development Organizations
     
     11.1. Information Modeling
     
        This power management framework should, as much as possible,
        reuse existing standards efforts, especially with respect to
        information modeling and data modeling [RFC3444].
     
        The data model for power and energy related objects is based
        on IEC 61850.
     
        Specific examples include:
     
          . The scaling factor, which represents Energy Object usage
             magnitude, conforms to the IEC 61850 definition of unit
             multiplier for the SI (System International) units of
             measure.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 63]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
          . The electrical characteristic is based on the ANSI and
             IEC Standards, which require that we use an accuracy
             class for power measurement.  ANSI and IEC define the
             following accuracy classes for power measurement:
     
             . IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
     
             . ANSI C12.20 class 0.2, 0.5
     
          . The electrical characteristics and quality adheres
             closely to the IEC 61850 7-2 standard for describing AC
             measurements.
     
          . The power state definitions are based on the DMTF Power
             State Profile and ACPI models, with operational state
             extensions.
     
     
     12. Security Considerations
     
        Regarding the data attributes specified here, some or all may
        be considered sensitive or vulnerable in some network
        environments. Reading or writing these attributes without
        proper protection such as encryption or access authorization
        may have negative effects on the network capabilities.
     12.1 Security Considerations for SNMP
     
        Readable objects in a MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered sensitive
        or vulnerable in some network environments.  It is thus
        important to control GET and/or NOTIFY access to these objects
        and possibly to encrypt the values of these objects when
        sending them over the network via SNMP.
     
        The support for SET operations in a non-secure environment
        without proper protection can have a negative effect on
        network operations.  For example:
     
          . Unauthorized changes to the Power Domain or business
             context of an Energy Object may result in misreporting or
             interruption of power.
          . Unauthorized changes to a power state may disrupt the
             power settings of the different Energy Objects, and
             therefore the state of functionality of the respective
             Energy Objects.
          . Unauthorized changes to the demand history may disrupt
             proper accounting of energy usage.
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 64]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        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.
     
     
     
     13. IANA Considerations
     
     
        AUTHORS NOTE: Section needs to be modified to reflect Power
        States text introduce in version 06
     
        Initial values for the Power State Sets, together with the
        considerations for assigning them, are defined in [EMAN-MON-
        MIB].
     
     
     
     14. Acknowledgments
     
        The authors would like to Michael Brown for improving the text
        dramatically, and Rolf Winter for his feedback.  The award for
        the best feedback and reviews goes to Bill Mielke.
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 65]


     Internet-Draft           <EMAN Framework>        October 2012
     
     15. References
     
     Normative References
     
     
        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
     
        [RFC2819]  S. Waldbusser, "Remote Network Monitoring
                Management Information Base", STD 59, RFC 2819, May
                2000
     
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for
                Internet Standard Management Framework ", RFC 3410,
                December 2002.
     
        [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB
                (Version3)", RFC 4133, August 2005.
     
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally
                Unique IDentifier (UUID) URN Namespace", RFC 4122,
                July 2005
     
     Informative References
     
     
        [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                "Structure of Management Information Version 2
                (SMIv2", RFC 2578, April 1999
     
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
                between Information Models and Data Models", RFC
                3444, January 2003.
     
        [RFC5101] B. Claise, Ed., Specification of the IP Flow
                Information Export (IPFIX) Protocol for the Exchange
                of IP Traffic Flow Information, RFC 5101, January
                2008.
     
        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling Language
                for the Network Configuration Protocol (NETCONF)",
                RFC 6020, October 2010.
     
        [ACPI] "Advanced Configuration and Power Interface
                Specification", http://www.acpi.info/spec30b.htm
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 66]


     Internet-Draft           <EMAN Framework>        October 2012
     
        [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-09, (work
                in progress), November 2011.
     
        [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
                Networks and Devices MIB", draft-ietf-eman-energy-
                aware-mib-07, (work in progress), February 2012.
     
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                Dietz, T., and B. Claise, "Power and Energy
                Monitoring MIB", draft-ietf-eman-energy-monitoring-
                mib-03, (work in progress), March 2012.
     
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                Definition of Managed Objects for Battery
                Monitoring", draft-ietf-eman-battery-mib-06, (work in
                progress), March 2012.
     
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
                "Energy Management (EMAN) Applicability Statement",
                draft-ietf-eman-applicability-statement-02, (work in
                progress), October 2011
     
        [EMAN-TERMINOLOGY] J. Parello, "Energy Management
                Terminology", draft-parello-eman-definitions-06,
                (work in progress), March 2012
     
        [ITU-T-M-3400] TMN recommandation on Management Functions
                (M.3400), 1997
     
        [NMF] "Network Management Fundamentals", Alexander Clemm,
                ISBN: 1-58720-137-2, 2007
     
        [TMN] "TMN Management Functions : Performance Management",
                ITU-T M.3400
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 67]


     Internet-Draft           <EMAN Framework>        October 2012
     
     
        [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
     
        [DASH] "Desktop and mobile Architecture for System Hardware",
                http://www.dmtf.org/standards/mgmt/dash/
     
        [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
     
        [SQL] ISO/IEC 9075(1-4,9-11,13,14):2008
     
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                2009 - IEEE Standard for Information technology -
                Telecommunications and information exchange between
                systems - Local and metropolitan area networks -
                Specific requirements - Part 3: Carrier Sense
                Multiple Access with Collision Detection (CSMA/CD)
                Access Method and Physical Layer Specifications -
                Amendment: Data Terminal Equipment (DTE) -  Power via
                Media Dependent Interface (MDI) Enhancements",
                   October 2009.
     
        [DMTF] "Power State Management Profile DMTF  DSP1027  Version
                2.0"  December 2009
                http://www.dmtf.org/sites/default/files/standards/doc
                uments/DSP1027_2.0.0.pdf
     
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
                Management", 2010, Wiley Publishing
     
        [X.700]  CCITT Recommendation X.700 (1992), Management
                framework for Open Systems Interconnection (OSI) for
                CCITT applications.
     
        [ASHRAE-201] "ASHRAE Standard Project Committee 201
                        (SPC 201)Facility Smart Grid Information
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 68]


     Internet-Draft           <EMAN Framework>        October 2012
     
                        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
     
     
     
     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
     
      Phone:
      Email: brad.schoening@verizon.net
     
     
     Juergen Quittek
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Germany
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 69]


     Internet-Draft           <EMAN Framework>        October 2012
     
     Phone: +49 6221 90511 15
     EMail: quittek@netlab.nec.de
     
     
     Bruce Nordman
     Lawrence Berkeley National Laboratory
     1 Cyclotron Road
     Berkeley  94720
     US
     
     Phone: +1 510 486 7089
     Email: bnordman@lbl.gov
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires Mar 12,2013         [Page 70]
     

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/