[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                              J. Parello
     Internet-Draft                                      B. Claise
     Intended Status: Informational             Cisco Systems, Inc.
     Expires: October 30, 2015                        B. Schoening
                                            Independent Consultant
                                                        J. Quittek
                                                    NEC Europe Ltd
     
                                                  January 11, 2014
     
     
                        Energy Management Framework
                       draft-ietf-eman-framework-12
     
     
     Status of this Memo
     
        This Internet-Draft is submitted in full conformance with
        the provisions of BCP 78 and BCP 79.
     
        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute working
        documents as Internet-Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time.  It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."
     
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be
        accessed at http://www.ietf.org/shadow.html
     
        This Internet-Draft will expire on October 30 2015.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al           Expires October 30, 2015       [Page 1]


     Internet-Draft              EMAN Framework        January 2014
     
     
     Copyright Notice
     
        Copyright (c) 2013 IETF Trust and the persons identified as
        the document authors. All rights reserved.
     
        This document is subject to BCP 78 and the IETF Trust's
        Legal Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the
        date of publication of this document. Please review these
        documents carefully, as they describe your rights and
        restrictions with respect to this document. Code Components
        extracted from this document must include Simplified BSD
        License text as described in Section 4.e of the Trust Legal
        Provisions and are provided without warranty as described
        in the Simplified BSD License.
     
     Abstract
     
        This document defines a framework for Energy Management for
        devices and device components within or connected to
        communication networks.  The framework presents a physical
        reference model and information model. The information
        model consists of an Energy Management Domain as a set of
        Energy Objects. Each Energy Object can be attributed with
        identity, classification, and context.  Energy Objects can
        be monitored and controlled with respect to power, Power
        State, energy, demand, Power Attributes, and battery.
        Additionally the framework models relationships and
        capabilities between Energy Objects.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015      [Page 2]


     Internet-Draft              EMAN Framework        January 2014
     
     
     Table of Contents
     
        1. Introduction........................................ 3
           1.1. Energy Management Documents Overview........... 4
        2. Terminology......................................... 5
        3. Target Devices..................................... 10
        4. Physical Reference Model........................... 11
        5. Not Covered by the Framework....................... 12
        6. Energy Management Abstraction...................... 13
           6.1. Conceptual Model.............................. 13
           6.2. Energy Object (Class)......................... 14
           6.3. Energy Object Attributes...................... 15
           6.4. Measurements.................................. 18
           6.5. Control....................................... 20
           6.6. Relationships................................. 25
        7. Energy Management Information Model................ 29
        8. Modeling Relationships between Devices............. 33
           8.1. Power Source Relationship..................... 33
           8.2. Metering Relationship......................... 37
           8.3. Aggregation Relationship...................... 38
        9. Relationship to Other Standards.................... 39
        10. Implementation Status............................. 39
        11. Security Considerations........................... 40
           11.1. Security Considerations for SNMP............. 40
        12. IANA Considerations............................... 41
           12.1. IANA Registration of new Power State Sets.... 41
           12.2. Updating the Registration...Power State Sets. 43
        13. References........................................ 43
        14. Acknowledgments................................... 47
        Appendix A. Information Model Listing................. 47
        Authors' Addresses.................................... 56
     
     1. Introduction
     
        Network management is often divided into the five main
        areas defined in the ISO Telecommunications Management
        Network model: Fault, Configuration, Accounting,
        Performance, and Security Management (FCAPS) [X.700].  Not
        covered by this traditional management model is Energy
        Management, which is rapidly becoming a critical area of
        concern worldwide, as seen in [ISO50001].
     
        This document defines an Energy Management framework for
        devices within or connected to communication networks.  The
        devices, or components of these devices (such as line
        cards, fans, disks) can then be monitored and controlled.
        Monitoring includes measuring power, energy, demand, and
        attributes of power.  Energy control can be performed by
     
     
     Claise et al.          Expires October 11, 2015      [Page 3]


     Internet-Draft              EMAN Framework        January 2014
     
        setting a devices' or components' state. The framework also
        covers monitoring and control of batteries contained in
        devices.
     
        This framework further describes how to identify, classify
        and provide context for such devices.  While context
        information is not specific to Energy Management, some
        context attributes are specified in the framework,
        addressing the following use cases: how important is a
        device in terms of its business impact, how should devices
        be grouped for reporting and searching, and how should a
        device role be described. Guidelines for using context for
        Energy Management are described.
     
        The framework introduces the concept of a Power Interface
        that is analogous to a network interface. A Power Interface
        is defined as an interconnection among devices where energy
        can be provided, received, or both.
     
        The most basic example of Energy Management is a single
        device reporting information about itself.  In many cases,
        however, energy is not measured by the device itself, but
        measured upstream in the power distribution tree.  For
        example, a power distribution unit (PDU) may measure the
        energy it supplies to attached devices and report this to
        an energy management system.  Therefore, devices often have
        relationships to other devices or components in the power
        network.  An EnMS (Energy Management System) generally
        requires an understanding of the power topology (who
        provides power to whom), the metering topology (who meters
        whom), and an understanding of the potential aggregation
        (who aggregates values of others).
     
        The relationships build on the Power Interface concept. The
        different relationships among devices and components,
        specified in this document, include: power source,
        metering, and aggregation relationships.
     
     1.1. Energy Management Documents Overview
     
        The EMAN standard provides a set of specifications for
        Energy Management.  This document specifies the framework,
        per the Energy Management requirements specified in [EMAN-
        REQ].
     
        The applicability statement document [EMAN-AS] includes use
        cases, a cross-reference between existing standards and the
        EMAN standard, and a description of this framework's
        relationship to other frameworks.
     
     
     Claise et al.          Expires October 11, 2015      [Page 4]


     Internet-Draft              EMAN Framework        January 2014
     
     
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies
        objects for addressing device/component identification,
        classification, context information, and relationships from
        the point of view of Energy Management.
     
        The Power and Energy Monitoring MIB [EMAN-MON-MIB]
        specifies objects for monitoring of power, energy, demand,
        and control.
     
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines
        managed objects that provide information on the status and
        condition of batteries in managed devices.
     
     2. Terminology
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
        and "OPTIONAL" in this document are to be interpreted as
        described in RFC-2119 [RFC2119].
     
        In this document these words will appear with that
        interpretation only when in ALL CAPS. Lower case uses of
        these words are not to be interpreted as carrying RFC-
        2119 significance.
     
        In this section some terms have a NOTE that is not part of
        the definition itself, but accounts for differences between
        terminologies of different standards organizations or
        further clarifies the definition.
     
        The terms are listing in an order that aids in reading
        where terms may build off a previous term as opposed to an
        alphabetical ordering. Some terms that are common in
        electrical engineering or that describe common physical
        items use a lower case notation.
     
        Energy Management
          Energy Management is a set of functions for measuring,
          modeling, planning, and optimizing networks to ensure
          that the network and network attached devices use energy
          efficiently and appropriately for the nature of the
          application and the cost constraints of the organization.
     
          Reference: Adapted from [ITU-T-M-3400]
     
          NOTES:
          1. Energy Management refers to the activities, methods,
          procedures and tools that pertain to measuring, modeling,
     
     
     Claise et al.          Expires October 11, 2015      [Page 5]


     Internet-Draft              EMAN Framework        January 2014
     
          planning, controlling and optimizing the use of energy in
          networked systems [NMF].
     
          2. Energy Management is a management domain which is
          congruent to any of the FCAPS areas of management in the
          ISO/OSI Network Management Model [TMN]. Energy Management
          for communication networks and attached devices is a
          subset or part of an organization's greater Energy
          Management Policies.
     
        Energy Management System (EnMS)
          An Energy Management System is a combination of hardware
          and software used to administer a network with the
          primary purpose of energy management.
     
          NOTES:
          1. An Energy Management System according to [ISO50001]
          (ISO-EnMS) is a set of systems or procedures upon which
          organizations can develop and implement an energy policy,
          set targets, action plans and take into account legal
          requirements related to energy use.  An ISO-EnMS allows
          organizations to improve energy performance and
          demonstrate conformity to requirements, standards, and/or
          legal requirements.
     
          2. Example ISO-EnMS:  Company A defines a set of policies
          and procedures indicating there should exist multiple
          computerized systems that will poll energy measurements
          from their meters and pricing / source data from their
          local utility. Company A specifies that their CFO (Chief
          Financial Officer) should collect information and
          summarize it quarterly to be sent to an accounting firm
          to produce carbon accounting reporting as required by
          their local government.
     
          3. For the purposes of EMAN, the definition herein is the
          preferred meaning of an Energy Management System (EnMS).
          The definition from [ISO50001] can be referred to as ISO
          Energy Management System (ISO-EnMS).
     
        Energy Monitoring
          Energy Monitoring is a part of Energy Management that
          deals with collecting or reading information from devices
          to aid in Energy Management.
     
        Energy Control
          Energy Control is a part of Energy Management that deals
          with directing influence over devices.
     
     
     
     Claise et al.          Expires October 11, 2015      [Page 6]


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


     Internet-Draft              EMAN Framework        January 2014
     
          The time rate at which energy is emitted, transferred, or
          received; usually expressed in watts (joules per second).
     
          Reference: [IEEE100]
     
        demand
          The average value of power or a related quantity over a
          specified interval of time. Note: Demand is expressed in
          kilowatts, kilovolt-amperes, kilovars, or other suitable
          units.
     
          Reference: [IEEE100]
     
          NOTES:
          1. While IEEE100 defines demand in kilo measurements, for
          EMAN we use watts with any suitable metric prefix.
     
        provide energy
          A device (or component) "provides" energy to another
          device if there is an energy flow from this device to the
          other one.
     
        receive energy
          A device (or component) "receives" energy from another
          device if there is an energy flow from the other device
          to this one.
     
        meter (energy meter)
          a device intended to measure electrical energy by
          integrating power with respect to time.
     
          Reference: Adapted from [IEC60050]
     
        battery
          one or more cells (consisting of an assembly of
          electrodes, electrolyte, container, terminals and usually
          separators)  that are a source and/or store of electric
          energy.
     
          Reference: Adapted from [IEC60050]
     
        Power Interface
          A power inlet, outlet, or both.
     
        Nameplate Power
          The Nameplate Power is the nominal power of a device as
          specified by the device manufacturer.
     
        Power Attributes
     
     
     Claise et al.          Expires October 11, 2015      [Page 8]


     Internet-Draft              EMAN Framework        January 2014
     
          Measurements of the electrical current, voltage, phase
          and frequencies at a given point in an electrical power
          system.
          Reference: Adapted from [IEC60050]
     
          NOTES:
          1. Power Attributes are not intended to be judgmental
          with respect to a reference or technical value and are
          independent of any usage context.
     
        Power Quality
          Characteristics of the electrical current, voltage, phase
          and frequencies at a given point in an electric power
          system, evaluated against a set of reference technical
          parameters. These parameters might, in some cases, relate
          to the compatibility between electricity supplied in an
          electric power system and the loads connected to that
          electric power system.
     
          Reference: [IEC60050]
     
          NOTES:
          1. Electrical characteristics representing power quality
          information are typically required by customer facility
          energy management systems. It is not intended to satisfy
          the detailed requirements of power quality monitoring.
          Standards typically also give ranges of allowed values;
          the information attributes are the raw measurements, not
          the "yes/no" determination by the various standards.
     
          Reference: [ASHRAE-201]
     
        Power State
          A Power State is a condition or mode of a device (or
          component) that broadly characterizes its capabilities,
          power, and responsiveness to input.
     
          Reference: Adapted from [IEEE1621]
     
        Power State Set
          A Power State Set is a collection of Power States that
          comprises a named or logical control grouping.
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015      [Page 9]


     Internet-Draft              EMAN Framework        January 2014
     
     
     3. Target Devices
     
        With Energy Management, there exists a wide variety of
        devices that may be contained in the same deployment as a
        communication network but comprise a separate facility,
        home, or power distribution network.
     
        Energy Management has special challenges because a power
        distribution network supplies energy to devices and
        components, while a separate communications network
        monitors and controls the power distribution network.
     
        The target devices for Energy Management are all devices
        that can be monitored or controlled (directly or
        indirectly) by an Energy Management System (EnMS). These
        target devices include, for example:
           o     Simple electrical appliances and fixtures
           o     Hosts, such as a PC, a server, or a printer
           o     Switches, routers, base stations, and other
              network equipment and middle boxes
           o     Components within devices, such as a battery
              inside a PC, a line card inside a switch, etc.
           o     Power over Ethernet (PoE) endpoints
           o     Power Distribution Units (PDU)
           o     Protocol gateway devices for Building Management
              Systems (BMS)
           o     Electrical meters
           o     Sensor controllers with subtended sensors
     
        Target devices include devices that communicate via the
        Internet Protocol (IP) as well as devices using other means
        for communication. The latter are managed through gateways
        or proxies that can communicate using IP.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 10]


     Internet-Draft              EMAN Framework        January 2014
     
     
     4. Physical Reference Model
     
        The following reference model describes physical power
        topologies that exist in parallel to a communication
        topology. While many more topologies can be created with
        combination of devices, the following are some basic ones
        that show how Energy Management topologies differ from
        Network Management topologies.
     
        NOTE: "###" is used to denote a transfer of energy.
              - >  is used to denote a transfer of information.
     
        Basic Energy Management
     
                               +--------------------------+
                               | Energy Management System |
                               +--------------------------+
                                           ^  ^
                                monitoring |  | control
                                           v  v
                                       +---------+
                                       | device  |
                                       +---------+
     
        Basic Power Supply
     
                    +-----------------------------------------+
                    |         Energy Management System        |
                    +-----------------------------------------+
                          ^  ^                       ^  ^
               monitoring |  | control    monitoring |  | control
                          v  v                       v  v
                    +--------------+        +-----------------+
                    | power source |########|      device     |
                    +--------------+        +-----------------+
     
        Single Power Supply with Multiple Devices
     
                      +---------------------------------------+
                      |       Energy Management System        |
                      +---------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                      +--------+        +------------------+
                      | power  |########|         device 1 |
                      | source |   #    +------------------+-+
                      +--------+   #######|         device 2 |
     
     
     Claise et al.          Expires October 11, 2015     [Page 11]


     Internet-Draft              EMAN Framework        January 2014
     
                                     #    +------------------+-+
                                     #######|         device 3 |
                                            +------------------+
     
        Multiple Power Supplies with Single Devices
     
             +----------------------------------------------+
             |          Energy Management System            |
             +----------------------------------------------+
                 ^  ^              ^  ^              ^  ^
            mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                 v  v              v  v              v  v
             +----------+      +----------+      +----------+
             | power    |######|  device  |######| power    |
             | source 1 |######|          |      | source 2 |
             +----------+      +----------+      +----------+
     
     
     
     5. Not Covered by the Framework
     
        While this framework is intended as a framework for Energy
        Management in general, there are some areas that are not
        covered.
     
        Non-Electrical Equipment
     
        The primary focus of this framework is the management of
        electrical equipment. Non-Electrical equipment can be
        covered by the framework by providing interfaces that
        comply with the framework. For example, using the same
        units for power and energy. Therefore, non-electrical
        equipment that do not convert-to or present-as equivalent
        to electrical equipment are not addressed.
     
        Energy Procurement and Manufacturing
     
        While an EnMS may be a central point for corporate
        reporting, cost computation, environmental impact analysis,
        and regulatory compliance reporting - Energy Management in
        this framework excludes energy procurement and the
        environmental impact of energy use.
     
        As such the framework does not include:
           o  Cost in currency or environmental units of
              manufacturing a device.
           o  Embedded carbon or environmental equivalences of a
              device
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 12]


     Internet-Draft              EMAN Framework        January 2014
     
           o  Cost in currency or environmental impact to dismantle
              or recycle a device.
           o  Supply chain analysis of energy sources for device
              deployment
           o  Conversion of the usage or production of energy to
              units expressed from the source of that energy (such
              as the greenhouse gas emissions associated the
              transfer of energy from a diesel source).
     
     6. Energy Management Abstraction
     
        This section describes a conceptual model of information
        that can be used for Energy Management. The classes and
        categories of attributes in the model are described with
        rationale for each.
     
     6.1. Conceptual Model
     
        This section describes an information model that addressing
        issues specific to Energy Management, which complements
        existing Network Management models.
     
        An information model for Energy Management will need to
        describe a means to monitor and control devices and
        components. The model will also need to describe the
        relationships among and connections between devices and
        components.
     
        This section proposes a similar conceptual model for
        devices and components to that used in Network Management:
        devices, components, and interfaces. This section then
        defines the additional attributes specific to Energy
        Management for those entities that are not available in
        existing Network Management models.
     
        For modeling the devices and components this section
        describes three classes:  a Device (Class), a Component
        (Class), and a Power Interface (Class). These classes are
        sub-types of an abstract Energy Object (Class).
     
            Summary of Notation for Modeling Physical Equipment
     
        Physical         Modeling (Meta Data)     Model Instance
        ---------------------------------------------------------
        equipment        Energy Object (Class)    Energy Object
        device           Device (Class)           Device
        component        Component (Class)        Component
        inlet / outlet   Power Interface (Class)  Power Interface
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 13]


     Internet-Draft              EMAN Framework        January 2014
     
     
        This section then describes the attributes of an Energy
        Object (Class) for identification, classification, context,
        control, power and energy.
     
        Since the interconnections between devices and components
        for Energy Management may have no relation to the
        interconnections for Network Management the Energy Object
        (Classes) contain a separate Relationships (Class) as an
        attribute to model these types of interconnections.
     
        The next sections describe the each of the classes and
        categories of attributes in the information model.
     
        Not all of the attributes are mandatory for
        implementations. Specifications describing implementations
        of the information model in this framework need to be
        explicit about which are mandatory and which are optional
        to implement
     
        The formal definitions of the classes and attributes are
        specified in Section 7.
     
     6.2. Energy Object (Class)
     
        An Energy Object (Class) represents a piece of equipment
        that is part of, or attached to, a communications network
        which is monitored, controlled, or aids in the management
        of another device for Energy Management.
     
        The Energy Object (Class) is an abstract class that
        contains the base attributes to represent a piece of
        equipment for Energy Management.  There are three types of
        Energy Object (Class)'s: Device (Class), Component
        (Component) and Power Interface (Class).
     
     
     6.2.1. Device (Class)
     
        The Device (Class) is a sub-class of Energy Object (Class)
        that represents a physical piece of equipment.
     
        A Device (Class) instance represents a device that is a
        consumer, producer, meter, distributor, or store of energy.
     
        A Device (Class) instance may represent a physical device
        that contains other components.
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 14]


     Internet-Draft              EMAN Framework        January 2014
     
     6.2.2. Component (Class)
     
        The Component (Class) is a sub-class of Energy Object
        (Class) that represents a part of a physical piece of
        equipment.
     
     6.2.3. Power Interface (Class)
     
        A Power Interface (Class) represents the interconnections
        (inlet, outlet) among devices or components where energy
        can be provided, received, or both.
     
        The Power Interface (Class) is a sub-class of Energy Object
        (Class) that represents a physical inlet or outlet.
     
        There are some similarities between Power Interfaces and
        network interfaces.  A network interface can be set to
        different states, such as sending or receiving data on an
        attached line.  Similarly, a Power Interface can be
        receiving or providing energy.
     
        A Power Interface (Class) instance can represent
        (physically) an AC power socket, an AC power cord attached
        to a device, or an 8P8C (RJ45) PoE socket, etc.
     
     6.3. Energy Object Attributes
     
        This section describes categories of attributes for an
        Energy Object (Class).
     
     6.3.1. Identification
     
        A Universal Unique Identifier (UUID) [RFC4122] is used to
        uniquely and persistently identify an Energy Object.
     
        Every Energy Object has an optional unique printable name.
        Possible naming conventions are: textual DNS name, MAC
        address of the device, interface ifName, or a text string
        uniquely identifying the Energy Object.  As an example, in
        the case of IP phones, the Energy Object name can be the
        device's DNS name.
     
        Additionally an alternate key is provided to allow an
        Energy Object to be optionally linked with models in
        different systems.
     
     6.3.2. Context in General
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 15]


     Internet-Draft              EMAN Framework        January 2014
     
        In order to aid in reporting and in differentiation between
        Energy Objects, each object optionally contains information
        establishing its business, site, or organizational context
        within a deployment.
     
        The Energy Object (Class) contains a category attribute
        that broadly describes how an instance is used in a
        deployment. The category indicates if the Energy Object is
        primarily functioning as a consumer, producer, meter,
        distributor or store of energy.
     
        Given the category and context of an object, an EnMS can
        summarize or analyze measurements for the site.
     
     6.3.3. Context: Importance
     
        An Energy Object can provide an importance value in the
        range of 1 to 100 to help rank a device's use or relative
        value to the site.  The importance range is from 1 (least
        important) to 100 (most important).  The default importance
        value is 1.
     
        For example: A typical office environment has several types
        of phones, which can be rated according to their business
        impact.  A public desk phone has a lower importance (for
        example, 10) than a business-critical emergency phone (for
        example, 100).  As another example: A company can consider
        that a PC and a phone for a customer-service engineer are
        more important than a PC and a phone for lobby use.
     
        Although EnMS and administrators can establish their own
        ranking, the following example is a broad recommendation
        for commercial deployments [CISCO-EW]:
     
           90 to 100 Emergency response
           80 to 90 Executive or business-critical
           70 to 79 General or Average
           60 to 69 Staff or support
           40 to 59 Public or guest
           1  to 39 Decorative or hospitality
     
     6.3.4. Context: Keywords
     
        The Energy Object (Class) contains an attribute with
        context keywords.
     
        An Energy Object can provide a set of keywords that are a
        list of tags that can be used for grouping, for summary
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 16]


     Internet-Draft              EMAN Framework        January 2014
     
        reporting (within or between Energy Management Domains),
        and for searching.
     
        All alphanumeric characters and symbols (other than a
        comma), such as #, (, $, !, and &, are allowed.  Potential
        examples are: IT, lobby, HumanResources, Accounting,
        StoreRoom, CustomerSpace, router, phone, floor2, or
        SoftwareLab.
     
        There is no default value for a keyword. Multiple keywords
        can be assigned to an Energy Object.  White spaces before
        and after the commas are excluded, as well as within a
        keyword itself. In such cases, commas separate the keywords
        and no spaces between keywords are allowed.  For example,
        "HR,Bldg1,Private".
     
     6.3.5. Context: Role
     
        The Energy Object (Class) contains a role attribute. The
        "role description" string indicates the primary purpose the
        Energy Object serves in the deployment.  This could be a
        string representing the purpose the Energy Object fulfills
        in the deployment.
     
        Administrators can define any naming scheme for the role.
        As guidance, a two-word role that combines the service the
        Energy Object provides along with type can be used
        [IPENERGY].
     
        Example types of devices: Router, Switch, Light, Phone,
        WorkStation, Server, Display, Kiosk, HVAC.
     
        Example Services by Line of Business:
     
           Line of Business     Service
           -----------------------------------------------------
           Education            Student, Faculty, Administration,
                                Athletic
           Finance              Trader, Teller, Fulfillment
           Manufacturing        Assembly, Control, Shipping
           Retail               Advertising, Cashier
           Support              Helpdesk, Management
           Medical              Patient, Administration, Billing
     
        Role as a two-word string: "Faculty Desktop", "Teller
        Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
        Kiosk", "Administration Switch".
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 17]


     Internet-Draft              EMAN Framework        January 2014
     
     6.3.6. Context: Domain
     
        The Energy Object (Class) contains a string attribute to
        indicate membership in an Energy Management Domain. An
        Energy Management Domain can be any collection of Energy
        Objects in a deployment, but it is recommended to map 1:1
        with a metered or sub-metered portion of the site.
     
        In building management, a meter refers to the meter
        provided by the utility used for billing and measuring
        power to an entire building or unit within a building.  A
        sub-meter refers to a customer- or user-installed meter
        that is not used by the utility to bill but is instead used
        to get measurements from sub portions of a building.
     
        An Energy Object should be a member of a single Energy
        Management Domain therefore one attribute is provided.
     
     6.4. Measurements
     
        The Energy Object (Class) contains attributes to describe
        power, energy and demand measurements.
     
        An analogy for understanding power versus energy
        measurements can be made to speed and distance in
        automobiles. Just as a speedometer indicates the rate of
        change of distance (speed), a power measurement indicates
        the rate of transfer of energy. The odometer in an
        automobile measures the cumulative distance traveled and
        similarly an energy measurement indicates the accumulated
        energy transferred.
     
        Demand measurements are averages of power measurements over
        time. So using the same analogy to an automobile: measuring
        the average vehicle speed over multiple intervals of time
        for a given distance travelled, demand is the average power
        measured over multiple time intervals for a given energy
        value.
     
        Within this framework, energy will only be quantified in
        units of watt-hours. Physical devices measuring energy in
        other units must convert values to watt-hours or be
        represented by Energy Objects that convert to watt-hours.
     
     6.4.1. Measurements: Power
     
        The Energy Object (Class) contains a Nameplate Power
        attribute that describes the nominal power as specified by
        the manufacturer of the device. The EnMS can use the
     
     
     Claise et al.          Expires October 11, 2015     [Page 18]


     Internet-Draft              EMAN Framework        January 2014
     
        Nameplate Power for provisioning, capacity planning and
        (potentially) billing.
     
        The Energy Object (Class) has attributes that describe the
        present power information, along with how that measurement
        was obtained or derived (e.g., actual, estimated, or
        static).
     
        A power measurement is qualified with the units, magnitude
        and direction of power flow, and is qualified as to the
        means by which the measurement was made.
     
        Power measurement magnitude conforms to the [IEC61850]
        definition of unit multiplier for the SI (System
        International) units of measure.  Measured values are
        represented in SI units obtained by BaseValue * (10 ^
        Scale).  For example, if current power usage of an Energy
        Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 mW,
        depending on the value of the scaling factor.  17 W implies
        that the BaseValue is 17 and Scale = 0, whereas 17 mW
        implies BaseValue = 17 and ScaleFactor = -3.
     
        An Energy Object (Class) indicates how the power
        measurement was obtained with a caliber and accuracy
        attribute that indicates:
           o  Whether the measurements were made at the device
              itself or at a remote source.
           o  Description of the method that was used to measure
              the power and whether this method can distinguish
              actual or estimated values.
           o  Accuracy for actual measured values
     
     6.4.2. Measurements: Power Attributes
     
        The Energy Object (Class) contains an optional attribute
        that describes Power Attribute information reflecting the
        electrical characteristics of the measurement. These Power
        Attributes adhere to the [IEC-61850-7-2] standard for
        describing AC measurements.
     
     6.4.3. Measurements: Energy
     
        The Energy Object (Class) contains optional attributes that
        represent the energy used, received, produced and or
        stored.  Typically only devices or components that can
        measure actual power will have the ability to measure
        energy.
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 19]


     Internet-Draft              EMAN Framework        January 2014
     
     6.4.4. Measurements: Demand
     
        The Energy Object (Class) contains optional attributes that
        represent demand information over time. Typically only
        devices or components that can report actual power are
        capable of measuring demand.
     
     
     6.5. Control
     
        The Energy Object (Class) contains a Power State Set
        (Class) attribute that represents the set of Power States a
        device or component supports.
     
        A Power State describes a condition or mode of a device or
        component. While Power States are typically used for
        control they may be used for monitoring only.
     
        A device or component is expected to support at least one
        set of Power States consisting of at least two states, an
        on state and an off state.
     
        There are many existing standards describing device and
        component Power States.  The framework supports modeling a
        mixed set of Power States defined in different standards. A
        basic example is given by the three Power States defined in
        IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF],
        ACPI [ACPI], and PWG all define larger numbers of Power
        States.
     
        The semantics of a Power State are specified by
           a) the functionality provided by an Energy Object in
        this state,
           b) a limitation of the power that an Energy Object uses
        in this state,
           c) a combination of a) and b)
     
        The semantics of a Power State should be clearly defined.
        Limitation (curtailment) of the power used by an Energy
        Object in a state may be specified by:
           o  an absolute power value
           o  a percentage value of power relative to the energy
              object's nameplate power
           o  an indication of power relative to another power
              state. For example: Specify that power in state A is
              less than in state B.
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 20]


     Internet-Draft              EMAN Framework        January 2014
     
           o  For supporting Power State management an Energy
              Object provides statistics on Power States including
              the time an Energy Object spent in a certain Power
              State and the number of times an Energy Object
              entered a power state.
     
        When requesting an Energy Object to enter a Power State an
        indication of the Power State's name or number can be used.
        Optionally an absolute or percentage of Nameplate Power can
        be provided to allow the Energy Object to transition to a
        nearest or equivalent Power State.
     
        When an Energy Object is set to a particular Power State,
        the represented device or component may be busy. The Energy
        Object should set the desired Power State and then update
        the actual Power State when the device or component
        changes. There are then two Power State (Class) control
        attributes: actual and requested.
     
        The following sections describe well-known Power States for
        devices and components that should be modeled in the
        information model.
     
     6.5.1. Power State Sets
     
        There are several standards and implementations of Power
        State Sets.  The Energy Object (Class) support modeling one
        or multiple Power State Set implementation(s) on the device
        or component concurrently.
     
        There are currently three Power State Sets advocated:
          IEEE1621(256) - [IEEE1621]
          DMTF(512)     - [DMTF]
          EMAN(768)     - [this document]
     
        The respective specific states related to each Power State
        Set are specified in the following sections. The guidelines
        for the modification of Power State Sets are specified in
        the IANA Considerations Section.
     
     6.5.2. Power State Set: IEEE1621
     
        The IEEE1621 Power State Set [IEEE1621] consists of 3
        rudimentary states: on, off or sleep.
     
        In IEEE1621 devices are limited to the three basic power
        states - on, sleep, and off. Any additional power states
        are variants of one of the basic states rather than a
        fourth state [IEEE1621].
     
     
     Claise et al.          Expires October 11, 2015     [Page 21]


     Internet-Draft              EMAN Framework        January 2014
     
     
     6.5.3. Power State Set: DMTF
     
        The DMTF [DMTF] standards organization has defined a power
        profile standard based on the CIM (Common Information
        Model) model that consists of 15 power states:
     
        {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-
        Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle
        Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt
        (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),
        MasterBus reset Graceful (14), Power-Cycle Off-Soft
        Graceful (15), PowerCycle-Hard Graceful (16)}
     
        The DMTF standard is targeted for hosts and computers.
        Details of the semantics of each Power State within the
        DMTF Power State Set can be obtained from the DMTF Power
        State Management Profile specification [DMTF].
     
        The DMTF power profile extends ACPI power states. The
        following table provides a mapping between DMTF and ACPI
        Power State Set:
     
             DMTF                              ACPI
            Reserved(0)
            Reserved(1)
            ON (2)                             G0-S0
            Sleep-Light (3)                    G1-S1 G1-S2
            Sleep-Deep (4)                     G1-S3
            Power Cycle (Off-Soft) (5)         G2-S5
            Off-hard (6)                       G3
            Hibernate (Off-Soft) (7)           G1-S4
            Off-Soft (8)                       G2-S5
            Power Cycle (Off-Hard) (9)         G3
            Master Bus Reset (10)              G2-S5
            Diagnostic Interrupt (11)          G2-S5
            Off-Soft Graceful (12)             G2-S5
            Off-Hard Graceful (13)             G3
            MasterBus Reset Graceful (14)      G2-S5
            Power Cycle off-soft Graceful (15) G2-S5
            Power Cycle off-hard Graceful (16) G3
     
     6.5.4. Power State Set: IETF EMAN
     
        The EMAN Power States are an expansion of the basic Power
        States as defined in [IEEE1621] that also incorporates the
        Power States defined in [ACPI] and [DMTF].  Therefore, in
        addition to the non-operational states as defined in [ACPI]
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 22]


     Internet-Draft              EMAN Framework        January 2014
     
        and [DMTF] standards, several intermediate operational
        states have been defined.
     
        Physical devices and components are expected to support the
        EMAN Power State Set or to be modeled via an Energy Object
        the supports these states.
     
        An Energy Object may implement fewer or more Power States
        than a particular EMAN Power State Set specifies. In that
        case, the Energy Object implementation can determine its
        own mapping to the predefined EMAN Power States within the
        EMAN Power State Set.
     
        There are twelve EMAN Power States that expand on
        [IEEE1621]. The expanded list of Power States is derived
        from [CISCO-EW] and is divided into six operational states
        and six non-operational states.
     
        The lowest non-operational state is 1 and the highest is 6.
        Each non-operational state corresponds to an [ACPI] Global
        and System state between G3 (hard-off) and G1 (sleeping).
        Each operational state represents a performance state, and
        may be mapped to [ACPI] states P0 (maximum performance
        power) through P5 (minimum performance and minimum power).
     
        In each of the non-operational states (from mechoff(1) to
        ready(6)), the Power State preceding it is expected to have
        a lower Power value and a longer delay in returning to an
        operational state:
     
                 mechoff(1) : An off state where no Energy Object
        features are available.  The Energy Object is unavailable.
        No energy is being consumed and the power connector can be
        removed.
     
                 softoff(2) : Similar to mechoff(1), but some
        components remain powered or receive trace power so that
        the Energy Object can be awakened from its off state.  In
        softoff(2), no context is saved and the device typically
        requires a complete boot when awakened.
     
                 hibernate(3): No Energy Object features are
        available.   The Energy Object may be awakened without
        requiring a complete boot, but the time for availability is
        longer than sleep(4). An example for state hibernate(3) is
        a save to-disk state where DRAM context is not maintained.
        Typically, energy consumption is zero or close to zero.
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 23]


     Internet-Draft              EMAN Framework        January 2014
     
                 sleep(4)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  The time for availability is longer than
        standby(5). An example for state sleep(4) is a save-to-RAM
        state, where DRAM context is maintained.  Typically, energy
        consumption is close to zero.
     
                 standby(5) : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms.  This mode is analogous to cold-standby.
        The time for availability is longer than ready(6).  For
        example processor context is may not be maintained.
        Typically, energy consumption is close to zero.
     
                 ready(6)    : No Energy Object features are
        available, except for out-of-band management, such as wake-
        up mechanisms. This mode is analogous to hot-standby.  The
        Energy Object can be quickly transitioned into an
        operational state.  For example, processors are not
        executing, but processor context is maintained.
     
                 lowMinus(7) : Indicates some Energy Object
        features may not be available and the Energy Object has
        taken measures or selected options to use less energy than
        low(8).
     
                 low(8)      : Indicates some features may not be
        available and the Energy Object has taken measures or
        selected options to use less energy than mediumMinus(9).
     
                 mediumMinus(9): Indicates all Energy Object
        features are available but the Energy Object has taken
        measures or selected options to use less energy than
        medium(10).
     
                 medium(10)  : Indicates all Energy Object features
        are available but the Energy Object has taken measures or
        selected options to use less energy than highMinus(11).
     
                 highMinus(11): Indicates all Energy Object
        features are available and has taken measures or selected
        options to use less energy than high(12).
     
                 high(12)    : Indicates all Energy Object features
        are available and the Energy Object may use the maximum
        energy as indicated by the Nameplate Power.
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 24]


     Internet-Draft              EMAN Framework        January 2014
     
     
     
     6.5.5. Power State Sets Comparison
     
        A comparison of Power States from different Power State
        Sets can be seen in the following table:
          IEEE1621  DMTF         ACPI           EMAN
     
          Non-operational states
          off       Off-Hard     G3, S5         MechOff(1)
          off       Off-Soft     G2, S5         SoftOff(2)
          off       Hibernate    G1, S4         Hibernate(3)
          sleep     Sleep-Deep   G1, S3         Sleep(4)
          sleep     Sleep-Light  G1, S2         Standby(5)
          sleep     Sleep-Light  G1, S1         Ready(6)
     
          Operational states:
          on        on           G0, S0, P5     LowMinus(7)
          on        on           G0, S0, P4     Low(8)
          on        on           G0, S0, P3     MediumMinus(9)
          on        on           G0, S0, P2     Medium(10)
          on        on           G0, S0, P1     HighMinus(11)
          on        on           G0, S0, P0     High(12)
     
     6.6. Relationships
     
        The Energy Object (Class) contains a set of Relationship
        (Class) attributes to model the relationships between
        devices and components.  Two Energy Objects can establish
        an Energy Object Relationship to model the deployment
        topology with respect to Energy Management.
     
        Relationships are modeled with a Relationship (Class) that
        contains the UUID of the other participant in the
        relationship and a name that describes the type of
        relationship [CHEN]. The types of relationships are:  Power
        Source, Metering, and Aggregations.
     
           o  A Power Source Relationship is relationship where one
              Energy Object provides power to one or more Energy
              Objects. The Power Source Relationship gives a view
              of the physical wiring topology.  For example: a data
              center server receiving power from two specific Power
              Interfaces from two different PDUs.
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 25]


     Internet-Draft              EMAN Framework        January 2014
     
              Note: A Power Source Relationship may or may not
              change as the direction of power changes between two
              Energy Objects. The relationship may remain to
              indicate the change of power direction was unintended
              or an error condition.
     
           o  A Metering Relationship is relationship where one
              Energy Object measures power, energy, demand or Power
              Attributes of one or more other Energy Objects. The
              Metering Relationship gives the view of the metering
              topology.  Physical meters can be placed anywhere in
              a power distribution tree.  For example, utility
              meters monitor and report accumulated power
              consumption of the entire building. Logically, the
              metering topology overlaps with the wiring topology,
              as meters are connected to the wiring topology.  A
              typical example is meters that clamp onto the
              existing wiring.
     
           o  An Aggregation Relationship is a relationship where
              one Energy Object aggregates Energy Management
              information of one or more other Energy Objects. The
              Aggregation Relationship gives a model of devices
              that may aggregate (sum, average, etc) values for
              other devices.  The Aggregation Relationship is
              slightly different compared to the other
              relationships as this refers more to a management
              function.
     
        In some situations, it is not possible to discover the
        Energy Object relationships, and an EnMS or administrator
        must set them.  Given that relationships can be assigned
        manually, the following sections describe guidelines for
        use.
     
     
     6.6.1. Relationship Conventions and Guidelines
     
        This Energy Management framework does not impose many
        "MUST" rules related to Energy Object Relationships. There
        are always corner cases that could be excluded with too
        strict specifications of relationships. However, the
        framework proposes a series of guidelines, indicated with
        "SHOULD" and "MAY".
     
     6.6.2. Guidelines: Power Source
     
        Power Source relationships are intended to identify the
        connections between Power Interfaces. This is analogous to
     
     
     Claise et al.          Expires October 11, 2015     [Page 26]


     Internet-Draft              EMAN Framework        January 2014
     
        a Layer 2 connection in networking devices (a "one-hop
        connection").
     
        The preferred modeling would be for Power Interfaces to
        participate in Power Source Relationships. It some cases
        Energy Objects may not have the capability to model Power
        Interfaces.  Therefore a Power Source Relationship can be
        established between two Energy Objects or two non-connected
        Power Interfaces.
     
        While strictly speaking Components and Power Interfaces on
        the same Device do provide or receive energy from each
        other, the Power Source relationship is intended to show
        energy transfer between Devices. Therefore the relationship
        is implied when on the same Device.
     
        An Energy Object SHOULD NOT establish a Power Source
        Relationship with a Component.
           o  A Power Source Relationship SHOULD be established
              with the next known Power Interface in the wiring
              topology.
     
           o  The next known Power Interface in the wiring topology
              would be the next device implementing the framework.
              In some cases the domain of devices under management
              may include some devices that do not implement the
              framework. In these cases, the Power Source
              relationship can be established with the next device
              in the topology that implements the framework and
              logically shows the Power Source of the device.
     
           o  Transitive Power Source relationships SHOULD NOT be
              established.  For example, if an Energy Object A has
              a Power Source Relationship "Poweredby" with the
              Energy Object B, and if the Energy Object B has a
              Power Source Relationship "Poweredby" with the Energy
              Object C, then the Energy Object A SHOULD NOT have a
              Power Source Relationship "Poweredby" with the Energy
              Object C.
     
     6.6.3. Guidelines: Metering Relationship
     
        Metering Relationships are intended to show when one device
        acting as a meter is measuring the power or energy at a
        point in a power distribution system. Since one point of a
        power distribution system may cover many devices within a
        wiring topology, this relationship type can be seen as a
        set.
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 27]


     Internet-Draft              EMAN Framework        January 2014
     
        Some devices, however, may include measuring hardware for
        components, and outlets or for the entire device. For
        example, some PDUs may have the ability to measure power
        for each outlet and are commonly referred to as metered-by-
        outlet. Others may be able to control power at each power
        outlet but can only measure power at the power inlet -
        commonly referred to as metered-by-device.
     
        While the Metering Relationship could be used to represent
        a device as metered-by-outlet or metered-by-device, the
        Metering Relationship SHOULD be used to model the
        relationship between a meter and all devices covered by the
        meter downstream in the power distribution system
     
        In general:
           o  A Metering Relationship MAY be established with any
              other Energy Object, Component, or Power Interface.
     
           o  Transitive Metering Relationships MAY be used.
     
           o  When there is a series of meters for one Energy
              Object, the Energy Object MAY establish a Metering
              relationship with one or more of the meters.
     
     6.6.4. Guidelines: Aggregation
     
        Aggregation relationships are intended to identify when one
        device is used to accumulate values from other devices.
        Typically this is for energy or power values among devices
        and not for Components or Power Interfaces on the same
        device.
     
        The intent of Aggregation relationships is to indicate when
        one device is providing aggregate values for a set of other
        devices when it is not obvious from the power source or
        simple containment within a device.
     
        Establishing aggregation relationships within the same
        device would make modeling more complex and the aggregated
        values can be implied from the use of Power Inlets, outlet
        and Energy Object values on the same device.
     
        Since an EnMS is naturally a point of aggregation it is not
        necessary to model aggregation for Energy Management
        Systems.
     
        The Aggregation Relationship is intended for power and
        energy. It MAY be used for aggregation of other values from
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 28]


     Internet-Draft              EMAN Framework        January 2014
     
        the information model, but the rules and logical ability to
        aggregate each attribute is out of scope for this document.
     
        In general:
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with Components contained on the same
              device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with the Power Interfaces contained on
              the same device.
           o  A Device SHOULD NOT establish an Aggregation
              Relationship with an EnMS.
           o  Aggregators SHOULD log or provide notification in the
              case of errors or missing values while performing
              aggregation.
     
     6.6.5. Energy Object Relationship Extensions
     
        This framework for Energy Management is based on three
        relationship types: Aggregation , Metering, and Power
        Source.
        This framework is defined with possible future extension of
        new Energy Object Relationships in mind.
        For example:
           o  Some Devices that may not be IP connected. This can
              be modeled with a proxy relationship to an Energy
              Object within the domain. This type of proxy
              relationship is left for further development.
           o  A Power Distribution Unit (PDU) that allows devices
              and components like outlets to be "ganged" together
              as a logical entity for simplified management
              purposes, could be modeled with an extension called a
              "gang relationship", whose semantics would specify
              the Energy Objects' grouping.
     
     7. Energy Management Information Model
     
        This section presents an information model expression of
        the concepts in this framework as a reference for
        implementers. The information model is implemented as a MIB
        in the different related IETF EMAN documents.  However,
        other programming structures with different data models
        could be used as well.
     
        Data modeling specifications of this information model may
        where needed specify which attributes are required or
        optional.
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 29]


     Internet-Draft              EMAN Framework        January 2014
     
        Syntax
     
          UML Construct
          [ISO-IEC-19501-2005] Equivalent Notation
          -------------------- ------------------------------------
          Notes                // Notes
          Class
          (Generalization)     CLASS name {member..}
          Sub-Class
          (Specialization)     CLASS subclass
                                     EXTENDS superclass {member..}
          Class Member
          (Attribute)          attribute : type
     
        Model
     
        CLASS EnergyObject {
     
              // identification / classification
              index        : int
              identifier   : uuid
              alternatekey : string
     
              // context
              domainName      : string
              role            : string
              keywords [0..n] : string
              importance      : int
     
              // relationship
              relationships [0..n] : Relationship
     
              // measurements
              nameplate    : Nameplate
              power        : PowerMeasurement
              energy       : EnergyMeasurment
              demand       : DemandMeasurement
     
              // control
              powerControl [0..n] : PowerStateSet
        }
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 30]


     Internet-Draft              EMAN Framework        January 2014
     
     
        CLASS PowerInterface EXTENDS EnergyObject{
              eoIfType : enum { inlet, outlet, both}
        }
     
        CLASS Device EXTENDS EnergyObject {
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
              powerInterfaces[0..n]: PowerInterface
              components [0..n]    : Component
        }
     
        CLASS Component EXTENDS EnergyObject
              eocategory   : enum { producer, consumer, meter,
        distributor, store }
              powerInterfaces[0..n]: PowerInterface
              components [0..n]    : Component
     
        }
     
        CLASS Nameplate {
              nominalPower : PowerMeasurement
              details      : URI
        }
     
        CLASS Relationship {
              relationshipType    : enum { meters, meteredby,
        powers, poweredby, aggregates, aggregatedby }
              relationshipObject  : uuid
        }
     
        CLASS Measurement {
              multiplier: enum { -24..24}
              caliber   : enum { actual, estimated, static }
              accuracy  : enum { 0..10000} // hundreds of percent
        }
     
        CLASS PowerMeasurement EXTENDS Measurement {
              value          : long
              units          : "W"
              powerAttribute : PowerAttribute
        }
     
        CLASS EnergyMeasurement EXTENDS Measurement {
              startTime : time
              units     : "kWh"
              provided  : long
              used      : long
              produced  : long
     
     
     Claise et al.          Expires October 11, 2015     [Page 31]


     Internet-Draft              EMAN Framework        January 2014
     
              stored    : long
        }
     
        CLASS TimedMeasurement EXTENDS Measurement {
              startTime  : timestamp
              value      : Measurement
              maximum    : Measurement
        }
     
        CLASS TimeInterval {
              value      : long
              units      : enum { seconds, miliseconds,...}
        }
     
        CLASS DemandMeasurement EXTENDS Measurement {
              intervalLength : TimeInterval
              intervals      : long
              intervalMode   : enum { periodic, sliding, total }
              intervalWindow : TimeInterval
              sampleRate     : TimeInterval
              status         : enum { active, inactive }
              measurements[0..n] : TimedMeasurements
        }
     
        CLASS PowerStateSet {
              powerSetIdentifier : int
              name               : string
              powerStates [0..n] : PowerState
              operState          : int
              adminState         : int
              reason             : string
              configuredTime     : timestamp
        }
     
        CLASS PowerState {
              powerStateIdentifier  : int
              name             : string
              cardinality      : int
              maximumPower     : PowerMeasurement
              totalTimeInState : time
              entryCount       : long
        }
     
        CLASS PowerAttribute {
              acQuality   : ACQuality
        }
     
        CLASS ACQuality {
              acConfiguration : enum {SNGL, DEL,WYE}
     
     
     Claise et al.          Expires October 11, 2015     [Page 32]


     Internet-Draft              EMAN Framework        January 2014
     
              avgVoltage         : long
              avgCurrent         : long
              frequency          : long
              unitMultiplier     : int
              accuracy           : int
              totalActivePower   : long
              totalReactivePower : long
              totalApparentPower : long
              totalPowerFactor   : long
              phases [0..2]      : ACPhase
        }
     
        CLASS ACPhase {
              phaseIndex    : long
              avgCurrent    : long
              activePower   : long
              reactivePower : long
              apparentPower : long
              powerFactor   : long
        }
     
        CLASS DelPhase EXTENDS ACPhase {
              phaseToNextPhaseVoltage  : long
              thdVoltage : long
              thdCurrent : long
        }
     
        CLASS WYEPhase EXTENDS ACPhase {
              phaseToNeutralVoltage : long
              thdCurrent : long
              thdVoltage : long
        }
     
     8. Modeling Relationships between Devices
     
        In this section we give examples of how to use the EMAN
        information model to model physical topologies.  Where
        applicable, we show how the framework can be applied when
        devices can be modeled with Power Interfaces.  We also show
        how the framework can be applied when devices cannot be
        modeled with Power Interfaces but only monitored or control
        as a whole. For instance, a PDU may only be able to measure
        power and energy for the entire unit without the ability to
        distinguish among the inlets or outlets.
     
     8.1. Power Source Relationship
     
        The Power Source relationship is used to model the
        interconnections between devices, components and/Power
     
     
     Claise et al.          Expires October 11, 2015     [Page 33]


     Internet-Draft              EMAN Framework        January 2014
     
        Interfaces to indicate the source of energy for a device.
        In the following examples we show variations on modeling
        the reference topologies using relationships.
     
        Given for all cases:
     
        Device W: A computer with one power supply. Power Interface
        1 is an inlet for Device W.
     
        Device X: A computer with two power supplies. Power
        Interface 1 and power interface 2 are both inlets for
        Device X.
     
        Device Y: A PDU with multiple Power Interfaces numbered
        0..10. Power Interface 0 is an inlet and Power Interface
        1..10 are outlets.
     
        Device Z: A PDU with multiple Power Interfaces numbered
        0..10. Power Interface 0 is an inlet and Power Interface
        1..10 are outlets.
     
        Case 1: Simple Device with one Source
     
        Physical Topology:
     
           o  Device W inlet 1 is plugged into Device Y outlet 8.
     
        With Power Interfaces:
     
           o  Device W has an Energy Object representing the
              computer itself as well as one Power Interface
              defined as an inlet.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device W inlet 1 is powered by Device Y outlet 8.
     
           +-------+------+       poweredBy +------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 | Device W |
           +-------+------+ powers          +------+----------+
     
        Without Power Interfaces:
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 34]


     Internet-Draft              EMAN Framework        January 2014
     
           o  Device W has an Energy Object representing the
              computer.
           o  Device Y would have an Energy Object representing the
              PDU.
     
        The devices would have a Power Source Relationship such
        that:
        Device W is powered by Device Y.
     
     
           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device W  |
           +----------+ powers          +------------+
     
        Case 2: Multiple Inlets
     
        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Y outlet 9.
     
        With Power Interfaces:
     
           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interfaces
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Y outlet 9.
     
           +-------+------+        poweredBy+------+----------+
           |       | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           | PDU Y +------+        poweredBy+------+ Device X |
           |       | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+
     
        Without Power Interfaces:
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 35]


     Internet-Draft              EMAN Framework        January 2014
     
           o  Device X has an Energy Object representing the
              computer. Device Y has an Energy Object representing
              the PDU.
     
     
        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y.
     
           +----------+       poweredBy +------------+
           |  PDU Y   |-----------------|  Device X  |
           +----------+ powers          +------------+
     
        Case 3: Multiple Sources
     
        Physical Topology:
           o  Device X inlet 1 is plugged into Device Y outlet 8.
           o  Device X inlet 2 is plugged into Device Z outlet 9.
     
        With Power Interfaces:
     
           o  Device X has an Energy Object representing the
              computer itself. It contains two Power Interface
              defined as inlets.
           o  Device Y would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
           o  Device Z would have an Energy Object representing the
              PDU itself  (the Device), with a Power Interface 0
              defined as an inlet and Power Interfaces 1..10
              defined as outlets.
     
        The interfaces of the devices would have a Power Source
        Relationship such that:
        Device X inlet 1 is powered by Device Y outlet 8.
        Device X inlet 2 is powered by Device Z outlet 9.
     
           +-------+------+        poweredBy+------+----------+
           | PDU Y | PI 8 |-----------------| PI 1 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+          |
                                                   | Device X |
           +-------+------+        poweredBy+------+          |
           | PDU Z | PI 9 |-----------------| PI 2 |          |
           |       |      |powers           |      |          |
           +-------+------+                 +------+----------+
     
     
     Claise et al.          Expires October 11, 2015     [Page 36]


     Internet-Draft              EMAN Framework        January 2014
     
     
        Without Power Interfaces:
     
           o  Device X has an Energy Object representing the
              computer. Device Y and Z would both have respective
              Energy Objects representing each entire PDU.
     
        The devices would have a Power Source Relationship such
        that:
        Device X is powered by Device Y and powered by Device Z.
     
           +----------+           poweredBy +------------+
           |  PDU Y   |---------------------|  Device X  |
           +----------+ powers              +------------+
     
           +----------+           poweredBy +------------+
           |  PDU Z   |---------------------|  Device X  |
           +----------+ powers              +------------+
     
     8.2. Metering Relationship
     
        A meter in a power distribution system can logically
        measure the power or energy for all devices downstream from
        the meter in the power distribution system.  As such, a
        Metering relationship can be seen as a relationship between
        a meter and all of the devices downstream from the meter.
     
        We define in this case a Metering relationship between a
        meter and devices downstream from the meter.
     
        +-----+---+    meteredBy +--------+   poweredBy +-------+
        |Meter| PI|--------------| switch |-------------| phone |
        +-----+---+ meters       +--------+ powers      +-------+
                |                                           |
                |                                 meteredBy |
                +-------------------------------------------+
                 meters
     
        In cases where the Power Source topology cannot be
        discovered or derived from the information available in the
        Energy Management Domain, the metering topology can be used
        to relate the upstream meter to the downstream devices in
        the absence of specific Power Source relationships.
     
        A Metering Relationship can occur between devices that are
        not directly connected, as shown in the following figure:
     
                           +---------------+
     
     
     Claise et al.          Expires October 11, 2015     [Page 37]


     Internet-Draft              EMAN Framework        January 2014
     
                           |   Device 1    |
                           +---------------+
                           |      PI       |
                           +---------------+
                                   |
                           +---------------+
                           |     Meter     |
                           +---------------+
                                   .
                                   .
                                   .
                  meters        meters           meters
            +----------+   +----------+   +-----------+
            | Device A |   | Device B |   | Device C  |
            +----------+   +----------+   +-----------+
     
        An analogy to communications networks would be modeling
        connections between servers (meters) and clients (devices)
        when the complete Layer 2 topology between the servers and
        clients is not known.
     
     8.3. Aggregation Relationship
     
        Some devices can act as aggregation points for other
        devices.  For example, a PDU controller device may contain
        the summation of power and energy readings for many PDU
        devices.  The PDU controller will have aggregate values for
        power and energy for a group of PDU devices.
     
        This aggregation is independent of the physical power or
        communication topology.
     
        The functions that the aggregation point may perform
        include the calculation of values such as average, count,
        maximum, median, minimum, or the listing (collection) of
        the aggregation values, etc.
        Based on the experience gained on aggregations at the IETF
        [draft-ietf-ipfix-a9n-08], the aggregation function in the
        EMAN framework is limited to the summation.
     
        When aggregation occurs across a set of entities, values to
        be aggregated may be missing for some entities.  The EMAN
        framework does not specify how these should be treated, as
        different implementations may have good reason to take
        different approaches.  One common treatment is to define
        the aggregation as missing if any of the constituent
        elements are missing (useful to be most precise). Another
        is to treat the missing value as zero (useful to have
        continuous data streams).
     
     
     Claise et al.          Expires October 11, 2015     [Page 38]


     Internet-Draft              EMAN Framework        January 2014
     
     
        The specifications of aggregation functions are out of
        scope of the EMAN framework, but must be clearly specified
        by the equipment vendor.
     
     9. Relationship to Other Standards
     
        This Energy Management framework uses, as much as possible,
        existing standards especially with respect to information
        modeling and data modeling [RFC3444].
     
        The data model for power- and energy-related objects is
        based on [IEC61850].
     
        Specific examples include:
           o  The scaling factor, which represents Energy Object
              usage magnitude, conforms to the [IEC61850]
              definition of unit multiplier for the SI (System
              International) units of measure.
           o  The electrical characteristic is based on the ANSI
              and IEC Standards, which require that we use an
              accuracy class for power measurement.  ANSI and IEC
              define the following accuracy classes for power
              measurement:
           o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
           o  ANSI C12.20 class 0.2, 0.5
           o  The electrical characteristics and quality adhere
              closely to the [IEC61850-7-4] standard for describing
              AC measurements.
           o  The power state definitions are based on the DMTF
              Power State Profile and ACPI models, with operational
              state extensions.
     
     10. Implementation Status
     
        [Note to RFC Editor: Please remove this section and the
        reference to [RFC6982] before publication.]
     
        This section records the status of known implementations of
        the protocol defined by this specification at the time of
        posting of this Internet-Draft, and is based on a proposal
        described in RFC6982.  The description of implementations
        in this section is intended to assist the IETF in its
        decision processes in progressing drafts to RFCs.  Please
        note that the listing of any individual implementation here
        does not imply endorsement by the IETF.  Furthermore, no
        effort has been spent to verify the information presented
        here that was supplied by IETF contributors. This is not
        intended as, and must not be construed to be, a catalog of
     
     
     Claise et al.          Expires October 11, 2015     [Page 39]


     Internet-Draft              EMAN Framework        January 2014
     
        available implementations or their features.  Readers are
        advised to note that other implementations may exist.
     
        According to RFC 6982, "this will allow reviewers and
        working groups to assign due consideration to documents
        that have the benefit of running code, which may serve as
        evidence of valuable experimentation and feedback that have
        made the implemented protocols more mature.
     
        Implementation descriptions for this document are
        maintained at:
        http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations
     
     11. 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 network
        capabilities.
     
        The information and control capabilities specified in this
        framework could be exploited with detriment to a site or
        deployment. Implementers of the framework SHOULD examine
        and mitigate security threats with respect to these new
        capabilities.
     
        [RFC3410] User Security Model for SNMPv3 presents a good
        description of threats and mitigations for the SNMPv3
        protocol that can be used as a guide for implementations of
        this framework using other protocols.
     
     11.1. Security Considerations for SNMP
     
        Readable objects in MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered
        sensitive or vulnerable in some network environments.  It
        is important to control GET and/or NOTIFY access to these
        objects and possibly to encrypt the values of these objects
        when sending them over the network via SNMP.
     
        The support for SET operations in a non-secure environment
        without proper protection can have a negative effect on
        network operations.
     
        For example:
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 40]


     Internet-Draft              EMAN Framework        January 2014
     
           o  Unauthorized changes to the Energy Management Domain
              or business context of a device may result in
              misreporting or interruption of power.
           o  Unauthorized changes to a power state may disrupt the
              power settings of the different devices, and
              therefore the state of functionality of the
              respective devices.
           o  Unauthorized changes to the demand history may
              disrupt proper accounting of energy usage.
     
        With respect to data transport, SNMP versions prior to
        SNMPv3 did not include adequate security.  Even if the
        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.
     
     
     12. IANA Considerations
     12.1. IANA Registration of new Power State Sets
     
        This document specifies an initial set of Power State Sets.
        The list of these Power State Sets with their numeric
        identifiers is given is Section 6. IANA maintains the lists
        of Power State Sets.
     
        New assignments for Power State Set are administered by
        IANA through Expert Review [RFC5226], i.e., review by one
        of a group of experts designated by an IETF Area Director.
        The group of experts MUST check the requested state for
        completeness and accuracy of the description. A pure vendor
        specific implementation of Power State Set shall not be
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 41]


     Internet-Draft              EMAN Framework        January 2014
     
        adopted; since it would lead to proliferation of Power
        State Sets.
     
        Power states in a Power State Set are limited to 255
        distinct values. New Power State Set must be assigned the
        next available numeric identifier that is a multiple of
        256.
     
     12.1.1. IANA Registration of the IEEE1621 Power State Set
     
        This document specifies a set of values for the IEEE1621
        Power State Set [IEEE1621].  The list of these values with
        their identifiers is given in Section 6.6.2.  IANA created
        a new registry for IEEE1621 Power State Set identifiers and
        filled it with the initial list of identifiers.
     
        New assignments (or potentially deprecation) for the
        IEEE1621 Power State Set is administered by IANA through
        Expert Review [RFC5226], i.e., review by one of a group of
        experts designated by an IETF Area Director.  The group of
        experts must check the requested state for completeness and
        accuracy of the description.
     
     12.1.2. IANA Registration of the DMTF Power State Set
     
        This document specifies a set of values for the DMTF Power
        State Set.  The list of these values with their identifiers
        is given in Section 6. IANA has created a new registry for
        DMTF Power State Set identifiers and filled it with the
        initial list of identifiers.
     
        New assignments (or potentially deprecation) for the DMTF
        Power State Set is administered by IANA through Expert
        Review [RFC5226], i.e., review by one of a group of experts
        designated by an IETF Area Director.  The group of experts
        must check the conformance with the DMTF standard [DMTF],
        on the top of checking for completeness and accuracy of the
        description.
     
     12.1.3. IANA Registration of the EMAN Power State Set
     
        This document specifies a set of values for the EMAN Power
        State Set.  The list of these values with their identifiers
        is given in Section 6.6.4.  IANA has created a new registry
        for EMAN Power State Set identifiers and filled it with the
        initial list of identifiers.
     
        New assignments (or potentially deprecation) for the EMAN
        Power State Set is administered by IANA through Expert
     
     
     Claise et al.          Expires October 11, 2015     [Page 42]


     Internet-Draft              EMAN Framework        January 2014
     
        Review [RFC5226], i.e., review by one of a group of experts
        designated by an IETF Area Director.  The group of experts
        must check the requested state for completeness and
        accuracy of the description.
     
     12.1.4. Batteries Power State Set
     
        Batteries have operational and administrational states that
        could be represented as a Power State Set. Since the work
        for battery management is parallel to this document, we are
        not proposing any Power State Sets for batteries at this
        time.
     
     12.2. Updating the Registration of Existing Power State Sets
     
        With the evolution of standards, over time, it may be
        important to deprecate some of the existing the Power State
        Sets, or to add or deprecate some Power States within a
        Power State Set.
     
        The registrant shall publish an Internet-draft or an
        individual submission with the clear specification on
        deprecation of Power State Sets or Power States registered
        with IANA.  The deprecation or addition shall be
        administered by IANA through Expert Review [RFC5226], i.e.,
        review by one of a group of experts designated by an IETF
        Area Director. The process should also allow for a
        mechanism for cases where others have significant
        objections to claims on deprecation of a registration.
     
     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
     
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A
                  Universally Unique Identifier (UUID) URN
                  Namespace", RFC 4122, July 2005
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 43]


     Internet-Draft              EMAN Framework        January 2014
     
        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  RFC 5226, May 2008
     
        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB
                  (Version4)", RFC 6933, May 2013
     
        [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
                  between Information Models and Data Models", RFC
                  3444, January 2003
     
        [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
                  technology, Open Distributed Processing --
                  Unified Modeling Language (UML), January 2005
     
     Informative References
     
        [RFC2578] McCloghrie, K., Perkins, D., and J.
                  Schoenwaelder, "Structure of Management
                  Information Version 2 (SMIv2", RFC 2578, April
                  1999
     
     
        [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed.,
                  "Specification of the IP Flow Information Export
                  (IPFIX) Protocol for the Exchange of IP Traffic
                  Flow Information ", draft-ietf-ipfix-protocol-
                  rfc5101bis-08, (work in progress), June 2013
     
        [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling
                  Language for the Network Configuration Protocol
                  (NETCONF)", RFC 6020, October 2010
     
        [RFC3986] T. Berners-Lee, Ed., " Uniform Resource
                  Identifier (URI): Generic Syntax", RFC3 986,
                  January 2005
     
        [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 October 11, 2015     [Page 44]


     Internet-Draft              EMAN Framework        January 2014
     
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management
                  Information Base extension module for TIA-TR41.4
                  media endpoint discovery information", July 2005
     
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
                  and M. Chandramouli, "Requirements for Energy
                  Management", draft-ietf-eman-requirements-14,
                  (work in progress), May 2013
     
        [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy
                  Object Contet MIB", draft-ietf-eman-energy-aware-
                  mib-08, (work in progress), April 2013
     
        [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
                  Dietz, T., and B. Claise, "Power and Energy
                  Monitoring MIB", draft-ietf-eman-energy-
                  monitoring-mib-05, (work in progress), April 2013
     
        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
                  Definition of Managed Objects for Battery
                  Monitoring", draft-ietf-eman-battery-mib-08,
                  (work in progress), February 2013
     
        [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
                  "Energy Management (EMAN) Applicability
                  Statement", draft-ietf-eman-applicability-
                  statement-03, (work in progress), April 2013
     
        [ITU-T-M-3400] TMN Recommendation on Management Functions
                  (M.3400), 1997
     
        [NMF] "Network Management Fundamentals", Alexander Clemm,
                  ISBN: 1-58720-137-2, 2007
     
        [TMN] "TMN Management Functions : Performance Management",
                  ITU-T M.3400
     
        [IEEE100] "The Authoritative Dictionary of IEEE Standards
                  Terms"
                  http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
                  p?punumber=4116785
     
        [ISO50001] "ISO 50001:2011 Energy management systems -
                  Requirements with guidance for use",
                  http://www.iso.org/
     
        [IEC60050] International Electrotechnical Vocabulary
                  http://www.electropedia.org/iev/iev.nsf/welcome?o
                  penform
     
     
     Claise et al.          Expires October 11, 2015     [Page 45]


     Internet-Draft              EMAN Framework        January 2014
     
     
        [IEC61850] Power Utility Automation,
                  http://www.iec.ch/smartgrid/standards/
     
        [IEC61850-7-4] Abstract communication service interface
                  (ACSI), http://www.iec.ch/smartgrid/standards/
     
        [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
                  2009 - IEEE Standard for Information technology -
                  Telecommunications and information exchange
                  between systems - Local and metropolitan area
                  networks - Specific requirements - Part 3:
                  Carrier Sense Multiple Access with Collision
                  Detection (CSMA/CD) Access Method and Physical
                  Layer Specifications - Amendment: Data Terminal
                  Equipment (DTE) -  Power via Media Dependent
                  Interface (MDI) Enhancements", October 2009
     
        [DMTF] "Power State Management Profile DMTF  DSP1027
                  Version 2.0"  December 2009
                  http://www.dmtf.org/sites/default/files/standards
                  /documents/DSP1027_2.0.0.pdf
     
        [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
                  Management", 2010, Wiley Publishing
     
        [X.700]  CCITT Recommendation X.700 (1992), Management
                  framework for Open Systems Interconnection (OSI)
                  for CCITT applications
     
        [ASHRAE-201] "ASHRAE Standard Project Committee 201
                        (SPC 201)Facility Smart Grid Information
                        Model", http://spc201.ashraepcs.org
     
        [CHEN] "The Entity-Relationship Model: Toward a Unified
                  View of Data",  Peter Pin-shan Chen, ACM
                  Transactions on Database Systems, 1976
     
        [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello,
                  Roland Saville, Steve Kramling, Cisco Validated
                  Designs, September 2010,
                  http://www.cisco.com/en/US/docs/solutions/Enterpr
                  ise/Borderless_Networks/Energy_Management/energyw
                  isedg.html
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 46]


     Internet-Draft              EMAN Framework        January 2014
     
     14. Acknowledgments
     
        The authors would like to thank Michael Brown for his
        editorial work improving the text dramatically. Thanks to
        Rolf Winter for his feedback and to Bill Mielke for
        feedback and very detailed review. Thanks to Bruce Nordman
        for brainstorming with numerous conference calls and
        discussions. Finally, the authors would like to thank the
        EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.
     
        This document was prepared using 2-Word-v2.0.template.dot.
     
     Appendix A.
                Information Model Listing
     
        EnergyObject (Class)
     
        r  index         Integer           An RFC6933
                                             entPhysicalIndex
     
        w  name          String            An RFC6933
                                             entPhysicalName
     
        r  identifier    uuid              An [RFC6933]
                                             entPhysicalUUID
     
        rw alternatekey  String            A manufacturer defined
                                             string that can be
                                             used to identify the
                                             Energy Object
     
        rw domainName    String            The name of an Energy
                                             Management domain for
                                             the Energy Object
     
        rw role          String            An administratively
                                             assigned name to
                                             indicate the purpose
                                             an Energy Object
                                             serves in the network
     
        rw keywords      String            A list of keywords or
           [0..n]                           tags that can be used
                                             to group Energy
                                             Objects for reporting
                                             or searching
     
        rw importance    Integer           Specifies a ranking of
                                             how important the
                                             Energy Object is (on a
     
     
     Claise et al.          Expires October 11, 2015     [Page 47]


     Internet-Draft              EMAN Framework        January 2014
     
                                             scale of 1 to 100)
                                             compared with other
                                             Energy Objects
     
        rw relationships Relationship      A list of
           [0..n]                           relationships between
                                             this Energy Object and
                                             other Energy Objects
     
        r  nameplate     Nameplate         The nominal
                                             PowerMeasurement of
                                             the Energy Object as
                                             specified by the
                                             device manufacturer
     
        r  power         PowerMeasurement  The present power
                                             measurement of the
                                             Energy Object
     
        r  energy        EnergyMeasurment  The present energy
                                             measurement for the
                                             Energy Object
     
        r  demand        DemandMeasurement The present demand
                                             measurement for the
                                             Energy Object
     
        r  powerControl  PowerStateSet     A list of Power States
           [0..n]                           Sets the Energy Object
                                             supports
     
     
     
        PowerInterface (Class) inherits from and specializes
        EnergyObject
     
        r  eoIfType       Enumeration      Indicates if the Power
                                           Interface is an -
                                           inlet; outlet; both
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 48]


     Internet-Draft              EMAN Framework        January 2014
     
     
        Device (Class) inherits from and specializes EnergyObject
     
        rw eocategory      Enumeration    Broadly indicates if
                                           the Device is a
                                           producer consumer meter
                                           distributor or store of
                                           energy
     
        r  powerInterfaces PowerInterface A list of
           [0..n]                          PowerInterfaces
                                           contained in this
                                           Device
     
        r  components      Component      A list of Components
           [0..n]                          contained in this
                                           Device
     
     
     
        Component (Class) inherits from and specializes
        EnergyObject
     
        rw eocategory      Enumeration    Broadly indicates if
                                           the Component is a
                                           producer consumer meter
                                           distributor or store of
                                           energy
     
        r  powerInterfaces PowerInterface A list of
           [0..n]                          PowerInterfaces
                                           contained in this
                                           Component
     
        r  components      Component      A list of Components
           [0..n]                          contained in this
                                           Component
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 49]


     Internet-Draft              EMAN Framework        January 2014
     
     
        Nameplate (Class)
     
        r  nominalPower  PowerMeasurement The nominal power of
                                           the Energy Object as
                                           specified by the device
                                           manufacturer
     
        rw details       URI              an [RFC3986] URI that
                                           links to manufacturer
                                           information about the
                                           nominal power of a
                                           device
     
     
        Relationship (Class)
     
        rw  relationshipType    Enumeration A description of the
                                            relationhip indicating
                                            - meters; meteredby;
                                            powers; poweredby;
                                            aggregates;
                                            aggregatedby
     
        rw  relationshipObject  uuid        An [RFC6933]
                                            entPhysicalUUID that
                                            indicates the other
                                            participating Energy
                                            Object in the
                                            relationship
     
     
     
        Measurement (Class)
     
        r   multiplier  Enumeration  The magnitude of the
                                      Measurement in the range -
                                      24..24
     
        r   caliber     Enumeration  Specifies how the Measurement
                                      was obtained - actual;
                                      estimated; static
     
        r   accuracy    Enumeration  Specifies the accuracy of the
                                      measurement if applicable as
                                      0..10000 indicating hundreds
                                      of percent
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 50]


     Internet-Draft              EMAN Framework        January 2014
     
     
        PowerMeasurement (Class) inherits from and specializes
        Measurement
     
        r value          Long            A measurement value of
                                          power
     
        r units          "W"             The units of measure for
                                          the power - "Watts"
     
        r powerAttribute PowerAttribute  Measurement of the
                                          electrical current;
                                          voltage; phase and/or
                                          frequencies for the
                                          PowerMeasurement
     
     
     
        EnergyMeasurement (Class) inherits from and specializes
        Measurement
     
        r startTime  Time         Specifies the start time of the
                                   EnergyMeasurement interval
     
        r units      "kWh"        The units of measure for the
                                   energy - kilowatt hours
     
        r provided   Long         A measurement of energy
                                   provided
     
        r used       Long         A measurement of energy used /
                                   consumed
     
        r produced   Long         A measurement of energy
                                   produced
     
        r stored     Long         A measurement of energy stores
     
     
     
        TimedMeasurement (Class) inherits from and specializes
        Measurement
     
        r  startTime timestamp    A start time of a measurement
     
        r  value     Measurement  A measurement value
     
        r  maximum   Measurement  A maximum value measured since a
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 51]


     Internet-Draft              EMAN Framework        January 2014
     
                                   previous timestamp
     
     
     
        TimeInterval (Class)
     
        r  value     Long         a value of time
     
        r  units     Enumeration  a magnitude of time express as
                                   seconds with an SI prefix
                                   (miliseconds etc)
     
     
     
        DemandMeasurement (Class) inherits from and specializes
        Measurement
     
        rw intervalLength TimeInterval     The length of time over
                                            which to compute
                                            average energy
     
        rw intervals      Long             The number of intervals
                                            that can be measured
     
        rw intervalMode   Enumeration      The mode of interval
                                            measurement as -
                                            periodic; sliding;
                                            total
     
        rw intervalWindow TimeInterval     The duration between
                                            the starting time of
                                            one sliding window and
                                            the next starting time
     
        rw sampleRate     TimeInterval     The sampling rate at
                                            which to poll power in
                                            order to compute demand
     
        rw status         Enumeration      a control to start or
                                            stop demand measurement
                                            as - active; inactive
     
        r  measurements[0 TimedMeasurement a collection of
           ..n]                             TimedMeasurements to
                                            compute demand
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 52]


     Internet-Draft              EMAN Framework        January 2014
     
        PowerStateSet (Class)
     
        r  powerSetIdentifier Integer      an IANA assigned value
                                            indicating a Power
                                            State Set
     
        r  name               String       A Power State Set name
     
        r  powerStates [0..n] PowerState   a set of Power States
                                            for the given
                                            identifier
     
        rw operState          Integer      The current operational
                                            Power State
     
        rw adminState         Integer      The desired Power State
     
        rw reason             String       Describes the reason
                                            for the adminState
     
        r  configuredTime     timestamp    Indicates the time of
                                            the desired Power State
     
     
     
        PowerState (Class)
     
        r  powerStateIdentifier Integer   an IANA assigned value
                                           indicating a Power State
     
        r  name                 String    A name for the Power
                                           State
     
        r  cardinality          Integer   A value indicating an
                                           ordering of the Power
                                           State
     
        rw maximumPower         PowerMea  indicates the maximum
                                 surement  power for the Energy
                                           Object at this Power
                                           State
     
        r  totalTimeInState     Time      Indicates the total time
                                           an Energy Object has
                                           been in this Power State
                                           since last reset
     
        r  entryCount           Long      Indicates the number of
                                           time the Energy Object
     
     
     Claise et al.          Expires October 11, 2015     [Page 53]


     Internet-Draft              EMAN Framework        January 2014
     
                                           has entered changed to
                                           this state
     
     
     
        PowerAttribute (Class)
     
        r acQuality  ACQuality  Describes AC Power Attributes for
                                 a Measurement
     
     
     
        ACQuality (Class)
     
        r acConfiguration     Enumera Describes the physical
                              tion    configuration of alternating
                                       current as single phase
                                       (SNGL) three phase delta
                                       (DEL) or three phase Y (WYE)
     
        r avgVoltage          Long    The average of the voltage
                                       measured over an integral
                                       number of AC cycles
                                       [IEC61850-7-4] 'Vol'
     
        r avgCurrent          Long    The current per phase
                                       [IEC61850-7-4] 'Amp'
     
        r frequency           Long    Basic frequency of the AC
                                       circuit [IEC61850-7-4] 'Hz'
     
        r unitMultiplier      Integer Magnitude of watts for the
                                       usage value in this instance
     
        r accuracy            Integer Percentage value in 100ths
                                       of a percent representing
                                       the presumed accuracy of
                                       active; reactive; and
                                       apparent power in this
                                       instance
     
        r totalActivePower    Long    A measured value of the
                                       actual power delivered to or
                                       consumed by the load
                                       [IEC61850-7-4] 'TotW'
     
        r totalReactivePower  Long    A measured value of the
                                       reactive portion of the
                                       apparent power [IEC61850-7-
     
     
     Claise et al.          Expires October 11, 2015     [Page 54]


     Internet-Draft              EMAN Framework        January 2014
     
                                       4] 'TotVAr'
     
        r totalApparentPower  Long    A measured value of the
                                       voltage and current which
                                       determines the apparent
                                       power as the vector sum of
                                       real and reactive power
                                       [IEC61850-7-4] 'TotVA'
     
        r totalPowerFactor    Long    A measured value of the
                                       ratio of the real power
                                       flowing to the load versus
                                       the apparent power
                                       [IEC61850-7-4] 'TotPF'
     
        r phases [0..2]       ACPhase A description of the three
                                       phase power
     
     
     
        ACPhase (Class)
     
        r phaseIndex     Long  A phase angle typically
                                corresponding to - 0; 120; 240
     
        r avgCurrent     Long  A measured value of the current per
                                phase [IEC61850-7-4] 'A'
     
        r activePower    Long  A measured value of the actual
                                power delivered to or consumed by
                                the load [IEC61850-7-4] 'W'
     
        r reactivePower  Long  A measured value of the reactive
                                portion of the apparent power [IEC
                                61850-7-4] 'VAr'
     
        r apparentPower  Long  A measured value of the active plus
                                reactive power [IEC61850-7-4] 'VA'
     
        r powerFactor    Long  A measure ratio of the real power
                                flowing to the load versus the
                                apparent power for this phase
                                [IEC61850-7-4] 'PF'
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 55]


     Internet-Draft              EMAN Framework        January 2014
     
        DelPhase (Class) inherits from and specializes ACPhase
     
        r phaseToNextPhase Long  A measured value of phase to next
          Voltage                phase voltages where the next
                                  phase is [IEC61850-7-4] 'PPV'
     
        r thdVoltage       Long  A calculated value for the
                                  voltage total harmonic disortion
                                  for phase to next phase. Method
                                  of calculation is not specified
                                  [IEC61850-7-4] 'ThdPPV'
     
        r thdCurrent       Long  A calculated value for the
                                  voltage total harmonic disortion
                                  (THD) for phase to phase. Method
                                  of calculation is not specified
                                  [IEC61850-7-4] 'ThdPPV'
     
     
     
        WYEPhase (Class) inherits from and specializes ACPhase
     
        r phaseToNeutral  Long A measured value of phase to
          Voltage              neutral voltage [IEC61850-7-4]
                                'PhV'
     
        r thdCurrent      Long A measured value of phase currents
                                [IEC 61850-7-4] 'A'
     
        r thdVoltage      Long A calculated value of the voltage
                                total harmonic distortion (THD)
                                for phase to neutral [IEC61850-7-
                                4] 'ThdPhV'
     
     
     Authors' Addresses
     
        John Parello
        Cisco Systems, Inc.
        3550 Cisco Way
        San Jose, California 95134
        US
     
        Phone: +1 408 525 2339
        Email: jparello@cisco.com
     
        Benoit Claise
        Cisco Systems, Inc.
        De Kleetlaan 6a b1
     
     
     Claise et al.          Expires October 11, 2015     [Page 56]


     Internet-Draft              EMAN Framework        January 2014
     
        Diegem 1813
        BE
     
        Phone: +32 2 704 5622
        Email: bclaise@cisco.com
     
        Brad Schoening
        44 Rivers Edge Drive
        Little Silver, NJ 07739
        US
     
        Phone:
        Email: brad.schoening@verizon.net
     
        Juergen Quittek
        NEC Europe Ltd.
        Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Germany
     
        Phone: +49 6221 90511 15
        EMail: quittek@netlab.nec.de
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.          Expires October 11, 2015     [Page 57]
     

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