[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         B. Nordman
Internet-Draft                     Lawrence Berkeley National Laboratory
Intended status: Informational                          October 21, 2013
Expires: April 24, 2014


                       Energy Reporting Framework
                   draft-nordman-eman-er-framework-02

Abstract

   Managing energy consumption of devices presents new challenges and
   issues.  The EMAN Requirements draft identifies essential
   capabilities needed to accomplish this.  This draft describes how an
   energy management system can use EMAN to gather and interpret data
   from individual devices, and how some of the Requirements are
   implemented in the model.  This document focuses on Energy Reporting,
   though acknowledges and fully includes the limited control functions
   specified in the Requirements draft.  Topics addressed in detail
   include the topology of power distribution, reporting mechanisms, and
   the various roles of devices, power interfaces, and components.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 24, 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



Nordman                  Expires April 24, 2014                 [Page 1]


Internet-Draft         Energy Reporting Framework           October 2013


   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
     1.1.  Guiding Principles  . . . . . . . . . . . . . . . . . . .   4
   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Energy Management System  . . . . . . . . . . . . . . . .   4
     2.2.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Power Interface . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Component . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Energy Object . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Battery . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Topologies  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Power Distribution  . . . . . . . . . . . . . . . . . . .   6
     3.2.  Reporting . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Fulfilling Basic EMAN Requirements  . . . . . . . . . . . . .  10
     4.1.  Identification  . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Local Data  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Power Interfaces  . . . . . . . . . . . . . . . . . . . .  12
     4.4.  Power, Static . . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Power . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.6.  Power State . . . . . . . . . . . . . . . . . . . . . . .  13
     4.7.  Energy  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.8.  Control . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.9.  Reporting . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.10. Data Summary  . . . . . . . . . . . . . . . . . . . . . .  14
   5.  How the ER Framework Fulfills Advanced EMAN Requirements  . .  15
     5.1.  Identification, Advanced  . . . . . . . . . . . . . . . .  15
     5.2.  Power, Advanced . . . . . . . . . . . . . . . . . . . . .  16
     5.3.  Power State, Advanced . . . . . . . . . . . . . . . . . .  16
     5.4.  Energy, Advanced  . . . . . . . . . . . . . . . . . . . .  17
     5.5.  Battery . . . . . . . . . . . . . . . . . . . . . . . . .  17
     5.6.  Time-series Data  . . . . . . . . . . . . . . . . . . . .  18
     5.7.  Reporting, Advanced . . . . . . . . . . . . . . . . . . .  18
     5.8.  Proxy Control . . . . . . . . . . . . . . . . . . . . . .  18
     5.9.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  EnMS Operation  . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Incomplete data . . . . . . . . . . . . . . . . . . . . .  19
     6.2.  Separately Tracking Energy Flows by Direction . . . . . .  20
     6.3.  Aggregate Devices . . . . . . . . . . . . . . . . . . . .  20
     6.4.  Proxy Control . . . . . . . . . . . . . . . . . . . . . .  21
     6.5.  Cloud Devices . . . . . . . . . . . . . . . . . . . . . .  21
     6.6.  External Power Meters . . . . . . . . . . . . . . . . . .  21



Nordman                  Expires April 24, 2014                 [Page 2]


Internet-Draft         Energy Reporting Framework           October 2013


   7.  EMAN Requirements Summary . . . . . . . . . . . . . . . . . .  21
   8.  Outstanding Issues  . . . . . . . . . . . . . . . . . . . . .  25
     8.1.  How to Address Requirement 7.5  . . . . . . . . . . . . .  25
     8.2.  EMAN Framework Content  . . . . . . . . . . . . . . . . .  26
     8.3.  Metering  . . . . . . . . . . . . . . . . . . . . . . . .  26
     8.4.  PI Capability . . . . . . . . . . . . . . . . . . . . . .  26
     8.5.  Data Representation for Section 5.1 . . . . . . . . . . .  26
     8.6.  Move Requirement Satisfaction Details to Appendix . . . .  26
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
   12. Informative References  . . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction

   Managing energy consumption of devices is different from typical
   network management functions because of the special nature of energy
   supply and use.  The EMAN Requirements draft [RFC6988] identifies
   necessary capabilities for an energy management standard.  This
   document describes how an energy management system (EnMS) uses EMAN
   and how to use and interpret EMAN data.

   In addition to the Requirements draft, this document derives content
   and inspiration from several now-expired drafts: Considerations for
   Power and Energy Management [I-D.norwin-energy-consider], Energy
   Perspective on Applicability [I-D.nordman-eman-energy-perspective],
   and most significantly, the Reference Model for Energy Management
   [I-D.quittek-eman-reference-model].  The EMAN Applicability statement
   [I-D.ietf-eman-applicability-statement] is also informative.

   The current EMAN Framework draft [I-D.ietf-eman-framework] addresses
   some of the requirements in ways suitable for this framework,
   particularly for Advanced capabilities (see Section 5).  Those
   requirements are noted below.

   The EMAN requirements are overwhelmingly about the reporting of
   energy data, not about control.  The only requirements that address
   control are setting power state (directly and by a proxy) and cutting
   power supply.  Thus, while these are fully included in this
   framework, it is titled "Energy Reporting" to match the empirical
   facts about the content of the EMAN requirements.









Nordman                  Expires April 24, 2014                 [Page 3]


Internet-Draft         Energy Reporting Framework           October 2013


1.1.  Guiding Principles

   This presentation, in form and content, takes simplicity as an
   overarching goal.  Complexity is burdensome for implementation of
   EMAN capabilities in individual devices, burdensome for
   implementation of management systems, and burdensome for readers and
   users of this standard to understand what they need to to accomplish
   their goals.

   Energy management involves people of many backgrounds and so
   documents about it should be accessible to a wide variety of
   audiences, from network professionals, to energy professionals, to
   building managers, or any person with an interest in energy use.

2.  Concepts

   At the core of this framework are just a few key concepts.  Energy is
   used by Devices.  Devices have Power Interfaces, which are like
   network interfaces, through which power is transferred into or out of
   a device.  Devices may have internal components with distinct power
   consumption or other characteristics.  Measurement for devices occurs
   at interfaces so that the total or net consumption of a device can be
   determined from these.  EMAN data are transferred from a device to an
   Energy Management System.

2.1.  Energy Management System

   An Energy Management System (EnMS) is an entity that receives EMAN
   data from many devices and interprets it.  An EnMS is often in the
   same building as the devices being monitored.  A building can have
   zero, one, or many EnMS.  A device can do both, acting as an EnMS and
   reporting EMAN data to another EnMS.  While the EMAN Requirements
   draft does not identify requirements for an EnMS, it is necessary to
   understand some of EnMS operation to fully describe how the EMAN
   framework operates.

   Basic EnMS operations include: discovering relevant devices,
   acquiring static data about them, acquiring dynamic data about them
   on a periodic basis, processing the resulting data, and implementing
   control and/or reporting functions.

2.2.  Device

   A Device is most commonly a complete product.  At any given time, a
   device may be drawing electricity in, and may be sending electricity
   out.  Combining these results in the net energy consumed by a device.





Nordman                  Expires April 24, 2014                 [Page 4]


Internet-Draft         Energy Reporting Framework           October 2013


   For devices with a single power interface, there is an identity
   between data about the interface and about the device as a whole, so
   the two can share an identity within EMAN.  The power interface
   reports some data that a device does not (see Section 2.5) so that in
   most cases both will be needed.

2.3.  Power Interface

   A Power Interface (PI) is an interface on a device through which
   power can flow into a device (an inlet) or out of it (an outlet).
   Some PIs change over time from being an inlet to being an outlet and
   vice versa, however most PIs never change.  Most devices have a
   single inlet.  Devices with multiple inlets often have them connected
   to separate power distribution trees.  Most devices have no outlets,
   but those that do often have many.  The only distinction between an
   inlet and outlet is the sign of the power value: positive for an
   inlet and negative for an outlet.  A PI can indicate whether it is
   capable of being only an inlet, only an outlet, or can switch between
   the two.  PIs are all contained (in ENTITY MIB sense) in the device;
   a PI is never contained in a component, and a PI cannot contain
   anything within it.  A PI consumes no power itself.  It is always on
   the border of a device, never internal.

   The flow of electricity within a building is determined by which
   power interfaces are connected to each other - the wiring topology.
   Thus, a key attribute of a PI is a list of the other interfaces it is
   connected to.  The power interface term is not new.  It is used
   similarly by the Power over Ethernet (PoE) standard [IEEE-802.3af]
   and [IEEE-802.3at] where a power interface denotes the interface
   between a device and the Ethernet transmission medium.

2.4.  Component

   A component is a distinct part of a device.  Components lack some of
   the features of devices, such as having power interfaces; instead,
   they simply have a net total consumption from the pool of power
   available within a device.  A component can contain other components,
   that draw from the pool of power within the containing component.

2.5.  Energy Object

   Devices, PIs, and Components are all Energy Objects (EOs).  The term
   "entity" in the Requirements draft generally corresponds to Energy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.  Basic data will be implemented by many or most
   devices.  Most devices are unlikely to implement advanced data.





Nordman                  Expires April 24, 2014                 [Page 5]


Internet-Draft         Energy Reporting Framework           October 2013


   The total energy and power for a device must match the total of all
   of its PIs.  PIs dump power into or take power out of the pool of
   power in a device.  A component draws power from the pool.
   Components do not have power interfaces.  The sum of all components
   in a device may be less than total device consumption as there may be
   hardware consuming power that is not part of any modeled component.

   Device PI Component  Kind
                      Basic
     X    X      X      Identification
     X    X      X      Local data
          X             Power Interfaces
          X             Power, static
     X    X      X      Power
     X    X      X      Power state
     X    X      X      Energy
     X                  Reporting
                      Advanced
     X    X             Identification, Advanced
          X             Power, Advanced
                 X      Battery``````
     X    X      X      Energy, Advanced
     X    X      X      Time-series data
     X                  Reporting, advanced
     X                  Proxy control

                       Figure 1: Kinds of EMAN data

2.6.  Battery

   A battery in a device is a special type of component.  EMAN has
   battery-specific data such as battery chemistry and charge state, see
   [I-D.ietf-eman-battery-mib].  A device can report on a battery with
   the battery-specific data, the component data, or both.

3.  Topologies

   EMAN covers several distinct topologies, particularly the
   distribution of electricity and the communication of information.
   The ability of EMAN to model power interfaces (PIs) of devices
   enables flexible and powerful capabilities.  This section describes
   some of them.  With this model an EnMS can query all devices in a
   building for their EMAN data and combine what it receives from each
   into a comprehensive picture of electricity flows and device state.

3.1.  Power Distribution





Nordman                  Expires April 24, 2014                 [Page 6]


Internet-Draft         Energy Reporting Framework           October 2013


   An EnMS combines all the data it acquires to create as complete a
   picture of power flows as possible; it is not necessary for each
   device to have complete information about its connectivity.  For
   example, terminal devices that only consume power may only know the
   identity of the PI from which they draw power.  The EnMS then sees
   many devices connected to a single outlet PI and can infer that they
   are all wired to each other, regardless of whether the supplying PI
   knows the identity of the devices it powers.  Similarly, a supplying
   device may know the identify of the PI it supplies power to and so
   can create the map, even if the supplied device does not know where
   it draws power from.

   For each PI on a device, the group of PIs that are known to be
   directly wired to that PI is reported.  In Figure 2, Device-A can
   report that its PI-1 is wired to PI-2, and Device-B can report that
   PI-2 is wired to PI-1.  The EnMS knows that PI-1 is part of Device-A
   and that PI-2 is part of Device-B.  Only one of the PIs needs to know
   of the wiring connection for the EnMS to fully understand it.  The
   drawing shows how a PI is part of a device but is on its periphery.
   The line shown is of power flow only.

           +---------------+                  +---------------+
           |          +--------+          +--------+          |
           | Device-A |  PI-1  |>-------->|  PI-2  | Device-B |
           |          +--------+          +--------+          |
           +---------------+                  +---------------+


                 Figure 2: Simple wiring topology example

   Figure 3 shows how wiring is commonly done in AC supply systems, with
   Device A being a circuit breaker.  In this case, four devices are
   wired together.  It is possible that all four know of the identity of
   all others, but commonly less is known.  PI-2, PI-3, and PI-4 may
   each know they are wired to PI-1, and PI-1 may know nothing, but the
   linkage of all four can be inferred by the EnMS.  As another example,
   PI-3 and PI-4 may know of the connection to PI-1, with PI-1 knowing
   it is connected to PI-2; this also enables construction of the full
   set.  Finally, PI-1 could know it is connected to PI-2 and PI-3, but
   have no knowledge of PI-4; however, it could observe that PI-2 and
   PI-3 do not account for all the energy leaving PI-1 and so infer that
   at least one other device is also wired to PI-1.

                                       +--------+----------+
                                  ---->|  PI-2  | Device-B |
        +---------------+         |    +--------+----------+
        |          +--------+     |    +--------+----------+
        | Device-A |  PI-1  |>-------->|  PI-3  | Device-C |



Nordman                  Expires April 24, 2014                 [Page 7]


Internet-Draft         Energy Reporting Framework           October 2013


        |          +--------+     |    +--------+----------+
        +---------------+         |    +--------+----------+
                                  ---->|  PI-4  | Device-D |
                                       +--------+----------+

               Figure 3: Typical AC wiring topology example

   Figure 4 shows how wiring is commonly done in DC supply systems, with
   Device-A being a PoE switch, USB hub, or similar device.  For
   technologies which inherently have communication, device identity can
   be readily determined.

        +----------+--------+          +--------+----------+
        |          |  PI-1  |>-------->|  PI-4  | Device-B |
        |          +--------+          +--------+----------+
        |          +--------+          +--------+----------+
        | Device-A |  PI-2  |>-------->|  PI-5  | Device-C |
        |          +--------+          +--------+----------+
        |          +--------+          +--------+----------+
        |          |  PI-3  |>-------->|  PI-6  | Device-D |
        +----------+--------+          +--------+----------+

               Figure 4: Typical DC wiring topology example

   From the capability of each PI (or the direction of power flow on
   first report) it is clear which PI is the source.  For devices that
   provide power (typically a power distribution unit, circuit breaker,
   or PoE switch), one can determine which PIs are inlets and which are
   outlets.  Thus, mapping a traditional tree-structured power
   distribution system is a simple process.

   Some installations have more complex power distribution, as with more
   than one device providing power to a circuit, or PIs that can and do
   change the direction of power flow.  These can be readily modeled
   though require more sophisticated interpretation by the EnMS.

   An EnMS may choose to put information it has inferred (principally
   about PI connectivity) back into the individual devices, but is not
   required to.  Doing so is valuable when there is more than one EnMS
   present.

   With a power distribution map, a management system knows which
   devices supply power to which other devices, so that the effect of
   switching off a PI (usually at an outlet, but possibly at an inlet)
   can be determined.  The same applies to metering at PIs, which can
   also occur at an outlet or inlet.





Nordman                  Expires April 24, 2014                 [Page 8]


Internet-Draft         Energy Reporting Framework           October 2013


   Power source control is accomplished by physically preventing power
   from flowing, or re-enabling it.  In contrast, power state control is
   accomplished by communication protocols and not by power distribution
   control so that power state control mechanisms and capabilities have
   no required relation to power distribution systems.  Power control
   for a PI is modeled with power state, with on corresponding with
   power able to flow, and off that power cannot flow.

3.2.  Reporting

   Only devices report data; PIs and components do not.  An EMAN device
   may report on itself, or on a device other than itself.  Self-
   reporting is the basic EMAN case and simply involves a device putting
   its internal data into the EMAN representation.  The EnMS knows the
   identity of the device doing the reporting and the identity of the
   device being reported on, and these are the same.  The left side of
   Figure 5 shows this.

         +----------+          +----------+
         |   EnMS   |          |   EnMS   |
         +----------+          +----------+
               ^                     ^
               |                     |
         +----------+          +----------+      +----------+
         | Device-A |          | Device-A |<-----| Device-B |
         +----------+          +----------+      +----------+

                  Figure 5: Two basic reporting scenarios

   The other EMAN case is non-self-reporting, or other-reporting.  The
   EnMS knows the identity of the device reporting and the identify of
   the device being reported on and can see that they are different.
   There are three types of other-reporting relationships, where
   Device-B is:

   a) an IP device (like Device-A) that has the ability to report
      EMAN data to an EnMS,
   b) an IP device that does not have the ability to report EMAN data
      to an EnMS, or
   c) a non-IP device.


   The right side of Figure 5 shows this where the Device-B to Device-A
   communication technology depends on which case applies.

   Case a) is particularly useful when some amount of collection and/or
   summation is done.  Summation can be across energy objects, and/or
   across time for an individual energy object.  The reporting device



