[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: April 30, 2012                             B. Schoening
                                                Independent Consultant
                                                            J. Quittek
                                                       NEC Europe Ltd.
                                                     October 31, 2011
     
     
                         Energy Management Framework
                        draft-ietf-eman-framework-03
     
     
     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>            Oct 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 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 April 30, 2012            [Page 2]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
     Table of Contents
     
        1. Introduction................................................4
           1.1. Energy Management Document Overview....................5
        2. Requirements & Use Cases....................................6
        3. Terminology.................................................6
        4. Energy Management Reference Model...........................9
        5. Framework High Level Concepts and Scope....................12
           5.1. Energy Object and Energy Management Domain............13
           5.2. Energy Object Identification and Context..............13
              5.2.1 Energy Object Identification......................13
              5.2.2 Context in General................................14
              5.2.3 Context: Importance...............................14
              5.2.4 Context: Keywords.................................15
              5.2.5 Context: Role.....................................16
           5.3. Energy Object Relationships...........................17
              5.3.1 Energy Object Children Discovery..................17
           5.4. Energy Monitoring.....................................18
              5.4.1 Power Measurement.................................19
           5.5. Energy Control........................................21
              5.5.1 IEEE1621 Power State Series.......................21
              5.5.2 DMTF Power State Series...........................22
              5.5.3 EMAN Power State Set..............................23
        6. Structure of the Information Model: UML Representation.....25
        7. Configuration..............................................30
        8. Fault Management...........................................31
        9. Relationship with Other Standards Development
        Organizations.................................................31
           9.1. Information Modeling..................................31
        10. Security Considerations...................................32
        10.1. Security Considerations for SNMP........................32
        11. IANA Considerations.......................................33
        12. Acknowledgments...........................................33
        13. References................................................33
           Normative References.......................................33
           Informative References.....................................34
     
     
     
        TO DO/OPEN ISSUE
        - Do we want to add some examples such as
          http://www.ietf.org/proceedings/81/slides/eman-4.pdf slide 14
          to 1]? Proposal: add it to [EMAN-AS]
        - Do we need variable range of states (i.e. dimmer)? Is this a
          requirement? How to model the batteries, as a component or a
          relationship? See the meeting minutes:
     
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 3]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
             o "Modeling of the battery?  If we are not modeling
               components then why model batteries? Use the Entity MIB"
        - Comment from Prantl on the list, related to energy control:
          non-discrete power-states are not supported -> Section 5.5.
          specifies the possibility of mapping
          "Manufacturer" Power States to the 12 Eman Power states,
          where there can be more than 12 Manufacturer Power States.
          However, in the context of power-capping of Servers we have a
          "non-discrete" floating cap corresponding to the Manufacturer
          Power State.
          The Problem is that different Servers will have completely
          different ranges of supported cap-values, e.g. Server 1 has a
          dynamic range of 300-500Watt, Server2 has a range of 70-
          270Watts. Now let's assume Powerstate 9=400 Watts for
          Server1, but would be 170Watts for Server2. Which would mean
          I have to specify a Mapping for each Server-Model.
          It would be far more practical if it would be possible to
          supply a key-value-pair with a certain power-state in Case
          the State needs context such as a power-cap, I would then
          specify a state of e.g. 7 and supply the desired Cap in the
          kvp-field.
          PROPOSAL:
               1. decide if we need a variable power state that is a
                 percent of maximum.
               2. Power-capping can be done by the EnMS. [EMAN-AS] to
                 document this use case.
     
     
     
     
     
     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
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 4]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        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, called Energy Objects, can then be
        monitored for Energy Management by obtaining measurements for
        Power, Energy, Demand and Power Quality.  If a device contains a
        battery(s) the characteristics and performance of the battery(s)
        can also be 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 consumption of 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 ,
        Proxy Relationship , and Dependency Relationship.
     
     
     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, cross-reference between existing standards and the
        EMAN standard, and shows how the this relates to other
        frameworks.
     
        The [EMAN-AWARE-MIB] specifies objects for addressing Energy
        Object 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, Power 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.
     
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 5]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     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.
     
        Target devices for the 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
            - Switches with line card components
            - Power over Ethernet (PoE) endpoints,
            - Power Distribution Units (PDU)
            - Protocol gateways 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.
     
     
     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.
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 6]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
        Energy Management System (EnMS)
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Management
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Monitoring
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Power
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Demand
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Power Quality
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Control
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Object
     
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 7]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Electrical Equipement
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Object Identification
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
          EDITOR'S NOTE: the uniqueness must be clarified in [EMAN-REQ]
     
        Energy Object Context
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Management Domain
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Object Relationships
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Aggregation Relationship
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Metering Relationship
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Power Source Relationship
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 8]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        Proxy Relationship
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Dependency Relationship
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Object Parent
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Energy Managed Object Child
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Power State
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Manufacturer Power State
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Power State Set
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
        Nameplate Power
     
          EDITOR'S NOTE: use the latest definition from the [draft-
          parello-eman-definitions-03] definitions
     
     
     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
     
     
     
     <Claise, et. Al>        Expires April 30, 2012            [Page 9]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        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.
     
        As displayed in the Figure 1, the most basic energy 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 require the push of time
        series of power values.  Therefore, IPFIX [RFC5101] is also
        mentioned as the appropriate solution in the following figures,
        even if there are no documents describing the IPFIX solution at
        the time of writing these lines. Note that this framework
        doesn't exclude another solution than IPFIX.
     
                            +---------------+
                            |      EnMS     |                -   -
                            +-----+---+-----+                ^   ^
                                  |   |                      |   |
                                  |   |                      |S  |I
                        +---------+   +----------+           |N  |P
                        |                        |           |M  |F
                        |                        |           |P  |I
               +-----------------+      +--------+--------+  |   |X
               | EO            1 |  ... | EO            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 April 30, 2012           [Page 10]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
     
                           +---------------+
                           |      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          ||
          - Dependency     ||       +-----------------------+
                           ||-------| EO Child 2            |
                           |        +-----------------------+
                           |
                           |
                           |--------           ...
                           |
                           |
                           |        +-----------------------+
                           |--------| EO Child M            |
                                    +-----------------------+
     
     
     
                   Figure 2: 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 centralize EnMS or one with a
        distributed Energy Management via the Energy Objects within the
        deployment.
     
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 11]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        Given the pattern in figure 2, 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 this
               Energy Object Child
             - A PDU modeled as an Energy Object Parent with the Power
               Source and Metering Relationships for the plugged in
               host (the Energy Object Children)
             - A PC with line cards modeled as an Energy Object Parent
               with Dependency Relationships for the line cards (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
             - Etc.
     
        The communication between the Energy Object Parent and Energy
        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 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
        - Relationship or capabilities of an Energy Object to an
        electrical or smart grid
        - Supply chain analysis of energy sources or Energy Object
        deployment
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 12]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        - 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
     
     
     5.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
        should be configured on an Energy Object.  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.
     
     
     
     5.2. Energy Object Identification and Context
     
     5.2.1 Energy Object Identification
     
        Energy Objects MUST contain a value that uniquely identifies the
        Energy Object among all the Energy Management Domains within an
        EnMS.  A universal identifier (UUID) [RFC4122] MUST be used to
        uniquely identify an Energy Object.
     
        Every Energy 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
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 13]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        identifying the Energy Object.  As an example, in the case of IP
        phones, the Energy 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 Objects, each Energy Object optionally contains
        information establishing its business, site, or organizational
        context within a deployment, i.e. the Energy Object Context.
     
     
     
     5.2.3 Context: Importance
     
        An Energy 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 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
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 14]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     5.2.4 Context: Keywords
     
        An Energy Object can provide a set of keywords.  These keywords
        are a list of tags that can be used for grouping 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
        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
     
        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 Object 1, keywords: gangA
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 15]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
              Outlet 2        Energy Object 2, keywords: gangA
     
              Outlet 3        Energy Object 3, keywords: gangA, gangB
     
              Outlet 4        Energy 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 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]
     
        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
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 16]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
     
        Role as a two-word string: "Faculty Desktop", "Teller Phone",
        "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
        "Administration Switch".
     
     
     
     5.3. 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. .
     
        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 Object Parent is the switch, and the Energy Object Child
        is the device attached to the switch.
     
        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.  The
        Energy Object Parent MUST keep track of its Energy Object
        Child(ren).
     
        While the Energy Object Relationships provide the different
        topologies information to all the EnMS in a consistent way,
        their implementation is optional.
     
     
     
     5.3.1 Energy Object Children Discovery
     
        There are multiple ways that the Energy Object Parent can
        discover its Energy Object Children, if they are not present on
        the same physical network:
     
          . 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
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 17]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
             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
             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 Object Parent/Energy Object Child relationships may
             be set by manual or automatic network configuration
             functions.
     
        Note that the communication specifications between the Energy
        Object Parent and Children is out of the scope of this document.
     
        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.
     
     
     5.4. 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 but MUST provide information converted
        to and expressed in watt hours.
     
        Each Energy Object will have information that describes Power
        information along with how that measurement was obtained or
        derived.  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 odometers that provide the Energy used,
        produced, and net Energy in Kwh.  These values are odometers
        that accumulate the Power readings.  If Energy values are
        returned then the three odometers must be provided along a
        description of accuracy.
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 18]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        Optionally, an Energy Object can provide Demand information over
        time
     
     
     
     5.4.1 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 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
        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 Object is 3, it
        could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of the
        scaling factor.  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 EMS can use this information to account for the accuracy and
        nature of the reading between different implementations.
     
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 19]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        The EMS can use the Nameplate Power for provisioning, capacity
        planning and potentially billing.
     
     
     
     5.4.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 include 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 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 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
     
        . battery type
     
        . nominal and remaining capacity
     
        . current charge
     
        . current state (charging, discharging, not in use, etc.)
     
        . number of charging cycles
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 20]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        . 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 Objects can be controlled by setting it to a Power State.
        Power States Sets can be seen as an interface by which an Energy
        Object can be controlled.  Each Energy Object should indicate
        the Power State Sets that it 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 Object may be busy at the request
        time.  The Energy 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 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 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 April 30, 2012           [Page 21]


     Internet-Draft             <EMAN Framework>            Oct 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
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 22]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
                   Figure 3: DMTF / ACPI Power State Mapping
     
     
     5.5.3 EMAN Power State Set
     
        The EMAN Power State Set 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 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.
     
        IEEE1621 Power(sleep)
     
                 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
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 23]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        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, 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 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 Object features are available,
        except for out-of-band management, for example 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.
     
        IEEE1621 Power(on):
     
                 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.
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 24]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
                 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.
     
     
     
     
     6. 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 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
     
        EDITOR'S NOTE: the first part of the UML must be aligned with
        the latest [EMAN-AWARE-MIB] document version.
     
     
     
                      EO 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 |
        +---------------------------+   +----------------------------+
                  |                            |
                  |                            |
                  |                            |
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 25]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
                  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()           |
        +-----------------------------------------------+
     
          +-----------------------------------+
          |  Measurements                     |
          | __________________________________|
          +-----------------------------------+
                            ^
                            |
                            |
         +------------------+----------------------------+
         |         PowerMeasurement                      |
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 26]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
         |-----------------------------------------------|
         | 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..}  |
         +----------------------------------------+
                            |
                            |
         +----------------------------------------+
         |        DemandMeasurement               |
         |----------------------------------------|
         |intervalLength :  TimeInterval          |
         |intervalNumbers: long                   |
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 27]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
         |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
                   |
                   |
                   |
                   |        +------------------------------------+
                   |        |         ACPhase                    |
                   |     *  |------------------------------------|
                   +--------+ phaseIndex : long                  |
                            | avgCurrent : long                  |
                            | activePower : long                 |
                            | reactivePower : long               |
                            | apparentPower : long               |
                            | powerFactor : long                 |
                            +------------------------------------+
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 28]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
                                        ^           ^
                                        |           |
                                        |           |
                                        |           |
                                        |           |
        +-------------------------------+---+       |
        |        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           |
           +----------------------------------------------+
     
            +-------------------------------+
            |        State                  |
            |-------------------------------|
            | name : string                 |
            | cardinality : int             |
            | maxUsage : Measurement        |
            +-------------------------------+
     
     
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 29]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
     
                 Figure 8: Information Model UML Representation
     
     
     7. 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 (0..12) for the Energy Object.
          . Demand parameters: For example, which interval length to
             report the Deman 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.
     
     
        This framework supports multiple means for setting the Power
        State of a specific Energy Object. 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.
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 30]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        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
        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].
     
     
     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 Object usage
             magnitude, conforms to the IEC 61850 definition of unit
             multiplier for the SI (System International) units of
             measure.
     
          . The electrical characteristic is based on the ANSI and IEC
             Standards, which require that we use an accuracy class for
             power measurement.  ANSI and IEC define the following
             accuracy classes for power measurement:
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 31]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
     
             . 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.
     
     
     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 Object may result in misreporting or
             interruption of power.
          . Unauthorized changes to a power state may disrupt the power
             settings of the different Energy Objects, and therefore the
             state of functionality of the respective Energy Objects.
          . Unauthorized changes to the demand history may disrupt
             proper accounting of energy usage.
     
        With respect to data transport SNMP versions prior to SNMPv3 did
        not include adequate security.  Even if the network itself is
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 32]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        secure (for example, by using IPsec), there is still no secure
        control over who on the secure network is allowed to access and
        GET/SET (read/change/create/delete) the objects in these MIB
        modules.
     
        It is recommended that implementers consider the security
        features as provided by the SNMPv3 framework (see [RFC3410],
        section 8), including full support for the SNMPv3 cryptographic
        mechanisms (for authentication and privacy).
     
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3 and to
        enable cryptographic security.  It is then a customer/operator
        responsibility to ensure that the SNMP entity giving access to
        an instance of these MIB modules is properly configured to give
        access to the objects only to those principals (users) that have
        legitimate rights to GET or SET (change/create/delete) them.
     
     
     
     11. IANA Considerations
     
     
        Initial values for the Power State Sets, together with the
        considerations for assigning them, are defined in [EMAN-MON-
        MIB].
     
     
     
     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.
     
        [RFC2819]  S. Waldbusser, "Remote Network Monitoring Management
                Information Base", STD 59, RFC 2819, May 2000
     
     
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 33]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet
                Standard Management Framework ", RFC 3410, December
                2002.
     
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally
                Unique IDentifier (UUID) URN Namespace", RFC 4122, July
                2005
     
     
     Informative References
     
        [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.
     
     
        [ACPI] "Advanced Configuration and Power Interface
                Specification", http://www.acpi.info/spec30b.htm
     
        [IEEE1621]  "Standard for User Interface Elements in Power
                Control of Electronic Devices Employed in
                Office/Consumer Environments", IEEE 1621, December
                2004.
     
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control
                Connectivity Discovery", 2005.
     
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information
                Base extension module for TIA-TR41.4 media endpoint
                discovery information", July 2005.
     
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
                M. Chandramouli, "Requirements for Energy Management",
                draft-ietf-eman-requirements-04, (work in progress),
                July 2010.
     
        [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
                Networks and Devices MIB", draft-ietf-eman-energy-
                aware-mib-02, (work in progress), July 2011.
     
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                Dietz, T., and B. Claise, "Power and Energy Monitoring
     
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 34]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
                MIB", draft-ietf-eman-energy-monitoring-mib-00, (work
                in progress), August 2011.
     
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                Definition of Managed Objects for Battery Monitoring",
                draft-ietf-eman-battery-mib-03, (work in progress),
                August 2011.
     
        [EMAN-AS] Tychon, E., Schoening, B., Chandramouli, M., and B.
                Nordman, "Energy Management (EMAN) Applicability
                Statement", draft-tychon-eman-applicability-statement-
                04, (work in progress), October 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
     
        [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.
     
     
     
     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.
     
     
     <Claise, et. Al>        Expires April 30, 2012           [Page 35]


     Internet-Draft             <EMAN Framework>            Oct 2011
     
      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 April 30, 2012           [Page 36]
     

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