GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7326

Internet Engineering Task Force (IETF) J. Parello Request for Comments: 7326 B. Claise Category: Informational Cisco Systems, Inc. ISSN: 2070-1721 B. Schoening

                                                Independent Consultant
                                                            J. Quittek
                                                       NEC Europe Ltd.
                                                        September 2014
                    Energy Management Framework

Abstract

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

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7326.

Parello, et al. Informational [Page 1] RFC 7326 EMAN Framework September 2014

Copyright Notice

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

Table of Contents

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

Parello, et al. Informational [Page 2] RFC 7326 EMAN Framework September 2014

1. Introduction

 Network Management is often divided into the five main areas defined
 in the ISO Telecommunications Management Network model: Fault,
 Configuration, Accounting, Performance, and Security Management
 (FCAPS) [X.700].  Not covered by this traditional management model is
 Energy Management, which is rapidly becoming a critical area of
 concern worldwide, as seen in [ISO50001].
 This document defines an Energy Management framework for devices
 within, or connected to, communication networks, per the Energy
 Management requirements specified in [RFC6988].  The devices, or the
 components of these devices (such as line cards, fans, and disks),
 can then be monitored and controlled.  Monitoring includes measuring
 power, energy, demand, and attributes of power.  Energy Control can
 be performed by setting a device's or component's state.  The devices
 monitored by this framework can be either of the following:
 o  consumers of energy (such as routers and computer systems) and
    components of such devices (such as line cards, fans, and disks)
 o  producers of energy (like an uninterruptible power supply or
    renewable energy system) and their associated components (such as
    battery cells, inverters, or photovoltaic panels)
 This framework further describes how to identify, classify, and
 provide context for such devices.  While context information is not
 specific to Energy Management, some context attributes are specified
 in the framework, addressing the following use cases:
 o  How important is a device in terms of its business impact?
 o  How should devices be grouped for reporting and searching?
 o  How should a device role be described?
 Guidelines for using context for Energy Management are described.
 The framework introduces the concept of a Power Interface that is
 analogous to a network interface.  A Power Interface is defined as an
 interconnection among devices where energy can be provided, received,
 or both.
 The most basic example of Energy Management is a single device
 reporting information about itself.  In many cases, however, energy
 is not measured by the device itself but is measured upstream in the
 power distribution tree.  For example, a Power Distribution Unit
 (PDU) may measure the energy it supplies to attached devices and

Parello, et al. Informational [Page 3] RFC 7326 EMAN Framework September 2014

 report this to an Energy Management System.  Therefore, devices often
 have relationships to other devices or components in the power
 network.  An Energy Management System (EnMS) generally requires an
 understanding of the power topology (who provides power to whom), the
 Metering topology (who meters whom), and the potential Aggregation
 (who aggregates values of others).
 The relationships build on the Power Interface concept.  The
 different relationships among devices and components, as specified in
 this document, include power source, Metering, and Aggregation
 Relationships.
 The framework does not cover non-electrical equipment, nor does it
 cover energy procurement and manufacturing.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].
 In this document, these words will appear with the above
 interpretation only when in ALL CAPS.  Lowercase uses of these words
 are not to be interpreted as carrying the significance of RFC 2119
 key words.
 In this section, some terms have a NOTE that is not part of the
 definition itself but accounts for differences between terminologies
 of different standards organizations or further clarifies the
 definition.
 The terms are listed in an order that aids in reading where terms may
 build off a previous term, as opposed to an alphabetical ordering.
 Some terms that are common in electrical engineering or that describe
 common physical items use a lowercase notation.
 Energy Management
    Energy Management is a set of functions for measuring, modeling,
    planning, and optimizing networks to ensure that the network and
    network-attached devices use energy efficiently and appropriately
    for the nature of the application and the cost constraints of the
    organization.
    Reference: Adapted from [TMN].

Parello, et al. Informational [Page 4] RFC 7326 EMAN Framework September 2014

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

Parello, et al. Informational [Page 5] RFC 7326 EMAN Framework September 2014

 Energy Control
    Energy Control is a part of Energy Management that deals with
    directing influence over devices.
 electrical equipment
    This is a general term that includes materials, fittings, devices,
    appliances, fixtures, apparatus, machines, etc., that are used as
    a part of, or in connection with, an electric installation.
    Reference: [IEEE100].
 non-electrical equipment (mechanical equipment)
    This is a general term that includes materials, fittings, devices,
    appliances, fixtures, apparatus, machines, etc., that are used as
    a part of, or in connection with, non-electrical power
    installations.
    Reference: Adapted from [IEEE100].
 device
    A device is a piece of electrical or non-electrical equipment.
    Reference: Adapted from [IEEE100].
 component
    A component is a part of electrical or non-electrical equipment
    (device).
    Reference: Adapted from [TMN].
 power inlet
    A power inlet (or simply "inlet") is an interface at which a
    device or component receives energy from another device or
    component.
 power outlet
    A power outlet (or simply "outlet") is an interface at which a
    device or component provides energy to another device or
    component.
 energy
    Energy is that which does work or is capable of doing work.  As
    used by electric utilities, it is generally a reference to
    electrical energy and is measured in kilowatt-hours (kWh).
    Reference: [IEEE100].

Parello, et al. Informational [Page 6] RFC 7326 EMAN Framework September 2014

    NOTE:
    1. Energy is the capacity of a system to produce external activity
       or perform work [ISO50001].
 power
    Power is the time rate at which energy is emitted, transferred, or
    received; power is usually expressed in watts (joules per second).
    Reference: [IEEE100].
 demand
    Demand is the average value of power or a related quantity over a
    specified interval of time.  Note: Demand is expressed in
    kilowatts, kilovolt-amperes, kilovars, or other suitable units.
    Reference: [IEEE100].
    NOTE:
    1. While IEEE100 defines demand in kilo measurements, for EMAN we
       use watts with any suitable metric prefix.
 provide energy
    A device (or component) "provides" energy to another device if
    there is an energy flow from this device to the other one.
 receive energy
    A device (or component) "receives" energy from another device if
    there is an energy flow from the other device to this one.
 meter (energy meter)
    A meter is a device intended to measure electrical energy by
    integrating power with respect to time.
    Reference: Adapted from [IEC60050].
 battery
    A battery is one or more cells (consisting of an assembly of
    electrodes, electrolyte, container, terminals, and (usually)
    separators) that are a source and/or store of electric energy.
    Reference: Adapted from [IEC60050].
 Power Interface
    A Power Interface is a power inlet, outlet, or both.

Parello, et al. Informational [Page 7] RFC 7326 EMAN Framework September 2014

 Nameplate Power
    The Nameplate Power is the nominal power of a device as specified
    by the device manufacturer.
 Power Attributes
    Power Attributes are measurements of the electrical current,
    voltage, phase, and frequencies at a given point in an electrical
    power system.
    Reference: Adapted from [IEC60050].
    NOTE:
    1. Power Attributes are not intended to provide any bounds or
       recommended range for the value.  They are simply the reading
       of the value associated with the attribute in question.
 Power Quality
    "Power Quality" refers to characteristics of the electrical
    current, voltage, phase, and frequencies at a given point in an
    electric power system, evaluated against a set of reference
    technical parameters.  These parameters might, in some cases,
    relate to the compatibility between electricity supplied in an
    electric power system and the loads connected to that electric
    power system.
    Reference: [IEC60050].
    NOTE:
    1. Electrical characteristics representing Power Quality
       information are typically required by customer facility Energy
       Management Systems.  Electrical characteristics are not
       intended to satisfy the detailed requirements of Power Quality
       monitoring.  Standards typically also give ranges of allowed
       values; the information attributes are the raw measurements,
       not the "yes/no" determination by the various standards.
    Reference: [ASHRAE-201].

Parello, et al. Informational [Page 8] RFC 7326 EMAN Framework September 2014

 Power State
    A Power State is a condition or mode of a device (or component)
    that broadly characterizes its capabilities, power, and
    responsiveness to input.
    Reference: Adapted from [IEEE1621].
 Power State Set
    A Power State Set is a collection of Power States that comprises a
    named or logical control grouping.

3. Target Devices

 With Energy Management, there exists a wide variety of devices that
 may be contained in the same deployment as a communication network
 but comprise a separate facility, home, or power distribution
 network.
 Energy Management has special challenges because a power distribution
 network supplies energy to devices and components, while a separate
 communications network monitors and controls the power distribution
 network.
 The target devices for Energy Management are all devices that can be
 monitored or controlled (directly or indirectly) by an Energy
 Management System (EnMS).  These target devices include, for example:
 o  Simple electrical appliances and fixtures
 o  Hosts, such as a PC, a server, or a printer
 o  Switches, routers, base stations, and other network equipment such
    as middleboxes
 o  Components within devices, e.g., a line card inside a switch
 o  Batteries functioning as a device or component that is a store of
    energy
 o  Devices or components that charge or produce energy, such as solar
    cells, charging stations, or generators
 o  Power over Ethernet (PoE) endpoints
 o  Power Distribution Units (PDUs)
 o  Protocol gateway devices for Building Management Systems (BMS)

