Internet-Draft Power State Capability Discovery September 2026
Claise, et al. Expires 14 March 2027 [Page]
Workgroup:
GREEN Working Group
Internet-Draft:
draft-claise-green-capability-discovery-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Claise
Everything OPS & Arrcus
N. Warnke
Deutsche Telekom
R. Rahman
Equinix
G. Chen
Huawei

A YANG Data Model for Power State Capability Discovery

Abstract

This document defines a YANG data model 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 expected and maximum Power the Component draws in it, and the time to enter and exit it.

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, how much Power each draws, or how long transitions between them take. 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.

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 14 March 2027.

▲

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 (the admin and oper leaves) 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.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Terminology

This document makes use of the terms defined in [I-D.ietf-green-terminology]. 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 Management System.

The term "Power Savings Potential (PSP)" is used as defined in [I-D.many-teas-power-steering].

In this document, 'admin' and 'oper' are the two leaves of the GREEN Power and Energy model [I-D.ietf-green-power-and-energy-yang] that report a Component's administratively requested and operational Power State, each carrying a power-state identity value; power-state-on, power-state-off, and power-state-sleep are those identity values, and the supported-power-state list defined here enumerates which of them a Component supports.

This document uses the following Power-quantity terms:

Nameplate Power:
the maximum Power a Component is designed to consume, as specified by the manufacturer, as reported by the nameplate-power leaf of [I-D.ietf-green-power-and-energy-yang]. It is a rated design ceiling, not an expected operating value.
max-power (per Power State):
the rated maximum Power a Component may draw in a given Power State -- the per-state counterpart of Nameplate Power. For power-state-on (the most power-consuming state) it is at most the Component's Nameplate Power (see Section 4).
nominal-power (per Power State):
the Power a Component is expected to draw in a given Power State under normal operation. The actual Power drawn depends on the offered load, the operating temperature, and other environmental conditions, and is therefore network-specific; nominal-power is a typical value, itself typically lower than max-power. Here "nominal" denotes the expected operating value, NOT the manufacturer's rating.

2. Applicability

The capability model defined in this document is a prerequisite for any function that reasons about what a Component can do with its Power.

Inventory and audit:
An operator can determine which deployed Components -- which interfaces, which line cards, which routers -- are sleep-capable and which are not. Without such an inventory, the question of which parts of a network can be turned off cannot be answered systematically.
Energy Efficiency control:
An Energy Management System that intends to place a line card in a low-power Power State, by writing the admin leaf in [I-D.ietf-green-power-and-energy-yang], needs to know which Power States that line card supports before making the request.
Energy modelling:
An Energy Management System can estimate off-line the Energy Saving of a proposed policy, such as putting a set of interfaces to sleep overnight, without changing the state of the running network.
Traffic engineering:
A path computation that concentrates traffic in order to idle links and the line cards behind them, such as [I-D.many-teas-power-steering], needs the same information as a static input. This is one consumer among several, not the only one.
Cross-checking the control plane:
A controller can validate the Power Savings Potential advertised by the IGP against the rated Power reported here, detecting misconfiguration or stale advertisements.
Platform comparison:
Two router models can be compared on the Power States they support, and the Power each state draws, in a single vendor-independent encoding.
Capacity and power budget planning:
Because the capability may be published as YANG instance data [RFC9195], the expected and maximum Power of a chassis populated with a given set of line cards can be computed before the equipment is ordered or installed.

2.1. Applicability to the GREEN Use Cases

This section analyzes the applicability of this document against the use cases specified in [I-D.ietf-green-use-cases].

Note: [I-D.ietf-green-use-cases] is a work in progress. If it does not progress to publication, this section might be removed.

