RFC 9845

Challenges and Opportunities in Management for Green Networking

📅 published October 2025, from ietf

RFC 9845: Challenges and Opportunities in Management for Green Networking 🌿💚

Okay bestie, this is a whole research doc and I'm so here for it. 💅 Here's the title block so you know who's behind it and where it sits. ✨

  • Series: Internet Research Task Force (IRTF) 🔬
  • Number: RFC 9845 🎀
  • Editors: A. Clemm, Ed. (Sympotech), C. Pignataro, Ed. (NC State University & Blue Fern Consulting)
  • Other authors: C. Westphal (University of California, Santa Cruz), L. Ciavaglia (Nokia), J. Tantsura (Nvidia), M-P. Odini
  • Category: Informational 🧚 (not a standards-track spec, just published for info)
  • ISSN: 2070-1721
  • Date: October 2025 🍓
  • Obsoletes / Updates: Not stated in this part of the document 🙈

The vibe of the whole thing is "networks are both the problem and part of the solution," and this is the intro bit. 🌸

Abstract ✨

Okay so reducing humankind's environmental footprint and making tech more sustainable are, like, some of the biggest challenges of our age, and networks are right in the middle of it 🌍. Networks can help shrink the footprint by enabling apps that do that, but they also contribute to the footprint themselves 😭. So the big question is: how do we make networking tech itself "greener" and run networks in ways that cut their environmental impact without making them less useful? 🤔 This doc lays out opportunities and research challenges for networking in general, and management tech in particular, to get greener, meaning more sustainable, with fewer greenhouse gas emissions and less harm to the planet. 💚

This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) 🔬. It reflects the consensus of the research group 🫶. It is not a candidate for any level of Internet Standard and is published for informational purposes 📚.

Status of This Memo ✨

Quick tea on the status 🍵: this is not an Internet Standards Track specification. It's published for info only 💖.

It's a product of the IRTF, which shares the results of Internet-related research and development. Those results might not be ready for deployment 🧪. This RFC represents the consensus of the NMRG within the IRTF 🫶. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 🎀.

For info about the current status of this doc, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9845 🦋.

Copyright (c) 2025 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. Please read these carefully, because they describe your rights and restrictions with respect to this document 📜🙈.

Table of Contents 🗺️

1.  Introduction
  1.1.  Motivation
  1.2.  Approaching the Problem
  1.3.  Structuring the Problem Space
2.  Definitions and Acronyms
3.  Network Energy Consumption Characteristics and Implications
4.  Challenges and Opportunities - Equipment Level
  4.1.  Hardware and Manufacturing
  4.2.  Visibility and Instrumentation
5.  Challenges and Opportunities - Protocol Level
  5.1.  Protocol Enablers for Carbon Optimization Mechanisms
  5.2.  Protocol Optimization
  5.3.  Data Volume Reduction
  5.4.  Network Addressing
6.  Challenges and Opportunities - Network Level
  6.1.  Network Optimization and Energy/Carbon/Pollution-Aware
        Networking
  6.2.  Assessing Carbon Footprint and Network-Level
        Instrumentation
  6.3.  Dimensioning and Peak Shaving
  6.4.  Convergence Schemes
  6.5.  The Role of Topology
7.  Challenges and Opportunities - Architecture Level
8.  Conclusions
9.  IANA Considerations
10. Security Considerations
11. Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🦋

1.1. Motivation 💅

Okay so climate change and the need to curb greenhouse gas (GHG) emissions have been recognized by the United Nations and most governments as one of the big challenges of our time 🌎. That means curbing those emissions is getting more and more important for society and for lots of industries, and the networking industry is totally included 🫶.

The science here is complex 🧠, but there's overwhelming scientific consensus pointing to a clear link between climate change and rising amounts of greenhouse gases in the atmosphere 🌡️. When we say "greenhouse gases" or GHG, we mean gases in Earth's atmosphere that trap heat and add to the greenhouse effect ☀️. They include carbon dioxide (CO2), methane (CH4), nitrous oxide (N2O), and fluorinated gases (as covered under the Kyoto Protocol and Paris Agreement) 🧪. For human-caused emissions, the dominant one is CO2 💨. CO2 gets released when fuels are burned to make energy, which is used to power things like networking equipment 🔌. Those fuels often include fossil fuels such as oil, which releases CO2 that had been locked away from the atmosphere for ages 🛢️. Renewable or sustainable fuels, on the other hand, don't "add" to the CO2 in the atmosphere 🌱. Other GHGs like CH4 and N2O are tied to electricity generation too, and even though they're emitted in smaller amounts, they have an even higher Global Warming Potential (GWP) 😳. To make accounting easier, they're all simply converted into CO2 equivalents (CO2e) 🧮.

Greenhouse gas emissions are linked to how much power technology needs, networks included ⚡. Cutting emissions can happen by using less fossil fuel to generate the energy those networks need 🌿. That can come from a cleaner energy mix with more low-carbon and/or renewable (and so sustainable) sources, like wind or solar 🌬️☀️. It can also come from saving energy and improving efficiency, so the same outcomes use less energy in the first place 💡.

The amount of greenhouse gases an activity adds to the atmosphere, like the CO2 emitted when burning fossil fuels to make the energy it needs, is called the "greenhouse footprint" or the "carbon footprint" (with non-CO2 gases counted in CO2 equivalents) 👣. Getting this footprint to net zero is a major sustainability goal 🎯. Sustainability is bigger than carbon though 🌍, and also covers other natural resources, preserving natural habitats and biodiversity, and avoiding all forms of pollution 🦋.

In this document, "green" means networking tech that helps improve its own sustainability 🌱. That includes tech that lowers networking's GHG emissions and carbon footprint, which in turn covers tech that boosts efficiency, realizes energy savings, and helps manage networks toward stronger use of renewables ⚡💚.

Honestly, networks already count as green tech in a big way 🙌. They let users and whole industries save energy and become more sustainable 🌷. For example, they let us (at least to an extent) swap travel for teleconferencing ✈️➡️💻. They let lots of employees work from home and telecommute, cutting down on commuting 🏡. IoT apps that automate monitoring and control from remote sites help make agriculture more sustainable by using less water, fertilizer, and land 🌾💧. Networked smart buildings can optimize energy better and use lighting and HVAC (heating, ventilation, air conditioning) more sparingly than their non-networked, not-so-smart counterparts 🏢✨. That said, calculating the precise net sustainability benefits and savings is complicated 😵‍💫, because a full picture involves substitution effects (you might save emissions from travel but add costs from extra home office use) and behavioral changes (like having more meetings than you would if travel were involved) 🙃.

The IETF recently started reflecting on the energy cost of hosting meetings three times a year (see [IETF-Net0]) 🌐. It studied the carbon emissions of a typical meeting and found that 99% of the emissions came from air travel ✈️😱. Similarly, [Framework] compared an in-person meeting with a virtual one and found a 66% energy reduction for the virtual meeting 💻✨. These findings show that networking tech can cut emissions when it acts as a virtual substitute for physical events 🥳.

That said, networks themselves use a lot of energy ⚡😬. So the networking industry has an important role in meeting sustainability goals, not just by helping others rely less on energy, but by reducing its own use too 💪. Future networking advances will increasingly need to focus on energy efficiency and cutting the carbon footprint, for reasons of both corporate responsibility and economics 💼. This shift has already started, and sustainability is becoming a big concern for network providers 🌟. In some cases, like networked data centers, being able to get enough energy becomes a bottleneck that blocks further growth, so greater sustainability becomes a business necessity 🚧.

For example, in its annual report, Telefónica says that in 2024, its network's energy consumption per petabyte (PB) of data was 38 megawatt-hours (MWh) [Telefonica2024] 📊. That's about a 90% improvement since the 2015 base year (400 MWh/PB) 🎉, thanks to steady year-on-year efficiency gains, although those are still partly offset by growth in data volume 📈. The same report highlights an important corporate goal: keep going on this trajectory and further cut overall greenhouse gas emissions 🌱💖.

