Department of Computer Science and Engineering, Indian Institute of Technology, Delhi

Applications of Software Defined Networks in IIT-Delhi Campus Network A Project Report submitted in partial fulfilment of the Requirements for the Degree of Bachelor + Master of Technology Submitted to Department of Computer Science & Engineering, IIT-Delhi Submitted by Shantanu Chaudhary (2010CS50295) Mukesh Kumar (2010CS50288) Under the supervision of Professor Huzur Saran Dr. SC Gupta Department of Computer Science and Engineering, Indian Institute of Technology, Delhi

Abstract Software Defined Networking is fast becoming a new front in computer networking technology. This approach has evolved from the work done at UC Berkeley and Stanford University. It allows network administrators to manage network services through abstraction of lower level functionality. This abstraction is achieved by decoupling the control plane (system that makes routing decisions) from the data forwarding plane (forward to destination). The inventors and vendors of this technology claim that this simplifies the networking. The topic of Software Defined Networking (SDN) has attracted a great deal of attention from service providers, enterprises, and industry associations. In our report, we present the changes needed in the present infrastructure of the network in order to shift from the current networking technology to software defined networking. We also present some example architectures highlighting their usefulness. We also seek to find the applications of this approach if it was to be deployed as a fully functional technology as part of the campus network replacing the current networking picture and try to analyse how it can benefit the users as well as network administrators. The report also presents all the research we did as part of the project to analyse the different SDN controllers as well as the switches needed to operate a network defined by software. We compare different SDN controllers and also explore the newly invented so called Baremetal switches. In the end, we present a set of options, to choose from, in order to expand the applications of SDN. 2

Acknowledgments We would like to thank Professor Huzur Saran, Head of Department, Department of Computer Science & Engineering, Indian Institute of Technology, Delhi for giving us the chance to take minor project under his able supervision. We would also like to thank him for introducing us to the field of Software Defined Networks and developing our interest in computer networks in general. We would also like to thank Dr. SC Gupta, Project Supervisor for enriching our knowledge with his experience and know-how of software defined networks and software systems. Your guidance in studying various SDN deployment architectures (Google, HP) and Baremetal switches gave us the idea of using modular and cost effective switches in the SDN fabric. Finally we would like to thank Apoorv Mohan (Developer, Baadal Cloud Computing Infrastructure), Utkarsh Singh (Developer, Baadal Cloud Computing Infrastructure), and Dushyant Behl (Developer, Baadal Cloud Computing Infrastructure) for your inputs on our work. We are really grateful for adding to our knowledge and deeply value your feedback about our project. 3

Table of Contents Abstract... 2 Acknowledgments... 3 List of Keywords... 5 1. Control Plane... 5 2. Data Plane:... 5 3. SDN:... 5 4. Switch:... 5 5. OpenFlow... 5 6. Controller... 5 7. Northbound APIs... 5 8. Southbound APIs... 5 9. Campus Network:... 5 List of Figures... 6 Ch.1-Introduction... 7 Ch.2-Software Defined Networking... 9 Ch.3-Routing & Forwarding in SDN... 10 Ch.4-Advantages of SDN approach... 11 Ch.5-Applications of SDN for IIT... 12 5.1 Flow Management:... 12 5.2 Configurability:... 12 5.3 Network Firewall:... 13 5.4 Department VLANs:... 13 5.5 Network Policy Management:... 13 5.6 Cloud Computing (Baadal):... 13 5.7 Software Defined Storage (SDS):... 13 Ch.6-Infrastructural Requirements for SDN... 14 Ch.7-Comparison of SDN controllers... 15 Ch.8-SDN Deployment Architecture... 16 Ch.9-SDN Deployment Architecture (Flowvisor)... 17 Ch.10-Summary... 18 Appendix A: OpenFlow... 19 Appendix B: Baremetal Switches... 20 Appendix C: SDN Controllers... 21 References... 22 4

