| Internet-Draft | Energy Efficiency Management Framework | February 2026 |
| Claise, et al. | Expires 7 August 2026 | [Page] |
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.¶
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/.¶
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.¶
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 7 August 2026.¶
Copyright (c) 2026 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.¶
IEC60050 reference needs a new URL¶
The following topics remain open for further discussion points:¶
Consider how long it takes for an Energy Object to switch power states.¶
Recommendation to standardize a data model for safe limits on frequency or speed of transitions to prevent device/component's damage.¶
Model SLAs that include both performance (e.g., transition time) and device safety (e.g., cycle limitations).¶
Recommendation to standardize a data model for new equipment interconnected East-West with optimized energy consumption.¶
[GreenUseCases] analyzes use cases such as "Incremental Application of the GREEN Framework" and "Consideration of other domains for end-to-end metrics," revealing the critical need for a structured approach to transitioning network device management towards energy-efficient operations. This framework addresses:¶
Standardization: Ensuring consistent practices across devices and network segments to facilitate interoperability¶
Energy Efficiency Management: Providing guidelines to identify inefficiencies, balance energy usage with network/resource/component utilization, and implement improvements¶
Scalability: Offering solutions that accommodate growing network demands and complexity¶
Cost Reduction: Optimizing energy usage to lower operational costs and extend equipment lifecycles¶
Competitiveness: Enabling organizations to maintain competitive infrastructure through enhanced sustainability¶
Environmental Impact: Supporting broader sustainability initiatives by reducing carbon footprints¶
Simplified Implementation: Streamlining deployment of energy-efficient measures to minimize service disruptions¶
Security: Protecting sensitive operations related to power states and consumption¶
This document specifies an Energy Management framework for devices within, or connected to, communication networks, addressing the use cases in [GreenUseCases].¶
The framework covers devices and components that can be monitored and controlled for energy management purposes:¶
Power consumers: Routers, switches, servers, storage systems, and their components (line cards, fans, disks, processors, GPUs)¶
Power sources: Uninterruptible power supplies (UPS), Power Distribution Units (PDUs), Power over Ethernet (PoE) switches, renewable energy systems, and their components (battery cells, inverters, photovoltaic panels)¶
Monitored entities: Any network-attached device or component with a unique identifier (UUID per [RFC8348]) that influences power or energy consumption¶
This framework defines conceptual requirements and architectural patterns for energy efficiency management. The companion YANG data model [PowerAndEnergy] provides the implementable specification, including:¶
Power and energy metric definitions and units¶
Measurement accuracy¶
Industry certification reporting (80 PLUS, Energy Star)¶
Hierarchical default value inheritance¶
Implementers should reference both documents: this framework for understanding requirements and use cases, the YANG model for implementation details and data structures.¶
The following terms are defined in [GreenTerminology] and EMAN Framework [RFC7326]: Energy, Power, Energy Object, Energy Management, Energy Monitoring, Energy Control.¶
The following terms are defined in EMAN Framework [RFC7326], and cut/paste here for completeness:¶
An Energy Management System is a combination of hardware and software used to administer a network, with the primary purpose of Energy Management.¶
NOTES: 1. An Energy Management System according to ISO50001 (ISO-EnMS) is a set of systems or procedures upon which organizations can develop and implement an energy policy, set targets and action plans, and take into account legal requirements related to energy use. An ISO-EnMS allows organizations to improve energy performance and demonstrate conformity to requirements, standards, and/or legal requirements. 2. Example ISO-EnMS: Company A defines a set of policies and procedures indicating that there should exist multiple computerized systems that will poll energy measurements from their meters and pricing / source data from their local utility. Company A specifies that their CFO (Chief Financial Officer) should collect information and summarize it quarterly to be sent to an accounting firm to produce carbon accounting reporting as required by their local government. 3. For the purposes of EMAN, the definition herein is the preferred meaning of an EnMS. The definition from ISO50001 can be referred to as an ISO Energy Management System (ISO-EnMS).¶
A device is a piece of electrical or non-electrical equipment. Reference: Adapted from [IEEE100].¶
A component is a part of electrical or non-electrical equipment (device). Reference: Adapted from [TMN].¶
A meter is a device intended to measure electrical energy by integrating power with respect to time. Reference: Adapted from [IEC60050].¶
A power inlet (or simply "inlet") is an interface at which a device or component receives energy from another device or component.¶
A power outlet (or simply "outlet") is an interface at which a device or component provides energy to another device or component.¶
A Power Interface is a power inlet, outlet, or both.¶
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].¶
A Power State Set is a collection of Power States that comprises a named or logical control grouping.¶
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.¶
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.¶
East-West Traffic Impact: Addressing the growing energy footprint of East-West traffic in data centers and distributed systems by providing a framework for measuring and optimizing energy consumption in these environments.¶
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.¶
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.¶
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.¶
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.¶
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 device(s)/component(s), as specified in this document, include power source, Metering, and Aggregation Relationships.¶
The GREEN Reference Model is represented in the Figure 1¶
The main elements in the framework are as follows:¶
(a), (d) Discovery and Inventory¶
(b), (c) GREEN Metrics¶
(b), (e) Monitor energy efficiency¶
(f) Control Energy Saving¶
(g) API Service Interface: enables access for service consumption, enabling data retrieval , control, and integration through API, e.g., [PetraApi].¶
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 the GREEN framework specificies logical blocks, however, the Energy Efficiency Management function might be implemented inside the device, based in [RFC8348], in the controller, or a combination of both.¶
Even the current reference model implicitly assume a hierarchical network structure, this assumption acknowledges that modern networks have flatter and anticipate more distributed topologies.¶
The referene model covers every network device and component that have a Unique Identifiable ID (UUID) and can represent or influence power or energy consumption. If the component can be uniquely identified, it can be modeled.¶
In scope:¶
Devices¶
Chassis,¶
Line cards, modules, ports¶
Power supply units (PSUs), fans, thermal units¶
Accelerators, GPUs, NPUs¶
Virtualized components where applicable¶
Any element providing power, energy¶
The framework recommends a push-based telemetry model for energy efficiency data collection, where network devices stream power and energy measurements to management systems rather than waiting for poll requests.¶
For energy monitoring specifically, push-based telemetry offers:¶
Temporal accuracy: Energy consumption varies over time; push models capture variations that polling might miss.¶
Reduced latency: Anomalies (power spikes, efficiency degradation) are detected immediately.¶
Network and data collection efficiency: Eliminates repetitive poll/response cycles.¶
Scalability: Controllers can subscribe once rather than poll continuously.¶
Following the YANG-Push approach, several parameters from EMAN [RFC7460] are not needed in this framework:¶
The framework supports both initiation models:¶
Energy metrics are anchored to hardware components using UUIDs from the ietf-hardware model [RFC8348]:¶
Each physical component (chassis, power supply, line card, etc.) has a stable UUID¶
Energy metrics reference these UUIDs, enabling correlation with:¶
To enable stable component identification across systems, the GREEN Framework supports dual identifiers based on [RFC8348]: controllers will need to assign their own ID during onboarding, query the device's ietf-hardware UUID, and maintain a mapping between both for cross-system correlation.¶
Energy metrics vary significantly in quality and source: some represent direct sensor measurements with known precision, others are estimates from datasheets or even machine learning predictions. To enable informed decision-making and prevent misleading comparisons, the framework requires explicit accuracy classification for all power and energy data.¶
The framework defines three primary accuracy categories:¶
Unknown Accuracy: Data accuracy cannot be determined, or measurements are unavailable due to sensor failures, powered-off components, or other operational constraints.¶
Estimated Data: Values derived through indirect methods:¶
Static estimates: From manufacturer datasheets, nameplate ratings (critical for UC 1: Incremental Deployment with legacy devices)¶
Identity: accuracy-static¶
Historic estimates: Based on prior measurements of this specific system under similar conditions¶
Identity: accuracy-historic¶
Learned estimates: Generated by machine learning models predicting consumption from workload patterns (UC 15: AI Training)¶
Identity: accuracy-learned¶
Measured Data: Direct, real-time sensor measurements with quantified precision:¶
Bronze: ±30% accuracy for typical values.¶
Silver: ±10% accuracy for typical values.¶
Gold: ±5% accuracy for typical values.¶
Red: ±2% accuracy for typical values.¶
Ones: All non-zero digits are significant/valid.¶
Percentage-based accuracy fails for small values. For example, ±5% of 0.1W is only 0.005W, which may be smaller than sensor noise. Industry standards (IEC 62053, IEC 61850-7-4) address this by specifying: Accuracy = MAX(percentage_error, absolute_threshold)¶
The absolute threshold suffixes (-1, -10, -100, -1000) refer to the unit-multiplier scale. For unit-multiplier: milli, -10 means ±10 milliwatts.¶
Example: A sensor with accuracy-measured-gold-10 reports:
- 16.25W → actual value between 16.2375W and 16.2625W (5% = 0.8125W > 0.010W threshold)
- 0.15W → actual value between 0.140W and 0.160W (5% = 0.0075W < 0.010W threshold, so ±10mW applies)¶
Explicit accuracy reporting enables:¶
Weighted aggregation: High-precision measurements carry appropriate weight when calculating network-wide energy consumption¶
Upgrade prioritization: Identify devices with low-accuracy reporting for sensor upgrades or replacement¶
Compliance validation: Automated verification against regulatory thresholds requiring specific measurement precision¶
Double-accounting prevention: Understand when PDU-level measurements (±2%) should override device estimates (±30%) to avoid counting the same energy twice (UC 13)¶
Cross-domain correlation: Map accuracy expectations when integrating with external systems like 3GPP energy KPIs (UC 6)¶
The accuracy hierarchy uses YANG identities for extensibility, allowing vendors to define manufacturer-specific accuracy classes while maintaining interoperability through standardized base types. Implementation details are provided in the companion YANG data model [PowerAndEnergy].¶
The accuracy hierarchy uses YANG identityref to allow vendor-specific extensions:
yang
identity accuracy-measured-vendor-calibrated {
base accuracy-measured;
description
"Vendor-specific calibrated sensor with certificate ID XYZ";
}
¶
This maintains interoperability (base accuracy-measured classification) while supporting proprietary accuracy metadata.¶
Implementation details are in [PowerAndEnergy].¶
In addition to measurement accuracy, the framework supports reporting of industry-standard energy efficiency certifications. These certifications provide vendor-verified efficiency benchmarks that complement direct measurements:¶
Common Certifications: - 80 PLUS (Power Supply Units): Bronze/Silver/Gold/Platinum/Titanium tiers based on efficiency at 20%/50%/100% load - Energy Star: Government-backed program certifying energy-efficient products - EPEAT: Electronic Product Environmental Assessment Tool ratings (Bronze/Silver/Gold) - TCO Certified: Sustainability certification for IT products - EU Energy Label: European efficiency ratings¶
Certifications and measurement accuracy serve complementary purposes:¶
| Aspect | Industry Certification | Measurement Accuracy |
|---|---|---|
| Purpose | Verify design efficiency | Indicate real-time measurement precision |
| Source | Independent testing labs | Device sensors or estimates |
| Granularity | Device-level (e.g., PSU) | Component or system-level |
| Stability | Fixed at manufacturing | May vary with sensor calibration |
| Use Case | Procurement decisions, compliance | Operational monitoring, optimization |
Example: A power supply might have:
- Certification: 80-PLUS-Platinum (≥92% efficient at 50% load, independently verified)
- Measurement Accuracy: accuracy-measured-silver (±10% sensor precision on real-time power readings)¶
The certification tells operators the PSU is designed to be efficient; the measurement accuracy tells them how precisely they can monitor its actual performance.¶
The framework leverages the hierarchical structure of the ietf-hardware model [RFC8348] to minimize redundant data reporting and simplify device implementation. The framework refers as parent-child relationships.¶
Energy objects inherit their hierarchical relationships from the hardware component tree. For example: - A chassis(parent) contains line cards(children). - Each line card(parent) contains ports(children). - Each chassis(parent) is powered by power supply units(children).¶
Energy metrics and metadata follow these same hierarchical relationships, enabling:¶
Child components inherit measurement accuracy from their parent unless explicitly overridden.¶
Reduced reporting overhead: Devices only transmit accuracy metadata for components that differ from their parent.¶
Hierarchical validation: Controllers leverage the device containment tree (per [RFC8348]) to verify parent measurements by aggregating child values.¶
The YANG data model [PowerAndEnergy] implements hierarchical defaults for key attributes. For example:¶
The data-source-accuracy leaf has a default value of accuracy-like-parent, meaning:¶
If a chassis reports accuracy-measured-gold (±5%)¶
All child components(line cards, ports, fans) automatically inherit accuracy-measured-gold¶
Only components with different accuracy need to explicitly report their value¶
Example:
Chassis (accuracy: gold ±5%)
├── Line Card 1 (inherits: gold ±5%) ← No need to report
├── Line Card 2 (inherits: gold ±5%) ← No need to report
└── PSU 1 (explicit: silver ±10%) ← Must report (differs from parent)
¶
This dramatically reduces YANG-Push telemetry volume while maintaining accuracy transparency.¶
While unit-multiplier does not inherit, the framework recommends:¶
Rationale from WG Discussion: > "Either mandatory or default to 1, not inheritance. Leave it open to authors to discuss further." The final YANG model can choose either approach, but must not use inheritance to avoid client code complexity.¶
The YANG data model [PowerAndEnergy] introduces a power-factor leaf to capture Power Factor (PF), enabling controller engines to accurately compute real power. PF is essential for accurately estimating real power consumption in AC-powered components, especially Power Supply Units (PSUs).¶
The power-factor leaf defaults to 100 (unity power factor), meaning:
- Devices with typical resistive loads don't need to report power factor
- Only devices with significant reactive power (motors, large PSUs) need explicit values
- Simplifies data for most networking equipment¶
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 using Power Interface.¶
"- >" is used to denote a transfer of information using Network Interface.¶
This covers the basic example of router connected to Power Outlet in the wall.¶
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.¶
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.¶
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.¶
This covers the example of device connected to wall Power Outlet, with a Physical Meter placed in the wall Power Outlet, because the previous device was not able to monitor its power, energy, demand.¶
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.¶
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.).¶
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.¶
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.¶
This covers the example of a smart PDU that provides energy to a series of routers in a rack.¶
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.¶
To prevent double counting in scenarios where one Energy Object provides power to another (e.g., PoE switch port to PoE endpoint):¶
Convention: Report both consumed and delivered energy separately: - The providing Energy Object reports total-energy-consumed (self) AND total-energy-delivered (to downstream) - The receiving Energy Object reports total-energy-consumed¶
Example: A PoE switch port consuming 1W and providing 9W to an endpoint: - Port reports: total-energy-consumed=1W, total-energy-produced=9W - Endpoint reports: total-energy-consumed=9W¶
Controllers must use Metering Relationships to identify and avoid aggregating both values.¶
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.¶
The Energy Object contains a Power State Set attribute that represents a 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¶
Defining and enforcing power states can be challenging, because each Energy Object's technical capabilities must be mapped to high-level operational intents for energy-efficient operation. The following examples illustrate how an Energy Object's power-saving capabilities can be aligned with typical intents:¶
running at reduced capacity during predictable low-demand periods;¶
lowering energy use while maintaining required performance levels;¶
operating at a reduced service level when the site is on a backup power source during a grid outage.¶
By expressing such intents, a controller can decide which power state an Energy Object should enter at any given time and under what conditions.¶
Identifying what power states an Energy Object supports is crucial for onboarding and integration, especially for legacy systems. Key discovery elements include:¶
Whether the energy object supports multiple Power State Sets.¶
Semantics and limitations of each state (e.g., absolute power, relative power).¶
Transition characteristics, such as the time required to move between states.¶
Energy Object-specific state transition constraints like frequency, which may limit energy-saving measures to avoid damaging the device/components.¶
Impacts on measurement accuracy.¶
The goal of intent mapping is to translate high-level energy-saving intents into specific device/component configurations. For example:¶
An intent like "reduce power consumption at low utilization" might map to a predefined low-power state.¶
Controllers may interpret intents variably, e.g., "run at half capacity but be ready to scale up if needed."¶
This is comparable to intent mapping in YANG-based systems, from high-level Customer-Facing Services (CFS) to Resource-Facing Services (RFS) and ultimately to device-specific configurations.¶
Meanwhile saving energy, the device or component shouldn't drop below a certain performance threshold or allow a certain service reduction or degradation. Based on this, there are two kinds of service level expectations (SLAs) are associated with Power State behavior:¶
This section provides an overview of how the GREEN use cases described in [GreenUseCases] interact with the framework interfaces defined in this document.¶
Each use case is characterized by the sequence of framework interfaces it invokes to achieve energy-efficiency objectives.¶
The table Table 2 maps each GREEN use case to the framework interfaces and summarizes how these are used:¶
The first line shows the interface sequences.¶
The second line briefly describes the functional purpose of that flow.¶
The notation a->b->c represents the flow between framework components as described in the Figure 1, where:¶
| UC | Use Case | Interfaces Usages |
|---|---|---|
| 1 | Incremental deployment | c; c->b; a->d->b->e |
| of the GREEN Framework | 1,2: legacy; 3: GREEN WG support (i) | |
| 2 | Selective Reduction of | e->b->c->f |
| Energy Consumption | monitor->metrics->control | |
| 3 | Reporting on Lifecycle | c->g |
| Management | metrics / metadata->API or report | |
| 4 | Real-time Energy Metering | b->c |
| of Virtualised NFs | monitor->metrics | |
| 5 | Indirect Energy Monitoring | b->f |
| & Control | monitor aggregate->control | |
| 6 | Consideration of Other | c->g->b |
| Domains for End-to-End | metrics->cross-domain API-> | |
| Metrics | monitoring | |
| 7 | Dynamic Adjustment via | b->f->c |
| Traffic Levels | observe->control->update metrics | |
| 8 | Video Streaming Use Case | b->c->f |
| monitor->metrics->control | ||
| 9 | WLAN Network Energy Saving | b->f |
| monitor->control | ||
| 10 | Fixed Network Energy | b->f |
| Saving | monitor->control | |
| 11 | Energy Efficiency Network | a->b->c->f->g |
| Management | discover->monitor->metrics-> | |
| control->API | ||
| 12 | ISAC-enabled Energy-Aware | --- |
| Smart City Traffic Mgmt | not clearly specified | |
| 13 | Double Accounting Open | c->g |
| Issue | metrics / metadata->API | |
| 14 | Energy Efficiency Under | b->f |
| Power Shortage | monitor->control | |
| 15 | Energy-Efficient Mgmt of | b->c->f |
| AI Training Workloads | monitor->metrics->control |
Use Case 1 (Incremental Deployment) illustrates how the usage of the framework interfaces evolves during the lifecycle of a network or device group, starting with legacy reporting, which is represented by 1=(c) and 2=(c -> b) and progressively incorporating GREEN-specific components 3=(a -> d -> b -> e).¶
This section analyzes the [GreenUseCases] to identify which capabilities require device-level implementation versus controller orchestration. This guides implementers on device feature priorities and operators on controller capabilities needed for effective energy management.¶
The framework distinguishes between two orthogonal concepts:¶
Device-Centric Use Cases require autonomous on-device decision-making: - Example: UC 14 (Power Shortage) - Device must independently manage backup power transitions when network connectivity is lost. - It might require local algorithms, minimal controller dependency, autonomous operation, etc.¶
Controller-Centric Use Cases require centralized orchestration and network-wide visibility: - Example: UC 10 (Fixed Network Saving) - Controller predicts traffic patterns across devices and coordinates state changes. - It requires cross-device coordination, centralized intelligence¶
Hybrid Use Cases need both device capabilities and controller coordination: - Example: UC 9 (WLAN Energy Saving) - Devices support power modes; controller coordinates AP groups to maintain coverage.¶
Who triggers telemetry is independent of implementation focus and follows YANG-Push [RFC8641] patterns:¶
Controller-Initiated, or Dynamic subscription: - Controller establishes YANG-Push subscriptions to energy objects - Device streams telemetry at specified intervals (periodic) or on change (event-driven) - Centralized monitoring policy management¶
Device-Initiated, or Static Subscription: - Device autonomously pushes alerts without prior subscription - Used for threshold violations, hardware failures, certification degradation - Complements controller-initiated monitoring¶
Even device-centric use cases(autonomous operation) typically use controller-initiated telemetry (controller subscribes to observe device behavior). These concepts are independent.¶
| UC# | Use Case | Critical Capabilities |
|---|---|---|
| Device-Centric | ||
| 14 | Power Shortage Management | Backup power awareness, autonomous operation |
| 1 | Incremental Deployment | Baseline metrics, certification reporting, capability discovery |
| Hybrid (Device + Controller) | ||
| 4 | Virtualized NF Metering | HW-layer metering, VM correlation, real-time telemetry push |
| 9 | WLAN Energy Saving | PoE power modes, double counting, coordinated state transitions |
| Controller-Centric | ||
| 2 | Selective Energy Reduction | Traffic pattern analysis, coordinated sleep modes, global optimization |
| 3 | Lifecycle Reporting | External database integration, carbon factor correlation, metadata aggregation |
| 5 | Indirect Monitoring | PDU/meter integration, topology-aware aggregation, proxy measurement |
| 6 | Cross-Domain Metrics | Multi-domain API integration, double-accounting prevention, metric mapping |
| 7 | Wireless Transport Optimization | *Traffic-aware power adjustment, dynamic link control, pattern recognition |
| 8 | Video Streaming | Multicast optimization, cache placement, traffic engineering |
| 10 | Fixed Network Saving | pattern prediction, coordinated reconfiguration, AI/ML integration |
| 11 | Network-Wide Management | Centralized visibility, topology mapping, vendor-neutral aggregation |
| 12 | ISAC Smart City | Context-aware activation, city-wide coordination, sensing prioritization |
| 13 | Double Accounting Prevention | Metering topology awareness, relationship modeling, intelligent aggregation |
| 15 | AI Training Workloads | Energy-aware scheduling, data placement, East-West traffic optimization |
| 16 | Cross-Layer Saving | Multi-layer coordination (L0-L3), cross-layer state synchronization |
<<TODO - to decide if we include from here onwards, key findings! and implementation priorities>>¶
To support controller-orchestrated optimization, devices MUST provide:¶
Devices: Granular metering, fast state transitions, component-level control¶
Controllers: Cross-domain integration, AI/ML optimization, multi-layer coordination¶
This phased approach allows incremental deployment while maximizing value at each stage.¶
The mapping in Table 2 demonstrates that most GREEN use cases rely primarily on the monitoring and control interfaces, with discovery being used during initialization or lifecycle events.¶
To complement Table 2, Table 4 provides a higher-level functional view of the framework. It summarizes how the interface sequences relate to the three primary operational domains of Discovery, Monitoring, and Control, and shows how they align with use cases.¶
| Functional Domain | Details | Related Use Cases | Maturity / Status |
|---|---|---|---|
| Discovery | Identification and characterization of devices and capabilities. Telemetry/Data Inputs: Device inventory data, model, firmware version, supported energy features. Example Actions: Register device energy profile; advertise capability set. | UC 1, UC 11 | High |
| Monitoring | Collection of energy-related telemetry across network elements. Telemetry/Data Inputs: Power usage, utilization, operational state, temperature. Example Actions: Aggregate metrics; compute KPIs; detect anomalies. | UC 2-10, UC 15 | Medium |
| Control | Modification of configuration to improve energy efficiency. Telemetry/Data Inputs: Monitored metrics, thresholds, policies. Example Actions: Adjust link speed; enable sleep; re-route load; trigger automation. | UC 2, UC 5-10, UC 14-15 | Low-Medium |
This indicates that future work should prioritize:¶
Enhancing the interoperability and extensibility of monitoring telemetry.¶
Defining control policies and interfaces to support energy optimization actions.¶
Clarifying cross-domain data exchange (interfaces g) for reporting and federation.¶
Combining both perspectives, the detailed interface mapping Table 2 and the functional overview Table 4, offers a comprehensive picture of how the GREEN Framework can be applied to concrete network energy-efficiency scenarios.¶
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.¶
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.¶
This document has no IANA actions.¶
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. 101139120).¶