]> Cisco Systems

jlindbla@cisco.com

Cisco Systems

snmitrov@cisco.com

Cisco Systems

mpalmero@cisco.com

Cisco Systems

gsalguei@cisco.com

operations OPSA Working Group Internet-Draft This document motivates and specifies a data model to report power and energy efficiency of an asset. 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, double counting and even contradictory metrics across vendors. This Power and Energy Efficiency Telemetry Specification (POWEFF) is required to promote consistency across vendors and consumers, based on: 1. The definition of datasets and attributes defining a common data model utilized by the standard calculation to yield power and energy efficiency value for any asset or network element. 2. The standard calculations utilizing the specified datasets and attributes which will yield energy consumption and energy efficiency value for any asset or network element. The model provides information and data requirements for calculating the Power and Energy Efficiency for specific assets. Assets can include hardware (physical or virtual), software, applications, or services.

Introduction The ability to speak a common language of how to measure power consumption, and how to use those measurements in calculations to derive meaningful data is an important business objective and central to developing customer insights. Today, vendors work independently to create methods of measurement and algorithms to calculate similar, yet inconsistent common data elements. When different business entities, responsible for developing multiple products and solutions, do not coordinate efforts, varying results causes confusion to downstream consumers of the data. The Power and Energy Efficiency Telemetry Specification seeks to address this inconsistency by providing a single reference for these important activities, aiming to create value through insights. POWEFF is considered a first phase of the Sustainability Telemetry Specification, as defined in the Sustainability Insights IETF draft.

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 electrical energy per unit 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 measure and report power and energy related metrics and provide the necessary insights to improve the overall CO2eq emission for use cases of which the asset contributes during its use. Following product Lifecycle Accounting (LCA), POWEFF focuses on the Use stage defined by the GHG Protocol Accounting and Reporting Standard, which is in accordance with the ISO 14040:44 standards. It includes emissions from the use of goods and services sold by the reporting organization 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.

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 needs.

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 The broad metric classes defined in previous sections that quantify power and energy efficiency can be modeled as shown in the information POWEFF model below. There is an inventory of all assets that the user or vendor possesses. The representation proposes an extension of the inventory module, and include attributes that provide insight to energy efficiency. Attributes defined as "role" of an asset or "location" of a network equipment are meaningful to compute energy efficiency and CO2eq footprint. Each asset will have attributes that determines power usage measured in a controlled environment, and energy consumption measured in production, this includes metrics related to the data traffic being processed by that particular asset. Based on those runtime and static measurements, power and energy metrics will be deduced. For example, when a user needs to measure the power utilization of a specific type of asset, the power information might be retrieved from a database. The asset state (active or not) will determine the energy consumption. As different assets (modules or components) might be part of a specific chassis, they are aggregated to provide power related information as per the information model shown below.

The functional block that refers to poweff-derived, contains the logic to compute power consumed and energy efficiency by the specific assets, as well as the units of measurement. From a simplification of the diagram, poweff-types and poweff-sensors have been excluded. They should be linked to poweff-environment, for the runtime measurements and to poweff-static, covering measurements given by the manufacturer. They described the sensor types, units of measurements and other meaningful caracteristics of sensors.

Data Models

Overview

ietf-poweff-asset-ext Describes and extends asset to cover sustainability use cases. Aligned with the network inventory, asset refers to hardware, software, applications, or services. An asset can be physical or virtual. This model provides the extension grafting point on top of an inventory model.

ietf-poweff-static Evaluating systems should include benchmarks that can be standardized as well as network-specific configurations which may include multiple generations of hardware, a partially filled chassis, or different traffic loads. These data normally corresponds to values provided by the manufacturer. Data for a specific asset that aligns to values provided by the manufacturer can be classified as “static” since they are unlikely to change. It is important to note that those values have been measured under certain conditions, including benchmarks that can be standardized, and network-specific configurations that may include multiple generations of hardware, a partially filled chassis, or different traffic loads. Each chassis is typically benchmarked for Idle, Typical=Operating, and Maximum capacity that might consist of temperature, hardware load, traffic, fans, CPU, memory, etc. For example, a particular chassis is rated to function in a 27C(Typical), 40C(Operating), and 55C(Max) temperature environment. Note that environmental temperature will not be the only required parameter required to retrieve relevant static data for an asset.

ietf-poweff-environment Describes the runtime values from the assets related to power environment; comprising of reading Voltage, Current, Power (Watts), Temperature, etc.