Parello, et al. Informational [Page 9] RFC 7326 EMAN Framework September 2014

 o  Electrical meters
 o  Sensor controllers with subtended sensors
 Target devices include devices that communicate via the Internet
 Protocol (IP) as well as devices using other means for communication.
 The latter are managed through gateways or proxies that can
 communicate using IP.

4. Physical Reference Model

 The following reference model describes physical power topologies
 that exist in parallel with a communication topology.  While many
 more topologies can be created with a combination of devices, the
 following are some basic ones that show how Energy Management
 topologies differ from Network Management topologies.
     NOTE: "###" is used to denote a transfer of energy.
           "- >" is used to denote a transfer of information.
                       Basic Energy Management:
                      +--------------------------+
                      | Energy Management System |
                      +--------------------------+
                                  ^  ^
                       monitoring |  | control
                                  v  v
                              +---------+
                              | device  |
                              +---------+
                          Basic Power Supply:
              +-----------------------------------------+
              |         Energy Management System        |
              +-----------------------------------------+
                    ^  ^                       ^  ^
         monitoring |  | control    monitoring |  | control
                    v  v                       v  v
              +--------------+        +-----------------+
              | power source |########|      device     |
              +--------------+        +-----------------+

Parello, et al. Informational [Page 10] RFC 7326 EMAN Framework September 2014

              Single Power Supply with Multiple Devices:
                +---------------------------------------+
                |       Energy Management System        |
                +---------------------------------------+
                   ^  ^                       ^  ^
        monitoring |  | control    monitoring |  | control
                   v  v                       v  v
                +--------+        +------------------+
                | power  |########|         device 1 |
                | source |   #    +------------------+-+
                +--------+   #######|         device 2 |
                               #    +------------------+-+
                               #######|         device 3 |
                                      +------------------+
              Multiple Power Supplies with Single Device:
           +----------------------------------------------+
           |          Energy Management System            |
           +----------------------------------------------+
               ^  ^              ^  ^              ^  ^
          mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
               v  v              v  v              v  v
           +----------+      +----------+      +----------+
           | power    |######|  device  |######| power    |
           | source 1 |      |          |      | source 2 |
           +----------+      +----------+      +----------+

5. Areas Not Covered by the Framework

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

Parello, et al. Informational [Page 11] RFC 7326 EMAN Framework September 2014

 Energy Procurement and Manufacturing
    While an EnMS may be a central point for corporate reporting, cost
    computation, environmental impact analysis, and regulatory
    compliance reporting, Energy Management in this framework excludes
    energy procurement and the environmental impact of energy use.
    As such, the framework does not include:
    o  Cost in currency or environmental units of manufacturing a
       device
    o  Embedded carbon or environmental equivalences of a device
    o  Cost in currency or environmental impact to dismantle or
       recycle a device
    o  Supply chain analysis of energy sources for device deployment
    o  Conversion of the usage or production of energy to units
       expressed from the source of that energy (such as the
       greenhouse gas emissions associated with the transfer of energy
       from a diesel source)

6. Energy Management Abstraction

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

6.1. Conceptual Model

 This section describes an information model that addresses issues
 specific to Energy Management and complements existing Network
 Management models.
 An information model for Energy Management will need to describe a
 means to monitor and control devices and components.  The model will
 also need to describe the relationships among, and connections
 between, devices and components.
 This section defines a conceptual model for devices and components
 that is similar to the model used in Network Management: devices,
 components, and interfaces.  This section then defines the additional
 attributes specific to Energy Management for those entities that are
 not available in existing Network Management models.

Parello, et al. Informational [Page 12] RFC 7326 EMAN Framework September 2014

 For modeling the devices and components, this section describes three
 classes denoted by a "(Class)" suffix: a Device (Class), a Component
 (Class), and a Power Interface (Class).  These classes are sub-types
 of an abstract Energy Object (Class).
          Summary of Notation for Modeling Physical Equipment
       Physical         Modeling (Metadata)      Model Instance
       ---------------------------------------------------------
       equipment        Energy Object (Class)    Energy Object
       device           Device (Class)           Device
       component        Component (Class)        Component
       inlet/outlet     Power Interface (Class)  Power Interface
 This section then describes the attributes of an Energy Object
 (Class) for identification, classification, context, control, power,
 and energy.
 Since the interconnections between devices and components for Energy
 Management may have no relation to the interconnections for Network
 Management, the Energy Object (Classes) contain a separate
 Relationships (Class) as an attribute to model these types of
 interconnections.
 The next sections describe each of the classes and categories of
 attributes in the information model.
 Not all of the attributes are mandatory for implementations.
 Specifications describing implementations of the information model in
 this framework need to be explicit about which are mandatory and
 which are optional to implement.
 The formal definitions of the classes and attributes are specified in
 Section 7.

6.2. Energy Object (Class)

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

Parello, et al. Informational [Page 13] RFC 7326 EMAN Framework September 2014

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

6.2.1. Device (Class)

 The Device (Class) is a subclass of Energy Object (Class) that
 represents a physical piece of equipment.
 A Device (Class) instance represents a device that is a consumer,
 producer, meter, distributor, or store of energy.
 A Device (Class) instance may represent a physical device that
 contains other components.

6.2.2. Component (Class)

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

6.2.3. Power Interface (Class)

 A Power Interface (Class) represents the interconnections (inlet,
 outlet) among devices or components where energy can be provided,
 received, or both.
 The Power Interface (Class) is a subclass of Energy Object (Class)
 that represents a physical inlet or outlet.
 There are some similarities between Power Interfaces and network
 interfaces.  A network interface can be set to different states, such
 as sending or receiving data on an attached line.  Similarly, a Power
 Interface can be receiving or providing energy.
 A Power Interface (Class) instance can represent (physically) an AC
 power socket, an AC power cord attached to a device, or an 8P8C
 (RJ45) PoE socket, etc.

Parello, et al. Informational [Page 14] RFC 7326 EMAN Framework September 2014

6.3. Energy Object Attributes

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

6.3.1. Identification

 A Universally Unique Identifier (UUID) [RFC4122] is used to uniquely
 and persistently identify an Energy Object.
 Every Energy Object has an optional unique human-readable printable
 name.  Possible naming conventions are textual DNS name, Media Access
 Control (MAC) address of the device, interface ifName, or a text
 string uniquely identifying the Energy Object.  As an example, in
 the case of IP phones, the Energy Object name can be the device's
 DNS name.
 Additionally, an alternate key is provided to allow an Energy Object
 to be optionally linked with models in different systems.

6.3.2. Context: General

 In order to aid in reporting and in differentiation between Energy
 Objects, each object optionally contains information establishing its
 business, site, or organizational context within a deployment.
 The Energy Object (Class) contains a category attribute that broadly
 describes how an instance is used in a deployment.  The category
 indicates whether the Energy Object is primarily functioning as a
 consumer, producer, meter, distributor, or store of energy.
 Given the category and context of an object, an EnMS can summarize or
 analyze measurements for the site.

6.3.3. Context: Importance

 An Energy Object can provide an importance value in the range of 1 to
 100 to help rank a device's use or relative value to the site.  The
 importance range is from 1 (least important) to 100 (most important).
 The default importance value is 1.
 For example, a typical office environment has several types of
 phones, which can be rated according to their business impact.  A
 public desk phone has a lower importance (for example, 10) than a
 business-critical emergency phone (for example, 100).  As another
 example, a company can consider that a PC and a phone for a customer
 service engineer are more important than a PC and a phone for
 lobby use.

Parello, et al. Informational [Page 15] RFC 7326 EMAN Framework September 2014

 Although EnMS and administrators can establish their own ranking, the
 following example is a broad recommendation for commercial
 deployments [CISCO-EW]:
    90 to 100  Emergency response
    80 to 90   Executive or business-critical
    70 to 79   General or average
    60 to 69   Staff or support
    40 to 59   Public or guest
    1  to 39   Decorative or hospitality

6.3.4. Context: Keywords

 The Energy Object (Class) contains an attribute with context
 keywords.
 An Energy Object can provide a set of keywords that is a list of tags
 that can be used for grouping, summary reporting (within or between
 Energy Management Domains), and searching.  Potential examples are
 IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace,
 router, phone, floor2, or SoftwareLab.
 The specifics of how this tag is represented are left to the MIB
 module or other object definition documents to be based on this
 framework.
 There is no default value for a keyword.  Multiple keywords can be
 assigned to an Energy Object.

