An Overview of Energy-related Efforts within the IETF, IRTF, and IAB

Introduction This document summarizes work that has been proposed to or performed within the IETF, IRTF, and IAB. Its goal is to summarize, not to propose or direct new work. It is intended as a compilation of prior work, not a proposal of new activities. The main purpose is to provide a consolidated reference for participants, by cataloging and contextualizing what has already been published and done in IETF, IRTF, and IAB. Considering the target audience, this document is primarily intended as an internal reference and orientation guide for the IETF, IRTF, and IAB communities. By cataloging prior work in a single place, it aims to lower the entry barrier for participants who may not be aware of earlier efforts and to provide future contributors with a historical foundation. It also offers background for readers outside the IETF community who may be less familiar with how networking technologies contribute to energy savings. In addition to this compilation, the authors also share their own observations on what has worked well and what lessons may be drawn from the past. Digitization is not a uniform energy saving: as discusses, some digitized workflows consume significantly more energy than their pre-digitization alternatives, or grow so much in volume that their total consumption outranks what they replaced. Given how TCP/IP based networks, especially the Internet, have excelled through their design principles in reducing network traffic cost and enabling ubiquitous access over the past few decades, IETF technologies and especially the Internet are the most important enabler of the digital economy, and of the energy consumption it produces.

Scope, Categorization, and Citation Approach There are various aspects how a given work relates to energy; these are grouped into categories for the sake of better readability, not as a formal taxonomy. Technologies are listed under a category that is specifically significant, for example, by being most narrow. This memo refers to technologies by their significant early RFCs or Internet-Draft versions, rather than by the latest revision. This differs from the common IETF practice of citing the most current version. The intent is to help readers follow the historical timeline of when a technology was first proposed or introduced. In many cases, especially for successful I* technologies, later RFCs build upon and update that original work. This document captures work until December 2022, when the "IAB workshop on Environmental Impact of Internet Applications and Systems" renewed community discussion of the topic. The workshop emphasized that existing and emerging work could benefit from increased visibility and understanding, but this memo itself does not recommend or direct future work.

Document Roadmap The rest of this document is organized as follows: Section 2 introduces the concept of energy saving through digitization and through scaling of the Internet. Section 3 discusses cases where digitization can lead to higher, not lower, energy consumption. Section 4 covers sustainability topics such as renewable-energy-aware scheduling, heat management, and telecollaboration. Section 5 surveys IETF work on energy optimization in specific types of networks, particularly constrained and low-power networks. Section 6 covers energy management networks such as the Smart Grid and synchrophasor networks. Section 7 covers the (limited) management of network equipment energy consumption, including the EMAN working group. Section 8 covers power awareness in forwarding and routing protocols. Section 9 identifies gaps relative to a prior survey of this space. Section 10 shares the authors' own observations and lessons learned.

Energy Saving: An Introduction Technologies that simply save energy compared to earlier or other alternatives are the broadest and most unspecific category. In this memo such an energy saving simply refers to energy savings in some unit of electricity, such as kWh and does not take other aspects of energy optimization into account. See for more details.

Digitization Digitization refers to the shift of processes from analog or partially digital forms into fully digital ones, typically supported by computer networking. For comparable outcomes, the digitized option is often, though not always, more energy efficient. Consider, for example, the energy consumption in the evolution of messaging starting from postal mail and over telegrams and various other historic forms to solutions including e-mail utilizing, for example, the IETF "Internet Message Format" used by SMTP ( obsoleted by , ), group communications utilizing the IETF "Network News Transfer Protocol" (NNTP, ) or the nearly limitless set of communication options built on top of the IETF "Hypertext Transfer Protocol" (HTTP, and successors), and IETF "HyperText Markup Language" (HTML, superseded by various later version of HTML, see ). Conventionally, digitization had only "incidental", but not "intentional" relationship to energy consumption: If it saved energy, this was not a target benefit; in fact, it was not even recognized as one until recently. Instead, the evolution was driven from anything-but-energy benefits, but instead utility benefits such as improved speed, functionality/flexibility, accessibility, usability, scalability, and reduced cost. In hindsight though, digitization through IETF technologies and specifically the Internet will likely have the largest contribution to energy saving amongst all the possible categories, but it is also the hardest to pinpoint on any specific technology/RFC. Instead, it is often a combination of the whole stack of deployed protocols and operational practices that contributes to energy saving through digitization. It is likely also the biggest overall energy saving impact of all possible categories that relate IETF work to energy: The Internet as well as all other IP/Multiprotocol Label Switching (MPLS) networks are likely the biggest energy saving development of the past few decades if only the energy consumption of equivalent services is compared. On the other hand, they are also the cause of the largest new category of energy consumption because of all the new services introduced in the past decades with the Internet and the hyper-scaling that the Internet affords them.

Energy Savings Enabled by Scaling the Internet Energy savings often arise indirectly from architectural choices that improved scalability. These mechanisms reduce the average energy cost per bit by minimizing per-packet work, consolidating infrastructures, and leveraging economies of scale.

An Iconic Example: Telephony Digitized voice over IP (e.g., "Session Initiation Protocol", SIP ) illustrates how packetized transport reduced per-minute energy costs compared to analog or "Time Division Multiplex" TDM voice. The saving comes not from SIP itself but from the lower joules/bit achieved in IP (including physical-layer and link-layer) networks at scale.

The Packet Multiplexing Principle Statistical multiplexing in IP and IPv6 (, ) was designed for link efficiency, not energy, but the two are related: by raising utilization, it spreads largely fixed equipment power across more flows, lowering energy per bit. This is not a realistically reversible gain, since returning to dedicated circuit-based links is not a viable alternative today.

Dynamic Power Negotiation Power over Ethernet (PoE) shows how device-level negotiation can affect energy use. Endpoints such as IP phones signal expected draw (e.g., via the Link Layer Discovery Protocol (LLDP) or the Cisco Discovery Protocol (CDP)), enabling switches to allocate power budgets and reduce waste when devices enter low-power modes. While the negotiation itself happens per device, the savings scale with deployment size: applied consistently across the many endpoints of an enterprise or campus network, the aggregate reduction in over-provisioned power becomes significant, following the same scaling logic as the other mechanisms in this section. Problems arise if devices misreport or later exceed their declared needs. A device requesting 30 W but consuming 60 W forces over-provisioning and complicates capacity planning. Accurate and dynamic signaling is therefore key: truthful reporting avoids systematic waste, while real-time updates allow closer matching of supply and demand. IETF's EMAN framework provides models for monitoring and control in support of these dynamics, though broader architectural adoption remains limited.

