RFC 7603

Energy Management (EMAN) Applicability Statement

📅 published August 2015, from ietf

RFC 7603: Energy Management (EMAN) Applicability Statement 🔌

okay bestie, this one is giving energy-saving networks 💅 Here's the title block tea:

  • Authors: B. Schoening (Independent Consultant), M. Chandramouli (Cisco Systems, Inc.), and B. Nordman (Lawrence Berkeley National Lab) 🎀
  • Category: Standards Track
  • Date: August 2015
  • Request for Comments number: 7603, with ISSN 2070-1721
  • Obsoletes / updates: the title block doesn't list anything this one obsoletes or updates, so it's flying solo 🦋

Abstract 🌸

okay so the whole goal of Energy Management (EMAN) is to give networked devices an energy management framework 🔋 This doc shows how the EMAN information model works across a bunch of scenarios and target devices. These use cases help figure out what the framework and MIBs actually need. It also explains how EMAN relates to other energy monitoring standards and architectures 🧚

Status of This Memo 📜

this is an Internet Standards Track document ✨

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7603.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, bestie, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents 🗂️

   1. Introduction ................................................. 3
     1.1. Energy Management Overview ............................... 4
     1.2. EMAN Document Overview ................................... 4
     1.3. Energy Measurement ....................................... 5
     1.4. Energy Management ........................................ 5
     1.5. EMAN Framework Application ............................... 6
   2. Scenarios and Target Devices ................................. 6
     2.1. Network Infrastructure Energy Objects .................... 6
     2.2. Devices Powered and Connected by a Network Device ........ 7
     2.3. Devices Connected to a Network ........................... 8
     2.4. Power Meters ............................................. 9
     2.5. Mid-level Managers ...................................... 10
     2.6. Non-residential Building System Gateways ................ 10
     2.7. Home Energy Gateways .................................... 11
     2.8. Data Center Devices ..................................... 12
     2.9. Energy Storage Devices .................................. 13
     2.10. Industrial Automation Networks ......................... 14
     2.11. Printers ............................................... 14
     2.12. Demand Response ........................................ 15
   3. Use Case Patterns ........................................... 16
     3.1. Metering ................................................ 16
     3.2. Metering and Control .................................... 16
     3.3. Power Supply, Metering and Control ...................... 16
     3.4. Multiple Power Sources .................................. 16
   4. Relationship of EMAN to Other Standards ..................... 17
     4.1. Data Model and Reporting ................................ 17
           4.1.1. IEC - CIM........................................ 17
           4.1.2. DMTF............................................. 17
           4.1.3. ODVA............................................. 19
           4.1.4. Ecma SDC......................................... 19
           4.1.5. PWG.............................................. 19
           4.1.6. ASHRAE........................................... 20
           4.1.7. ANSI/CEA......................................... 21
           4.1.8. ZigBee........................................... 21
     4.2. Measurement ............................................. 22
           4.2.1. ANSI C12......................................... 22
           4.2.2. IEC 62301........................................ 22
     4.3. Other ................................................... 22
           4.3.1. ISO.............................................. 22
           4.3.2. Energy Star...................................... 23
           4.3.3. Smart Grid....................................... 23
   5. Limitations ................................................. 24
   6. Security Considerations ..................................... 24
   7. References .................................................. 25
     7.1. Normative References .................................... 25
     7.2. Informative References .................................. 25
   Acknowledgements ............................................... 27
   Authors' Addresses ............................................. 28

1. Introduction ✨

The whole focus of the Energy Management (EMAN) framework is energy monitoring and management of energy objects [RFC7326] 🔋 The devices in scope are network equipment and its components, plus devices connected directly or indirectly to the network. EMAN lets you monitor a mix of heterogeneous devices so they can report their energy consumption and, if permissible, get controlled. There are lots of situations where this matters, especially since limiting consumption of finite energy resources and cutting operational expenses are both a bigger deal now 💅

The EMAN framework [RFC7326] describes how energy information can be retrieved from IP-enabled devices using Simple Network Management Protocol (SNMP), specifically Management Information Base (MIB) modules for SNMP 🧚

This document describes typical applications of the EMAN framework, plus its opportunities and limitations. It also reviews other standards that are kinda similar to EMAN in part but address different domains, and explains how they relate to the EMAN framework 📚

The rest of the document is organized like this. Section 2 has a list of use cases or network scenarios that EMAN addresses. Section 3 abstracts those use case scenarios into distinct patterns. Section 4 covers other standards related to and applicable to EMAN 🌈

1.1. Energy Management Overview

EMAN is all about the electrical energy consumed by devices connected to a network 🔌 The first step toward better energy efficiency in networks, and in the devices attached to them, is letting energy objects report their energy usage over time. The EMAN framework tackles this with an information model for electrical equipment: energy object identification, energy object context, power measurement, and power characteristics 💜

The EMAN framework defines SNMP MIB modules based on that information model. When an energy object implements these SNMP MIB modules, it can report its energy consumption according to the information model. The MIB documents specify SNMP MIB modules based on the information model, but it's equally possible to use other mechanisms, such as a YANG module, Network Conference Protocol (NETCONF), and so on 🎀

It's important to tell apart energy objects that can only report their own energy usage from devices that can also collect and aggregate the energy usage of other energy objects 🫶

1.2. EMAN Document Overview

The EMAN work is made up of the following Standards Track and Informational documents in the area of energy management 📚

  • Applicability Statement (this document)
  • Requirements [RFC6988]: This document presents requirements of energy management and the scope of the devices considered.
  • Framework [RFC7326]: This document defines a framework for providing energy management for devices within or connected to communication networks, and lists the definitions for the common terms used in these documents.
  • Energy Object Context MIB [RFC7461]: This document defines a MIB module that characterizes a device's identity, context, and relationships to other entities.
  • Monitoring and Control MIB [RFC7460]: This document defines a MIB module for monitoring the power and energy consumption of a device.
    • The MIB module contains an optional module for metrics associated with power characteristics.
  • Battery MIB [RFC7577]: This document defines a MIB module for monitoring characteristics of an internal battery 🔋

