]> Power and Energy Efficiency All For Eco
jan.lindblad+ietf@for.eco
Cisco Systems
snmitrov@cisco.com
Cisco Systems
mpalmero@cisco.com
Cisco Systems
gsalguei@cisco.com
operations GREEN Working Group Internet-Draft 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 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 Source for this draft and an issue tracker can be found at .
Introduction 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.
Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Terminology Terminology and abbreviations used in this document:
Asset
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.
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.
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.
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.
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.
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. 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 comparisions.
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 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.
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.
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.
Level 0, Proprietary Dashboard Only 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.
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.
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 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)
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.
YANG tree diagram of the Level 2 Dashboard. ../../subsystem/name ]]>
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 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.
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 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%.
YANG tree diagram of the Level 3 Dashboard. /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 ]]>
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:
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  
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'.
YANG tree diagram of the Level 4 Dashboard. ../../service/name ]]>
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.
YANG tree diagram of the Level 5 Dashboard. /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 ]]>
YANG Modules
Module ietf-poweff-types.yang 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. "; } } ]]>
Module ietf-poweff-level-1.yang 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). "; } } } } ]]>
Module ietf-poweff-level-2.yang 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."; } } } } ]]>
Module ietf-poweff-level-3.yang 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%. "; } } } } } ]]>
Module ietf-poweff-level-4.yang 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. "; } } } } ]]>
Module ietf-poweff-level-5.yang 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%. "; } } } } ]]>
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 , RESTCONF , streaming telemetry, etc. OpenAPI specification could be considered to consume POWEFF metrics.
  • How the configuration of assets should be done.
Security Considerations 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.
IANA Considerations
The IETF XML Registry FIXME
The YANG Module Names Registry FIXME
References Normative References Philatelist, YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases All For Eco Timestamped 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 Levels In 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 Words RFC 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. Informative References Asset Lifecycle Management and Operations: A Problem Statement Cisco Systems Cisco Systems NC State University NTT Telefonica I+D This 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 Insights Cisco Systems Cisco Systems Cisco Systems Cisco Systems Cisco Systems Cisco Systems Orange This 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 Protocol This 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 Language YANG 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).
Change log RFC Editor Note: This section is to be removed during the final publication of the document.
  • From version draft-opsawg-poweff-02 to draft-pslm-poweff-00
    • Renamed draft
    • Moved WG to GREEN
    • Updated one author affiliation
    • 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.