tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7326

Informational
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: EMAN

Energy Management Framework

Part 1 of 2, p. 1 to 29
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        J. Parello
Request for Comments: 7326                                     B. Claise
Category: Informational                              Cisco Systems, Inc.
ISSN: 2070-1721                                             B. Schoening
                                                  Independent Consultant
                                                              J. Quittek
                                                         NEC Europe Ltd.
                                                          September 2014


                      Energy Management Framework

Abstract

   This document defines a framework for Energy Management (EMAN) for
   devices and device components within, or connected to, communication
   networks.  The framework presents a physical reference model and
   information model.  The information model consists of an Energy
   Management Domain as a set of Energy Objects.  Each Energy Object can
   be attributed with identity, classification, and context.  Energy
   Objects can be monitored and controlled with respect to power, Power
   State, energy, demand, Power Attributes, and battery.  Additionally,
   the framework models relationships and capabilities between Energy
   Objects.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7326.

Page 2 
Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Target Devices ..................................................9
   4. Physical Reference Model .......................................10
   5. Areas Not Covered by the Framework .............................11
   6. Energy Management Abstraction ..................................12
      6.1. Conceptual Model ..........................................12
      6.2. Energy Object (Class) .....................................13
      6.3. Energy Object Attributes ..................................15
      6.4. Measurements ..............................................18
      6.5. Control ...................................................19
      6.6. Relationships .............................................25
   7. Energy Management Information Model ............................29
   8. Modeling Relationships between Devices .........................33
      8.1. Power Source Relationship .................................33
      8.2. Metering Relationship .....................................37
      8.3. Aggregation Relationship ..................................38
   9. Relationship to Other Standards ................................39
   10. Security Considerations .......................................39
      10.1. Security Considerations for SNMP .........................40
   11. IANA Considerations ...........................................41
      11.1. IANA Registration of New Power State Sets ................41
      11.2. Updating the Registration of Existing Power State Sets ...42
   12. References ....................................................43
      12.1. Normative References .....................................43
      12.2. Informative References ...................................44
   13. Acknowledgments ...............................................45
   Appendix A. Information Model Listing .............................46

Top      ToC       Page 3 
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, per the Energy
   Management requirements specified in [RFC6988].  The devices, or the
   components of these devices (such as line cards, fans, and disks),
   can then be monitored and controlled.  Monitoring includes measuring
   power, energy, demand, and attributes of power.  Energy Control can
   be performed by setting a device's or component's state.  The devices
   monitored by this framework can be either of the following:

   o  consumers of energy (such as routers and computer systems) and
      components of such devices (such as line cards, fans, and disks)

   o  producers of energy (like an uninterruptible power supply or
      renewable energy system) and their associated components (such as
      battery cells, inverters, or photovoltaic panels)

   This framework further describes how to identify, classify, and
   provide context for such devices.  While context information is not
   specific to Energy Management, some context attributes are specified
   in the framework, addressing the following use cases:

   o  How important is a device in terms of its business impact?

   o  How should devices be grouped for reporting and searching?

   o  How should a device role be described?

   Guidelines for using context for Energy Management are described.

   The framework introduces the concept of a Power Interface that is
   analogous to a network interface.  A Power Interface is defined as an
   interconnection among devices where energy can be provided, received,
   or both.

   The most basic example of Energy Management is a single device
   reporting information about itself.  In many cases, however, energy
   is not measured by the device itself but is measured upstream in the
   power distribution tree.  For example, a Power Distribution Unit
   (PDU) may measure the energy it supplies to attached devices and

Top      ToC       Page 4 
   report this to an Energy Management System.  Therefore, devices often
   have relationships to other devices or components in the power
   network.  An Energy Management System (EnMS) generally requires an
   understanding of the power topology (who provides power to whom), the
   Metering topology (who meters whom), and the potential Aggregation
   (who aggregates values of others).

   The relationships build on the Power Interface concept.  The
   different relationships among devices and components, as specified in
   this document, include power source, Metering, and Aggregation
   Relationships.

   The framework does not cover non-electrical equipment, nor does it
   cover energy procurement and manufacturing.

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 the above
   interpretation only when in ALL CAPS.  Lowercase uses of these words
   are not to be interpreted as carrying the significance of RFC 2119
   key words.

   In this section, some terms have a NOTE that is not part of the
   definition itself but accounts for differences between terminologies
   of different standards organizations or further clarifies the
   definition.

   The terms are listed in an order that aids in reading where terms may
   build off a previous term, as opposed to an alphabetical ordering.
   Some terms that are common in electrical engineering or that describe
   common physical items use a lowercase notation.

   Energy Management
      Energy Management is a set of functions for measuring, modeling,
      planning, and optimizing networks to ensure that the network and
      network-attached devices use energy efficiently and appropriately
      for the nature of the application and the cost constraints of the
      organization.

      Reference: Adapted from [TMN].

