A survey on SDN, the future of networking

Software Defined Networking (SDN) is an emerging architecture which decouples networks control plane and data plane physically. It makes control plane programmable trough a centralized controller, and builds intelligent and flexible networks. The OpenFlow is one of the most famous SDN protocols, which acts as a southbound interface between control plane and data plane. In this survey, SDN implementation approaches and different southbound interfaces, beside different version of OpenFlow, are introduced. In addition to general architecture of SDN, different wireless architectures are discussed. Here, also potential SDN’s applications and research areas including hot topics such as Information Centric Networks, Cloud and datacenters, multimedia, wireless and mobile networks over SDN are reviewed.


Introduction
Use of mobile devices, emerging technologies such as cloud computing and virtualization, caused changing of traffic patterns. The rise of Big Data in datacenters arise the need for high network capacity and network scaling. To support these needs, network devices become more complex. Furthermore it would be hard and time consuming for administrators to configure individual devices due to even little changes in network, such as adding or omitting a device. They should reconfigure many multivendor switches and routers, ACLs, which may cause inconsistency and errors [1][2][3]. The Idea of programmable networks was introduced to meet these challenges and facilitate network evolution. As a result, Software Defined Networking (SDN) is a new paradigm, which revolutionized traditional network architecture. SDN effectively separates the control plane from data plane and move it to a centralized server named controller. It moves the complexity of network management into a software-based controller and provides an abstraction of underlying infrastructure. This allows simple data plane and network devices, makes control plane to be directly programmable and manageable in a centralized manner [1], [4], [5]. The SDN architecture provides programmability, flexibility and reliability over networks. Network operators can implement their own protocols, rules and policies with common programming languages. They can achieve flexible control over network services such as routing, traffic engineering, QOS and security. Network can adapt itself depends on users' requirements. Network management and configurations can be automated through the centralized controller and standard open API, making the network scale easily. By using SDN, administrators are able to add features to control plane without changing data plane or enhance devices in data plane without changing control plane. Decupling control plane from infrastructure is also important because it reduces costs and inconvenience of testing new ideas and strategies in network or deploying new architectures [1], [3], [5], [6]. In this paper, we present SDN architecture, its capabilities, deployment, applications and challenges to give a broader view for those who are interested in this area. The rest of the paper is organized as follows. Section 2 represents the history of programmable networks. In Section 3 wired and wireless SDN architectures are discussed and different protocols used in these architectures are presented. SDN networks implementation and tests are discussed in section 4. In section 5, the SDN applications and its open research areas are reviewed. Section 6 describes existing challenges of SDN. Finally section 7 concludes the paper.

History
Many years ago, the idea of programmable networks, resulting SDN paradigm, has been created [6]. In 1988 SOFTNET [7], in 1990 Active Networking [8], in 1995 OPENSIG [9] and GSMP [10], in 1998, IEEE P1520 Standards Initiative [11], in 2004 4D Project [12] and SoftRouter [13] architecture and finally in 2006 NETCONF [14], Ethane [15] and SANE [16] were proposed to answer the idea of programming network. SANE developed as a prototype, considered a logical server that performed all access control decision. Ethane separated controller and Ethane switch toward providing policy and security by an identity-based accessing. But in 2010 according to RFC 5810 by IETF, ForCES (Forwarding and Control Element Separation) [17] "A parallel approach to software-defined networking" was announced which standardized the communication between controller and network elements. The difference between ForCES and OpenFlow (OF) is their network architectures. ForCES assumed no changing in network architecture so that controller and network elements are situated in one single device as regards to this point that they are apart from each other, but OF separates the controller and network elements physically. Several efforts in the field of SDN have been taken until now. Internet Research Task Force ( IRTF), defined The Software Defined Networking Research Group (SDNRG) [18], intended to figure out future SDN approaches and challenges. Also there is a Home provided for SDN researchers in [19].

Architecture
SDN architecture consists of 3 layers: infrastructure layer, control layer and application layer. Infrastructure layer or data plane is responsible for forwarding the packets by means of simple forwarders and switches. Control layer contains the controller to manage the Infrastructure layer. In application layer the business applications can interact with network services and capabilities. There is also a need for southbound and northbound interfaces to enable the controller to communicate with the two other layers [1]. More details of SDN components are described in this section.