1.3. Energy Measurement

it's getting super common for today's smart devices to measure and report their own energy consumption 💅 Intelligent power strips and some Power over Ethernet (PoE) switches can meter the consumption of connected devices too. The catch is that when this stuff gets managed and reported through proprietary means, it's hard to see at the enterprise level 🙈

The big goal of the EMAN information model is enabling reporting and management inside a standard framework that works for a wide variety of end devices, meters, and proxies. That lets a management system know who's consuming what, when, and how, by using existing networks across lots of different equipment in a unified and consistent way ✨

Energy objects can both consume energy and provide energy to other devices, so there are three types of energy measurement: energy input to a device, energy supplied to other devices, and net (resultant) energy consumed, which is the difference between energy input and supplied 🔥

1.4. Energy Management

The EMAN framework gives you mechanisms for energy control on top of passive monitoring 👑 There are plenty of cases where actively controlling devices' energy is desirable, for example during low device utilization or peak electrical price periods ⭐

Energy control can be as simple as controlling on/off states. But in lots of cases it needs an understanding of the energy object context 🌸 For instance, during non-business hours in a commercial building, some phones have to stay available in case of emergency, and office cooling usually isn't turned off completely. Instead, the comfort level just gets reduced 🥹

So energy object control needs flexibility and support for different policies and mechanisms, all the way from centralized management by an energy management system to autonomous control by individual devices, plus alignment with dynamic demand-response mechanisms 🦋

The power states specified in the EMAN framework can be used in demand-response scenarios. When time-of-day fluctuations in energy costs or grid power shortages hit, network devices can respond and reduce their energy consumption ⚡

1.5. EMAN Framework Application ✨

okay so a Network Management System (NMS) is basically the entity that asks compatible devices for info, usually using SNMP 📡 An NMS can do a bunch of network management stuff, like security or identity management 🔐 An NMS that handles only energy is called an Energy Management System (EnMS) ⚡ It can just keep an eye on energy use, or it can also do control functions 🎛️ Either way, an EnMS collects energy info for the devices in the network 💅

Energy management can be built by extending the SNMP support that's already there with EMAN-specific MIBs 🧚 SNMP is kind of the OG: it's industry-proven and well-known for discovering, securing, measuring, and controlling SNMP-enabled end devices 🫶 The EMAN framework then gives you an information and data model so you can access a huge range of devices in one unified way 🌈

2. Scenarios and Target Devices 🦋

this section walks through the energy management scenarios that the EMAN framework should solve 💖 Each scenario lists the target devices where the energy management framework can be applied, how the reported-on devices get their power, and how the reporting or control actually happens ✨ Some of the use cases overlap a bit, but they all show network scenarios that the EMAN framework supports 🎀

2.1. Network Infrastructure Energy Objects 🔌

this scenario covers the key use case of network devices and their components 💜 If a device knows about one or more of its components, our information model supports monitoring and control at the component level 🙈 Usually the chassis pulls power from one or more sources and feeds its internal components ⚡ It's highly desirable to have monitoring for individual components too, like line cards, processors, disk drives, and peripherals such as USB devices 🍓

so picture a switch with this grouping of subentities, where energy management could be really useful 👑

  • Physical view: chassis (or stack), line cards, and service modules of the switch.
  • Component view: CPU, Application-Specific Integrated Circuits (ASICs), fans, power supply, ports (single port and port groups), storage, and memory.

the ENTITY-MIB [RFC6933] gives you a containment model for uniquely identifying the physical subcomponents of network devices 🧩 That containment info tells you whether one Energy Object belongs to another Energy Object (like a line-card Energy Object sitting inside a chassis Energy Object) 🪆 The mapping table, entPhysicalContainsTable, has an index called entPhysicalChildIndex, and the entPhysicalTable has a MIB object called entPhysicalContainedIn that points to the containing entity 💅

the essential properties of this use case are:

  • Target devices: network devices such as routers and switches, as well as their components.
  • How powered: typically by a Power Distribution Unit (PDU) on a rack or from a wall outlet. The components of a device are powered by the device chassis.
  • Reporting: direct power measurement can be done at the device level. Components can report their power consumption directly, or the chassis/device can report on behalf of some components. 🫶

2.2. Devices Powered and Connected by a Network Device 🔋

this scenario covers Power Sourcing Equipment (PSE) devices 💖 A PSE device (like a PoE switch) provides power to a Powered Device (PD) (like a desktop phone) over a medium such as USB or Ethernet [RFC3621] ⚡ For each port, the PSE can control the power supply (switching it on and off) and usually meter the actual power it provides 🎛️ PDs get network connectivity and power over a single connection, so the PSE can figure out which device is associated with each port 🧠

PoE ports on a switch are commonly connected to things like IP phones, wireless access points, and IP cameras 📞 The switch needs power for its own internal use and to supply power to its PoE ports 🔥 Monitoring the power consumption of the switch (the supplying device) and the power consumption of the PoE endpoints (the consuming devices) is a simple use case of this scenario 🌸

this scenario shows the relationships between entities 🦋 The PoE IP phone is powered by the switch, and if there are lots of IP phones on the same switch, the switch can aggregate their power consumption all together 💜

the essential properties of this use case are:

Target devices: Power over Ethernet devices such as IP phones, wireless access points, and IP cameras.

How powered: PoE devices are connected to the switch port that supplies power to them.