The following use cases depend on the Power State capabilities defined in this document:

  • Section 2.2, "Selective reduction of energy consumption in network parts proportional to traffic levels": before a Component can be placed in a low-power Power State as traffic falls, a management system must know that the Component supports such a state, and how much Power that would save.
  • Section 2.9, "WLAN Network Energy Saving": this use case distinguishes several low-power modes and calls for coordinated management of them: when some access points enter lower Power States, neighboring access points adjust their transmit power to compensate for coverage. This model provides the per-state Power information on which such coordination depends.
  • Section 2.10, "Fixed Network Energy Saving": deactivating Components during low-traffic periods requires knowing which Components can be deactivated.
  • Section 2.11, "Energy Efficiency Network Management": the set of supported Power States and the rated Power of each completes the visibility that the operational model provides for the current state.
  • Section 2.14, "Energy Efficiency Under Power Shortage": planning which Components to place in a low-power Power State under a constrained power budget requires the Power of each state in advance.
  • Section 2.1, "Incremental Application of the GREEN Framework": an operator applying the framework to an installed base can discover which deployed Components are capable of energy saving and which are not.
  • Section 2.7, "Dynamic adjustment of network element throughput according to traffic levels in wireless transport networks": the adjustment requires the set of states the network element supports.
  • Section 2.16, "Network-level Cross Layer Energy Saving", and Section 2.17, "AI Agents for Energy Efficiency Management": coordinated or agent-driven optimization needs a machine-readable, vendor-independent description of what each Component can do.

3. Design Overview

The design follows five principles.

3.1. 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 [RFC9196] rather than being mixed into the operational power data of [I-D.ietf-green-power-and-energy-yang]. 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 Section 3.5 describes, even from a vendor-supplied file before the Component is deployed.

3.2. 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 [RFC8348], using the per-node capability mechanism of [RFC9196]: the node-selector selects the /hardware/component entry to which the capability applies.

The node-selector is the generic instance-identifier type defined in [RFC8341] and reused by [RFC9196]; 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 [RFC8342], as illustrated below:

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

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 ([I-D.ietf-green-power-and-energy-yang]) all refer to one and the same Component name, and no change to the GREEN module is needed.

The nominal-power and max-power reported for a Component are the Power of that Component alone; they do not include the Power of its child Components in the [RFC8348] hardware hierarchy. This follows from Energy Objects inheriting their containment from the hardware component tree [I-D.ietf-green-framework]: each Component (chassis, line card, port, transceiver, ...) advertises its own values, so the Power of a larger assembly -- for example a chassis populated with line cards and their transceivers -- is obtained by summing the per-Component values over the relevant subtree, each Component counted once, with no double counting.