Nordman                  Expires April 24, 2014                 [Page 9]


Internet-Draft         Energy Reporting Framework           October 2013


   may retain the detailed data in case it becomes of interest to an
   EnMS later.

   Case c) includes circumstances in which some or all of the EMAN data
   are communicated over non-IP mechanisms, as well as when the EMAN
   device monitors power flowing to the monitored device and may have
   access to other information, such as the identity of the device it
   provides power to.

   Case b) is similar to c) except that the device reported on is an IP
   device that is unable to report data in EMAN format.

   Practically, the EnMS is indifferent to the distinction between these
   cases or even whether the data is self-reported or other-reported; it
   only matters what device is being reported on.

   The lines shown in Figure 5 are data transfer, not power flow.  For
   the right side of Figure 5, Device-B could be powered by Device-A, or
   have no power relation at all with Device-A (only a reporting
   connection).  How Device-A obtains the data about Device-B has no
   effect on how the data are reported.

4.  Fulfilling Basic EMAN Requirements

   This section further elaborates the ER Framework and shows how its
   features fulfill many of the requirements in the EMAN Requirements
   draft.  Each subsection includes the relevant requirements,
   abbreviated (for the full list see Section 7).  Requirement numbers
   are noted in the text where the requirement is met.  This section
   only covers basic requirements that many devices will implement.
   More advanced capabilities and requirements are covered in Section 5.

   When implementing EMAN capability on a device, only the basic
   identification data are required.  All other data in Section 4 and
   all data in Section 5 are optional to report.  In a few cases,
   features included that do not derive from specific requirements are
   included, and these are always identified as such.