ietf-poweff-traffic Describes the real-time interface and traffic reading from the asset. This module might overlap with current YANG standards implemented at the network device level, but this module offers a level of abstraction to do not only cover networking equipment and a common data module is proposed for consistency, which might map 1:1 to current standards.

ietf-poweff-derived Considers kpi's and metrics computed by an analytics engine, that typically the values provided will be calculated on the collector, even they could be also implemented by the asset.

ietf-poweff-sensors Defines basic groupings for POWEFF sensor management

ietf-poweff-types Defines basic quantities, measurement units and sensor types for the POWEFF framework

ietf-sustainability-insights-common Includes common attributes to extend sustainability related use cases as defined in Sustainability Insights IETF draft. , i.e., carbon intensity factor, cost per kwh, etc.

YANG data models of POWEFF modules

Asset Extension Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module includes extra attributes which complement sustainability for assets. 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 2023-10-12 { description "Initial revision to complement Asset Inventory Module as part of the DMALMO YANG Model, with sustainability attributes"; reference "RFC XXXX: DMALMO YANG Model"; } augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst { when "derived-from-or-self(../ietf-lmo:lmo-class, "+ " 'ietf-lmo-asset:asset')"; description "Assets attributes related to sustainability"; leaf age { type string; description "Age of the asset"; } leaf site { when "not(../ietf-lmo:parent/ietf-lmo:id)"; type string; description "location site name"; // FIXME: Make this a reference to a list of sites? // FIXME: force this to be set for all assets that // do not have a parent? } leaf modular { type boolean; description "The asset is or is not modular"; } leaf status { type string; description "NEED to include: off, enabled, disabled, not present, failed, reserved-on, standby"; //FIXME status is simply the most inconsistent field //with wide variety of values reported. It is better //to make this a Enum with fixed set list of states. } leaf slot { type string; mandatory "true"; description "Defines the slot where the asset is placed in the chasssis. Used to map the sensor to particular UID."; } leaf device-family { type string; description "Device Family - may be derived from the product name or product id. It is to be used for immplementation purpose - filtering capability and future optimization purposes"; } } } ]]>

Power Environment Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module includes the live reading from the network devices related to the power environment. Dynamic/real-time data read from the network device, basically reading Voltage, Current, Power (Watts), and Temperature. 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 2023-10-12 { description "Initial revision to document power environmental related data"; reference "RFC XXXX: ..."; } augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst { when "derived-from-or-self(../ietf-lmo:lmo-class, "+ " 'ietf-lmo-asset:asset')"; description "Assets attributes related to power environment"; uses ietf-poweff-sensors:sensors-g; } } ]]>

Power Static Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module includes power and energy efficiency Product Data. Data for a specific asset that aligns to values provided by the manufacturer can be classified as “static” since they are unlikely to change during the lifetime of the product/asset. They are typically available in a form of data sheets or any kind of simulation tools. 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 2023-10-12 { description "Initial revision to document power static data"; reference "RFC XXXX: ..."; } augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst { when "derived-from-or-self(../ietf-lmo:lmo-class, "+ " 'ietf-lmo-asset:asset')"; description "Assets attributes related to power static attributes"; uses ietf-poweff-sensors:power-static-g; } } ]]>

Power Traffic Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module describes the live interface and traffic related metrics. It should be based on rfc7223, https://datatracker.ietf.org/doc/rfc7223/ 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. 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 2023-10-12 { description "Initial revision to document power traffic data"; reference "RFC XXXX: ..."; } augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst { when "derived-from-or-self(../ietf-lmo:lmo-class, "+ " 'ietf-lmo-asset:asset')"; description "Traffic attributes related to sustainability"; container interfaces { description "Interface parameters"; list interface { key "name"; leaf name { type leafref { path "/if:interfaces/if:interface/if:name"; require-instance false; } description "The name of the interface."; } leaf description { type string; description "A textual description of the interface. A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document. Since ifAlias is defined to be stored in non-volatile storage, the MIB implementation MUST map ifAlias to the value of 'description' in the persistently stored configuration."; reference "RFC 2863: The Interfaces Group MIB - ifAlias"; } leaf if-index { type int32; description "The ifIndex value for the ifEntry represented by this interface"; reference "RFC 2863: The Interfaces Group MIB - ifIndex"; } leaf interface-type { type string; //TO_DO adjust type to identy interface-type or similar description "The type of the interface. When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface. If a client tries to set the type of an interface to a value that can never be used by the system, e.g., if the type is not supported or if the type does not match the name of the interface, the server MUST reject the request. A NETCONF server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case."; reference "RFC 2863: The Interfaces Group MIB - ifType"; } leaf bandwidth { type yang:gauge64; units "kbits/s"; description "It is considered to be the Max bandwidth of the interface, in kbps, it could also be called capacity"; } leaf speed { type yang:gauge64; units "kbits/s"; description "It is considered to be current bandwidth of the interface, in kbps, it could also be called capacity"; } leaf data-rate-frequency { type string; //TO_DO normalized to do not be string, as different devices //will provide different implementation description "The length of time for which data is used to compute load statistics, load-interval command in interface configuration. Default value is 5min"; } container statistics { description "A collection of interface-related statistics objects."; leaf input-data-rate { type uint64; units "kbits/s"; mandatory "true"; description "Input data rate in 1000's of bps. Average number of bits received per second in the last load period (300 sec by default)"; } leaf input-packet-rate { type uint64; units "packet/s"; description "Input packets per second. Average number of packets received per second in the last load period (300 sec by default)"; } leaf output-data-rate { type uint64; units "kbits/s"; mandatory "true"; description "Output data rate in 1000's of bps. Average number of bits sent per second in the last load period (300 sec by default)"; } leaf output-packet-rate { type uint64; units "packet/s"; description "Output packets per second. Average number of packets sent per second in the last load period (300 sec by default)"; } } description "Interface parameters for a specific interface"; } } } } ]]>

