]> T-Systems

Guadalajara Spain ADRIAN.GALLEGO-SANCHEZ@t-systems.com

Cisco

Madrid Spain natal@cisco.com

Telefonica

Madrid Spain luismiguel.contrerasmurillo@telefonica.com

Toledo Spain marisol.ietf@gmail.com

All For Eco

jan.lindblad+ietf@for.eco

IRTF Proposed Sustainability and the Internet Proposed Research Group energy network sustainability API 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Proposed Sustainability and the Internet Proposed Research Group Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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.

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 when, and only when, they appear in all capitals, as shown here.

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. 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. Furthermore, the PETRA's energy parameters complement ongoing work on green service intents [I-D.irtf-nmrg-ibn-usecases], enabling customers to express sustainability objectives such as energy consumption thresholds, renewable energy usage, and carbon intensity limits. PETRA provides the underlying energy measurement interface necessary for providers to fulfill, assure, and report on these green intents. Moreover, by exposing detailed energy and carbon-related parameters, PETRA can allow intent translation components to map green service objectives into network resource allocation and path selection decisions.

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.

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 . In that case, using Figure 3 in 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. | Customer | Customer Service | Orchestrator | (a) | | related API | | ---------- ------------------ . . ########################## . . (b) ----------- . (b) . ......|Application| . . : | BSS/OSS | PETRA as . . : ----------- Service related API . Service Delivery . : . Model . : ------------------ ------------------ | | | | ############# | Network | | Network | | Orchestrator | | Orchestrator | | | | | .------------------ ------------------. PETRA as . : : . Network API . : Network Configuration : . . : Model : . ------------ ------------ ------------ ------------ | | | | | | | | ### | Controller | | Controller | | Controller | | Controller | | | | | | | | | ------------ ------------ ------------ ------------ : . . : : : . . Device : : : . . Configuration : : : . . Model : : --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- ]]>

YANG Module This is a posible definition of PETRA as a module following the YANG specification .

Module Structure 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 ]]>

Module Definition

Security Considerations In order to mitigate security risks, the PETRA API should implement the necessary mechanisms for authentication, secure data transfer and privacy preservation. On the other hand, in order to prevent denial of service attacks, new subsequent similar requests could be silently ignored during periods or time, or even requests from the same client could be filtered to prevent system (i.e., controller or orchestrator) affection.

IANA Considerations This document has no IANA actions.

References Normative References 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. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] 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 a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. 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. Informative References Everything OPS Telefonica All For Eco Independent Orange Huawei Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network’s functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices.

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 A. Gallego Sánchez to this document has been partially supported by the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union's Horizon Europe research and innovation project Sustain6G (Grant Agreement no. 101191936). The contribution of L.M. Contreras to this document has been partially 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. 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. gSLAs can be negotiated using customer-expressed green intents that specify objectives such as maximum energy consumption, minimum energy efficiency, carbon emission limits, and renewable energy usage [I-D.irtf-nmrg-ibn-usecases]. PETRA's metrics, including watts per gigabit, carbon intensity, and energy mix, provide essential measurements to translate these intents into network configurations and to monitor compliance during service operation. The lifecycle of green intents, encompassing fulfillment and assurance phases [RFC9315], can be supported by PETRA through its capability to deliver real-time energy metrics for translation into network policies and subsequent monitoring and validation.

Appendix B. Requirements for Energy Efficiency Management The document Framework for Energy Efficiency Management 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 to add an additional interface (interface 'g') to the controller to represent the Path Traffic Ratio API.

PETRA Integration in Energy Management Framework