RFC 6988

Requirements for Energy Management

📅 published September 2013, from ietf

Requirements for Energy Management 🔋✨

Okay bestie, first the ID card 🪪 This is RFC 6988, called Requirements for Energy Management, published by the IETF in September 2013. It's Informational, which means it's published for informational purposes and isn't a Standards Track spec 🌸 It was edited by J. Quittek (Ed.) of NEC Europe Ltd., with M. Chandramouli of Cisco Systems, Inc., R. Winter and T. Dietz of NEC Europe Ltd., and B. Claise of Cisco Systems, Inc. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅

Abstract 📝

Okay so this doc lays out the requirements that standards for Energy Management have to cover 🔌 The requirements are about two things: monitoring and control. Monitoring is basically knowing what's going on, like identifying energy-managed devices and their components, and keeping an eye on their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and any contained batteries 🔋 Control is the doing part, like controlling the power supply and the Power State of energy-managed devices and their components ⚡

It's giving "here's what the standards must include" and not "here's what your code must do" 🙈 The doc says it doesn't specify the features that must be implemented by compliant implementations. Instead, it lists features that must be supported by standards for Energy Management. Very important distinction, periodt 💖

Status of This Memo 📌

Quick legal-ish note: this document is not an Internet Standards Track specification. It's published for informational purposes 🎀

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). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🧐

If you want the current status, any errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc6988 🦋

Copyright Notice ©️

This document 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 of this document. Please review these documents carefully, because 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 they are provided without warranty as described in the Simplified BSD License 🫶

Table of Contents 📋

1. Introduction ....................................................3
   1.1. Conventional Requirements for Energy Management ............3
   1.2. Specific Requirements for Energy Management ................4
2. Terminology .....................................................5
3. General Considerations Related to Energy Management .............6
   3.1. Power States ...............................................7
   3.2. Saving Energy versus Maintaining Service Level .............7
   3.3. Local versus Network-Wide Energy Management ................7
   3.4. Energy Monitoring versus Energy Saving .....................8
   3.5. Overview of Energy Management Requirements .................8
4. Identification of Entities ......................................9
5. Information on Entities ........................................10
   5.1. General Information on Entities ...........................10
   5.2. Power Interfaces ..........................................11
   5.3. Power .....................................................13
   5.4. Power State ...............................................15
   5.5. Energy ....................................................17
   5.6. Battery State .............................................18
   5.7. Time Series of Measured Values ............................19
6. Control of Entities ............................................21
7. Reporting on Other Entities ....................................21
8. Controlling Other Entities .....................................22
   8.1. Controlling Power States of Other Entities ................22
   8.2. Controlling Power Supply ..................................23
9. Security Considerations ........................................23
10. Acknowledgments ...............................................25
11. References ....................................................25
   11.1. Normative References .....................................25
   11.2. Informative References ...................................26

1. Introduction 🌍

Rising energy costs and a growing awareness of the ecological impact of running IT equipment have made Energy Management (EMAN) functions and interfaces a basic requirement for network management systems and for devices connected to a network 🌱

This document defines requirements for standards specifications for Energy Management, covering both monitoring functions and control functions. The focus is mainly on devices and their components that receive and provide electrical energy ⚡ Devices such as hosts, routers, and middleboxes may have an IP address, or they may be connected indirectly to the Internet through a proxy with an IP address that provides a management interface for the device. For example, devices in a building infrastructure might use non-IP protocols with a gateway to the Internet 🏢

These requirements are about the standards specification process, not the implementation of specified standards. All requirements in this document must be reflected by standards specifications to be developed. However, which features those standards specify will be mandatory, recommended, or optional for compliant implementations is for Standards Track document(s) to define, not this one 🧁

Section 3 talks through a set of general needs for Energy Management. The requirements for an Energy Management standard are in Sections 4 through 8. Sections 4 through 6 hold the conventional requirements about information on entities and control functions, and Sections 7 and 8 hold the requirements that are specific to Energy Management 💜

Because of how power supply works, some monitoring and control functions don't happen by talking to the entity of interest. They happen by talking to other entities, like entities upstream in a power distribution tree 🌳

1.1. Conventional Requirements for Energy Management 🎀

The requirements for an Energy Management standard start in Section 4, which covers identifying entities and how granular the reporting of energy-related information should be. A standard must support the unique identification of entities, reporting per entire device, and reporting energy-related information on individual components of a device or on attached devices 🔍

Section 5 has the requirements for monitoring entities. That includes general information (type, context) and specific information on Power States, Power Inlets, Power Outlets, power, energy, and batteries 🔋 Control of Power State and power supply by entities is covered in Section 6 🎛️

1.2. Specific Requirements for Energy Management 🌟

Okay, so the conventional requirements above seem like they'd be all Energy Management needs, right? Not quite 🙈 Energy Management is really different from most well-known network management functions, and the biggest difference is that some devices need to report on other entities. There are three major reasons for this:

For monitoring a particular entity, it isn't always enough to talk only to that entity. If the entity has no instrumentation for determining power, it might still be possible to get its power values by communicating with other entities in its power distribution tree. A simple example is getting power values from a power meter on the power line going into the entity. A Power Distribution Unit (PDU) and a Power over Ethernet (PoE) switch are common examples. Both supply power to other entities at sockets or ports, respectively, and both are often instrumented to measure power per socket or port 📊
Similar considerations apply to controlling the power supply of an entity, which often needs direct or indirect communication with another entity upstream in the power distribution tree. Again, a PDU and a PoE switch are common examples, if they can switch power on or off at their sockets or ports, respectively ⚡
Energy Management often reaches beyond entities with IP network interfaces, out to non-IP building systems accessed through a gateway (sometimes called an Energy Management System or controller). The requirements in this document don't cover the details of these networks and energy devices. Instead, they specify ways to open IP network management towards them 🌈

These specific issues, along with other issues, are covered by the requirements in Sections 7 and 8 🦋

The requirements in these sections need a new Energy Management framework that deals with the specific nature of Energy Management 🧚 The actual standards documents, such as MIB module specifications, address conformance by specifying which features must, should, or may be implemented by compliant implementations 💅

2. Terminology ✨

okay so the terms in this section get CAPITALIZED all through the doc 💅 the only exceptions are the super common words "energy" and "power" 🌸 they're generic and show up in stuff like "energy-saving" and "low-power" ✨

Energy 🔋

Energy is the capacity of a system to do work. As used by electric utilities, it is generally a reference to electrical energy and is measured in kilowatt-hours (kWh) [IEEE-100].

Power ⚡

Power is the time rate at which energy is emitted, transferred, or received; power is usually expressed in watts (or in joules per second) [IEEE-100]. (The term "power" does not refer to the concept of demand, which is an averaged power value.)

Power Attributes 🎀

Power Attributes are measurements of electric current, voltage, phase, and frequencies at a given point in an electrical power system (adapted from [IEC.60050]).

NOTE: Power Attributes are not intended to be "judgmental" with respect to a reference or technical value and are independent of any usage context. 🙈

Energy Management 🌈

Energy Management is a set of functions for measuring, modeling, planning, and optimizing networks to ensure that the network elements and attached devices use energy efficiently and in a manner appropriate to the nature of the application and the cost constraints of the organization [ITU-M.3400]. it's giving full planning era 📋✨

Energy Management System 🖥️

An Energy Management System is a combination of hardware and software used to administer a network with the primary purpose being Energy Management. 💜

Energy Monitoring 👀

Energy Monitoring is a part of Energy Management that deals with collecting or reading information from network elements and attached devices and their components to aid in Energy Management.

Energy Control 🎛️

Energy Control is a part of Energy Management that deals with controlling energy supply and Power State of network elements, as well as attached devices and their components. 👑

Power Interface 🔌

A Power Interface is an interface at which a device is connected to a power transmission medium, at which it can in turn receive power, provide power, or both.

Power Inlet 📥

A Power Inlet is a Power Interface at which a device can receive power from other devices.

Power Outlet 📤

A Power Outlet is a Power Interface at which a device can provide power to other devices.

Power State 🦋

A Power State is a condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input [IEEE-1621].

the basic goal of Energy Management is to operate sets of devices using minimal energy, while still keeping a certain level of service 🫶 [EMAN-STATEMENT] shows how the EMAN framework applies to a bunch of different scenarios, and it also lists use cases and target devices 📚

3.1. Power States 🔋

Entities can be set to an operational state that results in the lowest power level that still meets the service-level performance objectives. In principle, there are three basic types of Power States for an entity or for a whole system:

full Power State
sleep state (not functional but immediately available)
off state (may require significant time to become operational)

the number of Power States and what they can do varies a LOT between devices 🙃 simple entities might only have the extremes: full Power State and off state. lots of devices have three basic ones: on, off, and sleep. but you can totally build more finely grained Power States too ✨ like operational low Power States where a device needs less energy than in the full power "on" state, but (compared to the sleep state) it's still operational with reduced performance or functionality 💤

3.2. Saving Energy versus Maintaining Service Level 📉

One of the objectives of Energy Management is to reduce energy consumption. while that goal is super clear, actually reaching it is often hard 😤 in lots of cases there's no way to cut power without a potential service (performance or capacity) degradation. so a trade-off needs to be made between service-level objectives and energy minimization ⚖️ in other cases, power can be reduced easily while still keeping enough service-level performance, for example by switching entities to lower Power States when higher performance isn't needed 🌙

3.3. Local versus Network-Wide Energy Management 🌐

Many energy-saving functions are executed locally by an entity; it monitors its usage and dynamically adapts its power according to the required performance. it may, for example, switch to a sleep state when it's not in use, or outside of scheduled business hours 😴 an Energy Management System may observe an entity's Power State and configure its power-saving policies. 👀

