1

TLEN-5710

Capstone Research Paper

Date – 04/25/2014

Software Defined Networking in the Clouds

Members – Siddharth Bali, Shankar Shivram, Srinivas Lakshminarayan, Rohith Vardha

Faculty Advisor – Dr. Eric Keller

Industry Advisor – Mr. Kevin McBride (Principal Architect, CenturyLink)

2

Abstract

Dynamic nature of cloud services requires server virtualization to be administered in real time

utilizing network virtualization. Software Defined Networking is the new paradigm of networking, which

uses a centralized controller to control the flow of packets in the data plane. This new approach makes

network management easier and has ability to save costs for the organization. There has been significant

advancement in cloud computing technologies, which has led to the development of cloud management

tools like OpenStack (An Open source Infrastructure as a Service (IaaS) cloud computing project).

OpenStack uses Neutron (formerly Quantum), which is networking component to provide network

virtualization. Neutron in its early stages of development provides limited functionality when compared to

traditional networking infrastructure. In this paper, we analyze the current scenario of different OpenStack

distributions and SDN controllers. We use already available integration solutions of SDN controllers into

OpenStack and test their functionality and usability based on defined parameters. The paper also discusses

the results of the business survey to know the industry and community opinion of SDN with OpenStack.

The paper uses results from business survey and test cases to provide insight on prominent topics like

barriers to SDN adoption, budget allocation, OpenStack distributions and SDN controllers. The achieved

results help us to assess the production readiness of the SDN with OpenStack as an IaaS solution.

3

Table of Contents

Abstract ......................................................................................................................................................................... 2

1. Introduction ........................................................................................................................................................... 5

1.1 Research Question .............................................................................................................................................. 6

2. Literature Review ..................................................................................................................................................... 6

2.1 OpenStack ........................................................................................................................................................... 6

2.2 Functionality of Neutron ..................................................................................................................................... 8

2.3. SDN and its Integration with OpenStack ........................................................................................................... 9

2.4. Contribution to the State-of-the-art .................................................................................................................. 11

3. Research Methodology ....................................................................................................................................... 11

4. Research Results ................................................................................................................................................. 15

5. Discussion of Results .......................................................................................................................................... 21

6. Conclusion ............................................................................................................................................................. 22

4

List of Figures and Tables

Figure 1: OpenStack Architecture [8].........................................................................................................7

Figure 2: Neutron and SDN Integration with Agents [4]………………………………………………...9

Figure 3- SDN Integration into OpenStack [4]…………………………………………………………..10

Figure 4 – SDN integration into OpenStack (Test Bed)………………………………………………...13

Figure 5: Future of SDN with OpenStack (Business Survey)…………………………………………..15

Figure 6: Participant choice of OpenStack distribution (Business Survey)…………………………….16

Figure 7: Participant’s choice of SDN Controller (Business Survey)…………………………………..17

Figure 8: Participants insight to SDN and Neutron Future (Business Survey)…………………………17

Figure 9: Features enhanced by SDN in OpenStack (Business Survey)………………………………..18

Figure 10: Barriers to SDN adoption (Business Survey)……………………………………………….18

Figure 11: Acceptance of SDN in production network (Business Survey)…………………………….19

Figure 12: Budget Allocation towards SDN deployement (Business Survey)………………………….19

Table 1 Test Environment Specifications ………………………………………………………………13

Table 2 Data Plane Test Cases ………………………………………………………………………….14

Table 3 Functionality Test Cases………………………………………………………………………..14

Table 4 - Comparison of different OpenStack distributions…………………………………………… 15

Table 5 - SDN Controllers Comparison…………………………………………………………………16

Table 6 Data Plane Test Results………………………………………………………………………. .20

Table 7 Functionality Test Results………………………………………………………………………20

5

1. Introduction

Cloud Computing has gained popularity in the recent years and is evolving at a fast pace [1]. The

flexibility and dynamic services offered by this technology is the main reason for its high adoption rates

[1]. It is also a cost efficient technology that is easy to maintain and upgrade, which is attracting

companies of all sizes [1]. Cloud computing has also gained a significant amount of attention from the

research community with the advent of OpenStack [1]. OpenStack is open source cloud management

software that enables its users to manage cloud infrastructure thereby providing Infrastructure as a Service

(IaaS) [1]. OpenStack is a collection of modules when used together gives the ability to control large

