GREEN Working Group J. Lindblad
Internet-Draft All For Eco
Intended status: Standards Track S. Mitrovic
Expires: 4 September 2025 M. Palmero
G. Salgueiro
Cisco Systems
3 March 2025
Power and Energy Efficiency
draft-pslm-poweff-01
Abstract
This document specifies a device YANG "dashboard" data model that
allows devices to report which power measurement and control
functions they offer. This basic YANG model is applicable to any
kind of device, regardless of whether the device itself has any
support for YANG-based management interfaces or not. The YANG model
simply allows a device to describe what it can report, and which
interfaces are available to request this data. Devices that lack any
on-board YANG-based management interfaces provide this information in
the form of a YANG instance data file. This file may be readable
from an on-board web server on the device, or hosted anywhere else.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/janlindblad/draft-pslm-poweff.
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 4 September 2025.
Lindblad, et al. Expires 4 September 2025 [Page 1]
Internet-Draft POWEFF March 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Proposed Solution Outline . . . . . . . . . . . . . . . . 5
3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Information Model . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Level 0, Proprietary Dashboard Only . . . . . . . . . . . 7
4.2. Level 1, Current Total Power Draw . . . . . . . . . . . . 7
4.3. Level 2, Add Energy and Susbsystem Breakdown . . . . . . 8
4.4. Level 3, Add Fundamental Power Control . . . . . . . . . 8
4.5. Level 4, Add Service Attribution . . . . . . . . . . . . 10
4.6. Level 5, Add Service Level Power Control . . . . . . . . 12
5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Module ietf-poweff-types.yang . . . . . . . . . . . . . . 12
5.2. Module ietf-poweff-level-1.yang . . . . . . . . . . . . . 21
5.3. Module ietf-poweff-level-2.yang . . . . . . . . . . . . . 23
5.4. Module ietf-poweff-level-3.yang . . . . . . . . . . . . . 26
5.5. Module ietf-poweff-level-4.yang . . . . . . . . . . . . . 30
5.6. Module ietf-poweff-level-5.yang . . . . . . . . . . . . . 33
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 38
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 39
Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
Lindblad, et al. Expires 4 September 2025 [Page 2]
Internet-Draft POWEFF March 2025
1. Introduction
As highlighted during the IAB workshop on environmental impacts
(https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
impacts-report-00), visibility is a very important first step.
Paraphrasing Peter Drucker's mantra of "You cannot improve what you
don't measure". During the workshop the need for standardized
metrics was established, to avoid proprietary, redundant and even
contradictory metrics across vendors.
POWEFF is considered a first step, part of the Sustainability
Telemetry Specification referred as part of the Sustainability
Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft (a
newer version may exist). That is where the overall problem
statement, solution principles and other components of the proposed
solution can be found. Specifically, this work is meant to fit in
with the [I-D.draft-lindblad-tlm-philatelist-03] framework.
This Power Consumption and Energy Efficiency Telemetry Specification
(POWEFF) provides a way for a controller to understand what a device
offers in terms of power related sensors and controls. It also
provides machine readable metadata for the sensors, such as which
units of measurement are used, what is included in the reported data,
the precision of the data, etc. This is referred to as the device
dashboard.
This document also contains embryonic definitions of recommended
datasets and attributes defining a common data model to report Power
Consumption and Energy Efficiency on assets, with multiple
implementation levels, that new devices may choose to implement.
Standardized calculations utilizing the specified datasets and
attributes will yield a power consumption value for any asset or
network element, and standardized calculations utilizing the
specified datasets and attributes will yield the energy efficiency
value for any asset or network element.
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.
2. Terminology
Terminology and abbreviations used in this document:
Lindblad, et al. Expires 4 September 2025 [Page 3]
Internet-Draft POWEFF March 2025
Asset Refers to hardware, software, applications, or services. An
asset can be physical or virtual, as defined in the Asset
Lifecycle Management and Operations
[I-D.draft-palmero-ivy-ps-almo-01] IETF draft.
Scope 1 Emissions directly caused by actions of the organization,
such as when fossil fuels are burned when the organization is
operating a fossil vehicle. See Greenhouse Gas protocol
(https://ghgprotocol.org/).
Scope 2 Emissions indirectly caused by actions of the organization,
but under control of the organization. For example, when electric
energy is purchased, causing a provider utility to make emissions
on behalf of the organization. See Greenhouse Gas protocol
(https://ghgprotocol.org/).
Scope 3 Emissions the organization indirectly causes others to make,
but outside the organizations direct control. Examples include
the energy customers consume when operating the organization's
products, or when employees commute to work at the organization.
See Greenhouse Gas protocol (https://ghgprotocol.org/).
Scope 4 Refers to the term used in Greenhouse Gas (GHG) accounting
and reporting to describe emissions that occur as a result of an
organization's value chain activities, but are not directly
controlled or owned by the organization. Scope 4 emissions are
considered indirect emissions and are typically associated with
activities that are upstream or downstream from a organization's
operations. Such as when equipment provided by the organization
enables a video conference, without which greater emissions from
business travel would have happened.
CO2eq Carbon dioxide equivalents, a measure of the disruptive force
of greenhouse gas emissions.
Power Refers to the (e.g. electrical or optical) energy per unit of
time, supplied to operate an asset, such as a smartphone. It is
usually measured in units of Watts.
Energy Efficiency refers to the ability of an asset to perform its
intended functions while minimizing energy consumption. It refers
to the ratio between the useful output energy and input energy
given by an asset. In a router or a switch, it is a measure of
how efficiently the network element utilizes energy resources to
transmit and process data or perform other network-related tasks.
See Energy efficiency wikipedia (https://en.wikipedia.org/wiki/
Energy_efficiency).
Lindblad, et al. Expires 4 September 2025 [Page 4]
Internet-Draft POWEFF March 2025
3. Motivation
The main objective of POWEFF is to enable Network Controllers to
measure, report and control power and energy related metrics from
networks with many and diverse devices, providing the necessary
insights to improve the overall CO2eq emission for use cases of which
the asset is part. Basically, emissions that address direct use-
phase emissions of Scope 3, Category 11 "use of sold products".
It includes emissions from the use of goods and services sold by the
reporting company or vendor in the reporting year. A vendor’s Scope
3 emissions from use of sold products include the scope 1 and scope 2
emissions of end users. End users include both consumers and
business customers that use final assets. It is important to note
that Scope 3 category 11, reports around 75% of the total Scopes 1, 2
and 3 reported by a given asset. See Cisco ESG Reporting Hub
(https://www.cisco.com/c/m/en_us/about/csr/esg-hub/environment/
goals.html#scope-1-3-emissions).
Power and energy consumption Telemetry data available for different
infrastructure vendors today is characterized by inconsistency and
best effort:
* Availability of primary data. Data is often only available on a
case by case basis.
* Varying APIs. Where Telemetry might be available, access methods,
data contents and formats are specific to platforms or elements.
* Limitations. Some useful or essential data items are never
collected by the relevant hardware or software.
* Precision. Data often contains significant margins of error, both
from random noise and systematic errors.
* Varying definitions. Calculated values use differing inputs and
algorithms, limiting the value of any possible comparison and
aggregation.
* Opacity. Lack of transparency of how and what is being measured
makes it very hard to ascertain fair comparisons.
3.1. Proposed Solution Outline
Formulate a Power and Energy Efficiency Telemetry Specification to
promote consistency:
Data Definition of datasets and attributes that will define a common
Lindblad, et al. Expires 4 September 2025 [Page 5]
Internet-Draft POWEFF March 2025
data model to report power and energy consumption on hardware and
software assets
Calculation Define a standardized calculation utilizing the
specified datasets and attributes which will yield an energy
consumption value for any asset.
Implementing any Sustainability Solution at scale for customers with
a broad range of equipment requires at minimum consistently available
Power Consumption/Energy Efficiency Telemetry. Telemetry
standardization will benefit numerous stakeholders, including
Corporate Social Responsibility (CSR), who have a need for Power
Consumption Telemetry data for a variety of purposes.
3.2. Use Cases
* Monitoring power and energy efficiency based on common metrics.
* Enhance reporting and provide a comprehensive overview for
potentially improving power usage during the operational phase.
* Consumption per device, e.g. wireless environment.
* Capabilities to optimize energy consumption when assets are not in
use, e.g. idle and allocated power.
* Hardware Lifecycle. Circular economy enables to restore product
value at the end of life, there are several options, reuse,
remanufacturing, recycling, repurpose, etc.
More elaborate use cases, e.g. define carbon footprint for network's
usage, might also be derived from POWEFF model, even discussion and
common understanding will be required.
4. Information Model
Implementors of this specification can choose the implementation
level that is appropriate for their device at the current time. As
the implementation matures, higher implementation levels may be
chosen over time. Each implementation level is a superset of the
previous level.
Lindblad, et al. Expires 4 September 2025 [Page 6]
Internet-Draft POWEFF March 2025
4.1. Level 0, Proprietary Dashboard Only
At level 0, the device implements only proprietary dashboards,
without implementing any dashboards with predefined content. This
allows controllers to find the power sensors already present in the
implementation, and read the associated metadata, but may not be well
prepared to really understand the meaning of the data being read.
The dashboard may be provided by an on-board YANG-based management
protocol, or delivered as a YANG instance data file from an on-board
webserver, or delivered as a file by some other mechanism (e.g. web
server elsewhere).
For level 0, the Network Element implements the Philatelist YANG
module ietf-tlm-philatelist-provider. This gives the controller one
or more proprietary dashboard with whatever contents the implementor
sees fit.
4.2. Level 1, Current Total Power Draw
At level 1, the device implements a very small, but well defined
dashboard, and lists it using the Philatelist ietf-tlm-philatelist-
provider module. The level 1 dashboard consists of a single
dashboard item. This dashboard item provides a way for the Network
Controller to read the current total power draw of the Network
Element.
module: ietf-poweff-level-1
+--rw poweff
+--ro stats
+--ro device-current-total-power-draw? uint32
Figure 1: YANG tree diagram of the Level 1 Dashboard.
The following requirements MUST be fulfilled by the Network Element
implementing the level 1 and higher dashboards. + The reported
telemetry data MUST be correct with regards to what is included and
not included for all reported telemetry data values + The metadata
MUST be correct with regards to measurement units for all reported
telemetry data values + The metadata MUST be correct with regards to
apparent/real RMS power, for all reported power and energy data
values + The power consumption values reported MUST NOT be
underestimated over time in actual field use
Lindblad, et al. Expires 4 September 2025 [Page 7]
Internet-Draft POWEFF March 2025
If Network Elements declaring conformance to the level 1, or higher,
dashboard of this specification, do not actually fulfill the
conditions required in this document, that may be construed as
violating the EU Green Claims Directive (GCD), EU 2023/0085(COD)
(https://oeil.secure.europarl.europa.eu/oeil/popups/
ficheprocedure.do?lang=en&reference=2023/0085(COD))
4.3. Level 2, Add Energy and Susbsystem Breakdown
At level 2, on top of all level 1 reporting, the Network Element also
reports the gross energy usage over time (the integral over time of
the power draw), and the power draw can be further inspected for each
major subsystem within the device.
module: ietf-poweff-level-2
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats:
+--ro device-total-energy-spent? uint32
+--ro device-total-energy-spent-since? yang:date-and-time
+--ro subsystem* [name]
+--ro name subsys-name-t
+--ro current-power-draw? uint32
+--ro children* -> ../../subsystem/name
Figure 2: YANG tree diagram of the Level 2 Dashboard.
4.4. Level 3, Add Fundamental Power Control
From this level onward, a YANG-based management protocol is required,
since standards based configuration control of the device is
required.
At level 3, all the reporting functions of level 2 are required, and
also basic control over device global power-save modes. The
controller may choose one of several power saving modes for the
Network Element. Network Element implementors or Standards Defining
Organizations (SDOs) may also augment the mode selection with
additional power saving modes.
The basic principle for the power saving controls is for the Network
Controller to specify how much degradation of the maximum possible
delivered performance it could tolerate, and for the Network Element
to decide on what power saving measures can be taken, while still
fulfilling expectations. The Network Element SHOULD also provide an
estimate of how much power can be saved under the given conditions.
This document specifies four power save modes and two power-save
conditions that apply generally to the power save modes.
Lindblad, et al. Expires 4 September 2025 [Page 8]
Internet-Draft POWEFF March 2025
fully-powered The subsystem is fully powered, i.e. does not take any
power-saving measures that would risk lowering the performance
below normal levels.
powered-off The subsystem is completely powered off, i.e. it is
drawing no or little power while also delivering zero performance.
napping The subsystem is napping, i.e. is taking frequent but brief
pauses in the service it provides. The Network Controller may
specify a max-additional-latency. This determines the maximum
tolerated length of the pauses with reduced performance. This
means the maximum additional delay that this subsystem would incur
on e.g. detecting incoming traffic or performing its function.
throttling The subsystem is throttling, i.e. is running with reduced
capacity in the service it provides. The Network Controller may
specify a max-capacity-reduction. This determines the maximum
tolerated reduction of performance.
For example, if a Network Controller applied throttling with a max-
capacity-reduction value at 50% onto a transport subsystem or service
that consists of 3 underlaying links of equal capacity, the Network
Element might decide to shut down one of the three links.
For all the power-save modes (except the fully-powered mode, in which
these have no effect) the two following general conditions also
apply:
max-time-to-cancel-power-save The maximum time the Controller allows
the subsystem to recover full performance. The subsystem should
not engage in power-saving measures that take longer than this
time to revert to full performance.
estimated-power-reduction The subsystem's own estimate on how much
of its own power draw is reduced by the power-saving measures in
effect.
For example, if a Network Controller applied throttling with a max-
capacity-reduction value at 50% onto a transport subsystem or service
that consists of 3 underlaying links of equal capacity, the Network
Element might decide to shut down one of the three links. The
Network Element might then report an estimated-power-reduction of
33%.
Lindblad, et al. Expires 4 September 2025 [Page 9]
Internet-Draft POWEFF March 2025
module: ietf-poweff-level-3
augment /ietf-poweff-level-1:poweff:
+--rw power-save
+--rw subsystem* [name]
+--rw name -> /poweff/stats/subsystem/name
+--rw (selected-power-save-mode)?
| +--:(fully-powered)
| | +--rw fully-powered? empty
| +--:(powered-off)
| | +--rw powered-off? empty
| +--:(napping)
| | +--rw napping
| | +--rw max-additional-latency? microseconds
| +--:(throttling)
| +--rw throttling
| +--rw max-capacity-reduction? percent
+--rw max-time-to-cancel-power-save? microseconds
+--ro estimated-power-reduction? uint32
Figure 3: YANG tree diagram of the Level 3 Dashboard.
4.5. Level 4, Add Service Attribution
At level 4, the Network Element also provides a list of
services/tenants/clients/domains/functions that it delivers value
towards, and attributes the Network Element's power draw to each of
the services. The list of services may include one
"overhead/idle/other/unknown" entry that absorbs any overhead not
attributable to a particular service. The power draw MAY be further
subdivided for each service by using a dot notation.
One service instance called '-idle-' may be present in the list and
absorb any overhead/idle/other/unknown kind of power draw that the
system would not allocate to any service. It is up to the
implementor to decide what a 'service' means for this type of system.
It may be any kind of service that it delivers user value towards.
For example, if a system serves three customers, X, Y and Z, their
power draw could be declared as follows:
Lindblad, et al. Expires 4 September 2025 [Page 10]
Internet-Draft POWEFF March 2025
+===============+====================+=========================+
| name | current-power-draw | children |
+===============+====================+=========================+
| X | 45 | vpn |
+---------------+--------------------+-------------------------+
| X.vpn | 39 | eth1/16 eth2/33 eth3/11 |
+---------------+--------------------+-------------------------+
| X.vpn.eth1/16 | 14 | |
+---------------+--------------------+-------------------------+
| X.vpn.eth2/33 | 12 | |
+---------------+--------------------+-------------------------+
| X.vpn.eth3/11 | 9 | |
+---------------+--------------------+-------------------------+
| Y | 26 | |
+---------------+--------------------+-------------------------+
| Z | 19 | |
+---------------+--------------------+-------------------------+
| -idle- | 48 | |
+---------------+--------------------+-------------------------+
Table 1
The sum of the current-power-draw top level entries (in this example:
X, Y, Z and -idle-, with values 45 + 26 + 19 + 48 = 138) must match
the value provided in ietf-poweff-level-1:device-current-total-power-
draw
The sub-service values (e.g. X.vpn, 39W) need to be lower than or
equal to (but do not necessarily need to match) their parent level
(e.g. X, 45W).
Note: the name of the children have been abbreviated in the diagram
above. In the actual payload, the full names would always be used,
e.g. 'eth1/16' above would actually be communicated as
'X.vpn.eth1/16'.
module: ietf-poweff-level-4
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats:
+--ro service* [name]
+--ro name string
+--ro current-power-draw? uint32
+--ro children* -> ../../service/name
Figure 4: YANG tree diagram of the Level 4 Dashboard.
Lindblad, et al. Expires 4 September 2025 [Page 11]
Internet-Draft POWEFF March 2025
4.6. Level 5, Add Service Level Power Control
At level 5, the device additionally implements power-save modes per
delivered service. The structure is exactly the same as the level 3
structure, except that it is for services rather than subsystems. A
service would be something that is relevant and meaningful from a
customer's or user's perspective. It is up to the Network Element
implementor to decide exactly what constitutes a service.
module: ietf-poweff-level-5
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save:
+--rw service* [name]
+--rw name -> /poweff/stats/service/name
+--rw (selected-power-save-mode)?
| +--:(fully-powered)
| | +--rw fully-powered? empty
| +--:(powered-off)
| | +--rw powered-off? empty
| +--:(napping)
| | +--rw napping
| | +--rw max-additional-latency? microseconds
| +--:(throttling)
| +--rw throttling
| +--rw max-capacity-reduction? percent
+--rw max-time-to-cancel-power-save? microseconds
+--ro estimated-power-reduction? uint32
Figure 5: YANG tree diagram of the Level 5 Dashboard.
5. YANG Modules
5.1. Module ietf-poweff-types.yang
<CODE BEGINS>
module ietf-poweff-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-types";
prefix ietf-poweff-types;
import ietf-tlm-philatelist-types {
prefix ietf-tlm-philatelist-types;
}
organization
"IETF GREEN (Getting Ready for Energy Efficient Networking)
Working Group";
contact
Lindblad, et al. Expires 4 September 2025 [Page 12]
Internet-Draft POWEFF March 2025
"WG Web: <https://datatracker.ietf.org/wg/green/>
WG List: <mailto:green@ietf.org>
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines basic quantities, measurement units
and sensor types for the POWEFF framework.
Copyright (c) 2021 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 Simplified 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 2024-04-16 {
description
"Restructured to use the Telemetry Philatelist framework";
reference
"RFC XXXX: ...";
}
typedef something {
// FIXME: Used when we haven't decided the type yet
type string;
description "FIXME";
}
typedef xpath {
type string;
// FIXME: Proper type needed
description "FIXME";
}
typedef sample-frequency {
type string;
// FIXME: Proper type needed
description "FIXME";
Lindblad, et al. Expires 4 September 2025 [Page 13]
Internet-Draft POWEFF March 2025
}
// ========== SENSOR-QUANTITY ==============================
identity sq-voltage {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports electric tension, voltage.
";
}
identity sq-current {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports electric current.
";
}
identity sq-power {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports power draw (energy per unit of time).
";
}
identity sq-power-apparent {
base sq-power;
description
"Sensor reports apparent power, i.e. average electrical
current times voltage (in VA).
";
}
identity sq-power-true {
base sq-power;
description
"Sensor reports true power, i.e. integral over current
and voltage at each instant in time.
";
}
identity sq-energy {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports actual energy drawn by asset.
";
}
identity sq-co2-emission {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports CO2 (carbon dioxide) emission by asset.
";
}
identity sq-co2eq-emission {
Lindblad, et al. Expires 4 September 2025 [Page 14]
Internet-Draft POWEFF March 2025
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports CO2 (carbon dioxide) equivalent
emission by asset.
";
}
identity sq-temperature {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports temperature of asset.
";
}
identity sq-time {
base ietf-tlm-philatelist-types:sensor-quantity;
description
"Sensor reports time duration.
";
}
// ========== SENSOR-UNIT ==============================
identity su-volt {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-voltage;
description
"Sensor unit volt, V.
";
}
identity su-ampere {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-current;
description
"Sensor unit ampere, A.
";
}
identity su-watt {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-power;
description
"Sensor unit watt, W.
";
}
identity su-voltampere {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-power;
description
"Sensor unit Volt*Ampere, VA.
";
}
Lindblad, et al. Expires 4 September 2025 [Page 15]
Internet-Draft POWEFF March 2025
identity su-kw {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-power;
description
"Sensor unit kilowatt, kW.
";
}
identity su-joule {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-energy;
description
"Sensor unit joule, J.
";
}
identity su-wh {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-energy;
description
"Sensor unit watthour, Wh.
";
}
identity su-kwh {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-energy;
description
"Sensor unit kliowatthour, kWh.
";
}
identity su-kelvin {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-temperature;
description
"Sensor unit kelvin, K.
";
}
identity su-celsius {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-temperature;
description
"Sensor unit celsius, C.
";
}
identity su-farenheit {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-temperature;
description
"Sensor unit farenheit, F.
";
Lindblad, et al. Expires 4 September 2025 [Page 16]
Internet-Draft POWEFF March 2025
}
identity su-gram {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-co2-emission;
description
"Sensor unit gram, g.
";
}
identity su-kg {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-co2-emission;
description
"Sensor unit kliogram, kg.
";
}
identity su-ton {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-co2-emission;
description
"Sensor unit ton, t.
";
}
identity su-second {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-time;
description
"Sensor unit second, s.
";
}
identity su-millisecond {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-time;
description
"Sensor unit millisecond, ms.
";
}
identity su-microsecond {
base ietf-tlm-philatelist-types:sensor-unit;
base sq-time;
description
"Sensor unit microsecond, us.
";
}
// ========== SENSOR-TYPE ==============================
extension sensor-type {
argument identity-name;
description
Lindblad, et al. Expires 4 September 2025 [Page 17]
Internet-Draft POWEFF March 2025
"YANG Extension used to declare which sensor type
(as in input/output, quantity and unit) it has in a
standardized machine readable way.
See ietf-tlm-philatelist-types:sensor-type.
";
}
identity st-v-in {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-input;
base sq-voltage;
base su-volt;
description
"Sensor reporting Voltage In to asset.
";
}
identity st-v-out {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-output;
base sq-voltage;
base su-volt;
description
"Sensor reporting Voltage Out of asset.
";
}
identity st-i-in {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-input;
base sq-current;
base su-ampere;
description
"Sensor reporting Current In to asset.
";
}
identity st-i-out {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-output;
base sq-current;
base su-ampere;
description
"Sensor reporting Current Out of asset.
";
}
identity st-p-in-apparent-watt {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-input;
base sq-power-apparent;
base su-voltampere;
description
Lindblad, et al. Expires 4 September 2025 [Page 18]
Internet-Draft POWEFF March 2025
"Sensor reporting Power In to asset as apparent (I*U)
power.
";
}
identity st-p-out-apparent-watt {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-output;
base sq-power-apparent;
base su-voltampere;
description
"Sensor reporting Power Out of asset as apparent (I*U)
power.
";
}
identity st-p-in-true-watt {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-input;
base sq-power-true;
base su-watt;
description
"Sensor reporting Power In to asset as true power.
";
}
identity st-p-out-true-watt {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-output;
base sq-power-true;
base su-watt;
description
"Sensor reporting Power Out of asset as true power.
";
}
identity st-p-allocated-watt {
base ietf-tlm-philatelist-types:sensor-type;
base ietf-tlm-philatelist-types:sc-allocated;
base sq-power;
base su-watt;
description
"Sensor reporting Allocated Power for asset.
";
}
identity st-w-j {
base ietf-tlm-philatelist-types:sensor-type;
base sq-energy;
base su-joule;
description
"Sensor reporting energy draw of asset in J.
";
Lindblad, et al. Expires 4 September 2025 [Page 19]
Internet-Draft POWEFF March 2025
}
identity st-w-wh {
base ietf-tlm-philatelist-types:sensor-type;
base sq-energy;
base su-wh;
description
"Sensor reporting energy draw of asset in Wh.
";
}
identity st-w-kwh {
base ietf-tlm-philatelist-types:sensor-type;
base sq-energy;
base su-kwh;
description
"Sensor reporting energy draw of asset in kWh.
";
}
identity st-t-k {
base ietf-tlm-philatelist-types:sensor-type;
base sq-temperature;
base su-kelvin;
description
"Sensor reporting Temperature of asset in K.
";
}
identity st-t-c {
base ietf-tlm-philatelist-types:sensor-type;
base sq-temperature;
base su-celsius;
description
"Sensor reporting Temperature of asset in °C.
";
}
identity st-t-f {
base ietf-tlm-philatelist-types:sensor-type;
base sq-temperature;
base su-farenheit;
description
"Sensor reporting Temperature of asset in °F.
";
}
// ========== TSDB-PATH ======================================
extension tsdb-path {
argument tsdb-path;
description
"YANG Extension for declaring the TSDB path that a given
YANG leaf would have.
Lindblad, et al. Expires 4 September 2025 [Page 20]
Internet-Draft POWEFF March 2025
";
}
// ========== COLLECTION-METHOD ==============================
// None defined here
// ========== POWER-SAVE UNITS ===============================
typedef microseconds {
type uint32;
units us;
description
"Time unit, millionths of a second. 10^-6 seconds.
";
}
typedef percent {
type uint32 {
range 0..100;
}
units %;
description
"Percent fraction, 1/100 of something.
";
}
}
<CODE ENDS>
5.2. Module ietf-poweff-level-1.yang
<CODE BEGINS>
module ietf-poweff-level-1 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-1";
prefix ietf-poweff-level-1;
import ietf-poweff-types {
prefix ietf-poweff-types;
}
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>
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
Lindblad, et al. Expires 4 September 2025 [Page 21]
Internet-Draft POWEFF March 2025
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines the POWEFF Level 1.
Copyright (c) 2024 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.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
";
revision 2024-04-16 {
description
"Initial revision of POWEFF Level 1";
reference
"RFC XXXX: ...";
}
container poweff {
description
"Top level container for POWEFF.
";
container stats {
config false;
description
"Statistics (read-only) branch of POWEFF.
";
leaf device-current-total-power-draw {
type uint32;
units W;
ietf-poweff-types:sensor-type
ietf-poweff-types:st-p-in-true-watt;
ietf-poweff-types:tsdb-path
Lindblad, et al. Expires 4 September 2025 [Page 22]
Internet-Draft POWEFF March 2025
poweff.stats.device_current_total_power_draw;
description
"The current power draw of the device that the
management server pertains to, including power supplies.
Does not include power draw of external cooling systems
that may be required to operate this system.
The power draw MUST be reported in Watts, and MUST be the
true RMS power. The reported value MUST NOT be lower than
the actual power draw. Any violations of these conditions
may be legally construed as greenwashing, as defined by
EU Green Claims Directive (GCD), EU 2023/0085(COD).
";
}
}
}
}
<CODE ENDS>
5.3. Module ietf-poweff-level-2.yang
<CODE BEGINS>
module ietf-poweff-level-2 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-2";
prefix ietf-poweff-level-2;
import ietf-yang-types {
prefix yang;
}
import ietf-poweff-types {
prefix ietf-poweff-types;
}
import ietf-poweff-level-1 {
prefix ietf-poweff-level-1;
}
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>
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
Lindblad, et al. Expires 4 September 2025 [Page 23]
Internet-Draft POWEFF March 2025
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines the POWEFF Level 2.
Copyright (c) 2024 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.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
";
revision 2024-04-16 {
description
"Initial revision of POWEFF Level 2";
reference
"RFC XXXX: ...";
}
typedef subsys-name-t {
type union {
type enumeration {
enum sys {
description "The name of the top level object is 'sys'.";
}
}
type string {
pattern '[a-zA-Z]+[a-zA-Z0-9_/\.:-]*[a-zA-Z0-9_/]+';
}
}
description
"Type for subsystem names. Must start with an ASCII
alpabetic characters. The characters following may also be
numeric characters, dash, underscore, forward slash. Parts of
Lindblad, et al. Expires 4 September 2025 [Page 24]
Internet-Draft POWEFF March 2025
the name may be interpunctuated with a dot or colon.
Interpunctuation must not be the last character in the name.";
}
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats {
description
"Level 2 extends the Level 1 defintions with additional content.
";
leaf device-total-energy-spent {
type uint32;
units J;
ietf-poweff-types:sensor-type
ietf-poweff-types:st-w-j;
ietf-poweff-types:tsdb-path
poweff.stats.device_total_energy_spent;
description
"The total energy spent by the device since the point
in time specified by ../device-total-energy-spent-since.
This is the integral over time of the power draw as specified
by ../ietf-poweff-level-1:device-current-total-power-draw.
The energy used MUST be reported in Joule. The reported value
MUST NOT be lower than the actual energy used.
Any violations of these conditions
may be legally construed as greenwashing, as defined by
EU Green Claims Directive (GCD), EU 2023/0085(COD).";
}
leaf device-total-energy-spent-since {
type yang:date-and-time;
description
"The point in time at which the energy couting started.
Typically at the most recent system initalization.";
}
list subsystem {
key name;
description
"List of subsystems, in a tree structure, as defined by the
system implementor. There MUST be an entry called 'sys',
which MUST have a current-power-draw value equal to the
../ietf-poweff-level-1:device-current-total-power-draw value.
";
leaf name {
type subsys-name-t;
description
"The name of the subsystem. The name is built from the name
of its ancestors joined with a dot (.). The root object of
tree is called 'sys'.
Lindblad, et al. Expires 4 September 2025 [Page 25]
Internet-Draft POWEFF March 2025
An example of a valid tree structure:
- sys
- sys.main-board
- sys.main-board.cpu0
- sys.main-board.cpu1
- sys.linecard1
- sys.linecard1.eth0/1
- sys.psu0
- sys.psu0.fan0
- sys.psu0.fan1
";
}
leaf current-power-draw {
type uint32;
units W;
ietf-poweff-types:sensor-type
ietf-poweff-types:st-p-in-true-watt;
ietf-poweff-types:tsdb-path
poweff.stats.subsystem.current_power_draw;
description
"Current power draw of the subsystem in Watts.
This value MUST be larger than or equal to the sum of the
power draw of all children listed in ../children, if any.";
}
leaf-list children {
type leafref {
path ../../subsystem/name;
}
description
"Children of this subsystem, each contributing to the power
draw of this subsystem.";
}
}
}
}
<CODE ENDS>
5.4. Module ietf-poweff-level-3.yang
<CODE BEGINS>
module ietf-poweff-level-3 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-3";
prefix ietf-poweff-level-3;
import ietf-poweff-types {
prefix ietf-poweff-types;
}
Lindblad, et al. Expires 4 September 2025 [Page 26]
Internet-Draft POWEFF March 2025
import ietf-poweff-level-1 {
prefix ietf-poweff-level-1;
}
import ietf-poweff-level-2 {
prefix ietf-poweff-level-2;
}
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>
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines the POWEFF Level 3.
Copyright (c) 2024 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.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
";
revision 2024-04-16 {
description
"Initial revision of POWEFF Level 3";
reference
Lindblad, et al. Expires 4 September 2025 [Page 27]
Internet-Draft POWEFF March 2025
"RFC XXXX: ...";
}
augment /ietf-poweff-level-1:poweff {
description
"Level 3 extends the Level 1 & 2 defintions with additional
content.
";
container power-save {
description
"Container for power-save control functions that the
Network Controller may use to ask this Network Element
to employ zero or more power-saving techniques.
";
list subsystem {
key name;
description
"List of subsystems that offer power-saving functions.
";
leaf name {
type leafref {
path "/ietf-poweff-level-1:poweff/" +
"ietf-poweff-level-1:stats/"+
"ietf-poweff-level-2:subsystem/"+
"ietf-poweff-level-2:name";
require-instance false;
}
description
"Name of the subsystem that offers power-saving
functionality. This name normally matches one of the
names in the poweff/stats subsystem list, but it is
possible that a subsystem is not listed there e.g.
because it has not started yet, during the system
initialization.
";
}
choice selected-power-save-mode {
description
"Choice of power saving modes that the Controller
may select. Additional power-saving modes may be
augmented into this choice by implementors, but may
not be known/understood by the controller.
";
leaf fully-powered {
type empty;
description
"The subsystem is fully powered, i.e. does not take
Lindblad, et al. Expires 4 September 2025 [Page 28]
Internet-Draft POWEFF March 2025
any power-saving measures that would risk lowering the
performance below normal levels.
";
}
leaf powered-off {
type empty;
description
"The subsystem is completely powered off, i.e. it is
drawing no or little power while also delivering zero
performance.
";
}
container napping {
description
"The subsystem is napping, i.e. is taking frequent but
brief pauses in the service it provides.
";
leaf max-additional-latency {
type ietf-poweff-types:microseconds;
description
"Determines the maximum tolerated length of the pauses
with reduced performance. This means the maximum
additional delay that this subsystem would incur on
e.g. detecting incoming traffic or performing its
function.
";
}
}
container throttling {
description
"The subsystem is throttling, i.e. is running with
reduced capacity in the service it provides.
";
leaf max-capacity-reduction {
type ietf-poweff-types:percent;
description
"Determines the maximum tolerated reduction of
performance. If this setting is applied to a bundle
interface, for example, that consists of 3 underlaying
links of equal capacity, and the controller sets the
max-capacity-reduction value to 50%, the bundle
interface could shut down one of the links.
";
}
}
}
leaf max-time-to-cancel-power-save {
type ietf-poweff-types:microseconds;
Lindblad, et al. Expires 4 September 2025 [Page 29]
Internet-Draft POWEFF March 2025
description
"The maximum time the Controller allows the subsystem
to recover full performance. The subsystem should not
engage in power-saving measures that take longer than
this time to revert to full performance.
";
}
leaf estimated-power-reduction {
type uint32;
config false;
description
"The subsystem's own estimate on how much of its own
power draw that is reduced by the power-saving
measures in effect.
If the controller sets a bundle interface that consists of
3 underlaying links of equal capacity, for example, into
50% throttling mode, the subsystem might shut down one of
the underlaying links and report an
estimated-power-reduction of 33%.
";
}
}
}
}
}
<CODE ENDS>
5.5. Module ietf-poweff-level-4.yang
<CODE BEGINS>
module ietf-poweff-level-4 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-4";
prefix ietf-poweff-level-4;
import ietf-poweff-types {
prefix ietf-poweff-types;
}
import ietf-poweff-level-1 {
prefix ietf-poweff-level-1;
}
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>
Lindblad, et al. Expires 4 September 2025 [Page 30]
Internet-Draft POWEFF March 2025
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines the POWEFF Level 4.
Copyright (c) 2024 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.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
";
revision 2024-04-16 {
description
"Initial revision of POWEFF Level 4";
reference
"RFC XXXX: ...";
}
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats {
description
"Level 4 extends the Level 1, 2 & 3 defintions with
power draw data broken down on services.
";
list service {
key name;
description
"List of services that the Network Element is aware of, and
their current power draw. The power draw MAY be further
Lindblad, et al. Expires 4 September 2025 [Page 31]
Internet-Draft POWEFF March 2025
subdivided for each service by using a dot notation.
One service instance called '-idle-' may be present in the
list and absorb any overhead/idle/other/unknown kind of power
draw that the system would not allocate to any service.
It is up to the implementor to decide what a 'service' means
for this type of system. It may be any kind of service that it
delivers user value towards.
For example, if a system serves three customers, X, Y and Z,
their power draw could be declared as follows:
| name | current- | children |
| | power- | |
| | draw | |
|---------------|----------|-----------------------------|
| X | 45 | [ vpn ] |
| X.vpn | 39 | [ eth1/16 eth2/33 eth3/11 ] |
| X.vpn.eth1/16 | 14 | |
| X.vpn.eth2/33 | 12 | |
| X.vpn.eth3/11 | 9 | |
| Y | 26 | |
| Z | 19 | |
| -idle- | 48 | |
The sum of the current-power-draw top level entries
(in this example: X, Y, Z and -idle-, with values
45 + 26 + 19 + 48 = 138) must match the value provided in
ietf-poweff-level-1:device-current-total-power-draw
The sub-service values (e.g. X.vpn, 39W) need to be lower than
or equal to (but do not necessarily need to match) their
parent level (e.g. X, 45W).
Note: the name of the children have been abbreviated in
the diagram above. In the actual payload, the full names
would always be used, e.g. 'eth1/16' above would actually be
communicated as 'X.vpn.eth1/16'.
";
leaf name {
type string;
description
"Name of the service/tenant/client/domain/function that the
system allocates power draw for. Power draw MAY be further
subdivided for each service by using a dot notation.
";
}
Lindblad, et al. Expires 4 September 2025 [Page 32]
Internet-Draft POWEFF March 2025
leaf current-power-draw {
type uint32;
units W;
ietf-poweff-types:sensor-type
ietf-poweff-types:st-p-in-true-watt;
ietf-poweff-types:tsdb-path
poweff.stats.service.current_power_draw;
description
"The current power draw of the service provided in Watts.
";
}
leaf-list children {
type leafref {
path ../../service/name;
}
description
"Child-services that contribute to the service's power draw.
All leafref values must exactly match the names used in
the name leaf.
";
}
}
}
}
<CODE ENDS>
5.6. Module ietf-poweff-level-5.yang
<CODE BEGINS>
module ietf-poweff-level-5 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-5";
prefix ietf-poweff-level-5;
import ietf-poweff-types {
prefix ietf-poweff-types;
}
import ietf-poweff-level-1 {
prefix ietf-poweff-level-1;
}
import ietf-poweff-level-3 {
prefix ietf-poweff-level-3;
}
import ietf-poweff-level-4 {
prefix ietf-poweff-level-4;
}
organization
Lindblad, et al. Expires 4 September 2025 [Page 33]
Internet-Draft POWEFF March 2025
"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>
Editor: Jan Lindblad
<mailto:jan.lindblad+ietf@for.eco>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines the POWEFF Level 5.
Copyright (c) 2024 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.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
";
revision 2024-04-16 {
description
"Initial revision of POWEFF Level 5";
reference
"RFC XXXX: ...";
}
augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save {
description
"Level 5 extends the Level 3 & 4 defintions with
power control for each on service instance.
";
Lindblad, et al. Expires 4 September 2025 [Page 34]
Internet-Draft POWEFF March 2025
list service {
key name;
description
"List of services that offer power-saving functions.
";
leaf name {
type leafref {
path "/ietf-poweff-level-1:poweff/" +
"ietf-poweff-level-1:stats/"+
"ietf-poweff-level-4:service/"+
"ietf-poweff-level-4:name";
require-instance false;
}
description
"Name of the sservice instance that offers power-saving
functionality. This name normally matches one of the
names in the poweff/stats/service list, but it is
possible that a service is not listed there e.g.
because it has not started yet, or has been removed.
";
}
choice selected-power-save-mode {
// FIXME: This is currently a copy of the level-3 power-save
// modes. If it is to remain so, we should break it out into
// a grouping. But maybe we want them to be different?
description
"Choice of power saving modes that the Controller
may select. Additional power-saving modes may be
augmented into this choice by implementors, but may
not be known/understood by the controller.
";
leaf fully-powered {
type empty;
description
"The service is fully powered, i.e. does not take
any power-saving measures that would risk lowering the
performance below normal levels.
";
}
leaf powered-off {
type empty;
description
"The service is completely powered off, i.e. it is
drawing no or little power while also delivering zero
performance.
";
}
container napping {
Lindblad, et al. Expires 4 September 2025 [Page 35]
Internet-Draft POWEFF March 2025
description
"The service is napping, i.e. is taking frequent but
brief pauses in the service it provides.
";
leaf max-additional-latency {
type ietf-poweff-types:microseconds;
description
"Determines the maximum tolerated length of the pauses
with reduced performance. This means the maximum
additional delay that this service would incur on
e.g. detecting incoming traffic or performing its
function.
";
}
}
container throttling {
description
"The service is throttling, i.e. is running with
reduced capacity in the functionality it provides.
";
leaf max-capacity-reduction {
type ietf-poweff-types:percent;
description
"Determines the maximum tolerated reduction of
performance. If this setting is applied to a bundle
interface, for example, that consists of 3 underlaying
links of equal capacity, and the controller sets the
max-capacity-reduction value to 50%, the bundle
interface could shut down one of the links.
";
}
}
}
leaf max-time-to-cancel-power-save {
type ietf-poweff-types:microseconds;
description
"The maximum time the Controller allows the service
to recover full performance. The service should not
engage in power-saving measures that take longer than
this time to revert to full performance.
";
}
leaf estimated-power-reduction {
type uint32;
config false;
description
"The service's own estimate on how much of its own
power draw that is reduced by the power-saving
Lindblad, et al. Expires 4 September 2025 [Page 36]
Internet-Draft POWEFF March 2025
measures in effect.
If the controller sets a bundle interface that consists of
3 underlaying links of equal capacity, for example, into
50% throttling mode, the service might shut down one of
the underlaying links and report a
estimated-power-reduction of 33%.
";
}
}
}
}
<CODE ENDS>
6. Deployment Considerations
POWEFF data models define the data schemas for power consumption and
energy efficiency data. POWEFF data models are based on YANG. YANG
data models can be used independently of the transport and can be
converted into any encoding format supported by the network
configuration protocol. YANG is therefore largely management
protocol independent.
To enable the exchange of POWEFF data among all interested parties,
deployment considerations that are out of the scope of this document,
will need to include:
* The data structure to describe all metrics and quantify relevant
data consistently, i.e. specific formats like XML or JSON encoded
message would be deemed valid or invalid based on POWEFF models.
* The process to share and collect POWEFF data across the consumers
consistently, including the transport mechanism. The POWEFF YANG
models can be used with network management protocols such as
NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc.
OpenAPI specification could be considered to consume POWEFF
metrics.
* How the configuration of assets should be done.
7. Security Considerations
The security considerations mentioned in section 17 of [RFC7950]
apply.
POWEFF brings several security and privacy implications because of
the various components and attributes of the information model. For
example, each functional component can be tampered with to give
manipulated data. POWEFF when used alone or with other relevant
Lindblad, et al. Expires 4 September 2025 [Page 37]
Internet-Draft POWEFF March 2025
data, can identify an individual, revealing Personal Identifiable
Information (PII). How the configuration of assets should be
accomplished could lead to data being accessed by unauthorized
entities.
Methods exist to secure the communication of management information.
The transport entity of the functional model MUST implement methods
for secure transport. This document also contains an Information
model and Data-Model in which none of the objects defined are
writable. If the objects are deemed sensitive in a particular
environment, access to them MUST be restricted using appropriately
configured security and access control rights. The information model
contains several optional elements which can be enabled or disabled
for the purpose of privacy and security. Proper authentication and
audit trail MUST be included for all the users/processes that access
POWEFF data.
8. IANA Considerations
8.1. The IETF XML Registry
FIXME
8.2. The YANG Module Names Registry
FIXME
9. References
9.1. Normative References
[I-D.draft-lindblad-tlm-philatelist-03]
Lindblad, J., "Philatelist, YANG-based Network Controller
collection and aggregation framework integrating Telemetry
data and Time Series Databases", Work in Progress,
Internet-Draft, draft-lindblad-tlm-philatelist-03, 28
February 2025, <https://datatracker.ietf.org/doc/html/
draft-lindblad-tlm-philatelist-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Lindblad, et al. Expires 4 September 2025 [Page 38]
Internet-Draft POWEFF March 2025
9.2. Informative References
[I-D.draft-almprs-sustainability-insights-02]
Andersson, P., Lindblad, J., Mitrovic, S., Palmero, M.,
Roure, E., Salgueiro, G., and E. Stephan, "Sustainability
Insights", Work in Progress, Internet-Draft, draft-almprs-
sustainability-insights-02, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-almprs-
sustainability-insights-02>.
[I-D.draft-palmero-ivy-ps-almo-01]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
Lopez, "Asset Lifecycle Management and Operations: A
Problem Statement", Work in Progress, Internet-Draft,
draft-palmero-ivy-ps-almo-01, 24 April 2024,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
ps-almo-01>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
Change log
RFC Editor Note: This section is to be removed during the final
publication of the document.
* From version -00 to -01
- Spelling corrections
* From version draft-opsawg-poweff-02 to draft-pslm-poweff-00
- Renamed draft
- Moved WG to GREEN
- Updated one author affiliation
Lindblad, et al. Expires 4 September 2025 [Page 39]
Internet-Draft POWEFF March 2025
- Moved YANG modules to yang/ directory
- Switched to building using MartinThompsons RFC build env.
* From version -01 to -02
- Adapted to leverage the updated Philatelist framework
- Added the dashboard concept
* From version -00 to -01
- Major rewrite as a device level YANG framework
- Added the implementation levels concept
* Version -00
- Initial version.
Acknowledgments
This document was created by meaningful contributions from Per
Andersson, Jeff Apcar, Derek Engi, Esther Roure Vila, Pascal Thubert,
Klaus Verschure, Joel Goergen, Colin Seward, Michael King, Angelo
Fienga and Suresh Krishnan.
The authors wish to thank them and many others for their helpful
comments and suggestions.
Authors' Addresses
Jan Lindblad
All For Eco
Email: jan.lindblad+ietf@for.eco
Snezana Mitrovic
Cisco Systems
Email: snmitrov@cisco.com
Marisol Palmero
Cisco Systems
Email: mpalmero@cisco.com
Lindblad, et al. Expires 4 September 2025 [Page 40]
Internet-Draft POWEFF March 2025
Gonzalo Salgueiro
Cisco Systems
Email: gsalguei@cisco.com
Lindblad, et al. Expires 4 September 2025 [Page 41]