Control layer
SDN architecture decouples two parts of a network device. In controller plane, a software program is placed on top and is separated from switches as shown in Fig. 1. Controller plane manipulates the forwarding table for each switch request based on the header of packet-in message (a packet which is created by switch upon table-miss) and sends respond via packet-out or flow-mod message and tracks all applications requests. Each controller plane is built from two components: applications and network operating system. The application part is in many of software programs from metering to monitoring which network virtualization is one of them. When lots of applications regardless of their works confront with WAN, resources become scarce and SDN architecture should be completed with a network packet broker (NPB) and access monitoring [20]. NPB could be one of the controller part that checks the required resources whether it is available or not. So NPB needs to have network topology, past and current traffic loads [20]. Some of controller platforms are compared in Table 1. Controllers can be deployed in a centralized or distributed manner. One of the most obvious advantages of using a centralized controller is that management and retrieving information would be applied from one logical point (controller) resulting uniform network. Centralized controller like each centralized model has the disadvantages of single point of failure, terminating no availability and scalability. Network could have more than one controller, so each controller is responsible to control a group of network switches, which may interfere with each other, thus one controller is chosen to be the main controller and the others would be backups [6]. ONIX [21] and HyperFlow [22], suggest a logically centralized but physically distributed control plane. Each switch is controlled with its controller and controllers are distributed in the network, using memory resident (in-memory database) and applications that are written on top of the controllers consider all of the controllers as one central controller. Although in this option lookup overhead will be reduced and scalability and availability are supported, establish consistency and compatibility between network OS and any kind of supported OF and even between controllers are some of the most important issues. Hierarchical view of the controllers like Kandoo [23], manage their related switches and there exists one controller that manages local controllers in order to implement applications on it. Using this case like ONIX and HyperFlow reduces lookup overhead, present availability and scalability with the central view of the whole network without worrying about its consistency and compatibility. Also a proxy controller, FlowVisor [24] is used to set a logical decentralization and give a virtualization view to the controllers in one network. Packet granularity requires controller plane decision whenever a packet is arrived in data plane. When a table-miss is happened in a switch, switch will encapsulate the entire received packet as a packet-in message and sends it to the controller, decision will be made and a packet-out message will be sent to the switch. In this case, huge amount of data would be passing through the controller and switch that could cause delay. Flow granularity is another selection. When a flow is passed through a switch, for the first time that switch receives that flow, it requires controller plane decision so sends packet-in message which contains only the header of original packet and at the controller side, decision will be made and flow-mod message containing original packet header will be sent to switch. After that, switch will decide based on last decision. In a switch, controller plane decisions would be applied to any kind of flow, subordinates to source, destination, data or any kind of information relates to that flow. If there isn't any decision for huge number of flows received at switch, a lot of connection would be required for any of them; which causes delay. In active policy, switch notifies the controller each time it needs a decision. In proactive policy, controller passes control information to the switch. Both of these policies would be merged to any kind of granularity [6].  [33][34][35][36][37]. A flow is a sequence of packets that matches a specific entry in a flow table. On receipt of a packet, the switch matches the packet header fields with match fields' component of entries. After table lookup and matching process, the instructions of entry with higher priority will be done on the packet. The fields from packets used to match with flow entries are shown in Table 2. There are two types of OpenFlow switches: OpenFlow-only, and OpenFlow-hybrid. OpenFlow-only switches support only OF operation, in those switches all packets are processed by the OpenFlow pipeline and the forwarding decisions are made by controllers. OpenFlow-hybrid switches support OF operation in addition to traditional operation such as L2 Ethernet switching, L3 routing etc. A classification mechanism is needed to classify the traffics of OF pipeline and normal pipeline. This mechanism may use VLAN tags, Input ports of the packets, etc. [33][34][35][36][37]. In another aspect, the switches can be classified into Hardware based switches and software based (virtual) switches. Table 3 lists some of the currently SDN available switches.

