NUNES et al:A SURVEY OF SOFTWARE-DEFINED NETWORKING:PAST.PRESENT.AND FUTURE OF PROGRAMMABLE NETWORKS 1623 Leaming PortDown OpenStack Switch Reconciliation Quantum Plugin Firewall VNF Hub Circuit Pusher JAVA API REST API Module Thread Packet Jython Unit Manager Web Ul Pool Streamer Server Tests Device Topology Link Flow Manager Manager/ Discovery Cache Storage Memory Routing Controller Counter Switches PerfMon Trace Memory Store OpenFlow Services Fig.4.The Floodlight architecture as an example of an OpenFlow controller. plane.Though controller-to-controller communication is sor [48].can be used to add a level of network virtualiza- not defined by OpenFlow,it is necessary for any type of tion to OpenFlow networks and allow multiple controllers distribution or redundancy in the control-plane. to simultaneously control overlapping sets of physical A physically centralized controller represents a single switches.Initially developed to allow experimental re- point of failure for the entire network;therefore,Open- search to be conducted on deployed networks alongside Flow allows the connection of multiple controllers to a production traffic,it also facilitates and demonstrates the switch,which would allow backup controllers to take ease of deploying new services in SDN environments. over in the event of a failure. A logically decentralized control plane would be needed Onix [44]and HyperFlow [45]take the idea further in an inter-network spanning multiple administrative do- by attempting to maintain a logically centralized but mains.Though the domains may not agree to centralized physically distributed control plane.This decreases the control,a certain level of sharing may be appropriate look-up overhead by enabling communication with local (e.g.,to ensure service level agreements are met for traffic controllers,while still allowing applications to be written flowing between domains). with a simplified central view of the network.The po- 。Control Granularity tential downside are trade-offs [46]related to consistency Traditionally,the basic unit of networking has been and staleness when distributing state throughout the con- the packet.Each packet contains address information trol plane,which has the potential to cause applications necessary for a network switch to make routing decisions. that believe they have an accurate view of the network However,most applications send data as a flow of many to act incorrectly. individual packets.A network that wishes to provide A hybrid approach,such as Kandoo [47],can utilize local QoS or service guarantees to certain applications may controllers for local applications and redirect to a global benefit from individual flow-based control.Control can controller for decisions that require centralized network be further abstracted to an aggregated flow-match,rather state.This reduces the load on the global controller by than individual flows.Flow aggregation may be based filtering the number of new flow requests,while also on source,destination,application,or any combination providing the data-path with faster responses for requests thereof. that can be handled by a local control application. In a software-defined network where network elements A software-defined network can also have some level of are controlled remotely,overhead is caused by traffic logical decentralization,with multiple logical controllers. between the data-plane and control-plane.As such,using An interesting type of proxy controller,called Flowvi- packet level granularity would incur additional delay asNUNES et al.: A SURVEY OF SOFTWARE-DEFINED NETWORKING: PAST, PRESENT, AND FUTURE OF PROGRAMMABLE NETWORKS 1623 Module Manager Thread Pool Packet Streamer Jython Server Web UI Unit Tests Device Manager Topology Manager/ Routing Link Discovery Flow Cache Storage Memory Switches Controller Memory PerfMon Trace Counter Store Firewall Hub Learning Switch PortDown Reconciliation VNF Circuit Pusher OpenStack Quantum Plugin OpenFlow Services JAVA API Fig. 4. The Floodlight architecture as an example of an OpenFlow controller. plane. Though controller-to-controller communication is not defined by OpenFlow, it is necessary for any type of distribution or redundancy in the control-plane. A physically centralized controller represents a single point of failure for the entire network; therefore, Open￾Flow allows the connection of multiple controllers to a switch, which would allow backup controllers to take over in the event of a failure. Onix [44] and HyperFlow [45] take the idea further by attempting to maintain a logically centralized but physically distributed control plane. This decreases the look-up overhead by enabling communication with local controllers, while still allowing applications to be written with a simplified central view of the network. The po￾tential downside are trade-offs [46] related to consistency and staleness when distributing state throughout the con￾trol plane, which has the potential to cause applications that believe they have an accurate view of the network to act incorrectly. A hybrid approach, such as Kandoo [47], can utilize local controllers for local applications and redirect to a global controller for decisions that require centralized network state. This reduces the load on the global controller by filtering the number of new flow requests, while also providing the data-path with faster responses for requests that can be handled by a local control application. A software-defined network can also have some level of logical decentralization, with multiple logical controllers. An interesting type of proxy controller, called Flowvi￾sor [48], can be used to add a level of network virtualiza￾tion to OpenFlow networks and allow multiple controllers to simultaneously control overlapping sets of physical switches. Initially developed to allow experimental re￾search to be conducted on deployed networks alongside production traffic, it also facilitates and demonstrates the ease of deploying new services in SDN environments. A logically decentralized control plane would be needed in an inter-network spanning multiple administrative do￾mains. Though the domains may not agree to centralized control, a certain level of sharing may be appropriate (e.g., to ensure service level agreements are met for traffic flowing between domains). • Control Granularity Traditionally, the basic unit of networking has been the packet. Each packet contains address information necessary for a network switch to make routing decisions. However, most applications send data as a flow of many individual packets. A network that wishes to provide QoS or service guarantees to certain applications may benefit from individual flow-based control. Control can be further abstracted to an aggregated flow-match, rather than individual flows. Flow aggregation may be based on source, destination, application, or any combination thereof. In a software-defined network where network elements are controlled remotely, overhead is caused by traffic between the data-plane and control-plane. As such, using packet level granularity would incur additional delay as