[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: March 9, 2014                                     B. Schoening
                                                      Independent Consultant
                                                                  J. Quittek
                                                              NEC Europe Ltd
     
                                                           September 9, 2013
     
     
                             Energy Management Framework
                          draft-ietf-eman-framework-09.txt
     
     
     
     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 March 9, 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
     
     
     
     Claise et al            Expires March 9, 2014                  [Page 1]


     Internet-Draft              EMAN Framework               September 2013
     
        to this document. Code Components extracted from this document must
        include Simplified BSD License text as described in Section 4.e of
        the Trust Legal Provisions and are provided without warranty as
        described in the Simplified BSD License.
     
     Abstract
     
        This document defines a framework for providing Energy Management for
        devices and device components within or connected to communication
        networks.  The framework defines both 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 is
        identified, classified and given context.   Energy Objects can be
        monitored and controlled with respect to Power, Power State, Energy,
        Demand, Power Attributes, and Battery.  Additionally the framework
        models relationships and capabilities between Energy Objects.
     
     Table of Contents
     
        1. Introduction...................................................3
           1.1. Energy Management Documents Overview......................4
        2. Terminology....................................................4
        3. Concerns Specific to Energy Management........................10
           3.1. Target Devices...........................................10
           3.2. Physical Reference Model.................................10
           3.3. Concerns Differing from Network Management...............12
           3.4. Concerns Not Addressed...................................12
        4. Energy Management Abstraction.................................13
           4.1. Conceptual Model.........................................13
           4.2. Energy Object............................................14
           4.3. Energy Object Attributes.................................14
           4.4. Measurements.............................................17
           4.5. Control..................................................18
           4.6. Relationships............................................23
        5. Energy Management Information Model...........................26
        6. Modeling Relationships between Devices........................30
           6.1. Power Source Relationship................................30
           6.2. Metering Relationship....................................33
           6.3. Aggregation Relationship.................................35
        7. Relationship to Other Standards...............................35
        8. Security Considerations.......................................36
           8.1. Security Considerations for SNMP.........................36
        9. IANA Considerations...........................................37
           9.1. IANA Registration of new Power State Sets................37
           9.2. Updating the Registration of Existing Power State Sets...38
        10. References...................................................38
        11. Acknowledgments..............................................41
     
     
     
     
     Claise et al.           Expires March 9, 2014                  [Page 2]


     Internet-Draft              EMAN Framework               September 2013
     
     1. Introduction
     
        Network management is often divided into the five main areas defined
        in the ISO Telecommunications Management Network model: Fault,
        Configuration, Accounting, Performance, and Security Management
        (FCAPS) [X.700].  Not covered by this traditional management model is
        Energy Management, which is rapidly becoming a critical area of
        concern worldwide, as seen in [ISO50001].
     
        This document defines an energy management framework for devices
        within or connected to communication networks.  The devices, or
        components of these devices (such as router line cards, fans, disks),
        can then be monitored and controlled.  Monitoring includes measuring
        power, energy, demand, and attributes of power.  Energy control can
        be performed by setting devices' or components' power state. If a
        device contains batteries, these can also be monitored and
        controlled.
     
        This framework further describes how to identify, classify and
        provide context for such devices.  While the context information is
        not specific to Energy Management, some context attributes are
        specified in the framework, addressing the following use cases: how
        important is a device in terms of its business impact, how should
        devices be grouped for reporting and searching, and how should a
        device role be described.  These context attributes help in fault
        management and impact analysis while controlling the power states.
        Guidelines for using context for energy management are described.
     
        The framework introduces the concept of a power interface that is
        analogous to a network interface. A power interface is defined as an
        interconnection among devices where energy can be provided, received,
        or both.
     
        The most basic example of Energy Management is a single device
        reporting information about itself.  In many cases, however, energy
        is not measured by the device itself, but 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 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 (does
        a meter aggregate values from other devices).
     
        The relationships build on the power interface concept. The different
        relationships among devices and components, specified in this
        document, include: power source relationship, metering relationship,
        and aggregation relationship.
     
     
     Claise et al.           Expires March 9, 2014                  [Page 3]


     Internet-Draft              EMAN Framework               September 2013
     
     
     1.1. Energy Management Documents Overview
     
        The EMAN standard provides a set of specifications for Energy
        Management.  This document specifies the framework, per the Energy
        Management requirements specified in [EMAN-REQ].
     
        The applicability statement document [EMAN-AS] includes use cases, a
        cross-reference between existing standards and the EMAN standard, and
        a description of this frameworks relationship to other frameworks.
     
        The Energy Object Context MIB [EMAN-OBJECT-MIB] specifies objects for
        addressing Energy Object Identification, classification, context
        information, and relationships from the point of view of Energy
        Management.
     
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] specifies objects
        for monitoring of Power, Energy, Demand, Power Attributes, and Power
        States.
     
        The Battery Monitoring MIB [EMAN-BATTERY-MIB] defines managed objects
        that provide information on the status of batteries in managed
        devices.
     
     2. Terminology
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119 [RFC2119].
     
        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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                  [Page 4]


     Internet-Draft              EMAN Framework               September 2013
     
     
        $ Energy Management
          Energy Management is a set of functions for measuring, modeling,
          planning, and optimizing networks to ensure that the network and
          network attached devices use energy efficiently and appropriately
          for the nature of the application and the cost constraints of the
          organization.
     
          Reference: Adapted from [ITU-T-M-3400]
     
          NOTES:
          1. Energy management refers to the activities, methods, procedures
          and tools that pertain to measuring, modeling, planning,
          controlling and optimizing the use of energy in networked systems
          [NMF].
     
          2. Energy Management is a management domain which is congruent to
          any of the FCAPS areas of management in the ISO/OSI Network
          Management Model [TMN]. Energy Management for communication
          networks and attached devices is a subset or part of an
          organization's greater Energy Management Policies.
     
        $ Energy Management System (EnMS)
          An Energy Management System is a combination of hardware and
          software used to administer a network with the primary purpose of
          energy management.
     
          Reference: Adapted from [1037C]
     
          NOTES:
          1. An Energy Management System according to [ISO50001] (ISO-EnMS)
          is a set of systems or procedures upon which organizations can
          develop and implement an energy policy, set targets, action plans
          and take into account legal requirements related to energy use.  An
          ISO-EnMS allows organizations to improve energy performance and
          demonstrate conformity to requirements, standards, and/or legal
          requirements.
     
          2. Example ISO-EnMS:  Company A defines a set of policies and
          procedures indicating there should exist multiple computerized
          systems that will poll energy from their meters and pricing /
          source data from their local utility. Company A specifies that
          their CFO should collect information and summarize it quarterly to
          be sent to an accounting firm to produce carbon accounting
          reporting as required by their local government.
     
          3. For the purposes of EMAN, the definition from [1037C] is the
          preferred meaning of an Energy Management System (EnMS). The
     
     
     
     Claise et al.           Expires March 9, 2014                  [Page 5]


     Internet-Draft              EMAN Framework               September 2013
     
          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 Energy Objects to aid in
          Energy Management.
     
        $ Energy Control
          Energy Control is a part of Energy Management that deals with
          directing influence over Energy Objects.
     
        $ 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
     
     
     Claise et al.           Expires March 9, 2014                  [Page 6]


     Internet-Draft              EMAN Framework               September 2013
     
          1. Energy is the capacity of a system to produce external activity
          or perform work [ISO50001]
     
        $ 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
          The time rate at which energy is emitted, transferred, or received;
          usually expressed in watts (joules per second).
     
          Reference: [IEEE100]
     
        $ Nameplate Power
          The Nameplate Power is the nominal Power of a device as specified
          by the device manufacturer.
     
        $ Power Attributes
          Measurements of the electrical current, voltage, phase and
          frequencies at a given point in an electrical power system.
          Reference: Adapted from [IEC60050]
     
          NOTES:
          1. Power Attributes are not intended to be judgmental with respect
          to a reference or technical value and are independent of any usage
          context.
     
        $ Power Quality
          Characteristics of the electrical current, voltage, phase and
          frequencies at a given point in an electric power system, evaluated
          against a set of reference technical parameters. These parameters
          might, in some cases, relate to the compatibility between
     
     
     Claise et al.           Expires March 9, 2014                  [Page 7]


     Internet-Draft              EMAN Framework               September 2013
     
          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]
     
        $ Demand
          The average value of power or a related quantity over a specified
          interval of time. Note: Demand is expressed in kilowatts, kilovolt-
          amperes, kilovars, or other suitable units.
     
          Reference: [IEEE100]
     
          NOTES:
          1. For EMAN we use kilowatts.
     
        $ Power State
          A Power State is a condition or mode of a device that broadly
          characterizes its capabilities, power consumption, and
          responsiveness to input.
     
          Reference: Adapted from [IEEE1621]
     
        $ Power State Set
          A Power State Set is a collection of Power States that comprises a
          named or logical control grouping.
     
        $ Energy Object
          An Energy Object (EO) is an information model (class) that
          represents a piece of equipment that is part of, or attached to, a
          communications network which is monitored, controlled, or aids in
          the management of another device for Energy Management.
     
        $ Power Interface
          A Power Interface (or simply interface) is an information model
          (class) that represents the interconnections among devices or
          components where energy can be provided, received, or both.
     
        $ Energy Management Domain
     
     
     Claise et al.           Expires March 9, 2014                  [Page 8]


     Internet-Draft              EMAN Framework               September 2013
     
          An Energy Management Domain is a set of Energy Objects that is
          considered one unit of management.
     
        $ Energy Object Identification
          Energy Object Identification is a set of attributes that enable an
          Energy Object to be universally unique or linked to other systems.
     
        $ Energy Object Context
          Energy Object Context is a set of attributes that allow an Energy
          Management System to classify an Energy Object within an
          organization.
     
        $ Energy Object Relationship
          An Energy Object Relationship is an association among Energy
          Objects.
     
          NOTES
          1. Relationships can be named and could include Aggregation,
          Metering, and Power Source.
          Reference: Adapted from [CHEN]
     
        $ Power Source Relationship
          A Power Source Relationship is an Energy Object Relationship where
          one Energy Object provides power to one or more Energy Objects.
          These Energy Objects are referred to as having a Power Source
          Relationship.
     
        $ Metering Relationship
          A Metering Relationship is an Energy Object Relationship where one
          Energy Object measures power, energy, demand or power attributes of
          one or more other Energy Objects. The measuring Energy Object has a
          Metering Relationship with each of the measured objects.
     
        $ Aggregation Relationship
          An Aggregation Relationship is an Energy Object Relationship where
          one Energy Object aggregates Energy Management information of one
          or more other Energy Objects. The aggregating Energy Object has an
          Aggregation Relationship with each of the other Energy Objects.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                  [Page 9]


     Internet-Draft              EMAN Framework               September 2013
     
     
     3. Concerns Specific to Energy Management
     
        This section explains areas of concern for Energy Management that do
        not exist in traditional Network Management. This section describes
        target devices, outlines physical reference models, and lists the
        major concerns specific to Energy Management.
     
     
     3.1. Target Devices
        With Energy Management, there exists a wide variety of devices that
        may be contained in the same deployments as a communication network
        but comprise a separate facility, home, or power distribution
        network.
     
        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) using the Internet protocol. These target
        devices include:
           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
     
        The target devices may also include those communicating via non-IP
        protocols deployed among the power distribution and IP communication
        network.
     
     3.2. Physical Reference Model
     
        The following reference models describe physical power topologies
        that exist in parallel to the communication topology. While many more
        permutations of topologies can be created the following are some
        basic ones that show how Energy Management topologies differ from
        Network Management topologies.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 10]


     Internet-Draft              EMAN Framework               September 2013
     
        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 supply |########|      device     |
                    +--------------+        +-----------------+
     
        Single Power Supply with Multiple Devices
                      +---------------------------------------+
                      |       energy management system        |
                      +---------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                      +--------+        +------------------+
                      | power  |########|         device 1 |
                      | supply |   #    +------------------+-+
                      +--------+   #######|         device 2 |
                                     #    +------------------+-+
                                     #######|         device 3 |
                                            +------------------+
     
        Multiple Power Supply with Single Devices
                   +----------------------------------------------+
                   |          energy management system            |
                   +----------------------------------------------+
                       ^  ^              ^  ^              ^  ^
                  mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                       v  v              v  v              v  v
                   +----------+      +----------+      +----------+
                   | power    |######|  device  |######| power    |
                   | supply 1 |######|          |      | supply 2 |
                   +----------+      +----------+      +----------+
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 11]


     Internet-Draft              EMAN Framework               September 2013
     
     3.3. Concerns Differing from Network Management
     
           o  Identification of the power source of a device may be
              independent of the communication network and require unique
              identifiers.
     
           o  Controlling power for a device may have to be fulfilled by
              addressing the power source as opposed to directing control to
              the device. For example controlling a device by controlling the
              outlet of the PDU or controlling a simple light by controlling
              its outlet.
     
           o  Control of a device may need to be coordinated if there are
              multiple power supplies.
     
           o  Modeling of power when the flow of energy can be bi-directional
              and require a separate interface model from Network Management.
              For example energy received into a battery or energy provided
              from battery).
     
           o  Some devices may need out-of-band or proxy capabilities to
              respond to communications request even though it is in a non-
              operational power state.
     
           o  Estimates and source of measurements may vary among devices.
              For example when devices do not have the capability to measure
              power an estimate can be provided from the device or estimated
              by the EnMS. This may require annotation of a measurement.
     
           o  A device may require a separate abstract model to describe its
              components and interconnections than a model used to describe
              it for Network Management.
     
     
     3.4. Concerns Not Addressed
     
        Non-Electrical Equipment
     
        The primary focus of this framework is the management of Electrical
        Equipment.  Some Non-Electrical Equipment may be connected to
        communication networks and could have their energy managed if
        normalized to the electrical units for power and energy. Non-
        Electrical equipment that do not convert-to or present-as equivalent
        to Electrical Equipment is not addressed.
     
        Energy Procurement and Manufacturing
     
        While an EnMS may be a central point for corporate reporting, cost,
        environmental impact, and regulatory compliance, Energy Management in
     
     
     Claise et al.           Expires March 9, 2014                 [Page 12]


     Internet-Draft              EMAN Framework               September 2013
     
        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
           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 with 1000kW from a diesel
              source).
     
     4. Energy Management Abstraction
        Network management is often divided into the five main areas defined
        in the ISO Telecommunications Management Network model: Fault,
        Configuration, Accounting, Performance, and Security Management
        (FCAPS) [X.700].  This traditional management model does not cover
        Energy Management.
     
        This section describes a conceptual model of information that can be
        used for Energy Management. The classes and categories of attributes
        in the model are described with rationale for each.
     
     4.1. Conceptual Model
        To address Energy Management this specification describes an
        information model that can exist along with Network Management while
        addressing issues specific to Energy Management.
     
        An information model for Energy Management will need to describe a
        means to report information, provide control, and model the
        interconnections among physical entities (equipment).
     
        Therefore, this section proposes a similar conceptual model for
        physical entities to that used in Network Management: devices,
        components, and interfaces. This section then defines the additional
        attributes specific to Energy Management for those entities that are
        not available in existing Network Management models.
     
        For modeling the physical entities this section describes three
        classes:  a Device, a Component, and a Power Interface. These classes
        are sub-types of an abstract Energy Object class.
     
        For modeling additional attributes, this section describes attributes
        of an Energy Object for: identification, classification, context,
        control, power and energy.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 13]


     Internet-Draft              EMAN Framework               September 2013
     
        Since the interconnections between physical entities for Energy
        Management may have no relation to the interconnections for Network
        Management the Energy Object classes contain a separate Relationships
        class as an attribute to model these types of interconnections.
     
        The remainder of this section describes the conceptual model of the
        classes and categories of attributes in the information model. The
        formal definitions of the classes and attributes are specified in
        Section 5.
     
     4.2. Energy Object
        An Energy Object is an abstract class that contains the base
        attributes for Energy Management.  There are three types of Energy
        Objects: Device, Component and Power Interface.
     
     4.2.1. Device Class
        The Device Class is a sub-class of Energy Object that represents a
        physical piece of equipment.
     
        A Device Class instance may represent a device that is a consumer,
        producer, or meter, distributor, or store of energy.
     
        A Device Class instance may represent a physical device that contains
        other components.
     
     4.2.2. Component Class
        The Component Class is a sub-class of Energy Object that represents a
        part of a physical piece of equipment.
     
     4.2.3. Power Interface Class
        The power interface class is a sub-class of Energy Object that
        represents the interconnection among devices and components.
        There are some similarities between Power Interfaces and network
        interfaces.  A network interface can be set to different states, such
        as sending or receiving data on an attached line.  Similarly, a Power
        Interface can be receiving or providing power.
     
        Physically, a Power Interface instance can represent an AC power
        socket, an AC power cord attached to a device, or an 8P8C (RJ45) PoE
        socket, etc.
     
     4.3. Energy Object Attributes
        This section describes categories of attributes for an Energy Object.
     
     4.3.1. Identification
        A Universal Unique Identifier (UUID) [RFC4122] is used to uniquely
        and persistently identify an Energy Object. Ideally the UUID is used
        to distinguish the Energy Object within the EnMS.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 14]


     Internet-Draft              EMAN Framework               September 2013
     
        Every Energy Object has an optional unique printable name.  Possible
        naming conventions are: textual DNS name, MAC address of the device,
        interface ifName, or a text string uniquely identifying the Energy
        Object.  As an example, in the case of IP phones, the Energy Object
        name can be the device's DNS name.
     
        Additionally an alternate key is provided to allow an Energy Object
        to be optionally linked with models in different systems.
     
     4.3.2. Context in General
        In order to aid in reporting and in differentiation between Energy
        Objects, each object optionally contains information establishing its
        business, site, or organizational context within a deployment.
     
        Energy Objects contain a category attributed that broadly describes
        how the object 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 example, metered usage reported by a meter
        and consumption usage reported by a device connected to that meter
        may measure the same usage. With the two measurements identified by
        category and context an EnMS can make summarizations and inferences.
     
     4.3.3. Context: Importance
        An Energy Object can provide an importance value in the range of 1 to
        100 to help rank a device's use or relative value to the site.  The
        importance range is from 1 (least important) to 100 (most important).
        The default importance value is 1.
     
        For example: A typical office environment has several types of
        phones, which can be rated according to their business impact.  A
        public desk phone has a lower importance (for example, 10) than a
        business-critical emergency phone (for example, 100).  As another
        example: A company can consider that a PC and a phone for a customer-
        service engineer are more important than a PC and a phone for lobby
        use.
     
        Although EnMS and administrators can establish their own ranking, the
        following example is a broad recommendation for commercial
        deployments [CISCO-EW]:
     
           90 to 100 Emergency response
           80 to 90 Executive or business-critical
           70 to 79 General or Average
           60 to 69 Staff or support
           40 to 59 Public or guest
           1  to 39 Decorative or hospitality
     
     
     Claise et al.           Expires March 9, 2014                 [Page 15]


     Internet-Draft              EMAN Framework               September 2013
     
     
     4.3.4. Context: Keywords
        An Energy Object can provide a set of keywords.  These keywords are a
        list of tags that can be used for grouping, summary reporting within
        or between Energy Management Domains, and for searching.  All
        alphanumeric characters and symbols (other than a comma), such as #,
        (, $, !, and &, are allowed.  Potential examples are: IT, lobby,
        HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone,
        floor2, or SoftwareLab.  There is no default value for a keyword.
        Multiple keywords can be assigned to a device.  White spaces before
        and after the commas are excluded, as well as within a keyword
        itself. In such cases, commas separate the keywords and no spaces
        between keywords are allowed.  For example, "HR,Bldg1,Private".
     
     4.3.5. Context: Role
        An Energy Object contains a "role description" string that indicates
        the purpose the Energy Object serves in the EnMS.  This could be a
        string describing the context the device fulfills in deployment.
     
        Administrators can define any naming scheme for the role of a device.
        As guidance, a two-word role that combines the service the device
        provides along with type can be used [IPENERGY].
     
        Example types of devices: Router, Switch, Light, Phone, WorkStation,
        Server, Display, Kiosk, HVAC.
     
        Example Services by Line of Business:
     
           Line of Business     Service
           Education            Student, Faculty, Administration,
                                Athletic
           Finance              Trader, Teller, Fulfillment
           Manufacturing        Assembly, Control, Shipping
           Retail               Advertising, Cashier
           Support              Helpdesk, Management
           Medical              Patient, Administration, Billing
     
        Role as a two-word string: "Faculty Desktop", "Teller Phone",
        "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
        "Administration Switch".
     
     4.3.6. Context: Domain
        An Energy Object contains a string to indicate membership in an
        Energy Management Domain. An Energy Management Domain can be any
        collection of devices in a deployment, but it is recommended to map
        1:1 with a metered or sub-metered portion of the site.
     
        In building management, a meter refers to the meter provided by the
        utility used for billing and measuring power to an entire building or
     
     
     Claise et al.           Expires March 9, 2014                 [Page 16]


     Internet-Draft              EMAN Framework               September 2013
     
        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.  The Energy Management
        Domain may be configured on an Energy Object.
     
     4.4. Measurements
        An Energy Object contains attributes to describe power, energy and
        demand measurements.
     
        For the purposes of this framework, energy will be limited to
        electrical energy in watt-hours.  Other forms of Energy Objects that
        use or produce non-electrical energy may be modeled as an Energy
        Object but must provide information converted to and expressed in
        watt-hours.
     
        An analogy for understanding power versus energy measurements can be
        made to speed and distance in automobiles. Just as a speedometer
        indicates the rate of change of distance (speed), a power 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.
     
     4.4.1. Measurements: Power
        Each Energy Object contains a Nameplate Power attribute that
        describes the nominal power as specified by the manufacturer.
        Power Measurement. The EnMS can use the Nameplate Power for
        provisioning, capacity planning and (potentially) billing.
     
        Each Energy Object will have information that describes 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 IEC 61850 definition of
        unit multiplier for the SI (System International) units of measure.
        Measured values are represented in SI units obtained by BaseValue *
        (10 ^ Scale).  For example, if current power usage of an Energy
        Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the
     
     
     Claise et al.           Expires March 9, 2014                 [Page 17]


     Internet-Draft              EMAN Framework               September 2013
     
        value of the scaling factor.  3W implies that the BaseValue is 3 and
        Scale = 0, whereas 3mW implies BaseValue = 3 and ScaleFactor = -3.
     
        An Energy Object indicates how the power measurement was obtained
        with a caliber 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
     
     4.4.2. Measurements: Power Attributes
        Optionally, an Energy Object describes the Power measurements with
        Power Attribute information reflecting the electrical characteristics
        of the measurement. These Power Attributes adhere to the IEC 61850 7-
        2 standard for describing AC measurements.
     
     4.4.3. Measurements: Energy
        Optionally, an Energy Object that can report actual power readings
        will have energy attributes that provide the energy used, produced,
        or stored in kWh.
     
     4.4.4. Measurements: Demand
        Optionally, an Energy Object will provide demand information over
        time. Demand measurements can be provided when the Energy Object is
        capable of measuring actual power.
     
     4.5. Control
        An Energy Object can be controlled by setting a Power State.  An
        Energy Object implements at least one set of Power States consisting
        of at least two states, an on state and an off state.
     
        Each Energy Object should indicate the sets of Power States that it
        implements.  Well-known Power States Sets are registered with IANA.
     
        When a device is set to a particular Power State, it may be busy. The
        device will set the desired Power State and then update the actual
        Power State when it changes.  There are then two Power State control
        variables: actual and requested.
        There are many existing standards for and implementations of Power
        States.  An Energy Object can support a mixed set of Power States
        defined in different standards. A basic example is given by the three
        Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The
        DMTF [DMTF], ACPI [ACPI], and PWG define larger numbers of Power
        States.
     
        The semantics of a Power State are specified by
           a) the functionality provided by an Energy Object in this state,
     
     
     Claise et al.           Expires March 9, 2014                 [Page 18]


     Internet-Draft              EMAN Framework               September 2013
     
           b) a limitation of the power that an Energy Object uses in this
        state,
           c) a combination of a) and b)
     
        The semantics of a Power State should be clearly defined. Limitation
        (curtailment) of the power used by an Energy Object in a state is
        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.
           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.
     
     4.5.1. Power State Sets
        There are several standards and implementations of Power State Sets.
        An Energy Object can support one or multiple Power State Set
        implementation(s) concurrently.
     
        There are currently three Power State Sets advocated:
          IEEE1621(256) - [IEEE1621]
          DMTF(512)     - [DMTF]
          EMAN(768)     - [EMAN-MONITORING-MIB]
     
        The respective specific states related to each Power State Set are
        specified in the following sections. The guidelines for the
        modification of Power State Sets are specified in the IANA
        Considerations Section.
     
     4.5.2. Power State Set: IEEE1621
        The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary
        states: on, off or sleep.
     
           o  on(0)    - The device is fully On and all features of the
              device are in working mode.
           o  off(1)   - The device is mechanically switched off and does not
              consume energy.
           o  sleep(2) - The device is in a power saving mode, and some
              features may not be available immediately.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 19]


     Internet-Draft              EMAN Framework               September 2013
     
     4.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
     
     4.5.4. Power State Set: IETF EMAN
        An EMAN Power State Set represents an attempt at a standard approach
        for modeling the different levels of power of a device.  The EMAN
        Power States are an expansion of the basic Power States as defined in
        [IEEE1621] that also incorporates the Power States defined in [ACPI]
        and [DMTF].  Therefore, in addition to the non-operational states as
        defined in [ACPI] and [DMTF] standards, several intermediate
        operational states have been defined.
     
        An Energy Object may implement fewer or more Power States than a
        particular EMAN Power State Set specifies. In this case, the Energy
     
     
     Claise et al.           Expires March 9, 2014                 [Page 20]


     Internet-Draft              EMAN Framework               September 2013
     
        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.
     
                 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
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 21]


     Internet-Draft              EMAN Framework               September 2013
     
        transitioned into an operational state.  For example, processors are
        not executing, but processor context is maintained.
     
                 lowMinus(7) : Indicates some Energy Object features may not
        be available and the Energy Object has taken measures or selected
        options to provide less than low(8) usage.
     
                 low(8)      : Indicates some features may not be available
        and the Energy Object has taken measures or selected options to
        provide less than mediumMinus(9) usage.
     
                 mediumMinus(9): Indicates all Energy Object features are
        available but the Energy Object has taken measures or selected
        options to provide less than medium(10) usage.
     
                 medium(10)  : Indicates all Energy Object features are
        available but the Energy Object has taken measures or selected
        options to provide less than highMinus(11) usage.
                 highMinus(11): Indicates all Energy Object features are
        available and power usage is less than high(12).
     
                 high(12)    : Indicates all Energy Object features are
        available and the Energy Object is consuming the highest power.
     
     4.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)
          sleep     Hibernate    G1, S4         Hibernate(3)
          sleep     Sleep-Deep   G1, S3         Sleep(4)
          sleep     Sleep-Light  G1, S2         Standby(5)
          sleep     Sleep-Light  G1, S1         Ready(6)
     
          Operational states:
          on        on           G0, S0, P5     LowMinus(7)
          on        on           G0, S0, P4     Low(8)
          on        on           G0, S0, P3     MediumMinus(9)
          on        on           G0, S0, P2     Medium(10)
          on        on           G0, S0, P1     HighMinus(11)
          on        on           G0, S0, P0     High(12)
     
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 22]


     Internet-Draft              EMAN Framework               September 2013
     
     
     4.6. Relationships
        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 participants in the relationship and a description of the
        type of relationship. The types of relationships are:  power source.
        metering, and aggregations.
     
           o  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.
     
              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  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  The Aggregation Relationship gives a model of devices that may
              aggregate (sum, average, etc) values for other devices.  The
              Aggregation Relationship is slightly different compared to the
              other relationships as this refers more to a management
              function.
     
        In some situations, it is not possible to discover the Energy Object
        Relationships, and they must be set by an EnMS or administrator.
        Given that relationships can be assigned manually, the following
        sections describes guidelines for use.
     
     
     4.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, this Energy Management framework proposes a
        series of guidelines, indicated with "SHOULD" and "MAY".
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 23]


     Internet-Draft              EMAN Framework               September 2013
     
     4.6.2. Guidelines: Power Source
        Power Source relationships are intended to identify the connections
        between Power Interfaces. This is analogous to a Layer 2 connection
        in networking devices (a "one-hop connection").
     
        The preferred modeling would be for Power Interfaces to participate
        in Power Source Relationships. It 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.
     
     4.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 with a complex wiring topology, this
        relationship type can be seen as an arbitrary set.
     
        Devices may include measuring hardware for components and Power
        Interfaces or for the entire Device. For example, some PDUs may have
        the ability to measure Power for each Power Interface (metered by
        outlet). Others may be able to control power at each Power Interface
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 24]


     Internet-Draft              EMAN Framework               September 2013
     
        but can only measure Power at the Power Inlet and a total for all
        Power Interfaces (metered by device).
     
        In such cases the Device SHOULD be modeled as an Energy Object that
        meters all of its Power Outlets and each Power Outlet MAY be metered
        by the Energy Object representing the Device.
     
        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.
     
     4.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.
     
        Aggregation SHOULD be used for power and energy. It MAY be used for
        aggregation of other values from the information model, but the rules
        and logical ability to aggregate each attribute is out of scope for
        this document.
     
        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.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 25]


     Internet-Draft              EMAN Framework               September 2013
     
           o  Aggregators SHOULD log or provide notification in the case of
              errors or missing values while performing aggregation.
     
     4.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 physical entities
              like outlets to be "ganged" together as a logical entity for
              simplified management purposes, could be modeled with an
              extension called a "gang relationship", whose semantics would
              specify the Energy Objects' grouping.
     
     5. Energy Management Information Model
     
        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.
     
        EDITORs NOTE:  The working group is converging on the use of
        code/pseudo-code rather than ascii UML diagram. If agreeable we can
        either indicate a BNF syntax in a formal syntax section or use the
        following table if obvious:
     
        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
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 26]


     Internet-Draft              EMAN Framework               September 2013
     
        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
        }
     
        CLASS Device EXTENDS EnergyObject {
              eocategory   : enum { producer, consumer, meter, distributor,
        store }
        }
     
        CLASS Component EXTENDS EnergyObject
              eocategory   : enum { producer, consumer, meter, distributor,
        store }
        }
     
        CLASS Interface EXTENDS EnergyObject{
              eoIfType : enum ( inlet, outlet, both}
        }
     
        CLASS Nameplate {
              nominalPower : PowerMeasurement
              details      : URI
        }
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 27]


     Internet-Draft              EMAN Framework               September 2013
     
        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
              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
              interval       : long
              intervalMode   : enum { periodic, sliding, total }
              intervalWindow : TimeInterval
              sampleRate     : TimeInterval
              status         : enum { active, inactive }
              measurements[0..n] : TimedMeasurements
        }
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 28]


     Internet-Draft              EMAN Framework               September 2013
     
        CLASS PowerStateSet {
              powerSetIdentifier : int
              name               : string
              powerStates [0..n] : PowerState
              operState          : int
              adminState         : int
              reason             : string
              configuredTime     : timestamp
        }
     
        CLASS PowerState {
              powerStateIdentifier  : int
              name             : string
              cardinality      : int
              maximumPower     : PowerMeasurement
              totalTimeInState : time
              entryCount       : long
        }
     
        CLASS PowerAttribute {
     
           // container for attributes
                 acQuality   : ACQuality
        }
     
        CLASS ACQuality {
           acConfiguration : enum {SNGL, DEL,WYE}
           avgVoltage   : long
           avgCurrent   : long
           frequency    : long
           unitMultiplier  : int
           accuracy    : int
           totalActivePower   : long
           totalReactivePower : long
           totalApparentPower : long
           totalPowerFactor : long
           phases [0..2]  : ACPhase
        }
     
        CLASS ACPhase {
           phaseIndex : long
           avgCurrent : long
           activePower : long
           reactivePower : long
           apparentPower : long
           powerFactor : long
        }
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 29]


     Internet-Draft              EMAN Framework               September 2013
     
        CLASS DelPhase EXTENDS ACPhase {
           phaseToNextPhaseVoltage  : long
           thdVoltage : long
           thdCurrent : long
        }
     
        CLASS WYEPhase EXTENDS ACPhase {
           phaseToNeutralVoltage : long
           thdCurrent : long
           thdVoltage : long
        }
     
     6. Modeling Relationships between Devices
        In this section we give examples of how to use the Energy Management
        framework relationships to model physical topologies.  Where
        applicable, we show how the framework can be applied when Devices
        have the capability to model Power Interfaces.  We also show how the
        framework can be applied when devices cannot support Power Interfaces
        but only monitor information or control the Device as a whole. For
        instance, a PDU may only be able to measure power and energy for the
        entire unit without the ability to distinguish among the inlets or
        outlet.
     
     6.1. Power Source Relationship
     
        The Power Source relationship is used to model the interconnections
        between Devices, Components and/Power Interfaces to indicate the
        source of energy for an Energy Object. Given the following examples
        Devices we can show various types of configurations that would model
        the reference or other topologies.
     
        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.
     
     
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 30]


     Internet-Draft              EMAN Framework               September 2013
     
     
        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:
     
           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.
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 31]


     Internet-Draft              EMAN Framework               September 2013
     
           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:
     
           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.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 32]


     Internet-Draft              EMAN Framework               September 2013
     
     
        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           |      |          |
           +-------+------+                 +------+----------+
     
     
        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              +------------+
     6.2. Metering Relationship
     
        Case 1: Metering between two Devices
     
        The metering topology between two devices is closely related to the
        power source topology.  It is based on the assumption that in many
        cases the power provided and the power received is the same for both
        peers of a power source relationship.
     
        We define in this case a Metering Relationship between two Devices or
        Power Interfaces of Devices that have a power source relationship.
        Power and energy values measured at one peer of the power source
        relationship are reported for the other peer as well.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 33]


     Internet-Draft              EMAN Framework               September 2013
     
        The Metering Relationship is independent of the direction of the
        Power Source Relationship.  The most common case is that values
        measured at the power provider are reported for the power receiver.
     
           +-----+---+    meteredBy +--------+   poweredBy +-------+
           |Meter| PI|--------------| switch |-------------| phone |
           +-----+---+ meters       +--------+ powers      +-------+
                   |                                           |
                   |                                 meteredBy |
                   +-------------------------------------------+
                    meters
     
        Case 2: Metering among many Devices
     
        A Sub-meter in a power distribution system can logically measure the
        power or energy for all devices downstream from the meter in the
        power distribution system.  As such, a Power metering relationship
        can be seen as a relationship between a meter DEvice and all of the
        devices downstream from the meter.
     
        We define in this case a Power Source relationship between a metering
        device and devices downstream from the meter.
     
        In cases where the Power Source topology cannot be discovered or
        derived from the information available in the Energy Management
        Domain, the Metering Topology can be used to relate the upstream
        meter to the downstream devices in the absence of specific power
        source relationships.
     
        A Metering Relationship can occur between devices that are not
        directly connected, as shown in the following figure:
     
                           +---------------+
                           |   Device 1    |
                           +---------------+
                           |      PI       |
                           +---------------+
                                   |
                           +---------------+
                           |     Meter     |
                           +---------------+
                                   .
                                   .
                                   .
                  meters        meters           meters
            +----------+   +----------+   +-----------+
            | Device A |   | Device B |   | Device C  |
            +----------+   +----------+   +-----------+
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 34]


     Internet-Draft              EMAN Framework               September 2013
     
        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.
     
     6.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.
        An Aggregation Relationship is an Energy Object Relationship where
        one Energy Object (called the Aggregate Energy Object) aggregates the
        Energy Management information of one or more other Energy Objects.
        These Energy Objects are said to have an Aggregation Relationship.
     
        The functions that the aggregation point may perform include the
        calculation of values such as average, count, maximum, median,
        minimum, or the listing (collection) of the aggregation values, etc.
        Based on the experience gained on aggregations at the IETF [draft-
        ietf-ipfix-a9n-08], the aggregation function in the EMAN framework is
        limited to the summation.
     
        When aggregation occurs across a set of entities, values to be
        aggregated may be missing for some entities.  The EMAN framework does
        not specify how these should be treated, as different implementations
        may have good reason to take different approaches.  One common
        treatment is to define the aggregation as missing if any of the
        constituent elements are missing (useful to be most precise). Another
        is to treat the missing value as zero (useful to have continuous data
        streams).
     
        The specifications of aggregation functions are out of scope of the
        EMAN framework, but must be clearly specified by the equipment
        vendor.
     
     7. Relationship 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 IEC
        61850.
     
        Specific examples include:
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 35]


     Internet-Draft              EMAN Framework               September 2013
     
           o  The scaling factor, which represents Energy Object usage
              magnitude, conforms to the IEC 61850 definition of unit
              multiplier for the SI (System International) units of measure.
           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 IEC 61850 7-2 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.
     
     
     8. Security Considerations
        Regarding the data attributes specified here, some or all may be
        considered sensitive or vulnerable in some network environments.
        Reading or writing these attributes without proper protection such as
        encryption or access authorization may have negative effects on the
        network capabilities.
     
     8.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:
           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.
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 36]


     Internet-Draft              EMAN Framework               September 2013
     
        It is recommended that implementers consider the security features as
        provided by the SNMPv3 framework (see [RFC3410], section 8),
        including full support for the SNMPv3 cryptographic mechanisms (for
        authentication and privacy).
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3 and to
        enable cryptographic security.  It is then a customer/operator
        responsibility to ensure that the SNMP entity giving access to an
        instance of these MIB modules is properly configured to give access
        to the objects only to those principals (users) that have legitimate
        rights to GET or SET (change/create/delete) them.
     
     9. IANA Considerations
     9.1. IANA Registration of new Power State 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 4. 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 adopted; since it would lead to proliferation of
        Power State Sets.
     
        Power states in a Power State Set are limited to 255 distinct
        values. New Power State Set must be assigned the next available
        numeric identifier that is a multiple of 256.
     
     9.1.1. IANA Registration of the IEEE1621 Power State Set
        This document specifies a set of values for the IEEE1621 Power State
        Set [IEEE1621].  The list of these values with their identifiers is
        given in Section 4.6.2.  IANA created a new registry for IEEE1621
        Power State Set identifiers and filled it with the initial list of
        identifiers.
     
        New assignments (or potentially deprecation) for the IEEE1621 Power
        State Set is administered by IANA through Expert Review [RFC5226],
        i.e., review by one of a group of experts designated by an IETF Area
        Director.  The group of experts must check the requested state for
        completeness and accuracy of the description.
     
     9.1.2. IANA Registration of the DMTF Power State Set
        This document specifies a set of values for the DMTF Power State
        Set.  The list of these values with their identifiers is given in
        Section 4. IANA has created a new registry for DMTF Power State Set
        identifiers and filled it with the initial list of identifiers.
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 37]


     Internet-Draft              EMAN Framework               September 2013
     
        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.
     
     9.1.3. IANA Registration of the EMAN Power State Set
        This document specifies a set of values for the EMAN Power State
        Set.  The list of these values with their identifiers is given in
        Section 4.6.4.  IANA has created a new registry for EMAN Power State
        Set identifiers and filled it with the initial list of identifiers.
     
        New assignments (or potentially deprecation) for the EMAN Power
        State Set is administered by IANA through Expert Review [RFC5226],
        i.e., review by one of a group of experts designated by an IETF Area
        Director.  The group of experts must check the requested state for
        completeness and accuracy of the description.
     
     9.1.4. Batteries Power State Set
        Batteries have operational and administrational states that could be
        represented as a power state set. Since the work for battery
        management is parallel to this document, we are not proposing any
        Power State Sets for batteries at this time.
     
     9.2. Updating the Registration of Existing Power State Sets
        With the evolution of standards, over time, it may be important to
        deprecate some of the existing the Power State Sets, or to add or
        deprecate some Power States within a Power State Set.
     
        The registrant shall publish an Internet-draft or an individual
        submission with the clear specification on deprecation of Power
        State Sets or Power States registered with IANA.  The deprecation or
        addition shall be administered by IANA through Expert Review
        [RFC5226], i.e., review by one of a group of experts designated by
        an IETF Area Director. The process should also allow for a mechanism
        for cases where others have significant objections to claims on
        deprecation of a registration.
     
     10. 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
     
     
     Claise et al.           Expires March 9, 2014                 [Page 38]


     Internet-Draft              EMAN Framework               September 2013
     
     
        [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique
                  Identifier (UUID) URN Namespace", RFC 4122, July 2005
     
        [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an
                  IANA Considerations Section in RFCs", RFC 5226, May 2008
     
        [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB (Version4)",
                  RFC 6933, May 2013
     
        [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
     
        [ACPI] "Advanced Configuration and Power Interface Specification",
                  http://www.acpi.info/spec30b.htm
     
        [IEEE1621]  "Standard for User Interface Elements in Power Control of
                  Electronic Devices Employed in Office/Consumer
                  Environments", IEEE 1621, December 2004
     
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control Connectivity
                  Discovery", 2005
     
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information Base
                  extension module for TIA-TR41.4 media endpoint discovery
                  information", July 2005
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 39]


     Internet-Draft              EMAN Framework               September 2013
     
        [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 recommandation on Management Functions (M.3400),
                  1997
     
        [NMF] "Network Management Fundamentals", Alexander Clemm, ISBN: 1-
                  58720-137-2, 2007
     
        [TMN] "TMN Management Functions : Performance Management", ITU-T
                  M.3400
     
        [1037C] US Department of Commerce, Federal Standard 1037C,
                  http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm
     
        [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms"
                  http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?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?openform
     
     
     
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 40]


     Internet-Draft              EMAN Framework               September 2013
     
        [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/Enterprise/Border
                  less_Networks/Energy_Management/energywisedg.html
     
     
     
     11. Acknowledgments
     
        The authors would like to 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.
     
     
     
     
     Claise et al.           Expires March 9, 2014                 [Page 41]


     Internet-Draft              EMAN Framework               September 2013
     
     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
        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 March 9, 2014                 [Page 42]
     

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