Path Energy Traffic Ratio API (PETRA)
draft-petra-green-api-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Alberto Rodriguez-Natal , Luis M. Contreras , Marisol Palmero , Jan Lindblad , Adrián Gallego Sánchez | ||
| Last updated | 2026-10-31 | ||
| Replaces | draft-petra-path-energy-api | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-petra-green-api-05
GREEN A. Rodriguez-Natal
Internet-Draft Cisco
Intended status: Informational L. M. Contreras
Expires: 4 May 2027 Telefonica
M. Palmero
Independent Consultant
J. Lindblad
All For Eco
A. Gallego Sanchez
T-SYSTEMS
31 October 2026
Path Energy Traffic Ratio API (PETRA)
draft-petra-green-api-05
Abstract
This document describes an API to query a network regarding its
Energy Traffic Ratio for a given path.
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/.
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 May 2027.
Copyright Notice
Copyright (c) 2026 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
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 1]
Internet-Draft Energy-API October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Requirements Notation . . . . . . . . . . . . 3
3. Path Energy Traffic Ratio API (PETRA) . . . . . . . . . . . . 3
3.1. Energy Information . . . . . . . . . . . . . . . . . . . 3
3.2. Recursive Usage . . . . . . . . . . . . . . . . . . . . . 3
4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Module Structure . . . . . . . . . . . . . . . . . . . . 5
4.2. Module Definition . . . . . . . . . . . . . . . . . . . . 6
5. Operational Considerations . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 17
A.1. SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Multilayer Energy Management . . . . . . . . . . . . . . 18
A.3. SLA Negotiation for Energy-Efficient Services . . . . . . 18
Appendix B. Requirements for Energy Efficiency Management . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Energy management is becoming one of the major societal goals for the
next decade, and networks are one of the major consumers of energy
nowadays. Energy management 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 can be uniformly reported, particularly in
heterogeneous network scenarios. This document introduces an API to
query networks about Energy Traffic Ratio.
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 2]
Internet-Draft Energy-API October 2026
2. Terminology and Requirements Notation
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 documents 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
underlaying 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. In the current version of this document, source
and destination endpoints can be IP addresses, IP prefixes, or MAC
addresses.
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.
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 (below), 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).
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 3]
Internet-Draft Energy-API October 2026
Customer
------------------ Service ----------
| | Model | |
PETRA as | Service |<-------->| 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 |
--------- --------- --------- --------- ---------
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.
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 4]
Internet-Draft Energy-API October 2026
4. YANG Module
This is a posible definition of PETRA as a module following the YANG
specification [RFC7950]. The module uses the common YANG data types
defined in [RFC9911], and imports the network slice model from
[I-D.ietf-teas-ietf-network-slice-nbi-yang] and the power and energy
model from [I-D.bcmj-green-power-and-energy-yang].
4.1. Module Structure
This section uses the graphical representation of data models defined
in [RFC8340].
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 5]
Internet-Draft Energy-API October 2026
module: ietf-petra
+--rw energy
+---x query
+---w input
| +---w source
| | +---w (identifier)
| | +--:(ip-address)
| | | +---w ip-address ietf-inet-types:ip-address
| | +--:(ip-prefix)
| | | +---w ip-prefix ietf-inet-types:ip-prefix
| | +--:(mac-address)
| | | +---w mac-address ietf-yang-types:mac-address
| | +--:(sdp-id)
| | +---w sdp-id -> /ietf-nss:network-slice-services/slice-service/sdps/sdp/id
| +---w destination
| | +---w (identifier)
| | +--:(ip-address)
| | | +---w ip-address ietf-inet-types:ip-address
| | +--:(ip-prefix)
| | | +---w ip-prefix ietf-inet-types:ip-prefix
| | +--:(mac-address)
| | | +---w mac-address ietf-yang-types:mac-address
| | +--:(sdp-id)
| | +---w sdp-id -> /ietf-nss:network-slice-services/slice-service/sdps/sdp/id
| +---w (traffic-characterization)?
| +--:(throughput)
| | +---w throughput? decimal64
| +--:(time-window-and-data-transmitted)
| +---w time-window
| | +---w start-time ietf-yang-types:date-and-time
| | +---w end-time ietf-yang-types:date-and-time
| +---w data-transmitted decimal64
+--ro output
+--ro (result)?
+--:(success)
| +--ro success
| +--ro watts-per-gigabit? decimal64
| +--ro data-source-accuracy? identityref
+--:(invalid-endpoint)
+--ro invalid-endpoint!
4.2. Module Definition
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 6]
Internet-Draft Energy-API October 2026
<CODE BEGINS> file "ietf-petra@2026-07-06.yang"
module ietf-petra {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-petra";
prefix petra;
import ietf-inet-types {
prefix ietf-inet-types;
reference "RFC 9911: Common YANG Data Types";
}
import ietf-yang-types {
prefix ietf-yang-types;
reference "RFC 9911: Common YANG Data Types";
}
import ietf-network-slice-service {
prefix ietf-nss;
revision-date 2026-05-27;
reference
"draft-ietf-teas-ietf-network-slice-nbi-yang-26:
A YANG Data Model for the RFC 9543 Network Slice Service.";
}
import ietf-power-and-energy {
prefix eo;
reference
"draft-bcmj-green-power-and-energy-yang:
Power and Energy YANG Module.";
}
organization
"IETF GREEN Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/green/>
WG List: <mailto:green@ietf.org>";
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
(https://trustee.ietf.org/license-info).
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 7]
Internet-Draft Energy-API October 2026
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-petra: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'
}
}'
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'
}
}
}
*/
revision 2026-07-06 {
description
"Initial YANG rendition of the PETRA Energy API, v1.0.1";
reference
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 8]
Internet-Draft Energy-API October 2026
"RFC XXXX: ...";
}
grouping endpoint {
description
"Identifies one endpoint of an energy-measurement path.";
choice identifier {
mandatory true;
description
"Endpoint represented as an IP address, IP prefix, MAC address,
or Service Demarcation Point (SDP) identifier.";
case ip-address {
leaf ip-address {
type ietf-inet-types:ip-address;
mandatory true;
description
"IPv4 or IPv6 address.";
}
}
case ip-prefix {
leaf ip-prefix {
type ietf-inet-types:ip-prefix;
mandatory true;
description
"IPv4 or IPv6 network prefix.";
}
}
case mac-address {
leaf mac-address {
type ietf-yang-types:mac-address;
mandatory true;
description
"IEEE 802 MAC address.";
}
}
case sdp-id {
leaf sdp-id {
type leafref {
path "/ietf-nss:network-slice-services"
+ "/ietf-nss:slice-service"
+ "/ietf-nss:sdps"
+ "/ietf-nss:sdp"
+ "/ietf-nss:id";
require-instance true;
}
mandatory true;
description
"Reference to a Service Demarcation Point (SDP) within the
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 9]
Internet-Draft Energy-API October 2026
scope of a Network Slice Controller (NSC).";
}
}
}
}
grouping energy-metrics {
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 data-source-accuracy {
type identityref { base eo:data-source-accuracy; }
description
"Accuracy classification of the watts-per-gigabit value,
using the GREEN data-source-accuracy hierarchy.
Implementations SHOULD populate this leaf to enable
consumers to assess reliability. For path-aggregated
values derived from multiple components, the RECOMMENDED
value is the LEAST accurate accuracy class among all
contributing energy objects.";
}
}
container energy {
description
"PETRA API top level container.";
action query {
description
"Query the network for energy consumption";
input {
must "throughput or (time-window/start-time and
time-window/end-time and data-transmitted)" {
error-message
"Provide either throughput or a time window with start
and end times together with data-transmitted.";
}
container source {
description
"Source endpoint.";
uses endpoint;
}
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 10]
Internet-Draft Energy-API October 2026
container destination {
description
"Destination endpoint.";
uses endpoint;
}
choice traffic-characterization {
default throughput;
description
"Characterizes the traffic either by its throughput or by
the amount of data transmitted during a time window.";
case throughput {
leaf throughput {
type decimal64 {
fraction-digits 3;
}
units Gb/s;
description
"Throughput between source and destination
(in gigabits per second).";
}
}
case time-window-and-data-transmitted {
container time-window {
description
"Interval during which the data was transmitted.";
leaf start-time {
type ietf-yang-types:date-and-time;
mandatory true;
description
"Start date and time of the interval.";
}
leaf end-time {
type ietf-yang-types:date-and-time;
mandatory true;
description
"End date and time of the interval.";
}
}
leaf data-transmitted {
type decimal64 {
fraction-digits 3;
}
units Gb;
mandatory true;
description
"Amount of data transmitted between source and
destination during the time window (in gigabits).";
}
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 11]
Internet-Draft Energy-API October 2026
}
}
}
output {
choice result {
description
"Choice of which kind of result the query gave.";
container success {
description
"Successful operation";
uses energy-metrics;
}
container invalid-endpoint {
presence
"Indicates that an invalid endpoint was supplied.";
description
"Invalid source or destination endpoint supplied.";
}
}
}
}
}
}
<CODE ENDS>
5. Operational Considerations
This section highlights deployment and operations considerations for
PETRA, following the guidance in [I-D.ietf-opsawg-rfc5706bis].
* Measurement method impact: PETRA results can differ depending on
whether values are directly measured, estimated, or model-derived.
Operators SHOULD document the methodology used for each exposed
metric.
* Provenance: PETRA does not require provenance support.
Deployments that require provenance assurance for the Energy
Object telemetry used to derive a PETRA result can use the per-
Energy-Object verification state defined in
[I-D.madpr-green-provenance].
* Consumer intent differences: customer-facing use cases (for
example, SD-WAN visibility and SLA reporting) prioritize
repeatability and explainability, while operator optimization use
cases may prioritize freshness and control-loop responsiveness.
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 12]
Internet-Draft Energy-API October 2026
* Recursive aggregation and double counting: recursive or multi-
domain use of PETRA can count the same contribution more than
once. Implementations SHOULD define aggregation boundaries and
controls that avoid double counting across segments and
administrative domains.
6. Security Considerations
The YANG module defined in this document is specified and reviewed
following the guidance in [RFC9907]. PETRA query exchanges can
reveal operationally sensitive information related to endpoints,
traffic, and energy behavior, and therefore require careful
deployment controls.
When this API is exposed over NETCONF [RFC6241] or RESTCONF
[RFC8040], implementations inherit those protocols' security
properties and deployment requirements.
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available protocol
operations and content.
The module defines no particularly sensitive readable or writable
datastore nodes. The "energy" container serves only as the parent of
the "energy/query" action.
Implementations and deployments SHOULD consider at least the
following:
* Secure transport: mutual authentication, confidentiality, and
integrity protection for PETRA exchanges MUST be provided by the
underlying management protocol and transport.
* Authentication and authorization: servers MUST authenticate
clients and MUST enforce authorization before processing requests.
In particular, invocation of the "energy/query" action MUST be
limited to authorized users.
* Input validation: implementations SHOULD validate endpoint
identifiers and traffic characterization values to prevent invalid
requests and abusive workloads.
* Information disclosure control: an "energy/query" request contains
source and destination identifiers plus throughput or time-and-
volume traffic information. A response can expose energy metrics,
their accuracy, or whether the supplied endpoints are valid.
Unauthorized invocation or observation can therefore disclose
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 13]
Internet-Draft Energy-API October 2026
customer traffic and operational energy information or enable
endpoint enumeration. Queries SHOULD be filtered according to
policy and client privileges.
* Denial-of-service resilience: repeated or computationally
expensive invocations of "energy/query" can consume controller or
orchestrator resources. Implementations SHOULD apply rate
limiting, quotas, and/or bounded processing.
* Privacy: where measurements can be correlated to customer
behavior, operators SHOULD minimize retention and protect logs and
telemetry generated by queries.
7. 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). 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).
8. IANA Considerations
IANA is requested to register the following URI in the "ns" registry
within the "IETF XML Registry" group [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-petra
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG
Module Names" registry [RFC7950] within the "YANG Parameters"
registry group:
Name: ietf-petra
Maintained by IANA? N
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 14]
Internet-Draft Energy-API October 2026
Namespace: urn:ietf:params:xml:ns:yang:ietf-petra
Prefix: petra
Reference: RFC XXXX
9. References
9.1. Normative References
[I-D.bcmj-green-power-and-energy-yang]
Claise, B., Chen, G., Palmero, M. P., and J. Lindblad,
"Power and Energy YANG Module", Work in Progress,
Internet-Draft, draft-bcmj-green-power-and-energy-yang-07,
26 May 2026, <https://datatracker.ietf.org/doc/html/draft-
bcmj-green-power-and-energy-yang-07>.
[I-D.belmq-green-framework]
Claise, B., Contreras, L. M., Lindblad, J., Palmero, M.
P., Stephan, E., and Q. Wu, "Framework for Energy
Efficiency Management", Work in Progress, Internet-Draft,
draft-belmq-green-framework-10, 8 February 2026,
<https://datatracker.ietf.org/doc/html/draft-belmq-green-
framework-10>.
[I-D.ietf-teas-ietf-network-slice-nbi-yang]
Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
"A YANG Data Model for the RFC 9543 Network Slice
Service", Work in Progress, Internet-Draft, draft-ietf-
teas-ietf-network-slice-nbi-yang-26, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-nbi-yang-26>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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,
<https://www.rfc-editor.org/info/rfc6241>.
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 15]
Internet-Draft Energy-API October 2026
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/info/rfc9911>.
9.2. Informative References
[I-D.ietf-opsawg-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S.,
Pignataro, C., and R. Chen, "Guidelines for Considering
Operations and Management in IETF Specifications", Work in
Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-09,
6 October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-opsawg-rfc5706bis-09>.
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 16]
Internet-Draft Energy-API October 2026
[I-D.madpr-green-provenance]
Palmero, M. P., Lopez, D., Pérez, A. M., Andersson, P.,
and R. Osterberg, "Provenance Traceability Augmentation
for the GREEN Power and Energy YANG Module", Work in
Progress, Internet-Draft, draft-madpr-green-provenance-00,
5 July 2026, <https://datatracker.ietf.org/doc/html/draft-
madpr-green-provenance-00>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
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 energy
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 energy 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 energy-efficient 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,
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 17]
Internet-Draft Energy-API October 2026
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 energy-efficiency objectives. For example,
paths with the lowest energy-consumption could be preferred, enabling
service differentiation where energy-efficient paths are explicitly
prioritized. This extends the SD-WAN use case into a more general
paradigm where routing decisions are jointly driven by network
performance and energy 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 Energy-Efficient Services
Another use case for PETRA could the negotiation of Service Level
Agreements (SLAs) between operators and enterprise customers. By
exposing PETRA-derived metrics such as watts-per-gigabit, providers
can offer differentiated SLAs that explicitly include environmental
targets. This enables customers to select network services not only
based on performance guarantees (e.g. latency), but also on their
environmental footprint (or a combination of both). Such SLAs
empower customers to align their digital services with corporate
energy-efficient and sustainability goals and reporting requirements,
while operators can use PETRA to provide the energy metrics used for
such services.
Appendix B. Requirements for Energy Efficiency Management
The document Framework for Energy Efficiency Management
[I-D.belmq-green-framework] describes a reference model for energy
management. The model includes an 'API Service Interface', labeled
as interface (g) in the document, which "enables access for service
consumption, enabling data retrieval, control, and integration
through API".
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 18]
Internet-Draft Energy-API October 2026
In that context, PETRA is one example of such 'API Service
Interface'. In the particular case of PETRA, the API might be used
to consume from the Network controller, the Domain controller, or
both. Appendix A describes a few use-cases that could make use of
PETRA as an 'API Service Interface' within the Framework for Energy
Efficiency Management [I-D.belmq-green-framework].
Contributors
Fernando Munoz
Cisco
Madrid
Spain
Email: fmunozma@cisco.com
Alejandro Muniz
Madrid
Spain
Roland Schott
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: Roland.Schott@telekom.de
Authors' Addresses
Alberto Rodriguez-Natal
Cisco
Barcelona
Spain
Email: natal@cisco.com
Luis M. Contreras
Telefonica
Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Marisol Palmero
Independent Consultant
Spain
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 19]
Internet-Draft Energy-API October 2026
Email: marisol.ietf@gmail.com
Jan Lindblad
All For Eco
Email: jan.lindblad+ietf@for.eco
Adrian Gallego Sanchez
T-SYSTEMS
Madrid
Spain
Email: ADRIAN.GALLEGO-SANCHEZ@t-systems.com
Rodriguez-Natal, et al. Expires 4 May 2027 [Page 20]