4.1.  Identification

   4.1. uniquely identifying entities.

               Figure 6: EMAN Requirement for Identification

   There are only two truly mandatory items for an energy object to
   implement in EMAN.  The first is a unique identity (UUID) (4.1).  The
   second is an energy object type which can be device, component, power
   interface, or aggregate device (see Section 6.3).  The EMAN Framework



Nordman                  Expires April 24, 2014                [Page 10]


Internet-Draft         Energy Reporting Framework           October 2013


   specifies the UUID and includes an integer as an index for the energy
   objects the device can report on.

   In addition to the requirements, a widely useful feature for a device
   is to report a URL for standard manufacturer data on the brand/model
   of the device, represented as a string.  Related to this, and also
   not derivative of a requirement, is a string for each of the brand
   (manufacturer) and model of the device.

4.2.  Local Data

   5.1.1. configure, retrieve and report a textual name or a description
   5.1.2. retrieving and reporting context information ..., for example,
       tags associated with an entity that indicate the entity's role.
   5.1.3. retrieving and reporting the significance of entities within
       its context, for example, how important the entity is.
   5.1.4. retrieving and reporting Power priorities of entities.  Power
       priorities indicate an order in which Power States of entities
       are changed.
   5.1.5. grouping entities.  This can be achieved in multiple ways, for
       example, by providing means to tag entities, to assign them to
       domains, or to assign device types to them.

                Figure 7: EMAN Requirements for Local Data

   Local data are those generated at the point of product use and so are
   created for each building individually.  The first item is a text
   string for the name (5.1.1).  The second is a list of keywords, each
   of which will be a pair of strings, one representing a name or type
   and the other one representing a value (5.1.2, .3, .4, .5).  Since
   none of these data types - role, priority, grouping, domain, or
   device type - has been standardized, their representation and
   encoding are determined locally.  This flexible mechanism can be used
   for various purposes, as the following examples illustrate using
   different notation styles.

      role="switch"

      powerDownPriority: 6

      "lineofbusiness:Helpdesk"

      <location>South Wing</location>

      domain::office