End-to-End Transport The TCP end-to-end reliability model was designed for reliability, not energy, by avoiding per-hop retransmission and state. This design choice has a direct energy benefit: it minimizes per-packet processing in routers, enabling simpler, more energy-efficient forwarding at scale.

Global vs. Restricted Connectivity: The Internet Routing Architectures BGP enabled open interconnection and competitive market expansion, accelerating Internet scale. This scale matters for energy: it let energy efficiency gains from newer hardware generations spread globally faster than they could have under the regulated, per-country monopoly networks that preceded the Internet.

Converged Networks Replacing parallel infrastructures (e.g., voice, video, data) with a single IP fabric was driven by cost and operational simplicity, not energy, but it avoids duplicative powered equipment as a direct consequence. DiffServ and later DetNet illustrate how lighter-weight Quality of Service (QoS) models supported this convergence without reintroducing high per-flow energy overhead.

Higher or New Energy Consumption Digitized, network centric workflows may consume more energy than their non-digitized counterpart, as may new network centric workflows without easy to compare prior workflows. In one type of instances, the energy consumption on a per-instance basis is lower than in the non-digitized/non-Internet-digitized case, but the total number of instances that are (Internet)-digitized is orders of magnitudes larger than their alternative options, typically because of their higher utility or lower overall cost. For example, each instance of (simple text) email consumes less energy than sending a letter or postcard. Even streaming a movie or TV series consumes less energy than renting a DVD . Nevertheless, the total number of instances and as a result energy consumption for email and streaming easily outranks their predecessor technologies. While these instances look beneficial from a simple energy consumption metric, its overall scale and the resulting energy consumption may in itself become an issue, especially when the energy demand it creates risks to outstrip the possible energy production, short term or long term. This concern is nowadays often raised against the "digital economy", where the network energy consumption is typically cited as a small contributor relative to its applications, such as what is running in Data Centers (DC). In other cases, the energy consumption of digitization is often significantly higher than that of its pre-digitization alternatives. The most well-known example of this are likely crypto-currencies based on "proof-of-work" computations (mining), which on a per currency value unit can cost from ten to thirty times or more of the energy consumed by for example gold mining (very much depending on the highly fluctuating price of the crypto currency). Nevertheless, its overall utility compared to such prior currencies or valuables makes it highly successful in the market. In general, the digital economy tends to be more energy intensive on a per utility/value unit (for example by replacing a lot of manual labor with computation), and/or it allows for faster growth of its workflows. The lower the cost of network traffic, and the more easily accessible everywhere network connectivity is, the more competitive and/or successful most of these new workflows of the digital economy can be.

Some Notes on Sustainability Sustainability is the principle to utilize resources in a way that they do not diminish or run out over the long term (e.g., ore depletion required for building hardware). Beyond the above covered energy saving, sustainability relates with respect to the IETF specifically to the use of renewable sources of energy to minimize exhaustion of fossil resources, and the impact of IETF technologies on global warming to avoid worsening living conditions on the planet. While there seems to be no IETF work specifically intending to target sustainability, related work is emerging in the IRTF, such as , which examines management challenges and opportunities for green networking. The Internet itself can similarly to how it does for digitization play a key role in building sustainable networked IT infrastructures. The following subsections list three exemplary areas where global high performance, low-cost Internet networking is a key requirement.

Follow-the-Energy Cloud Scheduling Renewable energy resources (except for water) do commonly have fluctuating energy output. For example, solar energy output correlates to night/day and strength of sunlight. Cloud DCs consume a significant amount of the IT sector's energy. Some workloads may simply be scheduled to consume energy in accordance with the amount of available renewable energy at the time, not requiring the network. Significant workloads are not elastic in time, such as interactive cloud DC work (cloud based applications) or entertainment (gaming, etc.). These workloads may be instantiated or even dynamically (over time) migrate to a DC location with sufficient renewable energy and the Internet (or large TCP/IP Over-The-Top (OTT) backbone networks) will serve as the fabric to access the remote DC and to coordinate the instantiation/migration.

Optimize Generated Heat The majority of energy in cloud DCs is normally also wasted as exhaust heat, requiring even more energy for cooling. The warmer the location, the more energy needs to be spent for cooling. For this reason, DCs in cooler climates, such as , can help to reduce the overall DC energy consumption significantly (independent of the energy being consumed in the DC to be renewable itself). The Internet again plays the role of providing access to those types of DCs whose location is not optimized for consumption but for sustainable generation of compute and storage.

Heat Recovery Exhaust heat, especially from compute in DCs, can be recovered when it is coupled to heating systems ranging in size all the way from individual family homes through larger buildings (hotels, for example) all the way to district heating systems. A provider of such a type of compute-generated heat as a service can sell the compute capacity as long as there is cost efficient network connectivity. "Cloud & Heat" is an example company offering such infrastructures and services .

