An SDN controller is a software controller defined as a network hypervisor to isolate the tenants network traffic. The benefits of SDN controllers [60] are:
• Less switch memory utilization during the forwarding process.
• Tenantnetwork isolation.
• VM and VN configuration and management throughout the network hypervisor in OpenStack. • Expansion and configuration of new network functions become easier.
Bozakov and Papdimitriou [14] introduced an advanced terminology of SDN called SDN virtualization, or vSDN. The idea was to virtualize the SDN platform then lease the slices to the service provider who would then lease VN slices to the end users. SDN isolates the traffic of different VNs, however vSDN isolates the flow space where each vSDN has its own isolated vSDNs [14]. Traditional SDN provides isolation and protection to the data plane between the multi-tenancy VNs. vSDN provides isolation and protection for the data plane in the physical layer as well as the SDN Control plane [84].OVXis a form of vSDN and is implemented in the OpenStack Cloud as a plugin.
As SDN functionality depends on the abstraction of the physical layer and SDN is a standard technology, there should be a way to adapt different vendor proprietary physical hardware embedded in a heterogeneous system. An intermediate layer of communication, an API, is provided by the vendors as an interface[24]. The SDN framework is extended via the use of open source APIs to allow the interaction between the system applications, physical environment, network component and other services [50].
SDN supports two types of network approach; the Traditional SDN and the Hybrid SDN. The Traditional SDN focuses on the network operations control/data plane communication without being concerned about any virtualized networks services. Such structures are flexible but not
scalable, therefore, the best application of such a structure is in a system that requires great elasticity [24].
Hybrid SDN use the same strategies as the Traditional for operating the network by separating the control from the data plane, yet differs from the Traditional SDN which uses a single centralized controller as the network operational control point. The Hybrid SDN uses the data and control plane as well as the network appliances and the devices are managed by their own control plane. Also it functions separately from the central SDN controller. The communication between the network applications and devices and the SDN central controller is via an API. This approach provides not only elasticity, but scalability and accessibility, due to the operation of the network being distributed amongst the individual network device controllers as well as the central controller. If the network lost the connection to the central controller, the functionality is handled by the other controllers using their current configuration until the central controller is revived [24].
However, controllers are independently implemented without necessarily following standard “northbound structure” (API) and hence controllers can not always work together in the same
environment [79].
SDN is designed for wide range, complicated network systems, where policies and flow rules may be reinstalled or reconfigured and this is only possible via the separation of control and data plane. However, routers and switches are only responsible for receiving and forwarding the traffic based on the flow rules installed/defined/configured by the control plane. Hardware such as switches and routers with SDN capability are configured to allow the control plane to send instructions of traffic forwarding and handling decisions to the data plane via the router/switches [61].
With the structure of the SDN central control, network adminstration gains more control on the network for defining the policies and rules of traffic handling as well as flagging the flow with administration defined categorization such as priority, allow or block. All of this is implemented in the central module, which means it saves time on configuring each network device connected to operational infrastructure [61].
Clouds adopted the Hybrid SDN approach. For example, OpenStack uses network applications as networking devices configured to be stand alone components that handle tenant L2 and L3 traffic for the network components configuration. Moreover, vendors implemented their network facilitation to the OpenStack networking system in a form of plugins, which perform port creation and VLAN isolation. OpenStack has its own network control module called Neutron that handles the SDN networking operation and implements the routing engine to facilitate communication
[24]. Neutron is connected to the Compute database to keep network related information, agents and plugins for services and appliances [85].
An example of a network hypervisor module implemented in OpenStack is called DCPortals or DCPortalsNg. This module gets the required information for OpenStack DB such as the tenant ID, VMs info and location, VNs, etc, and uses this information to create flow rules and inserts them into tables in the OVS switches in order to handle the traffic flow. The advantage of using DCPortals is not to be concerned about OpenFlow compatibility in the physical network environment of the cloud [60].