Nordman                  Expires April 24, 2014                [Page 11]


Internet-Draft         Energy Reporting Framework           October 2013


4.3.  Power Interfaces

   5.2.1. monitoring the list of Power Interfaces of a device.
   5.2.2. monitoring the operational mode of a Power Interface which is
       either "Power Inlet" or "Power Outlet".
   5.2.3. identifying the Power Outlet that provides the Power received
       at a Power Inlet.
   5.2.4. identifying the list of Power Inlets that receive the Power
       provided at a Power Outlet.
   5.2.5. monitoring the availability of Power at each Power Interface.
       ... indicates whether ... supply is switched on or off.
   5.2.6. monitoring for each Power Interface if it is in actual use.
       ... inlets ... device actually receives Power. ... outlets ...
       Power is actually provided.

             Figure 8: EMAN Requirements for Power Interfaces

   PIs provide wiring topology and are the source of core energy and
   power data.  A device provides PI information as a list of UUIDs of
   PIs it contains (5.2.1).  Each PI provides a list of UUIDs of PIs
   that it knows it is wired to (5.2.3, .4).  The power mode of a PI is
   indicated by the sign of the power value; positive for power flowing
   in, and negative for power flowing out (5.2.2).  The availability of
   power at a PI is shown by its power state (see Section 4.6) (5.2.5).
   Actual flow of power is indicated by the power value being non-zero
   (5.2.6).

   Since wiring topology usually changes only infrequently, it would be
   burdensome for an EnMS to constantly refresh these data.  To avoid
   this, a device can provide a timestamp of the last time there was a
   wiring topology change.  Only when this changes does an EnMS need to
   rescan the topology.  This feature does not arise from a listed
   requirement.

   Another capability not specified by any requirement is what
   directions of power flow a PI is capable of.  This is indicated by an
   enumeration value of either inlet-only, outlet-only, or both.

4.4.  Power, Static

   5.2.7. reporting the type of current (AC or DC) for each Power
       Interface as well as for a device.
   5.2.8. reporting the nominal voltage range for each Power Interface.
   5.2.9. reporting the nominal AC frequency for each Power Interface.
   5.2.10. reporting the number of AC phases for each Power Interface.

               Figure 9: EMAN Requirements for Power, Static




Nordman                  Expires April 24, 2014                [Page 12]


Internet-Draft         Energy Reporting Framework           October 2013


   These characteristics of power apply only to PIs and are static.
   They do not change so can be set at the factory.  They can be
   represented by an enumeration (5.2.7), two strings (5.2.8, .9), and
   an integers (5.2.10).

   The requirements say that a device should also report its type of
   current, but as some devices support both AC and DC simultaneously on
   different PIs.  There is not always a single type of current for a
   whole device (as there is for a single PI).  This is a shortcoming of
   the requirements document, and the situation is covered by single PI
   devices (see Section 2.2).

4.5.  Power

   5.3.1. reporting the real power for each Power Interface as well as
       for an entity. ... includes ... the direction.
   5.3.2. reporting the corresponding time or time interval for which a
       Power value is reported.

                  Figure 10: EMAN Requirements for Power

   Power is represented as an integer and a power-of-ten multiplier and
   the direction of power is by its sign (5.3.1; see Section 4.3).  Any
   kind of energy object can report power level data.  The time of a
   power reading is indicated by a corresponding timestamp.

4.6.  Power State

   5.4.1. reporting the actual Power State of an entity.

                Figure 11: EMAN Requirement for Power State

   The EMAN Framework [I-D.ietf-eman-framework] describes how EMAN
   supports devices to have any number of power state series, and at any
   time, a state can be reported for each.  This representation is
   suitable.  Each energy object has a list of power state series it
   supports and a corresponding state for each entry in the list
   (5.4.1).

   For PIs, the state indicates whether or not power can flow: 'on'
   means power can flow, 'off' that power unable to flow, and 'sleep'
   that only trickle power is available.  Technologies which support
   trickle power include PoE, USB, and UPAMD.  Since the IEEE 1621 power
   state series has these three states and only these, it is a natural
   one to use for PIs.

4.7.  Energy




Nordman                  Expires April 24, 2014                [Page 13]


Internet-Draft         Energy Reporting Framework           October 2013


   5.5.1. reporting measured values of Energy and the direction of the
       Energy flow received or provided by an entity. ... report the
       Energy passing through each Power Interface.
   5.5.2. reporting the time interval for which an Energy value is
       reported.

                  Figure 12: EMAN Requirements for Energy

   Energy is reported as an accumulated meter reading and a timestamp
   (5.5.1).  An EnMS subtracts one reading/timestamp from a later one to
   get an interval of time and the energy flow during that time (5.5.2).
   The sign of this energy value indicates whether net energy was
   brought into a device or component (a positive value) or sent out of
   it (a negative one) (5.5.1).

4.8.  Control

   6.1. setting Power States of entities.
   6.2. switching Power supply off or turning Power supply on at Power
       Interfaces.

                 Figure 13: EMAN Requirements for Control

   A device or component may accept a command to set the power state
   value to attempt a changing of the power state (6.1).  For a PI, this
   turns supply on and off (6.2; see Section 4.6).  No new data elements
   are introduced by these requirements.

