| Internet-Draft | Power State Capability Discovery | October 2026 |
| Claise, et al. | Expires 30 April 2027 | [Page] |
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.¶
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 30 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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. On high-speed platforms the pluggable optics can draw more Power than the forwarding ASIC, so interfaces and their transceivers are a primary target for such Power States. To determine which Components can be placed in a low-power state, and to estimate the resulting Energy Saving, the Energy Management System, the controller, or the distributed path computation (depending on operational design) draws on three things about each Component:¶
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.¶
This capability model reports steady-state, per-Power-State Power. Peak or inrush (transient) Power is out of scope, and so are power supply capabilities; a power supply's own power, its consumption and rated output, is reported by the GREEN Power and Energy model [I-D.ietf-green-power-and-energy-yang]. Coordinating energy-saving actions across layers, for example when an IP-layer Power State change affects an optical channel or wavelength, is also out of scope. This model supplies the capability input to the systems that perform that coordination.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document 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 terms:¶
nameplate-power leaf of
[I-D.ietf-green-power-and-energy-yang]. It is a
rated design ceiling, not an expected operating value, and not a
transient or inrush peak.¶
max-power (per Power State):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):nominal-power is a typical value, itself typically lower
than max-power. Here "nominal" denotes the expected
operating value, not the manufacturer's rating.¶
The capability model defined in this document is a prerequisite for any function that reasons about what a Component can do with its Power.¶
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.¶
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:¶
The design follows five principles. The final subsection records a limitation of the current approach regarding the potential repetitive information.¶
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.¶
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]. Here "node" is a schema (data) node, not a
network device: each per-node-capabilities entry is bound
to a single physical Component by setting its node-selector
to that Component's /hardware/component entry.¶
The node-selector is of type node-instance-identifier,
defined in [RFC8341] and reused by
[RFC9196]: an instance-identifier in which the
predicates for keys are optional. 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: an RFC 8341 node-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.¶
A per-Component capability entry likewise applies only to the Component that its node-selector names. It says nothing about that Component's child Components, so a Consumer cannot infer that subordinate Components support a Power State because their parent does. A capability that applies to only some Components, for example some of the ports of a line card, is advertised on those Components and not on the parent.¶
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.¶
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.¶
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. The supported Power States, and the figures for them, can depend on the platform and its software release. An instance-data file should therefore identify the platform and software release it applies to, using the name or description metadata of [RFC9195], while data read from a running Device reflects the release that Device is running.¶
Where many Components are identical, for example interfaces that carry the same optic, their capability figures repeat, since the Power and transition times are a property of the optic model and manufacturer, not of the slot the optic occupies. Removing that repetition is an optimization that would be ideal for the instance-data file. A query of the operational datastore returns one entry per Component, because the datastore holds a separate instance for each; grouping those entries by optic model and manufacturer would be convenient but is not expressible, as described below. An instance-data file is authored ahead of time, so in principle it could carry each distinct optic model and manufacturer once instead of once per Component.¶
Grouping Components by optic model and manufacturer is not expressible with the RFC 9196 node-selector, which anchors each capability entry to a Component. The node-selector is of type node-instance-identifier (RFC 8341), which follows the rules of a YANG instance-identifier ([RFC7950], Section 9.13): its predicates may address only list keys, and may be omitted. The [RFC8348] hardware component list is keyed only by name, so one entry can select a single Component by name, or every Component by omitting the predicate, but not the subset that shares a given manufacturer and model. A predicate on a non-key leaf, such as component[model-name='400G-DR4-S'], is not a valid node-selector, and a Consumer cannot be expected to interpret it consistently. [RFC8348] also defines no transceiver class and no form-factor or transceiver-type leaf; its closest attribute, model-name, is the config-false customer-visible part number and cannot serve as a selector predicate in any case.¶
The underlying reason is that an instance-data file carries data, that is, instances of YANG nodes, and not a condition. "Apply these figures to every Component whose manufacturer is X and model is Y" is a rule, and the only place to express a rule is the node-selector, which is keys-only. The same intent expressed as data, a self-contained record whose leaves are the manufacturer, the model, and the capabilities, would deduplicate, and the Consumer would match the manufacturer and model against the hardware inventory. The module as published, however, defines no list keyed by that pair, so no file can carry such a record today.¶
In practice, therefore, an instance-data file enumerates the per-Component entries, including the duplicates. This is not such a constraint from an automation point of view: the data is static and is typically delivered as a vendor-generated instance-data file [RFC9195], not hand-maintained. Where a Device is homogeneous, the system-wide capability augmentation can carry the common per-Component figures once.¶
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.¶
A Component's capability is not always sufficient on its own: whether a low-power state may be entered can depend on other Components. A SerDes (the serializer/deserializer behind a port or an optical module) can sleep, for example, only when none of the SerDes lanes it drives are in use. This document does not model such cross-Component dependencies, which are out of scope (Section 5); they are carried instead by the enabling and enabled-by relationships of [I-D.ietf-green-power-and-energy-yang], where a Component that is enabling others must remain operational while any of them is in use. A Consumer therefore reads both: the Power States a Component supports, from this document, and the relationships between Components, from the GREEN Power and Energy model. Appendix A.3 gives a worked example.¶
[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"
(equivalently, power-saving capable) when it advertises a Power
State derived from power-state-sleep, so no separate
capability flag is needed for it, 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.¶
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, as are dependencies between Components. Because the four transition times are all relative to power-state-on, a direct transition between two low-power states is not characterized.¶
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.¶
The nominal-power and max-power values are optional. A Component MAY advertise the Power States it supports with no Power value, in which case a Consumer learns what the Component can do but not what each state costs. A system-wide entry applies to every Component that has no per-Component entry. A Component that has neither a per-Component entry nor a system-wide entry has unknown capabilities, not zero Power.¶
Where present, nominal-power is the Power a Component is expected to draw in a Power State, and max-power is the rated per-state ceiling, in the spirit of Nameplate Power. Both are static approximations rather than measurements, like the transition times: 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.¶
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
¶
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>
Author: Gary Woodward
<mailto:gary.woodward1@virginmediao2.co.uk>";
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-10-26 {
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 sustained (continuous) Power that the
Component may draw while in this Power State: a rated
ceiling for this particular state, not a transient or
inrush peak. It is the per-Power-State counterpart of
the Component's Nameplate Power; for 'power-state-on',
the most power-consuming Power State, it is less than or
equal to that Nameplate Power when the latter is
reported.";
}
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 Power State capabilities that apply to each
Component unless overridden by a per-Component entry.";
container power-state-capabilities {
description
"Default Power State capabilities of each Component that has
no per-Component entry. These are the figures of an
individual Component, not a total for the Device.";
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;
}
}
}
¶
Per-Component coverage may be partial: a Device
MAY advertise Power State capabilities for some
Components and not others (incremental deployment). A Component is
covered if it has a per-Component entry or if a system-wide entry
applies to it. A total nominal-power or max-power
obtained by summing the 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 per-Component entries, and the system-wide
entry if present, 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. In particular, it should compare
max-exit-time against the applicable restoration or latency
threshold: a Power State whose Energy Saving is attractive but whose
exit time exceeds that threshold should not be selected.¶
An operator MUST treat nominal-power as a
planning baseline, not as a measurement. 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 Component being capable of entering a low-power Power State does not make it eligible to do so. A Consumer MUST NOT assume that a supported low-power Power State may be entered at any given moment. Eligibility is operator policy, for example excluding Components needed for N+1 protection, resilience or reserved capacity. It 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). Such policy is deliberately not part of this static capability model and is out of scope here.¶
This section is to be removed before publication.¶
power-state-on. For a Component with more than one
low-power state, this does not capture direct transitions between
two low-power states, which would require a transition matrix.
This document assumes relative-to-power-state-on is
sufficient, since the operationally relevant times are those to
leave and restore service; whether direct low-power-to-low-power
transitions must be modeled is open. To be discussed with the
Working Group.¶
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.¶
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¶
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].¶
The authors thank Marisol Palmero and Qin Wu for their reviews and comments on this work.¶
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. For simplicity, this example assumes that the inventory represents the port and its pluggable transceiver module as a single Component, so the Power reported is that of the port with its module. Where the transceiver is a separate Component (Section 3.2), the figures are advertised on the transceiver Component and not on the port.¶
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). The transition times are optional and
are omitted here; the line card example below shows them.¶
========== 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).¶
The following instance data shows the Power State capabilities
of two Components of the same Device: a line card, "linecard-3",
and a fabric module, "fabric-0". Each Component is a separate
per-node-capabilities entry, selected by its own
node-selector. 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 fabric module
supports the same two states, drawing a nominal 120 Watts
(max-power 150 Watts) when on and a nominal 10 Watts
(max-power 20 Watts) in the low-power state. 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
}]
}
},{
"node-selector":
"/ietf-hardware:hardware/component[name='fabric-0']",
"ietf-power-state-capabilities:power-state-capabilities": {
"supported-power-state": [{
"power-state": "ietf-power-and-energy:power-state-on",
"nominal-power": 120,
"max-power": 150
},{
"power-state":
"ietf-power-and-energy:power-state-sleep",
"nominal-power": 10,
"max-power": 20
}]
}
}]
}]
}
}
¶
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.¶
A SerDes (serializer/deserializer) is the mixed-signal circuitry that converts between the Device's parallel datapath and the serial signals carried on the wire or fibre. Each serial path that a SerDes drives is a SerDes lane. A port, an optical module or a fabric link is carried over one or more SerDes lanes; for example, the link between a line-card ASIC and the switching fabric is typically carried over several SerDes lanes. One SerDes usually drives the SerDes lanes of several ports, and it can enter a low-power state only when none of those SerDes lanes is in use, that is, when none of the ports carried over them is in use. That condition is a dependency between Components, which this document does not model (Section 5); it is expressed by the enabling and enabled-by relationships of [I-D.ietf-green-power-and-energy-yang].¶
First, this document advertises that the SerDes Component supports a low-power Power State:¶
{
"ietf-system-capabilities:system-capabilities": {
"datastore-capabilities": [{
"datastore": "ietf-datastores:operational",
"per-node-capabilities": [{
"node-selector":
"/ietf-hardware:hardware/component[name='serdes-0']",
"ietf-power-state-capabilities:power-state-capabilities": {
"supported-power-state": [{
"power-state": "ietf-power-and-energy:power-state-on",
"nominal-power": 5,
"max-power": 6
},{
"power-state":
"ietf-power-and-energy:power-state-sleep",
"nominal-power": 1,
"max-power": 1,
"typical-exit-time": 50,
"max-exit-time": 200
}]
}
}]
}]
}
}
¶
Second, the GREEN Power and Energy model records that the SerDes is enabling the two ports carried over its SerDes lanes, so each must be idle before the SerDes can enter its low-power state:¶
{
"ietf-power-and-energy:energy-objects": {
"energy-object": [{
"id": "serdes-0",
"source-component-id": "serdes-0",
"relationship": [{
"type": "ietf-power-and-energy:enabling",
"peer": [
{ "id": "port-0/0" },
{ "id": "port-0/1" }
]
}]
}]
}
}
¶
A Consumer combines the two: this document shows that serdes-0 can enter a low-power state, and the Power and Energy model shows that it is enabling port-0/0 and port-0/1. The SerDes may therefore be placed in its low-power state only when both ports are themselves idle. The capability stays in this document and the cross-Component dependency stays in the Power and Energy model, consistent with the narrow scope of this document.¶
Note to the RFC Editor: please remove this appendix before publication.¶
Added the "Applicability" and "Applicability to the GREEN Use Cases" sections, and an "Open Issues" section.¶
Two examples: an interface and a line card.¶
Added four per-power-state transition-time leaves (typical-exit-time, max-exit-time, typical-entry-time, and max-entry-time), typed by a new transition-time-ms typedef.¶
Removed the unit-multiplier leaf and the multiplier-based scaling; nominal-power and max-power are now expressed directly in Watts, to align with [I-D.ietf-green-power-and-energy-yang], which removed the multiplier identities.¶
Corrected the reference to the operational power state leaf of [I-D.ietf-green-power-and-energy-yang] from power/oper to power-state/oper.¶
Distinguished nominal-power (the expected operating draw) from max-power (the rated per-state ceiling, the per-state counterpart of nameplate power), and clarified that the model is operational state (config false).¶
Refined the nameplate power and max-power definitions (Terminology and the YANG module): both are rated continuous ceilings, not an expected operating value and not a transient or inrush peak, and max-power is the per-power-state counterpart of nameplate power. Bumped the YANG module revision to 2026-09-22.¶
Clarified that the RFC 9196 "node" is a data node, and that each per-node-capabilities entry is bound to one hardware component through its node-selector.¶
Extended the line card example to two components, a line card and a fabric module, showing one per-node-capabilities entry per component.¶
Made explicit that a component is "sleep-capable" (power-saving capable) when it advertises a low-power power state, as a derived property rather than a separate capability flag.¶
Noted that transition times are relative to power-state-on, and that direct transitions between two low-power states are not modeled.¶
Stated explicitly in Operational Considerations that peak or inrush (transient) power and power-supply capabilities are not modeled, and that a power supply's own power is reported by the GREEN Power and Energy model.¶
Added Operational Considerations guidance to compare max-exit-time against the applicable restoration or latency threshold, not only weigh energy saving, when selecting a low-power state.¶
Noted in the Introduction that on high-speed platforms the pluggable optics can draw more power than the forwarding ASIC.¶
Added a definition of "consumer" in Terminology.¶
Trimmed Operational Considerations to operational guidance, moving the meaning of the nominal-power and max-power values, and the transition scope, into the model section.¶
Added a Design Overview subsection, Identical Components Repeat Their Capabilities.¶
Added, in Relationship to Other Work, that cross-component dependencies such as a SerDes are carried by the enabling and enabled-by relationships of [I-D.ietf-green-power-and-energy-yang].¶
Added a SerDes example in Appendix A.3.¶
Noted in the Interface example that the port and its pluggable transceiver are treated as one component.¶
Stated in the Introduction that cross-layer coordination of energy-saving actions is out of scope.¶
Clarified that a capability entry applies only to the component it names, that an instance-data file should identify the platform and software release it applies to, and that being capable of a low-power state does not make a component eligible to enter it.¶
Clarified that a system-wide entry applies to each component without a per-component entry (module revision 2026-10-26).¶
Removed the Open Issues on the system-wide augmentation and on optional transition durations.¶