3.3. 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 [I-D.ietf-green-power-and-energy-yang] (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 [I-D.ietf-green-framework] rather than being independently invented, so that consumers can compare states across vendors.

3.4. The Characterization is a Reusable Grouping

The per-state characterization is defined once, as the YANG grouping power-state-capability (Section 5.2). The grouping is used both at the system-wide level and at the per-Component level of [RFC9196] -- the same two-level structure as the companion ietf-notification-capabilities module of [RFC9196]. [I-D.ietf-netconf-yp-transport-capabilities] uses the same mechanism for YANG-Push transport capabilities, although it augments at the system-wide level only.

3.5. 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 [RFC9195]. 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.

4. 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, for each, its expected and maximum Power and the time to enter and exit it, 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. This difference is a static planning baseline; the dynamic, load-dependent Power Savings Potential that a real-time path placement acts upon is a different quantity and is out of scope for this document (see Section 6). 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 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. Because an IGP Link State Database tolerates only slowly-changing state, an IGP encoding such as [I-D.many-lsr-power-group] proposes to carry a static or dampened value to avoid churn, while a real-time value is collected via telemetry instead. 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, and is a natural source for the static value an IGP advertises, rather than re-specified, with its own units and semantics, inside each consumer.

The GREEN Power and Energy model reports, for a Component, a single nameplate-power YANG leaf: the maximum Power the Component is designed to consume, as specified by the manufacturer. The nominal-power and max-power advertised for the power-state-on state in this model are realistic planning baselines that serve a different purpose; they are not required to equal the Nameplate Power (the nominal-power is typically lower). Because nameplate-power represents the Component's upper power limit, however, any nominal-power or max-power advertised for power-state-on MUST be less than or equal to the corresponding nameplate-power when the latter is reported. Where this model does not advertise power-state-on values, the nameplate-power MAY be used as a planning fallback. For the remaining Power States there is no GREEN equivalent, and that is what this model adds.

5. The Power State Capabilities Model

This module advertises the set of supported Power States and, for each, the time to enter and exit it relative to power-state-on. It does not advertise which transitions between Power States are permitted, or any other transition constraint; those are out of scope.

All nodes defined by this module are operational state (config false); the Power State capabilities are therefore reported only in the operational state datastore [RFC8342]. The module defines no configuration data and does not appear in any configuration datastore.

5.1. Tree Structure

The following tree diagram uses the notation defined in [RFC8340].

module: ietf-power-state-capabilities

  augment /sysc:system-capabilities:
    +--ro power-state-capabilities
       +--ro supported-power-state* [power-state]
          +--ro power-state           identityref
          +--ro nominal-power?        uint32
          +--ro max-power?            uint32
          +--ro typical-exit-time?    transition-time-ms
          +--ro max-exit-time?        transition-time-ms
          +--ro typical-entry-time?   transition-time-ms
          +--ro max-entry-time?       transition-time-ms
  augment /sysc:system-capabilities/sysc:datastore-capabilities
            /sysc:per-node-capabilities:
    +--ro power-state-capabilities
       +--ro supported-power-state* [power-state]
          +--ro power-state           identityref
          +--ro nominal-power?        uint32
          +--ro max-power?            uint32
          +--ro typical-exit-time?    transition-time-ms
          +--ro max-exit-time?        transition-time-ms
          +--ro typical-entry-time?   transition-time-ms
          +--ro max-entry-time?       transition-time-ms

5.2. YANG Module

This module imports the system capabilities module of [RFC9196] and reuses the power-state identities of [I-D.ietf-green-power-and-energy-yang].

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>
     Author:   Nils Warnke <mailto:Nils.Warnke@telekom.de>
     Author:   Reshad Rahman <mailto:reshad@yahoo.com>
     Author:   Gen Chen <mailto:chengen@huawei.com>";
  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
     expected and maximum Power the Component draws in it, and the
     time to enter and exit it).

     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' 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-09-10 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for Power State Capability
       Discovery";
  }

  typedef transition-time-ms {
    type uint32;
    units "milliseconds";
    description
      "The duration of a transition between Power States, in
       milliseconds. The specific Power States and the direction
       are given by the leaf that uses this type.";
  }

  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.";

    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'.";
      }

      leaf nominal-power {
        type uint32;
        units "Watts";
        description
          "The nominal Power drawn by the Component while it
           is in this Power State.
           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. This is the per-Power-State
           counterpart of the Component's Nameplate Power: a
           rated ceiling for this particular state. For
           'power-state-on', which is expected to be the most
           power-consuming Power State, this value does not
           exceed the 'nameplate-power' leaf reported for the
           same Component by ietf-power-and-energy.";
      }

      leaf typical-exit-time {
        type transition-time-ms;
        description
          "The typical time to transition the Component from this
           Power State back to 'power-state-on', under normal
           conditions, measured from when the transition to
           'power-state-on' is initiated until the Component is
           fully operational (able to carry traffic). It is a key
           input when weighing the Power a low-power state saves
           against the service impact of the delay to leave it.
           Not meaningful for 'power-state-on' and omitted for it.";
      }

      leaf max-exit-time {
        type transition-time-ms;
        description
          "The worst-case time to transition the Component from
           this Power State back to 'power-state-on'. It bounds the
           service-restoration delay an operator must budget for; a
           state is usable for hitless operation only if this value
           is within the applicable threshold. Not meaningful for
           'power-state-on'.";
      }

      leaf typical-entry-time {
        type transition-time-ms;
        description
          "The typical time to transition the Component from
           'power-state-on' into this Power State, under normal
           conditions. Together with the exit time it determines
           the minimum idle interval for which entering this state
           is worthwhile. Not meaningful for 'power-state-on'.";
      }

      leaf max-entry-time {
        type transition-time-ms;
        description
          "The worst-case time to transition the Component from
           'power-state-on' into this Power State. Not meaningful
           for 'power-state-on'.";
      }
    }
  }

  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;
    }
  }
}

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

Per-Component coverage may be partial: a Device MAY advertise Power State capabilities for some Components and not others (incremental deployment). A Component for which no entry is present has unknown capabilities, not zero Power. A total nominal-power or max-power obtained by summing the advertised Components is therefore complete only when every Component in the relevant [RFC8348] subtree is covered; otherwise it is a lower bound. A consumer can determine coverage by comparing the advertised Components against the [RFC8348] hardware inventory.

The time to enter and to exit a Power State can be significant and varies between Components and between states, and it constrains how a state can be used: a state that saves substantial Power but is slow to exit may be unusable for a Component carrying latency-sensitive traffic -- for example, a transition that must complete within milliseconds to be hitless, or a line card whose 30-second return to full operation would breach a service-level agreement. An Energy Management System should weigh the exit time (and, for short idle windows, the entry time) against the Energy Saving before selecting a low-power state. Where advertised, typical-exit-time, max-exit-time, typical-entry-time and max-entry-time give these durations relative to power-state-on; like the Power values they are rated approximations, optional, and network- and condition-dependent.

Where present, the nominal-power and max-power values 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 the IGP is the channel (e.g., [I-D.many-teas-power-steering] / [I-D.many-lsr-power-group]), but because a Link State Database tolerates only slowly-changing state those encodings propose to carry a static or dampened value rather than the real-time one; a controller in a centralized architecture can instead collect the real-time value 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 the admin leaf, which the Device may accept or reject). It is out of scope here.

7. Open Issues

This section is to be removed before publication.

8. 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 [RFC9846], 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 3.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. Where advertised, the per-state transition times (notably max-exit-time) further reveal how long each Component takes to return to service, which an attacker can use to time forced wake-ups for maximum disruption or to single out the Components most costly to wake. 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.

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

10. Acknowledgments

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

The separation between static manufacturer data and live operational readings, and the idea of delivering that static data as a YANG instance data file, were introduced in [I-D.opsawg-poweff]. This document realizes that intent using standardized mechanisms: anchoring to [RFC8348], augmenting [RFC9196], and pre-deployment delivery per [RFC9195].

11. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9196]
Lengyel, B., Clemm, A., and B. Claise, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", RFC 9196, DOI 10.17487/RFC9196, , <https://www.rfc-editor.org/info/rfc9196>.
[RFC8348]
Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, , <https://www.rfc-editor.org/info/rfc8348>.
[RFC8341]
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
[I-D.ietf-green-power-and-energy-yang]
Claise, B., Chen, G., Palmero, M. P., and J. Lindblad, "Power and Energy YANG Module", Work in Progress, Internet-Draft, draft-ietf-green-power-and-energy-yang-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-power-and-energy-yang-04>.

12. Informative References

[RFC9195]
Lengyel, B. and B. Claise, "A File Format for YANG Instance Data", RFC 9195, DOI 10.17487/RFC9195, , <https://www.rfc-editor.org/info/rfc9195>.
[RFC9907]
Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, , <https://www.rfc-editor.org/info/rfc9907>.
[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC4252]
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, , <https://www.rfc-editor.org/info/rfc4252>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8342]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, , <https://www.rfc-editor.org/info/rfc8342>.
[RFC9846]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, , <https://www.rfc-editor.org/info/rfc9846>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/info/rfc9000>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/info/rfc7951>.
[RFC8792]
Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, , <https://www.rfc-editor.org/info/rfc8792>.
[I-D.ietf-green-terminology]
Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M. P. Palmero, "Terminology for Energy Efficiency Network Management", Work in Progress, Internet-Draft, draft-ietf-green-terminology-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-terminology-02>.
[I-D.ietf-green-framework]
Claise, B., Contreras, L. M., Lindblad, J., Palmero, M. P., Stephan, E., and Q. Wu, "Framework for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-ietf-green-framework-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-framework-02>.
[I-D.ietf-green-use-cases]
Stephan, E., Palmero, M. P., Claise, B., Wu, Q., Contreras, L. M., Bernardos, C. J., and X. Chen, "Use Cases for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-ietf-green-use-cases-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-use-cases-02>.
[I-D.opsawg-poweff]
Lindblad, J., Mitrovic, S., Palmero, M., and G. Salgueiro, "Power and Energy Efficiency", Work in Progress, Internet-Draft, draft-opsawg-poweff-01, , <https://datatracker.ietf.org/doc/html/draft-opsawg-poweff-01>.
[I-D.ietf-netconf-yp-transport-capabilities]
Wu, Q., Ma, Q., Feng, A. H., and T. Graf, "YANG Notification Transport Capabilities", Work in Progress, Internet-Draft, draft-ietf-netconf-yp-transport-capabilities-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yp-transport-capabilities-07>.
[I-D.many-teas-power-steering]
Barth, C., Li, T., Beeram, V. P., and R. P. Bonica, "A Power Conserving Path Placement Strategy (PCPPS)", Work in Progress, Internet-Draft, draft-many-teas-power-steering-02, , <https://datatracker.ietf.org/doc/html/draft-many-teas-power-steering-02>.
[I-D.many-lsr-power-group]
Barth, C., Li, T., Beeram, V. P., and R. P. Bonica, "Using IS-IS To Advertise Power Group Membership", Work in Progress, Internet-Draft, draft-many-lsr-power-group-03, , <https://datatracker.ietf.org/doc/html/draft-many-lsr-power-group-03>.

Appendix A. Power Capabilities Examples

A.1. Interface Power Capability Example

The following JSON [RFC7951] instance data shows the Power State capabilities of a single interface, the 100 Gigabit Ethernet port "HundredGigE0/0/1", whose pluggable transceiver module uses the QSFP28 form factor (Quad Small Form-factor Pluggable, 28 Gb/s per lane), reported as a per-Component capability against the operational state datastore. It shows that the model applies at the interface level -- the granularity a traffic-engineering consumer such as [I-D.many-teas-power-steering] cares about.

The interface supports two of the IEEE 1621 Power States reused from [I-D.ietf-green-power-and-energy-yang]: power-state-on ("full power on"), drawing a nominal 3 Watts (max-power 4 Watts), and power-state-sleep ("low-power state"), drawing a nominal 1 Watt (max-power 2 Watts).

========== NOTE: '\\' line wrapping per RFC 8792 ==========

{
  "ietf-system-capabilities:system-capabilities": {
    "datastore-capabilities": [{
      "datastore": "ietf-datastores:operational",
      "per-node-capabilities": [{
        "node-selector":
          "/ietf-hardware:hardware/component\
          \[name='HundredGigE0/0/1']",
        "ietf-power-state-capabilities:power-state-capabilities": {
          "supported-power-state": [{
            "power-state": "ietf-power-and-energy:power-state-on",
            "nominal-power": 3,
            "max-power": 4
          },{
            "power-state":
              "ietf-power-and-energy:power-state-sleep",
            "nominal-power": 1,
            "max-power": 2
          }]
        }
      }]
    }]
  }
}

The long "node-selector" line is wrapped using the "\\" line-folding strategy of [RFC8792].

Power values are reported in Watts. The derived Power Savings Potential of the sleep state is 3 - 1 = 2 Watts. This is a planning-time estimate; the operational, load-dependent value is out of scope (see Section 6).

A.2. Line Card Power Capability Example

The following instance data shows the Power State capabilities of a single line card, "linecard-3". The line card supports the same two IEEE 1621 Power States reused from [I-D.ietf-green-power-and-energy-yang], and this example also shows their max-power and transition times. In power-state-on ("full power on") it draws a nominal 200 Watts, with a rated max-power of 240 Watts; in power-state-sleep ("low-power state") it draws a nominal 15 Watts (max-power 25 Watts) and, relative to power-state-on, takes a typical 300 ms (up to 600 ms) to enter and a typical 800 ms (up to 2 s) to exit. 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,
            "max-power": 240
          },{
            "power-state":
              "ietf-power-and-energy:power-state-sleep",
            "nominal-power": 15,
            "max-power": 25,
            "typical-exit-time": 800,
            "max-exit-time": 2000,
            "typical-entry-time": 300,
            "max-entry-time": 600
          }]
        }
      }]
    }]
  }
}

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]. This is a planning-time estimate; the operational, load-dependent value is out of scope (see Section 6). For completeness, the current Power State and the measured, load- and temperature-dependent Power of the same line card are reported separately by [I-D.ietf-green-power-and-energy-yang] -- its power-state/oper and power/instantaneous-power leaves, in the energy-object bound to this Component through source-component-id -- which an Energy Management System reads to obtain the actual value in operation.

Authors' Addresses

Benoit Claise
Everything OPS & Arrcus
Belgium
Nils Warnke
Deutsche Telekom
Germany
Reshad Rahman
Equinix
Canada
Gen Chen
Huawei
China