Reporting: PoE device power consumption is measured and reported by the switch (PSE) that supplies the power. On top of that, some edge devices can support the EMAN framework. ✨

this use case can be split into two subcases:

  • a) The endpoint device supports the EMAN framework, in which case the device is an EMAN Energy Object by itself with its own Universally Unique Identifier (UUID) 🪪 The device is responsible for its own power reporting and control. See the related scenario "Devices Connected to a Network" below.
  • b) The endpoint device doesn't have EMAN capabilities, so power measurement may not be able to be done independently and is therefore only performed by the supplying device. This scenario is similar to the "Mid-level Manager" below. 🙈

in subcase (a), note that there are two power usage reporting mechanisms for the same device: one done by the PD itself and one done by the PSE 😭 Device-specific implementations will dictate which one to use 🔥

2.3. Devices Connected to a Network 🌐

this use case covers the metering relationship between an energy object and the parent energy object it's connected to, while it gets its power from a different source 🧚

for example, a PC has a network connection to a switch but draws power from a wall outlet 💻 In this case, the PC can report its own power usage by itself, ideally through the EMAN framework 🎀

the wall outlet the PC is plugged into can be unmetered or metered, for example by a Smart PDU 🔌

  • a) If metered, the PC has a powered-by relationship to the Smart PDU, and the Smart PDU acts as a "mid-level manager".
  • b) If unmetered, or operating on batteries, the PC will report its own energy usage as any other Energy Object to the switch, and the switch may possibly provide aggregation.

these two cases are not mutually exclusive 🫶

in terms of relationships between entities, the PC has a powered-by relationship to the PDU, and if the PDU meters the PC's power consumption, then there's a metered-by relation between the PC and the PDU 🔗

the essential properties of this use case are:

  • Target devices: energy objects that have a network connection but receive their power supply from another source.
  • How powered: endpoint devices (e.g., PCs) receive power from the wall outlet (unmetered), a PDU (metered), or can be powered autonomously (batteries).
  • Reporting: the power consumption can be reported via the EMAN framework
    • by the device directly,
    • by the switch, with information provided to it by the device, or
    • by the PDU from which the device obtains its power. 💅

2.4. Power Meters ⚡

some electrical devices aren't equipped with instrumentation to measure their own power and accumulated energy consumption 🥺 External meters can be used to measure the power consumption of those electrical devices, as well as collections of devices 💖

three types of external metering are relevant to EMAN: PDUs, standalone meters, and utility meters 📊 External meters can measure the consumption of a single device or a set of devices 🦋

Power Distribution Units (PDUs) can have built-in meters for each socket, and they can measure the power supplied to each device in an equipment rack 🗄️ PDUs typically have remote management capabilities that can report, and possibly control, the power supply of each outlet 🔥

Standalone meters can be placed anywhere in a power distribution tree and may measure all or part of the total ✨ Utility meters monitor and report the accumulated power consumption of the entire building 🏢 There can also be submeters to measure the power consumption of a portion of the building 🍓

the essential properties of this use case are:

  • Target devices: PDUs and meters.
  • How powered: from traditional mains power, but supplied through a PDU or meter (where "mains power" is the standard AC power drawn from the wall outlet).
  • Reporting: PDUs report the power consumption of downstream devices, usually a single device per outlet. Meters may report for one or more devices and may require knowledge of the topology to associate meters with the metered devices. 📈

meters have metered-by relationships with devices, and they may have aggregation relationships between the meters and the devices whose power consumption is accumulated and reported by the meter 🫧

2.5. Mid-level Managers 👑

this use case covers aggregation of energy management data at "mid-level managers", which can provide energy management functions for themselves and their associated devices 💜

a switch can provide energy management functions for all the devices connected to its ports, whether or not those devices are powered by the switch, and whether or not the switch provides immediate network connectivity to them 🌈 A switch like that is a mid-level manager, offering aggregation of power consumption data for other devices 🧚 Devices report their EMAN data to the switch, and the switch aggregates that data for further reporting 🎀

the essential properties of this use case are:

  • Target devices: devices that can perform aggregation; commonly a switch or a proxy.
  • How powered: mid-level managers are commonly powered by a PDU or from a wall outlet, but can be powered by any method.
  • Reporting: the mid-level manager aggregates the energy data and reports that data to an EnMS or a higher mid-level manager. 🔥

2.6. Non-residential Building System Gateways 🏢✨

Okay bestie, this one is all about energy management in non-residential buildings 🏢. Building Management Systems (BMS) have been around for years running legacy protocols that aren't based on IP 💀. So a gateway steps in as a proxy between IP networks and those old building automation protocols, and it gives you an interface between the EMAN framework and the relevant building management protocols 🫶.

The energy savings are huge, so building energy management has gotten a LOT of attention 🔥. There are gateway network elements that manage all the parts of a building energy management system, like Heating, Ventilation, and Air Conditioning (HVAC), lighting, electrical, fire and emergency systems, elevators, etc. The gateway talks to those devices with legacy building protocols, collects their energy usage, and reports the results 💅.

The gateway does protocol conversion and talks over RS-232/RS-485 interfaces, Ethernet interfaces, and building-specific protocols like BACnet (a protocol for building automation and control networks) [BACnet], Modbus [MODBUS], or ZigBee [ZIGBEE] 🌈.

The essential properties of this use case are:

  • Target devices: building energy management devices -- HVAC systems, lighting, electrical, and fire and emergency systems.
  • How powered: any method.
  • Reporting: The gateway collects energy consumption of non-IP systems and communicates the data via the EMAN framework.

2.7. Home Energy Gateways 🏡

This use case is about energy management of a home 🏡. The home energy gateway is another proxy, and it interfaces with electrical appliances and other devices in the house. It can monitor and manage stuff like a refrigerator, heating/cooling, or a washing machine, using one of the many protocols being developed for residential devices 🧺.

