<?xml version="1.0"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY RFC.2481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2481.xml"> nbsp    "&#160;">
  <!ENTITY RFC.3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"> zwsp   "&#8203;">
  <!ENTITY RFC.3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml"> nbhy   "&#8209;">
  <!ENTITY RFC.7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml">
<!ENTITY RFC.8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC.9330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9330.xml"> wj     "&#8288;">
]>

<?rfc comments="yes"?>
<?rfc compact="no"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-irtf-nmrg-green-ps-06" number="9845" updates="" obsoletes="" consensus="true" xml:lang="en" ipr="trust200902"
    submissionType="IRTF"> submissionType="IRTF" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="5" version="3">

  <front>
    <title abbrev="Management for Green Networking">Challenges and Opportunities in Management for Green Networking</title>
    <seriesInfo name="RFC" value="9845"/>
    <author fullname="Alexander Clemm" initials="A." surname="Clemm" role="editor">
      <organization>Independent</organization>
      <address>
        <postal>
          <city>Los Gatos, CA</city>
            <country>US</country> Gatos</city><region>CA</region>
          <country>United States of America</country>
        </postal>
        <phone></phone>
        <email>ludwig@clemm.org</email>
      </address>
    </author>
    <author fullname="Carlos Pignataro" initials="C." surname="Pignataro" role="editor">
      <organization abbrev="NC State University">North Carolina State University</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>cpignata@gmail.com</email>
        <email>cmpignat@ncsu.edu</email>
      </address>
    </author>
    <author fullname="Cedric Westphal" initials="C" surname="Westphal">
      <address>
        <email>westphal@ieee.org</email>
      </address>
    </author>
    <author fullname="Laurent Ciavaglia" initials="L" surname="Ciavaglia">
      <organization>Nokia</organization>
      <address>
        <email>laurent.ciavaglia@nokia.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
      <organization>Nvidia</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Marie-Paule Odini" initials="M-P" surname="Odini">
      <address>
        <email>mp.odini@orange.fr</email>
      </address>
    </author>
    <date day="16" month="3" year="2025" /> month="August" year="2025"/>

    <workgroup>Network Management</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>
    Reducing humankind's environmental footprint and making technology more
    environmentally sustainable are among the biggest challenges of our age.
    Networks play an important part in this challenge.  On one hand, they
    enable applications that help to reduce this footprint. On the other hand,
    they contribute to this footprint themselves in no insignificant way.
<!--[rfced] In the abstract, rather than "in no insignificant way",
we suggest making the sentence more direct. Is this update acceptable?

Original:
  On the other hand,
  they contribute to this footprint themselves in no insignificant way.

Suggested:
  On the other hand,
  they significantly contribute to this footprint themselves.
-->
    Therefore, methods to make networking technology itself "greener" and to
    manage and operate networks in ways that reduce their environmental
    footprint without impacting their utility need to be explored.  This
    document outlines a corresponding set of opportunities, along with
    associated research challenges, for networking technology in general and
    management technology in particular to become "greener", i.e., more
    sustainable, with reduced greenhouse gas emissions and less negative
    impact on the environment.
      </t>
      <t>
   This document is a product of the Network Management Research Group (NMRG)
   of the Internet Research Task Force (IRTF).  This document reflects the
   consensus of the research group. It is not a candidate for any level of
   Internet Standard and is published for informational purposes.
      </t>
    </abstract>
  </front>
  <middle>
<!--[rfced] Several sentences in the original document that were difficult
to read have been reworded or separated into two sentences. In some cases,
a "FYI" has been added to call your attention to the edit. In general, please
review the edited document closely to make sure that the intended meaning
is intact. In particular, please review Sections 5.3 and 6.1.
-->

    <section anchor="intro" title="Introduction">

<section title="Motivation"> anchor="intro">
      <name>Introduction</name>
      <section>
        <name>Motivation</name>
        <t>
Climate change and the need to curb greenhouse gas (GHG) emissions have been recognized
by the United Nations and by most governments as one of the big challenges of our time.
As a result, curbing those emissions is becoming of
increasing importance
increasingly important for society and for many industries.  The networking industry is no
exception.
</t>
<!--[rfced] FYI, both "CO2" and "carbon" were used within the
same sentence; for consistency, the latter instance has been updated.
Please let us know if you prefer otherwise.

Original:
   Notable here is the use of fossil fuels, such as oil,
   which releases CO2 that had long been removed from the earth's
   atmosphere, as opposed to the use of renewable or sustainable fuels
   that do not "add" to the amount of carbon in the atmosphere.

Current:
   Notable here is the use of fossil fuels, such as oil,
   which releases CO2 that had long been removed from the earth's
   atmosphere, as opposed to the use of renewable or sustainable fuels
   that do not "add" to the amount of CO2 in the atmosphere.
-->
        <t>The science behind greenhouse gas emissions and their relationship with climate change
is complex. However, there is overwhelming scientific consensus pointing towards toward a clear
correlation between climate change and a rising amount of
greenhouse gases in the atmosphere.
One greenhouse gas of particular concern, but by no means the only one, is carbon
dioxide (CO2).  Carbon dioxide is emitted in the process of burning fuels to
generate energy that is used, for example, to power electrical devices such as
networking equipment.  Notable here is the use of fossil fuels, such fuels (such as
oil, which releases CO2 that had has long been removed from the earth's atmosphere, atmosphere),
as opposed to the use of renewable or sustainable fuels that do not "add" to the
amount of carbon CO2 in the atmosphere.
There are additional gases associated with electricity generation, in particular Methane methane (CH4) and Nitrous Oxide nitrous oxide (N2O). Although they exist in smaller quantities, they have an even higher Global Warming Potential (GWP).
</t>
        <t>Greenhouse gas emissions are in turn correlated with the need to power
technology, including networks.  Reducing those emissions can be achieved by reducing the
amount of fossil fuels needed to generate the energy that is needed to power
those networks.
This can be achieved by improving the energy mix to include increasing
amounts of low-carbon and/or renewable (and hence sustainable) energy sources sources, such as wind or solar.
It can also be achieved
by increasing energy savings and improving energy efficiency so that the same outcomes
are achieved while consuming less energy in the first place.
</t>
        <t>The amount of greenhouse gases that an activity adds to the atmosphere, such as CO2 that is emitted in burning fossil fuels to generate the required energy, is also
referred to as greenhouse footprint, the "greenhouse footprint" or carbon footprint the "carbon footprint" (accounting for greenhouses gases other than CO2 in terms of CO2 equivalents).  Reducing this footprint to net-zero net zero is hence a major
sustainability goal. However, sustainability encompasses also other factors beyond carbon,
such as the sustainable use of other natural resources, the preservation of natural habitats
and biodiversity, and the avoidance of any form of pollution.
</t>
        <t>In the context of this document, we refer to networking technology that helps to improve its own networking
sustainability  as "green".  Green, in that sense, includes technology that helps
to lower networking's greenhouse gas emissions including the carbon footprint, which in turn includes technology that helps to increase efficiency and realize energy savings as well as facilitating facilitates managing networks towards toward a
stronger use of renewables.
</t>
<!--[rfced] The phrase "as well as land use" doesn't parse in this
sentence. Is the intended meaning that it minimizes the land area
that is used? Does the suggested text convey the intended meaning?

Original:
   IoT applications that
   facilitate automated monitoring and control from remote sites help
   make agriculture more sustainable by minimizing the application of
   resources such as water and fertilizer as well as land use.

Perhaps:
   IoT applications that facilitate automated monitoring and control from
   remote sites help make agriculture more sustainable by minimizing the
   usage of water, fertilizer, and land area.
-->
        <t>
Arguably, networks can already be considered a "green" technology in that networks enable many applications that allow users and whole industries to save energy and thus
become environmentally more sustainable in a significant way.  For example, they allow (at least to an extent) to substitute travel with teleconferencing.  They enable many employees to work from home and "telecommute", telecommute, thus reducing the need for actual commute. commuting. IoT applications that facilitate automated monitoring and control from remote sites help make agriculture more sustainable by minimizing the application usage of resources such as water water, fertilizer, and fertilizer as well as land use. area.  Networked smart buildings allow for greater energy optimization and sparser use of lighting and HVAC (heating, ventilation, air conditioning) than their non-networked non-networked, not-so-smart counterparts.  That said, calculating precise benefits in terms of net sustainability contributions and savings is complex complex, as a holistic picture involves many effects, effects including substituion substitution effects (perhaps saving on emissions caused by travel but incurring additional cost costs associated with additional home office use) as well as behavioral changes (perhaps a higher number of meetings than if travel were involved).
</t>
        <t>The IETF has recently initiated a reflection on the energy cost of hosting meetings three times a year (see for instance <xref target="IETF-Net0" />). target="IETF-Net0"/>). It conducted a study of the carbon emissions of a typical meeting and found out that 99% of the emissions were due to the air travel. In the same vein, <xref target="Framework" /> target="Framework"/> compared an in-person with a virtual meeting and found a reduction in energy of 66% for a virtual meeting. These findings confirm that networking technology can reduce emissions when acting as a virtual substitution for physical events.
</t>
        <t>
That said, networks themselves consume significant amounts of energy. Therefore, the networking industry has an important role to play in meeting sustainability goals and not just by enabling others to reduce their reliance on energy, energy but by also reducing its own.  Future networking advances will increasingly need to focus on becoming more energy-efficient energy efficient and reducing the carbon footprint, both for economic reasons and for reasons of both corporate responsibility. responsibility and economics. This shift has already begun, and sustainability is already becoming an important concern for network providers. In some cases, such as in the context of networked data centers, the ability to procure enough energy becomes a bottleneck bottleneck, prohibiting further growth growth, and greater sustainability thus becomes a business necessity.
</t>
        <t>
For example, in its annual report, Telefónica reports that in 2021, its network's energy consumption per PB petabyte (PB) of data amounted to 54MWh 54 megawatt-hours (MWh) <xref target="Telefonica2021"/>. This rate has been dramatically decreasing (a seven-fold (by a factor of seven over six years) years), although gains in efficiency are being offset by simultaneous growth in data volume. In the The same report, it is stated as report states that an important corporate goal to continue is continuing on that trajectory and aggressively reduce reducing overall carbon emissions further.
</t>
      </section>
<section title="Approaching
      <section>
        <name>Approaching the Problem</name>

<!-- [rfced] For clarity, may we update this sentence as follows?

Original:
   An often-considered gain in networking sustainability can be made
   with regards to improving the efficiency with which networks utilize
   power during their use phase, reducing the amount of energy that is
   required to provide communication services.

Perhaps:
   Reducing the Problem"> amount of energy that is required to provide
   communication services and improving the efficiency with which
   networks utilize power during that use phase are both often
   considered gains in networking sustainability.

Or:
   As often discussed, networking sustainability can be improved
   by increasing the efficiency with which networks utilize
   power during their use phase, reducing the amount of energy that
   is required to provide communication services.
-->

        <t>
An often-considered gain in networking sustainability can be made with regards to improving the efficiency with which networks utilize power during their use phase, reducing the amount of energy that is required to provide communication services. However, for a holistic approach approach, other aspects need to be considered as well.
</t>
<t>Environmental
        <t>The environmental footprint is determined not determined by energy consumption alone.  The sustainability of power sources needs to be considered as well.  A deployment that includes devices that are less energy-efficient energy efficient but that are powered by a sustainable energy source can arguably be considered "greener" than a deployment that includes highly efficient device devices that are powered by Diesel diesel generators.  In fact, in the same Telefónica report mentioned earlier, extensive reliance on renewable energy sources is emphasized.
</t>

<!--[rfced] In general, please review how the terms "green", "greener",
etc., are used in this document and let us know if any updates are
needed. Specifically:

a) Inconsistent usage of quotation marks in the original

  "green"     3 instances vs. 5 without quotes
  "greener"   7 instances vs. 18 without quotes
  "greenness" 1 instance  vs. 1 without quotes

We note that "greener" is in quotes in the abstract, then used frequently
in the body of the document without quotes. Is there a rationale
for when it is with vs. without quotes?

b) Section 3: "greener" seems redundant with the surrounding text,
in light of the definition of "green" provided in Section 1.1.
May it be removed?

Original:
  for greener, more sustainable, less carbon-intensive networks.

Perhaps simply:
  for more sustainable, less carbon-intensive networks.

c) Section 6.2: Will it be clear to the reader what "green billing and
charging schemes" means?
-->
        <t>Similarly, deployments can take other environmental factors into account that affect the carbon footprint.  For example, deployments in which factors such as where the need for cooling are reduced, is reduced or where excessive heat that is generated by equipment can be put to a productive use, use will be considered greener than deployments where this is not the case. Examples include deployments in cooler natural surroundings (e.g., in colder climates) where that is an option.  Likewise, manufacturing and recycling of networking equipment are also part of the sustainability equation, as the production itself consumes energy and results in a carbon cost embedded as part of the device itself. Extending the lifetime of equipment may in many cases be preferable over replacing it earlier with equipment that is slightly more energy-efficient energy efficient, but that requires the embedded carbon cost to be amortized over a much shorter period of time.
</t>
<t>Management
<!--[rfced] Does "Management" refer to "network management" in the first
sentence of this paragraph? If so, we suggest updating it for clarity.

Original:
   Management has an outsized role to play in approaching those
   problems.