energy savings can also come from policies implemented by a network management system that controls Power States of managed entities. info about the power received and provided by entities in different Power States may be needed to set those policies, and this info is often best acquired through monitoring 📊

both network-wide and local Energy Management methods have advantages and disadvantages, and it's often desirable to combine them 💅 central management is often favorable for setting Power States of a large number of entities at the same time, for example at the beginning and end of business hours in a building 🏢 local management is often preferable for power-saving measures based on local observations, such as the high or low functional load of an entity 🧚

3.4. Energy Monitoring versus Energy Saving 📈

Monitoring energy, power, and Power States alone does not reduce the energy needed to run an entity. in fact, it may even increase it slightly, because the monitoring instrumentation itself needs energy 😭 reporting measured quantities over the network may also increase energy use, though the info it gets back may be an essential input to control loops that save energy 💜

monitoring energy and Power States can also be required for other purposes, including:

investigating energy-saving potential
evaluating the effectiveness of energy-saving policies and measures
deriving, implementing, and testing power management strategies
accounting for the total power received and provided by an entity, a network, or a service
predicting an entity's reliability based on power usage
choosing the time of the next maintenance cycle for an entity

3.5. Overview of Energy Management Requirements 📝

the following basic management functions are required:

monitoring Power States
monitoring power (energy conversion rate)
monitoring (accumulated) received and provided energy
monitoring Power Attributes
setting Power States

power control is complementary to other energy-saving measures, like low-power electronics, energy-saving protocols, energy-efficient device design (for example, low-power modes for components), and energy-efficient network architectures 🌿 measuring received and provided energy can give useful data for developing these technologies 🫶

4. Identification of Entities 🪪

entities must be capable of being uniquely identified within the context of the management system. this includes entities that are components of managed devices as well as entire devices 🎀

entities that report on or control other entities must identify the entities they report on or control: see Section 7 or Section 8, respectively, for the detailed requirements. 📋

an entity may be an entire device or a component of it. examples of components of interest are a hard drive, a battery, or a line card 🔋 the ability to control individual components to save energy may be required. for example, server blades can be switched off when the overall load is low, or line cards at switches may be powered down at night 🌙

identifiers for devices and components are already defined in standard MIB modules, like the Link Layer Discovery Protocol (LLDP) MIB module [IEEE-802.1AB] and the Link Layer Discovery Protocol -- Media Endpoint Discovery (LLDP-MED) MIB module [ANSI-TIA-1057] for devices, and the Entity MIB module [RFC6933] and the power Ethernet MIB [RFC3621] for components of devices 🧩 Energy Management needs a way to link energy-related information to those identifiers 🔗

instrumentation for measuring the received and provided energy of a device is typically more expensive than instrumentation for retrieving its Power State 💸 many devices may provide Power State info for all individual components separately, while only reporting the received and provided energy for the entire device 🫠

4.1. Identifying Entities 🆔

The standard must provide means for uniquely identifying entities. Uniqueness must be preserved such that collisions of identities are avoided at potential receivers of monitored information. no identity clashes, periodt 💅

4.2. Persistence of Identifiers 🔒

The standard must provide means for indicating whether identifiers of entities are persistent across a restart of the entity.

4.3. Change of Identifiers 🔄

The standard must provide means to indicate any change of entity identifiers.

4.4. Using Entity Identifiers of Existing MIB Modules 🧠

The standard must provide means for reusing entity identifiers from existing standards, including at least the following:

the entPhysicalIndex in the Entity MIB module [RFC6933]
the LldpPortNumber in the LLDP MIB module [IEEE-802.1AB] and in the LLDP-MED MIB module [ANSI-TIA-1057]
the pethPsePortIndex and the pethPsePortGroupIndex in the Power Ethernet MIB [RFC3621]

generic means for reusing other entity identifiers must be provided. ✨

5. Information on Entities 📚

this section describes info on entities that the standard must provide means for retrieving and reporting 💖

required info can be structured into seven groups 🌈 Section 5.1 covers requirements for general info on entities, like the type of entity or context info. requirements for info on Power Inlets and Power Outlets of entities are in Section 5.2 🔌 monitoring of power and energy is covered by Sections 5.3 and 5.5, respectively ⚡ Section 5.4 covers requirements related to entities' Power States 💤 Section 5.6 has the requirements for monitoring batteries 🔋 and finally, reporting time series of values is covered by Section 5.7 📈

5.1. General Information on Entities 🧾

for Energy Management, understanding the role and context of an entity may be required. an Energy Management System may aggregate values of received and provided energy according to a defined grouping of entities 🗂️ when controlling and setting Power States, it may be helpful to understand the grouping of the entity and the role an entity plays in a network 🕸️ for example, it may be important to exclude some mission-critical network devices from being switched to lower power or even from being switched off 🛡️ absolutely no turning off the important stuff 🙅‍♀️