Beyond just metering, you can set up energy saving policies based on time of day, occupancy, or energy pricing from the utility grid ⚡. The EMAN information model can be applied to energy management of a home, which is so iconic 🦋.

The essential properties of this use case are:

  • Target devices: home energy gateway and smart meters in a home.
  • How powered: any method.
  • Reporting: The home energy gateway can collect power consumption of device in a home and possibly report the meter reading to the utility.

2.8. Data Center Devices 🖥️

This use case is about energy management of a data center 🖥️. Energy efficiency is a fundamental challenge for data center operation, because data centers are big energy consumers with expensive infrastructure 💸. The equipment generates heat, and that heat has to be evacuated through an HVAC system 🥵.

A typical data center network is a hierarchy of electrical energy objects 🌸. At the bottom are servers mounted on a rack. Those connect to top-of-the-rack switches, which connect to aggregation switches, which then connect to core switches. Power consumption of all network elements, servers, and storage devices in the data center should be measured. Energy management can be implemented at different aggregation levels, i.e., at the network level, the Power Distribution Unit (PDU) level, and/or the server level 📊.

Beyond the network devices, storage devices, and servers, data centers also have Uninterruptable Power Systems (UPSs) that provide back-up power for the facility when there's a power outage 🔋. A UPS can power many devices in a data center for a finite period of time, so monitoring energy storage capacity is vital from a data center network operations point of view 😭. Right now, the UPS MIB can help monitor the battery capacity, the input load to the UPS, and the output load from the UPS. Currently, there is no link between the UPS MIB and the ENTITY MIB 🙈.

On top of monitoring power consumption, additional power characteristics should be monitored too. Some of these are dynamic variations in the input power supply from the grid, which are referred to as power quality metrics ⚡. It can also be useful to monitor how efficiently the devices use power 🎀.

Nameplate capacity of the data center can be estimated from the nameplate ratings (which indicate the maximum possible power draw) of the IT equipment at a site 🧮.

The essential properties of this use case are:

  • Target devices: IT devices in a data center, such as network equipment, servers, and storage devices, as well as power and cooling infrastructure.
  • How powered: any method, but commonly by one or more PDUs.
  • Reporting: Devices may report on their own behalf or for other connected devices as described in other use cases.

2.9. Energy Storage Devices 🔋💜

Energy storage devices can have two different roles. One type has the primary function of providing power to another device (e.g., a UPS). The other type has a different primary function but includes energy storage as a component (e.g., a notebook). This use case covers both 💻.

The energy storage can be a conventional battery or any other means of storing electricity, such as a hydrogen cell 🧪.

An internal battery can be a back-up or an alternative source of power to mains power. Batteries have a finite capacity and lifetime, so means for reporting the actual charge, age, and state of a battery are required 🔋. An internal battery can be viewed as a component of a device and can be contained within the device from an ENTITY-MIB perspective 🧩.

Battery systems are often used in remote locations such as mobile telecom towers 📡. For continuous operation, it is important to monitor the remaining battery life and raise an alarm when it falls below a threshold 🚨.

The essential properties of this use case are:

  • Target devices: devices that have an internal battery or external storage.
  • How powered: from batteries or other storage devices.
  • Reporting: The device reports on its power delivered and state.

2.10. Industrial Automation Networks 🏭

Energy consumption statistics in the industrial sector are staggering 😳. The industrial sector alone consumes about half of the world's total delivered energy and is a significant user of electricity. So the need to optimize energy usage in this sector is natural 💅.

Industrial facilities consume energy in process loads and non-process loads ⚙️.

The essential properties of this use case are:

  • Target devices: devices used in an industrial sector.
  • How powered: any method.
  • Reporting: The Common Industrial Protocol (CIP) is commonly used for reporting energy for these devices.

2.11. Printers 🖨️

This use case is about energy monitoring and management of printers 🖨️. Printers here stand in for all imaging equipment, including Multi-function Devices (MFDs), scanners, fax machines, and mailing machines 📠.

Energy use of printers has been a long-standing industry concern, and sophisticated power management is common. Printers often use a variety of low-power modes, especially for managing energy-intensive thermo-mechanical components 🌙. Printers have also long made extensive use of SNMP for end-user system interaction and for management in general, and cross-vendor management systems can manage fleets of printers in enterprises 🏢. Power consumption during active modes can vary widely, with high peak usage levels 📈.

Printers can expose detailed power state information, which is separate from operational state information, and some printers report transition states between stable long-term states ✨. Many also support active setting of power states and policies, such as delay times, where inactivity automatically moves the device to a lower power mode ⏰. Other features include reporting on components, counters for state transitions, typical power levels by state, scheduling, and events/alarms 🗓️.

Some large printers also have a "Digital Front End", which is a computer that performs functions on behalf of the physical imaging system 💻. These typically have their own presence on the network and are sometimes separately powered 🔌.

Printers have some unique characteristics from the point of view of energy management 🦋. While the printer is not in use, timer-based low power states consume very little power 😴. On the other hand, while the printer is printing or copying, the cylinder is heated, so power consumption is quite high, but only for a short period of time 🔥. Given this workload, periodic polling of power levels alone would not suffice 🙅‍♀️.

The essential properties of this use case are:

  • Target devices: all imaging equipment.
  • How powered: typically, AC from a wall outlet.
  • Reporting: The devices report for themselves.

2.12. Demand Response 🌤️

Demand response from a utility grid is a theme that spans several use cases 🔌. In some situations, like time-of-day fluctuation of energy costs or sudden energy shortages due to power outages, it may be important to respond and reduce the energy consumption of the network 📉.