Perhaps:
   Network management has an outsized role to play in approaching
   those problems.
-->

<!--[rfced] For readability and to avoid the odd phrasing "maximize ways
in which they eliminate the use of", we suggest rephrasing as follows.

Original:
   To reduce the amount of energy used, network providers
   need to maximize ways in which they make use of scarce resources and
   eliminate use of resources which are not needed.

Perhaps:
   To reduce the amount of energy used, network providers
   need to eliminate the use of unneeded resources
   and maximize the use of scarce resources.
-->
        <t>Management has an outsized role to play in approaching those problems. To reduce the amount of energy used, network providers need to maximize ways in which they use scarce resources and eliminate the use of unneeded resources. They need to optimize the way in which networks are deployed, which resources are placed where, and how equipment lifecycles and upgrades are being managed - -- all of which constitute classic operational problems. As best practices, methods, and algorithms are developed, they need to be automated to the greatest extent possible and possible, migrated over time into the network network, and performed on increasingly short time scales, timescales, transcending management and control planes.
</t>
      </section>
<section title="Structuring
      <section>
        <name>Structuring the Problem Space"> Space</name>
        <t>
From a technical perspective, multiple vectors along which networks can be made "greener" should be considered:
<list style="symbols">
<t>
Equipment level:<br /><br />Perhaps
</t>
        <ul spacing="normal">
          <li>
            <t>Equipment level:</t>
	    <t>Perhaps the most promising vector for improving networking
	    sustainability concerns the network equipment itself.  At the most
	    fundamental level, networks (even softwarized ones) involve
	    appliances, i.e., equipment that relies on electrical power to
	    perform its function. There are two distinct layers with different
	    opportunities for improvement:

<list style="symbols">
    <t>Hardware: improvement:</t>
            <ul spacing="normal">
<!--[rfced] Please clarify "motions" in this text.
Does it refer to mechanisms, processes, or something else?

Original:
      -  Hardware: Reducing embedded carbon during material extraction
         and manufacturing, improving energy efficiency and reducing
         energy consumption during operations, and reuse, repurpose, and
         recycle motions.

Perhaps:
      -  Hardware: Reducing embedded carbon during material extraction
         and manufacturing; improving energy efficiency and reducing
         energy consumption during operations; and improving mechanisms
         for reusing, repurposing, and recycling hardware.
-->
              <li>
                <t>Hardware: Reducing embedded carbon during material
                extraction and manufacturing, improving energy efficiency, and
                reducing energy consumption during operations, and reuse,
                repurpose, and recycle motions.</t>
              </li>
              <li>
                <t>Software: Improving software energy efficiency, maximizing
                utilization of processing devices, and allowing for software to
                interact with hardware to improve sustainability.</t>
</list>

Beyond
              </li>
            </ul>
            <t>Beyond making network appliances merely more energy-efficient, energy efficient,
            there are other important ways in which equipment can help
            networks become greener.  This includes aspects such as support for supporting
            port power saving power-saving modes or down-speeding of links to reduce
            power consumption for resources that are not fully utilized.  To
            fully tap into the potential of such features, it requires
            accompanying management functionality, for example, to determine
            when it is "safe" to down-speed a link or to enter a power-saving
            mode, and to maximize the conditions when that action is appropriate.
            </t>
<!--[rfced] FYI, this has been rephrased for clarity. Specifically,
this removes the redundancy of "management functionality" and
"manage the network".

Original:
      To fully tap into the potential of such features requires
      accompanying management functionality, for example to determine
      when it is "safe" to down-speed a link or enter a power saving
      mode, and manage the network in such a way that conditions to do
      so are maximized.

<br /><br />
Most importantly

Current:
      To tap into the potential of such features, it requires accompanying
      management functionality, for example, to determine when it is
      "safe" to down-speed a link or to enter a power-saving mode, and
      to maximize the conditions when that action is appropriate.
-->
	    <t>Most importantly, from a management perspective, improving
	    sustainability at the equipment level involves providing
	    management instrumentation that allows to precisely monitor for precise monitoring and manage
	    managing power usage and doing so at different levels of
	    granularity, for example example, accounting separately for the
	    contributions of CPU, memory, and different ports. This enables
	    (for example) controller applications to optimize energy usage
	    across the network and that to leverage control loops to assess the
	    effectiveness (e.g. (e.g., in terms of reduction in reducing power use) of
	    the measures that are taken.

<br /><br />
As taken.</t>
	    <t>As a side note, the terms "device" and "equipment", as used in
	    the context of this draft, document, are used to refer to networking
	    equipment.  We are not taking into consideration end-user devices
	    and endpoints such as mobile phones or computing equipment.
</t>
<t>
Protocol level:<br /><br />Energy-efficiency equipment.</t>
          </li>
          <li>
            <t>Protocol level:</t>
	    <t>Energy-efficiency and greenness are aspects that are rarely
	    considered when designing network protocols.  This suggests that
	    there may be plenty of untapped potential.  Some aspects involve
	    designing protocols in ways that reduce the need for redundant or
	    wasteful transmission of data to allow data, allowing not only for better network utilization,
	    utilization but for greater goodput per unit of energy being
	    consumed.  Techniques might include approaches that reduce the
	    "header tax" incurred by payloads as well as methods resulting in
	    the reduction of wasteful retransmissions.  Similarly, there may
	    be cases where chattiness of protocols may be preventing equipment
	    from going into sleep mode.  Designing protocols that reduce
	    chattiness in such scenarios, for example, that reduce dependence
	    on periodic updates or heartbeats, may result in greener
	    outcomes. Likewise, aspects such as restructuring addresses in
	    ways that allow to minimize the size of lookup tables and tables,
	    associated memory sizes sizes, and hence energy use use, can play a role as well. <br /><br />
Another
	    well.</t>
	    <t>Another role of protocols concerns the enabling
	    of management functionality to improve energy efficiency at the
	    network level, such as discovery protocols that allow for quick
	    adaptation to network components being taken dynamically into and
	    out of service depending on network conditions, as well as
	    protocols that can assist with functions such as the collection of
	    energy telemetry data from the network.
</t>
<t>
Network level<br /><br />Perhaps network.</t>
          </li>
          <li>
            <t>Network level:</t>
<!--[rfced] Please review the intended meaning of this sentence.
Instead of "and", should it be "because"?
Also, would 'rated less "green"' be more clear with a rephrase?

Original:
      Likewise, some networking devices may be
      rated less "green" and more power-intensive than others or
      powered by less-sustainable energy sources.

Perhaps:
      Likewise, some networking devices may be
      given a lower sustainability rating because they are
      more power-intensive or are using less-sustainable energy sources.
-->
	    <t>Perhaps the greatest opportunities to realize power savings
	    exist at the level of the network as whole. Many of these
	    opportunities are directly related to management
	    functionality. For example, optimizing energy efficiency may
	    involve directing traffic in such a way that it allows for the
	    isolation of equipment that might not be needed at certain moments
	    so that it can be powered down or brought into power-saving
	    mode. By the same token, traffic should be directed in a way that
	    requires bringing additional equipment online or out of
	    power-saving mode in cases where alternative traffic paths are
	    available for which the incremental energy cost would amount to
	    zero.  Likewise, some networking devices may be rated less "green"
	    and more power-intensive than others or may be powered by
	    less-sustainable energy sources.  Their use might be avoided unless
	    except during periods of peak capacity demands.  Generally,
	    incremental carbon emissions can be viewed as a cost metric that
	    networks should strive to minimize and consider as part of routing
	    and of network path optimization.
</t>
<t>
Architecture level<br /><br />The optimization.</t>
          </li>
          <li>
            <t>Architecture level:</t>
	    <t>The current network architecture supports a wide range of applications,
	    applications but does not consider energy efficiency as one of
	    its design parameters. One can argue that the most energy
	    efficient shift of the last two decades has been the deployment of
	    Content Delivery Network overlays: while these were set up to
	    reduce latency and minimize bandwidth consumption, from a network
	    perspective, retrieving the content from a local cache is also
	    much greener.  What other architectural shifts can produce energy
	    consumption reduction?
</t>
</list>
</t>
<t>
In reduction?</t>
          </li>
        </ul>
        <t>In this document, we will explore each of those vectors in further detail and attempt to articulate specific challenges that could make a difference when addressed.  As our starting point, we borrow some material from a prior paper, "Challenges and Opportunities in Green Networking" <xref target="GreenNet22"/>. For this document, this 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).
</t>
        <t>
This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF).  This document reflects the consensus of the research group and was discussed and presented multiple times, each time receiving positive feedback and no objections. It is not a candidate for any level of Internet Standard and is published for informational purposes.
</t>
      </section>
    </section>

	<section title="Definitions
    <section>
      <name>Definitions and Acronyms">

<t>
Below Acronyms</name>
      <t>Below you find acronyms used in this draft:
<list style="hanging" hangIndent='7'>

<t hangText="Carbon Footprint:"><br />As document:  </t>
      <dl newline="false" spacing="normal">
        <dt>Carbon Footprint:</dt>
        <dd>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</t>
<t hangText="CDN:">Content consumption</dd>
        <dt>CDN:</dt>
        <dd>Content Delivery Network</t>
<t hangText="CPU:">Central Network</dd>
        <dt>CPU:</dt>
        <dd>Central Processing Unit, that is Unit (that is, the main processor in a server</t>
<t hangText="DC:">Data Center</t>
<t hangText="FCT:">Flow server)</dd>
        <dt>DC:</dt>
        <dd>Data Center</dd>
        <dt>FCT:</dt>
        <dd>Flow Completion Time</t>
<t hangText="GHG:">Greenhouse Gas</t>
<t hangText="GPU:">Graphical Time</dd>
        <dt>GHG:</dt>
        <dd>Greenhouse Gas</dd>
        <dt>GPU:</dt>
        <dd>Graphical Processing Unit</t>
<t hangText="HVAC:">Heating, Unit</dd>
        <dt>HVAC:</dt>
        <dd>Heating, Ventilation, Air Conditioning</t>
<t hangText="ICN:">Information Centric Network</t>
<t hangText="IGP:">Interior Conditioning</dd>
        <dt>ICN:</dt>
        <dd>Information-Centric Network</dd>
        <dt>IGP:</dt>
        <dd>Interior Gateway Protocol</t>
<t hangText="IoT:">Internet of Things</t>
<t hangText="IPU:">Infrastructure Protocol</dd>
        <dt>IoT:</dt>
        <dd>Internet of Things</dd>

        <dt>IPU:</dt>
        <dd>Infrastructure Processing Units</t>
<t hangText="LEED:">Leadership Unit</dd>
        <dt>LEED:</dt>
        <dd>Leadership in Energy and Environmental Design, a Design (a green building rating system</t>
<t hangText="LEO:">Low system)</dd>
        <dt>LEO:</dt>
        <dd>Low Earth Orbit</t>
<t hangText="LPM:">Longest Orbit</dd>
        <dt>LPM:</dt>
        <dd>Longest Prefix Match, a Match (a method to look up prefixes in a forwarding element</t>
<t hangText="MPLS:">Multi-Path element)</dd>
        <dt>MPLS:</dt>
        <dd>Multiprotocol Label Switchin</t>
<t hangText="MTU:">Maximum Switching</dd>
        <dt>MTU:</dt>
        <dd>Maximum Transmission Unit, the Unit (the largest packet size that can be transmitted over a network</t>
<t hangText="NIC:">Network network)</dd>
        <dt>NIC:</dt>
        <dd>Network Interface Card</t>
<t hangText="QoE:">Quality of Experience</t>
<t hangText="QoS:">Quality of Service</t>
<t hangText="QUIC:">Quick Card</dd>
        <dt>QoE:</dt>
        <dd>Quality of Experience</dd>
        <dt>QoS:</dt>
        <dd>Quality of Service</dd>
<!--[rfced] Regarding "Definitions and Acronyms":

a) Does "IPU" refer to Intel's IPU specifically?
If so, we suggest updating the definition or the usage within the
document (one instance). Searches for this term outside the
RFC series (e.g., on dl.acm.org, ieeexplore.ieee.org) give
results such as "Intel's IPU".

Current:
   IPU:  Infrastructure Processing Unit

b) Regarding the expansion of "QUIC". We were told by the
QUIC WG of the IETF that it is not an acronym. May this entry be
updated as follows or otherwise? Also, would you like to add
RFC 9000 as an informative reference?

Original:
   QUIC:  Quick UDP Internet Connections

Perhaps:
   QUIC: the name of a UDP-based, stream-multiplexing, encrypted
         transport protocol.

c) FYI, we removed SNIC from this list because it is not
used within this document. There is one instance of "SmartNICs"
that remains in the document.

Original:
   SNIC:  Smart NIC
-->
        <dt>QUIC:</dt>
        <dd>Quick UDP Internet Connections</t>
<t hangText="SNIC:">Smart NIC</t>
<t hangText="SDN:">Software-Defined Networking</t>
<t hangText="TCP:">Transport Connections</dd>
        <dt>SDN:</dt>
        <dd>Software-Defined Networking</dd>
        <dt>TCP:</dt>
        <dd>Transport Control Protocol</t>
