3 Software Defined Networking Concepts

ion allowing the control of low level behavior in switching devices. Such an approach could turn out to be beneficial, since it would simplify the deployment of new more efficient schemes for low level switch operations [20]. On the other hand, while moving all control operations to a logically centralized controller has the advantage of easier network management, it can also raise scalability issues if physical implementation of the controller is also centralized. Therefore, it might be beneficial to retain some of the logic in the switches. For instance in the case of DevoFlow [21], which is a modification of the OpenFlow model, the packet flows are distinguished into two categories: small (“mice”) flows handled directly by the switches and large (“elephant”) flows requiring the intervention of the controller. Similarly, in the DIFANE [22] controller intermediate switches are used for storing the necessary rules and the controller is relegated to the simple task of partitioning the rules over the switches. Another issue of SDN switches is that the forwarding rules used in the case of SDN are more complex than those of conventional networks, using wildcards for forwarding packets, considering multiple fields of the packet like source and destination addresses, ports, application etc. As a result the switching hardware cannot easily cope with the management of packets and flows. In order for the forwarding operation to be fast ASICs using TCAM are required. Unfortunately, such specialized hardware is expensive and power-consuming and as a result only a limited number of forwarding entries for flow-based forwarding schemes can be supported in each switch, hindering network scalability. A way to cope with this would be to introduce an assisting CPU to the switch or somewhere nearby to perform not only control plane but also data plane functionalities, e.g., let the CPU forward the “mice” flows [23] or to introduce new architectures which would be more expressive and would allow more actions related to packet processing to be performed [24]. The issue of hardware limitations is not only restricted to fixed networks but is extended to the wireless and mobile domains as well. The wireless data plane needs to be redesigned in order to offer more useful abstractions similarly to what happened with the data plane of fixed networks. While the data plane abstractions offered by protocols like OpenFlow support the idea of decoupling the control from the data plane, they cannot be extended to the wireless and mobile field unless the underlying hardware (e.g., switches in backhaul cellular networks and wireless access points) starts providing equally sophisticated and useful abstractions [6]. Regardless of the way that SDN switches are implemented, it should be made clear that in order for the new paradigm to gain popularity, backwards compatibility is a very important factor. While pure SDN switches that completely lack integrated control exist, it is the hybrid approach (i.e. support of SDN along with traditional operation and protocols) that would probably be the most successful at these early steps of SDN [12]. The reason is that while the features of SDN present a compelling solution for many realistic scenarios, the infrastructure in most enterprise networks still follows the conventional approach. Therefore, an intermediate hybrid network form would probably ease the transition to SDN. 3.3.3 SDN Controllers As already mentioned, one of the core ideas of the SDN philosophy is the existence of a network operating system placed between the network infrastructure and the application layer. This network operating system is responsible for coordinating and managing the resources of the whole network and for revealing an abstract unified view of all components to the applications executed on top of it. This idea is analogous to the one followed in a typical computer system, where the operating system lies between the hardware and the user space and is responsible for managing the hardware resources and providing common services for user programs. Similarly, network administrators and developers are now presented with a homogeneous environment easier to program and configure much like a typical computer program developer would. The logically centralized control and the generalized network abstraction it offers makes the SDN model applicable to a wider range of applications and heterogeneous network technologies compared to the conventional networking paradigm. For instance, consider a heterogeneous environment composed of a fixed and a wireless network comprised by a large number of related network devices (routers, switches, wireless access points, middleboxes etc.). In the traditional networking paradigm each network device would require individual low level configuration by the network administrator in order to operate properly. Moreover, since each device targets a different networking technology, it would have its own specific management and configuration requirements, meaning that extra effort would be required by the administrator to make the whole network operate as intended. On the other hand, with the logically centralized control of SDN, the administrator would not have to worry about low level details. Instead, the network management would be performed by defining a proper high level policy, leaving the network operating system responsible for communicating with and configuring the operation of network devices. Having discussed the general concepts behind the SDN controller, the following subsections take a closer look at specific design decisions and implementation choices made at this core component that can prove to be critical for the overall performance and scalability of the network. 3.3.3.1 Centralization of control in SDN As already discussed, the SDN architecture specifies that the network infrastructure is logically controlled by a central entity responsible for management and policy enforcement. However, it should be made clear that logically centralized control does not necessarily also imply physical centralization. There have been various proposals for physically centralized controllers, like for instance NOX [19] and Maestro [25]. A physically centralized control design simplifies the controller implementation. All switches are controlled by the same physical entity, meaning that the network is not subject to consistency related issues, with all the applications seeing the same network state (which comes from the same controller). Despite its advantages, this approach suffers from the same weakness that all centralized systems do, i.e. the controller acts as a single point of failure for the whole network. A way to overcome this is by connecting multiple controllers to a switch, allowing a backup controller to take over in the event of a failure. In this case, all controllers need to have a consistent view of the network, otherwise applications might fail to operate properly. Moreover the centralized approach can raise scalability concerns, since all network devices need to be managed by the same entity. One approach that further generalizes the idea of using multiple controllers over the network is to maintain a logically centralized but physically decentralized control plane. In this case, each controller is responsible for managing only one part of the network, but all controllers communicate and maintain a common network view. Therefore, applications view the controller as a single entity, while in reality control operations are performed by a distributed system. The advantage of this approach, apart from not having a single point of failure anymore, is the increase in performance and scalability, since only a part of the network needs to be managed by each individual controller component. Some well-known controllers that belong to this category are Onix [26] and HyperFlow [27]. One potential downside of decentralized control is once more related to the consistency of the network state among controller components. Since the state of the network is distributed, it is possible that applications served by different controllers might have a different view of the network, which might make them operate improperly. A hybrid solution that tries to encompass both scalability and consistency is to use two layers of controllers like the Kandoo [28] controller does. The bottom layer is composed by a group of controllers which do not have knowledge of the whole network state. These controllers only run control operations which require knowing the state of a single switch (local information only). On the other hand the top layer is a logically centralized controller responsible for performing network-wide operations that require knowledge of the whole network state. The idea is that local operations can be performed faster this way and do not incur any additional load to the high-level central controller, effectively increasing the scalability of the network. Apart from the ideas related to the level of physical centralization of controllers, there have been other proposed solutions related to their logical decentralization. The idea of logical decentralization comes directly from the early era of programmable networks and from the Tempest project. Recall that the Tempest architecture allowed multiple virtual ATM networks to operate on top of the same set of physical switches. Similarly, there have been proposals for SDN proxy controllers like FlowVisor [29] which allow multiple controllers to share the same forwarding plane. The motivation for this idea was to enable the simultaneous deployment of experimental and enterprise networks over the same infrastructure without affecting one another. Before concluding our discussion on the degree of centralization with SDN controllers it is important to examine the concerns which can be raised regarding their performance and applicability over large networking en