From the EMAN use case perspective, the demand-response scenario can apply to a data center, a building, or a home 🏠. Real-time energy monitoring is usually a prerequisite, so that during a potential energy shortfall the EnMS can provide an active response 🚦. The EnMS could shut down selected devices that are considered lower priority, or uniformly reduce the power supplied to a class of devices. For multisite data centers, it may be possible to formulate policies such as the follow-the-sun approach, by scheduling the mobility of Virtual Machines (VMs) across data centers in different geographical locations 🌎.

The essential properties of this use case are:

  • Target devices: any device.
  • How powered: traditional mains AC power.
  • Reporting: Devices report in real time.
  • Control: demand response based upon policy or priority.

3. Use Case Patterns 🧩

The use cases presented above can be abstracted into the following broad patterns for energy objects 💖.

3.1. Metering 📏

  • Energy objects that have the capability for internal metering
  • Energy objects that are metered by an external device

3.2. Metering and Control 🎛️

  • Energy objects that do not supply power but can perform power metering for other devices
  • Energy objects that do not supply power but can perform both metering and control for other devices

3.3. Power Supply, Metering, and Control ⚡

  • Energy objects that supply power for other devices but do not perform power metering for those devices
  • Energy objects that supply power for other devices and also perform power metering
  • Energy objects that supply power for other devices and also perform power metering and control for other devices

3.4. Multiple Power Sources 🔌🔌

  • Energy objects that have multiple power sources, with metering and control performed by the same power source
  • Energy objects that have multiple power sources supplying power to the device, with metering performed by one or more sources and control performed by another source

4. Relationship of EMAN to Other Standards 🌸

Okay bestie, EMAN is NOT living in a bubble 🫧. It's tied to a whole bunch of other standards and efforts that deal with energy monitoring and control. It totally leverages existing standards whenever it can (no reinventing the wheel, periodt 💅), and it helps enable adjacent tech like Smart Grid ⚡.

The standards that matter most to EMAN are listed below. For each one you get a quick rundown of its objectives, where it's at right now, and how it relates to EMAN ✨.

4.1. Data Model and Reporting 📊

4.1.1. IEC - CIM

The International Electrotechnical Commission (IEC) has built a broad set of standards for power management 🔌. The one that's most applicable to EMAN is IEC 61850, which is a standard for designing electric utility automation. The abstract data model in 61850 is built upon and extends the Common Information Model (CIM). The complete 61850 CIM model has over a hundred object classes and is widely used by utilities all over the world 🌍.

These standards were originally conceived to automate control of a substation (a facility that transfers electricity from the transmission system to the distribution system). BUT the extensive data model has been used a lot in other domains too, including Energy Management Systems (EnMS) 🙌.

IEC TC57 WG19 is an ongoing working group with the goal of harmonizing the CIM data model and the 61850 standards 🤝.

Several concepts from IEC Standards have been reused in the EMAN documents. Specifically, AC Power Quality measurements were reused from IEC 61850-7-4. The concept of Accuracy Classes for measuring power and energy was adapted from ANSI C12.20 and IEC standards 62053-21 and 62053-22 🎯.

4.1.2. DMTF

The Distributed Management Task Force (DMTF) defined a Power State Management profile [DMTF-DSP1027] for managing computer systems using the DMTF's Common Information Model (CIM) 💻. These specifications cover physical, logical, and virtual system management requirements for power-state control services. The DMTF standard does NOT include energy monitoring 🙈.

The Power State Management profile is used to describe and manage the Power State of computer systems. That includes controlling the Power State of an entity so it can enter sleep mode, wake up, and reboot 😴. The EMAN framework references the DMTF Power Profile and Power State Set 🔗.

4.1.2.1. Common Information Model Profiles