List of Keywords 1. Control Plane: The part of a router which deals with path discovery and routing a packet. 2. Data Plane: The part of a router which deals with forwarding the packet by inspecting the packet headers. 3. SDN: Software Defined Networking. It defines a new approach of computer networking which involves the decoupling of control plane from data plane. 4. Switch: A device that is used to connect devices together on a computer network by performing packet switching. 5. OpenFlow: It is a communications protocol that provides a way to access and configure the forwarding plane of a network switch or router over the network. 6. Controller: A software that is used to manage the forwarding plane of a switch/router via OpenFlow protocol. 7. Northbound APIs: Application Programming Interfaces which are used to communicate between controller and applications/services running over the network. 8. Southbound APIs: Application Programming Interfaces which are used to communicate between controller and switches/routers of the network. 9. Campus Network: It refers to the network that connects the various sectors of the IIT campus. 5

List of Figures Figure 1: SDN Architecture... 9 Figure 2: SDN Controller View Forwarding....10 Figure 3: SDN Routing & Forwarding.9 Figure 4: SDN Applications... 12 Figure 5: Emulated Throughput... 15 Figure 6: Architecture with 1 controller... 16 Figure 7: Architecture with multiple controllers... 17 6

Ch.1-Introduction The conventional architecture of computer networks is based on the use of switches/routers which are in some sense autonomous in their working. The switches/routers when connected to any topology in a computer network perform certain actions (such as constructing a spanning tree) in order to avoid cycles in the network and to know about their neighbouring nodes. Hence they exchange certain messages which enables them to pass the information about their neighbours and the resulting topology to other nodes. Thus, every node has some idea (or complete picture of topology in case of link state algorithms) of the topology in which they are located. Each router consists of two functioning planes: Control Plane and Data Plane. Control Plane: It is the part of router architecture that is concerned with drawing the network topological information. It also means to gather information in a routing table that defines what to do with the incoming packets. Depending upon the router design, there may be different tables for unicast and broadcast mappings. Different implementations have different sets of preferences for routing information, and these are not standardized among IP routers. It is fair to say that subnets on directly connected active interfaces are always preferred. Beyond that, however, there will be differences. Routing protocols specify how routers gather information for the routing tables and talk to their neighbouring routers, disseminating information that enables them to select any two nodes on a computer network. Three major classes of routing protocols that are in widespread use on IP networks: Link-state routing protocols, such as OSPF and IS-IS Distance-vector routing protocols, such as Routing Information Protocol, RIPv2, IGRP Exterior gateway protocols are routing protocols used on the Internet for exchanging routing information between Autonomous Systems, such as Border Gateway Protocol (BGP) Data Plane: This part decides what to do with packets arriving on an inbound interface. Most commonly, it refers to a table in which the router looks up the destination address of the incoming packet and retrieves the information necessary to determine the path from the receiving element, through the internal forwarding fabric of the router, and to the proper outgoing interface(s). These two parts work in combination to define the complete working of a router. But with such complexity, this approach draws certain drawbacks which are as follows: Since the routers need to setup the topology when they are connected (determine neighbouring nodes, spanning tree construction etc.), they need certain processing capability to do this. Thus, they need to be pumped with enough processing power. This in return results in expensive routers/switches. Certain amount of setup time is required to identify loop free topology and the neighbouring nodes. 7

If a certain path on spanning tree goes down, the whole routine of identifying spanning tree will be done again. This again will require certain time expenditure. Hence some time is spent is convergence. The optimisation of route in conventional networks is limited. This is because they require loop free topologies which means they have to prune paths in the graph which can lead to cycles. It is with these shortcomings, concept of Software Defined Networks was introduced. The current campus network uses the conventional approach. Now we would see how software defined networking can help us in overcoming the above shortcomings. 8

Ch.2-Software Defined Networking The idea behind software defined networking is to separate the control plane and data (forwarding) plane. In other words, decoupling the two planes. Now if the functioning of the two planes is kept independent, then we can optimise each plane independently, resulting in an increased efficiency. Let us look at the following figure: Figure 1: SDN Architecture The above figure describes the functional architecture of SDN with respect to hardware and software. In other words, it describes how the control plane and data plane are arranged in the scheme. The control plane now resides at a high level and is part of a software called controller (SDN controller). The hardware (switches/routers) are now left with only the data plane. The controller by means of Southbound APIs (OpenFlow APIs) communicates with the switches and manages their data forwarding plane. On the other hand, the controller has certain Northbound APIs (application APIs), which help the applications running over the network to communicate with the controller which in turn interacts with the switches. Thus, the controller acts as an interface between the applications and switches. The interaction between switch and controller is maintained by certain types of OpenFlow messages. Some of which are as follows (see Appendix A): Controller-to-switch messages: Handshake, Switch Configuration, Flow Table Configuration, Modify State Messages, Queue Configuration Messages, Read State Messages, Packet Messages Asynchronous messages: Packet-In Message, Flow Removed Message, Port Status Message, Error Message Symmetric messages: Hello, Echo Request, Echo Reply, Experimenter Image Courtesy: www.sdncentral.com 9