Top      ToC       Page 5 
      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 that is congruent to
         any of the FCAPS areas of management in the ISO/OSI Network
         Management Model [TMN].  Energy Management for communication
         networks and attached devices is a subset or part of an
         organization's greater Energy Management Policies.

   Energy Management System (EnMS)
      An Energy Management System is a combination of hardware and
      software used to administer a network, with the primary purpose of
      Energy Management.

      NOTES:

      1. An Energy Management System according to [ISO50001] (ISO-EnMS)
         is a set of systems or procedures upon which organizations can
         develop and implement an energy policy, set targets and 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 that there should exist multiple
         computerized systems that will poll energy measurements from
         their meters and pricing / source data from their local
         utility.  Company A specifies that their CFO (Chief Financial
         Officer) should collect information and summarize it quarterly
         to be sent to an accounting firm to produce carbon accounting
         reporting as required by their local government.

      3. For the purposes of EMAN, the definition herein is the
         preferred meaning of an EnMS.  The definition from [ISO50001]
         can be referred to as an ISO Energy Management System
         (ISO-EnMS).

   Energy Monitoring
      Energy Monitoring is a part of Energy Management that deals with
      collecting or reading information from devices to aid in Energy
      Management.

Top      ToC       Page 6 
   Energy Control
      Energy Control is a part of Energy Management that deals with
      directing influence over devices.

   electrical equipment
      This is a general term that includes materials, fittings, devices,
      appliances, fixtures, apparatus, machines, etc., that are used as
      a part of, or in connection with, an electric installation.

      Reference: [IEEE100].

   non-electrical equipment (mechanical equipment)
      This is a general term that includes materials, fittings, devices,
      appliances, fixtures, apparatus, machines, etc., that are used as
      a part of, or in connection with, non-electrical power
      installations.

      Reference: Adapted from [IEEE100].

   device
      A device is a piece of electrical or non-electrical equipment.

      Reference: Adapted from [IEEE100].

   component
      A component is a part of electrical or non-electrical equipment
      (device).

      Reference: Adapted from [TMN].

   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
      Energy is 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].

Top      ToC       Page 7 
      NOTE:

      1. Energy is the capacity of a system to produce external activity
         or perform work [ISO50001].

   power
      Power is the time rate at which energy is emitted, transferred, or
      received; power is usually expressed in watts (joules per second).

      Reference: [IEEE100].

   demand
      Demand is 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].

      NOTE:

      1. While IEEE100 defines demand in kilo measurements, for EMAN we
         use watts with any suitable metric prefix.

   provide energy
      A device (or component) "provides" energy to another device if
      there is an energy flow from this device to the other one.

   receive energy
      A device (or component) "receives" energy from another device if
      there is an energy flow from the other device to this one.

   meter (energy meter)
      A meter is a device intended to measure electrical energy by
      integrating power with respect to time.

      Reference: Adapted from [IEC60050].

   battery
      A battery is one or more cells (consisting of an assembly of
      electrodes, electrolyte, container, terminals, and (usually)
      separators) that are a source and/or store of electric energy.

      Reference: Adapted from [IEC60050].

   Power Interface
      A Power Interface is a power inlet, outlet, or both.

Top      ToC       Page 8 
   Nameplate Power
      The Nameplate Power is the nominal power of a device as specified
      by the device manufacturer.

   Power Attributes
      Power Attributes are measurements of the electrical current,
      voltage, phase, and frequencies at a given point in an electrical
      power system.

      Reference: Adapted from [IEC60050].

      NOTE:

      1. Power Attributes are not intended to provide any bounds or
         recommended range for the value.  They are simply the reading
         of the value associated with the attribute in question.

   Power Quality
      "Power Quality" refers to characteristics of the electrical
      current, voltage, phase, and frequencies at a given point in an
      electric power system, evaluated against a set of reference
      technical parameters.  These parameters might, in some cases,
      relate to the compatibility between electricity supplied in an
      electric power system and the loads connected to that electric
      power system.

      Reference: [IEC60050].

      NOTE:

      1. Electrical characteristics representing Power Quality
         information are typically required by customer facility Energy
         Management Systems.  Electrical characteristics are 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].

Top      ToC       Page 9 
   Power State
      A Power State is a condition or mode of a device (or component)
      that broadly characterizes its capabilities, power, and
      responsiveness to input.

      Reference: Adapted from [IEEE1621].

   Power State Set
      A Power State Set is a collection of Power States that comprises a
      named or logical control grouping.

