SlideShare a Scribd company logo

B530429_FinalDissertation

J
Jasjoot Mudhar

This document discusses the deployment of a software-defined network testbed on the cloud. It begins with an introduction to software-defined networking and its advantages over traditional networking. It then discusses the design and implementation of an SDN testbed using OpenDaylight as the SDN controller, Mininet as the network emulator, and Wireshark for network traffic analysis. Various network topologies are implemented in Mininet including linear, single, tree and torus topologies. OpenFlow messages are captured to understand communication between the controller and switches. Network performance is evaluated by generating and measuring traffic across the testbed. The goal is to demonstrate and analyze the SDN concept in a practical virtualized environment.

1 of 47
Downloaded 12 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar B530429 A dissertation submitted in partial fulfillment of Loughborough University’s MSc Internet Media Clouds with Business Keywords: Software Defined Network, Cloud Environment, and Network Performance Monitoring
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 1 Abstract Technology is developing at an accelerating pace in this day and age. There is recognizable trend in the IT industry specifically in the cloud, mobile, social and big data. The future of the Internet is facing new challenges in which high bandwidth, dynamic management and ubiquitous accessibility are highly crucial. Traditional networking is very inflexible and static possessing little agility while being error prone in which networking infrastructure not getting completely utilized. Software Defined Networking (SDN) is a networking paradigm which has recently emerged and is touted as the most promising solution for the future of the internet. The two main characteristics imposed by SDN include the decoupling of the control plane from the data plane and allowing for programmability in network application development. In result, SDN provides a platform which allows for more efficient configurations along with greater flexibility with the ability to accommodate innovative network designs. SDN imposes a three layer architecture which includes the application layer, control layer and an infrastructure layer. This paper will discuss and investigate the key features of SDN as well as discuss the challenges and limitations while comparing to traditional networking. This project is also going practically demonstrate the SDN concept by using a controller to manage a network, a network emulator to develop a realistic virtual network testbed and a network monitoring tools to measure and analyse network activity.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 2 Table of Contents Section Page Number 1 Introduction 4 1.1 Project Aim 4 1.2 Project Objectives 4 2 Literature Review 5 2.1 The Evolution of Networks and Problems 5 2.2 History 6 2.3 Network Monitoring 7 2.3.1 Packet Loss 8 2.3.2 End-to-End Delay 8 2.3.3 Link Usage and Utilization 8 2.3.4 Software-Defined Networking in the Cloud 8 3 Software-Defined Networking 9 3.1 Defining Software-Defined Networking 9 3.1.1 Data Plane 9 3.1.2 Control Plane 9 3.1.3 Management Plane 9 3.2 SDN Architecture 11 3.2.1 Application Tier 12 3.2.2 Control Plane Tier 12 3.3.3 Infrastructure/ Data Plane Tier 12 4 Design 14 4.1 Wireshark 14 4.2 Ubuntu 14 4.3 VMware Workstation Player 12 14 4.4 OpenDayLight (ODL) 14 4.4.1 OpenDayLight – Beryllium 15 4.5 OpenFlow 16 OpenFlow Messages 17 4.6 Mininet 18 4.6.1 Benefits of Mininet 18 4.6.2 Justifications for Project 18
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 3 5 Implementation 19 5.1 Hardware 19 5.2 Downloading & Installing OpenDayLight Prerequisites 20 5.3 The OpenDayLight Graphical User Interface (GUI) 22 5.4 Network Topologies 23 5.4.1 Linear Topology 23 5.4.2 Single Topology 25 5.4.3 Tree Topology 26 5.4.4 Torus Topology 27 5.5 Capturing & Analysing OpenFlow Messages 28 5.5.1 OpenFlow Messages 29 5.5.2 Features Request & Reply 30 5.5.3 Other Type of Messages 30 5.6 Generating & Measuring Traffic 31 5.7 Yang UI 32 x 6 Evaluation 33 6.1 Problems Encountered 33 7 Conclusion 34 7.1 Future Implementations 34 References 35 APPENDIX 40 1 High-Level Overview of a SDN Architecture 40 2 Software-Defined Networking VS Traditional Conventional Networking 41 3 OpenDayLight Features List 42 4 OpenDayLight – 4th Release Berylliums 43 5 Current Research Projects 44 6 Project Proposal 45
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 4 1) Introduction Software-Defined Networking (SDN) is a new networking paradigm which supports the recent growth in data. This paradigm is making the telecommunications industry more scalable and agile. There is a notable growth in network traffic which is ringing alarms in the IT industry. This is attributed by dynamic cloud workloads, unified communications and video conferencing. At this alarming rate, new technology will continue to force the demand for bandwidth to increase exponentially. The emerging technologies include 4k video, the Internet of Things (IOT), augmented and virtual reality. The capacity in traditional telecoms industry is being outstretched as it is struggling accommodate the rapid increase in data. Traditionally a telecoms network is comprised of single-purpose and specialised equipment which include switches, routers or any other custom built networking devices. In order to add capacity, extra equipment needs to be added to current infrastructure. This was viable for data services include voice traffic as this increased predictably and gradually. However, the demands of modern society is outweighing the current capabilities as these networks cannot accommodate fast enough. There is now a demand for new ways to manage and build data networks. Technology advancements has already seen a profound solution being introduced. Virtualisation is providing a cost effective and scalable solution. Software can be used to virtualise physical hardware and by doing this at a network level allows for rapid expansions. In recent years the concept of Network Function Virtualisation (NFV) and Software-Defined Networking (SDN) have been introduced and touted as the future. The introduction of SDN and NFV represents a dramatic change within the industry. There has been a great shift in how networks are built and designed. The on-demand services are paving a way for software-centric networking which is allowing users to grow and adapt to their business needs. In 2016, it can already be seen that a lot of applications are cloud based, and the foreseen future can see majority of our networks being virtualised in the next five years. These advancements allow for greater agility, flexibility and control for networking services, improving the value of the solution. 1.1)_Project Aims: This projects aims to investigate the concept of Software-Defined Networking in terms of architecture, design and implementation. Then to implement a virtualised testbed using SDN-enabled technologies to analyse various network activities. 1.2) Project Objectives:  To differentiate Software-Defined Networking to traditional networking, exploring in depth the SDN architecture, design and implementation.  To investigate the scalability of the various topologies which can be implemented within a virtualised network  To design a SDN environment in order to practically understand the SDN concept  To develop an SDN networking testbed in order to capture and analyse various network activities and understand the different type of communication between a controller and networking devices.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 5 2) Literature Review 2.1) The Evolution of Networks and Problems The key technologies in switches and routers are the distributed control and transport network protocols in which digital packets transfer information through the World Wide Web. In spite of their widespread adoption, IP networks traditionally are hard to manage as well as complex [1]. High-level network policies are expressed through network operators who are assigned to configuring network devices individually using low-level, vendor-specific commands. As current networks environments are complicated to configure, they endure faults and struggle to adapt to load changes. Existing IP networks virtually lack response mechanisms and do not automatically reconfigure. To enforce the required policies in a dynamic environment is extremely challenging. Current networks are also complicated as they are vertically integrated. The control, data and forwarding planes are the key components in networking hardware as they transfer vertically integrated IP packets from A to B. The control plane decides how to handle network traffic while the data plane forwards traffic in accordance to the decisions made by the control plane. These are all inside networking devices, however these hinders innovation, reduces flexibility and limits evolution of networking infrastructures [2]. In the past decade, there has been a transition from IPv4 to IPv6. IPv6 can be seen merely as a protocol update, still incomplete and possess challenges. Current IP networks are static in terms of evolution and it can take anything between 5 to 10 years for a new routing protocol to be designed, evaluated and deployed. To change internet architecture (i.e., replacing IP) it is not feasible practically [3] [4]. Ultimately, operational and capital expenses have inflated in order to run IP networks. Software Defined Networking (SDN) is a networking paradigm which is emerging and counteracting current infrastructures limitations [5]. For this paradigm, the vertical integration is broken as it separates the control logic (networks control logic) from the underlying switches and routers which forward traffic (data plane) [6]. As the data and control planes are separated, the switches on the network become a forwarding device. A centralized controller (networking operating system) controls the logic logically and also simplifies policies and the network (re)configurations [7]. Figure A: simplified Software-Defined Network architecture model [2] Figure A illustrates a simplified Software-Defined Network architecture model (Appendix 1 shows a high level overview of a SDN networking architecture). Kopenens study in 2010 emphasized that a physical
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 6 centralized system does not postulate a logical centralized programmatic model. It must be noted that in order to ensure adequate levels of scalability, performance and reliability, this solution would be precluded. A production-level Software Defined Network design physically resorts to the distributed control planes [8] [9]. As mentioned earlier, Software Defined Networking separates the control and data plane. This can be distinguished by a well-defined programming interface between the SDN controller and switches. OpenFlow is a notable example of an Application Programming Interface (API) [6] [10]. Figure A illustrates that the direct control is given by the controller over the state in the data plane elements through an API. OpenFlow switches have tables depicting packet-handling rules (otherwise known as a flow table). Every rule matches with a subset of the traffic and achieves specific actions (forwarding, dropping, modifying, etc.) on the traffic. The rules initiated on the controller application can enable OpenFlow switches to behave either like router, firewall or other tasks (i.e., traffic shaper, load balancer). In principle, SDN separates the concerns between network policies, their implementation in switches (hardware) and the forwarding of traffic. Separation is a key element to accomplishing flexibility. Network control problems are broken into tractable pieces which make it easier to introduce and create new abstractions in networking. This simplifies network management and facilities networking innovations and evolution. Initially both OpenFlow and SDN started as experiments in academia [6], gaining significant attraction in the industry over the years. This evolution has seen vendors of commercial switches opting to include support of OpenFlow API in their networking equipment. The momentum gained by SDN has seen blue chip companies such as Facebook, Microsoft, Yahoo, Google, Deautsche Telekom, Verizon fund Open Networking Foundation (ONF)[10] with their objective being to promote and adopt SDN via open standards development. Yageneh’s study in 2013 addressed concerns with SDN scalability however it can be seen that the evolution of SDN evolving from academia has been a success in a commercial spectrum [11]. For instance, Google deployed a SDN to interconnect data centres globally. This transition has Google improving its operational efficiency as well as reducing costs [9]. Another instance is NSX, which is VMware’s network virtualization platform [12]. This solution delivers a complete functional network in software using SDN principles. SDN has evolved and developed, giving a better cutting edge advantage compared to traditional networks (Appendix 2 shows SDN versus Traditional Networks). IT organisations (from equipment manufacturers to carriers to financial companies and cloud service providers) have joined the SDN consortia including the OpenDaylight initiative [13] and ONF. SDN now is an important paradigm from the industrial perspective also. 2.2) History The idea of a ‘centralized network architecture’ has been coined for many years. For the past three decades, various research initiatives have been initiated on split architectures. Initially in the 1980’ a circuit switched network called the Network Control Point (NCP) was introduced in which the first attempt to separate control and data plane signalling [14].Prior to this, circuit switches were used to manage all call controls, however this technology was limited. The single switches had limited processing power with a lack of upgrades implementable as well as a lack of visibility on the network. These problems were addressed by NCP as an adjunct call processing platform, which was external to circuit switches. The NCP formed a basis in which many voice network features were built and are still used today (calling cards, call centres, 800-numbers etc.) [15].
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 7 In the late 90’s, the Tempest project emerged [16]. This project introduced network virtualization and the concept of switchlets in ATM networks. The core notion was to enable multiple switchlets on a singular ATM switch allowing ATM networks to share physical resources. This project discovered that every individual service has its own needs which require separate control architecture. The question shifted from finding ways to fit new services with the existing architecture to what is the best architecture for the new services [16]. In the 2000’s, IP networks faced similar problems than its predecessor. There was limited visibility on the network; the route controller had limited processing power as well as it being more difficult to configure routers. AT&T conceptualized an “IP-NCP”, which is a platform in which route selection is performed. This improved the control and management of telephone networks and motivated the development of the Routing Control Platform (RCP) [17]. RCP [18], PCE [19] and ForCES [20] proposed the separation of the data and control planes in order to improve management in Ethernet, MPLS, ATM and BGP networks. A conceptual architecture named 4D was introduced [21]. Along with RCP, these architectures were regarded as the forefathers of the Software Defined Network (SDN) notion. Recently, Ethane [22] and SANE [23] projects defined enterprise architectures and proposed the decoupling of the data and control planes for Ethernet networks. Today these technologies can be seen as the predecessors of OpenFlow [24]. Table B presents a summarized overview of the history of programmable networks. Table 1 shows a summarized overview of the history of programmable networks [2] 2.3) Network Monitoring Software Defined Networking is being used to solve current monitoring problems experienced in traditional IP networks. Network monitoring systems are seen as a solution to monitor the performance of the network against bottlenecks, failures or unusual activity which results in a slow or broken down network [25]. The last decade has seen network technologies revolutionized. There is a continuous increase in the volume of data being produced, which is at a record rate [26] as well as traffic in both wired and wireless networks. The capacity and speed of different components such as switches, routers, transmission media in networking systems has increased emphatically. There has also been an increase in multimedia applications including video and audio which make network characteristics more diverse and complex. The packet-switched networks provide best-effort services as opposed to reliable messaging. Now there is an urgent need to ensure network services have performance guarantees in terms of knowing the delay, throughput, loss rate and jitter. Traffic in packet-switched networks does get processed quickly however there is never a guarantee in the Quality of Service (QoS) [27].
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 8 A Quality of Service enabled network is compiled of many functions which provide various types of services to different packets, for instance the classifier, rate controller, admission control and scheduler. The scheduler, just as the name suggests, decides the order in which packets get processed, either at the node or transmission over a link. The Active Queue Management determines in which order packets get processed at the node. AQM schemes have evolved significantly overtime [27] The different type of network monitoring include active versus passive methods as well as application and network methods. The networks quality of service can be evaluated by characteristics such as, packet loss, end-to-end delay link usage and utilization and jitter [28]. This also imposes the question to whether contemporary monitoring techniques are adequate. Some networking characteristics used for network monitoring are discussed below. 2.3.1) Packet Loss As the name suggests, this event occurs when not all packets that are sent are received at the destination node. Network congestion, link failures or a change in the topology can cause this. In order to determine whether a packet has reached its destination, packet loss is expressed as a binary number, either 0 or 1. 0 suggest the packets have not been received, whereas 1 is when the packet is delivered successfully [29]. 2.3.2) End-to-End Delay End-to-End delays refer to the time taken for a packet to be transmitted from the source to the destination across a network. Packets can reach their destination via intermediate nodes. There are applications which are influenced by the delay in the network. A network delay subsequently can degenerate an application, which make it an important metric for user experience assurance and a Quality of Service. The total network delay is accumulated of propagation, processing, queueing and transmission delays [30]. 2.3.3) Link Usage and Utilization The link usage is defined as the successful number of received IP-layers bits which are sent from the source and pass via link L during the time interval of T [30]. Both usage are capacity are distinguishable. The link capacity is a value which represents the maximum link usage. The link utilization is represented in binary form. 0 represents the link not being used whereas 1 represents the link being completely saturated [31]. 2.4) Software-Defined Networking in the Cloud The advancements in technology have seen existing technology evolve. Namely, cloud computing is a form of internet-based computing. The US National Institute of Standards & Technology (NIST) in 2011 have defined cloud computing to be a model which enables ubiquitous, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, services and storage conveniently without being rapidly provisioned by service providers[32]. Cloud architectures provide networking infrastructures as-a-service via a group of layers, which are also as-a-service. Cloud computing inherits five fundamental characteristics, three service models and four deployment models. The emergence of cloud computing, in particular virtualisation has seen the industry transform. SDN in particular focuses on the orchestrations and operations of many virtualized compute functions over large networking infrastructures.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 9 3) Software Defined Networking 3.1) Defining Software Defined Networking (SDN) Software Defined Networking (SDN) is a recently new networking paradigm. Brandon Heller’s study in 2012 has quoted that, “SDN is about refactoring of the relationship between network devices and the software that controls them” [33]. The reference of networking devices includes firewalls, gateways, line drivers, modems, terminal adapters, multiplexers, network address translators, network bridges, network interface controllers, protocol converters, proxy servers, routers, switches, hubs and wireless access points. The three basic components of a telecommunication architecture include the control plane, data plane and management plane, as shown in Figure B. 3.1.1) Data Plane The data plane processes the transit traffic, determining the fate of the packets which arrive on an ingress interface. Packets are sent through the ‘fabric’ which interconnect both the ingress and egress interfaces. The data plane also includes forwarding, routing and ARP tables as well as tagging, re-tagging and queuing. The data plane essentially enforces the commands of the control plane [34]. 3.1.2) Control Plane The control plane focusses on collecting, managing and processing network information which determines forwarding/routing decisions. Routers and switches determine where to send packets (L3) and frames (L2) and also exchange information, i.e. status, host reachability with neighbours. Protocols associated with the control plane include BGP, OSPF and STP. The control plane also deals with connectivity, device discovery and service provisioning [35]. 3.1.3) Management Plane The management plane configures, interacts and monitors networking devices as well as and provide managements and configuration services to all the layers of the network stack. The management plane also possess its own protocols such as HTTP, HTTPS, SNMP, SHH, Telnet, TFTP [36]. In traditional networking devices, dedicated hardware carry out data plane activities whereas the CPU of a device handles the control plane operations. (Forwarding) DATA PLANE (Algorithms, Protocols, Tables) CONTROL PLANE (Configuration CLI/GUI) MANAGEMENT PLANE Frame IN Frame OUT Unknown Packets Forwarding Behaviour Figure B: The Planes of Network Elements
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 10 In traditional and conventional networking, the control, data and management planes are implemented in the firmware of switches and routers. SDN, on the other hand decouples the control and data planes, eliminates the control plane from the network hardware and implements it in software [37]. This allows for programmatic access, providing dynamic access which enforces flexibility for network administrators. Network administrators are able to shape traffic from a centralized control console without having to interact with individual switches. Flexibility also enables administrators to change the rules in switches, i.e. de-prioritizing, prioritizing as well as blocking specific packets with granular control levels [37]. SDN eradicates the static and complex nature of legacy distributed network architectures as it uses standard based software abstraction between the underlying data forwarding plane and the control plane [38]. Computer scientist, Scott Shenker has described SDN is about ‘achieving forwarding, state distribution and specification abstraction at network control planes’ [39]. In a realization perspective, Software Defined Networking in any network gives flexibility between the points on the design axes: centralized to distributed, fully-consistent to eventually-consistent, micro-flow to aggregated-flow, reactive to proactive, virtual to physical [33]. SDN also allows flexibility in the choice for control planes. Networking devices are now solely forwarding packets (data plane), with the devices being programmed through an open and standard interface (i.e. OpenFlow). The basis of legacy networks will be present in the years to come and have provided a platform for development and integration in SDN. For instance the development in switching and routing protocols have contributed towards the development of SDN controller software. Table 2 shows the different elements from a legacy network stack being embedded within the SDN stack. SDN Stack Legacy Network Stack Applications User Interface Unified Management API Controller Applications Protocol Utilities Switch Hardware Abstraction Layer SDK / Drivers Switching Silicon Traditional Device SDN Architecture Data Plane Management Plane Control Plane Data Plane Control Plane Management Plane OpenFlow Protocol OpenFlow API Figure C: Traditional Architecture V SDN Architecture Controller Networking Device Table 2: Integration of the SDN Stack from the Legacy Network Stack [42] Networking Device
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 11 3.2) SDN Architecture Software-Defined Networking architecture describes how computer systems and networks are compiled using open source software-based technologies along with commodity networking hardware in which both the data layer and control plane are separated in the network stack [41]. In 2008, the Open Network Foundation (ONF) defined OpenFlow, as the first standard communications interface between the decoupled data and control planes. In SDN, OpenFlow protocols transit messages between underlying network infrastructure and the SDN controller, which brings networking applications to life. The current issues imposed by OpenFlow include scalability, security and the requirement for specialized hardware. The other protocols which make up SDN include BGP, NETCONF, XMPP, OVSDB and MPLS-TP [40]. Figure D illustrates an SDN architecture, which is composed of three-tiers of functionality. SDN architecture enables applications to gain extra information from a controller regarding the state of the entire network, something which was not possible in traditional networking, as they are application aware [41]. The three tiers architecture include:  Application Tier  Control Plane Tier  Infrastructure/Data Plane Tier Appendix 1 shows a high level overview of a SDN architecture Application Tier Control Plane Tier Data Plane Tier Northbound API Figure D: SDN Architecture Data Plane Interface (OpenFlow) SDN Controller Network Services Network Devices Network DevicesNetwork Devices APPAPP APP 3rd Party Applications Physical Switch Virtual Switch
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 12 3.2.1) Application Tier The application tier encompasses solutions which are focused on the expansion of network services. The solutions are primarily software applications which communicate with the SDN controller via an Application Programming Interface (API). Applications form an abstracted view of the network as they collect information from the controller to aid in decision making. The different type of applications include network virtualization, network monitoring, network management, traffic engineering, etc. [41]. 3.2.2) Control Plane Tier The control plane tier, also known as the ‘Networking Operating System (NOS)’, is a key component of SDN and this is what differentiates from traditional networking technologies. In the control plane a SDN controller is used and provides a centralized and global view of the entire network as well as taking requests via API’s from the application layer. This enables monitoring and management for a network which is done through standard protocols, i.e. OpenFlow. This well-defined protocol enables the control layer to have direct access to the forwarding planes within network devices. The most common open source SDN controllers include Floodlight, NOX/POX, ODL, ONOS, RYU and Trema [42]. 3.2.3) Infrastructure/ Data Plane Tier The basis of a network is provided by the infrastructure tier which includes networking equipment that allows traffic forwarding. Traditionally the infrastructure layer consists of switching and routing protocols (forward decision-making algorithms). These are static varying from different vendors, which restricts adjustability and flexibility. SDN on the other hand, provides a cleverer approach. The forwarding algorithms get decoupled from networking equipment, which then get implemented in common programming languages in commodity servers [42]. In result, networking nodes become forwarding devices, only establishing communication with a controller which makes them less intelligent. This layer also includes southbound protocols such as OpenFlow, which allows connection from the infrastructure to control layer. Other southbound protocols include OVSDB. SNMP, PCEP. 3.3) SDN Controllers The controller in a Software Defined Network is essentially the brains of the network. Applications form a strategic control point within the network allowing low level components to be managed via southbound APIs. The northbound API on the other hand allows components in a network to communicate with high level components. Controllers typically have a pool of pluggable modules which perform various tasks. Tasks can include anything from inventorying to gathering network statistics. OpenFlow, NETCONF and OVSDB remain the popular choice of protocols used in SDN. Figure E shows the important features of a SDN controller. SDN Controller Features North Bound APIs & Apps Platform & Services South Bound Protocols Figure E: The features of a SDN controller
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 13 As mentioned earlier, SDN is a new networking paradigm and it benefits from an open source community. Figure F illustrates the various aspects of an SDN controller including the features, application networks, uses cases and efficacy. It is important to note that the features form an important part which influence the different efficiency targets of the controller, these include extensibility, programmability, scalability and interoperability. The controller efficacy is an umbrella phrase used to define the various performance parameters, including performance, scalability, security and reliability. Table 3 shows a comparison of open source controllers using the use cases mentioned above. This comparison will be used to justify the choice of controller for this project. Controllers Use Cases Floodlight NOX/POX ODL ONOS RYU Trema Campus Networks Partial Partial Partial No Partial Partial Dynamic Network Taps Yes No Yes No Yes No Hop-By-Hop Network Virtualization Yes No Yes Yes No No Legacy Network Interoperability No No Yes Partial No No Load Balancing No No Yes No No No Multi-Layer Network Optimization No No Partial Partial No No Network Monitoring Yes Partial Yes Yes Yes Partial Network Virtualization by Virtual Overlays Partial Yes Yes No Yes Yes OpenStack Neutron Support Yes No Yes No Yes No Policy Enforcement Partial No Yes Partial No No Routing Yes No Yes Yes Yes Yes Service Insertion and Chaining No No Yes Partial Partial No Traffic Engineering Partial Partial Yes Partial Partial Partial Transport Networks, NB, Traffic-Rerouting, Interconnecting DCs, etc. No No Partial Partial Partial No Table 3: Comparison of Open Source Controllers in consideration to different Use Cases [43] Influences Controller Features: -Platform -Services -Northbound APIs & APPs -Southbound Protocols Controller Efficacy: -Performance -Scalability -Security -Reliability Use- Cases: - Loud Balancing -Network Monitoring -Network Virtualization with Cloud- Orchestration -Service Insertion & Chaining -Traffic Engineering, - Policy Enforcement Application Networks: -Data Centre Networks -Multi-Layered Transport Networks -Enterprise & Campus Networks Figure F: The features of a SDN controller
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 14 4) Design This project is going to incorporate all theory mentioned in this report and demonstrate the features and functionality of Software-Defined Networking. The objective of this project is to deploy a testbed for performance monitoring in terms of link utilisation, delay and packet loss. By using the SDN architecture, below is a list of the applications which are available to elaborate SDN.  Applications: Wireshark, FlowMaker, HP Network Visualizer, HP Network Optimizer, Bash scripts  Controllers: Floodlight, HP/HPE VAN SDN, OpenDaylight (ODL), ONOS, RYU  Infrastructure: Mininet’s Open vSwitch using OpenFlow This project is going to demonstrate the concepts of SDN by using different application in accordance to the SDN network stack. This can be seen over the following pages. The selected applications for this project are stated below.  Wireshark: An open source packet analyzer which will be used for network monitoring and analysis.  OpenDayLight: This is an open-source SDN controller which offers abstraction to network services.  Mininet: This is a network emulator which will be used to create realistic virtual networks. 4.1) Wireshark Formerly known as Ethereal, Wireshark is an application which allows for real time packets to be captured and displayed in a user friendly manner. In this project, Wireshark is going to be used to analyse OpenFlow packets. 4.2) Ubuntu This is a debian-based open source Linux Operating System. In order to achieve the best results for ODL, the documentation has stated that ODL should run natively using a Linux operating system. For this project, the latest Ubuntu Desktop 16.04.1 LTS version is going to be used. In particular a command-line interface terminal is going to be used in order to streamline OpenDaylight. 4.3) VMware Workstation Player 12 The VMware Workstation is a hypervisor which can run on both Linux and Windows operating system. This software allows for virtual machines (VMs) to be created on a single physical machine. This software is going to be used to run Mininet by creating a virtual machine so that virtual experiments can take place for this project. 4.4) OpenDayLight (ODL) Introduced in 2013, the OpenDaylight Project (ODL) is an open-source Software-Defined Networking project which is hosted by the Linux Foundation. David Meyer from Brocade has nicely stated that “OpenDaylight can do for networking what Linux has done for the computing industry” [44]. This project was created to advance SDN adoption and develop the basis for robust network function virtualization (NFV). ODL focuses on the SDN control layer as it offers the service abstraction for services such as data packet delivery to northbound applications, conveying topology information, flow programming, showing statistics plus a node and connection inventory [44].
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 15 Figure G presents a simplified ODL architecture. The service abstraction layer enforces the ODL controller (Which operates on a Java Virtual Machine) to support different southbound SDN approaches though plugins. The northbound API on the other hand is used to provide consistent connection to business applications through bidirectional REST and the OSGi framework (45). The ODL platform also consists of features, plug-ins and protocols which can be integrated in various ways in order to deliver an inclusive set of SDN use cases. Appendix 3 shows you the list of services, applications and protocols that Open Daylight can support. The current Southbound SDN technologies which ODL support include OVSDB, OpenFlow, Yang tools, BGP, PCEP, and LISP [45]. OpenFlow is going to be used for this project as this standard demonstrates the decoupling of the control and data plane from the networking devices by the controller. This will be discussed in the following sections. 4.4.1) OpenDayLight – Beryllium For this project, OpenDaylight Beryllium (ODL Be) is going to be used, which is the fourth release for OpenDaylight. In industry ODL Be is phrased as the de facto platform for enterprises and service providers who are transitioning to SDN. It offers a wide range of uses cases and establishes itself as providing a network of the future. The key challenges ODL tackles in networking include Network Resource Optimization, Automated Service Delivery, Control and Visibility. For ODL Beryllium, the Model Driven Abstraction Layers (MD-SAL) architecture allows it to be highly scalable as well as making it easy to incorporate protocols and applications. ODL Be greatly improves the scalability, performance and functionality. It also offers services which include a new GUI, broader management of networking elements, clustering and high availability, a greater abstraction of network models, improved data handling and messaging for transport [46] .The previous ODL releases include Hydrogen, Helium and Lithium. Appendix 4 shows Beryllium’s Architectural Diagram. Application Layer Control Layer Network Device Layer Applications Network Devices Controller Northbound Glue Code OSI GiRESTful Southbound Glue Code Figure G: Simplified ODL Architecture Protocols Plugins Base Network Functions Service Abstraction Layer (MD and ADSAL) Service Modules
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 16 4.5) OpenFlow Initiated from Stanford University in 2008, OpenFlow is considered as the first SDN standard that defines the communication protocols in an SDN environment. Traditionally both forwarding and routing decisions in switches and routers happen in the same device. OpenFlow embraces the concept of SDN as it decouples these functions where the data path resides on the switch and the routing decisions are done via the controller. The OpenFlow protocol defines messages like send-packet out, packet-received, get- stats and forwarding-table. The OF protocol enables communication between the controller and the OpenFlow switch. The SDN controller interface allows for changes to be made in the router/switching flow-table, this allows for network administrators to control flows for optimal performance, partition traffic, test new applications and configurations [47]. Figure H shows you the flow table entities which are capable of being manipulated by an OpenFlow switch. OpenFlow has many benefits, one being that it is programmable. This allows for innovation and has the ability to accelerate new services and features. OF has formed a centralized intelligence as it can simplify provisioning, optimize performance and have a granular policy management [47]. OpenFlow is a feature which can be added to commercial routers, Ethernet switches and Wireless Access Points (WAP) [48]. OpenFlows capabilities allow for switching and routing protocols to be innovated within in a network. It can also be used in applications such as high security networks, next generation IP based mobile networks and virtual machine mobility. Switch Port MAC Source MAC Dest Eth Type VLAN ID IP Dest. Port IP Source Port IP Protocol IP Dest IP Source 1) Forward Packet to Port(s) 2) Encapsulate & Forward to Controller 3) Drop Packet 4) Send to Normal Processing Pipeline Figure H: Flow Table Entries which can be manipulated by an OpenFlow Switch Rule Action Stats Packets + Byte Counters
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 17 4.5.1) OpenFlow Messages OpenFlow Protocol supports three message types with multiple sub-types. The three message types include controller-to-switch, asynchronous and symmetric messages. These is adapted from the OpenFlow Specification [50] and discussed as follows. 1) Controller-to-switch: These messages are initiated by the controller and are used to directly inspect or manage the state of the switch. Table 3 shows the different messages between the controller & switch. Features The switch needs to request identity (DPID) Configuration Set and query configuration parameters Modify-State Also called ‘flow mod’, used to add, delete and modify group/flow entries in the OpenFlow tables Read-States Get statistics Packets Out The controller sends messages to the switch, either full packet or buffer ID Barrier Requests reply messages are used by the controller to ensure message dependencies have been met, it receives notifications Role Request Sets the role of its OpenFlow channel Asynchronous Configuration Sets an additional filter on an asynchronous message that it wants to receive on OpenFlow Channel Table 3: Controller to Switch Messages 2) Asynchronous: This is initiated by the switch and is used to update the controller of network events and changes to the switch state. Table 4 shows the various asynchronous messages. Packet-In The switch needs to request identity (DPID) Flow- Removed Informs controller that a flow has been removed Port Status Informs controller that a switch has gone down Error Notifies controller of any problems Table 4: Asynchronous Messages 3) Symmetric: These are initiated by either the controller or switch and are sent without solicitation. Table 5 shows the various symmetric messages. Hello Messages are exchanged between the controller and switch Echo Sent from either controller or switch Verify liveness of a controller-switch connection Used to measure latency or bandwidth Experimenter A standard way for OpenFlow switches to offer additional functionality with the OpenFlow message type space Table 5: Symmetric Messages
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 18 4.6) Mininet Mininet is a network emulation orchestration system which can be used to create realistic virtual networks running on a collection of routers, switches, links and end-hosts on a singular Linux kernel. Mininet’s virtual switches, hosts, controllers and links are virtualised on software and behave in the same manner as actual hardware. Mininet uses lightweight virtualization which can makes a singular system look like a whole network, running the same user code, system and kernel. The hosts can operate on standardised Linux networking software, while switches can support OpenFlow enabling flexible and customised routing as well as Software Defined Networking. Mininet, in general allows for debugging, developing, development, learning, prototyping, research and testing [49]. 4.6.1) Benefits of Mininet The benefits of Mininet can be seen below. 1. Mininet is fast, allowing simple networks to be created within seconds enabling users to run, edit and debug loops quickly. 2. Mininet enables users to create customized topologies, anything from single switches to large topologies, data centres, etc. 3. Mininet can run real programs, anything on Linux from TCP monitoring tools to webservers. 4. Mininet allows the end user to customize packet forwarding. Mininet provides a platform for customized SDN designs to be implemented in actual hardware. This can include switches which use OpenFlow enabling line-packet forwarding. 5. Mininet’s flexible, it can run it on the cloud, servers, laptops, virtual machine or Linux OS natively. 4.6.2) Justifications for Project Mininet is going to be used in this project to obtain correct system behaviour and experiment with topologies demonstrating the key features for SDN. Mininet is a combination of a simulator, emulator and a hardware testbed. In comparison to complete system virtualization approaches, Mininet has great features, as shown below.  Faster Boot: The system boots in seconds rather than minutes.  Larger Scalability: Allows for hundreds of switches and hosts  Greater Bandwidth: In modest hardware it is around 2 Gbps.  Easy Installation: It has a pre-packaged VM which can operate on Virtual software, i.e. Virtual Box In comparison to a hardware testbed, Mininet is always available and inexpensive as well as being quick to be reconfigured and restarted. Also in comparisons to simulators Mininet can easily connect to real networks as well as offer interactive performance. The limitations imposed on Mininet are that its network cannot exceed the bandwidth or CPU on a single server. It also cannot run OpenFlow applications or switches that are non-Linux, however this has not been a great issue in practice.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 19 5) Implementation The design section highlighted the various software, protocols and operating system needed for this project. The implementation section is going to show the important steps required to set up a virtualised network testbed required for testing the Software-Defined Networking concept. This section will also investigate the scalability of a network by using different topologies and analyse OpenFlow messages between switches and a controller. Figure I shows a modified ODL architecture diagram used from page 15. The red text shows how the various elements mentioned in the design section fit into the OpenDayLight architecture. This in result will allow for SDN to be investigated in this project. 5.1) Hardware In order to run the OpenDaylight controller, it requires a Linux operating machine. For this project OpenDayLight Beryllium is going to run natively using a HP EliteBook laptop running the Ubuntu operating system. Table 6 below shows the laptop specifications. HP Elite Book Specification Memory 7.7 GiB Processor Intel Core i5-4310U CPU @ 2.00GHz x 4 Graphics Intel Haswell Mobile Disk 117.5 GB OS Type 64-Bit Operating System Ubuntu 16.04 LTS Table 6: Laptop Specification Application Layer Control Layer Network Device Layer Application: WireShark Emulated Network Devices using Mininet ODLBeryllium Controller Northbound Glue Code OSI GiRESTful Southbound Glue Code OpenFlow Protocols Base Network Functions Service Abstraction Layer (MD and ADSAL) Service Modules Figure I: Simplified ODL Architecture
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 20 5.2) Downloading & Installing OpenDayLight Prerequisites First, the OpenDayLight controller needs to be initialised and then installed. As mentioned earlier, OpenDaylight is going to operate in a command line Linux environment. Below in Blue are the iterative commands which are going to be used to initialise and install OpenDaylight followed by the ‘//’ Icon commenting the lines stated. Figure J on the next page shows the OpenDayLight screen, when launched. ping www.google.com // The ping command tests for connectivity, in this case Google. sudo passwd root // This command allows for a root password to be initialised. su // This allows the user to use the root privileges, logging in using the credentials set in the previous command. apt-get update // This updates references on the Ubuntu System apt-get install maven git openjdk-8-jre openjdk-8-jdk unzip // Installs JAVA software needed for the installation of ODL wget https://nexus.opendaylight.org/content/repositories/public/org/ope ndaylight/integration/distribution-karaf/0.4.3-Beryllium- SR3/distribution-karaf-0.4.3-Beryllium-SR3.zip // This downloads the Software from OpenDaylight website ls // This lists directory contents of files and directories, in this case for Beryllium SR3 unzip distribution-karaf-0.4.3-Beryllium- SR3.zip // This unzips the file which has recently been downloaded cd distribution-karaf-0.4.3-Beryllium-SR3 // The cd command changes the directory, so in this case, this command will enter into the Beryllium folder ls // This will show the files and folders within this folder export JAVA_HOME=/usr/lib/jvm/java-8-opejdk-amd64 // This specifies the Java Home directory ./bin/karaf // This starts OpenDayLight Beryllium
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 21 Figure J: OpenDayLight Launched In OpenDaylight, different features need to be specified and installed manually as there are many with different functionality. Table 7 below states the features which are going to be used for this project and their descriptions. These are the minimum set of features which are required to test ODL and ODL GUI. Feature List Description Restconf Allows access to RESTCONF API L2 Switch Provides Layer 2 switch functionality. The L2 switch components include a packet handler, loop remover, ARP handler, address and host tracker. This feature ensures switches and hosts are visible within a topology of the DLUX User Interface. Mdsal Apidocs Allows access to the YANG API DLux OpenDayLight Graphical User Interface (GUI) Table 7: ODL Features & Description Below shows the commands inputted in the command terminal after OpenDayLight has been launched. The ‘feature:install’ command installs the features mentioned. Feature: install odl-restconf-all odl-l2switch-switch odl-mdsal-apidocs odl-dlux-all
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 22 5.3) The OpenDayLight Graphical User Interface (GUI) Following the previous steps, the OpenDayLight controller has now been initiated and installed. One of the advantages of using the OpenDayLight controller is that it enables us to manage the network via a Web based User Interface (DLUX UI). Below Figure J1 shows the URL which was entered into the web browser. The URL consists of an IP address, in this case is the IP address of the network in which OpenDayLight was launched. This then brings up the login page, which is shown in Figure J2. By default the username and password are both ‘admin’. Figure J3 shows the web interface once successfully logged in. Figure J1: URL address to access the Web ODL User Interface (DLUX UI) Figure J2:The login page Figure J3:The DLUX interface once logged in, currently showing no topologies
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 23 5. 4) Network Topologies Mininet has the ability to create various network topologies which consists of hosts (end devices) and OpenFlow switches. The different topologies can differ from a single switch network to a more complicated topology which can consist of multiple links and switches, also giving the power to create your own topologies. The virtualized hosts and switch act like real devices in which traffic can be sent between hosts as well as being able to view flows on the switches. Applications like iperf can be used to measure the performance on the network. In Mininet, the ‘sudo mn’ command allows for network topologies to be created. Different options like’– topo=linear, 8’ can be implemented, which in result will consist of 8 switches connected back to back in a linear fashion. Figure k shows the Mininet screen when a linear topology of 8 switches is created. 5.4.1) Linear Topology Linear topology consists of switches which are connected back to back. The single hosts are connected to each switch. When creating the topology, the IP address for the OpenDayLight controller is also initiated, which will allow for control in the ODL web interface. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=linear,8 Figure K: Mininet creating a Linear Topology with 8 Switches To test the connectivity between the hosts, the ‘pingall’ command sends traffic between the hosts. Figure K1 shows that there is an active connection between the hosts as all 56 packets have successfully transmitted. Figure K1: Testing Connection Between Hosts
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 24 The OpenDayLight controller provides a Graphical User Interface (GUI) to visualise the topologies created in Mininet. Figure K2 shows the result of a Linear Topology with 8 Switches. Figure K2: Linear Topology with 8 Switches Figure K3: Nodes Menu – List of Nodes Figure K4: Node Connector Statistics for Selected Node (7) Statistics include Packets and Bytes Received/Transmitted. This traffic was genererated from ‘pingall’ SwitchesHosts with Mac Address Local Management Interface
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 25 5.4.2) Single Topology The single topology is compiled of a single switch with numerous hosts connected to it. Figure L shows a single switch with 8 hosts. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=single,8 Figure L: Single Topology (8 Hosts) after Pinging All Hosts Figure L1: Tree Topology (48) ..after Pinging All Hosts Figure L2: Single Topology (96 Hosts) after Pinging All Hosts
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 26 5.4.3) Tree Topology Tree topologies consist of single switches along with other switches connected depending on a fan- out number. The fanout value determines how many switches offset the core switch. Figure M shows a tree topology with a depth and fanout of 3. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=tree, depth=3,fanout=3 Figure M: Tree Topology (Depth=3, Fanout=3) Figure M1: Tree Topology (Depth 3, Fanout=3) after Pinging All Hosts Figure M2: Tree Topology (Depth 2, Fanout=10) after Pinging All Hosts
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 27 5.4.4) Torus Topology A Torus topology interconnects the processing nodes within a parallel computer system. Figure N shows a basic Torus topology, whereas Figure N1 shows that topology after being pinged and Figure N2 shows a more complex Torus Topology. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=torus,4,4 Figure N: Torus Topology (4,4) Figure N1: Torus Topology (4,4) after Pinging All Hosts Figure N2: Torus Topology (16,16) after Pinging All Hosts
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 28 5.5) Capturing & Analysing OpenFlow Messages Wireshark is an application which allows for real time packets to be captured and displayed in a user friendly manner. In this project, Wireshark is going to be used to capture and analyse OpenFlow packets. To visualise the communication between the controller and switch, Figure O shows the main components of an OpenFlow switch. To start the experiment, a single switch topology with two hosts is going to get created using the code below in Mininet. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=single,2 – switch=ovsk,protocols=OpenFlow13 --mac This code initiates contact with the SDN controller via its IP address. Then it initiates the Open vSwitch in the kernel mode for each of its switches. This just means the OpenFlow switch is going to use the OpenFlow protocol to communicate with the ODL controller. The code specifies that OpenFlow 1.3 is going to be used and a mac command to ensure that mac addresses are easy to read. To start a capture, the ‘ping’ command will be used to communicate between the hosts, as shown below. h1 ping h2 Figure O1: Wireshark Capture Figure O1 shows the Wireshark capture, in particular the red box highlights the first communication between the switch and controller. The first message is a ‘HELLO’ message. So the switch with the IP address of 192.168.0.10 says ‘Hello’ to the ODL controller with the IP address of 192.168.0.76 and vice versa. OpenFlow Protocols Controller OpenFlow Channel Group Table Flow Table Flow Table Pipeline Figure O: The Main Components of an OpenFlow Switch
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 29 5.5.1) OpenFlow Hello Message Figure O2: Detailed Information from the Switch to ODL Controller Figure O3: Detailed Information from the ODL Controller to Switch Figure O2 and O3 shows more information regarding the communication between the switch and the controller. Specifically they are negotiating what the highest version of OpenFlow supports by both sides. These are what the colored boxes represent:  The Orange box shows that there is TCP and IP connectivity as well as the source/destination addresses and port numbers. The traffic still uses TCP/IP protocols however in SDN, the controller is able to manage the traffic and so networking devices become forwarding devices.  The Blue box states that both the controller and switch are able to support OpenFlow v1.3 and are communicating a ‘HELLO’ message, which is a symmetric message.  The Red box indicates that the switch has a value of ‘10’ which represents the version of OpenFlow, so in addition to supporting version 1.3, it can support version 1.0. The Controller also has a value of 12, meaning it can support version 1.3 only. If both the controller and switch cannot negotiate which version of OpenFlow to use, the connection will fail, meaning it will not allow for communication.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 30 5.5.2) Features Request & Reply After the switch and controller successfully negotiate the version of OpenFlow to use, the next set of messages is a FEATURES REQUEST/REPLY from the controller to the switch, as shown in Figure O4. The controller initially identifies the switch and reads its basic capabilities. Figure O4: Features Request/Reply Figure O5: Features Reply from Switch to Controller  datapath_id: This is a unique identifier for the switch where the lower 48-bits are for a MAC address whereas the upper 16 bits are implementer-defined (i.e. HP switches uses VLAN ID). The device could also be a router, firewall or load balancer.  n_table: The number of tables supported in the OpenFlow pipeline (switch). Figure O5 shows that this switch can support 254 tables. 5.5.3) Other Types of Messages Different types of message requests have different outputs. Multipart Messages: These are used to encode, request or reply. These carry large amounts of data and would not always fit into a single OpenFlow message as it is limited to 64kb. These messages are primarily used to request statistics, port and state information as well as table features. For example the controller may wish to learn the manufacturer information, hardware and software description, in order to learn the switches capabilities. These functionalities are what make SDN controllers more intelligent, which help to make better decisions in regards to the health of the network.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 31 5.6) Generating & Measuring Traffic To generate traffic within a Mininet network, various client and server programs allow this to happen. For example, ping, wget, iperf, curl, netcat, netperf etc. So Mininet allows us to run self- contained regression tests. The method that is going to be used to generate traffic is going to be the iperf command. Ping all has recently been used however iperf is another networking tool which was developed to measure both Transmission Control Protocols (TCP) and User Data Gram Protocol (UDP). Iperf can be used to check speed between two computers by measuring bandwidth, packet lost, delay jitter etc. Below we will test a few topologies. Figure M: shows iperf test in a single topology with 2 hosts Figure M1 shows that an iperf server is running on one host and also an iperf client is running on the other host. The results are shown as follows. Figure M2: iperf using a Torus Topology (4, 4) It can be seen that the greater the topology in terms of hosts and switches the less the bandwidth whereas the smaller the topology the greater the bandwidth.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 32 5.7) Yang UI The role of the Software Defined networking controller enables us to control and manage a network. Yang is a data modelling language which defines networking devices, operations and service configurations. The two new applications introduced by OpenDayLight are YANGUI and the YANG Visualizer which can be seen in Figure N. This figures main content shows a list of Rest API’s which are loaded into the controller. Figure N: Yang UI – List of Rest API’s Figure N1: Detailed View of Node Inventory API Figure N1 shows the API listing for the OpenDayLight inventory, in particular the nodes. You can use this menu to either GET, PUT, POST, DELETE and then to send requests to the controller. There is a modern software called POSTMAN which helps developers to develop APIs faster.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 33 6) Evaluation Both NFV and SDN complement each other. This project has demonstrated that these concepts are easy to manage and set up. SDN uses software-centric methods which can be seen in the YANG UI model. This feature in the OpenDayLight controller allows the network administrator to change networking functions easily and quickly. In results, on-site infrastructure upgrades and deployments are more remotely accessible as virtualisation technology eliminates on-site hardware. For example network functions like firewalls and routers can be installed without additional on-site hardware. SDN has also demonstrated its scalability in terms of topologies. Virtualisation allows for hosts and switches to act like real physical items. This in result is now saving physical space and costs as when a network is software based rather that physical, customers will invest less in hardware which in result frees up space in server rooms hence cutting down on operational costs. The concept of SDN has also enhanced security. This concept is allowing network service providers to respond and deploy updates when an attack occurs. Problems can be isolated and contained more easily. For example, in a Distributed Denial of Service attack, the network can scale in real time in order to avoid any sort of disruptions to customer networks. So Software-Defined Networking is here however it is going to be a challenge to integrate and make it the de facto standard. 6.1) Problems Encountered There were several problems which were encountered within the duration of this project, which in result took up quite a chunk of the project time. The main problem experienced in this project was to do with the set-up of all the elements which were required to demonstrate Software-Defined Networking. Initially, there was a problems setting up the OpenDayLight controller on the physical machine as every time the ODL controller was launched it was not 100% guaranteed it will operate. Every time the karaf console tried to launch OpenDayLight it would freeze and maybe be work one out of ten times when reinstalling and installing again. Once it did operate, there was problems getting Mininet and the controller to communicate as there was problems with the IP addresses. The laptop initially used for this project was a 7 year old Samsung laptop. This laptops capacity was near enough full thus making it really slow. There was also an initial confusion when running a hypervisor whether the memory needed to virtualise different system would be virtual memory or actual physical memory. It was discovered that running the Ubuntu Linux operating system on a Windows laptop using a hypervisor, added an extra layer of complexity as it was virtualised. This problem was solved thanks to the project supervisor and the technical team at University. They provided a new laptop with Ubuntu natively installed. So already the extra layer of complexity was removed and the laptops hardware was more than capable of handling the project activities. Thanks to project planning, there was time for this contingency, however it must be noted that valuable time was wasted. Overall, this has been a fantastic learning and knowledgeable experience.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 34 7) Conclusion To conclude, Software-Defined networking has been thoroughly investigated throughout this project. As technology is developing at an accelerating pace in this day and age, there is an exponential growth in data and increased demand for bandwidth. Traditional networking is proving to be very inflexible and static possessing little agility while being error prone in which networking infrastructures are not getting completely utilized. The introduction of both SDN and NFV have introduced more effective and intelligent ways to manage and build networks. The on-demand services provided by the World Wide Web has seen a shift from traditional networking to software-centric networking, thus making NFV and SDN more scalable and cost effective. This paper has defined SDN, while comparing to traditional networking methods. The SDN architecture was investigated, developing a greater understanding of how SDN operates. It has been seen that the SDN controller possess greater control which allows can make networking more effective and efficient. This project also designed an SDN environment by using network emulators, controllers and network monitoring tool to gain a greater understanding of the concept. To improve this project, more practical investigations should have been carried out, however this project did have unpredictable problems. Overall however, this project gives a greater understanding to the SDN concept. It has been a fantastic learning and knowledgeable experience. 7.1) Future Research There are many challenges in Software-Defined Networking which require attention and different organizations are continually researching and enhancing SDN. APPENDIX 5 shows the current research projects being undertaken by various companies for SDN. The open issues cover the complete lifecycle of SDN, starting from standardization, implementation to deployment. These are discussed as follows.  The Standardization of SDN: At the current moment, OpenFlow represents the official de facto implementation for the Software- Defined Networking concept. The Internet Engineering Task Force (IETF) have recently released a new SDN framework [51]. Network Functions Virtualization (NFV) highly complements SDN and ETSI industry Specification Group (ISG) have now started promoting NFV [52]. Also fragmentations in APIs and controller functions provide a barrier for commercial development in SDN. As OpenFlow evolves, it is allowing more interpretations which is causing unpredictable disorders [53].  The Implementation of SDN: SDN decouples the control plane entirely from the data plane which in result completely eradicates the routing protocols on board switching devices. This concept however can be seen to be idealistic which is preventing SDN from widespread adoption. Organizations classify SDN as a risky in terms of investment as all conventional networking devices would have to be replaced.  The Deployment of SDN: In order for a wide deployment of SDN a further study needs to be undertaken in areas such as wireless mesh networks with fast client mobility [55], wireless sensor networks which require high reliability and reachability[56] and carrier networks with carrier-grade requirements [54]. The issues associated with SDN are not exhaustive but are promising towards the evolution of Software Defined Networking.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 35 References [1] Benson T, Akella A, Maltz. (2009). Unravelling the complexity of network management. Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation. (9), P.335-348. Last accessed 26th June 2016. [2] Kreautz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. (2014). Software- Defined Networking: A Comprehensive Survey. IEEE Xplore. P.1-61. Last accessed 26th June 2016. [3] Raghavan B, Casado M, Kopenen T, Ratnassamy S, Ghodsi A, Shenker S. (2012). Software- defined internet architecture: Decoupling architecture from infrastructure. Proceedings of the 11th ACM Workshop on Hot Topics in Networks. P.43-48. Last accessed 27th July 2016. [4] Ghodsi A, Shenker S, Kopenen T, Singla A, Raghavan B, Wilcox J. (2011). Intelligent design enables architectural evolution. Available: http://people.eecs.berkeley.edu/~alig/papers/intelligent-design-evolution.pdf Last accessed 27th July 2016. [5] Schenker S. (2011). The Future of Networking, and the Past of Protocols. Available: http://www.youtube.com/watch?v= YHeyuD89n1Y . Last accessed 27th June 2016. [6] Mckeown N. (2011). How will SDN shape Networking? Available: http://www.youtube.com/watch?v=c9-K5OqYgA . Last accessed 27th July 2016. [7] Kim H and Feamster N. (2013). Improving network management with software defined networking. Communication Magazine, IEEE. 51 (2), P.113-120. Last accessed 27th July 2016. [8] Kopenen T, Casado N, Gude J, Stribling K, Poutiveski L, Zue M, Ramanathan R, Iwata Y, Inouye H , Hama T, Shenker S. (2010). Onix: a distributed control platform for large-scale production networks. Proceedings of the 9th USENIX conference on Operating systems design and implementation. (10), P.1-6. Last accessed 28th June 2016. [9] Jain S, Kumar A, Mandal S, Ong J, Poutievski L, Singh A, Venkata S, Wandere J, Zhou J, Zhu M, Zolla J, Vahdat A. (2013). B4: experience with a globally-deployed software defined wan. In Proceedings of the ACM SIGCOMM 2013 conference. P. 1- 14. Last accessed 28th June 2016. [10] ONF. (2014). Open networking foundation. Available: https://www.opennetworking.org/. Last accessed 28th June 2016. [11] Yageneh S, Tootoochian A, Ganjali Y. (2013). On scalability of software-defined networking. IEEE Xplore. 51 (2), P.135-140. Last accessed 28th June 2016. [12] VMware, Inc. (2013). VMware NSX Virtualization Platform. Available: https://www.vmware.com/products/nsx/. Last accessed 28th June 2016. [13] OpenDaylight. (2013). OpenDaylight: A Linux Foundation Collaborative Project. Available: http://www.opendaylight.org. Last accessed 28th June 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 36 [14] Horing S, Menard J.Z, Staehler R.E, Yokelson B.J. (1982). Stored Program Controlled Network: Overview. Bell System Technical Journal. 61 (7), P.1579-1588. Last Accessed 16th June 2016. [15] Van der Merwe J, Cepleanu A, D’Souza K, Freeman B. (2006). Dynamic Connectivity Management with an Intelligent Route Service Control Point. Available: https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/irscp.pdf. Last accessed 23rd June 2016. [16] Van Der Merwe J.E, Rooney S, Leslie I.M, Crosby S.A. (1997). The Tempest-a practical framework for network programmability. IEEE Network. 12 (3), P.20-29. Last Accessed 16th June 2016. [17] Feamster N, Balakrishnan H, Rexford J , Shaikh A, van der Merwe J. (2004). The Case for Separating Routing from Routers. MIT Computer Science & AI Lab. P.1-8. Last accessed 23rd June 2016. [18] Caesar M, Caldwell D, Feamster N, Rexford J, Shaikh A, and van der Merwe J. (2005). Design and implementation of a routing control platform. Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation. 2 (NSDI), P.15–28. Last accessed 24th June 2016. [19] Vasseur J and Roux J.L. (2009). Path Computation Element (PCE) Communication Protocol (PCEP). Available: https://www.rfc-editor.org/rfc/rfc7150.txt. Last accessed 24th June 2016. [20] Doria A, Salim JH, Haas R, Khosravi H, Wang W, Dong L, Gopal R, Halpern J. (2010). Forwarding and Control Element Separation (ForCES) Protocol Specification,” Available: http://www.ietf.org/rfc/rfc5810.txt. Last accessed 24th June 2016. [21] Greenberg A, Hjalmtysson G, Maltz D, Myers A, Rexford J, Xie G, Yan X, Zhan J, Zhang H. (2005). A clean slate 4D approach to network control and management. ACM SIGCOMM Computer Communication Review. 35 (5), P.41-54. Last accessed 24th June 2016. [22] Casado M, Freedman MJ, Petit J, Luo J, McKeown L, Shenker S. (2007). Ethane: taking control of the enterprise. ACM SIGCOMM Computer Communication Review. 37 (4), 1-12. Last accessed 24th June 2016. [23] Casado M, Garfinkel T, Akella A, Freedman MJ, Boneh D, McKeown N, Shenker S. (2006). SANE: a protection architecture for enterprise networks. Proceedings of the 15th conference on USENIX Security Symposium. (15). Last accessed 24th June 2016. [24] McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. (2008). OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review. 38 (2), P.68-75. Last accessed 24th June 2016. [25] Mohyuddin A, Dowland PS. (2007). The Art of Network Monitoring. Available: https://www.cscan.org/download/?id=394. Last accessed 28th June 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 37 [26] Villars RL, Olofson CW, Eastwood M. (2011). Big data: what it is and why you should care. White Paper, IDC. MA, USA [28] Kelly B. (2002). Quality of Service in Internet Protocol (IP) Networks .Available: http://www.wainhouse.com/files/papers/wr-qos-in-ip-networks.pdf. Last accessed 29th June 2016. [29] Almes G, Kalidind S, Zekauskas M. (1999). A One-way Packet Loss Metric for IPPM. RFC 2680 (Proposed Standard). Last accessed 28th June 2016. [30] Gourov VN. (2013). Networking Monitoring with Software Defined Networking - Towards OpenFlow network monitoring. Last accessed 20th June 2016. [31] Chimento P and Ishac J. (2008). Defining Network Capacity. Last accessed 28th June 2016. [32] US National Institute of Standards & Technology (NIST). (2011). NIST Cloud Computing Program. Available: http://www.nist.gov/itl/cloud/. Last accessed 5th May 2016. [33] Levin D, Wundsam A, Heller B, Handigol N, and Feldmann A. (2012). Logically centralized? State Distribution Trade-offs in Software Defined Networks in Proceedings of the first workshop on Hot topics in Software Defined Networks, HotSDN. P.1-6. Last accessed 19th August 2016. [34] Fratto, M. (2012). What is the difference between Control plane and Data plane in the context of networking equipment like routers / switches? Available: https://www.quora.com/What-is-the- difference-between-Control-plane-and-Data-plane-in-the-context-of-networking-equipment- like-routers-switches. Last accessed 19th August 2016. [35] Rao S. (2014). SDN Series Part One: Defining Software Defined Networking. Available: http://thenewstack.io/defining-software-defined-networking-part-1/. Last accessed 19th August 2016. [36] Cisco. (2011). Implementing Management Plane Protection. Available: http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4- 1/security/configuration/guide/syssec_cg41crs_chapter7.html. Last accessed 19th August 2016. [37] Rouse M. (2013). Control Plane (CP). Available: http://searchsdn.techtarget.com/definition/control-plane-CP. Last accessed 19th August 2016. [38] Big Switch Networks. (2013). The Open SDN Architecture. Available: https://www.bigswitch.com/sites/default/files/sdn_overview.pdf. Last accessed 19th August 2016. [39] Raghavan B, Casado M,Koponen T, Ratnasamy S,Ghodsi A, Shenker S. (2012). Software defined Internet architecture: decoupling architecture from infrastructure. In Proceedings of the 11th ACM Workshop on Hot Topics in Networks. HotNets XI, NY, USA. P.43-48. Last accessed 19th August 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 38 [40] McNickle M. (2014). Five SDN protocols other than OpenFlow. Available: http://searchsdn.techtarget.com/news/2240227714/Five-SDN-protocols-other-than-OpenFlow. Last accessed 22nd August 2016. [41] SDX Central. (2016). Understanding the SDN Architecture. Available: https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/ Last accessed 22nd August 2016. [42] PL Vision. (2015). Software-Defined Networking. Available: http://plvision.eu/expertise/networking/software-defined-networking/. Last accessed 25th August 2016. [43] Rao, S. (2015). SDN Series Part Eight: Comparison Of Open Source SDN Controllers. Available: http://thenewstack.io/sdn-series-part-eight-comparison-of-open-source-sdn-controllers/. Last accessed 27th August 2016. [44] Rao S. (2015). SDN Series Part Six: OpenDaylight, the Most Documented Controller. Available: http://thenewstack.io/sdn-series-part-vi-opendaylight/. Last accessed 27th August 2016. [45] Henthorn-Iwane A. (2015). Four open source networking projects explained. Available: https://thestack.com/iot/2015/02/02/four-open-source-networking-projects-explained/. Last accessed 27th August 2016. [46] Open Daylight. (2016). ODL Beryllium (Be) - The Fourth Release of OpenDaylight. Available: https://www.opendaylight.org/odlbe. Last accessed 27th August 2016. [47] SDX Central. (2016). What is OpenFlow? Definition and how it relates to SDN. Available: https://www.sdxcentral.com/sdn/definitions/what-is-openflow/. Last accessed 28th August 2016. [48] OpenFlow (2016). What is OpenFlow? Available: http://archive.openflow.org/wp/learnmore/. Last accessed 28th August 2016. [49] Mininet. (2016). Mininet Overview. Available: http://mininet.org/overview/ Last accessed 28th August 2016. [50] Open Networking Foundation. (2014). OpenFlow Switch Specification. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openflow/openflow-switch-v1.5.0.noipr.pdf. Last accessed 11th September 2016. [51] Nadeau T, Pan P. (2011). Framework for Software Defined Networks.Available: https://tools.ietf.org/html/draft-nadeau-sdn-framework-01. Last accessed 11th September 2016. [52] ETSI Industry Specification Group for Network Functions Virtualization (ISG NFV), (2012). Network Functions Virtualisation. Available: http://www.cisco.com/en/US/solutions/collateral/ ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf. Last accessed 11th September 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 39 [53] Kuzniar M, Persini P, Canini M, Venzano and Kostic D. (2012). A SOFT way for OpenFlow switch interoperability testing. In Proc. 8th Int. Conf. Emerging Network. Exp. Technol. P.265-276. [54] Kind M, Westphal F, Gladisch A and Topp S. (2012). Split Architecture: Applying the software defined networking concept to carrier networks.in Proc. WTC. P.1-6. Last accessed 11th September 2016. [55] Dely P, Kassler A and Bayer N (2011). OpenFlow for wireless mesh networks. In Proc. 20th ICCCN, P.1-6. Last accessed 11th September 2016. [56] Mahmud A and Rahmani R (2011). Exploitation of OpenFlow in wireless sensor networks in Proc. ICCSNT. Volume 1. P.594-600. Last accessed 11th September 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 40 APPENDIX 1) High-Level overview of a SDN architecture Source: Open Networking Foundation. (2013). SDN Architecture Overview. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN- architecture-overview-1.0.pdf. Last accessed 28th June 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 41 APPENDIX 2) Software Defined networking Versus Traditional and Conventional Networking Source: Kreautz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. (2014). Software- Defined Networking: A Comprehensive Survey. IEEE Xplore. P.5. Last accessed 26th June 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 42 APPENDIX 3) OpenDaylights Feature List Source: Open Daylight. (2016). OpenDaylight Features List. Available: https://www.opendaylight.org/opendaylight-features-list#NEMO. Last accessed 27th August 2016.
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 43 APPENDIX 4) OpenDayLight – 4th Release Beryllium’s Architectural Diagram
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 44 APPENDIX 5) Current Research Projects
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 45 APPENDIX 6) Research Proposal Contact Details Name Jasjoot Singh Mudhar Student ID: B530429 Course: MSc Internet Media Clouds with Business Institute: Institute of Digital Technologies Contact Number: 07534243183 Email: J.mudhar-15@student.lboro.ac.uk / Jmudhar90@hotmail.co.uk Project Details Title : Deployment of a Software Defined Network Testbed on the Cloud Summary: SDN allows for a much more dynamic usage of the network resources in order to accommodate appropriately various types of applications with different QoS requirements. The proposed MSc dissertation focuses on investigating on Software Defined Network (SDN) technologies and the implementation of one of the technologies in a Cloud environment (possibly MS Azure). A review of current SDN open-source technologies will be conducted in addition to literature review on the challenges in performance monitoring in terms of link utilisation, delay and packet loss in the context of SDN. The project will also seek to find answers to a number research questions, such as: Are contemporary monitoring techniques adequate? If not, which are the current monitoring solutions for SDN? Keywords: Software Defined Network, Cloud Environment, Network Performance Monitoring Key Dates for Project Assessment Size Weight Submission date A Research proposal 2,000 Words 20% of assessment Semester 2: 4th of May at 5pm A Literature Review 2,000 Words 20% of assessment Semester 2: Mid to late June Final Dissertation Final Dissertation: 10,000 Words 60% of assessment Semester 3: September 12, 2016 Academic History – Current MSc Internet Media Clouds with Business Internet and Communication Networks Collaborative Project Mobile Broadband and Wireless Networks Innovation Management Internet of Things and Application Intellectual Property Cloud Technologies and Systems Media Cloud Applications and Services Dissertation Academic History – Previous BSc Computing with Digital Media Undergraduate Information Communication & Technology A-Levels Information Communication & Technology GCSE
Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Gant Chart Stages Month May June July July Sept Week Commencing 2nd 9th 16th 23th 30th 5th 13th 20th 27th 29th 4th 11th 18th 25th 1st 8th 15th 22nd 29th 5th 12th Week Number 10 11 12 13 14 15 Summer Term (Semester 3) Planning Literature Review Analysis Exam/Revision Design Implementation Experiment Evaluation Project Report DD This chart shows the project schedule as well as the start and end date of tasks which is going to be used to track progress, analyse and manage workloads. Gantt Chart

