| Internet-Draft | GREEN-PEM-YANG | July 2026 |
| Benoit, et al. | Expires 4 January 2027 | [Page] |
This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks.¶
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 4 January 2027.¶
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.¶
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.¶
This document defines a YANG data model for Power and Energy Monitoring and control of devices within or connected to communication networks, for the use cases document in [I-D.ietf-green-use-cases-01].¶
The data model includes both the monitoring and control of Energy Objects for networked devices.¶
This YANG data model is based on the "GREEN framework" [I-D.ietf-green-framework-01], following the "GREEN terminology" [I-D.ietf-green-terminology-02].¶
Power and Energy Monitoring and Control can be applied to devices in communication networks. All identifiable devices with measurable or representable Power and Energy characteristics fall within the scope of this specification. Target devices include (but are not limited to) routers, switches, Power over Ethernet (PoE) endpoints, smart PDU, storage and compute servers, etc.¶
Where applicable, device monitoring extends to the components of the device as well as software and service running on the device. As a result, the metrics to be monitored include Device Level Energy Efficiency (DLEE), Component Level Energy Efficiency (CLEE) and potential Service Level Energy Efficiency (SLEE) at the orchestrator-level, etc. For example, a router can contain components such as Line Processing Unit (LPU), Switch Fabric Unit (SFU), Main Processing Unit (MPU).¶
This document makes use of the terms defined in [I-D.ietf-green-terminology-02]:¶
- Power - Energy - Energy Management - Energy Monitoring - Energy Control - Energy Efficiency/Energy Efficiency Ratio - Device Level Energy Efficiency (DLEE) - Component Level Energy Efficiency (CLEE) - Service Level Energy Efficiency (SLEE)¶
This document makes use of the terms defined in [I-D.ietf-green-framework-01]¶
- Energy Object¶
The terms reused from [I-D.ietf-green-terminology-02] and [I-D.ietf-green-framework-01] are capitalized in this specification.¶
This document uses the terms Power and Energy in accordance with [I-D.ietf-green-terminology-02]. Power refers to the instantaneous rate at which a device consumes or produces electrical energy (typically expressed in Watts). Energy, by contrast, represents the cumulative amount of work performed over time (typically expressed in Joules or Watt-hours). Both concepts are required within this YANG module. Power enables real-time monitoring, control, and optimization of device operation, while Energy provides a time-integrated view necessary for accounting, reporting, and even for sustainability analysis. This specification includes both Power and Energy attributes.¶
The terminology for describing YANG modules is defined in [RFC7950]. The meanings of the symbols in the YANG tree diagrams are defined in [RFC8340].¶
The "GREEN framework" described in [I-D.ietf-green-framework-01] covers monitoring and controlling devices and components where monitoring includes measuring Power, Energy, demand and attributes of Power.¶
For the whole picture of the monitoring interfaces and the relevant requirements, please refer to "GREEN reference model" in section 4 in [I-D.ietf-green-framework-01].¶
The Power and Energy Data Model reports the Power and Energy consumption of each Energy Object as well as the units, sign, measurement accuracy, etc.¶
A containment tree view of the Power and Energy Monitoring is presented. The model differentiates the power-state-admin and power-state-oper YANG leaves, representing the intended and operational power states respectively. The two leaves together form the complete power state management interface. The operational tree ('container energy-objects') will typically contain a significantly larger number of instances than the configuration tree ('container energy-control'). The configuration tree, which is limited to explicitly provisioned entries, provides a compact self-contained view of the intent. For this reason, although an NMDA (Network Management Datastore Architecture) design with a single "state" leaf (per [RFC8342]) was considered, it is not adopted in this document.¶
Finally, note that the instance is in the configuration tree, having a required-instance false leafref to operational tree instance.¶
The relationship list models the relationship between an Energy
Object and its peer Energy Objects, using the
energy-relationship-type identities: powered-by and powering
(Power Source Relationship), metered-by and metering (Metering
Relationship), aggregated-by and aggregating (Aggregation
Relationship), and enabled-by and enabling (Functional
Enablement Relationship).¶
Each pair of identities expresses the same
relationship from the perspective of each participant (e.g., if
Energy Object A is powered-by Energy Object B, then Energy Object B
is powering Energy Object A). These relationship categories,
including their use for power/metering topology discovery and for
preventing double-counting of Energy values, are defined in
[I-D.ietf-green-framework]. For each relationship type, one or
more peer Energy Objects can be identified via the id leaf within
the peer list, a string value that is typically the peer's UUID
when known, or another locally unique identifier, together with
human-readable details captured in the details leaf, otherwise.¶
Regarding relationships among Energy Objects, this document does not provide a mechanism to configure relationships on the device (i.e., there is no relationship list under /energy-control); the relationship list under /energy-objects/energy-entry is read-only operational data (config false).¶
For relationships between components within the same device (e.g., between a Line Processing Unit (LPU) and a Switch Fabric Unit (SFU)), the device can typically determine and populate this data directly, without requiring external configuration.¶
Relationships between Energy Objects located on different devices are generally established and maintained at the controller or Energy Management System (EnMS) level, which has visibility into the broader network topology, as discussed in [I-D.ietf-green-framework-01]. A device may still report a known inter-device relationship (e.g., using the peer's network-level UUID) when it has been made aware of it, but this module does not provide a mechanism to configure such relationships on the device itself.¶
{::include yang/ietf-power-and-energy.txt}
¶
The ietf-hardware YANG module [RFC8348] is required by the Power and Energy YANG module. In the ietf-hardware YANG model, there are three identifiers for hardware components, which are "name", "physical-index" and "uuid". Among them, "name" is the key to "List of components", "physical-index" matches entPhysicalIndex in the legacy Entity MIB [RFC6933] if it exists, and UUID is the Universally Unified IDentifier [RFC9562] of the component.¶
In the Power and Energy YANG Module defined in this specification, there is a leaf named "source-component-id" which refers to the component name in the ietf-hardware model. The "source-component-id" can in turn reuse the UUID in the ietf-hardware YANG module.¶
The mapping between energy-object entries in this YANG Module and the hardware-components in ietf-hardware YANG module [RFC8348] is designed to be 1:1, architecturally aligning each energy-entry with exactly one physical hardware component via source-component-id.¶
There are also cases where the controllers also generate their own set of UUIDs for the hardware (components). In such a case, it might be necessary to document the mappings between the UUIDs generated on the hardware side and the UUIDs on the controller side. Basically, the devices (such as routers) generate the UUID and the controller can query it.¶
The ietf-hardware YANG module [RFC8348] allows discovering all the device components, including the containment tree, and the parent/child relationship, which is important for energy/power aggregation (see the contains-child relationship in RFC 8348).¶
The EMAN IETF Working Group (https://datatracker.ietf.org/wg/eman/about/) is a concluded Working Group that produced a couple of RFCs in the domain of Power and Energy. The Working Group produced MIB modules for monitoring and control for power and energy, for the context information, for battery monitoring, and an extension to the ENTITY-MIB to add the UUID definition [RFC6933].¶
For various reasons, those MIB modules were not implemented by vendors.¶
The Power and Energy data model defined in this specification uses the Monitoring and Control MIB for Power and Energy [RFC7460] as a starting point to discuss the solution to the different use cases in [I-D.ietf-green-use-cases-01].¶
However, it has not been the goal to simply map the MIB module to a YANG module. The changes compared to the EMAN MIB modules are mainly due to the alignment with the up-to-date requirements of the network carriers on Energy Efficiency. Compared to the MIB modules, some definitions and types are optimized, some new Energy Objects are added and some legacy Energy Objects are removed accordingly.¶
This YANG Module is used to monitor and control Power and Energy usage of network devices and the components on these devices.¶
<CODE BEGINS> file "ietf-power-and-energy@2026-07-02.yang"
{::include yang/ietf-power-and-energy.yang}
<CODE ENDS>¶
The IANA-requested identities for power and energy class are separately described below.¶
<CODE BEGINS> file "iana-power-and-energy@2026-07-02.yang"
{::include yang/iana-power-and-energy.yang}
<CODE ENDS>¶
In the YANG data model, the unit-multiplier leaf is defined with different constraints in the power and energy containers. In the power container, the leaf is mandatory true. This ensures that every power measurement (instantaneous or nameplate) is always accompanied by an explicit scale, eliminating any ambiguity about the unit. In the energy container, the leaf is optional and has a default value of "multiplier-units" (which corresponds to 10^0 = 1, i.e., Watt‑hours). If a device does not provide this leaf, the client MUST assume that all energy values (total-energy-consumed and total-energy-delivered) are expressed in Watt‑hours. This default eliminates the ambiguity that would otherwise exist when the leaf is absent.¶
Heterogeneous sensor capabilities across components complicate power and energy aggregation. Operators must use the data-source-accuracy identities (e.g., accuracy-measured-bronze vs. accuracy-estimated) to weight data reliability carefully before aggregating Power (instantaneous-power) and Energy (total-energy-consumed and/or total-energy-delivered) values to avoid skewing Device Level Energy Efficiency (DLEE) metrics.¶
Operators might not always be interested in getting the individual component accuracy. What counts is the device level or domain level, identity accuracy-like-parent is introduced to meet their demands. From an implementation point of view, to facilitate data collection and aggregation on runtime and avoid post-aggregation data confidence interval issues, operators and implementers should use as much as possible this accuracy-like-parent identity.¶
YANG Push support eliminates device-side bucket storage by streaming energy telemetry directly to controller-side via subscriptions. Operators must verify the 'yang-push' bundle is enabled and validate push-max-operational limits accommodate all component subscriptions, preventing notification flooding while avoiding memory overhead on the device.¶
Power and energy metrics may originate from a wide range of sources and estimation methods, each with different levels of reliability. These include direct sensor measurements, manufacturer-provided specifications, historical observations, and predictive models. Without explicit characterization of data quality, comparisons and aggregations may be misleading. The GREEN YANG data model therefore requires all power and energy values to be associated with an accuracy classification.¶
The model defines the following primary accuracy categories using YANG identities:¶
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.¶
Energy efficiency certifications issued by recognized testing organizations provide standardized benchmarks for the expected performance of equipment and components. These certifications are typically based on controlled laboratory measurements and formal evaluation procedures. The GREEN YANG data model supports reporting of such certifications in order to complement operational measurement data.¶
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)¶
EU Energy Label: European efficiency ratings¶
CN Energy Label: China efficiency ratings¶
CQC: China Quality Certification for energy efficiency¶
Additional certification schemes may be supported through extensible identities.¶
Certification data and measurement accuracy serve complementary functions within the model.¶
Certification information describes the verified design-time efficiency characteristics of a device or component, as established through independent testing. Measurement accuracy describes the precision and reliability of reported operational data obtained from sensors or estimation mechanisms.¶
Key differences include:¶
Certification is typically applied at manufacturing time and remains stable throughout the product lifecycle.¶
Measurement accuracy may vary over time due to calibration, environmental conditions, or sensor degradation.¶
Certification is generally associated with discrete components, such as power supply units.¶
Measurement accuracy applies to individual metrics at component, subsystem, or system level.¶
Both types of information may be reported simultaneously for the same energy object.¶
Example: A power supply might have:¶
Certification: c80-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 energy object, for example, a PSU, is designed to be efficient; the measurement accuracy tells them how precisely they can monitor its actual performance.¶
This section is modeled after the template described in Section 3.7.1 of [rfc8407bis].¶
The Power and Energy YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There is one writable data node defined in this YANG module that may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to this data node without proper protection can have a negative effect on network operations:¶
/energy-control/energy-entry/power-state/power-state-admin: Unauthorized write access to this leaf allows an attacker to change the administratively requested power state of an Energy Object. Depending on the target device or component, this could be used to power down critical network infrastructure (resulting in denial of service), force a component into a state that damages hardware, or mask an ongoing attack by cycling power states to disrupt monitoring. Access to this data node SHOULD be limited to authorized administrators via NACM.¶
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities:¶
/energy-objects/energy-entry/power and /energy-objects/energy-entry/energy: These subtrees expose real-time and cumulative power and energy consumption for individual hardware components. Fine-grained, time-correlated power/energy telemetry can reveal operational patterns, such as workload levels, traffic volume, or usage schedules, of a device or of the network behind it. In some environments, this information could be leveraged as a side channel to infer sensitive operational or business information (e.g., data center utilization, capacity, or customer activity patterns).¶
/energy-objects/energy-entry/relationship: This list exposes relationships (e.g., powered-by, powering, metered-by) and UUIDs between Energy Objects, which can reveal the physical and logical power topology of a site. Disclosure of this information could assist an attacker in identifying high-value targets (e.g., shared power infrastructure whose disruption has a broad impact) or in correlating Energy Objects across administrative domains.¶
This document does not define any RPC operations or YANG notifications.¶
This document requests IANA to create and maintain a new registry group called "Power and Energy", with the following module registration:¶
| Field | Value |
|---|---|
| Name | iana-power-and-energy |
| Namespace | urn:ietf:params:xml:ns:yang:iana-power-and-energy |
| Prefix | ianaeo |
| Reference | RFC XXX |
Note to IANA: RFC XXX must be replaced by the newly assigned RFC number.¶
All registries defined in this document are part of the "Power and Energy" registry group.¶
This document requests IANA to create a new registry called "Power and Energy Certification Types" within the "Power and Energy" registry group.¶
This document defines the initial version of the IANA-maintained
certification-type identity in the iana-power-and-energy YANG
module. The registry assigns string identity names for power and energy efficiency certification types, for use as identityref values in "ietf-power-and-energy" YANG module. The registered value is the unqualified identity name (e.g., energy-star, c80-plus, etc). No numeric code points are assigned by this registry.¶
New entries to "Power and Energy Certification Types" registry require Expert Review [RFC8126]. The Designated Expert(s) should verify that:¶
The certification is issued by a recognized and independent standards body, testing laboratory, regulatory authority, or equivalent organization.¶
The certification has a stable, publicly accessible reference.¶
The proposed identity name SHOULD be a short mnemonic derived from the official certification name.¶
When a new certification type is added to the registry, a new
identity statement MUST be added to the iana-power-and-energy
YANG module. The following substatements to the identity statement
MUST be defined:¶
base: MUST contain the value certification-type.¶
status: Include only if a registration has been deprecated (use
the value deprecated) or obsoleted (use the value obsolete).¶
description: MUST include the full name of the certification
program and a brief description of its energy efficiency scope.
Lines MUST NOT exceed 72 characters.¶
reference: MUST include a stable URI to the certification
program's official documentation or registry.¶
Unassigned or reserved values MUST NOT be present in the module.¶
When the "Power and Energy Certification Types" registry is
updated with a new entry, a corresponding new identity statement
MUST be added to the iana-power-and-energy YANG module, and a new revision statement MUST be added in front of the existing revision
statements.¶
IANA is requested to add the following note to the "Power and Energy Certification Types" registry:¶
Certification types MUST NOT be directly added to the iana-power-and-energy YANG module. They MUST instead be added to the "Power and Energy Certification Types" registry. When this registry is updated, the iana-power-and-energy YANG module MUST be updated as defined in RFC XXX.¶
This work has benefited from the regular discussions on the GREEN Design Meetings. The authors wish to thank the WG chairs, Rob Wilton and Diego Lopez, for organizing the recurring calls and progressing the work. The authors also wish to thank the following individuals, who provided helpful comments and reviews to this document.¶