OPSA Working Group J. Lindblad Internet-Draft S. Mitrovic Intended status: Standards Track M. Palmero Expires: 22 April 2024 G. Salgueiro Cisco Systems 20 October 2023 Power and Energy Efficiency draft-opsawg-poweff-00 Abstract 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 (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental- impacts-report-00), visibility is a very important first step (paraphrasing Peter Drucker's mantra of "You cannot improve what you don't measure"). During the workshop the need for standardized metrics was established, to avoid proprietary, 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Lindblad, et al. Expires 22 April 2024 [Page 1] Internet-Draft POWEFF October 2023 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Proposed Solution Outline . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 7 6. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.1. ietf-poweff-asset-ext . . . . . . . . . . . . . . . . 8 6.1.2. ietf-poweff-static . . . . . . . . . . . . . . . . . 8 6.1.3. ietf-poweff-environment . . . . . . . . . . . . . . . 9 6.1.4. ietf-poweff-traffic . . . . . . . . . . . . . . . . . 9 6.1.5. ietf-poweff-derived . . . . . . . . . . . . . . . . . 9 6.1.6. ietf-poweff-sensors . . . . . . . . . . . . . . . . . 9 6.1.7. ietf-poweff-types . . . . . . . . . . . . . . . . . . 9 6.1.8. ietf-sustainability-insights-common . . . . . . . . . 9 6.2. YANG data models of POWEFF modules . . . . . . . . . . . 9 6.2.1. Asset Extension Module . . . . . . . . . . . . . . . 9 6.2.2. Power Environment Module . . . . . . . . . . . . . . 11 6.2.3. Power Static Module . . . . . . . . . . . . . . . . . 13 6.2.4. Power Traffic Module . . . . . . . . . . . . . . . . 14 6.2.5. Power Derived Module . . . . . . . . . . . . . . . . 18 6.2.6. Power Sensors Module . . . . . . . . . . . . . . . . 20 6.2.7. Power Types Module . . . . . . . . . . . . . . . . . 27 Lindblad, et al. Expires 22 April 2024 [Page 2] Internet-Draft POWEFF October 2023 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 35 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. 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 [I-D.draft-almprs-sustainability-insights-02] IETF draft. 1.1. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Terminology and abbreviations used in this document: Asset Lindblad, et al. Expires 22 April 2024 [Page 3] Internet-Draft POWEFF October 2023 Refers to hardware, software, applications, or services. An asset can be physical or virtual, as defined in the Asset Lifecycle Management and Operations [I-D.draft-palmero-ivy-ps-almo-00] IETF draft. Scope 1 Emissions directly caused by actions of the organization, such as when fossil fuels are burned when the organization is operating a fossil vehicle. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 2 Emissions indirectly caused by actions of the organization, but under control of the organization. For example, when electric energy is purchased, causing a provider utility to make emissions on behalf of the organization. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 3 Emissions the organization indirectly causes others to make, but outside the organizations direct control. Examples include the energy customers consume when operating the organization's products, or when employees commute to work at the organization. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 4 : Refers to the term used in Greenhouse Gas (GHG) accounting and reporting to describe emissions that occur as a result of an organization's value chain activities, but are not directly controlled or owned by the organization. Scope 4 emissions are considered indirect emissions and are typically associated with activities that are upstream or downstream from a organization's operations. Such as when equipment provided by the organization enables a video conference, without which greater emissions from business travel would have happened. CO2eq Carbon dioxide equivalents, a measure of the disruptive force of greenhouse gas emissions. Power Lindblad, et al. Expires 22 April 2024 [Page 4] Internet-Draft POWEFF October 2023 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 (https://en.wikipedia.org/wiki/Energy_efficiency). 3. 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 (https://www.cisco.com/c/m/en_us/about/csr/esg-hub/environment/ goals.html#scope-1-3-emissions). Power and energy consumption Telemetry data available for different infrastructure vendors today is characterized by inconsistency and best effort: * Availability of primary data. Data is often only available on a case by case basis. * Varying APIs. Where Telemetry might be available, access methods, data contents and formats are specific to platforms or elements. * Limitations. Some useful or essential data items are never collected by the relevant hardware or software. * Precision. Data often contains significant margins of error, both from random noise and systematic errors. Lindblad, et al. Expires 22 April 2024 [Page 5] Internet-Draft POWEFF October 2023 * Varying definitions. Calculated values use differing inputs and algorithms, limiting the value of any possible comparison and aggregation. 3.1. Proposed Solution Outline Formulate a Power and Energy Efficiency Telemetry Specification to promote consistency: Data Definition of datasets and attributes that will define a common 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. 4. 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. Lindblad, et al. Expires 22 April 2024 [Page 6] Internet-Draft POWEFF October 2023 5. 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 (Figure 1). 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 (Figure 1). +---------------------+ | ietf-poweff-derived | +--------+------------+ | +----------------+----------------+ v | v +------------+-------+ | +--------+------------+ | ietf-poweff-static | | | ietf-poweff-traffic | +------------+-------+ | +------------+--------+ | v | | +--------------+----------+ | | | ietf-poweff-environment | | | +--------------+----------+ | | | | +--------------------+----------------+ v +-----------------------+ | ietf-poweff-asset-ext | +-----------------------+ Figure 1: Information POWEFF Model Lindblad, et al. Expires 22 April 2024 [Page 7] Internet-Draft POWEFF October 2023 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. 6. Data Models 6.1. Overview 6.1.1. 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. 6.1.2. 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. Lindblad, et al. Expires 22 April 2024 [Page 8] Internet-Draft POWEFF October 2023 6.1.3. ietf-poweff-environment Describes the runtime values from the assets related to power environment; comprising of reading Voltage, Current, Power (Watts), Temperature, etc. 6.1.4. 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. 6.1.5. 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. 6.1.6. ietf-poweff-sensors Defines basic groupings for POWEFF sensor management 6.1.7. ietf-poweff-types Defines basic quantities, measurement units and sensor types for the POWEFF framework 6.1.8. ietf-sustainability-insights-common Includes common attributes to extend sustainability related use cases as defined in Sustainability Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft. , i.e., carbon intensity factor, cost per kwh, etc. 6.2. YANG data models of POWEFF modules 6.2.1. Asset Extension Module module ietf-poweff-asset-ext { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-asset-ext"; prefix ietf-poweff-asset-ext; import ietf-lmo { prefix ietf-lmo; Lindblad, et al. Expires 22 April 2024 [Page 9] Internet-Draft POWEFF October 2023 } import ietf-lmo-assets { prefix ietf-lmo-asset; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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 { Lindblad, et al. Expires 22 April 2024 [Page 10] Internet-Draft POWEFF October 2023 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"; } } } 6.2.2. Power Environment Module Lindblad, et al. Expires 22 April 2024 [Page 11] Internet-Draft POWEFF October 2023 module ietf-poweff-environment { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-environment"; prefix ietf-poweff-environment; import ietf-poweff-sensors { prefix ietf-poweff-sensors; } import ietf-lmo { prefix ietf-lmo; } import ietf-lmo-assets-inventory { prefix ietf-lmo-asset; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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."; Lindblad, et al. Expires 22 April 2024 [Page 12] Internet-Draft POWEFF October 2023 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; } } 6.2.3. Power Static Module module ietf-poweff-static { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-static"; prefix ietf-poweff-static; import ietf-poweff-sensors { prefix ietf-poweff-sensors; } import ietf-lmo { prefix ietf-lmo; } import ietf-lmo-assets-inventory { prefix ietf-lmo-asset; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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 Lindblad, et al. Expires 22 April 2024 [Page 13] Internet-Draft POWEFF October 2023 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; } } 6.2.4. Power Traffic Module module ietf-poweff-traffic { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-traffic"; prefix ietf-poweff-traffic; import ietf-yang-types { prefix yang; } Lindblad, et al. Expires 22 April 2024 [Page 14] Internet-Draft POWEFF October 2023 import ietf-interfaces { prefix if; } import ietf-lmo-assets-inventory { prefix ietf-lmo-asset; } import ietf-lmo { prefix ietf-lmo; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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 { Lindblad, et al. Expires 22 April 2024 [Page 15] Internet-Draft POWEFF October 2023 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"; } Lindblad, et al. Expires 22 April 2024 [Page 16] Internet-Draft POWEFF October 2023 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; Lindblad, et al. Expires 22 April 2024 [Page 17] Internet-Draft POWEFF October 2023 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"; } } } } 6.2.5. Power Derived Module module ietf-poweff-derived { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-derived"; prefix ietf-poweff-derived; Lindblad, et al. Expires 22 April 2024 [Page 18] Internet-Draft POWEFF October 2023 import ietf-poweff-sensors { prefix ietf-poweff-sensors; } import ietf-lmo { prefix ietf-lmo; } import ietf-lmo-assets-inventory { prefix ietf-lmo-asset; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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 Lindblad, et al. Expires 22 April 2024 [Page 19] Internet-Draft POWEFF October 2023 "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; } } 6.2.6. Power Sensors Module module ietf-poweff-sensors { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-sensors"; prefix ietf-poweff-sensors; import ietf-poweff-types { prefix ietf-poweff-types; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: 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 Lindblad, et al. Expires 22 April 2024 [Page 20] Internet-Draft POWEFF October 2023 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? } Lindblad, et al. Expires 22 April 2024 [Page 21] Internet-Draft POWEFF October 2023 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"; } Lindblad, et al. Expires 22 April 2024 [Page 22] Internet-Draft POWEFF October 2023 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"; } Lindblad, et al. Expires 22 April 2024 [Page 23] Internet-Draft POWEFF October 2023 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."; } Lindblad, et al. Expires 22 April 2024 [Page 24] Internet-Draft POWEFF October 2023 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"; Lindblad, et al. Expires 22 April 2024 [Page 25] Internet-Draft POWEFF October 2023 } 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"; } Lindblad, et al. Expires 22 April 2024 [Page 26] Internet-Draft POWEFF October 2023 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"; } } } } 6.2.7. Power Types Module module ietf-poweff-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-types"; prefix ietf-poweff-types; organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines basic quantities, measurement units Lindblad, et al. Expires 22 April 2024 [Page 27] Internet-Draft POWEFF October 2023 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."; Lindblad, et al. Expires 22 April 2024 [Page 28] Internet-Draft POWEFF October 2023 } 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; Lindblad, et al. Expires 22 April 2024 [Page 29] Internet-Draft POWEFF October 2023 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 { Lindblad, et al. Expires 22 April 2024 [Page 30] Internet-Draft POWEFF October 2023 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; Lindblad, et al. Expires 22 April 2024 [Page 31] Internet-Draft POWEFF October 2023 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 { Lindblad, et al. Expires 22 April 2024 [Page 32] Internet-Draft POWEFF October 2023 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."; } } 7. 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. Lindblad, et al. Expires 22 April 2024 [Page 33] Internet-Draft POWEFF October 2023 * The process to share and collect POWEFF data across the consumers consistently, including the transport mechanism. The POWEFF YANG models can be used with network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc. OpenAPI specification could be considered to consume POWEFF metrics. * How the configuration of assets should be done. 8. Security Considerations The security considerations mentioned in section 17 of [RFC7950] apply. POWEFF brings several security and privacy implications because of the various components and attributes of the information model. For example, each functional component can be tampered with to give manipulated data. POWEFF when used alone or with other relevant 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. 9. IANA Considerations 9.1. The IETF XML Registry This document registers URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the registrations defined below are requested: URI: urn:ietf:params:xml:ns:yang:ietf-lmo Registrant Contact: The OPSA WG of the IETF. XML: N/A, the requested URI is an XML namespace. Lindblad, et al. Expires 22 April 2024 [Page 34] Internet-Draft POWEFF October 2023 9.2. The YANG Module Names Registry This document registers YANG modules in the YANG Module Names registry [RFC7950]. Following the format in [RFC7950], the registrations defined below are requested: name: ietf-poweff-environment namespace: urn:ietf:params:xml:ns:yang:ietf-poweff-environment maintained by IANA: N prefix: ietf-poweff-environment reference: RFC XXXX 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.draft-almprs-sustainability-insights-02] Andersson, P., Lindblad, J., Mitrovic, S., Palmero, M., Roure, E., Salgueiro, G., and S. Emile, "Sustainability Insights", Work in Progress, Internet-Draft, draft-almprs- sustainability-insights-02, 20 October 2023, . [I-D.draft-palmero-ivy-ps-almo-00] Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D. Lopez, "Asset Lifecycle Management and Operations: A Problem Statement", Work in Progress, Internet-Draft, draft-palmero-ivy-ps-almo-00, 20 October 2023, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . Lindblad, et al. Expires 22 April 2024 [Page 35] Internet-Draft POWEFF October 2023 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . 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. Authors' Addresses Jan Lindblad Cisco Systems Email: jlindbla@cisco.com Snezana Mitrovic Cisco Systems Email: snmitrov@cisco.com Marisol Palmero Cisco Systems Email: mpalmero@cisco.com Lindblad, et al. Expires 22 April 2024 [Page 36] Internet-Draft POWEFF October 2023 Gonzalo Salgueiro Cisco Systems Email: gsalguei@cisco.com Lindblad, et al. Expires 22 April 2024 [Page 37]