]> Deutsche Telekom

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 sustainability-related metrics 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 and carbon 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 and sustainability 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 the 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 mix, idle energy draw, transmission losses, and cooling overheads (e.g., Cooling Energy Ratio). In addition, operational and temporal aspects matter: the ability of a path to spend time in low-power states (Sleep-mode Availability), the variability of carbon intensity over time (Temporal Carbon Variability), and the stability of reported sustainability behavior (e.g., Sustainability Stability Index). Finally, sustainability data is increasingly used for automated decision-making and assurance (e.g., in green SLAs), which introduces a need for indicators of data quality and robustness. Metrics such as variance of energy consumption (VEC), anomaly detection signals (e.g., Anomaly Factor), and a trustworthiness score of data sources (TDS) help distinguish persistent characteristics from transient conditions and support more reliable sustainability reporting and policy enforcement.

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.

Sustainability holistic API for Path Energy Evaluation (SHAPE) This document describes an API to query a network about several sustainability-related metrics for a given path. SHAPE extends PETRA as defined in with additional sustainability metrics. It reuses PETRA endpoint identifiers for source and destination (e.g., IP address, IP prefix, MAC address, or slice SDP identifier) and PETRA traffic characterization (i.e., throughput, or time-window plus transmitted data volume), and returns sustainability 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 PETRA baseline efficiency indicators (e.g., Watts per Gigabit) and SHAPE-specific sustainability extensions (e.g., carbon intensity, energy mix, transmission losses, idle energy draw, cooling overheads, and the availability of low-power states such as sleep modes). For authoritative sustainability comparison and optimization, carbon-intensity and temporal variability indicators are the primary actionable metrics. In addition to point-in-time values, the API can expose temporal and assurance-oriented information, such as the variability of carbon intensity over a defined observation window, stability indices for sustainability behavior (e.g., Sustainability Stability Index), statistical measures of energy variability, anomaly signals, and indicators of confidence in the underlying data sources. Such metrics can help consumers distinguish persistent characteristics from transient fluctuations. Furthermore, the SHAPE's energy parameters complement ongoing work on green service intents , enabling customers to express sustainability objectives such as energy consumption thresholds, renewable energy usage, and carbon intensity limits. SHAPE 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, SHAPE 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. PETRA defines the base query and baseline energy metric (Watts per Gigabit); SHAPE augments PETRA with additional sustainability metrics emphasizing carbon impact and operational variability. Currently the parameters that could be returned as energy information as part of the query are:

• Watts per Gigabit: (Inherited from PETRA) How many Watts are consumed per Gigabit of traffic traversing the path.
• Carbon Intensity: How much carbon emissions (e.g., gCO2e/kWh) are generated as a consequence of the energy consumed. This is the primary actionable metric for sustainability-aware routing and policy enforcement.
• Energy Mix (%): Percentage of energy used in the path that comes from different energy sources (e.g., solar, wind, biomass, nuclear, fossil fuel). Comparability of renewable percentages across paths may be limited by measurement scope, time window, and accounting/certification boundaries.
• Greenness Degree (%): The aggregated percentage of energy consumed on the path that comes from renewable sources. This metric can support policy-driven reporting, but by itself does not fully characterize carbon impact across operators or countries.
• Sustainability Score (0–1): (Informative) Composite metric combining greenness degree and energy efficiency. This can be used as an implementation-specific ranking aid, but carbon-intensity and temporal variability metrics are recommended for authoritative sustainability assessment.
• 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.
• Temporal Carbon Variability (TCV) (gCO2/kWh over period): Quantifies how much the carbon intensity of the electricity powering the network path fluctuates over a defined time window (e.g., 15 minutes, 1 hour, 24 hours). It reflects the stability or volatility of the renewable/fossil mix affecting the path during that period. A low TCV indicates predictable carbon characteristics; a high TCV suggests inconsistent or rapidly changing energy sources.
• Sleep-mode Availability (%): Measures the percentage of time during which network devices or segments along a path support and can enter low‑power or idle energy‑saving modes. It can also reflect real usage of these modes depending on the operator’s instrumentation (when supported or/and instrumented).
• Sustainability Stability Index (SSI) (0–1): Quantifies the stability over time of a sustainability metric (i.e., carbon intensity or greenness degree), it is particularly relevant for gSLAs, where predictable sustainability performance matters as much as absolute values. Values close to 1 indicate highly stable behavior.
• Trustworthiness Score of Data Sources (TDS) (0–1): characterizes how reliable the API’s sustainability‑related data is, based on provenance, measurement quality, freshness, and cross‑source consistency. Higher values indicate stronger confidence in the reported data.
• Variance of Energy Consumption (VEC) (W^2): VEC measures how much the energy use of the path fluctuates during an observation window. It helps detect energy instability, noisy equipment, or poorly tuned power‑management algorithms. High VEC indicates unstable or erratic energy usage; low VEC indicates consistent energy behavior.
• Anomaly Factor (AF) (z-factor): Identifies whether the energy usage of a path at a given moment deviates significantly from its historical baseline or expected statistical behavior, normalized by standard deviation. AF < 1 indicates normal behavior, AF around 2 indicates elevated deviation, and AF > 3 indicates an anomaly (classic 3-sigma rule).
• Cooling Energy Ratio (CER) (%): Quantifies the share of total energy consumed by a path or segment that is attributable to cooling rather than networking/IT workload. It is a path- or segment-level metric rather than a facility-wide efficiency metric. Higher values indicate higher cooling overhead relative to useful forwarding energy.

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 SHAPE and such energy consumption could be aggregated and reported for the overall path also using SHAPE. 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, SHAPE 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 SHAPE 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 | SHAPE as . . : ----------- Service related API . Service Delivery . : . Model . : ------------------ ------------------ | | | | ############# | Network | | Network | | Orchestrator | | Orchestrator | | | | | .------------------ ------------------. SHAPE 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 SHAPE is specified as an augmentation to the PETRA YANG module defined in . This section provides an example YANG module, as per the YANG specification , that imports PETRA and augments it with additional inputs and metrics. SHAPE reuses PETRA input and output structures. In particular, source and destination are modeled using PETRA endpoint identifier choices, traffic is characterized using PETRA traffic alternatives, and SHAPE adds optional sustainability metrics on top of PETRA successful query output.

Module Structure list of sources and percentages +--ro greenness-degree? decimal64 +--ro sustainability-score? decimal64 +--ro transmission-loss? decimal64 +--ro idle-watts? decimal64 +--ro temporal-carbon-variability? decimal64 +--ro sleep-mode-availability? decimal64 +--ro sustainability-stability-index? decimal64 +--ro trustworthiness-score? decimal64 +--ro variance-energy-consumption? decimal64 +--ro anomaly-factor? decimal64 +--ro cooling-energy-ratio? decimal64 ]]>