More Related Content

PDF
IRJET- Build SDN with Openflow Controller
IRJET Journal
 
PDF
Load Balance in Data Center SDN Networks
IJECEIAES
 
PDF
Software Defined Networks Explained
CM Research
 
PDF
Introduction to Software-defined Networking
Anees Shaikh
 
PDF
SDN Introduction
Steve Goeringer
 
PDF
Lte community networks in brazil sustainable modeling, deployment and mainte...
Christian Esteve Rothenberg
 
PDF
Rise of Network Virtualization
Arinto Murdopo
 
PDF
The Impact on Security due to the Vulnerabilities Existing in the network a S...
IJAEMSJORNAL
 
IRJET- Build SDN with Openflow Controller
IRJET Journal
 
Load Balance in Data Center SDN Networks
IJECEIAES
 
Software Defined Networks Explained
CM Research
 
Introduction to Software-defined Networking
Anees Shaikh
 
SDN Introduction
Steve Goeringer
 
Lte community networks in brazil sustainable modeling, deployment and mainte...
Christian Esteve Rothenberg
 
Rise of Network Virtualization
Arinto Murdopo
 
The Impact on Security due to the Vulnerabilities Existing in the network a S...
IJAEMSJORNAL
 

What's hot (20)

PDF
Trabalho berckley
Kamilo Souza
 