Telecollaboration Telecollaboration has a long history in the IETF resulting in multiple core technologies over the decades. If one considers textual communications via email and netnews (using e.g., NNTP) as early forms of Telecollaboration, then telecollaboration history through IETF technology reaches back into the 1980s and earlier. Around 1990, the IETF work on IP Multicast (e.g., and later) enabled the first efficient forms of audio/video group collaboration through an overlay network over the Internet called the MBone which was also used by the IETF for more than a decade to provide remote collaboration for its own (in-person + remote participation) meetings. With the advent of SIP in the early 2000s, commercial telecollaboration started to be built most often on SIP based session and application protocols with multiple IETF working groups contributing to that protocol suite, such as SIPCORE, MMUSIC, and XCON. Using these technologies and the Internet, the immersive nature of telecollaboration was brought to life-size video, was/is called Telepresence and later to even more immersive forms such as Augmented Reality (AR) / Virtual Reality (VR) telecollaboration. In 2011, the IETF opened the "Real-Time Communication in Web-browsers" (RTCWEB) WG, that towards the end of that decade became the most widely supported cross-platform reference for hundreds of commercial and free tele-collaboration solutions, including Cisco Webex, which is also used by the IETF itself, Zoom, and the collaboration suite the IETF most recently uses, Meetecho . While the various forms of Telecollaboration are mostly instances of digitization, they are discussed under sustainability rather than simply energy, because their relevant comparison is not to a "without digitization" baseline, but to an alternative that itself has an energy and emissions cost: in-person travel. This substitution effect is why the energy properties of the underlying transport and session protocols matter beyond the session itself: a more efficient or more reliable telecollaboration protocol stack can directly influence whether travel is displaced. Use of telecollaboration increased sharply during the COVID-19 pandemic , including for in-person events that were moved to a telecollaboration platform over the Internet, most of them likely relying on RTCWEB protocols. Actual energy consumption related comparison between teleconferencing and in-person travel is complex but since the last decades is commonly based on calculating some form of CO2 emission equivalent of the energy consumed, hence comparing not simply the energy consumption, but weighing it by the impact the energy consumption has on one of the key factors (CO2 emission) known to impact sustainable living conditions. is a good example of a comparison between travel and telecollaboration taking various factors into account and using CO2 emission equivalents as its core metric. That paper concludes that carbon/ energy cost of telecollaboration could be as little as 7% of an in-person meeting. Those numbers have various assumptions and change when time-effort of participants is converted to carbon/energy costs. These numbers should even be better today in favor of telecollaboration: cost of Internet traffic/bit goes down while cost of fossil fuel for travel goes up. Recently, air travel has also come under more scrutiny because the greenhouse gas emissions of air travel at the altitudes used by commercial aviation has been calculated to have a higher global warming impact than simply the amount of CO2 used by the airplane if it was exhausted at surface level. One publicly funded organization offering carbon offset services calculates a factor 3 of the CO2 consumption of an airplane . The protocol-relevant takeaway is that telecollaboration's sustainability benefit compared to travel exceeds what a simple energy-consumption comparison would suggest, because transportation is harder to decarbonize than networking is. This gap is largest where telecollaboration displaces air travel specifically, given the added global warming impact of burning fossil fuels at altitude.

Energy Optimization in Specific Networks This section surveys IETF work that optimizes energy use in specific types of networks, starting with the routing and subnet-management analysis that motivated much of it, and continuing through the working groups and technologies built on top of that analysis.

Analysis of Routing Protocol (In)Efficiencies At the beginning of much of the following IETF efforts was an understanding and analysis that prior protocols for routing and subnet management were not able to ideally support evolving network and device models: - lower compute performance due to low energy (batteries, energy recovery), bitrates especially on radio links, and lower memory footprint. The two documents from 2008-2009 that capture this analysis/ understanding are and . The overall challenges also very much related to energy of IPv6 over wireless are captured in , which is ongoing work.

Low-Power and Lossy Networks (LLN) Low-Power and Lossy Networks (LLNs) are networks in which nodes and/or radio links operate under significant constraints. Node power limitations often arise from the need to maximize lifetime when powered by batteries or energy-harvesting methods, most commonly solar panels, but also ambient sources such as motion (in wearables) or piezoelectric cells that generate energy for mechanically operated devices like switches. Several IETF WGs have or are producing work is primarily intended to support LLN through multiple layers of the protocol stack. gives a good overview of the energy consumption related communication challenges and solutions produced by the IETF for this space. To minimize the energy needs for such nodes, their network data-processing mechanisms have to be optimized. This includes packet header compression, fragmentation (to avoid latency through large packets at low bitrates, packet bundling to only consume radio energy at short time periods, radio energy tuning to reach only the destination(s), minimization of multicasting to eliminate need of radio receivers to consume energy and so on. gives a more detailed overview, especially because different L2 technologies such as IEEE 802.15.4 type (low-power) wireless networks, Bluetooth Low Energy (BLE), WLAN (IEEE 802.11) and DECT ULE. In the INT area of the IETF, several LLN specific WGs exist(ed):

IPv6 over Low Power WPAN (6LoWPAN) The "IPv6 over Low power WPAN (Wireless Personal Area Networks)" (6lowpan) WG ran from 2005 to 2014 and produced 6 RFC that adopt IPv6 to IEEE 802.15.4 type (low-power) wireless networks by transmission procedures ("Transmission of IPv6 Packets over IEEE 802.15.4 Networks", ), compression of IPv6 (and transport) packet headers ("Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", ), and modifications for neighbor discovery (ND) ("Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", , also known as 6LOWPAN-ND), as well as 3 informational RFCs about the WPAN space and applying IPv6 to it. Among these, the Problem Statement and Requirements gives details about the power and energy approaches and goals. It is important to understand the 6LOWPAN Overview, Assumptions, Problem Statement, and Goals , including "conserve energy". Outside the 6LOWPAN WG, connects Information-Centric Networking (ICN) to Low-Power Wireless Personal Area Networks (LoWPANs).

IPv6 over Low Power Wide-Area Networks (LPWAN) Since 2014 and before 2023, the "IPv6 over Low Power Wide-Area Networks" (LPWAN) WG has produced 4 RFC for low-power wide area networks, such as LoRaWAN , with three Standards-Track RFC documents, , , and .

IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Since 2013, the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6tisch) WG has produced 7 RFC for a version of 802.15.4 called the "Time-Slotted Channel Hopping Mode" (TSCH), which supports deterministic latency and lower energy consumption through the use of scheduling traffic into well-defined time slots, thereby also optimizing/minimizing energy consumption when compared to 802.15.4 without TSCH.

IPv6 over Networks of Resource-constrained Nodes (6LO) Since 2013, the "IPv6 over Networks of Resource-constrained Nodes" (6lo) WG has generalized the work of 6lowpan for LLN in general, producing 17 RFC for IPv6-over-l2foo adaptation layer specifications, information models, cross-adaptation layer specification (such as header specifications) and maintenance and informational documents for other pre-existing IETF work in this space. Notably, a key specification produced is , "IPv6 over BLUETOOTH(R) Low Energy", using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques, as well as the related for the formation of extended topologies, a mesh IPv6 network over Bluetooth LE links. From a management perspective, produced , LOWPAN MIB, as well as several specific improvements around power such as , , , , and . Finally, the 6LO WG also produced , IPv6 over DECT Ultra-Low Energy, and , IPv6 over Power Line Communication (PLC).

