Jul 7, 2018 - REpresentational State Transfer (REST) API to enable the gathering and configuration ..... A free home version is available, or users can .... Fibre also connects E217 through to A2, where the main polytechnic network ...... [65] J. Teixeira, G. Antichi, A. Del Chiaro, S. Giordano, and A. Santos, 'Datacenter in a.
SDN: The Readiness of Open Source Frameworks for Production Networking
A thesis presented in partial fulfilment of the requirements for the degree of
Master of Information Technology
Whitireia Polytechnic, Porirua, New Zealand
Lisa Patterson
2017
1
2
ABSTRACT
Software Defined Networking (SDN) represents a new paradigm, allowing for the separation of data and control planes in a network, through a vendor agnostic interface. It is currently in an early stage of development, however SDN has the potential to alter the foundation of computing and data centre infrastructure.
Whitireia School of IT provides a production network that has grown organically over the past ten years, supporting a diverse range of heterogeneous devices and services. This production network serves both students and staff, and extends across multiple campuses throughout New Zealand. It is a multi-faceted network that includes such components as a wireless network, a data centre and multiple computer laboratories, enabling students and staff to work and study both on campus and remotely.
This thesis investigates whether there is an open source SDN framework suitable to implement on the Whitireia School of IT network, and also what other practical changes need to be made to the network in order for a future SDN implementation to be a viable option.
A variety of SDN frameworks are investigated to determine whether there is an open source solution suitable to implement the Whitireia School of IT network. The thesis also explores the practical challenges associated with migrating the existing network to a SDN implementation. I have employed several real-world use cases, based on current services and requirements, to analyse the capabilities and limitations of SDN frameworks. From this, I determine that Faucet is a suitable candidate for deployment to the Whitireia School 3
of IT network. However, the structure of the School of IT network will not support conversion to SDN without further (future) work being carried out.
4
DEDICATION
Dedicated to Zara, Aidan, and Fabian.
You have the ability to achieve whatever you want in life, don’t let anything, or anyone, hold you back.
5
6
ACKNOWLEDGEMENTS
Thank you to my supervisors Dr Susan Chard, Dr Ryan Chard, and Scott Morton for the direction and guidance in navigating this journey. Your skills, experience, and gentle encouragement were invaluable to me.
Geoff Gordon, thank you for the technical network advice provided. Thank you to Dr Brenda Lloyd, Dr Marta Vos, Simon Dixon, Neale Catchpole, and Dr Sara Bilal for your general advice and support.
On a personal note, thank you Mum for the moral support and encouragement, and Glenn for believing in me.
7
TABLE OF CONTENTS
Abstract ........................................................................................................................3 Dedication ....................................................................................................................5 Acknowledgements ......................................................................................................7 List of Tables ...............................................................................................................11 List of Figures ..............................................................................................................12 CHAPTER 1 INTRODUCTION .........................................................................13 1.1 Context ......................................................................................................14 1.2 Research Problem .....................................................................................15 1.3 Research Objectives ..................................................................................16 1.4 Contributions .............................................................................................17 1.5 Research Scope .........................................................................................18 1.6 Thesis Organisation...................................................................................19 CHAPTER 2 RELATED LITERATURE ...........................................................20 2.1 What is SDN?............................................................................................20 2.2 Status of Current SDN Deployments ........................................................22 2.3 Open Source and Proprietary Software .....................................................25 2.4 SDN Controllers/Frameworks...................................................................26 2.4.1 Review of SDN Controllers/Frameworks ......................................28 2.4.2 Proprietary SDN Software .............................................................34 2.5 OpenFlow ..................................................................................................39 2.6 Network Function Virtualisation (NFV) ...................................................41 2.7 Gartner Hype Cycle ..................................................................................42 2.8 Techniques and Tools ...............................................................................45 2.9 Summary ...................................................................................................48 CHAPTER 3 RESEARCH DESIGN STRATEGY .............................................50 3.1 Motivation .................................................................................................50 3.1.1 Taxonomy ......................................................................................51 3.2 Research Methodology .............................................................................51 3.2.1 Experimental Method ....................................................................51 3.2.2 Use Case Selection ........................................................................52 3.3 Evaluation methods ...................................................................................52 3.3.1 Evaluation of Software Against the Use Cases .............................52 3.3.2 Simulation of Use Cases ................................................................53 3.4 Summary ...................................................................................................53 CHAPTER 4 NETWORK STRUCTURE ...........................................................54 4.1 The Current School of IT Network ...........................................................54 4.1.1 A Detailed View of the Network ...................................................57 4.2 Current Logical Depiction of the Network ...............................................59 4.3 Should the Network Structure be Altered to Move to SDN? ....................60 4.4 Security .....................................................................................................62 4.4.1 Open vSwitch.................................................................................63 4.4.2 VNGuard........................................................................................64 4.4.3 SDN Security Considerations ........................................................64 4.5 The Risk of Having a Controller Based in the Cloud ...............................66 4.6 Proposed Design .......................................................................................66 8
4.6.1 4.6.2 4.6.3 4.6.4 4.6.5
Top Layer Physical E Block (Proposed) .......................................68 Controller to be Installed in Hardware or Software? .....................69 Controller Placement .....................................................................69 Controller Appliance .....................................................................70 What Will be the Most Suitable Network Structure to Employ? .........................................................................................73 4.6.6 Network Resilience ........................................................................74 4.7 The Recommended Network Implementation ..........................................75 4.8 A Simplified Network Structure ...............................................................76 4.8.1 Simplified Switch Port Layout Description ...................................77 4.9 Summary ...................................................................................................78 CHAPTER 5 USE CASES ..................................................................................79 5.1 School of IT Wireless Network ................................................................79 5.2 Library Access ..........................................................................................79 5.3 Remote Sites .............................................................................................80 5.4 Deployment ...............................................................................................81 5.5 Multiple Gateways ....................................................................................82 5.6 Whitireia School of IT VPN .....................................................................83 5.7 Security Levels and Authentication ..........................................................84 5.8 Summary ...................................................................................................84 CHAPTER 6 TAXONOMY ................................................................................86 6.1 Related Taxonomies ..................................................................................86 6.2 Methodology .............................................................................................87 6.3 Categories..................................................................................................88 6.4 Desk Evaluation Using the Taxonomy .....................................................93 6.5 Desirable Criteria in Each Category .........................................................93 6.6 Analysis of Products Across Criteria ........................................................95 6.7 Summary ...................................................................................................96 CHAPTER 7 DESK EVALUATION OF THE USE CASES .............................97 7.1 Whitireia School of IT Wireless Network Use Case ................................97 7.1.1 Result of Desk Evaluation Against the School of IT Wireless Network Use Case ..........................................................97 7.2 Library Access Use Case ..........................................................................99 7.2.1 Result of Desk Evaluation Against the Library Access Use Case ........................................................................................100 7.3 Remote Sites Use Case .............................................................................100 7.3.1 Result of Desk Evaluation Against the Remote Sites Use Case ........................................................................................102 7.4 Summary ...................................................................................................103 CHAPTER 8 USE CASE IMPLEMENTATION ................................................105 8.1 School of IT Wireless Network Use Case ................................................105 8.2 Library Access Use Case ..........................................................................106 8.3 Remote Sites Use Case .............................................................................107 8.4 Summary ...................................................................................................108 CHAPTER 9 CONCLUSION..............................................................................109 9.1 Research Problems/Objectives ..................................................................109 9.2 Recommendations .....................................................................................110 9.2.1 Physical Network ...........................................................................110 9.2.2 Deployment....................................................................................112 9.2.3 Controller/Framework ...................................................................114 9
9.2.4 Use Cases .......................................................................................115 9.3 Future Work ..............................................................................................115 9.4 Contributions .............................................................................................117 9.5 Limitations of This Research ....................................................................119 9.6 Summary ...................................................................................................119 REFERENCES ............................................................................................................121 APPENDICES .............................................................................................................127 Appendix A ..................................................................................................................127 Appendix B ..................................................................................................................128
10
LIST OF TABLES
Table No.
Page No.
Table 2.1: OpenFlow Feature set comparison [43] ...................................................... 41
11
LIST OF FIGURES
Figure No.
Page No.
Figure 2-1: SDN Architecture ...................................................................................... 21 Figure 2-2: The Evolution of SDN Controllers/Frameworks ...................................... 27 Figure 2-3: OpenFlow version roadmap [43] .............................................................. 40 Figure 2-4: Gartner Hype Cycle [53] ........................................................................... 42 Figure 2-5: Gartner Hype Cycle for Emerging Technologies 2016 [56] ..................... 45 Figure 4-1: School of IT Network Diagram ................................................................ 56 Figure 4-2: Current logical depiction of the School of IT network ............................. 59 Figure 4-3: Proposed Future Logical Diagram ............................................................ 67 Figure 4-4: Top layer physical (possible solution using fan-out) ................................ 68 Figure 4-5: SDN Controller ‘Appliance’ ..................................................................... 71 Figure 4-6: Holistic view (logical), Whitireia School of IT network .......................... 74 Figure 4-7: Simplified network structure ..................................................................... 76 Figure 4-8: Switch port layout description .................................................................. 78 Figure 6-1: Taxonomy category evaluation ................................................................. 95 Figure 8-1: Example of Mininet-WiFi topology [101] .............................................. 106 Figure 8-2: Generic Abstracted SDN LAN solution .................................................. 107 12
CHAPTER 1
INTRODUCTION
Software Defined Networking (SDN) is an emerging technology in the field of networking. At present, there have not been any documented cases of SDN being implemented into a production, established, multiple computer laboratory network in a New Zealand (NZ) polytechnic. Current implementations of SDN are typically pilot programs with most studies described as research prototypes, and not actual deployments. While still in its infancy, it is anticipated that SDN approaches can increase network flexibility and improve cost efficiency, whilst also reducing the level of operational complexity.
This thesis aims to determine whether there is an existing open source SDN framework that is suitable to implement the Whitireia School of IT’s production networking capabilities. In addition, it explores and identifies the practical challenges that must be addressed in order for an SDN implementation to become a viable alternative for traditionally networked campus laboratories and services.
The thesis presents a case for the introduction of open source SDN as a direction for production networking and describes the potential benefits and advantages. The work investigates the early stages in adoption of this technology, as use for production networks is not yet considered to be mainstream in the community.
To investigate the capabilities of SDN frameworks I first construct a thorough taxonomy of both open-source and proprietary solutions. The desk evaluation research method is used with the taxonomy to guide the identification of the most suitable SDN frameworks 13
and construct a shortlist for potential implementation. To further evaluate whether these frameworks are suitable, I utilise real world case studies. I derive a set of representative use cases from the existing Whitireia School of IT network. These use cases are analysed using the desk evaluation method to determine the readiness of each framework. A simulation tool, called Mininet, is then used to explore implementation of the most suitable framework for the use cases representing the Whitireia School of IT network.
This research contributes to knowledge in the wider SDN community. The research is directly useful to Whitireia School of IT, helping evaluate whether or not SDN is yet sufficiently mature to deploy on its production network. In addition, the research also contributes to the wider understanding of the issues surrounding migration from traditional networks to SDN infrastructures, and the challenges involved in applying SDN to production use cases. A key strength of this research, and a point of difference from most existing works, is its focus on real-world scenarios and requirements, via deployment to a diverse polytechnic production network which services students and teaching staff.
1.1
CONTEXT
This research primarily focusses on two fields of study, SDN and Network Engineering, and has provided an opportunity to collaborate with other research institutes. A key collaboration has been established between researchers at both Whitireia and Victoria University of Wellington. This collaboration was founded to develop networking research at both institutes, establish joint training and development resources, and foster the dissemination of knowledge. The collaboration has resulted in a signed agreement between the two institutes in March 2016. 14
To date, research has included the establishment of a SDN network between the Whitireia School of IT and Victoria University of Wellington campuses. Whitireia School of IT is based at Porirua, and Victoria University is based in Kelburn, Wellington. A test network has been established between Whitireia School of IT network and Victoria University of Wellington Engineering and Computer Science, using a layer two private tunnel via the Research and Education Advanced Network New Zealand (REANNZ) [1]. REANNZ is New Zealand’s research network for educators and researchers, it provides technology unable to be gained from commercial networks [2].
At the time of this research, a SDN connection has also been established between Victoria University of Wellington and Kyoto University Graduate School of Informatics in Honshu, Japan; National Chiao Tung University in Hsinchu, Taiwan; and Nanyang Technological University School of Electronics and Electrical Engineering in Singapore. The network bridging these international institutes leverages layer three connections, as opposed to the layer two connection between Whitireia School of IT and Victoria University of Wellington. Preliminary work explored moving data between the institutions using SDN infrastructure.
1.2
RESEARCH PROBLEM
When any new technology is introduced, it is essential to analyse its capabilities and limitations prior to implementing it in a production environment [3]. As the Whitireia School of IT explored new networking technologies, SDN was identified as a technology with potential to reduce costs, improve flexibility, and lower operational complexity. However, prior to implementation, an in-depth analysis of SDN needs to be conducted. 15
In addition, it must be determined whether SDN technology is sufficiently mature for deployment to an environment that is essential for the day to day operation for both students and staff. Another issue for consideration is whether there is yet an open source SDN controller/framework software with capability to meet the diverse requirements of the Whitireia School of IT environment.
This research aims to answer the research question: “Is there an open source SDN framework suitable to implement on the Whitireia School of IT network?” A sub-question that must also be resolved is: “What other practical changes need to be made to the network in order for a future SDN implementation to be a viable option?”
1.3
RESEARCH OBJECTIVES
The objectives of this study were to identify the readiness of available SDN frameworks for deployment, to ascertain other changes needed for a future SDN implementation, and to advance knowledge in the area of production networking in a SDN environment.
It has been stated that the greatest challenge facing the adoption of SDN in enterprise is the issue of deployment and how to deploy and run a network using both traditional (legacy) and SDN capable switches, while maximising the benefit of the simplified management and increased flexibility available from SDN [4]. Most existing SDN use cases and technologies are new, with SDN still in its infancy, and developing. It is important to appreciate that careful thought must be given before adopting SDN, and it is prudent to precede real life adoption with a prototype [3].
16
1.4
CONTRIBUTIONS
This research makes several contributions that benefit knowledge for the Whitireia School of IT, the SDN research community, and the IT industry in general. The following enumerates the key contributions of this thesis.
Providing a categorisation of SDN products and features, open source and proprietary: A taxonomy of open source SDN frameworks has been constructed, in order to select frameworks potentially suitable for testing. The categorisation of SDN products and features differentiated between aspects such as open source and proprietary solutions plus the differing capabilities of products;
Clearly identifying what are SDN controllers/frameworks as opposed to SDN features: Further to categorisation into SDN products and features, the solutions were separated into SDN controllers/frameworks (as opposed to SDN features);
Investigating the practical aspects of moving from a current, diverse traditionally networked production environment to SDN: From the research conducted it appeared apparent that there had been considerable interest from an academic, or theoretical viewpoint of introducing SDN to a networking environment. However, documentation on actual requirements needed to move from a currently operating, diverse traditionally networked production environment to SDN was essentially non-existent. This document aims to contribute knowledge to facilitate an easier decision making process for organisations contemplating this move in the future;
17
Identifying and developing appropriate use cases: This thesis records construction of relevant use cases. Open source and proprietary SDN products were compared and categorised to analyse suitability against those selected use cases. The School of IT network is a valuable model to investigate as a potential match for SDN, as it is unique and diverse, and has interesting use case possibilities;
Conducting simulation of the use cases: Simulation of selected use cases allowed for the environment to be tested in a cost-effective manner prior to the expense of hardware and software purchase; and
Considering use case implementation: The readiness of SDN frameworks for production networking was investigated. Consideration of the implementation of these use cases demonstrated that certain functionalities were achievable, thus affording an organisation the confidence that certain outcomes would be possible.
1.5
RESEARCH SCOPE
It is within the scope of this research to investigate available open source SDN controller/framework solutions in order to determine which appear to be suitable for potential implementation in the Whitireia School of IT network. To assist with this research, a classification document, or taxonomy, has been prepared. This taxonomy categorises products together with their features and specifications in order to prepare a full and comprehensive catalogue, and identifies the subsumption of SDN projects. Both open source and proprietary projects and products are analysed.
18
The implementation of SDN to the Whitireia School of IT network is out of the scope of this research. Instead, this research focusses on an evaluation of the capabilities and readiness of SDN solutions for production deployment to networks, specifically the Whitireia School of IT network. Both software and hardware solutions have been investigated during the course of this research.
1.6
THESIS ORGANISATION
This thesis is organised as follows: Chapter 2 introduces literature related to the field of SDN, including history and information on the status of current deployments. Chapter 3 provides an introduction, description and summary of the design strategy and research methodology employed in this research. Chapter 4 discusses the network structure, both present and proposed. In Chapter 5, case studies are presented in the form of use cases. Chapter 6 presents a classification of SDN products and features as a taxonomy, which is used to select suitable candidates for this research. Chapter 7 comprises a desk evaluation of the use cases, comparing and evaluating features of each of the shortlisted controller/framework software to each of the use cases. In Chapter 8, implementation of the selected use cases is presented and discussed, this details the simulation environment that experimentation took place in. An evaluation of the findings of the research is given in Chapter 9, which details the conclusions drawn from the research, and suggests possible avenues for future work.
19
CHAPTER 2
RELATED LITERATURE
Software Defined Networking (SDN) has been described both as the future direction of networking and as a tsunami that is taking over many other parts of the Information Technology (IT) industry [5]. Literature reveals a great deal of academic research on the phenomenon, but few real world implementations at the present time [6]. At the date of this research, it does not appear that an open source SDN framework has been implemented and documented in a polytechnic teaching environment network in New Zealand.
2.1
WHAT IS SDN?
Seminal work centred around development of the OpenFlow (OF) protocol, an instrument that forms the foundation of the SDN paradigm, providing researchers with the ability to experiment with new protocols using traditional computer networks [7]. SDN presents a new paradigm, allowing for separation of the data and control planes of a network via a vendor agnostic interface [3]. Although it is at an early stage of development, SDN has a vast potential for creation of a totally new and foundational layer for data centre and computing infrastructure [8].
A SDN architecture is built from three layers: an infrastructure, control, and application layer. The infrastructure layer (known also as the data plane) sends packets around the network with simple forwarding commands and network switches. The control layer comprises a controller which manages the infrastructure layer. Lastly, the application layer is responsible for holding applications that interact with network services and capabilities. 20
Figure 2-1: SDN Architecture
When SDN is introduced to a network, the network becomes programmable, with the control plane moved to a central controller, allowing for a simpler data plane which contains the network devices [9]. The four main principles of SDN are the separation of control and data planes, logically centralised control, open interfaces, and the programmable nature of the network [10].
The SDN controller can be considered as the SDN network’s strategic control point. It relays information via southbound Application Programming Interfaces (APIs) to switches and routers below, and via northbound APIs to business logic and applications above. Open source SDN controllers typically contain collections of pluggable modules which perform differing network tasks. Some basic tasks include making an inventory of devices within the network (including the capability of each), and gathering statistics 21
from the network. To support more advanced capabilities and enhance functionality, extensions can be inserted. These include running algorithms to orchestrate new rules and perform analytics in the network [11].
The virtualisation of a network using a SDN strategy encompasses the separation of the network device from the data plane, allowing the abstraction of decentralised operations such as routing flow, via centralised control with the SDN controller. The implementation of SDN enables the necessary Quality of Service (QoS) requirements, which ensures maximum network utilisation [12].
2.2
STATUS OF CURRENT SDN DEPLOYMENTS
Interest in SDN has recently been growing in both industry and within the research community. Many network operators are actively investigating the potential offered by the SDN paradigm. For example, Google has moved to SDN for its network linking data centres, and the telecommunications company, NTT Communications, has introduced Infrastructure as a Service (IaaS) based on SDN. However, even though SDN has enjoyed success so far, it is still at a very early stage of development. It is evolving quickly and a great deal of effort is needed to create a production deployment [13]. Recent literature details early SDN hybrid architectures, Google’s B4 Wide Area Network (WAN) is considered one of these [14]. Google has deployed a purpose built (proprietary) global software defined WAN. Initially they had only basic SDN deployed, and they brought up one data centre at a time [15].
Networking solutions consisting purely of SDN switches running with a centralised controller have been proven to operate in locations and data centres that are 22
geographically distributed. Examples include OpenFlow in Europe: Linking Infrastructure and Applications (OFELIA) in Europe and Global Environment for Network Innovations (GENI) in America [14].
A software defined Internet exchange (SDX) architecture has been deployed in ColoAtl (Atlanta, Georgia) which uses OpenFlow capable switches and the open source SDN controller/framework
Floodlight
[16].
Of
local
relevance,
Google’s
SDN
controller/framework fabric appears as one logical switch which connects REANNZ and the Wellington Internet Exchange (WIX) to other autonomous systems [16].
SDN is also becoming increasingly prevalent in academic institutions. An implementation of SDN has been deployed to span three buildings at Georgia Tech [17]. SDN was deployed at Fulton Schools in Georgia, the Fulton County School System consisting of a faculty of 6800, and a student body of 94,000. It was reported that the installation of SDN was a tedious process, which resulted in feelings of isolation. Key problems, such as difficulty in finding qualified technicians capable of successful deployment, were encountered during the process. Although manufacturers and equipment vendors recommend upgrading to SDN, they themselves are still figuring the process out [18].
Both open source and proprietary SDN frameworks are available. This research focusses on open source options. However, proprietary products are also examined to ensure extensive understanding, including those where open source projects have subsumed into proprietary solutions, available for purchase.
23
An area of growth frequently mentioned in conjunction with SDN relates to the networking of everything, and is known as the Internet of Things (IoT). The term IoT (which also may be known as Internet of Objects) refers to a networked interconnection of everyday devices, or objects, such as refrigerators, cars, and sensors, which are often equipped with an omnipresent intelligence [19]. IoT environments present a challenging area for network managers, due to the proliferation of heterogeneous resources. The primary problem lies with the complexity of network convergence, and the difficulty of configuring network hardware for this environment [19].
An increasing interest in IoT has resulted in multiple wide area deployments of IoT subnetworks, which enables multiple heterogeneous wireless communication solutions to work together. These technologies included multiple access solutions such as Wi-Fi, cellular, Bluetooth and ZigBee, together with multi hop and Mobile Ad-Hoc Network (MANET) routing protocols. All protocols must effectively integrate to ensure the creation of a seamless platform of communication. Management of these geographically distributed, open and non-homogenous network infrastructures, particularly in dynamic environments, has been reported as a key technical challenge [20]. SDN has been shown to be one of the best solutions to manage resources in an IoT environment [21].
“Bristol Is Open” is a joint IoT venture between the Bristol City Council and the University of Bristol to create an open, programmable (smart) city. This venture uses Bristol as a research and development testbed to manage a series of projects with the aim of allowing citizens to better work, play and interact with the city. By using data sensors, the smart city can respond in real time to occurrences such as entertainment events, congestion, energy supply and waste management. Bristol’s infrastructure includes fibre 24
optic cables in the ground, more than 1.5 kilometres of experimental wireless connectivity along the harbour side, and a mesh network that bounces between lampposts in the city. These networks are controlled with software and form a SDN network, based on the OpenFlow standard. Network Function Virtualisation (NFV) is used to slice the infrastructure, and ensure that it is fluid and able to be used by several projects at once [22].
2.3
OPEN SOURCE AND PROPRIETARY SOFTWARE
Software exists in the market as either open source, or proprietary. Source code relates to the medium in which programmers both create and then modify software. The source code for open source software may be freely available on the internet. This differs from proprietary software where the source code is often a carefully guarded secret. The best known example of open source software in the marketplace is the Linux operating system. There are, however, a large number of open source software products that are available for many differing purposes. Open source software may be distributed under a wide variety of licences and terms. Almost all of the terms have two common factors: The software may be utilised without the user paying a licence fee; and any user may modify the software, and add functionality [23]. When comparing open source and proprietary software, it is important to consider the fundamental differences in the two.
Open source software systems are supervised by dedicated groups of developers contributing modifications that continually improve the product. The developers decide on the direction of the software, based on community needs [24]. Proprietary software is created and supported by ‘for profit’ companies (Microsoft is an example). These
25
companies typically sell licences to those who wish to use their software with the drive of maximising profit.
A brief explanation of the open source software illustrated in Figure 2-2 is given in the sections below, ordered by release date from oldest to most recently released.
2.4
SDN CONTROLLERS/FRAMEWORKS
The growth of the SDN paradigm has been rapid, and has seen the introduction and evolution of controller frameworks. Many started as open source projects, collaborated on within the networking community. Some projects branched off into other open source projects or products, whilst others were purchased by companies and morphed into proprietary, or commercial, solutions. SDN continues to be a very active area in the networking community. It has been reported that 15 SDN research survey papers were published over the period of 2014 to 2015, with each surveying an average of 167 papers [25]. SDN is a leading edge technology, and researchers working with it continue to operate in a fluid environment.
26
Figure 2-2: The Evolution of SDN Controllers/Frameworks 27
Figure 2-2 shows a high level view of the evolution of SDN controllers/frameworks. One point of particular interest depicted in the figure is that the largest quantity of new SDN controllers/frameworks were released in 2014. The figure also illustrates which products had roots in the open source community, before being purchased or altered and packaged for sale as proprietary solutions. It is also interesting to see the wide variety of programming languages that have been used to construct these controllers/frameworks.
2.4.1
Review of SDN Controllers/Frameworks
The following briefly presents a survey of the controllers/frameworks identified in Figure 2-2.
Trema Trema [26] is an open source controller framework that provides everything needed for creation of OpenFlow controllers written in Ruby. Trema provides a network emulator and high level library for creation of OpenFlow networks for testing on personal computers.
NOX (Classic) Written using the C++ language, NOX [15] is an open source controller/framework which provides an easy platform in which to write network control software. NOX is considered to be the original OpenFlow controller/framework [14]. Criticisms of NOX concerns how very low levels of flow instantiation are demonstrated [17] and to how that it only supports OpenFlow protocol v1.0.
28
Beacon Beacon v1.0.4 [27] is considered to be very stable. It is written in Java, and is a cross platform controller/framework which is capable of running on multiple platforms from phones to high level servers.
“The New NOX” A new version of NOX [28] exists, named ‘New NOX’, which supports the C++ language. New NOX has a superior codebase to the original NOX with greater speed, but supports less applications than the original version.
POX The POX [20] open source controller/framework was developed from NOX. It is written in Python, and runs with Windows, Linux and Mac operating systems. POX allows a simple way to carry out SDN experiments using the OpenFlow protocol [21]. One limitation of POX at the time of this research was that it was only able to communicate with OpenFlow 1.0 switches, however it also provided support for Open vSwitch and Nicira extensions [22].
Kandoo Kandoo [29] is the name of a distributed open source controller, built on top of Beehive, which provides a framework able to preserve scalability with changing switches. Kandoo supports not only OpenFlow, it can be extended for alternative southbound protocols. Kandoo is structured in two layers. The Kandoo [30] framework contains two controller layers; a group of controllers that have no interconnection or knowledge of the network wide state form the bottom layer, while the top layer is comprised of a logically 29
centralised controller which has the responsibility of maintaining the network wide state. The bottom layer controllers only run local control applications that can function using the state of a single switch near data paths, handling most of the frequent event and shielding the top layer. The design of Kandoo allows network operators to replicate local controllers on demand to relieve the load on the top layer, the only potential scalability bottleneck.
Floodlight Floodlight [31] is a Java-based SDN controller/framework, licenced by Apache. Floodlight controller/framework used Beacon as its foundation. Supporting a wide range of both physical and virtual OpenFlow switches, Floodlight can be easily enhanced and extended. Floodlight can facilitate fast adoption of SDN, and is highly regarded for use in experiments [32].
OpenContrail OpenContrail [33] is an open source SDN project, licenced by Apache. The aim of this community-based project was to provide functionality around network virtualisation on various orchestration systems, including OpenStack. OpenContrail has a large REpresentational State Transfer (REST) API to enable the gathering and configuration of operational data and analytics from the system. Built for scale, OpenContrail can act as the foundation networking platform for a cloud-based infrastructure.
Protocol Oblivious Forwarding (POF) Controller Based on Floodlight, the Java-based Protocol Oblivious Forwarding (POF) POFController [34] is licenced by Berkeley Software Distribution (BSD). It is a cross 30
platform OpenFlow controller, providing control for the support of protocol oblivious forwarding. POFController is based on, but not limited to, OpenFlow protocol v1.3.
Beehive The Beehive [35] distributed controller/framework platform can automatically deduce application dependencies, and maintain their state. Beehive can provide useful feedback, and identify design bottlenecks to help developers improve performance in the control plane. By doing this, Beehive significantly simplifies the process of developing control applications.
Open IRIS OpenIRIS [36] is the open source version of IRIS. Written in Java, it supports OpenFlow versions 1.0 to 1.3. OpenIRIS has an Apache 2.0 licence. Many OpenIRIS functions come from Beacon and Floodlight controllers/frameworks.
OpenMUL The lightweight OpenMUL [37] controller/framework is written almost entirely in C. Designed for performance, availability and scalability, OpenMUL provides a very stable platform which offers superb flow performance handling, it can control network devices supporting OpenFlow, OVSDB and Netconf.
Open Network Operating system (ONOS) Open Network Operating System (ONOS) [38] is a distributed open source software written in Java. ONOS is built for performance, and scales well. ONOS contains well defined northbound and southbound interfaces and abstractions. 31
Ryu Ryu [39] is a component-based SDN controller/framework written in Python which supports various protocols to manage network devices. With its set of pre-defined components which are capable of being altered and extended, Ryu makes it easy for developers to create new network control and management applications.
Lumina SDN Controller Developer Edition (Lumina/Brocade/Vyatta controller) Powered by OpenDaylight (ODL), The Lumina [40] SDN Controller provides an open, common platform for developers. This allows providers to exercise direct control over their SDN development and implementation, eliminating lock-in.
An interesting point to note is that when this information was originally collected in 2016, the product was referred to as the Brocade (formerly Vyatta) controller. In 2017 the Brocade SDN Controller page now forwards to Lumina.org. This serves to demonstrate how quickly SDN technology is changing, and what a fluid environment this technology exists in.
As well as an open source product, Lumina also offers the Lumina SDN Controller Commercial Edition [41]. This version is a quality-assured version of the standard OpenDaylight controller, and is licenced for production networks. Lumina enables delivery of multivendor interoperability as it is based on a common control plane. It contributes back to the open source community to ensure complete compatibility with the codebase of OpenDaylight.
32
OpenDaylight The OpenDaylight [42] SDN controller/framework supports OpenFlow, and also other open SDN standards. OpenDaylight is implemented purely in software, within its own Java Virtual Machine (VM) and can be deployed on to both hardware and operating system platforms supporting Java. The OpenDaylight controller/framework can be deployed in a variety of production networking environments. It supports a modular controller framework, and can also provide support for upcoming SDN protocols and other SDN standards. OpenDaylight is driven by a collaborative and global community of user and vendor organisations. The OpenDaylight project has over 50 member organisations, more than 1000 developers and supports approximately one billion subscribers worldwide. OpenDaylight code has been embedded or integrated in over 50 vendor applications and solutions, and it can be utilised within a range of services [43].
Cherry Cherry [44] is an OpenFlow controller written in the Go programming language. Cherry supports OpenFlow protocols versions 1.0 and 1.3, and focusses on compatibility with commercial OpenFlow switches. The Cherry controller was not designed for general purpose, it utilises SDN for an IT service provider.
Faucet Faucet [45] is an open source SDN controller originally developed by REANNZ (supported by the Open Networking Foundation) [1]. Faucet handles MAC learning and it supports Virtual Local Area Networks (VLANs) and Access Control Lists (ACLs). Faucet is deployed in a variety of locations, including the Open Networking Foundation [3]. 33
Compatible with OpenFlow switches supporting OpenFlow 1.3 and multiple tables, Faucet implements all its functionality by exclusively using OpenFlow (non-hybrid mode) [46]. Faucet is an OpenFlow controller for a layer 2 switch based on Valve, by OpenvApour [47]. Faucet has been deployed in both experimental and enterprise networks, it is running in production at multiple sites and it supports multiple hardware vendors [45].
Faucet is based on the OpenFlow protocol (v1.3). Written in Python, and released in 2015. It is deployed as two systems: a controller (usually running Ubuntu); together with an OpenFlow switch (such as an Allied Telesis x930), directly connected. The process of deployment is extremely quick, with recent deployments only taking minutes [3].
Multiple Faucet controllers may be used for high availability, Controllers may be as large or small as required, in fact Faucet is run in production at one location using a Raspberry Pi as a controller. The controller does not need to be particularly powerful as this is handled by the high performance switch [3]. Faucet implements all of its functionality exclusively, in non-hybrid node [3].
2.4.2
Proprietary SDN Software
Proprietary software is created and supported by ‘for profit’ companies (Microsoft is an example). These companies typically sell licences to those who wish to use their software, with the drive of maximising profit [24]. An explanation of open source software was provided in section 2.3.
34
ONIX The first SDN controller/framework, NOX, was initially developed by Nicira networks along with OpenFlow. Nicira Networks (subsequently acquired by VMWare), open sourced NOX in 2008 by donating it to the SDN community. Nicira then proceeded to co-develop ONIX [11] with Google and Nippon Telegraph and Telephone (NTT). ONIX is the foundation of the Nicira/VMWare controller/framework, and this proprietary solution is rumoured to form the base of the Google WAN Controller.
Google B4 Google’s proprietary SDN solution is named Google B4 [48]. A staged implementation of this SDN network took place early in 2011, with deployment complete by the second half of the same year.
NEC ProgrammableFlow Controller/Framework The proprietary NEC ProgrammableFlow controller/framework [49] gives the benefits of virtualisation to high performance switching in a network. From a single console, data centres are able to deploy, then control, manage and monitor multi-tenant network infrastructure. Combined with Nippon Electric Company (NEC)’s Virtual Tenant technology, network administrators are able to build multi-tenant networks. The centralised control of ProgrammableFlow eliminates the requirement for distributed protocols like Spanning Tree, which reduces network complexity and unlocks capacity that is often unavailable in existing networks.
35
VMware NSX controller VMware’s proprietary NSX [50] controller is an advanced distributed state management system, controlling virtual networks and overlay transport tunnels. The NSX controller is the central point of control for all the logical switches in a network. It maintains information of all hosts, virtual machines, logical switches, and Virtual Extensible LANs (VXLANs). NSX controller supports two new logical switch control plane modes, Hybrid and Unicast. These modes decouple NSX from the physical network. VXLANs no longer need the physical network to support multicast to be able to handle the Broadcast, Unknown unicast and Multicast (BUM) traffic in a logical switch. The unicast mode requires no physical network configuration and replicates all the BUM traffic locally on the host. In the hybrid mode, some of the BUM traffic replication gets offloaded to the first hop physical switch, achieving better performance.
Nuage Networks Virtualised Services Platform (VSP) Nuage Virtualised Services Platform (VSP) [51] provides SDN and policy based automation for cloud deployment. VSP was designed for large service providers and enterprises. The proprietary VSP solution supports clouds of all architectures and sizes, from large enterprise WANs to data centre private clouds, and some of the largest public clouds in the world.
Juniper Contrail Contrail Networking [52] is a SDN platform based on the open source network virtualisation project, OpenContrail. The Juniper platform orchestrates and automates creation of a highly scalable virtual network environment. This proprietary Contrail SDN solution includes cloud-native environments. As well as building virtual networks from 36
VMs and bare-metal servers, now Juniper customers can also use containers to create seamless multi-cloud environments.
HP Virtual Application Networks (VAN) HP Virtual Application Networks (VAN) [53] SDN Controller Software simplifies management provisioning and orchestration, providing a unified control point in a network running on OpenFlow. The proprietary HP Virtual Application Network provides a complete end to end SDN solution for creation of an agile, secure and scalable network. Based on HP FlexNetwork architecture, VAN delivers: scalable service and business agility; rapid and dynamic cloud application deployment; and increased IT efficiency with services orchestration. Deployment of VAN on top of the HP FlexNetwork architecture creates a unified platform with end to end control plan programmability for fast development of cloud applications and services.
Cisco Application Policy Infrastructure Controller (Cisco APIC) Cisco Application Policy Infrastructure Controller (APIC) [54] is a proprietary solution which is the unifying point of management and automation for the Application Centric Infrastructure (ACI) fabric. Cisco APIC provides centralised access to all fabric information. It supports flexible application provisioning across physical and virtual resources, and it optimises the application lifecycle for scale and performance.
Plexxi Control (Plexxi SDN) The use of Wavelength-Division Multiplexing (WDM) between switches enables dynamic allocation of bandwidth between Plexxi's top-of-rack switches using different spectrums of light. The proprietary Plexxi [55] SDN architecture divides the control plane 37
between a central controller and the individual switches. Plexxi's technologies include Plexxi Control, Plexxi Switch 1 and Affinity Networking APIs.
Plexxi Control is a tiered SDN controller that performs tasks that do not require real-time computation in the data path, e.g. planning and optimisation. Every Plexxi switch has its own control element to perform distributed processing for real-time forwarding. The distributed control element also offers resiliency and scalability. Plexxi Switch 1 is the physical layer of the product, a top-of-rack switch with 4x40 Gigabit Ethernet (GbE) ports and 32x10 GbE ports. Affinity Networking APIs provide northbound abstractions of the network to orchestration systems such as OpenStack Quantum. Plexxi offers two initial APIs. Workload Affinity API allows external systems, network overlays and analytical engines to communicate with Plexxi Control. The Network Orchestration API allows Plexxi Control to take information from workload requirements, converting it into instructions on how the network can satisfy them.
IRIS IRIS [36] is a proprietary SDN controller/framework, based on OpenFlow, designed to solve the availability and scalability issues of SDN. IRIS was built on the Beacon-like New IO (NIO) based event handler. A large portion of the IRIS functions take after those of Beacon and Floodlight. IRIS provides high availability with transparent failover from failure, plus multi-domain support with recursive network abstraction and horizontal scalability for carrier-grade networks.
38
Cyan Blue Planet Whilst many SDN services and products focus on the data centre, the proprietary Blue Planet [56] solution targets Cyan customers. Blue Planet solution can still be used in the data centre, but its main market is customers that have already purchased optical networking gear from Cyan. However, Cyan announced in late 2014 that Blue Planet WAN orchestration will work with some members of the Juniper MX and Cisco Aggregation Services Router (ASR) lines of routers, and that it plans to extend Blue Planet orchestration into NFV. Blue Planet SDN is multi-layer and scalable, with open APIs. It separates software from hardware, and allows software to manage service orchestration, network management, and control. Blue Planet enables fast development and service deployment in multi-vendor networking environments. It also enables network virtualisation and management over multiple layers of network
2.5
OPENFLOW
OpenFlow [57] is considered to be one of the first SDN standards. It is a communication protocol that allows a SDN controller to interact directly with a network device’s forwarding plane (such as routers and switches). These may be physical or virtual (based in a hypervisor). This direct interaction allows the environment to adapt efficiently to any change in business requirements.
39
Figure 2-3: OpenFlow version roadmap [43]
The OpenFlow protocol has developed over many iterations, as shown in Figure 2-3. Each of these OpenFlow version releases has incorporated new features. However, not all SDN hardware, for example switches, is keeping up to date with each version release. The differing features of the OpenFlow versions are shown in Table 2.1.
Although the OpenFlow protocol has existed for several years, and has been adopted and deployed by multiple vendors, there still remain a number of challenges that need to be resolved. These challenges centre around the implementation of hardware, conformance and interoperability. In addition to this, due to the large number of features the interoperability of switches is problematic, as different switches implement different features. Moreover, vendors may add proprietary features or enhancements, making many switches incompatible with one another [58].
The most common version of the OpenFlow protocol supported in hardware in 2017 is v1.3. This is the version that both the Allied Telesis switches under consideration for the
40
Whitireia School of IT network (ATx930 and ATx510) support as at 2017 [59], [60]. Also, some controllers only support earlier versions of OpenFlow.
Table 2.1: OpenFlow Feature set comparison [43]
2.6
NETWORK FUNCTION VIRTUALISATION (NFV)
The term Network Function Virtualisation (NFV) has recently been proposed as an effective means to decouple various functions of the network, including firewall, load balancing, Network Address Translation (NAT) and web proxy; moving them from existing as dedicated hardware and instead implementing them as purely software instances, existing on networking, storage and high volume servers [61]. NFV is a term that is often associated in conjunction with SDN in the literature.
41
2.7
GARTNER HYPE CYCLE
SDN has appeared in the Gartner Hype Cycle for Emerging Technologies, in various formats, since 2014. The Gartner Hype Cycle provides graphic representation of the both the levels of maturity, and the adoption of applications and technology. It aims to show how they are potentially relevant to being able to exploit new opportunities and solve real world business problems. The Gartner Hype Cycle methodology provides a view of the evolution of an application or technology over time, and provides insight to manage deployment within the context of an organisation’s goals [62]. The Gartner Hype Cycle is shown in Figure 2-4.
Figure 2-4: Gartner Hype Cycle [53]
The Gartner Hype Cycle is a tool created by Gartner, used widely in technology reporting. Businesses may use the Hype Cycle to navigate technology decisions in line with their 42
level of comfort with risk. Every stage in the cycle contains risks and opportunities. The Hype Cycle indicates five stages in the life cycle of technology, which overlap with one another. These stages are: “Technology Trigger; Peak of Inflated Expectations; Trough of Disillusionment; Slope of Enlightenment; and Plateau of Productivity” [63]. The five stages shown in Figure 2-4 are discussed further in the sections below.
Technology/Innovation Trigger Referring to the initial stage, Technology/Innovation Trigger is the stage where a technology is conceptualised. Prototypes may exist, but often there are no market studies or functional products. At this stage there is potential that drives media interest. Sometimes there may be proof of concept demonstrations [63].
Peak of Inflated Expectations Following on from the Technology/Innovation Trigger stage, implementation of the technology occurs, usually by early adopters. There is much publicity around implementations, both successful and unsuccessful, and the hype moves into the stage of Peak of Inflated Expectations [63].
Trough of Disillusionment After being at the Peak of Inflated Expectation, failures and flaws will lead to some people being disappointed with the technology. Some producers drop their products, or are unsuccessful. Continuing investments in other producers are dependent on problems being addressed successfully. This is referred to as the Trough of Disillusionment stage [63].
43
Slope of Enlightenment Following from the Trough of Disillusionment stage, the potential in the technology for future applications becomes more widely understood, and an increasing number of businesses test it in their environment, or implement it. Some produce further generations of the product. The technology has now moved into the stage known as the Slope of Enlightenment [63].
Plateau of Productivity Moving from the Slope of Enlightenment, the technology is widely implemented. Its position in the market, and its applications become well understood. Standards arise for the evaluation of technology providers. This stage of the hype cycle is referred to as the Plateau of Productivity [63].
In 2014, ‘Software-Defined Anything’ appeared in the Gartner Hype Cycle for Emerging Technologies in the Technology/Innovation Trigger stage, with the diagram notation predicting that a plateau will be reached in more than 10 years. The following year, ‘Software-Defined Security’ appeared in the Innovation Trigger stage, with the diagram notation predicting that a plateau will be reached in 5 to 10 years. In 2016, ‘SoftwareDefined Security’ appeared in the Gartner Hype Cycle for Emerging Technologies in the Peak of Inflated Expectations stage, with the diagram notation predicting 2 to 5 years to mainstream adoption. This hype cycle also includes ‘Software-Defined Anything’ which also appeared in the Peak of Inflated Expectations stage (on the verge of passing into the Trough of Disillusionment stage), with a prediction of 2 to 5 years to mainstream adoption. This is shown in Figure 2-5.
44
In 2017, ‘Software-Defined Security’ appeared in the Trough of Disillusionment stage, with the diagram notation predicting a plateau will be reached in 2 to 5 years.
SDN is currently in a trough of popularity, as initial excitement about the phenomenon has died down, and practical issues surrounding implementation have become apparent. It will be of continuing interest to watch SDN progress through the stages of the Gartner Hype Cycle for Emerging Technologies.
Figure 2-5: Gartner Hype Cycle for Emerging Technologies 2016 [56]
2.8
TECHNIQUES AND TOOLS
Simulators and emulators can be utilised for testing configurations and capabilities prior to real-world deployment. There are many SDN simulators and emulators available including Mininet, EstiNet, and NS3. A discussion of the tools that were selected for use in this research are discussed in the following section. 45
Mininet Mininet [9], is a very popular emulator, described as a system for being able to quickly prototype large networks using only the constrained resources contained in a single laptop. Mininet exports a Python API to create customisable topologies, experiments and types of node (including switch, controller, host and ‘other’). Mininet is distributed as a virtual machine, where all its dependencies are pre-installed and it can be run on common virtualisation technologies including VMware, VirtualBox and Xen [64]. Very large experimental tests can be performed using Mininet prior to deploying new SDN architecture solutions [65]. In one study, Mininet was used to emulate a data centre network [66]. Emulation tools included Virtual Box, the Mininet emulator and test-beds [14].
MiniEdit MiniEdit [67] is a simple Mininet Graphical User Interface (GUI) editor. MiniEdit provides a GUI to Mininet, an experimental tool that was created in order to demonstrate the way that Mininet is able to be extended.
Mininet-WiFi Mininet-WiFi [68] is an extension to Mininet that enables simulation of wireless networks using Access Points and WiFi Stations.
Vagrant An open sourced product, licenced by Massachusetts Institute of Technology (MIT), Vagrant [69] is a tool for the construction and management of virtualised development environments. Powerful and simple, Vagrant can manage virtual machines that are hosted 46
in Oracle VirtualBox (a full x86 virtualiser which is also open source with a GNU General Public License (GPL) v2 licence).
Vagrant enforces consistency by leveraging a declarative configuration file, describing all operating system configuration, packages, users, software requirements, and more. The same easy workflow is provided by Vagrant regardless of whether the user is a designer, operator or developer [70].
One aim of Vagrant is to mirror production environments, by providing the same configurations, packages, users, and operating system, whilst supplying users with the flexibility to use their favourite browser, Integrated Development Environment (IDE) and editor. In addition, Vagrant integrates with existing configuration management tools such as Ansible, Chef, Salt and Puppet, meaning the same scripts may be used to configure Vagrant as are used in production, promoting production parity [70].
Mobaxterm MobaXterm [71] is a tool for remote computing. It provides important remote networking tools such as Secure Shell (SSH), the X Window System (X11), Virtual Network Computing (VNC), Mobile Shell (Mosh), Remote Desktop Protocol (RDP), and File Transfer Protocol (FTP). MobaXterm also provides Unix commands such as rsync, bash, awk, ls, cat, grp and sed to a Windows desktop via a portable, single exe file that works out of the box.
There are many advantages from being able to have an all in one network application to control remote tasks. For example, when using SSH to connect to a server remotely, a 47
graphical Secure File Transfer Protocol (SFTP) pops up automatically to directly edit remote files. Using the embedded X server, the remote application also displays seamlessly on the Windows desktop. A free home version is available, or users can subscribe to the professional edition which has more features, customisation software and professional support
2.9
SUMMARY
There has been considerable hype surrounding SDN and it may be easy to assume that it is a well understood field which has enjoyed deployment by a great number of large IT organisations. In reality, only a small percentage of IT organisations make the claim that they are very familiar with SDN. So far, SDN is only for early adopters [72]. Currently, technologies to move existing networks to SDN are immature and scarce, as SDN only came into existence a few years ago [73]. There are many questions that exist at each level of SDN, and all of these need to be investigated for SDN to become commonplace in industry, rather than just for a few large organisations such as Google, Microsoft, and Amazon. The SDN community continues to work to address these issues [74].
SDN enables the abstraction of the data and control planes in a network. SDN is at an early stage of development and maturity, but shows great potential for the future direction of networking. Both open source and proprietary SDN solutions and projects are available. This research concentrates primarily on open source options.
An area that is closely related to SDN is IoT, an environment with a vast array of interconnected devices or objects. SDN lends itself to this environment very well.
48
The field of SDN is rapidly evolving. Open source projects have been subsumed into newer open source projects, or purchased and altered by vendors to become proprietary solutions. One of the main protocols utilised in SDN is OpenFlow. OpenFlow has passed through many versions, and different switch vendors have built their hardware to be compatible with different software versions. This can cause difficulty around compatibility and interoperability. Another term often used in conjunction with SDN is NFV, where various functions on the network are handled by virtual, as opposed to physical, technologies.
SDN has featured in the Gartner Hype Cycle for Emerging Technologies from its entry in 2014. SDN technologies are currently identified as being in the Trough of Disillusionment stage with a prediction of 2 to 5 years to mainstream adoption.
The Mininet simulator was utilised inside a Vagrant box, running within a VirtualBox environment. Benefits to running tests within a virtualised environment included knowing that all components were going to fit effectively together, and issues such as version incompatibilities were minimised or eliminated.
The next chapter provides an introduction, description and summary of the design strategy and research methodology employed in this research.
49
CHAPTER 3
RESEARCH DESIGN STRATEGY
This chapter describes the motivation, the design decisions, and the processes used to conduct this research. These processes have been employed to ensure the validity, reliability and reproducibility of the work presented.
3.1
MOTIVATION
The rapid development of the SDN paradigm and the rate at which new research and controllers/frameworks are created makes it difficult to categorise and compare controllers’/frameworks’ capabilities. For this reason, I have created a taxonomy of SDN frameworks. The taxonomy enables the comparison of a broad range of SDN controllers/frameworks and enables the identification of a set of the most suitable controllers/frameworks to consider in this research.
A set of representative use cases have been derived to evaluate whether the selected controllers/frameworks will be suitable for deployment in the Whitireia School of IT production network. These use cases encompass a diverse variety of real-world scenarios and demonstrate the required functionality for a framework to be considered ready for deployment. A Desk Evaluation technique has been used to determine whether the identified controllers/frameworks are capable of facilitating these use cases. Finally, simulations are used to verify the results of the desk evaluations.
50
3.1.1
Taxonomy
A taxonomy of SDN controllers/frameworks has been constructed by surveying existing literature and categorising the differentiating aspects of their implementations and capabilities. The taxonomy enables the comparison of SDN controllers/frameworks and is used to guide the selection of controllers/frameworks to evaluate for potential deployment. The taxonomy consists of both open source and proprietary solutions. Due to accessibility, the majority of the frameworks studied are open source. However, some proprietary controllers/frameworks are also discussed to ensure the study was suitably thorough, and as a reference to determine points of difference between the two categories.
The taxonomy consists of both broad categories, such as open source versus proprietary, as well as more specific features, such as programming language and support for multiple switches. This information is collated together to derive the features of the taxonomy and enable categorisation of new frameworks. Further research was conducted to separate actual SDN controllers/frameworks from SDN related features.
3.2
RESEARCH METHODOLOGY
This research leveraged aspects of an experimental research methodology, whereby experiments are conducted to evaluate the suitability of the solution.
3.2.1
Experimental Method
Experimental research is an extremely powerful research physic that is extensively used in the IT and domain science fields. Rather than being focussed on strict models and questionnaires, experimental research relies on direct observation of experiments to draw conclusions [35]. Use cases are often employed to investigate and analyse the behaviour 51
of a solution under different conditions [36]. This methodology aligns with the requirements of this research and has been deemed appropriate for this work.
3.2.2
Use Case Selection
Several use cases have been selected in order to investigate the capabilities of an SDN framework and determine the readiness of them to be applied in a production setting. The use cases have been derived from the capabilities of the existing Whitireia School of IT network, which is a live example of a complex production network with many varied facets. Seven of the essential network functions and uses have been identified as suitable use cases. Of these use cases, the three that represent the broadest range of capabilities are employed to evaluate the frameworks’ capabilities during the desk evaluation phase of the research. To verify the results of the desk evaluation the use cases are then explored via simulation of the network.
3.3
EVALUATION METHODS
In order to test the potential solutions against the proposed test conditions (use cases) two forms of evaluation were carried out and the results analysed. These evaluation techniques involve desk evaluation and simulation.
3.3.1
Evaluation of Software Against the Use Cases
The first stage of evaluating the shortlisted controller/framework software involves a desk evaluation. The desk evaluation enables the comparison and evaluation of the stated features of the controllers/frameworks against that of the use case requirements. This provides a theoretical answer as to the potential suitability of that controller/framework software as a solution to the particular need that use case identified.
52
3.3.2
Simulation of Use Cases
Simulations are employed to verify the findings of the desk evaluation. The controller/framework identified as most suitable for deployment in the desk evaluation phase is then experimented with via simulation. The Vagrant simulation tool and the Mininet emulator are used to perform the experiments to evaluate the software against each of the use cases. Further explanation of the networking tools Vagrant and Mininet is provided in Chapter 8.
3.4
SUMMARY
This chapter outlines the processes and methodologies employed during this research. These approaches help to ensure the studies validity and contribute to the reliability and reproducibility of the research.
A taxonomy is created by surveying existing literature to categorise and compare a wide range of SDN controller/framework software. The taxonomy is employed to create a shortlist of frameworks to investigate as potential solutions for the Whitireia School of IT network. An experimental research methodology is employed to evaluate the shortlisted frameworks. This methodology requires the identification and utilisation of use cases, which are derived from the existing network’s capabilities and functions. A Desk Evaluation technique is initially employed to evaluate the frameworks against the use cases. Simulation is then used to explore the readiness of the framework for deployment.
An investigation into network structure is provided in Chapter 4.
53
CHAPTER 4
NETWORK STRUCTURE
This chapter presents a new network architecture for the Whitireia School of IT that enables the adoption of SDN. The chapter first reviews the existing network topology before proposing a new, SDN-compatible, topology. The proposed topology simplifies the network structure, reducing the operational costs, improving resilience, security, and the granularity of control.
4.1
THE CURRENT SCHOOL OF IT NETWORK
The Whitireia School of IT network is diverse in structure, function and components, supporting hundreds of students with reliable wireless access, VPNs, multiple computing laboratories, multiple campuses and a data centre. Primary data from Whitireia’s enrolment records showed that the number of enrolled IT students grew from 162 students in Porirua in 2007 to 474 in 2017, (257 based in Porirua and Wellington, plus 217 based in Auckland). Correspondingly, the number of tutors and support staff has also increased in line with this figure. In 2007 the IT programs were delivered from a satellite Porirua campus only. In 2014, IT programmes at Whitireia Auckland began to be delivered using the School of IT network. In 2016 delivery commenced from the Dixon Street Wellington campus, under the umbrella of the Wellington ICT Graduate School. Delivery from Kapiti campus is planned to take place from early in 2018. The Whitireia School of IT network is in an almost constant state of change, with each change requiring significant alteration to both the infrastructure and its corresponding configuration. In 2007, the Whitireia School of IT network consisted of only 20 desktop computers on the network. Twenty student laptops and six tutor laptops were added to the network in 2008. A new 54
computer laboratory with a further 30 desktop computers was added to the network in 2009. Whitireia’s Auckland School of IT, consisting of 5 more computer laboratories joined the network in 2014, and in 2015 two computer laboratories at Dixon Street Wellington were added to the network in preparation for delivery under the Wellington ICT Graduate School.
The current School of IT network consists of a heterogeneous range of technologies and devices, due to the ad-hoc growth that occurred over the previous ten years. The resulting structure comprises an eclectic mix of devices, operating systems and hardware and software versions. The current network structure and devices are shown in Figure 4-1.
55
Figure 4-1: School of IT Network Diagram
56
The network is maintained at the main Whitireia campus in Porirua. Due to the internal layout of networking infrastructure at this campus, fibre connections terminate in an area shared with the main production network, in room E217. Tie lines connect these switches through to the School of IT networking room, E224. Switches that control the five IT computer laboratories and staff offices are divided between E217 and E224 due to the internal wall Ethernet cabling. The data centre containing blade servers for student work and staff research is housed in another building on campus, connected to E217 via a fibre link. Fibre also connects E217 through to A2, where the main polytechnic network infrastructure is located, and where the network joins the internet. The connection between E217 and E224 is via copper only, which introduces the possibility for a potential bottleneck.
Many different makes and models of networking equipment are used in the network, including Cisco, Linksys, Juniper, Allied Telesis, and Ubiquiti. Each of these brands is loaded with its own operating system, requiring it to be configured in its own language. Therefore, the network administrator needs to be competent in all of these languages, and be familiar with the inherent idiosyncrasies of both the hardware and software of every device.
4.1.1
A Detailed View of the Network
Based at the main campus in Porirua, the Whitireia School of IT network is a separate IT production network that operates alongside the rest of polytechnic network. The polytechnic consists of two internet connections. The main connection joins the rest of the polytechnic network in A block, while the School of IT network also has an alternate network connection (DTS) which connects directly from the School of IT server room in 57
E224. This additional internet connection enables networking research by circumventing the security restrictions of the polytechnic connection, such as port blocking.
Whitireia School of IT Porirua currently has four computer laboratories with 30 desktops each, located on the second floor of one building, plus one laboratory able to accommodate up to 30 laptops (wired or wireless). The School of IT network has been connected to a remote campus, located on Dixon Street in central Wellington, where the School of IT delivers content as part of the Wellington ICT Graduate School. This campus is joined to Porirua campus by a layer 2 VPN, with traffic travelling securely across VLANs. It is also joined to the School of IT Wireless network that runs separately from the main campus production wireless network. Seven access points deliver wireless networking for both students and staff working at the remote site.
Due to the growth of, and changes to, this network over time, there is a lack of formal documentation. The existing documentation is largely out of date and arranged in an ad hoc manner, making it challenging to determine the exact requirements when updating the network. In its current form, the network is not structured in a way that will easily lend itself to SDN, changes will need to be made to the network, aside from simply installing new hardware and software.
58
4.2
CURRENT LOGICAL DEPICTION OF THE NETWORK
Figure 4-2: Current logical depiction of the School of IT network
59
A logical view of the School of IT network is shown in Figure 4-2. The figure depicts that the (single) core switch forms a central point of the network, presenting a single point of failure. When planning any update to the network, such as a move towards a SDNbased infrastructure, the resilience and redundancy of the network must be considered.
4.3
SHOULD THE NETWORK STRUCTURE BE ALTERED TO MOVE TO SDN?
When contemplating a future migration to a SDN environment there are many decisions that must be made as to how to best structure the network. It is important to consider whether the existing network’s format and locations should be maintained under a new SDN deployment, or whether it is best to undertake the considerable task of altering the network structure such that it more easily lends itself to a SDN model.
Currently, the network is controlled by a ‘core’ switch (Cisco 3560G), which is located in E224 with no fibre access. Most of the network servers are connected to this core switch and various other switches in the E224 server room. The physical layout of the network has been examined, and consideration given to changing the physical layout of where the hardware is situated, with servers moving from E224 (the network server room) out to the Data Centre (in another building on Porirua campus) as a potential option. The Data Centre provides the benefit of an Uninterrupted Power Supply (UPS). There is presently no UPS on the School of IT network, which presents another serious reliability risk. Relocating the network infrastructure to the Data Centre also enables the core switch to be directly connected to the polytechnic’s fibre link to the Internet, removing the copper bottlenecks associated with the E224 and E217 server rooms. 60
Another question to consider is which brand, model, and version of switches should be employed in a new network deployment. Allied Telesis is Whitireia’s current supplier of networking equipment. A range of switches from Allied Telesis support both full SDN and SDN hybrid mode. The two switches that appear most suitable for implementation on the School of IT network are the ATx930 model (Appendix A) and the ATx510 model (Appendix B). The ATx930 model provides a higher powered switch and contains more memory. However, these are more expensive than the ATx510. After analysing the switch specifications, it has been determined that the ATx930 is appropriate as a ‘core’ switch whilst the ATx510 is sufficient to fulfil the requirements of the current classroom ‘laboratory level’ switches. The exact model of how these should fit together in the proposed network structure, and whether an instance of Open vSwitch is required, must also be considered. It is also important to determine the number of core-level switches required in the network. From a redundancy and contingency planning perspective, it has been determined sensible to have two. It has been determined that it is preferable to relocate the servers to the UPS protected Data Centre due to the direct fibre link.
Some changes have already been made within the network in (potential) preparation for a SDN implementation. One such change involved the replacement of the switch at the Dixon St Wellington campus. The aging legacy Cisco switch was replaced in 2017 with an Allied Telesis SDN capable switch ATx510, configured in hybrid mode, connected to and operating with the traditional network at present.
It is intended for the network to further expand in 2018 to another remote campus at a location north of Wellington (the Whitireia Kapiti campus). Currently, other Whitireia 61
faculties deliver their programmes from the Kapiti campus, but at September 2017, the School of IT had not yet commenced delivery at this location. There has been discussion about a Certificate course being delivered at the Kapiti campus imminently, with postgraduate IT qualifications following in the near future. To future proof the ability of the School of IT to deliver from the location, a laboratory within the Kapiti site was connected through to the main School of IT network in Porirua. As an interim measure, and because delivery was not yet live, the Cisco 3560G that was removed from Dixon street was relocated to the Kapiti campus. It is, however, intended that a SDN switch, such as an Allied Telesis ATx510, is purchased to run the School of IT presence at this site.
A new network architecture is required as the current network is unnecessarily complicated, and as explained above has been developed in an ad-hoc manner. The proposed architecture is presented in Figure 4-3. This logical diagram was developed to improve security, the granularity of control, and resilience.
4.4
SECURITY
A Security Appliance can be described as some form of device whose role it is to block unwanted traffic from a network. As these devices may carry out a number of security functions such as filtering of content, intrusion detection and firewalling, they are also known as Unified Threat Management (UTM) systems. These devices were conventionally deployed at the edge bordering the network to inspect the traffic before it entered the network [77].
When deciding upon the most suitable structure for the network, consideration must be given as to whether or not to include a Security Appliance. If a Security Appliance need 62
be included in the network design, then further consideration should be given as to the most appropriate position for placement. In addition to this, a decision is required as to whether to include a physical Security Appliance, or to implement this functionality virtually.
Administering security in a virtual environment is different from physical security, as the virtual network traffic may never depart from the hardware of the physical host, thus requiring a solution of virtual firewalls. Four varieties of virtual firewalls exist: a bespoke virtual security appliance which was designed for virtual network security; a traditional type of software firewall which has been installed on a guest virtual machine; a managed kernel process sitting on top of all virtual machine activity, on the host hypervisor; or a virtual switch which has additional security capability [78].
4.4.1
Open vSwitch
In contrast to traditional networking appliances, which generally achieve a high level of performance either through hardware or software, Open vSwitch was designed to be flexible and for general purpose use. One method of enhancing the security of packets in an SDN network is for the controller to add flow table entries on the switches, based on firewall rules [79].
Traditionally, firewalls have relied greatly upon a restricted network topology, using entry points in order to provide functional security protection [61]. Traditional firewall functionality is implemented on proprietary vendor appliances (also known as middleboxes), however the versatility and flexibility of these tends to be limited, and they normally lack a general interface for programming [80]. 63
By deploying virtual firewalls, users can stop being dependent on a fixed topology and entry points, as they can be put on any virtual machine, provided the virtual machine is able to provide the resources required. Additionally, as virtual firewalls exist in software, they can be moved and reconfigured quickly and with ease which allows them to adapt to changes in the virtual network. The mobility and flexibility of firewalls existing in software relies on traffic steering which is reliable in addition to being fast and dynamic. SDN has the ability to provide the traffic engineering that is required by virtual firewalls.
4.4.2
VNGuard
One solution proposed for the design and management of virtual firewalls based on SDN and the concept of network function virtualisation is VNGuard. VNGuard is a framework which provides effective management of virtual firewalls, in order to safeguard virtual networks. It leverages features provided by SDN and NFV, and defines a high level firewall policy language. VNGuard determines optimal placement for the virtual firewall, and adapts the virtual firewalls to virtual network changes [61].
4.4.3
SDN Security Considerations
There are multiple attributes that cause a SDN environment to be very well suited to the implementation of a manageable and secure environment. The flow paradigm is very suitable for security processing, as it offers a model that is free from traditional routing constraints. The (logically) centralised control allows for performance and monitoring of threats throughout the entire network. Granular management of policy may be based on organisational, geographical, service and application criteria, as opposed to physical configuration [81]. 64
Security policies that are resource-based allow for consolidated management of diverse devices which have various risk of threats, from firewalls that are very secure and security appliances that allow access to devices. Flexible and dynamic change to security policies are provided by programmatic control. Flexible path management allows fast containment and isolation of intrusions without other network users being impacted. By enabling real time and historical network state and performance data to blend, SDN is able to facilitate the making of decisions, the achievement of flexibility and simplicity of operation while improving security throughout a common infrastructure [81].
A SDN environment lends itself to agility in terms of rapid reconfiguration of end user devices to incorporate the diversity that the Whitireia School of IT requires. For example, a laboratory may be configured with an appropriate image for level 5 certificate students to use from 1pm to 3.50pm. The laboratory could quickly be changed via a SDN configuration change, with a different image on the hardware for the postgraduate students to use in that same laboratory between 4pm and 6pm. SDN will allow for the laboratory to be reimaged in minutes, as opposed to the current two hour process. The ability for rapid reconfiguration of resources adds to the benefits provided by the SDN paradigm to students and assist with their journey of learning.
The proposed design for the future network architecture, Figure 4-3, provides a high degree of granularity down to device level. The flexible and dynamic nature of security policies of the SDN controllers in this network improves security.
65
4.5
THE RISK OF HAVING A CONTROLLER BASED IN THE CLOUD
Both the quantity and location of controllers within a SDN environment was an important point for consideration. If a SDN structure is applied to an internal network, and the controller sits within that network, there is potential for failure on that network if the gateway to the internet is disturbed. On the other hand, if the controller is situated outside of the network in the Cloud, problems may also occur with reachability. SDN devices situated within the confines of the network will be expecting a handshake with their external controller. If a device cannot contact its cloud-based controller, it may cease to function in time as it has not received the keep alive reassurance that it expected to continue functioning effectively.
For resilience in the proposed network, the location of the SDN controller will provide a single point of failure if it is located at one campus. A cloud-based failover solution is recommended.
4.6
PROPOSED DESIGN
For SDN to be implemented, the network will benefit from being restructured. A depiction of the proposed network architecture developed in this research is shown in Figure 4-3.
66
Figure 4-3: Proposed Future Logical Diagram
67
4.6.1
Top Layer Physical E Block (Proposed)
When contemplating network design, it is necessary to consider how much redundancy is required around the ‘core’ of the network, the ATx930 switch. Figure 4-4 explores the possibility of using a fan-out switch architecture.
Figure 4-4: Top layer physical (possible solution using fan-out) Options to address redundancy include the question of whether an additional ‘fan out’ switch, possibly in the form of an ATx510 as shown in Figure 4-4 is preferable, or whether a better solution for full redundancy will be to have each of the ATx930 switches connecting to each of the ATx510 switches directly. The second option will provide more
68
robust redundancy however it will involve significantly greater network infrastructure, and cost.
If one ATx930 switch is utilised, and connected to each of the ATx510 switches, the fan out ATx510 switch will not be required. If failure occurred on this switch, the second ATx930 can be deployed to take its place. The negative aspect to this model is that it will require manual intervention in the case of a failure, as a networking team member will need to be physically onsite to transfer cables over from the failed ATx930 switch to the replacement ATx930 switch. The benefit to this model of redundancy is that no fan out switch is required, and the cost will be lower as only one network connection to the ATx930 is required. The second ATx930 can be deployed upon failure. The switch can remain in place, but it will require a staff member to come onsite to transfer cables. This is not an ideal solution, as the network is not staffed onsite overnight, on weekends or on public holidays.
4.6.2
Controller to be Installed in Hardware or Software?
One major decision that must be addressed is what form the network controller/s should take. One option is for controllers to be installed on physical hardware. Another option that exists is for controllers to exist purely as software components [82].
4.6.3
Controller Placement
In a SDN environment, there is no one best practice for determining the quantity of controllers, or for determining controller placement within a network. It is possible to have one, or multiple controllers in communication with each other in a network. There are differing controller architecture options available. The controller architecture may be 69
flat, whereby each controller assumes the same role. Another scenario involves a hierarchical structure where both ‘normal’ and ‘master controllers’ exist. There are many different approaches that can be followed. Some objectives for ideal placement of controllers are to minimise latency between controllers and nodes in the network. It is also important that resilience constraints are fulfilled when making a decision on placement of controllers [82]. Resilience of the network is an important consideration when network design is evaluated [83].
4.6.4
Controller Appliance
In theory, a controller should be installed, either virtually or physically, and just work. However, particularly with a leading edge system, there are many components that may cause issues or problems with installation. This has been the experience with previous attempts to install and run SDN controller software at the Whitireia School of IT, including a capstone project that was conducted in mid-2015.
Figure 4-5 demonstrates all of the components that comprise the package required to run a SDN controller within a network.
70
Figure 4-5: SDN Controller ‘Appliance’
The various levels indicated in Figure 4-5 can be described as follows. At infrastructure level (data plane) there is a switch. This switch must be capable of operating with a SDN protocol, such as OpenFlow, and a licence installed on it to allow this protocol to operate. The switch runs a specific operating system, and may be operating in either full SDN, or hybrid mode. Different models of switch are capable of running different versions of OpenFlow, so this must also be taken into account when choosing an appropriate switch.
71
At the controller (control plane) level, controller software is written in some form of programming language (for example C++, Java, Python). Libraries, a framework, and a compiler are all required to make this controller software run. Each may have various versions which may be incompatible with one another. These components must run on a machine, either virtual or physical. At some point, everything needs to run on some form of physical machine, somewhere. This is likely to be on some form of Unix operating system, of which many varieties are possible. Each of these may create problems with versions, as has been the experience of Whitireia School of IT. Immaturity of product also manifests itself in a lack of backwards compatibility, leading to major problems around version control, availability, and choice. For many organisations running production networks and requiring a high performance uptime, the risk of failure due to immature product and version incompatibility issues will likely discourage installation at this point in time.
One solution proposed here is to put together a ‘SDN Controller Appliance’. If a solution is proposed that has been fully installed and tested, is deployed into physical boxes, then effectively a network administrator can ‘plug the appliance into the network and it will work’. This Appliance will comprise: a switch, preloaded with the appropriate licences; and potentially a desktop, running an operating system, containing the controller software and its libraries, and compiler, and framework. Only by pre-installing the software and components, having tested versions and compatibility, can the network administrator proceed with the confidence that this ‘sandboxed’ solution will likely operate effectively.
72
4.6.5
What Will be the Most Suitable Network Structure to Employ?
To adopt an SDN approach one must determine how much of the network is to become programmable. This section discusses two approaches: SDN down to dumb switches, and full SDN throughout the network.
SDN down to dumb switches at laboratory level The first option is to push SDN down through the layers to dumb switches at classroom laboratory level, which allows the same ‘flows’ or data through ports to each computer in the VLAN. This model is similar to the design of the current network.
The benefit to this model is the ability to repurpose existing equipment, which reduces costs. This can be used as a model that will be of use in other deployments where limitation of funds is a realistic issue. Deployment from a partial to a full SDN environment can be undertaken in a staged manner, as finances and resource availability allows. The negatives of this option are that the network will be SDN to a certain level only, then regress back to a legacy (traditional) network at the endpoint, as each port from the last switch to desktop will have the same configuration and therefore the same limitations.
Full SDN per port In this option, SDN will flow fully through to the end device, by utilising SDN hardware and software at every level through the network. The benefits of this option are that the full functionality of SDN to an end level in the network will be realised. The disadvantages of this option are that the cost will be higher, as all new switches will have to be purchased up front. Depending on the size and complexity of the network, this will 73
incur significant cost, which can cause the SDN implementation to be delayed, or discarded altogether.
Figure 4-6: Holistic view (logical), Whitireia School of IT network
4.6.6
Network Resilience
There are five components of resilience, (R’s), these are: recovery; responsiveness; robustness; redundancy; and resourcefulness [84]. Robustness includes reliability, which refers to an ability to tolerate, and the absorption of disturbances and crises. Redundancy involves having an excess in capacity and back-up systems, enabling maintenance of core functionalities in event of disturbance, thus meaning an organisation will be less likely to collapse under stress or in the event of failure in its infrastructure if the design of the critical infrastructure includes diversity in overlapping methods, strategies, policies, or services. Resourcefulness refers to the ability of being able to adapt in a crisis, to respond 74
flexibly and if possible to turn a negative into a positive. Response means being able to quickly mobilise when a crisis occurs, gathering information and quickly communicating to those who need it. Recovery is the ability for a system to be adaptive, flexible, and able to return to some normality quickly after a crisis; evolving to adapt to changing circumstances and incorporating new situations into business strategies [84].
All of these R’s must be considered when designing a network for the Whitireia School of IT. Consideration must be given to which is critical infrastructure, that must keep running or be able to recover from failure very quickly. Extra hardware to ensure redundancy will achieve this, but will also increase the cost. If all parts of the network have redundancy, the risk will reduce significantly, but the cost of equipment purchase will in turn increase. It cannot be recommended that a resilient network use decommissioned hardware for redundancy, as this may offer a false economy with the equipment dying quickly or failing to start when required in time of emergency. Constraints to be considered when making this decision include funding, organisation preferred supplier contracts, equipment costs, physical location, and accessibility. Figure 4-6 shows a holistic logical view of the proposed Whitireia School of IT network.
4.7
THE RECOMMENDED NETWORK IMPLEMENTATION
As well as the decisions around network structure, other considerations must be taken into account including such issues as budgetary constraints and timing. It must be contemplated whether it is preferable that potential restructure work is implemented upfront, or whether implementation should occur in a staged approach, with silos of the network altered at different times. The latter approach is recommended as it follows an Agile approach, with different portions of network changes introduced at different times 75
whilst the network continues to operate (although changes will be incorporated at times that do not adversely affect students and staff, such as during end of semester breaks in case of any failures). This will provide the greatest benefits afforded by SDN, with the least risk to the smooth operation of the live network.
4.8
A SIMPLIFIED NETWORK STRUCTURE
Figure 4-7 illustrates a vastly simplified representation of how the network could be structured to run the use cases in the Whitireia School of IT network. The use cases are identified in Chapter 5.
Figure 4-7: Simplified network structure Figure 4-7 illustrates that the central point, and point at which conventional ‘routing’ occurs is at a high level SDN switch (an ATx930 switch is illustrated in this model). Controller software sits outside (potentially in the cloud, or alternatively in a physical box 76
somewhere in the network). The controller will communicate with the ATx930 switch via the control plane. The ATx930 will also connect to SDN switches that comprise the data plane. Allied Telesis ATx510 switches are used in this example.
In this model, the ATx930 switch will be responsible for managing the traffic flow rules sent to it by the controller. External traffic will be directed out various internet connections, through the standard Whitireia internet (REANNZ), or the Whitireia School of IT alternative DTS internet connection, or alternatively directed to the Whitireia School of IT data centre.
4.8.1
Simplified Switch Port Layout Description
Figure 4-8 shows graphically how the different components are connected to the switch. Ports 1, 2, and 3 are connected the two ATx510 switches, and to the controller; and Ports 10 and 12 are connected to the external internet connection boxes.
77
Figure 4-8: Switch port layout description
4.9
SUMMARY
This chapter presented a summary of the existing network topology and its features and then proposed a new, simplified, and more resilient topology that would enable SDN to be deployed throughout the Whitireia School of IT network. The chapter discussed the advantages and disadvantages of each solution, and explained the tradeoffs between different degrees of adoption, such as cost and functionality.
The new topology developed in this research increases resilience, security, and efficiency, while reducing complexity and operational costs. In addition, a simplified network structure has been articulated to enable testing of the use cases in this research. The use cases employed in the course of this research are discussed in Chapter 5. 78
CHAPTER 5
USE CASES
Seven use cases have been derived from the functionality and services provided by the existing production Whitireia School of IT network. These use cases have been specifically selected to represent a broad range of functions that must be supportable by a SDN framework for it to be considered viable for deployment. This chapter explains these use cases and reasons their selection.
5.1
SCHOOL OF IT WIRELESS NETWORK
The Whitireia School of IT Wireless Network provides an important service to both students and staff. Many students bring multiple devices to class (e.g. laptops, mobile phones and tablets), which all must attach to a reliable wireless network in order for them to be fully utilised. As there is no dedicated study space for IT students, and the wider polytechnic network does not have the appropriate image displayed on their network, it is critical that the wireless network operates effectively. The wireless component of the network is also very public and under constant scrutiny, therefore any production implementation requires high degrees of reliability in order to ensure the quality of the service. The Whitireia School of IT Wireless Network is an ideal test case for the viability of a SDN solution as it enables the examination of the framework’s reliability.
5.2
LIBRARY ACCESS
The terms of the Wellington ICT Graduate School agreement enable Whitireia students enrolled in the Wellington ICT Graduate School papers access to the digital libraries provided by Victoria University of Wellington. This connection enables Whitireia students to access a vast source of academic literature. The connection is currently 79
achieved with a layer 2 Virtual Private Network (VPN) that has been established by REANNZ between two Autonomous Systems (AS) for Victoria University of Wellington and Whitireia Polytechnic in Porirua. Through this link, four Virtual Local Area Networks (VLANs) pass traffic privately between the two organisations via a tunnel.
This use case emphasises an important feature of a research institute’s networking infrastructure. Whitireia School of IT researchers often leverage the network for both teaching and research projects, such as the aforementioned library connection. Therefore, any suitable SDN controller/framework requires the ability to be easily customised and applied to different research projects. The Library Access use case enables the evaluation of the extensibility of a controller/framework and its ability to facilitate research.
5.3
REMOTE SITES
The Whitireia School of IT network is controlled and operated from the main Whitireia campus in Porirua. Three additional campuses also deliver content and function as remote sites of this student and staff production network.
Whitireia School of IT Auckland offers IT programmes that run alongside the programmes delivered in Porirua. Security is critical in this deployment; thus the networks are connected via a layer 2 VPN. Whitireia School of IT Auckland network staff members have the ability to utilise the resources contained in the Porirua data centre for delivery of their operating systems courses, which are required by capstone and postgraduate students, and for student and staff research. Similarly, the Wellington ICT Graduate School is situated in the Wellington Central Business District, and is effectively
80
a remote laboratory which also connects to Whitireia School of IT Porirua via a layer 2 VPN.
Whitireia School of IT is scheduled to begin delivering content to students at the Kapiti campus in 2018. To achieve this, a layer 2 VPN has been installed between Kapiti and Porirua campuses. At this point it is envisaged that laptops and Odroids will be used at this location. To prepare for the possible future implementation of SDN on the network, a SDN capable switch (ATx510) has been installed at the Whitireia Kapiti campus.
In 2010, Whitireia received a research gift from Weta Digital, initially consisting of approximately 330 blade servers, and more recently another 160. A data centre has been established in a remote building on campus. As the Whitireia School of IT Data Centre is physically located in a separate building on campus, this is also treated as a remote resource. Fast and reliable connection to this remotely located data centre is vital for teaching and support to the local community, providing free hosting for projects developed for local iwi.
Evaluation of SDN controller/framework against the Remote Sites use case identified whether there are open source SDN controllers/frameworks that can achieve the functionality required to facilitate this problem. If so, the SDN network should be able to accommodate arbitrarily large networks.
5.4
DEPLOYMENT
The Whitireia School of IT network currently consists of five computer laboratories onsite in Porirua, and three remote campuses (Dixon St for delivery of Wellington ICT 81
Graduate School, Kapiti and Auckland). Laptops and desktop computers on the network are imaged prior to the commencement of each semester or trimester (two or three times per year, depending on the campus and the operation schedule). Each laboratory receives the image via multicast. It is essential that the ability to multicast is retained upon the adoption of SDN as it dramatically reduces the time and resources required to ensure consistency of computers and currency of software.
The network continues to grow every year, and deployment across multiple locations is vital, with the operation of Dixon Street, Auckland and Kapiti campuses. Auckland Whitireia School of IT has historically managed its own image deployment, using resources provided by main campus of Whitireia School of IT in Porirua. To ensure consistency however, it makes sense for the image to be remotely deployed to each remote location from the main campus located in Porirua.
Issues that add to the complexity of the image being multicast to multiple VLANs involve deployment to different locations, via heterogeneous hardware, stored in multiple locations. Security is also an important issue to keep in mind when proposing SDN solutions to this use case. It is necessary to evaluate SDN controllers/frameworks against the Deployment use case to ascertain which controllers/frameworks are able to handle the complexity that is involved in different aspects of this scenario.
5.5
MULTIPLE GATEWAYS
The Whitireia School of IT network has two internet links. The standard REANNZ link carries the majority of internet traffic, which passes through the main Whitireia production network firewall, and is subject to the filters and restrictions placed upon it at 82
this point. It is important to note that the SDN layer 2 VPN was set up to circumnavigate this firewall.
An alternative internet connection was initially set up in response to the Conficker Worm, to enable redundancy for the Whitireia School of IT network, with the purpose of allowing courses to continue running if any network outages occurred with the main internet link. Upon notification to the administrator of an internet outage (automatically monitored by software), traffic can be manually routed out the alternative (DTS) internet connection. In line with in-depth applied learning, Whitireia School of IT students sometimes need to carry out actions disallowed by the main polytechnic production network. Having the alternate connection is essential as it allows for redundancy in times of failure, and provides a way around port blocking that occurs by necessity on the main production network. Potential SDN solutions must be evaluated to determine whether they are capable of facilitating multiple internet connections.
5.6
WHITIREIA SCHOOL OF IT VPN
In times of disaster, it is sometimes unwise, or simply not allowed, for students or staff to work onsite. However, they may need to continue to work remotely. When the magnitude 7.8 Kaikoura (NZ) earthquake struck in November 2016, damage was sustained to many Whitireia buildings. For safety, the decision was made to only allow students onsite when they were accompanied by a staff member. At this time, the IT summer school programme was just about to commence and was due to run through until early February 2017. As a business continuity and resilience measure an Internet Key Exchange Version 2 (IKEV2) VPN was established to provide students access to the network and their networked drives remotely. Investigation into what effect SDN will 83
have on this network environment is essential to understanding whether the solution can facilitate remote access and the additional security precautions it entails.
5.7
SECURITY LEVELS AND AUTHENTICATION
Security is an important consideration on the Whitireia School of IT network, and is fundamental to several of the use cases. Different levels of security and user credentials/authentication must be reliably applied to staff and students across campuses. Within these groups, further levels of security division exist, for example regular staff members have no access to Victoria University of Wellington libraries, as opposed to the staff members involved with teaching on Wellington ICT Graduate School programme, and staff recognised in the Whitireia and Victoria University of Wellington MOU as permitted to access the Victoria University of Wellington digital libraries.
5.8
SUMMARY
Seven use cases have been derived from production network functionalities and behaviours. These use cases provide a broad range of features that can be used to evaluate potential SDN solutions. Each use case has been selected to highlight a specific criteria of a viable solution, such as reliability, scalability, and security.
In addition to the evaluation of potentially suitable SDN controller/framework software against required use cases, it was necessary to understand the overall structure of the Whitireia School of IT network. This is crucial to ascertain whether SDN can be applied to the network in its current form, or whether it will be advisable, or necessary, to alter network structure at the same time as introducing the fundamentally new network solution. 84
Chapter 6 presents the taxonomy constructed to select potentially suitable SDN controllers/frameworks for this research and presents the results of the desk evaluation to select the SDN controller/framework products for further investigation.
85
CHAPTER 6
TAXONOMY
A taxonomy of open source SDN frameworks has been constructed, in order to select potentially suitable frameworks for further evaluation. The taxonomy’s dimensions, or categorical attributes, have been derived to best describe the definitive aspects of SDN controllers/frameworks. This taxonomy presents a unified language for discussing SDN controllers/frameworks and is a means to compare and contrast their capabilities. Existing works have also been examined, and their interpretations leveraged, in order to construct a definitive taxonomy for SDN controllers/frameworks. An iterative methodology, described by Nickerson et al. [83] has been employed to construct the taxonomy. The taxonomy is later applied to an extensive set of SDN controllers/frameworks, and is employed to identify new research opportunities. Finally, it is shown how the taxonomy enables the direct comparison of SDN controllers/frameworks by using it to inform the selection of a suitable SDN controller/framework for specific use cases.
6.1
RELATED TAXONOMIES
One important issue that exists in many different disciplines is how to classify objects in a particular domain into a taxonomy [85]. A taxonomy may be described as a classification scheme which provides ways to understand both the similarities as well as the differences between objects being studied. Development of a taxonomy is a complex process [83]. One desired outcome from the construction of a taxonomy is to identify further research opportunities [86], this taxonomy explores a large body of existing literature.
86
A taxonomy starts empirically as opposed to conceptually, the goal being the classification of cases in accordance with their measured similarity on the variables under observation. The process of classifying items in terms of their similarities can be broken down into the two essential approaches of taxonomy and typology. A taxonomy is primarily empirical and a typology mainly conceptual [85].
6.2
METHODOLOGY
The methodology followed was iterative and thus must have conditions to determine when to terminate. These conditions are both objective and subjective. A fundamental objective ending condition is that the taxonomy must satisfy the definition of a taxonomy, specifically that it consists of dimensions each with mutually exclusive and collectively exhaustive characteristics. The conditions required for a taxonomy to be useful are that it is comprehensive, robust, concise, extendible, and explanatory. These form the minimal subjective conditions for the iterations to terminate. The iterative nature of this methodology allows the addition, removal, division, and merging of characteristics as it draws nearer to a concise and robust artefact [85].
The method followed in this research was to analyse relevant literature and products, documenting the features discovered through this analysis. New products were added to the analysis incorporating any additional features to the documentation until the inclusion of new products stopped identifying additional features to the analysis. At this point the features were combined by theme into categories to form the taxonomy. The resulting taxonomy has been reviewed to ensure that the categories are sufficiently differentiated. A total of 114 SDN controllers/frameworks and features were analysed to identify the categories, documented in Section 6.3. 87
6.3
CATEGORIES
Several categories were selected for the construction of this taxonomy. The definitions of these categories are now discussed.
Accessibility
(open or closed)
Accessibility describes the openness of the system in terms of programming and configuration. The majority of SDN controllers/frameworks employ an open approach, where users can freely customise the controllers/frameworks to meet their specific use case requirements. However, a number of the most widely used controllers/frameworks are proprietary, limiting the accessibility of the system.
Open:
Many SDN controllers/frameworks foster an open environment in which
the code is freely available and open source. This enables users to customise deployments, etc. Notable examples of widely used, yet open controllers/frameworks are OpenDaylight and Floodlight.
Closed:
A SDN controllers/frameworks is classified as having a closed codebase
if it is a proprietary solution that restricts customisation from end users. A common example of this are the largest of the SDN controllers/frameworks, often developed specifically for an individual company, such as Google, and Juniper Contrail.
Scale
(Data centre, carrier grade, or LAN)
Scale describes the scope of the network managed by the SDN controller. Many SDN controllers are designed to support large scale operations such as data centres, and backbone carrier networks as opposed to organisational LANs. 88
Data Centre: Some SDN controllers/frameworks are of a scale sufficient to manage the traffic within an entire data centre. An example of this is NEC ProgrammableFlow.
Carrier grade: A SDN controllers/frameworks must be well tested, extremely reliable, and have proven abilities to be referred to as carrier grade. One controller/framework that fits into this category is ONOS.
LAN:
A LAN environment may lend itself to a SDN controller/framework. One
example of an appropriate controller/framework for a LAN environment is Faucet.
Currency of OpenFlow version
(pre-v1.3 or v1.3 or higher than v1.3)
The version of OpenFlow supported by the controller/framework software. The current industry standard is v1.3.
Pre v1.3:
Some controllers only support OpenFlow versions lower than v1.3. A
well-known SDN controller/framework that falls into this category is POX.
v1.3:
Many SDN controller/framework software supports v1.3, one example is
OpenDaylight.
Above v1.3:
Some controllers/frameworks support higher versions of OpenFlow than
v1.3. Ryu is capable of operating with various OpenFlow versions, up to v1.5.
89
Type
(SDN controller/framework or SDN feature)
Upon initial research there are many products that appear to be SDN controllers/frameworks. Further research shows that some of these are actually features, as opposed to actual SDN controllers/frameworks.
Controller:
A SDN controller/framework is an application built to enable
intelligent networking by managing flow control. An example of a SDN controller/framework is NOX.
Features:
There are many SDN features that exist, with products related to,
but not actually, a SDN controller/framework. One example of a SDN related feature is the OpenStack project Neutron.
Currency of project
(ongoing or stalled)
Currency of the project is used to determine how up to date the product is. Some projects are under active development whilst others have stalled or even been discarded.
Ongoing projects:
Faucet is an example of an emerging project under
active development and review. The inaugural Faucet conference was held at Lawrence Berkeley National Laboratory in October 2017.
Stalled projects:
When a project stagnates or stalls, there is very little
interest in its continuing development. One project whose development has stalled in recent times is Project Indigo.
90
Hardware compatibility
(current
for
hardware,
not
current
for
hardware) The version of OpenFlow supported by the controller software determines the switch hardware that the controller/framework can interact with.
Current:
A SDN controller software compatible with current
hardware (switch) products available is Faucet, which runs OpenFlow v1.3, supported by Allied Telesis SDN capable switches.
Not current:
Some SDN controllers/frameworks use OpenFlow
versions either too old or too recent for hardware solutions to keep up with. An example of a product running an older OpenFlow version (therefore with more limited functionality) is NOX.
Language
(controller/framework’s
programming
language
e.g. Java) There is a wide variety of languages used to program the selection of SDN controllers/frameworks. Examples of languages used are Python and Java.
Inheritance
(forking of projects)
Inheritance relates to the forking of the underlying codebase that the product operates with. Some products are utilising unique code, some are related to other open source projects, and others have moved over time from use in open source to proprietary solutions.
91
Unique code:
No related products
Related products open source:
Some open source projects have forked to form new
projects. One example of this is Beacon forking to Floodlight.
Open source to proprietary:
Some projects started their existence as open source
projects before they were purchased and modified to form a proprietary SDN solution. An example of this is OpenContrail being modified and sold in a proprietary format by Juniper as Juniper Contrail.
Development Community
(whether project is active, and its accessibility)
The level of contribution of the SDN development community is a relevant consideration, as it determines how active research and development is.
Active community: (yes):
ONOS has a very active development community,
with many different roles established for members to contribute to.
Active community (no):
Indigo is an example of a project that no longer has
an active development community.
Accessible community (yes):
Faucet has a development community that is local
to New Zealand, and therefore very accessible.
Accessible community (no):
Cherry is a Korean project, therefore proximity to
support, and potential language barriers are considerations. 92
6.4
DESK EVALUATION USING THE TAXONOMY
The method of using desk evaluation to validate a product is a recognised component of the research and development cycle [87]. The categories now defined in the taxonomy were analysed against the research objective to determine which criteria are desirable in each
of
the
categories
specified
in
the
taxonomy
to
select
potential
frameworks/controllers for this research. An explanation of desirability as it relates specifically to application to the Whitireia School of IT network follows.
6.5
DESIRABLE CRITERIA IN EACH CATEGORY
As the Whitireia School of IT network is a research and teaching network in a polytechnic environment in a small country, purchase of a potentially expensive proprietary solution is not feasible. Therefore, the desirable criterion of Accessibility is open (source).
The scale of network that a controller/framework is designed for can sometimes align with ease of installation and efficiency of functions intended for a LAN sized environment. As functioning and uptime of the Whitireia School of IT network is not vital to other areas of the polytechnic, a product that fits a LAN sized environment is the most desirable criterion in this category.
The version of OpenFlow supported by a SDN controller/framework is vital. At present v1.3 is the industry standard. Anything older than v1.3 will not support all available features, anything higher than v1.3 may not be compatible with hardware unless it is backwards compatible. Therefore, the desirable criterion for currency of OpenFlow version is v1.3. 93
Whether a product listed in literature related to SDN controllers/frameworks is actually a product, or a feature related to SDN is an important distinction. For this exercise, it is products that are actual SDN controllers/frameworks that are most desirable.
To future proof the network it is important that a project related to the product is continually being researched, further developed and improved. The desirable criterion for this category therefore is ongoing.
If a product has bleeding edge technology, including protocols that are not yet followed by hardware manufacturers, then this technology is wasted as it cannot be implemented. Similarly, if an old version of technology is included (for example OpenFlow 1.0), full compatibility with hardware will not be achieved. The desirable criterion for this category is current for hardware.
The preference of language used in controller software will differ for individual organisations, based on their internal skill set of staff, or availability of external skilled staff. For Whitireia School of IT, the preferred language is Python, due to the skill set of relevant staff members.
Inheritance (or forking) of projects is important to this selection process from a developer’s perspective. Knowing the history of the code, and where else it is being used is an important consideration. As the Whitireia School of IT network runs alongside the main Whitireia production network it is also interesting to know whether an open source project has forked to a proprietary product that may be of interest for use in the wider polytechnic. The desired criterion is this category is open source to proprietary. 94
Whitireia School of IT has a number of staff who are actively researching. As there will likely be ongoing releases containing improvements, it is very desirable to select a product which has an active development community. For practical advice and ‘handson’ support when required it is desirable to have a local, accessible community.
6.6
ANALYSIS OF PRODUCTS ACROSS CRITERIA
CATEGORY
CRITERIA
PRODUCT Faucet
OpenDaylight
Floodlight
SDN type
Controller/Framework Feature
X
X
X
Accessibility
Open Closed
X
X
X
Scale
Data centre Carrier LAN
X
X
OpenFlow version
X
Pre-v.3 v1.3
X
X
higher than v1.3 Currency of project
Ongoing
Hardware compatibility
Compatible
X X
X
X
X
X
X
X
X
Stalled Incompatible Python
X
Java Go Language
Ruby C++ C Proprietary No inheritance
Inheritance
Related open source
X X
X
Open source to proprietary Active Development Community
X
X
X
X
X
Not active Accessible Inaccessible
X
Figure 6-1: Taxonomy category evaluation 95
The discussion points in Section 6.5 indicate the desired criteria for each category. The products were analysed to select those that met the desired criteria in the categories. The products that most comprehensively fulfilled the desire criteria across the most categories were selected for further analysis. From the selection process shown in Figure 6-1, SDN controller/framework software Faucet, OpenDaylight, and Floodlight were selected from a large number of products as most fit for purpose in terms of category evaluation.
6.7 A
SUMMARY taxonomy
has
been
developed,
based
on
the
analysis
of
114
SDN
controllers/frameworks and features. Open source and proprietary SDN products were compared, then categorised. Desk analysis of this taxonomy against available SDN controller/framework products has been used to select the three candidates for further study.
Chapter 7 presents a desk evaluation of use cases from the Whitireia School of IT network for the candidate controllers/frameworks.
96
CHAPTER 7
DESK EVALUATION OF THE USE CASES
It was determined in the previous chapter through analysis of categories and features that the SDN controller/framework software Faucet, OpenDaylight, and Floodlight were the most suited to this research. These products are now compared against selected use cases from Chapter 5, to determine the overall most likely candidate(s) suitable for implementation and deployment to the Whitireia School of IT network.
7.1
WHITIREIA SCHOOL OF IT WIRELESS NETWORK USE CASE
A wireless network is operated by the Whitireia School of IT for students and staff. Each of the three proposed controllers/frameworks were evaluated against the Whitireia School of IT Wireless Network use case, detailed in section 5.1. Results of this evaluation follow.
7.1.1
Result of Desk Evaluation Against the School of IT Wireless Network Use Case
The literature was searched for mention of wireless implementation and reliability/availability for heterogeneous devices in relation to the three SDN controllers/frameworks.
Faucet is compatible with wireless networking hardware [88]. When a client connects to a wireless access point, it will be served by OpenFlow enabled Open vSwitch, and will be under the control of Faucet [88]. Faucet has an active development community based in New Zealand who are able to provide support if required.
97
Faucet offers support for redundant controllers, the use of numerous controllers enables high availability [89].
No evidence can be found in literature regarding Floodlight’s wireless compatibility. Floodlight has been proven reliable, during long term 24/7 testing it was able to cope with an average workload [90].
OpenDaylight is capable of operating in a wireless network. An algorithm which provides load balancing has been implemented in the OpenDaylight controller/framework which acts to manage switch port load using SDN architecture. A design in the experiment consists of an OpenFlow switch based in hardware, with a wireless host connected [91].
Research states that the OpenDaylight controller/framework may be utilised as a main open source SDN controller/framework where a user can create reliable, modern, and smart networks so long as the user is capable of contributing to or making their own source code improvements [92].
Results of the desk evaluation of the three SDN controllers/frameworks against the School of IT Wireless Network use case indicate that Faucet is the most desirable controller in this instance, it is proven to work with a wireless network, together with the benefits of easy communication and hands on assistance from a local development community. OpenDaylight is the second preferred controller/framework, fulfilling most requirements, with Floodlight the least suitable, due to a lack of documentation detailing usage with wireless networks.
98
7.2
LIBRARY ACCESS USE CASE
The main purpose of this use case is to allow Wellington ICT Graduate School students enrolled via Whitireia access to digital library subscriptions through another institution’s link. This section provides an evaluation of the three proposed controllers/frameworks against the Library Access use case, following research into the literature.
One criteria vital for this use case is a controller/framework’s compatibility with traditional (non-SDN) hardware. Faucet has been proven to interoperate with non SDN devices in a network [89]. Faucet is compatible with heterogeneous hardware, supporting multiple vendors of hardware, and running in production at multiple sites [45].
Faucet supports VLAN routing in a similar way to traditional non SDN switches and routers, however at present routing is configured between all VLANs or none. In the future it is planned that Faucet will allow the user to configure routing between just the VLANs specified [93].
Floodlight is capable of handling networks that are a mix of OpenFlow and non OpenFlow [31]. There has been a security vulnerability identified in the Floodlight controller/framework, allowing an attacker who has access to an OpenFlow controller to selectively deny the communication between the controller and an individual switch. This will eventually disable the switch [94]. The vulnerability of the Floodlight controller exists in the OpenFlow interface whereby an attacker can overflow internal data structure that is used to track switches and their ports in the network. This overflow will cause full utilisation of the Central Processing Unit (CPU), which will effectively deny the controller functionality. This will eventually crash the Floodlight service [95]. 99
Scott-Hayward [96] states that currently there is not a single SDN controller/framework which includes each of the features identified for a secure, resilient, and robust SDN controller/framework, highlighting the gap that exists between potential SDN controller solutions, and the actual level of security in controller designs currently [96].
The literature relating to OpenDaylight included no specific detail relating to security.
7.2.1
Result of Desk Evaluation Against the Library Access Use Case
The controller selected as most suitable for use against the Library Access use case was again Faucet as literature reports Faucet is proven to support VLAN routing and heterogeneous hardware at multiple sites.
The other controller/framework that may be considered for implementation is OpenDaylight as it appears to fit most of the requirements. Least desirable was Floodlight, primary due to the issues around security that were recorded in literature.
7.3
REMOTE SITES USE CASE
The purpose of this use case is to enable the connection of remote sites including Wellington ICT Graduate School Dixon St, Kapiti, and Auckland campuses, and the Whitireia School of IT Data Centre. The following section provides an evaluation of each of the three proposed controllers/frameworks against the Remote Sites use case. The primary driver for this use case was to test scalability, performance, and security in a multi-site environment. It is expected that the School of IT network will continue to grow over time, so extensibility is an important issue to consider.
100
Performance is vital in regard to the requirements of the Remote Sites use case. Faucet has been deployed in a number of settings, notably including the Open Networking Foundation, where an instance of Faucet runs the office’s network. Faucet is capable of delivering high forwarding performance utilising switch hardware. It enables operators the ability to add and deploy network features quickly, in many instances without the need to alter (or restart) hardware [89]. Faucet’s ability to upgrade the controller in under one second, with the network still running and without having to reboot the hardware helps with security and preventing zero-day attacks [88].
Faucet supports routing VLANs in a way that is similar to traditional non SDN switches and routers. At the present point in time however, routing is configured between either all VLANS or none. In the future it is anticipated that Faucet will have the ability to allow users to configure routing between just the VLANs specified [93]. Research states that Faucet provides network scalability [88].
It appears that Faucet should run at remote sites, in an environment managed by VLANs which allows total isolation and total customisation of security policy on a per port basis, without any alterations to the switch required [89].
Floodlight is extensible, offering a module-loading system which enables extension and enhancement easily [31]. Floodlight is multithreaded, and is designed to offer high performance [31]. However, as previously stated in the Library Access use case, issues exist around security vulnerabilities regarding the Floodlight controller/framework. Shalimov et. al [90] reported that security analysis highlighted a number of possible security vulnerabilities of tested controllers/frameworks which can make them targets for 101
malware attacks. This analysis included Floodlight. In addition to this; Liang, Kawashima, and Matsuo [97] report Floodlight is not considered to be very scalable on large networks, as it contains limitations in relation to both scalability and performance. The issue of security in SDN as a whole needs careful consideration. Chourishi et. al [98]
state that security is one of the very crucial problematic areas that has emerged in the SDN environment and that SDN itself is natively insecure due to the fact that it takes
away boundaries that existed in a traditional hardware network, for example firewalls that were intended to maintain a secure environment [98].
The scalability of OpenDaylight has improved through releases. The release of Lithium showed an improvement in scalability when connecting 1750 switches to a sole controller, managing tens of thousands of flows [97]. A later release, Carbon, offered further significant improvements in the areas of security and network programmability [100].
7.3.1
Result of Desk Evaluation Against the Remote Sites Use Case
The controller selected as suitable for use against the Remote Sites use case is Faucet. Faucet was chosen from results shown in literature as the most appropriate controller to be considered for implementation on the Whitireia School of IT network as it has been shown to be scalable and extensible in reported deployments. Floodlight is also reported to be scalable and extensible, but the reports of potential issues with security lessen its appeal for selection. It is also reported that the scalability of OpenDaylight has continually improved with new releases.
102
7.4
SUMMARY
Based on the desk evaluation conducted of SDN controllers/frameworks against the use cases, Faucet was selected as a suitable open source controller software to move forward to simulation testing, for a number of reasons. Faucet appeared to be the closest fit to the use case requirements, defined for the diverse Whitireia School of IT network in Section 5.1. The first use case was the School of IT Wireless Network, which included requirements for wireless implementation and reliability/availability for heterogeneous devices. The second use case, Library Access, included compatibility and security as major requirements. The primary requirements to consider for the Remote Sites use case included scalability, performance, and security.
Another important reason why Faucet was determined appropriate was that a development team was resident locally in New Zealand, and therefore available for support as required. At this time, there are no technical staff in the Whitireia School of IT team with SDN production implementation experience. A close working relationship has developed since 2015 with Victoria University Wellington in response to the Memorandum of Understanding between the two organisations relating to research into SDN solutions. Victoria University are involved with evaluation of Faucet SDN, as are a number of other institutions in New Zealand.
The ability to contribute back to the open source SDN community will be beneficial to all. Being able to share details of issues encountered, and workarounds or solutions will add to the quantity of open source SDN implementation material available, as this is very scarce at present. This will aid other organisations and tertiary institutions when they plan to move toward a SDN environment. 103
OpenDaylight is a controller/framework that may also be suitable to implement on the network as it fits with many of the categories above. From the research done specific to implementation in the Whitireia School of IT network, Floodlight is the least suitable contender of the three shortlisted software.
Faucet has been selected as a likely candidate to deploy on the Whitireia School of IT network, Chapter 8 discusses how virtual testing of this open source SDN software may take place.
104
CHAPTER 8
USE CASE IMPLEMENTATION
The readiness of SDN frameworks for production networking was investigated. As research was being conducted in an emerging area of technology, it was decided to test via simulation to provide a proof of concept before proceeding to test in a physical testbed. Vagrant was used to overcome installation versioning issues and provide a stable VM for these simulations. Initial testbed installations encountered multiple versioning issues due to the immaturity of the software environment. This chapter describes the method of simulation employed and physical testing of the use cases conducted.
8.1
SCHOOL OF IT WIRELESS NETWORK USE CASE
A simulation environment was set up as a testbed for the School of IT Wireless Network use case using Vagrant to set up the virtual machine, with Mininet-WiFi [101] and Faucet [102] then installed.
Testing was carried out with Mininet-WiFi, refer to the topology in Figure 8-1. This topology represents the School of IT Wireless Network with three APs and multiple stations connected. This demonstrates that the functionality exists to operate the wireless network. Faucet operates on a wireless network therefore Faucet is an appropriate choice for this use case.
105
Figure 8-1: Example of Mininet-WiFi topology [101]
8.2
LIBRARY ACCESS USE CASE
Initial testing was conducted for the Library Access use case in a simulated environment using Mininet within Vagrant. To fully implement this use case in the simulated environment, two Mininet VMs needed to be connected using a tunnelling protocol. This was then tested using a physical silo on the School of IT network connected to a remote site.
The Library Access use case has been successfully tested using a physical silo on the School of IT production network and a silo set up on the remote institution using the Faucet controller and Pica8 SDN switches. This physical test environment was set up in a computer laboratory (E224) and was tested end to end using Faucet as the controller. This testing was conducted via a layer 2 private tunnel between the two networks. End 106
users were able to successfully access external digital libraries through a connection from the remote institution. Optimisation will be required, as this has been tested as a proof of concept only, and manual configuration was required for each use.
8.3
REMOTE SITES USE CASE
For the Remote Sites use case a simulation was developed. The simulation was set up using Vagrant, Mininet [103], and MiniEdit. Figure 8-2 shows a Mininet interpretation of a generic abstracted SDN LAN solution, with one controller, one ATx930 switch acting as the ‘core’ of the network, and two SDN capable switches representing classroom/laboratory ‘access’ switches, with end devices attaching to these.
Figure 8-2: Generic Abstracted SDN LAN solution
The deployment to remote sites has been successfully demonstrated using the topology shown in Figure 8-2. Indications from this testing show that the Remote Sites use case is 107
able to be implemented in a SDN environment, and Faucet has the functionality necessary to carry out the required activities.
8.4
SUMMARY
Initial testing via the Mininet simulation tool in a Vagrant virtual environment proved that a successful proof of concept can be constructed to simulate Faucet running a virtualised version of the Whitireia School of IT network.
Successful simulations of the Whitireia School of IT Wireless Network, Library Access and Remote Sites use cases have been created and tested. The use of simulation tools in this research proved a useful method of resolving issues prior to the introduction of added complexity inherent in physical testing.
In addition to the simulations, a physical silo of the Whitireia School of IT live production network was constructed and connected to a remote institution, providing access to external digital libraries available through the remote institution. This physical testbed was used to successfully test the Library Access use case.
The testing done to date through simulation and physical testing supports the choice of the Faucet SDN controller for future development.
108
CHAPTER 9
CONCLUSION
This research investigated two research questions. The literature was analysed to identify the current status of SDN controllers/frameworks. A taxonomy was created and used to evaluate the SDN controllers/frameworks identified, from this three were shortlisted as potential candidates. Seven use cases were identified from the Whitireia School of IT, and from this three were chosen for desk evaluation and selection of a suitable controller/framework for implementation. The controller selected, Faucet, was then used to test implementation of the three use cases.
9.1
RESEARCH PROBLEMS/OBJECTIVES
The following research questions were posed: “Is there an open source SDN framework suitable to implement on the Whitireia School of IT network?”; and “What other practical changes need to be made to the network in order for a future SDN implementation to become a viable option?”
The findings from this research indicate that Faucet is the most suitable candidate, as it was shown through evaluation against the taxonomy and evaluation against the use cases, to most closely meet the requirements identified, as discussed in Chapters 6 and 7.
Adopting a SDN structure will be a useful direction for the Whitireia School of IT to consider adopting in the future, but not imminently. The current hardware and architecture will need to be updated to support SDN, and maximise the benefits of the granularity afforded by a full SDN implementation, as discussed in Chapter 4.
109
9.2
RECOMMENDATIONS
The overall recommendation for the Whitireia School of IT is to implement Faucet in a staged approach, creating a model to test each stage prior to physical implementation. The Whitireia School of IT network supports both students and staff. It is a production network serving hundreds of users at multiple sites, and needs to remain reliable and available at all times.
This thesis was prepared at a relatively early stage of SDN. Considerations included evaluation as to which open source SDN software may be suitable to implement on the Whitireia School of IT network. This network is fully under the control of Whitireia School of IT, enabling the network to be altered to allow IT students and staff more academic freedom than they are offered on the wider Whitireia production network, which has to run effectively to support all areas and faculties of the polytechnic.
Any changes made to the Whitireia School of IT network will be contained to IT students and staff, so will pose a low risk to the polytechnic overall. It is, however, absolutely essential that the School of IT network continues to run efficiently, to support student learning, and to further staff research. A failure in network operation will be catastrophic if functionality is lost, therefore any move to SDN is one that must be very carefully thought out, planned, and implemented.
9.2.1
Physical Network
Consideration was given in the thesis to the necessary practical changes needed to facilitate a future SDN implementation on the Whitireia School of IT network. Options considered included introducing SDN to the network in its current structure, or 110
restructuring the network to make it a better fit for SDN, and how far through the network SDN runs, including the granularity to end devices.
The structure of the network is another issue that was investigated through the course of this thesis. At the end of the research, it was still to be decided when a SDN approach was going to be implemented. When the decision goes ahead to proceed with a SDN configuration, the preferred option is to completely redesign the network from scratch, which involves relocating equipment and infrastructure rather than tailoring an open source SDN solution around the shape of network that exists at the moment. It is recommended that when a SDN approach is implemented, that the network structure alters accordingly.
As described in Chapter 4, the research suggests that the best design for this network will involve a physical restructure, moving equipment and infrastructure between different buildings to overcome issues between copper and fibre networking. This move will involve considerable planning, and will be subject to budget restrictions and signoff.
The Whitireia School of IT will be a very interesting network to conduct physical testing on as products progress in maturity and versions become more stable.
Experience constructing the simulations showed incompatibility between versions of the Operating Systems, simulation software and controller software plus associated tools. There were gaps in the documentation, and mismatches with current versions of the frameworks reflecting the rapid evolution the field is undergoing and the lack of maturity
111
in the tools for this environment. The use of Vagrant-based virtual machines overcame many of the compatibility issues and enabled rapid deployment of new simulations.
Experience deploying physical hardware added another layer of complexity, with the addition of further compatibility issues plus the cost and complexity of hardware and licenses. It is recommended that implementation of SDN should be considered for the Whitireia School of IT network as this will allow for rapid reconfiguration of devices allowing optimum levels of usage. It appears from this research that this will not be possible until both the open source SDN products including controller/framework software, and associated hardware becomes sufficiently stable, allowing a greater degree of compatibility with hardware.
9.2.2
Deployment
The initial literature investigated in Chapter 2 indicated that the phenomenon of SDN was almost mainstream. However, most large scale SDN deployments are currently based on proprietary solutions, built or amended to fit exactly to a prescribed infrastructure. Some literature regarding open source deployment actually referred to theoretical deployment, based in a test environment. Some actual deployments that had taken place on a production network referred to very small and simple networks, some running off only one switch. As previously discussed, SDN is in the Hype Cycle trough of popularity phase at present. This research reports multiple issues with practical implementation, confirming that this stage is still appropriate.
112
The technology is not mature enough at this point in time to ensure a stable transition of the complete network. Running of this production network is considered essential for serving both students and staff at multiple locations around New Zealand.
The simulation tools and technologies used for the use case implementations described in Chapter 8 showed that Faucet can be tested in a virtual environment. The virtual environment, including versions, can then be moved to a physical test environment. When testing is complete in the physical environment, a portioned off silo of the live production network can be moved to SDN running alongside the traditional network. When the silo network operates error free, work on the next silo should commence, following an Agile approach.
This staged move to SDN is advisable, silos of the network can be chosen and moved to SDN, operating in conjunction with the traditional legacy network. At this point, the structure of the network moves to a hybrid model, incorporating both traditional networking operating systems, approaches and devices, and SDN. As the silos are progressively tested and prove to operate effectively, the next silo can be added. Over time in the staged implementation approach, the proportions of silo in the traditional network will lesson, and the percentage in the SDN component will grow. Once the network reaches the stage where the SDN components are all running effectively, with all bugs and major issues dealt with, and risks mitigated, Whitireia School of IT can switch the final silo over, so that the entire network is operating under an SDN model. It will be prudent at this point to leave the traditional legacy running in the background for a period of time, ready for rapid back-out procedures if this is deemed necessary, in line with use of sound change management practices. After a pre-determined period of time, 113
if it is not required, the traditional network can be decommissioned, with the network devices used for practical laboratory work in networking classes. A full analysis of the risks and benefits surrounding the decommissioning of the traditional network will have to be carried out and carefully considered before any decision are made in this regard.
9.2.3
Controller/Framework
The open source SDN controller Faucet has been selected as the most suitable candidate for future deployment to the Whitireia School of IT network. One reason for this included the location of the development team within New Zealand, and the fact that it is currently deployed on a small production network in Wellington. Some expertise already exists with the collaboration partners at Victoria University of Wellington.
As reported in Chapters 7 and 8, desk evaluation of open source software against selected use cases yielded the result that Faucet is the most suitable candidate to test for deployment.
Initial investigations into the range of open source SDN software available yielded a wide range of possibilities. Research involved gathering as much information as possible, from as many sources as possible. A total of 114 SDN controllers/frameworks and features were identified. An overview of the resulting taxonomy is described in Chapter 6, this was utilised to select software candidates for this research. The three open source SDN controllers/frameworks determined as possible candidates for implementation to the Whitireia School of IT network were Faucet, OpenDaylight, and Floodlight.
114
Faucet is a suitable candidate for deployment to the Whitireia School of IT network. The network in its current form is at present not adequately documented, due in part to rapid growth, with an ad-hoc system of adding network components as and when required, using heterogeneous hardware. Currently, the structure of the School of IT network will not support conversion to SDN without further (future) work being carried out.
9.2.4
Use Cases
Seven practical use cases were constructed, that incorporated actual requirements of the Whitireia School of IT network. From this list of seven, three were selected for desk evaluation against Faucet, OpenDaylight, and Floodlight. The three use cases selected for evaluation were School of IT Wireless, Library Access, and Remote Sites. Details of these use cases may be found in Chapter 5, Use Cases. The desk evaluation indicated that Faucet is a likely contender for implementation. Faucet was then used to test the three selected use cases. Chapter 8 provides details of this testing.
9.3
FUTURE WORK
The research identified seven use cases, three of which have been evaluated in this research. The remaining four should be evaluated in future work. In addition, the research identified a number of other areas for future research.
Future evaluation of use cases Evaluation of the four remaining use cases is required. These are: Deployment; Multiple Gateways; Whitireia School of IT VPN; and Security Levels and Authentication, as identified in Chapter 5 Use Cases.
115
Firewall/security research The issue of firewall structure and location is one component requiring further in depth consideration before any implementation can be considered. The best practice firewall and overall security considerations for the Whitireia School of IT network running a SDN environment require further research to determine the optimal balance between hardware and software options, and their placement within the network.
Wireless use cases Further work on wireless/IoT environments is required to refine the Whitireia School of IT Wireless Network use case to include different levels of security and control. This needs to be simulated and tested on the Whitireia School of IT Porirua wireless network prior to expansion out to remote campuses. Issues such as bandwidth overcrowding and contention require investigation.
Controller location This investigation began as research into whether there was an open source controller/framework available that is mature enough to implement on the School of IT network. Another consideration is the overall structure, and how the components fit together. One issue stemming from the research which raises concern is the introduction of only one single controller.
This research considered the question of how many controllers should be set up; how these controllers will failover; and where the controller(s) should be located (e.g. local or cloud-based). From a redundancy perspective it is prudent to employ three controllers, with a failover system to maintain control. 116
If a cloud-based solution is selected as being most appropriate, research needs to be undertaken as to how the controllers will be accessed. Consideration needs to be given as to whether a cloud solution is the most appropriate, given that the remote sites such as Auckland, Dixon Street, and Kapiti will be impacted if there are network problems at the Porirua campus, and the controller is situated on site within the network. A cloud-based approach could ensure continuity at the remote sites even if there is an outage at the Porirua campus.
9.4
CONTRIBUTIONS
This thesis makes the following contributions that benefit knowledge for the Whitireia School of IT, the SDN research community, and the IT industry in general.
Providing a categorisation of SDN products and features, open source and proprietary: A taxonomy of open source SDN frameworks has been constructed, in order to select frameworks potentially suitable for testing. The categorisation of SDN products and features differentiated between aspects such as open source and proprietary solutions plus the differing capabilities of products;
Clearly identifying what are SDN controllers/frameworks as opposed to SDN features: Further to categorisation into SDN products and features, the solutions were separated into SDN controllers/frameworks (as opposed to SDN features);
Investigating the practical aspects of moving from a current, diverse traditionally networked production environment to SDN: From the research conducted it 117
appeared apparent that there had been considerable interest from an academic, or theoretical viewpoint of introducing SDN to a networking environment. However, documentation on actual requirements needed to move from a currently operating, diverse traditionally networked production environment to SDN was essentially non-existent. This document aims to contribute knowledge to facilitate an easier decision making process for organisations contemplating this move in the future;
Identifying and developing appropriate use cases: This thesis records construction of relevant use cases. Open source and proprietary SDN products were compared and categorised to analyse suitability against those selected use cases. The School of IT network is a valuable model to investigate as a potential match for SDN, as it is unique and diverse, and has interesting use case possibilities;
Conducting simulation of the use cases: Simulation of selected use cases allowed for the environment to be tested in a cost-effective manner prior to the expense of hardware and software purchase; and
Considering use case implementation: The readiness of SDN frameworks for production networking was investigated. Consideration of the implementation of these use cases demonstrated that certain functionalities were achievable, thus affording an organisation the confidence that certain outcomes would be possible.
118
9.5
LIMITATIONS OF THIS RESEARCH
This research was based on the Whitireia School of IT network, and investigation of only three of a number of possible use cases.
The experience of this research indicates that due to the immaturity of SDN as a field of technology, there are many challenges that exist in respect of enabling actual physical deployment in a complex production networking environment. There are multiple versions of operating systems, protocols, and hardware. This results in compatibility and interoperability issues. At this point in time these are major problems, which lead to proposed solutions not being viable, and not even being able to be tested on physical equipment properly.
Scope Actual implementation of a SDN structure on Whitireia School of IT is out of scope of this work. However, dependent on sufficient managerial support including resourcing and funding, it is recommended that the Whitireia School of IT adopt a silo implementation of a SDN structure at some point in near future, preferably in a staged manner.
9.6
SUMMARY
The answer to these research questions is both yes, and no. Yes, there is a suitable framework available (Faucet), but no, at the present point in time, the School of IT network does not exist in a structure where it will be possible to convert to SDN without further (future) work being carried out.
119
The Whitireia School of IT network began as a small side network for IT students, to allow them to carry out functions that are not be possible on the Polytechnic’s production network due to security constraints. As such, the network has received very little financial resourcing. Over time, purchase decisions have had to be made largely based on price. The resulting network comprises a heterogeneous range of hardware and software, including a significant number of donated and recycled items. To fully adopt a SDN structure, it is necessary to redesign the network, which will involve purchasing new infrastructure, and moving existing infrastructure.
120
REFERENCES
[1] ‘REANNZ abbreviation stands for Research and Education Advanced Network New Zealand’, All Acronyms. [Online]. Available: https://www.allacronyms.com/REANNZ/Research_and_Education_Advanced_Ne twork_New_Zealand. [Accessed: 11-Sep-2017]. [2] ‘REANNZ • What we do’. [Online]. Available: https://reannz.co.nz/about/what-wedo/. [Accessed: 11-Sep-2017]. [3] K. Bakshi, ‘Considerations for software defined networking (SDN): Approaches and use cases’, in Aerospace Conference, 2013 IEEE, Big Sky, MT, 2013, pp. 1–9. [4] D. Levin, M. Canini, S. Schmid, F. Schaffert, and A. Feldmann, ‘Panopticon: Reaping the Benefits of Incremental SDN Deployment in Enterprise Networks’, in 2014 USENIX Annual Technical Conference (USENIX ATC 14), 2014, pp. 333–345. [5] R. Jain and S. Paul, ‘Network virtualization and software defined networking for cloud computing: a survey’, IEEE Commun. Mag., vol. 51, no. 11, pp. 24–31, 2013. [6] K. Kirkpatrick, ‘Software-defined networking’, Commun. ACM, vol. 56, no. 9, pp. 16–19, Sep. 2013. [7] N. McKeown et al., ‘OpenFlow: Enabling innovation in campus networks’, ACM SIGCOMM Comput. Commun. Rev., vol. Volume 38, no. 2, Apr. 2008. [8] C.-S. Li and W. Liao, ‘Software defined networks’, IEEE Commun. Mag., vol. 51, no. 2, pp. 113–114, 2013. [9] S. Rowshanrad, S. Namvarasl, V. Abdi, M. Hajizadeh, and M. Keshtgary, ‘A survey on SDN, the future of networking’, J. Adv. Comput. Sci. Technol., vol. 3, no. 2, pp. 232–248, 2014. [10] M. Jarschel, T. Zinner, T. Ho\s sfeld, P. Tran-Gia, and W. Kellerer, ‘Interfaces, attributes, and use cases: A compass for SDN’, IEEE Commun. Mag., vol. 52, no. 6, pp. 210–217, 2014. [11] ‘What are SDN Controllers (or SDN Controller Platforms)?’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/sdn/definitions/sdn-controllers/. [Accessed: 26-Aug-2017]. [12] R. Kirichek, A. Vladyko, M. Zakharov, and A. Koucheryavy, ‘Model networks for internet of things and SDN’, in Advanced Communication Technology (ICACT), 2016 18th International Conference on, 2016, pp. 76–79. [13] M. Kobayashi et al., ‘Maturing of OpenFlow and Software-defined Networking through deployments’, Comput. Netw., vol. 61, pp. 151–175, 2014. [14] S. Salsano, P. L. Ventre, L. Prete, G. Siracusano, M. Gerola, and E. Salvadori, ‘OSHI-Open Source Hybrid IP/SDN networking (and its emulation on Mininet and on distributed SDN testbeds)’, in 2014 Third European Workshop on Software Defined Networks, 2014, pp. 13–18. [15] C. Staff, ‘A purpose-built global network: Google’s move to SDN’, Commun. ACM, vol. 59, no. 3, pp. 46–54, 2016. [16] N. Feamster et al., ‘SDX: A Software Defined Internet Exchange’, Open Netw. Summit, 2013. [17] H. Kim and N. Feamster, ‘Improving network management with software defined networking’, Commun. Mag. IEEE, vol. 51, no. 2, pp. 114–119, 2013. 121
[18] ‘Fulton Schools Deploy Software-Defined Networks in New Data Center | Tech Learning’. [Online]. Available: http://www.techlearning.com/resources/0003/fulton-schools-deploysoftwaredefined-networks-in-new-data-center/69888. [Accessed: 09-Sep-2016]. [19] F. Xia, L. T. Yang, L. Wang, and A. Vinel, ‘Internet of things’, Int. J. Commun. Syst., vol. 25, no. 9, p. 1101, 2012. [20] Z. Qin, G. Denker, C. Giannelli, P. Bellavista, and N. Venkatasubramanian, ‘A Software Defined Networking architecture for the Internet-of-Things’, 2014, pp. 1– 9. [21] A. Hakiri, P. Berthou, A. Gokhale, and S. Abdellatif, ‘Publish/subscribe-enabled software defined networking for efficient and scalable IoT communications’, IEEE Commun. Mag., vol. 53, no. 9, pp. 48–54, Sep. 2015. [22] biouser, ‘Bristol Is Open - Open Programmable City’, Bristol Is Open. [Online]. Available: https://www.bristolisopen.com/. [Accessed: 06-Nov-2017]. [23] ‘Open Source vs. Proprietary Software’, GreenNet, 26-Apr-2008. [Online]. Available: https://www.greennet.org.uk/support/open-source-vs-proprietarysoftware. [Accessed: 09-Sep-2017]. [24] ‘What is the Difference Between Commercial and Open Source?’ . [25] M. Stevens, B. Ng, D. Streader, and I. Welch, ‘Global and local knowledge in SDN’, in Telecommunication Networks and Applications Conference (ITNAC), 2015 International, 2015, pp. 237–243. [26] Trema: Full-Stack OpenFlow Framework in Ruby. Trema, 2017. [27] ‘Beacon | SDN & NFV Open Source Project from Stanford University’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/projects/beacon/. [Accessed: 21-Aug-2017]. [28] ‘SDN Series Part Three: NOX, the Original OpenFlow Controller’, The New Stack, 15-Dec-2014. . [29] ‘Kandoo’, GitHub. [Online]. Available: https://github.com/kandoo. [Accessed: 22Aug-2017]. [30] Yeganeh, Soheil H and Ganjali, Yashar, ‘Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications’, in Proceedings of the first workshop on Hot topics in software defined networks, Helsinki, Finland, 2012, pp. 19–24. [31] ‘Floodlight OpenFlow Controller -Project Floodlight’. [Online]. Available: http://www.projectfloodlight.org/floodlight/. [Accessed: 14-Sep-2016]. [32] R. Wallner and R. Cannistra, ‘An SDN approach: quality of service using big switch’s floodlight open-source controller’, Proc. Asia-Pac. Adv. Netw., vol. 35, pp. 14–19, 2013. [33] ‘OpenContrail is an open source network virtualization platform for the cloud.’ [Online]. Available: http://www.opencontrail.org/. [Accessed: 22-Aug-2017]. [34] ‘Prototype | POForwarding’. . [35] S. H. Yeganeh and Y. Ganjali, ‘Beehive: Towards a Simple Abstraction for Scalable Software-Defined Networking’, 2014, pp. 1–7. [36] IRIS: Openflow Controller by ETRI. ETRI SDN Research Projects, 2017. [37] ‘OpenMUL SDN Controller | SDN & NFV Open Source Project from KulCl’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/projects/openmulcontroller/. [Accessed: 22-Aug-2017]. [38] ‘Open Network Operating System (ONOS) | SDN & NFV Open Source Proj’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/projects/on-labopen-network-operating-system-onos/. [Accessed: 04-Sep-2016]. 122
[39] R. Khondoker, A. Zaalouk, R. Marx, and K. Bayarou, ‘Feature-based comparison and selection of Software Defined Networking (SDN) controllers’, in Computer Applications and Information Systems (WCCAIS), 2014 World Congress on, 2014, pp. 1–7. [40] ‘Products | Lumina Networks’. . [41] ‘Products | Lumina Networks’. . [42] ‘What is an OpenDaylight Controller?’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/sdn/definitions/sdn-controllers/opendaylightcontroller/. [Accessed: 29-Sep-2017]. [43] ‘Platform Overview’, OpenDaylight. . [44] ‘Cherry-project’, GitHub. [Online]. Available: https://github.com/Cherry-project. [Accessed: 19-Aug-2017]. [45] ‘FAUCET SDN’. . [46] J. Bailey, ‘FAUCET SDN: FAUCET quickstart’. . [47] ‘REANNZ/faucet’, GitHub. [Online]. Available: https://github.com/REANNZ/faucet. [Accessed: 04-Sep-2016]. [48] ‘42948.pdf’. [Online]. Available: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/ 42948.pdf. [Accessed: 26-Aug-2017]. [49] ‘NEC ProgrammableFlow’. [Online]. Available: http://www.nec.com/en/global/prod/pflow/. [Accessed: 11-Sep-2017]. [50] ‘NSX Controller’. [Online]. Available: https://pubs.vmware.com/NSX6/topic/com.vmware.nsx.admin.doc/GUID-69010816-CADD-4BEB-89158C8E2C044E0B.html. [Accessed: 29-Sep-2017]. [51] ‘Virtualized Services Platform’, Nuage Networks. [Online]. Available: http://www.nuagenetworks.net/products/virtualized-services-platform/. [Accessed: 29-Sep-2017]. [52] ‘Juniper Networks Software-Defined Networking Solution - Juniper Networks’. [Online]. Available: http://www.juniper.net/us/en/solutions/sdn/. [Accessed: 29Sep-2017]. [53] ‘HP Virtual Application Networks - Enterprise Software Defined Networks (SDN) | HP Networking’. [Online]. Available: http://h17007.www1.hpe.com/cz/en/solutions/technology/van/index.aspx. [Accessed: 29-Sep-2017]. [54] ‘Cisco Application Policy Infrastructure Controller (APIC)’, Cisco. [Online]. Available: https://www.cisco.com/c/en/us/products/cloud-systemsmanagement/application-policy-infrastructure-controller-apic/index.html. [Accessed: 29-Sep-2017]. [55] ‘What is Plexxi? - Definition from WhatIs.com’, SearchSDN. [Online]. Available: http://searchsdn.techtarget.com/definition/Plexxi. [Accessed: 29-Sep-2017]. [56] ‘What is Cyan Blue Planet? (now part of Ciena)’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/sdn/definitions/sdn-controllers/opendaylightcontroller/cyan-blue-planet/. [Accessed: 29-Sep-2017]. [57] ‘What is OpenFlow? Definition and how it relates to SDN’, SDxCentral. [Online]. Available: https://www.sdxcentral.com/sdn/definitions/what-is-openflow/. [Accessed: 10-Sep-2017]. [58] C. Ching-Hao and Y.-D. Lin, ‘OpenFlow Version Roadmap’, 2015. [59] Allied Telesis, ‘x930 Series’. 2017. [60] Allied Telesis, ‘x510 Series’. 2017. 123
[61] J. Deng et al., ‘VNGuard: An NFV/SDN combination framework for provisioning and managing virtual firewalls’, in Network Function Virtualization and Software Defined Network (NFV-SDN), 2015 IEEE Conference on, 2015, pp. 107–114. [62] ‘Hype Cycle Research Methodology | Gartner Inc.’ [Online]. Available: http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp. [Accessed: 10-Sep-2017]. [63] ‘What is Gartner hype cycle? - Definition from WhatIs.com’, WhatIs.com. [Online]. Available: http://whatis.techtarget.com/definition/Gartner-hype-cycle. [Accessed: 03-Sep-2017]. [64] B. Lantz, B. Heller, and N. McKeown, ‘A Network in a laptop: Rapid prototyping for software-defined networks’, in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, New York, NY, USA, 2010, p. 19:1–19:6. [65] J. Teixeira, G. Antichi, A. Del Chiaro, S. Giordano, and A. Santos, ‘Datacenter in a box: test your SDN cloud-datacenter controller at home’, in 2013 Second European Workshop on Software Defined Networks, 2013, pp. 99–104. [66] J. Kempf, Y. Zhang, R. Mishra, and N. Beheshti, ‘Zeppelin-A third generation data center network virtualization technology based on SDN and MPLS’, in Cloud Networking (CloudNet), 2013 IEEE 2nd International Conference on, 2013, pp. 1– 9. [67] ‘How to use MiniEdit, Mininet’s graphical user interface’, Open-Source Routing and Network Simulation, 03-Apr-2015. [Online]. Available: http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphical-userinterface/. [Accessed: 19-Dec-2017]. [68] mininet-wifi: Emulator for Software-Defined Wireless Networks. INTRIG, 2017. [69] ‘Introducing Vagrant | Linux Journal’. [Online]. Available: http://www.linuxjournal.com/content/introducing-vagrant. [Accessed: 12-Sep2017]. [70] ‘Vagrant by HashiCorp’, Vagrant by HashiCorp. [Online]. Available: https://www.vagrantup.com/index.html. [Accessed: 12-Sep-2017]. [71] Mobatek, ‘MobaXterm free Xserver and tabbed SSH client for Windows’. [Online]. Available: http://mobaxterm.mobatek.net/. [Accessed: 12-Sep-2017]. [72] J. Metzler, ‘Understanding software-defined networks’, Rep. Inf. Com, vol. 9, 2012. [73] P. Lin, J. Bi, and H. Hu, ‘BTSDN: BGP-based Transition for the Existing Networks to SDN’, Wirel. Pers. Commun., vol. 86, no. 4, pp. 1829–1843, 2016. [74] D. M. Batista et al., ‘Perspectives on software-defined networks: Interviews with five leading scientists from the networking community’, J. Internet Serv. Appl., vol. 6, no. 1, pp. 1–10, Oct. 2015. [75] C. Voss, N. Tsikriktsis, and M. Frohlich, ‘Case research in operations management’, Int. J. Oper. Prod. Manag., vol. 22, no. 2, pp. 195–219, 2002. [76] I. Benbasat, D. K. Goldstein, and M. Mead, ‘The case research strategy in studies of Information Systems’, MIS Q, vol. 11, no. 3, pp. 369–386, Sep. 1987. [77] P. Comi, B. M. Parreira, A. Kourtis, and A. Ramos, ‘Virtual Security Appliances: The Next Generation Security’. [78] R. Tajpuriya, V. Gupta, and I. J. Rajput, ‘A SYSTEMATIC APPROACH FOR HIGHLY SECURE FRAMEWORK FOR VIRTUAL FIREWALL’. [79] J. Shah, ‘Implementation and Performance Analysis of Firewall on Open vSwitch’. [80] S. Rajagopalan, D. Williams, and H. Jamjoom, ‘Pico Replication: A high availability framework for middleboxes’, in Proceedings of the 4th annual Symposium on Cloud Computing, 2013, p. 1. [81] S. Brief, SDN Security Considerations in the Data Center. 2013. 124
[82] D. Hock, M. Hartmann, S. Gebert, M. Jarschel, T. Zinner, and P. Tran-Gia, ‘Paretooptimal resilient controller placement in SDN-based core networks’, in Teletraffic Congress (ITC), 2013 25th International, 2013, pp. 1–9. [83] Y. Zhang, N. Beheshti, and M. Tatipamula, ‘On resilience of split-architecture networks’, in Global Telecommunications Conference (GLOBECOM 2011), 2011 IEEE, 2011, pp. 1–6. [84] M. P. P. of 2013 | R. Says, ‘Five components of resilience – robustness, redundancy, resourcefulness, response and recovery’, Riskviews, 24-Jan-2013. . [85] R. C. Nickerson, U. Varshney, and J. Muntermann, ‘A method for taxonomy development and its application in information systems’, Eur. J. Inf. Syst., vol. 22, no. 3, pp. 336–359, 2013. [86] F. Hendrikx, K. Bubendorfer, and R. Chard, ‘Reputation systems: A survey and taxonomy’, J. Parallel Distrib. Comput., vol. 75, pp. 184–197, 2015. [87] I. D. Agusalim and A. F. Muhammad, ‘Developing Interactive E-Learning Module of English Teaching to Support the Distance Education Program at EEPIS’, IOSR J. Humanit. Soc. Sci. JHSS, vol. 5, no. 1, p. pp 28-32, Dec. 2012. [88] ‘Deploy an SDN Wired/Wireless Network with Open vSwitch* and Faucet* | Intel® Software’. [Online]. Available: https://software.intel.com/en-us/articles/deploy-ansdn-wiredwireless-network-with-open-vswitch-ovs-and-faucet. [Accessed: 15-Dec2017]. [89] J. Bailey and S. Stuart, ‘FAUCET: Deploying SDN in the Enterprise’, Queue, vol. 14, no. 5, p. 30, 2016. [90] A. Shalimov, D. Zuikov, D. Zimarina, V. Pashkov, and R. Smeliansky, ‘Advanced study of SDN/OpenFlow controllers’, in Proceedings of the 9th central & eastern european software engineering conference in russia, 2013, p. 1. [91] H. Selvi, E. Zeydan, G. Gür, and F. Alagöz, ‘Load balancing in OpenFlow-enabled switches for wireless access traffic aggregation’, in Network Operations and Management Symposium (NOMS), 2016 IEEE/IFIP, 2016, pp. 1013–1014. [92] M. Sisov, ‘Building a Software-Defined Networking System with OpenDaylight Controller’, 2016. [93] J. Bailey, ‘Inter VLAN routing’. . [94] J. M. Dover, A denial of service attack against the Open Floodlight SDN controller. Dover Networks LCC, 2013. [95] J. M. Dover, A switch table vulnerability in the Open Floodlight SDN controller. Dover Networks LLC, Tech. Rep, 2014. [96] S. Scott-Hayward, ‘Design and deployment of secure, robust, and resilient SDN Controllers’, in Network Softwarization (NetSoft), 2015 1st IEEE Conference on, 2015, pp. 1–5. [97] C. Liang, R. Kawashima, and H. Matsuo, Scalable and Crash-Tolerant Load Balancing Based on Switch Migration for Multiple Open Flow Controllers. 2014. [98] D. Chourishi, A. Miri, M. Milić, and S. Ismaeel, ‘Role-based multiple controllers for load balancing and security in SDN’, in Humanitarian Technology Conference (IHTC2015), 2015 IEEE Canada International, 2015, pp. 1–4. [99] 2015 at 1:35pm Posted by Neela Jacques on July 7 and V. Blog, ‘OpenDaylight Lithium Brings Stability, Scalability, Security and Performance to Open SDN’. [Online]. Available: http://insights.wired.com/profiles/blogs/opendaylight-lithiumbrings-stability-scalability-security-and. [Accessed: 16-Dec-2017]. [100] R Goulding, ‘Enhanced Stability, Security and Network Programmability’, OpenDaylight, June 12. . 125
[101] ‘Mininet-WiFi: SDN emulator supports WiFi networks’, Open-Source Routing and Network Simulation, 23-Apr-2016. [Online]. Available: http://www.brianlinkletter.com/mininet-wifi-software-defined-network-emulatorsupports-wifi-networks/. [Accessed: 18-Dec-2017]. [102] ‘My SDN Testbed’, My SDN Testbed, 26-Jun-2016. [Online]. Available: http://costiser.ro/2016/06/26/my-sdn-testbed/#setup. [Accessed: 19-Dec-2017]. [103] Z. Zhao, D. Gong, B. Lu, F. Liu, and C. Zhang, ‘SDN-based double hopping communication against sniffer attack’, Math. Probl. Eng., 2016.
126
APPENDICES APPENDIX A
127
APPENDIX B
128
![SDN, NFV, and open source: the operator's view - TIA [PDF]](https://m.moam.info/img/260x300/sdn-nfv-and-open-source-the-operators-view-tia-pdf_6482ca13098a9ee2728b4569.jpg)
