The History Of Software Defined Networking

Published Date: 02 Nov 2017

Conventional Networks utilize special algorithms implemented on dedicated devices (hardware components) for controlling and monitoring the data flow in the network, managing routing paths and algorithms and for determination of how different devices are arranged in the network i.e. finding the network topology. In general these algorithms and set of rules are implement in dedicated hardware components such as Application Specific Integrated Circuits (ASIC). ASIC are designed for speed and performing specific operations Packet forwarding is a simple example of this operation. In conventional network, upon the reception of a packet by a routing device, it uses a set of rules imbedded in its firmware to find the destination device as well as the routing path for that packet. Generally data packets that are supposed to be delivered to the same destination are handled in similar manner and are routed through the same path irrespective of the data types of different packets. This operation takes place in inexpensive routing devices. More expensive routing devices can treat different packet types in different manner based on their nature and contents. A problem posed by this is the limitation of the current network devices to high network traffic and will pose severe limitations on the network performance. Issues such as the increasing demand for scalability, security, reliability and network speed can severely hinder the performance of the current network devices due to the ever increasing network traffic. Current network devices lacks the flexibility to deal with different packet types differently based on their contents because of the underlying hardwired implementation of routing rules.

As mentioned before conventional networks suffer from the inflexibility to deal with different data types differently because of the routing rules embedded in hardware. a possible solution to this problem is the implementation of the data handling rules as software modules rather than embedding them in hardware. This enables the network administrators to have more control over the network traffic and therefore has a great potential to greatly improve the performance of the network in terms of efficient use of resources and speed. Such approach is defined as Software Defined Networking (SDN). In SDN, data handling is isolated from hardware and the its control is implemented in block of software called the controller. Basic idea behind the SDN is to separate the control of data handling in the networking stack from the hardware and implement it in the software. This results in improved network performance in terms of network management, control and data handling. SND is a potential solution to the problems faced by conventional network and is gaining more acceptance in applications such as cloud computing, their use in data centers for Big Data and for workload optimized systems.

Software Defined Networking enables the network administrators to deal with the data in the network in a more efficient and innovative manner. By using SDN network administrators have the ability to control the data flow as well as to alter the characteristics of the switching devices (routing devices) in the network from a central location with control application implemented as software module without the need of dealing with each device individually. This gives the network administrators the ability to change routing tables (routing paths) in network routing devices. This gives an extra layer of control over the network data as the administrator can assign high/low priority to certain data packets or allow/block certain packets flowing through the network with different levels of control. As a result the network traffic can be controlled in an efficient manner and hence can be used as a mechanism for traffic load management in networks. A potential application of SDN is in solutions such as cloud computing, multi-tenant architecture since the network administrators have more control over network traffic and can utilize network resources in a more efficient manner. SDN can provide inexpensive solutions as this approach is less expensive (switching devices used in this approach) and provides more control over network traffic flow as compared to the conventional network devices. Several standards are used for implementation of SDN, one of the most popular and widely accepted standards for SDN implementation is called Open-FLow. Open-Flow provides remote control over the network routing devices in form of the ability to control the routing tables of the traffic in the network.

As mentioned before, SDNs are more suitable for efficient routing of the data packets through paths which have less number of hops or have more bandwidth available. This increases the traffic efficiency of the network. Major advantages of SDNs are listed below.

Intelligence and Speed: SDNs have the ability to optimize the distribution of the workload and makes end devices more intelligent. This results in high speed networks and gives more efficient use of the resources.

Patterns in the networks: In SDNs the administrators have remote control over the network and can change the network characteristics such as services and connectivity base on the workload patterns. This enables to administrators to have more efficient and instant access to the configuration modifications based on the network status.

Multi-tenancy: The concept of the SDN can be expanded across multiple partitions of the networks such as the data centers and data clouds, this enables different players of the network to interact with each other in a more secure and efficient manner and provides to administrator with better tools for monitoring.

