Everything OPS & Arrcus

benoit@everything-ops.net

Operations and Management GREEN Working Group energy efficiency power state capability discovery YANG This document defines a YANG module that augments the system capabilities model of RFC 9196 to allow a network element to advertise, per hardware Component, the set of Power States that the Component supports together with a static characterization of each such state: the nominal Power the Component draws in that state. This capability model complements the operational Power and Energy data model defined in the GREEN Power and Energy YANG module, which reports the current Power State and the measured Power of a Component, but not which Power States are available or how much Power each draws. It is anchored to the hardware inventory of RFC 8348, reuses the Power State identities of the GREEN Power and Energy model, and, because it is static, may be provided at implementation time as YANG instance data per RFC 9195 so that an Energy Management System can learn a platform's Power State capabilities before the equipment is deployed or even powered on.

Introduction Networks are provisioned for peak demand and might be over-provisioned some of the time. Reducing the energy consumed by the idle capacity requires the ability to place selected Components into a low-power (sleep) Power State when they are not needed, and to return them to full operation when demand returns. To determine which Components can be placed in a low-power state, and estimating the resulting Energy Saving, the Energy Management System, the controller, or the distributed path computation (depending on operational design) draws on two things about each Component:

1. which Power States the Component actually supports
2. where it is known, how much Power the Component draws in each supported state.

The GREEN Power and Energy YANG module models the operational side of this problem: for each Energy Object it reports the current administrative and operational Power State (power-state-admin / power-state-oper) and the measured instantaneous Power. It does not, however, describe which Power States a Component is capable of entering. GREEN reports a single Nameplate Power for the Component, but not the Power the Component draws in each supported Power State -- which is precisely what a Power Savings Potential calculation needs. That information is a Capability: it is essentially static, it is a property of the platform rather than of the running datastore, and it is useful before the device is even powered on. No common capability model exists today, so each consumer defines the pieces it needs. The Power Conserving Path Placement Strategy and its IS-IS encoding introduce their own "sleep-capable" indication and Power Savings Potential value, defined independently of the GREEN data model. This document defines a single capability model, discoverable through the standard system capabilities mechanism of , from which those quantities can be derived -- for example, Power Savings Potential as the difference between the nominal Power of power-state-on and that of a low-power state -- rather than defined separately by each consumer.

Requirements Language 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.

Terminology This document makes use of the terms defined in . Terms reused from that document are capitalized in this specification, including in particular Component, Device, Power, Power State, Power State Set, Nameplate Power, Energy Object, Energy Saving, and Energy Efficiency Capabilities. The term "Power Savings Potential (PSP)" is used as defined in .

Design Overview The design follows four principles.

Capability is Kept Separate from Operational State The set of supported Power States and their characterization is a Capability, not operational state. It is therefore carried in the system capabilities subtree of rather than being mixed into the operational power data of . Keeping the capability model separate from live status lets a management system learn a Component's Power States without querying a running device -- and, as describes, even from a vendor-supplied file before the Component is deployed.

Capability is Anchored to the Hardware Component A Power State is a property of a physical Component (a line card, a fabric, an optical module), which is exactly the entity that is placed into a low-power state. This document therefore anchors the capability to a Component in the hardware inventory , using the per-node capability mechanism of : the node-selector selects the /hardware/component entry to which the capability applies. The node-selector is the generic instance-identifier type defined in and reused by ; although that type originates in the NACM module, it carries no access-control semantics and can address any data node. Because /hardware/component is operational state, the capability is advertised under the operational datastore , as illustrated below: No new correlation identifier is required. The GREEN Power and Energy model already binds each of its energy-entry instances to a hardware Component through the source-component-id leafref to /hw:hardware/hw:component/hw:name. As a result the hardware inventory (RFC 8348), the capability model (this document), and the live operational state () all refer to one and the same Component name, and no change to the GREEN module is needed.

Power State Names are Reused, Not Reinvented The supported Power States are identified by identities derived from the power-state base identity already defined in (namely power-state-on, power-state-off, and power-state-sleep). Where a Component supports more than one low-power depth, additional identities are derived from power-state-sleep; such a collection of related states forms a Power State Set, and its member names SHOULD align with the Power State Sets described in rather than being independently invented, so that consumers can compare states across vendors.

The Characterization is a Reusable Grouping The per-state characterization is defined once, as the YANG grouping power-state-capability (). The grouping is used both at the system-wide level and at the per-Component level of , following the same two-level pattern as the companion ietf-notification-capabilities module of .

Capability MAY be Provided as Instance Data (RFC 9195) Because the capability is static and platform-specific, it does not have to be read from a running Device. It MAY be published by a vendor, or generated from a product data sheet, as a YANG instance data file per . An Energy Management System or a planning tool can thereby learn the Power State capabilities of a platform -- which Components can sleep and how much Power they save -- at design or procurement time, before any equipment is deployed. When the Device is running, the same data MAY instead be read from the operational state datastore. The two sources use the identical schema defined here.

Relationship to Other Work This document is deliberately narrow: it supplies the missing capability layer that three existing efforts each assume but none provides in a common form. reports, for a Component, the Power State it is in now and its measured Power. This document adds the static complement: the set of Power States that Component can enter and the nominal Power of each, keyed to the same hardware Component. A consumer needs both -- what the Component can do, from this document, and its live status, from the GREEN YANG module. and define a Power Conserving Path Placement Strategy and its IS-IS encoding, which need to know which resources are sleep-capable and their Power Savings Potential. With this capability model both become derived facts rather than separately defined values: a Component is "sleep-capable" when it advertises a Power State derived from power-state-sleep, and its PSP for a given low-power state is simply the difference between the nominal-power of power-state-on and the nominal-power of that state. Those documents can then reference a single capability definition instead of carrying their own. This capability model does not replace those mechanisms, and it does not reduce what they must distribute. The dynamic, load-dependent quantities they carry -- for example, the Power Savings Potential actually available under the current traffic, or the sleeping bandwidth of a link -- change with network conditions and remain theirs to distribute, whether in the IGP or via telemetry. What this document changes is narrower: the static foundation those quantities build on -- which Power States a Component supports, and the rated Power of each -- is defined once here, rather than re-specified, with its own units and semantics, inside each consumer.

The Power State Capabilities Model This module advertises the set of supported Power States, not the permitted transitions between them; transition constraints are out of scope.

Tree Structure The following tree diagram uses the notation defined in .

YANG Module This module imports the system capabilities module of and reuses the power-state and unit-multiplier identities of . WG List: Author: Benoit Claise "; description "This module augments the system capabilities model defined in RFC 9196 to allow a server to advertise, per hardware Component, the set of Power States that the Component supports together with a static characterization of each such state (the nominal Power the Component draws in that state). The capability is anchored, via the RFC 9196 per-node capability mechanism, to a Component of the hardware inventory defined in RFC 8348. It reuses the 'power-state' and 'unit-multiplier' identities defined in ietf-power-and-energy. 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 Revised 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-08-25 { description "Initial revision."; reference "RFC XXXX: Discovering the Power State Capabilities of Components"; } grouping power-state-capability { description "Static characterization of the Power States that a Component supports. This grouping is reusable: it is used both at the system-wide level and at the per-Component level of the RFC 9196 capabilities model."; leaf unit-multiplier { type identityref { base eo:unit-multiplier; } default "eo:multiplier-units"; description "Scale factor applied to every Power value ('nominal-power' and 'max-power') reported in this grouping. This reuses the 'unit-multiplier' identity of ietf-power-and-energy. When not explicitly specified, the default of 'eo:multiplier-units' (10^0 = 1) applies, meaning Power values are expressed in Watts."; } list supported-power-state { key "power-state"; description "The set of Power States supported by the Component, with one entry per supported state."; leaf power-state { type identityref { base eo:power-state; } description "A Power State that the Component supports, identified by an identity derived from the 'power-state' base identity of ietf-power-and-energy (for example 'power-state-on', 'power-state-off', or 'power-state-sleep'). Additional low-power depths are represented by further identities derived from 'power-state-sleep'. The abstract identities 'power-state-admin' and 'power-state-oper' MUST NOT be used here."; } leaf nominal-power { type uint32; units "Watts"; description "The nominal Power drawn by the Component while it is in this Power State, scaled by 'unit-multiplier'. The Power Savings Potential of a low-power state is the difference between the 'nominal-power' of 'power-state-on' and the 'nominal-power' of that low-power state."; } leaf max-power { type uint32; units "Watts"; description "The maximum Power that the Component may draw while in this Power State, scaled by 'unit-multiplier'. This is the per-Power-State counterpart of the Component's Nameplate Power: a rated ceiling for this particular state."; } } } augment "/sysc:system-capabilities" { description "System-wide (Device-level) Power State capabilities that apply unless overridden by a per-Component entry."; container power-state-capabilities { description "Default Power State capabilities for the whole system."; uses power-state-capability; } } augment "/sysc:system-capabilities" + "/sysc:datastore-capabilities" + "/sysc:per-node-capabilities" { description "Per-Component Power State capabilities. The 'node-selector' of the enclosing RFC 9196 'per-node-capabilities' entry selects the Component to which these capabilities apply, typically a '/hw:hardware/hw:component' entry of RFC 8348."; container power-state-capabilities { description "Power State capabilities of the selected Component(s)."; uses power-state-capability; } } } ]]>

Operational Considerations The capability data defined by this module is essentially static for a given hardware configuration. A server that already implements the GREEN Power and Energy model -- and hence the hardware inventory of on which it depends -- can expose these capabilities as operational state, or a management system can obtain them out of band as instance data (). The nominal-power and max-power values are optional. A Component MAY advertise the Power States it supports with no Power value; a consumer then learns what the Component can do, but not what each state costs. Where present, these are static, rated figures -- the Power a Component is expected to draw in a Power State, in the spirit of Nameplate Power. They are an approximation: the Power actually drawn, especially in power-state-on, depends on the offered load, the operating temperature, and other environmental conditions, and is therefore network-specific and time-varying. An operator MUST treat nominal-power as a planning baseline, not as a measurement. These values are operational state (config false), not configuration: a Component reports them. Where a rated figure is unavailable, or too coarse for a given purpose, a more precise value can be obtained by measurement -- an Energy Management System can observe the measured instantaneous-power of while the Component is in the corresponding Power State, and use it to supply or refine the advertised value. The dynamic, load-dependent Power Savings Potential that a real-time path placement acts upon is out of scope for this static capability model. In a distributed path-computation architecture it is derived from live conditions and flooded by the IGP (e.g., / ); in a centralized architecture a controller can instead collect it via telemetry. This document supplies the stable capability baseline on which those mechanisms build. A consumer MUST NOT assume that a supported low-power Power State may be entered at any given moment; that is a runtime decision, taken by the consumer's policy and configured through the control side of the GREEN model (e.g., a write to power-state-admin, which the Device may accept or reject). It is out of scope here.

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-power-state-capabilities" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (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. All data nodes defined in this YANG module are read-only ("config false") operational state, which may equivalently be provided as instance data (). The module defines no writable data nodes, no RPC or action operations, and no notifications. 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 "power-state-capabilities" subtree -- the set of Power States a Component supports and the nominal Power of each -- reveals which Components of a Device can be placed into a low-power state and how much Power that would save. An attacker with read access to this information can identify the resources whose repeated forced wake-up would cause the greatest energy or thrashing amplification, or whose sleeping would most usefully be prevented to degrade capacity. This is the same exposure noted for the corresponding routing advertisements in . Read access to this subtree SHOULD be restricted, and, when the capability is distributed as a YANG instance data file , the file SHOULD be handled with the same care as other platform capability inventories.

IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry of the "IETF XML Registry" : This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry:

Acknowledgments This work builds directly on the GREEN Power and Energy YANG model and terminology, and on the system capabilities framework of RFC 9196.

Normative References Informative References

Example The following JSON instance data shows the Power State capabilities of a single line card, "linecard-3", reported as a per-Component capability against the operational state datastore. The line card supports two Power States: fully on, drawing 200 Watts, and asleep, drawing 15 Watts. The same encoding, wrapped in an instance-data-set per , could be shipped by the vendor before deployment. From these values, the Power Savings Potential of the sleep state (power-state-sleep) is derived by subtraction: 200 - 15 = 185 Watts, consistent with the Power Savings Potential convention of . The current Power State and measured Power of the same line card are reported separately by , against the same Component name.