pools of compute (Nova), storage (Cinder & Swift) and networking (Neutron) resources [2]. Horizon

(Dashboard) and API Communication are used to manage OpenStack modules [2].

Neutron is designed to provide “networking as a service” between virtual devices (vNICs)

managed by other OpenStack projects [1]. Neutron enables the tenants to create virtual networks and

manage them [2]. It also provides standardized plugin architecture that facilitates integrating SDN

controllers [3]. Neutron does not scale well to keep up with the dynamic nature of virtualized environment

and provides limited control over network resources [4]. SDN provides additional features to Neutron

such as centralized control, seamless networking, Multi-tenancy, and network scalability [5] [6].

However, there is a lack of proper resources and knowledge to evaluate the integration of SDN

controllers into OpenStack. Consequently, this has led to confusion in the market about the promised

benefits of SDN in OpenStack.

The rest of the paper is organized as follows Section II discusses Literature Review. Section III

describes the Research Methodology. Section IV discusses achieved results. Section V provides Result

discussions, and Section VI concludes the paper by explaining the future scope for research.

6

1.1. Research Question

Based on the problem setting, the research question for this capstone is

"Can SDN and OpenStack together drive the future of Infrastructure as a Service (IaaS)?"

We divide the research question into three subproblems

1) What is the optimal available solution of SDN’s integration into OpenStack?

2) Determine the industry and community opinion of SDN & OpenStack.

3) Does the performance and functionality of SDN into OpenStack meet the requirements of the industry?

2. Literature Review

2.1. OpenStack

OpenStack is open source cloud management software launched by Rackspace and NASA in July

2010. It is a collection of innovative software projects that when used in unison, creates and provides a

framework for quickly provisioning, and managing virtual devices in the cloud (public and private),

essentially acting as Infrastructure as a Service (IaaS) [1] [7].

All the services collaborate to offer flexible and scalable cloud solution using Application Programming

Interface (API) [4] [8]. It also has many projects in incubation stages that are developed and published in

stages with contributions from the communities.

The important nine modules (as shown in Figure: 1) of OpenStack are as follows.

Nova (Compute): It provides the virtual servers/machines for the cloud users on demand [8].

Neutron (Networking): It provides Networking as a Service (Virtual Networking services)

between interface devices managed by OpenStack Compute [8].

7

Figure 1: OpenStack Architecture [8]

Object Storage (Swift): It allows storing and retrieving of data (images, files and documents) in

virtual containers [8].

Block Storage (Cinder): It provides persistent block storage to the guest (user) Virtual Machines

(VM) [8].

Image (Glance): It provides a list of virtual disk images to the Compute node that is utilized by the

Virtual Machines [8].

Dashboard (Horizon): This component of OpenStack provides a web-based Graphic User

Interface (GUI) for managing the OpenStack by the cloud administrator and tenants (users) [8].

8

Identity (Keystone): It stores the information for providing authentication and authorization for the

OpenStack services [8].

Celiometer: It monitors and measures the OpenStack cloud usage for the purpose of billing,

benchmarking, and statistics purposes [8].

Heat: It provides an orchestration service for managing the cloud applications by using

appropriate API calls [8].

2.2 Functionality of Neutron

Neutron adds a layer of virtualized network services providing the tenants (users) the capability to

architect their own virtual networks. Neutron can be considered as virtualization of networks, which can

be moved from one location to another without affecting the existing connection [4]. It can be further

explained as a network management service that exposes an extensible set of APIs (Application

Programmable Interface) for creating and managing virtual networks (virtual network are created to

provide networking capability between virtual machines managed by OpenStack Compute) [9]. Using an

API centric networking service, the tenants and administrators can follow best practices to secure physical

and virtual networks. Neutron has a plug-in architecture that provides capabilities of APIs via open source

community or third-party services [4] [8]. Neutron also allows innovative plug-ins to provide advanced

network capabilities, which can be added and researched by the vendors/providers [4].

Currently, virtualized network services in Neutron are not as mature as their traditional networking

counterparts [4]. The Figure below describes the agents that interact with Neutron Component. Neutron

comprises of following elements -

Neutron-server, a python daemon, is the main process of the OpenStack Networking that runs on a

network node [4].

Plugin agents communicate with neutron plugin to manage the virtual switch. The plugin agents will

depend on the neutron plugin being used [4].