PDF
Netsoft 2020 S4SI Workshop Panel
Christian Esteve Rothenberg
 
PDF
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
IBM India Smarter Computing
 
PDF
CONCEPTUAL FRAMEWORK OF REDUNDANT LINK AGGREGATION
cseij
 
PDF
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
pijans
 
PDF
E018113036
IOSR Journals
 
PDF
Mobile World Congress 2017 - Creating Agility & Efficiency at Scale: New Econ...
Mehdi Sif
 
PPTX
Software-Defined Networking(SDN):A New Approach to Networking
Anju Ann
 
PPTX
Software-Defined Networking (SDN): Unleashing the Power of the Network
Robert Keahey
 
PPTX
SDN( Software Defined Network) and NFV(Network Function Virtualization) for I...
Sagar Rai
 
PDF
Report-SDN
Deeptiman Mallick
 
PDF
Performance and Simulation Study of TheProposed Direct, Indirect Trust Distri...
cseij
 
PDF
11.providing security to wireless packet networks by using optimized security...
Alexander Decker
 
PDF
Woodside Capital Partners SDN Seminar 6.19.13
WoodsideCapital
 
PDF
IMPROVEMENTS FOR DMM IN SDN AND VIRTUALIZATION-BASED MOBILE NETWORK ARCHITECTURE
ijmnct
 