<t hangText="TE:">Traffic Engineering</t>
<t hangText="TPU:">Tensor Protocol</dd>
        <dt>TE:</dt>
        <dd>Traffic Engineering</dd>
        <dt>TPU:</dt>
        <dd>Tensor Processing Unit</t>
<t hangText="WAN:">Wide Unit</dd>
        <dt>WAN:</dt>
        <dd>Wide Area Network</t>

</list>
</t> Network</dd>
      </dl>
    </section>
    <!--
<section title="The Dynamics of Combining Sustainability and Network Management">
<t>
    As it was mentioned and will be further explored in detail, improving energy efficiency is a key way to improve sustainability. However, this process and reduction is only meaningful within its larger context.
</t>
<t>
    There is a duality and dialectic in this interaction. First, in order to provide those hardware and software improvements, research and development need to take place, which bring their own carbon footprint. Further, if the improvement is in a much more energy efficient Chip, CPU, GPU, or piece of hardware, deploying the next generation of hardware (material acquisition, manufacturing, supply-chain, transportation) and end-of-lifing the older generation creates and added carbon footprint. Consequently, there are values that maximize sustainability at a global basis, which are neither at both ends: it is not about leaving old hardware and software for overextended periods, and it is also not about replacing and rearchitecting weekly.
</t>
<t>
    Similarly, at the protocol and architectural levels there is an equivalent duality: what is the "sweet-spot" on which protocols can be improved (for them to be less energy-wastful), and when to use protocol interactions (e.g., extensions) to carry sustainability data and information (i.e., sustainability telemetry and metrics) and to execute actions.
</t>
<t>
    Finally, there needs to be given consideration to Jevons paradox, particularly as the energy efficiency optimization (in hardware as well as in software) can bring important operational savings in cost.
</t>
</section>
-->

<section title="Network anchor="sec_implications">
      <name>Network Energy Consumption Characteristics and Implications" anchor="sec:implications"> Implications</name>
      <t>
Carbon
The carbon footprint and, with it, greenhouse gas emissions are determined by several factors. A main factor is network energy consumption, as the energy consumed can be considered a proxy for the burning of fuels required for corresponding power generation.  Network energy consumption by itself does not tell the whole story, as it does not take the sustainability of energy sources and the energy mix into account.  Likewise, there are other factors such as hidden carbon cost reflecting the carbon footprint cost expended in the manufacturing of networking hardware.  Nonetheless, network energy consumption is an excellent predictor for of a carbon footprint and its reduction reduction, which is key to sustainable solutions.  Exploring  Hence, exploring possibilities to improve energy efficiency is hence a key factor for greener, more sustainable, less carbon-intensive networks.
</t>
<t>For this, it
      <t>It is important to understand some of the characteristics of power consumption by networks and which aspects contribute the most.  This helps to identify where the greatest potential is, not just for power savings but also for sustainability improvements lies. improvements.
</t>
      <t>
Power is ultimately drawn by devices.  Devices are not monoliths but are composed of multiple components. The power consumption of the device can be divided into the consumption of the core device - -- the backplane and CPU, if you will - -- as well as additional consumption incurred per port and line card.  In addition,  the GPU and TPU may be used as well in the network and may have different power consumption profiles.
Furthermore, it is important to understand the difference between power consumption when a resource is idling versus when it is under load. This helps to understand the incremental cost of additional transmission versus the initial cost of transmission.
</t>
      <t>
In typical networking devices, only roughly half of the energy consumption is associated with the data plane <xref target="Bolla2011energy"/>.
An idle base system typically consumes more than half of the energy over that the same system would consume when running at full load <xref target="Chabarek08"/>, target="Chabarek08"/> <xref target="Cervero19"/>. target="Cervero15"/>.
Generally, the cost of sending the first bit is very high, as it requires powering up a device, port, etc.
The incremental energy cost of transmission of additional bits (beyond the first) is many orders of magnitude lower. Likewise, the incremental cost of the incremental CPU and memory needed to process additional packets becomes fairly negligible.
</t>
      <t> This means that a device's energy consumption does not increase linearly with the volume of forwarded traffic.  Instead, it resembles more of a step function in which energy consumption stays roughly the same up to a certain volume of traffic, followed by a sudden jump when additional resources need to be procured to support a higher volume of traffic.
</t>
      <t>
By the same token, it is generally more energy-efficient energy efficient to transmit a large volume of data in one burst (and subsequently turning turn off or down-speeding down-speed the interface when idling) than to continuously transmit at a lower rate. In that sense sense, it can be the duration of the transmission that dominates the energy consumption, consumption -- not the actual data rate.
</t>
      <t>