Virtual Application Networks: Virtual Application Networks can be implemented by the network administrators by using the Distributed Overlay Virtual Network (DOVE) with current network services which helps in transparency, automation and better mobility of the network loads that have been virtualized.

Open Flow:

A number of protocol standards exists to implement SDN in real life application. One of the most popular protocol standards is called Open Flow. Open Flow is a protocol that enables the implementation of the SDN concept in both hardware and software. This approach is used by the scientists to make new protocols and test their ability in network performance and analyze it in real network scenarios. An added feature is that scientist can utilize the existing hardware to design new protocols and analyze their performance. Now it's becoming the part of commercially available routing devices (routers) and switches as well.

In conventional routing devices, the packet forwarding algorithms (data path) and the routing algorithms (control path) both are implemented using hardware modules on the same device whereas Open Flow protocols decouples these operations from each other. An isolated control algorithm called controller is used to control the routing algorithms and is implemented as a separate standard server whereas the data path remains the part of the routing hardware component. Open Flow protocol is the main control protocol in the new devices which are termed as Open flow switch and Open flow Controller and they use the Open flow protocol for communication between different devices and to carry out operations such as packet reception, packet transmission and modifications in the routing tables etc.

Initially the data path of the Open flow routing devices has an empty routing table with many fields. This table contains several packet fields which are searched and an action field which contains the code for different actions (such as destination of different ports (receive or transmit), packet forwarding or reception etc). This table is populated based on the new data packets. When a new packet is received which has no matching entry in the data flow table, it is forwarded to the controller to take care of it. Controller is responsible for decision regarding this packet, it is either dropped or adds a new entry into the data flow table on how to deal with this and similar packets received in future.

Figure Open flow architecture

SDN has the capability to program multiple switches simultaneously but still it is a distributed system and therefore it suffers from conventional complexities such as dropping packets, delaying of the control packets etc. Currently used platforms for SDN such as NOX and Beacon enables this programming but not much therefore it is really hard to program in a low-level distributed programming.

http://twimgs.com/networkcomputing/2012/5/difference_large.jpg