9

DHCP agent, a part of Neutron, provides DHCP services to tenant networks. This agent maintains the

required DHCP configuration and is same across all the plugins [4].

L3 agent: This agent is responsible for providing Layer 3 and NAT forwarding to gain external access

for virtual machines on tenant networks [4].

SDN services: These services provide additional networking capabilities to tenant networks. The

services can interact with plugin agents or neutron-sever via API communication [4].

Figure 2: Neutron and SDN Integration with Agents [4]

The features provided by neutron fall short when it comes to scaling massive high-density, multi-

tenant cloud environments [4]. Neutron does not scale well to keep up with the dynamic nature of the

cloud environment [4] [8]. OpenStack Neutron provides with the functionality of plugins to integrate

SDN controllers into the OpenStack with the end goal of freeing the applications from being aware of

networking details such as IP addresses, VLAN's and ports, save time and reducing operational costs [10].

2.3. SDN and its Integration with OpenStack

Software Defined Networking is introduced to overcome the deficiencies of Neutron. SDN is a

network technology that allows centralized programmable control plane to manage the entire data plane,

10

so that the network operators and providers can control and manage their own virtualized resources and

networks [12]. SDN is a new networking model that allows open API communication between the

hardware and the operating system, and also between network elements (Physical and Virtualized) and

operating system [11].

In the SDN model a Network Operating System (NOS) such as Open Daylight, RYU, Floodlight,

POX is responsible for providing a complete view of the network and its current state [11]. The NOS is

also responsible for managing the changes to the network and transferring those changes both to the

network hardware and to the network (physical and Virtual) applications [11]. The change to the

underlying network comes from network applications (Neutron API, REST/JSON, Java RPC) running on

top of NOS using the Northbound API for communication [11]. The NOS manages and controls the

underlying hardware (Physical & Virtual) via Southbound APIs using protocols like OpenFlow, OVSDB,

OF-config, XMPP [11].

Integration of SDN Controller into Neutron using plug-ins provides centralized management and

also facilitates network programmability of OpenStack Networking using APIs [11][12]. SDN Controllers

like OpenDaylight, Ryu, and Floodlight, etc. use respective plugins that allow communication between

Neutron and SDN Controller [13].The Figure 3 below gives a general idea about the integration of SDN

Controller into OpenStack.

Figure 3- SDN Integration into OpenStack [4]

11

OpenDaylight interacts with neutron by using Modular Layer-2(ML2) plugin present on the network node

(neutron) via Rest API using northbound communication [13]. RYU utilizes RYU plugin present on the

neutron node that interacts with the RYU controller via Northbound API using REST API, and uses an

RYU agent on the compute nodes to communicate with the RYU plugin [14]. Both OpenDaylight and

RYU utilize Open vSwitch Database (OVSDB) and openflow for southbound API communication to the

virtual switches on the compute (nova) nodes [13] [14].

2.4. Contribution to the State-of-the-art

This research will allow evaluating production readiness of SDN integration into OpenStack as

there is less resources (limited documentation and limited bug support) in the market. Through this work,

we tried to analyze which distribution of OpenStack works best with selected SDN controllers. Using the

technical and business results, our capstone provides a comprehensive solution that will help the users

evaluate their SDN and OpenStack requirements.

3. Research Methodology:

We answer the three research subproblems, which together help answer our main research

question. We solve the subproblems following a two pronged approach.

First we setup our own test-bed by deploying OpenStack Infrastructure both standalone and with SDN

controller and evaluate the performance and functionality. It provides us with enough depth to answer

sub-problem 1 and 3.

Second we conduct a business survey whose participants are members of OpenStack & SDN community,

to help us understand the industry’s opinion on the two evolving technologies.

Following the answers from the sub-problem gives us sufficient depth and breadth of knowledge to arrive

at a conclusion that answers our research question.

12

The following are the major components of our test-bed:

i) OpenStack distribution

ii) SDN Controller

iii) Hardware (Servers, Switch)

To choose an OpenStack distribution for our research we performed tests based on the following

parameters:

Ease of installation

Scalability

Openness

Community Support

Online Documentation

Cost Factor

After selecting the suitable distribution, we deployed a multi node OpenStack infrastructure

having compute node on one server, and controller, neutron, nova components, glance, on another server.

We allocated resources (RAM, Storage, CPU) based on the functionality of the nodes.