3.  Target Devices

   With Energy Management, there exists a wide variety of devices that
   may be contained in the same deployment as a communication network
   but comprise a separate facility, home, or power distribution
   network.

   Energy Management has special challenges because a power distribution
   network supplies energy to devices and components, while a separate
   communications network monitors and controls the power distribution
   network.

   The target devices for Energy Management are all devices that can be
   monitored or controlled (directly or indirectly) by an Energy
   Management System (EnMS).  These target devices include, for example:

   o  Simple electrical appliances and fixtures

   o  Hosts, such as a PC, a server, or a printer

   o  Switches, routers, base stations, and other network equipment such
      as middleboxes

   o  Components within devices, e.g., a line card inside a switch

   o  Batteries functioning as a device or component that is a store of
      energy

   o  Devices or components that charge or produce energy, such as solar
      cells, charging stations, or generators

   o  Power over Ethernet (PoE) endpoints

   o  Power Distribution Units (PDUs)

   o  Protocol gateway devices for Building Management Systems (BMS)

Top      ToC       Page 10 
   o  Electrical meters

   o  Sensor controllers with subtended sensors

   Target devices include devices that communicate via the Internet
   Protocol (IP) as well as devices using other means for communication.
   The latter are managed through gateways or proxies that can
   communicate using IP.

4.  Physical Reference Model

   The following reference model describes physical power topologies
   that exist in parallel with a communication topology.  While many
   more topologies can be created with a combination of devices, the
   following are some basic ones that show how Energy Management
   topologies differ from Network Management topologies.

       NOTE: "###" is used to denote a transfer of energy.
             "- >" is used to denote a transfer of information.

                         Basic Energy Management:

                        +--------------------------+
                        | Energy Management System |
                        +--------------------------+
                                    ^  ^
                         monitoring |  | control
                                    v  v
                                +---------+
                                | device  |
                                +---------+


                            Basic Power Supply:

                +-----------------------------------------+
                |         Energy Management System        |
                +-----------------------------------------+
                      ^  ^                       ^  ^
           monitoring |  | control    monitoring |  | control
                      v  v                       v  v
                +--------------+        +-----------------+
                | power source |########|      device     |
                +--------------+        +-----------------+

Top      ToC       Page 11 
                Single Power Supply with Multiple Devices:

                  +---------------------------------------+
                  |       Energy Management System        |
                  +---------------------------------------+
                     ^  ^                       ^  ^
          monitoring |  | control    monitoring |  | control
                     v  v                       v  v
                  +--------+        +------------------+
                  | power  |########|         device 1 |
                  | source |   #    +------------------+-+
                  +--------+   #######|         device 2 |
                                 #    +------------------+-+
                                 #######|         device 3 |
                                        +------------------+


                Multiple Power Supplies with Single Device:

             +----------------------------------------------+
             |          Energy Management System            |
             +----------------------------------------------+
                 ^  ^              ^  ^              ^  ^
            mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                 v  v              v  v              v  v
             +----------+      +----------+      +----------+
             | power    |######|  device  |######| power    |
             | source 1 |      |          |      | source 2 |
             +----------+      +----------+      +----------+

5.  Areas Not Covered by the Framework

   While this framework is intended as a framework for Energy Management
   in general, there are some areas that are not covered.

   Non-Electrical Equipment

      The primary focus of this framework is the management of
      electrical equipment.  Non-electrical equipment, which is not
      covered in this framework, could nevertheless be modeled by
      providing interfaces that comply with the framework: for example,
      using the same units for power and energy.  Therefore,
      non-electrical equipment that does not "convert to" or
      "present as" an entity equivalent to electrical equipment is not
      addressed.

Top      ToC       Page 12 
   Energy Procurement and Manufacturing

      While an EnMS may be a central point for corporate reporting, cost
      computation, environmental impact analysis, and regulatory
      compliance reporting, Energy Management in this framework excludes
      energy procurement and the environmental impact of energy use.

      As such, the framework does not include:

      o  Cost in currency or environmental units of manufacturing a
         device

      o  Embedded carbon or environmental equivalences of a device

      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 the transfer of energy
         from a diesel source)

6.  Energy Management Abstraction

   This section describes a conceptual model of information that can be
   used for Energy Management.  The classes and categories of attributes
   in the model are described, with a rationale for each.

6.1.  Conceptual Model

   This section describes an information model that addresses issues
   specific to Energy Management and complements existing Network
   Management models.

   An information model for Energy Management will need to describe a
   means to monitor and control devices and components.  The model will
   also need to describe the relationships among, and connections
   between, devices and components.

   This section defines a conceptual model for devices and components
   that is similar to the model 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.

