Framework for Energy Efficiency Management
draft-belmq-green-framework-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Benoît Claise , Luis M. Contreras , Jan Lindblad , Marisol Palmero , Emile Stephan , Qin Wu | ||
| Last updated | 2025-06-13 (Latest revision 2025-05-19) | ||
| Replaced by | draft-ietf-green-framework | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-belmq-green-framework-03
Getting Ready for Energy-Efficient Networking B. Claise
Internet-Draft Huawei
Intended status: Informational L. M. Contreras
Expires: 15 December 2025 Telefonica
J. Lindblad
All For Eco
M. Palmero
Cisco Systems, Inc.
E. Stephan
Orange
Q. Wu
Huawei
13 June 2025
Framework for Energy Efficiency Management
draft-belmq-green-framework-03
Abstract
Recognizing the urgent need for energy efficiency, this document
specifies a management framework focused on devices and device
components within, or connected to, interconnected systems. The
framework aims to enable energy usage optimization, based on the
network condition while achieving the network's functional and
performance requirements (e.g., improving overall network
utilization) and also ensure interoperability across diverse systems.
Leveraging data from existing use cases, it delivers actionable
metrics to support effective energy management and informed decision-
making. Furthermore, the framework proposes mechanisms for
representing and organizing timestamped telemetry data using YANG
models and metadata, enabling transparent and reliable monitoring.
This structured approach facilitates improved energy efficiency
through consistent energy management practices.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://marisolpalmero.github.io/draft-belm-green-framework/draft-
belmq-green-framework.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-belmq-green-
framework/.
Claise, et al. Expires 15 December 2025 [Page 1]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
Discussion of this document takes place on the Getting Ready for
Energy-Efficient Networking mailing list (mailto:green@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/green/.
Subscribe at https://www.ietf.org/mailman/listinfo/green/.
Source for this draft and an issue tracker can be found at
https://github.com/marisolpalmero/draft-belm-green-framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 December 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Impact on Energy Metrics . . . . . . . . . . . . . . . . 7
3.2. Current Device Readiness . . . . . . . . . . . . . . . . 7
3.3. Why Now? . . . . . . . . . . . . . . . . . . . . . . . . 7
Claise, et al. Expires 15 December 2025 [Page 2]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Typical Power Topologies . . . . . . . . . . . . . . . . 11
4.1.1. Basic Power Supply . . . . . . . . . . . . . . . . . 11
4.1.2. Physical Meter with Legacy Device . . . . . . . . . . 12
4.1.3. Physical Meter with New Device . . . . . . . . . . . 14
4.1.4. Power over Ethernet . . . . . . . . . . . . . . . . . 16
4.1.5. Single Power Supply with Multiple Devices . . . . . . 17
4.1.6. Multiple Power Supplies with Single Device . . . . . 19
4.2. Relationships . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Power State Set . . . . . . . . . . . . . . . . . . . . . 21
5. Conventions and Definitions . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. TO DO
* IEC60050 reference needs a new URL
2. Introduction
In reference to [I-D.stephan-green-use-cases], analyzing use cases
such as the "Incremental Application of the GREEN Framework" and
"Consideration of other domains for obtention of end-to-end metrics",
it reveals the critical need for a structured approach to
transitioning network devices' management towards energy-efficient
operations. The framework is essential for:
* Standardization: Ensuring consistent practices across different
devices and network segments to facilitate interoperability.
* Energy Efficiency Management: Providing guidelines to identify
inefficiencies, look for the balance between energy usage and
network/resource/component/capability utilization and implement
improvements.
* Scalability: Offering solutions that accommodate growing network
demands and complexity.
Claise, et al. Expires 15 December 2025 [Page 3]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
* Cost Reduction: Optimizing energy usage to lower operational costs
and extend equipment lifecycles.
* Competitiveness: Enabling organizations to maintain a competitive
infrastructure through enhanced sustainability.
* Environmental Impact: Supporting broader sustainability
initiatives by reducing carbon footprints.
* Simplified Implementation: Streamlining the deployment of energy-
efficient measures to minimize service disruptions.
* Security: Protecting sensitive operations related to power states
and consumption.
This document defines an Energy Management framework for devices
within, or connected to, communication networks, for the use cases
described in [I-D.stephan-green-use-cases]. The devices, or the
components of these devices (such as line cards, fans, and disks),
can then be monitored and controlled. Monitoring includes
measuring power, energy, demand, and attributes of power. Energy
Control can be performed by setting a device's or component's
state. The devices monitored by this framework can be either of
the following:
- consumers of energy (such as routers and computer systems) and
components of such devices (such as line cards, fans, and
disks)
- producers of energy (like an uninterruptible power supply or
renewable energy system) and their associated components (such
as battery cells, inverters, or photovoltaic panels)
The framework introduces the concept of a Power Interface that is
analogous to a network interface. A Power Interface is defined as
an interconnection among devices where energy can be provided,
received, or both.
Claise, et al. Expires 15 December 2025 [Page 4]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
The most basic example of Energy Management is a single device
reporting information about itself. In many cases, however,
energy is not measured by the device itself but is measured
upstream in the power distribution tree. For example, a Power
Distribution Unit (PDU) may measure the energy it supplies to
attached devices and report this to an Energy Management System.
Therefore, devices often have relationships to other devices or
components in the power network. An Energy Management System
(EnMS) generally requires an understanding of the power topology
(who provides power to whom), the Metering topology (who meters
whom), and the potential Aggregation (who aggregates values of
others).
The relationships build on the Power Interface concept. The
different relationships among devices and components, as specified
in this document, include power source, Metering, and Aggregation
Relationships.
The framework does not cover non-electrical equipment, nor does it
cover energy procurement and manufacturing.
2.1. Terminology
The following terms are defined in [I-D.draft-bclp-green-terminology]
and EMAN Framework [RFC7326]: Energy, Power, Energy Management,
Energy Monitoring, Energy Control.
The following terms are defined in EMAN Framework [RFC7326], and cut/
paste here for completeness:
Energy Management System (EnMS) An Energy Management System is a
combination of hardware and software used to administer a network,
with the primary purpose of Energy Management.
Claise, et al. Expires 15 December 2025 [Page 5]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
NOTES:
1. An Energy Management System according to [ISO50001] (ISO-EnMS)
is a set of systems or procedures upon which organizations can
develop and implement an energy policy, set targets and action
plans, and take into account legal requirements related to
energy use. An ISO-EnMS allows organizations to improve energy
performance and demonstrate conformity to requirements,
standards, and/or legal requirements.
2. Example ISO-EnMS: Company A defines a set of policies and
procedures indicating that there should exist multiple
computerized systems that will poll energy measurements from
their meters and pricing / source data from their local
utility. Company A specifies that their CFO (Chief Financial
Officer) should collect information and summarize it quarterly
to be sent to an accounting firm to produce carbon accounting
reporting as required by their local government.
3. For the purposes of EMAN, the definition herein is the
preferred meaning of an EnMS. The definition from [ISO50001]
can be referred to as an ISO Energy Management System
(ISO-EnMS).
Device A device is a piece of electrical or non-electrical
equipment. _Reference: Adapted from [IEEE100]._
Component A component is a part of electrical or non-electrical
equipment (device). _Reference: Adapted from [TMN]._
Meter (Energy Meter) A meter is a device intended to measure
electrical energy by integrating power with respect to time.
_Reference: Adapted from [IEC60050]._
Power Inlet A power inlet (or simply "inlet") is an interface at
which a device or component receives energy from another device or
component.
Power Outlet A power outlet (or simply "outlet") is an interface at
which a device or component provides energy to another device or
component.
Power Interface A Power Interface is a power inlet, outlet, or both.
Power State A Power State is a condition or mode of a device (or
component) that broadly characterizes its capabilities, power, and
responsiveness to input. _Reference: Adapted from [IEEE1621]._
Claise, et al. Expires 15 December 2025 [Page 6]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
Power State Set A Power State Set is a collection of Power States
that comprises a named or logical control grouping.
Energy Object An Energy Object represents a piece of equipment that
is part of, or attached to, a communications network that is
monitored or controlled or that aids in the management of another
device for Energy Management.
3. Motivation
3.1. Impact on Energy Metrics
The framework will significantly enhance the creation of energy
metrics with actionable insights by:
* Standardizing Metrics: Establishing consistent measurement
protocols for energy consumption and efficiency.
* Enhancing Data Collection: Facilitating comprehensive monitoring
and data aggregation across devices.
* Supporting Real-time Monitoring: Enabling dynamic tracking and
immediate optimization of energy usage.
* Integration Across Devices: Ensuring interoperability for network-
wide data analysis.
* Providing Actionable Insights: Translating raw data into
meaningful information for decision-making.
3.2. Current Device Readiness
While many modern networking devices have basic energy monitoring
capabilities, these are often proprietary. The framework will define
requirements to enhance these capabilities, enabling standardized
metric production and meaningful data contributions for energy
management goals.
3.3. Why Now?
The decision to define the framework now, rather than later, is
driven by:
* Immediate Benefits: Start realizing cost savings, reduced carbon
footprints, and improved efficiencies.
* Rapid Technological Advancements: Aligning the framework with
current technologies to prevent obsolescence.
Claise, et al. Expires 15 December 2025 [Page 7]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
* Increasing Energy Demands: Mitigating the impact of growing energy
consumption on costs and sustainability.
* Regulatory Pressure: Preparing for compliance with existing and
anticipated sustainability regulations.
* Competitive Advantage: Positioning organizations as leaders in
sustainability and innovation.
* Foundational Work Ready: Building on the use cases and
requirements established in Phase I.
* Proactive Risk Management: Minimizing risks associated with energy
costs and environmental factors.
* Facilitate Future Innovations: Creating a platform for continuous
improvements and adaptations.
* Stakeholder Engagement: Ensuring diverse perspectives are
reflected for broader adoption.
In conclusion, establishing the framework for energy efficiency
management now is strategic and timely, leveraging the current
momentum of use cases and requirements to drive meaningful progress
in energy efficiency management. Delaying its development could
result in missed opportunities for immediate benefits, increased
costs, and challenges in adapting to future technological and
regulatory landscapes.
4. Reference Model
The framework introduces the concept of a Power Interface. A Power
Interface is defined as an interconnection among devices where energy
can be provided, received, or both. There are some similarities
between Power Interfaces and network interfaces. A network interface
can be set to different states, such as sending or receiving data on
an attached line. Similarly, a Power Interface can be receiving or
providing energy.
Claise, et al. Expires 15 December 2025 [Page 8]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
The most basic example of Energy Management is a single device
reporting information about itself. In many cases, however, energy
is not measured by the device itself but is measured upstream in the
power distribution tree. For example, a Power Distribution Unit
(PDU) may measure the energy it supplies to attached devices and
report this to an Energy Management System. Therefore, devices often
have relationships to other devices or components in the power
network. An Energy Management System (EnMS) generally requires an
understanding of the power topology (who provides power to whom), the
Metering topology (who meters whom), and the potential Aggregation
(who aggregates values of others).
The relationships build on the Power Interface concept. The
different relationships among devices and components, as specified in
this document, include power source, Metering, and Aggregation
Relationships.
The framework does not cover non-electrical equipment, nor does it
cover energy procurement and manufacturing.
Claise, et al. Expires 15 December 2025 [Page 9]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ |
(d) | (e) | (f) | |
Inventory | Monitor power | Control | |
Capability | Proportion | (Energy saving | |
| Energy efficiency| Functionality | |
| ratio, power | Localized mgmt/ | |
| consumption, | network wide mgmt) | |
| etc) | | |
| | | v
+--------------------------------------------------------------------+
| |
| (1) Device/Component |
| |
| +---------+ +-----------+ +----------------+ +----------------+ |
| | (I) | | (II) | | (III) | | (IV) | |
| | | | | | Legacy | | 'Attached'(PoE | |
| | Device | | Component | | Device | | end Point) | |
| | | | | | | | | |
| +---------+ +-----------+ +----------------+ +----------------+ |
+--------------------------------------------------------------------+
Figure 1: GREEN Reference Model
The main elements in the framework are as follows:
Claise, et al. Expires 15 December 2025 [Page 10]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
* (a), (d) Discovery and Inventory
* (b), (c) GREEN Metrics
* (b), (e) Monitor energy efficiency
* (f) Control Energy Saving
The monitoring interface (e) obviously monitor more aspects than just
power and energy, (for example traffic monitoring) but this is not
covered in the framework.
Note that this framework specificies logical blocks, however, the
Energy Efficiency Management Function might be implemented inside the
device or in the controller or a combination of both.
4.1. Typical Power Topologies
The following reference model describes physical power topologies
that exist in parallel with a communication topology. While many
more topologies can be created with a combination of devices, the
following are some basic ones that show how Energy Management
topologies differ from Network Management topologies. Only the
controller, devices and components, are depicted here, as the Network
Domain Level remains identical.
NOTE:
* "###" is used to denote a transfer of energy.
* "- >" is used to denote a transfer of information.
4.1.1. Basic Power Supply
This covers the basic example of router connected to Power Outlet in
the wall.
Claise, et al. Expires 15 December 2025 [Page 11]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ |
| | | |
(d) (e) (f)
| | | |
| | v
+--------------+ +------------------+
| | | |
| Power Supply |############| Device/Component |
| | | |
+--------------+ +------------------+
Figure 2: Reference Model Example: Basic Power Supply
4.1.2. Physical Meter with Legacy Device
This covers the basic example of device connected to wall Power
Outlet, with a Physical Meter placed in the wall Power Outlet,
because the device can not monitor its power, energy, demand.
Claise, et al. Expires 15 December 2025 [Page 12]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^
|
(e)
|
|
+--------------+ +----------------+ +---------------+
| | | | | |
| Power Supply |###| Physical Meter |###| Legacy Device |
| | | | | |
+--------------+ +----------------+ +---------------+
Figure 3: Reference Model Example: Physical Meter
When the EnMS discovers the physical meter, it must know for which
Energy Object(s) it measures power or energy. This is the Metering
Relatonship.
Claise, et al. Expires 15 December 2025 [Page 13]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
A Metering Relationship is a relationship where one Energy Object
measures power, energy, demand, or Power Attributes of one or more
other Energy Objects. The Metering Relationship gives the view of
the Metering topology. Physical meters can be placed anywhere in a
power distribution tree. For example, utility meters monitor and
report accumulated power consumption of the entire building.
Logically, the Metering topology overlaps with the wiring topology,
as meters are connected to the wiring topology. A typical example is
meters that clamp onto the existing wiring.
4.1.3. Physical Meter with New Device
This covers the example of device connected to wall Power Outlet,
with a Physical Meter placed in the wall Power Outlet, because the
device can not monitor its power, energy, demand.
Claise, et al. Expires 15 December 2025 [Page 14]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ ^ |
| | | | |
(e) (d) (e) (f)
| | | | |
| | | v
+--------------+ +----------------+ +------------------+
| | | | | |
| Power Supply |###| Physical Meter |###| Device/Component |
| | | | | |
+--------------+ +----------------+ +------------------+
Figure 4: Reference Model Example: Physical Meter with New Device
The most important issue in such a topology is to avoid the double
counting in the Energy Management System (EnMS). The physical meter
reports the Energy transmitted, while the connected Device/Component
might also report its consumed Energy. Those two values are
identical. Without the knowledge of this specific topology, that is
the Metering Relationship between the two Energy Objects, the EnMS
will double count the Energy consumed in the network.
Claise, et al. Expires 15 December 2025 [Page 15]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
4.1.4. Power over Ethernet
This covers the example of a switch port (Power Outlet) the provides
energy with Power over Ethernet (PoE) to a PoE end points (camera,
access port, etc.).
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ | ^ ^ ^ |
| | | | | | | |
(d) (e) (f) (d) (e) (f)
| | | | | | | |
| | v | | v
+--------------+ +----------------+
| | | |
| Device |############| PoE End Point |
| (switch) | | |
| | | |
+--------------+ +----------------+
Figure 5: Reference Model Example: Power over Ethernet
Double counting is also an issue in such an example. The switch
port, via its Power Outlet, reports the Energy transmitted, while the
PoE End Point, via its Power Inlet, reports its Energy consumed.
Claise, et al. Expires 15 December 2025 [Page 16]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
A second issue in such an example is the control topology. The
controller must have the knowledge that, if it shuts down the switch
port, it will also switch off the connected PoE End Point, as a
consequence. This is the Power Source Relationship.
A Power Source Relationship is a relationship where one Energy Object
provides power to one or more Energy Objects. The Power Source
Relationship gives a view of the physical wiring topology -- for
example, a PoE End Point receiving power from a switch port over PoE
or a data center server receiving power from two specific Power
Interfaces from two different PDUs.
On top of that, there might be two control points for the PoE End
Point. First the connected switch port but also the controller
direct connection to the PoE End Point (f). Via this interface, the
controller might for example put the PoE End Point to a lower Power
State.
4.1.5. Single Power Supply with Multiple Devices
This covers the example of a smart PDU that provides energy to a
series of routers in a rack.
Claise, et al. Expires 15 December 2025 [Page 17]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ | ^ ^ ^ |
| | | | | | | |
(d) (e) (f) (d) (e) (f) ... N
| | | | | | | |
| | v | | v
+--------------+ +--------------------+
| | | |
| Power Supply |############| Device/Component 1 |
| (Smart PDU) | # | |
| | # +--------------------+
+--------------+ #
#
# +--------------------+
# | |
##########| Device/Component 2 |
# | |
# +--------------------+
#
# +--------------------+
# | |
#######| Device/Component N |
| |
+--------------------+
Claise, et al. Expires 15 December 2025 [Page 18]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
Figure 6: Reference Model Example: Single Power Supply with
Multiple Devices
4.1.6. Multiple Power Supplies with Single Device
+--------------------------------------------------------------------+
| |
| (3) Network Domain Level |
| |
+--------------------------------------------------------------------+
(a) (b) (c)
Inventory Monitor +- DataSheets/DataBase and/or via API
Of identity Energy | Metadata and other device/component
and Capability Efficiency | /network related information:
^ ^ |
| | | .Power/Energy related metrics
| | | .information
| | | .origin of Energy Mix
| | | .carbon aware based on location
| | |
| | |
| | |
| | v
+--------------------------------------------------------------------+
| |
| (2) controller (collection, compute and aggregate?) |
| |
+--------------------------------------------------------------------+
^ ^ ^ | ^ ^ ^ | ^ ^ ^ |
| | | | | | | | | | | |
(d) (e) (f) (d) (e) (f) (d) (e) (f)
| | | | | | | | | | | |
| | v | | v | | v
+----------------+ +------------------+ +----------------+
| | | | | |
| Power Supply 1 |######| Device/Component |######| Power Supply 2 |
| | | | | |
+----------------+ +------------------+ +----------------+
Figure 7: Reference Model Example: Multiple Power Supplies with
Single Device
Claise, et al. Expires 15 December 2025 [Page 19]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
4.2. Relationships
The framework for Energy Management need to describe a means to
monitor and control devices and components, and it needs to describe
the relationships among, and connections between, devices and
components.
Two Energy Objects can establish an Energy Object Relationship to
model the deployment topology with respect to Energy Management.
Relationships are modeled with a Relationship that contains the UUID
of the other participant in the relationship, along with a
Relationship type.
There are three types of relationships are Power Source, Metering,
and Aggregations.
* A Power Source Relationship is a relationship where one Energy
Object provides power to one or more Energy Objects. The Power
Source Relationship gives a view of the physical wiring topology
-- for example, a data center server receiving power from two
specific Power Interfaces from two different PDUs.
Note: A Power Source Relationship may or may not change as the
direction of power changes between two Energy Objects. The
relationship may remain to indicate that the change of power
direction was unintended or an error condition.
* A Metering Relationship is a relationship where one Energy Object
measures power, energy, demand, or Power Attributes of one or more
other Energy Objects. The Metering Relationship gives the view of
the Metering topology. Physical meters can be placed anywhere in
a power distribution tree. For example, utility meters monitor
and report accumulated power consumption of the entire building.
Logically, the Metering topology overlaps with the wiring
topology, as meters are connected to the wiring topology. A
typical example is meters that clamp onto the existing wiring.
* An Aggregation Relationship is a relationship where one Energy
Object aggregates Energy Management information of one or more
other Energy Objects. The Aggregation Relationship gives a model
of devices that may aggregate (sum, average, etc.) values for
other devices. The Aggregation Relationship is slightly different
compared to the other relationships, as this refers more to a
management function.
Claise, et al. Expires 15 December 2025 [Page 20]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
In some situations, it is not possible to discover the Energy Object
Relationships, and an EnMS or administrator must manually set them.
Given that relationships can be assigned manually, the following
sections describe guidelines for use.
4.3. Power State Set
The Energy Object contains a Power State Set attribute that
represents the set of Power States a device or component supports.
A Power State describes a condition or mode of a device or component.
While Power States are typically used for control, they may be used
for monitoring only.
A device or component is expected to support at least one set of
Power States consisting of at least two states: an on state and an
off state.
The semantics of a Power State are specified by:
* The functionality provided by an Energy Object in this state.
* A limitation of the power that an Energy Object uses in this
state.
* A combination of the first two.
The semantics of a Power State should be clearly defined. Limitation
(curtailment) of the power used by an Energy Object in a state may be
specified by:
* An absolute power value.
* A percentage value of power relative to the Energy Object's
Nameplate Power.
* An indication of power relative to another Power State. For
example, specify that power in state A is less than in state B.
* For supporting Power State management, an Energy Object provides
statistics on Power States, including the time an Energy Object
spent in a certain Power State and the number of times an Energy
Object entered a Power State.
There are many existing standards describing device and component
Power States. TO BE COMPLETED
Claise, et al. Expires 15 December 2025 [Page 21]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
5. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
6. Security Considerations
Resiliency is an implicit use case of energy efficiency management
which comes with numerous security considerations :
Controlling Power State and power supply of entities are considered
highly sensitive actions, since they can significantly affect the
operation of directly and indirectly connected devices. Therefore,
all control actions must be sufficiently protected through
authentication, authorization, and integrity protection mechanisms.
Entities that are not sufficiently secure to operate directly on the
public Internet do exist and can be a significant cause of risk, for
example, if the remote control functions can be exercised on those
devices from anywhere on the Internet.
The monitoring of energy-related quantities of an entity as addressed
can be used to derive more information than just the received and
provided energy; therefore, monitored data requires protection. This
protection includes authentication and authorization of entities
requesting access to monitored data as well as confidentiality
protection during transmission of monitored data. Privacy of stored
data in an entity must be taken into account. Monitored data may be
used as input to control, accounting, and other actions, so integrity
of transmitted information and authentication of the origin may be
needed.
7. IANA Considerations
This document has no IANA actions.
8. Acknowledgments
This framework takes into account concepts from the Energy MANagement
(EMAN) Framework [RFC7326], authors by John Parello, Benoit Claise,
Brad Schoening, and Juergen Quittek. The contribution of Luis M.
Contreras to this document has been supported by the Smart Networks
and Services Joint Undertaking (SNS JU) under the European Union's
Horizon Europe research and innovation projects 6Green (Grant
Agreement no. 101096925) and Exigence (Grant Agreement no.
Claise, et al. Expires 15 December 2025 [Page 22]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
101139120).
9. References
9.1. Normative References
9.2. Informative References
10. Appendix
This appendix should be removed when the initial set of GREEN WG
documents will be stable
11. References
11.1. Normative References
[I-D.draft-bclp-green-terminology]
Liu, P. C., Boucadair, M., Wu, Q., Contreras, L. M., and
M. P. Palmero, "Terminology for Energy Efficiency Network
Management", Work in Progress, Internet-Draft, draft-bclp-
green-terminology-01, 23 April 2025,
<https://datatracker.ietf.org/doc/html/draft-bclp-green-
terminology-01>.
[I-D.stephan-green-use-cases]
Stephan, E., Palmero, M. P., Claise, B., Wu, Q.,
Contreras, L. M., and C. J. Bernardos, "Use Cases for
Energy Efficiency Management", Work in Progress, Internet-
Draft, draft-stephan-green-use-cases-01, 16 May 2025,
<https://datatracker.ietf.org/doc/html/draft-stephan-
green-use-cases-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
11.2. Informative References
[IEC60050] IEC, "Power Utility Automation", 11 December 2000,
<http://www.iec.ch/smartgrid/standards/>.
Claise, et al. Expires 15 December 2025 [Page 23]
Internet-Draft Framework for Energy Efficiency Manageme June 2025
[IEEE100] IEEE, "The Authoritative Dictionary of IEEE Standards
Terms", 11 December 2000, <http://ieeexplore.ieee.org/xpl/
mostRecentIssue.jsp?punumber=4116785>.
[IEEE1621] IEEE, "Standard for User Interface Elements in Power
Control of Electronic Devices Employed in Office/Consumer
Environments, IEEE 1621", December 2004.
[RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek,
"Energy Management Framework", RFC 7326,
DOI 10.17487/RFC7326, September 2014,
<https://www.rfc-editor.org/rfc/rfc7326>.
[TMN] "International Telecommunication Union, "TMN management
functions"", February 2000, <ITU-T Recommendation M.3400>.
Authors' Addresses
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Jan Lindblad
All For Eco
Email: jan.lindblad+ietf@for.eco
Marisol Palmero
Cisco Systems, Inc.
Email: mpalmero@cisco.com
Emile Stephan
Orange
Email: emile.stephan@orange.com
Qin Wu
Huawei
Email: bill.wu@huawei.com
Claise, et al. Expires 15 December 2025 [Page 24]