4.9.  Reporting

   7.1. an entity to report information on another entity.
   7.2. reporting the identity of other entities on which information is
       reported. ... For entities that report on one or more other
       entities.
   7.4. reporting the complete list of all those entities on which
       Energy-related information can be reported. ... For entities that
       report on one or more other entities.

                Figure 14: EMAN Requirements for Reporting

   Each device must be able to report the UUIDs of each device it can
   report for, including itself (7.2).  An EnMS can request data for any
   listed device (7.1, .4).  It can also request data for any PI or
   component of any listed device.

4.10.  Data Summary





Nordman                  Expires April 24, 2014                [Page 14]


Internet-Draft         Energy Reporting Framework           October 2013


   The basic requirements above result in the following data elements
   for a fully compliant implementatios.  Note that a minimal
   implementation would only require the first two data elements.  In
   the table below, the first column lists which type of energy objects
   are relevant: device, PI, or component.  The second column lists the
   requirement level, mandatory, recommended, or optional.

   EOs R Kind           Data
   --- - -------------- -----------------------------------------------
   DPC m Identification Index (within the device)
   DPC m                UUID (for unique identification globally)
   D   o                URL for brand/model specifications
   D C o                Brand, model (strings)
   DPC m Local Data     Text name
   DPC o                Keyword list (strings)
   D   r Power Interf.  List of PIs in device (UUIDs)
    P  r                List of PIs known to be connected to PI (UUIDs)
    P  r                Timestamp of last change to wiring topology
    P  m Power, Static  Type of current (AC or DC)
    P  m                Nominal voltage range, AC frequency, AC phases
   DPC r Power          Timestamp of power reading
   DPC r                Numeric value and exponent for power in W
   DPC m Power State    List of supported power state series
   DPC m                Current power state (for each supported series)
   DPC m Energy         Timestamp of energy reading
   DPC m                Numeric value and exponent for energy in Wh
   D   r Reporting      List of devices that can be reported on (UUIDs)

                   Figure 15: Summary of Basic EMAN Data

   A key point about the above table is that it is modest in size and
   minimally burdensome for both implementers and those who use the EMAN
   data in real buildings.

5.  How the ER Framework Fulfills Advanced EMAN Requirements

   This section describes how the ER Framework fulfills the rest of the
   requirements in the EMAN Requirements draft.  Each subsection begins
   with the requirements listed, abbreviated, as from Section 7.  Most
   devices will not implement any of these, and many EnMS may not as
   well.  That said, for those devices and buildings where these are
   relevant, these provide important capability.  Many readers can skip
   this section entirely.  For most of these, content from the EMAN
   Framework draft is suitable.

5.1.  Identification, Advanced





Nordman                  Expires April 24, 2014                [Page 15]


Internet-Draft         Energy Reporting Framework           October 2013


   4.2. indicating whether identifiers ... are persistent across a
       re-start.
   4.3. indicate any change of entity identifiers.
   4.4. re-using entity identifiers from existing standards including
       ... the Entity MIB module ... the LLDP MIB module ... the
       LLDP-MED MIB module ... and the ... the Power Ethernet MIB. ...
       Generic means for re-using other entity identifiers must be
       provided.

         Figure 16: EMAN Requirements for Identification, Advanced

   These require a flag for identifier persistance (4.2), a timestamp of
   the last entity identifier change (4.3), and a list of identifiers
   each consisting of a pair of strings, one string representing a type
   and the other one representing a value (4.4).

5.2.  Power, Advanced

   5.3.3. means to indicate the method how these values have been
       obtained.
   5.3.4. reporting the accuracy of reported Power and Energy values.
   5.3.5. reporting the actual voltage and actual current for each Power
       Interface as well as for a device. In case of AC Power supply ...
       per phase.
   5.3.6. creating notifications if Power values of an entity rise above
       or fall below given thresholds.
   5.3.7. reporting the complex power for each Power Interface and for
       each phase at a Power Interface.
   5.3.8. reporting the actual AC frequency for each Power Interface.
   5.3.9. reporting the Total Harmonic Distortion (THD) of voltage and
       current for each Power Interface.
   5.3.10. reporting the impedance of Power supply for each Power
       Interface.  In case of AC Power supply ... per phase.

             Figure 17: EMAN Requirements for Power, Advanced

   The treatment of these requirements in the EMAN Framework draft is
   suitable.  Note that 5.3.3, .4, and .6 apply to any energy object,
   but the rest only apply to PIs.

5.3.  Power State, Advanced

   5.4.2. retrieving the list of all potential Power States of an
       entity.
   5.4.3. supporting multiple Power State sets simultaneously at an
       entity.
   5.4.4. retrieving the list of all Power State sets supported by an
       entity.



Nordman                  Expires April 24, 2014                [Page 16]


Internet-Draft         Energy Reporting Framework           October 2013


   5.4.5. retrieving the list of all potential Power States of an entity
       for each supported Power State set.
   5.4.6. retrieving the typical Power for each supported Power State.
   5.4.7. monitoring statistics per Power State including the total time
       spent in a Power State, the number of times each state was
       entered and the last time each state was entered.
   5.4.8. generating a notification when the actual Power State of an
       entity changes.

               Figure 18: EMAN Requirements for Power State

   The treatment of these requirements in the EMAN Framework draft is
   suitable.

5.4.  Energy, Advanced

   5.5.3. reporting the received and provided Energy for each individual
       Power State.

             Figure 19: EMAN Requirement for Energy, Advanced

   The treatment of these requirements in the EMAN Framework draft is
   suitable, except for the notion of distinct values for consumed,
   provided, and net consumption (see Section 6.2).

5.5.  Battery

   5.6.1. reporting the current charge ... in units of milliampere hours
   5.6.2. reporting the charging state (charging, discharging, etc.)
   5.6.3. reporting the number of completed charging cycles
   5.6.4. reporting the actual capacity
   5.6.5. reporting the actual temperature
   5.6.6. reporting static properties ... including the nominal
       capacity, the number of cells, the nominal voltage, and the ...
       technology.
   5.6.7. generating a notification when the charge ... decreases
       below a given threshold.
   5.6.8. generating a notification when the number of charging cycles
       ... exceeds a given threshold.
   5.6.9. meeting requirements 5.6.1 to 5.6.8 for each individual
       battery contained in a single entity.

                Figure 20: EMAN Requirements for Batteries

   The treatment of these requirements in the Battery MIB draft
   [I-D.ietf-eman-battery-mib] is suitable.





