NUNES et al:A SURVEY OF SOFTWARE-DEFINED NETWORKING:PAST.PRESENT.AND FUTURE OF PROGRAMMABLE NETWORKS 1625 TABLE I CURRENT SOFTWARE SWITCH IMPLEMENTATIONS COMPLIANT WITH THE OPENFLOW STANDARD. Software Switch Implementation Overview Version Open vSwitch [55] C/Python Open source software switch that aims to implement a switch platform w1.0 in virtualized serve Supports standard managem interfaces and enables programmatic extension and control of the forwarding functions.Can be ported into ASIC switches. Pantou/OpenWRT [56] Tums a commercial wireless router or Access Point into an OpenFlow-enabled switch. vLO C7C++ OpenFlow 1.3 compatible user-space software switch implementation. v.3 Indigo [58] Open source OpenFlow implementation that runs on physical switches and uses vI0 the hardware features of Ethernet switch ASICs to run OpenFlow. protocol.As the control plane abstracts network applications TABLE II from underlying hardware infrastructure,they focus on stan- MAIN CURRENT AVAILABLE COMMODITY SWITCHES BY MAKERS, COMPLIANT WITH THE OPENFLOW STANDARD. dardizing the interfaces between:(1)network applications and the controller (i.e.northbound interface)and(2)the controller Maker Switch Model I Version and the switching infrastructure (i.e.,southbound interface) Hewlett-Packard 8200zL.6600.6200zL, vI.0 which defines the OpenFlow protocol itself.Some of the Study 5400zL.and3500/3500yl rocade Netlron CES 2000 Series v1.0 Groups (SGs)of ITU's Telecommunication Standardization IBM RackSwitch G8264 v1.0 Sector (ITU-T)[49]are currently working towards discussing P5240PF5820 v1.0 onto 3290and3780 v1.0 requirements and creating recommendations for SDNs under uniber Junos MX-Series vLO different perspectives.For instance,the SG13 focuses on P53290.P-295,P-3780andP39201 v1.2 Future Networks,including cloud computing,mobile and next generation networks,and is establishing requirements for network virtualization.Other ITU-T SGs such as the SG11 for protocols and test specifications started,in early 2013, protocols can first be developed and tested on an emulation requirements and architecture discussions on SDN signaling. of the anticipated deployment environment before moving to The Software-Defined Networking Research Group (SDNRG) the actual hardware.By default Mininet supports OpenFlow at IRTF [50]is also focusing on SDN under various perspec- v1.0,though it may be modified to support a software switch tives with the goal of identifying new approaches that can be that implements a newer release. defined and deployed,as well as identifying future research The ns-3 [54]network simulator supports OpenFlow challenges.Some of their main areas of interest include switches within its environment,though the current version solution scalability,abstractions,security and programming only implements OpenFlow v0.89. languages and paradigms particularly useful in the context of SDN. B.Available Software Switch Platforms These and other working groups perform important work, There are currently several SDN software switches available coordinating efforts to evolve existing standards and proposing that can be used,for example,to run an SDN testbed or when new ones.The goal is to facilitate smooth transitions from developing services over SDN.Table I presents a list of current legacy networking technology to the new protocols and archi- software switch implementations with a brief description in- tectures,such as SDN Some of these groups,such as ITU-T's cluding implementation language and the OpenFlow standard SG13,advocate the establishment of a Joint Coordination Ac- version that the current implementation supports. tivity on SDN (JCA-SDN)for collaboration and coordination between standardizing efforts and also taking advantage of the C.Native SDN Switches work performed by the Open Source Software (OSS)commu- One of the main SDN enabling technologies currently being nity,such as OpenStack [51]and OpenDayLight [52]as they implemented in commodity networking hardware is the Open- start developing the building blocks for SDN implementation. Flow standard.In this section we do not intend to present a detailed overview of OpenFlow enabled hardware and makers, IV.SDN DEVELOPMENT TOOLS but rather provide a list of native SDN switches currently SDN has been proposed to facilitate network evolution and available in the market and provide some information about innovation by allowing rapid deployment of new services and them,including the version of OpenFlow they implement. protocols.In this section,we provide an overview of currently One clear evidence of industry's strong commitment to SDN available tools and environments for developing SDN-based is the availability of commodity network hardware that are services and protocols. OpenFlow enabled.Table II lists commercial switches that are currently available,their manufacturer,and the version of OpenFlow they implement. A.Emulation and Simulation Tools Mininet [53]allows an entire OpenFlow network to be D.Available Controller Platforms emulated on a single machine,simplifying the initial develop- Table III shows a snapshot of current controller implemen- ment and deployment process.New services,applications and tations.To date,all the controllers in the table support theNUNES et al.: A SURVEY OF SOFTWARE-DEFINED NETWORKING: PAST, PRESENT, AND FUTURE OF PROGRAMMABLE NETWORKS 1625 TABLE I CURRENT SOFTWARE SWITCH IMPLEMENTATIONS COMPLIANT WITH THE OPENFLOW STANDARD. Software Switch Implementation Overview Version Open vSwitch [55] C/Python Open source software switch that aims to implement a switch platform v1.0 in virtualized server environments. Supports standard management interfaces and enables programmatic extension and control of the forwarding functions. Can be ported into ASIC switches. Pantou/OpenWRT [56] C Turns a commercial wireless router or Access Point into an OpenFlow-enabled switch. v1.0 ofsoftswitch13 [57] C/C++ OpenFlow 1.3 compatible user-space software switch implementation. v1.3 Indigo [58] C Open source OpenFlow implementation that runs on physical switches and uses v1.0 the hardware features of Ethernet switch ASICs to run OpenFlow. protocol. As the control plane abstracts network applications from underlying hardware infrastructure, they focus on stan￾dardizing the interfaces between: (1) network applications and the controller (i.e. northbound interface) and (2) the controller and the switching infrastructure (i.e., southbound interface) which defines the OpenFlow protocol itself. Some of the Study Groups (SGs) of ITU’s Telecommunication Standardization Sector (ITU-T) [49] are currently working towards discussing requirements and creating recommendations for SDNs under different perspectives. For instance, the SG13 focuses on Future Networks, including cloud computing, mobile and next generation networks, and is establishing requirements for network virtualization. Other ITU-T SGs such as the SG11 for protocols and test specifications started, in early 2013, requirements and architecture discussions on SDN signaling. The Software-Defined Networking Research Group (SDNRG) at IRTF [50] is also focusing on SDN under various perspec￾tives with the goal of identifying new approaches that can be defined and deployed, as well as identifying future research challenges. Some of their main areas of interest include solution scalability, abstractions, security and programming languages and paradigms particularly useful in the context of SDN. These and other working groups perform important work, coordinating efforts to evolve existing standards and proposing new ones. The goal is to facilitate smooth transitions from legacy networking technology to the new protocols and archi￾tectures, such as SDN Some of these groups, such as ITU-T’s SG13, advocate the establishment of a Joint Coordination Ac￾tivity on SDN (JCA-SDN) for collaboration and coordination between standardizing efforts and also taking advantage of the work performed by the Open Source Software (OSS) commu￾nity, such as OpenStack [51] and OpenDayLight [52] as they start developing the building blocks for SDN implementation. IV. SDN DEVELOPMENT TOOLS SDN has been proposed to facilitate network evolution and innovation by allowing rapid deployment of new services and protocols. In this section, we provide an overview of currently available tools and environments for developing SDN-based services and protocols. A. Emulation and Simulation Tools Mininet [53] allows an entire OpenFlow network to be emulated on a single machine, simplifying the initial develop￾ment and deployment process. New services, applications and TABLE II MAIN CURRENT AVAILABLE COMMODITY SWITCHES BY MAKERS, COMPLIANT WITH THE OPENFLOW STANDARD. Maker Switch Model Version Hewlett-Packard 8200zl, 6600, 6200zl, v1.0 5400zl, and 3500/3500yl Brocade NetIron CES 2000 Series v1.0 IBM RackSwitch G8264 v1.0 NEC PF5240 PF5820 v1.0 Pronto 3290 and 3780 v1.0 Juniper Junos MX-Series v1.0 Pica8 P-3290, P-3295, P-3780 and P-3920 v1.2 protocols can first be developed and tested on an emulation of the anticipated deployment environment before moving to the actual hardware. By default Mininet supports OpenFlow v1.0, though it may be modified to support a software switch that implements a newer release. The ns-3 [54] network simulator supports OpenFlow switches within its environment, though the current version only implements OpenFlow v0.89. B. Available Software Switch Platforms There are currently several SDN software switches available that can be used, for example, to run an SDN testbed or when developing services over SDN. Table I presents a list of current software switch implementations with a brief description in￾cluding implementation language and the OpenFlow standard version that the current implementation supports. C. Native SDN Switches One of the main SDN enabling technologies currently being implemented in commodity networking hardware is the Open￾Flow standard. In this section we do not intend to present a detailed overview of OpenFlow enabled hardware and makers, but rather provide a list of native SDN switches currently available in the market and provide some information about them, including the version of OpenFlow they implement. One clear evidence of industry’s strong commitment to SDN is the availability of commodity network hardware that are OpenFlow enabled. Table II lists commercial switches that are currently available, their manufacturer, and the version of OpenFlow they implement. D. Available Controller Platforms Table III shows a snapshot of current controller implemen￾tations. To date, all the controllers in the table support the