Ch.3-Routing & Forwarding in SDN Figure 2: SDN Controller View Figure 3: SDN Routing & Forwarding The above two figures give a flavour of how routing and forwarding takes place in a network defined by software. We refer each switch in the above shown topology as a node. Now we see that since we have removed the control plane, each switch/router only knows its connections and not the picture of the whole topology. Whereas, the controller (connected to each and every node in the network) knows the exact picture of the network. Next we refer to figure 3, suppose host X is connected to node E and host Y is connected to node D. Now, if X wants to send some packet to Y, it will send the packet to node E. Node E is unaware of the location of host Y so it queries about the destination of the packet with the controller. Since the controller knows the location of host Y in the network, it will program a flow in the forwarding table of node E which tells E to forward the packet from X to its port connected to node F. Similarly, node F forwards the packet to node C after it queries the outgoing port from the controller based on the incoming port of the packet and the destined host. This procedure is repeated at each node until the packet reaches the destined host. The flows in the nodes can then either be removed or kept as is to allow future communication between hosts X and Y. Thus, we see here the routing decisions are taken by the controller above the hardware level in a software based approach. 10

Ch.4-Advantages of SDN approach SDN offers the following advantages over the conventional networking approach: Since the control plane has been decoupled from the data plane, the switches/routers become very simple in terms of functionality. They only need to forward a packet to a port based upon the flow installed in the data forwarding table by the controller. The switches/routers only need a trivial multiplexing circuit to carry out the packet forwarding. There is no need for significant computation power as in conventional networks. Since only the controller needs to know the topology, significant amount of time can be saved, as the nodes in the network don t need to discover all the other nodes in the network except their neighbours. Optimization of both planes possible independently. Paths need not be pruned between two nodes to avoid cycles. In fact, they can be used to increase throughput of the network or in case of link failures. This approach is easy to scale and no complicated configuration is needed [6]. Most importantly, centralizing the control plane allows forwarding decisions to be made globally across the SDN domain rather than at each hop. 11

Ch.5-Applications of SDN for IIT Determining the applications of SDN in a network depend on various factors such as network topology size, size of user base, throughput required in the network, type of traffic, policy based networking etc. Here we try to answer the question, What benefit does SDN based approach give as compared to the existing networking approach of IIT? Following is a list of applications that can benefit the campus network: 5.1 Flow Management: A flow is defined as an input-output port mapping in the forwarding table of a switch. The current network topology consists of switches with learning switch logic and no control whatsoever over custom mapping of network flows in the forwarding tables. The switches populate their tables based upon the packets they witness and also on the basis of some node discovery logic. SDN controller can add flow rules to the switch tables so that proper switching of packet takes place. The controller can define flow rules with respect to a particular type of packet i.e. it can route certain type of packet and drop the others. The network admin by means of applications (based on Northbound APIs) can re-route traffic if there is a link failure in the network. 5.2 Configurability: The switched network is statically configured. With SDN, the network administrator can dynamically reconfigure the switches in order to adjust traffic flow, bandwidth, flow routes etc. The admin would also not need to take down the switch for reconfiguration. Thus, reconfiguration can be done on the fly dynamically. Figure 4: SDN Applications 12

