Sdn/o Pen F Low
M U H A M M A D FA ROOQ A N D F E I H U
Introduction
Conventional networks use special algorithms implemented on dedi-cated devices (hardware components) for controlling and monitoring the data flow in the network, managing routing paths and algorithms, and determining how different devices are arranged in the network, in other words, finding the network topology. In general, these algo-rithms and set of rules are implemented in dedicated hardware com-ponents, such as Application-Specific Integrated Circuits (ASIC).
ASIC are designed for performing specific operations. Packet for-warding is a simple example of this operation. In a conventional net-work, upon the reception of a packet by a routing device, it uses a set of rules embedded 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 Contents
Introduction 73
OpenFlow Concept 76
Language Abstractions for SDNs 78
Network Query Abstractions 79
Consistent Update Abstractions 79
Languages for SDNs 80
Querying Network State 80
Reconfiguring the Network 81
Virtualization Layer for SDNs 81
Discussion 84 References 85
a 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 manners based on their nature and contents. A problem posed by this is the limitation of the current net-work devices under high netnet-work traffic, which poses severe limita-tions on network performance. Issues, such as the increasing demand for scalability, security, reliability, and network speed, can severely hinder the performance of current network devices because of the ever-increasing network traffic. Current network devices lack the flexibility to deal with different packet types with various contents because of the underlying hardwired implementation of routing rules [1].
A possible solution to this problem is implementing data handling rules as software modules rather than embedding them in hardware.
This enables 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 an approach is defined in software-defined network-ing (SDN). In SDN, data handlnetwork-ing is isolated from the hardware, and its control is implemented in a software module called the controller.
The basic idea behind 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. SDN is a potential solution to the problems faced by a conventional network and is gain-ing more acceptance in applications, such as cloud computgain-ing. It can be used in data centers and for workload-optimized systems [2].
SDN enables network administrators to deal with data in the network in a more efficient and innovative manner. By using SDN, administrators have the ability to control data flow as well as to alter the characteristics of the switching devices (routing devices) in the net-work from a central location, with control application implemented as software module, without the need of dealing with each device indi-vidually. This enables network administrators to change routing tables (routing paths) in network routing devices. This also gives an extra layer of control over the network data because the administrator can assign high/low priority to certain data packets or allow/block certain
75
L anguage and Pro gr aMMing in Sdn /o PenFLow
packets flowing through the network with different levels of control.
As a result, the network traffic can be controlled in an efficient man-ner and, hence, can be used as a mechanism for traffic load manage-ment in networks. A potential application of SDN is in solutions, such as cloud computing, multitenant architecture, etc., because network administrators have more control over the network traffic and can use network resources in a more efficient manner. SDN is less expensive (because of switching of devices used in this approach) and provides more control over network traffic flow as compared with conventional network devices. Several standards are used for the implementation of SDN. One of the most popular and widely accepted standards for SDN implementation is OpenFlow. OpenFlow provides remote con-trol over network routing devices because of its ability to concon-trol the routing tables of the traffic in the network. Figure 4.1 illustrates the major difference between SDNs and conventional networks.
As mentioned before, SDNs are more suitable for efficient routing of data packets through paths that have a fewer number of hops or have more bandwidth available. This increases the traffic efficiency of the network. The major advantages of SDNs are listed below.
Traditional network
Data plane Switch
Control plane
Software-defined network
Programmable switch
Controller machine
Figure 4.1 Difference between traditional networks and SDN.
1. Intelligence and speed: SDNs have the ability to optimize the distribution of the workload and make end devices more intel-ligent. This results in high-speed networks and gives more efficient use of the resources.
2. 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, based on the workload patterns. This enables administrators to have more efficient and instant access to the configuration modifications based on the network status.
3. Multitenancy: The concept of SDN can be expanded across multiple partitions of the networks, such as the data centers and the data clouds; this enables different players of the net-work to interact with each other in a more secure and efficient manner and provides the administrator with better tools for monitoring.
4. Virtual application networks: Virtual application networks can be implemented by network administrators using the Distributed Overlay Virtual Network (DOVE), which helps in the trans-parency, automation, and better mobility of the network loads that have been virtualized.
OpenFlow Concept
There are several protocol standards on the use of SDN in real-life applications. One of the most popular protocol standards is OpenFlow (Figure 4.2) [2]. OpenFlow is a protocol that enables the implemen-tation of the SDN concept in both hardware and software. This approach is used by scientists to make new protocols and test their ability in network performance and analyze it in real network sce-narios. An added feature is that a scientist can use the existing hard-ware to design new protocols and analyze their performance. Now, it is becoming a part of commercially available routing devices (routers) and switches as well.
In conventional routing devices, both the packet forwarding algo-rithms (datapath) and the routing algoalgo-rithms (control path) are implemented by hardware modules on the same device; however, OpenFlow protocols decouple these operations from each other.
7 7
L anguage and Pro gr aMMing in Sdn /o PenFLow
An isolated control algorithm, the controller, is used to control the routing algorithms and is implemented as a separate standard server, whereas the datapath remains as a routing hardware component. The OpenFlow protocol is the main control protocol in the new devices, which are termed as the OpenFlow switch and the OpenFlow con-troller. They use the OpenFlow protocol for communications among different devices and for carrying out operations, such as packet recep-tion, packet transmission, and modifications in the routing tables, etc.
Initially, the datapath of the OpenFlow routing devices has an empty routing table with many fields. This table contains several packet fields that are searched, as well as an action field that contains the code for different actions, such as the destination of different ports (receiving or transmission), 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 be taken care of. The controller is responsible for packet handling decisions, for example, a new entry on how to deal with this and similar packets received in the future, is added into the data flow table [3].
SDN has the capability of programming multiple switches simul-taneously, but still, it is a distributed system, and therefore, it suffers from conventional complexities, such as dropping packets, delaying control packets, etc. Currently used platforms for SDN, such as Nox and Beacon, enable programming, but it is still hard to program them in a low level.
OpenFlow controller
Control path OpenFlow Data path (hardware) OpenFlow protocol (SSL)
Figure 4.2 OpenFlow architecture.
Language Abstractions for SDNs
SDN uses an event-driven paradigm, where the software application reacts when certain events take place (Figure 4.3) [4,5]. It uses a set of rules embedded in the routing device or switches when packets are received; however, there are no rules present in the data flow tables on how to forward them.
One of the problems is the decoupling of the control function into two parts: (1) the controller with the program and (2) the set of rules implemented on the routing devices. This has an implication of mak-ing the programmer worry about the low-level details that also include the switch hardware. The NetCore programmers write the specifica-tion that captures the intended forwarding behavior of the network instead of write programs dealing with the low-level details, such as the events and the forwarding rules of the network. This enables interactions between the controllers and switches. A compiler trans-forms these specifications into code segments for both controllers and switches. A prominent feature of the NetCore allows descriptions of the network rules and policies in terms of the simple specifications, which cannot be implemented or realized directly in the switches.
Another important fact about NetCore is that it has a clear formal set of rules that provide a basis for reasoning about programs [4].
Application layer
Business applications
API API API
Control layer
Network services
Infrastructure layer
Network device Network device Network device Network device Control data plane interface (e.g., OpenFlow) SDNControl
software
Figure 4.3 Programming of the SDN and language abstraction.
79
L anguage and Pro gr aMMing in Sdn /o PenFLow
Network Query Abstractions
In SDNs, each switch stores counters for different forwarding rules.
They are for the counts of the total number of packets and data seg-ments processed using those rules. For traffic monitoring, the con-troller has the ability to check the different counters associated with the different sets of forwarding rules. This allows programmers to monitor the fine details of implementation in the switches. This is a tedious job and makes the program complicated. Therefore, an added level of abstraction will help the programmers. To support appli-cations whose correct operation involves a monitoring component, Frenetic includes an embedded query language that provides effec-tive abstractions for reading network state. This language is similar with structured query language (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 of for-warding policies. A compiler produces the control messages needed to query and tabulate the counters in the switches.
Consistent Update Abstractions
Because SDNs are event-driven networks, some programs in SDNs need to change their policy from one state to another 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 uses just one version of the policy (instead of a combination of both the old and the new policies). This preserves all properties that can be expressed in terms of individual packets and the paths that they take through the network—a class of properties that subsumes important struc-tural 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 [6].
Languages for SDNs
Conventional computer networks are responsible for carrying out sev-eral 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 several different types of devices, such as combination of routers, switches, firewall, repeaters, etc. This heterogeneous nature of different mod-ules present in the networks makes the network management a dif-ficult and complicated task. A simple solution is provided by 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 previously mentioned, OpenFlow is an innovative idea where a standard protocol is used for changing the behavior of devices (programming them) using low-level applica-tion programming interface (API) that mimic the underlying hard-ware components. SDN requires a higher level of abstractions to create applications. An example is the Frenetic project, where the goal is to provide a simple and higher level of abstraction for making applications with three main areas in mind: (1) monitoring of traffic in a network, (2) managing (creation and composition) packet forwarding policies in the network, and (3) ensuring the consistency in updating those poli-cies [5]. By providing these abstractions, the job of the programmer becomes easy and efficient in creating and managing new applications for SDN without a need of worrying about the low-level details.
Querying Network State
The Frenetic project uses a language that supports a high-level query scheme for subscribing to information streams. It gives information about the state of the network, including traffic statistics and topology changes. The run-time system is responsible for managing the poll-ing switch counters, gatherpoll-ing statistics, and reactpoll-ing to the happen-ing of events. In the Frenetic project, the specification of the packet forwarding rules in the network is defined by the use of a high-level
81
L anguage and Pro gr aMMing in Sdn /o PenFLow
policy language that makes it really simple and easy for program-mers. Different modules can be responsible for different operations, such as routing, discovery of the topology of the network, workload balancing, access control, etc. This modular design is used to register each module’s task with the run-time system, which is responsible for the composition, automatic compilation, and optimization of the programmer’s requested tasks.
Reconfiguring the Network
To update the global configuration of the network, the Frenetic proj-ect provides a higher level of abstraction. This allows programmers to configure the network without physically going to each routing device to install or change the packet forwarding rules in each table.
This process is very tedious and is prone to errors. The run-time sys-tem makes sure that, during the updating process, only one set of rules is applied to them: either the old policy or the new policy, but not both of the rules. This makes sure that there are no violations for the important invariants, such as connectivity, control parameters of the loops, and access control, when the OpenFlow switches from one policy to another [3].
The Frenetic language project is an aggregation of simple yet powerful modules that provide an added level of abstraction to the programmer for controlling the routing devices from the central application. This added layer of abstraction runs on the compiler and the run-time system, and is vital for the fast and efficient execution of the code.
Virtualization Layer for SDNs
As mentioned before, the virtualization layer helps in the develop-ment and operation of the SDN slice on the top of shared network infrastructures. A potential solution is the concept of AutoSlice [7].
This provides the manufacturer with the ability to redesign the SDN for different applications while the operator intervention is mini-mized. Simultaneously, the programmers have the ability to build the programmable network pieces that enable the development of differ-ent services based on the SDN working principles.
Network virtualization enables the development of a viable and working solution toward the development and functionality of the small segments of the network slices on the top of a common network infrastructure. SDNs can combine different programmable routing devices such as switching hardware by facilitating the application of the network services, such as centralized control, network-wide avail-ability, and visibility. These features of SDNs enable the network cli-ents to have control over their segmcli-ents of slices, implementation of custom forwarding decisions, security policies, and configuration of access control, as needed.
FlowVisor is considered to be a fundamental building block for SDN virtualization and is used to partition the data flow tables in switches using the OpenFlow protocol by dividing it into flow spaces.
This results in hard switches that can be manipulated concurrently by several software controllers. Nevertheless, the instantiation of an entire virtual SDN (vSDN) topology is nontrivial because it involves numerous operations, such as mapping 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 that is called the SDN hypervisor. It enables the automation of the deployment process and the operation of the vSDN topologies with the minimum interaction of the administrator. vSDN focuses on the scalability aspects of the hypervisor design of the network.
In Ref. [8], an example is presented in which a network infrastruc-ture is assumed to provide vSDN topologies to several tenants. The vSDN of each tenant takes care of several things, such as the band-width of the link, its location, the switching speed (capacity), etc. The assumption in this example is that every tenant uses switches that use OpenFlow protocol standards, with a flow table that is partitioned into several segments. The proposed distributed hypervisor architec-ture has the capability of handling a large amount of data flow tables for several clients.
There are two very important modules in its hypervisor: manage-ment module (MM) and multiple controller proxies (CPX). These modules are designed in such a manner that it distributes the load control over all the tenants. Upon the receipt of a request, MM inquires the vSDN about the resources available in the network
8 3
L anguage and Pro gr aMMing in Sdn /o PenFLow
with every SDN domain and then accordingly assigns a set of logical resources to each CPX. Next, each CPX initializes the allocated seg-ment of the topology by installing flow entries in its domain, which
with every SDN domain and then accordingly assigns a set of logical resources to each CPX. Next, each CPX initializes the allocated seg-ment of the topology by installing flow entries in its domain, which