PDF
Improvements for DMM in SDN and Virtualization-Based Mobile Network Architecture
ijmnct
 
PDF
IMPROVEMENTS FOR DMM IN SDN AND VIRTUALIZATION-BASED MOBILE NETWORK ARCHITECTURE
ijmnct
 
PDF
Rui aguiarphd proposal
KellyCheah
 
PDF
CONTAINERIZED SERVICES ORCHESTRATION FOR EDGE COMPUTING IN SOFTWARE-DEFINED W...
IJCNCJournal
 
PDF
A SURVEY ON AUTHENTICATION AND KEY AGREEMENT PROTOCOLS IN HETEROGENEOUS NETWORKS
IJNSA Journal
 
Trabalho berckley
Kamilo Souza
 
Netsoft 2020 S4SI Workshop Panel
Christian Esteve Rothenberg
 
Towards an Open Data Center with an Interoperable Network (ODIN) Volume 3: So...
IBM India Smarter Computing
 
CONCEPTUAL FRAMEWORK OF REDUNDANT LINK AGGREGATION
cseij
 
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
pijans
 
E018113036
IOSR Journals
 
Mobile World Congress 2017 - Creating Agility & Efficiency at Scale: New Econ...
Mehdi Sif
 
Software-Defined Networking(SDN):A New Approach to Networking
Anju Ann
 
Software-Defined Networking (SDN): Unleashing the Power of the Network
Robert Keahey
 
SDN( Software Defined Network) and NFV(Network Function Virtualization) for I...
Sagar Rai
 
Report-SDN
Deeptiman Mallick
 
Performance and Simulation Study of TheProposed Direct, Indirect Trust Distri...
cseij
 
11.providing security to wireless packet networks by using optimized security...
Alexander Decker
 
Woodside Capital Partners SDN Seminar 6.19.13
WoodsideCapital
 
IMPROVEMENTS FOR DMM IN SDN AND VIRTUALIZATION-BASED MOBILE NETWORK ARCHITECTURE
ijmnct
 