1.2. Approaching the Problem 🌸

Okay so, one way networks can get greener is by using less energy to provide communication services, and by getting better at using power efficiently while they're actually running. But bestie, that's not the whole story. For a holistic approach we need to look at other stuff too 🫶

Your environmental footprint isn't just about how much energy you use. Where the power comes from matters too! A deployment with less energy-efficient devices that run on a sustainable energy source can arguably be greener than one with super efficient devices running on diesel generators 💀 The Telefónica report we mentioned earlier actually really emphasizes relying heavily on renewable energy sources 🌱

Other environmental factors affect the carbon footprint too 🧊 Deployments where the need for cooling is reduced, or where the excess heat from equipment gets put to good use, are considered greener than deployments where neither happens. For example, a deployment in cooler natural surroundings (like colder climates) is greener, if that's an option for you. Manufacturing and recycling networking equipment are also part of the sustainability equation, because production itself eats up energy and leaves a carbon cost baked into the device. Honestly, extending the life of equipment is often a better move than swapping it out early for something slightly more energy efficient, since that new gear would need its embedded carbon cost paid back over a much shorter period 😭

Network management has an outsized role here 👑 To cut energy use, network providers need to make the most of scarce resources and get rid of any resources that aren't strictly needed. They also need to optimize how networks get deployed, which resources go where, and how equipment lifecycles and upgrades are managed. Honestly, all of that is classic operational stuff. As best practices, methods, and algorithms get developed, they need to be automated as much as possible, moved into the network over time, and run on shorter and shorter timescales, transcending management and control planes ✨

1.3. Structuring the Problem Space 🧩

From a technical perspective, there are multiple vectors along which networks can get greener, and all of them are worth thinking about:

  • Equipment level:

Perhaps the most promising vector for improving networking sustainability is the network equipment itself 🔥 At the most basic level, networks (even softwarized ones) are built out of appliances, meaning gear that needs electrical power to do its job. There are two distinct layers with different opportunities for improvement:

  • Hardware: cutting embedded carbon during material extraction and manufacturing, getting more energy efficient and using less energy during operations, and increasing reuse, repurposing, and recycling.
  • Software: making software more energy efficient, maximizing how much processing devices get used, and letting software interact with hardware to boost sustainability.

Making appliances merely more energy efficient isn't the only glow-up available ✨ Equipment can also help networks get greener by supporting port power-saving modes, or by down-speeding links to cut power for resources that aren't fully used. To really tap into these features, you need management functionality to match. For example, you need to figure out when it's "safe" to down-speed a link or enter a power-saving mode, and then run the network so that those conditions show up as often as possible 🧚

Most importantly, from a management perspective, improving sustainability at the equipment level means providing management instrumentation that lets you precisely monitor and manage power usage, at different levels of granularity. For example, you could account separately for the contributions of the CPU, memory, and different ports 📊 This lets controller applications (for example) optimize energy usage across the whole network, and lets them use control loops to check how well the measures they've taken are working (e.g., in terms of reducing power use) 💅

As a side note, the terms "device" and "equipment", as used in this document, refer to networking equipment. End-user devices and endpoints like mobile phones or computing equipment are not in scope here 🙈

  • Protocol level:

Energy efficiency and "greenness" are rarely considered when designing network protocols, which means there's probably a lot of untapped potential 💜 Some aspects involve designing protocols that cut down on redundant or wasteful data transmission. That gives better network utilization and more goodput per unit of energy consumed. Techniques might include approaches that reduce the "header tax" payloads pay, as well as methods that reduce wasteful retransmissions 🍓 Protocols can also be chatty in ways that stop equipment from going into sleep mode. Designing protocols that reduce chattiness in those scenarios, for example by relying less on periodic updates or heartbeats, may lead to greener outcomes. Restructuring addresses can help too, by minimizing the size of lookup tables, the memory sizes tied to them, and therefore the energy use 🧠

Protocols also play a role in enabling management functionality that improves energy efficiency at the network level. Think discovery protocols that let the network quickly adapt when components are dynamically taken into or out of service depending on network conditions, and protocols that help collect energy telemetry data from the network 📡

  • Network level:

The biggest power-saving opportunities probably live at the level of the network as a whole 🌈 Lots of these are directly tied to management functionality. For example, optimizing energy efficiency may mean directing traffic so that equipment that isn't needed at certain moments can be isolated, powered down, or put into power-saving mode. By the same token, traffic should be directed so that additional equipment only gets brought online or out of power-saving mode when alternative traffic paths are available for which the incremental energy cost would be zero 🦋 Some networking devices may also have a lower sustainability rating, be less energy efficient, or be powered by less sustainable energy sources than others. Their use might be avoided except during periods of peak capacity demand. Generally, incremental carbon emissions can be treated as a cost metric that networks should work to minimize, and considered as part of routing and network path optimization 🌿

  • Architecture level:

The current network architecture supports a wide range of applications, but it doesn't treat energy efficiency as one of its design parameters 🏗️ One could argue that the most energy-efficient shift of the last two decades has been the deployment of Content Delivery Network overlays. Those were set up to reduce latency and minimize bandwidth consumption, but from a network perspective, retrieving content from a local cache is also much greener 🥹 So what other architectural shifts can reduce energy consumption?

In this document, we'll dig into each of those vectors in more detail and try to pin down specific challenges that could make a difference when addressed 🎀 As our starting point, we borrow some material from "Challenges and Opportunities in Green Networking" [GreenNet22]. For this document, that material has been both expanded (for example, in terms of some of the opportunities) and pruned (for example, in terms of background on prior scholarly work) 💖

This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). It reflects the consensus of the research group, and it was discussed and presented multiple times, each time getting positive feedback and no objections 🫶 It is not a candidate for any level of Internet Standard, and it's published for informational purposes.

2. Definitions and Acronyms 💜

Below you'll find the acronyms used in this document 📚

  • Carbon Footprint: As used in this document, the amount of carbon emissions associated with the use or deployment of technology, usually correlated with the amount of energy consumption
  • CDN: Content Delivery Network
  • CPU: Central Processing Unit (that is, the main processor in a server)
  • DC: Data Center
  • FCT: Flow Completion Time
  • GHG: Greenhouse Gas
  • GPU: Graphical Processing Unit
  • HVAC: Heating, Ventilation, Air Conditioning
  • ICN: Information-Centric Network
  • IGP: Interior Gateway Protocol
  • IoT: Internet of Things
  • LEED: Leadership in Energy and Environmental Design (a green building rating system)
  • LEO: Low Earth Orbit
  • LPM: Longest Prefix Match (a method to look up prefixes in a forwarding element)
  • MPLS: Multiprotocol Label Switching
  • MTU: Maximum Transmission Unit (the largest packet size that can be transmitted over a network)
  • NIC: Network Interface Card
  • QoE: Quality of Experience
  • QoS: Quality of Service
  • QUIC: the name of a UDP-based, stream-multiplexing, encrypted transport protocol [RFC9000]
  • SDN: Software-Defined Networking
  • TCP: Transport Control Protocol
  • TE: Traffic Engineering
  • TPU: Tensor Processing Unit
  • WAN: Wide Area Network

3. Network Energy Consumption Characteristics and Implications 🔋

okay so the carbon footprint (and the greenhouse gas emissions that come with it) is decided by several factors 🌍. a main one is network energy consumption, because the energy a network uses can be treated as a proxy for the fuel burned to generate that power ⚡. but energy alone doesn't tell the whole story, since it doesn't account for how sustainable the energy sources are or what the energy mix looks like 🤷‍♀️. there are other factors too, like the carbon cost of manufacturing networking hardware. still, network energy consumption is an excellent predictor of a carbon footprint and of how much that footprint can be reduced, and that reduction is key to sustainable solutions 💚. so exploring ways to improve energy efficiency is a key factor for greener, more sustainable, less carbon-intensive networks ✨.

