Scope
The Internet Engineering Task Force (IETF) is the leading standardisation body concerning the Internet and Internet-connected systems. The increased attention to green networking has led to two Internet Draft documents exploring this topic in depth: draft-cx-opsawg-green-metrics-02 and the current document. These documents contain ideas and considerations rather than proposing a normative standard. In fact, the current document identifies relevant topics for research and is still far from providing solutions.
Summary
The document starts by discussing some network energy consumption characteristics and their implications. Subsequently, it identifies and discusses opportunities and research challenges regarding green networking, addressing four different levels: equipment level, protocol level, network level, and architecture level.
Also, some comments are placed promoting a holistic approach, considering carbon next to energy, considering embedded energy/carbon (including consumption during the development process itself), considering the need for cooling (favouring deployments in colder climates and productive use of excess heat), and looking beyond carbon to any pollution, biodiversity and the preservation of natural habitats. However, except for carbon, these are out of the scope of IETF.
Furthermore, some comments are made regarding security, as is usual in IETF documents. Energy-saving measurements and measures introduce additional attack surfaces. For example, tampering with measurements will compromise control loops, power-down modes could be leveraged to launch denial-of-service attacks, and energy measurements may enable side-channel attacks.
Network Energy Consumption Characteristics and Implications
Half of the energy consumption is associated with the data plane. The energy consumption in idle state is more than half of the energy consumption at full load, which implies that the incremental cost of additional bits (i.e., beyond the first bit), or additional load on CPU/memory (i.e., beyond the first packet) is fairly negligible. Consequently, a device’s energy consumption does not increase linearly with volume, but it is more like a step function (i.e., a step is made when additional resources need to be procured). Similarly, transmitting large data volumes in bursts is more efficient than continuously transmitting at a lower rate, because the duration dominates over the actual data rate. In other words, utilising resources to the max is essential, which requires fast control loops.
At the device level, very efficient and rapid discovery, monitoring and control of networking resources are needed so that they can be taken offline and put back into service dynamically. However, this should be achieved without causing extensive state convergence across the network, recalculation of routes and other optimisation problems. Furthermore, the network equipment should support rapid power cycle and initialisation schemes for this to happen. Solutions developed for IoT to maximise battery life might also be leveraged in the context of green networking.
Equipment Level
Selecting the most energy-efficient equipment (e.g., leveraging an energy rating like EnergyStar in the US) is an obvious opportunity. This includes the choice of medium (e.g., optical vs radio) and the trade-off between general-purpose and special-purpose hardware (e.g., hardware switch vs switch running as VNF on general-purpose hardware). Note that general-purpose hardware may extend its lifetime through software updates, thus reducing embedded energy (“energy”); however, it might not always be as efficient as special-purpose hardware. Also, supporting port power-saving modes and down-speeding of links is important. Generally speaking, knobs for energy-saving policies (e.g., power-saving modes) are well-known for endpoints but not for networking equipment.
The key opportunity and challenge to address right away is instrumenting equipment to measure energy consumption at fine granularity, also taking virtualisation into account (i.e., perform correct attribution), as this will enable control loops for energy optimisation (e.g., setting up a path with minimal incremental energy consumption). Also, it will help in answering architectural questions (e.g., whether to cache or not). Energy consumption can be monitored at device, line card and individual port levels. It also needs to be related to data rates and current traffic. YANG data models that address network energy consumption to be used with management and control protocols don’t exist yet, which is the reason for the “green metrics” study (i.e., it should serve as the basis for developing such models). Certification and compliance assessment to ensure this instrumentation cannot be manipulated is also essential. The same holds for methods that allow accounting for the energy mix (i.e., addressing carbon footprint instead of mere energy consumption).
Protocol Level
To facilitate Network Level optimisation (see “Network Level” below), protocols are needed to rapidly take down network resources and bring them up again and discover their states with minimal reconvergence and state propagation. Furthermore, protocols that could be extended with energy- and sustainability-related parameters should be assessed to enable new solutions, including protocols meant to collect energy telemetry data.
Protocol advances are needed to enable better control over traffic pacing (e.g., bulking up transmission for minimal carbon cost) and to optimise link utilisation. The carbon impact of these strategies should also be assessed.
Designing protocols to reduce data volume is another opportunity. Important trade-offs to consider are the maintenance of state versus having a more compact encoding, as well as the extra computation needed for transcoding versus transmitting larger data volumes. Also, protocol advances are needed to improve “goodput” versus throughput, for example, by reducing header tax, protocol verbosity, and the number of retransmissions and improving coding. Furthermore, protocols are needed to manage transmission patterns in ways that facilitate periods of link inactivity (e.g., by reducing chattiness, e.g., by avoiding heartbeats).
Finally, network addressing presents an opportunity, considering that address and forwarding tables can get quite large which, in turn, requires a lot of memory and state synchronisation and hence energy. Methods should be developed to assess the magnitude of the carbon footprint associated with addressing schemes and to improve addressing and address assignment schemes (e.g., geographical addressing).
Network Level
Significant opportunities for energy reduction exist at the network level. Traffic could be directed to isolate devices, enabling them to power down, essentially striving for zero incremental energy cost. Also, devices could be selected based on having an energy source with low carbon impact. Similarly, VNFs can be placed in a carbon-aware fashion. However, the approach will depend on the traffic characteristics (e.g., a highly trafficked core with predictable traffic versus access networks and data centres that may have a more bursty load).
In terms of opportunities and research challenges, methods should be devised for carbon-aware traffic steering and routing, using carbon footprint as a metric, ML/AI should be applied to optimise these networks while managing trade-offs between carbon awareness and other operational goals (i.e., service levels, resiliency, and fairness), control-plane protocols should be extended with carbon-related parameters, and security should be addressed as outlined above. Also, methods need to be devised to assess, estimate, and predict the carbon intensity of paths and account for the carbon footprint of flows and networking services. Furthermore, methods to monitor and forecast traffic demand need to be supported and additional methods are needed to enable an even load distribution across the network (i.e., peak shaving). Additionally, protocols are needed for rapid convergence and methods to mitigate churn need to be investigated. Finally, carbon and energy awareness should be embedded into topology representations (e.g., link state databases and their advertisements). Also, carbon-aware attributes are needed to optimize the topology as a whole under end-to-end and carbon considerations.
Architecture Level
The organisation of the networking and networked application architecture should be investigated for important classes of applications like content delivery (CDN), deploying computational intelligence (e.g., the trade-off between computation and communication for central data centre versus edge), and massively distributed ML/AI. Models are needed to assess and compare architectural alternatives for providing networked services concerning carbon impact. Also, economic aspects should be considered, such as providing end-user incentives to minimise energy consumption. Late binding of data and functions is a research topic of relevance.
Relevance for EXIGENCE
This document is mostly relevant to orchestration and energy optimisation, as it discusses possibilities for orchestrating and optimising network energy consumption. It also emphasises the need for visibility of energy impact (and the need for proper attribution in case of virtualised resources), but those topics are discussed in depth in the other document i.e., draft-cx-opsawg-green-metrics-02, not in this one. Also, this is ongoing work and therefore provides an opportunity to contribute to standardisation.