Module Definition RG List: "; description "Initial YANG module for SHAPE API, v1.0.0 SHAPE extends the PETRA YANG module ('draft-petra-green-api') with additional optional sustainability-related metrics and, where needed, additional input parameters to qualify observation windows. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; /* 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/ietf-shape:energy/query' \ --header 'Content-Type: application/yang-data+json' \ --user 'admin:admin' \ --data-raw '{ "input" : { "source": { "ip-prefix": "10.10.10.0/24" }, "destination": { "ip-prefix": "10.20.20.0/24" }, "throughput": 40, "measurement-interval": 900, "recursive": false } }' 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, "shape-metrics": { "carbon-intensity": 108, "energy-mix": [ { "source": "solar", "percentage": 35.00 }, { "source": "wind", "percentage": 25.00 }, { "source": "gas", "percentage": 40.00 } ], "greenness-degree": 60.00, "sustainability-score": 0.312, "transmission-loss": 3.50, "idle-watts": 12.500, "temporal-carbon-variability": 14.250, "sleep-mode-availability": 20.00, "sustainability-stability-index": 0.880, "trustworthiness-score": 0.950, "variance-energy-consumption": 1.750, "anomaly-factor": 0.420, "cooling-energy-ratio": 15.00 } } } } */ revision 2026-02-26 { description "Initial SHAPE augmentation of PETRA, adding additional sustainability metrics (including temporal/stability and trustworthiness indicators)."; reference "RFC XXXX: ..."; } // ===== Groupings ===== grouping shape-metrics { description "Additional sustainability metrics defined by SHAPE that extend the base PETRA query output."; leaf carbon-intensity { type uint32 { range "0..max"; } units "gCO2e/kWh"; description "Carbon intensity of the electricity powering the path."; } 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 { description "Energy sourced from solar generation."; } enum wind { description "Energy sourced from wind generation."; } enum hydro { description "Energy sourced from hydroelectric generation."; } enum nuclear { description "Energy sourced from nuclear generation."; } enum coal { description "Energy sourced from coal-based generation."; } enum gas { description "Energy sourced from gas-based generation."; } enum biomass { description "Energy sourced from biomass generation."; } enum other { description "Energy sourced from other or unspecified generation."; } } description "Type of energy source."; } leaf percentage { type decimal64 { fraction-digits 2; range "0..100"; } units "%"; description "Percentage of path energy from this source."; } } leaf greenness-degree { type decimal64 { fraction-digits 2; range "0..100"; } units "%"; description "Aggregated percentage of energy from renewable sources. This metric is not always directly comparable across domains and accounting boundaries; carbon-intensity is the primary cross-domain sustainability metric."; } leaf sustainability-score { type decimal64 { fraction-digits 3; range "0..1"; } description "Informative composite metric combining greenness degree and energy efficiency for implementation-specific ranking. Carbon-intensity and temporal variability metrics are RECOMMENDED for authoritative sustainability assessment."; } leaf transmission-loss { type decimal64 { fraction-digits 2; range "0..100"; } units "%"; description "Energy lost in transmission as percentage of total energy input."; } leaf idle-watts { type decimal64 { fraction-digits 3; range "0..max"; } units "W"; description "Energy consumed by the path infrastructure when idle."; } leaf temporal-carbon-variability { type decimal64 { fraction-digits 3; range "0..max"; } units "gCO2e/kWh"; description "Quantifies how much the carbon intensity powering the path fluctuates over an observation window (e.g., 15 minutes, 1 hour, 24 hours)."; } leaf sleep-mode-availability { type decimal64 { fraction-digits 2; range "0..100"; } units "%"; description "Percentage of time during which devices or segments on the path can enter low-power or idle energy-saving modes (when supported and instrumented)."; } leaf sustainability-stability-index { type decimal64 { fraction-digits 3; range "0..1"; } description "Index (0..1) capturing the stability over time of a sustainability metric (e.g., carbon intensity or greenness degree)."; } leaf trustworthiness-score { type decimal64 { fraction-digits 3; range "0..1"; } description "Composite score (0..1) reflecting reliability of reported sustainability data, e.g., based on provenance, quality, freshness, and cross-source consistency."; } leaf variance-energy-consumption { type decimal64 { fraction-digits 3; range "0..max"; } units "W^2"; description "Variance of energy consumption over an observation window."; } leaf anomaly-factor { type decimal64 { fraction-digits 3; } units "z-score"; description "Deviation of current energy consumption from a historical mean, normalized by standard deviation (z-factor)."; } leaf cooling-energy-ratio { type decimal64 { fraction-digits 2; range "0..100"; } units "%"; description "Ratio between cooling energy and IT/network energy for a path or segment."; } } // ===== Augmentations ===== augment "/petra:energy/petra:query/petra:input" { description "Additional optional input parameters for SHAPE that qualify the observation window and, when supported, recursive collection."; leaf measurement-interval { type uint32 { range "1..max"; } units "seconds"; description "Observation window used to compute time-dependent metrics (e.g., variability, stability, variance, and anomaly indicators)."; } leaf recursive { type boolean; default "false"; description "Whether the query should be expanded recursively across multiple administrative domains (if supported)."; } } augment "/petra:energy/petra:query/petra:output/petra:result/petra:success" { description "Add SHAPE sustainability metrics to the successful PETRA query result."; container shape-metrics { description "Collection of additional sustainability metrics defined by SHAPE."; uses shape-metrics; } } } ]]>

Operational Considerations This section highlights deployment and operation aspects for SHAPE, following the operational guidance commonly applied to network management specifications and the guidance in .