Nordman                  Expires April 24, 2014                [Page 17]


Internet-Draft         Energy Reporting Framework           October 2013


5.6.  Time-series Data

   5.7.1. reporting time series of Energy values.  If ... comparison ...
       between multiple entities ... is required, then time
       synchronization ... must be provided.
   5.7.2. supporting alternative interval types.  Requirement 5.5.2
       applies to every reported time value.
   5.7.3. should ... reporting the number of values of a time series
       that can be stored.

             Figure 21: EMAN Requirements for Time-series data

   Time-series data is of the same form as single-value data for power
   and energy, notably a timestamp plus the relevant value.  Thus,
   reporting is of a list of these (5.7.1).  Every interval type can be
   derived from pairs of single-value data, by subtracting the time and
   energy values (5.7.2).  For sequential windows, adjacent values are
   compared; for overlapping windows, non-adjacent values are compared.
   The energy object must be able to report the number of available time
   series data slots (5.7.3).  A device must be able to accept a setting
   of time from an EnMS for time syncronization (5.7.1), though for
   security purposes, this might affect only EMAN reporting and not
   change the global system clock of the device.  To implement all this,
   a device must be able to accept commands to initiate time-series data
   collection, including the requested time interval.

5.7.  Reporting, Advanced

   7.3. reporting the list of all entities from which contributions are
       included in an accumulated value.
   7.5. indicating which Energy-related information can be reported for
       which of those entities. ... For entities that report on one or
       more other entities.

           Figure 22: EMAN Requirements for Reporting, Advanced

   This framework includes the concept of an aggregate device (7.3; see
   Section 6.3).  No new dta elements are required for this.  The method
   to implement 7.5 is TBD.

5.8.  Proxy Control

   8.1.1. an Energy Management System to send Power State control
       commands to an entity that concern the Power States of [other]
       entities.
   8.1.2. reporting the identities of the entities for which the
       reporting entity has means to control their Power States.
   8.1.3. an entity to report the list of all entities for which it can



Nordman                  Expires April 24, 2014                [Page 18]


Internet-Draft         Energy Reporting Framework           October 2013


       control the Power State.
   8.1.4. an entity that receives commands controlling its Power State
       from other entities to report the list of all those entities.

              Figure 23: EMAN Requirements for Proxy Control

   Only a device can control the power state of another entity, but any
   energy object can be controlled this way.  An energy object that can
   be controlled by a proxy must be able to provide a list of
   controllers (8.1.4).  A device must be able to provide a list of
   energy objects that it is capable to control the power state of
   (8.1.2).  8.1.3 appears to be a duplicate of 8.1.2.  To use this
   feature, a device receives a power state set command for a UUID that
   it is not itself.

5.9.  Security

   9.1. provide privacy, integrity, and authentication mechanisms for
       all actions addressed in Sections 5 - 8. ... must meet the
       security requirements elaborated in Section 1.4 of [RFC3411].
   9.2. allow for isolation of entities that that are not sufficiently
       secure to operate on the public Internet.

                 Figure 24: EMAN Requirements for Security

   The treatment of these requirements in the EMAN Framework draft is
   suitable.

6.  EnMS Operation

   The full utility and application of EMAN can only be understood with
   some understanding of how an EnMS operates.  This section covers
   several of these.  This section does not introduce new data items.

6.1.  Incomplete data

   Section 3 noted that data on PI connectivity need not be complete to
   be useful, and need not be complete on every device to be
   comprehensive.  The ability to report and use incomplete data is
   generic in EMAN.  This is particularly valuable for including the
   many legacy devices with few or no EMAN capabilities.

   Note that for the case in the right side of Figure 5, the data
   available from Device-A and Device-B need not be the same.  There may
   be a different combination of PIs and components available on them,
   and for each energy object, one of the devices may know and report
   more data than the other.




Nordman                  Expires April 24, 2014                [Page 19]


Internet-Draft         Energy Reporting Framework           October 2013


   Devices may lack power or energy detail for several PIs but still be
   able to report data about the device total.

6.2.  Separately Tracking Energy Flows by Direction

   In some cases it may be desired to separately track the flows of
   energy into or out of a device, PI, or component for those that
   support bi-directional power flow.  When the direction of power flow
   changes within a reporting period, the opposite flows cancel each
   other out, giving a correct indication of the net flow, but lacking
   the tracking of the total in each direction.  Doing this is readily
   accomplished by having two PIs in place of one, or two components in
   place of one.  Each is used only for a single direction of power
   flow.  In this way, the separate directions are correctly tracked,
   and by summation, the net flow can be calculated.  Implementations
   which desire this (batteries being a prime example) can do this, and
   those that do not simply use a single PI or component.  This ability
   adds no data fields or complexity to the ER framework.

6.3.  Aggregate Devices

   An aggregate device is a not a real device, but an information
   construct to represent the summation of data across a set of energy
   objects.  It has a UUID as any device does, has no power interfaces
   (since it does not interact with power in the real world), and has
   one or more components.  Each component of an aggregate device can be
   any type of energy object.  Commonly, all objects in an aggregate
   object will be of the same type (all devices, all PIs, or all
   components) but this is not required.  A device may or may not report
   any data for the UUIDs in the aggregate object components; all that
   is required is to have the component UUIDs.  The aggregate device
   concept introduces no new data items to the EMAN structure.

   In producing an aggregate result, EMAN does not define how a
   reporting device should treat incomplete data, any mismatch in the
   alignment of timestamps among the objects to be aggregated, or
   whether power states should be aggregated or how such an aggregation
   would be interpreted.  A device is free to do whatever it likes in
   this regard.  The only requirement is that power and energy reported
   reflect a summation of all the constituent energy objects.  Since
   this is an aggregate device and not an aggregate PI, advanced power
   data are not reported.

   Common examples of aggregate objects might be all servers in a data
   center rack, all fans in a data center, all devices in a single room,
   all lights in a building, or all devices under the financial
   responsibility of a single tenant.




Nordman                  Expires April 24, 2014                [Page 20]


Internet-Draft         Energy Reporting Framework           October 2013


6.4.  Proxy Control

   Control of the power state of one device by a second device is not
   common, but does occur.  A prime example is the ability to wake (or
   turn on) a sleeping PC with the "Wake On LAN" technology.  Another
   example would be when the device being controlled is not an IP
   device.