6.3.5. Context: Role

 The Energy Object (Class) contains a role attribute.  The "role
 description" string indicates the primary purpose the Energy Object
 serves in the deployment.  This could be a string representing the
 purpose the Energy Object fulfills in the deployment.
 The specifics of how this tag is represented are left to the MIB
 module or other object definition documents to be based on this
 framework.
 Administrators can define any naming scheme for the role.  As
 guidance, a two-word role that combines the service the Energy Object
 provides, along with type, can be used [IPENERGY].
 Example types of devices: Router, Switch, Light, Phone, WorkStation,
 Server, Display, Kiosk, HVAC.

Parello, et al. Informational [Page 16] RFC 7326 EMAN Framework September 2014

                 Example Services by Line of Business:
       Line of Business     Service
       ------------------------------------------------------
       Education            Student, Faculty, Administration,
                            Athletic
       Finance              Trader, Teller, Fulfillment
       Manufacturing        Assembly, Control, Shipping
       Retail               Advertising, Cashier
       Support              Helpdesk, Management
       Medical              Patient, Administration, Billing
 Role as a two-word string: "Faculty Desktop", "Teller Phone",
 "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk",
 "Administration Switch".
 The specifics of how this tag is represented are left to the MIB
 module or other object definition documents to be based on this
 framework.

6.3.6. Context: Domain

 The Energy Object (Class) contains a string attribute to indicate
 membership in an Energy Management Domain.  An Energy Management
 Domain can be any collection of Energy Objects in a deployment, but
 it is recommended to map 1:1 with a metered or sub-metered portion of
 the site.
 In building management, a meter refers to the meter provided by the
 utility used for billing and measuring power to an entire building or
 unit within a building.  A sub-meter refers to a customer- or user-
 installed meter that is not used by the utility to bill but is
 instead used to get measurements from portions of a building.
 The specifics of how this tag is represented are left to the MIB
 module or other object definition documents to be based on this
 framework.
 An Energy Object MUST be a member of a single Energy Management
 Domain; therefore, one attribute is provided.

Parello, et al. Informational [Page 17] RFC 7326 EMAN Framework September 2014

6.4. Measurements

 The Energy Object (Class) contains attributes to describe power,
 energy, and demand measurements.
 An analogy for understanding power versus energy measurements can be
 made to speed and distance in automobiles.  Just as a speedometer
 indicates the rate of change of distance (speed), a power measurement
 indicates the rate of transfer of energy.  The odometer in an
 automobile measures the cumulative distance traveled; similarly, an
 energy measurement indicates the accumulated energy transferred.
 Demand measurements are averages of power measurements over time.
 So, using the same analogy to an automobile: measuring the average
 vehicle speed over multiple intervals of time for a given distance
 traveled, demand is the average power measured over multiple time
 intervals for a given energy value.
 Within this framework, energy will only be quantified in units of
 watt-hours.  Physical devices measuring energy in other units must
 convert values to watt-hours or be represented by Energy Objects that
 convert to watt-hours.

6.4.1. Measurements: Power

 The Energy Object (Class) contains a Nameplate Power Attribute that
 describes the nominal power as specified by the manufacturer of the
 device.  The EnMS can use the Nameplate Power for provisioning,
 capacity planning, and (potentially) billing.
 The Energy Object (Class) has attributes that describe the present
 power information, along with how that measurement was obtained or
 derived (e.g., actual, estimated, or static).
 A power measurement is qualified with the units, magnitude, and
 direction of power flow and is qualified as to the means by which the
 measurement was made.
 Power measurement magnitude conforms to the [IEC61850] definition of
 unit multiplier for the SI (System International) units of measure.
 Measured values are represented in SI units obtained by BaseValue *
 (10 ^ Scale).  For example, if current power usage of an Energy
 Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 MW, depending on
 the value of the scaling factor.  17 W implies that BaseValue = 17
 and Scale = 0, whereas 17 mW implies that BaseValue = 17 and
 ScaleFactor = -3.

Parello, et al. Informational [Page 18] RFC 7326 EMAN Framework September 2014

 An Energy Object (Class) indicates how the power measurement was
 obtained with a caliber and accuracy attribute that indicates:
 o  Whether the measurements were made at the device itself or at a
    remote source.
 o  Description of the method that was used to measure the power and
    whether this method can distinguish actual or estimated values.
 o  Accuracy for actual measured values.

6.4.2. Measurements: Power Attributes

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

6.4.3. Measurements: Energy

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

6.4.4. Measurements: Demand

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

6.5. Control

 The Energy Object (Class) contains a Power State Set (Class)
 attribute that represents the set of Power States a device or
 component supports.
 A Power State describes a condition or mode of a device or component.
 While Power States are typically used for control, they may be used
 for monitoring only.
 A device or component is expected to support at least one set of
 Power States consisting of at least two states: an on state and an
 off state.
 There are many existing standards describing device and component
 Power States.  The framework supports modeling a mixed set of Power
 States defined in different standards.  A basic example is given by

Parello, et al. Informational [Page 19] RFC 7326 EMAN Framework September 2014

 the three Power States defined in IEEE1621 [IEEE1621]: on, off, and
 sleep.  The Distributed Management Task Force (DMTF) standards
 organization [DMTF], Advanced Configuration and Power Interface
 (ACPI) specification [ACPI], and Printer Working Group (PWG) all
 define larger numbers of Power States.
 The semantics of a Power State are specified by:
 a) The functionality provided by an Energy Object in this state.
 b) A limitation of the power that an Energy Object uses in this
    state.
 c) A combination of a) and b).
 The semantics of a Power State should be clearly defined.  Limitation
 (curtailment) of the power used by an Energy Object in a state may be
 specified by:
 o  An absolute power value.
 o  A percentage value of power relative to the Energy Object's
    Nameplate Power.
 o  An indication of power relative to another Power State.  For
    example, specify that power in state A is less than in state B.
 o  For supporting Power State management, an Energy Object provides
    statistics on Power States, including the time an Energy Object
    spent in a certain Power State and the number of times an Energy
    Object entered a Power State.
 When requesting an Energy Object to enter a Power State, an
 indication of the Power State's name or number can be used.
 Optionally, an absolute or percentage of Nameplate Power can be
 provided to allow the Energy Object to transition to a nearest or
 equivalent Power State.
 When an Energy Object is set to a particular Power State, the
 represented device or component may be busy.  The Energy Object
 should set the desired Power State and then update the actual Power
 State when the device or component changes.  There are then two Power
 State (Class) control attributes: actual and requested.
 The following sections describe well-known Power States for devices
 and components that should be modeled in the information model.

Parello, et al. Informational [Page 20] RFC 7326 EMAN Framework September 2014

6.5.1. Power State Sets

 There are several standards and implementations of Power State Sets.
 The Energy Object (Class) supports modeling one or multiple Power
 State Set implementations on the device or component concurrently.
 There are currently three Power State Sets specified by IANA:
    IEEE1621 (256) - [IEEE1621]
    DMTF (512)     - [DMTF]
    EMAN (768)     - [RFC7326]
 The respective specific states related to each Power State Set are
 specified in the following sections.  The guidelines for the
 modification of Power State Sets are specified in the IANA
 Considerations section.

6.5.2. Power State Set: IEEE1621

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

6.5.3. Power State Set: DMTF

 The DMTF [DMTF] standards organization has defined a power profile
 standard based on the CIM (Common Information Model), which consists
 of 15 Power States.
 The DMTF standard is targeted for hosts and computers.  Details of
 the semantics of each Power State within the DMTF Power State Set can
 be obtained from the DMTF Power State Management Profile
 specification [DMTF].

Parello, et al. Informational [Page 21] RFC 7326 EMAN Framework September 2014

 The DMTF power profile extends ACPI Power States.  The following
 table provides a mapping between DMTF and ACPI Power State Sets:
     DMTF                                 ACPI
     ------------------------------------------------
     Reserved (0)
     Reserved (1)
     ON (2)                               G0/S0
     Sleep-Light (3)                      G1/S1 G1/S2
     Sleep-Deep (4)                       G1/S3
     Power Cycle (Off-Soft) (5)           G2/S5
     Off-Hard (6)                         G3
     Hibernate (Off-Soft) (7)             G1/S4
     Off-Soft (8)                         G2/S5
     Power Cycle (Off-Hard) (9)           G3
     Master Bus Reset (10)                G2/S5
     Diagnostic Interrupt (11)            G2/S5
     Off-Soft Graceful (12)               G2/S5
     Off-Hard Graceful (13)               G3
     MasterBus Reset Graceful (14)        G2/S5
     Power Cycle Off-Soft Graceful (15)   G2/S5
     Power Cycle Off-Hard Graceful (16)   G3