it's important to understand how networks use power and which aspects contribute the most 🧠. this helps us spot where the greatest potential is, not just for power savings but also for sustainability wins 🎯.

power is ultimately drawn by devices, and devices aren't monoliths, they're made of multiple components 🧩. a device's power consumption can be split into the core device (the backplane and CPU, if you will) plus the extra consumption incurred per port and line card 🔌. the GPU and TPU may also be used in the network, and they may have different power consumption profiles 👀. and it's really important to know the difference between power use when a resource is idling and when it's under load 💤➡️🔥. this helps you see the incremental cost of additional transmission compared to the initial cost of transmission 💅.

in typical networking devices, only roughly half of the energy consumption is tied to the data plane [Bolla2011energy] 😳. an idle base system typically eats more than half the energy the same system would use at full load [Chabarek08] [Cervero15] 🍽️. generally, sending the first bit is super expensive, because you have to power up a device, port, etc. 🥵 the extra energy for each additional bit (beyond the first) is many orders of magnitude lower 📉. same energy vibe with the CPU and memory needed to process additional packets: the incremental cost becomes fairly negligible 🙌.

so a device's energy use doesn't climb in a straight line as forwarded traffic goes up 📈. it's more like a step function, where energy stays roughly the same up to a certain volume of traffic, and then BAM, there's a sudden jump when additional resources have to be procured to support a higher volume 🪜.

by the same logic, it's generally more energy efficient to send a large volume of data in one burst (and then turn off or down-speed the interface while it's idling) than to keep transmitting at a lower rate 🚀. so in that sense, it can be the duration of the transmission that dominates energy consumption, not the actual data rate ⏱️.

the implications for green networking from an energy-savings standpoint are significant 💜. of utmost importance are schemes that allow for "peak shaving": networks are typically dimensioned for periods of peak demand and usage, yet any excess capacity during periods of non-peak usage does not result in corresponding energy savings 😤. peak shaving techniques that reduce peak traffic spikes and waste during non-peak periods may result in outsize sustainability gains 🌱. peak shaving could be accomplished by techniques such as spreading spikes out over geographies (e.g., routing traffic across more costly but less utilized routes) or over time (e.g., postponing and buffering non-urgent traffic) 🗺️.

likewise, large gains can be made whenever network resources can effectively be taken offline for at least some of the time 🌙. that means managing networks so resources can be removed from service and powered down (or put into a more energy-saving state, such as when down-speeding ports) while they aren't needed. of course, any such methods need to account for the overhead of taking resources offline and bringing them back online 😵‍💫. this typically takes some amount of time, so it requires accurate predictive capabilities to avoid situations where network resources aren't available when they're needed 🔮. on top of that, there's additional overhead, such as synchronization of state, that has to be accounted for 🧾.

at the same time, any non-idle resources should be utilized to the greatest extent possible, since the incremental energy cost is negligible 💪. of course, this has to happen while still taking other operational goals into consideration, like protection against failures (allowing for readily available redundancy and spare capacity in case of failure) and load balancing (for increased operational robustness) 🛡️. data transmission needs tend to fluctuate wildly and arrive in bursts, so any optimization schemes need to be highly adaptable and allow control loops at very fast time scales ⚡🔁.

similarly, for applications where this is possible, it may be desirable to replace continuous traffic at low data rates with traffic sent in bursts at high data rates, in order to potentially maximize the time during which resources can be idled 🦋.

as a result, emphasis needs to be placed on technology that enables, for example, very efficient and rapid discovery, monitoring, and control of networking resources 🔍. this lets devices be dynamically taken offline or brought back online without extensive network-level state convergence, route recalculation, or other complex optimizations at the network level 🧚. to make these schemes work, rapid power cycle and initialization schemes should be supported at the device level 🔄. there may be some lessons to borrow here from IoT, which has long had to deal with power-constrained end devices that spend much of their time in power-saving states to conserve battery 🔋🫶.

4. Challenges and Opportunities - Equipment Level 🛠️

we're sorting the challenges and opportunities for improving sustainability at the network equipment level along these lines:

  • Hardware and manufacturing: related opportunities are arguably among the most obvious and perhaps "largest". however, solutions here lie largely outside the scope of networking researchers 🏭.
  • Visibility and instrumentation: instrumenting equipment to provide visibility into how it consumes energy is key to management solutions and control loops that facilitate optimization schemes 👀📊.

4.1. Hardware and Manufacturing

perhaps the most obvious opportunities to make networking technology more energy efficient exist at the equipment level 💖. after all, networking involves physical equipment to receive and transmit data 📡. making that equipment more power efficient, so it dissipates less heat, consumes less energy, and reduces the need for cooling, sourcing sustainable materials, and facilitating the recycling of equipment at the end of its lifecycle all contribute to greener networks ♻️. reducing the energy usage of transmission technology, from wireless (antennas) to optical (lasers), is a strategy that's unique to networking 🌈.

one critical aspect of the energy cost of networking is the cost to manufacture and deploy networking equipment 🧱. on top of that, even the development process comes with its own carbon footprint 🫠. this is outside the scope of this document: we only consider the energy cost of running the network during the operational part of the equipment's lifecycle 🙈. however, a holistic approach would include the embedded energy included in the networking equipment 🔋. as part of this, things like the impact of deploying new protocols on the rate of obsolescence of existing equipment should be considered 🧐. for instance, incremental approaches that don't require replacing equipment right away (or even that extend the lifetime of deployed equipment) would have a lower carbon footprint 🌸. this is one important benefit of technologies like Software-Defined Networking and network function virtualization, since they may allow support for new networking features through software updates without requiring hardware replacements 💻✨.

[Emergy] describes an attempt to compute not only the energy of running a network but also the energy embedded in manufacturing the equipment 🧮. this is denoted by "emergy", a portmanteau for embedded energy 💜. likewise, [Junkyard] describes an approach to recycling equipment and a proof of concept using old mobile phones recycled into a "junkyard" data center 📱🏚️.

one trade-off to consider at this level is choosing between a platform that can be hardware-optimized for energy efficiency and a platform that's versatile and can run multiple functions ⚖️. for instance, a switch could run on an efficient hardware platform, or it could run as a software module (container) over some multipurpose platform 🧩. the first is operationally more energy efficient, but it may have a higher embedded energy from a smaller scale, a less efficient production process, and a shorter shelf life once new functions need to be added to the platform 🥺💅.

4.2. Visibility and Instrumentation ✨

okay so, beyond the "first-order" stuff we just talked about in Section 4.1, network equipment is ALSO a huge deal for green networking at other levels 💅. The biggest thing is the equipment's ability to show the management and control planes how much energy it's currently using 🔌. That visibility powers control loops for energy optimization, so applications can get feedback on the energy impact of what they do. Think: setting up paths that need the least extra energy, or tracking energy-cost metrics so forwarding decisions get smarter 🧠✨. And if there's no real measurement of energy usage yet (until one is in place), the equipment could advertise some proxy for its power consumption instead 🎀. Some examples: a silver, gold, or platinum label like the LEED sustainability rating for buildings, or the Energy Star label on home appliances, or just describing the device type, like CPU vs. GPU vs. TPU processors, which all have different power profiles 🌈.

One prerequisite for all of this is proper instrumentation that can monitor current power consumption for whole networking devices, for line cards, and for individual ports 🔍. That instrumentation should also let you assess the energy efficiency and carbon footprint of the device as a whole 🌍. It would also be super useful to link power consumption to data rates and current traffic. For example, you'd see current energy use relative to interface speeds, plus the incremental energy that's expected for extra traffic. That helps control schemes "shave" power off existing services, or keep the extra power for new traffic as low as possible ⚡. Honestly, this is an area where the current state of the art is sorely lacking, and standardization is lagging behind 😭. As of today, standardized YANG data models [RFC7950] for network energy consumption that work alongside management and control protocols just haven't been defined yet. 💀