5.3 Network Firewall: As we mentioned previously, the controller gives us the capability to filter traffic on the basis of flow rules, this capability can be utilised to define a firewall within the switch itself. A firewall application can be programmed using the Northbound APIs which takes feedback (information of packets flowing through the switch) from the controller as well as switches and then filters the packets based upon user defined rules. 5.4 Department VLANs: SDN can be used to efficiently implement department VLANs. VLANs can be implemented with the existing networking infrastructure but SDN offers more features oven the existing networking approach. This is the main motivation for use of SDN in VLAN setup. 5.5 Network Policy Management: Policy management is already implemented in the existing networking approach. But the level of granularity at which this is done is not very low and modular. SDN offers modularity as well as policy at the lowest level of network granularity. The policy management can be restricted to a certain subnet, certain VLAN, link layer, IP layer etc. The existing approach only provides some of these features. 5.6 Cloud Computing (Baadal): After discussion with the Baadal team we came to know that the current build of Baadal allows the user to specify the machine configuration in System Domain (such as RAM, Persistence storage, OS). There is no provision for configuration of parameters in Network Domain (such as QoS, Uplink speed, Downlink speed and so on). Based upon our case study of SDNs in Google as well as Hewlett Packard Datacentres, we can claim that SDN can be used to introduce the feature of Quality of Service, link speeds etc. in the cloud computing infrastructure. 5.7 Software Defined Storage (SDS): Just as in SDN, control plane is decoupled from data plane, SDS is an approach to data storage in which the programming that controls the storage related tasks is decoupled from the physical storage hardware. SDS puts the emphasis on storage services such as deduplication, replication, thin provisioning, snapshots and backup. Without the constraints of a physical system, a storage resource can be used more efficiently and its administration can be simplified through automated policy based management. This approach of storage in conjugation with SDN can be utilised by Baadal as well as network file servers so as to provide flexibility to the network administrator without compromising on services for the user. 13

Ch.6-Infrastructural Requirements for SDN In this section we cover the necessary changes which are needed for basic deployment of software based networking approach. With reference to architecture of SDN approach (see figure 1), we infer that we need to identify the changes in two domains which are as follows: Hardware Domain: In this domain, we need to identify switches which give access to their forwarding tables by means of well-defined APIs, as normal switches provide no interface to access and configure their tables. This need is met by the use of OpenFlow compliant switches (in other words OpenFlow enabled switches). These switches are different from the normal switches in the sense, that they allow access as well as manipulation of entries in their data forwarding tables via OpenFlow APIs. This is same as defining flow rules in the switch, based on which, the switch multiplexes the packets. Baremetal switches are a new breed of highly customizable switches which offer flexibility at a very low cost (see Appendix A). Software Domain: The hardware-software domain interact via OpenFlow communication protocol. SDN controllers or controllers are soft wares that are used to manage and control the flow and data entries in the forwarding tables of the switches. Increasingly, these soft wares are being developed as network operating systems which perform multiple tasks of managing and monitoring the status of hardware and applications running on the network. For the deployment of SDN in campus, we can either choose from existing SDN controllers or we can also develop our own controller which is customised to suit the scale and applications of the campus network. Some examples of SDN controllers are POX, NOX, Beacon, Floodlight etc. Some examples of Networking OS are JUNOS, CISCO IOS, and EXOS etc. 14

Ch.7-Comparison of SDN controllers A case study was done by Open Network Foundation regarding comparison of different prominent SDN controllers in order to determine their performance with respect to throughput and latency. The OpenFlow ecosystem has given rise to numerous controllers in multiple languages (C, C++, Java, Python and Ruby for starters). cbench is a tool used to benchmark performance of controllers. NOX, Beacon, Maestro were tested for throughput. Test methodology: cbench is run locally via loopback, the 4th thread's performance is slightly impacted cbench emulates 32 switches, sending packet-ins from 1 million source MACs per switch 10 loops of 10 seconds each are run 3 times and averaged per thread/switch combination. Figure 5: Emulated Throughput cbench in this test generates flows of the order of millions in number on all the switches. The controller should be able to handle multiple flow insertions/deletions onto the switches. As the number of threads increases, the throughput of the controller should increase. The graph shows that Beacon has the highest throughput out of the other controllers. Also, beacon exhibits a significant increase in throughput when the number of threads are 4. 15