For selecting an SDN controller to integrate with our selected OpenStack distribution we

researched on the following parameters:

Open source

Language of implementation

Ease of use (GUI)

Platform support

OpenFlow Version

OpenStack Neutron plugin

Support &

Industry Backing

Based on the results from above we develop the test-bed as shown in the Figure 4 [15] following

specifications in Table 1

13

We used VMware ESXi host to deploy Havana Edition of OpenStack on Controller and Compute Nodes.

Node CPU Memory Storage

Controller 2 Virtual CPU 5 GB 80 GB

Compute 2 Virtual CPU 6 GB 80 GB

Table 1 Test Environment Specifications

Figure 4 – SDN integration into OpenStack (Test-bed)

In order to answer our second research subproblem, we conducted business survey to understand

the state of SDN and OpenStack in the industry. We used a survey tool “SoGo Survey” and posted the

survey links on Social Media Websites (Facebook & LinkedIn) and contacted industry experts. We also

interviewed industry experts on SDN and OpenStack to know about the present and future trends and

utilized data-analytics tools to infer the survey results.

14

To answer the third subproblem of the research question i.e., to verify if performance and

functionality of SDN Controller with OpenStack satisfies the industry’s requirement; we followed a series

of test cases for validating and evaluating the integration [16]. The test cases are as shown below in Table

Data Plane Test Cases [16]:

Test Case Tool Used

Average flow setup latency Ping

Average steady-state latencies (ms) Broadcast flood ping

Max TCP unicast through under varying MSS

(Throughput Test) Iperf

UDP under varying number of parallel sessions

(Throughtput Test)

Iperf

Max allowed TCP flows

(Max Allowed Flows)

Hping

Table 2: Data Plane Test Cases

Functionality Test Cases [16]:

Test Case Tool Used

Layer 3 Functionality Test

(Automatic Layer 3 domain discovery)

Ping using Virtual Router

VM-Migration Tests

( VM moment without drop)

Manual Testing

Fault-Tolerance Tests

(Connection between two VM’s with Controller Disconnected)

Manual Testing

Stress Tests

( Increase Number of VM instances and random VM

creation)

Manual Testing

Table 3: Functionality Test Case

15

4. Research Results:

When asked about our research question participants of our business survey (Figure 5) believe that

OpenStack and SDN will together drive the future of Infrastructure as a service (IaaS).

Figure 5: Future of SDN with OpenStack (Business Survey)

To determine the answer for the first subproblem, we compared different OpenStack distributions

based on predefined parameters. Table 4 below shows our results of the evaluation for available

OpenStack distributions.

Table 4 - Comparison of different OpenStack distributions

Parameters Red Hat – RDO Mirantis – Fuel DevStack OpenStack Manual

Installation

Ease of Installation Easy Medium Easy Complex

Scalability Good Good Good Poor

Open Source Yes Yes Yes Yes

Community

Support

Yes

(Red Hat)

Yes

(Mirantis)

Yes

(open source)

Yes

(open source)

Online Documentation Medium Medium High High

Cost factor No Cost

No Cost

No Cost

No Cost

Integration with SDN Medium Medium Easy Medium

16

OpenStack Opensource Installation and DevStack are the preferred versions by the participants of our

business survey.

Figure 6: Participant choice of OpenStack distribution (Business Survey)

Considering results from the comparison (Table 2) and business survey (Figure 6), we selected DevStack

as our OpenStack distribution for our research.

In order to select the SDN Controllers, we researched popular open source SDN controllers and

compared their performance as per predefined parameters. Table 5 shows the results of the comparison.

We also used business survey (Figure) results to strengthen our findings.

Parameters Open Daylight Flood Light Ryu POX

Open source Yes Yes Yes Yes

Language of

Implementation

Java Java Python Python

Ease of Use (GUI) Easy Easy Medium Medium

Platform Support Linux Linux, Mac OS,

Windows

Most supported on

Linux

Linux, Mac OS,

Windows

Open Flow support 1.0, 1.3 1.0 1.0,1.2,1.3 1.0

OpenStack

Integration

Strong Medium Strong No

Neutron Plug-in Modular Layer 2

(ML 2)

REST Proxy Plugin Ryu Plugin No

Online

Documentation

Good Good Medium Poor

Industry Support High ( supported by

many Vendors)