To fix that, efforts to define sets of green networking metrics [GREEN_METRICS] and YANG data models with objects that give visibility into power measurements (e.g., [POWER_YANG]) were underway in 2024 🙌. Once the metrics and data models are agreed on, they'll be the foundation for the next steps, starting with implementing them as part of management and control instrumentation 🛠️.

Instrumentation also has to account for virtualization, which adds layers of indirection when you're trying to figure out the actual energy usage 🧩. For example, virtualized networking functions might run on containers or virtual machines hosted on a CPU in a data center, instead of on a regular network appliance like a router or a switch. That gives very different power consumption characteristics 🏢. A data center CPU's power use could be more efficient and more proportional to its actual CPU load, which is a whole vibe 💜. Instrumentation needs to reflect all of this and make it possible to attribute power consumption correctly ✅.

Monitoring and visibility are only half the story, though. You also need control knobs to configure energy-saving policies 🎛️. Power-saving modes are already common in endpoints like mobile phones or notebook computers, but they're sorely lacking in networking equipment 😤.

Here's the summary of challenges and opportunities in this space that could set the stage for greener networking 🌸:

  • Basic equipment categorization as "energy efficient" (or not) as a first step to spot immediate potential improvements, kind of like the Energy Star program from the US's Environmental Protection Agency 🏷️.
  • Equipment instrumentation advances for better energy awareness, plus defining and standardizing granular management information 📊.
  • Virtualized energy and carbon metrics, and checking how well they work in solutions that optimize carbon footprints in virtualized environments (including SDN, network slicing, network function virtualization, etc.) ☁️.
  • Certification and compliance assessment methods that make sure green instrumentation can't be manipulated to give false and misleading data 🚫.
  • Methods that account for the energy mix of the power sources used to power equipment, so solutions can optimize the actual carbon footprint and minimize pollution beyond mere energy efficiency [Hossain2019] 🌱.

5. Challenges and Opportunities - Protocol Level 🦋

okay, there are several ways to improve network sustainability at the protocol level, and they can be sorted into categories 📚. The first and arguably most impactful category is protocols that enable carbon footprint optimization schemes at the network level, plus management aimed at those goals 🎯. Other categories cover protocols designed to optimize data transmission rates under energy considerations, protocols designed to reduce the volume of data being transmitted, and protocol aspects related to network addressing schemes 🗂️. Those categories might be less impactful, but even the areas with smaller gains are worth exploring 💖.

There's also a ton of work in IoT, which has had to deal with energy-constrained devices for a long time 🔋. A lot of that work was motivated not by sustainability but by practical stuff like battery life 🪫. Still, many of those aspects seem to apply to sustainability too, like reducing chattiness so IoT equipment can go into low-power mode 🤫. So there's an opportunity to extend IoT work to more generalized scenarios 🌈. Power-constrained protocols showing up in the wider Internet already happens regularly 👀. For instance, ARM-based chipsets that were first designed for energy efficiency in battery-operated mobile devices have been embraced in data centers on a similar trajectory 🚀.

5.1. Protocol Enablers for Carbon Optimization Mechanisms 🔌

As discussed in Section 6, energy-aware and pollution-aware schemes can help improve network sustainability, but they need awareness of related data 🧐. To make these schemes happen, protocols need to be able to discover which links are available and how energy-efficient they are 🔎. For instance, links may be turned off to save energy and turned back on based on the elasticity of demand 📉📈. Protocols should be devised to discover when this happens and to keep a dynamic view of the topology that keeps up with frequent updates from power cycling of network resources 🔄.

Protocols are also required to quickly converge onto an energy-efficient path once a new topology is created by turning links on or off ⚡. Current routing protocols may provide fast recovery when there's a failure 🛟. But failures are hopefully relatively rare events, while we expect an energy-efficient network to aggressively try to turn off links 😅. There may be synergies with Time-Variant Routing [TVR_REQS] that can be explored, where the topology varies over time with nodes and links turned on or off according to a schedule 🗓️. There may also be overlaps in use cases, for example when regular changes in the energy mix (and so the carbon footprint) of some nodes line up with the time of day, like switching from solar to fossil fuels at night 🌙☀️.

Some mechanism is needed to give the management layer a view of the network that identifies opportunities to turn off resources (e.g., routers or links) while still providing an acceptable level of Quality of Experience (QoE) to users 💅. This gets way more complex as QoE shifts from the current best-effort delivery model to more sophisticated mechanisms with, for instance, latency, bandwidth, or reliability guarantees 📶.

Similarly, schemes might be devised in which links across paths with a favorable energy mix are preferred over other paths 🍃. This implies that topology discovery should be able to support corresponding parameters 🧩. More generally, any mechanism that gives applications network visibility is a candidate for scrutiny as to whether it should be extended to support sustainability-related parameters 🔍✨.

Here's the summary for this space 🌸:

  • Protocol advances to enable rapidly taking down, bringing back online, and discovering the availability and power-saving status of networking resources, while minimizing the need for reconvergence and propagation of state 🔁.
  • An assessment of which protocols could be extended with energy- and sustainability-related parameters in ways that would enable greener networking solutions, and an exploration of those solutions 🧪.

5.2. Protocol Optimization 🎀

The second category is about designing protocols so the rate of transmission is chosen to maximize energy efficiency 🏃‍♀️. For example, Traffic Engineering (TE) can be manipulated to impact the rate adaptation mechanism [Ren2018jordan] 🤯. By choosing where traffic is sent, TE can artificially congest links to trigger rate adaptation, which reduces the total amount of traffic 🪄. Most TE systems try to minimize Maximum Link Utilization, but energy-saving mechanisms could decide to do the opposite (i.e., maximize Minimum Link Utilization) and try to turn off some resources to save power 🔌🌿.

Another example is setting the right transmission rate to minimize flow completion time (FCT), so there are more chances to turn off links ⏱️. In a wireless context, [TradeOff] studies how setting the proper initial value for the congestion window can reduce the FCT, which lets the equipment go into a low-energy mode faster 💨. Sending data faster can significantly cut the energy cost 💰. This is a simple proof of concept, but protocols that let links drop into low-power mode by transmitting data over shorter periods could be designed for other types of networks beyond Wi-Fi access 📡. That should be done carefully, though 🙈. A sudden, very high transmission rate over a short period may create bursts the network has to accommodate, with all the attendant complications of bursty traffic 💥. We conjecture there's a sweet spot between trying to complete flows faster and controlling for burstiness in the network 🎯. It's probably wise to send traffic paced yet in bulk, rather than spread out over multiple round trips 🧃. This is an area of worthwhile exploration 🔭.

Here's the summary for this space 💜:

  • Protocol advances that allow greater control over traffic pacing to account for fluctuations in carbon cost, i.e., control knobs to "bulk up" transmission over short periods or to smooth it out over longer periods 🎚️.
  • Protocol advances for optimizing link utilization according to different goals and strategies (including maximizing Minimal Link Utilization vs. minimizing Maximal Link Utilization, etc.) 📈.
  • Assessments of the carbon impact of such strategies 🌍.

5.3. Data Volume Reduction 💅

Okay so the third category is all about designing protocols so they send less data for any given job 🧠. Loosely speaking, if you shrink the volume, the same networking gear can carry more traffic, which means less overall energy burned 🔋✨. One idea is protocols that avoid unnecessary retransmissions 🙈. At the application layer, protocols might also use coding mechanisms that encode information close to the Shannon limit [Shannon]. Now, video streaming is basically most of the Internet's traffic right now 🍿, and video encoders are already super efficient and keep getting better 📈. That's a win for energy, even though it's partly cancelled out by everyone wanting higher resolution 😭. It's not totally clear that the extra work to squeeze the payloads harder is a net energy gain, because what you save on the network could get eaten up by the effort of compressing and decompressing 🤔. More research on this is needed, bestie 📚.

