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

2

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.

3

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.

4

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

5

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.

6

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

7

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.

8

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.

9

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

10

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.

11

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.

12

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

13

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.

14

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.

15

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.

16

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.

17

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

18

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.

19

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

20

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.

21

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, Apache-

licensed, 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].

22

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 software-

defined 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.

23

[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-is-

created-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-of-

the-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-sdn-

works-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-cisco-

getting-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/data-

centers/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-merchant-

silicon-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.