6.5.4. Power State Set: IETF EMAN

 The EMAN Power States are an expansion of the basic Power States as
 defined in [IEEE1621] plus the addition of the Power States defined
 in [ACPI] and [DMTF].  Therefore, in addition to the non-operational
 states as defined in [ACPI] and [DMTF] standards, several
 intermediate operational states have been defined.
 Physical devices and components are expected to support the EMAN
 Power State Set or to be modeled via an Energy Object the supports
 these states.
 An Energy Object may implement fewer or more Power States than a
 particular EMAN Power State Set specifies.  In that case, the Energy
 Object implementation can determine its own mapping to the predefined
 EMAN Power States within the EMAN Power State Set.
 There are twelve EMAN Power States that expand on [IEEE1621].  The
 expanded list of Power States is derived from [CISCO-EW] and is
 divided into six operational states and six non-operational states.

Parello, et al. Informational [Page 22] RFC 7326 EMAN Framework September 2014

 The lowest non-operational state is 0, and the highest is 5.  Each
 non-operational state corresponds to an [ACPI] Global and System
 state between G3 (hard-off) and G1 (sleeping).  Each operational
 state represents a performance state and may be mapped to [ACPI]
 states P0 (maximum performance power) through P5 (minimum performance
 and minimum power).
 In each of the non-operational states (from mechoff(0) to ready(5)),
 the Power State preceding it is expected to have a lower Power value
 and a longer delay in returning to an operational state:
    mechoff(0): An off state where no Energy Object features are
       available.  The Energy Object is unavailable.  No energy is
       being consumed, and the power connector can be removed.
    softoff(1): Similar to mechoff(0), but some components remain
       powered or receive trace power so that the Energy Object can be
       awakened from its off state.  In softoff(1), no context is
       saved, and the device typically requires a complete boot when
       awakened.
    hibernate(2): No Energy Object features are available.  The Energy
       Object may be awakened without requiring a complete boot, but
       the time for availability is longer than sleep(3).  An example
       for state hibernate(2) is a save-to-disk state where DRAM
       context is not maintained.  Typically, energy consumption is
       zero or close to zero.
    sleep(3): No Energy Object features are available, except for
       out-of-band management, such as wake-up mechanisms.  The time
       for availability is longer than standby(4).  An example for
       state sleep(3) is a save-to-RAM state, where DRAM context is
       maintained.  Typically, energy consumption is close to zero.
    standby(4): No Energy Object features are available, except for
       out-of-band management, such as wake-up mechanisms.  This mode
       is analogous to cold-standby.  The time for availability is
       longer than ready(5).  For example, processor context may not
       be maintained.  Typically, energy consumption is close to zero.
    ready(5): No Energy Object features are available, except for
       out-of-band management, such as wake-up mechanisms.  This mode
       is analogous to hot-standby.  The Energy Object can be quickly
       transitioned into an operational state.  For example,
       processors are not executing, but processor context is
       maintained.

Parello, et al. Informational [Page 23] RFC 7326 EMAN Framework September 2014

    lowMinus(6): Indicates that some Energy Object features may not be
       available and the Energy Object has taken measures or selected
       options to use less energy than low(7).
    low(7): Indicates that some Energy Object features may not be
       available and the Energy Object has taken measures or selected
       options to use less energy than mediumMinus(8).
    mediumMinus(8): Indicates that all Energy Object features are
       available but the Energy Object has taken measures or selected
       options to use less energy than medium(9).
    medium(9): Indicates that all Energy Object features are available
       but the Energy Object has taken measures or selected options to
       use less energy than highMinus(10).
    highMinus(10): Indicates that all Energy Object features are
       available and the Energy Object has taken measures or selected
       options to use less energy than high(11).
    high(11): Indicates that all Energy Object features are available
       and the Energy Object may use the maximum energy as indicated
       by the Nameplate Power.

6.5.5. Power State Sets Comparison

 A comparison of Power States from different Power State Sets can be
 seen in the following tables:
    Non-operational states:
    IEEE1621  DMTF           ACPI         EMAN
    --------------------------------------------------
    off       Off-Hard       G3/S5        mechoff(0)
    off       Off-Soft       G2/S5        softoff(1)
    off       Hibernate      G1/S4        hibernate(2)
    sleep     Sleep-Deep     G1/S3        sleep(3)
    sleep     Sleep-Light    G1/S2        standby(4)
    sleep     Sleep-Light    G1/S1        ready(5)

Parello, et al. Informational [Page 24] RFC 7326 EMAN Framework September 2014

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

6.6. Relationships

 The Energy Object (Class) contains a set of Relationship (Class)
 attributes to model the relationships between devices and components.
 Two Energy Objects can establish an Energy Object Relationship to
 model the deployment topology with respect to Energy Management.
 Relationships are modeled with a Relationship (Class) that contains
 the UUID of the other participant in the relationship and a name that
 describes the type of relationship [CHEN].  The types of
 relationships are Power Source, Metering, and Aggregations.
 o  A Power Source Relationship is a relationship where one Energy
    Object provides power to one or more Energy Objects.  The Power
    Source Relationship gives a view of the physical wiring topology
    -- for example, a data center server receiving power from two
    specific Power Interfaces from two different PDUs.
    Note: A Power Source Relationship may or may not change as the
    direction of power changes between two Energy Objects.  The
    relationship may remain to indicate that the change of power
    direction was unintended or an error condition.
 o  A Metering Relationship is a relationship where one Energy Object
    measures power, energy, demand, or Power Attributes of one or more
    other Energy Objects.  The Metering Relationship gives the view of
    the Metering topology.  Physical meters can be placed anywhere in
    a power distribution tree.  For example, utility meters monitor
    and report accumulated power consumption of the entire building.
    Logically, the Metering topology overlaps with the wiring
    topology, as meters are connected to the wiring topology.  A
    typical example is meters that clamp onto the existing wiring.

Parello, et al. Informational [Page 25] RFC 7326 EMAN Framework September 2014

 o  An Aggregation Relationship is a relationship where one Energy
    Object aggregates Energy Management information of one or more
    other Energy Objects.  The Aggregation Relationship gives a model
    of devices that may aggregate (sum, average, etc.) values for
    other devices.  The Aggregation Relationship is slightly different
    compared to the other relationships, as this refers more to a
    management function.
 In some situations, it is not possible to discover the Energy Object
 Relationships, and an EnMS or administrator must set them.  Given
 that relationships can be assigned manually, the following sections
 describe guidelines for use.

6.6.1. Relationship Conventions and Guidelines

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

6.6.2. Guidelines: Power Source

 Power Source Relationships are intended to identify the connections
 between Power Interfaces.  This is analogous to a Layer 2 connection
 in networking devices (a "one-hop connection").
 The preferred modeling would be for Power Interfaces to participate
 in Power Source Relationships.  In some cases, Energy Objects may not
 have the capability to model Power Interfaces.  Therefore, a Power
 Source Relationship can be established between two Energy Objects or
 two non-connected Power Interfaces.
 Strictly speaking, while components and Power Interfaces on the same
 Device do provide or receive energy from each other, the Power Source
 Relationship is intended to show energy transfer between Devices.
 Therefore, the relationship is implied when on the same Device.
 An Energy Object SHOULD NOT establish a Power Source Relationship
 with a component.
 o  A Power Source Relationship SHOULD be established with the next
    known Power Interface in the wiring topology.

Parello, et al. Informational [Page 26] RFC 7326 EMAN Framework September 2014

 o  The next known Power Interface in the wiring topology would be the
    next device implementing the framework.  In some cases, the domain
    of devices under management may include some devices that do not
    implement the framework.  In these cases, the Power Source
    Relationship can be established with the next device in the
    topology that implements the framework and logically shows the
    Power Source of the device.
 o  Transitive Power Source Relationships SHOULD NOT be established.
    For example, if Energy Object A has a Power Source Relationship
    "Poweredby" with Energy Object B, and if Energy Object B has a
    Power Source Relationship "Poweredby" with Energy Object C, then
    Energy Object A SHOULD NOT have a Power Source Relationship
    "Poweredby" with Energy Object C.

6.6.3. Guidelines: Metering Relationship

 Metering Relationships are intended to show when one device acting as
 a meter is measuring the power or energy at a point in a power
 distribution system.  Since one point of a power distribution system
 may cover many devices within a wiring topology, this relationship
 type can be seen as a set.
 Some devices may include hardware that can measure power for
 components, outlets, or the entire device.  For example, some PDUs
 may have the ability to measure power for each outlet and are
 commonly referred to as metered-by-outlet.  Others may be able to
 control power at each power outlet but can only measure power at the
 power inlet -- commonly referred to as metered-by-device.
 While the Metering Relationship could be used to represent a device
 as metered-by-outlet or metered-by-device, the Metering Relationship
 SHOULD be used to model the relationship between a meter and all
 devices covered by the meter downstream in the power distribution
 system.
 In general:
 o  A Metering Relationship MAY be established with any other Energy
    Object, component, or Power Interface.
 o  Transitive Metering Relationships MAY be used.
 o  When there is a series of meters for one Energy Object, the Energy
    Object MAY establish a Metering Relationship with one or more of
    the meters.

Parello, et al. Informational [Page 27] RFC 7326 EMAN Framework September 2014