6.5.  Cloud Devices

   Another use of EMAN to accomplish real-world needs is through the use
   of "cloud" devices.  Like an aggregate device, these are not a single
   real-world object (or not necessarily one), but do correspond to real
   wiring topology.  An example is a tree-structured wiring topology
   with circuit breaker panels.  An individual circuit breaker, or
   collection of them, can be represented as a cloud device.  The meter
   device shows a PI on it wired to an inlet PI on the cloud device, and
   individual end-use devices (or downstream circuit breakers) are wired
   to an outlet PI on the cloud device.  The cloud device has a UUID,
   but is not a device on the network, and no data are reported from the
   cloud device.  Since no data are reported, there is no cloud device
   of energy object.

   What this does is correctly represent the data known about the wiring
   topology, while hiding some potentially-existing (but unknown)
   complexity inside the cloud.  It adds no complexity to the EMAN model
   and only adds the creation and use of a single UUID in PIs as
   appropriate.  It is flexible in allowing for a wire variety of
   topologies of devices, clouds, and devices operating as meters.

6.6.  External Power Meters

   A device which is only a power meter is modeled exactly as any other
   device.  It is modeled as a device that has an inlet power interface
   receiving power and one or more outlet power interfaces providing
   power.  The fact that a device may consume none of the energy that
   passes through it is not relevant to EMAN, and in this case, the
   quantitative values on both PIs will be identical except of opposite
   sign.

   A DC-powered blade server in a chassis has its own identity on the
   network and if it reports for itself, it is a separate device, not a
   component of the chassis.  Similarly, a PoE-powered device can be
   modeled as either a separate device, or a component of the powering
   device.

7.  EMAN Requirements Summary




Nordman                  Expires April 24, 2014                [Page 21]


Internet-Draft         Energy Reporting Framework           October 2013


   This section summarizes the content of the EMAN Requirements
   document, lists all specific requirements.  The text is excerpted for
   brevity, in one case text in [ brackets ] is added, and "..."
   indicates text deleted within a requirement.  The words "should" and
   "must" occur in the introductory text; these are often redundant to
   the actual requirements and so are not included in this list.
   Requirements generally begin with "The standard must provide means
   for ..."; this text is omitted.  The headings below are not part of
   the requirements draft.

   Requirements: Basic

   Identification
   4.1. uniquely identifying entities.

   Local Data
   5.1.1. configure, retrieve and report a textual name or a description
   5.1.2. retrieving and reporting context information ..., for example,
       tags associated with an entity that indicate the entity's role.
   5.1.3. retrieving and reporting the significance of entities within
       its context, for example, how important the entity is.
   5.1.4. retrieving and reporting Power priorities of entities.  Power
       priorities indicate an order in which Power States of entities
       are changed.
   5.1.5. grouping entities.  This can be achieved in multiple ways, for
       example, by providing means to tag entities, to assign them to
       domains, or to assign device types to them.

   Power Interfaces
   5.2.1. monitoring the list of Power Interfaces of a device.
   5.2.2. monitoring the operational mode of a Power Interface which is
       either "Power Inlet" or "Power Outlet".
   5.2.3. identifying the Power Outlet that provides the Power received
       at a Power Inlet.
   5.2.4. identifying the list of Power Inlets that receive the Power
       provided at a Power Outlet.
   5.2.5. monitoring the availability of Power at each Power Interface.
       ... indicates whether ... supply is switched on or off.
   5.2.6. monitoring for each Power Interface if it is in actual use.
       ... inlets ... device actually receives Power. ... outlets ...
       Power is actually provided.

   Power, Static
   5.2.7. reporting the type of current (AC or DC) for each Power
       Interface as well as for a device.
   5.2.8. reporting the nominal voltage range for each Power Interface.
   5.2.9. reporting the nominal AC frequency for each Power Interface.
   5.2.10. reporting the number of AC phases for each Power Interface.



Nordman                  Expires April 24, 2014                [Page 22]


Internet-Draft         Energy Reporting Framework           October 2013


   Power
   5.3.1. reporting the real power for each Power Interface as well as
       for an entity. ... includes ... the direction.
   5.3.2. reporting the corresponding time or time interval for which a
       Power value is reported.

   Power State
   5.4.1. reporting the actual Power State of an entity.

   Energy
   5.5.1. reporting measured values of Energy and the direction of the
       Energy flow received or provided by an entity. ... report the
       Energy passing through each Power Interface.
   5.5.2. reporting the time interval for which an Energy value is
       reported.

   Control
   6.1. setting Power States of entities.
   6.2. switching Power supply off or turning Power supply on at Power
       Interfaces.

   Reporting
   7.1. an entity to report information on another entity.
   7.2. reporting the identity of other entities on which information is
       reported. ... For entities that report on one or more other
       entities.
   7.4. reporting the complete list of all those entities on which
       Energy-related information can be reported. ... For entities that
       report on one or more other entities.

   Requirements: Advanced

   Identification, Advanced
   4.2. indicating whether identifiers ... are persistent across a
       re-start.
   4.3. indicate any change of entity identifiers.
   4.4. re-using entity identifiers from existing standards including
       ... the Entity MIB module ... the LLDP MIB module ... the
       LLDP-MED MIB module ... and the ... the Power Ethernet MIB. ...
       Generic means for re-using other entity identifiers must be
       provided.

   Power, Advanced
   5.3.3. means to indicate the method how these values have been
       obtained.
   5.3.4. reporting the accuracy of reported Power and Energy values.
   5.3.5. reporting the actual voltage and actual current for each Power
       Interface as well as for a device. In case of AC Power supply ...



Nordman                  Expires April 24, 2014                [Page 23]


