Proposed Sustainability and the Internet Proposed Research GroupA. Gallego Sanchez Internet-Draft T-Systems Intended status: Informational A. Rodriguez-Natal Expires: 23 April 2026 Cisco L. M. Contreras Telefonica M. Palmero J. Lindblad All For Eco October 2025 Path Energy Traffic Ratio API (PETRA) Augmented draft-malja-sustain-petra-augmented-00 Abstract This document describes an API to query a network regarding its Energy Traffic Ratio and other energy-related metric for a given network path. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://galledohm.github.io/draft-malja-sustain-petra-augmented/ draft-malja-sustain-petra-augmented.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- malja-sustain-petra-augmented/. Discussion of this document takes place on the Proposed Sustainability and the Internet Proposed Research Group Research Group mailing list (mailto:sustain@irtf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sustain/. Subscribe at https://www.ietf.org/mailman/listinfo/sustain/. Source for this draft and an issue tracker can be found at https://github.com/galledohm/draft-malja-sustain-petra-augmented. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Gallego Sanchez, et al. Expires 23 April 2026 [Page 1] Internet-Draft Energy-API Augmented October 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Path Energy Traffic Ratio API (PETRA) . . . . . . . . . . . . 3 3.1. Energy Information . . . . . . . . . . . . . . . . . . . 4 3.2. Recursive Usage . . . . . . . . . . . . . . . . . . . . . 5 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Module Structure . . . . . . . . . . . . . . . . . . . . 5 4.2. Module Definition . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 13 A.1. SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. Multilayer Energy Management . . . . . . . . . . . . . . 14 A.3. SLA Negotiation for Green Services . . . . . . . . . . . 14 Appendix B. Requirements for Energy Efficiency Management . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Gallego Sanchez, et al. Expires 23 April 2026 [Page 2] Internet-Draft Energy-API Augmented October 2025 1. Introduction Sustainability is becoming one of the major societal goals for the next decade, and networks are one of the major consumers of energy nowadays. Sustainability of network services is thus one of the forefronts of innovation and action from network service stakeholders, involving manufacturers, operators and customers. In this line, there is a shared goal of achieving better energy awareness. As with any other network metric, the energy traffic ratio could be collected from the underlying network infrastructure. However, there is not a common or single definition of energy metrics towards network consumers so that they can be uniformly reported, particularly in heterogeneous network scenarios. This document introduces an API to query networks about Energy Traffic Ratio. Beyond simple efficiency indicators such as watts per gigabit, network stakeholders are increasingly interested in richer sustainability information, such as carbon intensity, energy, power usage effectiveness (PUE), idle energy draw, and transmission losses. These additional metrics allow more informed decision-making in contexts such as service routing, green SLA negotiations, and sustainability reporting. 2. Conventions and Definitions 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. 3. Path Energy Traffic Ratio API (PETRA) This document describes an API to query a network about the Energy Traffic Ratio for a given path. It takes as input the source and destination of a path along with the traffic throughput between and returns energy information related to the traffic on the path. This is energy computed by the infrastructure that is dynamically part of the traffic path. The API is agnostic to the actual hops and underlying infrastructure that enables a path, which might change transparently to the API. This document only describes the API, the computation of the energy information to return is out of the scope of this document. Gallego Sanchez, et al. Expires 23 April 2026 [Page 3] Internet-Draft Energy-API Augmented October 2025 The API can return a variety of energy-related parameters to provide a complete view of path sustainability. These include: base energy efficiency indicators, energy mix, renewable energy contributions, and standby or idle consumption. 3.1. Energy Information This API allows to return a number of energy attributes associated with the path and the traffic. Currently the parameters that could be returned as energy information as part of the query are: * *Watts per Gigabit:* How many Watts are consumed per Gigabit of traffic traversing the path. * *Carbon Intensity:* How much carbon emissions are generated as a consequence of the energy consumed. * *Energy Mix (%):* Percentage of energy used in the path that comes from different energy sources (e.g., solar, wind, biomass, nuclear, fossil fuel). * *Greenness Degree (%):* The aggregated percentage of energy consumed on the path that comes from renewable sources. Useful to rank and select paths based on renewable energy usage. * *Sustainability Score (0–1):* Composite metric combining greenness degree and energy efficiency (Watts per Gigabit), calculated as (Greenness/100) × 1/(1 + Watts per Gigabit). Higher values indicate more sustainable, efficient paths. * *Power Usage Effectiveness (PUE):* The ratio of total facility power consumption to the power consumption of networking/IT equipment. * *Transmission Loss (%):* The percentage of energy lost along the path due to transmission inefficiencies. * *Idle Energy Draw (Watts):* The amount of energy consumed by the path infrastructure when idle or under negligible load. These metrics are OPTIONAL, and an implementation MAY support a subset depending on available measurement capabilities. Gallego Sanchez, et al. Expires 23 April 2026 [Page 4] Internet-Draft Energy-API Augmented October 2025 3.2. Recursive Usage The API is envisioned in such a way that could be used recursively. That means, subpaths could report their energy consumption using PETRA and such energy consumption could be aggregated and reported for the overall path also using PETRA. Similarly, this API could be (recursively) used to provide energy information according to the definition of Service Models in an SDN context as described in [RFC8309]. In that case, using Figure 3 in [RFC8309] as reference, PETRA could be used between the Controller(s) and the Network Orchestrator(s), between the Network Orchestrator(s) and the Service Orchestrator, and between the Service Orchestrator and the Customer(s). While considering recursive usage, the aspect of double-counting shall also be taken into consideration. Double counting refers to the fact of counting more than once the same energy consumed. Organizations using PETRA in a recursive manner need to take appropriate measures to ensure no double-counting occurs across recursive calls to the API. 4. YANG Module This is a posible definition of PETRA as a module following the YANG specification [RFC6020]. 4.1. Module Structure Gallego Sanchez, et al. Expires 23 April 2026 [Page 5] Internet-Draft Energy-API Augmented October 2025 module: irtf-petra +--rw energy +---x query +---w input | +---w src-ip ietf-inet-types:ip-address | +---w dst-ip ietf-inet-types:ip-address | +---w throughput uint32 +--ro output +--ro (result)? +--:(success) | +--ro success | +--ro watts-per-gigabit? decimal64 | +--ro carbon-intensity? uint32 | +--ro energy-mix* -> list of sources and percentages | +--ro greenness-degree? decimal64 | +--ro sustainability-score? decimal64 | +--ro pue? decimal64 | +--ro transmission-loss? decimal64 | +--ro idle-watts? decimal64 +--:(invalid-address) +--ro invalid-address 4.2. Module Definition module irtf-petra { yang-version 1.1; namespace "urn:irtf:params:xml:ns:yang:irtf-petra"; prefix irtf-petra; import ietf-inet-types { prefix ietf-inet-types; } organization ""; contact ""; description "Initial YANG rendition of the PETRA Energy API, v1.0.1 Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents Gallego Sanchez, et al. Expires 23 April 2026 [Page 6] Internet-Draft Energy-API Augmented October 2025 (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. "; /* If you have an implementation of this YANG module, you could access it like something this over RESTCONF: $ curl --location --request POST \ 'https://localhost:8008/restconf/operations/energy/query' \ --header 'Content-Type: application/yang-data+json' \ --user 'admin:admin' \ --data-raw '{ 'input' : { 'src-ip': '10.10.10.10', 'dst-ip': '10.20.20.20', 'throughput': '40' } }' And if all goes well, you might receive (besides all the HTTP headers) a reply body with something like this: { 'output': { 'success': { 'watts-per-gigabit': '191.855', 'carbon-intensity': '108' } } } */ revision 2025-10-06 { description "Extended PETRA YANG module with richer input parameters and additional energy/sustainability metrics."; reference Gallego Sanchez, et al. Expires 23 April 2026 [Page 7] Internet-Draft Energy-API Augmented October 2025 "RFC XXXX: ..."; } // ===== Groupings ===== grouping query-parameters-g { description "Common input parameters for energy path queries."; leaf src { type inet:ip-address; mandatory true; description "Source IP address for the path."; } leaf dst { type inet:ip-address; mandatory true; description "Destination IP address for the path."; } leaf throughput { type decimal64 { fraction-digits 2; } units "Gbps"; description "Throughput of the traffic for which the path energy ratio is calculated."; } leaf measurement-interval { type uint32; units "seconds"; description "Optional measurement interval (duration) for the query. If omitted, defaults to instantaneous or most recent data."; } leaf recursive { type boolean; default "false"; description "Whether the query should be expanded recursively across multiple administrative domains (if supported)."; } } Gallego Sanchez, et al. Expires 23 April 2026 [Page 8] Internet-Draft Energy-API Augmented October 2025 grouping energy-metrics-g { description "Grouping for query result metrics."; leaf watts-per-gigabit { type decimal64 { fraction-digits 3; } units "W/Gb"; description "Watts consumed per Gigabit transmitted"; } leaf carbon-intensity { type uint32; units "gCO2e/kWh"; description "Grams of CO2 equivalent per kilowatt-hour consumed"; } list energy-mix { key "source"; description "Percentage contribution of each energy source to the total energy used on the path."; leaf source { type enumeration { enum solar; enum wind; enum hydro; enum nuclear; enum coal; enum gas; enum biomass; enum other; } description "Type of energy source."; } leaf percentage { type decimal64 { fraction-digits 2; } units "%"; description "Percentage of path energy from this source."; } } leaf greenness-degree { type decimal64 { fraction-digits 2; } units "%"; description "Aggregated percentage of energy from renewable sources."; } leaf sustainability-score { type decimal64 { fraction-digits 3; } description "Composite metric combining greenness degree and efficiency. Suggested formula: (Greenness/100) × 1/(1 + Watts per Gigabit)."; } Gallego Sanchez, et al. Expires 23 April 2026 [Page 9] Internet-Draft Energy-API Augmented October 2025 leaf pue { type decimal64 { fraction-digits 2; } description "Power Usage Effectiveness: ratio of total facility energy to IT/networking energy."; } leaf transmission-loss { type decimal64 { fraction-digits 2; } units "%"; description "Energy lost in transmission as percentage of total energy input."; } leaf idle-watts { type decimal64 { fraction-digits 3; } units W; description "Energy consumed by the path infrastructure when idle."; } } // ===== PETRA Container ===== container energy { description "PETRA API top-level container for energy queries."; action query { description "Query the network for energy consumption and sustainability metrics along a given path."; input { uses query-parameters-g; } output { choice result { description "Result of the PETRA query."; container success { description "Successful query returning energy metrics."; leaf timestamp { type yang:date-and-time; description "Time when the energy data was measured or aggregated."; } leaf aggregation-level { Gallego Sanchez, et al. Expires 23 April 2026 [Page 10] Internet-Draft Energy-API Augmented October 2025 type enumeration { enum path; enum subpath; enum site; enum facility; } description "Level of aggregation of reported data."; } container metrics { uses energy-metrics-g; description "Collection of energy and sustainability metrics."; } } container invalid-address { description "Invalid source or destination IP address supplied."; } container unsupported-metric { description "The requested metric is not supported by this implementation."; } container insufficient-data { description "The system could not collect sufficient data for the query."; } } } } } } 5. Security Considerations TBD 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References Gallego Sanchez, et al. Expires 23 April 2026 [Page 11] Internet-Draft Energy-API Augmented October 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . 7.2. Informative References [I-D.belmq-green-framework] Claise, B., Contreras, L. M., Lindblad, J., Palmero, M. P., Stephan, E., and Q. Wu, "Framework for Energy Gallego Sanchez, et al. Expires 23 April 2026 [Page 12] Internet-Draft Energy-API Augmented October 2025 Efficiency Management", Work in Progress, Internet-Draft, draft-belmq-green-framework-05, 6 October 2025, . Acknowledgments Kudos to Elis Lulja for his help with the OpenAPI specification in early versions of this draft. Thanks to Fernando Sanz Garcia and Lori Jakab for their help and support on this work. The contribution of Telefonica to this document has been supported by the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union's Horizon Europe research and innovation projects 6Green (Grant Agreement no. 101096925) and Exigence (Grant Agreement no. 101139120). Appendix A. Use Cases This section describes some use-cases where this specification might be useful. A.1. SD-WAN Software-Defined Wide-Area Networks (SD-WAN) have become a common way for enterprises to provide cost-effective connectivity across their different geographically distributed sites. Typically, SD-WAN deployments operate as an overlay network that is established on top of an existing underlay connectivity network. One aspect to consider is that in many SD-WAN production deployments the operator of the overlay network and the operator of the underlay network are different organizations. This poses an additional challenge when trying to derive sustainability metrics. Even if the underlay network is instrumented to collect energy data, this data is opaque to the operator of the overlay network which has no access to underlay information. While operators of underlay networks offer certain general network metrics to overlay operators, no interface has been defined to allow the overlay operator to query the underlay network for energy information. In this context, the PETRA specification presented in this document enables the operator of the SD-WAN network to coordinate with the underlay operator to capture sustainability data. This in turns opens further use-cases, from observability and reporting to potentially overlay policies based on underlay energy data, further enabling an overall more sustainable operation of the network. Gallego Sanchez, et al. Expires 23 April 2026 [Page 13] Internet-Draft Energy-API Augmented October 2025 In addition to energy considerations in SD-WAN deployments, PETRA can also be leveraged for broader energy-aware service routing. In this context, network controllers and service orchestrators—such as SD-WAN controllers, transport SDN controllers, 5G slice orchestrators, or multi-domain service orchestrators—can use PETRA metrics not only to balance latency, throughput, or load, but also to optimize path selection according to sustainability objectives. For example, paths with the lowest carbon intensity or the highest share of renewable energy in their energy mix could be preferred, enabling service differentiation where “green paths” are explicitly prioritized. This brings a paradigm where routing decisions are jointly driven by network performance and environmental impact. A.2. Multilayer Energy Management The concept of multilayer L3-L1 collection involves integrating data from different network layers to provide a comprehensive view of network operations. The use case of multilayer involves collecting and correlating data from Layer 3 (network layer) down to Layer 1 (physical layer). This multilayer approach allows for better network performance, optimization, and troubleshooting by providing end-to- end visibility. Leveraging PETRA API for multilayer L3-L1 collection use case enhances energy management by providing comprehensive visibility, enabling optimization, and supporting proactive management. This makes PETRA a useful tool for more accurate, efficient and effective energy management in modern networks. A.3. SLA Negotiation for Green Services Another use case for PETRA could be the negotiation of green Service Level Agreements (gSLAs) between operators and enterprise customers. By exposing PETRA-derived metrics such as renewable energy percentage, carbon intensity, or sustainability scores, providers can offer differentiated SLAs that explicitly include environmental targets. This enables customers to select network services not only based on performance guarantees, but also on their environmental footprint, for example requesting that at least 60% of traffic be carried over renewable-powered infrastructure. Such gSLAs empower customers to align their digital services with corporate sustainability goals and reporting requirements, while operators can use PETRA as the trusted source of verifiable energy data. Gallego Sanchez, et al. Expires 23 April 2026 [Page 14] Internet-Draft Energy-API Augmented October 2025 Appendix B. Requirements for Energy Efficiency Management The document Framework for Energy Efficiency Management [I-D.belmq-green-framework] describes a framework that comprises a controller element. In that document, the tasks of the controller are defined as "collection, compute and aggregate". In the context of that framework, the controller could also expose PETRA to offer path-related energy information. The figure below updates the one present in [I-D.belmq-green-framework] to add an additional interface (interface 'g') to the controller to represent the Path Traffic Ratio API. Gallego Sanchez, et al. Expires 23 April 2026 [Page 15] Internet-Draft Energy-API Augmented October 2025 +--------------------------------------------------------------------+ | | | (3) Network Domain Level | | | +--------------------------------------------------------------------+ (a) (b) (c) Inventory Monitor +- DataSheets/DataBase Of identity Energy | and/or via API and Capability Efficiency | Metadata and other ^ ^ | device/component/network | | | related information: (g) | | | PETRA | | | .Power/Energy related metrics API | | | .information ^ | | | .origin of Energy Mix | | | | .carbon aware based on location | | | | | | | v | +--------------------------------------------------------------------+ | | | | | (2) controller (collection, compute and aggregate?) +-+ | | +--------------------------------------------------------------------+ ^ ^ ^ | (d) | (e) | (f) | | Inventory | Monitor power | Control | | Capability | Proportion | (Energy saving | | | Energy efficiency| Functionality | | | ratio, power | Localized mgmt/ | | | consumption, | network wide mgmt) | | | etc) | | | | | | v +--------------------------------------------------------------------+ | | | (1) Device/Component | | | | +---------+ +-----------+ +----------------+ +----------------+ | | | (I) | | (II) | | (III) | | (IV) | | | | | | | | Legacy | | 'Attached'(PoE | | | | Device | | Component | | Device | | end Point) | | | | | | | | | | | | | +---------+ +-----------+ +----------------+ +----------------+ | +--------------------------------------------------------------------+ Figure 1: PETRA Integration in Energy Management Framework Gallego Sanchez, et al. Expires 23 April 2026 [Page 16] Internet-Draft Energy-API Augmented October 2025 Authors' Addresses Adrian Gallego Sanchez T-Systems Guadalajara Spain Email: ADRIAN.GALLEGO-SANCHEZ@t-systems.com Alberto Rodriguez-Natal Cisco Madrid Spain Email: natal@cisco.com Luis M. Contreras Telefonica Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com Marisol Palmero Toledo Spain Email: marisol.ietf@gmail.com Jan Lindblad All For Eco Email: jan.lindblad+ietf@for.eco Gallego Sanchez, et al. Expires 23 April 2026 [Page 17]