At the transport layer, TCP and, to some extent, QUIC handle congestion by dropping packets 📦💀. This is an extremely energy-inefficient way to signal congestion, for two reasons: (a) the network has to wait one RTT before it even knows the congestion happened, and (b) all the effort it took to send that packet from the source up until it got dropped ends up wasted 🗑️. So the vibe is that we need new transport protocols that react to congestion without dropping packets 🙅‍♀️. ECN [RFC3168] is a possible solution, but it is not widely deployed yet 😤. DCTCP [Alizadeh2010DCTCP] is tuned for data centers 🏢, and Low Latency, Low Loss, and Scalable Throughput (L4S) is an attempt to bring similar functionality to the Internet [RFC9330] 🌐. Qualitative Communication [QUAL] [Westphal2021qualitative] lets nodes react to congestion by dropping only some of the data in a packet, so the resources already spent on that packet are only partially wasted 🦋. Novel transport protocols for the WAN can make sure no energy gets wasted sending packets that are going to be dropped eventually anyway 🫶.

Another way to cut the bandwidth of network protocols is to reduce their header tax, for example by applying header compression 🎀. An example from the IETF is RObust Header Compression (ROHC) [RFC3095]. Again, shrinking protocol headers saves energy when forwarding packets, but it comes at a cost: you have to maintain state for compression and decompression, plus do the computation for those operations 🧮. How much you gain also depends on the application and on whether it sends (a) large payloads close to the MTU, which limits the header tax and therefore the savings, or (b) very small payloads, which makes the header tax bigger and the savings bigger too 🌸.

Instead of reducing the amount of protocol data, you can also design routing protocols that are more efficient for each node to process 🧚. For instance, path-based forwarding and labels such as MPLS [RFC3031] make the next-hop lookup easier, which reduces energy consumption ⚡. It's unclear whether keeping some state at the router to speed up lookups is more energy efficient than "no state + lookup", which is more computationally intensive 🤷‍♀️. Other ways to speed up a next-hop lookup include geographic routing (e.g., [Herzen2011PIE]) 🗺️. Some network protocols could also be designed to reduce the next-hop lookup computation at a router 💜. It's unclear whether Longest Prefix Match (LPM) is energy efficient or a significant energy burden for router operation 👀.

Beyond the volume of data itself, you also have to think about the number of messages and how chatty the protocol is 💬. Some protocols rely on frequent periodic updates or heartbeats, and those can stop equipment from going into sleep mode 😴. In those cases, it makes sense to explore feasible alternatives that use different communication patterns and fewer messages 🌈.

The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking 🌿:

  • Assessments of energy-related trade-offs in the protocol design space, such as maintaining state versus using more compact encodings, or extra computation for transcoding operations versus larger data volume 🧐.
  • Protocol advances that improve the ratio of goodput to throughput and reduce waste 📈. This includes things like coding improvements, reductions in header tax, lower protocol verbosity, and a reduced need for retransmissions 🔥.
  • Protocols that let you manage transmission patterns in ways that make periods of link inactivity possible, such as burstiness and chattiness 🦋.

5.4. Network Addressing 🏡

Network addressing is another way to shave energy off networks 💡. Address tables can get huge, which leads to big forwarding tables that need a lot of memory 🧱. On top of that, there's a ton of state that has to be maintained and kept in sync 🔄. Memory, plus the processing needed to maintain and synchronize state, both use energy ⚡. So exploring ways to reduce the memory and state synchronization required gives us room to cut energy use 🌟. At the protocol level, rethinking how addresses are structured can allow flexible addressing schemes that work well in network deployments that are less energy-intensive by design 🫧. This can be paired with clever address allocation schemes that minimize the number of forwarding entries needed in deployments 🧩.

Alternatively, addressing could be designed to allow for more efficient processing than LPM 🙌. For instance, geographic addressing, where the next hop is computed as a simple distance calculation based on the positions of the current node, its neighbors, and the destination [Herzen2011PIE], could potentially be more energy efficient 🌍.

The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking 🌱:

  • Devise methods to assess the magnitude of the carbon footprint associated with addressing schemes 👣.
  • Devise methods to improve addressing schemes, as well as address assignment schemes, to minimize their footprint 🍃.

6. Challenges and Opportunities - Network Level 🌐

6.1. Network Optimization and Energy/Carbon/Pollution-Aware Networking 🌍💖

Networks have been optimized for many years under many criteria, like maximizing network utilization and minimizing cost 📊. So it's pretty straightforward to add optimization for greenness (including energy efficiency, power consumption, and carbon footprint) as an important criterion 💚.

This includes assessing the carbon footprints of paths and optimizing those paths so the overall footprint is minimized, and then using techniques like path-aware networking or segment routing [RFC8402] to steer traffic along those paths 🛣️. (As mentioned earlier, other proxy measures could be used for carbon footprint, such as energy-efficiency ratings of the equipment traversed 🔌.) It also includes things like considering the incremental carbon footprint in routing decisions 🧾. Optimizing cost has been a focus in networking for ages, and lots of existing mechanisms can be reused for greener networking just by adding carbon footprint as a cost factor 💅. The low-hanging fruit is adding carbon-related parameters as a cost parameter in control planes, whether distributed (e.g., IGP) or conceptually centralized via SDN controllers 🍒. There are also opportunities to smartly place functionality in the network for optimal effectiveness 🧠. One example is placing virtualized network functions in carbon-optimized ways. For example, virtualized network functions can be cohosted on fewer servers to achieve higher server utilization, which is more effective from an energy and carbon perspective than running more servers at lower utilization 🖥️. They can also be placed close to each other to avoid unnecessary overhead in long-distance control traffic 📍.

Other opportunities involve adding carbon awareness to dynamic path selection schemes ✨. This is sometimes called "energy-aware networking" (or "pollution-aware networking" [Hossain2019], or "carbon-aware networking" when parameters beyond simply energy consumption are taken into account) 🏷️. Again, considerable energy savings can potentially be realized by taking resources offline, for example by putting them into power-saving or hibernation mode, when they aren't needed under current network demand and load conditions 😴. So weaning resources off traffic is an important consideration for energy-efficient traffic steering 🍼. This approach contrasts with, and in fact conflicts with, existing schemes that typically aim to create redundancy and load-balance traffic across a network, to achieve even resource utilization across larger numbers of resources as a way to increase resilience, optimize service levels, and ensure fairness ⚖️. A big challenge, then, is how resource-weaning schemes that realize energy savings can be accommodated without cannibalizing other important goals, counteracting other established mechanisms, or destabilizing the network 😱.

An opportunity may lie in making a distinction between "energy modes" of different domains 🗂️. For instance, in a highly trafficked core, the energy challenge is to transmit traffic efficiently 🚀. The amount of traffic is relatively fluid (because multiple sessions are multiplexed) and the traffic is predictable, so there's no need to optimize on a per-session basis or on a short timescale 🕰️. In the access networks connecting to that core, though, there are chances for this fast convergence: traffic is much burstier and less predictable, so the network should be able to be more reactive ⚡. Other domains, such as DCs, may have more variable workloads and different traffic patterns 🎢.

The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking 💫:

  • Devise methods for carbon-aware traffic steering and routing, treating carbon footprint as a traffic cost metric to optimize 🗺️.
  • Apply Machine Learning (ML) and AI methods to optimize networks for carbon footprint, and assess the applicability of game theoretic approaches 🤖.
  • Articulate and, where applicable, moderate the trade-offs between carbon awareness and other operational goals such as robustness and redundancy ⚖️.
  • Extend control plane protocols with carbon-related parameters 🧩.
  • Consider the security issues imposed by greater energy awareness, to minimize the new attack surfaces that would let an adversary turn off resources or waste energy 🚨💀.

6.2. Assessing Carbon Footprint and Network-Level Instrumentation ✨

Okay so, if we want to grab all those yummy opportunities from Section 6.1 💅, we first need good abstractions (and the matching instrumentation 🔍) for easily assessing energy cost and carbon footprint. bestie, these have to account for more than just the energy cost of forwarding packets along a given path. They also need the cost of processing, memory, and maintaining state, so we get the full holistic picture 🌸