Ch.8-SDN Deployment Architecture SDN deployment can have multiple variants of architectures. The nature of architecture depends upon the scale of network, type of traffic, amount of traffic, nature of network services etc. For the most trivial approach we can have the following architecture for the deployment as shown in the diagram. Figure 6: Architecture with 1 controller In the above figure, each of the blocks in the third layer denotes the switches connecting the respective sections of the campus. For example, Bharti represents the switch connecting Bharti building with the Computer Services Centre (CSC). The core servers and switches which connect the rest of the IIT campus with the outside network (internet) are housed in CSC. The arrows depict the connection links. Despite these links are shown as unidirectional, they are actually representing bi-directional links. In this architecture, there is a single SDN controller which controls the switches in different sections of the campus. The controller runs from CSC (either on a single machine or in a distributed approach) and manages the flow of traffic across all switches. The advantage of this architecture is that it is very simple in terms of deployment scheme. The administrator then just needs to build applications on top of the controller layer. However, this architecture exhibits a fatal flaw of the nature: Single Point of Failure. To overcome this flaw, we propose another architecture. 16

Ch.9-SDN Deployment Architecture (Flowvisor) In the figure below, each of the blocks in the third layer denote the switches connecting the respective sections of the campus. For example, Bharti represents the switch connecting Bharti building with the Computer Services Centre (CSC). The core servers and switches which connect the rest of the IIT campus with the outside network (internet) are housed in CSC. The arrows depict the connection links. Despite these links are shown as unidirectional, they are actually representing bi-directional links. Since in the previous architecture we had a single point of failure (1 controller for the whole topology), we need to connect multiple controllers to the switches in the topology so that if one controller fails, other controllers can take over and support the network. For allowing multiple controllers to connect to the same topology of switches we would need an interface so as to make the interaction between multiple controllers and switches possible. This interface is provided by a software called Flowvisor. Flowvisor itself is a SDN controller which makes it possible for multiple controllers to connect to the same set of switches. Thus, now if our primary controller fails then we have a backup controller to mind the flows in the network. Figure 7: Architecture with multiple controllers 17

Ch.10-Summary We have seen many advantages of SDN but there are a few cautions which we should keep in mind if we are to successfully migrate to network defined by software. OpenFlow protocol: The OpenFlow protocol is in its infancy and is bare bones. However, as deployment shows, it is good enough for many network applications. The poor documentation of the protocol code as well poor tracking makes the development difficult [9]. Fault tolerant OpenFlow controllers: As mentioned in the previous section, multiple controllers provide fault tolerance. Having multiple controllers can give rise to coherency problems (such as selecting primary controller). This requires handling master election and partitioning between the controllers. Partitioning functionality: It is not very clear what functionality should reside in the network devices and what should reside in external controllers. Configuration of functionality resident in the network device remains an open question. Flow programming: For large networks, programming of individual flows can take a long time. This can prove to be a significant time penalty. SDN has generated its whole ecosystem since the inception of this idea. This concept has generated immense curiosity among the members of the computer science community. Various IT companies [reference] are turning to SDN for solution to some very complex problems (such as cloud computing, computation on virtual machines and so on). SDN has a large part to play in the domain of Infrastructure as a Service (IaaS). For the application of SDN in the college campus network, the architecture of the deployment model, type of controller (choose an open source controller or create new one), nature of network services and applications needs to be estimated in order to successfully establish this service. It also necessary to weigh in the cost of transitioning from the current network infrastructure to SDN. If the cost of this transition is more than the cost that can be reclaimed with SDN then the whole model of deployment will not benefit the community. 18

