Software-Defined Networking 2
Description
Additionally, a thorough examination of the major challenges of existing distributed SDN controllers is provided along with insights into emerging and future trends in that area. Decentralization challenges in large-scale networks are tackled using three novel approaches, applied to the SDN control plane presented in the book. The first approach addresses the SDN controller placement optimization problem in large-scale IoT-like networks by proposing novel scalability and reliability aware controller placement strategies. The second and third approaches tackle the knowledge sharing problem between the distributed controllers by suggesting adaptive multilevel consistency models following the concept of continuous Quorum-based consistency. These approaches have been validated using different SDN applications, developed from real-world SDN controllers.
More details
Other editions
Additional editions
Persons
Fetia Bannour is an Associate Professor in Computer Science at ENSIIE and SAMOVAR, France. She earned her PhD in Computer Networks from the University of Paris-Est. Her research interests include the control/management of SDN and NFV-based future networks.
Sami Souihi is an Associate Professor in Computer Science at the N&T Department and the LiSSi-TincNET research team (Paris-Est Créteil University (UPEC)), France. His research work focuses on adaptive mechanisms in large-scale dynamic systems, among others.
Abdelhamid Mellouk is currently the Director of IT4H High School Engineering Department, a Full Professor at the University of Paris-Est Créteil (UPEC) and Head of UPEC-LiSSi-TincNET research team, France. He is the founder of the Network Control Research and Curricula activities in UPEC, the current co President of the French Deep Tech Data Science and Artificial Intelligence Systematic Hub, member of the High Scientific Research and Technology National Council (DZCNRST) and associate editor in several top ranking scientific journals.
Content
Acronyms ix
Preface xiii
Introduction xvii
Chapter 1 Toward a Decentralized SDN Control Architecture: Overview and Taxonomy 1
1.1. Introduction 1
1.2. Software-defined networking: a centralized control architecture 2
1.2.1. Conventional networking and the SDN paradigm 2
1.2.2. The SDN architecture 3
1.3. Physical classification of existing SDN control plane architectures 8
1.3.1. Physically centralized SDN control 8
1.3.2. Physically distributed SDN control 11
1.4. Logical classification of existing SDN control plane architectures 16
1.4.1. Logically centralized SDN control 17
1.4.2. Logically distributed SDN control 22
1.5. Conclusion 26
Chapter 2. Decentralized SDN Control: Major Open Challenges 27
2.1. Introduction 27
2.2. Scalability 28
2.2.1. Data plane extensions 30
2.2.2. Control plane distribution 32
2.3. Reliability 33
2.3.1. Control state redundancy 33
2.3.2. Controller failover 34
2.4. Controller state consistency 35
2.4.1. Static consistency 36
2.4.2. Adaptive multi-level consistency 37
2.5. Interoperability 38
2.5.1. Interoperability between the SDN controllers 38
2.5.2. SDN interoperability with legacy networks 38
2.6. Other challenges 39
2.7. Conclusion 40
Chapter 3 Scalability and Reliability Aware SDN Controller Placement Strategies 41
3.1. Introduction 41
3.2. Related work 42
3.3. The SDN controller placement optimization problem 44
3.3.1. Problem statement 44
3.3.2. Problem formulation 45
3.3.3. Placement metrics 45
3.4. The proposed SDN controller placement scheme 49
3.4.1. The adopted approach 49
3.4.2. Multi-criteria placement algorithms 50
3.4.3. Gradual strategies 52
3.5. Performance evaluation 53
3.5.1. Simulation settings 53
3.5.2. Simulation results 54
3.6. Discussion 60
3.7. Conclusion 62
Chapter 4 Adaptive and Continuous Consistency for Distributed SDN Controllers: Anti-Entropy Reconciliation Mechanism 65
4.1. Introduction 65
4.2. Related work 66
4.3. The consistency problem in SDN 68
4.3.1. Consistency trade-offs in SDN 68
4.3.2. Consistency models in SDN 69
4.4. Consistency models in ONOS 70
4.4.1. Strong consistency in ONOS 70
4.4.2. Eventual consistency in ONOS 71
4.5. The proposed adaptive consistency for ONOS 72
4.5.1. A continuous consistency model for ONOS 72
4.5.2. Our consistency adaptation strategy for ONOS 74
4.5.3. Our implementation approach 74
4.6. Performance evaluation 76
4.6.1. Experimental setup 76
4.6.2. Results 76
4.7. Conclusion 79
Chapter 5 Adaptive and Continuous Consistency for Distributed SDN Controllers: Quorum-Based Replication 81
5.1. Introduction 81
5.2. Background on eventual consistency in distributed data stores 83
5.2.1. Consistency and performance metrics 83
5.2.2. Adaptive consistency control 84
5.2.3. Existing modern tunable consistency systems 84
5.3. The proposed adaptive Quorum-inspired consistency for ONOS 86
5.3.1. A continuous consistency model for ONOS 86
5.3.2. Our Quorum-inspired consistency adaptation strategy for ONOS 87
5.4. Implementation approach on ONOS 93
5.4.1. Design of a CDN-like application 93
5.4.2. State synchronization and content distribution 94
5.4.3. Content delivery to customers 95
5.5. Performance evaluation 97
5.5.1. Application-specific performance and consistency metrics 97
5.5.2. Experimental setup 98
5.5.3. Results 103
5.6. Conclusion 112
Conclusions and Perspectives 115
C.1. Summary of contributions 115
C.2. Perspectives and future work 117
References 121
Index 139
1
Toward a Decentralized SDN Control Architecture: Overview and Taxonomy
1.1. Introduction
In contrast to the decentralized control logic that underpins the construction of the Internet as a complex bundle of box-centric protocols and vertically integrated solutions, the software-defined networking (SDN) paradigm advocates the separation of the control logic from hardware and its centralization in software-based controllers. These key tenets offer new opportunities to introduce innovative applications and incorporate automatic and adaptive control aspects, thereby easing network management and guaranteeing the user's QoE.
However, despite the interest surrounding SDN, adoption raises many challenges, including the scalability and reliability issues of centralized designs that can be addressed with the physical decentralization of the control plane. However, such physically distributed but logically centralized systems bring an additional set of challenges.
This chapter presents a survey on SDN with a special focus on distributed SDN control. In section 1.2, we start by describing the promises and solutions offered by SDN compared to conventional networking. We also elaborate on the fundamental elements of the SDN architecture.
Then, we expand our knowledge of the different approaches to SDN by exploring the wide variety of existing SDN controller platforms. In doing so, we intend to place a special emphasis on distributed SDN solutions and classify them in two different ways. In section 1.3, we propose a physical classification of state-of-the-art SDN control plane architectures into centralized and distributed (flat or hierarchical) in order to highlight the SDN performance, scalability and reliability challenges. In section 1.4, we put forward a logical classification of distributed SDN control plane architectures, logically centralized and logically distributed, while tackling the associated state consistency and knowledge dissemination issues.
1.2. Software-defined networking: a centralized control architecture
1.2.1. Conventional networking and the SDN paradigm
Over the past few years, the need for a new approach to networking has been expressed to overcome the many issues associated with current networks. In particular, the main vision of the SDN approach is to simplify networking operations, optimize network management and introduce innovation and flexibility compared to legacy networking architectures.
In this context, and in line with the vision of Kim and Feamster (2013), four key reasons for the problems encountered in the management of existing networks can be identified:
1) Complex and low-level network configuration: network configuration is a complex distributed task in which each device is typically configured in a low-level vendor-specific manner. Additionally, the rapid growth of the network, together with the changing networking conditions, have resulted in network operators constantly performing manual changes to network configurations, thereby compounding the complexity of the configuration process and introducing additional configuration errors.
2) Dynamic network state: networks are growing dramatically in size, complexity and consequently in dynamicity. Furthermore, with the rise of mobile computing trends as well as the advent of network virtualization (Bari et al. 2013; Alam et al. 2020) and cloud computing (Zhang et al. 2010; Sharkh et al. 2013; Shamshirband et al. 2020), the networking environment becomes even more dynamic as hosts are continually moving, arriving and departing due to the flexibility offered by VM migration, thus making traffic patterns and network conditions change in a more rapid and significant way.
3) Exposed complexity: in today's large-scale networks, network management tasks are challenged by the significant complexity presented by distributed low-level network configuration interfaces. This complexity is mainly generated by the tight coupling between the management, control and data planes, where many control and management features are implemented in hardware.
4) Heterogeneous network devices: current networks consist of a large number of heterogeneous network devices including routers, switches and a wide variety of specialized middle-boxes. Each of these appliances has its own proprietary configuration tools and operates according to specific protocols, therefore increasing both complexity and inefficiency in network management.
As a result, network management is becoming more difficult and challenging given that the static and inflexible architecture of legacy networks is ill-suited to cope with today's increasingly dynamic networking trends, and to meet the QoE requirements of modern users. This has fueled the need for the enforcement of complex, high-level policies to adapt to current networking environments, and for the automation of network operations to reduce the tedious workload of low-level device configuration tasks.
In this sense, and to deliver the goals of easing network management in real networks, operators considered running dynamic scripts as a way to automate network configuration settings before realizing the limitations of such approaches, which led to misconfiguration issues. It is worth noting, however, that recent approaches to scripting configurations and network automation are becoming relevant (e.g. Ansible).
The SDN initiative led by the Open Networking Foundation (ONF), on the other hand, proposes a new open architecture to address current networking challenges with the potential to facilitate the automation of network configurations and, better yet, fully program the network. Unlike the conventional distributed network architecture (Figure 1.1(a)) in which network devices are closed and vertically integrated, bundling software with hardware, the SDN architecture (Figure 1.1(b)) raises the level of abstraction by separating the network data and control planes. In this way, network devices become simple forwarding switches; all the control logic is centralized in software controllers, providing a flexible programming framework for the development of specialized applications and deployment of new services.
Such aspects of SDN are believed to simplify and improve network management by offering the possibility to innovate, customize behaviors and control the network according to high-level policies expressed as centralized programs. This therefore bypasses the complexity of low-level network details and overcomes the fundamental architectural problems raised in points 1) and 3). Added to these features is the ability of SDN to easily cope with the heterogeneity of the underlying infrastructure (outlined in point 4)) thanks to the SDN southbound interface abstraction.
More detailed information on the SDN-based architecture, which is split vertically into three layers (see Figure 1.2), is provided in the next section.
1.2.2. The SDN architecture
The SDN-based architecture is split vertically into three layers (see Figure 1.2). Detailed information about the SDN architecture is provided in the sections that follow.
Figure 1.1 Conventional networking versus software-defined networking.
1.2.2.1. SDN data plane
The data plane, also known as the forwarding plane, consists of a distributed set of forwarding network elements (mainly switches) in charge of forwarding packets. In the context of SDN, the control-to-data plane separation feature requires the data plane to be remotely accessible for software-based control via an open vendor-agnostic southbound interface.
Both OpenFlow (McKeown et al. 2008; Costa et al. 2021) and ForCES (Forwarding and Control Element Separation) (Doria et al. 2010; Anerousis et al. 2021) are well-known candidate protocols for the southbound interface. They both follow the basic principle of splitting the control plane and the forwarding plane in network elements, and they both standardize the communication between the two planes. However, these solutions are different in many aspects, especially in terms of network architecture design.
Standardized by IETF, ForCES (Doria et al. 2010; Anerousis et al. 2021) introduced separation between the control plane and the forwarding plane. In doing so, ForCES defines two logic entities that are logically kept in the same physical device: the control element (CE) and the forwarding element (FE). However, despite being a mature standard solution, the ForCES alternative did not gain widespread adoption by major router vendors.
Figure 1.2 A three-layer distributed SDN architecture.
On the other hand, OpenFlow (McKeown et al. 2008; Costa et al. 2021) received major attention in both the research community and industry. Standardized by the ONF, it is considered the first widely accepted communication protocol for the SDN southbound interface.
OpenFlow enables the control plane to specify, in a centralized way, the desired forwarding behavior of the data plane. Such traffic forwarding decisions reflect the specified network control policies and are translated by controllers into actual packet forwarding rules, populated in the flow tables of OpenFlow switches.
In more specific terms, and according to the original version 1.0.0 of the standard defined by Open Networking Foundation (2009), an OpenFlow-enabled Switch consists of a flow table and an OpenFlow secure channel to an external OpenFlow controller. Typically, the forwarding table maintains a list of flow entries. Each flow entry...