• Measurement method impacts: SHAPE results can vary depending on how measurements are obtained (e.g., direct telemetry, estimates, model-based aggregation, or historical averaging). Operators SHOULD document which methods are used for each metric and SHOULD expose measurement confidence where possible.
• Traffic characterization impacts: Query results can differ when traffic is characterized by throughput versus time-window plus transmitted volume. Implementations SHOULD document supported PETRA traffic-characterization modes and SHOULD avoid mixing incomparable measurement bases in trend analysis.
• Comparability caveat for renewable percentages: Renewable-percentage indicators (e.g., greenness-degree) can be influenced by measurement boundaries, time windows, and accounting instruments. Implementations SHOULD avoid using a single aggregated renewable percentage as the sole basis for cross-domain optimization.
• Consumer intent differences: Operational use cases may have different requirements. Customer-facing use cases (e.g., SD-WAN sustainability visibility) generally require stability, repeatability, and clear policy constraints, while operator optimization use cases may prioritize freshness and responsiveness over strict comparability.
• Recursive aggregation and double counting: Recursive operation across domains introduces a risk of counting the same energy contribution multiple times. Implementations SHOULD define clear aggregation boundaries (e.g., segment ownership, handoff points, or unique contribution identifiers) and SHOULD provide auditability for aggregation logic.
• Subset support and policy controls: SHAPE metrics are optional and may be supported only partially. Implementations SHOULD make unsupported metrics explicit in operational documentation and SHOULD align metric exposure with authorization and disclosure policies.

Security Considerations The YANG module defined in this document augments PETRA query input and output nodes under /petra:energy/petra:query. SHAPE queries and responses can reveal operational and business-sensitive information (e.g., energy efficiency, carbon footprint, facility overheads, and potentially location- or time-correlated behavior). SHAPE API MAY be exposed via management protocols such as NETCONF and RESTCONF and, therefore, it inherits their security properties and deployment practices. The SHAPE input leaves measurement-interval and recursive are configuration inputs to an action invocation. Unauthorized manipulation of these inputs can increase computation cost and disclosure scope. The SHAPE output container shape-metrics exposes additional sustainability data and can reveal sensitive operational characteristics. Implementations MUST consider the following aspects:

• Secure transport: Implementations MUST ensure confidentiality and integrity protection for SHAPE exchanges (i.e., by using secure transports mandated by the underlying management protocol). Where RESTCONF is used, HTTPS is REQUIRED by .
• Authentication and authorization: SHAPE servers MUST authenticate clients and MUST enforce authorization on a per-request basis. Authorization SHOULD be granular (e.g., via access-control mechanisms such as NACM ) and cover: (i) which path endpoints can be queried, (ii) which PETRA and SHAPE metrics can be returned, and (iii) which precision/granularity is permitted.
• Information disclosure controls: Returned sustainability data (i.e., energy mix, cooling-energy ratio, or temporal variability) can be used to infer facility characteristics, topology, utilization patterns, or operational policies. Servers SHOULD support policy controls that reduce disclosure risk (e.g., aggregation, reduced precision, or suppressing specific metrics) for less-privileged clients.
• Input validation and bounds: Servers MUST validate all inputs (i.e., including PETRA endpoint identifiers, PETRA traffic characterization inputs such as throughput or time-window with transmitted volume, measurement-interval, and the recursive flag) and enforce reasonable bounds to prevent expensive computations and state growth. In particular, servers SHOULD enforce upper limits on observation-window durations, recursion depth/scope, and the amount of per-request data returned.
• Denial-of-service resilience: SHAPE computations may involve multi-device sampling, aggregation, and historical lookups. Servers SHOULD implement DoS mitigations such as rate limiting, per-client quotas, request prioritization, and caching of commonly requested results. If requests are rejected due to overload or policy, servers SHOULD return explicit errors rather than silently ignoring requests.
• Multi-domain and recursive operation: When the query is expanded recursively across administrative domains, each domain MUST enforce its own local policy and MUST NOT assume that upstream requests are safe. Implementations SHOULD ensure that recursive expansion does not leak credentials, does not bypass local authorization, and does not create amplification (e.g., fan-out storms). Responses obtained from external domains SHOULD be treated as untrusted inputs.
• Integrity of measurement chain: SHAPE metrics can be used for automated decisions (e.g., policy enforcement or gSLAs). Implementations SHOULD protect the integrity of the measurement pipeline (collection, aggregation, and publication) and SHOULD provide operational mechanisms such as audit logs and provenance tracking to help detect tampering or misconfiguration.
• Privacy: Sustainability metrics may correlate with customer traffic patterns or reveal information about customer locations and activity. Implementations SHOULD minimize retention of per-customer/per-flow data and SHOULD protect logs and telemetry derived from SHAPE requests.

