-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-eckert-ietf-and-energy-overview.txt
2688 lines (1913 loc) · 117 KB
/
draft-eckert-ietf-and-energy-overview.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group T. Eckert, Ed.
Internet-Draft Futurewei Technologies USA
Intended status: Informational M. Boucadair, Ed.
Expires: 9 January 2025 Orange
P. Thubert
Cisco Systems, Inc.
J. Tentsura
NVIDIA
C. Pignataro, Ed.
NC State University
8 July 2024
An Overview of Energy-related Effort within the IETF
draft-eckert-ietf-and-energy-overview-07
Abstract
This memo provides an overview of work performed by or proposed
within the IETF related to energy and/or green: awareness,
management, control or reduction of consumption of energy, and
sustainability as it related to the IETF.
This document is written to help those unfamiliar with that work, but
interested in it, in the hope to raise more interest in energy-
related activities within the IETF, such as identifying gaps and
investigating solutions as appropriate.
This document captures work until 12/2022, at which time the "IAB
workshop on Environmental Impact of Internet Applications and
Systems" revived interest and triggered new work in the topic within
the IETF/IRTF.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Eckert, et al. Expires 9 January 2025 [Page 1]
Internet-Draft IETF Energy Overview July 2024
This Internet-Draft will expire on 9 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Energy Saving: An Introduction . . . . . . . . . . . . . . . 4
2.1. Digitization . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Energy Saving Through Scale . . . . . . . . . . . . . . . 5
2.2.1. An Iconic Example: Telephony . . . . . . . . . . . . 5
2.2.2. The Packet Multiplexing Principle . . . . . . . . . . 5
2.2.3. End-to-End Transport . . . . . . . . . . . . . . . . 5
2.2.4. Global vs Restricted Connectivity: The Internet Routing
Architectures . . . . . . . . . . . . . . . . . . . . 6
2.2.5. Freedom to Innovate . . . . . . . . . . . . . . . . . 6
2.2.6. End-to-End Encryption . . . . . . . . . . . . . . . . 6
2.2.7. Converged Networks . . . . . . . . . . . . . . . . . 6
2.2.7.1. IntServ and DetNet . . . . . . . . . . . . . . . 7
2.2.7.2. DiffServ . . . . . . . . . . . . . . . . . . . . 7
2.2.7.3. SIP . . . . . . . . . . . . . . . . . . . . . . . 8
3. Higher or New Energy Consumption . . . . . . . . . . . . . . 8
4. Some Notes on Sustainability . . . . . . . . . . . . . . . . 9
4.1. Follow the Energy Cloud Scheduling . . . . . . . . . . . 9
4.2. Optimize Generated Heat . . . . . . . . . . . . . . . . . 10
4.3. Heat Recovery . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Telecollaboration . . . . . . . . . . . . . . . . . . . . 10
5. Energy Optimization in Specific Networks . . . . . . . . . . 12
5.1. Analysis of Routing Protocol (In)Efficiencies . . . . . . 12
5.2. Low Power and Lossy Networks (LLN) . . . . . . . . . . . 12
5.2.1. 6LOWPAN WG . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. LPWAN WG . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. 6TISCH WG . . . . . . . . . . . . . . . . . . . . . . 14
5.2.4. 6LO WG . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.5. ROLL WG . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Constrained Nodes and Networks . . . . . . . . . . . . . 16
5.3.1. LWIG WG . . . . . . . . . . . . . . . . . . . . . . . 16
5.3.2. CoRE and CoAP . . . . . . . . . . . . . . . . . . . . 16
5.3.3. Satellite Constellations . . . . . . . . . . . . . . 17
Eckert, et al. Expires 9 January 2025 [Page 2]
Internet-Draft IETF Energy Overview July 2024
5.3.4. Devices with Batteries . . . . . . . . . . . . . . . 17
5.4. Sample Technical Enablers . . . . . . . . . . . . . . . . 17
5.4.1. (IP) Multicast . . . . . . . . . . . . . . . . . . . 17
5.4.1.1. Power Saving with Multicast . . . . . . . . . . . 18
5.4.1.2. Power Waste Through Multicast-based Service
Coordination . . . . . . . . . . . . . . . . . . . 19
5.4.1.3. Multicast Problems in Wireless Networks . . . . . 19
5.4.2. Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 20
5.5. (Lack of) Power Benchmarking Proposals . . . . . . . . . 22
6. Energy Management Networks . . . . . . . . . . . . . . . . . 22
6.1. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Synchro Phasor Networks . . . . . . . . . . . . . . . . . 23
7. (Limited) Energy Management for Networks . . . . . . . . . . 24
7.1. Some Metrics . . . . . . . . . . . . . . . . . . . . . . 24
7.2. EMAN WG . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Power-Awareness in Forwarding and Routing Protocols . . . . . 26
8.1. Power Aware Networks (PANET) . . . . . . . . . . . . . . 26
8.2. SDN-based Semantic Forwarding . . . . . . . . . . . . . . 27
8.3. Miscelaneous . . . . . . . . . . . . . . . . . . . . . . 28
9. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14. Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction
This document summarizes work that has been proposed to or performed
within the IETF/IRTF. Particularly, it covers IETF/IRTF RFCs as well
as ISE RFCs and IETF/IRTF or individual submission drafts that where
abandoned for various reasons (e.g., lack of momentum, broad scope).
There are various aspects how a given work relates to energy that are
classified into categories. Such a classification does not attempt
to propose a formal taxonomy, but is used for the sake of better
readability. Technologies are listed under a category that is
specifically significant, for example, by being most narrow.
This memo usually refers to the technologies by significant early RFC
or specific draft version, as opposed to the newest. This is
contrary to the common practice in IETF documents to refer to the
newest version. This approach is meant to allow readers to better
understand the historic timeline in which a specific technology was
proposed or introduced. Especially successful IETF technologies will
have newer RFC that updates such initial work.
Eckert, et al. Expires 9 January 2025 [Page 3]
Internet-Draft IETF Energy Overview July 2024
This document captures work until 12/2022, at which time the "IAB
workshop on Environmental Impact of Internet Applications and
Systems" [I-D.iab-ws-environmental-impacts-report] revived interest
and highlighted the need for some structured activity within the
IETF/IRTF.
2. Energy Saving: An Introduction
Technologies that simply save energy compared to earlier or other
alternatives are the broadest and most unspecific category. In this
memo such an energy saving simply refers to energy savings in some
unit of electricity, such as kWh and does not take other aspects of
energy optimization into account. See Section 4 for more details.
2.1. Digitization
Digitization describes the transformation of processes from non- or
less digital with networking to more digital with computer-
networking. For comparable process results, the digitized option is
often, but not always, less energy consuming. Consider, for example,
the energy consumption in the evolution of messaging starting from
postal mail and overs telegrams and various other historic form to
solutions including e-mail utilizing, for example, the IETF "Simple
Mail Transport Protocol" (SMTP, [RFC822] obsoleted by [RFC2822],
[RFC5322]), group communications utilizing the IETF "Network News
Transport Protocol" (NNTP, [RFC3977]) or the almost infinite set of
communication options built on top of the IETF "HyperText Transport
Protocol" (HTTP, [RFC2086] and successors), and IETF "HyperText
Markup Language" (HTML, [RFC1866] superseded by various later version
of HTML, see [RFC2854]).
Conventionally, digitization had only "incidental", but not
"intentional" relationship to energy consumption: If it saved energy,
this was not a target benefit; in fact, it was not even recognized as
one until recently. Instead, the evolution was driven from anything-
but-energy benefits, but instead utility benefits such as improved
speed, functionality/flexibility, accessibility, usability,
scalability, and reduced cost.
In hindsight though, digitization through IETF technologies and
specifically the Internet will likely have the largest contribution
to energy saving amongst all the possible categories, but it is also
the hardest to pinpoint on any specific technology/RFC. Instead, it
is often a combination of the whole stack of deployed protocols and
operational practices that contributes to energy saving through
digitization. It is likely also the biggest overall energy saving
impact of all possible categories that relate IETF work to energy:
Eckert, et al. Expires 9 January 2025 [Page 4]
Internet-Draft IETF Energy Overview July 2024
The Internet as well as all other IP/MPLS networks are likely the
biggest energy saving development of the past few decades if only the
energy consumption of equivalent services is compared. On the other
hand, they are also the cause for the biggest new type of new energy
consumption because of all the new services introduced in the past
decades with the Internet and the hyper-scaling that the Internet
affords them.
2.2. Energy Saving Through Scale
2.2.1. An Iconic Example: Telephony
In most cases, energy saving through the use of IETF protocols
compared to earlier (digitized or non-digitized) solutions is purely
a result of the reduction in the energy cost per bit over the decades
in networking. For example, the energy consumption of digital voice
telephony through the IETF "Session Initiation Protocol" (SIP,
[RFC2543] superseded by [RFC3261] and successors) can easily be
assumed to be more energy efficient on a per voice-minute basis than
prior voice technologies such as analog or digital "Time Division
Multiplex" (TDM) telephony solely because of this evolution in mostly
device as well as physical-layer and link-layer networking
technologies.
2.2.2. The Packet Multiplexing Principle
Nevertheless, it is at the heart of the packet multiplexing model
employed by the IETF networking protocols IP ([RFC791]) and IPv6
([RFC1883] superseded by [RFC2460] and [RFC8200]) to successfully
support this scaling that brough down the cost per bit through ever
faster links and network nodes, especially for networks larger than
building scale networks. While the IETF protocols have not been the
first or over their early decades necessarily the most widely
deployed packet networking protocols, they were the ones who at least
during the 1990s started to break away from other protocols both in
scale of deployment, as well as in development of further
technologies to support this scaling.
2.2.3. End-to-End Transport
At the core of scalability, even up to now, is the lightweight per-
packet-processing enabled through end-to-end congestion loss
management architecture as embodied through the IETF "Transmission
Control Protocol" (TCP, [RFC9293]). This model eliminated more
expensive per-hop, per-packet processing, such as would be required
for reliable hop-by-hop forwarding through per-hop ARQ, which was key
to scaling routers cost effectively.
Eckert, et al. Expires 9 January 2025 [Page 5]
Internet-Draft IETF Energy Overview July 2024
2.2.4. Global vs Restricted Connectivity: The Internet Routing
Architectures
The meshed peer-to-peer and transitive routing of the Internet
enabled through the IETF Border Gateway (Routing) Protocol (BGP,
[RFC4271] as well as predecessors) is another key factor to
successful scalability, because it enabled competitive market forces
to explore markets quickly.
Prior to the Internet, the public often only had access to highly
regulated international networking connections through often per-
country monopoly regulated data networks.
2.2.5. Freedom to Innovate
(non-IP) networks often also did not allow as much "freedom-to-
innovate" (as it is often called in the IETF) for applications
running over it. Instead, those networks were exploring the coupling
of packet transport with higher layer services to allow the network
operator some degree of revenue sharing with the services running on
top of it. Such approaches resulted not only in higher cost of those
services but also (likely) preferential and (often) exclusionary
treatment of network traffic not fitting the perceived highest
revenue service options.
2.2.6. End-to-End Encryption
When the same business practices were applied to IP network, it was
one of the key factors leading to the development of IETF end-to-end
encryption though protocols such as "Transport Layer Security" (TLS,
[RFC2246] [RFC4346], [RFC5246], [RFC8446]). This further
strengthened the ability to scale service/applications at minimum
additional cost for the underlying packet transport, arguably driving
innovation into ever faster networking technology and likely lower
cost per bit.
2.2.7. Converged Networks
Another key factor to support scaling where IETF technologies that
allowed to multiplex different types of traffic (e.g., real-time vs.
non-real-time) which previously used separate networks with typically
incompatible networking technologies.
Eliminating multiple physical networks with separate routing/
forwarding nodes and separate links affords significant energy
savings even at the same generation of speed and hence energy/bit
simply by avoiding the N-fold production and operations of equipment
and links. Of course, originally the CAPEX and OPEX of multiple,
Eckert, et al. Expires 9 January 2025 [Page 6]
Internet-Draft IETF Energy Overview July 2024
technology-diverse networks and host-stacks was the core reason for
unified networks, and energy saving is in hindsight just incidental
(as for all other cases mentioned here).
2.2.7.1. IntServ and DetNet
The first (non-IETF) widely adopted technology promising converged
networks was "Asynchronous Transfer Mode" (ATM), which was designed
and deployed at the end of the 1980s to support specifically
multiplexing of "Data Voice and Video", where both Voice and Video
(at that time) required loss-free deterministic bounded latency and
low-jitter and had therefore their own Time-Division-Multiplex (TDM)
networks, both separate from so-called Data networks using packet
multiplexing. This technology was very expensive on a per-bit basis
due to its cell-forwarding nature though.
At the end of the 1980s, it was proven in [BOUNDED_LATENCY] that
variable length packet multiplexing in network can also support non-
NP-hard calculations for bounded latency. This led to the IETF
"Integrated Services WG" (INTSERV) to support such guaranteed
throughput and bounded latency traffic via [RFC2212] - and to the
demise of ATM.
IntServ has so far seen little traction because it too got superseded
as explained in the following section - for its original use-cases
(voice and video). However, this type of services is being revisited
for a broader set of use-cases [RFC8575] in the DetNet WG, which
should enable even further network infrastructure convergence for IoT
and industrial markets.
2.2.7.2. DiffServ
Due to the much higher per-packet processing overhead of INTSERV
versus regular (so-called Best-Effort) Internet traffic, the INTSERV
model was already recognized in the 1990s to not support highest-
scale at lowest cost, leading to the parallel development of the IETF
"Differentiated Services WG" (DIFFSERV) model defined in [RFC2475].
This has since then become the dominant technology to support
multiplexing of applications and services originally not designed for
the Internet onto a common TCP/IP network infrastructure,
specifically for voice and video over UDP ([RFC768]) including RTP
[RFC3550] and SIP.
Eckert, et al. Expires 9 January 2025 [Page 7]
Internet-Draft IETF Energy Overview July 2024
2.2.7.3. SIP
SIP has most notably in the past two decades eliminated additional
network infrastructures previously required for (voice) telephony
services starting in the early 2000 with commercial/enterprise
deployments and today by removing even the option for any (non-IP/
SIP) analog or digital (ISDN) telephone service connection, instead
delivering those purely as services over adaptation interfaces on
home routers (TBD: Any RFC to cite for those tunneling/adaptation
services ?).
3. Higher or New Energy Consumption
Digitized, network centric workflows may consume more energy than
their non-digitized counterpart, as may new network centric workflows
without easy to compare prior workflows.
In one type of instances, the energy consumption on a per-instance
basis is lower than in the non-digitized/non-Internet-digitized case,
but the total number of instances that are (Internet)-digitized is
orders of magnitudes larger than their alternative options, typically
because of their higher utility or lower overall cost.
For example, each instance of (simple text) email consumes less
energy than sending a letter or postcard. Even streaming a movie or
TV series consumes less energy than renting a DVD [DVDvsStreaming].
Nevertheless, the total amount of instances and in result energy
consumption for email and streaming easily outranks their predecessor
technologies.
While these instances look beneficial from a simple energy
consumption metric, its overall scale and the resulting energy
consumption may in itself become an issue, especially when the energy
demand it creates risks to outstrip the possible energy production,
short term or long term. This concern is nowadays often raised
against the "digital economy", where the network energy consumption
is typically cited as a small contributor relative to its
applications, such as what is running in Data Centers (DC).
In other cases, the energy consumption of digitization requires often
significantly more than their pre-digitization alternatives. The
most well-known example of this are likely crypto-currencies based on
"proof-of-work" computations (mining), which on a per currency value
unit can cost from ten to thirty times or more of the energy consumed
by for example gold mining (very much depending on the highly
fluctuating price of the crypto currency). Nevertheless, its overall
utility compared to such prior currencies or valuables makes it
highly successful in the market.
Eckert, et al. Expires 9 January 2025 [Page 8]
Internet-Draft IETF Energy Overview July 2024
In general, the digital economy tends to be more energy intensive on
a per utility/value unit, for example by replacing a lot of manual
labor with computation), and/or it allows for faster growth of its
workflows.
The lower the cost of network traffic, and the more easily accessible
everywhere network connectivity is, the more competitive and/or
successful most of these new workflows of the digital economy can be.
Given how TCP/IP based networks, especially the Internet have
excelled through their design principles (and success) in this
reduction of network traffic cost and ubiquitous access over the past
few decades, as outlined above, one can say that IETF technologies
and especially the Internet are the most important enabler of the
digital economy, and the energy consumption it produces.
4. Some Notes on Sustainability
Sustainability is the principle to utilize resources in a way that
they do not diminish or run out over the long term (e.g., ore
depletion required for building hardware). Beyond the above covered
energy saving, sustainability relates with respect to the IETF
specifically to the use of renewable sources of energy to minimize
exhaustion of fossil resources, and the impact of IETF technologies
on global warming to avoid worsening living conditions on the planet.
While there seems to be no IETF work specifically intending to target
sustainability, the Internet itself can similarly to how it does for
digitization play a key role in building sustainable networked IT
infrastructures. The following subsections list three exemplary
areas where global high performance, low-cost Internet networking is
a key requirement.
4.1. Follow the Energy Cloud Scheduling
Renewable energy resources (except for water) do commonly have
fluctuating energy output. For example, solar energy output
correlates to night/day and strength of sunlight. Cloud Data Centers
(DC) consume a significant amount of the IT sectors energy. Some
workloads may simply be scheduled to consume energy in accordance
with the amount of available renewable energy at the time, not
requiring the network. Significant workloads are not elastic in
time, such as interactive cloud DC interactive work (cloud based
applications) or entertainment (gaming, etc.). These workloads may
be instantiated or even dynamically (over time) migrate to a DC
location with sufficient renewable energy and the Internet (or large
TCP/IP OTT backbone networks) will serve as the fabric to access the
remote DC and to coordinate the instantiation/migration.
Eckert, et al. Expires 9 January 2025 [Page 9]
Internet-Draft IETF Energy Overview July 2024
4.2. Optimize Generated Heat
The majority of energy in cloud DCs is normally also wasted as
exhaust heat, requiring even more energy for cooling. The warmer the
location, the more energy needs to be spent for cooling. For this
reason, DCs in cooler climates, such as https://greenmountain.no/
power-and-cooling/, can help to reduce the overall DC energy
consumption significantly (independent of the energy being consumed
in the DC to be renewable itself). The Internet again plays the role
of providing access to those type of DCs whole location is not
optimized for consumption but for sustainable generation of compute
and storage.
4.3. Heat Recovery
Exhaust heat, especially from compute in DCs, can be recovered when
it is coupled to heating systems ranging in size all the way from
individual family homes through larger buildings (hotels, for
example) all the way to district heating systems. A provider of such
a type of compute-generated heat as a service can sell the compute
capacity as long as there is cost efficient network connectivity.
"Cloud & Heat" is an example company offering such infrastructures
and services https://www.cloudandheat.com/wp-content/
uploads/2020/02/2020_CloudHeat-Whitepaper-Cost-saving-Potential.pdf.
4.4. Telecollaboration
Telecollaboration has a long history in the IETF resulting in
multiple core technologies over the decades.
If one considers textual communications via email and netnews (using
e.g., NNTP) as early forms of Telecollaboration, then
telecollaboration history through IETF technology reaches back into
the 1980s and earlier.
Around 1990, the IETF work on IP Multicast (e.g., [RFC1112] and
later) enabled the first efficient forms of audio/video group
collaboration through an overlay network over the Internet called the
MBone https://en.wikipedia.org/wiki/Mbone which was also used by the
IETF for more than a decade to provide remote collaboration for its
own (in-person + remote participation) meetings.
With the advent of SIP in the early 2000s, commercial
telecollaboration started to be built most often on SIP based session
and application protocols with multiple IETF working groups
contributing to that protocol suite (TBD: how much more example/
details should we have here). Using this technology and the
Internet, the immersive nature of telecollaboration was brought to
Eckert, et al. Expires 9 January 2025 [Page 10]
Internet-Draft IETF Energy Overview July 2024
life-size video, was/is called Telepresence
https://en.wikipedia.org/wiki/Telepresence and later to even more
immersive forms such as AR/VR telecollaboration.
In 2011, the IETF opened the "Real-Time Communication in Web-
browsers" (RTCWEB) WG, that towards the end of that decade became the
most widely supported cross-platform reference for hundreds of
commercial and free tele-collaboration solutions, including Cisco
Webex, which is also used by the IETF itself, Zoom, and the
collaboration suite the IETF most recently uses, Meetecho
https://www.meetecho.com/en/.
While the various forms of Telecollaboration are mostly instances of
digitization, they are discussed under sustainability because of its
comparison to in-person travel that is not based on simple comparison
of energy, but nowadays by comparing their impact on global warming,
a key factor to sustainability.
Telecollaboration was primarily developed because of the utility for
the participants - to avoid travel for originally predominantly
business communications/collaborations. It saw an extreme increase
in use (TBD: references) in the Corona Crisis of 2019, when
especially international travel was often prohibited, and often even
working from an office. This forced millions of people to work from
home and utilizing commercial telecollaboration tools. It equally
caused most in-person events that where not cancelled to be moved to
a telecollaboration platform over the Internet - most of them likely
relying on RTCWEB protocols.
Actual energy consumption related comparison between teleconferencing
and in-person travel is complex but since the last decades is
commonly based on calculating some form of CO2 emission equivalent of
the energy consumed, hence comparing not simply the energy
consumption, but weighing it by the impact the energy consumption has
on one of the key factors (CO2 emission) known to impact sustainable
living conditions.
[VC2014] is a good example of a comparison between travel and
telecollaboration taking various factors into account and using CO2
emission equivalents as its core metric. That paper concludes that
carbon/ energy cost of telecollaboration could be as little as 7% of
an in-person meeting. in-person meeting. Those numbers have various
assumptions and change when time-effort of participants is converted
to carbon/energy costs. These numbers should even be better today in
favor of telecollaboration: cost of Internet traffic/bit goes down
while cost of fossil fuel for travel goes up.
Eckert, et al. Expires 9 January 2025 [Page 11]
Internet-Draft IETF Energy Overview July 2024
Recently, air travel has also come under more scrutiny because the
greenhouse gas emissions of air travel at the altitudes used by
commercial aviation has been calculated to have a higher global
warming impact than simply the amount of CO2 used by the airplane if
it was exhausted at surface level. One publicly funded organization
offering carbon offset services calculates a factor 3 of the CO2
consumption of an airplane
https://www.atmosfair.de/de/fliegen_und_klima/flugverkehr_und_klima/
klimawirkung_flugverkehr/.
In summary: Telecollaboration has a higher sustainability benefit
compared to travel than just the comparison of energy consumption
because of the higher challenge to use renewable energy in
transportation than in networking, and this is most extreme in the
case of telecollaboration that replaces air travel because of the
even higher global warming impact of using fossil fuels in air
travel.
5. Energy Optimization in Specific Networks
5.1. Analysis of Routing Protocol (In)Efficiencies
At the beginning of much of the following IETF efforts was an
understanding and analysis that prior protocols for routing and
subnet management where not able to ideally support evolving network
and device models: - lower compute performance due to low energy
(batteries, energy recovery), bitrates especially on radio links, and
lower memory footprint.
The two documents from 2008/2009 that capture this analysis/
understanding are [I-D.levis-roll-overview-protocols] and
[I-D.ietf-roll-protocols-survey]. The overall challenges also very
much related to energy of IPv6 over wireless are captured in
[I-D.thubert-6man-ipv6-over-wireless], which is ongoing work.
5.2. Low Power and Lossy Networks (LLN)
Low Power and Lossy Networks (LLNs) are networks in which nodes and/
or radio links have constraints. Low power consumption constraints
in nodes often originate from the need to operate nodes from as long
as possible from battery and/or energy harvesting such as (today most
commonly) solar panels associated with the node or ambient energy
such as energy harvesting from movement for wearable nodes or piezo
cells to generate energy for mechanically operated nodes such as
switches.
Eckert, et al. Expires 9 January 2025 [Page 12]
Internet-Draft IETF Energy Overview July 2024
Several IETF WGs have or are producing work is primarily intended wo
support LLN through multiple layers of the protocol stack. [RFC8352]
gives a good overview of the energy consumption related communication
challenges and solutions produced by the IETF for this space.
To minimize the energy needs for such nodes, their network data-
processing mechanisms have to be optimized. This includes packet
header compression, fragmentation (to avoid latency through large
packets at low bitrates, packet bundling to only consume radio energy
at short time periods, radio energy tuning to just reach the
destination(s), minimization of multicasting to eliminate need of
radio receivers to consume energy and so on. [RFC8352] gives a more
detailed overview, especially because different L2 technologies such
as IEEE 802.15.4 type (low power) wireless networks, Bluetooth Low
Energy (BLE), WLAN (IEEE 802.11) and DEC ULE.
In the INT area of the IETF, several LLN specific WGs exist(ed):
5.2.1. 6LOWPAN WG
The "IPv6 over Low power WPAN (Wireless Personal Area Networks)"
(6lowpan) WG ran from 2005 to 2014 and produced 6 RFC that adopt IPv6
to IEEE 802.15.4 type (low power) wireless networks by transmission
procedures [RFC4949], compression of IPv6 (and transport) packet
headers [RFC6282], modifications for neighbor discovery (ND)
[RFC6775], as well as 3 informational RFCs about the WPAN space and
applying IPv6 to it. Among these, the Problem Statement and
Requirements [RFC6606] gives details about the power and energy
approaches and goals.
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944],
"Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks" [RFC6282], "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
(6LOWPAN-ND).
It is important to understand the 6LOWPAN Overview, Assumptions,
Problem Statement, and Goals [RFC4919], including "conserve energy".
Outside the 6LOWPAN WG, [RFC9139] connects Information-Centric
Networking (ICN) to Low-Power Wireless Personal Area Networks
(LoWPANs).
Eckert, et al. Expires 9 January 2025 [Page 13]
Internet-Draft IETF Energy Overview July 2024
5.2.2. LPWAN WG
Since 2014 and before 2023, the "IPv6 over Low Power Wide-Area
Networks" (LPWAN) WG has produced 4 RFC for low-power wide area
networks, such as LoRaWAN https://en.wikipedia.org/wiki/LoRa, with
three Standards-Track RFC documents, [RFC8724], [RFC8824], and
[RFC9011].
5.2.3. 6TISCH WG
Since 2013, the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6tisch)
WG has produced 7 RFC for a version of 802.15.4 called the "Time-
Slotted Channel Hopping Mode" (TSCH), which supports deterministic
latency and lower energy consumption through the use of scheduling
traffic into well-defined time slots, thereby also optimizing/
minimizing energy consumption when compared to 802.15.4 without TSCH.
5.2.4. 6LO WG
Since 2013, the "IPv6 over Networks of Resource-constrained Nodes"
(6lo) WG has generalized the work of 6lowpan for LLN in general,
producing 17 RFC for IPv6-over-l2foo adaptation layer specifications,
information models, cross-adaptation layer specification (such as
header specifications) and maintenance and informational documents
for other pre-existing IETF work in this space.
Notably, a key specification produced is [RFC7668], "IPv6 over
BLUETOOTH(R) Low Energy", using IPv6 over Low-power Wireless Personal
Area Network (6LoWPAN) techniques, as well as the related [RFC9159]
for the formation of extended topologies, an IPv6 mesh over Bluetooth
LE links.
From a management perspective, produced [RFC7388], LOWPAN MIB, as
well as several specific improvements around power such as [RFC7973],
[RFC8025], [RFC8928], [RFC8931], and [RFC9034].
Finally, the 6LO WG also produced [RFC8105], IPv6 over DECT Ultra-Low
Energy, and [RFC9354], IPv6 over Power Line Communication (PLC).
5.2.5. ROLL WG
In the RouTinG (RTG) area of the IETF, the "Routing Over Low power
and Lossy networks" (ROLL) WG has produced since 2008 23 RFC.
Initially it produced requirement RFCs of different type of "Low-
power and Lossy Networks": urban: [RFC5548], industrial [RFC5673],
home automation [RFC5826] and building automation [RFC5867].
Eckert, et al. Expires 9 January 2025 [Page 14]
Internet-Draft IETF Energy Overview July 2024
Since then, its work is mostly focused on the "IPv6 Routing Protocol
for Low-Power and Lossy Networks" (RPL) [RFC6550] [RFC6551]
[RFC6552], which is used in a wide variety of the above-described
IPv6 instances of LLN networks and which are discussed in two ROLL
applicability statement RFCs, "Applicability Statement: The Use of
the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol
Suite in Home Automation and Building Control" [RFC7733] and
"Applicability Statement for the Routing Protocol for Low-Power and
Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks" [RFC8036]. Further, some RPL RFCs were progressed in the
6MAN WG, such as [RFC6553], RPL Option for Carrying RPL Information
in Data-Plane Datagrams, and [RFC6554], IPv6 Routing Header for
Source Routes with RPL. [RFC7416] covers a Security Threat Analysis
for RPLs, which is also relevant to energy efforts.
The ROLL WG also wrote a more generic RFC for LLN, "Terms Used in
Routing for Low-Power and Lossy Networks" [RFC7102]. RPL has a
highly configurable set of functions to support (energy) constrained
networks. Unconstrained root node(s), typically edge routers between
the RPL network and a backbone network calculate "Destination-
Oriented Directed Acyclic Graphs" (DODAG) and can use strict hop-by-
hop source routing with dedicated IPv6 routing headers [RFC8138]
[RFC9008] to minimize constrained nodes routing related compute and
memory requirements. "The Trickle Algorithm" [RFC6206] allows to
minimize routing related packets through automatic lazy updates.
While RPL is naturally a mesh network routing protocol, where all
nodes are usually expected to be able to participate in it, RPL also
supports even more lightweight leave nodes [RFC9010].
The 2013 [I-D.ajunior-energy-awareness-00] proposes the introducing
of energy related parameters into RPL to support calculation/
selection of most energy efficient paths. The 2017 "An energy
optimization routing scheme for LLSs",
[I-D.wang-roll-energy-optimization-scheme] observed that DODAGs in
RPL tend to require more energy in nodes closer to the root and
proposed specific optimizations to reduce this problem. Neither of
these drafts proceeded in the IETF.
While original use-cases for RPL where energy and size limited
networks, its design is to a large extend not scale limited. Because
of this, and due to its reduced compute/memory requirements for the
same size networks compared to other routing protocols, especially
the so-called link-state "Interior Gateway routing Protocols" (IGP),
such as most commonly used protocols ISIS ([RFC1142] superseded by
[ISO10589-Second-Edition]) and OSPF [RFC2328], RPL has also
proliferated into use-cases for non-constrained networks, for example
to support the largest possible networks automatically, such as in
[RFC8994].
Eckert, et al. Expires 9 January 2025 [Page 15]
Internet-Draft IETF Energy Overview July 2024
5.3. Constrained Nodes and Networks
(Power) constrained nodes and/or networks exist in a much broader
variety than coupled with low-power and lossy networks. For example,
Wi-Fi and cellular mobile network connections are not considered to
be lossy networks, and personal mobile nodes with both connections
are order of magnitude less constrained than nodes typically attached
to LLN network. Therefore, broader work in the IETF than focused
primarily on LLN typically uses just the term lightweight or
constrained (nodes and networks).
5.3.1. LWIG WG
Since 2013, the "Light-Weight Implementation Guidance" (lwig) WG is
has produced 6 informational RFC on the groups subject, much of which
indirectly supports implementing power efficient network
implementations via lightweight nodes/links, but it also addressed
the topic explicitly including via the aforementioned [RFC8352] and
[RFC9178], "Building Power-Efficient Constrained Application Protocol
(CoAP) Devices for Cellular Networks".
Further, the LWIG WG produced [RFC7228], "Terminology for
Constrained-Node Networks", which includes important energy and power
definitions of terms. These include scaling properties, classes of
energy limitation, and strategies for using power for communication.
It also produced [RFC9006], giving guidance on TCP usage for saving
energy.
5.3.2. CoRE and CoAP
In the APPlication (APP) area of the IETF, the "Constrained RESTful
Environments" (core) WG has produced since 2010 21 RFC, most of them
for or related to "The Constrained Application Protocol" (CoAP)
[RFC6690], which can best be described as a replacement for HTTP for
constrained environment, using UDP instead of TCP and DTLS instead of
TLS, compact binary message formats instead of human readable textual
formats, RESTful message exchange semantic instead of a broader set
of options (in HTTP), but also more functionality such as (multicast)
discovery and directory services, therefore providing a more
comprehensive set of common application functions with more compact
on-the-wire/radio encoding than its unconstrained alternatives.
"Object Security for Constrained RESTful Environments" (OSCORE),
[RFC8613] is a further product of the CoRE WG providing a more
message layer based, more lightweight security alternative to DTLS.
Eckert, et al. Expires 9 January 2025 [Page 16]
Internet-Draft IETF Energy Overview July 2024
While originally designed for LLN, CoAP is transcending LLN and
equally becoming ubicuitous in unconstrained environments such as
wired/ethernet industrial Machine 2 Machine (M2M) communications,
because of simplicity, flexibility and relying on the single set of
protocols supporting the widest range of deployment scenarios.
In the SECurity (SEC) area of the IETF, the "Authentication and
Authorization for Constrained Environments" (ace) working group has
since 2014 produced 4 RFC for security functions in constrained
environments, for example CoAP based variations of prior HTTPS
protocols such as EST-coaps [RFC9148] for HTTPS based EST [RFC7030].
Constrained node support in cryptography especially entails support
for Elliptic Curve (EC) public keys due to their shorter key sizes
and lower compute requirements compared to RSA public keys with same
cryptographic strength. While the benefits of EC over RSA where
making them preferred, this "additional market space" (constrained
node) benefit helped in their faster market proliferation even beyond
constrained networks.
5.3.3. Satellite Constellations
Emerging communication infrastructures may have specific requirements
on power consumption. Such requirements should be taken into account
when designing/customizing techniques (e.g., routing) to be enabled
in such networks. For example,
[I-D.lhan-problems-requirements-satellite-net] identifies a set of
requirements (including power) for satellite constellations.
5.3.4. Devices with Batteries
Many IETF protocols (e.g., [RFC3948]) were designed to accommodate
the presence of middleboxes mainly by encouraging clients to issue
frequent keepalives. Such strategy has implication on battery-
supplied devices. In order to optimize battery consumption for such
devices, [RFC6887] specifies a deterministic method so that client
can control state in the network, including their lifetime.
Keepalive alive messages may this be optimized as a function of the
network policies.
A_REC#2 of [RFC7849] further insist on the importance of saving
battery exacerbated by keep-alive messages and recommends the support
of collaborative means to control state in the network rather than
relying on heuristics.
5.4. Sample Technical Enablers
5.4.1. (IP) Multicast
Eckert, et al. Expires 9 January 2025 [Page 17]
Internet-Draft IETF Energy Overview July 2024
5.4.1.1. Power Saving with Multicast
IP Multicast was introduced with [RFC1112] and today also called "Any
Source Multicast" (ASM) has various protocols go through the
standardization process in the IETF across multiple working groups.
There are also MPLS and BIER multicast protocols from the IETF
developed in the equally named WGs.
These three, network layer multicast technologies can be a power
saving technologies when used to distribute data because they reduce
the number of packets that need to be sent across the network
(through in-network-replication where needed). Because most current
link and router technologies do not allow to actually save
significant amounts of energy on lower than maximum utilization,
these benefits are often only theoretical though. Software routers
are the ones most likely to expose energy consumption somewhat
proportional to their throughput for just the forwarding (CPU) chip.
Likewise, in large backbone networks, IP multicast can free up
bandwidth to be used for other traffic, such as unicast traffic,
which may allow to avoid upgrades to faster and potentially more
power consuming routers/links. Today, these benefits too are most
often overcompensated for by lower per-bit energy consumption of
newer generations of routers and links though.
Multicasting can also save energy on the transmitting station across
radio links, compared to replicated unicast traffic, but this is
rarely significant, because except for fully battery powered mesh
network, there are typically non-energy-constrained nodes, such as
(commonly) the wired access-points in Wi-Fi networks.
In result, today multicasting has typically no significant power
saving benefits with available network technologies. Instead, it is
used (for data distribution) when the amount of traffic that a
unicast solution alternative (with so-called ingress replication) is
not possible due to the total amount of traffic generated. This
includes wireless/radio networks, where equally airtime is the
limiting factor.
As an additional pointer, [RFC7731] defined the Multicast Protocol
for Low-Power and Lossy Networks (MPL).