Routing Over Low power and Lossy networks (ROLL) In the RouTinG (RTG) area of the IETF, the "Routing Over Low power and Lossy networks" (ROLL) WG has produced since 2008 23 RFC. Initially it produced requirement RFCs of different type of "Low-power and Lossy Networks": urban: , industrial , home automation and building automation . Since then, its work is mostly focused on the "IPv6 Routing Protocol for Low-Power and Lossy Networks" (RPL) , which is used in a wide variety of the above-described IPv6 instances of LLN networks and which are discussed in two ROLL applicability statement RFCs, "Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control" and "Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks" . Further, some RPL RFCs were progressed in the 6MAN WG, such as , RPL Option for Carrying RPL Information in Data-Plane Datagrams, and , IPv6 Routing Header for Source Routes with RPL. covers a Security Threat Analysis for RPLs, which is also relevant to energy efforts. The ROLL WG also wrote a more generic RFC for LLN, "Terms Used in Routing for Low-Power and Lossy Networks" . RPL has a highly configurable set of functions to support (energy) constrained networks. Unconstrained root node(s), typically edge routers between the RPL network and a backbone network calculate "Destination-Oriented Directed Acyclic Graphs" (DODAG) and can use strict hop-by-hop source routing with dedicated IPv6 routing headers to minimize constrained nodes routing related compute and memory requirements. "The Trickle Algorithm" allows to minimize routing related packets through automatic lazy updates. While RPL is naturally a mesh network routing protocol, where all nodes are usually expected to be able to participate in it, RPL also supports even more lightweight leave nodes . The 2013 proposes the introducing of energy-related parameters into RPL to support calculation/selection of most energy-efficient paths. The 2017 "An energy optimization routing scheme for LLNs", observed that DODAGs in RPL tend to require more energy in nodes closer to the root and proposed specific optimizations to reduce this problem. Neither of these Internet-Drafts proceeded in the IETF. Originally, RPL was designed for networks constrained by energy and size, but its design is largely not limited by scale. Because of this, and due to its reduced compute and memory requirements for networks of the same size compared to other routing protocols, especially the link-state Interior Gateway Protocols (IGPs) such as IS-IS ( superseded by ) and OSPF , RPL has also expanded into use cases for non-constrained networks. For example, it can automatically support very large-scale deployments, as described in .

Constrained Nodes and Networks (Power) constrained nodes and/or networks exist in a much broader variety than coupled with low-power and lossy networks. For example, Wi-Fi and cellular mobile network connections are not considered to be lossy networks, and personal mobile nodes with both connections are an order of magnitude less constrained than nodes typically attached to LLN network. Therefore, broader work in the IETF than focused primarily on LLN typically uses just the term lightweight or constrained (nodes and networks).

Light-Weight Implementation Guidance (LWIG) Since 2013, the "Light-Weight Implementation Guidance" (lwig) WG has produced 6 informational RFCs on the group's subject, much of which indirectly supports implementing power efficient network implementations via lightweight nodes/links, but it also addressed the topic explicitly including via the aforementioned and , "Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks". Further, the LWIG WG produced , "Terminology for Constrained-Node Networks", which includes important energy and power definitions of terms. These include scaling properties, classes of energy limitation, and strategies for using power for communication. It also produced , giving guidance on TCP usage for saving energy.

CoRE and CoAP In the APPlication (APP) area of the IETF, the "Constrained RESTful Environments" (core) WG has produced since 2010 21 RFC, most of them for or related to "The Constrained Application Protocol" (CoAP) , which can best be described as a replacement for HTTP for constrained environment, using UDP instead of TCP and DTLS instead of TLS, compact binary message formats instead of human readable textual formats, RESTful message exchange semantic instead of a broader set of options (in HTTP), but also more functionality such as (multicast) discovery and directory services via the "Constrained RESTful Environments (CoRE) Link Format" , therefore providing a more comprehensive set of common application functions with more compact on-the-wire/radio encoding than its unconstrained alternatives. "Object Security for Constrained RESTful Environments" (OSCORE), is a further product of the CoRE WG providing a more message layer based, more lightweight security alternative to DTLS. While originally designed for LLN, CoAP is transcending LLN and equally becoming ubiquitous in unconstrained environments such as wired/ethernet industrial Machine 2 Machine (M2M) communications, because of simplicity, flexibility and relying on the single set of protocols supporting the widest range of deployment scenarios. In the SECurity (SEC) area of the IETF, the "Authentication and Authorization for Constrained Environments" (ace) working group has since 2014 produced 4 RFC for security functions in constrained environments, for example CoAP based variations of prior HTTP over TLS (HTTPS) protocols such as EST-coaps for HTTPS based Enrollment over Secure Transport (EST) . Constrained node support in cryptography especially entails support for Elliptic Curve (EC) public keys due to their shorter key sizes and lower compute requirements compared to RSA (Rivest-Shamir-Adleman) public keys with same cryptographic strength. While the benefits of Elliptic Curve Cryptography (ECC) over RSA already made them the preferred choice, the additional advantage for constrained nodes accelerated their adoption and proliferation, even beyond constrained networks.

Satellite Constellations Emerging communication infrastructures may have specific requirements on power consumption. Such requirements should be taken into account when designing/customizing techniques (e.g., routing) to be enabled in such networks. For example, identifies a set of requirements (including power) for satellite constellations.

Devices with Batteries Many IETF protocols (e.g., ) were designed to accommodate the presence of middleboxes mainly by encouraging clients to issue frequent keepalives. Such a strategy has implications on battery-supplied devices. In order to optimize battery consumption for such devices, specifies a deterministic method so that the client can control state in the network, including their lifetime. Keepalive messages may thus be optimized as a function of the network policies. The recommendation labeled "A_REC#2" of further insists on the importance of saving battery exacerbated by keep-alive messages and recommends the support of collaborative means to control state in the network rather than relying on heuristics.

(IP) Multicast Multicast has both power-saving and power-wasting properties, and its energy impact differs significantly between wired and wireless links, so it is covered here across three subsections.