Top      ToC       Page 13 
   For modeling the devices and components, this section describes three
   classes denoted by a "(Class)" suffix: a Device (Class), a Component
   (Class), and a Power Interface (Class).  These classes are sub-types
   of an abstract Energy Object (Class).

            Summary of Notation for Modeling Physical Equipment

         Physical         Modeling (Metadata)      Model Instance
         ---------------------------------------------------------
         equipment        Energy Object (Class)    Energy Object

         device           Device (Class)           Device

         component        Component (Class)        Component

         inlet/outlet     Power Interface (Class)  Power Interface

   This section then describes the attributes of an Energy Object
   (Class) for identification, classification, context, control, power,
   and energy.

   Since the interconnections between devices and components for Energy
   Management may have no relation to the interconnections for Network
   Management, the Energy Object (Classes) contain a separate
   Relationships (Class) as an attribute to model these types of
   interconnections.

   The next sections describe each of the classes and categories of
   attributes in the information model.

   Not all of the attributes are mandatory for implementations.
   Specifications describing implementations of the information model in
   this framework need to be explicit about which are mandatory and
   which are optional to implement.

   The formal definitions of the classes and attributes are specified in
   Section 7.

6.2.  Energy Object (Class)

   An Energy Object (Class) represents a piece of equipment that is
   part of, or attached to, a communications network that is monitored
   or controlled or that aids in the management of another device for
   Energy Management.

Top      ToC       Page 14 
   The Energy Object (Class) is an abstract class that contains the base
   attributes to represent a piece of equipment for Energy Management.
   There are three types of Energy Object (Class): Device (Class),
   Component (Class), and Power Interface (Class).

6.2.1.  Device (Class)

   The Device (Class) is a subclass of Energy Object (Class) that
   represents a physical piece of equipment.

   A Device (Class) instance represents a device that is a consumer,
   producer, meter, distributor, or store of energy.

   A Device (Class) instance may represent a physical device that
   contains other components.

6.2.2.  Component (Class)

   The Component (Class) is a subclass of Energy Object (Class) that
   represents a part of a physical piece of equipment.

6.2.3.  Power Interface (Class)

   A Power Interface (Class) represents the interconnections (inlet,
   outlet) among devices or components where energy can be provided,
   received, or both.

   The Power Interface (Class) is a subclass of Energy Object (Class)
   that represents a physical inlet or outlet.

   There are some similarities between Power Interfaces and network
   interfaces.  A network interface can be set to different states, such
   as sending or receiving data on an attached line.  Similarly, a Power
   Interface can be receiving or providing energy.

   A Power Interface (Class) instance can represent (physically) an AC
   power socket, an AC power cord attached to a device, or an 8P8C
   (RJ45) PoE socket, etc.

Top      ToC       Page 15 
6.3.  Energy Object Attributes

   This section describes categories of attributes for an Energy Object
   (Class).

6.3.1.  Identification

   A Universally Unique Identifier (UUID) [RFC4122] is used to uniquely
   and persistently identify an Energy Object.

   Every Energy Object has an optional unique human-readable printable
   name.  Possible naming conventions are textual DNS name, Media Access
   Control (MAC) address of the device, interface ifName, or a text
   string uniquely identifying the Energy Object.  As an example, in
   the case of IP phones, the Energy Object name can be the device's
   DNS name.

   Additionally, an alternate key is provided to allow an Energy Object
   to be optionally linked with models in different systems.

6.3.2.  Context: 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.

   The Energy Object (Class) contains a category attribute that broadly
   describes how an instance is used in a deployment.  The category
   indicates whether the Energy Object is primarily functioning as a
   consumer, producer, meter, distributor, or store of energy.

   Given the category and context of an object, an EnMS can summarize or
   analyze measurements for the site.

6.3.3.  Context: Importance

   An Energy Object can provide an importance value in the range of 1 to
   100 to help rank a device's use or relative value to the site.  The
   importance range is from 1 (least important) to 100 (most important).
   The default importance value is 1.

   For example, a typical office environment has several types of
   phones, which can be rated according to their business impact.  A
   public desk phone has a lower importance (for example, 10) than a
   business-critical emergency phone (for example, 100).  As another
   example, a company can consider that a PC and a phone for a customer
   service engineer are more important than a PC and a phone for
   lobby use.

Top      ToC       Page 16 
   Although EnMS and administrators can establish their own ranking, the
   following example is a broad recommendation for commercial
   deployments [CISCO-EW]:

      90 to 100  Emergency response
      80 to 90   Executive or business-critical
      70 to 79   General or average
      60 to 69   Staff or support
      40 to 59   Public or guest
      1  to 39   Decorative or hospitality