6.6.4. Guidelines: Aggregation

 Aggregation Relationships are intended to identify when one device is
 used to accumulate values from other devices.  Typically, this is for
 energy or power values among devices and not for components or Power
 Interfaces on the same device.
 The intent of Aggregation Relationships is to indicate when one
 device is providing aggregate values for a set of other devices when
 it is not obvious from the power source or simple containment within
 a device.
 Establishing Aggregation Relationships within the same device would
 make modeling more complex, and the aggregated values can be implied
 from the use of power inlets, outlet, and Energy Object values on the
 same device.
 Since an EnMS is naturally a point of Aggregation, it is not
 necessary to model Aggregation for Energy Management Systems.
 The Aggregation Relationship is intended for power and energy.  It
 MAY be used for Aggregation of other values from the information
 model, but the rules and logical ability to aggregate each attribute
 are out of scope for this document.
 In general:
 o  A Device SHOULD NOT establish an Aggregation Relationship with
    components contained on the same device.
 o  A Device SHOULD NOT establish an Aggregation Relationship with the
    Power Interfaces contained on the same device.
 o  A Device SHOULD NOT establish an Aggregation Relationship with an
    EnMS.
 o  Aggregators SHOULD log or provide notification in the case of
    errors or missing values while performing Aggregation.

Parello, et al. Informational [Page 28] RFC 7326 EMAN Framework September 2014

6.6.5. Energy Object Relationship Extensions

 This framework for Energy Management is based on three relationship
 types: Aggregation, Metering, and Power Source.
 This framework is defined with possible future extension of new
 Energy Object Relationships in mind.
 For example:
 o  Some Devices that may not be IP connected could be modeled with a
    proxy relationship to an Energy Object within the domain.  This
    type of proxy relationship is left for further development.
 o  A Power Distribution Unit (PDU) that allows devices and components
    like outlets to be "ganged" together as a logical entity for
    simplified management purposes could be modeled with an extension
    called a "gang relationship", whose semantics would specify the
    Energy Objects' grouping.

7. Energy Management Information Model

 This section presents an information model expression of the concepts
 in this framework as a reference for implementers.  The information
 model is implemented as MIB modules in the different related IETF
 EMAN documents.  However, other programming structures with different
 data models could be used as well.
 Data modeling specifications of this information model may, where
 needed, specify which attributes are required or optional.
 Syntax
    Unified Modeling
    Language (UML)
    Construct
    [ISO-IEC-19501-2005]  Equivalent Notation
    --------------------  ----------------------------------
    Notes                 // Notes
    Class
       (Generalization)   CLASS name {member..}
    Subclass
       (Specialization)   CLASS subclass
                               EXTENDS superclass {member..}
    Class Member
       (Attribute)        attribute : type

Parello, et al. Informational [Page 29] RFC 7326 EMAN Framework September 2014

 Model
    CLASS EnergyObject {
          // identification / classification
          index        : int
          name         : string
          identifier   : uuid
          alternatekey : string
          // context
          domainName      : string
          role            : string
          keywords [0..n] : string
          importance      : int
          // relationship
          relationships [0..n] : Relationship
          // measurements
          nameplate    : Nameplate
          power        : PowerMeasurement
          energy       : EnergyMeasurement
          demand       : DemandMeasurement
          // control
          powerControl [0..n] : PowerStateSet
    }
    CLASS PowerInterface EXTENDS EnergyObject {
          eoIfType : enum { inlet, outlet, both }
    }
    CLASS Device EXTENDS EnergyObject {
          eocategory             : enum { producer, consumer, meter,
    distributor, store }
          powerInterfaces [0..n] : PowerInterface
          components [0..n]      : Component
    }
    CLASS Component EXTENDS EnergyObject {
          eocategory             : enum { producer, consumer, meter,
    distributor, store }
          powerInterfaces [0..n] : PowerInterface
          components [0..n]      : Component
    }

Parello, et al. Informational [Page 30] RFC 7326 EMAN Framework September 2014

    CLASS Nameplate {
          nominalPower : PowerMeasurement
          details      : URI
    }
    CLASS Relationship {
          relationshipType    : enum { meters, meteredby, powers,
    poweredby, aggregates, aggregatedby }
          relationshipObject  : uuid
    }
    CLASS Measurement {
          multiplier : enum { -24..24 }
          caliber    : enum { actual, estimated, static }
          accuracy   : enum { 0..10000 } // hundreds of percent
    }
    CLASS PowerMeasurement EXTENDS Measurement {
          value          : long
          units          : "W"
          powerAttribute : PowerAttribute
    }
    CLASS EnergyMeasurement EXTENDS Measurement {
          startTime : time
          units     : "kWh"
          provided  : long
          used      : long
          produced  : long
          stored    : long
    }
    CLASS TimedMeasurement EXTENDS Measurement {
          startTime  : timestamp
          value      : Measurement
          maximum    : Measurement
    }
    CLASS TimeInterval {
          value      : long
          units      : enum { seconds, milliseconds,... }
    }

Parello, et al. Informational [Page 31] RFC 7326 EMAN Framework September 2014

    CLASS DemandMeasurement EXTENDS Measurement {
          intervalLength      : TimeInterval
          intervals           : long
          intervalMode        : enum { periodic, sliding, total }
          intervalWindow      : TimeInterval
          sampleRate          : TimeInterval
          status              : enum { active, inactive }
          measurements [0..n] : TimedMeasurements
    }
    CLASS PowerStateSet {
          powerSetIdentifier : int
          name               : string
          powerStates [0..n] : PowerState
          operState          : int
          adminState         : int
          reason             : string
          configuredTime     : timestamp
    }
    CLASS PowerState {
          powerStateIdentifier : int
          name                 : string
          cardinality          : int
          maximumPower         : PowerMeasurement
          totalTimeInState     : time
          entryCount           : long
    }
    CLASS PowerAttribute {
          acQuality  : ACQuality
    }
    CLASS ACQuality {
          acConfiguration    : enum { SNGL, DEL, WYE }
          avgVoltage         : long
          avgCurrent         : long
          thdCurrent         : long
          frequency          : long
          unitMultiplier     : int
          accuracy           : int
          totalActivePower   : long
          totalReactivePower : long
          totalApparentPower : long
          totalPowerFactor   : long
    }

Parello, et al. Informational [Page 32] RFC 7326 EMAN Framework September 2014

    CLASS DelPhase EXTENDS ACQuality {
          phaseToNextPhaseVoltage : long
          thdVoltage              : long
    }
    CLASS WYEPhase EXTENDS ACQuality {
          phaseToNeutralVoltage : long
          thdCurrent            : long
          thdVoltage            : long
          avgCurrent            : long
    }

8. Modeling Relationships between Devices

 In this section, we give examples of how to use the EMAN information
 model to model physical topologies.  Where applicable, we show how
 the framework can be applied when devices can be modeled with Power
 Interfaces.  We also show how the framework can be applied when
 devices cannot be modeled with Power Interfaces but only monitored or
 controlled as a whole.  For instance, a PDU may only be able to
 measure power and energy for the entire unit without the ability to
 distinguish among the inlets or outlets.

8.1. Power Source Relationship

 The Power Source Relationship is used to model the interconnections
 between devices, components, and/or Power Interfaces to indicate the
 source of energy for a device.
 In the following examples, we show variations on modeling the
 reference topologies using relationships.
 Given for all cases:
 Device W: A computer with one power supply.  Power Interface 1 is an
    inlet for Device W.
 Device X: A computer with two power supplies.  Power Interface 1 and
    Power Interface 2 are both inlets for Device X.
 Device Y: A PDU with multiple Power Interfaces numbered 0..10.  Power
    Interface 0 is an inlet, and Power Interfaces 1..10 are outlets.
 Device Z: A PDU with multiple Power Interfaces numbered 0..10.  Power
    Interface 0 is an inlet, and Power Interfaces 1..10 are outlets.

Parello, et al. Informational [Page 33] RFC 7326 EMAN Framework September 2014

 Case 1: Simple Device with one Source
    Physical Topology:
       o  Device W inlet 1 is plugged into Device Y outlet 8.
    With Power Interfaces:
       o  Device W has an Energy Object representing the computer
          itself as well as one Power Interface defined as an inlet.
       o  Device Y would have an Energy Object representing the PDU
          itself (the Device), with Power Interface 0 defined as an
          inlet and Power Interfaces 1..10 defined as outlets.
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device W inlet 1 is powered by Device Y outlet 8.
          +-------+------+       poweredBy +------+----------+
          | PDU Y | PI 8 |-----------------| PI 1 | Device W |
          +-------+------+ powers          +------+----------+
    Without Power Interfaces:
       o  Device W has an Energy Object representing the computer.
       o  Device Y would have an Energy Object representing the PDU.
       The devices would have a Power Source Relationship such that:
       Device W is powered by Device Y.
          +----------+       poweredBy +------------+
          |  PDU Y   |-----------------|  Device W  |
          +----------+ powers          +------------+

