]> Everything OPS

benoit@everything-ops.net

Huawei

chengen@huawei.com

Individual

marisol.ietf@gmail.com

All For Eco

jan.lindblad@for.eco

OPS GREEN Internet-Draft GREEN YANG Power Energy This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks.

Introduction 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 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 . The data model includes both the monitoring and control of Energy Objects for networked devices. This YANG data model is based on the the "GREEN framework" , following the "GREEN terminology" . 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).

Terminology This document makes use of the terms defined in : This document makes use of the terms defined in The terms reused from and are capitalized in this specification. This document uses the terms Power and Energy in accordance with . 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 . The meanings of the symbols in the YANG tree diagrams are defined in .

The GREEN Framework The "GREEN framework" described in 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 .

Power and Energy Data Model 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 power-state-admin and power-state-oper, representing the intended and operational power states respectively. Although an NMDA (Network Management Datastore Architecture) design with a single "state" leaf (per [RFC8342]) was considered, it is not adopted in this document. /hw:hardware/component/name | +--ro power | | +--ro instantaneous-power int32 | | +--ro nameplate-power? uint32 | | +--ro unit-multiplier identityref | | +--ro data-source-accuracy? identityref | | +--ro power-factor? power-factor | | +--ro measurement-local? boolean | +--ro energy | | +--ro total-energy-consumed? uint64 | | +--ro total-energy-delivered? uint64 | | +--ro unit-multiplier? identityref | | +--ro data-source-accuracy? identityref | | +--ro measurement-local? boolean | | +--ro certifications* identityref | +--ro power-state | | +--ro power-state-oper? identityref | +--ro relationship* [type] | +--ro type identityref | +--ro peer* [id] | +--ro id string | +--ro details? string +--rw energy-control +--rw energy-entry* [object-id] +--rw object-id string +--rw power-state +--rw power-state-admin? identityref +--rw state-enter-reason? identityref ]]>

Relationship to the Hardware YANG Data Model The ietf-hardware YANG module 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 if it exists, and UUID is the Universally Unified IDentifier 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 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 its 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 allows to discover 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).

