WIXLIB

2TABLE IE XAMPLE O PEN F LOW- COMPLIANT SWITCHES .Switch lQuantaSeriesArista extensible modular operating system (EOS), Arista 7124FX application switchCiena Coredirector running firmware version 6.1.1Cisco cat6k, catalyst 3750, 6500 seriesJuniper MX-240, T-640HP procurve series- 5400 zl, 8200 zl, 6200 yl, 3500 yl, 6600NEC IP8800Pronto 3240, 3290Toroki Lightswitch 4810Dell Z9000 and S4810Quanta LB4GOpen vSwitchSoftware switch. Latest version: 1.10.0and on proposing methods to improve their performance.OpenFlow offers great opportunities for network innovationbut it also faces challenges. The fact that the availability ofthe network depends on a single controller at a given time,creates scalability and availability problems. There are securityconcerns regarding the fact that all the network information iscontained in one single server. Compatibility issues must alsobe taken into consideration. Questions remain about futuredirections of OpenFlow research as well. We discuss theextension of this technology to network-layer devices such asIP routers, as well as the deployment of OpenFlow in widearea networks (WAN).This survey paper is the first comprehensive document, inour opinion, to discuss the capabilities, applications, deployments and challenges of OpenFlow networks in local andwide area environments. We also describe SDN and alternativestandards such as ForCES [4]. We explain how OpenFlow hasreceived major attention among SDN technologies but we alsopoint out the difference between SDN and OpenFlow.We begin by giving a background of programmable networks and describing SDN in Section II. We explain theOpenFlow specification in Section III. Then we present thecapabilities of OpenFlow networks in Section IV and wesurvey how they have been exploited in different applicationsin Section V. We describe deployments of OpenFlow-basednetworks in Section VI. Next we discuss studies that haveevaluated the performance of OpenFlow in Section VII. Thenwe discuss the challenges faced by OpenFlow in Section VIII.We conclude by proposing future research directions in SectionIX.II. BACKGROUND OF PROGRAMMABLE NETWORKSIn this section we present several contributions to programmable networks prior to SDN and OpenFlow. One of thefirst approaches was SOFTNET [5], an experimental multihoppacket radio network that introduced the idea of adding commands to the contents of each packet. The goal was to modify anetwork node during operation time, using commands writtenin the SOFTNET language. The motivation of the authors increating this network was to enable experiments with differentnetwork protocols. SOFTNET was deployed as a proof ofconcept. There were no further large scale deployments, butthe idea behind it was the motivation for Active Networks [6],[7].The main idea of Active Networks (AN) was to allowpackets to contain programs that could be executed by thenetwork devices that they traversed. The concept of activenetwork is due to the fact that switches perform computationson the data of the packets flowing through them and the userscan inject programs into the network [6]. A survey on ANresearch is available in [8]. Although AN became an activefield of research, it ultimately failed at being widely used.Recently, NetServ [9] was proposed as ActiveNetworks 2.0.The authors argue that NetServ contains all the necessaryelements to be deployed.SOFTNET and ActiveNetworks did not use software components to control the network devices. The programmabilityof the network was achieved by adding source code to thepayload of the packets. More recent approaches proposed separating the control plane from the data plane by moving the firstone to general purpose servers. We describe SoftRouter [10],ForCES [4] and finally we focus on OpenFlow [1]. They areall based on software defined networking architectures, wherethe network devices are controlled by software components.A. Software Defined NetworkingThe difference between SDN and the previous approachesis that a software component running on a server or a CPU isadded to the architecture of the network. In SDN, the softwarecomponent is responsible for the control plane of the network.This is why we say that SDN decouples the control anddata planes, as this distinction was not as clear in previousapproaches.One important feature of SDN is its ability to provide anetwork wide abstraction. Keller et al. [11] discuss the idea ofthe “platform as a service” model for networking. According tothe authors, it is a common trend to decouple the infrastructuremanagement from the service management. In this model, theunderlying physical network and the topology are hidden to theuser. Instead, the abstraction presented to the user is a singlerouter. According to them, the customer is mostly interested inbeing able to configure policies and defining how packets arehandled. We will see during the rest of this survey that a largenumber of publications aim at hiding the complexity of thenetwork and providing an easier way to configure a service.Using names instead of IP addresses, or high level policiesinstead of access control configuration files are examples ofthis abstraction.

3Network operating system is a key concept in SDN. It comesfrom the idea of abstracting the complexity of the underlyingnetwork. Lazar [12] explains how an early approach to programmable networks introduced the term of kernel in terms ofnetworking. The idea was precisely to draw a parallel betweenthe network operating system and the typical operating system.In an operating system, the abstraction includes the hardwarecomponents of the CPU. In a network, the abstraction hidesthe topology and the network devices. Therefore, the networkoperating system is responsible for the abstraction providedby SDN to its users.Another important advantage of SDN is that it enablesinnovation and flexibility. If the control and data plane aremanaged by a hardware network devices, there is little roomfor innovating and experiment, as the software or firmware ofthose devices cannot be easily modified. Instead, by havingaccess to a software component to manage the control plane,many ideas can be explored.compare ForCES and OpenFlow.The IETF documented the differences between ForCES andOpenFlow [16]. According to this document, both standardsdecouple the control and data planes and they both standardizethe communication between the two planes. Regarding thearchitecture of the network, one difference can be found between ForCES and OpenFlow. ForCES defines networking andforwarding elements and how they can communicate with eachother. The architecture of the network remains unchanged.On the other hand, OpenFlow modifies the architecture inthe sense that data plane elements become simple devicesthat forward packets according to rules given by the controlelement. ForCES allows multiple control and data elementswithin

Arista Arista extensible modular operating system (EOS), Arista 7124FX application switch Ciena Ciena Coredirector running firmware version 6.1.1 Cisco Cisco cat6k, catalyst 3750, 6500 series Juniper Juniper MX-240, T-640 HP HP procurve series- 5400 zl, 8200 zl, 6200 yl, 3500 yl, 6600 NEC NEC IP8800 Pronto Pronto 3240, 3290 Toroki Toroki Lightswitch 4810 Dell Dell Z9000 and S4810 Quanta .