5.1.1. Type of Entity 🏷️

The standard must provide means to configure, retrieve, and report a textual name or a description of an entity. 🫶

5.1.2. Context of an Entity 🎀

okay so the standard has to give us a way to fetch and report context info on entities 🧚 like, tags that show what role an entity plays. bestie, that's the vibe check for every device in the network 💅

5.1.3. Significance of Entities ⭐

the standard also has to let us retrieve and report how significant an entity is within its context. think "how important is this one?" 👑 it's giving priority, and we need to be able to see it ✨

5.1.4. Power Priority 🔥

the standard must provide means for retrieving and reporting power priorities of entities. power priorities set the order in which Power States of entities get changed, like dropping devices into lower Power States to save power 🦋 it's the main character lineup for who gets to power down first 💀

5.1.5. Grouping of Entities 🌸

the standard must provide means for grouping entities. there are a bunch of ways to do this, like tagging entities, assigning them to domains, or giving them device types 🍓 basically, sorting the squad into friend groups 🫶

5.2. Power Interfaces 🔌

a Power Interface is an interface where a device plugs into a power transmission medium. at that spot it can receive power, provide power, or do both 💜

every Power Interface is either an inlet or an outlet. some of them flip over time from inlet to outlet and back again, but most never change 🙈 they're very consistent, honestly iconic 👑

devices have Power Inlets where they get their electric power 🔋 most devices have just one, but some have several. different Power Inlets on the same device are often hooked up to separate power distribution trees 🌳 for Energy Monitoring, it's useful to pull up how many inlets a device has, whether power is available at each inlet, and which inlets are actually being used ✨

devices can also have one or more Power Outlets for powering other devices 🎀

for identifying, and maybe controlling, where the power at an inlet is coming from, you may need to identify the Power Outlet on another device that's providing it 🕵️ same idea in reverse: for each outlet, it's of interest to identify the Power Inlets that receive the power from that outlet 🦋 this info is also needed to build the wiring topology of electrical power distribution to devices, which is a whole mood 🧚

the static properties of each Power Interface are required information for Energy Management 💖 those properties include the kind of electric current (AC or DC), the nominal voltage, the nominal AC frequency, and the number of AC phases ⚡ also, the nominal voltage is often not one single value but a voltage range, like (100V-120V), (100V-240V), or (100V-120V,220V-240V) 🌈 so many possibilities, no cap 😭

5.2.1. List of Power Interfaces 📋

the standard must provide means for monitoring the list of Power Interfaces of a device.

5.2.2. Operational Mode of Power Interfaces 🔄

the standard must provide means for monitoring the operational mode of a Power Interface, which is either "Power Inlet" or "Power Outlet" 💅

5.2.3. Corresponding Power Outlet 🔗

the standard must provide means for identifying the Power Outlet that provides the power received at a Power Inlet.

5.2.4. Corresponding Power Inlets 🔗

the standard must provide means for identifying the list of Power Inlets that receive the power provided at a Power Outlet.

5.2.5. Availability of Power 💡

if the Power States allow it, the standard must provide means for monitoring the availability of power at each Power Interface. this includes indicating whether a power supply at a Power Interface is switched on or off 🔛 it's giving on/off energy, periodt 💀

5.2.6. Use of Power ⚡

the standard must provide means for monitoring each Power Interface to see if it's actually in use. for inlets, that means the device is really receiving power at that inlet. for outlets, that means power is really being provided from that outlet to one or more devices ✨

5.2.7. Type of Current 🔋

the standard must provide means for reporting the type of current (AC or DC) for each Power Interface, as well as for a device 🫶

5.2.8. Nominal Voltage Range 📈

the standard must provide means for reporting the nominal voltage range for each Power Interface 💜

5.2.9. Nominal AC Frequency 🌊

the standard must provide means for reporting the nominal AC frequency for each Power Interface 🎶

5.2.10. Number of AC Phases 🔺

the standard must provide means for reporting the number of AC phases for each Power Interface 🌸

5.3. Power ⚡

power is measured as an instantaneous value or as the average over a time interval 🕰️

getting super accurate values for power and energy can be costly if you need dedicated metering hardware 💸 so entities that can't measure with high accuracy can just report estimated values instead, for example based on load monitoring, Power State, or even just the entity type 🤷‍♀️ it's a glow-up with a budget, lowkey relatable 🥹

depending on how the power and energy values are obtained, how much you can trust a reported value and how accurate it is will vary 🔍 entities reporting these values should qualify their confidence and quantify the accuracy of their measurements, bestie 📏 for reporting accuracy, the accuracy classes in IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered 💅

