| Internet-Draft | Flow Carbon Trace | July 2026 |
| El-Zahr, et al. | Expires 7 January 2027 | [Page] |
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.¶
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/.¶
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 (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.¶
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.¶
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.¶
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.¶
Traffic-independent power consumption of the device.¶
Traffic-dependent power consumption of the device.¶
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.¶
Emissions directly caused by forwarding traffic.¶
A share of non-traffic-dependent emissions attributed to traffic (for example, the idle power of equipment).¶
A sequence of packets identified by a common set of packet header fields, including the same source and destination fields.¶
The cumulative carbon emissions (both consequential and attributional) associated with a flow across all traversed devices.¶
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.¶
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.¶
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.¶
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
¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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].¶
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.¶
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]¶
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.¶
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.¶
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.¶
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:¶
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.¶
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]¶
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.¶
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 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:¶
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).¶
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 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.¶
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).¶
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.¶
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:¶
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.¶
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 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.¶
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 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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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.¶
This specification applies to packet forwarding devices including routers, switches, and programmable forwarding elements.¶
This document does not address:¶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119.¶
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174.¶
[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/¶