The DMTF uses CIM-based 'Profiles' to represent and manage power utilization and configuration of managed elements (and yes, this is NOT the 61850 CIM, so don't mix them up 🙃). The key profiles for energy management are 'Power Supply' (DSP 1015), 'Power State' (DSP 1027), and 'Power Utilization Management' (DSP 1085). These profiles define lots of features for monitoring and configuring a Power Managed Element's static and dynamic power saving modes, power allocation limits, and power states 🔋.

Reduced power modes can be established as static or dynamic. Static modes are fixed policies that limit power use or utilization. Dynamic power saving modes rely on internal feedback to control power consumption 📉.

Power states are eight named operational and non-operational levels: On, Sleep-Light, Sleep-Deep, Hibernate, Off-Soft, and Off-Hard 🎀. Power change capabilities provide immediate, timed interval, and graceful transitions between on, off, and reset power states ⚡. Table 3 of the Power State Profile defines the correspondence between the Advanced Configuration and Power Interface [ACPI] and the DMTF power state models, although it is not necessary for a managed element to support ACPI 🧚. Optionally, a TransitioningToPowerState property can represent power state transitions that are in progress 🦋.

4.1.2.2. DASH

DMTF Desktop and Mobile Architecture for System Hardware [DASH] is all about managing heterogeneous desktop and mobile systems (including power) through in-band and out-of-band communications 🖥️. DASH uses the DMTF's Web Services for Management (WS-Management) and the CIM data model to manage and control resources such as power, CPU, and so on 🧠.

Both in-service and out-of-service systems can be managed with the DASH specification in a fully secured remote environment 🔐. Full power life-cycle management is possible using out-of-band management 💜.

4.1.3. ODVA

The Open DeviceNet Vendors Association (ODVA) is an association for industrial automation companies, and it defines the Common Industrial Protocol (CIP) 🏭. Within ODVA there's a special interest group focused on energy, standardization, and interoperability of energy-aware devices 💡.

The ODVA is developing an energy management framework for the industrial sector, and there are synergies and similar concepts between the ODVA and EMAN approaches to energy monitoring and management 🫶.

ODVA defines a three-part approach to energy management: awareness of energy usage, energy efficiency, and the exchange of energy with a utility or others ✨. Energy monitoring and management promote efficient consumption and enable automating actions that reduce energy consumption 🌈.

The foundation of the approach is the information and communication model for entities. An entity is a network-connected, energy-aware device that can either measure or derive its energy usage based on its native consumption or generation of energy, OR report a nominal or static energy value 📋.

4.1.4. Ecma SDC

The Ecma International standard on Smart Data Centre [Ecma-SDC] defines semantics for managing entities in a data center, like servers, storage, and network equipment 🗄️. It covers energy as one of many functional resources or attributes of systems for monitoring and control. It ONLY defines messages and properties and does NOT reference any specific protocol 🙅. Its goal is to enable interoperability of protocols like SNMP, BACnet, and HTTP by ensuring a common semantic model across them 🤍.

Four power states are defined: Off, Sleep, Idle, and Active 💤. The standard does not include actual energy or power measurements 🙈.

When used with EMAN, the SDC standard will provide a thin abstraction on top of the more detailed data model available in EMAN 🎀.

4.1.5. PWG

The IEEE Industry Standards and Technology Organization (ISTO) Printer Working Group (PWG) defines open standards for printer-related protocols, for the benefit of printer manufacturers and related software vendors 🖨️. The Printer WG covers power monitoring and management of network printers and imaging systems in the PWG Power Management Model for Imaging Systems [PWG5106.4]. Clearly these devices are in scope for energy management, since they receive power and are attached to the network 🔌. There's also plenty of room for power management, since printers and imaging systems are not used that often 😴.

The IEEE-ISTO Printer Working Group (PWG) defines SNMP MIB modules for printer management, and in particular a "PWG Power Management Model for Imaging Systems v1.0" [PWG5106.4] along with a companion SNMP binding in the "PWG Imaging System Power MIB v1.0" [PWG5106.5] 💖. This PWG model and MIB are harmonized with the DMTF CIM Infrastructure [DMTF-DSP0004] and the DMTF CIM Power State Management Profile [DMTF-DSP1027] for power states and alerts 🤝.

These MIB modules can be useful for monitoring the power and Power State of printers 👀. The EMAN framework takes the standards defined in the Printer Working Group into account. The PWG may harmonize its MIBs with those from EMAN. The PWG covers many topics in greater detail than EMAN, including ones specific to imaging equipment 📚. The PWG also provides for vendor-specific extension states (beyond the standard DMTF CIM states) 🦋.

The IETF Printer MIB [RFC3805] is on the Standards Track, but that MIB module does NOT address power management 🙃.

4.1.6. ASHRAE

In the U.S., there's an extensive effort to coordinate and develop standards related to the "Smart Grid" 🇺🇸. The Smart Grid Interoperability Panel, coordinated by the government's National Institute of Standards and Technology, identified the need for a building-side information model (as a counterpart to utility models) and specified this in Priority Action Plan (PAP) 17 🏢. This was designated as a joint effort by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) and the National Electrical Manufacturers Association (NEMA), both ANSI-approved Standards Development Organizations (SDOs). The result is meant to be an information model, NOT a protocol 🧩.

The ASHRAE effort [ASHRAE] addresses data used only within a building, as well as data that may be shared with the grid, particularly when it comes to coordinating future demand levels with the needs of the grid ⚡. The model is intended to be applied to any building type, both residential and commercial 🏠. It is expected that existing protocols will be adapted to comply with the new information model, just as new protocols would be 🔄.

There are four basic types of entities in the model: generators, loads, meters, and energy managers 🎀. The metering part of the model overlaps to a large degree with the EMAN framework, though each has features unique to it. The load part speaks to control capabilities well beyond what EMAN covers. Details of generation and of the energy management function are outside EMAN scope 🙌.

A public review draft of the ASHRAE standard was released in July 2012. There are no apparent major conflicts between the two approaches, but there are areas where some harmonization is possible 🫶.

4.1.7. ANSI/CEA

The Consumer Electronics Association (CEA) has approved ANSI/CEA-2047 [ANSICEA] as a standard data model for Energy Usage Information 📺. The primary purpose is to let home appliances and electronics communicate energy usage information over a wide range of technologies, using pluggable modules that contain the physical-layer electronics 🏡. The standard can be used by devices on any home network, including Wi-Fi, Ethernet, ZigBee, Z-Wave, and Bluetooth 📶. The Introduction to ANSI/CEA-2047 says that "this standard provides an information model for other groups to develop implementations specific to their network, protocol and needs" 💬. It covers device identification, current power level, and cumulative energy consumption, and it provides for reporting time-series data 📈.

4.1.8. ZigBee

The ZigBee Smart Energy Profile 2.0 (SEP) effort [ZIGBEE] focuses on IP-based wireless communication to appliances and lighting 💡. It's meant to enable internal building energy management AND provide for bidirectional communication with the power grid 🔁.

ZigBee protocols are intended for embedded applications with low data rates and low power consumption 🔋. ZigBee defines a general-purpose, inexpensive, self-organizing mesh network that can be used for industrial control, embedded sensing, medical data collection, smoke and intruder warning, building automation, home automation, and so on 🕸️.

ZigBee is currently NOT an ANSI-recognized SDO 🙈.

The EMAN framework addresses the needs of IP-enabled networks through the usage of SNMP, while ZigBee provides completely integrated and inexpensive mesh solutions 🌸.

4.2. Measurement 📏

4.2.1. ANSI C12 ✨

okay so the American National Standards Institute (ANSI) has defined a whole family of power meter standards under ANSI C12 ⚡ the main ones cover communication protocols (C12.18, 21 and 22), data and schema definitions (C12.19), and measurement accuracy (C12.20) 🎀 the European side has its own equivalent in IEC 62053-22 🇪🇺