6.3.4.  Context: Keywords

   The Energy Object (Class) contains an attribute with context
   keywords.

   An Energy Object can provide a set of keywords that is a list of tags
   that can be used for grouping, summary reporting (within or between
   Energy Management Domains), and searching.  Potential examples are
   IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace,
   router, phone, floor2, or SoftwareLab.

   The specifics of how this tag is represented are left to the MIB
   module or other object definition documents to be based on this
   framework.

   There is no default value for a keyword.  Multiple keywords can be
   assigned to an Energy Object.

6.3.5.  Context: Role

   The Energy Object (Class) contains a role attribute.  The "role
   description" string indicates the primary purpose the Energy Object
   serves in the deployment.  This could be a string representing the
   purpose the Energy Object fulfills in the deployment.

   The specifics of how this tag is represented are left to the MIB
   module or other object definition documents to be based on this
   framework.

   Administrators can define any naming scheme for the role.  As
   guidance, a two-word role that combines the service the Energy Object
   provides, along with type, can be used [IPENERGY].

   Example types of devices: Router, Switch, Light, Phone, WorkStation,
   Server, Display, Kiosk, HVAC.

Top      ToC       Page 17 
                   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".

   The specifics of how this tag is represented are left to the MIB
   module or other object definition documents to be based on this
   framework.

6.3.6.  Context: Domain

   The Energy Object (Class) contains a string attribute to indicate
   membership in an Energy Management Domain.  An Energy Management
   Domain can be any collection of Energy Objects in a deployment, but
   it is recommended to map 1:1 with a metered or sub-metered portion of
   the site.

   In building management, a meter refers to the meter provided by the
   utility used for billing and measuring power to an entire building or
   unit within a building.  A sub-meter refers to a customer- or user-
   installed meter that is not used by the utility to bill but is
   instead used to get measurements from portions of a building.

   The specifics of how this tag is represented are left to the MIB
   module or other object definition documents to be based on this
   framework.

   An Energy Object MUST be a member of a single Energy Management
   Domain; therefore, one attribute is provided.

Top      ToC       Page 18 
6.4.  Measurements

   The Energy Object (Class) contains attributes to describe power,
   energy, and demand measurements.

   An analogy for understanding power versus energy measurements can be
   made to speed and distance in automobiles.  Just as a speedometer
   indicates the rate of change of distance (speed), a power measurement
   indicates the rate of transfer of energy.  The odometer in an
   automobile measures the cumulative distance traveled; 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
   traveled, demand is the average power measured over multiple time
   intervals for a given energy value.

   Within this framework, energy will only be quantified in units of
   watt-hours.  Physical devices measuring energy in other units must
   convert values to watt-hours or be represented by Energy Objects that
   convert to watt-hours.

6.4.1.  Measurements: Power

   The Energy Object (Class) contains a Nameplate Power Attribute that
   describes the nominal power as specified by the manufacturer of the
   device.  The EnMS can use the Nameplate Power for provisioning,
   capacity planning, and (potentially) billing.

   The Energy Object (Class) has attributes that describe the present
   power information, along with how that measurement was obtained or
   derived (e.g., actual, estimated, or static).

   A power measurement is qualified with the units, magnitude, and
   direction of power flow and is qualified as to the means by which the
   measurement was made.

   Power measurement magnitude conforms to the [IEC61850] definition of
   unit multiplier for the SI (System International) units of measure.
   Measured values are represented in SI units obtained by BaseValue *
   (10 ^ Scale).  For example, if current power usage of an Energy
   Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 MW, depending on
   the value of the scaling factor.  17 W implies that BaseValue = 17
   and Scale = 0, whereas 17 mW implies that BaseValue = 17 and
   ScaleFactor = -3.

Top      ToC       Page 19 
   An Energy Object (Class) indicates how the power measurement was
   obtained with a caliber and accuracy attribute that indicates:

   o  Whether the measurements were made at the device itself or at a
      remote source.

   o  Description of the method that was used to measure the power and
      whether this method can distinguish actual or estimated values.

   o  Accuracy for actual measured values.

6.4.2.  Measurements: Power Attributes

   The Energy Object (Class) contains an optional attribute that
   describes Power Attribute information reflecting the electrical
   characteristics of the measurement.  These Power Attributes adhere to
   the [IEC61850-7-2] standard for describing AC measurements.

6.4.3.  Measurements: Energy

   The Energy Object (Class) contains optional attributes that represent
   the energy used, received, produced, and/or stored.  Typically, only
   devices or components that can measure actual power will have the
   ability to measure energy.

