Cloud and Edge Networking E-Book
142,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A major transformation in the world of networks is underway, as the focus shifts from physical technology to software-based solutions. In this book, the authors present this new generation of networks that are based in the Cloud by detailing the transition from a complex environment to a simple digital infrastructure. This infrastructure brings together connected devices, the antennas that collect radio waves, the optical fibers that carry signals and the data center that handles all of the different processes. From this perspective, the data center becomes the brain, managing network services, controls, automation, intelligence, security and other applications. This architecture is relevant to carrier networks, the Internet of Things, enterprise networks and the global networks of the major Internet companies. Cloud and Edge Networking further discusses developments at the border of networks, the Edge, where data is processed as near as possible to the source. Over the next ten years, the Edge will become a major strategic factor.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 391
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Table of Contents
Title Page
Copyright Page
Preface
1 Introduction to Edge and Cloud Networking
1.1. Introduction to digital infrastructure
1.2. Cloud services
1.3. Cloud Networking
1.4. Network Functions Virtualization
1.5. Conclusion
1.6. References
2 The Cloud Continuum
2.1. Cloud Continuum levels
2.2. Cloud Continuum Networks
2.3. The Cloud Continuum and the digitization of companies
2.4. Example of digital infrastructure
2.5. Conclusion
2.6. References
3 Digital Infrastructure Architecture
3.1. The evolution of enterprise information system architectures
3.2. The Open Infrastructure Foundation architecture
3.3. The Cloud Native Computing Foundation architecture
3.4. Gaia-X
3.5. Conclusion
3.6. References
4 Open-Source Architectures for Edge and Cloud Networking
4.1. Organizations and the main open sources
4.2. The main open-source projects
4.3. Conclusion
4.4. References
5 Software-Defined Networking (SDN)
5.1. Introduction to Software-Defined Networking
5.2. ONF architecture
5.3. Southbound interfaces and controllers
5.4. The northbound interface and the application plan
5.5. Conclusion
5.6. References
6 Edge and Cloud Networking Commercial Products
6.1. Introduction to SDN products
6.2. Fabric control
6.3. Software-Defined Wide Area Network
6.4. Secure Access Service Edge
6.5. Virtual Customer Premises Equipment
6.6. vWi-Fi
6.7. Virtual Radio Access Network
6.8. Virtual Evolved Packet Core and virtual 5GCore
6.9. Conclusion
6.10. References
7 OpenFlow, P4, Opflex and I2RS
7.1. OpenFlow signaling
7.2. P4
7.3. OpFlex
7.4. I2RS
7.5. Conclusion
7.6. References
8 Edge and Cloud Networking Operators
8.1. Edge Networking in 5G architecture
8.2. Cloud RAN
8.3. Cloud Networking at the heart of 5G
8.4. The Cloud and the new Ethernet and Wi-Fi generations
8.5. Enterprise 5G Edge Networks
8.6. Conclusion
8.7. References
9 Cloud Networking Protocols
9.1. Low-level protocols
9.2. Virtual extensible LAN
9.3. Network Virtualization using Generic Routing Encapsulation
9.4. Ethernet MEF
9.5. Ethernet Carrier Grade
9.6. Transparent Interconnection of Lots of Links
9.7. Locator/Identifier Separation Protocol
9.8. Conclusion
9.9. References
10 Edge and Cloud Networking in the IoT
10.1. Internet of Things networks
10.2. Low Power Wide Area Networks
10.3. PAN and LAN networks for the IoT
10.4. Telecommunications operator networks for the IoT
10.5. Platform for the IoT
10.6. Conclusion
10.7. References
11 Cloud Continuum in Vehicular Networks
11.1. ETSI ITS-G5
11.2. 5G standardization
11.3. Visible light communication
11.4. The architecture of vehicular networks
11.5. Conclusion
11.6. References
12 The Cloud Continuum and Industry 4.0
12.1. The features needed to achieve Industry 4.0
12.2. Technical specifications for 5G
12.3. Cloud and Edge for Industry 4.0
12.4. Conclusion
12.5. References
13 AI for Cloud and Edge Networking
13.1. The knowledge plane
13.2. Artificial intelligence and Software-Defined Networking
13.3. AI and Cloud Networking management
13.4. AI through digital twins
13.5. Conclusion
13.6. References
14 Cloud and Edge Networking Security
14.1. The Security Cloud
14.2. SIM-based security
14.3. Blockchain and Cloud
14.4. Cloud Networking security
14.5. Edge Networking security
14.6. Conclusion
14.7. References
15 Accelerators
15.1. The DPDK accelerator
15.2. The FD.io accelerator
15.3. Hardware virtualization
15.4. Conclusion
15.5. References
16 The Future of Edge and Cloud Networking
16.1. 5G continuity
16.2. Fully distributed networks
16.3. Cloud Continuum-based networks
16.4. Edge and Cloud properties
16.5. Conclusion
16.6. References
Conclusion
List of Authors
Index
End User License Agreement
List of Tables
Chapter 10
Table 10.1. The different characteristics of Internet of Things networks
List of Illustrations
Chapter 1
Figure 1.1. The virtualization process.
Figure 1.2. A data center and its virtual machines.
Figure 1.3. Virtualizable and non-virtualizable devices.
Figure 1.4. A distributed Cloud.
Figure 1.5. A hybrid Cloud.
Figure 1.6. Hypervision and containerization.
Figure 1.7. The three main types of Clouds.
Figure 1.8. The first service architectures.
Figure 1.9. A set of virtual networks.
Figure 1.10. A virtual network with non-virtualized boxes.
Figure 1.11. Slicing.
Figure 1.12. Virtualization of all network functions.
Figure 1.13. The four levels of Cloud and Edge Networking.
Figure 1.14. Network Functions Virtualization (NFV).
Figure 1.15. The architecture of the LF-Networking Anuket platform.
Chapter 2
Figure 2.1. The data center infrastructure of operators and Cloud providers.
Figure 2.2. The Fog layer in the digital infrastructure.
Figure 2.3. A Cloud Continuum.
Figure 2.4. The digitization of companies.
Figure 2.5. The digital infrastructure.
Figure 2.6. The Google network (© Google).
Figure 2.7. Google’s infrastructure.
Chapter 3
Figure 3.1. Enterprise information systems architecture.
Figure 3.2. Application services.
Figure 3.3. Infrastructure services.
Figure 3.4. The digital infrastructure.
Figure 3.5. Cybersecurity and independence.
Figure 3.6. The basic elements of OIF architecture.
Figure 3.7. An overview of OpenStack modules.
Figure 3.8. The Kubernetes orchestrator architecture.
Figure 3.9. The four basic elements of Cloud Native.
Figure 3.10. Cloud Native Architecture.
Figure 3.11. Cloud Computing Architectures.
Figure 3.12. CaaS and FaaS architecture.
Figure 3.13. The three architectures for Cloud Computing.
Figure 3.14. Comparison of the three Cloud Computing architectures.
Figure 3.15. The architecture of the Gaia-X project (© Gaïa-X).
Figure 3.16. A federation of Clouds.
Figure 3.17. Architecture of a federation of Clouds.
Chapter 4
Figure 4.1. The Anuket/OPNFV platform (OPNFV).
Figure 4.2. The full version of the Anuket/OPNFV platform (OPNFV).
Figure 4.3. The three ONAP subsystems.
Figure 4.4. The ONAP architecture (ONAP).
Figure 4.5. The Open vSwitch virtual switch (OvS).
Figure 4.6. Architecture of an OpenDaylight platform (OpenDaylight).
Figure 4.7. FD.io accelerator architecture (FD.io).
Figure 4.8. The PNDA platform (PNDA).
Chapter 5
Figure 5.1. The Open Network Foundation (ONF) architecture.
Figure 5.2. SDN architecture.
Figure 5.3. The main open sources of SDN architecture.
Figure 5.4. The OpenFlow signaling protocol.
Figure 5.5. The control level and its interfaces.
Figure 5.6. The OpenStack management system (OpenStack).
Figure 5.7. The interconnection architecture of different SDN domains.
Chapter 6
Figure 6.1. Architecture of an old and new generation fabric.
Figure 6.2. Interconnection of fabrics.
Figure 6.3. NSX architecture.
Figure 6.4. The detailed architecture of NSX (VMware).
Figure 6.5. Cisco’s ACI architecture (Cisco).
Figure 6.6. The detailed architecture of ACI (Cisco).
Figure 6.7. Juniper’s OpenContrail Platform (Juniper).
Figure 6.8. The Nokia SDN platform (Nokia).
Figure 6.9. An SD-WAN network.
Figure 6.10. Company networks.
Figure 6.11. The SD-WAN overlay network.
Figure 6.12. The overlay network.
Figure 6.13. The SD-WAN with its controller.
Figure 6.14. An SD-Branch network.
Figure 6.15. An SD-WAN with SASE.
Figure 6.16. An example of vCPE with a hybrid architecture.
Figure 6.17. The basic configuration for vWi-Fi
Figure 6.18. vWi-Fi in Ethernet compatible mode.
Figure 6.19. Cloud-RAN (C-RAN): a 5G vRAN.
Figure 6.20. Virtualization of a core network.
Chapter 7
Figure 7.1. The OpenFlow signaling protocol.
Figure 7.2. The OpenFlow protocol in a network.
Figure 7.3. OpenFlow protocol fields 3.0.
Figure 7.4. The different versions of OpenFlow.
Figure 7.5. Decomposition of the flow table in OpenFlow.
Figure 7.6. A table of groups in the flow table.
Figure 7.7. P4 and OpenFlow architectures.
Figure 7.8. I2RS Architecture.
Chapter 8
Figure 8.1. 5G architecture.
Figure 8.2. The transition from 4G to 5G.
Figure 8.3. C-RAN architecture.
Figure 8.4. Partial Cloud-RAN.
Figure 8.5. 5G slicing with the three main layers.
Figure 8.6. Major Ethernet product lines.
Figure 8.7. Comparison of public and private 5G.
Chapter 9
Figure 9.1. The RoF technique.
Figure 9.2. The EoF technique.
Figure 9.3. The VXLAN protocol.
Figure 9.4. The VXLAN encapsulation.
Figure 9.5. The NVGRE protocol.
Figure 9.6. The different versions of Ethernet Carrier Grade.
Figure 9.7. The TRILL protocol.
Figure 9.8. The LISP protocol.
Chapter 10
Figure 10.1. Network categories in the Internet of Things.
Figure 10.2. Frequencies used for LPWANs.
Figure 10.3. The SigFox solution.
Figure 10.4. The LoRa solution.
Figure 10.5. LoRaWAN.
Figure 10.6. Bluetooth: piconet and scatternet.
Figure 10.7. ZigBee.
Figure 10.8. The HaLow range (IEEE 802.11ad).
Figure 10.9. The HaLow environment.
Figure 10.10. Comparison of different solutions for the Internet of Things.
Figure 10.11. The NB-IoT environment.
Figure 10.12. The eDRX technology used in NB-IoT for rendez-vous.
Figure 10.13. Platform architecture for the IoT.
Figure 10.14. Using AI for the IoT.
Figure 10.15. AI control in the IoT.
Figure 10.16. The Azure platform for IOT (Microsoft).
Figure 10.17. Google’s platform for IoT (Google).
Figure 10.18. The AWS platform for IOT.
Figure 10.19. The IBM platform for IoT.
Chapter 11
Figure 11.1. Communication between vehicles: V2V.
Figure 11.2. V2V via 5G.
Figure 11.3. Communication by light between two vehicles.
Figure 11.4. Connections in a vehicular network.
Figure 11.5. The Cloud for vehicular networks.
Figure 11.6. The Edge and the Cloud in a vehicular environment.
Chapter 12
Figure 12.1. Revolutions in the industrial world.
Figure 12.2. Response time and throughput of different applications.
Figure 12.3. Architecture of an Industry 4.0 application.
Figure 12.4. The main elements of Industry 4.0.
Figure 12.5. The Industry 4.0 environment.
Figure 12.6. The three major tiers of data centers used by Industry 4.0.
Chapter 13
Figure 13.1. Information management with and without Big Data.
Figure 13.2. Data governance.
Figure 13.3. Automatic and intelligent control of an SDN network.
Figure 13.4. Intent-based networking (IBN).
Figure 13.5. Diagram of actions to be taken to achieve IBN.
Figure 13.6. A digital twin.
Figure 13.7. Behavior of a digital twin.
Figure 13.8. The three stages of operation of a digital twin.
Figure 13.9. Digital twins associated with objects.
Figure 13.10. NTT Docomo’s view of 6G control.
Figure 13.11. The structure of 6G by the Hexa-X project led by Nokia.
Figure 13.12. A possible infrastructure for 6G.
Chapter 14
Figure 14.1. Security elements.
Figure 14.2. How an eSIM works.
Figure 14.3. The profiles linked to the eSIM card.
Figure 14.4. How a blockchain works.
Chapter 15
Figure 15.1. Architecture using DPDK.
Figure 15.2. The introduction of DPDK in OvS.
Figure 15.3. The architecture of the FD.io accelerator.
Figure 15.4. FD.io intervention levels.
Figure 15.5. Description of the FD.io solution.
Figure 15.6. Acceleration architecture.
Chapter 16
Figure 16.1. Specifications for moving from 5G to 6G.
Figure 16.2. A 5G network with slices.
Figure 16.3. Increasing the number of slices.
Figure 16.4. Connections via directional antennas.
Figure 16.5. 6G with a vision of centralization.
Figure 16.6. Distribution of data centers at the Edge.
Figure 16.7. A possible 6G ad hoc mode.
Figure 16.8. The box of a 6G mesh network (Green Communications).
Figure 16.9. A 6G mesh network (Green Communications).
Figure 16.10. Cloud Continuum-based 6G.
Figure 16.11. The digital infrastructure of the future.
Figure 16.12. Advanced 6G programming technologies.
Guide
Cover Page
Table of Contents
Title Page
Copyright Page
Preface
Begin Reading
Conclusion
List of Authors
Index
WILEY END USER LICENSE AGREEMENT
Pages
iii
iv
xi
xii
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
SCIENCES
Networks and Communications, Field Director – Guy Pujolle
Cloud Networking, Subject Head – Kamel Haddadou
Cloud and Edge Networking
Kamel Haddadou
Guy Pujolle
First published 2023 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:
ISTE Ltd27-37 St George’s RoadLondon SW19 4EUUK
www.iste.co.uk
John Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030USA
www.wiley.com
© ISTE Ltd 2023The rights of Kamel Haddadou and Guy Pujolle to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s), contributor(s) or editor(s) and do not necessarily reflect the views of ISTE Group.
Library of Congress Control Number: 2022950912
British Library Cataloguing-in-Publication DataA CIP record for this book is available from the British LibraryISBN 978-1-78945-128-3
ERC code:PE7 Systems and Communication Engineering PE7_8 Networks (communication networks, sensor networks, networks of robots, etc.)
Preface
Cloud Networking is revolutionizing the field of networks by proposing a complete paradigm shift. The Cloud imposes a completely different vision of the Internet with centralized controls and a virtualization of all the functions necessary to the life of a network, the latter consisting of the replacement of hardware equipment by software equipment which runs in the Cloud. As a result, physical networks are replaced by logical networks that run in data centers that are more or less remote from the network nodes themselves.
The broad categories of Clouds, with data centers ranging from infinitely large to infinitely small, are examined and described in detail. Data centers within 10 km form the Edge and support real-time applications with latencies of less than 1 ms. This set of data centers takes the shape of the Cloud Continuum, which becomes the core environment for Cloud Networking. The logical devices that replace the physical devices must be urbanized in this environment, that is, positioned in the Cloud Continuum in the optimal location for the network to work best.
This book then introduces the digital infrastructure of the 2020s, which is composed of three elements: an antenna that collects the signals from users, an optical fiber that carries the signal and the data center that receives this signal, processes it and performs all the functions requested by the user. All material devices and intermediary equipment are recreated as virtual machines. Thus, it is possible to add many functions such as control, management, security, intelligence, automation and so on.
Another feature is the use of open source software, which seems to be self-evident since the whole point of this new generation of Cloud Networking is to be able to reduce costs despite the increase in user throughput that doubles every year. The agility and flexibility of this approach makes it an incomparable solution that is widely introduced in this book.
This new generation of software-defined networking technology translates into a number of products, described in detail, including SD-WAN, which constitutes the main requirement of large enterprises along with vCPE (virtual Customer Premises Equipment) and data center access fabrics. The impact of Cloud Networking is equally important in carrier networks and network providers. It is the foundation of 5G and even forms the revolutionary aspect of this generation. Indeed, what is typically called 5G relates to the radio part of this technology, but that is not the most important part. The revolutionary part is the MEC (Multi-access Edge Computing) data centers that sit on the edge of the Edge with response times that support a whole new set of real-time services such as vehicular network automation, Industry 4.0, touch networks and so on.
SDN has a special role in Cloud Networking, providing automated control of the digital infrastructure through centralization. However, this solution has not yet fully imposed itself due to its overly disruptive aspect, simultaneously providing automated control of a new generation of equipment through the migration of intelligence to the central controller but also a level of centralization that can seem too exacerbated.
Finally, we introduce in this book a whole set of important points like security, reliability, intelligence and acceleration. It ends with a vision of what Cloud Networking could become in the future, especially with 6G. Indeed, a return to hardware is more than likely to both improve performance and consume much less energy.
We hope to fulfill the expectations of all those interested in Cloud Networking with a relatively high-level vision of all the elements necessary to fully understand the path of this technology toward 6G.
Kamel HADDADOU and Guy PUJOLLE
July 2023
1Introduction to Edge and Cloud Networking
1.1. Introduction to digital infrastructure
For the next 10 years, digital infrastructure in Cloud Networking will establish itself as the basic standard. This standard has been adopted by all network and telecommunications equipment manufacturers. It consists of four elements: the terminal equipment, an antenna, an optical fiber and a data center. To understand the reasons that led to this architecture, we must start with the basic element: virtualization.
The virtualization process is described in Figure 1.1. This process is a result of moving from a physical machine to a logical machine. The first step is to write code that does exactly the same thing as the physical machine. Assuming the physical machine is a router, the virtual router code must perform the same routing and send the incoming packet processed by the logical code on the same outgoing line as the physical machine would.
The next step is to compare the performance of the physical machine and the logical machine by running it on the processor of the physical machine. Without accelerator hardware such as ASICs (application-specific integrated circuits) or Field-Programmable Gate Array (FPGAs), performance will easily drop by a factor of at least 10 and possibly as much as 100. If we assume this loss by a factor of 20, it would take a processor 20 times more powerful to achieve the same performance, which is not a problem with data center power. However, since energy consumption is very roughly proportional to processor power, it jumps to a high level.
The next step is to try to minimize the energy expenditure. To do this, the processor of the physical machine supporting the logical machine must be occupied as close to 100% as possible. As this is not really possible, we must try to stay around 80%. To achieve this, a sufficient number of virtual machines must be multiplexed to achieve a very good CPU utilization.
Figure 1.1.The virtualization process.
The solution is to group virtual machines so that there are exactly the right number of them. If demand is too high, virtual machines must be migrated to other servers and vice versa to maintain high CPU utilization. We can also see from Figure 1.1 that data center utilization is the solution since the many servers are either put into sleep mode if not in use or they run at high utilization. Optimization of energy consumption is therefore achieved by migrating virtual machines so that all servers not in standby mode are heavily used. Virtual machine migrations, that is, the movement of virtual machines from one server to another, are in the vast majority of cases carried out in the same data center and much more rarely between separate data centers.
Figure 1.2 shows a data center with its virtual machines. As shown, there are continuous migrations to optimize operation. We also need to be able to give the virtual machines the power they need to perform the requested task. To do this, we need an orchestrator of the data center resources that are allocated to the virtual machines.
This software virtualization should be replaced gradually by hardware virtualization because of reconfigurable processors, but it will take many years before this new generation arrives, which will consume much less energy and greatly increase performance.
Figure 1.2.A data center and its virtual machines.
The question arises as to which physical elements can be virtualized and which cannot be virtualized. In fact, it is better to look at the second part of the question since everything is virtualizable except for three elements: the sensors, the wireless communication cards and wired communication cards. Sensors are not virtualizable because they have to capture something, which cannot be done by a code. For example, we cannot measure the temperature in a room by writing a code. In the same way, we cannot capture an electromagnetic signal with a code, nor can we always send a light in an optical fiber by a code. Otherwise, everything is virtualizable: a Wi-Fi box, a firewall, a key, a switch, etc.
Cloud Networking is precisely the network solution that uses the digital infrastructure that was described at the beginning of this chapter, that is, based on four elements: the terminal equipment, the antenna, the optical fiber and the data center. We will start by describing a few types of Clouds and their importance.
The Cloud is above all a mechanism that consists of grouping the resources of a company in the Internet rather than having them directly in the company, in order to share them with other users and benefit from a strong multiplexing of the resources and therefore a reduced cost. Cloud providers also benefit from multiplexing by selling shared resources to users who may be located on different continents.
In the early 2000s, the utilization of hardware, software and personnel resources was not optimized, since these resources were heavily used only during peak hours and hardly at all at night. Average utilization calculations showed that resources were used at less than 20%. By connecting several companies to the same common resources at different peak times, it is possible to achieve utilization rates of around 80% without increasing the resources.
Figure 1.3.Virtualizable and non-virtualizable devices.
The problem that immediately arose concerned the data of companies that are in a public Cloud and are therefore often at the mercy of attackers or states requesting information from their providers for cybersecurity reasons.
Private Clouds have been democratized to take this issue into account and have become the majority. The data is often installed on several private clouds within the framework of either large companies with several sites or companies with a single site but independent departments.
Today, there are different types of Clouds that have become more complex to accommodate new diversification and availability parameters needed by businesses.
The first type concerns distributed Clouds. As shown in Figure 1.4, these are different types of Clouds offered by the same provider: public, private, close to the user, on the Edge, or in the core of the Internet network but much further from the user, which we will call the Core Cloud.
The Edge (data centers on the edge of the core network) or Cloud (data centers inside the core network) provider can offer several types of services that we will detail later: an infrastructure, a platform or an application software.
Figure 1.4.A distributed Cloud.
Another widely used term is Hybrid Cloud, in which the data centers can be both private and public but can come from different Cloud providers. The hybrid Cloud is therefore a solution that combines a private Cloud, one or more public Cloud services and often proprietary software that enables communication between each service. By opting for a hybrid Cloud strategy, companies gain greater flexibility by shifting loads between different Cloud providers as needs change, and costs can vary rapidly.
An illustration of this type of Cloud is provided in Figure 1.5, where we see the connection of the two Clouds realized by access to multiple applications carried by the public or private part.
Other types have also been defined, such as multi-Clouds, which bring together several providers to support all the services requested by companies and which allow better availability in the event of overload of one of the Clouds in the environment. These multi-Clouds bring together both public and private Clouds and different types of services, platforms, infrastructure and applications.
Finally, the term omni-Cloud is the most general to take into account the multitude of possibilities of associations and structures of Clouds.
Figure 1.5.A hybrid Cloud.
Figure 1.6.Hypervision and containerization.
In Figure 1.6, we describe the internal architecture of servers inside a data center. There are two main possibilities: hypervisor and containerization. The first is the older one, it concerns the support of virtual machines as it was originally conceived. The second solution is gradually replacing the first with a simpler, less expensive and more flexible architecture.
Hypervision consists of using a hypervisor on a standard physical machine (commodity) which is a software able to support several virtual machines simultaneously through one or several operating systems (OSs). The hypervisor supports domains formed by an operating system and the virtual machine running on it. The Domain 0 or Dom0 is specialized in processing the I/O of the other domains on the base physical machine.
There are different types of hypervisors. Paravirtualization requires that the operating systems be slightly modified so that all the processing requested by the virtual machine can be done natively on the basic physical machine. On the contrary, the second solution is to accept the operating systems without modification but with the introduction, above the hypervisor, of an emulation software able to adapt the execution of certain functions to the underlying physical machine.
Containerization is gradually replacing hypervisor with a division of services into microservices that each run in a container. In this case, a single operating system is used that supports containers that are isolated from each other to avoid “jumping”, allowing a user to move from one container to another. Each microservice runs in a container and application interfaces between microservices allow the service itself to be realized. We will study this microservices technology in more detail in the following section, as it allows for simpler updates without completely stopping the service, and also allows for simplified development of services.
This microservices technology is itself beginning to be replaced by a function-based solution that we will study in detail in the following section, which consists of building services with a succession of functions. This last solution is called serverless to indicate that the programmer who develops a function-based service is no longer at all aware that there are underlying servers.
1.2. Cloud services
Figure 1.7 explains the three major types of Clouds that are complemented by two new Clouds that fall between the solutions shown in Figure 1.7.
The first protocol stack on the left represents the case where a company has all the resources to run its information system. These resources include the network, storage and computing elements on hardware servers. To this must be added the virtualization and the operating system that support the company’s data and applications.
Figure 1.7.The three main types of Clouds.
Figure 1.8.The first service architectures.
When using an IaaS (Infrastructure as a Service) provider, the provider delivers the lower layers corresponding to the network, storage and computation with the virtualization environment and the company takes care of the upper layers. In PaaS (Platform as a Service), the provider takes care of everything except for the application. Finally, for SaaS, the provider offers all the layers including the applications. An example of the latter is Microsoft’s Office 365 service. SaaS represents approximately 50% of installed Clouds, and the other two share the rest.
We show in Figure 1.8 more classical cases that have been used for a long time and are gradually being replaced by the three cases we have described above. These are mainly colocation and hosting.
Now that we have introduced virtualization and the Cloud, we can move into Cloud Networking.
1.3. Cloud Networking
Cloud Networking is a group of network technologies that are based on the Cloud and thus on virtualization. The digital infrastructure is the basis: all the physical machines, all the services of the digital infrastructure and the application services form the Cloud Networking. First, let us define the virtual networks that form the basis of Cloud Networking.
Figure 1.9 shows a set of virtual networks that are made up of virtual machines, routers, switches, firewalls, authentication servers, etc. to perform all the functions necessary for a network to function properly. Each virtual network is made up of its own virtual machines which can be very different from each other. One network can be made up of IPv6 routers, another of Ethernet switches, a third of LSRs (Label Switch Routers) found in MPLS networks and finally a fourth that has very specific and proprietary equipment. These networks use the same data centers and cable infrastructures or microwave links between the virtual equipment. The number of virtual networks that can coexist on the digital infrastructure depends on the will of the environment manager and the traffic on each network. These virtual networks are called slices, and we will mainly use this word in 5G core networks. These different virtual networks must be independent and isolated from each other to prevent an attack from spreading from one network to another.
Figure 1.10 shows a virtual network built on data centers that become the network rooms of the digital infrastructure. In this figure, apart from the routers or switches, the equipment is not virtualized, such as the Internet boxes at the users’ premises or intermediate boxes such as the DPI (Deep Packet Inspection) or the firewall or an authentication server.
Figure 1.9.A set of virtual networks.
Figure 1.10.A virtual network with non-virtualized boxes.
Figure 1.11 introduces slicing, that is, as we have seen, the presence of several virtual networks on the same physical infrastructure. These networks may belong to different operators, each with its own packet transfer technology and specific functions. Slicing is most notably introduced in the 5G core network, the network that interconnects antennas to allow the transfer of information from one region to another. However, the slices are defined from end to end, so they continue on the access and radio parts as we will detail in Chapter 8. At the beginning, the 5G network will have only one slice to support user connections, and gradually the number of slices will increase to specialize in the connection of objects, the connection of vehicles, the connection of machine tools, etc. Then, these slices could become enterprise networks, enabling the different sites of the same company to be interconnected.
Figure 1.11.Slicing.
The step shown in Figure 1.12 is the complete virtualization of the physical infrastructure to allow the arrival of the digital infrastructure. All functions are virtualized, from the Internet box to the DPI, including the firewall and the authentication server, to name just a few.
Figure 1.12.Virtualization of all network functions.
Let us look, for example, at the case of the Internet box that is being set up by the operators. The antenna cannot be virtualized and therefore it is necessary to keep a box that will contain the Wi-Fi antenna and/or the 5G antenna. Behind this antenna, an optical fiber connects the electromagnetic signal reception box to a data center of the operator. These centers are those being deployed for 5G. They will be located less than 10 km from the antenna to allow for an extremely short latency time, in the order of a millisecond. Indeed, a 20-km round trip at the speed of light on an optical fiber takes 0.1 ms. With the access time to the antenna and the processing time of a short request, we are in the order of a millisecond. This value corresponds to the maximum latency time for real-time applications such as the control of a vehicular network, between the start of braking of one vehicle and the start of braking of the next vehicle. Similarly, for the control of robots and machine tools, one millisecond is the recommended time. Similarly, for performing remote surgery where the surgeon needs to see what he is doing, a time lapse in the order of one millisecond is acceptable. The functions integrated in the Internet box are virtualized in the operator’s data center. The name of the data centers of 5G operators is MEC (Multi-access Edge Computing), which succeeded the first definition of Mobile Edge Computing that referred only to mobile networks, while 5G is interested in all types of networks whether fixed or mobile. For example, a LAN (Local Area Network) using Wi-Fi is one of the connected systems in the 5G universe. The DPI function, which analyzes streams bit by bit, allowing the detection of anomalies by not recognizing the signatures of certain applications, is also virtualized in the Cloud. Similarly, the firewall and authentication server are virtualized in one of the operator’s MEC data centers or possibly in a data center of a Cloud provider.
The question of where the virtual machines or containers are positioned must be asked. Today, we work with the four levels that are represented in Figure 1.13. The level called the Cloud represents the large data centers that are at the heart of the Internet, the core Clouds. The other three levels make up the Edge Cloud, which is abbreviated as the Edge. The Edge itself has three levels: the MEC, the Fog and the Embedded Edge.
Figure 1.13.The four levels of Cloud and Edge Networking.
MEC is the furthest level from the customer, specified and realized in the 5G environment that introduces these data centers to define a digital infrastructure that will be built on top of the MEC data centers. 5G antennas or terrestrial access via Wi-Fi or other LAN techniques are connected over the MEC via fiber optics. The MEC data centers are intended to host all the virtual machines of the physical equipment and software located between the terminal equipment and the data center: signal processing, localization functions, control and management algorithms, environment autopilot, artificial intelligence processes, business applications, etc. In particular, there are real-time applications with strong constraints such as latency time, which must be in the millisecond range.
The name Fog Computing comes from the company CISCO, which in 2012 proposed to connect emerging objects (sensors, actuators and the like) on an intermediate data center to have a pre-processing before routing the selected information to a central Cloud to be processed. The term Fog has remained, and today it refers to data centers in companies but more particularly data centers on campuses, very close to the users, that is, a few hundred meters at most. The idea is to replace all physical equipment with virtual machines and to bring all business processes together as virtual machines or containers in the Fog data center. The latencies are very small, less than a millisecond.
The third level has several possible names including Embedded Edge, which we will use, as well as Skin, Mist or Far Edge. It is located very close to the user, within range of Wi-Fi or private 5G, which have the same range (a few tens of meters at most) since these two technologies transmit on free bands with the same constraints. The data centers are embedded computers of relatively low power at first. However, these embedded devices will become more and more powerful and will accept containerization and serverless technologies. The advantages of this solution are numerous: extremely low latency, data security while remaining in the user’s lap and minimization of energy consumption. The objective is also to have a mobile environment, the embedded Edge can be in a vehicle, in a mobile object, in a smartphone or in a specific equipment in a user’s pocket. The embedded Edge equipment is itself connected either to a more distant antenna such as an operator’s 5G antenna or to other embedded Edges to form an embedded Cloud. This solution automates vehicular networks or oversees the control of mobile robots, and more globally may realize intelligent mobile environments.
1.4. Network Functions Virtualization
The basis of the technologies used in the previous sections comes from NFV (Network Functions Virtualization), which consists of virtualizing all the functions of the various boxes, such as a NAT device, a firewall, a DPI, a controller, a router, etc., as shown in Figure 1.14.
The problem with NFV comes from the potential non-compatibility of virtual machines between them. As a result, operators, who were at the origin of the request, wanted to standardize virtual machines to allow simple interconnection between operators. The first request for standardization was addressed to ETSI, the telecommunications standardization body for Europe, and at the request of many companies from all over the world, they opened the doors to a worldwide standardization. Furthermore, ETSI approached the Linux Foundation to create an open-source code reflecting this standardization of virtual machines. But a few months after the start, ETSI wished to go further by proposing an open-source software package associated with each function to allow them to interact to realize a complete and operational platform. This platform took the name of OPNFV (Open Platform Network Functions Virtualization) and, at the end of the development process on December 31, 2021, more than ten thousand people-years of work (i.e. the equivalent of ten thousand people working for 1 year) to realize this software. The final name that was given to it is Anuket, coming from the LF-Networking (Linux Foundation Networking). The project lasted 6 years with the development of intermediate releases from A to I.
Figure 1.14.Network Functions Virtualization (NFV).
This Anuket platform of LF-Networking includes much open-source software of the Linux Foundation. The main work was to agglomerate all software while completing it. The general structure of this platform is described in Figure 1.15. It has three main parts:
NFVI (NFV Infrastructure), which is the infrastructure element required to run virtual machines not only for networking but also for storage and computation.
VNF (Virtual Network Function), which represents all available virtual functions from which the system will draw to perform the services requested by the users.
NFV MANO (Management and Orchestration), which is the autopilot of the platform.
Figure 1.15.The architecture of the LF-Networking Anuket platform.
The more precise architecture of the LF-Networking Anuket platform will be described in a later chapter.
1.5. Conclusion
We have seen in this chapter an introduction to the digital infrastructure that has greatly simplified the network environments we knew with a strong centralization of functions, whether they are digital infrastructure functions like signal processing or routing or infrastructure service functions with control, management, intelligence, automation, etc. or application functions corresponding to the large applications requested by the users. This change is revolutionary and has led to Cloud Networking, which is slowly coming into place as many pieces of the puzzle are not yet really available, such as MEC data centers or slicing.
1.6. References
Antonopoulos, N. and Gilla, L. (2017).
Cloud Computing: Principles, Systems and Application
. Springer, New York.
Artasanchez, A. (2021).
AWS for Solutions Architects: Design Your Cloud Infrastructure by Implementing DevOps, Containers, and Amazon Web Services
. Packt Publishing, Birmingham.
Ben Jemaa, F., Pujolle, G., Pariente, M. (2016). Cloudlet- and NFV-based carrier Wi-Fi architecture for a wider range of services.
Annals of Telecommunications
, 71(11–12), 617–624.
Comer, D. (2021).
The Cloud Computing Book: The Future of Computing Explained
. CRC Press, Boca Raton.
Culkin, J. and Zazon, M. (2021).
AWS Cookbook: Recipes for Success on AWS
. O’Reilly, Sebastopol.
Dutt, D. (2019).
Cloud Native Data Center Networking: Architecture, Protocols, and Tools
. O’Reilly, Sebastopol.
Fox, R. and Hao, W. (2017).
Internet Infrastructure: Networking, Web Services, and Cloud Computing
. CRC Press, Boca Raton.
Gessert, F., Wingerath, W., Ritter, N. (2020).
Fast and Scalable Cloud Data Management
. Springer, Cham.
Gray, K. and Nadeau, T.D. (2016).
Network Function Virtualization
. Morgan Kaufmann, Burlington.
Halabi, S. (2019).
Hyperconverged Infrastructure Data Centers: Demystifying HCI
. Cisco Press, Indianapolis.
He, Y., Ren, J., Yu, G., Cai, Y. (2019). D2D communications meet mobile Edge computing for enhanced computation capacity in cellular networks.
IEEE Transactions on Wireless Communications
, 18(3), 1750–1763.
Kraemer, F.A., Braten, A.E., Tamkittikhun, N., Palma, N. (2017). Fog computing in healthcare – A review and discussion.
IEEE Access
, 5, 9206–9222.
Mach, P. and Becvar, Z. (2017). Mobile Edge computing: A survey on architecture and computation offloading.
IEEE Communications Surveys & Tutorials
, 19(3), 1628–1656.
Mao, Y., You, C., Zhang, J., Huang, K., Letaief, K.B. (2017). A survey on mobile Edge computing: The communication perspective.
IEEE Communications Surveys Tutorials
, 19(4), 2322–2358.
Moura, J. and Hutchison, D. (2019). Game theory for multi-access Edge computing: Survey, use cases, and future trends.
IEEE Communications Surveys Tutorials
, 21(1), 260–288.
Mouradian, C., Naboulsi, D., Yangui, C., Glitho, R.H., Morrow, M.J., Polakos, P.A. (2018). A comprehensive survey on fog computing: State-of-the-art and research challenges.
IEEE Communications Surveys Tutorials
, 20(1), 416–464.
Mukherjee, M., Shu, L., Wang, D. (2018). Survey of fog computing: Fundamental, network applications, and research challenges.
IEEE Communications Surveys Tutorials
, 20(3), 1826–1857.
Olaoye, A. (2022).
Beginning DevOps on AWS for iOS Development
. Apress/Springer Nature, Cham.
Perera, C., Qin, Y., Estrell, J.C.A., Reiff-Marganiec, S., Vasilakos, A.V. (2017). Fog computing for sustainable smart cities: A survey.
ACM Computing Surveys
, 50(3), 1–43.
Satyanarayanan, M. (2017). The emergence of Edge computing.
Computer
, 50(1), 30–39.
Shaukat, U., Ahmed, E., Anwar, Z., Xia, F. (2016). Cloudlet deployment in local wireless networks: Motivation, architectures, applications, and open challenges.
Journal of Network and Computer Applications
, 62, 18–40.
Sujata, D., Subhendu, K., Ajith, A., Yulan, L. (2021).
Advanced Soft Computing Techniques in Data Science, IoT and Cloud Computing
. Springer, Cham.
Vaquero, L.M. and Rodero-Merino, L. (2014). Finding your way in the fog: Towards a comprehensive definition of fog computing.
ACM SIGCOMM Computer Communication Review
, 44(5) 27–32.
Zburivsky, D. and Partnet, L. (2021).
Designing Cloud Data Platforms
. Manning Publications, Shelter Island.
