[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 7326

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

     Internet-Draft    <Power Management Archictecture>    March 2011
     Copyright Notice
        Copyright (c) 2011 IETF Trust and the persons identified as the
        document authors.  All rights reserved.
        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the date of
        publication of this document.  Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.  Code Components extracted from this
        document must include Simplified BSD License text as described
        in Section 4.e of the Trust Legal Provisions and are provided
        without warranty as described in the Simplified BSD License.
        This document defines an energy management framework.
     <Claise, et. Al>      Expires September 14, 2011          [Page 2]

     Internet-Draft    <Power Management Archictecture>    March 2011
     Table of Contents
        1. Introduction.............................................. 4
           1.1. Energy Management Document Overview.................. 5
        2. Use Cases & Requirements.................................. 6
        3. Terminology............................................... 6
           3.1. Functional Entities.................................. 9
        4. Energy Management Reference Model........................ 10
        5. Architecture High Level Concepts and Scope............... 12
           5.1. Power Monitor Information........................... 13
           5.2. Power Monitor Topologies: Metering versus Control versus
           Power Distribution....................................... 14
           5.3. Power Monitor Meter Domain.......................... 15
           5.4. Power Monitor Parent and Child...................... 15
           5.5. Power Monitor Context............................... 16
           5.6. Power Monitor States................................ 18
           5.7. Power Monitor Usage Measurement..................... 22
           5.8. Optional Power Usage Quality........................ 23
           5.9. Optional Energy Measurement......................... 23
           5.10. Optional Battery Information....................... 23
        6. Structure of the Information Model: UML Representation... 24
        7. Power Monitor Children Discovery......................... 29
        8. Configuration............................................ 29
        9. Fault Management......................................... 31
        10. Relationship with Other Standards Development
        Organizations............................................... 31
           10.1. Information Modeling............................... 31
           10.2. Power States....................................... 32
        11. Implementation Scenarios................................ 32
           Scenario 1: Switch with PoE endpoints.................... 32
           Scenario 2: Switch with PoE endpoints with further connected
           device(s)................................................ 33
           Scenario 3: A switch with Wireless Access Points......... 33
           Scenario 4: Network connected facilities gateway......... 33
           Scenario 5: Data center network.......................... 33
           Scenario 6: Building gateway device...................... 34
           Scenario 7: Power consumption of UPS..................... 34
           Scenario 8: Power consumption of battery-based devices... 34
        12. Security Considerations................................. 34
        12.1. Security Considerations for SNMP...................... 34
        13. IANA Considerations..................................... 35
        14. Acknowledgments......................................... 35
        15. References.............................................. 35
           Normative References..................................... 35
           Informative References................................... 36
     <Claise, et. Al>      Expires September 14, 2011          [Page 3]

     Internet-Draft    <Power Management Archictecture>    March 2011
       . Agree on the terminology (Power Monitor agreed on the mailing
       . How to model the battery in PC? What are the requirements?
       . ENTITY-MIB:
            o 1. could we solve the problems specified in draft-ietf-
               eman-requirements with the ENTITY-MIB?
               2.  if yes, do we chose to do so?
       . How many operational power states (series) do we need? If any?
       . At some paces in this I-D there is support for devices
          producing power. However, this is not done consistently. Is a
          generator of electricity a power monitor? If we want to
          support generation, then we must check the entire document for
          consistency. The same applies if we just focus on consumption
          (usage). I tend to exclude generation, but include storage,
          such as batteries. Must wait for a definite requirements
       . Should implementation scenarios be incorporated in the
          framework draft or in the MIB module?
       . Do we agree that the units should W, A, Wh, Ah, V, and not
          Joule and Coulombs?  Proposal: the MIB variable uses W, A, Wh,
          Ah, V, and explain, if appropriate, how to convert into
       . Identity table: If the UUID is per box, then we have an issue
          as we need it per port.
     1. Introduction
        Network management is typically divided into the five main
        network management areas defined in the ISO Telecommunications
        Management Network model: Fault, Configuration, Accounting,
        Performance, and Security Management.  Absent from this model is
        any consideration of energy management, which is now becoming a
        critical area of concern worldwide.
        This document defines a framework for energy management for
        devices within or connected to communication networks.  This
        framework includes monitoring for power state and energy
        consumption of networked elements, covering the requirements
     <Claise, et. Al>      Expires September 14, 2011          [Page 4]

     Internet-Draft    <Power Management Archictecture>    March 2011
        specified in [EMAN-REQ].  It also goes a step further in
        defining some elements of configuration.
        There is a need to apply Energy Management to all devices in
        communication networks.  Target devices for this specification
        include (but are not limited to): hosts, servers, routers,
        switches, Power over Ethernet (PoE) endpoints, protocol gateways
        for building management systems, intelligent meters, home energy
        gateway, sensor proxies, etc.
        Where applicable, device monitoring extends to the individual
        components of the device and to any attached dependent devices.
        For example: A device can contain components that are
        independent from a power-state point of view, such as line
        cards, processor cards, hard drives. A device can also have
        dependent attached devices, such as a switch with PoE powered
        devices or a power distribution unit with attached powered
     1.1. Energy Management Document Overview
        The EMAN standards provides network administrators with energy
        management.  This document specifies the framework, per the
        Energy Management requirements specified in [EMAN-REQ], which
        allow networks and devices to become energy aware.
        Energy-aware Networks and Devices MIB document [EMAN-AWARE-MIB]
        allows the monitoring of energy-aware networks and devices, by
        addressing devices identification, context information, and
        relationship between reporting devices, remote devices, and
        monitoring probes.
        The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains the
        managed objects for monitoring of power states and energy
        consumption/production.  The monitoring of power states
        includes: retrieving power states, properties of power states,
        current power state, power state transitions, and power state
        statistics. This MIB provides the detailed properties of the
        actual energy rate (power) and of accumulated energy, along with
        the power quality.
        The applicability statement document [EMAN-AS] provides the list
        of use cases, cross-reference between existing standards and the
        EMAN standard, and shows how the EMAN framework relates to other
     <Claise, et. Al>      Expires September 14, 2011          [Page 5]

     Internet-Draft    <Power Management Archictecture>    March 2011
        EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
        group documents.  Hence, these references will be changed in the
     2. Use Cases & Requirements
        Requirements for power and energy monitoring for networking
        devices are specified in [EMAN-REQ].  The requirements in [EMAN-
        REQ] cover devices typically found in communications networks,
        such as switches, routers, and various connected endpoints.  For
        a power monitoring framework to be useful, it should also apply
        to facility meters, power distribution units, gateway proxies
        for commercial building control, home automation devices, and
        devices that interface with the utility and/or smart grid.
        Accordingly, this framework, the scope is broader than that
        specified in [EMAN-REQ].  Several scenarios that cover these
        broader use cases are presented later in Section 11. -
        Implementation Scenarios.
     3. Terminology
        This section contains definitions of important terms used
        throughout this specification.
        IPFIX-specific terminology used in this document is defined in
        section 2 of [RFC5101]. For example: Flow Record, Collector ,
        etc...  As in [RFC5101], these IPFIX-specific terms have the
        first letter of a word capitalized.
       Energy Management
       Energy Management deals with assessing and influencing the
       consumption of energy in a network of powered devices.  A
       typical objective of energy management is reducing the energy
       consumption in the network.  This objective may conflict with
       other objectives of a general network management system, for
       example, with service level objectives.
       Energy Monitoring
       Energy Monitoring is a part of Energy Management.  It deals with
       monitoring only and does not include influencing the consumption
       of energy.
     <Claise, et. Al>      Expires September 14, 2011          [Page 6]

     Internet-Draft    <Power Management Archictecture>    March 2011
       Power, Energy, and Energy Consumption
       Power is a rate of energy conversion.  In scenarios relevant to
       energy management electrical energy is delivered to a device
       that "consumes" it by converting the energy.
       Power and consumed energy are essential quantities for network
       management.  Power can be an instantaneous value of the current
       energy conversion rate or an average value of instantaneous
       power over a time interval.  Consumed energy, is the total
       energy converted by a powered device during a time interval.
       The term 'Energy Consumption' is commonly used for both, for
       referring to the amount of consumed energy and also for
       referring to the process of consuming energy.  In the first case
       it addresses consumed energy, in the second one it addresses
       power, typically an average power.  In this document we use this
       ambiguous term for addressing both, power and consumed energy.
        Power Monitor
        A power monitor has access to energy-related information
        concerning powered devices and is able to report this
        information to energy management systems.
        The power monitor may also provide information on identities and
        properties of powered devices to the management system.
        A power monitor may store energy-related information and process
        it, for example, for aggregating information or for extracting
        statistics that are provided to the management system.
        Power Monitor Parent
        A Power Monitor Parent is a Power Monitor that is the root of
        one or more subtending Power Monitors, called Power Monitor
        Children.  The Power Monitor Parent is able to aggregate data
        about or report on the power state and energy consumption of its
        Power Monitor Children.
        For example: A Power-over-Ethernet (PoE) device (such as an IP
        phone or an access point) is attached to a switch port. The
     <Claise, et. Al>      Expires September 14, 2011          [Page 7]

     Internet-Draft    <Power Management Archictecture>    March 2011
        switch is the source of power for the attached device, so the
        Power Monitor Parent is the switch, and the Power Monitor Child
        is the device attached to the switch.
        The Power Monitor Parent may aggregate data or proxy actions on
        behalf of the Power Monitor Child.
        The communication between the parent and child for monitoring or
        collection of power data is left to the device manufacturer. For
        example: A parent switch may use LLDP to communicate with a
        connected child, and a parent lighting controller may use BACNET
        to communicate with child lighting devices.
        Power Monitor Child
        A Power Monitor Child is a Power Monitor associated with a Power
        Monitor Parent, and which reports its power usage and power
        state to its Power Monitor Parent. The Power Monitor Child may
        or may not draw power from its Power Monitor Parent. .
        Power Monitor Meter Domain
        A Power Monitor Meter Domain is a name or name space that
        logically groups Power Monitors into a zone of manageable power
        usage.  Typically, this zone will have as members all Power
        Monitors that are powered from the same electrical panel or
        panels for which there is a meter or sub meter.  For example:
        All Power Monitors receiving power from the same distribution
        panel of a building, or all Power Monitors in a building for
        which there is one main meter, would comprise a Power Monitor
        Meter Doman.  From the standpoint of power-use monitoring, it is
        useful to report the total power usage as the sum of power
        consumed by all the Power Monitors within a Power Monitor Meter
        Domain and then correlate that value with the metered usage.
        Power State
        A Power State is a uniform way to classify power settings on a
        Power Monitor (e.g., shut, hibernate, sleep, high).  Power
        States can be viewed as an interface for the underlying device-
        implemented power settings.
        Manufacturer Power State
     <Claise, et. Al>      Expires September 14, 2011          [Page 8]

     Internet-Draft    <Power Management Archictecture>    March 2011
        A Manufacturer Power State is a device-specific way to classify
        power settings implemented on a Power Monitor.  For cases where
        the implemented power settings cannot be directly mapped to
        Power States, we can use the Manufacturer Power States to
        enumerate and show the relationship between the implemented
        power settings and the Power State interface.
        Nameplate Power
        The Nameplate Power is the maximal electrical capacity that a
        component can support under electrical load testing. It is
        specified by the vendor as the capacity required to power the
        device.  Often this label is a conservative number and is the
        worst-case power draw.  While the actual utilization of an
        entity can be lower, the Nameplate Power is important for
        provisioning, capacity planning and billing.
        EDITOR'S NOTE: we should be referring to another SDO/reference.
     3.1. Functional Entities
       Power Proxy
       A Power Proxy is a Power Monitor Parent that reports the power
       information on behalf of its Power Monitor Children. For
       example, because the Power Monitor Children are non IP devices,
       because they can't report the power information themselves, or
       simply for scalability reasons.
       Power Aggregator
       A Power Aggregator is a Power Monitor Parent that aggregates the
       power information of its Power Monitor Children.
       Power Distributor
       A Power Aggregator supplies power to Power Monitors. Only in
       rare examples such as PoE is the Power Distributor a Power
       Monitor Parent.
     <Claise, et. Al>      Expires September 14, 2011          [Page 9]

     Internet-Draft    <Power Management Archictecture>    March 2011
     4. Energy Management Reference Model
        As displayed in the figure 1, the most basic energy reference
        model is composed of a Energy Management Systems (EMS) that
        manages, via SNMP, the power and energy information from Power
        Monitors.  The Power Monitor returns information about the power
        consumption, the power states, the power quality, the energy
        usage, potentially the business context, and other information
        as described further.
                            |      EMS      |                -
                            +-----+---+-----+                |
                                  |   |                      |
                                  |   |                      |  S
                        +---------+   +----------+           |  N
                        |                        |           |  M
                        |                        |           |  P
               +-----------------+      +--------+--------+  |
               | Power Monitor 1 |  ... | Power Monitor N |  |
               +-----------------+      +-----------------+  -
                    Figure 1: Basic Energy Management Model
        As displayed in the figure 2, the advanced energy reference
        model manages the Power Monitor Parents.  The Power Monitor
        Parents returns information for themselves and for any attached
        Power Monitor Children.  The information returned is the same as
        in the basic energy management, plus some extra information
        about the relationship between Power Monitor Child and Power
        Monitor Parent.
                          |      EMS      |               -
                          +-----+--+------+               |
                                |  |                      |
                                |  |                      |  S
                   +------------+  +--------+             |  N
                   |                        |             |  M
                   |                        |             |  P
           +------------------+     +------+-----------+  |
           | Power Monitor    |     | Power Monitor    |  |
           | Parent 1         | ... | Parent N         |  -
           | Power Proxy      | ... | Power Proxy      |
           |(Power Aggregator)| ... |(Power Aggregator)|
           +------------------+     +------------------+
     <Claise, et. Al>      Expires September 14, 2011         [Page 10]

     Internet-Draft    <Power Management Archictecture>    March 2011
                   |||                    |
         (protocol |||                    |
         out of    |||      +-------------+---------+
         the scope)|||------| Power Monitor Child 1 |
                   ||       +-----------------------+
                   ||       +-------------+---------+
                   ||-------| Power Monitor Child 2 |
                   |        +-----------------------+
                   |--------           ...
                   |        +-------------+---------+
                   |--------| Power Monitor Child M |
                   Figure 2: Advanced Energy Management Model
        This advanced energy management model is required when the
        scalability of managing all Power Monitor Children becomes an
        issue. In such as case, the Power Monitor Parent also acts as a
        Power Aggregator, i.e. an aggregation point for other subtended
        Power Monitor Children.
        The advanced energy management model is also required when the
        Power Monitor Child doesn't speak the IP protocol. Indeed, the
        Power Monitor Parent may speak to a Power Monitor Child using a
        manufacturer selected protocol.  In such a case, the Power
        Monitor Parent acts as a Power Proxy for protocol translation
        between the Power Monitor Parent and Child.  Therefore, the
        protocol between the Power Monitor Parent and Power Monitor
        Children is out of scope of this document.
        The Power Monitor Parents may send SNMP notifications regarding
        their own state or the state of their Power Monitor Children.
        The Power Monitor Children do not send SNMP notifications on
        their own.
        As discussed in [EMAN-REQ], the Power Monitor Parents may export
        IPFIX Flow Records [RFC5101] to a Collector.  However, the
        framework doesn't mandate it.
        While both the basic and advanced energy management models
        (figure 1 and 2) contain a EMS, this architecture doesn't impose
     <Claise, et. Al>      Expires September 14, 2011         [Page 11]

     Internet-Draft    <Power Management Archictecture>    March 2011
        any requirements regarding the control, which could be
        centralized from the EMS, or distributing in the network.
     5. Architecture High Level Concepts and Scope
        The scope of this architecture is to enable networking and
        network-attached devices to be managed with respect to their
        energy consumption or production.  The goal is to make IP
        devices energy-aware.  If those devices don't support IP, then a
        Power Proxy acting as a protocol translation can be used.
        The architecture makes the Energy Management System aware of
        power usage.  . This does not include:
        - Manufacturing costs in currency or environmental units
        - Embedded carbon or environmental equivalences of the device
        - Cost in currency or environmental impact to dismantle or
        recycle the device
        - Relationship to an electrical or smart grid
        - Supply chain analysis
        - Conversion of the usage or production of energy to units
        expressed from the source of that energy (such as the greenhouse
        gas emissions associated with 1000kW from a diesel source).
        The remainder of this section describes the basic concepts of
        the architecture.  Each concept is examined in detail in
        subsequent sections.
        Examples are provided in a later section to show how these
        concepts can be implemented.
        The basic concepts are:
        The Power Monitor will have basic naming and informational
        descriptors to identify it in the network.
        A Power Monitor can be part of a Power Monitor Meter Domain.  A
        Power Monitor Meter Domain is a manageable set of devices that
        has a meter or sub-meter attached and typically corresponds to a
        power distribution point or panel.  In building management, the
        meter refers to the meter provided by the utility used for
        billing or rationing power to the entire building or unit in a
        building, while a sub-meter refers to a customer or user
        installed meter that is not used by the utility to bill but
        instead used to get readings from sub portions of a building.
     <Claise, et. Al>      Expires September 14, 2011         [Page 12]

     Internet-Draft    <Power Management Archictecture>    March 2011
        Examples consists of building with a meter form utility with
        submeters installed for data center, HVAC and common areas.
        A Power Monitor can be a parent (Power Monitor Parent) or child
        (Power Monitor Child) of another Power Monitor.  This allows for
        Power Monitor Parent to aggregate power reporting and control of
        power information.
        Each Power Monitor can have information to allow it to be
        described in the context of the business or ultimate use.  This
        is in addition to its networked information.  This allows for
        tagging, grouping, and differentiation between Power Monitors
        for the EMS.
        For control and universal monitoring, each Power Monitor
        implements or declares a set of known Power States.  The Power
        States are mapped to Manufacturer Power States that indicate the
        specific power settings for the device implementing the Power
        When the Power State is set, a Power Monitor may be busy at the
        request time.  The Power Monitor will set the desired state and
        then update the actual Power State when the priority task is
        finished.  This mechanism implies two different Power State
        variables: actual versus desired.
        EDITOR'S NOTE: The transition state will have to be specified.
        Each Power Monitor will have usage information that describes
        the power information along with how that usage was obtained or
        Optionally, a Power Monitor can further describe the power
        information with power quality information reflecting the
        electrical characteristics of the measurement.
        Optionally, a Power Monitor can provide power usage over time to
        describe energy consumption
        If a Power Monitor has one or more batteries, it can provide
        optional battery information as well.
     5.1. Power Monitor Information
        Every Power Monitor should have a unique printable name, and
        must have a unique Power Monitor index.
     <Claise, et. Al>      Expires September 14, 2011         [Page 13]

     Internet-Draft    <Power Management Archictecture>    March 2011
        Possible naming conventions are: textual DNS name, MAC-address
        of the device, interface ifName, or a text string uniquely
        identifying the Power Monitor.  As an example, in the case of IP
        phones, the Power Monitor name can be the device DNS name.
     5.2. Power Monitor Topologies: Metering versus Control versus Power
        In a simple Power Proxy scenario, the Power Monitor Parent,
        which reports on the power state and power consumption of its
        Power Monitor Children, would also be controlling the Power
        States for its Power Monitor Children and would provide the
        power to the Power Monitor Children.  A typical example is the
        PoE case, where a switch meters the power consumption, controls
        the power state, and also provides the power for the connected
        device.  In this PoE case, the metering, control and power
        distribution topologies are overlapping.  This case offers an
        extra advantage if the Power Monitor Child sends its own power
        consumption metering value to the Power Monitor Parent, as the
        Power Monitor Parent can compare two values and deduce the
        discrepancy such as line loss.
        However, this ideal case is not the only situation.
        In most cases, the Power Monitor Children communicates his power
        consumption to the Power Monitor Parent, while it receives its
        energy from a different source.  A very simple example is a PC
        connected to a switch port, which receives his power from the
        outlet, or from its battery.  Another example is the
        introduction of smart PDU in a datacenter, where the power
        distribution is a key aspect.  In such cases, metering and power
        distribution are two distinct topologies.  Note that the power
        distribution topology is also known as the power distribution
        tree.  If the Power Monitor Child communicates its power
        consumption, it should have one and only Power Monitor Parent,
        so that there is no double counting in the Power Monitor
        Metering Domain.
        In other cases, sub-meters may exist in a building or data
        center.  These meters monitor the power consumption of one or
        more end devices.  Since these meters are layered on an existing
        infrastructure, they subdivide the domain and might overlap.
        They are also distinct from the network control topology.  An
        example would be a smart PDU metering the power consumption of a
        server in a data center, while the server applications could be
        moved to a different data center.
     <Claise, et. Al>      Expires September 14, 2011         [Page 14]

     Internet-Draft    <Power Management Archictecture>    March 2011
        To summarize, all combinations of distinct or overlapping
        topologies exist: metering, configuration, and power source.
        The Power Monitor Metering Domain reflects the metering
     5.3. Power Monitor Meter Domain
        When a Power Monitor Parent acts as a Power Aggregator or a
        Power Proxy, the Power Monitor Parent and its Power Monitor
        Child/Children must be a member of Power Monitor Meter Domain
        The Power Monitor Meter Domain should map 1-1 with a metered or
        sub-metered portion of the site.  The Power Monitor Meter Domain
        must be configured on the Power Monitor Parent.  The Power
        Monitor Children may inherit their domain values from the Power
        Monitor Parent or the Power Monitor Meter Domain may be
        configured directly in a Power Monitor Child.  The Power Monitor
        must belong to a single Power Monitor Meter Domain.
     5.4. Power Monitor Parent and Child
        When a Power Monitor Parent acts as a Power Aggregator or a
        Power Proxy, a Power Monitor Child reports its power usage to
        its Power Monitor Parent.  A Power Monitor Child has one and
        only one Power Monitor Parent in the Power Monitor Metering
        Domain.  If a Power Monitor had two parents in the same Power
        Monitor Metering Domain, there would be a risk of double-
        reporting the power usage. Therefore, a Power Monitor cannot be
        both a Power Monitor Parent and a Power Monitor Child at the
        same time.
        A Power Monitor Child can be fully dependent on the Power
        Monitor Parent for its power or independent from the parent
        (such as a PC connected to a switch).  In the dependently
        powered case, the Power Monitor Parent provides power for the
        Power Monitor Child (as in the case of Power Over Ethernet
        devices).  In the independently powered case, the Power Monitor
        Child draws power from another source (typically a wall outlet).
        Since the Power Monitor Parent is not the source of power
        supply, the power usage cannot be measured at the Power Monitor
        Parent.  However, an independent Power Monitor Child reports
        Power Monitor information to the Power Monitor Parent.  The
        Power Monitor Child may listen to the power control settings
        from a Power Monitor Parent and could react to the control
        messages.  However, note that the communication between the
     <Claise, et. Al>      Expires September 14, 2011         [Page 15]

     Internet-Draft    <Power Management Archictecture>    March 2011
        Power Monitor Parent and Power Monitor Child is out of scope for
        this document.
        A mechanism, outside of the scope of this document, should be in
        place to verify the connectivity between the Power Monitor
        Parent and its Power Monitor Children.  If a Power Monitor Child
        is unavailable, the Power Monitor Parent must follow some rules
        to determine how long it should wait before removing the Power
        Monitor Child entry, along with all associated statistics, from
        its database.  In some situations, such as a connected building
        in which the Power Monitor Children are somewhat static, this
        removal-delay period may be long, and persistence across a Power
        Monitor Parent reload may make sense.  However, in a networking
        environment, where endpoints can come and go, there is not much
        sense in configuring a long removal timer.  In all cases, the
        removal timer or persistence must be clearly specified.
        Further examples of Power Monitor Parent and Child
        implementations are provided in the Implementation Scenarios
        section 11.
     5.5. Power Monitor Context
        Monitored power data will ultimately be collected by and
        reported from an EMS.  In order to aid in reporting and in
        differentiation between Power Monitors, each Power Monitor
        optionally contains information establishing its business or
        site context.
        Importance Description
        A Power Monitor can provide an importance value in the range of
        1 to 100 to help differentiate a device's use or relative value
        to the site.  The importance range is from 1 (least important)
        to 100 (most important).  The default importance value is 1.
        For example: A typical office environment has several types of
        phones, which can be rated according to their business impact.
        A public desk phone has a lower importance (for example, 10)
        than a business-critical emergency phone (for example, 100).  As
        another example: A company can consider that a PC and a phone
        for a customer-service engineer is more important than a PC and
        a phone for lobby use.
        Although network managers must establish their own ranking, the
        following is a broad recommendation:
     <Claise, et. Al>      Expires September 14, 2011         [Page 16]

     Internet-Draft    <Power Management Archictecture>    March 2011
          . 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
        Keywords Description
        A Power Monitor can provide a set of keywords.  These keywords
        are a list of tags that can be used for grouping and summary
        reporting within or between Power Monitor Meter Domains.  All
        alphanumeric characters and symbols, such as #, (, $, !, and &,
        are allowed.  Potential examples are: IT, lobby, HumanResources,
        Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or
        SoftwareLab.  There is no default value for a keyword.
        Multiple keywords can be assigned to a device.  In such cases,
        the keywords are separated by commas and no spaces between
        keywords are allowed.  For example, "HR,Bldg1,Private".
        Another keyword use case is the virtual grouping of Power
        Monitors. For example, a Power Distribution Unit (PDU) that
        allows physical entities like outlets to be "ganged" together as
        a logical entity for simplified management purposes.  This is
        particularly useful for servers with multiple power supplies,
        where each power supply is connected to a different physical
        outlet.  Other implementations allow "gangs" to be created based
        on common ownership of outlets, such as business units or load
        shed priority or other non-physical relationships.  For example,
        current PDU implementations allow for an "M-to-N" mapping
        between outlet "gangs" and physical outlets:
              Outlet 1             (physical entity)
              Outlet 2             (physical entity)
              Outlet 3             (physical entity)
              Outlet 4             (physical entity)
              Outlet Gang A        (virtual entity)
              Outlet Gang B        (virtual entity)
              Gang A -> Outlets 1, 2 and 3
              Gang B -> Outlets 3 and 4
        Note the allowed overlap on Outlet 3, where Outlet 3 belongs to
        both "gangs."  The keywords concept for this specific example
        would be used as such:
              Outlet 1        Power Monitor 1, keywords: gangA
     <Claise, et. Al>      Expires September 14, 2011         [Page 17]

     Internet-Draft    <Power Management Archictecture>    March 2011
              Outlet 2        Power Monitor 2, keywords: gangA
              Outlet 3        Power Monitor 3, keywords: gangA, gangB
              Outlet 4        Power Monitor 4, keywords: gangB
        Each "Outlet Gang" virtual entity, aggregated based on the value
        of the keywords, reports the aggregated data from the individual
        outlet entities that comprise it.  The same concept enables a
        single point of control for all the individual outlet entities.
        For example, turning "Outlet Gang A" to the "off" state would
        turn outlets 1, 2, and 3 "off" in some implementations.  Note
        that the impact of this action on "Outlet Gang B" is out of
        scope of this document.
        Role Description
        Additionally, a Power Monitor can provide a "role description"
        string that indicates the purpose the Power Monitor serves in
        the network or for the site/business.  This could be a string
        describing the context the device fulfills in deployment.  For
        example, a lighting fixture in a kitchen area could have a role
        of "Hospitality Lighting" to provide context for the use of the
     5.6. Power Monitor States
        Power States represent universal states of power management of a
        Power Monitor.  Existing power state models can be roughly
        divided into operational and non-operational states.  Examples
        of operational power state models include PoE power classes and
        Windows Power Polices. PoE negotiation may select a power level
        from one of four power classes: Very Low power (1), Low power
        (2), Mid power (3), and High power (4).  Windows default power
        policy settings define three states: 'Power Saver', 'Balanced',
        and 'High Performance'.  Windows allows user defined states, so
        many more states are possible.  Some new devices starts to have
        several operational Power States: an IP phone with an High Power
        State and a lower operational Power State for the ability to
        only dial 911, IP surveillance cameras with different Power
        States depending on the image definition and sampling rate,
        It is foreseen that, with the goal to save energy, this trend
        will continue and many more devices will contain Power States.
        ACPI and the DMTF Power State models define non-operational
        states for when a system is inactive.  In our model, each Power
        State corresponds to a global, system, and performance state in
        the ACPI model [ACPI] and DMTF models.
     <Claise, et. Al>      Expires September 14, 2011         [Page 18]

     Internet-Draft    <Power Management Archictecture>    March 2011
                State      DMTF Power     ACPI            MIB Power
                             State       State           State Name
        Non-operational states:
                  1        Off-Hard      G3, S5           Mech Off
                  2        Off-Soft      G2, S5           Soft Off
                  3        Hibernate     G1, S4           Hibernate
                  4        Sleep-Deep    G1, S3           Sleep
                  5        Sleep-Light   G1, S2           Standby
                  6        Sleep-Light   G1, S1           Ready
        Operational states:
                  7        On            G0, S0, P5       LowMinus
                  8        On            G0, S0, P4       Low
                  9        On            G0, S0, P3       MediumMinus
                 10        On            G0, S0, P2       Medium
                 11        On            G0, S0, P1       HighMinus
                 12        On            G0, S0, P0       High
                   Figure 3: DMTF / ACPI Power State Mapping
        For example, a Power Monitor with a Power State of 9 would
        indicate an operational state with MediumMinus Power State.
        The Power States can be considered as guidelines in order to
        promote interoperability across device types.  Realistically,
        each specific feature requiring Power States will require a
        complete recommendation of its own.  For example, designing IP
        phones with consistent Power States across vendors requires a
        specification for IP phone design, along with the Power States
        Manufacturer Power States are required in some situations, such
        as when no mappings with the existing Power States are possible,
        or when more than the twelve specified Power States are
        A first example would be an imaginary device type, with only
        five states: "none", "short", "tall", "grande", and "venti".
          Manufacturer Power State    Respective Name
               0                           none
               1                           short
               2                           tall
               3                           grande
     <Claise, et. Al>      Expires September 14, 2011         [Page 19]

     Internet-Draft    <Power Management Archictecture>    March 2011
               4                           venti
                          Figure 4: Mapping Example 1
        In the unlikely event that there is no possible mapping between
        these Manufacturer Power States and the proposed Power Monitor
        Power States, the Power State will remain 0 throughout the MIB
        module, as displayed below.
           Power State / Name     Manufacturer Power State / Name
               0 / unknown              0 / none
               0 / unknown              1 / short
               0 / unknown              2 / tall
               0 / unknown              3 / grande
               0 / unknown              4 / venti
                          Figure 5: Mapping Example 2
        If a mapping between the Manufacturer Power States and the Power
        Monitor Power States is achievable, both series of states must
        exist in the MIB module in the Power Monitor Parent, allowing
        the EMS to understand the mapping between them by correlating
        the Power State with the Manufacturer Power States.
           Power State / Name       Manufacturer Power State / Name
               1 / Mech Off             0 / none
               2 / Soft Off             0 / none
               3 / Hibernate            0 / none
               4 / Sleep, Save-to-RAM   0 / none
               5 / Standby              0 / none
               6 / Ready                1 / short
               7 / LowMinus             1 / short
               8 / Low                  1 / short
               9 / MediumMinus          2 / tall
               10 / Medium              2 / tall
               11 / HighMinus           3 / grande
               12 / High                4 / venti
                          Figure 6: Mapping Example 3
        How the Power Monitor States are then mapped is an
        implementation choice.  However, it is recommended that the
        Manufacturer Power States map to the lowest applicable Power
        States, so that setting all Power Monitors to a Power State
        would be conservative in terms of disabled functionality on the
        Power Monitor.
     <Claise, et. Al>      Expires September 14, 2011         [Page 20]

     Internet-Draft    <Power Management Archictecture>    March 2011
        A second example would be a device type, such as a dimmer or a
        motor, with a high number of operational states.  For the sake
        of the example, 100 operational states are assumed.
           Power State / Name       Manufacturer Power State / Name
               1 / Mech Off                  0 / off
               2 / Soft Off                  0 / off
               3 / Hibernate                 0 / off
               4 / Sleep, Save-to-RAM        0 / off
               5 / Standby                   1 / off
               6 / Ready                     2 / off
               7 / LowMinus                  11 / 1%
               7 / LowMinus                  12 / 2%
               7 / LowMinus                  13 / 3%
               .                             .
               .                             .
               .                             .
               8 / Low                       15 / 15%
               8 / Low                       16 / 16%
               8 / Low                       17 / 17%
               .                             .
               .                             .
               .                             .
               9 / MediumMinus               30 / 30%
               9 / MediumMinus               31 / 31%
               9 / MediumMinus               32 / 32%
               .                             .
               .                             .
               .                             .
               10 / Medium                   45 / 45%
               10 / Medium                   46 / 46%
               10 / Medium                   47 / 47%
               .                             .
               .                             .
               .                             .
                          Figure 7: Mapping Example 4
        As specified in section 6, this architecture allows the
        configuration of the Power State, while configuring the
        Manufacturer Power State from the MIB directly is not possible.
     <Claise, et. Al>      Expires September 14, 2011         [Page 21]

     Internet-Draft    <Power Management Archictecture>    March 2011
     5.7. Power Monitor Usage Measurement
        A power measurement must be qualified with the units, magnitude,
        direction of power flow, and by what means the measurement was
        made (ex: Root Mean Square versus Nameplate).
        In addition, the Power Monitor should describe how it intends to
        measure usage as one of consumer, producer or meter of usage.
        Given the intent any readings can be correctly summarized or
        analyzed by an EMS.  For example metered usage reported by a
        meter and consumption usage reported by a device connected to
        that meter may naturally measure the same usage.  With the two
        measurements identified by intent a proper summarization can be
        made by an EMS.
        The power usage measurement should conform to the IEC 61850
        definition of unit multiplier for the SI (System International)
        units of measure.  The power usage measurement is considered an
        instantaneous usage value and does not include the usage over
        Measured values are represented in SI units obtained by
        BaseValue * 10 raised to the power of the scale.  For example,
        if current power usage of a Power Monitor is 3, it could be 3 W,
        3 mW, 3 KW, or 3 MW, depending on the value of the scaling
        factor.  Electric energy is often billed in kilowatt-hours
        instead of megajoules from the SI units.  Similarly, battery
        charge is often measured as miliamperes-hour (mAh) instead of
        coulombs from the SI units.  The units used in this framework
        are: W, A, Wh, Ah, V.  An conversion from Wh to Joule and from
        Ah to Coulombs is obviously possible, and can be described if
        In addition to knowing the usage and magnitude, it is useful to
        know how a Power Monitor usage measurement was obtained:
          . Whether the measurements were made at the device itself or
             from a remote source.
          . Description of the method that was used to measure the
             power and whether this method can distinguish actual or
             estimated values.
        An EMS can use this information to account for the accuracy and
        nature of the reading between different implementations.
        The EMS can use the Nameplate Power for provisioning, capacity
        planning and potentially billing.
     <Claise, et. Al>      Expires September 14, 2011         [Page 22]

     Internet-Draft    <Power Management Archictecture>    March 2011
     5.8. Optional Power Usage Quality
        Given a power measurement of a Power Monitor, it may in certain
        circumstances be desirable to know the power quality associated
        with that measurement.  The information model must adhere to the
        IEC 61850 7-2 standard for describing AC measurements.  In some
        Power Monitor Domains, the power quality may not be needed,
        available, or relevant to the Power Monitor.
     5.9. Optional Energy Measurement
        In addition to reporting the Power State, an approach to
        characterizing the energy demand is required.  It is well known
        in commercial electrical utility rates that demand charges can
        be on par with actual power charges, so it is useful to
        characterize the demand.  The demand can be described as the
        average energy of a Power Monitor over a time window called a
        demand interval (typically 15 minutes).  The highest peak energy
        demand measured over a time horizon, such as 1 month or 1 year,
        is often the basis for usage charges.  A single window of time
        of high usage can penalize the consumer with higher energy
        consumption charges.  However, it is relevant to measure the
        demand only when there are actual power measurements from a
        Power Monitor, and not when the power measurement is assumed or
        Several efficiency metrics can be derived and tracked with the
        demand usage data. For example:
          . Per-packet power costs for a networking device (router or
             switch) can be calculated by an EMS.  The packet count can
             be determined from the traffic usage in the ifTable
             [RFC2863], from the forwarding plane figure, or from the
             platform specifications.
          . Watt-hour power can be combined with utility energy sources
             to estimate carbon footprint and other emission statistics.
     5.10. Optional Battery Information
        Some Power Monitors may use batteries for storing energy and for
        receiving power supply.  These Power Monitors should report
        their current power supply (battery, power line, etc.) and the
        battery status for each contained battery. Battery-specific
        information to be reported should include the number of
        batteries contained in the device and per battery
     <Claise, et. Al>      Expires September 14, 2011         [Page 23]

     Internet-Draft    <Power Management Archictecture>    March 2011
          . battery type
          . nominal and remaining capacity
          . current charge
          . current state (charging, discharging, not in use, etc.)
          . number of charging cycles
          . expected remaining time that the battery can serve as power
          . expected remaining lifetime of the battery
        Beyond that a device containing a battery should be able to
        generate alarms when the battery charge falls below a given
        threshold and when the battery needs to be replaced.
     6. Structure of the Information Model: UML Representation
        The following basic UML represents an information model
        expression of the concepts in this framework.  This information
        model, provided as a reference for implementers, is represented
        as an MIB in the different related IETF Energy Monitoring
        documents.  However, other programming structure with different
        data models could be used as well.
        Notation is a shorthand UML with lowercase types considered
        platform or atomic types (i.e. int, string, collection).
        Uppercase types denote classes described further.  Collections
        and cardinality are expressed via qualifier notation.
        Attributes labeled static are considered class variables and
        global to the class.  Algorithms for class variable
        initialization, constructors or destructors are not shown
                                        | _Child Specific Info __    |
        +--------------------------+    |                            |
        |    Context Information   |    |  parentId : UUID           |
        | _______________________  |    |  parentProxyAbilities      |
        |                          |    |           : bitmap         |
        |  roleDescription : string|    | _mgmtMacAddress : octets   |
        |  keywords[0..n] : string |    |  mgmtAddress : inetaddress |
        |  importance : int        |    |  mgmtAddressType : enum    |
        |  category :  enum        |    |  mgmtDNSName : inetaddress |
        +--------------------------+    +----------------------------+
                  |                            |
     <Claise, et. Al>      Expires September 14, 2011         [Page 24]

     Internet-Draft    <Power Management Archictecture>    March 2011
                  |                            |
                  |                            |
                  v                            v
          |  Power Monitor Information              |
          |_______________________________________  |
          | index : int                             |
          | powerMonitorId | UUID                   |
          | name : string                           |
          | meterDomainName | string                |
          | alternateKey | string                   |
        |    Links Object         |
        | _______________________ |
        |  physicalEntity : int   |
        |  ethPortIndex : int     |
        |  ethPortGrpIndex : int  |
        |  lldpPortNumber : int   |
        |             Power Monitor                     |
        | _____________________________________________ |
        |  nameplate : Measurement                      |
        |  battery[0..n]: Battery                       |
        |  measurements[0..n]: Measurement              |
        | --------------------------------------------- |
        | Measurement instantaneousUsage()              |
        | DemandMeasurement historicalUsage()           |
          |  Measurements                     |
          | __________________________________|
          |                                   |
     <Claise, et. Al>      Expires September 14, 2011         [Page 25]

     Internet-Draft    <Power Management Archictecture>    March 2011
         |         PowerMeasurement                      |
         | --------------------------------------------  |
         | value : long                                  |
         | rate : enum {0,millisecond,seconds,           |
         |              minutes,hours,...}               |
         | multiplier : enum {-24..24}                   |
         | units : "watts"                               |
         | caliber : enum { actual, estimated,           |
         |                  trusted, assumed...}         |
         | accuracy : enum { 0..10000}                   |
         | current :  enum {AC, DC}                      |
         | origin : enum { self, remote }                |
         | time : timestamp                              |
         | quality : MeasurementQuality                  |
         |         TimeMeasurement                       |
         | --------------------------------------------  |
         | startTime : timestamp                         |
         | usage : Measurement                           |
         | maxUsage : Measurment                         |
         |        TimeInterval                    |
         |--------------------------------------- |
         |value : long                            |
         |units : enum { seconds, miliseconds..}  |
         |                                        |
         |        DemandMeasurement               |
         |--------------------------------------- |
         |intervalLength :  TimeInterval          |
         |intervalNumbers: long                   |
         |intervalMode :  enum { period, sliding, |
         |total }                                 |
         |intervalWindow : TimeInterval           |
         |sampleRate : TimeInterval               |
         |status : enum {active, inactive }       |
         |measurements : TimedMeasurement[]       |
     <Claise, et. Al>      Expires September 14, 2011         [Page 26]

     Internet-Draft    <Power Management Archictecture>    March 2011
         |       MeasurementQuality               |
         |                                        |
         |         ACQuality                     |
         | --------------------------------------|
         | acConfiguration : enum {SNGL, DEL,WYE}|
         | avgVoltage   : long                   |
         | avgCurrent   : long                   |
         | frequency    : long                   |
         | unitMultiplier  : int                 |
         | accuracy  : int                       |
         | totalActivePower  : long              |
         | totalReactivePower : long             |
         | totalApparentPower : long             |
         | totalPowerFactor : long               |
                   | 1
                   |        +------------------------------------+
                   |        |         ACPhase                    |
                   |        | -----------------------------------|
                   |     *  |                                    |
                   +--------+ phaseIndex : long                  |
                            | avgCurrent : long                  |
                            | activePower : long                 |
                            | reactivePower : long               |
                            | apparentPower : long               |
                            | powerFactor : long                 |
                                        ^           ^
                                        |           |
                                        |           |
                                        |           |
                                        |           |
        +-------------------------------+---+       |
        |        DelPhase                   |       |
        |---------------------------------  |       |
        |phaseToNextPhaseVoltage  : long    |       |
     <Claise, et. Al>      Expires September 14, 2011         [Page 27]

     Internet-Draft    <Power Management Archictecture>    March 2011
        |thdVoltage : long                  |       |
        |thdCurrent : long                  |       |
        |                                   |       |
        +-----------------------------------+       |
                                 |        WYEPhase              |
                                 |----------------------------- |
                                 |phaseToNeutralVoltage : long  |
                                 |thdCurrent : long             |
                                 |thdVoltage : long             |
                                 |                              |
                           POWER MONITOR & STATES
           |         Power Monitor                        |
           | currentLevel : int                           |
           | configuredLevel : int                        |
           | configuredTime : timestamp                   |
           | reason: string                               |
           | manufacturerLevels[0..n]: State              |
           | emanLevels[0..11] : State                    |
           | levelMappings[0..n] : LevelMapping           |
           |                                              |
            |        State                  |
            | ------------------------------|
            | name : string                 |
            | cardinality : int             |
            | maxUsage : Measurement        |
           |         Level Mapping                         |
           | emanLevelIndex: int                           |
           | manufacturerLevelIndex : int                  |
     <Claise, et. Al>      Expires September 14, 2011         [Page 28]

     Internet-Draft    <Power Management Archictecture>    March 2011
     7. Power Monitor Children Discovery
        There are multiple ways that the Power Monitor Parent can
        discover its Power Monitor Children, if they are not present on
        the same physical network element:
          . In case of PoE, the Power Monitor Parent automatically
             discovers a Power Monitor Child when the Child requests
          . The Power Monitor Parent and Children may run the Link
             Layer Discovery Protocol [LLDP], or any other discovery
             protocol, such as Cisco Discovery Protocol (CDP).  The
             Power Monitor Parent might even support the LLDP-MED MIB
             [LLDP-MED-MIB], which returns extra information on the
             Power Monitor Children.
          . The Power Monitor Parent may reside on a network connected
             facilities gateway.  A typical example is a converged
             building gateway, monitoring several other devices in the
             building, and serving as a proxy between SNMP and a
             protocol such as BACNET.
          . Power Monitor Parent/Power Monitor Child relationships may
             be set by manual or automatic network configuration
        When a Power Monitor Child supports only its own Manufacturer
        Power States, the Power Monitor Parent will have to discover
        those Manufacturer Power States.  Note that the communication
        specifications between the Power Monitor Parent and Children is
        out of the scope of this document.  This includes the
        Manufacturer Power States discovery, which is protocol-specific.
     8. Configuration
        This power management architecture allows the configuration of
        the following key parameters:
          . Power Monitor name: A unique printable name for the Power
          . Power Monitor Role: An administratively assigned name to
             indicate the purpose a Power Monitor serves in the network.
          . Power Monitor Importance: A ranking of how important the
             Power Monitor is, on a scale of 1 to 100, compared with
             other Power Monitors in the same Power Monitor Meter
     <Claise, et. Al>      Expires September 14, 2011         [Page 29]

     Internet-Draft    <Power Management Archictecture>    March 2011
          . Power Monitor Keywords: A list of keywords that can be used
             to group Power Monitors for reporting or searching.
          . Power Monitor Domain: Specifies the name of a Power Monitor
             Meter Domain for the Power Monitor.
          . The Power Monitor State: Specifies the current Power State
             (0..12) for the Power Monitor.
          . The energy demand parameters: For example, which interval
             length to report the energy on, the number of intervals to
             keep, etc.
          . Assigning a Power Monitor Parent to a Power Monitor Child
          . Assigning a Power Monitor Child to a Power Monitor Parent.
        When a Power Monitor requires a mapping with the Manufacturer
        Power State, the Power Monitor configuration is done via the
        Power State settings, and not directly via the Manufacturer
        Power States, which are read-only.  Taking into account Figure
        8, where the LowMinus Power State corresponds to three different
        Manufacturer Power States (11 for 1%, 12 for 2%, and 13 for 3%),
        the implication is that this architecture will not set the
        Manufacturer Power State to one percent granularity without
        communicating over or configuring the proprietary protocol for
        this Power Monitor.
        This architecture supports multiple means for setting the Power
        State of a specific Power Monitor. One of them is by setting an
        object in the Power State MIB. .  However, the Power Monitor
        might be busy executing an important task that requires the
        current Power State for some more time.  For example, a PC might
        have to finish a backup first, or an IP phone might be busy with
        a current phone call.  Therefore a second MIB object contains
        the actual Power State.  A difference in values between the two
        objects indicates that the Power Monitor is currently in Power
        State transition.
        Other, already well established means for setting Power States,
        such as DASH [DASH], already exist.  Such a protocol may be
        implemented between the Power Monitor Parent and the Power
        Monitor Child, when the Power Monitor Parent acts as a Power
        Proxy.  Note that the Wake-up-on-Lan (WoL) mechanism allows to
        transition a device out of the Off Power State.
       When a Power Monitor Parent is a Power Proxy, , the Power
       Monitor Parent should enumerate the capabilities it is providing
       for the Power Monitor Child. The child would express that it
       wants its parent to proxy capabilities such as, energy
       reporting, power state configurations, non physical wake
       capabilities (such as WoL)), or any combination of capabilities.
     <Claise, et. Al>      Expires September 14, 2011         [Page 30]

     Internet-Draft    <Power Management Archictecture>    March 2011
        Note that for the communication between the Power Monitor Parent
        and Children the MIB modules and other communication means
        defined for this architecture may be used, but as well other
        proprietary protocols may be applied. This includes
        communication of power settings and configuration information,
        such as the Power Monitor Domain.
     9. Fault Management
        [EMAN-REQ] specifies some requirements about power states such
        as "the current state - the time of the last change", "the total
        time spent in each state", "the number of transitions to each
        state", etc.  Such requirements are fulfilled via the
        pmPowerStateChange NOTIFICATION-TYPE [EMAN-MON-MIB].  This SNMP
        notification is generated when the value(s) of Power State has
        changed for the Power Monitor.
     10. Relationship with Other Standards Development Organizations
     10.1. Information Modeling
        This power management architecture should, as much as possible,
        reuse existing standards efforts, especially with respect to
        information modeling and data modeling [RFC3444].
        The data model for power, energy related objects is based on IEC
        Specific examples include:
          . The scaling factor, which represents Power Monitor usage
             magnitude, conforms to the IEC 61850 definition of unit
             multiplier for the SI (System International) units of
          . The power accuracy model is based on the ANSI and IEC
             Standards, which require that we use an accuracy class for
             power measurement.  ANSI and IEC define the following
             accuracy classes for power measurement:
             . IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
             . ANSI C12.20 class 0.2, 0.5
     <Claise, et. Al>      Expires September 14, 2011         [Page 31]

     Internet-Draft    <Power Management Archictecture>    March 2011
          . The powerQualityMIB MIB module adheres closely to the IEC
             61850 7-2 standard for describing AC measurements.
          . The power state definitions are based on the DMTF Power
             State Profile and ACPI models, with operational state
     10.2. Power States
        There are twelve Power Monitor States.  They are subdivided into
        six operational states, and six non-operational states.  The
        lowest non-operational state is 1 and the highest is six.  Each
        non-operational state corresponds to an ACPI state [ACPI].
     11. Implementation Scenarios
        The scope of power and energy monitoring consists of devices
        that consume power within and that are connected to a
        communications network.  These devices include:
        - Network devices and sub-components: Devices such as routers
        and switches and their sub-components.
        - Network attached endpoints: Devices that use the
        communications network, such as endpoints, PCs, and facility
        gateways that proxy energy monitor and control for commercial
        buildings or home automation.
        - Network attached meters or supplies: Devices that can monitor
          the electrical supply, such as smart meters or Universal
          Power Supplies (UPS) that meter and provide availability.
        This section provides illustrative examples that model different
        scenarios for implementation of the Power Monitor, including
        Power Monitor Parent and Power Monitor Child relationships.
        Each of the scenarios below is explained in more detail in the
        Power Monitor MIB document [EMAN-MON-MIB], with a mapping to the
        MIB Objects.
     Scenario 1: Switch with PoE endpoints
        Consider a PoE IP phone connected to a switch.  The IP phone is
        supplied with power from the PoE switch.
     <Claise, et. Al>      Expires September 14, 2011         [Page 32]

     Internet-Draft    <Power Management Archictecture>    March 2011
     Scenario 2: Switch with PoE endpoints with further connected
        Consider the same example as in Scenario 1, but with a PC daisy-
        chained from the IP phone for LAN connectivity.  The phone is
        supplied with power from the PoE port of the switch, while the
        PC draws power from the wall outlet.
     Scenario 3: A switch with Wireless Access Points
        Consider a WAP (Wireless Access Point) connected to the PoE port
        of a switch.  There are several PCs connected to the Wireless
        Access Point over Wireless protocols.  All PCs draw power from
        the wall outlets.
        The switch port is the Power Monitor Parent for the Wireless
        Access Point (WAP) and all the PCs. But there is a distinction
        among the Power Monitor Children, as the WAP draws power from
        the PoE port of the switch and the PCs draw power from the wall
     Scenario 4: Network connected facilities gateway
        At the top of the network hierarchy of a building network is a
        gateway device that can perform protocol conversion between many
        facility management devices, such as BACNET, MODBUS, DALI, LON,
        etc.  There are power meters associated with power-consuming
        entities (Heating Ventilation & Air Conditioning - HVAC,
        lighting, electrical, fire control, elevators, etc).  The
        proposed MIB can be implemented on the gateway device.  The
        gateway can be considered as the Power Monitor Parent, while the
        power meters associated with the energy consuming entities can
        be considered as its Power Monitor Children.
     Scenario 5: Data center network
        A typical data center network consists of a hierarchy of
        switches.  At the bottom of the hierarchy there are servers
        mounted on a rack, and these are connected to the top-of-the-
        rack switches.  The top switches are connected to aggregation
        switches that are in turn connected to core switches.  As an
        example, Server 1 and Server 2 are connected to different switch
        ports of the top switch.
     <Claise, et. Al>      Expires September 14, 2011         [Page 33]

     Internet-Draft    <Power Management Archictecture>    March 2011
        The proposed MIB can be implemented on the switches.  The switch
        can be considered as the Power Monitor Parent.  The servers can
        be considered as the Power Monitor Children.
     Scenario 6: Building gateway device
        Similar scenario as the scenario 4.
     Scenario 7: Power consumption of UPS
        Data centers and commercial buildings can have Uninterruptible
        Power Supplies (UPS) connected to the network. The Power Monitor
        can be used to model a UPS as a Power Monitor Parent with the
        connected devices as Power Monitor Children.
     Scenario 8: Power consumption of battery-based devices
        A PC is a typical example of a battery-based device.
     12. Security Considerations
        Regarding the data attributes specified here, some or all may be
        considered sensitive or vulnerable in some network environments.
        Reading or writing these attributes without proper protection
        such as encryption or access authorization may have negative
        effects on the network capabilities.
     12.1. Security Considerations for SNMP
        Readable objects in a MIB modules (i.e., objects with a MAX-
        ACCESS other than not-accessible) may be considered sensitive or
        vulnerable in some network environments.  It is thus important
        to control GET and/or NOTIFY access to these objects and
        possibly to encrypt the values of these objects when sending
        them over the network via SNMP.
        The support for SET operations in a non-secure environment
        without proper protection can have a negative effect on network
        operations.  For example:
          . Unauthorized changes to the Power Domain or business
             context of a Power Monitor may result in misreporting or
             interruption of power.
     <Claise, et. Al>      Expires September 14, 2011         [Page 34]

     Internet-Draft    <Power Management Archictecture>    March 2011
          . Unauthorized changes to a power state may disrupt the power
             settings of the different Power Monitors, and therefore the
             state of functionality of the respective Power Monitors.
          . Unauthorized changes to the demand history may disrupt
             proper accounting of energy usage.
        With respect to data transport SNMP versions prior to SNMPv3 did
        not include adequate security.  Even if the network itself is
        secure (for example, by using IPsec), there is still no secure
        control over who on the secure network is allowed to access and
        GET/SET (read/change/create/delete) the objects in these MIB
        It is recommended that implementers consider the security
        features as provided by the SNMPv3 framework (see [RFC3410],
        section 8), including full support for the SNMPv3 cryptographic
        mechanisms (for authentication and privacy).
        Further, deployment of SNMP versions prior to SNMPv3 is not
        recommended.  Instead, it is recommended to deploy SNMPv3 and to
        enable cryptographic security.  It is then a customer/operator
        responsibility to ensure that the SNMP entity giving access to
        an instance of these MIB modules is properly configured to give
        access to the objects only to those principals (users) that have
        legitimate rights to GET or SET (change/create/delete) them.
     13. IANA Considerations
        This document has no actions for IANA.
     14. Acknowledgments
        The authors would like to Michael Brown for improving the text
        dramatically, and Bruce Nordman for his excellent feedback.
     15. References
     Normative References
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet
                Standard Management Framework ", RFC 3410, December
     <Claise, et. Al>      Expires September 14, 2011         [Page 35]

     Internet-Draft    <Power Management Archictecture>    March 2011
        [RFC5101] B. Claise, Ed., Specification of the IP Flow
                Information Export (IPFIX) Protocol for the Exchange of
                IP Traffic Flow Information, RFC 5101, January 2008.
        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
                M. Chandramouli, "Requirements for Power Monitoring",
                draft-ietf-eman-requirements-00, (work in progress),
                December 2010.
        [EMAN-AWARE-MIB] Parello, J., and B. Claise, "Energy-aware
                Networks and Devices MIB", draft-ietf-eman-energy-
                aware-mib-01, (work in progress), March 2011.
        [EMAN-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and
                Schoening, B., "Power and Energy Monitoring MIB",
                draft-claise-energy-monitoring-mib-06, (work in
                progress), October 2010.
     Informative References
        [RFC2863]  McCloghrie, K., Kastenholz, F., "The Interfaces Group
                MIB", RFC 2863, June 2000.
        [RFC3444]  Pras, A., Schoenwaelder, J. "On the Differences
                between Information Models and Data Models", RFC 3444,
                January 2003.
        [ACPI] "Advanced Configuration and Power Interface
                Specification", http://www.acpi.info/spec30b.htm
        [LLDP]  IEEE Std 802.1AB, "Station and Media Control
                Connectivity Discovery", 2005.
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information
                Base extension module for TIA-TR41.4 media endpoint
                discovery information", July 2005.
        [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy
                Management (EMAN) Applicability Statement", draft-
                tychon-eman-applicability-statement-00, (work in
                progress), October 2010
        [DASH] "Desktop and mobile Architecture for System Hardware",
     <Claise, et. Al>      Expires September 14, 2011         [Page 36]

     Internet-Draft    <Power Management Archictecture>    March 2011
     Authors' Addresses
      Benoit Claise
      Cisco Systems, Inc.
      De Kleetlaan 6a b1
      Diegem 1813
      Phone: +32 2 704 5622
      Email: bclaise@cisco.com
      John Parello
      Cisco Systems, Inc.
      3550 Cisco Way
      San Jose, California 95134
      Phone: +1 408 525 2339
      Email: jparello@cisco.com
      Brad Schoening
      44 Rivers Edge Drive
      Little Silver, NJ 07739
      Email: brad@bradschoening.com
     Juergen Quittek
     NEC Europe Ltd., Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Phone: +49 6221 90511 15
     EMail: quittek@netlab.nec.de
     <Claise, et. Al>      Expires September 14, 2011         [Page 37]

     Internet-Draft    <Power Management Archictecture>    March 2011
     <Claise, et. Al>      Expires September 14, 2011         [Page 38]

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