6.4.4.  Measurements: Demand

   The Energy Object (Class) contains optional attributes that represent
   demand information over time.  Typically, only devices or components
   that can report actual power are capable of measuring demand.

6.5.  Control

   The Energy Object (Class) contains a Power State Set (Class)
   attribute that represents the set of Power States a device or
   component supports.

   A Power State describes a condition or mode of a device or component.
   While Power States are typically used for control, they may be used
   for monitoring only.

   A device or component is expected to support at least one set of
   Power States consisting of at least two states: an on state and an
   off state.

   There are many existing standards describing device and component
   Power States.  The framework supports modeling a mixed set of Power
   States defined in different standards.  A basic example is given by

Top      ToC       Page 20 
   the three Power States defined in IEEE1621 [IEEE1621]: on, off, and
   sleep.  The Distributed Management Task Force (DMTF) standards
   organization [DMTF], Advanced Configuration and Power Interface
   (ACPI) specification [ACPI], and Printer Working Group (PWG) all
   define larger numbers of Power States.

   The semantics of a Power State are specified by:

   a) The functionality provided by an Energy Object in this state.

   b) A limitation of the power that an Energy Object uses in this
      state.

   c) A combination of a) and b).

   The semantics of a Power State should be clearly defined.  Limitation
   (curtailment) of the power used by an Energy Object in a state may be
   specified by:

   o  An absolute power value.

   o  A percentage value of power relative to the Energy Object's
      Nameplate Power.

   o  An indication of power relative to another Power State.  For
      example, specify that power in state A is less than in state B.

   o  For supporting Power State management, an Energy Object provides
      statistics on Power States, including the time an Energy Object
      spent in a certain Power State and the number of times an Energy
      Object entered a Power State.

   When requesting an Energy Object to enter a Power State, an
   indication of the Power State's name or number can be used.
   Optionally, an absolute or percentage of Nameplate Power can be
   provided to allow the Energy Object to transition to a nearest or
   equivalent Power State.

   When an Energy Object is set to a particular Power State, the
   represented device or component may be busy.  The Energy Object
   should set the desired Power State and then update the actual Power
   State when the device or component changes.  There are then two Power
   State (Class) control attributes: actual and requested.

   The following sections describe well-known Power States for devices
   and components that should be modeled in the information model.

Top      ToC       Page 21 
6.5.1.  Power State Sets

   There are several standards and implementations of Power State Sets.
   The Energy Object (Class) supports modeling one or multiple Power
   State Set implementations on the device or component concurrently.

   There are currently three Power State Sets specified by IANA:

      IEEE1621 (256) - [IEEE1621]
      DMTF (512)     - [DMTF]
      EMAN (768)     - [RFC7326]

   The respective specific states related to each Power State Set are
   specified in the following sections.  The guidelines for the
   modification of Power State Sets are specified in the IANA
   Considerations section.

6.5.2.  Power State Set: IEEE1621

   The IEEE1621 Power State Set [IEEE1621] consists of three rudimentary
   states: on, off, or sleep.

   In IEEE1621, devices are limited to the three basic Power States --
   on (2), sleep (1), and off (0).  Any additional Power States are
   variants of one of the basic states, rather than a fourth state
   [IEEE1621].

6.5.3.  Power State Set: DMTF

   The DMTF [DMTF] standards organization has defined a power profile
   standard based on the CIM (Common Information Model), which consists
   of 15 Power States.

   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].

Top      ToC       Page 22 
   The DMTF power profile extends ACPI Power States.  The following
   table provides a mapping between DMTF and ACPI Power State Sets:

       DMTF                                 ACPI
       ------------------------------------------------
       Reserved (0)
       Reserved (1)
       ON (2)                               G0/S0
       Sleep-Light (3)                      G1/S1 G1/S2
       Sleep-Deep (4)                       G1/S3
       Power Cycle (Off-Soft) (5)           G2/S5
       Off-Hard (6)                         G3
       Hibernate (Off-Soft) (7)             G1/S4
       Off-Soft (8)                         G2/S5
       Power Cycle (Off-Hard) (9)           G3
       Master Bus Reset (10)                G2/S5
       Diagnostic Interrupt (11)            G2/S5
       Off-Soft Graceful (12)               G2/S5
       Off-Hard Graceful (13)               G3
       MasterBus Reset Graceful (14)        G2/S5
       Power Cycle Off-Soft Graceful (15)   G2/S5
       Power Cycle Off-Hard Graceful (16)   G3