there are more properties of the power supplied to a device that are also of interest 👀 for AC power supply especially, several Power Attributes beyond the real power are of potential interest to Energy Management Systems 🧠 that set includes the complex Power Attributes (apparent power, reactive power, and phase angle of the current or power factor), plus the actual voltage, the actual AC frequency, the Total Harmonic Distortion (THD) of voltage and current, and the impedance of an AC phase or of the DC supply 🌈 a new standard for monitoring these Power Attributes should line up with already-existing standards, such as [IEC.61850-7-4] 🫶

for some network management tasks, it's desirable to get notifications from entities when their power value goes above or below given thresholds 🔔 very much a "tell me when it's too much" energy 💖

5.3.1. Real Power / Power Factor 💪

the standard must provide means for reporting the real power for each Power Interface, as well as for an entity. reporting power includes reporting the direction of power flow ➡️⬅️

5.3.2. Power Measurement Interval ⏱️

the standard must provide means for reporting the corresponding time or time interval for which a power value is reported. the power value can be measured at the corresponding time, or averaged over the corresponding time interval 📊

5.3.3. Power Measurement Method 🧪

the standard must provide means to indicate the method used to get these values 🔬 based on how the measurement was done, you can attach a certain degree of confidence to the reported power value 💯 for example, there are measurement methods like direct power measurement, estimation based on performance values, or hard-coding average power values for an entity 🍰

5.3.4. Accuracy of Power and Energy Values 🎯

the standard must provide means for reporting the accuracy of reported power and energy values ✨

5.3.5. Actual Voltage and Current ⚡

the standard must provide means for reporting the actual voltage and actual current for each Power Interface, as well as for a device. for AC power supply, means must be provided for reporting the actual voltage and actual current per phase 🌀

5.3.6. High-Power/Low-Power Notifications 🚨

the standard must provide means for creating notifications if the power values of an entity rise above or fall below given thresholds 📣 it's the "hey, something's off" alert, iykyk 🙈

5.3.7. Complex Power / Power Factor 🧮

the standard must provide means for reporting the complex power for each Power Interface and for each phase at a Power Interface. in addition to the real power, at least two of the following three quantities need to be reported: apparent power, reactive power, and phase angle. the phase angle can be substituted by the power factor 🦋 math bestie energy, I'm obsessed 😭

5.3.8. Actual AC Frequency 🌊

the standard must provide means for reporting the actual AC frequency for each Power Interface 🎵

5.3.9. Total Harmonic Distortion 〰️

the standard must provide means for reporting the Total Harmonic Distortion (THD) of voltage and current for each Power Interface. for AC power supply, means must be provided for reporting the THD per phase 🌸

5.3.10. Power Supply Impedance 🧱

the standard must provide means for reporting the impedance of a power supply for each Power Interface. for AC power supply, means must be provided for reporting the impedance per phase 💜

5.4. Power State 🌙

many entities have a limited number of discrete Power States 🔢 it's like a short playlist of modes, but make it energy 🎧

there's a need to report the actual Power State of an entity, and to provide the means for retrieving the list of all supported Power States 📝

different standards bodies have already defined sets of Power States for some entities, and others are making new ones 🌈 in this context, it's desirable that the standard supports many of these Power State standards 🫶 to support multiple management systems that might use different Power State sets while talking to the same entity at the same time, the Energy Management System must provide means for supporting multiple Power State sets used simultaneously at an entity 🧚

Power States have parameters that describe their properties 🎀 it's required to have a standardized means for reporting some key properties, like the typical power of an entity in a certain state 🔑

there's also a need to report statistics on Power States, including the time spent in them, as well as the received and provided energy in a Power State 📈 the stats are giving, bestie 💅

5.4.1. Actual Power State ✅

the standard must provide means for reporting the actual Power State of an entity.

5.4.2. List of Supported Power States 📜

the standard must provide means for retrieving the list of all potential Power States of an entity.

5.4.3. Multiple Power State Sets 🎭

the standard must provide means for supporting multiple Power State sets simultaneously at an entity.

5.4.4. List of Supported Power State Sets 🗂️

the standard must provide means for retrieving the list of all Power State sets supported by an entity.

5.4.5. List of Supported Power States within a Set 🧾

the standard must provide means for retrieving the list of all potential Power States of an entity for each supported Power State set.

5.4.6. Typical Power Per Power State 🔋

the standard must provide means for retrieving the typical power for each supported Power State.

5.4.7. Power State Statistics 📊

the standard must provide means for monitoring statistics per Power State, including the total time spent in a Power State, the number of times each state was entered, and the last time each state was entered. more Power State statistics are addressed by the requirements in Section 5.5.3 🔗

5.4.8. Power State Changes 🔔

the standard must provide means for generating a notification when the actual Power State of an entity changes 💖

5.5. Energy 💜