In a lot of cases, optimizing carbon footprint comes with trade-offs that involve way more than packet forwarding 🧚 Think keeping state, caching data, or running computations at the edge instead of somewhere else. (Side note: there can be a differential between running a computation at an edge server and at a hyperscale DC, because the latter is often better optimized than the former 🙈.) Carbon footprint is also about more than energy-intensity 🌈 For instance, some network segments may be powered by more sustainable energy sources than others, and some network equipment may be more environmentally friendly to build, deploy, and recycle. All of that can be reflected in the abstractions we consider 💜

Assessing carbon footprint at the network level takes instrumentation that ties the footprint not just to individual devices (as outlined in Section 4.2) but also to concepts that matter at the network level, i.e., to flows and to paths 🦋 For example, it would be super useful to see the carbon intensity of a path. Can the carbon cost of traffic sent over the path be aggregated? Does the path include outliers, i.e., segments with equipment that has a particularly large carbon footprint? 👀

Then there's the question of how to assess the carbon cost of a flow 🎀 That's useful for way more than network optimization. It opens the door to green billing and charging schemes that account for the amount of carbon-equivalent emissions attributed to particular users' use of communication services, and it can help raise carbon awareness among end users too 🫶

Here's a summary of some challenges and opportunities in this space that can provide the basis for advances in greener networking 💖

  • Devise methods to assess, estimate, and predict the carbon intensity of paths.
  • Devise methods to account for the carbon footprint of flows and networking services.

6.3. Dimensioning and Peak Shaving ⭐

As mentioned in Section 3, the overall energy usage of a network is mostly decided by how the network is dimensioned 📐 Specifically, which and how many pieces of network equipment are deployed and turned on. A big chunk of energy gets drawn even when things are just sitting in an idle state 😴 So minimizing the amount of equipment that needs to be turned on in the first place is one of the biggest energy-saving opportunities out there 🔥

Network deployments are usually dimensioned for periods of peak traffic, which leaves excess capacity during non-peak usage that still burns power 💀 Shaving peak usage can therefore lead to outsized sustainability gains. It cuts energy usage during peak traffic but, even more importantly, cuts the waste during non-peak periods 🌿

Traffic volume is mostly driven by demand, and network providers don't have a ton of say over that 🙃 Still, some peak shaving can be done with techniques like spreading spikes out over geographies (e.g., redirecting some traffic across more costly but less utilized routes, especially when traffic spikes are more local or regional in nature) or over time (e.g., postponing non-urgent traffic, or storing or buffering things using edge clouds or extra storage where that's feasible) 🌙

To make these techniques work, accurate learning and prediction of traffic patterns are needed 🔮 That includes the ability to forecast, so additional resources can be spun up in time if they're needed. Honestly, this is a seriously interesting challenge, but it's also a chance for technical advances to make a real difference 🚀

Here's a summary of some challenges and opportunities in this space that can provide the basis for advances in greener networking 💖

  • Support methods for monitoring and forecasting traffic demand, involving new mechanisms and/or performance improvements of existing mechanisms to support the collection of telemetry and generation of traffic matrices at very high velocity and scale.
  • Additional methods for distributing traffic load evenly across the network, i.e., load balancing on a network scale, and enablement of those methods through control protocol extensions as needed.

6.4. Convergence Schemes 🔄

One set of challenges with carbon-aware networking is that many schemes make the network way more dynamic and constantly changing 🌪️ Resources may be steered away from (when possible) and then leveraged again (when necessary) in rapid succession. That puts serious stress on convergence schemes, which can make solutions hard to scale and can make them too slow to keep up. Network-wide convergence is expensive and comes with significant delay, so it just can't keep up with schemes like these 😩 To work around this, mechanisms should be investigated that don't require convergence beyond the vicinity of the affected network device 🧘 The impact of churn needs to be minimized, especially where central network controllers are involved (the ones responsible for configuring paths and positioning network functions, aiming for global optimization) 👑 That means, for example, discovery, rediscovery, and update schemes need to be simplified, and heavy recalculation (e.g., of routes and paths based on the current energy state of the network) needs to be avoided 🙅‍♀️

Here's a summary of some challenges and opportunities in this space that can provide the basis for advances in greener networking 💖

  • Protocols that facilitate rapid convergence (per Section 5.1).
  • Investigate methods that mitigate effects of churn, including methods that maintain memory or state as well as methods relying on prediction, inference, and interpolation.

6.5. The Role of Topology 🗺️

One of the most important network management constructs is the network topology 🧩 A network topology can usually be represented as a database or as a mathematical graph, with vertices or nodes (representing networking nodes), and edges or links (connecting their interfaces), along with all their characteristics. Examples of these topology representations include routing protocols' link-state databases (LSDBs) and service function chaining graphs 🦋

As part of adding carbon and energy awareness into networks, it's useful for topology information to also provide visibility into sustainability data 🌱 That kind of capability can help assess how sustainable the network is overall, and it can enable automated applications to improve it 🤖

Here's a summary of some challenges and opportunities in this space that can provide the basis for advances in greener networking 💖

  • Embedding carbon and energy awareness into the representation of topologies, whether considering IGP LSDBs and their advertisements, BGP-LS (BGP Link-State), or metadata for the rendering of service function paths in a service chain.
  • Use of those carbon-aware attributes to optimize topology as a whole under end-to-end energy and carbon considerations.

7. Challenges and Opportunities - Architecture Level ✨

Okay bestie, let's talk architecture 🏗️🧚. Another way to make networks more energy efficient is to organize them so that important applications can use less energy in the first place. 💖 That means helping people retrieve content, or do computation, in ways that cut down how much communication is needed at all. Even if the network saves energy, that could be partly cancelled out by extra energy spent somewhere else. Still, the examples below suggest it's worth rethinking how networks are architected if the goal is a smaller carbon footprint 🌱✨.

Content Delivery Networks (CDNs) are a great example 🎀. They've cut the Internet's energy use by downloading content close to users. The content only travels over the WAN a few times, and then it's served locally. So the energy use shifts from networking to storage 💾. Even more savings are possible with further methods [Bianco2016energy] [Mathew2011energy] [Islam2012evaluating]. Whether the overall savings are net positive depends on the actual deployment 🤔. From the network operator's point of view, though, at least the energy bill moves away from the network and over to the CDN operator 💅.

CDNs run as an overlay. Another architecture has been proposed to provide CDN features directly inside the network, called Information-Centric Networks [Ahlgren2012survey] 🌸. The IRTF's ICNRG also studies them. But this shifts the energy consumption back onto the network operator, and it needs some power-hungry hardware, like chips for larger name lookups and memory for the in-network cache 🔥. So it's honestly unclear whether there's a real energy gain from delivering content through in-network caches 😬.

Fog computing and putting intelligence at the edge are other architectural directions for reducing energy spent on packet forwarding and inside the network 🦋. Here the trade-off is between two options. Option (a) is doing computational tasks in an energy-optimized data center at very large scale. That needs a lot of data to be sent across many nodes and long distances 🌍. Option (b) is doing them at the edge. There the energy may not be used as efficiently, because resources are multiplexed less and smaller sites are inherently less efficient due to their smaller scale 📉. But the amount of long-distance traffic, and the energy the network needs for it, drops a lot 💜. Softwarization, containers, and microservices directly enable these architectures 🧩. Programmable network infrastructure will help them happen too, like Infrastructure Processing Units (IPUs) or Smart NICs that offload some computation from the CPU onto the NIC 🚀. Just keep in mind that CPUs and NPUs have different power consumption characteristics, so that's another thing to consider alongside virtualization 👀.

Other possibilities involve economic aspects, like giving users of networking services incentives to minimize energy consumption and emission impact 💰. [Wolf2014choicenet] gives an example that could be expanded to include energy incentives 🍓.