Northbound interface
SDN Applications are programs that may consume an abstract view of the network for their decision making goals. Moreover, these applications programmatically and directly convey their network requirements and desired network behavior to the SDN Controller. Interfaces between SDN Applications and SDN Controllers are known as Controller-Application Interaction or SDN Northbound Interfaces (NBIs). Northbound Interface of component can be introduced as an element that conceptualizes the lower level details of functions used by component. This interface is usually positioned at the top of the corresponding component, which is the basis of the "northbound interface" title [47]. Despite southbound interface that is well defined in protocols such as ForCES and OF, no comprehensive standard is defined for northbound interface and they are more likely to be developed for particular SDN applications [6]. One justification is that the southbound must enable hardware implementation, while northbound interface's definition completely in software. For various reasons controllers may need to communicate with each other, on the other side, network applications may require extraction of information about the underlying network policy aspect, then there should be a clearly defined interface. There are some proposals such as Procera [48], Frenetic [49], FML [50] and Nettle [51] which build a policy layer by using a network configuration language. In addition, the northbound API must authorize employment of different policies to the same flow. The modularization approach proposed by [52] tries to avoid rules installed for one task override other rules. This goal is achieved by implementation of an abstraction layer. IETF with the goal of network traffic engineering deployed Application-Layer Traffic Optimization (ALTO) [53] which currently has been considered for content delivery networks (CDNs) implementation. According to information provided by ALTO, server network was optimized that improve performance and resource consumption. This information gathers by mapping network topology and create abstract and logical model of network by server. Exchanging request and response is accomplished thereby JSON [54]. The set of ALTO features convert this API to appropriate option for SDN implementation [4].
Interface to the Routing System (I2RS) working group is another API for northbound was developed by IETF that its objective was to provide standard for programmable network. Policy-based routing can be mentioned as important trait of I2RS. This interface in compared with similar protocol such as SNMP and NETCONF. It is more rapid and application-friendly [4].

Southbound interface
In SDN, the most popular southbound interface is the OF protocol. OF enables communication between controller and the nodes in the network, so the controller discover network topology, get reports from the nodes, instruct and manage them as needed and implement requests relayed to flows via northbound APIs. There are also other southbound interfaces, which are described in this section [5], [55].

Openflow protocol
OF protocol is the most well-known interface between forwarders and controllers in SDN. This protocol is defined for Ethernet-based networks. OF protocol have different versions. The first version was OF 0.2.0 released in March 2008 as a draft. The OF 1.0 specification is the first version which has official vendor support. The latest specification is OF 1.4 which released in October 2013. As shown in Table 3 Table 2. Each flow entry contains a specific value or ANY keyword which matches any value. The entries must associate with zero or more actions that should be done on the matching packets in order. The packets with zero actions or action lists which cannot be processed by the switch are dropped. If no matches found for a packet the first 200 bytes of the packet are sent to the controller through the secure channel.
In OF 1.1 [34] several flow tables are pipelined. When a switch receives a packet, it starts to look for an entry to be matched in table0. If the entry found, the packets get processed according to the entry Instructions. The instructions may contain Goto Instruction which points to another flow Another improvement over previous versions is meter tables which make OF to implement QOS operations like rate limiting. Also a specific duration filed is added to most statistics which helps to compute rates. A cookie field is added to messages containing packets sent to the controller. This helps controller, process the messages faster than if it had to search its entire database. In Previous version of OF, a switch could connect to multiple controllers for fault tolerance and load balancing. OF 1.3 introduces per connection event filtering which improves the multi-controller support by enabling each controller to filter events from the switch it does not want. It also enables a switch to create auxiliary connections to supplement the main connection between the switch and the controller. This allows using the parallelism ability implemented in most switches. OF 1.4 [37] is the latest specification. In this version TLV structures is used in more parts, improving extensibility. Support for optical ports is added by means of new set of port properties. They include fields for configuring and monitoring transmit/receive frequency and power of a laser in either Ethernet optical port or optical ports on circuit switches. In previous versions, when a flow table is full, the switch sends an error message to controller to operate on the flow table. This is time consuming and may cause problem. In OF 1.4 an Eviction option is added which makes the switch able to eliminate lower important entries automatically and make space available for new entries. Switches can also inform controller of tables getting full (based on a capacity threshold chosen by controller) via vacancy events and avoid tables to get full. Bundle mechanism is added for quasi-atomic execution of a group of instructions. The Error message is sub-type of symmetric messages in this version and can be initiated by either switch or the controller.

XMPP
The Extensible Messaging and Presence Protocol (XMPP) [56] is a XML-based protocol introduced by Internet Engineering Task Force (IETF). The basic idea was proposed by Jabber community in 1999 and they introduced an open-source protocol. Afterward IETF represented the improvement version for instance message in 2002. Finally in 2004 the standard definition was published on RFC3920 and RFC3921. XMPP enable exchange "XML stanzas", small piece of XML, between different entities based on client-server architecture. All connection of this protocol is performed by TCP. Decentralized system of XMPP enables everyone to implement their own XMPP servers and launch their domain. At Juniper Networks Contrail [3], an open source solution introduced by Juniper Network Company was intended XMPP as southbound protocol and was implemented in the controller. As a result, it is possible to build high scalable virtual network and control cloud services automatically.