Relationship to the EMAN Work The EMAN IETF Working Group (https://datatracker.ietf.org/wg/eman/about/) is a concluded Working Group that produces 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 ENITY-MIB to add the UUID definition . For various reasons, those MIB modules were not implemented by vendors. The Power and Energy data model defined in this specification use the Monitoring and Control MIB for Power and Energy as a starting point to discuss the solution to the different use cases in . 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.

Power and Energy YANG Module This YANG Module is used to monitor and control Power and Energy usage of network devices and the components on these devices. WG List: "; description "This YANG module specifies for Power and Energy monitoring and control of devices within or connected to communication networks. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-01-22 { description "Initial revision"; reference "RFC XXXX: Energy Object YANG Data Model"; } identity data-source-accuracy { description "Base identity for all possible data accuracy types. This identity serves as the root for a hierarchy of accuracy types, allowing for extensibility while maintaining alignment with current and future industry standards. The hierarchy, as defined in this YANG module, is as follows. Other modules may extend this hierarchy with additional accuracy base- and sub-types as needed. data-source-accuracy ├── accuracy-like-parent ├── accuracy-unknown │ └── accuracy-unavailable ├── accuracy-estimated │ ├── accuracy-static │ ├── accuracy-historic │ └── accuracy-learned └── accuracy-measured ├── accuracy-measured-bronze │ ├── accuracy-measured-bronze-1 │ ├── accuracy-measured-bronze-10 │ ├── accuracy-measured-bronze-100 │ └── accuracy-measured-bronze-1000 ├── accuracy-measured-silver │ └── accuracy-measured-silver-... ├── accuracy-measured-gold │ └── accuracy-measured-gold-... ├── accuracy-measured-red │ └── accuracy-measured-red-... └── accuracy-measured-ones The accuracy levels under accuracy-measured are based on percent-wise accuracy classes: bronze: +/- 30% silver: +/- 10% gold: +/- 5% red: +/- 2% In addition, the accuracy-measured-ones identity indicates a power data measurement with all digits valid, except trailing zeros. Since percent-wise accuracy works poorly for very small values, standards such as IEC 62053, IEC 61850-7-4 and IEEE 1451 define accuracy classes based on a combination of percent-wise accuracy and absolute accuracy thresholds. E.g. +/-1 % of reading + +/-0.05 absolute units. Similarly, for each percent-wise accuracy class, this module defines a few absolute tolerance classes, indicated by suffixes to the accuracy identity names. The suffixes indicate absolute accuracy thresholds: no suffix: +/-0.5 absolute units -1: +/-1 absolute unit -10: +/-10 absolute units -100: +/-100 absolute units -1000: +/-1000 absolute units Thus, for example, accuracy-measured-gold-10 indicates a power data measurement with an accuracy of either +/-5% or +/-10 absolute units, whichever is larger. For example, a power sensor reading might report a value of 16250, with unit multiplier of milli (10^-3), under accuracy-measured-gold-10. This indicates that the actual power value is between 16.2375 and 16.2625 Watts, since 5% of 16.250 Watts is 0.8125 Watts, which is greater than the absolute threshold of 10 milliwatts (0.010 W). At another time, the same sensor might report a value of 150, with unit multiplier of milli (10^-3), under accuracy-measured-gold-10. This indicates that the actual power value is between 0.140 and 0.160 Watts, since 5% of 0.150 Watts is only 0.0075 Watts, which is less than the absolute threshold of 10 milliwatts (0.010 W)."; } identity accuracy-unknown { base data-source-accuracy; description "The accuracy of the power data is unknown."; } identity accuracy-unavailable { base accuracy-unknown; description "A power data is not available for some reason, such as a sensor failure or a component being powered off."; } identity accuracy-like-parent { base data-source-accuracy; description "The accuracy of the power/energy data is the same as this energy object's parent object. This identity is useful for hierarchical energy objects where child objects inherit the accuracy characteristics."; } identity accuracy-estimated { base data-source-accuracy; description "The power data is estimated, perhaps based on a model, history or calculation rather than a direct measurement."; } identity accuracy-static { base accuracy-estimated; description "The power data is based on static data, such as manufacturer specifications, datasheet of typical power values or nameplate ratings, rather than real-time measurements."; } identity accuracy-historic { base accuracy-estimated; description "The power data is based on an historic measurement data for this specific system and usage pattern."; } identity accuracy-learned { base accuracy-estimated; description "The power data is based on an machine learning model prediction."; } identity accuracy-measured { base data-source-accuracy; description "The power data is a direct, real-time measurement from a sensor."; } identity accuracy-measured-bronze { base accuracy-measured; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 30% OR |actual-sensor| ≤ 0.5"; } identity accuracy-measured-bronze-1 { base accuracy-measured-bronze; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 30% OR |actual-sensor| ≤ 1"; } identity accuracy-measured-bronze-10 { base accuracy-measured-bronze; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 30% OR |actual-sensor| ≤ 10"; } identity accuracy-measured-bronze-100 { base accuracy-measured-bronze; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 30% OR |actual-sensor| ≤ 100"; } identity accuracy-measured-bronze-1000 { base accuracy-measured-bronze; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 30% OR |actual-sensor| ≤ 1000"; } identity accuracy-measured-silver { base accuracy-measured; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 10% OR |actual-sensor| ≤ 0.5"; } identity accuracy-measured-silver-1 { base accuracy-measured-silver; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 10% OR |actual-sensor| ≤ 1"; } identity accuracy-measured-silver-10 { base accuracy-measured-silver; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 10% OR |actual-sensor| ≤ 10"; } identity accuracy-measured-silver-100 { base accuracy-measured-silver; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 10% OR |actual-sensor| ≤ 100 "; } identity accuracy-measured-silver-1000 { base accuracy-measured-silver; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 10% OR |actual-sensor| ≤ 1000"; } identity accuracy-measured-gold { base accuracy-measured; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 5% OR |actual-sensor| ≤ 0.5"; } identity accuracy-measured-gold-1 { base accuracy-measured-gold; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 5% OR |actual-sensor| ≤ 1"; } identity accuracy-measured-gold-10 { base accuracy-measured-gold; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 5% OR |actual-sensor| ≤ 10"; } identity accuracy-measured-gold-100 { base accuracy-measured-gold; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 5% OR |actual-sensor| ≤ 100"; } identity accuracy-measured-gold-1000 { base accuracy-measured-gold; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 5% OR |actual-sensor| ≤ 1000"; } identity accuracy-measured-red { base accuracy-measured; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 2% OR |actual-sensor| ≤ 0.5"; } identity accuracy-measured-red-1 { base accuracy-measured-red; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 2% OR |actual-sensor| ≤ 1"; } identity accuracy-measured-red-10 { base accuracy-measured-red; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 2% OR |actual-sensor| ≤ 10"; } identity accuracy-measured-red-100 { base accuracy-measured-red; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 2% OR |actual-sensor| ≤ 100"; } identity accuracy-measured-red-1000 { base accuracy-measured-red; description "The power data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| ≤ sensor * 2% OR |actual-sensor| ≤ 1000"; } identity accuracy-measured-ones { base accuracy-measured; description "The power data is a direct, real-time measurement from a sensor with all digits valid, except trailing zeros. For example, a sensor reading of 12300 represents a sensor value between 12250 and 12350."; } typedef power-factor { type uint8 { range "0 .. 100"; } default 100; description "The percent value of the power factor measurement. Leaf often omitted, implying 100%."; } identity power-state { description "Base identity for all possible power states. This identity serves as the root for a hierarchy of power states, allowing for extensibility while maintaining alignment with the IANA Power State Set Registry."; reference "IANA: Power State Set Registry: https://www.iana.org/assignments/power-state-sets/"; } identity power-state-admin { base power-state; description "Base identity for administratively requested power states. The administrative power state indicates the desired power state requested for the Energy Object by a management system."; } identity power-state-oper { base power-state; description "Base identity for operational power states. The operational power state indicates the actual current power state of the Energy Object. A difference between the administrative state and the operational state indicates that the Energy Object is transitioning between power states."; } identity power-state-enter-reason { description "Base identity for reasons why an Energy Object entered its current operational power state. This is analogous to the enumeration values defined for eoPowerStateEnterReason in RFC 7460."; } identity power-state-on { base power-state; description "full power on."; reference "IANA: Power State Set Registry (ieee1621-power-state-set): https://www.iana.org/assignments/power-state-sets/"; } identity power-state-off { base power-state; description "power off."; reference "IANA: Power State Set Registry (ieee1621-power-state-set): https://www.iana.org/assignments/power-state-sets/"; } identity power-state-sleep { base power-state; description "low-power state."; reference "IANA: Power State Set Registry (ieee1621-power-state-set): https://www.iana.org/assignments/power-state-sets/"; } identity unit-multiplier { description "Base identity for unit multipliers as defined in IEC 61850-7-3 Annex A. These represent exponents of 10 for scaling units associated with the integer units used to measure the power or energy. yocto(-24), -- 10^-24 zepto(-21), -- 10^-21 atto(-18), -- 10^-18 femto(-15), -- 10^-15 pico(-12), -- 10^-12 nano(-9), -- 10^-9 micro(-6), -- 10^-6 milli(-3), -- 10^-3 units(0), -- 10^0 kilo(3), -- 10^3 mega(6), -- 10^6 giga(9), -- 10^9 tera(12), -- 10^12 peta(15), -- 10^15 exa(18), -- 10^18 zetta(21), -- 10^21 yotta(24) -- 10^24 "; } identity multiplier-yocto { description "Represents a multiplier of 10^-24 associated with the integer units used to measure the power or energy."; } identity multiplier-zepto { description "Represents a multiplier of 10^-21 associated with the integer units used to measure the power or energy."; } identity multiplier-atto { description "Represents a multiplier of 10^-18 associated with the integer units used to measure the power or energy."; } identity multiplier-femto { description "Represents a multiplier of 10^-15 associated with the integer units used to measure the power or energy."; } identity multiplier-pico { description "Represents a multiplier of 10^-12 associated with the integer units used to measure the power or energy."; } identity multiplier-nano { description "Represents a multiplier of 10^-9 associated with the integer units used to measure the power or energy."; } identity multiplier-micro { description "Represents a multiplier of 10^-6 (0.000001) associated with the integer units used to measure the power or energy."; } identity multiplier-milli { description "Represents a multiplier of 10^-3 (0.001) associated with the integer units used to measure the power or energy."; } identity multiplier-units { description "Represents a multiplier of 10^0 (1) associated with the integer units used to measure the power or energy."; } identity multiplier-kilo { description "Represents a multiplier of 10^3 (1,000) associated with the integer units used to measure the power or energy."; } identity multiplier-mega { description "Represents a multiplier of 10^6 (1,000,000) associated with the integer units used to measure the power or energy."; } identity multiplier-giga { description "Represents a multiplier of 10^9 (1,000,000,000) associated with the integer units used to measure the power or energy."; } identity multiplier-tera { description "Represents a multiplier of 10^12 associated with the integer units used to measure the power or energy."; } identity multiplier-peta { description "Represents a multiplier of 10^15 associated with the integer units used to measure the power or energy."; } identity multiplier-exa { description "Represents a multiplier of 10^18 associated with the integer units used to measure the power or energy."; } identity multiplier-zetta { description "Represents a multiplier of 10^21 associated with the integer units used to measure the power or energy."; } identity multiplier-yotta { description "Represents a multiplier of 10^24 associated with the integer units used to measure the power or energy."; } identity energy-relationship-type { description "Base identity for energy object relationships"; } identity powered-by { base energy-relationship-type; description "Energy Object A is powered by Energy Object B"; } identity powering { base energy-relationship-type; description "Energy Object A is powering Energy Object B"; } identity metered-by { base energy-relationship-type; description "Energy Object A is metered by Energy Object B"; } identity metering { base energy-relationship-type; description "Energy Object A is metering Energy Object B"; } identity aggregated-by { base energy-relationship-type; description "Energy Object A is aggregated by Energy Object B"; } identity aggregating { base energy-relationship-type; description "Energy Object A is aggregating Energy Object B"; } container energy-objects { config false; description "Energy objects container for power and energy attributes."; list energy-entry { key "object-id"; description "Power and energy entry for an energy object, indexed by object id. Each entry contains the complete set of power and energy attributes for a specific physical component."; leaf object-id { type string; description "An identifier that uniquely identifies the energy object"; } leaf source-component-id { type leafref { path "/hw:hardware/hw:component/hw:name"; } description "Reference to the component name in the ietf-hardware model. This leaf creates a direct semantic link between the power/energy attributes and the physical component they describe. "; } container power { description "Container for power measurement attributes."; leaf instantaneous-power { type int32; units "Watts"; mandatory true; description "The power usage measurement for the energy object right now. This value represents the instantaneous power consumption of the component. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately as unit-multiplier in this container. Positive values indicate power consumption, while negative values can indicate power generation (e.g., for devices with battery backup or renewable energy sources)."; } leaf nameplate-power { type uint32; units "Watts"; description "The nameplate power rating of an energy object. This is the maximum power that the energy object is designed to consume or produce, as specified by the manufacturer. Essential for power budget calculations and capacity planning."; } leaf unit-multiplier { type identityref { base unit-multiplier; } mandatory true; description "The unit multiplier used to measure the power. This multiplier applies to both instantaneous-power and nameplate-power values, allowing representation of power values from milliwatts to gigawatts using integer arithmetic."; } leaf data-source-accuracy { type identityref { base data-source-accuracy; } default accuracy-like-parent; description "The accuracy of the power data source. Indicates whether the data source is a direct measurement, an estimate, or unavailable and also the accuracy level of the data source. By default, the accuracy is inherited from the parent energy object, facilitating hierarchical accuracy definitions without the need to specify accuracy at every level. This metadata is crucial for network management applications to assess the reliability and accuracy of the power data."; } leaf power-factor { type power-factor; description "The percent value of the power factor measurement for the energy object. This information is important for understanding the electrical characteristics of the energy object and for correctly interpreting the power data."; } leaf measurement-local { type boolean; description "Indicates whether the power measurement is local (true) or remote (false). A local measurement is taken directly at the energy object, while a remote measurement is collected from an external source. This information can be useful for troubleshooting and understanding the data source."; } } container energy { description "Container for energy measurement attributes."; leaf total-energy-consumed { type uint64; units "Watt-hours"; description "The total cumulative energy consumed by the energy object since the last reset. This value is specified as watt-hours with the magnitude of watt-hours (milliwatt-hours, kilowatt-hours, etc.) indicated separately as unit-multiplier in this container. This value is useful for tracking overall energy usage over time for billing, reporting, or optimization purposes."; } leaf total-energy-delivered { type uint64; units "Watt-hours"; description "The total cumulative energy delivered by the energy object since the last reset. This value is specified as watt-hours with the magnitude of watt-hours (milliwatt-hours, kilowatt-hours, etc.) indicated separately as unit-multiplier in this container. This value is relevant for energy objects capable of generating power, such as those with renewable energy sources or battery backup systems, or capable of providing energy to other energy objects (e.g., PoE switches)."; } leaf unit-multiplier { type identityref { base unit-multiplier; } description "This multiplier applies to both total-energy-consumed and total-energy-delivered values. It determines the scale of the energy measurements, allowing representation of energy values from milliwatt-hours to gigawatt-hours using integer arithmetic."; } leaf data-source-accuracy { type identityref { base data-source-accuracy; } default accuracy-like-parent; description "The accuracy of the energy data source. Indicates whether the data source is a direct measurement, an estimate, or unavailable and also the accuracy level of the data source. By default, the accuracy is inherited from the parent energy object, facilitating hierarchical accuracy definitions without the need to specify accuracy at every level. This metadata is crucial for network management applications to assess the reliability and accuracy of the energy data."; } leaf measurement-local { type boolean; description "Indicates whether the energy measurement is local (true) or remote (false). A local measurement is taken directly at the energy object, while a remote measurement is collected from an external source. This information can be useful for troubleshooting and understanding the data source."; } leaf-list certifications { type identityref { base ianaeo:certification-type; } description "List of certifications applicable to this energy object. If this list is empty, the energy object has no certifications."; } } container power-state { description "Container for Power state monitoring."; leaf power-state-oper { type identityref { base power-state-oper; } description "The actual operational power state of the Energy Object. This reflects the current state, which may differ from the admin-state during transitions. This leaf is the operational counterpart of the administratively set 'power-state-admin' in /energy-control/energy-entry. The two leaves together form the complete power state management interface."; } } list relationship { config false; key "type"; description "Relationships for this energy entry. Replaces RFC 7461 eoRelationTable."; leaf type { type identityref { base energy-relationship-type; // powered-by, powering, metered-by, metering, etc. } description "The type of relationship this energy object has with peer objects."; } list peer { key "id"; description "Multiple peers for this relationship type."; leaf id { type string; description "This id specifies the Universally Unique Identifier (UUID) of the peer (other) Energy Object that this energy object is powering/powered-by/metering/ metered-by, etc. If the network level UUID is not known, some other locally unique identifier MAY be used, in conjunction with a human readable details."; } leaf details { type string; description "Human-readable details of the peer relationship. Useful when network level UUID of the peer is not known."; } } } } } container energy-control { description "Energy control configuration, mirroring monitored objects. The operational tree ('container energy-objects') will typically contain a significantly larger number of instances than the configuration tree here. The configuration tree represents the administrator's intent and is limited to explicitly provisioned entries."; list energy-entry { key "object-id"; description "Control entry for a specific energy object."; leaf object-id { type string; description "An identifier that uniquely identifies the energy object."; } container power-state { description "Container for Power state management."; leaf power-state-admin { type identityref { base power-state-admin; } description "The administratively requested power state for the Energy Object. This is the state that the management system desires the energy object to be in. This leaf is the administrative counterpart of the operational set 'power-state-oper' in /energy-objects/energy-entry. The two leaves together form the complete power state management interface."; } leaf state-enter-reason { type identityref { base power-state-enter-reason; } description "The reason why the Energy Object entered its current operational power state. This is set whenever the power-state-oper changes."; } } } } } ]]> The IANA requested identities for power and energy class are separately described below. "; description "IANA-defined identities for power and energy class. The latest revision of this YANG module can be obtained from the IANA website. Requests for new values should be made to IANA via email (iana@iana.org). Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). The initial version of this YANG module is part of RFC XXX; see the RFC itself for full legal notices."; reference "https://www.iana.org/assignments/yang-parameters"; revision 2026-02-26 { description "Initial revision."; reference "RFC XXX: A YANG Data Model for Power and Energy monitoring and control of devices within or connected to communication networks"; } identity certification-type { description "Base identity for certification types applicable to energy objects. This identity serves as the root for a hierarchy of certification types, allowing for extensibility."; reference "Industry sustainability and energy efficiency certifications"; } identity energy-star { base certification-type; description "ENERGY STAR certification for energy efficiency."; reference "https://www.energystar.gov/"; } identity c80-plus{ base certification-type; description "80 PLUS Power Supply Certification"; reference "https://www.clearesult.com/80plus/"; } identity epeat { base certification-type; description "Electronic Product Environmental Assessment Tool ratings (Bronze/Silver/Gold)."; reference "https://www.epeat.net/"; } identity eu-energy-level{ base certification-type; description "EU Energy Label: European efficiency ratings"; reference "https://eprel.ec.europa.eu/screen/home"; } identity cn-energy-level{ base certification-type; description "CN Energy Label: China efficiency ratings"; reference "https://www.energylabel.com.cn"; } identity cqc{ base certification-type; description "China Quality Certification for energy efficiency"; reference "https://www.cqc.com.cn/"; } } ]]> # Operational Considerations 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 to get 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.

Measurement Accuracy and Data Source Classification 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.

Industry-Standard Certifications 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.

Security Considerations This section will be completed once the YANG module is complete, according to https://wiki.ietf.org/group/ops/yang-security-guidelines. This section is modeled after the template described in Section 3.7.1 of . The Power and Energy YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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.

IANA Considerations This document requests IANA to create and maintain a new registry group called "Power and Energy", with the following module registration:

Field	Value
Name	ietf-iana-power-and-energy
Namespace	urn:ietf:params:xml:ns:yang:ietf-iana-power-and-energy
Prefix	ianaeo
Reference	RFC XXXX

Note to IANA: RFC XXXX must be replaced by the newly assigned RFC number. All sub-registries defined in this document are part of the "Power and Energy" registry group.

GREEN Certification Type Registry This document requests IANA to create a new sub-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 ietf-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 . 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 ietf-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 ietf-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 ietf-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 ietf-iana-power-and-energy YANG module MUST be updated as defined in RFC XXXX.

Acknowledgments 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Huawei Orange Huawei Telefonica Individual Energy-efficient network management is primarily meant to enhance conventional network management with energy-related management capabilities that optimize overall network energy consumption. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network elements and their components. This document defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. This document defines a YANG data model for the management of hardware on a single server. This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References YumaWorks Orange Huawei This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. Orange Individual Huawei Huawei Telefonica Universidad Carlos III de Madrid This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases Everything OPS Telefonica All For Eco Independent Orange Huawei 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 memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133. This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]