Medium (supported

by Big Switch

Networks)

Medium (supported

by NTT)

Medium

Table 5 - SDN Controllers Comparison

17

The participants of the business survey preferred OpenDaylight and Floodlight as the options to

enhance Neutron. Analyzing the results from business survey (Figure 7) and comparison (Table 5), we

selected Open Daylight and RYU controller to integrate into our DevStack environment.

Figure 7: Participant’s choice of SDN Controller (Business Survey)

To determine the answers for the second subproblem, we gathered results from our business

survey. Results show that 45% of survey participants agree that SDN and Neutron satisfy their

organization’s IaaS need (Figure 8).

Figure 8: Participants insight to SDN and Neutron Future (Business Survey)

18

When asked about what features SDN can enhance (Figure 9) in OpenStack around 50% of

participants voted for the features like Multi-Tenancy, Network Scalability, Network Visibility and

Seamless Networking.

Figure 9: Features enhanced by SDN in OpenStack (Business Survey)

When asked about current barriers encountered for adopting SDN in their organization, 52% of

participants feel “Immaturity of current products” is a major barrier. However, the second highest

response at 39% is “Lack of proper resources for evaluating SDN” (Figure 10).

Figure 10: Barriers to SDN adoption (Business Survey)

19

When asked about the willingness to bring SDN (Figure 11) into their production network 42% of

the participants are either ‘very willing’ or ‘completely willing’ and other 42% are ‘moderately willing’ to

make significant changes in their production networks to support SDN.

Figure 11: Acceptance of SDN in production network (Business Survey)

When asked about budget allocation towards SDN in their organization 60% of the participants

plan to allocate a major portion of their allocated budget for SDN deployment (Figure 12)

Figure 12: Budget Allocation towards SDN deployment (Business Survey)

In order to evaluate the performance and functionality of SDN into OpenStack on our test-bed, we

use the results of first research subproblem (OpenDaylight and RYU Controller with DevStack). We

performed Data Plane and Functionality tests. The results of test cases are shown in Table 6 & 7:

20

Data Plane Tests

Test Case Open Daylight Ryu

Average Flow Setup Latency [ms]

10.52

2.537

Average Steady State Latencies [ms]

4.819

2.957

Unidirectional TCP transfer

MSS - 68 : 1 Mb/s

MSS - 1468 : 18Mb/s

MSS - 8908 : 17 Mb/s

MSS - 68 : 133 Mb/s

MSS - 1468 :291 Mb/s

MSS - 8908 : 293 Mb/s

Unidirectional UDP transfer 1 minute.

P = 1 sessions

1.05Mbps,

0% packet loss

P = 5 sessions

520 Kbps,

0.15% packet loss

P = 1 sessions

21.9Mbps,

30 % packet loss

P = 5 sessions

2.1Mbps,

17 % packet loss

Maximum Allowed TCP flows

10 flows/sec - 0 % loss

100 flows/sec - 0 % loss

1000 flows/sec - 3 % loss

10000 flows/sec - 98 % loss

10 flows/s - 0 % loss

100 flows/s - 0% loss

1000flows/s - 7%loss

10000 flows/s - 100 % loss

Table 6: Data Plane Test Results

Functionality Tests:

Test Case

OpenDaylight RYU

Layer 3 Functionality Test

Pass

Pass *

VM-Migration Tests

Pass

Pass

Fault-Tolerance Tests

Pass

Pass

Stress Tests

Fail

Pass

* - For RYU rest_router module was used.

Table 7: Functionality Test Results

The results obtained from the above test cases helped us determine the current scope of OpenDaylight and

RYU controller integrated into OpenStack.

21

5. Discussion of Results:

We started our research by enquiring about available OpenStack distributions. Then we installed

selected distributions and compared those using predefined parameters in our test environment. Using the

obtained results, we selected DevStack among all the options. DevStack provides highly scalable and

flexible testing environment that can quickly be rebuilt according to our requirements. The other

distribution like OpenStack OpenSource installation, which was highly preferred option by the survey

participants had a complex installation process and was difficult to scale. Other options like Mirantis and

RDO did not suit research requirements. Next we selected four popular open source SDN controllers and

compared those using our predefined parameters. While selecting SDN controllers, we preferred

OpenDaylight and RYU over POX and Floodlight. POX does not support integration with OpenStack,