Power Derived Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module includes power derived values per asset. Typically, power derived values will be calculated on the receiver, even those values may be provided by the devices as well. Typically we expect chassis to report total psu-input-power and psu-output-power but ptr-bps-ratio may be derived on the receiver side. 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 2023-10-12 { description "Initial revision to document power derived data"; reference "RFC XXXX: ..."; } augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst { when "derived-from-or-self(../ietf-lmo:lmo-class, "+ " 'ietf-lmo-asset:asset')"; description "Power derived attributes related to assets"; uses ietf-poweff-sensors:power-derived-g; } } ]]>

Power Sensors Module

WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines basic groupings for POWEFF sensor management. 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 2023-10-12 { description "Initial revision of POWEFF sensors"; reference "RFC XXXX: ..."; } grouping sensors-g { description "sensors grouping"; container sensors { description "list of sensors"; list sensor { key "sensor-type"; description "list of sensors attached to this asset"; leaf sensor-type { type identityref { base ietf-poweff-types:sensor-type; } // FIXME: Are we fine with a single sensor of each type // for each asset? I.e. is there ever a need for more than // one Vin-sensor on a particular asset? Ever more than one // Temp-sensor? If so, we need to add a second key here. description "Type of sensor sending data per asset: Vin, Iin, Vout, Iout, Pin, Pout, Palloc, Temp, etc. Sensor type specifies which unit of measurement is used."; } leaf sensor-location { type string; mandatory "true"; description "Indicates the current location where the sensor is located in the chassis,typically refers to slot"; } leaf sensor-state { type string; description "Current state of the sensor"; // FIXME: What does this mean? } leaf sensor-current-reading { type string; config false; description "Current reading of the sensor"; } leaf sensor-accuracy-eligible { type boolean; default false; description "Used to identify which sensor/assets reading shall be included in real metrics"; } leaf sensor-accuracy { type string; must "../sensor-accuracy-eligible = 'true'"; description "Maximum deviation to be considered. This attribute mainly will apply to drawn power, which corresponds to PSU PowerIn measured power or calculated power; assuming discrepancy between Real Power, power collected from a power meter, and power measured or calculated from the metrics provided by the sensors"; } container sensor-thresholds { description "Threshold values for the particular sensor. Default values shall beprovided as part of static data but when configurable need to be pulledfrom the device. Ideally, the sensor should allow configuing thesethreshold values"; leaf minor-low { type string; description "minor-low"; } leaf minor-high { type string; description "minor-high"; } leaf major-low { type string; description "major-low"; } leaf major-high { type string; description "major-high"; } leaf critical-low { type string; description "critical-low"; } leaf critical-high { type string; description "critical-high"; } leaf shutdown { type string; description "shutdown"; } } } } } grouping power-derived-g { description "define derived metrics"; container power-derived { config false; description "power derived attributes"; leaf heat-dissipation { type string; description "It refers to Heat Transfer, i.e. heat transferred from hotter object to coolerobject (1W = 3.412BTU/h)"; } leaf rated-input-pwr-value { type string; mandatory "true"; description "Total Input Power for the chassis and specific inventory inside. The sum for all assets for specific hardware configuration. Can be calculated for Typical, Operating, or Maximum anticipated Capacity Load. Mainly used for dimensioning based on benchmark data"; } leaf asset-input-pwr { type string; mandatory "true"; description "For a given asset, assumed input power means the rate of electricity consumption in Watts provided by the network device or sensor. Conditionally derived - if the device/sensor can give actualpower draw then this calculation is not required, and will be taken directly from the sensor."; } leaf asset-output-pwr { type string; description "Watts provided to the internal components for a given asset. Only applicable to assets that provide output power, such as PSUs. This is present here to accommodate chassis that don’t provide Watt value currently. Ideal implementation should provide Pout sensor reading"; //FIXME: add condition this is mandatory for when asset is //chassis or PSU and not LC or Port; } leaf psu-input-power { type string; mandatory "true"; description "Total input power per chassis, rate of the electricity consumption in Watts. Sum of asset-input-pwr when uid=PSU. It considers all operational PSU'́s to the chassis"; } leaf psu-output-power { type string; mandatory "true"; description "Total input power for chassis, rate of the electricity consumption inWatts. Sum of asset-output-pwr when uid=PSU. It considers alloperational PSU's to the chassis"; } leaf psu-pwr-ratio { type string; mandatory "true"; description "Define dynamic (current) power ratio taking into consideration total system real power input vs used. Not expected to be the same as PSU efficiency. Formula: (psu-output-power / psu-input-power) * 100.0. It considers all operational PSU ́s to the chassis."; } leaf energy-traffic-ratio { type string; mandatory "true"; description "How much Watts is spent to move 100Gigaytes per chassis within thetime period; Formula: psu-output-power [Watt] /SUM of all interfaces (input-data-rate-bits + output-data-rate-bits). Measured over a period of 1hr. energy-traffic-ratio is the value considered for the complete chassis and all operational LC ́s/interfaces."; } } } grouping power-static-g { description "define static attributes"; container power-static { description "power static attributes"; leaf max-amp { type string; mandatory "true"; description "For a given asset, it is the current in Amperes that the asset could withdraw at Maximum capacity"; } leaf output-amp { type string; mandatory "true"; description "For a given asset, it is the current in Amperes that the asset couldwithdraw at Operating capacity."; } leaf input-amp { type string; mandatory "true"; description "Current of an asset at a typical power consumption of switch in Amperes. Somethimes refered to as input-current"; } leaf max-output-pwr { type string; mandatory "true"; description "For a given asset, it is the maximum power in Watts that the asset could draw at Maximum capacity"; } leaf output-pwr { type string; mandatory "true"; description "For a given asset, it is the power in Watts that the asset could withdraw at Operating capacity"; } leaf typical-output-pwr { type string; mandatory "true"; description "This value is an estimation of the average power usage in Watts that the same configuration will use at Typical capacity"; } leaf accuracy-pwr { type string; description "If known, the maximum deviation of power to be considered. BU shouldprovide an estimation"; } leaf inline-pwr { type string; mandatory "true"; description "Available PoE Power i.e the power which can be passed over ethernet cables to power devices."; } leaf psu-efficiency { type string; mandatory "true"; description "Rating the PSU has been certified for against 80plus certification specification. The amount of the actual power delivered to the assetdivided by the electrical power drawn from the main supply socket.i.e. Output Power of System/ Input Power of PSU. The objective for psu-efficiency values is to reach 80+ certification. Please refer to https://www.clearesult.com/80plus"; } leaf voltage-type { type string; mandatory "true"; description "AC/DC/HVDC. Note: DC typically gives an accurate measure, but AC, due to the nature of the metric is not accurate"; } leaf idle-pwr { type string; mandatory "true"; description "Initial power allocated to the asset with no traffic load"; } leaf max-temperature { type string; mandatory "true"; description "Operating temperature - i.e max temperature tolerance (temperaturerange expands to approximately -40°C to 85°C). If the asset exceeds themax temperature limit, it either slows down or stops completely"; } leaf pwr-saving-mode { type string; mandatory "true"; description "Does the asset support any power-saving software feature Y/N. Will beexpanded in future releases"; } } } } ]]>

Power Types Module

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 2023-10-12 { description "Initial revision of POWEFF types"; reference "RFC XXXX: ..."; } identity sensor-class { description "Sensor's relation to the asset it sits on."; } identity sc-input { base sensor-class; description "Sensor reports input quantity of the asset it sits on."; } identity sc-output { base sensor-class; description "Sensor reports output quantity of the asset it sits on."; } identity sc-allocated { base sensor-class; description "Sensor reports (maximum) allocated quantity of the asset it sits on."; } identity sensor-quantity { description "Sensor's quantity being measured."; } identity sq-voltage { base sensor-quantity; description "Sensor reports electric tension, voltage."; } identity sq-current { base sensor-quantity; description "Sensor reports electric current."; } identity sq-power { base 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 sensor-quantity; description "Sensor reports actual energy drawn by asset."; } identity sq-co2-emission { base sensor-quantity; description "Sensor reports CO2 (carbon dioxide) emission by asset."; } identity sq-co2eq-emission { base sensor-quantity; description "Sensor reports CO2 (carbon dioxide) equivalent emission by asset."; } identity sq-temperature { base sensor-quantity; description "Sensor reports temperature of asset."; } identity sensor-unit { description "Sensor's unit of reporting."; } identity su-volt { base sensor-unit; base sq-voltage; description "Sensor unit volt, V."; } identity su-ampere { base sensor-unit; base sq-current; description "Sensor unit ampere, A."; } identity su-watt { base sensor-unit; base sq-power; description "Sensor unit watt, W."; } identity su-voltampere { base sensor-unit; base sq-power; description "Sensor unit Volt*Ampere, VA."; } identity su-kw { base sensor-unit; base sq-power; description "Sensor unit kilowatt, kW."; } identity su-joule { base sensor-unit; base sq-energy; description "Sensor unit joule, J."; } identity su-wh { base sensor-unit; base sq-energy; description "Sensor unit watthour, Wh."; } identity su-kwh { base sensor-unit; base sq-energy; description "Sensor unit kliowatthour, kWh."; } identity su-kelvin { base sensor-unit; base sq-temperature; description "Sensor unit kelvin, K."; } identity su-celsius { base sensor-unit; base sq-temperature; description "Sensor unit celsius, C."; } identity su-farenheit { base sensor-unit; base sq-temperature; description "Sensor unit farenheit, F."; } identity su-gram { base sensor-unit; base sq-co2-emission; description "Sensor unit gram, g."; } identity su-kg { base sensor-unit; base sq-co2-emission; description "Sensor unit kliogram, kg."; } identity su-ton { base sensor-unit; base sq-co2-emission; description "Sensor unit ton, t."; } identity sensor-type { description "Sensor's type, i.e. combination of class, quantity and unit."; } identity st-v-in { base sensor-type; base sc-input; base sq-voltage; base su-volt; description "Sensor reporting Voltage In to asset."; } identity st-v-out { base sensor-type; base sc-output; base sq-voltage; base su-volt; description "Sensor reporting Voltage Out of asset."; } identity st-i-in { base sensor-type; base sc-input; base sq-current; base su-ampere; description "Sensor reporting Current In to asset."; } identity st-i-out { base sensor-type; base sc-output; base sq-current; base su-ampere; description "Sensor reporting Current Out of asset."; } identity st-p-in-apparent-watt { base sensor-type; base 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 sensor-type; base 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 sensor-type; base 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 sensor-type; base 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 sensor-type; base sc-allocated; base sq-power; base su-watt; description "Sensor reporting Allocated Power for asset."; } identity st-w-j { base sensor-type; base sq-energy; base su-joule; description "Sensor reporting energy draw of asset in J."; } identity st-w-wh { base sensor-type; base sq-energy; base su-wh; description "Sensor reporting energy draw of asset in Wh."; } identity st-w-kwh { base sensor-type; base sq-energy; base su-kwh; description "Sensor reporting energy draw of asset in kWh."; } identity st-t-k { base sensor-type; base sq-temperature; base su-kelvin; description "Sensor reporting Temperature of asset in K."; } identity st-t-c { base sensor-type; base sq-temperature; base su-celsius; description "Sensor reporting Temperature of asset in °C."; } identity st-t-f { base sensor-type; base sq-temperature; base su-farenheit; description "Sensor reporting Temperature of asset in °F."; } } ]]>

Deployment Considerations POWEFF data models define the data schemas for power and energy efficiency data. POWEFF data models are based on YANG. YANG is protocol independent. YANG data models can be used independently of the transport and can be converted into any encoding format supported by the network configuration protocol. 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 This document registers URIs in the IETF XML registry . Following the format in , the registrations defined below are requested:

The YANG Module Names Registry This document registers YANG modules in the YANG Module Names registry . Following the format in , the registrations defined below are requested:

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. 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. 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 is proposed whose primary objective is to 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. 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. 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] 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). 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). This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

Change log RFC Editor Note: This section is to be removed during the final publication of the document. 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.