Internet-Draft         Energy Reporting Framework           October 2013


       per phase.
   5.3.6. creating notifications if Power values of an entity rise above
       or fall below given thresholds.
   5.3.7. reporting the complex power for each Power Interface and for
       each phase at a Power Interface.
   5.3.8. reporting the actual AC frequency for each Power Interface.
   5.3.9. reporting the Total Harmonic Distortion (THD) of voltage and
       current for each Power Interface.
   5.3.10. reporting the impedance of Power supply for each Power
       Interface.  In case of AC Power supply ... per phase.

   Power State
   5.4.2. retrieving the list of all potential Power States of an
       entity.
   5.4.3. supporting multiple Power State sets simultaneously at an
       entity.
   5.4.4. retrieving the list of all Power State sets supported by an
       entity.
   5.4.5. retrieving the list of all potential Power States of an entity
       for each supported Power State set.
   5.4.6. retrieving the typical Power for each supported Power State.
   5.4.7. monitoring statistics per Power State including the total time
       spent in a Power State, the number of times each state was
       entered and the last time each state was entered.
   5.4.8. generating a notification when the actual Power State of an
       entity changes.

   Energy, Advanced
   5.5.3. reporting the received and provided Energy for each individual
       Power State.

   Battery
   5.6.1. reporting the current charge ... in units of milliampere hours
   5.6.2. reporting the charging state (charging, discharging, etc.)
   5.6.3. reporting the number of completed charging cycles
   5.6.4. reporting the actual capacity
   5.6.5. reporting the actual temperature
   5.6.6. reporting static properties ... including the nominal
       capacity, the number of cells, the nominal voltage, and the ...
       technology.
   5.6.7. generating a notification when the charge ... decreases
       below a given threshold.
   5.6.8. generating a notification when the number of charging cycles
       ... exceeds a given threshold.
   5.6.9. meeting requirements 5.6.1 to 5.6.8 for each individual
       battery contained in a single entity.

   Time-series data



Nordman                  Expires April 24, 2014                [Page 24]


Internet-Draft         Energy Reporting Framework           October 2013


   5.7.1. reporting time series of Energy values.  If ... comparison ...
       between multiple entities ... is required, then time
       synchronization ... must be provided.
   5.7.2. supporting alternative interval types.  Requirement 5.5.2
       applies to every reported time value.
   5.7.3. should ... reporting the number of values of a time series
       that can be stored.

   Reporting
   7.3. reporting the list of all entities from which contributions are
       included in an accumulated value.
   7.5. indicating which Energy-related information can be reported for
       which of those entities. ... For entities that report on one or
       more other entities.

   Proxy Control
   8.1.1. an Energy Management System to send Power State control
       commands to an entity that concern the Power States of [other]
       entities.
   8.1.2. reporting the identities of the entities for which the
       reporting entity has means to control their Power States.
   8.1.3. an entity to report the list of all entities for which it can
       control the Power State.
   8.1.4. an entity that receives commands controlling its Power State
       from other entities to report the list of all those entities.

   Security
   9.1. provide privacy, integrity, and authentication mechanisms for
       all actions addressed in Sections 5 - 8. ... must meet the
       security requirements elaborated in Section 1.4 of [RFC3411].
   9.2. allow for isolation of entities that that are not sufficiently
       secure to operate on the public Internet.



8.  Outstanding Issues

   The following are questions that need further consideration by the
   EMAN working group.

8.1.  How to Address Requirement 7.5

   "7.5. indicating which Energy-related information can be reported for
   which of those entities. ... For entities that report on one or more
   other entities."  An EnMS could simply query all data for an energy
   object and observe what are available.  A more efficient mechanism
   could be defined.  Regardless, any value should have "unknown" as an
   option.



Nordman                  Expires April 24, 2014                [Page 25]


Internet-Draft         Energy Reporting Framework           October 2013


8.2.  EMAN Framework Content

   Incorporate details from the EMAN Framework draft and the Battery MIB
   draft where they are to be included substantially as-is.

8.3.  Metering

   Add text to section 3 explaining how measurement done at different
   power interfaces leads to conclusions about device metering.

8.4.  PI Capability

   Per Section 4.3, should there be a data element to indicate if a PI
   can be only an inlet, only an outlet, or either?

8.5.  Data Representation for Section 5.1

   Consider the syntax of the items to be represented and whether the
   proposal for a single text string is sufficient.  Possibly provide
   examples.

8.6.  Move Requirement Satisfaction Details to Appendix

   Consider whether the details in sections 4 and 5 on how specific
   requirements are satisfied should be moved to an appendix.  Sections
   4 and 5 would retain, and possibly expand, their explanation of the
   framework content itself.  This would make the document more readable
   (and shorter, not counting the appendix) while retaining
   documentation of the relationships of framework content to
   requirements in the appendix.

9.  Security Considerations

   This memo currently does not impose any security considerations.

10.  IANA Considerations

   This memo has no actions for IANA.

11.  Acknowledgements

   This memo was inspired by discussions with many people, including
   (but not limited to) Juergen Quittek, Rolf Winter, Benoit Claise,
   John Parello, and Mouli Chandramouli.

12.  Informative References





Nordman                  Expires April 24, 2014                [Page 26]


Internet-Draft         Energy Reporting Framework           October 2013


   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC6988]  Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and
              B. Claise, "Requirements for Energy Management", RFC 6988,
              September 2013.

   [I-D.ietf-eman-framework]
              Parello, J., Claise, B., Schoening, B., and J. Quittek,
              "Energy Management Framework", draft-ietf-eman-
              framework-11 (work in progress), October 2013.

   [I-D.ietf-eman-applicability-statement]
              Schoening, B., Chandramouli, M., and B. Nordman, "Energy
              Management (EMAN) Applicability Statement", draft-ietf-
              eman-applicability-statement-04 (work in progress),
              October 2013.

   [I-D.ietf-eman-battery-mib]
              Quittek, J., Winter, R., and T. Dietz, "Definition of
              Managed Objects for Battery Monitoring", draft-ietf-eman-
              battery-mib-09 (work in progress), July 2013.

   [I-D.nordman-eman-energy-perspective]
              Nordman, B., "Energy perspective on applicability", draft-
              nordman-eman-energy-perspective-01 (work in progress),
              March 2011.

   [I-D.norwin-energy-consider]
              Nordman, B. and R. Winter, "Considerations for Power and
              Energy Management", draft-norwin-energy-consider-02 (work
              in progress), March 2011.

   [I-D.quittek-eman-reference-model]
              Quittek, J., Nordman, B., and R. Winter, "Reference Model
              for Energy Management", draft-quittek-eman-reference-
              model-03 (work in progress), October 2011.

   [IEEE-802.3af]










Nordman                  Expires April 24, 2014                [Page 27]


Internet-Draft         Energy Reporting Framework           October 2013


              IEEE 802.3 Working Group, ., "IEEE Std 802.3af-2003 - 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)", July 2003.

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

Author's Address

   Bruce Nordman
   Lawrence Berkeley National Laboratory
   1 Cyclotron Road
   Berkeley  94720
   US

   Phone: +1 510 486 7089
   Email: bnordman@lbl.gov





















Nordman                  Expires April 24, 2014                [Page 28]


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