Power and Energy EfficiencyCisco Systemsjlindbla@cisco.comCisco Systemssnmitrov@cisco.comCisco Systemsmpalmero@cisco.comCisco Systemsgsalguei@cisco.com
operations
OPSA Working GroupInternet-DraftThis 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 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.As highlighted during the IAB workshop on environmental impacts, 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 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 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 multuple implementation levels, that new devices may choose to implement. Standardized calculations utilizing the specified datasets and attributes which will yield a power consumption value for any asset or network element, and standardized calculations utilizing the specified datasets and attributes which will yield the energy efficiency value for any asset or network element.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 and abbreviations used in this document:
Refers to hardware, software, applications, or services. An asset can be physical or virtual, as defined in the Asset Lifecycle Management and Operations IETF draft.
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.
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.
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.
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.
Carbon dioxide equivalents, a measure of the disruptive force of greenhouse gas emissions.
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.
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.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.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 basisVarying APIs. Where Telemetry might be available, access methods, data contents and formats are specific to platforms or elementsLimitations. Some useful or essential data items are never collected by the relevant hardware or softwarePrecision. Data often contains significant margins of error, both from random noise and systematic errorsVarying definitions. Calculated values use differing inputs and algorithms, limiting the value of any possible comparison and aggregationOpacity. Lack of transparency of how and what is being measured makes it very hard to ascertain fair comparisions.Formulate a Power and Energy Efficiency Telemetry Specification to promote consistency:
Definition of datasets and attributes that will define a common data model to report power and energy consumption on hardware and software assets
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.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.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.At level 0, the device implements only proprietary dashboards, without implmementing 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 delievered 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.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.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 useIf 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)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. ../../subsystem/name
]]>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 performace it could tolerate, and for the Network Element to decide on what power saving measures that 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.
The subsystem is fully powered, i.e. does not take any power-saving measures that would risk lowering the performance below normal levels.
The subsystem is completely powered off, i.e. it is drawing no or little power while also delivering zero performance.
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.
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:
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.
The subsystem’s own estimate on how much of its own power draw that 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%. /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
]]>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:namecurrent-power-drawchildrenX45vpnX.vpn39eth1/16 eth2/33 eth3/11X.vpn.eth1/1614X.vpn.eth2/3312X.vpn.eth3/119Y26Z19-idle-48The 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-drawThe 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’. ../../service/name
]]>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. /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
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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";
}
// ========== 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 {
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.
";
}
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.
";
}
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
"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
"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.
";
}
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.
";
}
// ========== 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.
";
}
}
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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
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).
";
}
}
}
}
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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
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'.
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.";
}
}
}
}
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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
"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
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;
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%.
";
}
}
}
}
}
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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
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.
";
}
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.
";
}
}
}
}
]]>
WG List:
Editor: Jan Lindblad
Editor: Snezana Mitrovic
Editor: Marisol Palmero
";
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.
";
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 {
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
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%.
";
}
}
}
}
]]>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 , RESTCONF , streaming telemetry, etc. OpenAPI specification could be considered to consume POWEFF metrics.How the configuration of assets should be done.The security considerations mentioned in section 17 of 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 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.FIXMEFIXMEPhilatelist, YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series DatabasesTimestamped telemetry data is collected en masse today. Mature tools
are typically used, but the data is often collected in an ad hoc
manner. While the dashboard graphs look great, the resulting data is
often of questionable quality, not well defined, and hard to compare
with seemingly similar data from other organizations.This document proposes a standard, extensible, cross domain framework
for collecting and aggregating timestamped telemetry data in a way
that combines YANG, metadata and Time Series Databases to produce
more transparent, dependable and comparable results. This framework
is implemented in the Network Controller layer, but is rooted in data
that is collected from all kinds of Network Elements and related
systems.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Asset Lifecycle Management and Operations: A Problem StatementCisco SystemsCisco SystemsNC State UniversityNTTTelefonica I+DThis document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model. The primaty objectives for the problem statement document is to validate and proof that the framework can measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset.Sustainability InsightsCisco SystemsCisco SystemsCisco SystemsCisco SystemsCisco SystemsCisco SystemsOrangeThis document motivates the collection and aggregation of sustainability environmental related metrics. It describes the motivation and requirements to collect asset centric metrics including but not limited to power consumption and energy efficiency, circular economy properties, and more general metrics useful in environmental impact analysis. It provides foundations for building an industry-wide, open-source framework for the reduction of greenhouse gas emissions, enabling measurement and optimization of the overall impact on the environment of networking devices, software applications, services, and solutions across the lifecycle journey.Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RFC Editor Note: This section is to be removed during the final publication of the document.From version -01 to -02 Adapted to leverage the updated Philatelist frameworkAdded the dashboard conceptFrom version -00 to -01 Major rewrite as a device level YANG frameworkAdded the implementation levels conceptVersion -00 Initial version.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.