Parello, et al. Informational [Page 34] RFC 7326 EMAN Framework September 2014

 Case 2: Multiple Inlets
    Physical Topology:
    o  Device X inlet 1 is plugged into Device Y outlet 8.
    o  Device X inlet 2 is plugged into Device Y outlet 9.
    With Power Interfaces:
       o  Device X has an Energy Object representing the computer
          itself.  It contains two Power Interfaces defined as inlets.
       o  Device Y would have an Energy Object representing the PDU
          itself (the Device), with Power Interface 0 defined as an
          inlet and Power Interfaces 1..10 defined as outlets.
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device X inlet 1 is powered by Device Y outlet 8.
       Device X inlet 2 is powered by Device Y outlet 9.
          +-------+------+        poweredBy+------+----------+
          |       | PI 8 |-----------------| PI 1 |          |
          |       |      |powers           |      |          |
          | PDU Y +------+        poweredBy+------+ Device X |
          |       | PI 9 |-----------------| PI 2 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+----------+
    Without Power Interfaces:
       o  Device X has an Energy Object representing the computer.
          Device Y has an Energy Object representing the PDU.
       The devices would have a Power Source Relationship such that:
       Device X is powered by Device Y.
          +----------+       poweredBy +------------+
          |  PDU Y   |-----------------|  Device X  |
          +----------+ powers          +------------+

Parello, et al. Informational [Page 35] RFC 7326 EMAN Framework September 2014

 Case 3: Multiple Sources
    Physical Topology:
    o  Device X inlet 1 is plugged into Device Y outlet 8.
    o  Device X inlet 2 is plugged into Device Z outlet 9.
    With Power Interfaces:
       o  Device X has an Energy Object representing the computer
          itself.  It contains two Power Interfaces defined as inlets.
       o  Device Y would have an Energy Object representing the PDU
          itself (the Device), with Power Interface 0 defined as an
          inlet and Power Interfaces 1..10 defined as outlets.
       o  Device Z would have an Energy Object representing the PDU
          itself (the Device), with Power Interface 0 defined as an
          inlet and Power Interfaces 1..10 defined as outlets.
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device X inlet 1 is powered by Device Y outlet 8.
       Device X inlet 2 is powered by Device Z outlet 9.
          +-------+------+        poweredBy+------+----------+
          | PDU Y | PI 8 |-----------------| PI 1 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+          |
                                                  | Device X |
          +-------+------+        poweredBy+------+          |
          | PDU Z | PI 9 |-----------------| PI 2 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+----------+
    Without Power Interfaces:
       o  Device X has an Energy Object representing the computer.
          Devices Y and Z would both have respective Energy Objects
          representing each entire PDU.

Parello, et al. Informational [Page 36] RFC 7326 EMAN Framework September 2014

       The devices would have a Power Source Relationship such that:
       Device X is powered by Device Y and powered by Device Z.
          +----------+           poweredBy +------------+
          |  PDU Y   |---------------------|  Device X  |
          +----------+ powers              +------------+
          +----------+           poweredBy +------------+
          |  PDU Z   |---------------------|  Device X  |
          +----------+ powers              +------------+

8.2. Metering Relationship

 A meter in a power distribution system can logically measure the
 power or energy for all devices downstream from the meter in the
 power distribution system.  As such, a Metering Relationship can be
 seen as a relationship between a meter and all of the devices
 downstream from the meter.
 We define in this case a Metering Relationship between a meter and
 devices downstream from the meter.
   +-----+---+    meteredBy +--------+   poweredBy +-------+
   |Meter| PI|--------------| switch |-------------| phone |
   +-----+---+ meters       +--------+ powers      +-------+
           |                                           |
           |                                 meteredBy |
           +-------------------------------------------+
            meters
 In cases where the Power Source topology cannot be discovered or
 derived from the information available in the Energy Management
 Domain, the Metering topology can be used to relate the upstream
 meter to the downstream devices in the absence of specific Power
 Source Relationships.

Parello, et al. Informational [Page 37] RFC 7326 EMAN Framework September 2014

 A Metering Relationship can occur between devices that are not
 directly connected, as shown in the following figure:
                        +---------------+
                        |   Device 1    |
                        +---------------+
                        |      PI       |
                        +---------------+
                                |
                        +---------------+
                        |     Meter     |
                        +---------------+
                                .
                                .
                                .
               meters        meters           meters
         +----------+   +----------+   +-----------+
         | Device A |   | Device B |   | Device C  |
         +----------+   +----------+   +-----------+
 An analogy to communications networks would be modeling connections
 between servers (meters) and clients (devices) when the complete
 Layer 2 topology between the servers and clients is not known.

8.3. Aggregation Relationship

 Some devices can act as Aggregation points for other devices.  For
 example, a PDU controller device may contain the summation of power
 and energy readings for many PDU devices.  The PDU controller will
 have aggregate values for power and energy for a group of PDU
 devices.
 This Aggregation is independent of the physical power or
 communication topology.
 The functions that the Aggregation point may perform include the
 calculation of values such as average, count, maximum, median,
 minimum, or the listing (collection) of the Aggregation values, etc.
 Based on IETF experience gained on Aggregations [RFC7015], the
 Aggregation function in the EMAN framework is limited to the
 summation.
 When Aggregation occurs across a set of entities, values to be
 aggregated may be missing for some entities.  The EMAN framework does
 not specify how these should be treated, as different implementations
 may have good reason to take different approaches.  One common
 treatment is to define the Aggregation as missing if any of the

Parello, et al. Informational [Page 38] RFC 7326 EMAN Framework September 2014

 constituent elements are missing (useful to be most precise).
 Another is to treat the missing value as zero (useful to have
 continuous data streams).
 The specifications of Aggregation functions are out of the scope of
 the EMAN framework but must be clearly specified by the equipment
 vendor.

9. Relationship to Other Standards

 This Energy Management framework uses, as much as possible, existing
 standards, especially with respect to information modeling and data
 modeling [RFC3444].
 The data model for power- and energy-related objects is based on
 [IEC61850].
 Specific examples include:
 o  The scaling factor, which represents Energy Object usage
    magnitude, conforms to the [IEC61850] definition of unit
    multiplier for the SI (System International) units of measure.
 o  The electrical characteristics are 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:
  1. IEC 62053-22 and 60044-1 classes 0.1, 0.2, 0.5, 1, and 3.
  1. ANSI C12.20 classes 0.2 and 0.5.
 o  The electrical characteristics and quality adhere closely to the
      [IEC61850-7-4] standard for describing AC measurements.
 o  The Power State definitions are based on the DMTF Power State
      Profile and ACPI models, with operational state extensions.

10. 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 will have negative effects on
 network capabilities.  Event logs for audit purposes on configuration
 and other changes should be generated according to current

Parello, et al. Informational [Page 39] RFC 7326 EMAN Framework September 2014

 authorization, audit, and accounting principles to facilitate
 investigations (compromise or benign misconfigurations) or any
 reporting requirements.
 The information and control capabilities specified in this framework
 could be exploited, to the detriment of a site or deployment.
 Implementers of the framework SHOULD examine and mitigate security
 threats with respect to these new capabilities.
 "User-based Security Model (USM) for version 3 of the Simple Network
 Management Protocol (SNMPv3)" [RFC3414] presents a good description
 of threats and mitigations for SNMPv3 that can be used as a guide for
 implementations of this framework using other protocols.

10.1. Security Considerations for SNMP

 Readable objects in MIB modules (i.e., objects with a MAX-ACCESS
 other than not-accessible) may be considered sensitive or vulnerable
 in some network environments.  It is important to control GET and/or
 NOTIFY access to these objects and possibly to encrypt the values of
 these objects when sending them over the network via SNMP.
 The support for SET operations in a non-secure environment without
 proper protection can have a negative effect on network operations.
 For example:
 o  Unauthorized changes to the Energy Management Domain or business
    context of a device will result in misreporting or interruption of
    power.
 o  Unauthorized changes to a Power State will disrupt the power
    settings of the different devices and therefore the state of
    functionality of the respective devices.
 o  Unauthorized changes to the demand history will disrupt proper
    accounting of energy usage.
 With respect to data transport, SNMP versions prior to SNMPv3 did not
 include adequate security.  Even if the network itself is secure (for
 example, by using IPsec), there is still no secure control over who
 on the secure network is allowed to access and GET/SET
 (read/change/create/delete) the objects in these MIB modules.
 It is recommended that implementers consider the security features as
 provided by the SNMPv3 framework (see [RFC3411]), including full
 support for the SNMPv3 cryptographic mechanisms (for authentication
 and confidentiality).

Parello, et al. Informational [Page 40] RFC 7326 EMAN Framework September 2014

 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.

11. IANA Considerations