monitoring the electrical energy received or provided by an entity is a core function of Energy Management 🌟 energy is an accumulated quantity, so it's always reported for a certain interval of time ⏳ that could be, for example, the time from the last restart of the entity to the reporting time, the time from some other past event to the reporting time, the last given amount of time before the reporting time, or a certain interval specified by two timestamps in the past 🕰️ no cap, time windows are everything 🫶

it's useful for entities to record their received and provided energy per Power State and report those quantities 🎀 that way the energy story is broken down by mode, and it's so easy to follow 🦋

5.5.1. Energy Measurement ⚡

Okay bestie, the standard must provide means for reporting measured values of energy and the direction of the energy flow received or provided by an entity 💖 So basically, which way the juice is moving, in or out 🔌. It must also give you a way to report the energy passing through each Power Interface 🎀.

5.5.2. Time Intervals ⏰

The standard must provide means for reporting the time interval for which an energy value is reported. No energy number is complete without its timestamp window, obviously 🙈✨

5.5.3. Energy Per Power State 🔋

The standard must provide means for reporting the received and provided energy for each individual Power State 💅 This extends the requirements on Power State statistics from Section 5.4.7, so it's like the upgraded version with main character energy 👑

5.6. Battery State 🔋🩷

Batteries are special entities that supply power 🍓 Their status is usually handled by automatic functions running locally on the entity, and also manually by the users of that entity. Network management systems need to keep an eye on the battery status of these entities, so there's a real need there 👀

Devices with batteries can be modeled in two ways 🧚 Option one: model the entire device as a single entity and report energy-related information on it. Option two: model the battery as its own individual entity, and monitor its energy-related information individually, following the requirements in Sections 5.1 through 5.5.

Energy Management also cares about more battery info, like the current charge, the number of completed charging cycles, the charging state, its temperature, and other static and dynamic battery properties 🌈 It's also desirable to get notifications when a battery's charge gets really low, or when a battery needs to be replaced 😭

5.6.1. Battery Charge 🔋

The standard must provide means for reporting the current charge of a battery, in milliampere-hours (mAh) 💜

5.6.2. Battery Charging State ⚡

The standard must provide means for reporting the charging state (charging, discharging, etc.) of a battery 🦋

5.6.3. Battery Charging Cycles 🔁

The standard must provide means for reporting the number of completed charging cycles of a battery 🌸

5.6.4. Actual Battery Capacity 🔋

The standard must provide means for reporting the actual capacity of a battery 💖

5.6.5. Actual Battery Temperature 🌡️

The standard must provide means for reporting the actual temperature of a battery 🔥

5.6.6. Static Battery Properties 📋

The standard must provide means for reporting static properties of a battery, including the nominal capacity, the number of cells, the nominal voltage, and the battery technology ✨

5.6.7. Low Battery Charge Notification 🚨

The standard must provide means for generating a notification when the charge of a battery decreases below a given threshold 😱 Quick note, the threshold may depend on the battery technology, so don't assume one number fits every battery 🙈

5.6.8. Battery Replacement Notification 🔧

The standard must provide means for generating a notification when the number of charging cycles of a battery exceeds a given threshold 🫶

5.6.9. Multiple Batteries 🔋🔋

If the battery technology allows it, the standard must provide means for meeting the requirements in Sections 5.6.1 through 5.6.8 for each individual battery contained in a single entity 🌟 Double the batteries, double the vibes 💅

5.7. Time Series of Measured Values 📈

For some network management tasks, you need time series of measured values from entities, like power, energy, battery charge, and so on 💫

There are lots of ways to get time series measurements 🧁 The standard should provide a way to either push those values from where they live to the management system, or to store them locally for long enough that a management system can pull the full time series back out 📦

When you're designing time series measurement and reporting functions, these are the questions to think about 🤔

Which quantities should be reported?
Which time interval type should be used (total, delta, sliding window)?
Which measurement method should be used (sampled, continuous)?
Which reporting model should be used (push or pull)?

Energy is the most talked-about and probably most needed quantity 💖 But power and battery charge are needed too, so keep them in mind ✨

There are three time interval types being discussed for accumulated quantities like energy 🎀 The first is total values, accumulated between the last restart of the measurement and a given timestamp. The second is delta values between two consecutive timestamps. The third is reporting values for sliding windows, as specified in [IEC.61850-7-4].

For non-accumulative quantities, like power, there are different measurement methods to consider 🌈 You can report values sampled at certain timestamps, or you can report mean values averaged between two (consecutive) timestamps or over a sliding window.

Time series can also use different reporting models, mainly push-based or pull-based 🦋 Push-based reporting can be done by reporting power or energy values with the IP Flow Information Export (IPFIX) protocol [RFC7011] [RFC7012]. The Simple Network Management Protocol (SNMP) [RFC3411] is an example of a protocol that can be used for pull-based reporting of time series 🧚

For reporting time series of measured values, the following requirements have been identified 📝 Further decisions on the issues above need to be made when developing concrete Energy Management standards, so this is just the starting point 🫶