and while integrating Floodlight with DevStack (OpenStack) we identified various issues that hindered us

from performing further tests.

We used the results from our business survey to analyze the industry opinion on SDN and

OpenStack. Our survey participants believed that SDN with Neutron can satisfy their IaaS needs. The

participants feel that SDN brings features into OpenStack such as Network visibility, Seamless

Networking and Network scalability that are verified from our test results and experiences. But the

participants are concerned about SDN Controllers being immature and also feel that there is lack of

resources for evaluating them. We also encountered that SDN Controllers with OpenStack lack maturity

that we verified from our findings during the testing phase. Results from the survey also show participants

being highly interested in making changes to their production network and allocating a major portion of

their total budget to support SDN in coming years. The results from our business survey add value to our

research question with participants showing high acceptability to SDN and OpenStack.

22

Analyzing our data plane test results, we observed OpenDaylight lags behind RYU on parameters

like throughput, flow latency and unidirectional TCP transfer. However, we observe OpenDaylight is a

better solution over RYU in terms of functionality and usability. Both Controllers passed the Layer 3

functionality test, VM Migration test, and Fault-tolerance tests. However, with the increase in number of

virtual machine instances the controllers fail to perform, and we encountered unexpected failures in our

test deployment proving it to be an unstable solution. From our tests, and research we see that the SDN

controllers currently have the capability to handle around 1000 flows /second. A data center, on the other

hand, handles around 100000 flows per second [19]. It clearly indicates a huge gap between the current

capabilities of SDN controllers and the demands of a data center. Moreover, we experienced lack of

resources in terms of documentation and error support available for SDN with OpenStack. Even though

SDN with OpenStack is an evolving IaaS solution it is currently not reliable under a high utilization

environment thus making it not ready for use in production environment. However even with the current

constraints of OpenStack and SDN we strongly believe that these two technologies will drive the future

growth of IaaS. This is because of the rapid development rate and industry acceptance of their

capabilities. As inferred from our survey results industry is willing to invest a major part of their IT

budget for deployment of these technologies. All these features together will in turn translate to faster

feature development and rapid improvements in the controller and OpenStack capabilities thereby,

helping to drive the future of IaaS.

6. Conclusion

Based on the obtained technical and the business survey results, we strongly believe that SDN

with OpenStack is still not feature complete and leaves a lot to be desired. This mainly because of weak

integration solution, incomplete feature set, shaky orchestration and lack of proper documentation. Our

performance results corroborate the industry opinion that SDN still lags behind traditional network

infrastructure in terms of performance and functionality. OpenStack currently does not provide us with

23

ease of use and features to allow it to compete with the commercial offerings like Amazon Web Services

(AWS), Microsoft Azure, VMWare Cloud, etc [18]. However, this being said both SDN and OpenStack

have a large developer base, industry backing and an aggressive release road map. Based on the industry

backing and the active development cycle, we believe it will take at approximately two more years of

development and testing for SDN with OpenStack to reach production readiness and widespread

adoption. We believe that matching industry requirements in terms of performance and functionality will

be the critical factor for OpenStack and SDN together to drive the future of IaaS. The introduction of

Network Function Virtualization [19] in SDN with OpenStack will aid to proliferate acceptance of IaaS.

24

References:

[1] Hsu, F., Malik ,S., Ghorbani S, "Open Flow as a Service". Retrieved April 21, 2014 Available:

https://wiki.engr.illinois.edu/download/attachments/197298167/CloudFlow-3rd.pdf?version=6

[2] OpenStack Training Guides (2013). Retrieved April 17, 2014 from

http://docs.openstack.org/training-guides/content/index.html

[3] OpenStack Networking Administration Guide (2013). Retrieved April 18, 2014 from

http://docs.openstack.org/grizzly/openstack-network/admin/content/

[4] OpenStack Security Guide (2014). Retrieved April 20, 2014 from http://docs.openstack.org/security-

guide/security-guide.pdf

[5] [online] "A10 Networks Openstack Integration". Retrieved April 20, 2014

Available:http://www.a10networks.com/resources/files/A10-SB-19107-EN.pdf

[6] Kerner, S, "Alcatel-Lucent Embraces OpenStack as SDN and NFV Efforts Expand". Retrieved April

23, 2014 Available: http://www.enterprisenetworkingplanet.com/datacenter/alcatel-lucent-embraces-