Power Saving through Multicast IP Multicast, introduced in and now also referred to as Any-Source Multicast (ASM), has seen various supporting protocols standardized in the IETF across multiple working groups. In addition, multicast solutions have also been developed for MPLS and for Bit Index Explicit Replication (BIER) within their respective IETF working groups. These three, network layer multicast technologies can be power-saving technologies when used to distribute data because they reduce the number of packets that need to be sent across the network (through in-network-replication where needed). Because most current link and router technologies do not allow to actually save significant amounts of energy on lower than maximum utilization, these benefits are often only theoretical though. Software routers are the ones most likely to expose energy consumption somewhat proportional to their throughput for just the forwarding (CPU) chip. Likewise, in large backbone networks, IP multicast can free up bandwidth to be used for other traffic, such as unicast traffic, which may allow to avoid upgrades to faster and potentially more power consuming routers/links. Today, these benefits too are most often overcompensated for by lower per-bit energy consumption of newer generations of routers and links though. Multicasting can also save energy on the transmitting station across radio links, compared to replicated unicast traffic, but this is rarely significant, because except for fully battery powered mesh network, there are typically non-energy-constrained nodes, such as (commonly) the wired access-points in Wi-Fi networks. In result, today multicasting has typically no significant power-saving benefits with available network technologies. Instead, it is used (for data distribution) when the amount of traffic that a unicast solution alternative (with so-called ingress replication) is not possible due to the total amount of traffic generated. This includes wireless/radio networks, where equally airtime is the limiting factor. As an additional pointer, defined the Multicast Protocol for Low-Power and Lossy Networks (MPL).

Power Waste through Multicast-based Service Coordination (IP) multicast is often not used to distribute data requested by receivers, but also coordination type functions such as service or resource announcement, discovery or selection. These multicast messages may not carry a lot of data, but they cause recurring, often periodic packets to be sent across a domain and waste energy because of various ill-advised designs, including, but not limited to the following issues: (a) The receivers of such packets may not even need to receive them, but the protocol shares a multicast group with another protocol that the client does need to receive. (b) The receiver should not need to receive the packet as far as multicast is concerned, but the underlying link-layer technology still makes the receiver consume the packet at link-layer. (c) The information received is not new, but just periodically refreshed. (d) The packet was originated for a service selection by a client, and the receiving device is even responding, but the client then chooses to select another device for the service/resource. These problems are specifically problematic in the presence of so-called "sleepy" nodes that need to wake up to receive such packets (unnecessarily). It is worse, when the network itself is an LLN network where the forwarders themselves are power constrained and for example periodic multicasting of such coordination packets wastes energy on those forwarders as well - compared to better alternatives. In 2006, the IETF published "Source Specific Multicast" (SSM) , a variation of IP Multicast that does not allow to perform these type of coordination functions but is only meant for (and useable for) actual data distribution. SSM was introduced for other reasons than the above-described power-related issues though, but deprecating the use of ASM is one way to avoid/minimize its ill-advised use with these type of coordination functions, when energy efficiency is an issue. is an example for deprecating ASM for other reasons in Service Provider networks.

Power Waste through Wireless Multicast covers multicast challenges and solutions (proposals) for IP Multicast over Wi-Fi. With respect to power consumption, it discusses the following aspects: (a) Unnecessary wake-up of power-constrained Wi-Fi Stations (STA) nodes can be minimized by wireless Access Points (APs) that buffer multicast packets so they are sent only periodically when those nodes wake up. (b) Wi-Fi access points with "Multiple Input Multiple Output" (MIMO) antenna diversity focus sent packets in a way that they are not "broadcast" to all receivers within a particular maximum distance from the AP, making Wi-Fi multicast transmission even less desirable. (c) It lists the most widely deployed protocols using aforementioned coordination via IP multicast and describes their specific challenges and possible improvements. (d) Existing proprietary conversion of Wi-Fi multicast to Wi-Fi unicast packets. focuses on IPv6-related concerns of multicast traffic in large wireless networks. This document provides a set of statistics and the induced device power consumption of such flows.

Sleepy Nodes Sleepy nodes are one of the most common design solutions in support of power saving. This includes LLN level constrained nodes, but also nodes with significant battery capacity, such as mobile phones, tablets and notebooks, because battery lifetime has long since been a key selling factor. In result, vendors do attempt to optimize power consumption across all hardware and software components of such nodes, including the interface hardware and protocols used across the nodes Wi-Fi and mobile radios. As noted in : CoAP provides basic support for sleepy nodes by allowing (non-sleepy) proxy nodes to cache resource information. extends this by enabling sleepy nodes to update caching intermediaries on their own schedule. Around 2012-2013, there was significant discussion of additional mechanisms for supporting sleepy nodes in CoAP, resulting in a series of Internet-Drafts: , , , , , , , , and , all of which are summarized in . None of these Internet-Drafts, however, advanced further. One partial solution to certain sleepy-node energy consumption issues, particularly those caused by the use of multicast , , is the Constrained RESTful Environments (CoRE) Resource Directory (CoRE-RD) . It enables sleepy nodes to discover and register resources via unicast, thereby avoiding unnecessary wake-ups when they are not selected by a resource consumer. A partial alternative to CoRE-RD is the "DNS-Based Service Discovery" (DNS-SD) combined with for example "Service Registration Protocol for DNS-Based Service Discovery" . Services can be seen as a subset of resources, and in networks where DNS has to be supported anyhow for other reasons, DNS-SD may be a sufficient alternative to CoRE-RD. It is used for example in Thread for this purpose and the only multicast based coordination is the one to establish network wide parameters, such as the address(es) of DNS-SD server(s). "Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks" discusses sleepy devices, especially the use of CoAP PubSub as a mechanism to build proxies for sleepy devices. Normalized proxy infrastructures are best built with published data models, such as "Sensor Measurement Lists" (SenML) for sensors, likely the largest number of sleepy devices, especially in LLN. "Reducing Energy Consumption of Router Advertisements", eliminates/reduces the energy impact for sleepy nodes of the ubiquitous IPv6 ND protocol by giving recommends for replacing multicast "Router Advertisement" (RA) messages with so-called directed unicast versions, therefore not waking up sleepy nodes (with an IP multicast RA message). This was already allowed in ND , but not recommended as the default. Note that does not provide all the energy-related optimizations of ND as developed by 6LoWPAN through , later updated by in 6LO. proposes generalizations for those applications for to all IPv6 links, but was not further pursued by the IETF so far.