Appendix A: OpenFlow OpenFlow is a communication protocol that define rules to transfer flow to the forwarding plane of a network switch or router over the network. It determine the path of network packets through the network of switches. Some of the feature of OpenFlow are: It allows the switches from different suppliers (no vendor lock-in). It allows remote administration of a switch s packet forwarding table by adding, modifying and removing packet matching rules and actions. Packets which are unmatched by the switch are forwarded to the controller. Controller decide to modify existing flow table rules or create new rules. Controller can divert/forward the traffic itself. It is layered on the top of TCP and uses TLS. The Open Networking Foundation (ONF) manages the OpenFlow standard, defines it as the first standard communication interface defined between the controls and forwarding layers of an SDN architecture. Its first version 1.1 was released on February 28, 2011. The current version of OpenFlow is 1.4. After ONF, many other companies start taking interest in SDN. In June 2012, Infoblox released LINC, an open-source OpenFlow version 1.2 and 1.3 compliant software switch. In February 2012, Big Switch Networks released Project Floodlight, an Apache-licensed open-source software OpenFlow Controller. Following sub-section gives a brief account of the type of OpenFlow messages that are exchanged between the controller and the switch. The protocol consists of three types of messages: controller-to-switch, asynchronous and symmetric: Controller-to-switch messages are sent by the controller to: Specify, modify or delete flow definitions Request information on switch capabilities Retrieve information like counters from the switch Send a packet back to a switch for processing after a new flow is created Asynchronous messages are sent by the switch to: Send the controller a packet that does not match an existing flow Inform the controller that a flow has been removed because it s time to live parameter or inactivity timer has expired Inform the controller of a change in port status or that an error as occurred on the switch Symmetric messages can be sent by both the switch and the controller and are used for: Hello messages exchanged between controller and switch on start-up Echo messages used to determine the latency of the controller-to-switch connection and to verify that the controller-to-switch connection is still operative Experimenter messages to provide a path for future extensions to OpenFlow technology 19

Appendix B: Baremetal Switches SDN works on the basis of decoupling of control plane and data plane. Traditional network have both control plane and data plane in a single router/switch. Supporting new protocols and traditional protocols on one hardware is hard. Now we need special hardware which support only data plane (OpenFlow compliant switches). Baremetal switches are hardware without software. In other words, they can be loaded with a suitable firmware (software) and can be used just like any other switch. Big Switch Technologies first introduced the idea of Baremetal switches. These switches can be booted with firm wares of different specifications in order to meet the requirement of the application for which the switch is required. Since, they can be flashed and booted with such custom firm wares, they offer high customizability at a low cost. Advantages of Baremetal Switches over traditional switches Faster Innovation: it enables software-speed design. There is no need to virtualize the ASIC tables. No vendor lock-in: allow the switches from different suppliers. Surprisingly inexpensive: its price is very low as compared to traditional switches. However, these type of switches are relatively new to the market. As a result, the number of vendors is low. But they are a viable alternative to traditional as well as OpenFlow switches. 20

Appendix C: SDN Controllers An SDN controller is an application in software-defined networking (SDN) that manages flow control to enable intelligent networking. SDN controllers are based on protocols, such as OpenFlow, that allow servers to tell switches where to send packets. The controller is the core of an SDN network. It lies between network devices at one end and applications at the other end (see Figure 1). Any communications between applications and devices have to go through the controller. The controller also uses protocols such as OpenFlow to configure network devices and choose the optimal network path for application traffic. Vendors of SDN controllers include Big Switch Networks, HP, IBM, VMWare and Juniper. Open Source Controllers Beacon Floodlight NOX and POX Maestro Trema Ryu Open Daylight Closed Source / Commercial Controllers: Big Network Controller ProgrammableFlow ONIX Details of some SDN controllers 1. Floodlight- Floodlight is the core of a commercial controller product from Big Switch Networks. The Floodlight Open SDN Controller is an enterprise-class, Apachelicensed, Java-based OpenFlow Controller. 2. Beacon-Beacon is a fast, cross-platform, modular, Java-based OpenFlow controller that supports both event-based and threaded operation. 3. Pox-it s a platform for the rapid development and prototyping of network control software using Python [13]. 4. Maestro-Maestro is an "operating system" for orchestrating network control applications. A scalable control platform written in Java which supports OpenFlow switches [9]. 21