OnePK
One Platform Kit (OnePK) [4] is API & software development kit (SDK) toolkit to develop controller application for programming Cisco network devices managing and planning. OnePK consists of three main elements: presentation Layer which provides required library for programmers and supports multi language programming such as C, Java and Python, API Infrastructure with task of coordination among various platform and Communication Channel that put out security and flexibility between controller and network elements. Provided service sets enable network administrator to manage and control great number of elements.

Wireless architectures
We described the general architecture of SDN in previous sections which is mainly used for wired networks. But SDN also can be deployed for wireless networks. Currently, researchers' main focus in SDN wireless architecture, is centralized control of wireless networks: A central controller's main duties such as management wireless access points, user verification, etc. [57]. In comparison with distributed wireless networks, the centralized system has better consistency because of global view of the network controller. One other feature of wireless SDN networks is that they present peculiarities because its control requires the knowledge and policy about the radio interference and the node mobility [5].

Openroad
For controlling wireless SDNs one of the first approaches was OpenRoad [58]. This open source platform was developed to specify the wireless OF over NOX. OpenRoad architecture [5], is composed of three layers as illustrated in Fig. 3

SoftRAN
Nowadays, distributed algorithms are utilized by radio access network in order to handovers management. While the decision making in environment with few base stations can be easy, it will be relatively harder to swiftly select the best candidate in dense deployments of base stations. For the purpose of handling increasing mobile traffic, some researchers offered SoftRAN [59], a centralized software defined radio access network designed for performing handovers efficiently. In SoftRAN all the base stations are abstracted and controlled in a centralized way. In order to manage every base station, control plane used defined APIs to communicate with radio elements. General architecture of SoftRAN is illustrated in Fig 4. It periodically gathers the states of base stations and updates the global view of the network. The controller modules require that information to manage radio resource, so collected in the form of a database.

SoftCell
For solving significant scalability problems exist in cellular networks, Li Erran Li et al. [60] proposed a cellular SDN architecture with local control agents with ability to make simple decisions, as illustrated in Fig. 5. The centralized controller responsible for interpreting flows with high level abstractions. On the Other side, some actions and policies are run on a cell agent for improving the performance and efficiency of the centralized controller.

Implementation and testing
As mentioned in previous section, many switches and controllers are available for implementing a software defined network. But there is also ways for testing ideas in SDN such as using simulators, emulators and test-beds. NetFPGA's [61] can be used for building a SDN node. Debuggers are also available for testing controllers.

Simulators and emulators
In this section available SDN simulators and emulators such as Mininet, NS-3 and Estinet are described and compared.

Mininet
Mininet [62], an emulator platform using OF protocol, runs a collection of end-hosts, switches, routers and links on a single Linux kernel by using lightweight virtualization. Components of Mininet act as real network components. This emulator has lots of tools to check the possible bandwidth, the connectivity among nodes and deepest nodes, and the speed of flows. These tools are named Ipref, Ping, PingAll, PingPair, CBench and also Wireshark in order to view network traffic. Mininet is used by developers, teachers and researchers and this is because of easily interaction with network using CLI and API, customizing and sharing features and also development feature on real hardware. It should be mentioned that Mininet is actively developed and supported. Mininet is used widely just because of: fast to start a simple network, supporting custom topologies and packet forwarding, running real programs available on Linux, running on laptops, servers, virtual machines, having sharing and replicating ability, easy to use, being in open source and active development state. In contrast with these advantages, Mininet has some disadvantages too: having disability of transferring huge amount of data in one single system, non-available supporting arbitrary OF controllers, supporting just one platform (Linux kernel), doing NAT out of box, having sharing host file system and PID space and virtual time notion absence. Measuring performance is presented in [63].

NS-3 [64]
is a discrete event network simulator which is suited for researchers and educators. The NS-3 library is split across many modules organized under the modules tab. One of these modules is OF conformable to SDN. NS-3 has OpenFlowSwitchNetDevice object behaves as a switch and is OF compatible. This object implements a flow table for all received packets and also a connection to controller just like SDN architecture. Two controllers are available in original package, DropController and LearningController (based on learning switch algorithm) [65]. This simulator has these advantages: adding new protocols, shortage of distance among real network and simulated network, having integration and customizable without remaking the core of simulator. NS-3 disadvantages are: loss of available models, absence of visual interface for creating topology and visible capability in experimental level.