6.5.4.  Power State Set: IETF EMAN

   The EMAN Power States are an expansion of the basic Power States as
   defined in [IEEE1621] plus the addition of 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.

   Physical devices and components are expected to support the EMAN
   Power State Set or to be modeled via an Energy Object the supports
   these states.

   An Energy Object may implement fewer or more Power States than a
   particular EMAN Power State Set specifies.  In that case, the Energy
   Object implementation can determine its own mapping to the predefined
   EMAN Power States within the EMAN Power State Set.

   There are twelve EMAN Power States that expand on [IEEE1621].  The
   expanded list of Power States is derived from [CISCO-EW] and is
   divided into six operational states and six non-operational states.

Top      ToC       Page 23 
   The lowest non-operational state is 0, and the highest is 5.  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(0) to ready(5)),
   the Power State preceding it is expected to have a lower Power value
   and a longer delay in returning to an operational state:

      mechoff(0): 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(1): Similar to mechoff(0), but some components remain
         powered or receive trace power so that the Energy Object can be
         awakened from its off state.  In softoff(1), no context is
         saved, and the device typically requires a complete boot when
         awakened.

      hibernate(2): 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(3).  An example
         for state hibernate(2) is a save-to-disk state where DRAM
         context is not maintained.  Typically, energy consumption is
         zero or close to zero.

      sleep(3): 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(4).  An example for
         state sleep(3) is a save-to-RAM state, where DRAM context is
         maintained.  Typically, energy consumption is close to zero.

      standby(4): 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(5).  For example, processor context may not
         be maintained.  Typically, energy consumption is close to zero.

      ready(5): No Energy Object features are available, except for
         out-of-band management, such as wake-up mechanisms.  This mode
         is analogous to hot-standby.  The Energy Object can be quickly
         transitioned into an operational state.  For example,
         processors are not executing, but processor context is
         maintained.

Top      ToC       Page 24 
      lowMinus(6): Indicates that some Energy Object features may not be
         available and the Energy Object has taken measures or selected
         options to use less energy than low(7).

      low(7): Indicates that some Energy Object features may not be
         available and the Energy Object has taken measures or selected
         options to use less energy than mediumMinus(8).

      mediumMinus(8): Indicates that all Energy Object features are
         available but the Energy Object has taken measures or selected
         options to use less energy than medium(9).

      medium(9): Indicates that all Energy Object features are available
         but the Energy Object has taken measures or selected options to
         use less energy than highMinus(10).

      highMinus(10): Indicates that all Energy Object features are
         available and the Energy Object has taken measures or selected
         options to use less energy than high(11).

      high(11): Indicates that all Energy Object features are available
         and the Energy Object may use the maximum energy as indicated
         by the Nameplate Power.

6.5.5.  Power State Sets Comparison

   A comparison of Power States from different Power State Sets can be
   seen in the following tables:

      Non-operational states:

      IEEE1621  DMTF           ACPI         EMAN
      --------------------------------------------------
      off       Off-Hard       G3/S5        mechoff(0)
      off       Off-Soft       G2/S5        softoff(1)
      off       Hibernate      G1/S4        hibernate(2)
      sleep     Sleep-Deep     G1/S3        sleep(3)
      sleep     Sleep-Light    G1/S2        standby(4)
      sleep     Sleep-Light    G1/S1        ready(5)

Top      ToC       Page 25 
      Operational states:

      IEEE1621  DMTF         ACPI           EMAN
      ----------------------------------------------------
      on        on           G0/S0/P5       lowMinus(6)
      on        on           G0/S0/P4       low(7)
      on        on           G0/S0/P3       mediumMinus(8)
      on        on           G0/S0/P2       medium(9)
      on        on           G0/S0/P1       highMinus(10)
      on        on           G0/S0/P0       high(11)

6.6.  Relationships

   The Energy Object (Class) contains a set of Relationship (Class)
   attributes to model the relationships between devices and components.
   Two Energy Objects can establish an Energy Object Relationship to
   model the deployment topology with respect to Energy Management.

   Relationships are modeled with a Relationship (Class) that contains
   the UUID of the other participant in the relationship and a name that
   describes the type of relationship [CHEN].  The types of
   relationships are Power Source, Metering, and Aggregations.

   o  A Power Source Relationship is a relationship where one Energy
      Object provides power to one or more Energy Objects.  The Power
      Source Relationship gives a view of the physical wiring topology
      -- for example, a data center server receiving power from two
      specific Power Interfaces from two different PDUs.

      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 that the change of power
      direction was unintended or an error condition.

   o  A Metering Relationship is a relationship where one Energy Object
      measures power, energy, demand, or Power Attributes of one or more
      other Energy Objects.  The Metering Relationship gives the view of
      the Metering topology.  Physical meters can be placed anywhere in
      a power distribution tree.  For example, utility meters monitor
      and report accumulated power consumption of the entire building.
      Logically, the Metering topology overlaps with the wiring
      topology, as meters are connected to the wiring topology.  A
      typical example is meters that clamp onto the existing wiring.