these are super specific standards aimed at the meter itself, and they're used by electricity distributors and producers 💅

and the EMAN framework [RFC7326] references the Accuracy Classes specified in ANSI C12.20 🦋

4.2.2. IEC 62301 🌸

IEC 62301, "Household electrical appliances - Measurement of standby power" [IEC62301], lays out a power-level measurement procedure 📏 it's nominally for appliances and low-power modes, but its concepts apply to other device types and modes too, and it's commonly referenced in test procedures for energy using products 🔌

the standard is meant for lab measurements of devices in controlled conditions, but parts of it are informative for anyone implementing measurement in products that ultimately report via EMAN 🧪💜

4.3. Other 🌈

4.3.1. ISO 🌍

the International Organization for Standardization (ISO) [ISO] is developing an energy management standard, ISO 50001, to complement ISO 9001 for quality management and ISO 14001 for environmental management 🙌 the goal is to help create energy management programs for industrial, commercial, and other entities 🏭

the standard defines a process for energy management at an organizational level 🏢 it does not define how devices report energy or consume energy, so don't go looking for that here 🙈

ISO 50001 is built on the common elements found in all of ISO's management system standards, which is why it's so compatible with ISO 9001 and ISO 14001 💖 the benefits include:

  • Integrating energy efficiency into management practices and throughout the supply chain. 🔗
  • Using energy management best practices and good energy management behaviors. ✨
  • Benchmarking, measuring, documenting, and reporting energy intensity improvements and their projected impact on reductions in greenhouse gas (GHG) emissions. 🌿
  • Evaluating and prioritizing the implementation of new energy-efficient technologies. 🔋

ISO 50001 was developed by ISO project committee ISO TC 242, Energy Management 🎯 and EMAN is complementary to ISO 9001 💜

4.3.2. Energy Star ⭐

the U.S. Environmental Protection Agency (EPA) and U.S. Department of Energy (DOE) jointly sponsor the Energy Star program [ESTAR] 🇺🇸 the program promotes the development of energy efficient products and practices 🍃

to qualify as Energy Star, products have to meet specific energy efficiency targets 🎀 the program also offers planning tools and technical documentation to encourage more energy-efficient building design 🏗️

for businesses and data centers, Energy Star offers technical support to help companies set up energy conservation practices 🖥️ it shares best practices for measuring current energy performance, goal setting, and tracking improvement 📈 the tools include a rating system for building performance and comparative benchmarks 🏆

Energy Star is a program, not a protocol or standard. Keep that straight, bestie! 💅

there's no immediate link between EMAN and Energy Star, since one is a protocol and the other is a set of recommendations for developing energy-efficient products 🙃 however, Energy Star could include EMAN standards in specifications for future products, either as required or rewarded with some benefit 👑

4.3.3. Smart Grid ⚡🧚

the Smart Grid standards efforts underway in the United States are overseen by the U.S. National Institute of Standards and Technology [NIST] 🏛️ NIST coordinates a public-private partnership with key energy and consumer stakeholders to help develop Smart Grid standards 🤝 those activities are monitored and facilitated by the Smart Grid Interoperability Panel (SGIP) 👀 the group has working groups for specific topics, including homes, commercial buildings, and industrial facilities as they relate to the grid 🏘️ a stated goal is to harmonize any new standard with the IEC CIM and IEC 61850 💫

when a working group spots a standard or technology gap, the team asks the SGIP to approve a Priority Action Plan (PAP), a private-public partnership to close the gap 🛠️ PAP 17 is discussed in Section 4.1.6 📌

PAP 10 addresses "Standard Energy Usage Information" 🔍 Smart Grid standards will provide distributed intelligence in the network and allow enhanced load shedding ⚖️ for example, pricing signals can enable selective shutdown of non-critical activities during peak price periods 💸 actions can be taken through both centralized and distributed management controls 🎛️

there's an obvious functional link between Smart Grid and EMAN in the form of demand response, even though the EMAN framework itself doesn't address any coordination with the grid 🫶 since EMAN enables control, it can be used to accomplish demand response by translating a signal from an outside entity 🔥

5. Limitations 🚧

EMAN addresses the needs of energy monitoring in terms of measurement, and it considers limited control capabilities of energy monitoring of networks 📊

EMAN does not create a new protocol stack 🙅‍♀️ instead, it defines a data and information model useful for measuring and reporting energy and other metrics over SNMP 🦋

EMAN does not address questions regarding Smart Grid, electricity producers, and distributors 🙈

6. Security Considerations 🔐💀

this part is seriously important, so listen up! 🚨 EMAN uses SNMP and therefore has the functionality of SNMP's security capabilities 🛡️ SNMPv3 [RFC3411] provides important security features such as confidentiality, integrity, and authentication 🔒

Section 10 of [RFC7460] and Section 6 of [RFC7461] mention that power monitoring and management MIBs may have certain privacy implications 👁️ those privacy implications are beyond the scope of this document 🙅‍♀️ there may be additional privacy considerations specific to each use case, and this document hasn't attempted to analyze those 🌙

7. References 📚

7.1. Normative References 💜

[RFC3411]   Harrington, D., Presuhn, R., and B. Wijnen, "An
            Architecture for Describing Simple Network Management
            Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
            DOI 10.17487/RFC3411, December 2002,
            <http://www.rfc-editor.org/info/rfc3411>.

[RFC3621]   Berger, A. and D. Romascanu, "Power Ethernet MIB",
            RFC 3621, DOI 10.17487/RFC3621, December 2003,
            <http://www.rfc-editor.org/info/rfc3621>.

7.2. Informative References 🦋