3 EstiNet
EstiNet 8.0 [66] simulator and emulator supports many OF 1.3.2 and 1.0.0 switches. Besides this advantage, in the simulation mode of EstiNet; POX, NOX, Floodlight and Ryu controllers will have the role of SDN controller plane. In the emulation mode of EstiNet, these controllers can run up on an external machine that is different from the machine which simulates switches. Also in this mode implementation of the controller as a dedicated hardware device using an Ethernet cable is possible, resulting remote controlling. The other benefits of using this simulator/emulator are: accuracy, quickness, repetition and scalability. EstiNet has a unique capability which is called "kernel-reentering simulation methodology". By using this, testing of a novel controller applications program by an OF researcher is easy and effective. A comparison between Mininet, NS-3 and EstiNet is presented in Table 4.

NeTFPGA
NetFPGA is the software and hardware platform aim for researchers and is used for teaching. Now it is available in 2 platforms: NetFPGA-1G (1G) and the NetFPGA-10G (10G). Due to its open source software and low cost hardware, it is taken into consideration of many students. NetFPGA consists of PCI with four Ethernet port, Xilinx Virtex II pro, static RAM and Double Date Rate (DDR2) SDRAM [4]. Based on advantages that mentioned and flexibility of NetFPGA platform, it is intended as one solution to implement SDN. Field Programmable Gate Array (FPGA) allows to program core processing with user defined logic and embedded core allows to program control functions [61].
In [67] Pang-Wei Tsai et al. described a solution to integrate NetFPGA and OF into network emulation test-bed. Therefore, the authors succeed to implement traffic-controllable network test-bed with high speed packet processing. J. Naous et al. presented a paper and explained the result of implementing OF on NetFPGA in [68].They stated that this implementation is full line-rate and easy to monitor network flow.

Test-beds
OF test-beds are experimental environments that mainly developed for testing novel applications using OF. Currently, there are some open test-beds that can be employed for academic research. In continue, some of the most important OF test-beds are introduced and described. GENI: GENI [69] stands for Global Environment for Network Innovations that is supported by the National Science Foundation. It is a wide suite of infrastructure, developed to support experimental research in networking by creating a huge test-bed [5] In order to reach its goal, GENI federated some platform such as PlanetLab [70], Internet 2 [71], Emulab [72], etc. At a high level, it has the prospect of experimental test-bed in which all components will be programmable, federated and virtualizable, thus it is the best candidate when the deployment scales [73]. Nowadays, GENI project in conjunction with Internet2 are enabling a SDN based network ready for the deployment novel architecture for new network services and future internet [74]. OFELIA: Funded by Seventh Frame-work Program (FP7) of European Union. The idea behind OFELIA [75] is a testbed in which researchers can dynamically control and extend the network via OF. The OFELIA infrastructure formed by a set of interconnected islands, each of them managed independently. Employment of virtualization, permits each experimenter receives a network slice. Each slice is formed by virtual machines to run the clients and server, virtual machine which corresponds to a typical OF controller and virtual OF network. OFELIA Control Framework (OCF) is a Common control framework to performed experiment. OCF provides tools for user verification and access, allocation of the slice, configuration of the network [5]. FIBRE: The main goal of FIBRE is to create common space between Brazil and Europe for future Internet architectures [76]. The key idea behind this project [77], is to build a federated test-bed by combining wireless networks and wide area network. The wireless network and wide area network are controlled using OF [5].

Debuggers
As mentioned before SDN controller is programmable and this feature increases the probability of inadvertently errors. Generally, finding bugs is hard and time-consuming therefore debuggers have become one of the important components of OF/SDN. Debuggers are tools that are used to test and diagnose program and enable programmers to interact with program while it is executing on computer. OF debuggers allow us to trace packet flow behavior to check whether the network is operating as expected [5]. Nikhil Handigol et al. in [78] introduced ndb, a SDN debugger. Their idea was similar to gdb, a debugger for GNU operating system, which changes original control flow without any changes to its semantic. The main goal of the authors was using familiar action specially breakpoint. Breakpoint operation calls all functions that lead program to specified point.
A. Khurshid et al. presented VeriFlow in [79], a layer between controller and hosts that analyzes and checks network configuration to find bugs without having negative impact on network performance. They claimed that implementation of VeriFlow is compatible with NOX controller and demonstrated that it is able to verify the control plan rules in real time and prevent error to impact the proper functioning of the network. FlowChecker is a configuration analysis tool which introduced by in [80]. Using this system provides the possibility of checking correctness of data plan configuration and validating consistency of different devices on OF network by interpretation intra/inter-switches flow table using Binary Decision Diagrams. The authors showed that configuration analysis can be done while network is running. This feature is useful to determinate QoS. M.Kobayashi et al. at [81] presented approach for collecting network parameters and used that data to monitor, analyze and debug SDN. The main information for debugging is gathered from flow table, different traffic statistics and controller messages. Some different tools were used for debugging purpose and checking traffic between controller and switches using Wireshark integration, which was stated as the most effective approach.