(Lack of) Power Benchmarking Proposals presented some measurement results of the power consumption when using IPv6 vs. IPv4 with a focus on mobile devices. Such measurements are not backed with formal benchmarking methodologies so that solid and reliable references are set to compare and interpret data. presented a benchmark example but with a focus on power cost of encryption.

Energy Management Networks The use of IETF protocols in networks that manage power consumption and production is another broad area of digitization.

Smart Grid "Smart Grid" is the most well-known instance of such energy management networks. According to , the term covers aspects mostly centered around intelligent measured and controlled consumption of energy. This includes "Advanced Metering Infrastructure" / "Smart Meters", remote controllable "distribution boards", "circuit breakers", "load control" and "smart appliances". Use cases for the "Smart Grid" include for example timed and measured operations of home devices such as washers or charging cars, when energy consumption is below average. The 2011 "Internet Protocols for the Smart Grid" is a quite comprehensive (66 page) overview of all IETF protocols considered to be necessary or beneficial for Smart Grid networks. This document was written in response to interest by the (not-yet-smart grid) community in utilizing the IETF TCP/IP technologies to evolve previously non-TCP/IP network, and the risk that unnecessary reinvention of the wheel/protocols would be done by that community instead of reusing what was already well specified by the IETF. Most of the overview in this document is not specific to networks used for Smart Grid applications, but is summarized here for the outreach and education of the community as described above. The aspects most specific to Smart Grids concern the, back in 2011 still somewhat nascent, adaptation of IPv6 network technologies to LLN networks (see ): smart meters, circuit breakers, load measurement devices, car chargers, and similar devices that would most likely be connected via low-power radio networks ideally utilizing IPv6 directly. Support for LLN networks with IPv6 has significantly improved in IETF specifications over the past decade.

