department of computer science and engineering, indian ...cs5100295/reports/sdn.pdf · a project...
TRANSCRIPT
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.