Conclusiones e Impacto y recomendaciones respecto al desarrollo de la práctica profesional

The proposed solutions to control plane scalability issue of an SDN network can be classified in two broad categories. First, control plane itself is a vicinity to solve the scalability of the network by means of some networking architectures. Second category aims to exploit some well-known optimization techniques in order to alleviate the foregoing issue in an SDN network.

As a solution to improve the scalability of an SDN network, networking topologies like central controller architecture and distributed networking are famous settings for SDN networks. Central controller centric settings utilize a central controller which is powered with global network view, applications and policies.

[69] proposes a central controller based network targeting enterprises networks. An Ethane network comprises of a controller which accounts for routing task and sim- ple and dump switches to forward packets on controller commands. Ethane network performs five main functions: registration, bootstrapping, authentication, flow setup, and forwarding. While Ethane brings ease of use and can scale to large networks, it

might be cheated by means of MAC addresses to send packets, which is an open issue to be addressed.

NOX [23] is a network operating system which is more than just a controller plat- form for a network. A NOX network has switches, server(s) running NOX software acting like a controller along with applications atop, and a database to keep network view for applications. The network view consists of network topology, users, end- points, etc.. As in most SDN controller platforms, NOX treats the packets based on the first packet of a flow traversing through the controller. This flow-based method helps increase the scalability of a network.

In distributed type of architectures, the controllers share the same global view and cope with the traffic locally and coming from neighbor domains. The purpose of a distributed networking is to reduce the load on the central controller and avoid the failure of the central controller.

In HyperFlow [72], local controllers are utilized to serve all requests for their own remote sites and thereby flow setup times and flow initiation rates drop by the time. HyperFlow is logically centralized albeit its distributed architecture is an event-based control plane for OpenFlow and is actually implemented as a NOX application. Its main tasks are: global network view synchronization between controllers, communica- tion with switches controlled by another controller from a different site, and managing responses coming from switches in other sites to the request-originator controllers.

[82] introduces a distributed cluster-based controller architecture to retain the communication and coordination between controllers to obtain a more scalable net- work. This cluster-based architecture brings flexibility to the network regarding adding or removing controllers since it does not bother network applications. In the proposed network, each switch is associated with a single controller via an IP network.

[77] proposes Onix, a distributed control platform, in responses to lack of a control platform which provides consistent network state and global network view for network devices and applications. Onix instances propagate network states to other instances

to be able to scale large networks. The authors follow three approaches for a better scalability in Onix architecture; (1) work partitioning by applications for less work on instances, (2) cluster aggregation for a hierarchical structure, and (3) consistency and durability of the network states for applications.

The architecture called ElastiCon in [68] aims to evenly distribute load in con- trollers by a controller pool since they may not be loaded equally due to static configu- ration. The proposed architecture has two main mechanisms to dynamically shift the workload across the controllers in a pool which is dynamically expanding or shrink- ing. Their framework considers the total load on controllers and may add or remove controllers based on the load exceeding or falling down a threshold. It may also move switches from one controller to another if the load on a controller is more than a pre-defined threshold.

Kandoo [73] focuses on scaling controller by decreasing the number of frequent events on the control plane since these events bring more overhead than others to the controller plane. Kandoo’s setting is similar to this framework proposed but there are two differences. First, in Kandoo, the local controllers are handling less number of switches than the local controllers proposed in the setting proposed in this chapter. Second, routing with Quality of Service (QoS) for connection requests is considered in the architecture proposed. Users may specify their requested QoS values when they ask for a connection. On the other hand, the Orion [79] exploits a hybrid hierarchical architecture along with a routing method for large-scale networks in which a large size domain, managed by one administrator, is divided into sub-domains. The proposed framework differs from the Orion since routing with QoS for both intra-domain and inter-AS traffic is considered while the Orion considers for only intra-domain traffic. Optimization-based designs aim to empower the controller performance so that it can handle more packet flows per second and reduce the latency and overhead. They achieve this by exploiting some techniques like parallelism, multi-threaded designs, batching, efficient routing decisions.

In [75], Maestro is proposed to increase scalability in SDN networks by empower- ing multi-core architecture to leverage the parallelism in order to increase controller speed along with hassle-free programming model for application writers. Maestro is designed to partition the workload evenly available in threads in cores to increase the performance (i.e throughput) by keeping all processor cores busy by means of “pull” fashion instead of “push” fashion. Maestro balances the memory consumption by keeping no data between stages in CPU cores’ threads.

Beacon [25] is reinforced for a high performance by multi-threaded designs; “Shared Queue” and “Run-To-Completion”. In “Shared Queue” design, each switch is con- nected to single I/O thread which reads the messages from the switches and then send to a shared queue. The pipeline threads take the message from the shared queue in order to process by corresponding applications. In the “Run-To-Completion” design, on the other hand, there is no pipeline threads and each message is processed by I/O threads.

[85,86] propose source routing based routing schema in SDN. They aim to reduce the number of events processed by the controller because each flow installation in hops across the path will create an event and make the controller busy. The routing schema in [85] and this chapter’s are similar with respect to considering QoS for requests. However, the proposed setting is hierarchic and considers inter-AS traffic as well albeit they consider the traffic in a single domain.