Synchrophasor Networks Power output of multiple power plants/generators into the same power grid needs to be synchronized by power levels based on consumption and power phase (50/60Hz depending on continent) to avoid that energy created out-of-phase is not only wasted, but would actually burn out power lines or create permanent damage in power generators. When generators go out-of-sync, they have to be emergency switched off, resulting in (rolling-)blackouts, worsening the conditions beyond its likely root-cause such as a single overloaded region. Synchrophasor Networks are networks whose goal it is to support synchronization of power generators across a power grid, ultimately also permitting to build larger and more resilient power grids. "Phasor Measurement Units" (PMU) are their core sensing elements. Since about 2012, these networks have started to move from traditional Supervisory Control and Data Acquisition (SCADA) towards more TCP/IP based networking and application technologies "to improve power system reliability and visibility through wide area measurement and control, by fostering the use and capabilities of synchrophasor technology" (https://www.naspi.org/). With their fast control loop reaction time and measurement requirements, they also benefit from reliable, fast propagation of PMU data as well as stricter clock synchronization than most Smart Grid applications. For example, transmission lines expand under heat that is caused by electrical load and/or environmental temperature by as much as 30% (between coldest and hottest or highest-load times), impacting the necessary phase relationship of power generation on either end (speed of light propagation speed based on effective length of contracted/expanded wire). The length of transmission wires can be measured from data sent across the transmission lines and measuring their propagation latency with the help of accurate clock synchronization between sender and receiver(s), using for example network-based clock synchronization protocols. The IETF "Network Time Protocol version 4" (NTPv4), is one option for this. The IEEE Precision Time Protocol (PTP) is often preferred though because it specifies better how measurements can be integrated at the hardware level of Ethernet interfaces, thus allowing easier to achieve higher accuracy, such as Maximum Time Interval Error (MTIE) of less than 1 msec. See for example . The "North American SynchroPhasor Initiative" (NASPI), https://www.naspi.org is an example organization in support of synchrophasor networking. It is an ongoing project by the USA "Department of Energy" (DoE).

(Limited) Energy Management of Network Equipment This section covers IETF work that manages the energy consumption of network equipment itself, starting with early, non-adopted metrics proposals before turning to the one working group, EMAN, that produced standardized models in this space.

Some Metrics A 2010-2013 Internet-Draft , which was not adopted, discussed and proposed metrics for power consumption that were intended to be used for benchmarking. The later work in referred instead to other metrics for measuring power consumption from other Standards Developing Organizations (SDOs). A 2011-2012 Internet-Draft , which was not adopted, discusses and proposes a data model to communicate time-varying cost of energy in support of enabling time-shifting of network attached or managed equipment consumption of power.

Energy Management (EMAN) While the IETF did specify a few MIBs with aspects related to power management, it was only with the formation of the "Energy Management" (EMAN) WG (2010-2015) that a comprehensive set of MIB-based models for managing energy in network equipment was developed. This work also provides standardized support for issues noted earlier in , such as negotiation and monitoring of device-level power needs. EMAN produced (solely) a set of data/information models (MIBs). It does not introduce any new protocol/stacks nor does it address "questions regarding Smart Grid, electricity producers, and distributors" (from ). describes the initial EMAN architecture as envisioned by some of the core contributors to the WG. It was rewritten in EMAN as the "Energy Management Framework" . "Requirements for Energy Management" are defined in . According to , "the (EMAN) framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects." One category of use-cases of particular interest to network equipment vendors was and is the management of "Power over Ethernet" via the EMAN framework, measuring and controlling ethernet connected devices through their PoE supplied power. Besides industrial, surveillance cameras and office equipment, such as Wi-Fi access points and phones, PoE is also positioned as a new approach for replacing most in-building automation components including security control for doors/windows, as well as environmental controls and lighting through the use of an in-ceiling, PoE enabled IP/ethernet infrastructure. EMAN produced version 4 of the "Entity MIB" (ENTITY-MIB) , primarily to introduce globally unique UUIDs for physical entities that allows to better link across different entities, such as a PoE port on an ethernet switch and the device connected to that switch port. The "Monitoring and Control MIB for Power and Energy" specifies a MIB for monitoring for Power State and energy consumption of networked equipment. The document discusses the link with other MIBs such as the ENTITY-MIB, the ENTITY-SENSOR-MIB for which it is amending missing accuracy information to meet International Electrotechnical Commission (IEC) power monitoring requirements, the "Power Ethernet MIB" (POWER-ETHERNET-MIB) to manage PoE, and the pre-existing IETF MIB for Uninterruptible Power Supplies (UPS) (UPS-MIB) , allowing for example to build control systems that manage shutdowns of devices in case of power failure based on UPS battery capacity and device consumptions/priorities. Similarly, the EMAN "Definition of Managed Objects for Battery Monitoring" defines objects to support battery monitoring in managed devices. It is important to note that, outside the EMAN WG and as an Independent Submission, specifies "Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses". The pre-existing IETF "Entity State MIB" (ENTITY-STATE-MIB) allows to specify the operational state of entities specified via the ENTITY-MIB respective to their power consumption and operational capabilities (e.g.: "coldStandby", "hotStandby", "ready" etc.). Devices can also act as proxies to provide a MIB interfaces for monitoring and control of power for other devices, that may use other protocols, such as in case of a home gateway interfacing with various vendor specific protocols of home equipment. The EMAN "Energy Object Context MIB" defines the ENERGY-OBJECT-CONTEXT-MIB and IANA-ENERGY-RELATION-MIB, both of which serve to "address device identification, context information, and the energy relationships between devices" according to . To automatically discover and negotiate PoE power consumption between switch and client, non-IETF technologies, such as IEEE LLDP and proprietary MIBs for it, such as LLDP-EXT-MED-MIB can be used. Finally, the "Energy Management (EMAN) Applicability Statement" provides an overview of EMAN with a user/operator perspective, also reviewing a range of typical scenarios it can support as well as how it could/can link to a variety of pre-existing, non-IETF standards relevant for power management. Such intended applicability includes home, core, and DC networks. There are currently no YANG equivalent modules. Such modules would not only be designed to echo the EMAN MIBs but would also allow to control dedicated power optimization engines instead of relying upon static and frozen vendor-specific optimization.

Power Awareness in Forwarding and Routing Protocols This section covers proposals for making forwarding and routing decisions themselves aware of, and responsive to, power consumption, from the earliest (non-adopted) PANET work through more recent Software-Defined Networking (SDN) based and miscellaneous efforts.

Power-Aware Networks (PANET) In 2013-2014, some Internet-Drafts proposed how networks themselves, specifically those of Internet Service Providers (ISP) could dynamically regulate their power consumption based on the required performance, for example by switching off or low-powering non-needed components (links, nodes, linecards) or changing speeds on links, or reducing clock-rates of processing elements, and/or routing traffic to utilize as few components as will support the required performance. The authors called this "Power-Aware Networks" (PANET), even though no awareness of actual power consumption is required in this approach. The 2013 "Power-Aware Networks (PANET): Problem Statement" gives an overview of this concept, and so does "Power-aware Routing and Traffic Engineering: Requirements, Approaches, and Issues", from the same year. The 2014 exemplifies the concept and discusses key challenges such as the reduced resilience against errors when redundant components are switched off, the risk of increased stretch (path length) and therefore latency under partial network component shutdown or down-speeding, as well as the idea of saving energy through (periodic) microsleeps such as possible with "Energy Efficient Ethernet" links. The 2013 Internet-Draft "Reducing Power Consumption using BGP with power source data", proposed BGP attributes to allow calculation of power-efficient (or for example green) paths. One core market driver for this work was the rolling blackouts that especially affected India at the time of these Internet-Drafts, creating a desire to, for example, reduce the total power consumption of a network during such energy emergencies. While there was technical interest in the IETF, the market significance for the vendors mostly present in the IETF was considered as not to be important enough. Likewise, traditional routers, unlike for example todays standard PC hardware designs do exhibit little power savings upon shutdown of components such as line-cards or interfaces. In addition, an SDN / controller-based solution was relatively in its infancy back in 2013-2014, and technologies that would allow for SDN controller to have resilient (self-healing) connectivity, such as described in and , were also not available, making the risk of severely impacting network reliability one of the key factors for this PANET work to not proceed so far.

SDN-based Semantic Forwarding Recently, provided the following feature as an example of capabilities that can be offered by appropriate control of forwarding elements: Energy-efficient Forwarding: An important effort was made in the past to optimize the energy consumption of network elements. However, such optimization is node-specific and no standardized means to optimize the energy consumption at the scale of the network have been defined. For example, many nodes (also, service cards) are deployed as backups. A controller-based approach can be implemented so that the route selection process optimizes the overall energy consumption of a path. Such a process takes into account the current load, avoids waking nodes/cards for handling "sparse" traffic (i.e., a minor portion of the total traffic), considers node-specific data (e.g., ), etc. This off-line Semantic Routing approach will transition specific cards/nodes to "idle" and wake them as appropriate, etc., without breaking service objectives. Moreover, such an approach will have to maintain an up-to-date topology even if a node is in an "idle" state (such nodes may be removed from adjacency tables if they don't participate in routing advertisements).

Additional Related Efforts The non-adopted, expired 2013 Internet-Draft discusses power awareness in routing in conjunction with Traffic Engineering (tunnels), specifically in the context of Generalized MPLS (GMPLS), e.g.: various L2 technologies such as switched optical fiber networks. It primarily claims the issue that the existing management objects are not sufficient to express energy management related aspects, and thus do not allow to build energy conscious policies into the Path Computation Element (PCE) for such GMPLS networks. The non-adopted 2013 "Requirements for an Energy-Efficient Network System", proposes a signaling of network capacity towards DC, for example based on load or network energy management in support of appropriate performance control (such as VM migration) at the DC - or vice versa (DC load-based traffic engineering in the network to support that DC load). The non-adopted 2013 "Building power optimal Multicast Trees" proposes that (Protocol Independent Multicast (PIM) based) IP Multicast routing could perform local routing choices in the case of "Equal Cost MultiPath" (ECMP) "Reverse Path Forwarding" (RPF) alternatives based on the energy that would be consumed in the router, such as when one ECMP alternative would use a more power-efficient linecard or when one ECMP choice was on the same linecard as the interfaces to which the packets would need to be routed (and therefore avoiding to forward the packet across separate ingress and egress linecards). These three proposals share a common obstacle: each required detailed, standardized visibility into a router's or data center's internal energy consumption (per linecard, per VM, or per multicast tree) that was not available at the time, and in most cases still is not. That missing visibility is a plausible reason none of the three proceeded, distinct from the market-interest and SDN-maturity factors behind the PANET experience described earlier in this section.

Gap Analysis The 2013 "Towards an Energy-Efficient Internet" summarizes some of the same work items as this document (as written back in 2013) and lists additional non-adopted Internet-Drafts. It also identified three areas of gaps: "Load-adaptive Resource Management", "Energy-efficient Protocol Design", and "Energy-efficiency Metrics and Standard Benchmarking Methodologies". While these areas remain open, this document records them for reference rather than recommending specific next steps. Unlike , this document does not cover quantitative, industry-level energy and emissions estimates (such as ICT's projected share of global electricity use), nor does it analyze structural obstacles to energy efficiency, such as IETF protocols that assume always-on nodes (complicating the introduction of sleep modes) or network over-provisioning for resiliency and strict failover requirements, which works against energy savings. Readers interested in those obstacle-level questions should consult directly. Some aspects for those areas of gaps were partially tackled by later work in the IETF, but broadly speaking, most of those areas remain open. This document records these gaps for reference only; it does not recommend or direct any future work to address them.

Authors' Observations and Lessons Learned Beyond compiling existing work, the authors consider it valuable to briefly reflect on where energy-related activities within the IETF/IRTF/IAB have gone well and what can be learned from them. In particular: Successful integration into existing work: Several cases show that energy awareness was most effective when integrated into ongoing protocol development (e.g., extensions in transport and management protocols) rather than as an isolated stand-alone activity. For example, Power over Ethernet power negotiation builds on existing link-layer signaling (LLDP/CDP) rather than a new, energy-specific protocol. Clear problem framing: Efforts that were framed around a well- defined operational or architectural need tended to achieve broader traction than more generic appeals to "green networking." For example, the constrained-device networking work in the IETF (6LoWPAN, 6TiSCH, 6Lo, ROLL, and LWIG) succeeded by addressing concrete constraints of low-power and lossy networks, such as limited energy, memory, and bandwidth, rather than by framing itself around energy savings as a goal in its own right. Collaboration across communities: Effective work often involved coordination between the related research and standardization bodies (e.g., IETF, IRTF, IAB, International Telecommunication Union (ITU)), showing that energy and environmental sustainability topics benefit from cross-community dialogue. Appreciating multidisciplinarity: It has proven important to bring in the right subject-matter experts (e.g., from energy systems, environmental science, or other disciplines) rather than making assumptions within the networking community alone. Limited continuity: Some prior activities were time-bound or lacked continuity. A lesson is that sustained progress often requires ongoing integration into mainstream workstreams. For example, after the EMAN WG concluded in 2015, dedicated IETF/IRTF energy-management activity did not resume until the Sustainability and the Internet (SUSTAIN) Research Group (RG) and the Getting Ready for Energy-Efficient Networking (GREEN) WG efforts nearly a decade later. Constrained and actionable scope: Experience shows that activities with a well-defined and bounded scope are more likely to deliver actionable results and running code, which is core to the IETF ethos. These observations are the personal views of the authors and are included here to provide additional context. They do not represent IETF consensus or recommendations for future work.

Security Considerations This document provides an overview of IETF work related to energy, and as such does not contain security considerations of its own. Each one of the cited documents contains security considerations within its own context. As this document aims to help those unfamiliar with but interested in IETF energy work by raising awareness of an important, broad topic, it indirectly also raises awareness of the security considerations overall. This document does not recommend or direct future work; any future energy-related activities within the IETF, IRTF, or IAB would separately need to address their own security considerations.

IANA Considerations This document has no IANA actions.

Acknowledgments The authors are especially grateful to Fred Baker for his thorough review, historical insight, and evident care in reading successive versions of this document. The authors also thank the other reviewers and commenters who contributed feedback across its revisions, including Michael Welzl and other experts who reviewed this document. The authors further thank Eliot Lear, Independent Submissions Editor (ISE), for his guidance and shepherding of this document through the independent submission process. By serving as the first catalog of energy-related work within the IETF, IRTF, and IAB, this document is intended to be a resource for participants rather than a vehicle for setting future directions.

Changelog [RFC-Editor: this section to be removed in final document.] The master for this document is hosted at . Please submit Issues and/or Pull-requests for proposed changes or join the team of authors and edit yourself. 00: Initial version 01: Added Co-author (Mohamed Boucadair) - long list of typo fixes, editorial improvements in abstract, introduction and other chapters. Added section on satellite networks, devices with batteries, power benchmarking and SDN-based forwarding semantics. 02: Minor text edits (med), add pointer to additional Internet-Draft (med), Added co-author pascal (tte), 03: Added Jeff Tantsura as co-author 04: Various textual fixups, added new versions of RFC for references using obsoleted RFCs, so that both original and latest are referenced. 05: Added pointers on analysis and limit scope of document to Dec 2022. 06: Full review and throughout addition of references and context on energy and power-related IETF work, full editorial pass. New co-author. 07: Added security considerations, updated pointers. 08: Independent Submissions Editor (ISE) Review: starting with a thorough editorial pass of fixes and improvements. Clarified motivation and scope (IETF/IRTF/IAB), added authors' observations and lessons learned, emphasized internal audience as first catalog, and applied readability cleanups. 09: ISE Review: Tightened and restructured Section 2 by collapsing subsections and clarifying audience focus; include only technologies with direct energy impact 10: ISE Review: Editorial update, refined language and terminology (e.g., "December 2022" vs. "12/2022"), improving consistency and readability across sections. 11: ISE Review: Reframed the abstract to highlight and make explicit three audiences (insiders, newcomers, and external readers) 12: ISE Review: Addressed substantive ISE feedback throughout the document, including restructuring the Introduction (added scope/citation-approach and roadmap subsections), reframing and expanding several technology discussions, retitling and splitting sections, and adding missing citations and reflection, along with citation, acronym, and grammar corrections.