The implications on 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 allow to reduce peak traffic spikes and thus 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. (e.g., routing traffic across more costly but less utilized routes) or over time (e.g. (e.g., postponing and buffering non-urgent traffic).
</t>
      <t>Likewise, large gains can be made whenever network resources can effectively be taken offline for at least some of the time, managing networks in a way that enables resources to be removed from service so they can be powered down (or put into a more energy-saving state, such as when down-speeding ports) while not needed.  Of course, any such methods need to take into account the overhead of taking resources offline and bringing them back online.  This typically takes some amount of time, requiring accurate predictive capabilities to avoid situations in which network resources are not available at times when they would be needed.  In addition, there is additional overhead overhead, such as synchronization of state state, to be accounted for.
</t>
      <t>
At the same time, any non-idle resources should be utilized to the greatest extent possible possible, as the incremental energy cost is negligible. Of course, this needs to occur while still taking other operational goals into consideration, such as protection against failures (allowing for readily available redundancy and spare capacity in case of failure) and load balancing (for increased operational robustness).
As data transmission needs tend to fluctuate wildly and occur in bursts, any optimization schemes need to be highly adaptable and allow for control loops at very fast time scales.
</t>
      <t>
Similarly, for applications where this is possible, it may be desirable to replace continuous traffic at low data rates with traffic that is sent in burst bursts at high data rates in order to potentially maximize the time during which resources can be idled.
</t>

<t>
<!--[rfced] For readability, may this sentence be rephrased as follows?
Specifically, we suggest rephrasing "emphasis needs to be given to technology"
and making the sentence into shorter ones.

Original:
   As a result, emphasis needs to be given to technology that allows for
   example to (at the device level) exercise very efficient and rapid
   discovery, monitoring, and control of networking resources so that
   they can be dynamically be taken offline or back into service,
   without (at the network level) requiring extensive convergence of
   state across the network or recalculation of routes and other
   optimization problems, and (at the network equipment level) support
   rapid power cycle and initialization schemes.

Perhaps:
   As a result, we should prioritize technology that efficiently
   discovers, monitors, and controls networking resources at the device
   level.  This allows devices to be dynamically taken offline or brought
   back online without extensive network-level state convergence, route
   recalculation, or other complex optimizations.  At the network equipment
   level, it should also support rapid power cycling and initialization.

Or:
   Technology that has the following characteristics should be prioritized:
   *  At the device level, it does efficient and rapid discovery, monitoring,
      and control of networking resources so they can be dynamically taken
      offline or online.
   *  At the network level, it does not require extensive convergence of
      state across the network or recalculation of routes and other
      optimization problems.
   *  At the network equipment level, it supports rapid power cycle and
      initialization schemes.
-->
<t>
As a result, emphasis needs to be given to technology that allows, for example, (at the device level) very efficient and rapid discovery, monitoring, and control of networking resources so that they can be dynamically taken offline or brought back in service without (at the network level) requiring an extensive convergence of state across the network or a recalculation of routes and other optimization problems, and (at the network equipment level) support rapid power cycle and initialization schemes.  There may be some lessons that can be applied here from IoT,
which has long had to contend with power-constrained end devices that need to spend much of their time in power saving power-saving states to conserve battery.
</t>
    </section>
    <section title="Challenges anchor="sec_device">
      <name>Challenges and Opportunities - Equipment Level" anchor="sec:device"> Level</name>
      <t>
We are categorizing challenges and opportunities to improve sustainability at the network equipment level along the following lines:
<list style="symbols">
</t>
      <ul spacing="normal">
        <li>
          <t>Hardware and manufacturing. manufacturing: Related opportunities are arguably among the most obvious and perhaps "largest". However, solutions here lie largely outside the scope of networking researchers. </t>
        </li>
        <li>
          <t>Visibility and instrumentation. instrumentation: Instrumenting equipment to provide visibility into how they consume energy is key to management solutions and control loops to facilitate optimization schemes. </t>
</list>
</t>
        </li>
      </ul>
      <section title="Hardware anchor="sec_hw_and_man">
        <name>Hardware and Manufacturing"> Manufacturing</name>
        <t>
<!--[rfced] Please clarify the phrase "eco-friendly to deploy";
could a more precise term than "eco-friendly" be used in this context?

Original:
   Making such equipment more power efficient, have it dissipate less
   heat to consume less energy and reduce the need for cooling, making
   it eco-friendly to deploy, sourcing sustainable materials and
   facilitating recycling of equipment at the end of its lifecycle all
   contribute to making networks greener.
-->
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 such equipment more power efficient, have having it dissipate less heat to consume less energy and reduce the need for cooling, making it eco-friendly to deploy, sourcing sustainable materials materials, and facilitating the recycling of equipment at the end of its lifecycle -- all contribute to making networks greener.  More specific and unique to networking are schemes to reduce
Reducing the energy usage of transmission technology technology, from wireless (antennas) to optical (lasers). (lasers), is a strategy that is unique to networking.
</t>
        <t>One critical aspect of the energy cost of networking is the cost to manufacture and deploy the networking equipment. In addition, even the development process itself comes with its own carbon footprint.  This is outside of the scope of this document: we only consider the energy cost of running the network that applies during the operational part of the equipment's lifecycle. However, a holistic approach would include into this the embedded energy that is included in the networking equipment. As part of this, aspects such as the impact of deploying new protocols on the rate of obsolescence of existing equipment should be considered. For instance, incremental approaches that do not require to replace replacing equipment right away - -- or even that extend the lifetime of deployed equipment - -- would have a lower energy footprint.  This is one important benefit also of technologies such as Software-Defined Networking and Network Function Virtualization, network function virtualization, as they may allow support of for new networking features through software updates without requiring hardware replacements.
</t>
<t>An
        <t><xref target="Emergy"/> describes an attempt to compute not only the energy of running a network, network but also the energy embedded into manufacturing the equipment is described in <xref target="Emergy"/> . equipment. This is denoted by "emergy", a portmanteau for embedded energy. Likewise, <xref target="Junkyard"/> describes an approach to recycling equipment and a proof of concept using old cell mobile phones recycled into a "junkyard" data center are described in <xref target="Junkyard"/>. center.
</t>
        <t>One trade-off to consider at this level is the selection of a platform that can be hardware-optimized for energy efficiency vs versus a platform that is versatile and can run multiple functions. For instance, a switch could run on an efficient hardware platform, platform or run as a software module (container) over some multi-purpose multipurpose platform. While the first one is operationally more energy efficient, it may have a higher embedded energy from a smaller scale, a less efficient production process, as well as a shorter shelf life once new functions need to be added to the platform.
</t>
      </section>
      <section title="Visibility anchor="sec_instrum">
        <name>Visibility and Instrumentation" anchor="sec:instrum"> Instrumentation</name>
        <t>
Beyond "first-order" opportunities opportunities, as outlined in the previous subsection, <xref target="sec_hw_and_man"/>, network equipment just as importantly plays an important a role to enable in enabling and support supporting green networking at other levels. Of prime importance is the equipment's ability to provide visibility to the management and control plane planes into its current energy usage. Such visibility enables control loops for energy optimization schemes, allowing applications to obtain feedback regarding the energy implications of their actions, from setting up paths across the network that require the least incremental amount of energy to quantifying metrics related to energy cost used to optimize forwarding decisions. Absent an actual measurement of energy usage (and until such measurement is put in place), the network equipment could advertise some proxy of its power consumption (say, consumption. For example, it could use a labelling labeling scheme as of silver, gold, or platinum similar to the LEED sustainability metric in building codes codes, or the Energy Star label in home appliances; appliances, or a description of the type of the device as using CPU vs vs. GPU vs vs. TPU processors with different power profiles). profiles.
</t>
        <t>
One prerequisite to such schemes is to have proper instrumentation in place that allows to monitor for monitoring current power consumption at the level of networking devices as a whole, line cards, and individual ports.  Such instrumentation should also allow to assess for assessing the energy efficiency and carbon footprint of the device as a whole. In addition, it will be desirable to relate this power consumption to data rates as well as and to current traffic, for example, to indicate current energy consumption relative to interface speeds, as well as for incremental energy consumption that is expected for incremental traffic (to aid control schemes that aim to "shave" power off current services or to minimize the incremental use of power for additional traffic).  This is an area where the current state of the art is sorely lacking lacking, and standardization lags behind.  For example, as of today, standardized YANG data models <xref target="RFC7950"/> for network energy consumption that can be used in conjunction with management and control protocols have yet to be defined.
</t>
        <t>To remedy this situation, efforts to define sets of green networking metrics <xref target="I.D.draft-cx-green-green-metrics"/> target="I-D.cx-green-green-metrics"/> as well as YANG data models that include objects that provide visibility into power measurements (e.g. (e.g., <xref target="I.D.draft-li-green-power"/>) are getting underway. target="I-D.li-green-power"/>) were underway in 2024.  Agreed sets of metrics and corresponding data models will provide the basis for further steps, beginning with their implementation as part of management and control instrumentation.
</t>
        <t>
Instrumentation should also take into account the possibility of virtualization, introducing layers of indirection to assess the actual energy usage. For example, virtualized networking functions could be hosted on containers or virtual machines which that are hosted on a CPU in a data center instead of a regular network appliance such as a router or a switch, leading to very different power consumption characteristics. For example, a data center CPU CPU's power consumption could be more power efficient and consume power more proportionally proportional to actual CPU load. Instrumentation needs to reflect these facts and facilitate attributing power consumption in a correct manner.
</t>
        <t>
Beyond monitoring and providing visibility into power consumption, control knobs are needed to configure energy saving energy-saving policies. For instance, power saving power-saving modes are common in endpoints (such as mobile phones or notebook computers) but sorely lacking in networking equipment.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Basic equipment categorization as "energy-efficient" "energy efficient" (or not) as a first step to identify immediate potential improvements, akin to the EnergyStar Energy Star program from the US's Environmental Protection Agency. </t>
          </li>
          <li>
            <t>Equipment instrumentation advances for improved energy-awareness; energy awareness; definition and standardization of granular management information.</t>
          </li>
          <li>
            <t>Virtualized energy and carbon metrics and assessment of their effectiveness in solutions that optimize carbon footprint also footprints in virtualized environments (including SDN, network slicing, network function virtualization, etc.). </t>
          </li>
          <li>
            <t>Certification and compliance assessment methods that ensure that green instrumentation cannot be manipulated to give false and misleading data.</t>
    <t>Methods
          </li>
          <li>
<!--[rfced] FYI, "energy mix powering equipment" has been
updated as follows. Please review whether it conveys the intended
meaning.

Original:
   *  Methods that allow to account for energy mix powering equipment,
      to facilitate solutions that optimize carbon footprint and
      minimize pollution beyond mere energy efficiency [Hossain2019].

Current:
   *  Methods that account for equipment that powers an energy mix, to
      facilitate solutions that optimize carbon footprint and minimize
      pollution beyond mere energy efficiency [Hossain2019].
-->
            <t>Methods that account for equipment that powers an energy mix, to facilitate solutions that optimize carbon footprint and minimize pollution beyond mere energy efficiency <xref target="Hossain2019"/>.</t>
</list>
</t>
          </li>
        </ul>
      </section>
    </section>
    <section title="Challenges anchor="sec_protocol">
      <name>Challenges and Opportunities - Protocol Level" anchor="sec:protocol"> Level</name>
      <t>
There are several opportunities to improve network sustainability at the protocol level.  We characterize them along several categories. level, which can be categorized as follows. The first and arguably most impactful category concerns protocols that enable carbon footprint optimization schemes at the network level and management towards those goals. Other categories concern protocols designed to optimize data transmission rates under energy considerations, protocols designed to reduce the volume of data to be transmitted, and protocol aspects related to network addressing schemes. While those categories may be less impactful, even areas with smaller gains should not be left unexplored. explored.
</t>
      <t>
There is also substantial work in the area of IoT, which has had to contend with
energy-constrained devices for a long time.  Much of that work was motivated not
by sustainability concerns but practical concerns such as battery life.  However,
many aspects appear to also apply in the context of sustainability, such as reducing
chattiness to allow IoT equipment to go into low-power mode.  Accordingly, there is
an opportunity to extend IoT work to more generalized scenarios.  The
 	   use of power-constrained protocols into in the wider Internet happens
 	   regularly.  For instance, ARM-based chipsets initially designed for
 	   energy-efficiency
 	   energy efficiency in battery-operated mobile devices have been
 	   embraced in data centers for a similar trajectory.
</t>
      <section title="Protocol anchor="NetworkEnergySaving">
        <name>Protocol Enablers for Carbon Optimization Mechanisms" anchor="NetworkEnergySaving"> Mechanisms</name>
        <t>
As will be discussed in <xref target="sec:network"/>, target="sec_network"/>, energy-aware and pollution-aware schemes can help improve network sustainability but require awareness of related data.  To facilitate such schemes, protocols are needed that are able to discover what links are available along with their energy efficiency. For instance, links may be turned off in order to save energy and turned back on based upon the elasticity of the demand. Protocols should be devised to discover when this happens, happens and to have a dynamic view of the topology that is consistent keeps up with frequent topology updates due to power cycling of the network resources.
</t>
        <t>
Also, protocols are required to quickly converge onto an energy-efficient path once a new topology is created by turning links on/off. Current routing protocols may provide for fast recovery in the case of failure. However, failures are hopefully relatively rare events, while we expect an energy efficient energy-efficient network to aggressively try to turn off links.  There may be synergies with time-variant routing Time-Variant Routing <xref target="I.D.draft-ietf-tvr-requirements"/> target="I-D.ietf-tvr-requirements"/> that can be explored, in which the topology varies over time with nodes and links turned on or off according to a schedule. There may even be overlaps in use cases, for example in cases where example, when regular changes in the energy mix (and hence carbon footprint) of some nodes occur that coincide with the time of day (such as switching from solar to fossil fuels at night).
</t>
        <t>
Some mechanism is needed to present to the management layer a view of the network that identifies opportunities to turn resources off (routers/links) resources (e.g., routers or links) while still providing an acceptable level of Quality of Experience (QoE) to the users. This gets more complex as the level of QoE shifts from the current Best Effort best-effort delivery model to more sophisticated mechanisms with, for instance, latency, bandwidth bandwidth, or reliability guarantees.
</t>
        <t>Similarly, schemes might be devised in which links across paths with a favorable energy mix are preferred over other paths. This implies that the discovery of topology should be able support corresponding parameters.  More generally speaking, any mechanism that provides applications with network visibility is a candidate for scrutinization as to whether it should be extended to provide support for sustainability-related parameters.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Protocol advances to enable rapidly taking down, bring bringing back online, and discover discovering availability and power saving power-saving status of networking resources while minimizing the need for reconvergence and propagation of state.</t>
          </li>
          <li>
            <t>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.  </t>
</list>
</t>
          </li>
        </ul>
        <!-- CW: QoS, QoE and then EoS Energy of Service? -->
</section>
      <!-- End of Enabling Energy Saving Mechanisms subsection-->

<!--[rfced] FYI, we updated these terms as follows, based on their
usage in other documents (including on ieeexplore.ieee.org and
dl.acm.org). Please review. Also, we removed "(MLU)" because
the acronym is not used within this document.

Original:
  Maximal Link Utilization (MLU)
  minimal link utilization

Current:
  Maximum Link Utilization
  Minimum Link Utilization
-->
<section title="Protocol Optimization" anchor="TrafficAdaptation">
        <name>Protocol Optimization</name>
        <t>
The second category involves designing protocols in such a way that the rate of transmission is chosen to maximize energy efficiency.  For example, Traffic Engineering (TE) can be manipulated to impact the rate adaptation mechanism <xref target="Ren2018jordan"/>. By choosing where to send the traffic, TE can artificially congest links so as to trigger rate adaptation and therefore reduce the total amount of traffic. Most TE systems attempt to minimize Maximal Maximum Link Utilization (MLU) but energy saving energy-saving mechanisms could decide to do the opposite (maximize minimal link utilization) (i.e., maximize Minimum Link Utilization) and attempt to turn off some resources to save power.
</t>
<!--[rfced] FYI, we updated "in the limit" to "in an extreme case"
here. Please let us know if that is not the intended meaning.

Current:
   This should be done
   carefully: in an extreme case, a high rate of transmission over a
   short period of time may create bursts that the network would need to
   accommodate, with all attendant complications of bursty traffic.
-->
        <t>Another example is to set up the proper rate of transmission to minimize the flow completion time (FCT) so as to enable opportunities to turn off links. In a wireless context, <xref target="TradeOff" /> target="TradeOff"/> studies how setting the proper initial value for the congestion window can reduce the FCT and therefore allow the equipment to go faster into a low-energy mode. By sending the data faster, the energy cost can be significantly reduced. This is a simple proof of concept, but protocols that allow for turning links into a low-power mode by transmitting the data over shorter periods could be designed for other types of networks beyond Wi-Fi access. This should be done carefully: in the limit, an extreme case, a high rate of transmission over a short period of time may create bursts that the network would need to accommodate, with all attendant complications of bursty traffic. We conjecture there is a sweet spot between trying to complete flows faster while controlling for burstiness in the network. It is probably advisable to attempt to send traffic paced yet in bulk rather than spread out over multiple round trips. This is an area of worthwhile exploration.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>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 smoothen smooth it out over longer periods.  </t>
          </li>
          <li>
            <t>Protocol advances that allow to optimize for optimizing link utilization according to different goals and strategies (including maximizing minimal link utilization vs Minimal Link Utilization vs. minimizing maximal link utilization, Maximal Link Utilization, etc.)</t>
          </li>
          <li>
            <t>Assessments of the carbon impact of such strategies.</t>
</list>
</t>
          </li>
        </ul>
        <!-- CW: most transport protocols attempt to find the operating point where traffic is sent without dropping packet. TCPs seesaw mechanism is rather crude for this purpose. New protocols such as BBR should be more efficient in that respect. I feel this section can be beefed up a bit. Also we can circle back to your point in the intro that bursty transmission of traffic is more energy efficient. This is true at the edge only, I would assume, since bursts are multiplexed in the core. That said: having some burst when there are few flows, and then some more fluid behavior when there are many could be suggested. For instance, having some "energy gateway" that buffers the burst from the domain with few flows and then transmit them to the domain with more flows, and back on the other end of the connection -->
</section>
      <section title="Data Volume Reduction" anchor="DataVolume">
        <name>Data Volume Reduction</name>
<!--[rfced] For the ease of the reader, would you like to
add a definition for "Shannon limit"? For example, perhaps
it's referring to [Shannon] as referenced in RFC 6386.

Original:
   At the application layer, protocols may also use
   coding mechanisms that encode information close to the Shannon limit.
-->

<!--[rfced] FYI, we updated this sentence as follows to clarify
"(of course being offset by increasingly higher resolution)"; please
review. Is it accurate the savings are offset by the energy demands of
increasingly higher resolution?

Original:
   Currently, most of the traffic over the Internet consists of video
   streaming and encoders for video are already quite efficient and keep
   improving all the time, resulting in energy savings as one of many
   advantages (of course being offset by increasingly higher
   resolution).

Current:
   Currently, most of the traffic over the Internet consists of video
   streaming, and video encoders are already quite efficient and keep
   improving all the time.  This results in energy savings as one of
   many advantages, although of course the savings are offset by
   increasingly higher resolution.
-->
        <t>
The first third category involves designing protocols in such a way that they reduce the volume of data that needs to be transmitted for any given purpose. Loosely speaking, by reducing this volume, more traffic can be served by the same amount of networking infrastructure, hence reducing overall energy consumption. Possibilities here include protocols that avoid unnecessary retransmissions.  At the application layer, protocols may also use coding mechanisms that encode information close to the Shannon limit.  Currently, most of the traffic over the Internet consists of video streaming streaming, and encoders for video encoders are already quite efficient and keep improving all the time, resulting time. This results in energy savings as one of many advantages (of advantages, although of course being the savings are offset by increasingly higher resolution). However, it resolution. It is not clear that the extra work to achieve higher compression ratios for the payloads results in a net energy gain: what is saved over the network may be offset by the compression/decompression effort. Further research on this aspect is necessary.
</t>
        <t>At the transport protocol layer, TCP and to some extent QUIC react to congestion by dropping packets. This is a highly an extremely energy inefficient method to signal congestion, since congestion because (a) the network has to wait one RTT to be aware that the congestion has occurred, and since (b) the effort to transmit the packet from the source up until it is dropped ends up being wasted.  This calls for new transport protocols that react to congestion without dropping packets. ECN <xref target="RFC2481"/> is a possible solution, however, it is not widely deployed. DC-TCP DCTCP <xref target="Alizadeh2010DCTCP"/> is tuned for Data Centers, L4S data centers; Low Latency, Low Loss, and Scalable Throughput (L4S) is an attempt to port similar functionality to the Internet <xref target="RFC9330"/>. Qualitative Communication <xref target="QUAL"/> <xref target="Westphal2021qualitative"/> allows the nodes to react to congestion by dropping only some of the data in the packet, thereby only partially wasting the resource consumed by transmitted the packet up to this that point.  Novel transport protocols for the WAN can ensure that no energy is wasted transmitting packets that will be eventually dropped.
</t>
        <t>Another solution to reduce the bandwidth of network protocols is by reducing their header tax, for example example, by applying header compression. An example in IETF is RObust Header Compression (ROHC) <xref target="RFC3095"/>. Again, reducing protocol header size saves energy to forward packets, but at the cost of maintaining a state for compression/decompression, plus computing these operations. The gain from such protocol optimization further depends on the application and whether it sends packets with (a) large payloads close to the MTU (the MTU, thus limiting the header tax and any savings here are very limited), savings, or whether it sends packets with (b) very small payload size (making size, thus increasing the header tax more pronounced and savings more significant). the savings.
</t>
        <t>
An alternative to reducing the amount of protocol data is to design routing protocols that are more efficient to process at each node. For instance, path-based forwarding/labels such as MPLS <xref target="RFC3031"/> facilitate the next hop look-up, lookup, thereby reducing the energy consumption. It is unclear if some state at router to speed up look up lookup is more energy efficient that than "no state + lookup" that lookup", which is more computationally intensive. Other methods to speed up a next-hop lookup include geographic routing (e.g., <xref target="Herzen2011PIE"/>). Some network protocols could be designed to reduce the next hop look-up lookup computation at a router.  It is unclear if whether Longest Prefix Match (LPM) is efficient from an energy point of view efficient or if constitutes a significant energy burden for the operation of a router. router operation.
</t>
        <t>Beyond the volume of data itself, another consideration is the number of messages and chattiness of the protocol.  Some protocols rely on frequent periodic updates or heartbeats, which may prevent equipment to go from going into sleep mode. In such cases, it makes sense to explore the use of feasible alternatives that rely on different communication patterns and fewer messages.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Assessments of energy-related tradeoffs trade-offs regarding protocol design space and tradeoffs, trade-offs, such as maintaining state versus more compact encodings encodings, or extra computation for transcoding operations versus larger data volume. </t>
    <t>Protocol
          </li>
<!--[rfced] May this item be rephrased as follows? The original list
reads as "reduction in improvements in coding", which does not seem intended.

Original:
   *  Protocol advances for improving the ratio of goodput to throughput
      and to reduce waste: reduction in header tax, in protocol
      verbosity, in need for retransmissions, improvements in coding,
      etc.

Perhaps:
   *  Protocol advances for improving the ratio of goodput to throughput
      and to reduce waste; this could include coding improvements as well as
      reductions in the header tax, the protocol verbosity, and the need for
      retransmissions.
-->
          <li>
            <t>
      Protocol advances for improving the ratio of goodput to throughput
      and to reduce waste: reduction in header tax, in protocol
      verbosity, in need for retransmissions, improvements in coding,
      etc.
	    </t>
          </li>
          <li>
            <t>Protocols that allow to manage for managing transmission patterns in ways that facilitate periods of link inactivity, such as burstiness and chattiness. </t>
</list>
</t>
          </li>
        </ul>
      </section>
      <section title="Network Addressing" anchor="Addressing">
        <name>Network Addressing</name>
<!--[rfced] "energy footprint" vs. "carbon footprint"
In Section 5.4, the first paragraph uses the former, whereas the
summary uses the latter. Is this accurate?

Note: "energy footprint" only appears twice in this document;
please consider whether "energy consumption" is more accurate.

Original:
   From an energy footprint perspective, ...
[...]

   *  Devise methods to assess the magnitude of the carbon footprint
      that is associated with addressing schemes.
-->
        <t>
There may be other ways
Network addressing is another way to shave off energy usage from networks.  One example concerns network addressing.  Address tables can get very large, resulting in large forwarding tables that require considerable amount of memory, in addition to large amounts of state needing that needs to be maintained and synchronized.  From an energy footprint perspective, both can be considered wasteful and offer opportunities for improvement.   At the protocol level, rethinking how addresses are structured can allow for flexible addressing schemes that can be exploited in network deployments that are less energy-intensive by design.  This can be complemented by supporting clever address allocation schemes that minimize the number of required forwarding entries as part of deployments.
</t>
        <t>Alternatively, the address addressing could be designed to allow for more efficient processing than LPM. For instance, a geographic type of addressing (where the next hop is computed as a simple distance calculation based on the respective position of the current node, of its neighbors and of the destination) <xref target="Herzen2011PIE"/> could be potentially more energy efficient.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Devise methods to assess the magnitude of the carbon footprint that is associated with addressing schemes.</t>
          </li>
          <li>
            <t>Devise methods to improve addressing schemes, as well as address assignment schemes, to minimize their footprint.</t>
</list>
</t>
          </li>
        </ul>
      </section>
    </section>
</section><!-- End of Protocol Level Section-->

<section title="Challenges anchor="sec_network">
      <name>Challenges and Opportunities - Network Level" anchor="sec:network"> Level</name>
      <section title="Network anchor="sec_ean">
        <name>Network Optimization and Energy/Carbon/Pollution-Aware Networking" anchor="sec:ean"> Networking</name>
        <t>
Networks have been optimized for many years under many criteria, for example example, to optimize (maximize) network utilization and to optimize (minimize) cost.  Hence, it is straightforward to add optimization for "greenness" (including energy efficiency, power consumption, carbon footprint) as important criteria.
</t>
        <t>
This includes assessing the carbon footprints of paths and optimizing those paths so that overall footprint is minimized, then applying techniques such as path-aware networking or segment routing <xref target="RFC8402"/> to steer traffic along those paths.  (As mentioned earlier, other proxy measures
could be used for carbon footprint, such as an energy-efficiency ratings of traversed equipment.)
It also includes aspects such as considering the incremental carbon footprint in routing decisions.  Optimizing cost has a long tradition in networking; many of the existing mechanisms can be leveraged for greener networking simply by introducing the carbon footprint as a cost factor. Low-hanging fruit include the inclusion of includes adding carbon-related parameters as a cost parameter in control planes, whether distributed (e.g., IGP) or conceptually centralized via SDN controllers. Likewise, there are opportunities in right-placing functionality in the network.
<!--[rfced] Will the term "right-placing" be clear to the reader?
It has not been used before in the RFC series and does not appear
in the dictionary. It appears twice in this document, as follows.
Please consider whether the term should be replaced or explained,
as follows or otherwise.

Section 6.1:
   there are opportunities in right-placing functionality in the network.

Section 7:
   ..., right-placing of computational intelligence, ...

Perhaps:

S6.1: there are opportunities for "right-placing" functionality, i.e.,
ensuring that it is in the most suitable location for optimal effectiveness.
[or]
   there are opportunities for deliberate placement of functionality
   within the network.

S7:  ensuring the most suitable placement of computational intelligence
within the network design
-->
 An example concerns is placement of virtualized network functions in carbon-optimized ways - for example, ways, i.e., cohosted on fewer servers in close proximity to each other in order to avoid unnecessary overhead in long-distance control traffic.
</t>
<!--[rfced] Please clarify what "This" refers to in each instance.
Perhaps first "This" is weaning, and the second "This" is load-balancing.
May it be significantly rephrased as shown below?

Original:
   Therefore, weaning such
   resources from traffic becomes an important consideration for energy-
   efficient traffic steering.  This contrasts and indeed conflicts with
   existing schemes that typically aim to create redundancy and load-
   balance traffic across a network to achieve even resource
   utilization.  This usually occurs for important reasons, such as
   making networks more resilient, optimizing service levels, and
   increasing fairness.

Perhaps:
   Therefore, weaning resources from traffic is an important consideration
   for energy-efficient traffic steering. This approach conflicts with
   existing schemes that typically aim to increase network resilience,
   optimize service levels, and ensure fairness by creating redundancy and
   load-balancing traffic for even resource utilization.
-->
<t>
Other opportunities concern adding carbon-awareness carbon awareness to dynamic path selection schemes.  This is sometimes also referred to as "energy-aware networking" (respectively (or "pollution-aware networking" <xref target="Hossain2019"/> or "carbon-aware networking", when carbon footprint related parameters beyond pure simply energy consumption are taken into account).  Again, considerable energy savings can potentially be realized by taking resources offline (e.g., putting them into power-saving or hibernation mode) when they are not currently needed under current network demand and load conditions. Therefore, weaning such resources from traffic becomes an important consideration for energy-efficient traffic steering.  This contrasts and indeed conflicts with existing schemes that typically aim to create redundancy and load-balance traffic across a network to achieve even resource utilization. This usually occurs for important reasons, such as making networks more resilient, optimizing service levels, and increasing fairness.  Thus, a big challenge is how resource-weaning schemes to realize energy savings can be accommodated without cannibalizing other important goals, counteracting other established mechanisms, or destabilizing the network.
</t>
<!--[rfced] FYI, this sentence has been updated as follows for readability.
Please review whether it conveys your intended meaning, and whether you
prefer the shorter alternative.

Original:
   One of the big challenges hence concerns how
   resource weaning schemes to realize energy savings can be
   accommodated while preventing the cannibalization of other important
   goals, counteracting other established mechanisms, and avoiding
   destabilization of the network.
</t>

Current:
   Thus, a big challenge is how
   resource-weaning schemes to realize energy savings can be
   accommodated without cannibalizing other important goals,
   counteracting other established mechanisms, or destabilizing the
   network.

Or even shorter:
   Thus, a big challenge is implementing resource-weaning for
   energy savings without cannibalizing other important goals,
   counteracting other established mechanisms, or destabilizing the network.
-->
        <t>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 the traffic efficiently. The amount of traffic is relatively fluid (due to multiplexing of multiple sessions) and the traffic is predictable. In this case, there is no need to optimize on a per session per-session basis nor even or at a short time scale. timescale. In the access networks connecting to that core, though, there are opportunities for this fast convergence: traffic is much more bursty, bursty and less predictable predictable, and the network should be able to be more reactive. Other domains such as DCs may have also more variable workloads and different traffic patterns.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Devise methods for carbon-aware traffic steering and routing; treat carbon footprint as a traffic cost metric to optimize.</t>
          </li>
          <li>
            <t>Apply ML Machine Learning (ML) and AI methods to optimize networks for carbon footprint; assess applicability of game theoretic approaches.</t>
          </li>
          <li>
            <t>Articulate and, as applicable, moderate tradeoffs trade-offs between carbon awareness and other operational goals such as robustness and redundancy. </t>
          </li>
          <li>
            <t>Extend control-plane control plane protocols with carbon-related parameters. </t>
          </li>
          <li>
            <t>Consider security issues imposed by greater energy awareness, to minimize the new attack surfaces that would allow an adversary to turn off resources or to waste energy.</t>
</list>
</t>
          </li>
        </ul>
      </section>
<section title="Assessing
      <section>
        <name>Assessing Carbon Footprint and Network-Level Instrumentation"> Instrumentation</name>
        <t>
As an important prerequisite to capture many of the opportunities outlined in <xref target="sec:ean"/>, target="sec_ean"/>, good abstractions (and corresponding instrumentation) that allow to for easily assess assessing energy cost and carbon footprint will be required. These abstractions need to account for not only for the energy cost associated with packet forwarding across a given path, but also the related cost for processing, for memory, and for maintaining of state, to result in a holistic picture.
</t>
<t> Optimization

<!--[rfced] Section 6.2: What was intended here, rather than 'latter' twice?

Original:
   (Note: there may be a differential in running
   a computation at an edge server vs. at an hyperscale DC.  The latter
   is often better optimized than the latter.)

Perhaps: [The first sentence remains the same.]

   The latter is often better optimized than the former.
-->
        <t>In many cases, optimization of carbon footprint involves in many cases has trade-offs that involve not only packet forwarding but also aspects such as keeping state, caching data, or running computations at the edge instead of elsewhere.  (Note: there There may be a differential in running a computation at an edge server vs. at an a hyperscale DC. The latter is often better optimized than the latter.)  Likewise, other aspects of carbon footprint beyond mere energy-intensity should be considered. 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 deploy, and recycle, all of which can be reflected in abstractions to consider.
</t>
<!--[rfced] Please clarify "a particularly poor carbon footprint" here.
Does it mean a large carbon footprint? If so, we suggest replacing
the word "poor", which could be interpreted as "weak" or "substandard".

Original:
   Does the path include
   outliers, i.e., segments with equipment with a particularly poor
   carbon footprint?

Perhaps:
   Does the path include
   outliers, i.e., segments with equipment with a particularly large
   carbon footprint?
-->
        <t>Assessing carbon footprint at the network level requires instrumentation that associates that footprint not just with individual devices (as outline outlined in <xref target="sec:instrum"/> target="sec_instrum"/>) but relates it also to with concepts that are meaningful at the network level, i.e., to flows and to paths.  For example, it will be useful to provide visibility into the carbon intensity of a path: Can the carbon cost of traffic transmitted over the path be aggregated? Does the path include outliers, i.e., segments with equipment with a particularly poor carbon footprint?
</t>
        <t>Similarly, how can the carbon cost of a flow be assessed?  That might serve many purposes beyond network optimization, from the option to introduce e.g., introducing green billing and charging schemes to the ability to raise schemes, and raising carbon awareness by end users.
</t>
        <!-- CW: One key class of network that is potentially more energy intensive, but uses mostly renewable energy is that of satellite networks, and in particular Low Earth Orbit constellations.  Wireless networks are less energy efficient than fiber, as there is more signal loss and the transmitted energy is less focused towards the destination (this has to be qualified for free-space optical transmission of course). Therefore transmitting a signal into space and back comes with an arguably high energy cost. However, satellites cannot be connected to a power grid, and therefore have the requirement to be energy independent. Solar arrays provide the energy to power up the satellites, with a higher efficienty outside of the atmosphere. Any discussion of the "greenness" of such network should take into account the energy cost of building up an infrastructure in space and how this energy "capital expense" is amortized over time with the lower "operating expense" of using renewable energy. -->
<t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Devise methods to assess, to estimate, to and predict carbon-intensity the carbon intensity of paths.</t>
          </li>
          <li>
            <t>Devise methods to account for the carbon footprint of flows and networking services.</t>
</list>
</t>
          </li>
        </ul>
      </section>
<section title="Dimensioning
      <section>
        <name>Dimensioning and Peak Shaving"> Shaving</name>
        <t>
As mentioned in <xref target="sec:implications"/>, target="sec_implications"/>, the overall energy usage of a network is in large part determined by how the network is dimensioned, specifically: which and how many pieces of network equipment are deployed and turned on. A significant portion of energy is drawn even when simply in idle state.  Minimizing  Hence, minimizing the amount of equipment that needs to be turned on in the first place presents hence one of the biggest energy saving energy-saving opportunities.
</t>
        <t>
Network deployments are generally dimensioned for periods of peak traffic, resulting in excess capacity during periods of non-peak usage that nonetheless consumes power.  Shaving peak usage may thus result in outsized sustainability gains, as it reduces not only energy usage during peak traffic, but traffic but, more importantly importantly, waste during non-peak periods.
</t>
        <t>While traffic volume is largely a function of demand traffic that network providers have little influence over, some peak shaving cand can nevertheless be accomplished by techniques such as spreading spikes out over geographies (e.g. (e.g., redirecting some traffic across more costly but less utilized routes, particular particularly in cases when traffic spikes are of a more local or reginal regional nature) or over time (e.g. (e.g., postponing non-urgent traffic, storing or buffering using edge clouds or extra storage where feasible).
</t>
        <t>To make techniques effective, accurate learning and prediction of traffic patterns is are required. This includes the ability to perform forecasting to ensure that additional resources can be spun up in time should it they be needed.  Clearly, this presents interesting challenges, yet also opportunities for technical advances to make a difference.
</t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener  networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Support for methods that allow to monitor for monitoring and forecast 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 </t> scale.</t>
          </li>
          <li>
            <t>Additional methods that allow for even distributing traffic load distribution evenly across the network, i.e. i.e., load balancing on a network scale, and enablement of those methods through control protocol extensions as needed.</t>
</list>
</t>
          </li>
        </ul>
      </section>
<section title="Convergence Schemes">
      <section>
        <name>Convergence Schemes</name>
        <t>
One set of challenges of carbon-aware networking concerns the fact that many schemes result in much greater dynamicity and continuous change in the network network, as resources may be getting steered away from (when possible) and then leveraged again (when necessary) in rapid succession.  This imposes significant stress on convergence schemes that results in challenges to the scalability of solutions and their ability to perform in a fast-enough manner. Network-wide convergence imposes high cost and incurs significant delay and thus is hence not susceptible to such schemes. In order to mitigate this problem, mechanisms should be investigated that do not require convergence beyond the vicinity of the affected network device.  Especially  The impact of churn needs to be minimized, especially in cases where central network controllers are involved that are responsible (responsible for aspects such as the configuration of paths and the positioning of network functions and that aim for global optimization, the impact of churn needs to be minimized. optimization) are involved.  This means that, for example, (re-) discovery discovery, rediscovery, and update schemes need to be simplified simplified, and extensive recalculation e.g., (e.g., of routes and paths based on the current energy state of the network network) needs to be avoided.
</t>
        <t>The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
</t>
        <ul spacing="normal">
          <li>
            <t>Protocols that facilitate rapid convergence (per <xref target="NetworkEnergySaving"/>).</t>
          </li>
          <li>
            <t>Investigate methods that mitigate effects of churn, including methods that maintain memory or state as well as methods relying on prediction, inference, and interpolation.</t>
</list>
</t>
          </li>
        </ul>
      </section>
      <!-- Alex, feel free to comment out this following section, we can talk more about it. -->

<section title="The

<section>
        <name>The Role of Topology"> Topology</name>
        <t>
        One of the most important network management constructs is that of the network topology. A network topology can usually be represented as a database or as a mathematical graph, with vertices or nodes, edges or links, representing networking nodes, links connecting their interfaces, and all their characteristics. Examples of these network topology representations include routing protocols protocols' link-state databases, databases (LSDBs) and service function chaining graphs.
        </t>
    <t>
<!--[rfced] The term "sustainability visibility" reads oddly.
Please review if the updated sentence conveys the intended meaning.
The phrase "visibility into energy consumption" (a concept from Section 4)
has been used.

Original:
   As we desire to add carbon and energy awareness into networks, the
   energy proportionality of topologies directly supports sustainability
   visibility and improvements via automation.

Current:
   To add carbon and energy awareness into networks, the
   energy proportionality of topologies directly supports
   visibility into energy consumption and improvements via automation.
-->
        <t>
   To add carbon and energy awareness into networks, the
   energy proportionality of topologies directly supports
   visibility into energy consumption and improvements via automation.
        </t>
        <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
    <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Embedding carbon and energy awareness into the representation of topologies, whether considering IGP LSDBs (link-state databases) and their advertisements, BGP-LS (BGP Link-State), or metadata for the rendering of service function paths in a service chain.</t>
          </li>
          <li>
            <t>Use of those carbon-aware attributes to optimize topology as a whole under end-to-end energy and carbon considerations.
            </t>
    </list>
    </t>
          </li>
        </ul>
      </section>
    </section>
    <section title="Challenges anchor="sec_archi">
      <name>Challenges and Opportunities - Architecture Level" anchor="sec:archi"> Level</name>
      <t>
Another possibility to improve network energy efficiency is to organize networks in a way that they allow important applications to reduce energy consumption. Examples include facilitating retrieval of content or performing computation in ways that minimize the amount of communication that needs to take place needed in the first place, even if energy savings within the network may at least in part be offset (at least in part) by additional energy consumption elsewhere. The following are some examples that suggest that it may be worthwhile reconsidering to reconsider the ways in which networks are architected to minimize their carbon footprint.
</t>
      <t>
For example, Content Delivery Networks (CDNs) have reduced the energy expenditure of the Internet by downloading content near the users. The content is sent only a few times over the WAN, WAN and then is served locally. This shifts the energy consumption from networking to storage. Further methods can reduce the energy usage even more <xref target="Bianco2016energy"/> <xref target="Mathew2011energy"/> <xref target="Islam2012evaluating"/>. Whether overall energy savings are net positive depends on the actual deployment, but from the network operator's perspective, at least it shifts the energy bill away from the network to the CDN operator.
</t>
      <t>
While CDNs operate as an overlay, another architecture has been proposed to provide the CDN features directly in the network, namely Information Centric network -- namely, Information-Centric Networks <xref target="Ahlgren2012survey"/>, also studied as well in the IRTF ICNRG. This however ICNRG of the IRTF. However, this shifts the energy consumption back to the network operator and requires some power-hungry hardware, such as chips for larger name look-ups lookups and memory for the in-network cache.  As a result, it is unclear if there is an actual energy gain from the dissemination and retrieval of content within in-network caches.
</t>
      <t>
Fog computing and placing intelligence at the edge are other architectural directions for reducing the amount of energy that is spent on packet forwarding and in the network. There again, the trade-off is between performing computation computational tasks (a) in an energy-optimized data center at very large scale (but requiring transmission of significant volumes of data across many nodes and long distances) versus performing computational tasks (b) at the edge where the energy may not be used as efficiently (less multiplexing of resources and inherently lower efficiency of smaller sites due to their smaller scale) but the amount of long-distance network traffic and energy required for the network is significantly reduced.
<!--[rfced] FYI, this sentence has been updated as follows
to clarify the phrase "help its realization". Seemingly this phrase
refers to help the realization of such architectures. Please review.

Original:
   Softwarization,
   containers, microservices are direct enablers for such architectures,
   and the deployment of programmable network infrastructure (as for
   instance Infrastructure Processing Units - IPUs or SmartNICs that
   offload some computations from the CPU onto the NIC) will help its
   realization.

Current:
   Softwarization, containers, and
   microservices are direct enablers of such architectures.  Their
   realization will be further aided by the deployment of programmable
   network infrastructure, such as Infrastructure Processing Units
   (IPUs) or SmartNICs that offload some computations from the CPU onto
   the NIC.
-->
Softwarization, containers, and microservices are direct enablers of such architectures.  Their realization will be further aided by the deployment of programmable network infrastructure, such as Infrastructure Processing Units (IPUs) or SmartNICs that offload some computations from the CPU onto the NIC.
However, the power consumption characteristics of CPUs are different from those of NPUs, NPUs; this is another aspect to be considered in conjunction with virtualization.
</t>
      <t>
Other possibilities concern are taking economic aspects into consideration impact, consideration, such as providing incentives to users of networking services in order to minimize energy consumption and emission impact.  An example for this is given in  In <xref target="Wolf2014choicenet"/>, which an example is provided that could be expanded to include energy incentives.
</t>
      <t>
Other approaches consider performing a late binding of the data and the functions to be performed on the data it <xref target="Krol2017NFaaS"/>. The COIN Research Group in COINRG of the IRTF focuses on similar issues. Jointly optimizing for the total energy cost that takes into account networking as well as computing (along with the different energy cost of computing in an a hyperscale DC vs vs. at an edge node) is still an area of open research.
</t>
      <t>
In summary, rethinking of the overall network (and networked application) architecture can be an opportunity to significantly reduce the energy cost at the network layer, for example example, by performing tasks that involve massive communications closer to the user.  To what extend extent these shifts result in a net reduction of carbon footprint is an important question that requires further analysis on a case-by-case basis.
</t>
      <t>
The following summarizes some challenges and opportunities in this space that can provide the basis for advances in greener networking:
<list style="symbols">
    <t>Investigate
</t>
      <ul spacing="normal">
        <li>
<!--[rfced] "green footprint" (one instance)
You might want to consider a different term.

Original:
   *  Investigate organization of networking architecture for important
      classes of applications (examples: content delivery, right-placing
      of computational intelligence, industrial operations and control,
      massively distributed machine learning and AI) to optimize green
      foot print and holistic approaches to trade off carbon footprint
      between forwarding, storage, and computation.
-->
          <t>Investigate organization of networking architecture for important classes of applications (e.g., content delivery, right-placing of computational intelligence, industrial operations and control, massively distributed ML and AI) to optimize green footprint and holistic approaches to trade-offs of carbon footprint with forwarding, storage, and computation.</t>
        </li>
        <li>
          <t>Models to assess and compare alternatives in providing networked services, e.g., evaluate carbon impact relative to alternatives where to perform compute, computation, what information to cache, and what communication exchanges to conduct.</t>
</list>
</t>
        </li>
      </ul>
    </section>

<section title="Conclusions">
    <section>
      <name>Conclusions</name>
      <t> How to make networks "greener" and reduce their carbon footprint is an important problem for the networking industry to address, both for societal and for economic reasons. This document has highlighted a number of the technical challenges and opportunities in that regard.
</t>
<!--[rfced] Section 8: FYI, we have formatted this list of questions as
a bulleted list. Please let us know if you prefer otherwise.

Current:
   It will also help to answer questions such as:

   *  Is caching (with the associated storage) better than
      retransmitting from a different server (with the associated
      networking cost)?
   *  Is compression more energy efficient once factoring in the
      computation cost of compression vs. transmitting uncompressed
      data?
   *  Which compression scheme is more energy efficient?
   *  Is energy saving of computing at an efficient hyperscale DC
      compensated by the networking cost to reach that DC?
   *  Is the overhead of gathering and transmitting fine-grained energy
      telemetry data offset by the total energy gain resulting from the
      better decisions that this data enables?
   *  Is transmitting data to a Low Earth Orbit (LEO) satellite
      constellation compensated by the fact that once in the
      constellation, the networking is fueled by solar energy?
   *  Is the energy cost of sending rockets to place routers in LEO
      amortized over time?
-->
      <t>
Of those, perhaps the key challenge to address right away concerns is the ability to expose at a fine granularity the energy impact of any networking actions. Providing visibility into this will enable many approaches to come towards a solution. It will be key to implementing optimization via control loops that allow to can assess the energy impact of a decision taken.  It will also help to answer questions such as: is as:</t>
<ul spacing="compact">
  <li>Is caching - with (with the associated storage energy - storage) better than retransmitting from a different server - with (with the associated networking cost? Is cost)?</li>
  <li>Is compression more energy-efficient energy efficient once factoring in the computation cost of compression vs vs. transmitting uncompressed data? Which data?</li>
  <li>Which compression scheme is more energy efficient? Is efficient?</li>
  <li>Is energy saving of computing at an efficient hyperscale DC compensated by the networking cost to reach that DC? Is DC?</li>
  <li>Is the overhead of gathering and transmitting fine-grained energy telemetry data offset by the total energy gain by ways of resulting from the better decisions that this data enables? enables?</li>
<!--[rfced] In order to clarify the phrase "by the fact that once in
the constellation", please consider whether the updated text conveys
the intended meaning.

Original:
    Is transmitting data to a Low Earth Orbit (LEO) satellite
    constellation compensated by the fact that once in the
    constellation, the networking is fueled by solar energy?

Perhaps:
   *  Is the energy cost of transmitting data to a Low Earth Orbit
      (LEO) satellite constellation offset by the networking of
      that constellation being powered by solar energy?

Or:
   *  Does the energy saved by a Low Earth Orbit (LEO) satellite
      constellation, which is powered by solar energy, offset the
      energy required to transmit data to it?
-->
  <li>Is transmitting data to a Low Earth Orbit (LEO) satellite constellation compensated by the fact that once in the constellation, the networking is fueled by solar energy?</li>
  <li>Is the energy cost of sending rockets to place routers in Low Earth Orbit LEO amortized over time?
</t> time?</li>
</ul>

      <t>
Determining where the sweet spots are and optimizing networks along those lines will be a key towards making networks "greener". We expect to see significant advances across these areas and believe that researchers, developers, and operators of networking technology have an important role to play in this.
</t>
    </section>

<section title="IANA Considerations">
    <section>
      <name>IANA Considerations</name>
      <t>This document does not have any has no IANA requests. </t> actions.</t>
    </section>

<section title="Security Considerations">
    <section>
      <name>Security Considerations</name>
      <t>Security considerations may appear to be orthogonal to green networking considerations.  However, there are a number of important caveats.
</t>
      <t>Security vulnerabilities of networks may manifest themselves in compromised energy efficiency.  For example, attackers could aim at increasing energy consumption to drive up attack victims' energy bill. bills.  Specific vulnerabilities will depend on the particular mechanisms.  For example, in the case of monitoring energy consumption data, tampering with such data might result in compromised energy optimization control loops. Hence Hence, any mechanisms to instrument and monitor the network for such data need to be properly secured to ensure authenticity.
</t>
      <t>In some cases, there are inherent tradeoffs trade-offs between security and maximal energy efficiency that might otherwise be achieved.  An example is encryption, which requires additional computation for encryption and decryption activities and security handshakes, in addition to the need to send more traffic than necessitated by the entropy of the actual data stream.  Likewise, mechanisms that allow to turn resources on or off could become a target for attackers.
</t>
      <t>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 <xref target="TCC"/>, or the reading/sharing of the measured energy consumption can be abused to create a covert channel (see for instance <xref target="DRAM"/> or <xref target="NewClass"/>). Power information may be used to create side-channel attacks. For instance, <xref target="SideChannel"/> provides a review of 20 years of study on this topic. Any new parameters considered in protocol designs or in measurements are susceptible to create such covert or side channel channels, and this should be taken into account while designing energy efficient energy-efficient protocols.
</t>
    </section>

<section title="Contributors">
    <t>
    <list>
    <t>Michael Welzl, University of Oslo, michawe@ifi.uio.no</t>
    </list>
    </t>
</section>

<section title="Acknowledgments">
<t>
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.
</t>
</section>

  </middle>
  <back>

	<references title="Informative References">
        &RFC.2481;
        &RFC.3031;
        &RFC.3095;
        &RFC.7950;
        &RFC.8402;
        &RFC.9330;
<displayreference target="I-D.ietf-tvr-requirements" to="TVR_REQS" />
<displayreference target="I-D.cx-green-green-metrics" to="GREEN_METRICS"/>
<displayreference target="I-D.li-green-power" to="POWER_YANG"/>

    <references>

<!-- [rfced] Informative reference RFC 2481 has been obsoleted by
RFC 3168.  We recommend replacing RFC 2481 with RFC 3168; is that
acceptable? It is cited only once in the original:

  ECN [RFC2481] is a possible solution, however, it is not widely deployed.
-->

<!-- [rfced] FYI - We have updated the following references to include DOIs
and added URLs. Please let us know if you have any objections or
clarifications.

   [Ahlgren2012survey]
   [Alizadeh2010DCTCP]
   [Bianco2016energy]
   [Bolla2011energy]
   [Chabarek08]
   [DRAM]
   [Emergy]
   [Framework]
   [GreenNet22]
   [Herzen2011PIE]
   [Islam2012evaluating]
   [Junkyard]
   [Krol2017NFaaS]
   [Mathew2011energy]
   [NewClass]
   [QUAL]
   [Ren2018jordan]
   [SideChannel]
   [TCC]
   [TradeOff]
   [Westphal2021qualitative]
   [Wolf2014choicenet]
-->

      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3095.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
      <xi:include
      href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9330.xml"/>

<!-- [I-D.cx-green-green-metrics] IESG State: Expired as of 06/27/25-->

<reference anchor="I.D.draft-cx-green-green-metrics"> anchor="I-D.cx-green-green-metrics" target="https://datatracker.ietf.org/doc/html/draft-cx-green-green-metrics-00">
   <front>
      <title>Green Networking Metrics</title> Metrics for Environmentally Sustainable Networking</title>
      <author initials="A." surname="Clemm" fullname="Alexander Clemm"></author> Clemm" role="editor">
         <organization>Santa Clara University</organization>
      </author>
      <author initials="C." surname="Pignataro" fullname="Carlos Pignataro"></author> Pignataro" role="editor">
         <organization>North Carolina State University</organization>
      </author>
      <author initials="E." surname="Schooler" fullname="Eve Schooler"></author> Schooler">
         <organization>University of Oxford</organization>
      </author>
      <author initials="L." surname="Ciavaglia" fullname="Laurent Ciavaglia"></author> Ciavaglia">
         <organization>Nokia</organization>
      </author>
      <author initials="A." surname="Rezaki" fullname="Ali Rezaki"></author> Rezaki">
         <organization>Nokia</organization>
      </author>
      <author initials="G." surname="Mirsky" fullname="Greg Mirsky"></author> Mirsky">
         <organization>Ericsson</organization>
      </author>
      <author initials="J." surname="Tantsura" fullname="Jeff Tantsura"></author> Tantsura">
         <organization>Nvidia</organization>
      </author>
      <date month="October" year="2024"/> day="21" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-cx-green-green-metrics-00" />

</reference>

    <reference anchor="I.D.draft-li-green-power">
  <front>
    <title>A YANG model

<!-- [I-D.li-green-power] IESG State: Expired as of 06/27/25-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.li-green-power.xml"/>

<!-- [I-D.ietf-tvr-requirements] IESG State: I-D Exists as of 06/27/25-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tvr-requirements.xml"/>

<!-- [rfced] We found the following URL for Power Management</title>
    <author fullname="Tony Li"></author>
	<author fullname="Ron Bonica"></author>
	<date month="October" year="2024"/>
    </front>
  </reference>

  <reference anchor="I.D.draft-ietf-tvr-requirements">
  <front>
    <title>TVR (Time-Variant Routing) Requirements</title>
    <author fullname="Daniel King"></author>
	<author fullname="Luis Contreras"></author>
    <author fullname="Brian Sipos"></author>
    <author fullname="L. Zhang"></author>
	<date month="September" year="2024"/>
    </front>

  </reference> [Telefonica2021];
would you like to add it or a different URL to this reference?

https://www.telefonica.com/en/shareholders-investors/financial-reports/historical-archive-annual-reports/2021/

Current:
   [Telefonica2021]
              Telefonica, "Telefonica Consolidated Annual Report 2021",
              2021.
-->

      <reference anchor="Telefonica2021">
        <front>
          <title>Telefonica Consolidated Annual Report 2021.</title>
          <author fullname="Telefonica"> 2021</title>
          <author>
            <organization>Telefonica</organization>
          </author>
          <date year="2021"/>
        </front>
      </reference>

      <reference anchor="GreenNet22">
        <front>
          <title>Challenges and Opportunities in Green Networking</title>
          <author fullname="Alexander Clemm"> </author>
          <author fullname="Cedric Westphal"></author> Westphal"/>
          <date month="June" year="2022" /> year="2022"/>
        </front>
        <seriesInfo
		name="1st name="DOI" value="10.1109/NetSoft54395.2022.9844020"/>
        <refcontent>1st International Workshop on Network Energy Efficiency in the Softwarization Era" value="IEEE Era, IEEE NetSoft 2022"/> 2022</refcontent>
      </reference>

      <reference anchor="Bolla2011energy">
        <front>
          <title>Energy Efficiency in the Future Internet: A Survey of Existing Approaches and Trends in Energy-Aware Fixed Network Infrastructures</title>
          <author fullname="Raffaele Bolla"> </author>
          <author fullname="Roberto Bruschi"> </author>
          <author fullname="Franco Davoli"> </author>
          <author fullname="Flavio Cucchietti"> </author>
          <date year="2011" /> year="2011"/>
        </front>
    <seriesInfo name="IEEE
        <refcontent>IEEE Communications Surveys and Tutorials" value="Vol.13 No.2, pp.223-244"/> Tutorials, vol. 13, no. 2, pp. 223-244</refcontent>
        <seriesInfo name="DOI" value="10.1109/SURV.2011.071410.00073"/>
      </reference>

      <reference anchor="Chabarek08">
        <front>
          <title>Power awareness Awareness in network design Network Design and routing</title> Routing</title>
          <author fullname="J. Chabarek"></author> Chabarek"/>
          <author fullname="J. Sommers"></author> Sommers"/>
          <author fullname="P. Barford"></author> Barford"/>
          <author fullname="C. Estan"/>
          <author fullname="D. Tsiang"></author> Tsiang"/>
          <author fullname="S. Wright"></author> Wright"/>
          <date year="2008"/>
        </front>
        <refcontent>IEEE INFOCOM 2008 - The 27th Conference on Computer Communications, pp. 457-465</refcontent>
        <seriesInfo name="IEEE Infocom" value="pp.457-465"/> name="DOI" value="10.1109/INFOCOM.2008.93"/>
      </reference>

<!-- [rfced] FYI, for [Cervero19], we updated the year from 2019 to
2015 to match the year found at the DOI. Please let us know if that
is not accurate.

Current:
   [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>.
-->

      <reference anchor="Cervero19"> anchor="Cervero15">
        <front>
          <title>Green Wired Networks</title>
          <author fullname="Alfonso Gazo Cervero"></author> Cervero"/>
          <author fullname="Michele Chincoli"></author> Chincoli"/>
          <author fullname="Lars Dittmann"></author> Dittmann"/>
          <author fullname="Andreas Fischer"></author> Fischer"/>
          <author fullname="Alberto Garcia"></author> Garcia"/>
          <author fullname="Jaime Galán-Jiménez"/>
          <author fullname="Laurent Lefevre"/>
          <author fullname="Hermann de Meer"/>
          <author fullname="Thierry Monteil"/>
          <author fullname="Paolo Monti"/>
          <author fullname="Anne-Cecile Orgerie"/>
          <author fullname="Louis-Francois Pau"/>
          <author fullname="Chris Phillips"/>
          <author fullname="Sergio Ricciardi"/>
          <author fullname="Remi Sharrock"/>
          <author fullname="Patricia Stolf"/>
          <author fullname="Tuan Trinh"/>
          <author fullname="Luca Valcarenghi"/>
          <date year="2019"/> year="2015"/>
        </front>
	<seriesInfo name="Wiley Journal on Large-Scale
        <refcontent>Large-Scale Distributed Systems and Energy Efficiency" value="pp.41-80"/> Efficiency, pp. 41-80</refcontent>
        <seriesInfo name="DOI" value="10.1002/9781118981122.ch3"/>
      </reference>

      <reference anchor="Alizadeh2010DCTCP">
        <front>
          <title>Data Center TCP (DCTCP) </title>
          <author fullname="Mohammad Alizadeh"></author> Alizadeh"/>
          <author fullname="Albert Greenberg"></author> Greenberg"/>
          <author fullname="David Maltz"></author> Maltz"/>
          <author fullname="Jitendra Padhye"></author> Padhye"/>
          <author fullname="Parveen Patel"></author> Patel"/>
          <author fullname="Balaji Prabhakar"></author> Prabhakar"/>
          <author fullname="Sudipta Sengupta"></author> Sengupta"/>
          <author fullname="Murari Sridharan"></author> Sridharan"/>
          <date year="2010"/>
        </front>
        <refcontent>ACM SIGCOMM Computer Communication Review, vol. 40, no. 4, pp. 63-74</refcontent>
        <seriesInfo name="ACM SIGCOMM" value="pp.63-74"/> name="DOI" value="10.1145/1851275.1851192"/>
      </reference>

      <reference anchor="QUAL">
        <front>
    <title> A
          <title>A Framework for Qualitative Communications using Big Packet Protocol</title>
          <author fullname="Richard Li"></author> Li"/>
          <author fullname="Kiran Makhijani"></author> Makhijani"/>
          <author fullname="Hamed Yousefi"></author> Yousefi"/>
          <author fullname="Cedric Westphal"></author> Westphal"/>
          <author fullname="Lijun Xong"></author> Xong"/>
          <author fullname="Tim Wauters"></author> Wauters"/>
          <author fullname="Filip De Turck"></author> Turck"/>
          <date year="2019"/>
        </front>
        <seriesInfo name="Proceedings name="DOI" value="10.1145/3341558.3342201"/>
        <refcontent>NEAT'19: Proceedings of the ACM Sigcomm Workshop On Networking For Emerging Applications And Technologies" value="pp.22-28"/> Technologies, pp. 22-28</refcontent>
      </reference>

      <reference anchor="Westphal2021qualitative">
        <front>
          <title>Qualitative Communications for Augmented Reality and Virtual Reality </title>
          <author fullname="Cedric Westphal"></author> Westphal"/>
          <author fullname="Dongbiao He"></author> He"/>
          <author fullname="Kiran Makhijani"></author> Makhijani"/>
          <author fullname="Richard Li"></author> Li"/>
          <date year="2021"/>
        </front>
        <seriesInfo name="22nd name="DOI" value="10.1109/HPSR52026.2021.9481793"/>
        <refcontent>22nd IEEE International Conference on High Performance Switching and Routing (HPSR)" value="pp.1-6"/> (HPSR), pp. 1-6</refcontent>
      </reference>

      <reference anchor="Herzen2011PIE">
        <front>
          <title>Scalable routing easy as PIE: A practical isometric embedding protocol</title>
          <author fullname="Julien Herzen"></author> Herzen"/>
          <author fullname="Cedric Westphal"></author> Westphal"/>
          <author fullname="Patrick Thiran"></author> Thiran"/>
          <date year="2011"/>
        </front>
        <seriesInfo name="19th name="DOI" value="10.1109/ICNP.2011.6089081"/>
        <refcontent>19th IEEE International Conference on Network Protocols (ICNP)" value="pp.49-58"/> (ICNP), pp. 49-58</refcontent>
      </reference>

      <reference anchor="Ren2018jordan">
        <front>
          <title>JORDAN: A Novel Traffic Engineering Algorithm for Dynamic Adaptive Streaming over HTTP</title>
          <author fullname="Jing Ren"></author> Ren"/>
          <author fullname="Kejie Ren"></author> Lu"/>
          <author fullname="Cedric Westphal"></author> Westphal"/>
          <author fullname="Jin Wang"></author> Wang"/>
          <author fullname="Jinfan Wang"></author> Wang"/>
          <author fullname="Tongyu Song"></author> Song"/>
          <author fullname="Sucheng Liu"></author> fullname="Shucheng Liu"/>
          <author fullname="Jianping Wang"></author> Wang"/>
          <date year="2018"/>
        </front>
        <seriesInfo name="IEEE name="DOI" value="10.1109/ICCNC.2018.8390337"/>
        <refcontent>2018 International Conference on Computing, Networking and Communications (ICNC)" value="pp.581-587"/> (ICNC), pp. 581-587</refcontent>
      </reference>

      <reference anchor="Bianco2016energy">
        <front>
          <title>Energy consumption for data distribution in content delivery networks</title>
          <author fullname="Andreas Bianco"></author> Bianco"/>
          <author fullname="Reza Mashayekhi"></author> Mashayekhi"/>
          <author fullname="Michele Meo"></author> Meo"/>
          <date year="2016"/>
        </front>
    <seriesInfo name="IEEE
        <refcontent>IEEE International Conference on Communications (ICC)" value="pp.1-6"/> (ICC), pp. 1-6</refcontent>
        <seriesInfo name="DOI" value="10.1109/ICC.2016.7511356"/>
      </reference>

      <reference anchor="Mathew2011energy"> anchor="Mathew2011energy" target="https://arxiv.org/abs/1109.5641">
        <front>
          <title>Energy-Aware Load Balancing in Content Delivery Networks</title>
          <author fullname="Vimal Mathew"></author> Mathew"/>
          <author fullname="Ramesh Sitaraman"></author> Sitaraman"/>
          <author fullname="Prashant Shenoy"></author> Shenoy"/>
          <date year="2011"/>
        </front>
        <seriesInfo name="CoRR http://arxiv.org/abs/1109.5641" value=""/> name="DOI" value="10.48550/arXiv.1109.5641"/>
        <seriesInfo name="arXiv:" value="1109.5641v1"/>
      </reference>

      <reference anchor="Islam2012evaluating">
        <front>
          <title>Evaluating Energy Consumption in CDN Servers</title>
          <author fullname="Saif ul Islam"></author> Islam"/>
          <author fullname="Jean-Marc Pierson"></author> Pierson"/>
          <date year="2012"/>
        </front>
        <seriesInfo name="Proceedings name="DOI" value="10.1007/978-3-642-32606-6_6"/>
<refcontent>Proceedings of the Second International Conference on ICT as Key Technology against Global Warming" value="pp.64-78"/> Warming, Lecture Notes in Computer Science, vol 7453, pp. 64-78</refcontent>
      </reference>

      <reference anchor="Ahlgren2012survey">
        <front>
          <title>A survey of information-centric networking</title>
          <author fullname="Bengt Ahlgren"></author> Ahlgren"/>
          <author fullname="Christian Dannewitz"></author> Dannewitz"/>
          <author fullname="Claudio Imbrenda"></author> Imbrenda"/>
          <author fullname="Dirk Kutscher"></author> Kutscher"/>
          <author fullname="Borje Ohlman"></author> Ohlman"/>
          <date year="2012"/>
        </front>
	<seriesInfo name="IEEE
        <refcontent>IEEE Communications Magazine" value="Vol.50 No.7"/> Magazine, vol. 50, no. 7, pp. 26-36</refcontent>
        <seriesInfo name="DOI" value="10.1109/MCOM.2012.6231276"/>
      </reference>

      <reference anchor="Wolf2014choicenet">
        <front>
          <title>ChoiceNet: Toward an Economy Plane for the Internet</title>
          <author fullname="Wolf Tilman"></author> Tilman"/>
          <author fullname="James Griffioen"></author> Griffioen"/>
          <author fullname="Lenneth Calvert"></author> Calvert"/>
          <author fullname="Rudra Dutta"></author> Dutta"/>
          <author fullname="George Rouskas"></author> Rouskas"/>
          <author fullname="Ilya Baldin"></author> Baldin"/>
          <author fullname="Anna Nagurney"></author> Nagurney"/>
          <date year="2014" month="July"/>
        </front>
        <seriesInfo name="SIGCOMM name="DOI" value="10.1145/2656877.2656886"/>
        <refcontent>ACM SIGCOMM Computer Communciations Review" value="Vol.44 No.3"/> Review, vol. 44, no. 3, pp. 58-65</refcontent>
      </reference>

      <reference anchor="Krol2017NFaaS">
        <front>
          <title>NFaaS: Named Function as a Service</title>
          <author fullname="Michal Krol"></author> Krol"/>
          <author fullname="Ioannis Psaras"></author> Psaras"/>
          <date year="2017"/>
        </front>
        <refcontent>ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking, pp. 134-144</refcontent>
        <seriesInfo name="ACM SIGCOMM ICN Conference" value=""/> name="DOI" value="10.1145/3125719.3125727"/>
      </reference>

      <reference anchor="TCC">
        <front>
          <title>Selective Noise Based Power Efficient Power-Efficient and Effective Countermeasure Against Thermal Covert Channel Attacks in Multi-Core Systems</title>
          <author fullname="Parisa Rahimi"></author> Rahimi"/>
          <author fullname="Amit Kumar Singh"></author> Singh"/>
          <author fullname="Xioahang Wang"></author> Wang"/>
          <date year="2022"/>
        </front>
        <seriesInfo name="Journal name="DOI" value="10.3390/jlpea12020025"/>
        <refcontent>Journal on Low Power Electronics and Applications" value=""/> Applications, vol. 12, no. 2</refcontent>
      </reference>

      <reference anchor="DRAM">
        <front>
          <title>Robust Covert Channels Based on DRAM Power Consumption</title>
          <author fullname="Thales Bandiera Paiva"></author> Paiva"/>
          <author fullname="Javier Navaridas"></author> Navaridas"/>
          <author fullname="Routo Terada"></author> Terada"/>
          <date year="2019"/>
        </front>
        <seriesInfo name="In book: Information Security (pp.319-338)" value=""/> name="DOI" value="10.1007/978-3-030-30215-3_16"/>
        <refcontent>Information Security, ISC 2019, Lecture Notes in Computer Science, vol 11723</refcontent>
      </reference>

      <reference anchor="NewClass">
        <front>
          <title>A New Class of Covert Channels Exploiting Power Management Vulnerabilities</title>
          <author fullname="S. Karen Khatamifard"></author> Khatamifard"/>
          <author fullname="Longfei Wang"></author> Wang"/>
          <author fullname="Selcuk Kose"></author> Kose"/>
          <author fullname="Ulya R. Karpuzcu"></author> Karpuzcu"/>
          <date year="2018"/>
        </front>
        <seriesInfo name="IEEE name="DOI" value="10.1109/LCA.2018.2860006"/>
        <refcontent>IEEE Computer Architecture Letters" value=""/> Letters, vol. 15, no. 2, pp. 201-204</refcontent>
      </reference>

      <reference anchor="SideChannel">
        <front>
          <title>Power Side-Channel Attack Analysis: A Review of 20 Years of Study for the Layman</title>
          <author fullname="Mark Randolph"></author> Randolph"/>
          <author fullname="William Diehl"></author> Diehl"/>
          <date year="2020"/>
        </front>
	<seriesInfo name="Cryptography 2020,
        <refcontent>Cryptography, vol. 4, 15" value=""/> no. 2</refcontent>
        <seriesInfo name="DOI" value="10.3390/cryptography4020015"/>
      </reference>

      <reference anchor="Framework">
        <front>
    <title> A
          <title>A framework to estimate emissions from virtual conferences</title>
          <author fullname="Grant Faber"></author> Faber"/>
          <date year="2021"/>
        </front>
        <seriesInfo name="International name="DOI" value="10.1080/00207233.2020.1864190"/>
        <refcontent>International Journal of Environmental Studies, 78:4, 608-623" value=""/> vol. 78, no. 4, pp. 608-623</refcontent>
      </reference>

      <reference anchor="Emergy">
        <front>
          <title>The Energy and Emergy of the Internet</title>
          <author fullname="Barath Raghavan"></author> Raghavan"/>
          <author fullname="Justin Ma"></author> Ma"/>
          <date year="2011"/>
        </front>
        <seriesInfo name="ACM HotNets" value=""/> name="DOI" value="10.1145/2070562.2070571"/>
        <refcontent>Proceedings of the 10th ACM Workshop on Hot Topics in Networks, no. 9, pp. 1-6</refcontent>
      </reference>

      <reference anchor="Junkyard"> anchor="Junkyard" target="https://arxiv.org/abs/2110.06870v1">
        <front>
          <title>Architecture of a Junkyard Datacenter</title>
          <author fullname="Jennifer Switzer"></author> Switzer"/>
          <author fullname="Ryan Kastner"></author> Kastner"/>
          <author fullname="Pat Pannuto"></author> Pannuto"/>
          <date year="2021"/>
        </front>
        <seriesInfo name="arXiv:2110.06870v1, October 2021" value=""/> name="DOI" value="10.48550/arXiv.2110.06870"/>
        <seriesInfo name="arXiv:" value="2110.06870v1"/>
      </reference>

      <reference anchor="TradeOff">
        <front>
          <title>Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective Internet Congestion Control</title>
          <author fullname="Michael Welzl"></author> Welzl"/>
          <date year="2022"/>
        </front>
        <refcontent>2022 17th Wireless On-Demand Network Systems and Services Conference (WONS), pp. 1-4</refcontent>
        <seriesInfo name="IEEE/IFIP WONS" value=""/> name="DOI" value="10.23919/WONS54113.2022.9764413"/>
      </reference>

<!-- [rfced] For [Hossain2019], the URL provided
(https://ieeexplore.ieee.org/document/6779082) is fro an article
titled "Measurement and modeling the power consumption of router
interface".

We have updated the URL to use the DOI provided in the original
reference. Please let us know if that is not accurate.

Original:
   [Hossain2019]
              Hossain, M., Georges, J., Rondeau, E., and T. Divoux,
              "Energy, Carbon and Renewable Energy: Candidate Metrics
              for Green-Aware Routing?", DOI 10.3390/s19132901,
              Sensors Vol. 19 No. 3, June 2019,
              <https://ieeexplore.ieee.org/document/6779082>.

Current:
   [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://doi.org/10.3390/s19132901>.
-->

      <reference anchor="Hossain2019" target="https://ieeexplore.ieee.org/document/6779082"> anchor="Hossain2019">
        <front>
          <title>Energy, Carbon and Renewable Energy: Candidate Metrics for Green-Aware Routing?</title>
          <author fullname="M.M. Hossain"> </author>
          <author fullname="J.-P. Georges"> </author>
          <author fullname="E. Rondeau"> </author>
          <author fullname="T. Divoux"> </author>
          <date month="June" year="2019"/>
        </front>
        <seriesInfo name="DOI" value="10.3390/s19132901"/>
        <seriesInfo name="Sensors" value="Vol. 19 No. 3"/>
        <refcontent>Sensors, vol. 19, no. 3</refcontent>
      </reference>

      <reference anchor="IETF-Net0" target="https://www.ietf.org/blog/towards-a-net-zero-ietf/">
        <front>
          <title>Towards a net zero IETF</title>
          <author fullname="Jay Daley"></author> Daley"/>
          <date day="6" month="5" year="2022"/>
        </front>
    <seriesInfo name="IETF News" value=""/>
        <refcontent>IETF News</refcontent>
      </reference>

    </references>

    <section numbered="false">
      <name>Acknowledgments</name>
      <t>The authors thank <contact fullname="Dave Oran"/> for providing the
      information regarding covert channels using energy measurements and
      <contact fullname="Mike King"/> for an exceptionally thorough review and
      useful comments.</t>
    </section>

    <section numbered="false">
      <name>Contributors</name>

    <contact fullname="Michael Welzl">
      <organization>University of Oslo</organization>
      <address>
        <email>michawe@ifi.uio.no</email>
      </address>
    </contact>

    </section>

  </back>

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

In addition, please consider whether "tradition" should be updated for clarity.
It can be ambiguous.

 Section 6.1: Optimizing cost has a long tradition in networking;
-->

<!-- [rfced] Some author comments are present in the XML. Please confirm
that no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication. -->
</rfc>