SDN: network enhancement

In this section we will give an overview of what are the benefits of the SDN approach and what can be achieved by decoupling the control and data plane.

In order to put the focus on the concepts on which an SDN network is built upon rather than on implementation details, we will refer to the schematiza-tion of an SDN network shown in Figure 4.5, in which just one controller has envisaged. We will also consider OpenFlow as the controller-switch protocol.

First of all, this kind of approach offers a centralized management and control on different network devices. One of the most problematic tasks for both a network administrator and a programmer is interaction with different vendors’ switches. In the network of a big company, indeed, it is very un-common to find only one kind of switch so, in a real-world scenario, multiple devices and software are involved. As each switch has different software mod-ules making use of different protocols, management is often complex and re-quires the implementation of different communication mechanisms.This prob-lem can be solved if all the switches in the network impprob-lemented OpenFlow as communication protocol. Switch vendors can differentiate their switches by many features but as long as their device implement the OpenFlow pro-tocol they can be controlled by the controller in an easy and standard way.

In fact, being the controller a single management point, all maintenance and control operations are hugely simplified. Some readers at this point could ex-press their doubt that the OpenFlow controller can represent a single point of failure. It certainly can. Actually, as the controller’s only task is to just occasionally instruct switches, its failure will not be as catastrophic as it may appear. Moreover, in case of a component crash, be it a switch or the controller itself, it will be much easier to find its related fault(s) by just examining the controller logs.

Second, SDN offers an abstraction of the underlying network. This point directly relates to the previous paragraph, where we exposed the general benefits of network customization. All the operations we introduced, like al-tering traffic patterns or offering to users specific QoS levels, are hindered

Software Defined Networks 73

by the number and the complexity of the low level devices, which have to be contacted in order to achieve the expected result. Furthermore, since other technologies could already be in place, it’s very important to interact with them as well. In such a situation, an high-level operation like traffic orchestration, is mixed with low-level operations, like communication with switches. By exploiting the aforementioned NorthBound APIs of an SDN controller the real network is abstracted from the business application. This feature makes programmers’ job easier as well, because they just have to learn one API for all switches no matter of the internal structure of the switches nor of software changes or updates. It is not uncommon for administrators to keep older versions of network devices software, as an update could, in the worst case scenario, disrupt an entire service and affect interactions with other existent apparatus. With SDN and OpenFlow, software updates have a very limited impact: vendors will have to simply make sure that a new switch update does not alter the OpenFlow protocol part, whereas network administrators will keep on dialoging with the switches. Figure 4.7 shows a practical example of what we are talking about. We can note how dif-ferent kinds of business applications, cloud-based or not, interact with the underlying network just by contacting the NorthBound API. Also note how the OpenFlow network can coexist, setting a very simple configuration, with other generic virtual network software components.

The last important benefit we have to talk about is related to the pre-vious section as well, and it is about the agility and scalability that SDN brings to the network. Let us start by pointing out that the assertion that the actual Internet is static is clearly in contrast with the dynamic nature of modern server applications and services. Nowadays, most servers are virtu-alized and almost all applications running on such VMs interact with each other using various communication protocols, so they need to be properly configured. We illustrate virtualization in-depth in 2.2, as its understanding is required to fully comprehend our application. However, what we want to make clear here is that while in the past a server application typically

ex-Figure 4.7: Overview of SDN’s provided abstraction

changed data just with clients, applications have now to work toether and communicate with each other in order to provide the final service. In ad-dition, being each server virtual, this can be migrated from a location to another. Motivations behind migration can be multiple, but this is mainly done with the purpose of optimize and rebalance servers workload. Neverthe-less, this operation, which includes simpler cases as boot up/shut down, has to be done trying to avoid long period of service downtime. Finally, given their constant interaction and increase in number, we have to admit that a static configuration of the network could not be enough anymore to as-sure fast data exchanging among modern and complex applications. Just to give an example, Google computing nodes, in order to maintain consistency among the Internet and their internal databases (representing the source for user searches), have to periodically exchange data on the order of petabytes.

To allow this mass of data to flow, an hyper scalable network infrastructure is needed. In fact this type of network cannot be statically configured, as a single change would involve a not negligible downtime to reconfigure. With SDN, again, a controller can act as a single management point and imple-ment ad-hoc algorithms to dynamically alter the network. As the controller can see the state of all the network switches, it is aware of their changes and so, properly configuring them, can manage any network change in a

consis-OpenFlow 75

tent way. For example, switches can be instructed to change destination of a traffic flow in case the recipient changed its location or was shut down, thus solving the migration problem.