Project topics and materials
Get Complete Project Material File(s) Now! »
SDN Architecture
SDN architecture [7, 11–18] compounds four layers (see Figure 2.1). The bottom layer is the Infrastructure Plane (Data Plane Layer). It processes network traffic and executes network for-warding/routing behaviors. The application layer is localized on the top of the architecture. It runs the business logic of network stakeholders. It defines different network services such as load balancing, firewalls, VoIP, and other services. The control layer (controller) is situated be-tween the previous two layers. It provides the application layer with network state and network data. It interacts through Northbound APIs with the application layer and Southbound APIs with the infrastructure layer. Besides, the control layer uses East/West APIs to exchange with other controllers. The management layer is connected to the three layers mentioned above. It manages the configuration, provisioning, and administration of their resources.
Infrastructure layer
The infrastructure layer (Data Plane Layer) consists of a set of interconnected network ele-ments. Data links ensure this interconnection in the infrastructure. Each link connects a port of a network Element to the port of its neighbor. A network element performs computation, stor-age and forwarding operations on network traffic. Network elements can be virtual or hard-ware switches, routers, middle-boxes, and other network components. They integrate open programmable interfaces. The control layer uses these interfaces to reprogram their behaviors and to extract their local states. They operate directly on network traffic by performing for-warding behavior, routing tasks, caching, packet inspection and other networking operations.
Open Virtual Switch is a concrete example of an SDN network element. This open source software switch is included in every Linux distribution [19]. It supports many SDN protocols such as OpenFlow. Its modular design eases its integration with vendors switches. This inte-gration guarantees the acceleration of switching and the support of OpenFlow without imple-menting it in vendors’ hardware [20]. Vendors use the provided interface to run OVS and Open-Flow in their Hardware. OVS implements its modules in two spaces [21–23]. In the user space, it integrates OpenFlow in the switch daemon Ovs-vswitchd. In the kernel space, it proposes a kernel module (Datapath Kernel) that abstracts the forwarding behavior based on flows.
Southbound API
The Southbound API (Data Control Planes Interface (D-CPI)) is an open programmable inter-face between the infrastructure layer and the control layer. It supports the interactions be-tween both layers by offering them all the necessary abstractions and protocols. It has mainly two functions. It provides the control layer with abstractions to communicate with network elements. Besides, it executes the commands of the control layer in network elements.
There are many available D-CPI such as Protocol Oblivious Forwarding (POF) [24, 25], Open-VSwitch Data Base Management Protocol (OVSDB) [26], OpenState [27], Programmable Ab-straction of Datapath (PAD) [28], Hardware Abstraction Layer (HAL) [29], LISP [30] and Open Policy Flexible Protocol (OPFlex) [31]. However, OpenFlow [32] is the most widely used D-CPI. This standardized open interface enables the control layer to reprogram the forwarding behav-ior of the infrastructure layer and to pull its state. Mainly, it uses Flow rules to configure the Data Plane Layer. Flow rules are a set of matching fields associated with actions and an in-struction that describes how the network element should execute these actions. Flow rules are kept in OpenFlow tables inside network elements.
Control layer
The control layer (also called the controller) is considered the brain of the network. It is a log-ically centralized entity that embeds interfaces, network operations, network state and a de-velopment environment to control the behavior of network elements. It abstracts the network infrastructure, processes network states and creates a domain knowledge of the network. Net-work applications use these abstractions to reprogram the network elements. Moreover, SDN controllers interpret applications policies into low-level rules. They guarantee the consistency and validity of rules installation in network elements. Besides, they monitor the network ele-ments and network traffic by extracting network state, network events, metrics and other pa-rameters.
The control layer can be considered as a Network Operating System that simplifies the de-velopment of network applications. It drives open programmable interfaces by interpreting applications requirements into hardware specifications and by deploying them in the network elements. It collects network states also using these interfaces. It guarantees network con-sistency by dynamically managing rule updates throughout the entire network. It offers a de-velopment environment to implement control functions. It constructs a holistic view of the network using the collected infrastructure states. Besides, it manages the virtualization of the infrastructure layer. Physically, the control layer can be a single entity running on one server or a set of dis-tributed controllers running on many servers. In the latter case, the distributed controllers co-operate to harmonize the control logic and to guarantee network consistency. The distributed control architecture is advantageous regarding scalability and performance because it enables the distribution of the load on many controllers. As a result, it prevents the control layer from becoming a bottleneck. Also, it limits overheads due to frequent network events handled by a single controller. Distributed controllers are more resilient than centralized controllers be-cause they can handle failures while keeping control of the network.
Furthermore, the controller can include Network Programming Languages. Network appli-cations use them to program controller functions. These languages can offer formal validation mechanisms to check the consistency of network functions. FML [33], Nettle [34], Frenetic [35], Procera [36]and Pyretic [37] are examples of SDN languages.
The SDN community has developed many open source controllers. NOX [38] is the first SDN controller that has been developed as an open source control layer. This single-threaded controller is implemented in the C language. Opendaylight [39] is a control layer project that has been developed to satisfy network operators’ needs. It is implemented in Java, and it pro-vides many SDN interfaces. It provides development environments that create control func-tionalities and their interaction patterns. ONOS [40] is an open source NOS. It is a distributed architecture based on clustering the control layer to ensure high performance and scalability. RYU [41] is a software component SDN controller. Its software architecture is multi-threaded. It supports all the versions of OpenFlow.
Eastbound and Westbound APIs
Eastbound and Westbound APIs (Control Control Planes Interface (C-CPI)) enable controllers to communicate within the control layer. Depending on the communication peer, there are two types of Eastbound and Westbound APIs. An Eastbound interface manages communications between an SDN controller and a legacy network. It integrates the mechanisms that interpret SDN interactions into their none SDN counterparts and vice-versa. A Westbound interface manages communications between only SDN controllers. It ensures the interoperability be-tween different types of SDN controllers. It improves network consistency and inter-domain policy deployment. Depending on the position of controllers, intermediary controllers inte-grate both types of interfaces, whereas edge controllers integrate one type. The locality of con-trollers is essential for running the proper Interface with one of the other peers.
Eastbound and Westbound APIs are used to control traffic between multiple domains that are governed by different controllers. This coordination has different aspects. Controllers can be from different vendors. In this case, the interface ensures the interoperability between them. They can have different functions and network applications. Another controller can solicit the functions through the interface. Different administrative authorities can govern the domains. In this case, the interface is used to route the packet to its destination or to calculate the costs of the paths. Finally, the interface can be used to divide a load of a controller on different controllers to ensure suitable scalability.
C-CPI is not standardized yet. For example, SDNi [42] is a Westbound interface for SDN multi-domain communications. It defines multi-control orchestration and coordination in-teractions across multiple SDN domains. It enables controllers to collaborate to reprogram the behaviors of their network elements which is crucial for inter-domain network operations such as path computing, routing, load balancing and other global network services. SDNi also handles information exchanges like QoS, SLAs, flow setup requests, reachability updates be-tween controllers. It also enables the sharing of domain Knowledge and resources such as QoS, domain topology and other information.
Northbound API
Northbound API (Application Control Planes Interface (A-CPI)) is a programmable interface between controllers and network applications. It enables the latter to interact with the control plane and to deploy its requirements across the network infrastructure [43]. This abstraction enables network applications to profit from the full potential of SDN features such as global knowledge, programmability, automation, and policy deployment. It offers network applica-tions universal data models, network states, management information and other functions. The latter use the interface to reprogram the behavior of network elements and to update the network state. The interface ensures the interoperability of network applications. Thus, the latter can in-teract with any controller without relying on its implementation. In the same way, network applications become entirely independent from the infrastructure implementation. It hides all the control functions’ complexity while integrating the proper modules that plug network ap-plications with the control layer functions. Besides, it abstracts the details of the infrastructure by hiding the implementation of the forwarding behavior of network elements.
The interface features abstract the functions of the controller to simplify the infrastructure configuration. For instance, network applications express through the northbound interface network policies. The controller uses the policies to perform network computation (for ex-ample, routing). The latter includes network constraints such as traffic priorities, QoS, racing conditions, consistency checking and other control operations. Then, through the southbound interface, it interprets the received policies and the results into southbound API rules such as OpenFlow rules.
Expected SDN Benefits
Thanks to its features externalization, centralization, programmability and federation, SDN of-fers many benefits [53–55]. For instance, SDN leverages the network with simplification, con-vergence, agility, operation automation, global knowledge, orchestration, efficiency, and open-ness. These advantages make SDN a key solution to integrate into operational environments. Cloud Computing, data centers, Wide Area Networks (WAN), mobile networks, Network Func-tion Virtualization (NFV) and many others can benefit from SDN as an innovation enabler. Moreover, on the business level, SDN contributes to cost reduction, simplifies network admin-istration and enhances network quality.
Simplicity and convergence
SDN hides the complexity of hardware thanks to federation, programmability, and external-ization. Network applications can reprogram the network elements and collect data without worrying about the details of the underlying layers. This simplicity enhances network cost sav-ings, reduces its complexity and improves innovation. Developers need to integrate into their implementation only the proper SDN interface module instead of developing a specific appli-cation that runs only on a specific network device. The controller abstracts the complexity of the infrastructure layer by offering high-level lan-guages and models. This simplicity leads to the convergence of different vendors technologies around the same concepts and models. SDN convergence enhances data transfer, application collaboration and operations upgrades. It enables the exchange of information between the vendor’s solutions, the control layer, and network elements. It transforms them into intelligible and unified data models that can be reused in different environments.
Table of contents :
Contents
List of Figures
List of Tables
I Thesis Background
1 Introduction
1.1 General Introduction
1.2 Context
1.3 Problem Statement
1.4 Solution and Contribution Overview
1.5 Thesis Organization
2 Software Defined networking
2.1 Introduction
2.2 SDN Paradigm
2.3 SDN Architecture
2.4 OpenFlow
2.5 Expected SDN Benefits
2.6 SDN Challenges
2.7 Discussion
3 Security in Software Defined Networking
3.1 Introduction
3.2 FromNetwork Security to SDN Security
3.3 Security for SDN
3.4 SDN for security
3.5 Discussion
II Security for SDN
4 Software Defined Networking Vulnerability Analysis
4.1 Introduction
4.2 Problem Statement
4.3 Vulnerability Analysis Concepts
4.4 SDN Asset Classification
4.5 SDN Vulnerability Procedure
4.6 Vulnerability severity results
4.7 Discussion
III SDN for Security
5 Centralized SDN Firewall
5.1 Introduction
5.2 Conventional Firewalls
5.3 Motivation for an SDN Firewall
5.4 Key Concepts
5.5 Implementation
5.6 Evaluation
5.7 Discussion
6 SDN Firewall Orchestration
6.1 Introduction
6.2 Context and Objectives
6.3 SDN firewall policy model
6.4 Implementation
6.5 Evaluation
6.6 Discussion
IV Conclusion
7 Conclusion
7.1 General Conclusion
7.2 Contribution Summary
7.3 Perspectives
V Appendix
.1 Appendix AHP Computations
VI References