Some approaches look at late binding of the data and the functions performed on it [Krol2017NFaaS] 🧠. The IRTF's COINRG focuses on similar issues 🌈. Optimizing the total energy cost, counting both networking and computing (including the different energy costs of computing in a hyperscale DC versus at an edge node), is still an open research area 🔬.

In summary, rethinking the overall network, and the networked application architecture, could significantly cut the energy cost at the network layer 💚. One example is doing tasks that involve massive communication closer to the user 🫶. Whether these shifts actually reduce the carbon footprint overall is a big question that needs case-by-case analysis 🧐.

Here are some challenges and opportunities in this space that could set the stage for greener networking ⭐:

  • Investigate how networking architecture should be organized for important classes of applications, such as content delivery, the best placement of computational intelligence and network functionality within the network design, industrial operations and control, and massively distributed ML and AI. The goal is to optimize overall sustainability and take holistic approaches that trade off carbon footprint between forwarding, storage, and computation 🏭🤖.
  • Build models to assess and compare alternatives for providing networked services, for example by evaluating carbon impact based on where computation happens, what information gets cached, and what communication exchanges take place 📊💅.

8. Conclusions 🎓

Making networks greener and reducing their carbon footprint is a big problem for the networking industry to tackle, for both societal and economic reasons 🌏💖. This document has highlighted a number of the technical challenges and opportunities there 🦋.

Of those, perhaps the key challenge to tackle right away is being able to expose the energy impact of any networking action at a fine granularity 🔍⚡. Visibility into this will enable many approaches to a solution 👑. It will be key for optimization through control loops that can assess the energy impact of a decision once it's been taken 🔁. It will also help answer questions like these (and more) 🙈:

  • Is caching, with its associated storage, better than retransmitting from a different server, with its associated networking cost? 🤷‍♀️
  • Is compression more energy efficient once you factor in the computation cost of compression versus transmitting uncompressed data? And which compression scheme is more energy efficient? 🗜️
  • Is the energy saved by computing at an efficient hyperscale DC offset by the networking cost of reaching that DC? 🏢
  • Is the overhead of gathering and transmitting fine-grained energy telemetry data offset by the total energy gain from the better decisions this data enables? 📡
  • Is the energy cost of transmitting data to a Low Earth Orbit (LEO) satellite constellation offset by the fact that the constellation, and any networking within it, is powered by solar energy? ☀️🛰️
  • Is the energy cost of sending rockets to place routers in LEO amortized over time? 🚀

Figuring out where the sweet spots are, and optimizing networks along those lines, will be key to making networks greener 💚. We expect to see significant advances across these areas 🌸, and we believe researchers, developers, and operators of networking technology have an important role to play 🫶✨.

9. IANA Considerations 📋

This document has no IANA actions. 🙌

10. Security Considerations 🔐

Okay, this part is important 😭. Security might look like it has nothing to do with green networking 🙈, but there are a number of important caveats 🚨.

Security vulnerabilities in networks can show up as compromised energy efficiency ⚠️. For example, attackers could try to increase energy consumption so that attack victims' energy bills go up 💸. Specific vulnerabilities depend on the particular mechanisms involved 🧩. For instance, if you're monitoring energy consumption data, tampering with that data could compromise energy optimization control loops 🔄. So any mechanisms that instrument and monitor the network for this kind of data need to be properly secured to ensure authenticity 🔒💖.

There are also inherent trade-offs between security and the maximal energy efficiency that could otherwise be achieved 🤏. Encryption is one example. It needs extra computation for encryption and decryption and for security handshakes 🧮. It also means sending more traffic than the entropy of the actual data stream would require 📦. Mechanisms that let you turn resources on or off could also become a target for attackers 🎯.

Energy consumption can be used to create covert channels, which is a security risk for information leakage 🕵️‍♀️💀. For instance, the temperature of an element can be used to create a Thermal Covert Channel [TCC] 🌡️. Reading or sharing measured energy consumption can also be abused to create a covert channel, see for instance [DRAM] or [NewClass] 🧠. Power information may be used to create side-channel attacks 🕳️. For instance, [SideChannel] reviews 20 years of study on this topic 📚. Any new parameters considered in protocol designs or in measurements could create such covert or side channels, and this needs to be taken into account when designing energy-efficient protocols 🛡️🌈.

11. Informative References 📚

Here are the informative references, served fresh 🍓:

   [Ahlgren2012survey]
              Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
              and B. Ohlman, "A survey of information-centric
              networking", IEEE Communications Magazine, vol. 50, no. 7,
              pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012,
              <https://doi.org/10.1109/MCOM.2012.6231276>.

   [Alizadeh2010DCTCP]
              Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
              P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data
              Center TCP (DCTCP)", ACM SIGCOMM Computer Communication
              Review, vol. 40, no. 4, pp. 63-74,
              DOI 10.1145/1851275.1851192, 2010,
              <https://doi.org/10.1145/1851275.1851192>.

   [Bianco2016energy]
              Bianco, A., Mashayekhi, R., and M. Meo, "Energy
              consumption for data distribution in content delivery
              networks", IEEE International Conference on Communications
              (ICC), pp. 1-6, DOI 10.1109/ICC.2016.7511356, 2016,
              <https://doi.org/10.1109/ICC.2016.7511356>.

   [Bolla2011energy]
              Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti,
              "Energy Efficiency in the Future Internet: A Survey of
              Existing Approaches and Trends in Energy-Aware Fixed
              Network Infrastructures", IEEE Communications Surveys and
              Tutorials, vol. 13, no. 2, pp. 223-244,
              DOI 10.1109/SURV.2011.071410.00073, 2011,
              <https://doi.org/10.1109/SURV.2011.071410.00073>.

   [Cervero15]
              Cervero, A. G., Chincoli, M., Dittmann, L., Fischer, A.,
              Garcia, A., Galán-Jiménez, J., Lefevre, L., Meer, H. D.,
              Monteil, T., Monti, P., Orgerie, A., Pau, L., Phillips,
              C., Ricciardi, S., Sharrock, R., Stolf, P., Trinh, T., and
              L. Valcarenghi, "Green Wired Networks", Large-Scale
              Distributed Systems and Energy Efficiency, pp. 41-80,
              DOI 10.1002/9781118981122.ch3, 2015,
              <https://doi.org/10.1002/9781118981122.ch3>.

   [Chabarek08]
              Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang,
              D., and S. Wright, "Power Awareness in Network Design and
              Routing", IEEE INFOCOM 2008 - The 27th Conference on
              Computer Communications, pp. 457-465,
              DOI 10.1109/INFOCOM.2008.93, 2008,
              <https://doi.org/10.1109/INFOCOM.2008.93>.

[DRAM] Paiva, T. B., Navaridas, J., and R. Terada, "Robust Covert Channels Based on DRAM Power Consumption", Information Security, ISC 2019, Lecture Notes in Computer Science, vol 11723, DOI 10.1007/978-3-030-30215-3_16, 2019, https://doi.org/10.1007/978-3-030-30215-3_16.

[Emergy] Raghavan, B. and J. Ma, "The Energy and Emergy of the Internet", Proceedings of the 10th ACM Workshop on Hot Topics in Networks, no. 9, pp. 1-6, DOI 10.1145/2070562.2070571, 2011, https://doi.org/10.1145/2070562.2070571.

[Framework] Faber, G., "A framework to estimate emissions from virtual conferences", International Journal of Environmental Studies, vol. 78, no. 4, pp. 608-623, DOI 10.1080/00207233.2020.1864190, 2021, https://doi.org/10.1080/00207233.2020.1864190.

[GreenNet22] Clemm, A. and C. Westphal, "Challenges and Opportunities in Green Networking", 1st International Workshop on Network Energy Efficiency in the Softwarization Era, IEEE NetSoft 2022, DOI 10.1109/NetSoft54395.2022.9844020, June 2022, https://doi.org/10.1109/NetSoft54395.2022.9844020.