Top      ToC       Page 26 
   o  An Aggregation Relationship is a relationship where one Energy
      Object aggregates Energy Management information of one or more
      other Energy Objects.  The Aggregation Relationship gives a model
      of devices that may aggregate (sum, average, etc.) values for
      other devices.  The Aggregation Relationship is slightly different
      compared to the other relationships, as this refers more to a
      management function.

   In some situations, it is not possible to discover the Energy Object
   Relationships, and an EnMS or administrator must set them.  Given
   that relationships can be assigned manually, the following sections
   describe guidelines for use.

6.6.1.  Relationship Conventions and Guidelines

   This Energy Management framework does not impose many "MUST" rules
   related to Energy Object Relationships.  There are always corner
   cases that can be excluded by making stricter specifications for
   relationships.  However, the framework proposes a series of
   guidelines, indicated with "SHOULD" and "MAY".

6.6.2.  Guidelines: Power Source

   Power Source Relationships are intended to identify the connections
   between Power Interfaces.  This is analogous to 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.  In 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.

   Strictly speaking, while 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.

Top      ToC       Page 27 
   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 Energy Object A has a Power Source Relationship
      "Poweredby" with Energy Object B, and if Energy Object B has a
      Power Source Relationship "Poweredby" with Energy Object C, then
      Energy Object A SHOULD NOT have a Power Source Relationship
      "Poweredby" with Energy Object C.

6.6.3.  Guidelines: Metering Relationship

   Metering Relationships are intended to show when one device acting as
   a meter is measuring the power or energy at a point in a power
   distribution system.  Since one point of a power distribution system
   may cover many devices within a wiring topology, this relationship
   type can be seen as a set.

   Some devices may include hardware that can measure power for
   components, outlets, or the entire device.  For example, some PDUs
   may have the ability to measure power for each outlet and are
   commonly referred to as metered-by-outlet.  Others may be able to
   control power at each power outlet but can only measure power at the
   power inlet -- commonly referred to as metered-by-device.

   While the Metering Relationship could be used to represent a device
   as metered-by-outlet or metered-by-device, the Metering Relationship
   SHOULD be used to model the relationship between a meter and all
   devices covered by the meter downstream in the power distribution
   system.

   In general:

   o  A Metering Relationship MAY be established with any other Energy
      Object, component, or Power Interface.

   o  Transitive Metering Relationships MAY be used.

   o  When there is a series of meters for one Energy Object, the Energy
      Object MAY establish a Metering Relationship with one or more of
      the meters.

Top      ToC       Page 28 
6.6.4.  Guidelines: Aggregation

   Aggregation Relationships are intended to identify when one device is
   used to accumulate values from other devices.  Typically, this is for
   energy or power values among devices and not for components or Power
   Interfaces on the same device.

   The intent of Aggregation Relationships is to indicate when one
   device is providing aggregate values for a set of other devices when
   it is not obvious from the power source or simple containment within
   a device.

   Establishing Aggregation Relationships within the same device would
   make modeling more complex, and the aggregated values can be implied
   from the use of power inlets, outlet, and Energy Object values on the
   same device.

   Since an EnMS is naturally a point of Aggregation, it is not
   necessary to model Aggregation for Energy Management Systems.

   The Aggregation Relationship is intended for power and energy.  It
   MAY be used for Aggregation of other values from the information
   model, but the rules and logical ability to aggregate each attribute
   are out of scope for this document.

   In general:

   o  A Device SHOULD NOT establish an Aggregation Relationship with
      components contained on the same device.

   o  A Device SHOULD NOT establish an Aggregation Relationship with the
      Power Interfaces contained on the same device.

   o  A Device SHOULD NOT establish an Aggregation Relationship with an
      EnMS.

   o  Aggregators SHOULD log or provide notification in the case of
      errors or missing values while performing Aggregation.

Top      ToC       Page 29 
6.6.5.  Energy Object Relationship Extensions

   This framework for Energy Management is based on three relationship
   types: Aggregation, Metering, and Power Source.

   This framework is defined with possible future extension of new
   Energy Object Relationships in mind.

   For example:

   o  Some Devices that may not be IP connected could be modeled with a
      proxy relationship to an Energy Object within the domain.  This
      type of proxy relationship is left for further development.

   o  A Power Distribution Unit (PDU) that allows devices and components
      like outlets to be "ganged" together as a logical entity for
      simplified management purposes could be modeled with an extension
      called a "gang relationship", whose semantics would specify the
      Energy Objects' grouping.



(page 29 continued on part 2)

Next RFC Part