11.1. IANA Registration of New Power State Sets

 This document specifies an initial set of Power State Sets.  The list
 of these Power State Sets with their numeric identifiers is given in
 Section 6.  IANA maintains the lists of Power State Sets.
 New assignments for a Power State Set are administered by IANA
 through Expert Review [RFC5226], i.e., review by one of a group of
 experts designated by an IETF Area Director.  The group of experts
 must check the requested state for completeness and accuracy of the
 description.  A pure vendor-specific implementation of a Power State
 Set shall not be adopted, since it would lead to proliferation of
 Power State Sets.
 Power States in a Power State Set are limited to 255 distinct values.
 A new Power State Set must be assigned the next available numeric
 identifier that is a multiple of 256.

11.1.1. IANA Registration of the IEEE1621 Power State Set

 This document specifies a set of values for the IEEE1621 Power State
 Set [IEEE1621].  The list of these values with their identifiers is
 given in Section 6.5.2.  IANA created a new registry for IEEE1621
 Power State Set identifiers and filled it with the initial list of
 identifiers.
 New assignments (or, potentially, deprecation) for the IEEE1621 Power
 State Set are administered by IANA through Expert Review [RFC5226].

11.1.2. IANA Registration of the DMTF Power State Set

 This document specifies a set of values for the DMTF Power State Set
 [DMTF].  The list of these values with their identifiers is given in
 Section 6.5.3.  IANA has created a new registry for DMTF Power State
 Set identifiers and filled it with the initial list of identifiers.
 New assignments (or, potentially, deprecation) for the DMTF Power
 State Set are administered by IANA through Expert Review [RFC5226].

Parello, et al. Informational [Page 41] RFC 7326 EMAN Framework September 2014

 The group of experts must check for conformance with the DMTF
 standard [DMTF] in addition to checking for completeness and accuracy
 of the description.

11.1.3. IANA Registration of the EMAN Power State Set

 This document specifies a set of values for the EMAN Power State Set.
 The list of these values with their identifiers is given in
 Section 6.5.4.  IANA has created a new registry for EMAN Power State
 Set identifiers and filled it with the initial list of identifiers.
 New assignments (or, potentially, deprecation) for the EMAN Power
 State Set are administered by IANA through Expert Review [RFC5226].

11.2. Updating the Registration of Existing Power State Sets

 With the evolution of standards, over time, it may be important to
 deprecate some of the existing Power State Sets, or to add or
 deprecate some Power States within a Power State Set.
 The registrant shall post an Internet-Draft with the clear
 specification on deprecation of Power State Sets or Power States
 registered with IANA.  The deprecation or addition shall be
 administered by IANA through Expert Review [RFC5226], i.e., review by
 one of a group of experts designated by an IETF Area Director.  The
 process should also allow for a mechanism for cases where others have
 significant objections to claims regarding the deprecation of a
 registration.

Parello, et al. Informational [Page 42] RFC 7326 EMAN Framework September 2014

12. References