5.7.1. Time Series of Energy Values ⚡

The standard must provide means for reporting time series of energy values 💅 If you need to compare time series across multiple entities, then time synchronization between those entities must be provided, for example with the Network Time Protocol [RFC5905] ⏰

5.7.2. Time Series Interval Types 🕰️

The standard must provide means for supporting alternative interval types 🌸 The requirement in Section 5.5.2 applies to every reported time value, so no timestamp gets left out 💖

5.7.3. Time Series Storage Capacity 💾

The standard should provide means for reporting the number of values of a time series that can be stored for later reporting 🧁

6. Control of Entities 🎮

Lots of entities control their Power State locally, all on their own 🤖 Other entities need interfaces so an Energy Management System can control their Power State 👑

A power supply usually isn't self-managed by the devices themselves, and controlling a power supply usually isn't an interaction between an Energy Management System and the device itself 🙅‍♀️ It's more of an interaction between the management system and the device that provides power at its Power Outlets 🔌 Just like Power State control, power supply control may be policy driven 📋 And be careful, because shutting down the power supply abruptly may have severe consequences for the device 😭🚨

6.1. Controlling Power States 🎛️

The standard must provide means for setting Power States of entities 💖

6.2. Controlling Power Supply 🔌

The standard must provide means for switching a power supply off or turning a power supply on at Power Interfaces that provide power to one or more devices ✨

7. Reporting on Other Entities 👀

As discussed in Section 5, not all energy-related information may be available at the entity in question 🙈 Sometimes that info comes from other entities instead. This section only covers reporting information. For requirements on controlling other entities, see Section 8 🫶

Sometimes a power supply unit switches power for several entities by turning power on or off at a single Power Outlet 🔌 Other times a power meter measures the accumulated power of several entities on a single power line ⚡ So it should be possible to report that a monitored value doesn't relate to just one entity, but is an accumulated value for a set of entities 🌈 All the entities in that set need to be identified 🧚

7.1. Reports on Other Entities 📣

The standard must provide means for an entity to report information on another entity 💅

7.2. Identity of Other Entities on Which Information Is Reported 🪪

For entities that report on one or more other entities, the standard must provide means for reporting the identity of the other entities on which information is reported 💖 Heads up, in some situations a manual configuration might be required to fill in this information 🙃

7.3. Reporting Quantities Accumulated over Multiple Entities ➕

The standard must provide means for reporting the list of all entities that contribute to an accumulated value ✨

7.4. List of All Entities on Which Information Is Reported 📜

For entities that report on one or more other entities, the standard must provide means for reporting the complete list of all those entities on which energy-related information can be reported 🦋

7.5. Content of Reports on Other Entities 🗂️

For entities that report on one or more other entities, the standard must provide means for indicating what type or types of energy-related information can be reported, and for which entities 🌸

8. Controlling Other Entities 🎛️✨

This section lays out requirements for controlling Power States and power supply of entities by talking to other entities that have the means to do that control 🫶

8.1. Controlling Power States of Other Entities 🔐

Some entities have control over the Power States of other entities 👑 For example, a gateway to a building system may be able to control the Power State of entities in the building that don't have an IP interface 🏢 For this scenario and other similar cases, the Energy Management System needs a way to access that control 💅

It's also required that an entity whose state is controlled by other entities can report the list of those other entities 📋

8.1.1. Control of Power States of Other Entities 🎮

The standard must provide means for an Energy Management System to send Power State control commands to an entity that controls the Power States of entities other than the entity the command was sent to 🚀

8.1.2. Identity of Other Power State Controlled Entities 🪪

The standard must provide means for reporting the identities of the entities for which the reporting entity has the means to control their Power States 💖 Again, in some situations a manual configuration might be required to populate this information 🙃

8.1.3. List of All Power State Controlled Entities 📜

The standard must provide means for an entity to report the list of all entities for which it can control the Power State 🌈

8.1.4. List of All Power State Controllers 🗝️

The standard must provide means for an entity that receives commands controlling its Power State from other entities to report the list of all those entities 🧚

8.2. Controlling Power Supply 🔌

Some entities may control the power supply of other entities, for example because the other entity is supplied via a Power Outlet of the entity 🙌 For this and similar cases, means are needed to make that control accessible to the Energy Management System 🫶 This need is already covered by the requirement in Section 6.2 ✨

It's also required that an entity whose supply is controlled by other entities can report the list of those other entities 📋 This need is already addressed by the requirements in Sections 5.2.3 and 5.2.4 💅

9. Security Considerations 🔒✨

Okay bestie, this section is the most important one 😭 Controlling the power state and power supply of entities is seriously sensitive stuff, because it can mess with everything plugged into it and connected to it 💀. So all the control actions in Sections 6 and 8 must be protected with authentication, authorization, and integrity protection mechanisms 🫶