openstack-as-network-function-virtualization-efforts-expand.html

[7] Tan, D, "Introduction to OpenStack with Dell Compellent Storage Center ". Retrieved April 15, 2014

Available: http://commweb-ps3.us.dell.com/techcenter/extras/m/white_papers/20439057.aspx

[8] OpenStack Cloud Administrator Guide, Retrieved April 20, 2014 from

http://docs.openstack.org/admin-guide-cloud/content/index.html

[9] Barabash, K., Cohen, R., Schour, L. (2013).Distributed Overlay Virtual Ethernet (DOVE)

integration with Openstack. 2013 IFIP/IEEE International Symposium on Integrated Network

Management (IM 2013), 1088 – 1089.

[10] "OpenStack Networking: What is Quantum and Neutron?" Retrieved April 16, 2014 Available:

http://www.sdncentral.com/what-is-openstack-quantum-neutron/

[11] Devlic, A., Ericsson, R., John, W., Kista, S, Skoldstrom, P. (2012). A Use-Case Based Analysis of

Network Management Functions in the ONF SDN Model. 2012 European Workshop on Software Defined

Networking, 85 – 90. doi : 10.1109/EWSDN.2012.11

[12] Myung-Ki, S., Ki-Hyuk, N., Hyoung-Jun, K. (2012). Software-defined networking (SDN): A

reference architecture and open APIs. 2012 International Conference on ICT Convergence (ICTC), 360-

361. doi: 10.1109/ICTC.2012.6386859

[13] [online] "OpenDaylight Integration" Retrieved April 21, 2014 Available

http://openstack.redhat.com/OpenDaylight_intergration

[14] “Details of Ryu in cooperation with OpenStack Grizzly”. Retrieved April 01, 2014 Available

https://github.com/osrg/ryu/wiki/Details-of-Ryu-in-cooperation-with-OpenStack-Grizzly

[15] “Neutron/FloodlightPluginSetup”. Retrieved April 10, 2014 Available

https://wiki.openstack.org/wiki/Neutron/FloodlightPluginSetup

25

[16] “Test suite for SDN-based Network Virtualization”. SDN Hub. Retrieved April 12, 2014 Available

http://sdnhub.org/projects/sdn-test-suite/

[17] Tie Luo; Hwee-Pink Tan; Quan, P.C.; Yee Wei Law; Jiong Jin, "Enhancing responsiveness and

scalability for OpenFlow networks via control-message quenching," ICT Convergence (ICTC), 2012

International Conference on , vol., no., pp.348,353, 15-17 Oct. 2012 doi: 10.1109/ICTC.2012.6386857

[18] Torsten V.,“War of the Stacks: OpenStack vs. CloudStack vs. vCloud vs. Amazon EC2 “ Retrieved

on April 22, 2014 Available : http://blogs.enterprisemanagement.com/torstenvolk/2013/10/11/war-stacks-

openstack-cloudstack-vcloud-amazon-ec2/#sthash.hfZrvFeV.dpuf

[19] Kerner, S , "Alcatel-Lucent Embraces OpenStack as SDN and NFV Efforts Expand".

RetrievedMarch , 2014 Available: http://www.enterprisenetworkingplanet.com/datacenter/alcatel-lucent-

embraces-openstack-as-network-function-virtualization-efforts-expand.html

References used for SDN integration into OpenStack

[1] [Online] “Using Ryu Network Operating System with OpenStack as Network controller!” Retrieved

April 2, 2014 Available: https://github.com/osrg/ryu/wiki/OpenStack

[2] [Online] “Using Ryu Network Operating System With Openstack as Openflow Controller” Retrieved

April 3, 2014 Available : http://ryu.readthedocs.org/en/latest/using_with_openstack.html

[3] [Online] “OpenStack Quantum”, Project Floodlight. Retrieved April 8, 2014 Available:

http://www.projectfloodlight.org/openstack/

[4] [Online] “Neutron/FloodlightPluginSetup”, OpenStack Wiki. Retrieved April 9, 2014 Available:

https://wiki.openstack.org/wiki/Neutron/FloodlightPluginSetup

[5] [Online] “ OpenDaylight OpenStack Integration with DevStack on Fedora “, NetworkStatic. Retrieved

April 1, 2014 Available http://networkstatic.net/opendaylight-openstack-integration-devstack-fedora-20/