Improvements for DMM in SDN and Virtualization-Based Mobile Network Architecture
ijmnct
 
IMPROVEMENTS FOR DMM IN SDN AND VIRTUALIZATION-BASED MOBILE NETWORK ARCHITECTURE
ijmnct
 
Rui aguiarphd proposal
KellyCheah
 
CONTAINERIZED SERVICES ORCHESTRATION FOR EDGE COMPUTING IN SOFTWARE-DEFINED W...
IJCNCJournal
 
A SURVEY ON AUTHENTICATION AND KEY AGREEMENT PROTOCOLS IN HETEROGENEOUS NETWORKS
IJNSA Journal
 
Ad

Similar to B530429_FinalDissertation (20)

PDF
TheimplementationofSoftwareDefinedNetworkinginenterprisenetworks.pdf
Fernando Velez Varela
 
PDF
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Editor IJCATR
 
PDF
Ericsson Review: Software-Defined-Networking
Ericsson
 
PDF
Software Defined Networking (SDN): A Revolution in Computer Network
IOSR Journals
 
PDF
A Centralized Network Management Application for Academia and Small Business ...
ITIIIndustries
 
PDF
Software Defined Networking: A Concept and Related Issues
Eswar Publications
 
PDF
A Survey of Past, Present and Future of Software Defined Networking.pdf
Wendy Belieu
 
PDF
SD_WAN_NFV_White_Paper
Marc Curtis
 
PPTX
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
University of Technology - Iraq
 
PDF
A Survey On Software-Defined Wireless Sensor Networks Challenges And Design ...
Angela Tyger
 
PDF
Survey of optimizing dynamic virtual local area network algorithm for softwar...
TELKOMNIKA JOURNAL
 
PDF
Virtuora Catalog_lowres
Margaret Malone
 
PPTX
Cloud computing and Software defined networking
saigandham1
 
PDF
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
IJCNCJournal
 
PDF
Controller Placement Problem resiliency evaluation in SDN-based architectures
IJCNCJournal
 
PDF
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
IJCNCJournal
 
PDF
Software Defined Networking – Virtualization of Traffic Engineering
QuEST Global (erstwhile NeST Software)
 
PDF
Performance evaluation of software-defined networking controllers in wired an...
TELKOMNIKA JOURNAL
 
PDF
Week 8 Lecture Material.pdf Spftware defined Networking
dinesh579192
 
PDF
Comparative Analysis of POX and RYU SDN Controllers in Scalable Networks
IJCNCJournal
 
TheimplementationofSoftwareDefinedNetworkinginenterprisenetworks.pdf
Fernando Velez Varela
 
Security in Software Defined Networks (SDN): Challenges and Research Opportun...
Editor IJCATR
 
Ericsson Review: Software-Defined-Networking
Ericsson
 
Software Defined Networking (SDN): A Revolution in Computer Network
IOSR Journals
 
A Centralized Network Management Application for Academia and Small Business ...
ITIIIndustries
 
Software Defined Networking: A Concept and Related Issues
Eswar Publications
 
A Survey of Past, Present and Future of Software Defined Networking.pdf
Wendy Belieu
 
SD_WAN_NFV_White_Paper
Marc Curtis
 
Performance Evaluation for Software Defined Networking (SDN) Based on Adaptiv...
University of Technology - Iraq
 
A Survey On Software-Defined Wireless Sensor Networks Challenges And Design ...
Angela Tyger
 
Survey of optimizing dynamic virtual local area network algorithm for softwar...
TELKOMNIKA JOURNAL
 
Virtuora Catalog_lowres
Margaret Malone
 
Cloud computing and Software defined networking
saigandham1
 
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
IJCNCJournal
 
Controller Placement Problem resiliency evaluation in SDN-based architectures
IJCNCJournal
 
Controller Placement Problem Resiliency Evaluation in SDN-based Architectures
IJCNCJournal
 
Software Defined Networking – Virtualization of Traffic Engineering
QuEST Global (erstwhile NeST Software)
 
Performance evaluation of software-defined networking controllers in wired an...
TELKOMNIKA JOURNAL
 
Week 8 Lecture Material.pdf Spftware defined Networking
dinesh579192
 
Comparative Analysis of POX and RYU SDN Controllers in Scalable Networks
IJCNCJournal
 
Ad

