[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: January 8, 2012                            B. Schoening
                                                Independent Consultant
                                                            J. Quittek
                                                       NEC Europe Ltd.
                                                         July 8, 2011
     
     
                         Energy Management Framework
                        draft-ietf-eman-framework-02
     
     
     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 October, 2011.
     
     
     
     
     
     
     
     
     
     
     
     
     Internet-Draft             <EMAN Framework>            July 2011
     
     Copyright Notice
     
        Copyright (c) 2011 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.  The framework defines a domain of Energy Management
        devices that is a logical unit of Energy Management. Within a
        domain each device is identified, classified and given context.
        Devices can be monitored and/or controlled with respect to
        power, power state, energy, demand, electrical quality, and
        battery.  Additionally the framework models relationships and
        capabilities between devices in a domain.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 2]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
     Table of Contents
     
        1. Introduction........................................... 4
           1.1. Energy Management Document Overview............... 4
        2. Requirements & Use Cases............................... 5
        3. Terminology............................................ 6
        4. Energy Management Reference Model..................... 11
        5. Framework High Level Concepts and Scope............... 14
           5.1. Energy Managed Object and Energy Management Domain15
           5.2. Energy Managed Object Identification and Context. 15
              5.2.1 Identification .............................. 15
              5.2.2 Context in General .......................... 16
              5.2.3 Context: Importance ......................... 16
              5.2.4 Context: Keywords............................ 17
              5.2.5 Context: Role ............................... 18
           5.3. Energy Managed Object Relationships.............. 18
              5.3.1 Energy Managed Object Children Discovery .... 19
           5.4. Energy Monitoring ............................... 19
           5.5. Energy Control................................... 22
              5.5.1 IEEE1621 Power State Series ................. 22
              5.5.2 DMTF Power State Series...................... 23
              5.5.3 EMAN Power State Series...................... 24
        6. Structure of the Information Model: UML Representation 28
        7. Configuration ........................................ 33
        8. Fault Management ..................................... 34
        9. Relationship with Other Standards Development
        Organizations............................................ 35
           9.1. Information Modeling............................. 35
        10. Security Considerations.............................. 35
        10.1. Security Considerations for SNMP .................. 36
        11. IANA Considerations ................................. 37
        12. Acknowledgments ..................................... 37
        13. References .......................................... 37
           Normative References ................................. 37
           Informative References ............................... 37
     
     
     
        TO DO/OPEN ISSUE
        - IPFIX or not? Initially IPFIX was mentioned in [EMAN-REQ],
        then we see now: "A solution for this is that the concerned
        entity or another entity closely interacting with the concerned
        entity collect time series of power values and make them
        available via push or pull mechanisms to receivers of the
        information.". So, the questions are: Is IPFIX a requirement?
        What other mechanism do we have to PUSH time series of power
     
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 3]


     Internet-Draft             <EMAN Framework>            July 2011
     
        values (no, SNMP notifications are not suitable)? So should we
        or not include IPFIX in this document?
        - Power Monitor has been renamed to Energy Managed Object. Get
          consensus on the terminology. Another example is Power
          Quality
        - A couple of EDITOR'S NOTES in the draft
     
     
     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).   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].
     
        This document defines a framework for providing Energy
        Management for devices within or connected to communication
        networks.  The framework describes how to identity, classify and
        provide context for a device in a communications network from
        the point of view of Energy Management.
     
        The identified device can then be monitored for Energy
        Management by obtaining measurements for power, energy, demand
        and electrical quality.  If a device contains a battery(s) the
        characteristics and performance of the battery(s) can also be
        managed.  A device's 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
        device reporting information about itself.  However, in many
        cases, energy is not measured by the device itself, but by a
        meter located upstream in the power distribution tree.  An
        example is a power distribution unit (PDU) that measures energy
        consumption of attached devices and may report this to an Energy
        Management System.  Therefore, devices are recognized as having
        relationships to other devices in the network from the point of
        view of Energy Management.  These relationships include
        Aggregation, Metering, Power Source(s), Proxy, and Dependency.
     
     
     1.1. Energy Management Document Overview
     
     
        The EMAN standard provides a set of specifications that together
        provide Energy Management.  This document specifies the
        framework, per the Energy Management requirements specified in
        [EMAN-REQ]
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 4]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
        The applicability statement document [EMAN-AS] provides a list
        of use cases, cross-reference between existing standards and the
        EMAN standard, and shows how the this relates to other
        frameworks.
     
        The [EMAN-AWARE-MIB] provides objects for addressing
        identification, classification, context information, and
        relationships form the point of view of Energy Management.
     
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains
        objects for monitoring of Power, Energy, Demand, Electrical
        Quality and Power State Sets.
     
        Definition of Managed Objects for Battery Monitoring [EMAN-
        BATTERY-MIB] defines managed objects that provide information on
        the status of batteries in managed devices.
     
        EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
        group documents.  Hence, these references will be changed in the
        future.
     
     2. 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.
     
        For example, target devices for this specification can include
        (but are not limited to):
            - Simple electrical appliances / fixtures
            - Hosts, such as a PC or a datacenter server
            - Routers
            - Switches
            - Switches with line card components
            - Power over Ethernet (PoE) endpoints,
            - Power Distribution Units (PDU)
            - Protocol gateways devices for Building Management Systems
        (BMS)
            - Electrical Meters
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 5]


     Internet-Draft             <EMAN Framework>            July 2011
     
            - Sensor controllers with subtended sensors
     
        There may also exist varying protocols deployed among these
        parallel 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.
     
     
     
     3. 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].
     
        This section contains definitions of terms used throughout this
        specification. Defined terms have their first letter
        capitalized.  Entities, relationships and or capabilities are
        defined with respect to well known software patterns as
        described in [GAMMA] and [EIPATT]
     
        Energy Management System (EnMS)
     
        An EnMS is a set of systems or procedures upon which
        organizations can develop and implement an energy policy, set
        targets, action plans and take into account legal requirements
        related to energy use.  An EnMS allows organizations to improve
        energy performance and demonstrate conformity to requirements,
        standards and/or legal requirements.  This definition is in line
        with the definition of "Energy management systems - Requirements
        with guidance for use" [ISO50001].
     
        With respect to communication networks these same goals will
        apply to the communications networks and attached devices within
        an organization.
     
        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
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 6]


     Internet-Draft             <EMAN Framework>            July 2011
     
        constraints of the organization. In that light, Energy
        Management is a system congruent to any of FCAPS area 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 EnMS.
        Energy Management Systems
     
        An Energy Management System (EMS) is congruent to a Network
        Management System (NMS) and is a combination of hardware and
        software used to administer a network with the primarily purpose
        being Energy Management.
     
        Energy Monitoring
     
        Energy Monitoring is a part of Energy Management that deals with
        collecting or reading measurements from devices to aid in Energy
        Management.  This could include Energy, Power, Demand, Quality,
        Context and/or Battery information.
        Energy
     
        Energy
     
        Energy is the capacity of a system to produce external activity
        or perform work and can be electricity, fuels, steam, heat,
        compressed air, and other like media. Energy is typically
        expressed in watt hours or joules.
     
        Power
     
        Power is a rate of energy conversion.  As the unit of time
        approaches zero a power measurement is called an instantaneous
        power reading.  Typically when implementing Power monitoring in
        hardware, a measuring device may have to compute an average
        value per some unit of time to express a reading to approximate
        an instantaneous power measurement.
     
        Demand
     
        Demand is an average of Power measurements over an interval(s)
        of time and typically expressed in kilowatt hours.  This
        measurement is significant because some utilities or energy
        providers bill by Demand measurements as well as for maximum
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 7]


     Internet-Draft             <EMAN Framework>            July 2011
     
        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 Quality
     
        EDITOR'S NOTE: This may be rephrased as Electrical
        Characteristics.
     
        Power Quality is defined as a set of values to describe the
        electrical characteristics of Power as provided by an electrical
        source as seen by the Energy Managed Object.  For example: AC
        phase, apparent and reactive power, etc.
     
        Energy Control
     
        Energy Control is a part of Energy Management that deals with
        modifying or setting the state of an Energy Managed Object in
        order to optimize or ensure its efficiency.
     
     
        Energy Managed Object
     
        An Energy Managed Object (EMO) is a device 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.
     
        Energy Aware Object
     
        An Energy Managed Object may not have the capability to provide
        information necessary for Energy Management itself. If an Energy
        Managed Object can provide Energy Management Context, Energy
        Monitor and optionally Energy Control values for itself then the
        Energy Managed Object is said to be an Energy Aware Object
     
        For example: as the most simplistic example, a set of light
        bulbs where all values are provided by an EMS through estimation
        and or catalogue information are not Energy Aware. In contrast a
        set of network switches that can report the same information
        based upon hardware sensing is said to be Energy Aware.
     
        Energy Managed Object Identification
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 8]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Energy Managed Object Identification is a set of attributes that
        enable an Energy Managed Object to be: uniquely identified among
        all Energy Management Domains; linked to other systems;
        classified as to type model and or manufacturer.
        RFC EDITOR'S: the uniqueness must be clarified in [EMAN-REQ]
     
        Energy Managed Object Context
     
        Energy Managed Object Context is a set of attributes that allow
        an Energy Management system to classify the use of the Energy
        Managed Object within an organization.  The classification
        contains use and/or ranking of the Energy Managed Object as
        compared to other Energy Managed Objects in the Energy
        Management Domain.
     
        Energy Management Domain
     
        An Energy Management Domain is a name or name space that
        logically groups Energy Managed Objects into a zone of Energy
        Management.  Typically, this zone will have as members all
        Energy Managed Objects that are powered from the same electrical
        panel(s) for which there is a meter or sub meter.
        For example: All Energy Managed Objects drawing power from the
        same distribution panel with the same AC voltage within a
        building, or all Energy Managed Objects in a building for which
        there is one main meter, would comprise an Energy Management
        Domain.
     
        From the standpoint of Energy Management, it is useful to report
        Energy as the sum of the Energy of all the Energy Managed
        Objects within an Energy Management Domain and then correlate
        that value with metered values.
     
        Energy Managed Object Relationships
     
        Energy Managed Objects may have functional relationships to each
        other within an Energy Management Domain.  The functional
        relationships include Aggregation, Metering, Power Source(s),
        Proxy, and Dependency.  One device will provide a capability or
        functional value in the relationship and another will be the
        receiver of the capability.  These capabilities include
        Aggregation, Metering, Power Source, Proxy and Dependency.
     
        Aggregation Relationship
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012           [Page 9]


     Internet-Draft             <EMAN Framework>            July 2011
     
        An Energy Managed Object may aggregate the Energy Management
        information of one or more Energy Managed Objects and is
        referred to as an Aggregation Relationship.  An Energy Managed
        Object may be aggregated by another Energy Managed Object(s).
        Aggregate values are obtained by reading values from multiple
        Energy Managed Objects and producing a single value of more
        significant meaning such as average, count, maximum, median,
        minimum, mode and most commonly sum.
     
        Metering Relationship
     
        An Energy Managed Object may measure the Energy of another
        Energy Managed Object(s) and is referred to as a Metering
        Relationship.  An Energy Managed Object may be metered by
        another Energy Managed Object(s).  Example: a PoE port on a
        switch measure the Power it provides to the connected Energy
        Managed Object.
     
        Power Source Relationship
     
        An Energy Managed Object may be the source of or distributor of
        power to another Energy Managed Object(s) and is referred to as
        a Power Source Relationship.  An Energy Managed Object may be
        powered by another Energy Managed Object(s).  Example: a PDU
        provides power for a connected host.
     
        Proxy Relationship
     
        An Energy Managed Object that provides Energy Management
        capabilities on behalf of another Energy Managed Object so that
        is appears to be Energy Aware is referred to a Proxy
        Relationship.  An Energy Managed Object may be proxied by
        another Energy Managed Object(s).  Example: a protocol gateways
        device for Building Management Systems (BMS) with subtended
        devices.
     
     
        Dependency Relationship
     
        An Energy Managed Object may be a component of or rely
        completely upon another Energy Managed Object to operate and is
        referred to as a Dependency Relationship.  An Energy Managed
        Object may be dependent on another Energy Managed Object(s).
        Example: A Switch chassis with multiple line cards
     
     
        Energy Managed Object Parent
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 10]


     Internet-Draft             <EMAN Framework>            July 2011
     
        An Energy Managed Object Parent is an Energy Managed Object that
        provides one or more of the Energy Managed Object Relationships
        capabilities.
     
        Energy Managed Object Child
     
        An Energy Managed Object Child is an Energy Managed Object that
        has at least one Energy Managed Object Relationship capability
        provided by another Energy Managed Object.
     
     
        Power State
     
        A Power State is a way to classify a Power setting on an Energy
        Managed Object (e.g., on, off, or sleep).  A Power State can be
        viewed as a method for Energy Control
     
     
        Manufacturer Power State
     
        A Manufacturer Power State is a device-specific way to classify
        a Power setting implemented on an Energy Managed Object.
     
        Power State Set
     
        A collection of Power States that comprise one named or logical
        grouping of control is a Power State Set.  For 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 maximal (nominal) Power that a device
        can support.  This is typically determined via load testing and
        is specified by the manufacturer as the maximum value required
        to operate the 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.
     
     
     4. 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 Managed
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 11]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Objects may communicate over varying protocols.  For example the
        communications network may use IP Protocols (SNMP) but attached
        Energy Managed Object Parent may communicate to Energy Managed
        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.
     
        As displayed in the Figure 1, the most basic energy reference
        model is composed of an Energy Management System (EMS) that
        obtains Energy Management information from Energy Managed
        Objects.  The Energy Managed Object returns information for
        Energy Management directly to the EMS.
     
        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 require the push of time
        series of power values.  Therefore, IPFIX [RFC5101] is also
        mentioned in the following figures.
     
                            +---------------+
                            |      EMS      |                -   -
                            +-----+---+-----+                ^   ^
                                  |   |                      |   |
                                  |   |                      |S  |I
                        +---------+   +----------+           |N  |P
                        |                        |           |M  |F
                        |                        |           |P  |I
               +-----------------+      +--------+--------+  |   |X
               | EMO           1 |  ... | EMO           N |  v   |
               +-----------------+      +-----------------+  -   -
     
                       Figure 1: Simple Energy Management
     
     
     
        As displayed in the Figure 2, 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 January 8, 2012          [Page 12]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
                           +---------------+
                           |      EMS      |               -   -
                           +-----+--+------+               ^   ^
                                 |  |                      |   |
                                 |  |                      |S  |I
                    +------------+  +--------+             |N  |P
                    |                        |             |M  |F
                    |                        |             |P  |I
            +------------------+     +------+-----------+  |   |X
            | EMO              |     | EMO              |  v   |
            | Parent 1         | ... | Parent N         |  -   -
            +------------------+     +------------------+
                           |||                  .
          One or           |||                  .
          Multiple         |||                  .
          Enery Managed    |||                  .
          Object           |||                  .
          Relationship(s): |||
          - Aggregation    |||      +-----------------------+
          - Metering       |||------| EMO Child 1           |
          - Power Source   ||       +-----------------------+
          - Proxy          ||
          - Dependency     ||       +-----------------------+
                           ||-------| EMO Child 2           |
                           |        +-----------------------+
                           |
                           |
                           |--------           ...
                           |
                           |
                           |        +-----------------------+
                           |--------| EMO Child M           |
                                    +-----------------------+
     
     
     
                   Figure 2: Complex Energy Management Model
     
     
        While both the simple and complex Energy Management models
        contain an EMS, this framework doesn't impose any requirements
        regarding a topology with a centralize EMS or one with a
        distributed Energy Management via the Energy Managed Objects
        within the deployment.
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 13]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Given the pattern in figure 2, the complex relationships between
        Energy Managed Objects can be modeled (refer also to section
        5.3):
             - A PoE device modeled as an Energy Managed Object Parent
               with the Power Source, Metering, and Proxy Relationships
               for this powered device
             - A PDU modeled as an Energy Managed Object Parent with
               the Power Source and Metering for the plugged in host
             - A PC with line cards modeled as an Energy Managed Object
               Parent with Dependency Relationships for the line cards
             - Building management gateway, used as proxy for non IP
               protocols, is modeled as an Energy Managed Object Parent
               with the Proxy Relationship, and potentially the
               Aggregation Relationship
             - Etc.
     
     
        The communication between the Energy Managed Object Parent and
        Energy Managed Object Children is out of the scope of this
        framework.
     
     
     
     
     5. Framework High Level Concepts and Scope
     
        Energy Management can be organized into areas of concern that
        include:
     
        - Energy Managed Object Identification and Context - for
        modeling and planning
        - Energy Monitoring - for energy measurements
        - Energy Control - for optimization
        - Energy Procurement - for optimization of resources
     
        The framework addresses Energy Management but excludes Energy
        Procurement and the environmental impact of energy use.  As such
        the framework does not include:
     
        - Manufacturing costs of an Energy Managed Object in currency or
        environmental units
        - Embedded carbon or environmental equivalences of an Energy
        Managed Object
        - Cost in currency or environmental impact to dismantle or
        recycle an Energy Managed Object
        - Relationship or capabilities of an Energy Managed Object to an
        electrical or smart grid
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 14]


     Internet-Draft             <EMAN Framework>            July 2011
     
        - Supply chain analysis of energy sources or Energy Managed
        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 Managed Object and Energy Management Domain
          - Energy Managed Object Identification and Context
          - Energy Managed Object Relationships
          - Energy Monitoring
          - Energy Control
          - Deployment Topologies
     
     5.1. Energy Managed Object and Energy Management Domain
     
        An Energy Management Domain is a manageable set of devices that
        has a meter or sub-meter attached and typically corresponds to a
        power distribution point or panel.
     
        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.  The Energy Management Domain
        should be configured on an Energy Managed Object.  An Energy
        Managed Object Child may inherit the domain value from an Energy
        Managed Object Parent or the Energy Management Domain may be
        configured directly in an Energy Managed Object Child.
     
     5.2. Energy Managed Object Identification and Context
     
     
     
     5.2.1 Identification
     
     
     
        Energy Managed Objects MUST contain a value that uniquely
        identifies the Energy Managed Object among all the Energy
        Management Domains within an EnMS.  It is recommended that a
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 15]


     Internet-Draft             <EMAN Framework>            July 2011
     
        universal identifier (UUID) be used to uniquely identify the
        Energy Managed Object.
     
        Every Energy Managed Object should have a unique printable name.
        Possible naming conventions are: textual DNS name, MAC-address
        of the device, interface ifName, or a text string uniquely
        identifying the Energy Managed Object.  As an example, in the
        case of IP phones, the Energy Managed Object name can be the
        device DNS name.
     
     
     
     5.2.2 Context in General
     
        In order to aid in reporting and in differentiation between
        Energy Managed Objects, each Energy Managed Object optionally
        contains information establishing its business, site, or
        organizational context within a deployment.
     
     
     
     5.2.3 Context: Importance
     
        An Energy Managed Object can provide an importance value in the
        range of 1 to 100 to help differentiate 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.
     
         Although Energy Management Systems 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
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 16]


     Internet-Draft             <EMAN Framework>            July 2011
     
        . 40 to 59 Public or guest
     
        . 1  to 39 Decorative or hospitality
     
     
     
     5.2.4 Context: Keywords
     
        An Energy Managed Object can provide a set of keywords.  These
        keywords are a list of tags that can be used for grouping and
        summary reporting within or between Energy Management Domains.
        All alphanumeric characters and symbols, 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.  In such cases,
        the keywords are separated by commas and no spaces between
        keywords are allowed.  For example, "HR,Bldg1,Private".
     
        Another keyword use case is the virtual grouping of Energy
        Managed Objects.  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.
        This is particularly useful for servers with multiple power
        supplies, where each power supply is connected to a different
        physical outlet.  Other implementations allow "gangs" to be
        created based on common ownership of outlets, such as business
        units or load shed priority or other non-physical relationships.
        For example, current PDU implementations allow for an "M-to-N"
        mapping between outlet "gangs" and physical outlets:
     
              Outlet 1             (physical entity)
     
              Outlet 2             (physical entity)
     
              Outlet 3             (physical entity)
     
              Outlet 4             (physical entity)
     
              Outlet Gang A        (virtual entity)
     
              Outlet Gang B        (virtual entity)
     
              Gang A -> Outlets 1, 2 and 3
     
              Gang B -> Outlets 3 and 4
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 17]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
        both "gangs".  The keywords concept for this specific example
        would be used as such:
     
              Outlet 1        Energy Managed Object 1, keywords: gangA
     
              Outlet 2        Energy Managed Object 2, keywords: gangA
     
              Outlet 3        Energy Managed Object 3, keywords: gangA,
        gangB
     
              Outlet 4        Energy Managed Object 4, keywords: gangB
     
        Each "Outlet Gang" virtual entity, aggregated based on the value
        of the keywords, reports the aggregated data from the individual
        outlet entities that comprise it.  The same concept enables a
        single point of control for all the individual outlet entities.
        For example, turning "Outlet Gang A" to the "off" state would
        turn outlets 1, 2, and 3 "off" in some implementations.  Note
        that the impact of this action on "Outlet Gang B" is out of
        scope of this document.
     
     
     
     5.2.5 Context: Role
     
        An Energy Managed Object can provide a "role description" string
        that indicates the purpose the Energy Managed Object serves in
        the EnMS.  This could be a string describing the context the
        device fulfills in deployment.  For example, a lighting fixture
        in a kitchen area could have a role of "Hospitality Lighting" to
        provide context for the use of the device.
     
     5.3. Energy Managed Object Relationships
     
        An Energy Managed Object MAY be an Energy Managed Object Parent
        or Energy Managed Object Child of another Energy Managed Object.
     
        Energy Managed Objects establish a parent and child relationship
        when one Energy Managed Object provides capabilities for another
        Energy Managed Object.
     
        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 is the source of power for the attached device, so the
        Energy Managed Object Parent is the switch, and the Energy
        Managed Object Child is the device attached to the switch.
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 18]


     Internet-Draft             <EMAN Framework>            July 2011
     
        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.
     
     5.3.1 Energy Managed Object Children Discovery
     
        There are multiple ways that the Energy Managed Object Parent
        can discover its Energy Managed Object Children, if they are not
        present on the same physical network:
     
          . In case of PoE, the Energy Managed Object Parent
             automatically discovers an Energy Managed Object Child when
             the Child requests power.
          . The Energy Managed 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 Managed Object Parent might even support the
             LLDP-MED MIB [LLDP-MED-MIB], which returns extra
             information on the Energy Managed Object Children.
          . The Energy Managed Object Parent may reside on a network
             connected 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.
          . Energy Managed Object Parent/Energy Managed Object Child
             relationships may be set by manual or automatic network
             configuration functions.
     
        Note that the communication specifications between the Energy
        Managed Object Parent and Children is out of the scope of this
        document.
     
        When an Energy Managed Object Parent is a Proxy, the Energy
        Managed Object Parent should enumerate the capabilities it is
        providing for the Energy Managed 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.
     
     5.4. Energy Monitoring
     
        For the purposes of this framework energy will be limited to
        electrical energy in watt hours.  Other forms of Energy Managed
        Objects that use or produce non-electrical energy may be part of
        an Energy Management Domain but MUST provide information
        converted to and expressed in watt hours.
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 19]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Each Energy Managed Object will have information that describes
        Power and Energy information along with how that measurement was
        obtained or derived.
     
        Optionally, an Energy Managed Object can further describe the
        power information with power quality information reflecting the
        electrical characteristics of the measurement.
     
        Optionally, an Energy Managed Object can provide Demand
        information over time
     
        Power Measurement
     
        A Power measurement must be qualified with the units, magnitude,
        direction of power flow, and by what means the measurement was
        made (ex: Root Mean Square versus Nameplate).
     
        In addition, the Energy Managed 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 EMS.  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 EMS.
     
        Power measurement magnitude should conform to the IEC 61850
        definition of unit multiplier for the SI (System International)
        units of measure.  Measured values are represented in SI units
        obtained by BaseValue * 10 raised to the power of the scale.
        For example, if current power usage of an Energy Managed Object
        is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the
        value of the scaling factor.  Electric 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.  An 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 Managed Object usage measurement was
        obtained:
     
        . Whether the measurements were made at the device itself or
        from a remote source.
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 20]


     Internet-Draft             <EMAN Framework>            July 2011
     
        . Description of the method that was used to measure the power
        and whether this method can distinguish actual or estimated
        values.
     
        An EMS can use this information to account for the accuracy and
        nature of the reading between different implementations.
     
        The EMS can use the Nameplate Power for provisioning, capacity
        planning and potentially billing.
     
        Optional Power Quality
     
        Given a Power measurement it may in certain circumstances be
        desirable to know the electrical characteristics associated with
        that measurement.  The information model must adhere to the IEC
        61850 7-2 standard for describing AC measurements.  In some
        Energy Management Domains, the power quality may not be needed,
        available, or relevant to the EMS.
     
        Optional Demand
     
        It is well known in commercial electrical utility rates that
        Demand is used as a measurement for billing.  Also 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 Managed Object, and not when the power measurement is
        assumed or predicted.
     
        Optional Battery
     
        Some Energy Managed Objects may use batteries for storing energy
        and for receiving power supply.  These Energy Managed 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
     
        . battery type
     
        . nominal and remaining capacity
     
        . current charge
     
        . current state (charging, discharging, not in use, etc.)
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 21]


     Internet-Draft             <EMAN Framework>            July 2011
     
        . number of charging cycles
     
        . expected remaining time that the battery can serve as power
        supply
     
        . expected remaining lifetime of the battery
     
        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.
     
     5.5. Energy Control
     
        Energy Managed Objects can be controlled by setting it to a
        Power State. Sets of Power States can be seen as an interface by
        which an Energy Managed Object can be controlled.  Each Energy
        Managed Object should indicate the Power State Sets that is
        implements. Well known Power State Sets should be registered
        with IANA
     
        When and individual Power State is configured from a specific
        Power State Set, an Energy Managed Object may be busy at the
        request time.  The Energy Managed Object will set the desired
        state and then update the actual Power State when the priority
        task is finished.  This mechanism implies two different Power
        State variables: actual versus desired
     
        There are several standards and implementations of Power State
        Set.  An Energy Managed Object can support one or multiple Power
        State Set implementations concurrently.
     
        This framework list three initial possible Power State Series
        that can be supported by an Energy Managed Object:
     
        IEEE1621 - [IEEE1621]
     
        DMTF - [DMTF]
     
        EMAN - Specified here
     
     5.5.1 IEEE1621 Power State Series
     
        The IEEE1621 Power State Series [IEEE1621] consists of 3
        rudimentary states : on, off or sleep.
     
          on(0)    - The device is fully On and all features of the
        device are in working mode.
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 22]


     Internet-Draft             <EMAN Framework>            July 2011
     
          off(1)   - The device is mechanically switched off and does
        not consume energy.
     
          sleep(2) - The device is in a power saving mode, and some
        features may not be available immediately.
     
     5.5.2 DMTF Power State Series
     
        DMTF [DMTF] standards organization has defined a power profile
        standard based on the CIM (Common Information Model) model that
        consists of 15 power states ON (2), SleepLight (3), SleepDeep
        (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off-
        Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10),
        Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard
        Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off-
        Soft Graceful (15), PowerCycle-Hard Graceful (16).  DMTF
        standard is targeted for hosts and computers.  Details of the
        semantics of each Power State within the DMTF Power State Series
        can be obtained from the DMTF Power State Management Profile
        specification [DMTF].
     
        DMTF power profile extends ACPI power states.  The following
        table provides a mapping between DMTF and ACPI Power State
        Series and EMAN Power State Sets (described in the next
        section):
     
     
                State      DMTF Power     ACPI            EMAN Power
                             State       State           State Name
     
        Non-operational states:
     
                  1        Off-Hard      G3, S5           MechOff
                  2        Off-Soft      G2, S5           SoftOff
                  3        Hibernate     G1, S4           Hibernate
                  4        Sleep-Deep    G1, S3           Sleep
                  5        Sleep-Light   G1, S2          Standby
                  6        Sleep-Light   G1, S1           Ready
     
        Operational states:
                  7        On            G0, S0, P5       LowMinus
                  8        On            G0, S0, P4       Low
                  9        On            G0, S0, P3       MediumMinus
                 10        On            G0, S0, P2       Medium
                 11        On            G0, S0, P1       HighMinus
                 12        On            G0, S0, P0       High
     
                   Figure 3: DMTF / ACPI Power State Mapping
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 23]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
     
     5.5.3 EMAN Power State Series
     
        The EMAN Power State Series represents an attempt for a uniform
        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 incorporate the
        Power States defined in [ACPI] and [DMTF].  Therefore, in
        addition to the non-operational states as defined in [ACPI] and
        [DMTF] standards, several intermediate operational states have
        been defined.
     
        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).  For each
        operational state represent 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:
     
        IEEE1621 Power(off):
     
                 mechoff(1) : An off state where no Energy Managed
        Object features are available.  The Energy Managed 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 Managed
        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.
     
        IEEE1621 Power(sleep)
     
                 hibernate(3): No Energy Managed Object features are
        available.   The Energy Managed 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.
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 24]


     Internet-Draft             <EMAN Framework>            July 2011
     
        Typically, energy consumption is zero or close to zero.  This
        corresponds to state G1, S4 in ACPI.
     
                 sleep(4)    : No Energy Managed Object features are
        available, except for out-of-band management, for example 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 Managed Object features are
        available, except for out-of-band management, for example wake-
        up mechanisms.  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 Managed Object features are
        available, except for out-of-band management, for example wake-
        up mechanisms. This mode is analogous to hot-standby.  The
        Energy Managed 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.
     
        IEEE1621 Power(on):
     
                 lowMinus(7) : Indicates some Energy Managed Object
        features may not be available and the Energy Managed 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 Managed Object has taken measures or
        selected options to provideless than mediumMinus(9) usage.
     
                 mediumMinus(9): Indicates all Energy Managed Object
        features are available but the Energy Managed Object has taken
        measures or selected options to provide less than medium(10)
        usage.
     
                 medium(10)  : Indicates all Energy Managed Object
        features are available but the Energy Managed Object has taken
        measures or selected options to provide less than highMinus(11)
        usage.
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 25]


     Internet-Draft             <EMAN Framework>            July 2011
     
                 highMinus(11): Indicates all Energy Managed Object
        features are available and power usage is less than high(12).
     
                 high(12)    : Indicates all Energy Managed Object
        features are available and the Energy Managed Object is
        consuming the highest power.
     
        Energy Managed Objects may have Manufacturer Power States Sets
        and can map these to the EMAN Power State Sets.  The follow
        shows examples when Manufacturer Power State Sets have fewer or
        more states than the EMAN Power State Set
     
        A first example would be an imaginary device type, with only
        five states: "none", "short", "tall", "grande", and "venti".
     
          Manufacturer Power State    Respective Name
               0                           none
               1                           short
               2                           tall
               3                           grande
               4                           venti
     
                          Figure 4: Mapping Example 1
     
        In the unlikely event that there is no possible mapping between
        these Manufacturer Power States and the proposed Energy Managed
        Object States, the Power State will remain 0 throughout, as
        displayed below.
     
           Power State / Name     Manufacturer Power State / Name
               0 / unknown              0 / none
               0 / unknown              1 / short
               0 / unknown              2 / tall
               0 / unknown              3 / grande
               0 / unknown              4 / venti
     
                          Figure 5: Mapping Example 2
     
        If a mapping between the Manufacturer Power States and the
        Energy Managed Object Power States is achievable, both series of
        states must exist in the MIB module in the Energy Managed Object
        Parent, allowing the EMS to understand the mapping between them
        by correlating the Power State with the Manufacturer Power
        States.
     
           Power State / Name       Manufacturer Power State / Name
               1 / MechOff              0 / none
               2 / SoftOff              0 / none
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 26]


     Internet-Draft             <EMAN Framework>            July 2011
     
               3 / Hibernate            0 / none
               4 / Sleep, Save-to-RAM   0 / none
               5 / Standby              0 / none
               6 / Ready                1 / short
               7 / LowMinus             1 / short
               8 / Low                  1 / short
               9 / MediumMinus          2 / tall
               10 / Medium              2 / tall
               11 / HighMinus           3 / grande
               12 / High                4 / venti
     
                          Figure 6: Mapping Example 3
     
     
        How the Energy Managed Object States are then mapped is an
        implementation choice.  However, it is recommended that the
        Manufacturer Power States map to the lowest applicable Power
        States, so that setting all Energy Managed Objects to a Power
        State would be conservative in terms of disabled functionality
        on the Energy Managed Object.
     
        A second example would be a device type, such as a dimmer or a
        motor, with a high number of operational states.  For the sake
        of the example, 100 operational states are assumed.
     
           Power State / Name       Manufacturer Power State / Name
               1 / MechOff                   0 / off
               2 / SoftOff                   0 / off
               3 / Hibernate                 0 / off
               4 / Sleep, Save-to-RAM        0 / off
               5 / Standby                   1 / off
               6 / Ready                     2 / off
               7 / LowMinus                  11 / 1%
               7 / LowMinus                  12 / 2%
               7 / LowMinus                  13 / 3%
               .                             .
               .                             .
               .                             .
               8 / Low                       15 / 15%
               8 / Low                       16 / 16%
               8 / Low                       17 / 17%
               .                             .
               .                             .
               .                             .
               9 / MediumMinus               30 / 30%
               9 / MediumMinus               31 / 31%
               9 / MediumMinus               32 / 32%
               .                             .
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 27]


     Internet-Draft             <EMAN Framework>            July 2011
     
               .                             .
               .                             .
               10 / Medium                   45 / 45%
               10 / Medium                   46 / 46%
               10 / Medium                   47 / 47%
               .                             .
               .                             .
               .                             .
               etc...
     
                          Figure 7: Mapping Example 4
     
        As specified in section 6, this framework allows the
        configuration of the Power State, while configuring the
        Manufacturer Power State from the MIB directly is not possible.
     
     
     
     6. Structure of the Information Model: UML Representation
     
        EDITOR'S NOTE: right place here or in the appendix?
     
        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 an 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
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 28]


     Internet-Draft             <EMAN Framework>            July 2011
     
                      EMO RELATIONSHIPS AND CONTEXT
     
                                        +----------------------------+
                                        | _Child Specific Info __    |
                                        |----------------------------|
        +---------------------------+   |  parentId : UUID           |
        |    Context Information    |   |  parentProxyAbilities      |
        |---------------------------|   |           : bitmap         |
        |  roleDescription : string |   | _mgmtMacAddress : octets   |
        |  keywords[0..n] : string  |   |  mgmtAddress : inetaddress |
        |  importance : int         |   |  mgmtAddressType : enum    |
        |  category :  enum         |   |  mgmtDNSName : inetaddress |
        +---------------------------+   +----------------------------+
                  |                            |
                  |                            |
                  |                            |
                  v                            v
          +-----------------------------------------+
          |  Energy Managed Object Information      |
          |-----------------------------------------|
          | index : int                             |
          | powerMonitorId | UUID                   |
          | name : string                           |
          | meterDomainName | string                |
          | alternateKey | string                   |
          +-----------------------------------------+
                  ^
                  |
                  |
                  |
        +-------------------------+
        |    Links Object         |
        |-------------------------|
        |  physicalEntity : int   |
        |  ethPortIndex : int     |
        |  ethPortGrpIndex : int  |
        |  lldpPortNumber : int   |
        +-------------------------+
     
     
     
                     EMO AND MEASUREMENTS
     
     
        +-----------------------------------------------+
        |             Energy Managed Object             |
        |-----------------------------------------------|
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 29]


     Internet-Draft             <EMAN Framework>            July 2011
     
        |  nameplate : Measurement                      |
        |  battery[0..n]: Battery                       |
        |  measurements[0..n]: Measurement              |
        | --------------------------------------------- |
        | Measurement instantaneousUsage()              |
        | DemandMeasurement historicalUsage()           |
        +-----------------------------------------------+
     
          +-----------------------------------+
          |  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 : MeasurementQuality                  |
         +-----------------------------------------------+
     
         +-----------------------------------------------+
         |         TimeMeasurement                       |
         |-----------------------------------------------|
         | startTime : timestamp                         |
         | usage : Measurement                           |
         | maxUsage : Measurment                         |
         +-----------------------------------------------+
     
     
     
         +----------------------------------------+
         |        TimeInterval                    |
         |--------------------------------------- |
         |value : long                            |
         |units : enum { seconds, miliseconds..}  |
         +----------------------------------------+
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 30]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
         +----------------------------------------+
         |        DemandMeasurement               |
         |----------------------------------------|
         |intervalLength :  TimeInterval          |
         |intervalNumbers: long                   |
         |intervalMode :  enum { period, sliding, |
         |total }                                 |
         |intervalWindow : TimeInterval           |
         |sampleRate : TimeInterval               |
         |status : enum {active, inactive }       |
         |measurements : TimedMeasurement[]       |
         +----------------------------------------+
     
     
     
                       QUALITY
     
         +----------------------------------------+
         |       MeasurementQuality               |
         |----------------------------------------|
         |                                        |
         +----------------------------------------+
                            ^
                            |
                            |
         +------------------+--------------------+
         |         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
                   |
                   |
                   |
                   |        +------------------------------------+
                   |        |         ACPhase                    |
                   |     *  |------------------------------------|
                   +--------+ phaseIndex : long                  |
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 31]


     Internet-Draft             <EMAN Framework>            July 2011
     
                            | avgCurrent : long                  |
                            | activePower : long                 |
                            | reactivePower : long               |
                            | apparentPower : long               |
                            | powerFactor : long                 |
                            +------------------------------------+
                                        ^           ^
                                        |           |
                                        |           |
                                        |           |
                                        |           |
        +-------------------------------+---+       |
        |        DelPhase                   |       |
        |-----------------------------------|       |
        |phaseToNextPhaseVoltage  : long    |       |
        |thdVoltage : long                  |       |
        |thdCurrent : long                  |       |
        +-----------------------------------+       |
                                                    |
                                 +------------------+-----------+
                                 |        WYEPhase              |
                                 |------------------------------|
                                 |phaseToNeutralVoltage : long  |
                                 |thdCurrent : long             |
                                 |thdVoltage : long             |
                                 +------------------------------+
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
                           EMO & STATES
     
           +----------------------------------------------+
           |         Energy Managed Object                |
           |----------------------------------------------|
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 32]


     Internet-Draft             <EMAN Framework>            July 2011
     
           | currentLevel : int                           |
           | configuredLevel : int                        |
           | configuredTime : timestamp                   |
           | reason: string                               |
           | manufacturerLevels[0..n]: State              |
           | emanLevels[0..11] : State                    |
           | levelMappings[0..n] : LevelMapping           |
           +----------------------------------------------+
     
            +-------------------------------+
            |        State                  |
            |-------------------------------|
            | name : string                 |
            | cardinality : int             |
            | maxUsage : Measurement        |
            +-------------------------------+
     
           +-----------------------------------------------+
           |         Level Mapping                         |
           |-----------------------------------------------|
           | emanLevelIndex: int                           |
           | manufacturerLevelIndex : int                  |
           +-----------------------------------------------+
     
     
     
     
     7. Configuration
     
        This power management framework allows the configuration of the
        following key parameters:
     
     
          . Energy Managed Object name: A unique printable name for the
             Energy Managed Object.
          . Energy Managed Object Role: An administratively assigned
             name to indicate the purpose an Energy Managed Object
             serves in the network.
          . Energy Managed Object Importance: A ranking of how
             important the Energy Managed Object is, on a scale of 1 to
             100, compared with other Energy Managed Objects in the same
             Energy Management Domain.
          . Energy Managed Object Keywords: A list of keywords that can
             be used to group Energy Managed Objects for reporting or
             searching.
          . Energy Management Domain: Specifies the name of an Energy
             Management Domain for the Energy Managed Object.
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 33]


     Internet-Draft             <EMAN Framework>            July 2011
     
          . Energy Managed Object State: Specifies the current Power
             State (0..12) for the Energy Managed Object.
          . Demand parameters: For example, which interval length to
             report the Deman over, the number of intervals to keep,
             etc.
          . Assigning an Energy Managed Object Parent to an Energy
             Managed Object Child
          . Assigning an Energy Managed Object Child to an Energy
             Managed Object Parent.
     
        When an Energy Managed Object requires a mapping with the
        Manufacturer Power State, the Energy Managed Object
        configuration is done via the Power State settings, and not
        directly via the Manufacturer Power States, which are read-only.
        Taking into account Figure 7, where the LowMinus Power State
        corresponds to three different Manufacturer Power States (11 for
        1%, 12 for 2%, and 13 for 3%), the implication is that this
        framework will not set the Manufacturer Power State to one
        percent granularity without communicating over or configuring
        the proprietary protocol for this Energy Managed Object.
     
        This framework supports multiple means for setting the Power
        State of a specific Energy Managed Object. However, the Energy
        Managed 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 Managed
        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 Managed Object Parent and the
        Energy Managed Object Child, when the Energy Managed 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.
     
     
     
     8. 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
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 34]


     Internet-Draft             <EMAN Framework>            July 2011
     
        notification is generated when the value(s) of Power State has
        changed for the Energy Managed Object.
     
     
     9. Relationship with Other Standards Development Organizations
     
     9.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, energy related objects is based on IEC
        61850.
     
        Specific examples include:
     
          . The scaling factor, which represents Energy Managed Object
             usage magnitude, conforms to the IEC 61850 definition of
             unit multiplier for the SI (System International) units of
             measure.
     
          . The electrical characterisitc 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.
     
     10. Security Considerations
     
        Regarding the data attributes specified here, some or all may be
        considered sensitive or vulnerable in some network environments.
        Reading or writing these attributes without proper protection
        such as encryption or access authorization may have negative
        effects on the network capabilities.
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 35]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
     10.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 Managed Object may result in
             misreporting or interruption of power.
          . Unauthorized changes to a power state may disrupt the power
             settings of the different Energy Managed Objects, and
             therefore the state of functionality of the respective
             Energy Managed Objects.
          . Unauthorized changes to the demand history may disrupt
             proper accounting of energy usage.
     
        With respect to data transport SNMP versions prior to SNMPv3 did
        not include adequate security.  Even if the network itself is
        secure (for example, by using IPsec), there is still no secure
        control over who on the secure network is allowed to access and
        GET/SET (read/change/create/delete) the objects in these MIB
        modules.
     
        It is recommended that implementers consider the security
        features as provided by the SNMPv3 framework (see [RFC3410],
        section 8), including full support for the SNMPv3 cryptographic
        mechanisms (for authentication and privacy).
     
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3 and to
        enable cryptographic security.  It is then a customer/operator
        responsibility to ensure that the SNMP entity giving access to
        an instance of these MIB modules is properly configured to give
        access to the objects only to those principals (users) that have
        legitimate rights to GET or SET (change/create/delete) them.
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 36]


     Internet-Draft             <EMAN Framework>            July 2011
     
     11. IANA Considerations
     
        EDITOR'S NOTE: Add power states
     
     
     12. Acknowledgments
     
        The authors would like to Michael Brown for improving the text
        dramatically, and Bruce Nordman for his excellent feedback.
     
     
     13. References
     
     Normative References
     
     
        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
     
     
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet
                Standard Management Framework ", RFC 3410, December
                2002.
     
        [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.
     
     
     Informative References
     
        [RFC3444]  Pras, A., Schoenwaelder, J. "On the Differences
                between Information Models and Data Models", RFC 3444,
                January 2003.
     
        [ACPI] "Advanced Configuration and Power Interface
                Specification", http://www.acpi.info/spec30b.htm
     
        [IEEE1621]  "Standard for User Interface Elements in Power
                Control of Electronic Devices Employed in
                Office/Consumer Environments", IEEE 1621, December
                2004.
     
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control
                Connectivity Discovery", 2005.
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 37]


     Internet-Draft             <EMAN Framework>            July 2011
     
        [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 Managed
                Objecting", draft-ietf-eman-requirements-03, (work in
                progress), June 2010.
     
        [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
                Networks and Devices MIB", draft-ietf-eman-energy-
                aware-mib-01, (work in progress), March 2011.
     
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                Dietz, T., and B. Claise, "Power and Energy Monitoring
                MIB", draft-claise-energy-monitoring-mib-08, (work in
                progress), May 2011.
     
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                Definition of Managed Objects for Battery Monitoring",
                draft-ietf-eman-battery-mib-02, (work in progress),
                July 2011.
     
        [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy
                Management (EMAN) Applicability Statement", draft-
                tychon-eman-applicability-statement-02, (work in
                progress), June 2011
     
        [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/
     
        [DMTF] "Power State Management Profile DMTF  DSP1027  Version
                2.0"  December 2009
                http://www.dmtf.org/sites/default/files/standards/docum
                ents/DSP1027_2.0.0.pdf
     
        [TMN] "TMN Management Functions : Performance Management.", ITU-
                T M.3400
     
        [GAMMA] Eric Gamma et al. "Design Patterns: Element of Reusable
                Object-Oriented Software", 1994
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 38]


     Internet-Draft             <EMAN Framework>            July 2011
     
        [EIPATT] Gregor Hohpe, Bobby Woolf, "Enterprise Integration
                Patterns: Designing Building and Deploying Messaging
                Solutions" 2004, http://eaipatterns.com/index.html
     
     
     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@bradschoening.com
     
     
      Juergen Quittek
      NEC Europe Ltd.
      Network Laboratories
      Kurfuersten-Anlage 36
      69115 Heidelberg
      Germany
     
      Phone: +49 6221 90511 15
      EMail: quittek@netlab.nec.de
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 39]


     Internet-Draft             <EMAN Framework>            July 2011
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>       Expires January 8, 2012          [Page 40]
     

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