Applications and research trends
In this section we introduce SDN applications and recent researches including Software defined ICN, Multimedia, network management, network virtualization, cloud and datacenter, security, wireless and mobile networks.

Software defined ICN
In recent years many researchers claimed that current internet architecture is not able to response the emerging and future need of users. Based on this claim, new architectures were introduced. Information centric network is one of these architectures. In ICN, the information name is unique and independent of locations, applications, storages and distribution and network primitives are done based on the names. To retrieve named information, various transmission techniques are introduced, including name-based routing, name-based resolution, and etc. To support these techniques and exploit the advantages of ICN, dramatic changes to the network devices deployed in current Internet are needed, which leads to challenge of ICN implementation [82], [83]. A number of projects [82][83][84][85][86] proposed implementing ICN over SDN. This leads to decreasing in implementation costs. It also enables innovation and optimization of network resources and functionalities. Proposed methods are discussed in Table 5. Integrating ICN and SDN can help emerging technologies grow efficiently and easily face the challenges in today's networks. Supporting mobility and cloud computing are two controversial subjects in today's networks due to inconsistency with IP protocol. SDN can be used to make the best and optimized decisions for VM migration based on the controllers' view of network and automatically update the network devices configurations after migration [5].
One of the advantages of implementing ICN over SDN is to improve ICN's functionalities. In [89] a routing protocol is proposed which supports mobility by means of controller. This can be easily implemented using software defined ICN.
In [90] the authors, discussed the role of virtualization in NDN (an architecture based on ICN) and outlined traffic optimization, traffic engineering and in-network catching management as the advantages of implementing NDN over SDN, specially for multimedia traffics.

Multimedia and QOS
Today's internet architecture is based on end-to-end communication control which enables best effort services. This is valuable for data transmission but not for multimedia traffics. Multimedia applications such as video streaming, video on demand, video conferencing, WebTV and etc. require steady network resources and tolerate special amount of delay, jitter and error-rate. Providing these QOS requirements needs to select optimum path among all paths available in the network [91], [92]. QOS architectures like IntServ [93] and DiffServ [94] are proposed for this purpose, which have difficulties. They have lack of a centralized view of the network and choose the path in a hop-by-hop manner which may not be the optimum path. They also need specialized software and hardware requirements for implementation. Software defined networks make it possible to select different paths for different traffic flows by use of different routing protocols (performing routing prioritization), based on flow's requirements and a centralized view of the network. Moreover, OF has some QOS features. In OF 1.0 the flows' packets can be queued in output ports. This queuing mechanism can be configured through protocols such as SNMP, CLI and NetConf [95]. By use of an auxiliary configuration protocol named OF-Config [96] maximum and minimum transmission rate of queues can be configured. OF 1.1 added support for rewriting ECN (Explicit Congestion Notification) bits. The most important feature is table meters which have been supported since OF 1.3. This feature enables rate limiting. Many projects [91,92,97,98] proposed enhancement or optimization methods for multimedia QOS over SDN. A summary of these projects are presented in Table 6.

Network management
SDN caused an abstract picture of network for simplified policy enforcement and network management so network management is applied from one logical point. OF architecture, as a part of SDN architecture, made network management more flexible, control in the packet or flow granularity levels. Management in software defined network from a centralized logical point upon flow-table at controllers and using that flow-tables distributed in network (switches) cause a flexible network management [99]. Here are some efforts accomplished in the field of network management. Network configuration because of A) high-level policies specifications in a distributed low-level configuration (using CLI) mode and B) mutable network state is difficult [99]. Authors also in [99] authors solved three problems SDN network management: frequently changes happening in a network, using a high level language for network configuration, fault and error recognition and troubleshooting. They did it by Procera, an event-driven control framework based on SDN paradigm which is based on functional reactive programming (FRP) and OF 1.0.0. High level policies could be translates into a set of rules and four control domain is in operators' hand: time, data usage and authentication status and traffic flow. Another control system is integrated network management and control system (I-NMCS) discovery and fault detection [100]. Provisioning and control are combined together and is modular, loose coupling, with low overhead and extensible. I-NMCS is used in a hybrid mode which means that only selected flows will be handled by the controllers and rest of the flows will be exerted by network protocols. This is because of authors' thought that traditional network management and SDN in future networks would be co-exists with each other. Security management is another aspect of network management. Some applications implemented in controllers brings complex processing more than security. In [101] an algorithm of information security management system combined with fuzzy logic and a prototype of intrusion detection system (IDS) is presents. Using fuzzy logic in this paper decreases number of code lines 20-30%. For event-based network control approach, Lithium [102] system and for minimal visibility of performance and control, a programmable measurement platform approach resulting BISmark [103] are offered. In [104] an online configuration management problem which uses OF and includes agility, accuracy, reliability and scalability is presented. This framework is consists of two parts: disaster event detection and filtering segment and disaster correlation and detector management segment. More efforts are doing in network management fields from performance to security.