[GREEN_METRICS] Clemm, A., Ed., Pignataro, C., Ed., Schooler, E., Ciavaglia, L., Rezaki, A., Mirsky, G., and J. Tantsura, "Green Networking Metrics for Environmentally Sustainable Networking", Work in Progress, Internet-Draft, draft-cx-green-green-metrics-00, 21 October 2024, https://datatracker.ietf.org/doc/html/draft-cx-green-green-metrics-00.

[Herzen2011PIE] Herzen, J., Westphal, C., and P. Thiran, "Scalable routing easy as PIE: A practical isometric embedding protocol", 19th IEEE International Conference on Network Protocols (ICNP), pp. 49-58, DOI 10.1109/ICNP.2011.6089081, 2011, https://doi.org/10.1109/ICNP.2011.6089081.

[Hossain2019] Hossain, M., Georges, J., Rondeau, E., and T. Divoux, "Energy, Carbon and Renewable Energy: Candidate Metrics for Green-Aware Routing?", Sensors, vol. 19, no. 3, DOI 10.3390/s19132901, June 2019, https://hal.science/hal-02169758/.

[IETF-Net0] Daley, J., "Towards a net zero IETF", IETF News, 6 May 2022, https://www.ietf.org/blog/towards-a-net-zero-ietf/.

[Islam2012evaluating] Islam, S. U. and J. Pierson, "Evaluating Energy Consumption in CDN Servers", Proceedings of the Second International Conference on ICT as Key Technology against Global Warming, Lecture Notes in Computer Science, vol 7453, pp. 64-78, DOI 10.1007/978-3-642-32606-6_6, 2012, https://doi.org/10.1007/978-3-642-32606-6_6.

[Junkyard] Switzer, J., Kastner, R., and P. Pannuto, "Architecture of a Junkyard Datacenter", DOI 10.48550/arXiv.2110.06870, arXiv: 2110.06870v1, 2021, https://arxiv.org/abs/2110.06870v1.

[Krol2017NFaaS] Krol, M. and I. Psaras, "NFaaS: Named Function as a Service", ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking, pp. 134-144, DOI 10.1145/3125719.3125727, 2017, https://doi.org/10.1145/3125719.3125727.

[Mathew2011energy] Mathew, V., Sitaraman, R., and P. Shenoy, "Energy-Aware Load Balancing in Content Delivery Networks", DOI 10.48550/arXiv.1109.5641, arXiv: 1109.5641v1, 2011, https://arxiv.org/abs/1109.5641.

[NewClass] Khatamifard, S. K., Wang, L., Kose, S., and U. R. Karpuzcu, "A New Class of Covert Channels Exploiting Power Management Vulnerabilities", IEEE Computer Architecture Letters, vol. 15, no. 2, pp. 201-204, DOI 10.1109/LCA.2018.2860006, 2018, https://doi.org/10.1109/LCA.2018.2860006.

[POWER_YANG] Li, T. and R. Bonica, "A YANG model for Power Management", Work in Progress, Internet-Draft, draft-li-green-power-00, 17 October 2024, https://datatracker.ietf.org/doc/html/draft-li-green-power-00.

[QUAL] Li, R., Makhijani, K., Yousefi, H., Westphal, C., Xong, L., Wauters, T., and F. D. Turck, "A Framework for Qualitative Communications using Big Packet Protocol", NEAT'19: Proceedings of the ACM Sigcomm Workshop On Networking For Emerging Applications And Technologies, pp. 22-28, DOI 10.1145/3341558.3342201, 2019, https://doi.org/10.1145/3341558.3342201.

[Ren2018jordan] Ren, J., Lu, K., Westphal, C., Wang, J., Wang, J., Song, T., Liu, S., and J. Wang, "JORDAN: A Novel Traffic Engineering Algorithm for Dynamic Adaptive Streaming over HTTP", 2018 International Conference on Computing, Networking and Communications (ICNC), pp. 581-587, DOI 10.1109/ICCNC.2018.8390337, 2018, https://doi.org/10.1109/ICCNC.2018.8390337.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, https://www.rfc-editor.org/info/rfc3031.

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, https://www.rfc-editor.org/info/rfc3095.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, https://www.rfc-editor.org/info/rfc3168.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, https://www.rfc-editor.org/info/rfc7950.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, https://www.rfc-editor.org/info/rfc8402.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, https://www.rfc-editor.org/info/rfc9330.

[Shannon] Shannon, C. E., "A Mathematical Theory of Communication", The Bell System Technical Journal, vol. 27, no. 3, pp. 379-423, DOI 10.1002/j.1538-7305.1948.tb01338.x, July 1948, https://doi.org/10.1002/j.1538-7305.1948.tb01338.x.

[SideChannel] Randolph, M. and W. Diehl, "Power Side-Channel Attack Analysis: A Review of 20 Years of Study for the Layman", Cryptography, vol. 4, no. 2, DOI 10.3390/cryptography4020015, 2020, https://doi.org/10.3390/cryptography4020015.

[TCC] Rahimi, P., Singh, A. K., and X. Wang, "Selective Noise Based Power-Efficient and Effective Countermeasure Against Thermal Covert Channel Attacks in Multi-Core Systems", Journal on Low Power Electronics and Applications, vol. 12, no. 2, DOI 10.3390/jlpea12020025, 2022, https://doi.org/10.3390/jlpea12020025.

[Telefonica2024] Telefonica, "Telefonica Consolidated Annual Report 2024", 2025, https://www.telefonica.com/en/wp-content/uploads/sites/5/2025/02/Consolidated-Annual-Accounts-2024.pdf.

[TradeOff] Welzl, M., "Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective Internet Congestion Control", 2022 17th Wireless On-Demand Network Systems and Services Conference (WONS), pp. 1-4, DOI 10.23919/WONS54113.2022.9764413, 2022, https://doi.org/10.23919/WONS54113.2022.9764413.

[TVR_REQS] King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR (Time-Variant Routing) Requirements", Work in Progress, Internet-Draft, draft-ietf-tvr-requirements-06, 7 July 2025, https://datatracker.ietf.org/doc/html/draft-ietf-tvr-requirements-06.

[Westphal2021qualitative] Westphal, C., He, D., Makhijani, K., and R. Li, "Qualitative Communications for Augmented Reality and Virtual Reality", 22nd IEEE International Conference on High Performance Switching and Routing (HPSR), pp. 1-6, DOI 10.1109/HPSR52026.2021.9481793, 2021, https://doi.org/10.1109/HPSR52026.2021.9481793.

[Wolf2014choicenet] Tilman, W., Griffioen, J., Calvert, L., Dutta, R., Rouskas, G., Baldin, I., and A. Nagurney, "ChoiceNet: Toward an Economy Plane for the Internet", ACM SIGCOMM Computer Communications Review, vol. 44, no. 3, pp. 58-65, DOI 10.1145/2656877.2656886, July 2014, https://doi.org/10.1145/2656877.2656886.

Acknowledgments 💖

The authors thank Dave Oran for providing the information regarding covert channels using energy measurements and Mike King for an exceptionally thorough review and useful comments. 🫶

Contributors 🌸

Michael Welzl University of Oslo Email: michawe@ifi.uio.no

Authors' Addresses 🦋

Alexander Clemm (editor) 👑 Sympotech Los Gatos, CA United States of America Email: ludwig@clemm.org

Carlos Pignataro (editor) ✨ North Carolina State University & Blue Fern Consulting United States of America Email: cmpignat@ncsu.edu, carlos@bluefern.consulting

Cedric Westphal 🧚 Department of Computer Science and Engineering University of California, Santa Cruz Email: cedric@ucsc.edu

Laurent Ciavaglia 💜 Nokia Email: laurent.ciavaglia@nokia.com

Jeff Tantsura 🔥 Nvidia Email: jefftant.ietf@gmail.com

Marie-Paule Odini 🌈 Email: mp.odini@orange.fr

📦 where this page comes from