Flow-Level Carbon Emissions Tracing for Packet Networks
draft-elzahr-flow-carbon-trace-00
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 | Sawsan El Zahr , Eve Schooler , Robert Soulé , Noa Zilberman | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-elzahr-flow-carbon-trace-00
Sustain Research Group S. El-Zahr
Internet-Draft E. Schooler
Intended status: Informational University of Oxford
Expires: 7 January 2027 R. Soulé
Yale University
N. Zilberman
University of Oxford
6 July 2026
Flow-Level Carbon Emissions Tracing for Packet Networks
draft-elzahr-flow-carbon-trace-00
Abstract
This document defines a method to derive per-flow energy consumption
and associated carbon emissions without requiring inline power
instrumentation for network equipment. Although energy consumption
is commonly monitored at the device, network, or facility level,
fine-grained attribution of energy consumption and carbon emissions
to individual traffic flows remains an open research problem. The
central contribution is the formulation of a flow-level carbon
accounting model that transforms counter-based traffic measurements
into energy usage estimates and subsequently into carbon emissions
using time- and location-dependent carbon intensity data.
The specification defines a device power model, a flow-level energy
derivation, and idle-energy attribution methods for flows. This
document further highlights how different definitions of carbon
attribution can lead to significant variability in attributed carbon
to flows, emphasizing the urgent need to standardize carbon
accounting definitions and methodologies. In addition to the
modeling framework, the document defines mechanisms for telemetry
collection and deployment models for end-to-end flow tracing to
support operational use cases. These elements complement the core
contribution by enabling implementation and observability.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-elzahr-flow-carbon-trace/.
El-Zahr, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Flow Carbon Trace July 2026
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 7 January 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Framework Overview . . . . . . . . . . . . . . . . . . . . . 5
5. Device Power Model . . . . . . . . . . . . . . . . . . . . . 6
5.1. High-Level Power Model . . . . . . . . . . . . . . . . . 7
5.2. Required Inputs for Compliant Implementation . . . . . . 8
5.3. Model Parameters . . . . . . . . . . . . . . . . . . . . 8
5.4. Benchmarking Methodology for Power Measurements . . . . . 8
6. Flow Energy Derivation . . . . . . . . . . . . . . . . . . . 10
6.1. Consequential Energy of Flows . . . . . . . . . . . . . . 10
6.2. Attributional Energy of Flows . . . . . . . . . . . . . . 11
7. Carbon Emissions Computation . . . . . . . . . . . . . . . . 14
El-Zahr, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Flow Carbon Trace July 2026
8. Telemetry and Flow Carbon Trace Collection . . . . . . . . . 15
8.1. Using In-Network Telemetry . . . . . . . . . . . . . . . 16
8.1.1. Carbon Telemetry Header Structure . . . . . . . . . . 16
8.1.2. Computation Overview . . . . . . . . . . . . . . . . 18
8.2. Using Packet-Level Tracing . . . . . . . . . . . . . . . 19
8.3. Using ISP-Level Tracing . . . . . . . . . . . . . . . . . 20
8.4. Comparison of Approaches . . . . . . . . . . . . . . . . 21
8.5. Interoperability Considerations . . . . . . . . . . . . . 22
9. Other Carbon Scopes . . . . . . . . . . . . . . . . . . . . . 22
10. Operational Considerations . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 24
14. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. Normative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Normative References . . . . . . . . . . . . . . . . 24
Appendix B. Informative References . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Network infrastructure contributes a non-negligible portion of the
energy consumption and carbon footprint of modern digital services
[ICT-Footprint-2023]. While energy consumption is commonly measured
at the device, network, or facility level, attributing energy
consumption and carbon emissions to individual traffic flows remains
an open problem.
Flow-level carbon attribution enables emerging use cases such as
carbon-aware traffic engineering, sustainability reporting for
digital services, carbon-aware service-level agreements, carbon
accounting across interdomains, and application-specific carbon
optimization. However, existing approaches do not provide a
consistent method to derive and attribute emissions at the
granularity of individual traffic flows.
This document defines a framework for deriving, attributing, and
reporting flow-level carbon emissions in packet networks. The
framework consists of three independent stages: device power
modeling, flow-level energy attribution, and end-to-end carbon trace
construction.
El-Zahr, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Flow Carbon Trace July 2026
Future standardization is expected to define common power modeling
methods, attributional emissions definitions and accounting rules,
and standardized mechanisms for tracing, collecting, and transporting
carbon-related information. This document presents one framework and
corresponding mechanisms as a basis for standardization efforts,
while recognizing that alternative methods and future extensions may
also satisfy the framework objectives.
2. Conventions and Terminology
2.1. Requirements Language
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.
2.2. Terminology
Device Idle Power: Traffic-independent power consumption of the
device.
Device Dynamic Power: Traffic-dependent power consumption of the
device.
Carbon Intensity (CI): Mass of CO2 emitted per unit of electrical
energy consumed. This is a measure of how green the energy
consumed is in a given geographic region. Lower values indicate
greener electricity consumed.
Consequential Emissions: Emissions directly caused by forwarding
traffic.
Attributional Emissions: A share of non-traffic-dependent emissions
attributed to traffic (for example, the idle power of equipment).
Flow: A sequence of packets identified by a common set of packet
header fields, including the same source and destination fields.
Flow Carbon Trace: The cumulative carbon emissions (both
consequential and attributional) associated with a flow across all
traversed devices.
El-Zahr, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Flow Carbon Trace July 2026
3. Problem Statement
Packet forwarding devices (e.g., routers and switches) process large
numbers of traffic flows concurrently. These devices do not provide
native mechanisms to measure energy consumption or carbon emissions
at the granularity of individual flows.
While external power meters can measure total device power
consumption, they do not provide any direct decomposition of that
power across traffic flows. In addition, deploying power meters
across all devices and locations is often impractical due to cost,
operational complexity, and installation constraints in large-scale
networks. In current networks, some have implemented smart power
distribution units (PDUs) and some have not. Furthermore, the
accuracy of built-in power measurements in devices is often
insufficiently accurate for flow-level accounting purposes.
As a result, per-flow energy consumption and carbon emissions cannot
be obtained through direct measurement. Instead, they must be
derived from observable network telemetry and suitable accounting
methodologies.
This document defines a framework for deriving, attributing, and
reporting flow-level carbon emissions in packet networks.
4. Framework Overview
Flow-level carbon emissions cannot be measured directly. Network
devices consume electrical energy, multiple flows share the same
infrastructure, and the resulting carbon emissions depend on both
energy consumption and the carbon intensity of the energy source.
This document defines a framework that derives flow-level carbon
emissions from network telemetry through three logical stages:
Network Traffic Statistics
↓
Device Power Model
↓
Energy Attribution at the Flow-Level
↓
Carbon Trace Construction along the Full Path of the Flow
The first stage estimates device power consumption from observable
traffic statistics without requiring power instrumentation in
operational networks. Section 5 defines the power model and
introduces a benchmarking methodology used to derive model
parameters.
El-Zahr, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Flow Carbon Trace July 2026
The second stage attributes device energy consumption to the
individual flows traversing the device. This produces flow-level
energy metrics. Section 6 describes the different types of energy-
usage that can be allocated to flows and their respective scales.
The third stage converts flow-level energy into carbon emissions,
taking the regional carbon intensity into account (Section 7), and
constructs an end-to-end carbon trace for the flow as it traverses
the network (Section 8).
A key design principle of this framework is modularity. These three
stages are independent and can evolve separately over time.
A deployment may adopt a new device power model without changing the
flow attribution methodology or the carbon trace construction
mechanisms. Likewise, a new flow attribution methodology can be
introduced without changing the underlying power model or the tracing
mechanisms. Similarly, new carbon trace formats or transport
mechanisms can be deployed while continuing to use existing power
models and attribution methods.
The purpose of this document is therefore not to define a single
monolithic algorithm. Instead, it defines a framework composed of
interoperable building blocks and well-defined interfaces between
them. This modular design allows future improvements in device
modeling, flow attribution, and carbon tracing to be adopted
independently while maintaining interoperability.
Sections 5-8 describe each stage of the framework and standardize the
packet formats and information exchanged between them.
5. Device Power Model
The first stage of the framework estimates device power consumption
from observable network traffic statistics. While total device power
may be measured through external instrumentation, such measurements
are often unavailable in operational networks. To address this
limitation, the framework uses a device power model that maps network
traffic statistics to device power consumption, thereby eliminating
the need for power meters installed for network equipment.
Conceptually, this stage performs the following transformation:
Network Traffic Statistics
↓
Device Power Consumption
El-Zahr, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Flow Carbon Trace July 2026
The output of this stage is an estimate of the instantaneous power
consumption of the device. This output serves as the input to the
Flow Energy Attribution stage described in Section 6. The model
presented in this section provides one approach for deriving device
power consumption from commonly available traffic statistics.
5.1. High-Level Power Model
In its most general form, the device total power consumption is a
function that can be expressed as:
text P = f(X1, X2, ..., Xn)
where P denotes device power consumption and X1 ... Xn represent
observable traffic statistics.
The choice of the function f raises an important question: how
complex does the power model need to be?
A sufficiently complex model could incorporate a large number of
traffic variables, device-specific characteristics, and non-linear
interactions between them. While such models may improve accuracy,
they also increase deployment complexity and reduce interoperability.
The goal of this framework is not to identify the most accurate model
possible, but rather to identify a model that provides sufficient
accuracy while relying on measurements that are commonly available in
operational networks.
An experimental evaluation in [SIGMETRICS25] demonstrates that, for
the devices studied, power consumption can be modeled with high
accuracy using a simple linear relationship between device power and
a small set of traffic statistics.
P [W] = P_idle [W] + α_p [W/bps] · T [bps] + β_p [W/pps] · R [pps]
where P_idle captures the traffic-independent baseline power
consumption, T and R are the throughput and packet rate, and the
coefficients α_p and β_p represent the linear contribution of
throughput and packet rate, respectively, to the overall power
consumption. The brackets represent the units of these variables.
The next subsections describe a benchmarking methodology for deriving
these parameters from experimental measurements.
El-Zahr, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Flow Carbon Trace July 2026
5.2. Required Inputs for Compliant Implementation
A compliant implementation of the proposed benchmark relies on
observable traffic counters that are commonly available on packet
forwarding devices. Specifically, the model requires access to the
total throughput and total packet rate processed by the device over a
given measurement interval.
These quantities can be derived from device counters and represent
aggregate traffic handled by the forwarding plane. The throughput is
expressed in bits per second, while the packet rate is expressed in
packets per second.
5.3. Model Parameters
The device power model is defined by three parameters: P_idle, α_p,
and β_p. These parameters can be obtained through the benchmarking
methodology described below and provided by any compliant
implementation.
P_idle represents the baseline power consumption of the device in the
absence of traffic and reflects the contribution of always-on
components such as power supplies, cooling systems, and control-plane
elements. The coefficients α_p and β_p quantify the incremental
power associated with processing traffic, capturing the effects of
throughput and packet rate, respectively.
Implementations can expose these parameters in a programmatically
accessible manner, allowing them to be consumed by monitoring
systems, telemetry pipelines, or external controllers. In cases
where devices support multiple operating modes (e.g., different port
configurations or power states), implementations can provide multiple
parameter sets corresponding to these modes. Section 8 describes how
these parameters can be incorporated into carbon tracing packets.
5.4. Benchmarking Methodology for Power Measurements
To derive a device power model that is reproducible and portable
across implementations, a standardized benchmarking methodology
should be followed. In this document, a methodology for benchmarking
router power modeling is proposed based on the work in
[SIGMETRICS25]. The objective of this benchmark is to characterize
how the power consumption of a packet forwarding device varies as a
function of observable traffic properties. Rather than relying on
instantaneous power instrumentation in operational deployments, this
approach enables a one-time characterization of the device that can
later be reused in operation.
El-Zahr, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Flow Carbon Trace July 2026
The benchmarking process consists of subjecting the device under test
(DUT) to controlled traffic conditions while measuring its power
consumption. Traffic is generated in a way that allows independent
variation of throughput and packet rate. This typically requires the
use of a traffic generator capable of producing packet streams with
configurable packet sizes and transmission rates. Since packet rate
is inversely related to packet size for a given throughput, varying
packet sizes is essential to decouple the effects of throughput and
packet processing on power consumption.
The DUT can be configured in a stable forwarding mode, ensuring that
no additional control-plane or background processes significantly
affect power consumption during measurements. To accurately capture
the full operational range of the device, it is recommended to allow
the traffic generation setup to exercise the device from idle
conditions up to near-maximum capacity. This may require multi-port
traffic generation or loopback configurations that ensure the
switching fabric is fully utilized.
Power measurements can be collected using either external measurement
equipment (such as instrumented or smart power distribution units) or
reliable embedded sensors, provided that the measurement accuracy is
sufficient to capture variations in dynamic power (i.e., the traffic-
dependent power consumption of the device). For each measurement
point, the total device power is recorded together with the
corresponding total throughput and packet rate observed on the
device.
The collected measurements are then used to derive a parametric power
model through regression analysis. Implementations can fit a model
of the following form:
P [W] = P_idle [W] + α_p [W/bps] · T [bps] + β_p [W/pps] · R [pps]
As shown in [SIGMETRICS25], linear regression can be used as the
baseline method, as it provides both high accuracy and implementation
simplicity. This benchmark model was validated against independent
traffic traces, particularly those containing mixed packet sizes, to
ensure that it generalizes beyond the controlled benchmark inputs.
Moreover, it was demonstrated that both throughput and packet rate
are essential to achieve a high accuracy for the power model. Using
throughput alone or packet rate alone to model power can reduce
accuracy significantly under certain scenarios, e.g., to 53% and 16%,
respectively [SIGMETRICS25].
The parameters obtained from this process are specific to the device
model and its configuration, including hardware characteristics and
software settings or firmware versions. As such, these parameters
El-Zahr, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Flow Carbon Trace July 2026
are treated as device-specific constants. Implementations can make
these parameters accessible through programmatic interfaces or
configuration mechanisms, enabling their use in downstream energy and
carbon computations.
An example implementation of this benchmark is provided in
[SIGMETRICS-GithubRepo].
6. Flow Energy Derivation
The device power model provides an estimate of the total power
consumption of a device based on aggregate traffic. To enable flow-
level accounting, this total power can be decomposed into
contributions attributable to individual traffic flows.
A key distinction arises between the idle portion of the power, which
is independent of traffic, and the dynamic portion, which is directly
influenced by traffic characteristics. The dynamic power component
can be directly allocated to individual flows, as it represents the
additional energy required to process and forward traffic. This
component is therefore referred to as consequential energy.
The idle power component requires a different treatment. Although a
router consumes this baseline power regardless of the traffic it
carries, it must remain operational and ready to process flows
whenever they arrive. Consequently, individual flows share
responsibility for maintaining the availability of the network
infrastructure. For this reason, a portion of the idle energy
consumption can also be attributed to individual flows. This
component is referred to as attributional energy. For an end-to-end
flow that traverses many hops, the assignment of attributional energy
should follow a previously agreed-upon definition as will be
explained in the following sections.
6.1. Consequential Energy of Flows
Consequential energy captures the additional energy consumed by a
router as a direct consequence of processing a particular traffic
flow. The derivation of flow-level consequential energy builds on
the linearity of the device power model. By considering the
cumulative traffic associated with a flow, the energy attributable to
that flow can be expressed directly in terms of its total number of
bytes and packets. Specifically, the consequential energy of a flow
E_f can be computed as:
E_f [J] = α_e [J/B] · bytes_f [B] + β_e [J/Pkt] · packets_f [Pkt]
El-Zahr, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Flow Carbon Trace July 2026
where bytes_f and packets_f represent the cumulative byte and packet
counts of the flow, respectively. The coefficients α_e and β_e are
derived from the device-level parameters α_p and β_p multiplied by
time, with α_e corresponding to α_p scaled to units of energy per
byte, and β_e corresponding directly to energy per packet.
Specifically:
α_e [J/B or Ws/B] = 8 * α_p [W / bps]
and,
β_e [J/Pkt or Ws/Pkt]= β_p [W/pps]
An important property of this formulation is that it does not depend
on the duration of the flow. Instead, it depends solely on the total
volume of traffic transmitted. As a result, the computed energy is
invariant to how the traffic is temporally transmitted. For example,
transmitting a given amount of data at a high rate over a short
period yields the same consequential energy as transmitting it at a
lower rate over a longer period.
This property ensures consistency and fairness in energy attribution,
as flows with identical traffic characteristics will be assigned
identical consequential energy regardless of their timing behavior.
6.2. Attributional Energy of Flows
In contrast to dynamic power, idle power represents the baseline
energy consumption required to keep the device operational. This
component is independent of the presence or characteristics of
individual traffic flows and therefore is not typically directly
assigned to a specific flow. Instead, it is attributed according to
a chosen accounting methodology.
Idle energy is therefore considered attributional, and different
attribution methods may lead to significantly different results.
Implementations need to support at least one method for attributing
idle energy to flows, and the corresponding exported energy/carbon
records per flow should explicitly indicate the chosen method as will
be explained in Section 8. This attribution is particularly
important in core and backbone networks, where idle power often
represents a substantial fraction of total device power consumption.
Since this energy is consumed regardless of traffic volume, an
explicit attribution methodology is required to determine which
flows, services, or users are assigned responsibility for this shared
infrastructure cost.
El-Zahr, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Flow Carbon Trace July 2026
One possible approach is to exclude idle energy entirely from flow-
level accounting, assigning only consequential energy to flows.
Alternatively, idle energy may be divided equally among all active
flows within a given measurement interval, assigning each flow an
equal share regardless of its traffic volume. More refined
approaches allocate idle energy proportionally based on flow
characteristics. For example, flows may be assigned a share of idle
energy proportional to their byte volume, resulting in larger flows
receiving a greater share. Similarly, attribution based on packet
volume assigns a higher share to flows with higher packet counts.
The expectation is that every router in the path of a flow should use
the same option, otherwise, the resulting estimate may be
inconsistent or inaccurate.
The four definitions can be summarized as:
* No Idle Attribution: Idle energy is not assigned to flows
* Equal Per-Flow Division: Idle energy is evenly divided among all
active flows during a measurement interval.
In this case, the energy share attributed to each flow depends on the
total number of active flows during the given time interval and on
the flow duration. Consequently, the longer a flow remains active on
a device, the greater its overall attributed energy consumption. The
attributional energy per flow Eb_f in this case is:
Eb_f [J] = (Idle Power [W] / Number of Flows) × Flow Duration [s]
Variations in the number of active flows are accounted for by
recomputing the metric for each measurement interval. When exported
through telemetry, the reported value is (Idle Power / Number of
Flows), expressed in Watts (or equivalently joules per second). The
energy attributed to a flow is obtained by multiplying this value by
the duration of the flow.
The choice of the measurement interval influences the stability of
the metric. Short intervals capture rapid changes in the number of
active flows but may produce significant fluctuations in the
attributed value. Longer intervals provide a more stable estimate
but may smooth over short-term variations in flow activity.
Implementations require the selection of an interval that balances
responsiveness and stability according to operational requirements.
* Proportional to Flow Bitrate: Idle energy is distributed
proportionally to each flow's bitrate contribution.
El-Zahr, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Flow Carbon Trace July 2026
In this case, flow duration is not relevant. Instead, attribution is
based on the total number of bytes associated with a flow relative to
the total number of bytes across all flows. Hence, the required
parameters are the total router throughput and the total number of
bytes of the individual flow. The attributional energy per flow Eb_f
in this case is:
Eb_f [J] = (Idle Power [W] / Router Throughput [bps] * 8) × Flow Number of Bytes [B]
Similarly to the previous option, the router throughput value should
be updated whenever it changes significantly. The telemetry metric
in this case would be (Idle Power [W] / Router Throughput [bps] * 8)
expressed in J/B and should be multiplied by the total number of
bytes of the flow (Flow Number of Bytes [B]).
* Proportional to Flow Packet Rate: Idle energy is distributed
proportionally to each flow's packet-rate contribution.
This approach is similar to the previous case; however, attribution
is based on packet counts rather than byte counts. The attributional
energy per flow Eb_f in this case is:
Eb_f [J] = (Idle Power [W] / Router Packet Rate [pps]) × Flow Number of Packets [pkts]
The router packet rate value should be updated whenever it changes
significantly. The telemetry metric in this case would be (Idle
Power [W] / Router Packet Rate [pps]) expressed in J/pkt and should
be multiplied by the total number of packets of the flow (Flow Number
of Packets [pkts]).
In all cases, the definition of an “active flow” over a specific
measurement interval should be clearly specified, and the attribution
is computed over well-defined time intervals consistent with counter
measurements. Implementations may also incorporate utilization-aware
attribution, in which only a fraction of the idle energy---
corresponding to the device’s utilization level---is distributed
among flows. The proportion of idle energy variable γ is defined as:
γ = Router Throughput [bps]/ Max Capacity [bps]
This variable is added to the extended definitions as follows:
* Equal per-flow division and router utilization considered:
Eb_f [J] = (Idle Power [W] * γ / Number of Flows) × Flow Duration [s]
* Proportional to byte volume and router utilization considered:
El-Zahr, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Flow Carbon Trace July 2026
Eb_f [J] = (Idle Power [W] * γ / Router Throughput [bps] * 8) × Flow Number of Bytes [B]
* Proportional to packet volume and router utilization considered:
Eb_f [J] = (Idle Power [W] * γ / Router Packet Rate [pps]) × Flow Number of Packets [pkts]
The choice of attribution method has a significant impact on the
resulting carbon footprint of flows. For example, the paper
[SIGMETRICS25] shows that in a video streaming use case,
attributional emissions can be up to 120 times higher based on the
choice of attribution method. Depending on the chosen model,
different and sometimes contradictory insights emerge: (1) When idle
power is evenly divided across flows, transmitting over shorter
durations leads to lower attributed emissions. (2) When idle power is
attributed based on bit rate, lower bit rates yield lower emissions.
(3) When packet rate is used for attribution, larger packet sizes
result in lower emissions. (4) When idle power is divided without
accounting for router utilization, sending flows during high-
utilization periods (e.g., peak hours) reduces their carbon footprint
which may incentivize sending more flows at peak.
These observations highlight the ambiguity and sensitivity of
attributional carbon accounting in networks. The selection of an
idle power attribution model can significantly influence the
calculated emissions of individual flows and may lead to divergent
optimization strategies. Given this variability, it is essential
that Internet Service Providers (ISPs), cloud operators, and
application developers adopt a consistent and transparent definition
for attributing emissions, particularly those associated with idle
power.
The modularity of the framework would allow for the incorporation of
new/improved attributional models in the future.
7. Carbon Emissions Computation
Carbon emissions are derived from energy consumption through the use
of carbon intensity data, which represents the amount of carbon
emitted per unit of electrical energy consumed. The computation of
carbon emissions follows a direct proportional relationship between
energy and carbon intensity.
Specifically, carbon emissions are computed as:
Carbon [gCO2] = Energy [kWh] × CI [gCO2/kWh]
El-Zahr, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Flow Carbon Trace July 2026
where Energy represents the energy consumption of the device or flow,
and CI denotes the carbon intensity of the electricity used to supply
that energy.
To ensure correctness, implementations should ensure unit consistency
in this computation. Since carbon intensity is typically expressed
in grams of CO2 per kilowatt-hour, energy values expressed in Joules
should be converted accordingly before applying the formula.
Carbon intensity is inherently dependent on both time and location,
as the energy mix used to generate electricity varies across regions
and throughout the day. Therefore, carbon intensity data must be
aligned with the time interval over which energy is measured and with
the physical location of the device.
Where possible, implementations should use real-time or near-real-
time carbon intensity data obtained from reliable sources
[ELECTRICITY-MAPS] [CARBON-INTENSITY-API]. In cases where such data
is not available, historical averages or forecasted values may be
used, provided that their source and temporal resolution are clearly
documented.
At the flow level, carbon emissions are computed by combining both
consequential and attributional components of energy. The total
carbon associated with a flow is therefore the sum of the carbon
derived from its consequential energy and the carbon derived from its
attributed share of idle energy.
Finally, the end-to-end carbon trace of a flow is obtained by summing
the carbon contributions from all devices traversed by that flow.
This cumulative view provides a complete representation of the flow’s
carbon footprint across the network.
8. Telemetry and Flow Carbon Trace Collection
The computation of flow-level carbon emissions requires that per-
device carbon contributions be combined across all devices traversed
by a flow. While the previous sections define how carbon is computed
locally at each device, this section specifies how such information
is collected and propagated to construct an end-to-end Flow Carbon
Trace.
A fundamental challenge is that carbon contributions are generated
independently at each hop, yet must be represented as a single
cumulative value associated with a flow. It is important to
distinguish between collecting carbon telemetry data and collecting
the actual carbon trace of a flow. The carbon trace of a flow is
easier to formulate because at each hop, the router computes the
El-Zahr, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Flow Carbon Trace July 2026
carbon contribution of a specific flow from both consequential and
attributional emissions and adds them together. This represents one
aggregated cumulative value. However, if users or applications want
to adjust their operation in real-time to optimize their carbon
footprint, then in-network telemetry is the right approach. In this
case, cumulative telemetry data from all hops is collected and the
carbon trace is computed locally after receiving the telemetry data.
This means that more data needs to be sent in the telemetry packet
rather than a simple single value of the total carbon of a flow.
This document defines three approaches to achieve flow-level carbon
tracing, reflecting different deployment models and operational
trade-offs:
* using in-network telemetry
* using packet-level tracing
* using ISP-level tracing
8.1. Using In-Network Telemetry
In this method, the user or application periodically sends telemetry
packets through the network to estimate the carbon footprint of a
given path. A new telemetry packet can be generated when carbon
intensity changes (e.g., every 30-60 minutes) or when significant
shifts in network utilization are expected (given a certain
threshold).
Each telemetry packet carries carbon metrics for both consequential
and attributional emissions. These values are separately accumulated
at each hop.
Upon arrival, the destination reads the accumulated carbon header and
returns it to the sender. Different paths yield different aggregate
values. Increasing telemetry frequency improves accuracy and enables
applications to adapt behavior (e.g., scheduling or rate control).
8.1.1. Carbon Telemetry Header Structure
Since these packets are used solely for telemetry, they do not
collect or carry a per-flow carbon trace. Instead, they accumulate
only the carbon model coefficients defined in the previous sections,
enabling applications to adapt their operation (e.g., transmission
rate, scheduling, or other parameters) according to their own
characteristics and carbon-reduction objectives. The carbon
telemetry header therefore provides a compact in-network telemetry
structure for accumulating consequential and attributional carbon
El-Zahr, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Flow Carbon Trace July 2026
coefficients along the path of a flow. The format is inspired by
IOAM aggregation mechanisms [I-D.draft-cxx-ippm-ioamaggr-04] but
reduced to the minimal set of fields required for carbon accounting.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Idle Model | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conseq Carbon per Byte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conseq Carbon per Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributional Carbon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Descriptions:
* Flags (8 bits): Flags indicate which fields in the option are
active or valid. They also provide basic control information for
interpretation of the telemetry data.
Typical flag usage includes enabling or disabling the use of
consequential or attributional components and indicating whether the
option has been processed by all hops.
* Idle Model (8 bits): The Idle Model field defines how idle energy
is attributed to the flow. It determines the unit of the
Attributional Carbon field.
The potential values of this field are as follows: - 0: no idle
attribution - 1: equal per-flow division - 2: proportional to byte
volume - 3: proportional to packet volume - 4: equal per-flow
division and router utilization considered - 5: proportional to byte
volume and router utilization considered - 6: proportional to packet
volume and router utilization considered - The interpretation of the
Attributional Carbon field depends on this selection. The
expectation is that every router in the path of a flow should use the
same option, otherwise, the resulting estimate may not be accurate.
The 7 options discussed in this paper are included in the options,
but alternatively, the community is invited to propose with
additional definitions.
* Hop Count (16 bits): The Hop Count field records the number of
network nodes that have contributed to the carbon accumulation.
Each node increments this value when updating the telemetry data.
El-Zahr, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Flow Carbon Trace July 2026
* Conseq Carbon per Byte (32 bits): This field contains the
accumulated consequential carbon coefficient per byte along the
path. Each node adds its local contribution to this field.
The flow-level consequential carbon is obtained by multiplying this
value by the total number of bytes in the flow.
* Conseq Carbon per Packet (32 bits): This field contains the
accumulated consequential carbon coefficient per packet along the
path. Each node adds its local contribution to this field.
The flow-level consequential carbon is obtained by multiplying this
value by the total number of packets in the flow.
* Attributional Carbon (32 bits): This field contains the
accumulated attributional carbon coefficient. Its unit depends on
the selected Idle Model.
When the Idle Model is:
- equal division among flows (with or without router utilization consideration), the field represents carbon per second
- proportional to bytes (with or without router utilization consideration), the field represents carbon per byte
- proportional to packets (with or without router utilization consideration), the field represents carbon per packet
- no idle attribution, the field is zero
The final attributional carbon for a flow is obtained by multiplying
this field with the corresponding flow metric (duration, bytes, or
packets).
8.1.2. Computation Overview
At each hop, the node does not append new information to the header.
Instead, it updates the existing aggregate fields by adding its local
contributions to the cumulative values already carried in the packet.
The final carbon footprint of a flow is computed at the node
collecting telemetry by combining consequential and attributional
components.
The consequential component depends on the total number of bytes and
packets in the flow, while the attributional component depends on the
idle attribution model selected for the telemetry option.
El-Zahr, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Flow Carbon Trace July 2026
8.2. Using Packet-Level Tracing
This method provides higher accuracy by embedding carbon information
in every packet of a flow. As with the telemetry-based approach
described above, packets may carry carbon telemetry coefficients that
are interpreted by the destination. Alternatively, packets may carry
a directly accumulated carbon trace, in which case each node updates
the cumulative carbon value carried in the packet.
For the accumulated carbon trace approach, at each hop:
* Consequential and attributional emissions are computed,
* Combined into a single contribution, and
* Added to the cumulative carbon field.
The destination aggregates results per flow and can report them
periodically or upon completion. This method can be applied
bidirectionally (client-to-server and server-to-client).
In terms of packet structure, this method can be realized using a
modification of the structure defined in the previous section where
here we only need one aggregate value of carbon instead of 3 separate
fields. Moreover, in cases of intradomain traffic, this method can
also be realized using In-situ Operations, Administration, and
Maintenance, specifically the IOAM Aggregation Trace Option [I-
D.draft-cxx-ippm-ioamaggr-04], where each node updates the aggregate
carbon field rather than appending per-hop data.
For intradomain traffic, an example is presented next of how to
encode the carbon trace data directly using the In-situ Operations,
Administration, and Maintenance Aggregation Trace Option, without
modifying its format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM Data Param | Aggregator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auxil-data Node-ID | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Carbon-specific field usage:
El-Zahr, et al. Expires 7 January 2027 [Page 19]
Internet-Draft Flow Carbon Trace July 2026
* Namespace-ID: Identifies the IOAM domain. It remains unchanged
along the path.
* Flags: Error indicators. If set, aggregation stops and data is
forwarded unchanged.
* Reserved: Reserved by the IOAM Aggregation Trace Option
specification. This field is set to zero by the sender and
ignored by receivers.
* IOAM Data Param: Identifies the aggregated metric. Set to “Carbon
Emissions” (combined consequential + attributional).
* Aggregator: Defines aggregation function. It should be set to
Sum.
* Aggregate: Carries the cumulative carbon value. Each node adds
its local contribution (consequential + attributional).
* Auxil-data Node-ID: Identifies node of interest. Used only for
error reporting (per IOAM semantics).
* Hop Count: Counts nodes that successfully contributed to
aggregation.
Each node computes:
* carbon_contribution = consequential + attributional
* The contribution is added to Aggregate.
* The attribution method (one of the 7 models) can be: pre-
configured within the IOAM domain, or implicitly defined by the
Namespace-ID.
In this case, no additional fields are introduced; the IOAM
Aggregation Option is used unchanged, ensuring compatibility with
existing implementations and drafts.
8.3. Using ISP-Level Tracing
ISP-level tracing leverages existing ISP monitoring infrastructure
without requiring any changes to packet headers. It supports only
coarse-grained reporting intervals (e.g., daily or monthly), which
limits real-time carbon-aware adaptation but remains effective for
accurate carbon accounting. Border routers and other monitoring
nodes already collect traffic logs for operational and billing
purposes. These nodes record information such as source and
El-Zahr, et al. Expires 7 January 2027 [Page 20]
Internet-Draft Flow Carbon Trace July 2026
destination IPs, ports, timestamps, and volume, and forward
aggregated records to a central node for analysis.
A key assumption here is that the central node operates at ISP scope,
meaning it only has visibility into traffic once it enters and leaves
the ISP’s network. In other words, it does not assume full end-to-
end visibility across multiple ISPs or external networks. Instead,
it can only reconstruct the portion of each flow that traverses its
own infrastructure. Depending on the deployment, this may cover
either the entire flow (if both endpoints are within the ISP) or only
a segment of a broader end-to-end path (if the traffic crosses
multiple ISPs).
For example, a streaming service---whose content caches may already
be embedded within the ISP’s infrastructure---might request the ISP
to estimate the carbon footprint of delivering video to users on its
network. In this case, the ISP measures only the portion of traffic
that traverses its own infrastructure, between ingress and egress
points associated with those users.
The central node estimates the paths taken by the flows and
correlates them with the carbon intensity values of routers along
those paths. As a result, the ISP can estimate emissions per flow,
user, or cache and report them periodically (e.g., hourly, daily, or
weekly). Although packet sampling can reduce accuracy, biased
monitoring of selected flows can mitigate this limitation.
8.4. Comparison of Approaches
Each of the three methods presents different trade-offs in terms of
accuracy, overhead, carbon data distribution, and update frequency.
In terms of *accuracy*, in-network telemetry may be limited by multi-
path routing (e.g., ECMP), which introduces uncertainty in flow
paths. Packet-level tracing is the most accurate since it captures
emissions on a per-hop basis with full path visibility. ISP-level
tracing achieves moderate to high accuracy depending on the quality
of path estimation and sampling.
With respect to *packet overhead*, in-network telemetry introduces
minimal overhead by sending dedicated telemetry packets or
occasionally attaching carbon tracing headers to flow packets.
Packet-level tracing has higher overhead as every packet carries a
carbon trace header. The total length of the suggested aggregate
carbon header is fixed at 8 bytes.
For the range 64B-1500B for the packet size, the overhead is 0.5%-
12.5%. With an average packet size of 880B (taken from a CAIDA
trace), the packet overhead would be 0.9% on average. ISP-level
El-Zahr, et al. Expires 7 January 2027 [Page 21]
Internet-Draft Flow Carbon Trace July 2026
tracing imposes no additional packet overhead, as it relies solely on
existing ISP traffic logs. While increasing telemetry frequency
improves accuracy, it also slightly increases traffic and associated
emissions. However, this trade-off does not eliminate the need for
accurate carbon reporting that is a requirement to enable carbon-
aware networks.
For *carbon intensity data distribution*, in-network telemetry and
packet-level tracing require each router to have local access to up-
to-date carbon intensity. In contrast, ISP-level tracing centralizes
this information, requiring only the central monitoring node to
maintain carbon intensity data.
Finally, in terms of *reporting frequency*, in-network telemetry
requires updates at flow initiation, when carbon intensity changes
and when network load changes significantly. Packet-level tracing
allows reporting at flow completion or at low periodic intervals.
ISP-level tracing supports only coarse-grained reporting intervals
(e.g., daily, monthly), which limits its ability to support real-time
carbon-aware application adaptation, although it remains effective
for accurate carbon reporting.
8.5. Interoperability Considerations
To ensure interoperability across implementations and administrative
domains, carbon values are expressed in consistent units across all
telemetry methods. The attribution method used for idle energy is
explicitly encoded in all telemetry representations and should be
consistent at least along the path of a specific flow. Time
intervals should be clearly defined where applicable.
If one or more devices along a flow's path do not expose carbon
metrics, the calculated carbon footprint of the flow will
underestimate the actual value. The mechanisms specified in this
document therefore provide a best-effort estimate based on the subset
of participating devices. Although incomplete, such estimates remain
valuable for identifying emission hotspots, comparing alternatives,
and guiding carbon-aware optimization decisions.
9. Other Carbon Scopes
The framework can be extended beyond operational emissions to include
other carbon scopes associated with network infrastructure.
Embodied carbon emissions, i.e., emissions associated with the
extraction of raw materials, manufacturing, transportation, and
deployment of network equipment, can be treated analogously to idle
power. These emissions are typically amortized over the operational
El-Zahr, et al. Expires 7 January 2027 [Page 22]
Internet-Draft Flow Carbon Trace July 2026
lifetime of the device, which is often assumed to be approximately
five years. The resulting amortized emissions can then be
apportioned across flows using the same attribution methodologies
defined for idle power consumption.
Similarly, end-of-life emissions, including equipment
decommissioning, transportation, recycling, and disposal, can be
incorporated as an additional static carbon component. As with
embodied emissions, these emissions may be amortized over the device
lifetime and attributed across flows using the same methodologies
applied to idle power.
Consequently, the attribution framework defined in this document is
not limited to operational emissions and can be applied to any static
carbon component attributed to the device.
10. Operational Considerations
Vendors are recommended to provide power-model parameters that have
been adequately derived and validated in accordance with the
recommended benchmarking methodology.
Operators need to consider the Power Usage Effectiveness (PUE) where
applicable by incorporating a PUE adjustment factor into the energy
estimation coefficients to reflect facility-level overheads.
11. Security Considerations
The use of in-band carbon telemetry is not expected to expose
sensitive operational information, as the telemetry carries only an
aggregate carbon value for the end-to-end path rather than per-hop
measurements or detailed operational metrics.
Implementations need to consider the confidentiality and integrity of
telemetry data. In particular:
* Access to carbon data should be restricted to authorized entities.
* Telemetry data can be aggregated or anonymized where possible to
limit information leakage.
* Carbon data carried in packets need to be protected against
unauthorized modification or inspection (e.g., via encryption or
integrity protection at the network or transport layer).
* Exported telemetry data are required to be transmitted over secure
channels.
El-Zahr, et al. Expires 7 January 2027 [Page 23]
Internet-Draft Flow Carbon Trace July 2026
Operators need to carefully evaluate the trade-off between telemetry
granularity and potential information exposure when deploying these
mechanisms.
Furthermore, in inter-domain deployments, there is a risk that
operators may report incorrect carbon metrics, intentionally or
otherwise. For example, operators may advertise lower carbon
intensity values to influence routing decisions or attract traffic.
The validation and certification of reported metrics are outside the
scope of this document and are expected to be addressed through
separate trust, auditing, or regulatory mechanisms.
12. IANA Considerations
IANA requests are TBD. Future versions of this document may request
the establishment of a registry for per-flow carbon metrics, idle
attribution methods and carbon tracing methods.
13. Applicability
This specification applies to packet forwarding devices including
routers, switches, and programmable forwarding elements.
14. Limitations
This document does not address:
* non-packet network domains
* availability of carbon-intensity data
15. Normative References
[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>.
[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>.
Appendix A. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
El-Zahr, et al. Expires 7 January 2027 [Page 24]
Internet-Draft Flow Carbon Trace July 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174.
Appendix B. Informative References
[ICT-Footprint-2023] Seth Ayers, Sara Ballan, Vanessa Gray, and Rosie
McDonald. Measuring the emissions and energy footprint of the ICT
sector: Implications for climate action. 2023. A Joint ITU/World
Bank Report.
[SIGMETRICS25] Sawsan El-Zahr and Noa Zilberman. 2025. From
Measurement to Emissions: Assessing the Carbon Footprint of Traffic
Flows. Proc. ACM Meas. Anal. Comput. Syst. 9, 3, Article 54
(December 2025), 24 pages. https://doi.org/10.1145/3771569
[SIGMETRICS-GithubRepo] Sawsan El-Zahr and Noa Zilberman.
"Measurements2Emissions", https://github.com/ox-computing/
Measurements2Emissions, accessed June 2026.
[ELECTRICITY-MAPS] Electricity Maps, "Methodology",
https://www.electricitymaps.com/data-portal/methodology, accessed
June 2026.
[CARBON-INTENSITY-API] "Carbon Intensity API",
https://www.carbonintensity.org.uk/, accessed June 2026.
[I-D.draft-cxx-ippm-ioamaggr-04] Clemm, A., Metzger, L., Bister, R.
and Dellsperger, S., "Aggregation Trace Option for In-situ
Operations, Administration, and Maintenance (IOAM)", Work in
Progress, Internet-Draft, draft-cxx-ippm-ioamaggr-04, 03 November
2025, https://datatracker.ietf.org/doc/draft-cxx-ippm-ioamaggr/04/
Authors' Addresses
Sawsan El-Zahr
University of Oxford
Email: sawsan.elzahr@some.ox.ac.uk
Eve Schooler
University of Oxford
Email: eve.schooler@eng.ox.ac.uk
Robert Soulé
Yale University
Email: robert.soule@yale.edu
El-Zahr, et al. Expires 7 January 2027 [Page 25]
Internet-Draft Flow Carbon Trace July 2026
Noa Zilberman
University of Oxford
Email: noa.zilberman@eng.ox.ac.uk
El-Zahr, et al. Expires 7 January 2027 [Page 26]