Figure Difference between the OpenFlow and SDN [source: http://twimgs.com/networkcomputing/2012/5/difference_large.jpg]

Language Abstractions for Software-Defined Networks:

SDN is uses an event driven paradigm where the software application reacts when certain events takes place by using set of rules embedded in the routing device or switches ( when packets are received but there are no rules present in the data flow data on how to forward them or the changes in the network architecture or changes in the network topology).

One of the problems is decoupling of the control into two parts i.e. the controller with the program and the set of rules implemented on the routing devices. Another reason is that this has an implication of making the programmer worry about the low level details which also includes switch hardware. The NetCore programmers write specification that captures the intending forwarding behavior of the network instead of writing programs dealing with the low level details such as the events and the forwarding rules of the network. This enables interaction between the controllers and switches. A compiler transforms these specifications into codes segments for both controller and switches. A prominent feature of the NetCore allows description of the network rules and policies in terms of the simple specifications which can’t be implemented or realized directly on the switches. Another important fact about NetCore is that it has a clear formal set of rules that provides a basis for reasoning about programs.

Network Query Abstractions:

In SDNs each switch stores counters for different forwarding rules and the count of the total number packets and data segments processed using those rules. For traffic monitoring the controller has the ability to check different counters associated with different sets of forwarding rules. This makes the programmers worry about the fine details of implementation on the switches. This is a tedious job and makes the program complicated. Therefore an added level of abstraction will help the programmers. To support applications whose correct operation involves a monitoring component, Frenetic includes an embedded query language that provides effective abstractions for reading network state. This language is similar to SQL and includes segments for selecting, filtering, splitting, merging and aggregating the streams of packets flowing through the network. Another special feature of this language is that it enables the queries to be composed with each other and with forwarding policies. Compliers and the real time systems make it possible. Compiler produces the control messages and needed to query and tabulate the counters on switches.

Figure Programming of the SDN and language Abstraction

Consistent Update Abstractions:

Since SDNs are event driven networks therefore some programs in SDNs need to change their policy from one state to another such as because of the changes in the network topology, failures in the network etc. An ideal solution is the automatic update of all the network switches but practically it is not possible to implement. A possible solution is to allow some level of abstraction and then propagate these changes from one device to another. An example is the per-packet consistency which ensures that each packet going through the network just uses one version of the policy and not a combination of both the old and new policy. This preserves all properties that can be expressed in terms of individual packets and the paths they take through the network—a class of properties that subsumes important structural invariants such as basic connectivity and loop-freedom, as well as access control policies. Going a step further, per-flow consistency ensures that sets of related packets are processed with the same policy. Frenetic provides an ideal platform for exploring such abstractions, as the compiler and run-time system can be used to perform the tedious bookkeeping related to implementing network updates.

Languages for Software-Defined Networks

Conventional computer networks are responsible for carrying out a number of operations such as monitoring of network traffic, routing of data in the network, access control in the network and server workload balancing. Apart from this computer networks are made up of a number of different types of devices such as combination of routers, switches, firewall, repeaters etc. This heterogeneous nature of different modules present in the networks makes the network management a difficult and complicated. A simple solution is provided by the concept of SDN by achieving the task of network resource management using a simple and neat interface among several different devices and the software module used to control them. As mentioned before Open-Flow is an innovative idea where a standard protocol is utilized for changing the behavior of devices (programming them) using low level API's that mimics the underlying hardware components. SDN requires a higher level of abstractions to create applications that can be used for it. An example is the Frentic project where the goal is to provide simple and higher level of abstraction for making applications with three main areas in mind i.e.

(i) Monitoring of traffic in a Network

(ii) Managing (creating and composition) packet forwarding policies in the network

(iii) Ensuring the Consistency in updating those policies

By providing these abstractions the job of the programming becomes really easy and efficient in creating and managing new applications for SDN without a need to worry about the low level details.

To achieve this higher level of abstraction the Frenetic project was divided into different parts and three main components are described below: Three main important parts of the Frenetic project are given below:

Querying network state: Frenetic project utilizes a language that supports a high level query scheme for subscribing to an information streams which given info about the state of the network, including traffic statistics and topology changes. The run time system is responsible for managing the polling switch counters, gathering statistics and reacting to the happening of events. Expressing policies: In the Frenetic project the specification of the packet forwarding rules in the network is defined by the use of a high level policy language which makes it really simple and easy for programmers. Different modules can be responsible for different operations such as the routing, discovery of the topology of the network, workload balancing and access control etc. This modular design is used to register each module's task with the run time system which is responsible for composing, automatic compilation and optimization of the programmer's requested tasks.

Reconfiguring the network: For updating the global configuration of the network, Frenetic project provides a higher level of abstraction. This provides the programmers to be able to configure the network without to go physically to each routing device to install or change packet forwarding rules in each table. This process is very tedious and is a prone to errors. The run-time system makes sure that during the updating process only one set of rules is applied to them, i.e. either the old policy or the new policy and not both of the rules. This makes sure that there is no violations for the important invariants such as connectivity, control parameters of the loops and the access control when the Open-Flow switch from one policy to the other policy.

Frenetic language project is a aggregation of very simple yet powerful modules that provide an added level of abstraction to the programmer for controlling the routing devices from central application. This added layer of abstraction runs on the compiler and run time system and is vital for the fast and efficient execution of the code.

Auto-Slice: Automated and Scalable Slicing for Software-Defined Networks

As mentioned before the virtualization layer helps in the development and operation of the SDN slice on the top of shared network infrastructures. A potential solution is the concept of Auto-Slice. This provides the manufacturer with the ability to redesign the SDN for different applications while the operator intervention is minimized. Simultaneously the programmers have the ability to have the programmable network pieces which enables the development of different services based on the SND working principles.

Network virtualization enables the development of a viable and working solution towards the developing and functionality of the small segments of the network slices on the top of common network infrastructure. SDNs can combine different programmable routing devices such as switching hardware etc by facilitating the application of the network services such as centralized control, network wide availability and visibility and Open-Flow. These features of SDNs enables the network clients to have control over their segments of slices, implementation of custom forwarding decisions, security policies and configuring access control as needed.

Flow Visor is considered to be a fundamental building block for SDN virtualization and is used to partition the data flow tables in switches using the Open-Flow protocol by dividing it into the so called flow spaces. This results in hard switches that can be manipulated concurrently by several software controllers. Nevertheless, the instantiation of an entire vSDN topology is non-trivial, as it involves numerous operations, such as mapping virtual SDN (vSDN) topologies, installing auxiliary flow entries for tunneling and enforcing flow table isolation. Such operations need a lot of management recourses and planning of the network infrastructures. The goal is to develop a virtualization layer which is transparent or called SDN hypervisor, this enables the automation of the deployment process and the operation of the vSDN topologies with the minimum interaction of the administrator. vSDNs focuses on the scalability aspects of the hypervisor design of the network.

An example is presented in which a case of network infrastructure is assumed to provide vSDN topologies to several tenants. The vSDN of each tenant takes care of a number of things such a set of nodes and links with network characteristics and requirement such as the bandwidth of the link, its location and the switching speed (capacity) etc. The assumption in this example is that every tenant uses Switches that uses Open-Flow protocol standards that uses a flow tables which is partitioned into a number of segments. The propose distributed hypervisor architecture has the capability of handling a big quantity of data flow tables for several clients. There are two very important modules of hypervisor:

(i) Management Module (MM)

(ii) Multiple Controller Proxies (CPX)

These modules are designed in such a manner that it distributes the load control over all the tenants.

Upon the reception of a request MM inquires the vSDN about the resources available in the network with every SDN domain and then accordingly assign a set of logical resources to each CPX. As a next step each CPX initialize the allocated segment of the topology by installing flow entries in its domain, which unambiguously bind traffic to a specific logical context using tagging. As the clients are required to be isolated from each others, therefore every CPX is responsible to do a policy control on the data flow table access and make sure that all the entries in these tables are mapped into segments that are not overlapping. CPX is responsible for controlling the routing switches. Also the CPX takes care of all the data communication between all the clients controller and the forwarding plane. A new entry into the switch has to follow certain steps. First the proxy creates a control message for addition of new entry into the switch flow table in such a manner that all references (addresses) to memories are replaced by the corresponding physical entries and corresponding traffic controlling actions are added into the packet. Proxy is responsible for maintaining for storing the status of each virtual node in a given SDN. As a result the CPX has the ability to independently transfer virtual resources within its domain in order to optimize intera-domain resource allocation. The MM portion is to optimize global parameters. The transport control message translation is used to enable the tenants to have access the packet processing set of rules within a specific SDN layer without have to disturb the simultaneous users.

FORWADING PLANE

If you have a number of clients in a network we need a large number of flow tables to arrange them in the memory of a routing switch. The job of CPX is to make sure that all the flow tables are virtually isolated and make sure that all packet processing takes place in a correct order and timely and all the actions are carried out in case a connected group of virtual nodes is being mapped to the same routing device. In the Open-FLow routing devices, the main reason for the limitations on the scalability of the platform is the flow table size. This is caused because there are there are a large number of entries in the flow table. To deal with such situation, an auxiliary software data paths (ASD) is used in the substrate network. For every SDN domain an ASD is assigned that has a software routing switch which is running on a separate server. The server has enough memory to store all the logical flow tables which are needed by the corresponding ASD compared to the limited space on the Open-Flow routing devices. Although the software based data path (as in the SDN) architecture and commodity have achieved recent advantages, still there is a huge gap between the software defined Open-Flow protocol and the actual hardware components. Hardware implemented modules have higher capacity.

To overcome these limitations the Zipf property of the aggregate traffic i.e. small fraction of flows is responsible for the traffic flowing through the network. In this technique ASDs are used for handling volume data traffic while only a very small number of high volume traffic volume caching in the dedicated routing devices.

Quantitatively Evaluating (and Optimizing) Software-Defined Networks

There are still questions on how to make the SDN more efficient and optimize them across all the network sets and how to define determine tradeoffs between different implementations and get a better one.

There is a need to have quantitative approach for evaluating the performance and efficiency of the SDNs. Controllers are responsible in SDN's for managing the packet forwarding tasks. There are a number of practical applications of SDNs and there are a number of commercial applications/products based on SDN. . There is still the question of how to quantify the performance of the network and how to contify their performance and what are the best tradeoffs in the networks.

Some of the important parameters while considering the performance of the SDN are the scalability, availability and latency. These issues are vital and must be addressed before choosing SDN for any application. A shift from the conventional networks doesn't require to think about the cost, performance and reliability of the new architecture. Answers to some of these questions are unknown and there is a need to find out these answers so that to motivate the network operators to migrate from conventional networks to the SDN.

Why this is hard to find which SDN’s is good one

The situation about the choice is made much more complicated due to a number of factors. A few of them are listed below.

Topologies vary: In different networks there are different number of parameters such as number of edges, number of nodes, distance between the nodes and connectivity of the nodes etc. Therefore its a very interesting research area to find out how to generate reliable network topologies.

Finding relevant metrics: It is a very interesting question to decide how to evaluate the performance of the SDN. Which metrics or factors are most important in evaluation of the performance of the SDN e.g. is having a low average cost among a large number of sets is less important than having a specific delay among them? Such questions need to be answered

Combining metrics: A good solution is to combine a number of factors (parameters) and use them for evaluation. But the question remains the same how to combine different criterion or to come up with a good enough solution.

Computational complexity: Another great problem is the optimization of each factor in consideration. In itself this poses an NP-hard problem for each metric. Some of these factors/metrics include but not limited to the availability of resources, how fair the distribution of resources is, latency and controlling the congestion in different channels.

Design space size: There are a number of options to implement the scalability and fault tolerance across a multiple nodes in the network. Some of these parameters are the number of controllers, where to place these controllers, number of state replicas, how to distribute the processing method and how many switches are to be connected to each controller in the SDN.

Most of these factors can be addressed in a different manners and they can addressed by repeating analysis on a large number of different topologies to find out the embedded trends. Others of these factors can be addressed by the use of some approximation algorithms and the rest could be addressed through simplified models of distributed systems communication.

REFRENCES:

[1] Heller, Brandon. "Quantitatively Evaluating (and Optimizing) Software-Defined Networks."

[2] Martin Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, Natasha Gude, Nick McKeown, and Scott Shenker. Rethinking enterprise network control. IEEE/ACM Transactions on Networking, 17(4), August 2009.

[3] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: Enabling innovation in campus networks. SIGCOMM CCR, 38(2):69–74, 2008.

[4] Monsanto, Christopher, and Alec Story. "Language Abstractions for Software-Defined Networks."

[5] Foster, N.; Guha, A.; Reitblatt, M.; Story, A.; Freedman, M.J.; Katta, N.P.; Monsanto, C.; Reich, J.; Rexford, J.; Schlesinger, C.; Walker, D.; Harrison, R., "Languages for software-defined networks," Communications Magazine, IEEE , vol.51, no.2, pp.128,134, February 2013 doi: 10.1109/MCOM.2013.6461197

[6] Bozakov, Zdravko and Papadimitriou, Panagiotis. "AutoSlice: Automated and Scalable Slicing for Software-Defined Networks ." ACM CoNEXT Student 2012 Proceedings (2012):

[7] G. Scharath, et al., Network Virtualization Architecture: Proposal and Initial Prototype, Proc. ACM SIGCOMM VISA 2009.

[8] N. Sarrar, et al., Leveraging's Zipf's Law for Traffic Offloading, ACM SIGCOMM CCR, 2012.