B530429_FinalDissertation

  • 1. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar B530429 A dissertation submitted in partial fulfillment of Loughborough University’s MSc Internet Media Clouds with Business Keywords: Software Defined Network, Cloud Environment, and Network Performance Monitoring
  • 2. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 1 Abstract Technology is developing at an accelerating pace in this day and age. There is recognizable trend in the IT industry specifically in the cloud, mobile, social and big data. The future of the Internet is facing new challenges in which high bandwidth, dynamic management and ubiquitous accessibility are highly crucial. Traditional networking is very inflexible and static possessing little agility while being error prone in which networking infrastructure not getting completely utilized. Software Defined Networking (SDN) is a networking paradigm which has recently emerged and is touted as the most promising solution for the future of the internet. The two main characteristics imposed by SDN include the decoupling of the control plane from the data plane and allowing for programmability in network application development. In result, SDN provides a platform which allows for more efficient configurations along with greater flexibility with the ability to accommodate innovative network designs. SDN imposes a three layer architecture which includes the application layer, control layer and an infrastructure layer. This paper will discuss and investigate the key features of SDN as well as discuss the challenges and limitations while comparing to traditional networking. This project is also going practically demonstrate the SDN concept by using a controller to manage a network, a network emulator to develop a realistic virtual network testbed and a network monitoring tools to measure and analyse network activity.
  • 3. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 2 Table of Contents Section Page Number 1 Introduction 4 1.1 Project Aim 4 1.2 Project Objectives 4 2 Literature Review 5 2.1 The Evolution of Networks and Problems 5 2.2 History 6 2.3 Network Monitoring 7 2.3.1 Packet Loss 8 2.3.2 End-to-End Delay 8 2.3.3 Link Usage and Utilization 8 2.3.4 Software-Defined Networking in the Cloud 8 3 Software-Defined Networking 9 3.1 Defining Software-Defined Networking 9 3.1.1 Data Plane 9 3.1.2 Control Plane 9 3.1.3 Management Plane 9 3.2 SDN Architecture 11 3.2.1 Application Tier 12 3.2.2 Control Plane Tier 12 3.3.3 Infrastructure/ Data Plane Tier 12 4 Design 14 4.1 Wireshark 14 4.2 Ubuntu 14 4.3 VMware Workstation Player 12 14 4.4 OpenDayLight (ODL) 14 4.4.1 OpenDayLight – Beryllium 15 4.5 OpenFlow 16 OpenFlow Messages 17 4.6 Mininet 18 4.6.1 Benefits of Mininet 18 4.6.2 Justifications for Project 18
  • 4. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 3 5 Implementation 19 5.1 Hardware 19 5.2 Downloading & Installing OpenDayLight Prerequisites 20 5.3 The OpenDayLight Graphical User Interface (GUI) 22 5.4 Network Topologies 23 5.4.1 Linear Topology 23 5.4.2 Single Topology 25 5.4.3 Tree Topology 26 5.4.4 Torus Topology 27 5.5 Capturing & Analysing OpenFlow Messages 28 5.5.1 OpenFlow Messages 29 5.5.2 Features Request & Reply 30 5.5.3 Other Type of Messages 30 5.6 Generating & Measuring Traffic 31 5.7 Yang UI 32 x 6 Evaluation 33 6.1 Problems Encountered 33 7 Conclusion 34 7.1 Future Implementations 34 References 35 APPENDIX 40 1 High-Level Overview of a SDN Architecture 40 2 Software-Defined Networking VS Traditional Conventional Networking 41 3 OpenDayLight Features List 42 4 OpenDayLight – 4th Release Berylliums 43 5 Current Research Projects 44 6 Project Proposal 45
  • 5. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 4 1) Introduction Software-Defined Networking (SDN) is a new networking paradigm which supports the recent growth in data. This paradigm is making the telecommunications industry more scalable and agile. There is a notable growth in network traffic which is ringing alarms in the IT industry. This is attributed by dynamic cloud workloads, unified communications and video conferencing. At this alarming rate, new technology will continue to force the demand for bandwidth to increase exponentially. The emerging technologies include 4k video, the Internet of Things (IOT), augmented and virtual reality. The capacity in traditional telecoms industry is being outstretched as it is struggling accommodate the rapid increase in data. Traditionally a telecoms network is comprised of single-purpose and specialised equipment which include switches, routers or any other custom built networking devices. In order to add capacity, extra equipment needs to be added to current infrastructure. This was viable for data services include voice traffic as this increased predictably and gradually. However, the demands of modern society is outweighing the current capabilities as these networks cannot accommodate fast enough. There is now a demand for new ways to manage and build data networks. Technology advancements has already seen a profound solution being introduced. Virtualisation is providing a cost effective and scalable solution. Software can be used to virtualise physical hardware and by doing this at a network level allows for rapid expansions. In recent years the concept of Network Function Virtualisation (NFV) and Software-Defined Networking (SDN) have been introduced and touted as the future. The introduction of SDN and NFV represents a dramatic change within the industry. There has been a great shift in how networks are built and designed. The on-demand services are paving a way for software-centric networking which is allowing users to grow and adapt to their business needs. In 2016, it can already be seen that a lot of applications are cloud based, and the foreseen future can see majority of our networks being virtualised in the next five years. These advancements allow for greater agility, flexibility and control for networking services, improving the value of the solution. 1.1)_Project Aims: This projects aims to investigate the concept of Software-Defined Networking in terms of architecture, design and implementation. Then to implement a virtualised testbed using SDN-enabled technologies to analyse various network activities. 1.2) Project Objectives:  To differentiate Software-Defined Networking to traditional networking, exploring in depth the SDN architecture, design and implementation.  To investigate the scalability of the various topologies which can be implemented within a virtualised network  To design a SDN environment in order to practically understand the SDN concept  To develop an SDN networking testbed in order to capture and analyse various network activities and understand the different type of communication between a controller and networking devices.
  • 6. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 5 2) Literature Review 2.1) The Evolution of Networks and Problems The key technologies in switches and routers are the distributed control and transport network protocols in which digital packets transfer information through the World Wide Web. In spite of their widespread adoption, IP networks traditionally are hard to manage as well as complex [1]. High-level network policies are expressed through network operators who are assigned to configuring network devices individually using low-level, vendor-specific commands. As current networks environments are complicated to configure, they endure faults and struggle to adapt to load changes. Existing IP networks virtually lack response mechanisms and do not automatically reconfigure. To enforce the required policies in a dynamic environment is extremely challenging. Current networks are also complicated as they are vertically integrated. The control, data and forwarding planes are the key components in networking hardware as they transfer vertically integrated IP packets from A to B. The control plane decides how to handle network traffic while the data plane forwards traffic in accordance to the decisions made by the control plane. These are all inside networking devices, however these hinders innovation, reduces flexibility and limits evolution of networking infrastructures [2]. In the past decade, there has been a transition from IPv4 to IPv6. IPv6 can be seen merely as a protocol update, still incomplete and possess challenges. Current IP networks are static in terms of evolution and it can take anything between 5 to 10 years for a new routing protocol to be designed, evaluated and deployed. To change internet architecture (i.e., replacing IP) it is not feasible practically [3] [4]. Ultimately, operational and capital expenses have inflated in order to run IP networks. Software Defined Networking (SDN) is a networking paradigm which is emerging and counteracting current infrastructures limitations [5]. For this paradigm, the vertical integration is broken as it separates the control logic (networks control logic) from the underlying switches and routers which forward traffic (data plane) [6]. As the data and control planes are separated, the switches on the network become a forwarding device. A centralized controller (networking operating system) controls the logic logically and also simplifies policies and the network (re)configurations [7]. Figure A: simplified Software-Defined Network architecture model [2] Figure A illustrates a simplified Software-Defined Network architecture model (Appendix 1 shows a high level overview of a SDN networking architecture). Kopenens study in 2010 emphasized that a physical
  • 7. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 6 centralized system does not postulate a logical centralized programmatic model. It must be noted that in order to ensure adequate levels of scalability, performance and reliability, this solution would be precluded. A production-level Software Defined Network design physically resorts to the distributed control planes [8] [9]. As mentioned earlier, Software Defined Networking separates the control and data plane. This can be distinguished by a well-defined programming interface between the SDN controller and switches. OpenFlow is a notable example of an Application Programming Interface (API) [6] [10]. Figure A illustrates that the direct control is given by the controller over the state in the data plane elements through an API. OpenFlow switches have tables depicting packet-handling rules (otherwise known as a flow table). Every rule matches with a subset of the traffic and achieves specific actions (forwarding, dropping, modifying, etc.) on the traffic. The rules initiated on the controller application can enable OpenFlow switches to behave either like router, firewall or other tasks (i.e., traffic shaper, load balancer). In principle, SDN separates the concerns between network policies, their implementation in switches (hardware) and the forwarding of traffic. Separation is a key element to accomplishing flexibility. Network control problems are broken into tractable pieces which make it easier to introduce and create new abstractions in networking. This simplifies network management and facilities networking innovations and evolution. Initially both OpenFlow and SDN started as experiments in academia [6], gaining significant attraction in the industry over the years. This evolution has seen vendors of commercial switches opting to include support of OpenFlow API in their networking equipment. The momentum gained by SDN has seen blue chip companies such as Facebook, Microsoft, Yahoo, Google, Deautsche Telekom, Verizon fund Open Networking Foundation (ONF)[10] with their objective being to promote and adopt SDN via open standards development. Yageneh’s study in 2013 addressed concerns with SDN scalability however it can be seen that the evolution of SDN evolving from academia has been a success in a commercial spectrum [11]. For instance, Google deployed a SDN to interconnect data centres globally. This transition has Google improving its operational efficiency as well as reducing costs [9]. Another instance is NSX, which is VMware’s network virtualization platform [12]. This solution delivers a complete functional network in software using SDN principles. SDN has evolved and developed, giving a better cutting edge advantage compared to traditional networks (Appendix 2 shows SDN versus Traditional Networks). IT organisations (from equipment manufacturers to carriers to financial companies and cloud service providers) have joined the SDN consortia including the OpenDaylight initiative [13] and ONF. SDN now is an important paradigm from the industrial perspective also. 2.2) History The idea of a ‘centralized network architecture’ has been coined for many years. For the past three decades, various research initiatives have been initiated on split architectures. Initially in the 1980’ a circuit switched network called the Network Control Point (NCP) was introduced in which the first attempt to separate control and data plane signalling [14].Prior to this, circuit switches were used to manage all call controls, however this technology was limited. The single switches had limited processing power with a lack of upgrades implementable as well as a lack of visibility on the network. These problems were addressed by NCP as an adjunct call processing platform, which was external to circuit switches. The NCP formed a basis in which many voice network features were built and are still used today (calling cards, call centres, 800-numbers etc.) [15].
  • 8. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 7 In the late 90’s, the Tempest project emerged [16]. This project introduced network virtualization and the concept of switchlets in ATM networks. The core notion was to enable multiple switchlets on a singular ATM switch allowing ATM networks to share physical resources. This project discovered that every individual service has its own needs which require separate control architecture. The question shifted from finding ways to fit new services with the existing architecture to what is the best architecture for the new services [16]. In the 2000’s, IP networks faced similar problems than its predecessor. There was limited visibility on the network; the route controller had limited processing power as well as it being more difficult to configure routers. AT&T conceptualized an “IP-NCP”, which is a platform in which route selection is performed. This improved the control and management of telephone networks and motivated the development of the Routing Control Platform (RCP) [17]. RCP [18], PCE [19] and ForCES [20] proposed the separation of the data and control planes in order to improve management in Ethernet, MPLS, ATM and BGP networks. A conceptual architecture named 4D was introduced [21]. Along with RCP, these architectures were regarded as the forefathers of the Software Defined Network (SDN) notion. Recently, Ethane [22] and SANE [23] projects defined enterprise architectures and proposed the decoupling of the data and control planes for Ethernet networks. Today these technologies can be seen as the predecessors of OpenFlow [24]. Table B presents a summarized overview of the history of programmable networks. Table 1 shows a summarized overview of the history of programmable networks [2] 2.3) Network Monitoring Software Defined Networking is being used to solve current monitoring problems experienced in traditional IP networks. Network monitoring systems are seen as a solution to monitor the performance of the network against bottlenecks, failures or unusual activity which results in a slow or broken down network [25]. The last decade has seen network technologies revolutionized. There is a continuous increase in the volume of data being produced, which is at a record rate [26] as well as traffic in both wired and wireless networks. The capacity and speed of different components such as switches, routers, transmission media in networking systems has increased emphatically. There has also been an increase in multimedia applications including video and audio which make network characteristics more diverse and complex. The packet-switched networks provide best-effort services as opposed to reliable messaging. Now there is an urgent need to ensure network services have performance guarantees in terms of knowing the delay, throughput, loss rate and jitter. Traffic in packet-switched networks does get processed quickly however there is never a guarantee in the Quality of Service (QoS) [27].
  • 9. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 8 A Quality of Service enabled network is compiled of many functions which provide various types of services to different packets, for instance the classifier, rate controller, admission control and scheduler. The scheduler, just as the name suggests, decides the order in which packets get processed, either at the node or transmission over a link. The Active Queue Management determines in which order packets get processed at the node. AQM schemes have evolved significantly overtime [27] The different type of network monitoring include active versus passive methods as well as application and network methods. The networks quality of service can be evaluated by characteristics such as, packet loss, end-to-end delay link usage and utilization and jitter [28]. This also imposes the question to whether contemporary monitoring techniques are adequate. Some networking characteristics used for network monitoring are discussed below. 2.3.1) Packet Loss As the name suggests, this event occurs when not all packets that are sent are received at the destination node. Network congestion, link failures or a change in the topology can cause this. In order to determine whether a packet has reached its destination, packet loss is expressed as a binary number, either 0 or 1. 0 suggest the packets have not been received, whereas 1 is when the packet is delivered successfully [29]. 2.3.2) End-to-End Delay End-to-End delays refer to the time taken for a packet to be transmitted from the source to the destination across a network. Packets can reach their destination via intermediate nodes. There are applications which are influenced by the delay in the network. A network delay subsequently can degenerate an application, which make it an important metric for user experience assurance and a Quality of Service. The total network delay is accumulated of propagation, processing, queueing and transmission delays [30]. 2.3.3) Link Usage and Utilization The link usage is defined as the successful number of received IP-layers bits which are sent from the source and pass via link L during the time interval of T [30]. Both usage are capacity are distinguishable. The link capacity is a value which represents the maximum link usage. The link utilization is represented in binary form. 0 represents the link not being used whereas 1 represents the link being completely saturated [31]. 2.4) Software-Defined Networking in the Cloud The advancements in technology have seen existing technology evolve. Namely, cloud computing is a form of internet-based computing. The US National Institute of Standards & Technology (NIST) in 2011 have defined cloud computing to be a model which enables ubiquitous, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, services and storage conveniently without being rapidly provisioned by service providers[32]. Cloud architectures provide networking infrastructures as-a-service via a group of layers, which are also as-a-service. Cloud computing inherits five fundamental characteristics, three service models and four deployment models. The emergence of cloud computing, in particular virtualisation has seen the industry transform. SDN in particular focuses on the orchestrations and operations of many virtualized compute functions over large networking infrastructures.
  • 10. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 9 3) Software Defined Networking 3.1) Defining Software Defined Networking (SDN) Software Defined Networking (SDN) is a recently new networking paradigm. Brandon Heller’s study in 2012 has quoted that, “SDN is about refactoring of the relationship between network devices and the software that controls them” [33]. The reference of networking devices includes firewalls, gateways, line drivers, modems, terminal adapters, multiplexers, network address translators, network bridges, network interface controllers, protocol converters, proxy servers, routers, switches, hubs and wireless access points. The three basic components of a telecommunication architecture include the control plane, data plane and management plane, as shown in Figure B. 3.1.1) Data Plane The data plane processes the transit traffic, determining the fate of the packets which arrive on an ingress interface. Packets are sent through the ‘fabric’ which interconnect both the ingress and egress interfaces. The data plane also includes forwarding, routing and ARP tables as well as tagging, re-tagging and queuing. The data plane essentially enforces the commands of the control plane [34]. 3.1.2) Control Plane The control plane focusses on collecting, managing and processing network information which determines forwarding/routing decisions. Routers and switches determine where to send packets (L3) and frames (L2) and also exchange information, i.e. status, host reachability with neighbours. Protocols associated with the control plane include BGP, OSPF and STP. The control plane also deals with connectivity, device discovery and service provisioning [35]. 3.1.3) Management Plane The management plane configures, interacts and monitors networking devices as well as and provide managements and configuration services to all the layers of the network stack. The management plane also possess its own protocols such as HTTP, HTTPS, SNMP, SHH, Telnet, TFTP [36]. In traditional networking devices, dedicated hardware carry out data plane activities whereas the CPU of a device handles the control plane operations. (Forwarding) DATA PLANE (Algorithms, Protocols, Tables) CONTROL PLANE (Configuration CLI/GUI) MANAGEMENT PLANE Frame IN Frame OUT Unknown Packets Forwarding Behaviour Figure B: The Planes of Network Elements
  • 11. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 10 In traditional and conventional networking, the control, data and management planes are implemented in the firmware of switches and routers. SDN, on the other hand decouples the control and data planes, eliminates the control plane from the network hardware and implements it in software [37]. This allows for programmatic access, providing dynamic access which enforces flexibility for network administrators. Network administrators are able to shape traffic from a centralized control console without having to interact with individual switches. Flexibility also enables administrators to change the rules in switches, i.e. de-prioritizing, prioritizing as well as blocking specific packets with granular control levels [37]. SDN eradicates the static and complex nature of legacy distributed network architectures as it uses standard based software abstraction between the underlying data forwarding plane and the control plane [38]. Computer scientist, Scott Shenker has described SDN is about ‘achieving forwarding, state distribution and specification abstraction at network control planes’ [39]. In a realization perspective, Software Defined Networking in any network gives flexibility between the points on the design axes: centralized to distributed, fully-consistent to eventually-consistent, micro-flow to aggregated-flow, reactive to proactive, virtual to physical [33]. SDN also allows flexibility in the choice for control planes. Networking devices are now solely forwarding packets (data plane), with the devices being programmed through an open and standard interface (i.e. OpenFlow). The basis of legacy networks will be present in the years to come and have provided a platform for development and integration in SDN. For instance the development in switching and routing protocols have contributed towards the development of SDN controller software. Table 2 shows the different elements from a legacy network stack being embedded within the SDN stack. SDN Stack Legacy Network Stack Applications User Interface Unified Management API Controller Applications Protocol Utilities Switch Hardware Abstraction Layer SDK / Drivers Switching Silicon Traditional Device SDN Architecture Data Plane Management Plane Control Plane Data Plane Control Plane Management Plane OpenFlow Protocol OpenFlow API Figure C: Traditional Architecture V SDN Architecture Controller Networking Device Table 2: Integration of the SDN Stack from the Legacy Network Stack [42] Networking Device
  • 12. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 11 3.2) SDN Architecture Software-Defined Networking architecture describes how computer systems and networks are compiled using open source software-based technologies along with commodity networking hardware in which both the data layer and control plane are separated in the network stack [41]. In 2008, the Open Network Foundation (ONF) defined OpenFlow, as the first standard communications interface between the decoupled data and control planes. In SDN, OpenFlow protocols transit messages between underlying network infrastructure and the SDN controller, which brings networking applications to life. The current issues imposed by OpenFlow include scalability, security and the requirement for specialized hardware. The other protocols which make up SDN include BGP, NETCONF, XMPP, OVSDB and MPLS-TP [40]. Figure D illustrates an SDN architecture, which is composed of three-tiers of functionality. SDN architecture enables applications to gain extra information from a controller regarding the state of the entire network, something which was not possible in traditional networking, as they are application aware [41]. The three tiers architecture include:  Application Tier  Control Plane Tier  Infrastructure/Data Plane Tier Appendix 1 shows a high level overview of a SDN architecture Application Tier Control Plane Tier Data Plane Tier Northbound API Figure D: SDN Architecture Data Plane Interface (OpenFlow) SDN Controller Network Services Network Devices Network DevicesNetwork Devices APPAPP APP 3rd Party Applications Physical Switch Virtual Switch
  • 13. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 12 3.2.1) Application Tier The application tier encompasses solutions which are focused on the expansion of network services. The solutions are primarily software applications which communicate with the SDN controller via an Application Programming Interface (API). Applications form an abstracted view of the network as they collect information from the controller to aid in decision making. The different type of applications include network virtualization, network monitoring, network management, traffic engineering, etc. [41]. 3.2.2) Control Plane Tier The control plane tier, also known as the ‘Networking Operating System (NOS)’, is a key component of SDN and this is what differentiates from traditional networking technologies. In the control plane a SDN controller is used and provides a centralized and global view of the entire network as well as taking requests via API’s from the application layer. This enables monitoring and management for a network which is done through standard protocols, i.e. OpenFlow. This well-defined protocol enables the control layer to have direct access to the forwarding planes within network devices. The most common open source SDN controllers include Floodlight, NOX/POX, ODL, ONOS, RYU and Trema [42]. 3.2.3) Infrastructure/ Data Plane Tier The basis of a network is provided by the infrastructure tier which includes networking equipment that allows traffic forwarding. Traditionally the infrastructure layer consists of switching and routing protocols (forward decision-making algorithms). These are static varying from different vendors, which restricts adjustability and flexibility. SDN on the other hand, provides a cleverer approach. The forwarding algorithms get decoupled from networking equipment, which then get implemented in common programming languages in commodity servers [42]. In result, networking nodes become forwarding devices, only establishing communication with a controller which makes them less intelligent. This layer also includes southbound protocols such as OpenFlow, which allows connection from the infrastructure to control layer. Other southbound protocols include OVSDB. SNMP, PCEP. 3.3) SDN Controllers The controller in a Software Defined Network is essentially the brains of the network. Applications form a strategic control point within the network allowing low level components to be managed via southbound APIs. The northbound API on the other hand allows components in a network to communicate with high level components. Controllers typically have a pool of pluggable modules which perform various tasks. Tasks can include anything from inventorying to gathering network statistics. OpenFlow, NETCONF and OVSDB remain the popular choice of protocols used in SDN. Figure E shows the important features of a SDN controller. SDN Controller Features North Bound APIs & Apps Platform & Services South Bound Protocols Figure E: The features of a SDN controller
  • 14. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 13 As mentioned earlier, SDN is a new networking paradigm and it benefits from an open source community. Figure F illustrates the various aspects of an SDN controller including the features, application networks, uses cases and efficacy. It is important to note that the features form an important part which influence the different efficiency targets of the controller, these include extensibility, programmability, scalability and interoperability. The controller efficacy is an umbrella phrase used to define the various performance parameters, including performance, scalability, security and reliability. Table 3 shows a comparison of open source controllers using the use cases mentioned above. This comparison will be used to justify the choice of controller for this project. Controllers Use Cases Floodlight NOX/POX ODL ONOS RYU Trema Campus Networks Partial Partial Partial No Partial Partial Dynamic Network Taps Yes No Yes No Yes No Hop-By-Hop Network Virtualization Yes No Yes Yes No No Legacy Network Interoperability No No Yes Partial No No Load Balancing No No Yes No No No Multi-Layer Network Optimization No No Partial Partial No No Network Monitoring Yes Partial Yes Yes Yes Partial Network Virtualization by Virtual Overlays Partial Yes Yes No Yes Yes OpenStack Neutron Support Yes No Yes No Yes No Policy Enforcement Partial No Yes Partial No No Routing Yes No Yes Yes Yes Yes Service Insertion and Chaining No No Yes Partial Partial No Traffic Engineering Partial Partial Yes Partial Partial Partial Transport Networks, NB, Traffic-Rerouting, Interconnecting DCs, etc. No No Partial Partial Partial No Table 3: Comparison of Open Source Controllers in consideration to different Use Cases [43] Influences Controller Features: -Platform -Services -Northbound APIs & APPs -Southbound Protocols Controller Efficacy: -Performance -Scalability -Security -Reliability Use- Cases: - Loud Balancing -Network Monitoring -Network Virtualization with Cloud- Orchestration -Service Insertion & Chaining -Traffic Engineering, - Policy Enforcement Application Networks: -Data Centre Networks -Multi-Layered Transport Networks -Enterprise & Campus Networks Figure F: The features of a SDN controller
  • 15. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 14 4) Design This project is going to incorporate all theory mentioned in this report and demonstrate the features and functionality of Software-Defined Networking. The objective of this project is to deploy a testbed for performance monitoring in terms of link utilisation, delay and packet loss. By using the SDN architecture, below is a list of the applications which are available to elaborate SDN.  Applications: Wireshark, FlowMaker, HP Network Visualizer, HP Network Optimizer, Bash scripts  Controllers: Floodlight, HP/HPE VAN SDN, OpenDaylight (ODL), ONOS, RYU  Infrastructure: Mininet’s Open vSwitch using OpenFlow This project is going to demonstrate the concepts of SDN by using different application in accordance to the SDN network stack. This can be seen over the following pages. The selected applications for this project are stated below.  Wireshark: An open source packet analyzer which will be used for network monitoring and analysis.  OpenDayLight: This is an open-source SDN controller which offers abstraction to network services.  Mininet: This is a network emulator which will be used to create realistic virtual networks. 4.1) Wireshark Formerly known as Ethereal, Wireshark is an application which allows for real time packets to be captured and displayed in a user friendly manner. In this project, Wireshark is going to be used to analyse OpenFlow packets. 4.2) Ubuntu This is a debian-based open source Linux Operating System. In order to achieve the best results for ODL, the documentation has stated that ODL should run natively using a Linux operating system. For this project, the latest Ubuntu Desktop 16.04.1 LTS version is going to be used. In particular a command-line interface terminal is going to be used in order to streamline OpenDaylight. 4.3) VMware Workstation Player 12 The VMware Workstation is a hypervisor which can run on both Linux and Windows operating system. This software allows for virtual machines (VMs) to be created on a single physical machine. This software is going to be used to run Mininet by creating a virtual machine so that virtual experiments can take place for this project. 4.4) OpenDayLight (ODL) Introduced in 2013, the OpenDaylight Project (ODL) is an open-source Software-Defined Networking project which is hosted by the Linux Foundation. David Meyer from Brocade has nicely stated that “OpenDaylight can do for networking what Linux has done for the computing industry” [44]. This project was created to advance SDN adoption and develop the basis for robust network function virtualization (NFV). ODL focuses on the SDN control layer as it offers the service abstraction for services such as data packet delivery to northbound applications, conveying topology information, flow programming, showing statistics plus a node and connection inventory [44].
  • 16. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 15 Figure G presents a simplified ODL architecture. The service abstraction layer enforces the ODL controller (Which operates on a Java Virtual Machine) to support different southbound SDN approaches though plugins. The northbound API on the other hand is used to provide consistent connection to business applications through bidirectional REST and the OSGi framework (45). The ODL platform also consists of features, plug-ins and protocols which can be integrated in various ways in order to deliver an inclusive set of SDN use cases. Appendix 3 shows you the list of services, applications and protocols that Open Daylight can support. The current Southbound SDN technologies which ODL support include OVSDB, OpenFlow, Yang tools, BGP, PCEP, and LISP [45]. OpenFlow is going to be used for this project as this standard demonstrates the decoupling of the control and data plane from the networking devices by the controller. This will be discussed in the following sections. 4.4.1) OpenDayLight – Beryllium For this project, OpenDaylight Beryllium (ODL Be) is going to be used, which is the fourth release for OpenDaylight. In industry ODL Be is phrased as the de facto platform for enterprises and service providers who are transitioning to SDN. It offers a wide range of uses cases and establishes itself as providing a network of the future. The key challenges ODL tackles in networking include Network Resource Optimization, Automated Service Delivery, Control and Visibility. For ODL Beryllium, the Model Driven Abstraction Layers (MD-SAL) architecture allows it to be highly scalable as well as making it easy to incorporate protocols and applications. ODL Be greatly improves the scalability, performance and functionality. It also offers services which include a new GUI, broader management of networking elements, clustering and high availability, a greater abstraction of network models, improved data handling and messaging for transport [46] .The previous ODL releases include Hydrogen, Helium and Lithium. Appendix 4 shows Beryllium’s Architectural Diagram. Application Layer Control Layer Network Device Layer Applications Network Devices Controller Northbound Glue Code OSI GiRESTful Southbound Glue Code Figure G: Simplified ODL Architecture Protocols Plugins Base Network Functions Service Abstraction Layer (MD and ADSAL) Service Modules
  • 17. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 16 4.5) OpenFlow Initiated from Stanford University in 2008, OpenFlow is considered as the first SDN standard that defines the communication protocols in an SDN environment. Traditionally both forwarding and routing decisions in switches and routers happen in the same device. OpenFlow embraces the concept of SDN as it decouples these functions where the data path resides on the switch and the routing decisions are done via the controller. The OpenFlow protocol defines messages like send-packet out, packet-received, get- stats and forwarding-table. The OF protocol enables communication between the controller and the OpenFlow switch. The SDN controller interface allows for changes to be made in the router/switching flow-table, this allows for network administrators to control flows for optimal performance, partition traffic, test new applications and configurations [47]. Figure H shows you the flow table entities which are capable of being manipulated by an OpenFlow switch. OpenFlow has many benefits, one being that it is programmable. This allows for innovation and has the ability to accelerate new services and features. OF has formed a centralized intelligence as it can simplify provisioning, optimize performance and have a granular policy management [47]. OpenFlow is a feature which can be added to commercial routers, Ethernet switches and Wireless Access Points (WAP) [48]. OpenFlows capabilities allow for switching and routing protocols to be innovated within in a network. It can also be used in applications such as high security networks, next generation IP based mobile networks and virtual machine mobility. Switch Port MAC Source MAC Dest Eth Type VLAN ID IP Dest. Port IP Source Port IP Protocol IP Dest IP Source 1) Forward Packet to Port(s) 2) Encapsulate & Forward to Controller 3) Drop Packet 4) Send to Normal Processing Pipeline Figure H: Flow Table Entries which can be manipulated by an OpenFlow Switch Rule Action Stats Packets + Byte Counters
  • 18. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 17 4.5.1) OpenFlow Messages OpenFlow Protocol supports three message types with multiple sub-types. The three message types include controller-to-switch, asynchronous and symmetric messages. These is adapted from the OpenFlow Specification [50] and discussed as follows. 1) Controller-to-switch: These messages are initiated by the controller and are used to directly inspect or manage the state of the switch. Table 3 shows the different messages between the controller & switch. Features The switch needs to request identity (DPID) Configuration Set and query configuration parameters Modify-State Also called ‘flow mod’, used to add, delete and modify group/flow entries in the OpenFlow tables Read-States Get statistics Packets Out The controller sends messages to the switch, either full packet or buffer ID Barrier Requests reply messages are used by the controller to ensure message dependencies have been met, it receives notifications Role Request Sets the role of its OpenFlow channel Asynchronous Configuration Sets an additional filter on an asynchronous message that it wants to receive on OpenFlow Channel Table 3: Controller to Switch Messages 2) Asynchronous: This is initiated by the switch and is used to update the controller of network events and changes to the switch state. Table 4 shows the various asynchronous messages. Packet-In The switch needs to request identity (DPID) Flow- Removed Informs controller that a flow has been removed Port Status Informs controller that a switch has gone down Error Notifies controller of any problems Table 4: Asynchronous Messages 3) Symmetric: These are initiated by either the controller or switch and are sent without solicitation. Table 5 shows the various symmetric messages. Hello Messages are exchanged between the controller and switch Echo Sent from either controller or switch Verify liveness of a controller-switch connection Used to measure latency or bandwidth Experimenter A standard way for OpenFlow switches to offer additional functionality with the OpenFlow message type space Table 5: Symmetric Messages
  • 19. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 18 4.6) Mininet Mininet is a network emulation orchestration system which can be used to create realistic virtual networks running on a collection of routers, switches, links and end-hosts on a singular Linux kernel. Mininet’s virtual switches, hosts, controllers and links are virtualised on software and behave in the same manner as actual hardware. Mininet uses lightweight virtualization which can makes a singular system look like a whole network, running the same user code, system and kernel. The hosts can operate on standardised Linux networking software, while switches can support OpenFlow enabling flexible and customised routing as well as Software Defined Networking. Mininet, in general allows for debugging, developing, development, learning, prototyping, research and testing [49]. 4.6.1) Benefits of Mininet The benefits of Mininet can be seen below. 1. Mininet is fast, allowing simple networks to be created within seconds enabling users to run, edit and debug loops quickly. 2. Mininet enables users to create customized topologies, anything from single switches to large topologies, data centres, etc. 3. Mininet can run real programs, anything on Linux from TCP monitoring tools to webservers. 4. Mininet allows the end user to customize packet forwarding. Mininet provides a platform for customized SDN designs to be implemented in actual hardware. This can include switches which use OpenFlow enabling line-packet forwarding. 5. Mininet’s flexible, it can run it on the cloud, servers, laptops, virtual machine or Linux OS natively. 4.6.2) Justifications for Project Mininet is going to be used in this project to obtain correct system behaviour and experiment with topologies demonstrating the key features for SDN. Mininet is a combination of a simulator, emulator and a hardware testbed. In comparison to complete system virtualization approaches, Mininet has great features, as shown below.  Faster Boot: The system boots in seconds rather than minutes.  Larger Scalability: Allows for hundreds of switches and hosts  Greater Bandwidth: In modest hardware it is around 2 Gbps.  Easy Installation: It has a pre-packaged VM which can operate on Virtual software, i.e. Virtual Box In comparison to a hardware testbed, Mininet is always available and inexpensive as well as being quick to be reconfigured and restarted. Also in comparisons to simulators Mininet can easily connect to real networks as well as offer interactive performance. The limitations imposed on Mininet are that its network cannot exceed the bandwidth or CPU on a single server. It also cannot run OpenFlow applications or switches that are non-Linux, however this has not been a great issue in practice.
  • 20. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 19 5) Implementation The design section highlighted the various software, protocols and operating system needed for this project. The implementation section is going to show the important steps required to set up a virtualised network testbed required for testing the Software-Defined Networking concept. This section will also investigate the scalability of a network by using different topologies and analyse OpenFlow messages between switches and a controller. Figure I shows a modified ODL architecture diagram used from page 15. The red text shows how the various elements mentioned in the design section fit into the OpenDayLight architecture. This in result will allow for SDN to be investigated in this project. 5.1) Hardware In order to run the OpenDaylight controller, it requires a Linux operating machine. For this project OpenDayLight Beryllium is going to run natively using a HP EliteBook laptop running the Ubuntu operating system. Table 6 below shows the laptop specifications. HP Elite Book Specification Memory 7.7 GiB Processor Intel Core i5-4310U CPU @ 2.00GHz x 4 Graphics Intel Haswell Mobile Disk 117.5 GB OS Type 64-Bit Operating System Ubuntu 16.04 LTS Table 6: Laptop Specification Application Layer Control Layer Network Device Layer Application: WireShark Emulated Network Devices using Mininet ODLBeryllium Controller Northbound Glue Code OSI GiRESTful Southbound Glue Code OpenFlow Protocols Base Network Functions Service Abstraction Layer (MD and ADSAL) Service Modules Figure I: Simplified ODL Architecture
  • 21. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 20 5.2) Downloading & Installing OpenDayLight Prerequisites First, the OpenDayLight controller needs to be initialised and then installed. As mentioned earlier, OpenDaylight is going to operate in a command line Linux environment. Below in Blue are the iterative commands which are going to be used to initialise and install OpenDaylight followed by the ‘//’ Icon commenting the lines stated. Figure J on the next page shows the OpenDayLight screen, when launched. ping www.google.com // The ping command tests for connectivity, in this case Google. sudo passwd root // This command allows for a root password to be initialised. su // This allows the user to use the root privileges, logging in using the credentials set in the previous command. apt-get update // This updates references on the Ubuntu System apt-get install maven git openjdk-8-jre openjdk-8-jdk unzip // Installs JAVA software needed for the installation of ODL wget https://nexus.opendaylight.org/content/repositories/public/org/ope ndaylight/integration/distribution-karaf/0.4.3-Beryllium- SR3/distribution-karaf-0.4.3-Beryllium-SR3.zip // This downloads the Software from OpenDaylight website ls // This lists directory contents of files and directories, in this case for Beryllium SR3 unzip distribution-karaf-0.4.3-Beryllium- SR3.zip // This unzips the file which has recently been downloaded cd distribution-karaf-0.4.3-Beryllium-SR3 // The cd command changes the directory, so in this case, this command will enter into the Beryllium folder ls // This will show the files and folders within this folder export JAVA_HOME=/usr/lib/jvm/java-8-opejdk-amd64 // This specifies the Java Home directory ./bin/karaf // This starts OpenDayLight Beryllium
  • 22. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 21 Figure J: OpenDayLight Launched In OpenDaylight, different features need to be specified and installed manually as there are many with different functionality. Table 7 below states the features which are going to be used for this project and their descriptions. These are the minimum set of features which are required to test ODL and ODL GUI. Feature List Description Restconf Allows access to RESTCONF API L2 Switch Provides Layer 2 switch functionality. The L2 switch components include a packet handler, loop remover, ARP handler, address and host tracker. This feature ensures switches and hosts are visible within a topology of the DLUX User Interface. Mdsal Apidocs Allows access to the YANG API DLux OpenDayLight Graphical User Interface (GUI) Table 7: ODL Features & Description Below shows the commands inputted in the command terminal after OpenDayLight has been launched. The ‘feature:install’ command installs the features mentioned. Feature: install odl-restconf-all odl-l2switch-switch odl-mdsal-apidocs odl-dlux-all
  • 23. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 22 5.3) The OpenDayLight Graphical User Interface (GUI) Following the previous steps, the OpenDayLight controller has now been initiated and installed. One of the advantages of using the OpenDayLight controller is that it enables us to manage the network via a Web based User Interface (DLUX UI). Below Figure J1 shows the URL which was entered into the web browser. The URL consists of an IP address, in this case is the IP address of the network in which OpenDayLight was launched. This then brings up the login page, which is shown in Figure J2. By default the username and password are both ‘admin’. Figure J3 shows the web interface once successfully logged in. Figure J1: URL address to access the Web ODL User Interface (DLUX UI) Figure J2:The login page Figure J3:The DLUX interface once logged in, currently showing no topologies
  • 24. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 23 5. 4) Network Topologies Mininet has the ability to create various network topologies which consists of hosts (end devices) and OpenFlow switches. The different topologies can differ from a single switch network to a more complicated topology which can consist of multiple links and switches, also giving the power to create your own topologies. The virtualized hosts and switch act like real devices in which traffic can be sent between hosts as well as being able to view flows on the switches. Applications like iperf can be used to measure the performance on the network. In Mininet, the ‘sudo mn’ command allows for network topologies to be created. Different options like’– topo=linear, 8’ can be implemented, which in result will consist of 8 switches connected back to back in a linear fashion. Figure k shows the Mininet screen when a linear topology of 8 switches is created. 5.4.1) Linear Topology Linear topology consists of switches which are connected back to back. The single hosts are connected to each switch. When creating the topology, the IP address for the OpenDayLight controller is also initiated, which will allow for control in the ODL web interface. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=linear,8 Figure K: Mininet creating a Linear Topology with 8 Switches To test the connectivity between the hosts, the ‘pingall’ command sends traffic between the hosts. Figure K1 shows that there is an active connection between the hosts as all 56 packets have successfully transmitted. Figure K1: Testing Connection Between Hosts
  • 25. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 24 The OpenDayLight controller provides a Graphical User Interface (GUI) to visualise the topologies created in Mininet. Figure K2 shows the result of a Linear Topology with 8 Switches. Figure K2: Linear Topology with 8 Switches Figure K3: Nodes Menu – List of Nodes Figure K4: Node Connector Statistics for Selected Node (7) Statistics include Packets and Bytes Received/Transmitted. This traffic was genererated from ‘pingall’ SwitchesHosts with Mac Address Local Management Interface
  • 26. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 25 5.4.2) Single Topology The single topology is compiled of a single switch with numerous hosts connected to it. Figure L shows a single switch with 8 hosts. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=single,8 Figure L: Single Topology (8 Hosts) after Pinging All Hosts Figure L1: Tree Topology (48) ..after Pinging All Hosts Figure L2: Single Topology (96 Hosts) after Pinging All Hosts
  • 27. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 26 5.4.3) Tree Topology Tree topologies consist of single switches along with other switches connected depending on a fan- out number. The fanout value determines how many switches offset the core switch. Figure M shows a tree topology with a depth and fanout of 3. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=tree, depth=3,fanout=3 Figure M: Tree Topology (Depth=3, Fanout=3) Figure M1: Tree Topology (Depth 3, Fanout=3) after Pinging All Hosts Figure M2: Tree Topology (Depth 2, Fanout=10) after Pinging All Hosts
  • 28. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 27 5.4.4) Torus Topology A Torus topology interconnects the processing nodes within a parallel computer system. Figure N shows a basic Torus topology, whereas Figure N1 shows that topology after being pinged and Figure N2 shows a more complex Torus Topology. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=torus,4,4 Figure N: Torus Topology (4,4) Figure N1: Torus Topology (4,4) after Pinging All Hosts Figure N2: Torus Topology (16,16) after Pinging All Hosts
  • 29. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 28 5.5) Capturing & Analysing OpenFlow Messages Wireshark is an application which allows for real time packets to be captured and displayed in a user friendly manner. In this project, Wireshark is going to be used to capture and analyse OpenFlow packets. To visualise the communication between the controller and switch, Figure O shows the main components of an OpenFlow switch. To start the experiment, a single switch topology with two hosts is going to get created using the code below in Mininet. sudo mn -–controller=remote,ip=192.168.0.76 –-topo=single,2 – switch=ovsk,protocols=OpenFlow13 --mac This code initiates contact with the SDN controller via its IP address. Then it initiates the Open vSwitch in the kernel mode for each of its switches. This just means the OpenFlow switch is going to use the OpenFlow protocol to communicate with the ODL controller. The code specifies that OpenFlow 1.3 is going to be used and a mac command to ensure that mac addresses are easy to read. To start a capture, the ‘ping’ command will be used to communicate between the hosts, as shown below. h1 ping h2 Figure O1: Wireshark Capture Figure O1 shows the Wireshark capture, in particular the red box highlights the first communication between the switch and controller. The first message is a ‘HELLO’ message. So the switch with the IP address of 192.168.0.10 says ‘Hello’ to the ODL controller with the IP address of 192.168.0.76 and vice versa. OpenFlow Protocols Controller OpenFlow Channel Group Table Flow Table Flow Table Pipeline Figure O: The Main Components of an OpenFlow Switch
  • 30. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 29 5.5.1) OpenFlow Hello Message Figure O2: Detailed Information from the Switch to ODL Controller Figure O3: Detailed Information from the ODL Controller to Switch Figure O2 and O3 shows more information regarding the communication between the switch and the controller. Specifically they are negotiating what the highest version of OpenFlow supports by both sides. These are what the colored boxes represent:  The Orange box shows that there is TCP and IP connectivity as well as the source/destination addresses and port numbers. The traffic still uses TCP/IP protocols however in SDN, the controller is able to manage the traffic and so networking devices become forwarding devices.  The Blue box states that both the controller and switch are able to support OpenFlow v1.3 and are communicating a ‘HELLO’ message, which is a symmetric message.  The Red box indicates that the switch has a value of ‘10’ which represents the version of OpenFlow, so in addition to supporting version 1.3, it can support version 1.0. The Controller also has a value of 12, meaning it can support version 1.3 only. If both the controller and switch cannot negotiate which version of OpenFlow to use, the connection will fail, meaning it will not allow for communication.
  • 31. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 30 5.5.2) Features Request & Reply After the switch and controller successfully negotiate the version of OpenFlow to use, the next set of messages is a FEATURES REQUEST/REPLY from the controller to the switch, as shown in Figure O4. The controller initially identifies the switch and reads its basic capabilities. Figure O4: Features Request/Reply Figure O5: Features Reply from Switch to Controller  datapath_id: This is a unique identifier for the switch where the lower 48-bits are for a MAC address whereas the upper 16 bits are implementer-defined (i.e. HP switches uses VLAN ID). The device could also be a router, firewall or load balancer.  n_table: The number of tables supported in the OpenFlow pipeline (switch). Figure O5 shows that this switch can support 254 tables. 5.5.3) Other Types of Messages Different types of message requests have different outputs. Multipart Messages: These are used to encode, request or reply. These carry large amounts of data and would not always fit into a single OpenFlow message as it is limited to 64kb. These messages are primarily used to request statistics, port and state information as well as table features. For example the controller may wish to learn the manufacturer information, hardware and software description, in order to learn the switches capabilities. These functionalities are what make SDN controllers more intelligent, which help to make better decisions in regards to the health of the network.
  • 32. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 31 5.6) Generating & Measuring Traffic To generate traffic within a Mininet network, various client and server programs allow this to happen. For example, ping, wget, iperf, curl, netcat, netperf etc. So Mininet allows us to run self- contained regression tests. The method that is going to be used to generate traffic is going to be the iperf command. Ping all has recently been used however iperf is another networking tool which was developed to measure both Transmission Control Protocols (TCP) and User Data Gram Protocol (UDP). Iperf can be used to check speed between two computers by measuring bandwidth, packet lost, delay jitter etc. Below we will test a few topologies. Figure M: shows iperf test in a single topology with 2 hosts Figure M1 shows that an iperf server is running on one host and also an iperf client is running on the other host. The results are shown as follows. Figure M2: iperf using a Torus Topology (4, 4) It can be seen that the greater the topology in terms of hosts and switches the less the bandwidth whereas the smaller the topology the greater the bandwidth.
  • 33. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 32 5.7) Yang UI The role of the Software Defined networking controller enables us to control and manage a network. Yang is a data modelling language which defines networking devices, operations and service configurations. The two new applications introduced by OpenDayLight are YANGUI and the YANG Visualizer which can be seen in Figure N. This figures main content shows a list of Rest API’s which are loaded into the controller. Figure N: Yang UI – List of Rest API’s Figure N1: Detailed View of Node Inventory API Figure N1 shows the API listing for the OpenDayLight inventory, in particular the nodes. You can use this menu to either GET, PUT, POST, DELETE and then to send requests to the controller. There is a modern software called POSTMAN which helps developers to develop APIs faster.
  • 34. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 33 6) Evaluation Both NFV and SDN complement each other. This project has demonstrated that these concepts are easy to manage and set up. SDN uses software-centric methods which can be seen in the YANG UI model. This feature in the OpenDayLight controller allows the network administrator to change networking functions easily and quickly. In results, on-site infrastructure upgrades and deployments are more remotely accessible as virtualisation technology eliminates on-site hardware. For example network functions like firewalls and routers can be installed without additional on-site hardware. SDN has also demonstrated its scalability in terms of topologies. Virtualisation allows for hosts and switches to act like real physical items. This in result is now saving physical space and costs as when a network is software based rather that physical, customers will invest less in hardware which in result frees up space in server rooms hence cutting down on operational costs. The concept of SDN has also enhanced security. This concept is allowing network service providers to respond and deploy updates when an attack occurs. Problems can be isolated and contained more easily. For example, in a Distributed Denial of Service attack, the network can scale in real time in order to avoid any sort of disruptions to customer networks. So Software-Defined Networking is here however it is going to be a challenge to integrate and make it the de facto standard. 6.1) Problems Encountered There were several problems which were encountered within the duration of this project, which in result took up quite a chunk of the project time. The main problem experienced in this project was to do with the set-up of all the elements which were required to demonstrate Software-Defined Networking. Initially, there was a problems setting up the OpenDayLight controller on the physical machine as every time the ODL controller was launched it was not 100% guaranteed it will operate. Every time the karaf console tried to launch OpenDayLight it would freeze and maybe be work one out of ten times when reinstalling and installing again. Once it did operate, there was problems getting Mininet and the controller to communicate as there was problems with the IP addresses. The laptop initially used for this project was a 7 year old Samsung laptop. This laptops capacity was near enough full thus making it really slow. There was also an initial confusion when running a hypervisor whether the memory needed to virtualise different system would be virtual memory or actual physical memory. It was discovered that running the Ubuntu Linux operating system on a Windows laptop using a hypervisor, added an extra layer of complexity as it was virtualised. This problem was solved thanks to the project supervisor and the technical team at University. They provided a new laptop with Ubuntu natively installed. So already the extra layer of complexity was removed and the laptops hardware was more than capable of handling the project activities. Thanks to project planning, there was time for this contingency, however it must be noted that valuable time was wasted. Overall, this has been a fantastic learning and knowledgeable experience.
  • 35. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 34 7) Conclusion To conclude, Software-Defined networking has been thoroughly investigated throughout this project. As technology is developing at an accelerating pace in this day and age, there is an exponential growth in data and increased demand for bandwidth. Traditional networking is proving to be very inflexible and static possessing little agility while being error prone in which networking infrastructures are not getting completely utilized. The introduction of both SDN and NFV have introduced more effective and intelligent ways to manage and build networks. The on-demand services provided by the World Wide Web has seen a shift from traditional networking to software-centric networking, thus making NFV and SDN more scalable and cost effective. This paper has defined SDN, while comparing to traditional networking methods. The SDN architecture was investigated, developing a greater understanding of how SDN operates. It has been seen that the SDN controller possess greater control which allows can make networking more effective and efficient. This project also designed an SDN environment by using network emulators, controllers and network monitoring tool to gain a greater understanding of the concept. To improve this project, more practical investigations should have been carried out, however this project did have unpredictable problems. Overall however, this project gives a greater understanding to the SDN concept. It has been a fantastic learning and knowledgeable experience. 7.1) Future Research There are many challenges in Software-Defined Networking which require attention and different organizations are continually researching and enhancing SDN. APPENDIX 5 shows the current research projects being undertaken by various companies for SDN. The open issues cover the complete lifecycle of SDN, starting from standardization, implementation to deployment. These are discussed as follows.  The Standardization of SDN: At the current moment, OpenFlow represents the official de facto implementation for the Software- Defined Networking concept. The Internet Engineering Task Force (IETF) have recently released a new SDN framework [51]. Network Functions Virtualization (NFV) highly complements SDN and ETSI industry Specification Group (ISG) have now started promoting NFV [52]. Also fragmentations in APIs and controller functions provide a barrier for commercial development in SDN. As OpenFlow evolves, it is allowing more interpretations which is causing unpredictable disorders [53].  The Implementation of SDN: SDN decouples the control plane entirely from the data plane which in result completely eradicates the routing protocols on board switching devices. This concept however can be seen to be idealistic which is preventing SDN from widespread adoption. Organizations classify SDN as a risky in terms of investment as all conventional networking devices would have to be replaced.  The Deployment of SDN: In order for a wide deployment of SDN a further study needs to be undertaken in areas such as wireless mesh networks with fast client mobility [55], wireless sensor networks which require high reliability and reachability[56] and carrier networks with carrier-grade requirements [54]. The issues associated with SDN are not exhaustive but are promising towards the evolution of Software Defined Networking.
  • 36. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 35 References [1] Benson T, Akella A, Maltz. (2009). Unravelling the complexity of network management. Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation. (9), P.335-348. Last accessed 26th June 2016. [2] Kreautz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. (2014). Software- Defined Networking: A Comprehensive Survey. IEEE Xplore. P.1-61. Last accessed 26th June 2016. [3] Raghavan B, Casado M, Kopenen T, Ratnassamy S, Ghodsi A, Shenker S. (2012). Software- defined internet architecture: Decoupling architecture from infrastructure. Proceedings of the 11th ACM Workshop on Hot Topics in Networks. P.43-48. Last accessed 27th July 2016. [4] Ghodsi A, Shenker S, Kopenen T, Singla A, Raghavan B, Wilcox J. (2011). Intelligent design enables architectural evolution. Available: http://people.eecs.berkeley.edu/~alig/papers/intelligent-design-evolution.pdf Last accessed 27th July 2016. [5] Schenker S. (2011). The Future of Networking, and the Past of Protocols. Available: http://www.youtube.com/watch?v= YHeyuD89n1Y . Last accessed 27th June 2016. [6] Mckeown N. (2011). How will SDN shape Networking? Available: http://www.youtube.com/watch?v=c9-K5OqYgA . Last accessed 27th July 2016. [7] Kim H and Feamster N. (2013). Improving network management with software defined networking. Communication Magazine, IEEE. 51 (2), P.113-120. Last accessed 27th July 2016. [8] Kopenen T, Casado N, Gude J, Stribling K, Poutiveski L, Zue M, Ramanathan R, Iwata Y, Inouye H , Hama T, Shenker S. (2010). Onix: a distributed control platform for large-scale production networks. Proceedings of the 9th USENIX conference on Operating systems design and implementation. (10), P.1-6. Last accessed 28th June 2016. [9] Jain S, Kumar A, Mandal S, Ong J, Poutievski L, Singh A, Venkata S, Wandere J, Zhou J, Zhu M, Zolla J, Vahdat A. (2013). B4: experience with a globally-deployed software defined wan. In Proceedings of the ACM SIGCOMM 2013 conference. P. 1- 14. Last accessed 28th June 2016. [10] ONF. (2014). Open networking foundation. Available: https://www.opennetworking.org/. Last accessed 28th June 2016. [11] Yageneh S, Tootoochian A, Ganjali Y. (2013). On scalability of software-defined networking. IEEE Xplore. 51 (2), P.135-140. Last accessed 28th June 2016. [12] VMware, Inc. (2013). VMware NSX Virtualization Platform. Available: https://www.vmware.com/products/nsx/. Last accessed 28th June 2016. [13] OpenDaylight. (2013). OpenDaylight: A Linux Foundation Collaborative Project. Available: http://www.opendaylight.org. Last accessed 28th June 2016.
  • 37. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 36 [14] Horing S, Menard J.Z, Staehler R.E, Yokelson B.J. (1982). Stored Program Controlled Network: Overview. Bell System Technical Journal. 61 (7), P.1579-1588. Last Accessed 16th June 2016. [15] Van der Merwe J, Cepleanu A, D’Souza K, Freeman B. (2006). Dynamic Connectivity Management with an Intelligent Route Service Control Point. Available: https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/irscp.pdf. Last accessed 23rd June 2016. [16] Van Der Merwe J.E, Rooney S, Leslie I.M, Crosby S.A. (1997). The Tempest-a practical framework for network programmability. IEEE Network. 12 (3), P.20-29. Last Accessed 16th June 2016. [17] Feamster N, Balakrishnan H, Rexford J , Shaikh A, van der Merwe J. (2004). The Case for Separating Routing from Routers. MIT Computer Science & AI Lab. P.1-8. Last accessed 23rd June 2016. [18] Caesar M, Caldwell D, Feamster N, Rexford J, Shaikh A, and van der Merwe J. (2005). Design and implementation of a routing control platform. Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation. 2 (NSDI), P.15–28. Last accessed 24th June 2016. [19] Vasseur J and Roux J.L. (2009). Path Computation Element (PCE) Communication Protocol (PCEP). Available: https://www.rfc-editor.org/rfc/rfc7150.txt. Last accessed 24th June 2016. [20] Doria A, Salim JH, Haas R, Khosravi H, Wang W, Dong L, Gopal R, Halpern J. (2010). Forwarding and Control Element Separation (ForCES) Protocol Specification,” Available: http://www.ietf.org/rfc/rfc5810.txt. Last accessed 24th June 2016. [21] Greenberg A, Hjalmtysson G, Maltz D, Myers A, Rexford J, Xie G, Yan X, Zhan J, Zhang H. (2005). A clean slate 4D approach to network control and management. ACM SIGCOMM Computer Communication Review. 35 (5), P.41-54. Last accessed 24th June 2016. [22] Casado M, Freedman MJ, Petit J, Luo J, McKeown L, Shenker S. (2007). Ethane: taking control of the enterprise. ACM SIGCOMM Computer Communication Review. 37 (4), 1-12. Last accessed 24th June 2016. [23] Casado M, Garfinkel T, Akella A, Freedman MJ, Boneh D, McKeown N, Shenker S. (2006). SANE: a protection architecture for enterprise networks. Proceedings of the 15th conference on USENIX Security Symposium. (15). Last accessed 24th June 2016. [24] McKeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. (2008). OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review. 38 (2), P.68-75. Last accessed 24th June 2016. [25] Mohyuddin A, Dowland PS. (2007). The Art of Network Monitoring. Available: https://www.cscan.org/download/?id=394. Last accessed 28th June 2016.
  • 38. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 37 [26] Villars RL, Olofson CW, Eastwood M. (2011). Big data: what it is and why you should care. White Paper, IDC. MA, USA [28] Kelly B. (2002). Quality of Service in Internet Protocol (IP) Networks .Available: http://www.wainhouse.com/files/papers/wr-qos-in-ip-networks.pdf. Last accessed 29th June 2016. [29] Almes G, Kalidind S, Zekauskas M. (1999). A One-way Packet Loss Metric for IPPM. RFC 2680 (Proposed Standard). Last accessed 28th June 2016. [30] Gourov VN. (2013). Networking Monitoring with Software Defined Networking - Towards OpenFlow network monitoring. Last accessed 20th June 2016. [31] Chimento P and Ishac J. (2008). Defining Network Capacity. Last accessed 28th June 2016. [32] US National Institute of Standards & Technology (NIST). (2011). NIST Cloud Computing Program. Available: http://www.nist.gov/itl/cloud/. Last accessed 5th May 2016. [33] Levin D, Wundsam A, Heller B, Handigol N, and Feldmann A. (2012). Logically centralized? State Distribution Trade-offs in Software Defined Networks in Proceedings of the first workshop on Hot topics in Software Defined Networks, HotSDN. P.1-6. Last accessed 19th August 2016. [34] Fratto, M. (2012). What is the difference between Control plane and Data plane in the context of networking equipment like routers / switches? Available: https://www.quora.com/What-is-the- difference-between-Control-plane-and-Data-plane-in-the-context-of-networking-equipment- like-routers-switches. Last accessed 19th August 2016. [35] Rao S. (2014). SDN Series Part One: Defining Software Defined Networking. Available: http://thenewstack.io/defining-software-defined-networking-part-1/. Last accessed 19th August 2016. [36] Cisco. (2011). Implementing Management Plane Protection. Available: http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4- 1/security/configuration/guide/syssec_cg41crs_chapter7.html. Last accessed 19th August 2016. [37] Rouse M. (2013). Control Plane (CP). Available: http://searchsdn.techtarget.com/definition/control-plane-CP. Last accessed 19th August 2016. [38] Big Switch Networks. (2013). The Open SDN Architecture. Available: https://www.bigswitch.com/sites/default/files/sdn_overview.pdf. Last accessed 19th August 2016. [39] Raghavan B, Casado M,Koponen T, Ratnasamy S,Ghodsi A, Shenker S. (2012). Software defined Internet architecture: decoupling architecture from infrastructure. In Proceedings of the 11th ACM Workshop on Hot Topics in Networks. HotNets XI, NY, USA. P.43-48. Last accessed 19th August 2016.
  • 39. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 38 [40] McNickle M. (2014). Five SDN protocols other than OpenFlow. Available: http://searchsdn.techtarget.com/news/2240227714/Five-SDN-protocols-other-than-OpenFlow. Last accessed 22nd August 2016. [41] SDX Central. (2016). Understanding the SDN Architecture. Available: https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/ Last accessed 22nd August 2016. [42] PL Vision. (2015). Software-Defined Networking. Available: http://plvision.eu/expertise/networking/software-defined-networking/. Last accessed 25th August 2016. [43] Rao, S. (2015). SDN Series Part Eight: Comparison Of Open Source SDN Controllers. Available: http://thenewstack.io/sdn-series-part-eight-comparison-of-open-source-sdn-controllers/. Last accessed 27th August 2016. [44] Rao S. (2015). SDN Series Part Six: OpenDaylight, the Most Documented Controller. Available: http://thenewstack.io/sdn-series-part-vi-opendaylight/. Last accessed 27th August 2016. [45] Henthorn-Iwane A. (2015). Four open source networking projects explained. Available: https://thestack.com/iot/2015/02/02/four-open-source-networking-projects-explained/. Last accessed 27th August 2016. [46] Open Daylight. (2016). ODL Beryllium (Be) - The Fourth Release of OpenDaylight. Available: https://www.opendaylight.org/odlbe. Last accessed 27th August 2016. [47] SDX Central. (2016). What is OpenFlow? Definition and how it relates to SDN. Available: https://www.sdxcentral.com/sdn/definitions/what-is-openflow/. Last accessed 28th August 2016. [48] OpenFlow (2016). What is OpenFlow? Available: http://archive.openflow.org/wp/learnmore/. Last accessed 28th August 2016. [49] Mininet. (2016). Mininet Overview. Available: http://mininet.org/overview/ Last accessed 28th August 2016. [50] Open Networking Foundation. (2014). OpenFlow Switch Specification. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openflow/openflow-switch-v1.5.0.noipr.pdf. Last accessed 11th September 2016. [51] Nadeau T, Pan P. (2011). Framework for Software Defined Networks.Available: https://tools.ietf.org/html/draft-nadeau-sdn-framework-01. Last accessed 11th September 2016. [52] ETSI Industry Specification Group for Network Functions Virtualization (ISG NFV), (2012). Network Functions Virtualisation. Available: http://www.cisco.com/en/US/solutions/collateral/ ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf. Last accessed 11th September 2016.
  • 40. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 39 [53] Kuzniar M, Persini P, Canini M, Venzano and Kostic D. (2012). A SOFT way for OpenFlow switch interoperability testing. In Proc. 8th Int. Conf. Emerging Network. Exp. Technol. P.265-276. [54] Kind M, Westphal F, Gladisch A and Topp S. (2012). Split Architecture: Applying the software defined networking concept to carrier networks.in Proc. WTC. P.1-6. Last accessed 11th September 2016. [55] Dely P, Kassler A and Bayer N (2011). OpenFlow for wireless mesh networks. In Proc. 20th ICCCN, P.1-6. Last accessed 11th September 2016. [56] Mahmud A and Rahmani R (2011). Exploitation of OpenFlow in wireless sensor networks in Proc. ICCSNT. Volume 1. P.594-600. Last accessed 11th September 2016.
  • 41. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 40 APPENDIX 1) High-Level overview of a SDN architecture Source: Open Networking Foundation. (2013). SDN Architecture Overview. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN- architecture-overview-1.0.pdf. Last accessed 28th June 2016.
  • 42. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 41 APPENDIX 2) Software Defined networking Versus Traditional and Conventional Networking Source: Kreautz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. (2014). Software- Defined Networking: A Comprehensive Survey. IEEE Xplore. P.5. Last accessed 26th June 2016.
  • 43. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 42 APPENDIX 3) OpenDaylights Feature List Source: Open Daylight. (2016). OpenDaylight Features List. Available: https://www.opendaylight.org/opendaylight-features-list#NEMO. Last accessed 27th August 2016.
  • 44. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 43 APPENDIX 4) OpenDayLight – 4th Release Beryllium’s Architectural Diagram
  • 45. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 44 APPENDIX 5) Current Research Projects
  • 46. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Loughborough University | Dissertation 45 APPENDIX 6) Research Proposal Contact Details Name Jasjoot Singh Mudhar Student ID: B530429 Course: MSc Internet Media Clouds with Business Institute: Institute of Digital Technologies Contact Number: 07534243183 Email: J.mudhar-15@student.lboro.ac.uk / Jmudhar90@hotmail.co.uk Project Details Title : Deployment of a Software Defined Network Testbed on the Cloud Summary: SDN allows for a much more dynamic usage of the network resources in order to accommodate appropriately various types of applications with different QoS requirements. The proposed MSc dissertation focuses on investigating on Software Defined Network (SDN) technologies and the implementation of one of the technologies in a Cloud environment (possibly MS Azure). A review of current SDN open-source technologies will be conducted in addition to literature review on the challenges in performance monitoring in terms of link utilisation, delay and packet loss in the context of SDN. The project will also seek to find answers to a number research questions, such as: Are contemporary monitoring techniques adequate? If not, which are the current monitoring solutions for SDN? Keywords: Software Defined Network, Cloud Environment, Network Performance Monitoring Key Dates for Project Assessment Size Weight Submission date A Research proposal 2,000 Words 20% of assessment Semester 2: 4th of May at 5pm A Literature Review 2,000 Words 20% of assessment Semester 2: Mid to late June Final Dissertation Final Dissertation: 10,000 Words 60% of assessment Semester 3: September 12, 2016 Academic History – Current MSc Internet Media Clouds with Business Internet and Communication Networks Collaborative Project Mobile Broadband and Wireless Networks Innovation Management Internet of Things and Application Intellectual Property Cloud Technologies and Systems Media Cloud Applications and Services Dissertation Academic History – Previous BSc Computing with Digital Media Undergraduate Information Communication & Technology A-Levels Information Communication & Technology GCSE
  • 47. Deployment of a Software-Defined Network Testbed on the Cloud Dissertation (15LLP501) Jasjoot Singh Mudhar Gant Chart Stages Month May June July July Sept Week Commencing 2nd 9th 16th 23th 30th 5th 13th 20th 27th 29th 4th 11th 18th 25th 1st 8th 15th 22nd 29th 5th 12th Week Number 10 11 12 13 14 15 Summer Term (Semester 3) Planning Literature Review Analysis Exam/Revision Design Implementation Experiment Evaluation Project Report DD This chart shows the project schedule as well as the start and end date of tasks which is going to be used to track progress, analyse and manage workloads. Gantt Chart