Some entities are not secure enough to live directly on the public Internet, and that's a real risk if the remote control functions in Sections 6 and 8 can be reached from literally anywhere on the Internet 🙈 The standard needs to give us ways to deal with that. One fix is isolating those devices, for example by putting them behind a properly secured gateway 🚧 Another fix is letting compliant implementations turn off sensitive functions, or just not implement them at all 💅

Monitoring energy-related quantities of an entity, as covered in Sections 5 through 8, can reveal way more than just how much energy came in and went out 👀 So monitored data requires protection. That means authentication and authorization for anyone asking to access it, plus confidentiality while it's being transmitted 🔐 Privacy of stored data in an entity must be taken into account too. And since monitored data may be used as input for control, accounting, and other actions, integrity of transmitted information and authentication of the origin may be needed 🦋

9.1. Secure Energy Management

The standard must provide privacy, integrity, and authentication mechanisms for all actions covered in Sections 5 through 8 ✨ Those security mechanisms must meet the security requirements detailed in Section 1.4 of [RFC3411] 🎀

9.2. Isolation of Insufficiently Secure Entities

The standard must provide ways to isolate entities that aren't secure enough to operate on the public Internet 🧱 For example, that could mean putting them behind a gateway with enough security that the vulnerable entities are never directly exposed to the Internet 🌸

9.3. Optional Restriction of Functions

The standard must let compliant implementations disable sensitive functions, or skip implementing them entirely, when they're running in environments that aren't sufficiently secured 🙅‍♀️ This especially applies to the control functions described in Sections 6 and 8 💜

10. Acknowledgments 🫶🌈

The authors want to thank Ralf Wolter for his first essay on this document 📝 Huge thanks to William Mielke, John Parello, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff for their super helpful comments 🍓 Thanks also to Stephen Farrell, Robert Sparks, Adrian Farrel, Barry Leiba, Brian Haberman, Peter Resnick, Sean Turner, Stewart Bryant, and Ralph Droms for their IESG reviews 👑 And special shoutouts to the document shepherd, Nevil Brownlee, and to the EMAN working group chairs, Nevil Brownlee and Bruce Nordman 🧚

11. References 📚

11.1. Normative References

[ANSI-TIA-1057]: Telecommunications Industry Association, ANSI-TIA-1057-2006, "TIA Standard -- Telecommunications -- IP Telephony Infrastructure -- Link Layer Discovery Protocol for Media Endpoint Devices", April 2006.
[IEC.61850-7-4]: International Electrotechnical Commission, "Communication networks and systems for power utility automation -- Part 7-4: Basic communication structure -- Compatible logical node classes and data object classes", March 2010.
[IEC.62053-21]: International Electrotechnical Commission, "Electricity metering equipment (a.c.) -- Particular requirements -- Part 21: Static meters for active energy (classes 1 and 2)", January 2003.
[IEC.62053-22]: International Electrotechnical Commission, "Electricity metering equipment (a.c.) -- Particular requirements -- Part 22: Static meters for active energy (classes 0,2 S and 0,5 S)", January 2003.
[IEEE-100]: IEEE, "The Authoritative Dictionary of IEEE Standards Terms, IEEE 100, Seventh Edition", December 2000.
[IEEE-1621]: Institute of Electrical and Electronics Engineers, "IEEE 1621-2004 - IEEE Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", 2004.
[IEEE-802.1AB]: IEEE Computer Society, "IEEE Std 802.1AB-2009 -- IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Discovery", September 2009.
[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.
[RFC3621]: Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003.
[RFC6933]: Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013.

11.2. Informative References

[EMAN-STATEMENT]: Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", Work in Progress, April 2013.
[IEC.60050]: International Electrotechnical Commission, "Electropedia: The World's Online Electrotechnical Vocabulary", 2013, <http://www.electropedia.org/iev/iev.nsf/welcome?openform>.
[ITU-M.3400]: International Telecommunication Union, "ITU-T Recommendation M.3400 -- Series M: TMN and Network Maintenance: International Transmission Systems, Telephone Circuits, Telegraphy, Facsimile and Leased Circuits -- Telecommunications Management Network - TMN management functions", February 2000.
[RFC7011]: Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7012]: Claise, B., Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC5905]: Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

Authors' Addresses 💌

Juergen Quittek (editor)
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Phone: +49 6221 4342-115
EMail: quittek@neclab.eu


Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore
India

Phone: +91 80 4426 3947
EMail: moulchan@cisco.com


Rolf Winter
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Phone: +49 6221 4342-121
EMail: Rolf.Winter@neclab.eu

Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg  69115
Germany

Phone: +49 6221 4342-128
EMail: Thomas.Dietz@neclab.eu


Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem  1831
Belgium

Phone: +32 2 704 5622
EMail: bclaise@cisco.com

That's the whole RFC, bestie! 🌈💖 Thanks for hanging in there with me 🧚✨

📦 where this page comes from

ietf: rfc6988 2013-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms