A YANG Data Model for
Power State Capability Discovery
Everything OPS & Arrcus
Belgium
benoit@everything-ops.net
Deutsche Telekom
Germany
Nils.Warnke@telekom.de
Equinix
Canada
reshad@yahoo.com
Huawei
China
chengen@huawei.com
Virgin Media O2
UK
gary.woodward1@virginmediao2.co.uk
Operations and Management
GREEN Working Group
energy efficiency
power state
capability discovery
YANG
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.
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. 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:
- which Power States the Component actually supports;
- where it is known, how much Power the Component draws in each
supported state; and
- where it is known, how long the Component takes to enter and
exit each Power State.
The GREEN Power and Energy YANG module
models the
operational side of this problem: for each Energy Object it
reports the current administrative and operational Power State
(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 and its
IS-IS encoding introduce
their own "sleep-capable" indication and Power Savings Potential
value, defined independently of the GREEN data model. This document
defines a single capability model, discoverable through the
standard system capabilities mechanism of ,
from which those quantities can be derived -- for example, Power
Savings Potential as the difference between the nominal Power of
power-state-on and that of a low-power state -- rather than
defined separately by
each Consumer.
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
. 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.
Requirements Language
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.
Terminology
This document makes use of the terms defined in
. Terms reused from that
document are capitalized in this specification, including in
particular Component, Device, Power, Power State, Power State Set,
Nameplate Power, Energy Object, Energy Saving, and Energy
Management System.
The term "Power Savings Potential (PSP)" is used as defined in
.
In this document, 'admin' and 'oper' are the two
leaves of the GREEN Power and Energy model
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:
- Consumer:
- any system that reads the Power State capabilities, whether
from a Device or from an instance-data file, for example an Energy
Management System, a controller, a path computation function, or a
planning tool.
- Nameplate Power:
- the maximum sustained (continuous) Power a Component is
designed to consume, as specified by the manufacturer, as
reported by the nameplate-power leaf of
. It is a
rated design ceiling, not an expected operating value, and not a
transient or inrush peak.
- max-power (per Power State):
- the maximum sustained (continuous) Power a Component may draw
in a given Power State, the per-state counterpart of Nameplate
Power. It is a rated design ceiling, not an expected operating
value, and not a transient or inrush peak. For
power-state-on (the most power-consuming state) it is at
most the Component's Nameplate Power (see
).
- 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.
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 , 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
, 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
, 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.
Applicability to the GREEN Use Cases
This section analyzes the applicability of this document
against the use cases specified in
.
Note: 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, as input, a
machine-readable, vendor-independent description of what each
Component can do.
Design Overview
The design follows five principles. The final subsection records
a limitation of the current approach regarding the potential
repetitive information.
Capability is Kept Separate from Operational State
The set of supported Power States and their characterization is
a capability, not operational state. It is therefore carried in the system
capabilities subtree of rather than being
mixed into the operational power data of
. Keeping the
capability model separate from live status lets a management system learn a
Component's Power States without querying a running Device -- and,
as describes, even from a
vendor-supplied file before the Component is deployed.
Capability is Anchored to the Hardware Component
A Power State is a property of a physical Component (a line card,
a fabric, an optical module), which is exactly the entity that is
placed into a low-power state. This document therefore anchors the
capability to a Component in the hardware inventory
, using the per-node capability mechanism of
. 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 and reused by
: 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 , as illustrated
below:
No new correlation identifier is required. The GREEN Power and
Energy model already binds each of its energy-entry
instances to a hardware Component through the
source-component-id leafref to
/hw:hardware/hw:component/hw:name. As a result the hardware
inventory (RFC 8348), the capability model (this document), and
the live operational state
() all refer to
one and the same Component name, and no change to the GREEN module
is needed.
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
hardware hierarchy. This follows from Energy Objects inheriting
their containment from the hardware component tree
: 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.
Power State Names are Reused, Not Reinvented
The supported Power States are identified by identities derived
from the power-state base identity already defined in
(namely
power-state-on, power-state-off, and
power-state-sleep). Where a Component supports more than one
low-power depth, additional identities are derived from
power-state-sleep; such a collection of related states forms
a Power State Set, and its member names should align
with the Power State Sets described in
rather than
being independently invented, so that Consumers can compare states
across vendors.
The Characterization is a Reusable Grouping
The per-state characterization is defined once, as the YANG
grouping power-state-capability ().
The grouping is used both at the system-wide level and at the
per-Component level of -- the same
two-level structure as the companion
ietf-notification-capabilities module of
.
uses
the same mechanism for YANG-Push transport capabilities, although
it augments at the system-wide level only.
Capability MAY be Provided as Instance Data (RFC 9195)
Because the capability is static and platform-specific, it does
not have to be read from a running Device. It MAY be
published by a vendor, or generated from a product data sheet, as a
YANG instance data file per . An Energy
Management System or a planning tool can thereby learn the Power
State capabilities of a platform -- which Components can sleep and
how much Power they save -- at design or procurement time, before
any equipment is deployed. When the Device
is running, the same data MAY instead be read from
the operational state datastore. The two sources use the identical
schema defined here. 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 , while data read from a running
Device reflects the release that Device is running.
Identical Components Repeat Their Capabilities
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
(): its
predicates may address only list keys, and may be omitted. The
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. 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
, not hand-maintained. Where a Device is
homogeneous, the system-wide capability augmentation can carry the
common per-Component figures once.
Relationship to Other Work
This document is deliberately narrow: it supplies the missing
capability layer that three existing efforts each assume but none
provides in a common form.
reports, for
a Component, the Power State it is in now and its measured Power.
This document adds the static complement: the set of Power States
that Component can enter and, 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
(); they are carried instead by the enabling
and enabled-by relationships of
, 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.
gives a worked example.
and
define a Power Conserving
Path Placement Strategy and its IS-IS encoding, which need to know
which resources are sleep-capable and their Power Savings Potential.
With this capability model both become derived facts rather than
separately defined values: a Component is "sleep-capable"
(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 ). 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
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.
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,
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
. 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.
Tree Structure
The following tree diagram uses the notation defined in
.
YANG Module
This module imports the system capabilities module of
and reuses the power-state
identities of .
WG List:
Author: Benoit Claise
Author: Nils Warnke
Author: Reshad Rahman
Author: Gen Chen
Author: Gary Woodward
";
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;
}
}
}
]]>
Operational Considerations
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 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 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
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.,
/ ), 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.
Open Issues
This section is to be removed before publication.
- should adopt this
document's definition of Nameplate Power, namely the maximum
sustained (continuous) Power a Component is designed to consume,
and drop the word "nominal", which this document uses for the
expected operating draw.
- Transition times are defined relative to
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.
Security Considerations
This section is modeled after the template described in
Section 3.7.1 of .
The "ietf-power-state-capabilities" YANG module defines a data
model that is designed to be accessed via YANG-based management
protocols, such as the Network Configuration Protocol (NETCONF)
and RESTCONF .
These YANG-based management protocols (1) have to use a secure
transport layer (e.g., Secure Shell (SSH) ,
TLS , and QUIC ) and
(2) have to use mutual authentication.
The Network Configuration Access Control Model (NACM)
provides the means to restrict access for
particular NETCONF or RESTCONF users to a preconfigured subset of
all available NETCONF or RESTCONF protocol operations and
content.
All data nodes defined in this YANG module are read-only
("config false") operational state, which may equivalently be
provided as instance data (). The
module defines no writable data nodes, no RPC or action operations,
and no notifications.
Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. Specifically, the
"power-state-capabilities" subtree -- the set of Power States a
Component supports and the nominal Power of each -- reveals which
Components of a Device can be placed into a low-power state and how
much Power that would save. An attacker with read access to this
information can identify the resources whose repeated forced wake-up
would cause the greatest energy or thrashing amplification, or whose
sleeping would most usefully be prevented to degrade capacity. 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 . Read
access to this subtree SHOULD be restricted, and,
when the capability is distributed as a YANG instance data file
, the file SHOULD be handled
with the same care as other platform capability inventories.
IANA Considerations
This document requests IANA to register the following URI in the
"ns" subregistry of the "IETF XML Registry"
:
This document requests IANA to register the following YANG module
in the "YANG Module Names" subregistry
within the "YANG Parameters" registry:
Acknowledgments
This work builds directly on the GREEN Power and Energy YANG model
and terminology, and on the system capabilities framework of
RFC 9196.
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
. This document realizes that
intent using standardized mechanisms: anchoring to
, augmenting , and
pre-deployment delivery per .
The authors thank Marisol Palmero and Qin Wu for their reviews
and comments on this work.
Normative References
Informative References
Power Capabilities Examples
Interface Power Capability Example
The following JSON 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
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 (), 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 :
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.
The long "node-selector" line is wrapped using the
"\\" line-folding strategy of .
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 ).
Line Card Power Capability Example
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
, 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
, could be shipped by the vendor before
deployment.
From these values, the Power Savings Potential of the sleep
state (power-state-sleep) is derived by subtraction:
200 - 15 = 185 Watts, consistent with the Power Savings Potential
convention of . This is a
planning-time estimate; the operational, load-dependent value is out
of scope (see ). For completeness, the
current Power State and the measured, load- and temperature-dependent
Power of the same line card are reported separately by
-- 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.
SerDes and the enabling Relationship
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
(); it is expressed by the enabling and
enabled-by relationships of
.
First, this document advertises that the SerDes Component
supports a low-power Power State:
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:
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.
Changes
Note to the RFC Editor: please remove this appendix before
publication.
Changes from 00 to 01
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 , which
removed the multiplier identities.
Corrected the reference to the operational power state leaf of
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).
Changes from 01 to 02
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.
Changes from 02 to 03
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
.
Added a SerDes example in .
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.