The fifth part of this series on integration of network function virtualization with the DevOps pipeline discusses the integration of network functions such as routing, switching, and forwarding in a software defined network (SDN).
We can no longer fulfill the network requirements of complex applications using traditional proprietary networking hardware. Hardware solutions cannot simply stand toe-to-toe with the growing demands of applications and their functionalities. Operators today require solutions that are scalable, flexible, and can fulfill the challenges of mammoth network traffic. If only this could be resolved via virtualization of the various network functions. Well, that’s what we’ll discuss here, including how software defined networking can push for networking models with basic devices underneath it, which are easily scalable and not too costly.
Traditional networks have always been about hardware such as switches, routers, and firewalls that route the network traffic or restrict them. Various network operations such as control, monitoring, and management have dedicated hardware devices connected to serve the traditional network. But this traditional network has fallen short due to the growing network size and demands of computing (such as data centres) as well as the network needs of large scale software applications. Setting up switches and routers has become too complicated and error-prone. Implementing and configuring network policies on such a cluttered network with so many static devices has become burdensome and complex.
Traditional network devices have always been criticised for vertical integration. Because of this, the network complexity, management, and operation cost increase whenever new services, technologies, or hardware are adapted to be deployed in the network. In vertical integration, the control plane and the data plane are packed inside these network devices.
The control plane is designated to fill the routing table based on the topology discovery. The routing table decides where to send the incoming data packets. The function of the control plane is to provide the routing and signal protocols to be used. The data plane or forwarding plane, on the other hand, forwards the data packets once the control plane has decided what to do with the given packet. In Figure 1, we can see how the control plane and data plane work while being vertically integrated into the traditional networking device switch.
To cater to all these shortcomings of traditional networking, software defined networking (SDN) intelligently decouples the control plane and the data plane. SDN promises a new networking environment that knows no limits and bounds, where network management is easy and enables network configuration programmatically. With SDN, we are smartly converting our static architecture of traditional networks to a more dynamic architecture. When we disassociate the control plane and data plane, we are making an intelligent unit of networking, i.e., control plane centralised in the software-based controller, which further pushes rules to the simple packet forwarding devices, i.e., data plane. SDN uses a centralised model for the control plane.
Architecture
Figure 2 depicts the SDN architecture. We can see it has been divided into three layers — the application layer, the control layer, and the infrastructure layer (the data layer). The application layer and control layer communicate with each other via northbound interface APIs, whereas the control layer and data layer do so via southbound interface APIs.
The southbound interface enables this via the usage of the OpenFlow protocol. The interface provides:
Programmatic control of all forwarding operations
- Capabilities to advertise
- Statistics reporting
- Event notifications
Northbound interface APIs enable communication between SDN-enabled applications and the control layer. This interface provides an abstract view of the network, which projects the latter’s requirements and behaviour. An open and standard northbound interface facilitates portability and interoperability between the controller and applications.
Controllers
With the advent of SDN, many controllers came to light to dictate the forwarding rules of routing procedures. SDN sits at the control layer and plays an integral part in dictating rules and policies for the data flowing between the application layer and the data layer. Network devices in the SDN network have no intelligence of their own. To balance that, we need a central intelligence to perform the integral network operations and that’s where the SDN controller comes into the picture. It is the central brain of the network, which has an abstract view of the topologies around and, accordingly, makes decisions for every data packet. It translates the requirements of SDN applications straight from the application layer to the data layer.
There are different types of SDN controllers, and we can choose from them based on their features. Table 1 showcases some of the features of different controllers.
Controller name | NOX | POX | RYU | Floodlight | OpenDayLight |
Language | C++ | Python | Python | Java | Java |
Performance | High | Low | Low | High | High |
Distributed | No | No | Yes | Yes | Yes |
OpenFlow support version | 1 | 1 | 1.0-1.4 | 1 | 1.3 |
Cloud support | No | No | Yes | Yes | Yes |
Learning | Medium | Easy | Medium | Hard | Hard |
Open vSwitch
Open vSwitch (OVS) was introduced to overcome the networking challenges of virtual machines. The primary purpose of OVS is to decouple virtual networks from their underlying physical networks. OVS is a software implementation of a multilayer virtual switch. It provides a general switching stack for virtualised hardware environments, and supports multiple protocols and networking standards while enabling network automation via its programmatic extensions. Some of its features are:
- Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN, RSPAN, and GRE-tunnelled mirrors
- Multi-cast snooping
- Fine-grained QoS control
- OpenFlow protocol support (including many extensions for virtualization)
- IPv6 support
- Multiple tunnelling protocols (GRE, VXLAN, STT, and Geneve, with IP security support)
- Multi-table forwarding pipeline with flow-caching engine
Mininet
Mininet is an emulator that can be used to create a network of hosts with links and switches. With Mininet, one can create virtual networks while experimenting with software defined networking systems. It enables rapid prototyping of SDN using OpenFlow. Some of the features of Mininet are:
- Command-line interface which instantiates networks
- Python API to create custom topologies
- Inbuilt diagnostic tools such as ping and iperf
- Setting performance parameters like bandwidth, delay, and many more in the network setup
With SDN we can create multiple virtual networks on a common infrastructure, but what if we could virtualize the various network functions? These network functions would be abstracted from their physical location just like server virtualization beneath a hypervisor, where the network could grow without any addition to the devices. We have seen many services like firewalls, content delivery networks, routers, and load balancers run on proprietary hardware, but now they have been released in the form of a virtualized solution. This is being done by the using of network function virtualization, and it has been reshaping the telecommunications industry.