IANA Considerations IANA is requested to register the following YANG module in the "YANG Module Names" registry . Name: ietf-shape Namespace: urn:ietf:params:xml:ns:yang:ietf-shape Prefix: shape Reference: RFC XXXX Maintained by IANA? N

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 data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). 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 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. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. 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 networks, 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 defines mechanisms for representing and organizing timestamped telemetry data using YANG data models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. Cisco Telefonica Independent Consultant All For Eco T-SYSTEMS This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. Everything OPS Huawei Individual All For Eco This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks. China Mobile China Mobile Department of Computer Science and Engineering Huawei Xidian University Telefonica Huawei This document proposes several use cases of Intent-Based Networking (IBN) and a methodology to differ each use case by following the lifecycle of a real IBN system. It includes data collection for system awareness in the IBN system and the construction of the IBN system. This construction consists of intent translation, policy translation, policy verification, policy deployment, policy monitoring, policy validation, policy optimization, and intent report. Practice learnings are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. Finally, this document discusses three aspects for the deployment of IBN systems on the real world. They are Multi-Domain Dichotomy for IBN, the Integration of IBN and Network Digital Twin, and IBN with Artificial Intelligence (AI). Everything OPS Cisco Old Dog Consulting Nokia Blue Fern Consulting ZTE New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.

Acknowledgments 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 SHAPE 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, SHAPE 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 SHAPE metrics not only to balance latency, throughput, or load, but also to optimize path selection according to sustainability objectives. Carbon-intensity and temporal-carbon-variability metrics are the primary optimization levers for low-emission routing. Energy mix and renewable percentages can complement decisions where policy requires specific sourcing criteria, but should not be used as standalone sustainability indicators. This brings a paradigm where routing decisions are jointly driven by network performance and carbon 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 SHAPE API for multilayer L3-L1 collection use case enhances energy management by providing comprehensive visibility, enabling optimization, and supporting proactive management. This makes SHAPE 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 SHAPE could be the negotiation of green Service Level Agreements (gSLAs) between operators and enterprise customers. By exposing SHAPE-derived metrics such as carbon intensity, energy efficiency, and temporal variability, 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 actual carbon impact. Renewable-percentage and energy-mix metrics MAY support policy-driven sourcing requirements, but carbon-intensity remains the primary metric for carbon accounting and SLA compliance. Such gSLAs empower customers to align their digital services with verifiable sustainability goals, while operators can use SHAPE as the trusted source of energy and carbon 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 constraints . SHAPE's metrics, including Watts per Gigabit, carbon intensity, temporal carbon variability, 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 , can be supported by SHAPE through its capability to deliver real-time energy metrics for translation into network policies and subsequent monitoring and validation.

A.4. Energy-Aware UPF and Edge Selection in 5G Mobile Network Operators (MNOs) often have choices regarding the placement of user-plane functions (UPFs), traffic break-out points, and Multi-access Edge Computing (MEC) sites. These choices influence not only latency and capacity, but also the energy and carbon footprint of the end-to-end user-plane path (e.g., from a radio site or aggregation point towards a selected UPF/MEC and onwards to a data network). In this context, SHAPE can be used by the 5G slice orchestrator, policy controller, or transport controller to query candidate paths associated with alternative UPF/MEC selections and compare sustainability metrics (e.g., watts-per-gigabit, carbon intensity, energy mix, and temporal carbon variability over a defined observation window). This enables energy-aware traffic steering, selection of greener break-out points when service constraints allow it, and assurance of sustainability objectives for enterprise slices.

A.5. Sustainability Reporting Across Leased Backhaul and Network Sharing MNOs frequently rely on third-party transport (e.g., leased lines or wholesale backhaul) and may participate in network sharing arrangements where different administrative domains contribute to the effective end-to-end service path. This makes it difficult to obtain consistent and comparable sustainability metrics for internal carbon accounting, regulatory reporting, or customer-facing sustainability statements. SHAPE's recursive usage model can support these scenarios by allowing an MNO to obtain per-segment sustainability metrics from each contributing domain (subject to authorization and policy) and then aggregate them for an overall view of the service path. When combined with appropriate safeguards against double counting (Section "Recursive Usage"), this enables a more robust, auditable decomposition of energy and carbon contributions across shared or outsourced infrastructure.

Appendix B. Requirements for Energy Efficiency Management The document Framework for Energy Efficiency Management describes a framework where an Energy Management System (EnMS) coordinates inventory, monitoring, and control functions through a controller element. In that context, SHAPE can be exposed via the API Service Interface (interface 'g') to provide path-related energy and sustainability information to external consumers.