[ACPI]      ACPI, "Advanced Configuration and Power Interface
            Specification", Revision 5.0b, November 2013,
            <http://www.acpi.info/spec30b.htm>.

[ANSICEA]   ANSI, "CEA 2047 CE Energy Usage Information (CE-EUI)",
            ANSI/CEA-2047, August 2014.

[ASHRAE]    NIST, "ASHRAE SPC 201 P Information Page",
            <http://collaborate.nist.gov/twiki-sggrid/
            bin/view/SmartGrid/PAP17Information>.

[BACnet]    "BACnet Webpage", <http://www.bacnet.org>.

[DASH]      DMTF, "Desktop and Mobile Architecture for System
            Hardware", <http://www.dmtf.org/standards/mgmt/dash/>.

[DMTF-DSP0004]
            DMTF, "Common Information Model (CIM) Infrastructure",
            DSP0004, Version 2.5.0, May 2009, <http://www.dmtf.org/
            standards/published_documents/DSP0004_2.5.0.pdf>.

[DMTF-DSP1027]
            DMTF, "Power State Management Profile", DSP1027, Version
            2.0.0, December 2009, <http://www.dmtf.org/standards/
            published_documents/DSP1027_2.0.0.pdf>.

[Ecma-SDC]  Ecma International, "Smart Data Centre Resource
            Monitoring and Control", Standard ECMA-400, Second
            Edition, June 2013, <http://www.ecma-international.org/
            publications/standards/Ecma-400.htm>.

[ESTAR]     Energy Star, <http://www.energystar.gov/>.

[IEC62301]  IEC, "Household electrical appliances - Measurement of
            standby power", IEC 62301:2011, Edition 2.0, January
            2011.

[ISO]       ISO, "ISO launches ISO 50001 energy management standard",
            June 2011,
            <http://www.iso.org/iso/news.htm?refid=Ref1434>.

[MODBUS]    Modbus-IDA, "MODBUS Application Protocol Specification",
            Version 1.1b, December 2006, <http://www.modbus.org/docs/
            Modbus_Application_Protocol_V1_1b.pdf>.

[NIST]      NIST, "Smart Grid Homepage", August 2010,
            <http://www.nist.gov/smartgrid/>.

[PWG5106.4] IEEE-ISTO, "PWG Power Management Model for Imaging
            Systems 1.0", PWG Candidate Standard 5106.4-2011,
            February 2011, <ftp://ftp.pwg.org/pub/pwg/candidates/
            cs-wimspower10-20110214-5106.4.pdf>.

[PWG5106.5] IEEE-ISTO, "PWG Imaging System Power MIB v1.0", PWG
            Candidate Standard 5106.5-2011, February 2011.

[RFC3805]   Bergman, R., Lewis, H., and I. McDonald, "Printer MIB
            v2", RFC 3805, DOI 10.17487/RFC3805, June 2004,
            <http://www.rfc-editor.org/info/rfc3805>.

[RFC6933]   Bierman, A., Romascanu, D., Quittek, J., and M.
            Chandramouli, "Entity MIB (Version 4)", RFC 6933,
            DOI 10.17487/RFC6933, May 2013,
            <http://www.rfc-editor.org/info/rfc6933>.

[RFC6988]   Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz,
            T., and B. Claise, "Requirements for Energy Management",
            RFC 6988, DOI 10.17487/RFC6988, September 2013,
            <http://www.rfc-editor.org/info/rfc6988>.

[RFC7326]   Parello, J., Claise, B., Schoening, B., and J. Quittek,
            "Energy Management Framework", RFC 7326,
            DOI 10.17487/RFC7326, September 2014,
            <http://www.rfc-editor.org/info/rfc7326>.

[RFC7460]   Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
            and T. Dietz, "Monitoring and Control MIB for Power and
            Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015,
            <http://www.rfc-editor.org/info/rfc7460>.

[RFC7461]   Parello, J., Claise, B., and M. Chandramouli, "Energy
            Object Context MIB", RFC 7461, DOI 10.17487/RFC7461,
            March 2015, <http://www.rfc-editor.org/info/rfc7461>.

[RFC7577]   Quittek, J., Winter, R., and T. Dietz, "Definition of
            Managed Objects for Battery Monitoring", RFC 7577,
            DOI 10.17487/RFC7577, July 2015,
            <http://www.rfc-editor.org/info/rfc7577>.

[ZIGBEE]    "The ZigBee Alliance", <http://www.zigbee.org/>.

Acknowledgements 🫶🌸

firstly, the authors thank Emmanuel Tychon for taking the lead on the initial draft and making substantial contributions to it 👏 the authors also thank Jeff Wheeler, Benoit Claise, Juergen Quittek, Chris Verges, John Parello, and Matt Laherty for their valuable contributions 💖 and they thank Kerry Lynn for the use case involving demand response 🎉

Authors' Addresses ✨

Okay bestie, this is the final bit of the RFC, and it's just the contact cards for the three authors. Think of it as the "who do I DM about this" section 💅

Brad Schoening is an Independent Consultant. His mailing address is 44 Rivers Edge Drive, Little Silver, NJ 07739, United States. You can call him at +1 917 304 7190 or email brad.schoening@verizon.net 📞

Mouli Chandramouli is at Cisco Systems, Inc. His address is Sarjapur Outer Ring Road, Bangalore 560103, India. His phone is +91 80 4429 2409 and his email is moulchan@cisco.com 🌸

Bruce Nordman is at Lawrence Berkeley National Laboratory. His address is 1 Cyclotron Road, 90-2000, Berkeley, CA 94720-8130, United States. Reach him at +1 510 486 7089 or bnordman@lbl.gov 🦋

That's the whole RFC, babes! Three brilliant people, a whole lot of energy-efficiency knowledge, and now you have every way to reach them 🫶🌈

📦 where this page comes from