Research‎ > ‎

Software Defined Networking (SDN)

The term Software Defined Networking (SDN) is prevalent in today’s discussion about future communication networks. As with any new term or paradigm, however, no consistent definition regarding this technology has formed. The fragmented view on SDN results in legacy products being passed off by equipment vendors as SDN, academics mixing up the attributes of SDN with
those of network virtualization, and users not fully understanding the benefits. Therefore, establishing SDN as a widely adopted technology beyond laboratories and insular deployments requires a compass to navigate the multitude of ideas and concepts that make up SDN today. The compass for SDN gives guidance to a potential adopter of SDN on whether SDN is in fact the right technology for a specific use case. 

Separation of Control- and Data Plane
The physical separation of control- and forwarding- or data plane is the best-known principle of SDN. It postulates the externalization of the control plane from a network device to an external control plane entity often called the “controller”. In particular, this means that an internal software control plane, while it may still exist, is not enough to brand a device or technology as “Software Defined Networking”. The external controller has to have the ability to change the forwarding behavior of the network element directly. This enables several key benefits of SDN. Control- and data plane can be developed separately from each other, which lowers the entry-to-market hurdle, as a company no longer has to have expert knowledge in both areas. Moreover, the externalization of a software-based controller produces pressure on established hardware switch vendors, which are reduced to providing forwarding hardware only. This has already introduced new and disruptive start-ups to the market that have sped up innovation in the network. Even the market leader Cisco has reacted to this trend by introducing its own flavor of SDN with the Application Centric Infrastructure concept developed at the Spin-In company “Insieme”. Customers are also enabled to “mix-and-match” products of different vendors and thus increase competition further. The switch vendors have reacted to that shift by forming the OpenDaylight project for an open SDN software platform. 
Challenges in this area are to design appropriate control protocols that offer the necessary flexibility and work across domains or cater to the features of a specific technology. Furthermore, the corresponding forwarding elements have to be adapted to support forwarding at line rate when the new protocols are in use.

Logically Centralized Control
The controller of an SDN network is a logically centralized entity, i.e. it can consist of multiple physical or virtual instances, but behaves like a single component. The global network information such a central controller possesses enables it to adapt its network policy with respect to routing and forwarding much better and faster than a system of traditional routers could. 
The realization of a logically centralized controller is challenging with respect to scalability depending on the specific scenario and network or virtual network size. Scalability can be achieved by implementing a centralized controller as a distributed system where the contained information has to be maintained consistently. 

Open Interfaces
For SDN to reach its full potential in terms of flexibility and adaptability, it is fundamental that its interfaces are and remain open. A closed or proprietary interface limits component exchangeability and innovation. This is especially true for the interface between control- and data plane (Southbound Interface). In the absence of a standard open interface, one of the main SDN advantages – the interchangeability of network devices and control planes – would be taken away. This is also true for the remaining interfaces, which are discussed in more detail in Section 2.1.
To maintain open interfaces might be challenging since vendors try to introduce proprietary interfaces or to bypass proprietary information via the open interface. This could generate additional value if entities of the same vendor are used, but also lead to deadlocks and performance bottlenecks in mixed operation. Furthermore, the use of proprietary interfaces negates one of the key advantages of the SDN principle: the flexible combination of forwarding hardware and control software from multiple vendors tailored to a specific usage scenario or setup.
The fundamental paradigm shift in networking, SDN has initiated is represented by programmability. It is enabled by the external software controller and open interfaces. The programmability principle is not limited to introducing new network features to the control plane but rather represents the ability to treat the network as a single programmable entity instead of an accumulation of devices that have to be configured individually. SDN can thus be regarded as a very suitable complement to network virtualization providing the control plane for an easy operation (‘programming’) of, e.g., virtual networks in network substrates or to control specific flows within a virtual network as possible applications. 
Here it is essential to find the appropriate abstraction level, which determines on the one hand the ease-of-use for network programmers, and on the other hand the abstraction overhead and therewith a possible performance degradation.

There is a lack of clear definitions and a lack of methodology for assessing the suitability of SDN concepts for certain use cases. Current discussions direct SDN towards an image of being a universal solution in networking.
As a basis for such a methodology, we (1) defined four main interfaces in an SDN-enabled network control architecture, namely the southbound, eastbound, westbound, and northbound interfaces, and (2) we identified the five main features provided by SDN technologies, namely programmability, protocol independence, dynamic, granularity and elasticity.

Ehe use cases depend on (a) different application areas (Data center, Enterprise, WAN). Furthermore, (b) different interfaces are needed for each use case, i.e., not all interfaces have to be implemented. Accordingly, development guidelines for specific controllers can be derived based on the analysis of the specific use-case in relation to the features and interfaces used. Different use cases are based on different SDN features, i.e., the implementation of the features depends on the specific use-case.
Similarly, a corresponding analysis of a new use case can reveal whether the use case can benefit from SDN technology, i.e., is there at least one feature with “high”. Furthermore, the benefit of SDN for a certain use case increases with the number of important features identified. Additionally, we can observe that there are more advanced use cases which cannot be realized in today’s networks. These use cases can benefit from or are even enabled by SDN features like the presented application awareness use-case.

Despite the operational use-cases discussed above, SDN drives innovation also in other areas. Particularly in research testbeds, for prototyping and for service rollout (Beta Slice), the capabilities of SDN enable innovation within networks. Accordingly, the areas of application are not limited to the discussed use-cases, but are expected to expand beyond the scope of today’s networks.