12.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [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.
 [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
 [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
            Information Models and Data Models", RFC 3444,
            January 2003.
 [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
            Unique IDentifier (UUID) URN Namespace", RFC 4122,
            July 2005.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
            Chandramouli, "Entity MIB (Version 4)", RFC 6933,
            May 2013.
 [RFC6988]  Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T.,
            and B. Claise, "Requirements for Energy Management",
            RFC 6988, September 2013.
 [ISO-IEC-19501-2005]
            ISO/IEC 19501:2005, Information technology, Open
            Distributed Processing -- Unified Modeling Language (UML)
            Version 1.4.2, January 2005.

Parello, et al. Informational [Page 43] RFC 7326 EMAN Framework September 2014

12.2. Informative References

 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66,
            RFC 3986, January 2005.
 [RFC7015]  Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
            for the IP Flow Information Export (IPFIX) Protocol",
            RFC 7015, September 2013.
 [ACPI]     "Advanced Configuration and Power Interface
            Specification", October 2006,
            <http://www.acpi.info/spec30b.htm>.
 [IEEE1621] "Standard for User Interface Elements in Power Control of
            Electronic Devices Employed in Office/Consumer
            Environments", IEEE 1621, December 2004.
 [NMF]      Clemm, A., "Network Management Fundamentals",
            ISBN-10: 1-58720-137-2, Cisco Press, November 2006.
 [TMN]      International Telecommunication Union, "TMN management
            functions", ITU-T Recommendation M.3400, February 2000.
 [IEEE100]  "The Authoritative Dictionary of IEEE Standards Terms",
            <http://ieeexplore.ieee.org/xpl/
            mostRecentIssue.jsp?punumber=4116785>.
 [ISO50001] "ISO 50001:2011 Energy management systems -- Requirements
            with guidance for use", June 2011, <http://www.iso.org/>.
 [IEC60050] "International Electrotechnical Vocabulary",
            <http://www.electropedia.org/iev/iev.nsf/
            welcome?openform>.
 [IEC61850] "Power Utility Automation",
            <http://www.iec.ch/smartgrid/standards/>.
 [IEC61850-7-2]
            "Abstract communication service interface (ACSI)",
            <http://www.iec.ch/smartgrid/standards/>.
 [IEC61850-7-4]
            "Compatible logical node classes and data classes",
            <http://www.iec.ch/smartgrid/standards/>.

Parello, et al. Informational [Page 44] RFC 7326 EMAN Framework September 2014

 [DMTF]     "Power State Management Profile", DMTF DSP1027
            Version 2.0.0, December 2009,
            <http://www.dmtf.org/sites/default/files/standards/
            documents/DSP1027_2.0.0.pdf>.
 [IPENERGY] Aldrich, R. and J. Parello, "IP-Enabled Energy Management:
            A Proven Strategy for Administering Energy as a Service",
            2010, Wiley Publishing.
 [X.700]    CCITT Recommendation X.700, "Management framework for Open
            Systems Interconnection (OSI) for CCITT applications",
            September 1992.
 [ASHRAE-201]
            "ASHRAE Standard Project Committee 201 (SPC 201) Facility
            Smart Grid Information Model",
            <http://spc201.ashraepcs.org>.
 [CHEN]     Chen, P., "The Entity-Relationship Model: Toward a Unified
            View of Data", ACM Transactions on Database Systems
            (TODS), March 1976.
 [CISCO-EW] Parello, J., Saville, R., and S. Kramling, "Cisco
            EnergyWise Design Guide", Cisco Validated Design (CVD),
            September 2011,
            <http://www.cisco.com/en/US/docs/solutions/
            Enterprise/Borderless_Networks/Energy_Management/
            energywisedg.html>.

13. Acknowledgments

 The authors would like to thank Michael Brown for his editorial work,
 which improved the text dramatically.  Thanks to Rolf Winter for his
 feedback, and to Bill Mielke for his feedback and very detailed
 review.  Thanks to Bruce Nordman for brainstorming, with numerous
 conference calls and discussions.  Finally, the authors would like to
 thank the EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.

Parello, et al. Informational [Page 45] RFC 7326 EMAN Framework September 2014

Appendix A. Information Model Listing

 A. EnergyObject (Class):
 r  index         Integer            An [RFC6933] entPhysicalIndex
 w  name          String             An [RFC6933] entPhysicalName
 r  identifier    uuid               An [RFC6933] entPhysicalUUID
 rw alternatekey  String             A manufacturer-defined string
                                     that can be used to identify the
                                     Energy Object
 rw domainName    String             The name of an Energy Management
                                     Domain for the Energy Object
 rw role          String             An administratively assigned name
                                     to indicate the purpose an
                                     Energy Object serves in the
                                     network
 rw keywords      String             A list of keywords or [0..n] tags
                                     that can be used to group Energy
                                     Objects for reporting or
                                     searching
 rw importance    Integer            Specifies a ranking of how
                                     important the Energy Object is
                                     (on a scale of 1 to 100) compared
                                     with other Energy Objects
 rw relationships Relationship       A list of relationships between
    [0..n]                           this Energy Object and other
                                     Energy Objects
 r  nameplate     Nameplate          The nominal PowerMeasurement of
                                     the Energy Object as specified by
                                     the device manufacturer
 r  power         PowerMeasurement   The present power measurement of
                                     the Energy Object
 r  energy        EnergyMeasurement  The present energy measurement
                                     for the Energy Object
 r  demand        DemandMeasurement  The present demand measurement
                                     for the Energy Object

Parello, et al. Informational [Page 46] RFC 7326 EMAN Framework September 2014

 r  powerControl  PowerStateSet      A list of Power States Sets the
    [0..n]                           Energy Object supports
 B. PowerInterface (Class) inherits from EnergyObject:
 r  eoIfType      Enumeration        Indicates whether the Power
                                     Interface is an inlet, outlet,
                                     or both
 C. Device (Class) inherits from EnergyObject:
 rw eocategory       Enumeration     Broadly indicates whether
                                     the Device is a producer,
                                     consumer, meter, distributor,
                                     or store of energy
 r  powerInterfaces  PowerInterface  A list of PowerInterfaces
    [0..n]                           contained in this Device
 r  components       Component       A list of components
    [0..n]                           contained in this Device
 D. Component (Class) inherits from EnergyObject:
 rw eocategory       Enumeration     Broadly indicates whether the
                                     component is a producer,
                                     consumer, meter, distributor, or
                                     store of energy
 r  powerInterfaces  PowerInterface  A list of PowerInterfaces
    [0..n]                           contained in this component
 r  components       Component       A list of components contained
    [0..n]                           in this component

Parello, et al. Informational [Page 47] RFC 7326 EMAN Framework September 2014

 E. Nameplate (Class):
 r  nominalPower     PowerMeasurement  The nominal power of the Energy
                                       as specified by the device
                                       manufacturer
 rw details          URI               An [RFC3986] URI that links to
                                       manufacturer information about
                                       the nominal power of a device
 F. Relationship (Class):
 rw relationshipType    Enumeration   A description of the
                                      relationship, indicating
                                      meters, meteredby, powers,
                                      poweredby, aggregates, or
                                      aggregatedby
 rw relationshipObject  uuid          An [RFC6933] entPhysicalUUID
                                      that indicates the other
                                      participating Energy Object in
                                      the relationship
 G. Measurement (Class):
 r  multiplier  Enumeration    The magnitude of the Measurement
                               in the range -24..24
 r  caliber     Enumeration    Specifies how the Measurement was
                               obtained -- actual, estimated, or
                               static
 r  accuracy    Enumeration    Specifies the accuracy of the
                               measurement, if applicable, as
                               0..10000, indicating hundreds of
                               percent
 H. PowerMeasurement (Class) inherits from Measurement:
 r value          Long             A measurement value of
                                   power
 r units          "W"              The units of measure for
                                   the power -- "Watts"

Parello, et al. Informational [Page 48] RFC 7326 EMAN Framework September 2014

 r powerAttribute PowerAttribute   Measurement of the electrical
                                   current -- voltage, phase, and/or
                                   frequencies for the
                                   PowerMeasurement
 I. EnergyMeasurement (Class) inherits from Measurement:
 r startTime  Time          Specifies the start time of the
                            EnergyMeasurement interval
 r units      "kWh"         The units of measure for the energy --
                            kilowatt-hours
 r provided   Long          A measurement of energy provided
 r used       Long          A measurement of energy used/consumed
 r produced   Long          A measurement of energy produced
 r stored     Long          A measurement of energy stored
 J. TimedMeasurement (Class) inherits from Measurement:
 r  startTime timestamp     A start time of a measurement
 r  value     Measurement   A measurement value
 r  maximum   Measurement   A maximum value measured since a previous
                            timestamp
 K. TimeInterval (Class):
 r  value     Long          A value of time
 r  units     Enumeration   A magnitude of time, expressed as seconds
                            with an SI prefix (milliseconds, etc.)
 L. DemandMeasurement (Class) inherits from Measurement:
 rw intervalLength  TimeInterval     The length of time over which to
                                     compute average energy
 rw intervals       Long             The number of intervals that can
                                     be measured

Parello, et al. Informational [Page 49] RFC 7326 EMAN Framework September 2014

 rw intervalMode    Enumeration      The mode of interval
                                     measurement -- periodic, sliding,
                                     or total
 rw intervalWindow  TimeInterval     The duration between the starting
                                     time of one sliding window and
                                     the next starting time
 rw sampleRate      TimeInterval     The sampling rate at which to
                                     poll power in order to compute
                                     demand
 rw status          Enumeration      A control to start or stop demand
                                     measurement -- active or inactive
 r  measurements    TimedMeasurement A collection of TimedMeasurements
    [0..n]                           to compute demand
 M. PowerStateSet (Class):
 r  powerSetIdentifier Integer       An IANA-assigned value indicating
                                     a Power State Set
 r  name               String        A Power State Set name
 r  powerStates        PowerState    A set of Power States for the
    [0..n]                           given identifier
 rw operState          Integer       The current operational Power
                                     State
 rw adminState         Integer       The desired Power State
 rw reason             String        Describes the reason
                                     for the adminState
 r  configuredTime     timestamp     Indicates the time of
                                     the desired Power State
 N. PowerState (Class):
 r  powerStateIdentifier Integer           An IANA-assigned value
                                           indicating a Power State
 r  name                 String            A name for the Power State

Parello, et al. Informational [Page 50] RFC 7326 EMAN Framework September 2014

 r  cardinality          Integer           A value indicating an
                                           ordering of the Power State
 rw maximumPower         PowerMeasurement  Indicates the maximum power
                                           for the Energy Object at
                                           this Power State
 r  totalTimeInState     Time              Indicates the total time
                                           an Energy Object has been
                                           in this Power State since
                                           the last reset
 r  entryCount           Long              Indicates the number of
                                           times the Energy Object
                                           has entered or changed to
                                           this state
 O. PowerAttribute (Class):
 r acQuality          ACQuality    Describes AC Power Attributes for
                                   a Measurement
 P. ACQuality (Class):
 r acConfiguration    Enumeration  Describes the physical
                                   configuration of alternating
                                   current as single phase (SNGL),
                                   three-phase delta (DEL), or
                                   three-phase Y (WYE)
 r avgVoltage         Long         The average of the voltage measured
                                   over an integral number of AC
                                   cycles [IEC61850-7-4] 'Vol'
 r avgCurrent         Long         The current per phase
                                   [IEC61850-7-4] 'Amp'
 r thdCurrent         Long         A calculated value for the current
                                   Total Harmonic Distortion (THD).
                                   The method of calculation is not
                                   specified [IEC61850-7-4] 'ThdAmp'
 r frequency          Long         Basic frequency of the AC circuit
                                   [IEC61850-7-4] 'Hz'
 r unitMultiplier     Integer      Magnitude of watts for the usage
                                   value in this instance

Parello, et al. Informational [Page 51] RFC 7326 EMAN Framework September 2014

 r accuracy           Integer      Percentage value in 100ths
                                   of a percent, representing the
                                   presumed accuracy of active,
                                   reactive, and apparent power
                                   in this instance
 r totalActivePower   Long         A measured value of the actual
                                   power delivered to or consumed by
                                   the load [IEC61850-7-4] 'TotW'
 r totalReactivePower Long         A measured value of the reactive
                                   portion of the apparent power
                                   [IEC61850-7-4] 'TotVAr'
 r totalApparentPower Long         A measured value of the voltage
                                   and current, which determines the
                                   apparent power as the vector sum of
                                   real and reactive power
                                   [IEC61850-7-4] 'TotVA'
 r totalPowerFactor   Long         A measured value of the ratio of
                                   the real power flowing to the load
                                   versus the apparent power
                                   [IEC61850-7-4] 'TotPF'
 Q. DelPhase (Class) inherits from ACQuality:
 r phaseToNext      Long      A measured value of phase to
    PhaseVoltage              next phase voltages where the
                              next phase is [IEC61850-7-4]
                              'PPV'
 r thdVoltage       Long      A calculated value for the
                              voltage Total Harmonic Distortion
                              (THD) for phase to next phase.
                              The method of calculation is not
                              specified [IEC61850-7-4] 'ThdPPV'

Parello, et al. Informational [Page 52] RFC 7326 EMAN Framework September 2014

 R. WYEPhase (Class) inherits from ACQuality:
 r phaseToNeutral  Long   A measured value of phase to
    Voltage               neutral voltage [IEC61850-7-4]
                          'PhV'
 r thdCurrent      Long   A calculated value for the current
                          Total Harmonic Distortion (THD).
                          The method of calculation is not
                          specified [IEC61850-7-4] 'ThdA'
 r thdVoltage      Long   A calculated value of the voltage
                          THD for phase to neutral
                          [IEC61850-7-4] 'ThdPhV'
 r avgCurrent      Long   A measured value of phase currents
                          [IEC61850-7-4] 'A'

Parello, et al. Informational [Page 53] RFC 7326 EMAN Framework September 2014

Authors' Addresses

 John Parello
 Cisco Systems, Inc.
 3550 Cisco Way
 San Jose, CA  95134
 US
 Phone: +1 408 525 2339
 EMail: jparello@cisco.com
 Benoit Claise
 Cisco Systems, Inc.
 De Kleetlaan 6a b1
 Diegem 1813
 BE
 Phone: +32 2 704 5622
 EMail: bclaise@cisco.com
 Brad Schoening
 44 Rivers Edge Drive
 Little Silver, NJ  07739
 US
 EMail: brad.schoening@verizon.net
 Juergen Quittek
 NEC Europe Ltd.
 Network Laboratories
 Kurfuersten-Anlage 36
 69115 Heidelberg
 Germany
 Phone: +49 6221 90511 15
 EMail: quittek@netlab.nec.de

Parello, et al. Informational [Page 54]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7326.txt · Last modified: 2014/09/05 00:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki