Discovering the Power State Capabilities of Components

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 February 2027.¶

Copyright Notice

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

Table of Contents

1. 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 [I-D.ietf-green-power-and-energy-yang] 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 [I-D.many-teas-power-steering] and its IS-IS encoding [I-D.many-lsr-power-group] 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 [RFC9196], 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.¶

2. Design Overview

The design follows four principles.¶

system-capabilities
  datastore-capabilities [datastore = ietf-datastores:operational]
      // hardware components live in the operational datastore
    per-node-capabilities [node-selector =
        "/ietf-hardware:hardware/component[name='linecard-3']"]
      // node-selector: a generic RFC 8341 instance-identifier,
      // resolving here to an RFC 8348 hardware component
      power-state-capabilities { ... }   // added by this document

3. 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.¶

[I-D.ietf-green-power-and-energy-yang] 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.¶

[I-D.many-teas-power-steering] and [I-D.many-lsr-power-group] 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.¶

4. 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.¶

module: ietf-power-state-capabilities

  augment /sysc:system-capabilities:
    +--ro power-state-capabilities
       +--ro unit-multiplier?        identityref
       +--ro supported-power-state* [power-state]
          +--ro power-state      identityref
          +--ro nominal-power?   uint32
          +--ro max-power?       uint32
  augment /sysc:system-capabilities
            /sysc:datastore-capabilities
            /sysc:per-node-capabilities:
    +--ro power-state-capabilities
       +--ro unit-multiplier?        identityref
       +--ro supported-power-state* [power-state]
          +--ro power-state      identityref
          +--ro nominal-power?   uint32
          +--ro max-power?       uint32

module ietf-power-state-capabilities {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities";
  prefix pscap;

  import ietf-system-capabilities {
    prefix sysc;
    reference
      "RFC 9196: YANG Modules Describing Capabilities for Systems
       and Datastore Update Notifications";
  }
  import ietf-power-and-energy {
    prefix eo;
    reference
      "I-D.ietf-green-power-and-energy-yang: A YANG Data Model for
       Power and Energy Monitoring and Control";
  }

  organization
    "IETF GREEN (Getting Ready for Energy-Efficient Networking)
     Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/green/>
     WG List:  <mailto:green@ietf.org>
     Author:   Benoit Claise <mailto:benoit@everything-ops.net>";
  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;
    }
  }
}

5. 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 [I-D.ietf-green-power-and-energy-yang] -- and hence the hardware inventory of [RFC8348] on which it depends -- can expose these capabilities as operational state, or a management system can obtain them out of band as instance data (Section 2.5).¶

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 [I-D.ietf-green-power-and-energy-yang] 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., [I-D.many-teas-power-steering] / [I-D.many-lsr-power-group]); 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.¶

6. Security Considerations

This section is modeled after the template described in Section 3.7.1 of [RFC9907].¶

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) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (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.¶

All data nodes defined in this YANG module are read-only ("config false") operational state, which may equivalently be provided as instance data (Section 2.5). 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 [I-D.many-lsr-power-group]. Read access to this subtree SHOULD be restricted, and, when the capability is distributed as a YANG instance data file [RFC9195], the file SHOULD be handled with the same care as other platform capability inventories.¶

7. IANA Considerations

This document requests IANA to register the following URI in the "ns" subregistry of the "IETF XML Registry" [RFC3688]:¶

   URI:  urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:¶

   Name:       ietf-power-state-capabilities
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities
   Prefix:     pscap
   Reference:  RFC XXXX

8. Acknowledgments

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

Appendix A. Example

The following JSON [RFC7951] 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 [RFC9195], could be shipped by the vendor before deployment.¶

{
  "ietf-system-capabilities:system-capabilities": {
    "datastore-capabilities": [{
      "datastore": "ietf-datastores:operational",
      "per-node-capabilities": [{
        "node-selector":
          "/ietf-hardware:hardware/component[name='linecard-3']",
        "ietf-power-state-capabilities:power-state-capabilities": {
          "supported-power-state": [{
            "power-state": "ietf-power-and-energy:power-state-on",
            "nominal-power": 200
          },{
            "power-state":
              "ietf-power-and-energy:power-state-sleep",
            "nominal-power": 15
          }]
        }
      }]
    }]
  }
}

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 [I-D.many-teas-power-steering]. The current Power State and measured Power of the same line card are reported separately by [I-D.ietf-green-power-and-energy-yang], against the same Component name.¶

Author's Address