Path Energy Traffic Ratio API (PETRA)

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.¶

Some other parameters that could be considered as well as part of the energy information include:¶

• Renewable Percentage: How much of the energy consumed comes from renewable energy sources.¶
• Carbon Intensity: How much carbon emissions are generated as a consequence of the energy consumed.¶
• ...¶

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).¶

                                                 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.¶

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, 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 energy consumption, renewable energy percentage, 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). For example requesting that at least 60% of traffic be carried over renewable-powered infrastructure. Such SLAs empower customers to align their digital services with corporate energy-efficient and sustainability goals and reporting requirements, while operators can use PETRA as the trusted source of verifiable energy data.¶