References [1] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma and S. Banerjee, DevoFlow: scaling flow management for high-performance networks, in SIGCOMM '11, New York,NY, 2011. [2] W. Kim and P. Sharma, HERCULES: Integrated Control Framework for Datacenter Traffic Management, in Network Operations and Management Symposium (NOMS), Maui,HI, 2012. [3] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown and S. Shenker, Ethane: Taking Control of the Enterprise, in SIGCOOMM '07, New York,NY, 2007. [4] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenkar and J. Turner, OpenFlow: Enabling Innovation in Campus Networks, ACM SIGCOMM, vol. 38, no. 2, pp. 69-74, 2008. [5] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis, P. Sharma, S. Banerjee and N. McKeown, ElasticTree: Saving Energy in Data Center Networks, in NSDI'10, Berkeley,CA, 2010. [6] M. R. Nascimento, C. E. Rothenberg, M. R. Salavador, C. N. A. Correa, S. C. de Lucena and M. F. Magalhaes, Virtual Routers as a Service: The RouteFlow Approach, in CFI '11, New York,NY, 2011. [7] C. E. Rothenberg, M. R. Nascimento, M. R. Salvador, C. N. A. Correa, S. C. de Lucena and R. Raszuk, Revisiting Routing Control Platforms with the Eyes and, in HotSDN '12, New York,NY, 2012. [8] A. Tootoonchian and Y. Ganjali, HyperFlow: A Distributed Control Plane for OpenFlow, in INM/WREN'10, Berkeley, CA, 2010. [9] Z. Cai, A. L. Cox and T. E. Ng, Maestro: Balancing Fairness, Latency and Throughput in, Houston,TX: Rice University Technical Report, 2011. [10] W. Kim, P. Sharma, J. Lee, S. Banerjee, J. Tourrilhes, S.-J. Lee and P. Yalagandula, Automated and Scalable QoS Control for Network Convergence, in INM/WREN'10, Berkeley, CA, 2010. [11] C. Monsanto, J. Reich, N. Foster, J. Rexford and D. Walker, Composing softwaredefined networks, in NSDI'13, Berkeley, CA, 2013. [12] C. Wang, A Geek's Page, 20 October 2012. [Online]. Available: http://wangcong.org/blog/archives/2131. [13] POX Wiki, [Online]. Available: https://openflow.stanford.edu/display/onl/pox+wiki#poxwiki-installingpox. 22

[14] S. McGillicuddy, Not all OpenFlow hardware is created equal: Understanding the options, 25 September 2013. [Online]. Available: http://searchsdn.techtarget.com/news/2240206058/not-all-openflow-hardware-iscreated-equal-understanding-the-options. [15] What s Software-Defined Networking (SDN)?, SDN Centra, [Online]. Available: http://www.sdncentral.com/what-the-definition-of-software-defined-networking-sdn/. [16] J. Stretch, What the Hell is SDN?, PacketLife.net, 2 May 2013. [Online]. Available: http://packetlife.net/blog/2013/may/2/what-hell-sdn/. [17] SDN: TRANSFORMING NETWORKING TO ACCELERATE BUSINESS AGILITY, Open Net Summit (ONS), [Online]. Available: http://www.opennetsummit.org/why-sdn.html. [18] Northbound API guide: The new network application, SearchSDN, [Online]. Available: http://searchsdn.techtarget.com/guides/northbound-api-guide-the-rise-ofthe-network-applications. [19] B. Kleyman, Software-Defined Networking's 3 Biggest Benefits, Network Computing, 12 February 2014. [Online]. Available: http://www.networkcomputing.com/networking/software-defined-networkings-3- biggest-benefits/a/d-id/1113808. [20] R. Le Maistre, Google: SDN Works for Us, LightReading, 23 October 2012. [Online]. Available: http://www.lightreading.com/carrier-sdn/sdn-architectures/google-sdnworks-for-us/d/d-id/699197. [21] N. W. Staff, Is Cisco getting squeezed by SDNs?, Networld World, 20 June 2012. [Online]. Available: http://www.networkworld.com/research/2012/061912-is-ciscogetting-squeezed-by-260339.html. [22] G. Ferro, Cisco's ONE Controller Debuts; Targets SDN, Network Computing, 4 February 2013. [Online]. Available: http://www.networkcomputing.com/datacenters/ciscos-one-controller-debuts-targets-sdn/a/d-id/1234066?. [23] B. Salisbury, The CISCO ONE SDN Controller, Network Static, 12 April 2013. [Online]. Available: http://networkstatic.net/the-cisco-one-sdn-controller/. [24] S. McGillicuddy, Bare metal switches: Will merchant silicon take over networking?, Search Networking, December 2313. [Online]. Available: http://searchnetworking.techtarget.com/opinion/bare-metal-switches-will-merchantsilicon-take-over-networking. [25] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKeown and G. Parulkar, FlowVisor: A Network Virtualization Layer, Deutsche Telekom Inc. R&D Lab, Stanford University, 2009. 23