Network virtualization
Network virtualization is one of the important research areas of today's network that enable users to share resource and infrastructure. SDN due to central controller is discussed as a solution to manage virtual networks [5].
In [105] J. Matias et.al presented the EHU OF Enabled Facility (EHU-OEF), a system for managing virtual networks and sharing infrastructure based on layer 2 and OF. The authors were selected L2PNV for implementation their system. The benefits of using layer 2 prefix-based network virtualization (L2PNV) for network virtualization consist of ease of configuration and flexibility of header fields that allows users to create different slice and different virtual network. R. Nejbati et.al in [106] was proposed cross-layer approach for network isolation based on OF to optimize Network virtualization without interfering between different slice so users are enable to modify the behavior of own virtual network. The suggested solution was based on FlowVisor and SCML. Slice Control and Management Layer (SCML) is used for management and monitoring slices infrastructure operations. I. M. Moraes et al. in [107] suggested FITS, a test-bed for completely isolated virtual network with different QoS. FITS provided the possibility for researchers to choose Xen [108], hypervisor for virtualization with the best performance and high ability to manage resource, or OF to test and perform their experiments. Measurement tools of FITS monitor the state of physical and virtual network that helped administrator to manage and allocate resource optimally.

Cloud and data center
One area that SDN has been attended a lot is Cloud Services and data center. One of the main characteristics of cloud is that users gain the adequate resources based on requirement in real time [109]. Cloud management is the most important challenge that has always been and many solutions have been proposed for that. SDN is highly regarded as one of the newest solutions, which makes it possible to configure and manage cloud and data center easily. In [110] Anderson et.al implemented cloud data center using OF and they found that SDN based implementation is faster and easier to configure because of SDN centralized controller and abstraction management plan. The other challenge of cloud system is maintain costs, that SDN due to centralized location management solve this problem well [5,109]. Oracle SDN is an example of system that virtualizes data center using definition connectivity in software. This system connects virtual machine to other virtual machines and network servers with 70 percent simpler infrastructure. Using Oracle Fabric Manager's interface configuration and monitoring virtual network is possible from any location. It is claimed that the cost of Oracle SDN system compared with legacy network is 50 percent less where as you benefit of up to 80 GB/s server-to-server throughput [111]. Raghavendra et.al in [112] introduce NetGraph, a software architecture to manage SDN based cloud systems. This system is shared graph library and provides a module with a set of API for monitoring and diagnostics cloud system. Hedera which is presented by Al-Fares et al. [113], define Dynamic Flow Scheduling for Data Center Networks using OF. A central scheduler makes it possible to balance load based on active flow state on whole system. In [114] propose cross stratum resilience architecture for OF enabled data center interconnection. Deployment of virtual machines to server is utilized based on service type. Managing resources, degree of their occupation and backup mechanisms are used for resource maintenance. This system is designed for Flexi-Grid optical networks. Hui Yang et.al argued that system has improved end to end responsiveness and optimized resource usage.

