Software Defined Network
Table of Contents
Software Defined Network……………………………………..
2. History of SDN…………………………………………..
3. SDN and traditional network………………………………..
4. Idea of Software Defined Network……………………………
4.1. Control Plane………………………………………..
4.2. Data plane…………………………………………..
4.3. Load Balancing………………………………………
5. sdn components…………………………………………
5.1. SDN controller……………………………………….
5.2. Southbound APIs……………………………………..
5.3. Northbound APIs……………………………………..
6. Quality of service in Sdn…………………………………..
6.1. Integrated Services (IntServ)……………………………
6.2. Differentiated Services (DiffServ)………………………..
7. SDN use Cases…………………………………………..
7.1. Cloud Datacenter……………………………………..
7.2. Unified Communications in Enterprises…………………..
8.1. Network Virtualization…………………………………
8.2. Network Function Virtualization
8.2.1. NFV Framework……………………………………
8.3. NFV VS SDN…………………………………………
9.1. SDN Firewalls………………………………………..
9.2. SDN improves three types of Firewall…………………….
10.1. Open-Flow Architecture
10.2. OpenFlow switch……………………………………
10.2.1. OpenFlow enabled switch…………………………….
10.2.2. Flow tables……………………………………….
10.3. OpenFlow Protocol………………………………….
10.4. OpenFlow Controller
10.4.1. Centralized Control and Distributed Control Configuration
10.4.2. Reactive and Proactive Modes………………………..
10.5. OpenFlow Channel
11. Floodlight controller
11.1. Floodlight architecture
13. List of references……………………………………….
Nowadays all the world uses internet in most devices and applications that need internet for working and billions of users in the world are using and accessing the network for several purpose. Also, most of these applications, devices and customers need high speed and performance for communicating with each other. In addition, there are routers, bridges, switches, access points and servers that connected and worked with each other for serving all clients and let them communicating together therefore, they require high speed and performance for any devices in the network.
In other hand, one of the router functions is making decision for forwarding in-coming packets to the exact destination router and this forward based on the routing table and some algorithm for each router that packets will pass through it. In addition, the routing table is stored in memories inside the router. Moreover, this router mechanism operates when each router receives a packet, first it must check its routing table to look for the best path for forwarding the packet to the destination. However, routing tables contain IP addresses for the other routers and router learned from routing protocols such as (OSPF, RIP2 and RIP etc.). Therefore, the scientists think for new idea and more benefits for networks which make this operation very fast and solve problem, and that is Software Defined Network (SDN).
In fact, Networks have become a crucial factor in communications growth and this need to improve the network transportation of data in a fast and massive which have been required elements for whose infrastructure is a suitable sufficiently for efficiently data management. In these days, there is more possibility for implementing software tools which is fit in network functionality systems. In addition, it will be more interesting and optimally for controlling data flow in management resource. Therefore, Software Defined Networks improves and simplifies data transportation at this time in the network .
Actually, Software defined network (SDN) is an approach for networking which enables applications to converse or talk with and manipulate the control software of resources and network devices. Also, SDN enables the enterprise for high bandwidth in addressing and the network needs will be able for ever-changing business in the organizations. Moreover, SDN gives and allows us to make improvements in the designed way, how it will be built and managed, and scaled within the data center or other branches for the networks. Software Defined Network can regulate traffics flow dynamically which it can meet service level agreement (SLAs). In addition, Software Defined Network applies Quality of Service (QoS) policies in data flow which can dictate how network traffic is handled and prioritized. SDN requires a high level of control and assurance for fault condition .
However, most of modern applications need to react and manipulate resources provisioned and controlled via network easily. Moreover, applications give benefits for available resources which the resources we knowing will be available in specific ways in the networks. Therefore, most of the modern applications need to interact and manipulate for both physical and virtual storage, compute and resources connectivity. Also, in SDN the application make dynamic links among locations such as enterprise and their branches and those links apply appropriate QoS and bandwidth allocation .
Also, in SDN, network administrators can programmatically initialize, control, manage, and support storage infrastructure of the modern data center and the behavior dynamically of the network by open interfaces and abstraction for low-level functionality. Also, SDN routes can make auto adjust and redesign the network flow based on what OpenFlow is receipting from devices. Moreover, SDN allow administrators replacing protocols for best results in the networks like in control plane. In addition, Software Defined Network gives the ability for the administrator to make changing and adding more configurations tasks on existing network devices when the business growths .
In the past, a Network depended on the traditional way to pass the messages through other devices. Also, inside the router or switch will provide two planes that are control plane and data plane. The control plane is the brain of the router or the switch which it is responsible for configuring the device and programming the paths that used for data flows. Also, when the path has been determined then it will be pushed down to the data plane and typically will store in hardware. After that, data plane makes decision in hardware based on latest information that provided by control plane.
Figure 1 network infrastructure without SDN
The control plane routes from the other routers and builds own global routing, control plane making decisions and checking the source IP and destination IP for the packets and checking any interfaces go out the router then deliver the packet to the data plane. The function of the data plane is only forwarding the packets. So, the network can be slow during forwarding the packets. Moreover, in traditional networks you have to configure each switches and routers manually.
Nowadays, SDN (software defined network) come to solve this problem that is slowness in the network which facing in the network through separating the control plane from the device and put it at a centralized point in the cloud. It transfers controller by network operating system (NOS) that controller information depend on Application programming interface (API) and handles forwarding plane operating, providing, a fixed model of network topology to SDN controller devices.
Figure 2: network infrastructure with SDN infrastructure.
These applications which the controller has full knowledge about the network which optimize and perform management and service of user requirement to deal with it. The mean idea for separating the control plane from the data plane is making the network work faster and easy to manage by the administrator and make the cost less. Also, there is a way for communicating between the layers for the control plane layer and data plane (infrastructure layer) by OpenFlow protocol. In addition, SDN is more flexible when you make changes to the software in the control plane and these changes will be appeared on entire network system.
Software Defined Network comes to solve several problems in network which we have to know these solutions. Also, each router consist of or separate to three elements which is data plane, control plane and management plane. In addition, data plane take packets from one port to others, control plane has the logic which router use for directing the data plane and management plane gives the ability for the administrator to logs remotely or locally to the router such as configuring router .
However, the idea of SDN is splitting control plane from data plane and this make the router faster and also it improve the network performance. As a result, network will still up and work and this is makes router more intelligent from the hardware.
Figure 3 SDN structure Map.
Software Defined Network breaks or separates the data plane from the control plane which gives different understanding for computer network. Also, SDN builds new structures for network that makes network more effective. Moreover, it improves and develops many aspects such as security, manageability and scalability. In addition, SDN replaces how administrator can configure and structure the networks . At the control level, it can control everything that happened in the network and essential function for network is located that using SDN controller which based on software programming. The programming network function can manage SDN controller . In Application level, it requires for controlling the network. Also, it can add SDN controller to simplify the network device and this help administrator’s in changing setting instead of going to the device.
Moreover, it supports resources to be optimized in terms of network security and configuration. Finally, at infrastructure level, it has network devices such as switches and routers .
Control plane is a component for network in SDN which it can carry traffics and it can focus on how individual package will interacts with its neighbors during state exchange. Also, it is responsible for creating and forwarding table entries.
Figure 4 illustrates how control plane working.
Moreover, the control plane has roles for input and output devices which called Routing Information Base (RIB) and Label Information Base (LIB) and these are handled in software and they used for populating Forwarding Information Base (FIB) and LFIB. However, the function of RIB is exchange information among control planes consistently inside the network. In addition, the role for FIB is when packets is sent to the second router then control plane will examine the rule if it match then it will pass through, but if it does not match then it will go back to the port it came from. Also, Routing Information Base makes Forwarding Information Base more stable and also RIB programs FIB.
Therefore, to implement this task, the network topology will be developed by using the control program which will be satisfied in certain constraints. And this network view can be programmed manually or it will be built from portions of information. For example, when control plane receive a packets then it will see the condition of packet has been accepted after that it will send to data plane. Next, control plane will begin performing special operations. After that, the packet will be executed in separately method by data plane. Both control and data planes can operate in the same network topology. However, when control plane receives packets from unknown resource then it will show waring message to RIP protocol which can create and establish a new route and configuration by FIB in data and control plane. Also, it makes decisions for the traffics where have to go or the way for the packets. The tasks for control plane are system configuration, management and exchange of routing table and also packets will be processed by the router for updating the routing table information.
Control plane will send packets and data plane receive them. Actually, control plane make some decision and combination for layer 2 or layer 3. Therefore, control plane does not receive packets from unknown protocols and MAC addresses. In fact, the improvement of internet has been happened, because most of these protocols progressed in terms of functionality and hardware salesmen who have to know how to implement them in highly scalable and available ways. Also, layer 2 focuses on hardware or physical layer addresses in control plane and also it learned MAC addresses through its behaviors, and the mechanisms are used to ensure the cyclic graph and flooding of BUM such as broadcast, unicast and multicast that create their own scalability. But, layer 3 can build for facilitating network layer addresses like what IP protocol has and also, layer 3 forwarding focus on reach ability on the network addresses .
Data plane is considered as workhorse of the switches components in the networks. Also, data plane responsible for parsing packet headers those ASICs has been searched by high speed. Moreover, it has many functions like manage QoS, filtering, encapsulations, Queuing and policing most of the causes which still do in several cases aim and built custom ASIC designs. However, Incoming datagrams will be controlled by data plane where it comes through series of links such as fiber or wireless which can collect datagrams and perform basic sanity checks. In addition, data plane process datagram in FIB table by performing lookups which has been already programmed by control plane. Moreover, data plane has to make these tasks in Fast Path which it will keep the execution needs up in data centers or core networks. But, there is one exception for this operation which is when packets does not match the role like unknown destination is detected then the packets will be sent to the router for processing where if the control plane can moreover operate them using RIB.
Figure 5 shows how data plane executing.
The software path will be exemplified by CPU driven for forwarding of the dedicated elements in modern network. However, in hardware lookups tables will be proven to get a result in much higher packet forwarding performance. Therefore, lookups have dominated network components designs for higher bandwidth network components. As a result, there are varieties of differences in hardware forwarding designs that are distribute across different factors which include budget, space and target requirements. Also, it can guide to various types such as speed, location and size of the memory. Moreover, a number of sequence and operation kind on the packet during process can forwarding in different line rate. In addition, forwarding can move and connect as unit. Also, data plane sends traffics to the next hop through the path that selected for the destination which is based on the control plane decision. In addition, the packets go through the router in data plane and also switches and routers are used what control plane decide to dispose for incoming frames and outgoing frames and packets. In some cases, data plane can return back a local port that causes traffic which designed to process as OSPF or BGP. Data plane in forwarding decision may implement some features like ACL and QoS/policy .
Load Balancing means that an efficient and intelligent overcrowding aware about routing protocol in Software Defined Network. Also, the load balancing can constraint for the network based on SDN environment and this will improve the scalability and availability that can leads to achieve maximum number of packets which has been handled by the controller in minimal time for any application.
Figure 6: show how load balancing work
A load balancer can act as the traffic cop, which is sitting in the front of servers and routers. However, user’s requests pass through all servers for fulfilling these requests in a way that will maximize speed and capacity utilization and should make ensure there is no one server is overworked. Therefore, if there is an overworked server then could degrade the network performance. As a result, when a single server does not work or goes down then the load balancer will forward traffic to online server. Moreover, if a new server has been added to the server group then the load balancer automatically begins to send request to the new server. The load balancer executes these functions which are distributes clients request across multiple servers, make sure it has high availability and reliability by forwarding requests to server that online, and offers the flexibility for adding or subtract servers , .
The SDN controller is Application in SDN which manages control in the flow and depends on protocols like OpenFlow that allow servers to talk with the switches to send the packets. Also, SDN controller is the core of SDN network where located between network devices at one end and applications at the other end. In addition, the controller is responsible for the communications between the devices and applications. The information send is done to switches and routers via southbound APIs, and to the application that include northbound APIs by SDN controller via OpenFlow protocol. Moreover, the controller is using OpenFlow protocol for configuring network devices and selects the best path for application traffic. In reality, SDN controller includes a control plane that is separated from devices and placed in SDN controller to act as a program to run the network faster.
The connection is done between SDN controller, the services, and the application running across the network by Northbound Application Program Interface (APIs). Also, northbound is providing automatic running for the network so that they are aligned with the different applications. On another hand, Northbound Application Program Interface is the very important Application Program Interface in SDN environment because northbound depends on the innovative applications. In addition, Northbound interface includes load balancers, firewalls or other services .
The connection is done between SDN controller, switches, and routers for the network in SDN architecture via Southbound Application Program Interface (APIs). Also, Southbound APIs is providing the efficient control and enable SDN controller to make dynamically changes across the network depend on required needs. In addition, within this component of SDN architecture, there is a protocol responsible for the communication between the controller and the network infrastructure called OpenFlow protocol. Moreover, OpenFlow protocol is most common using in southbound APIs and it is determined the way should be using from SDN controller with forwarding plane to make the modification in the network. Also, by OpenFlow can be adding entries to internal flow table or removed to make the network more responsive to traffic requirements in real time .
Figure 7: illustrates how SDN components work.
A quality of service (QoS) mechanisms is trying to fit the network allocation of resources to the demands for service that running over the network. However, the aim from QoS is to supply every service by the required resources of network that given and maybe limited overall available resources. Unluckily, most of these services have various QoS requirements like error rate, packet loss, latency and redundancy and also it is hard to design a system which treats all requirements. Therefore, there is two frameworks to solve these issue, first IntServ and this is able to provide the network with end-to-end Quality of Service connections per flow, but the scalability of this framework is poor. The Second framework is DiffServ and this is designed for the scalability, but it has low granularity in the flow control. Moreover, when you implement DiffServ then it need high proprietary and also leading to difficult management , .
An IntServ can provide hardware Quality of Service which will guarantee thru resource reservation techniques which means bandwidth and buffer. Also, the technique that IntServ use which is similar to circuit switched networks and also the data transmission will be started after an end-to-end connection has been established. Moreover, the Resource Reservation Protocol (RSVP) is used by the IntServ that can operate with any routing protocol for reserving resources over the calculated path . However, IntServ has a problem which is based on the architectures that they need fundamental changes in a network core .
A DiffServ can provide software Quality of Service that will guarantee through scheduling such as priority queuing. Actually, the IntServ is different than DiffServ which the DiffServ need to modifies in the edge of a network. However, core routers should redirect packets based on their priorities and even edge routers should have packet classification functionality .
In other hand, the mechanism that we will use in QoS is DiffServ DSCP and we will use the common queuing techniques within the Open vSwitch. Also, we will define network wide class of service besides rate limiting paths over a given network of N switches. However, these values of the DSCP are used to state a class for services through a given network segment.
Figure 8: illustrates the QoS module and how it works.
As a result, the Quality of Service will be added to the architecture and it will be responsible about tracking and storing classes of services with the association of DSCP values also will apply policies for taking advantage of a class for service and will apply type of queuing technique on queues related to ports in switch. Furthermore, the module also responsible for tracking the policies on each switch during verifying there are no duplicates. In addition, if there is any topology updates then the module will track them which may skew quality of service inside the network and inform network administrator. Moreover, OpenFlow will present an enqueue mechanism with an assured flow which can be forwarded to the particular queue that will maintain Quality of Service, but it cannot be create queues by using OpenFlow. As a result, QoS has features, like the packet that belong to a flow, it can enqueue in a particular queue for an output port, however the queue could be configured via standard protocols such as NetConf and SNMP. In other hand, those switches in the network can rewrite IP ToS filed in IP header and this help to use and implement QoS mechanisms such as DiffServ , .
Software Defined Network uses cases which can force drive behind the evolution of OpenFlow. However, the number of used cases based on OpenFlow has been grown over years and we cannot list all these cases here. Therefore, we will mention some of those cases and we will select the most influential on the recent evolution of OpenFlow, and also the most complete and the best illustrate of differences scope for issues which SDN framework had to address. In addition, those cases are Cloud datacenter and Unified Communications in Enterprises. Here we will describe their effect on SDN framework elements and the OpenFlow features .
Cloud Datacenter come with a new idea and put new orders and requirements on the primary network. For example, packets and traffics from various residents need to separate both performance and security. Also, the network has many functions like firewall, load balancing and Deep packet inspection which will be inserted on demand and in line with resident’s packets and traffics. However, these functions for the network, they need to be more connected with computing tasks and also network policies have to match also the compute policies. In other hand, todays Software Defined Network comes to solve this issue that will deploy an overlay for this dynamic configuration to static network .
In every server, a software network switch dynamically can route packets from virtual machines (VMs) over network on diverse static tunnels that already established. Moreover, the manager in datacenter has an API which can communicate to the new connectivity requests for the network controller when they are making changes for the compute placement. In addition, network controller can use the API like OpenFlow that help to perform policies and the connectivity requirements in software network switch and vSwitch. As a result, we can enable network controller for tightly manage the hardware switches. Furthermore, vSwitch could avert the need of the controller which can conclude a network behavior.
Actually, most of the functions in core switch are programmed by OpenFlow like forwarding rules and tunnel configuration that using datacenter central database .
Unified Communication in enterprises has interacting media applications such as remote desktop and video conferencing which need Network Quality of Service QoS for ensuring the performance of the application and sometime they are deployed on costly dedicated networks or they suffer from the poor quality on non-dedicated. Actually, those applications need QoS to be preserved over the whole end to end network path based and on global wide network policy which they will make it complex for deploying and configuring. However, SDN comes to help and solve this issue which it can automate QoS configurations of network-wide for Unified Communications and this will be proved by OpenFlow Lync demonstration by Microsoft and HP .
Microsoft Lync is an enterprise communication and messaging product which it has these features, desktop sharing and shared whiteboard that using end-client on PC and central Lync server for managing communication sessions and policies and also it has audio and video conferencing. Also, SDN controller can configure network switches using OpenFlow protocol and also HP Virtual Application Network (VAN) controller does same as SDN. Therefore, Lync server and HP VAN controller can react with each other over SDN northbound API. Moreover, on SDN controller the QoS can monitor network resource usage and apply specific QoS handling for the network flows based on QoS policies. In addition, if a new Lync session has been started then Lync server will directly communicate with the requirements of the session like desired bandwidth and end to end latency for making check with SDN controller when the resources are available .
Moreover, QoS controller can determine the policy that applicable for the connection which is based on the global QoS policies and the attributes will be given by the Lync server. After that, The Quality of Service will program that policy on different switches over path that using OpenFlow protocol.
As a result, when the session has observed the quality is not accepted then the state of the network will be analyzed in specific actions can be taken. Therefore, in Enterprise networks that has independent management and control then it can be amenable to such global Quality of Service control .
Network virtualization is not new technology because the network organizations have a long history in techniques execution like routing and forwarding virtual LANs, virtual LANs (VLANs). Virtualization in networks will allow users to create a network with virtual devices based on their needs and set the type of connection between these devices also, it will allow them to manage the data following so this improve the quality of service. In figure 5 refers in the network virtualization to the ability to provide end-to-end networks for abstracted away from the physical network in a similar way for how to provide virtualization that is abstracted away from any underlying x86 based servers .
Figure 9: Network Virtualization.
NFV was done suggested as a key technology to get benefit from IT virtualization evolution through isolating devices network functions of basic hardware by transferring network functions from customized hardware to general software which working on commercial off-the-shelf (COTS) equipment, like virtual machines. in addition, these programs are running on standard IT platforms such as storage, high-performance switches, and service. Also, through NFV can be deployed in different locations from the networks like network nodes, data centers and end-node of network edge as required. Currently, the market of NFV includes network appliances, switching elements, network services and applications. Moreover, the reduce from using middle boxes that deployed in traditional networks to take the pros of saving cost and achieve flexibility, this is the biggest advantage to using NFV. On the other hand, NFV also supports the co-exists of multi-tenancy from network and service functions, across allowing using one physical platform for different applications, services, and tenants .
ETSI specified NVF architectural framework is enabling virtualized network functions (VNF) to be deployed and executed on network functions virtualization infrastructure which is composed of logically partition them and commodity servers wrapped with the software layer that abstracting them. The VNF usually is set in one virtual machine above the hypervisor layer in the NFVI. The Management and Orchestration (M&O) system is responsible for many operations which are deployment, execution, and operation of VNFs on the NFVI, which are controls is select by a set of metadata describing the characteristics of the network services and their constituent VNFs. Also, the system is responsible around lifecycle the network services is the management and orchestration, the managers responsible for the lifecycle of the VNFs and a virtualized infrastructure manager are managers group VNF, which are considered extended cloud management system responsible for controlling and managing NFVI resources .
Figure 10 Illustration of the NFV framework.
NFV and SDN technologies are closely related and highly complementary to each other. Where, NFV can be used SDN through virtualizing the SDN controller for running on the cloud, so it allows dynamic migration to move the optimal locations by the controller. On another hand, SDN is serving NFV for getting on achieving optimized traffic engineering and steering through providing a connection to a programmable network between VNF. However, NFV and SDN are completely different from the concepts of the system architecture and functions, which are summarized by the following aspects:
- The idea behind NFV is execution the network functions by software’s, whilst achieve centralized control and programmable network architecture by SDN to get better connectivity.
- The goal from NFV is the limit of OpEx, CapEx and power consumption, whilst the goal of providing network abstractions to enable configuration and flexible network control is done by SDN.
- NFV decouples the network functions from the exclusive hardware to get Provide agile and deployment, whilst SDN decouples a network control plane from data plane to get centralized controller through enabling programmability .
Firewall is a software security programs which filter and monitor incoming and outgoing the network traffics based on IP addresses, protocols and ports that come to the network through the outside world, or computer security systems that defend your PC, home or organization from hackers, intruders and malicious code. In addition, a barrier in Firewalls is established between a secure intranet network and another internet. Also, firewalls secure your office from aggressive software which may come to destroy your system. Moreover, firewalls allow administrator to designate that systems and services such as HTTPS, FTP, etc. are publicly available, and also firewalls give ability to users for controlling inbound and outbound access to a specific ports and IPs. However, PCs communicate over several different ports and then the firewall will permit these without alerting the clients .
Nowadays, Software Defined Network firewall can filter not only at the packet level but, it can filter at the flow level. However, the flow may entire to the network and may violate policy and then should be rejected. Also, the changes of flow policy may conflict with firewall policy and to resolve this conflicting then the SDN firewall will be responsible. Both a packet filter and a policy checker will be done by SDN firewall. In addition, violations flow packet is distinguished from flow policy violations in a broader class. However, when a new flow is installed or when policy has been changed then flow policy violations may be occurred. As a result, when the flow policy has been changed then it will be more complicated because, this change may cause a violation of firewall policy then load balancer in OpenFlow that could alter packet header fields which can change flow paths.
Figure 11 illustrates Network with SDN Firewall and without SDN Firewall.
Therefore, when load balancer modify flows and this is imperative for the packet header fields which will be changed by the OpenFlow rules and this will not be result at firewall rule. Furthermore, to prevent this, the SDN firewall has to check the flow policy to make sure there is no conflict with firewall policy .
Table 1: Comparing between Traditional and SDN firewall.
|Parameters||Traditional Network Firewall||SDN Firewall|
|Stateful Inspection||Track the state of traffic present on layers 2 to 4.||Track the state of layer 2 to 7.|
|Integrated IPS and IDS||The IPS or IDS deployment is done with the help of a separate appliance or an appliance that is logically separated with the single appliance.||Intrusion Detection (IDS) and Intrusion Protection System (IPS) are fully integrated.|
|Identity Awareness||Not Supported||Keeps the track of the identity of local traffic device and user.|
There are mainly three types of firewalls stateless, stateful and application firewalls.
Stateless firewalls in memory do not keep any processes for different states of connection. Also, the dynamic network information does not take any consideration like port source negotiation. Therefore, they can be easily broken and are very weak. Finally, they introduced a stateful firewall to solve this issue. However, Stateful firewalls record on their memory most of the different states of previous technology (stateless).
In addition, they use the attributes linked with the connection states in their matching field. In other hand, application firewalls come to advance stateful firewalls which they use application layer for matching their fields to classify traffics and handle application level threats. Furthermore, there is an intense research in the field of SDN stateless firewalls and as a result, most of these solutions will use OpenFlow rules for expressing the firewall security policies , .
In other hand, the unknown packet will be forward it to the controller for processing. After that, the controller distributes packet headers and then it matches their values with the policy rules. However, SDN admin can install firewall policy rules in data plane by using OpenFlow protocol. The controller may interpret these policies to OpenFlow rules and then send them to switch .
This is considered as robust SDN firewall which supports network-wide access control by effectively managing in firewall policy violations with dynamic OpenFlow-based on networks. In addition, the SDN firewall should be more accurate which can discover violations that caused by traffic adjustments. Also, it should flow rule dependencies in both flow tables and firewall policies. Moreover, it should resolve identified violations effectively with respect to different violation situations like partial or entire violations. Furthermore, SDN firewall should be flexible for any inspect in network state and configuration updates such as visualization, optimization, migration and integration of SDN firewalls. Therefore, the SDN firewall needs to be working continuously. Also, generally the network based on the state of an OpenFlow should be evolved and improved rapidly .
Figure 12: show how FlowGuard work and the components that come with FlowGuard.
In violation detection, flow packet should be challenged to deal with flow policy violation because both flow policies and firewall support wildcard rules. In addition, the header fields of flow packets can be dynamically replaced while packets cross the network in an OpenFlow network. Therefore, to make violation detection more accurate in firewall application then it needs to not only checking the violation at entry switch for each flow, but it needs to track the flow path after that identify both the source and final destination of each flow ay network.
Also, the firewall application needs to know the source address and final destination address for each flow through tracking its flow path in the network. However, we should use a mechanism to identify the flow paths. First, we should use a geometric model like header space for processing packets to provide an independent protocol model for the network. Second, the samples of the networking boxes which is using a switch to transport function for supporting dynamic packets adjustments. Finally, it builds a diagram for representing all entire next hops dependencies and the intra table dependencies of rules and automatically can be capture both direct and indirect flow paths in the network .
Figure 13: show how violations will be detected.
However, in firewall authorization a system administrator may introduce certain overlaps at firewall rules that knowing only the first rule and it is important rule. In addition, for the aim of the detecting firewall policy violations in OpenFlow networks, then it has to separate the relations between allow rules and deny rules in the firewall policy. Furthermore, administrator can introduce an approach that represents rules with header space and also executes different set of operations on the rules which help to transforming a list of firewall rules into two disjoint authorization sub spaces which is denied authorization space and allowed authorization space .
As a result, new flows may directly reject by SDN firewall which violates the firewall policy and this would be simple for resolving flow packet violations. When there is a new flow policy then the request for installing this target will be rejected and if firewall application detects that the target policy violates the firewall policy then it will be rejected and also will be removed directly from the network devices. However, when it has been removed or rejected then the flow policy could affect the utility of the network services. Also, when the rule has been deleted in the violated policy then it can impact other flow policies and it could create a new violation .
The main advantages of packet filtering firewalls that they are located in every device on the network such as routers, switches, wireless and VPN and also all could have the capability of being a packet filtering firewall. Moreover, it gives administrator policies to add or remove some flow policies.
OpenFlow was made up via Stanford University in 2008 and OpenFlow managed via Open Networking Foundation (ONF), a user-led organization dedicated to open standards and SDN .
The OpenFlow is open communications protocol and the first interface between the control plane and the data plane from SDN architecture. All switches and controller can communicate to each other via OpenFlow protocol. Also, the high-level control the switch which includes packet routing and is moved to the center of the server. The OpenFlow protocol depends on SDN to enable information technology to deal with high bandwidth, compatibility the network to constantly changing business needs and reduce operations and management complexity .
Flow tables are like the tables in modern Ethernet switches and routers. In addition, can be executing QoS, NAT and firewalls or collect statistics for the network without regard to on which vender deals with, this process is done by flow tables. Also, flow-tables include correspond or action rules that can be established and modulate by the centralized controller. Moreover, the controller is providing the programmatic controller of flows for the network administrator to determine the specific route from source to destination using flow-based processing of packets forwarding. The OpenFlow protocol is the more common using the southbound interface of SDN. OpenFlow has referred the advantages of flexibility configurable forwarding plane. OpenFlow protocol provides the ability to control plane to communicate with data plane .
OpenFlow architecture consists of three concepts: First, network is created via Flow tables that compatible with data plane. Second, the control plane is made up of more than one Open-Flow controller. finally, the switch is connected to the control plane by the security of control channel .
Figure 14: OpenFlow Network Architecture.
The data path software is enabled to communicate switches with each other and with hosts. The switches communicate with the controller by using the control path. The connection between the OpenFlow controller and the switch is secured by using cryptographic protocols which are TLS or TLS. Authentication is done between the switch and controller via certificates signing that consists of strong security algorithm by the private key from both sides. However, The controller can be attacked through the denial of service (DoS) attack or Man in the middle attack. So, appropriate security practices should be strong to prevent attacks .
It is possible to divide the OpenFlow switch into three parts. The First part is the flow table refers to the switch as it must process the flow. Also, the flow chart comprises of actions that related for each flow. The second part is secure channel, it is very important to connect the switch with the controller. OpenFlow protocol offers communication between controller and switch via secure channel. Third part is OpenFlow protocol. OpenFlow offers open communication and standard between switch and controller. In addition, determine standard interface by OpenFlow protocol to pass through which entries in the flow table externally .
Figure 15: OpenFlow switch communicates.
The OpenFlow enabled switch is basically forwarding the packets device according to the flow table own it that is such as traditional forwarding tables. However, the OpenFlow enabled switch does not manage them and keep them in the switch Also, messages are exchanged between the switch and controller via OpenFlow which is connected to secure channel .
Open-Flow is the device compatible with basic forwarding that forwards packets depending to flow table. It consists of flow table entries group which are the header field, the action, and the counters. In addition, there are entries called flow entries or flow rules. OpenFlow table consist of flow entries:
Figure 16: Flow table entry for OpenFlow.
- The header fields: In the flow table entry, the packets that are accessible are checked. Also, the header field is consisting of specific field packets contain the wildcard-capable match and OpenFlow allows forwarding the fast packet and the switch requires ternary content addressable memory (TCAM) that permitting the fast search of wildcard matches. The header fields can be matched with different protocols rely on Open-Flow specifications such as Ethernet, IPv4, IPv6 or Multi-Protocol Label Switching (MPLS).
Flow table in the header field contains on different fields that are compared with incoming packets:
- Incoming switch port.
- IEEE 802.3 Ethernet source and destination address.
- IEEE 802.3 Ethernet type.
- IEEE 802.1Q VLAN ID and priority.
- IP source and destination address.
- IP proto field.
- IP Type of Service (TOS) bits.
- TCP/UDP source and destination ports.
- The actions: each flow entry is related to zero or more proceedings which dictate how the switch handles matching packets. After that, if no forward proceedings the packet is dropped. Proceedings list for inserted flow entries should be processed in the order specified. There is no arrangement to output the packets from inside the port and most common actions are modify the filed, forward and drop .
- The counters: are isolating statistics to collect for flow table. On another hand, the counters are consisting of variables, port, and queue for each table and store the number of packets and bytes and time of the flow .
Table 2: List of required counters that using in statistics messages.
|Per Table||Active Entries
|Per Flow||Received Packets
|Per Port||Received Packets
Receive Overrun Errors
Receive CRC Errors
|Per Queue||Transmit Packets
Transmit Overrun Errors
The controller is a software program that responsible for filling and manipulating the flow table of the switches by insert, modify and remove the flow entries. Also, the controller can change the behavior of the switch that related for forwarding. In addition, the protocol that is set for enables the controller to direct the switches called Open-Flow, so the controller uses a secure control channel .
There are three categories of communication in the Open-Flow protocol:
Controller-to-switch messages are established through the controller and sent to switch. Controller to switch includes different types of messages:
Features: request to the capability of the switch via send features request, the switch should be with answer advantage that determines capabilities of the switch. This operation is done by the controller and this is normally performed upon establishment of the OpenFlow channel.
Configuration: responds the switch from configuration parameters and the query with the parameter settings.
Modify-State: the message is sent via the controller to control state on the switches. In addition, it can add and delete the flow or set switch port properties.
Read State: can be collected information from the switch through using the message via the controller.
Packet-out: the controller is using to send packets from specific port across the switch and to forward packets received via packet in messages.
Barrier: the message is used to make sure receive the message or notice about operations completed via the controller .
Asynchronous communication is started by the OpenFlow-compatible without asking permission of the controller, asynchronous communication is using to inform the controller around packet arrivals, errors and state changes at the switch. For all packets that do not have a matching flow entry, a packet may be sent in the event to the controller depending on the configuration of the table. All packets are redirected to the virtual controller port, the package event is sent in down to the controller.
Flow-Removed: by the message is done added the flow entry to switch and determined timeout the value inactive. When the value is no active, must delete the entry because there is no activity. Also, there is the difficult value which determines entry time in any activity. In addition, the message modulation flow also determines whether the switch should send a message to remove the flow to the controller during the flow out.
Port-status: The key is accepted to send port status messages to the console while the port configuration state has changed. These actions contain a change in the status of the port status such as if it is dropped directly by the user.
Error: the switch able to notifying the controller by using error messages .
Symmetric messages are sent without asking permission from both sides that mean the switch or the controller are free to begin the communication without asking permission from the other side.
Hello: The Hello messages are exchanged between the controller and the switch when connection starts up.
Echo: the controller or the switch are using request and reply messages and they can use the echo to measure the bandwidth or verification from the controller and switch connection.
Experimenter: The experimenter messages display a standard way for the OpenFlow switches to show additional functionality inside the OpenFlow message type space. This is a platform area for features planned for future OpenFlow redaction .
Network devices are getting instructions from the data centre and network rules of from the controller. On the other hand, the controller receives the cases about the switch configuration and management from the switch and sends the packet out to the switch. In addition, OpenFlow is responsible about manages packet and switches flow table entries through adding and removing flow entries across the secure channel .
There are two configurations for the controller which are the centralized configuration and the distributed configuration. The centralized configuration is the controller that manage and configuring all devices. The distributed configuration is a single controller for each set of switches .
Figure 17: Illustrates Centralized and Distributed controls components.
The controller is working also in reactive mode or proactive mode. In reactive mode, the packets appear at a switch and the switch send informs to the controller about the packet. After that, the controller determines the path of the packet and set the rules along the right path for all switches.
Figure 18: demonstrate how reactive and proactive works.
Lastly, send the flow packets to their destination. As the result, the table does not have any rules. In proactive mode, the controller will be more powerful on performance than the proactive flow configuration. Also, the controllers are faster than the switches regarding performance. The reason is timeouts such as Transport Layer Security (TLS) echo request can be lost session timeout or cut connections with all controllers. As a result, the switch should leave based on executing the switch and configuration. Drop the packets and the messages that are going in the unsafe mode to the controller. According to unsafe mode, the flow entries have they expiration timeout. Also, in this case of the independent failure, all packets are fixed via the switch is using reserved port where it acts as a legacy router or Ethernet switch. At the beginning, the switch will be working successfully connected with the controller, unless it fails in secure mode or fails in standalone mode. When the controller is connected, the current flow entries remain the same. Also, the controller has the option for erasing all flow entries if it required from it .
The messages are exchanged between OpenFlow controller and OpenFlow switch by using OpenFlow channel. The switch and controller communicate, the connection done by TLS which is located by default on TCP port 6653.Therefore, we must look in security actions to prevent attacks, eavesdropping and controller impersonation during using TCP on OpenFlow channel. Also, the communicate between the controller and switches is done by using default transport port or the specified transport port switches at a user configured IP address If the switch is configured by using an IP address of the controller to connect, the switch starts connection TLS or TCP to the controller. So, between the switch and the controller are mutually authenticated via exchanging certificates signed across the private key for both of sides. Each switch must be configured by the user with one certificate for authenticating the controller. If they fail connection between the switch and the controller, the switch can be replaced this controller by other controllers, the switch can be connected to one controller or several controllers. In addition, multiple controllers are connected and the controller manages the switch. Also, enables load balancing and fast recovery from failure .
Floodlight controller is a SDN controller that provides by big switch networks which working with OpenFlow protocol to organize traffic flows in SDN. Floodlight is built up at Stanford University to turn on big switch networks by a group of developer’s open source side by side with engineers at SDN and NFV. Floodlight is open source program depends on java to implementation the controller that is working with OpenFlow switches. Also, OpenFlow protocol determines open communication that allows the controller to talk with the data plane to make the changes in the network. In addition, providing basic infrastructure instructions on how to handle traffic and maintaining all the network rules by SDN controller.
Floodlight is OpenFlow controller and group of applications is built upon Floodlight controller header. Also, there is a group of common functions for the control and inquire about OpenFlow network, done by the Floodlight controller. On another hand, applications on Floodlight header has different features which help to solve different users’ needs across the network. Moreover, there is relationship between the controller and the applications that are built upon java modules was compiled with Floodlight and applications were built on Floodlight REST API.
As shown in the figure (19) we will illustrate the primary module which are related to the Floodlight controller core:
The Link Discovery: Link Layer Discovery Protocol (LLDP) and Broadcast Domain Discovery Protocol (BDDP) are working in the link discovery; they are responsible for discovering the status of links in the OpenFlow network and maintain them. In addition, control the controller by the Link Discovery module the switch to flooding Link Layer Discovery Protocol (LLDP) and Broadcast Domain Discovery Protocol (BDDP) to all the packets and the ports. Moreover, protocol packets include usually on Data Path Identifier (DPID) from the sender switch with the port of the switch that the message outputs from. Direct and indirect communication is detecting between the switches via the controller. For this reason, it will establish the direct link for LLDP is sent to one port and the same LLDP is received on the on other port, so the result the ports are connected directly. on another hand, it is possible to find connections direct and indirect by Broadcast Domain Discovery Protocol (BDDP) via flooding approach. In this case, broadcast link will be established if the BDDP packet is sent to port and received from other port, that mean is another layer 2 switch is not under the control of the controller. Finally, the verifying is done from the connection and periodical checks by the controller.
The Topology Manager: the controller gets the update, maintains the information and to find right routes in the network via the topology manager. Also, by the link information that restored from the Link Discovery service the topology is counted. In addition, the topology instance is storing all information in the immutable data structure about for the current topology, by using Dijkstra algorithm can selecting shortest path via the controller from the source switch port to the destination switch port.
The Device Manager: devices are tracked through requests the packet in the connected with the network and selecting the destination device for the new flow via the devices manager. Also, the MAC address and the VLAN are used for the module to determine unique device by default. Moreover, the devices manager learns the most important parts from information like permits to know the device attachment points and IP addresses. so, establish the point for that device if the switch received a packet.
The Storage service: a support service which provides a notification mechanism and allows modify the style of NoSQL databases.
The forwarding component: The operation that make forwarding the packet between two devices possible, to verify from reactive forwarding and It is loaded by default is the forwarding component. Also, styling for the forwarding component uses to work in the networks that consist of OpenFlow switches and the ordinary switch. in addition, it works without groups loops OpenFlow switches and ordinary switches.
The learning switch: almost working similarly as in the ordinary switch network in layer two and it detects and learns about the new devices depending on own MAC address for them. Also, the learning switch determines entries and output switches when it is discovered new flow and selecting the short path between the beginning point and the end. Moreover, when finding on the ordinary network the learning switch It installs the occasion OpenFlow rules to deal with the new flows on all the switches.
The Static Flow Entry Pusher: through EST API allows the user to enter the flows manually in the OpenFlow-enabled switch by the static flow entry. Also, it realizes the proactive forwarding approach.
 P. A. Morreale and J. M. Anderson, Software Defined Networking: Design and Deployment. CRC Press, 2015.
 J. Doherty, SDN and NFV Simplified: A Visual Guide to Understanding Software Defined Networks and Network Function Virtualization. Addison-Wesley Professional, 2016.
 P. Goransson, C. Black, and T. Culver, Software Defined Networks: A Comprehensive Approach. Morgan Kaufmann, 2016.
 D. A. R. Bryant, D. R. F. Mills, and D. J. R. Lopez, Eds., 12th International Conference on Cyber Warfare and Security 2017 Proceedings. Academic Conferences and publishing limited, 2017.
 S. Racherla et al., Implementing IBM Software Defined Network for Virtual Environments. IBM Redbooks, 2014.
 J. Liu, Y. Lai, Z. Diao, and Y. Chen, “A trusted access method in software-defined network,” Simulation Modelling Practice and Theory, vol. 74, pp. 28–45, May-2017.
 M. CHEN et al., “LCMSC: A Lightweight Collaborative Mechanism for SDN Controllers,” Computer Networks.
 T. D. Nadeau and K. Gray, SDN: Software Defined Networks: An Authoritative Review of Network Programmability Technologies. O’Reilly Media, Inc., 2013.
 C. Chenxiao and X. Yabin, “Research on Load Balance Method in SDN,” vol. 9, p. 12, 2016.
 S. Ganesh N and R. S, “Dynamic Load Balancing using Software Defined Networks,” p. 4, 2015.
 P. Goransson, C. Black, and T. Culver, Software Defined Networks: A Comprehensive Approach. Morgan Kaufmann, 2016.
 W. Zhou, L. Li, M. Luo, and W. Chou, “REST API design patterns for SDN northbound API,” 2014.
 S. Sharma et al., “Implementing Quality of Service for the Software Defined Networking Enabled Future Internet,” 2014 Third European Workshop on Software Defined Networks, pp. 49–54, Sep-2014.
 D. D’souza and S. Lokanath, “Improving QoS in a Software-Defined Network,” vol. 1–9, p. 9, 30-Apr-2016.
 L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification,” 2000. [Online]. Available: https://tools.ietf.org/html/rfc2205. [Accessed: 07-May-2017].
 R. Mameli and S. Salsano, “Use of COPS for Intserv operations over Diffserv: architectural issues, protocol design and test-bed implementation,” in ICC 2001. IEEE International Conference on Communications. Conference Record (Cat. No.01CH37240), 2001, vol. 10, pp. 3265–3270 vol.10.
 K. Nichols, D. L. Black, S. Blake, and F. Baker, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” 1998. [Online]. Available: https://tools.ietf.org/html/rfc2474. [Accessed: 07-May-2017].
 I. Ku, Y. Lu, and M. Gerla, “Software-Defined Mobile Cloud: Architecture, services and use cases,” 2014 International Wireless Communications and Mobile Computing Conference (IWCMC), pp. 1–6, Aug-2014.
 S. Azodolmolky and P. Wieder, “Cloud Computing Networking: Challenges and Opportunities for Innovations,” p. 14, 2013.
 W. Kim and J. Lee, “Automated and Scalable QoS Control for Network Convergence,” p. 6, 2010.
 R. Jain and S. Paul, “Network virtualization and software defined networking for cloud computing: a survey,” IEEE Commun. Mag., 2013.
 Y. Li and M. Chen, “Software-defined network function virtualization: A survey,” IEEE Access, 2015.
 A. X. Liu, Firewall Design and Analysis. World Scientific, 2011.
 F. Lombardi and R. D. Pietro, Security for Cloud Computing. Artech House, 2015.
 G. Katwal and M. Sood, “A Comparative Study of Traditional Network Firewalls & SDN Firewalls,” no. RICSIT-2016, p. 16, 2016.
 J. Shah, “Implementation and Performance Analysis of Firewall on Open vSwitch,” p. 42, 29-Apr-2015.
 C. Yannick and O. Paul, “DIADEM Firewall: Web Server Overload Attack Detection and Response,” p. 7, 12-Dec-2005.
 P. Kazemian, G. Varghese, and N. McKeown, “Header Space Analysis: Static Checking For Networks,” p. 14, 2013.
 S. Dutta Kalita and R. Kumar Sharma, “Firewalls Policies Based on Software Defined Networking: A survey,” vol. 4(1), 2016, p. 3, 2016.
 N. McKeown et al., “OpenFlow: enabling innovation in campus networks,” ACM SIGCOMM Comput. Commun. Rev., 2008.
 F. Hu, Network Innovation through OpenFlow and SDN: Principles and Design. 2014.
 A. Sonba and H. Abdalkreim, “Performance Comparison Of the state of the art OpenFlow Controllers,” 2014.
 W. Braun and M. Menth, “Software-defined networking using OpenFlow: Protocols, applications and architectural design choices,” Future Internet, pp. 302–336, 2014.
 B. Heller, “OpenFlow Switch Specification,” 2009.
 S. Azodolmolky, Software Defined Networking with OpenFlow. Packt Publishing Ltd, 2013.
 G. Romero de Tejada Muntaner, Evaluation of openflow controllers. 2012.
 P. M. Rekha and M. Dakshayini, “A Study of Software Defined Networking with OpenFlow,” Int. J. Comput. Appl., 2015.