Security
Due to centralized architecture of SDN, it used to detect security problem. Supervision of SDN on whole network flow and monitoring behavior of users makes SDN possible to detect attack rapidly and prevent more damage. Many researchers introduced mechanisms to detect Dos and DDos attack -because of flooding based behavior of them. The example of such system is introduced by Junho Suh et.al in [115] that is implemented on NetFPGA-OF platform. Chu et al. in [116] introduced system which uses OF switch on edge to pass only safe traffic which is defined on flow table and LISP (Locator/ID separation protocol) to recognize trusty user In [117] have been explored solutions for scanning-based attack. In that article J. Jafarian et.al introduced OF Random Host Mutation (OFRHM) system which changes real IP of each host with the random virtual IP. With this mechanism fake IP is easily detectable and system prevents large percentage of attacks such as stealthy scanning, worm propagation and etc. OF responsibility is assigned the virtual IP to host frequently. Considering policy based security is another security solution that Xiong Liu et.al in [118] have dealt with. They introduced multilevel security system that prevents information of specific level which gathered by same or lower level host. In designing system is used OF is used to monitor packet and check content so filter packet with security problem. Main idea of Y. Jubaa et.al paper in [119] is to isolate network device dynamically from intra-LAN attack using OF. In suggested architecture IDS component is responsible for detecting attacks and recognizing unsecure devises and inform OF controller. They argue that results have shown this architecture is effective enough on actual LAN. One problem of SDN approach anomaly detection is that when network traffic is high gathering full data from flow table is not efficient so K. Giotis et.al in [120] suggested solution to optimal real time detection system. They combined sFlow [121] and OF and used sampling instead of full flow information and benefited entropy-based algorithm to detect and mitigate anomaly. The authors stated that in low traffic situation performance of system is comparable with native OF architecture.

Wireless and mobile
SDN can be applied in wireless sensor network [122]. Generally, using SDN in WSNs provided the SDN benefits such as flexibility, easier management, optimized resource utilization, etc. The network controllers have the power to set policies to support several applications by utilizing sensor based software defined wireless network. Also this approach would permit using the same sensor nodes for several applications. OF can be used for applying flexible control in Wireless Mesh Networks [123]. This approach benefits both features of Mesh networks and OF which are self-configuration and flexible forwarding, respectively. To apply concepts of abstraction to wireless ad hoc network of smartphone, software defined networking in ad hoc networks [124] was developed. This Hybrid platform has been implemented on Android operating system. The purposed platform is more modular and easier for modification and extension of its components.
Other use case were mentioned in [57] referred the benefit of based SDN, such as Inter-cell interference management and Mobile traffic management. OF could provide seamless handover, dynamic resource management for wireless backhaul, power consumption optimization in mobile backhaul network, Security and Backhaul Optimization and etc. [125].

Challenges
Software defined network and OF have confronted with some challenges. Security needs to be everywhere within SDN: A) architecture and its controller, applications, devices, channels (TLS with plain text) and flow table, B) services (to protect availability), C) connected resources and D) information. Also a robust policy framework in order to check and balance controllers, a recovery, report policy and security deployment is still very much up for grabs. The solutions should be simple to deploy and maintain, cost effective and assuredly secure. A new category called software-defined security (SDSec) which is an example of network functions virtualization (NFV) delivers network security enforcement by separating the security control plane from processing and forwarding planes [126]. Besides security, availability (controllers' existence), flexibility [5], [15], [55], [127], controllers and applications compatibility, link and controller reliability are considerable issues. A centralized controller could recover itself in some processes by using backup flows in a way that is not as faster as it is expected [55]. Capital and operational expenses called CAPEX and OPEX is another challenge debated by OF adapters. Availability and reducing system bottleneck would increase CAPEX, however adapters believe that using software defined network and OF reduce the CAPEX. OPEX in SDN would be decreased by diminishing the number of human based configuration, time and error prone fields [55]. Besides these challenges there are some implementation issues for example having 40+ matching fields in a flow, several tables and their large number of flow entries, instructions and actions, flow level programming and controllers' own way programming that must be considered. Also lack of standard APIs in case of overlapping domain among controllers, necessity of encryption APIs for data plane packets, injection APIs for packet and instantaneous APIs for services like IDS and firewall on a switch, absence of operations in case of absence of controller, existence of other packet format are regarding too [128].

Conclusion
In this survey, we provided an overview of software defined networks. We introduced programmable networks such as SOFTNET, SANE, ForCes, etc. which resulted the SDN paradigm. Then we described the SDN architecture in three layers: control layer, infrastructure layer and application layer. We discussed about the control layer and its different control platforms such as Floodlight, RYU, OpenDaylight, etc., the infrastructure layer, available switches and their capabilities. Also the northbound interfaces and southbound interfaces including different versions of OpenFlow protocol, XMPP and OnePK were described. Wireless architectures such as OpenRoad, SoftRan and SoftCell are also explained. We also described different tools for testing SDN. We compared Mininet, EstiNet and NS3 as SDN simulators and emulators. We discussed different hardware and software tools and test-beds for SDN. At last we introduced SDN applications and research trends such as software defined ICN, virtualization, wireless and mobile networks, cloud and datacenters, multimedia over SDN and the works done on security of SDN . We also point out the existing challenges of using SDN.