17
Coursework Submission Cover Sheet Please use block capitals Student No 5737135 7 Degree Scheme Master s Student Name Aun Ahsan Year 5th Module EE552 Lecturer Dr. Martin Collier Title Broadba nd Network s Hours spent on this exercise 25+ I hereby declare that the attached submission is all my own work, that it has not previously been submitted for assessment, and that I have not knowingly allowed it to be used by another student. I understand that deceiving or attempting to deceive examiners by passing off the work of another as one's own is not permitted. I also understand that using another's student’s work or knowingly allowing another student to use my work is against the University regulations and that doing so will result in loss of marks and possible disciplinary proceedings. Signed: Date: Note: Coursework examiners are entitled to reject any coursework which does not have a signed copy of this form attached. For use by examiners only (students should not write below this line)

EE552SDNAunAhsan57371357

Embed Size (px)

Citation preview

Page 1: EE552SDNAunAhsan57371357

Coursework Submission Cover Sheet Please use block capitals

Student No 57371357 Degree Scheme  Masters

Student Name Aun Ahsan

Year  5th

Module EE552 Lecturer  Dr. Martin Collier

Title Broadband Networks

Hours spent on this exercise

 25+

I hereby declare that the attached submission is all my own work, that it has not previously been submitted for assessment, and that I have not knowingly allowed it to be used by another student. I understand that deceiving or attempting to deceive examiners by passing off the work of another as one's own is not permitted. I also understand that using another's student’s work or knowingly allowing another student to use my work is against the University regulations and that doing so will result in loss of marks and possible disciplinary proceedings.

Signed: Date:

Note: Coursework examiners are entitled to reject any coursework which does not have a signed copy of this form attached.

For use by examiners only (students should not write below this line)

Comments:

Page 2: EE552SDNAunAhsan57371357

Software Defined Networking

Aun AhsanDublin City University

March 2016

Page 3: EE552SDNAunAhsan57371357

Chapter 1: The Control, Data and Management Planes in Data Communications

In today’s networking hardware, moving IP packets from a point A to B requires the use of the Control, Data (sometimes referred to as the Forwarding plane) and Management planes. It is the heart and core of networks. These planes carry out operations and are the building blocks of layered architecture that helped evolve the networks we have today. The control plane is responsible of essentially configuring the data plane. The control plane is needed in any device which requires routing to be working, Control plane packets are locally originated by the router itself or are destined to it, and this is the essential difference between the concepts of data and control plane [1]. The control plane makes decisions about where the traffic is to be sent, some examples of control plane functions include routing protocols, configuration for network middle boxes. The routing protocols compute the shortest path over a topology but ultimately the data plane must do the actual forwarding according to the control plane logic which controls the forwarding logic. The data plane’s job is to carry out forward logic according to the control plane logic; some examples of data plane functions include forwarding packets at the IP layer and switching at layer two.

The separation of the two planes is important as it allows the software element and the hardware element to evolve independent of each other. The other reason for control and data planes being separate is that it allows the control of network behaviour from a high-level program which allows the network operators to debug and or check behaviour easily, as opposed to where network behaviour is determined by the low level configuration across switches in the routers. The management plane is the interface between the network operator/administrator and the devices by using either Simple Network Management Protocol (CNMP) or Secure Shell (SSH) protocol [2]. It allows the User to not only configure but also monitor and gather information. This helps the network administrator to identify potential problems and take corrective measures whether short-term or long-term. This monitoring and data collection is not a part of either the data or the control plane, and thus management plane is a vital part of a network communications.

In Software Defined networking (SDN), the control plane can sit outside the router and hence provide global controllability of the network from the single control plane.

Page 4: EE552SDNAunAhsan57371357

Chapter 2: Introduction to SDN and NFV – 1 page

Software defined networking and Network Function Virtualisation are complementary concepts but do not require each other to be implemented. SDN started at campus networks, with researchers experimenting with new protocols, the need for SDN was kindled when the researchers had to change the networks in each of the network devices each time they had to implement a new protocol. This led to the SDN we have today which follows the principle elements of [1]:

- Separation of control plane and forwarding functions.- Centralization of the control- The ability to program network behaviour

The idea of SDN is to separate the intelligence that once was held by the networking equipment and creating a management and control system that makes the overall networking system much more intelligent, this allows the control of the entire networking infrastructure at one control panel as opposed to controlling individual routers and other networking equipment. The control plane in an SDN network consists of management servers that communicate with the data plane equipment and instructs the equipment as to how the data should move through the data plane. The management plane is there to manage the control plane servers and make sure they are working as intended. So in other words, SDN allows the real time shaping of the traffic. SDN allows the automation of traffic priority depending on the current needs whether it’s VoIP or HD Video etc. The control protocol known as OpenFlow is used at the control plane to direct traffic, according to the OpenFlow protocol.

Network Functions Virtualisation (NFV) is the virtualisation of network functional hardware, it is the virtualisation of hardware like firewall, media server etc. with virtual machines on cheaper servers, switches and storage to perform the same functions as the network functions as compared to the traditional network hardware. The ability to scale up and down depending on need is a huge plus point. NFV allows the ability to add or subtract the things that are needed as they are needed and NFV allows the instantiation of network functions on demand. Using NFV a standard x86 platform is used, the physical Customer-Premises equipment (CPE) is replaced with virtual-CPE, the server that runs these virtual machines is called the compute node, and this node includes the software called hypervisor that manages the virtual machine and the resources of the compute node. Figure 1 shows the how the hypervisor sits in relation to the network.

Figure 1 Network virtualisation functions implemented

Page 5: EE552SDNAunAhsan57371357

Chapter 3: Overview of the OpenFlow Protocol – 1 page

OpenFlow is the standard communications interface between the control and the forwarding planes of SDN architecture. It allows the manipulation of the switches and routers of physical and virtual nature (for NFV, hypervisor based). OpenFlow lets network controllers rule out the path that the network packets will take across the switches in the network. OpenFlow switch is the software program of a hardware device that forwards packets in a SDN environment, OpenFlow switches are compatible and based on the OpenFlow protocol.

The Conventional switch has the control and the data plane on the same device, however these two planes are decoupled in the SDN environment. The data plane is implemented in the switch, but the control plane is now in the software and a SDN controller makes the high level routing decisions. The OpenFlow switch and the controller communicate by means of the OpenFlow Protocol [3]. OpenFlow takes advantage of the fact that most Ethernet switches and routers have flow-tables typically build from Ternary Content Addressable Memory’s (TCAM’s) that collect statistics. Different vendor switches contain different flow-tables but the Open Networking Foundation (ONF, the organisation in charge of managing OpenFlow protocol) have discovered interesting common set of functions that apply to all switches, OpenFlow exploits this common set of functions [3] [4]. The OpenFlow switch consists of at least three parts:

1. A Flow Table – with an action associated with each entry, to instruct the switch how to process the flow.

2. A secure channel – connects the switch to the controller3. OpenFlow Protocol – way for the controller to communicate with the

switches.

OpenFlow was the most commonly used protocol to be used in SDN environment, however OpenFlow requires network vendors to create supporting switches in order for OpenFlow to be the industry wide standard. Vendor support for the new OpenFlow 1.3 has diminished, this is true partly because of the way the current protocol is programmed, many of its attributes are reportedly defined as type length values (TLVs). Many vendors are not prepared to support these TLVs [5]. OpenFlow is far from extinction however it now has healthy competition in form of other protocols emerging for SDN. NETCONF is an Internet Engineering Task Force (IETF) network management protocol; it allows a secure way to configure a firewall, switch, router and other network devices. It is based on the remote procedure call (RPC) and was designed to fix issues that existed with SNM protocol and command line protocols. The ONF has recently adapted NETCONF and has made it mandatory for the configuration of OpenFlow-enabled devices, called OF-CONFIG; this specification requires that the device supporting this must implement the NETCONF protocol as the transport. There are other protocols such as Extensible Messaging and presence of protocol (XMPP) based on the extensible mark-up language, and protocols like Open vSwitch Database Management Protocol (OVSDB) that provide the OpenFlow protocol with some healthy competition to further the focus on solving the problems of SDN protocols.

Page 6: EE552SDNAunAhsan57371357

Chapter 4: Software Defined Networking

A conventional network works in a way that utilizes algorithms that are implemented on dedicated network devices, this allows the conventional network to control and monitor the data flow by managing the routing paths and determining how different devices are interconnected in the network. For example in an Application Specific Integrated Circuits (ASICs) the routing data and sets of rules to follow are implemented in the hardware itself. ASICs perform specific operations like packets switching. When a packet is received by the routing device, it uses its sets of rules in its firmware to determine the routing paths of the packet and the destined device. Expensive routing devices in a conventional network can determine the types of packets received and treat them in different manners according to their nature and contents. For example a Cisco router can allow the user to mark out the priorities of different flows with customised local router programming, known as configuration mode in most Cisco routers [6]. This allows better traffic congestion efficiency and allows the prioritization control.

The hardwired implementation of these routing rules limits the current network devices and they lack the flexibility to deal with different types of packets. The increased demands and emphasis on security, scalability and network speed hinders the performance of these networks due to the ever increasing network traffic. Under high network traffic this methodology limits the current network device, which has severe limitation and affects the network performance.

Innovative technology such as SDN proposes a possible solution to this problem, by the implementation of the data handling rules as software rather than hardware. This enables the network administrators to have more control over the network traffic and thus being able to greatly improve the network performance by efficiently using the network resources. SDN was originally proposed by the Nicira networks based on their earlier findings at Stanford, UCB, Princeton and CMU. The goal of which was to provide an open, user controlled management of the data hardware (switches, routers etc.) SDN has the ability to split the data plane from the control plane in the network. The control plane can send instructions to the data plane hardware, this allows the global changes to be made without the need for configuration of each network hardware [7].

Figure 2 Conventional (left) vs Software Defined Network (right) [7]

Page 7: EE552SDNAunAhsan57371357

Figure 2 shows the comparison between a conventional network and the SDN, it is evident from the simplistic figure that the conventional networks requires several different control and data planes labelled C1 through C5 for control plane and D1 through D5 from data planes, that all need to be configured separately. While the Software Defined Network has one Control plane and one data plane, the control plane is communicating with the data plane by updating the flow tables as necessary.

The control plane can be managed by a central controller or multiple controllers, where in a multiple controller set-up, the controllers are synchronised. SDN is suitable for environments like homes, offices and data centres, further scaling of the control plane has raised questions about the speed at which the controller can respond to the data path requests and how many data path requests it can handle per second. OpenFlow is the standard protocol widely used in SDN, and the four publicly available OpenFlow controllers: NOX, Beacon, and Maestro [8]. The performance of NOX has shown interest in improving the control panel efficiency, however NOX is single threaded and thus is not optimised for performance. NOX-MT is a multithread slightly tweaked NOX, with greatly increased performance and response time. Despite these changes and performance boosts, NOX-MT still suffers from performance deficiencies left over from NOX, mainly due to NOX’s code base [7]. Heavy use of dynamic memory allocation and having redundant memory copies on a per-request basis are the few changes needed to be made to the code base to improve NOX’s performance. The Methods to enhance the controller’s performance can be through having multiple controllers which would allow scalability and avoid the throughput bottleneck in the networks in [7] authors came to the conclusion on previous findings that a HP ProCurve switch is over 250 flows/second while a data centre with over a thousand servers a flow rate of 100k flows/second could be faced. However a reported peak of 10 M flows per second for a 100 switch network, showing that the current switches are unable to handle the application flow rate. This proposes research into better protocols to be invented that minimises the switch to controller communications. The paper suggests that OpenFlow protocol has scalability issues as it communicates to the controller very frequently which consumes processing power of the controller and causes congestion in the switch to controller links.

The security issues that the SDN creates that could be potentials for a security attack comes from the SDN controller, and the virtual infrastructure. Besides the conventional ways of attacks through routers and servers, SDN has new targets introduced such as the SDN controller that bring the same security vulnerabilities from the conventional ways as stated above. SDN also could have potential attacks in the hypervisor in the virtual infrastructure and attacks could be directed towards the OpenFlow protocol for OpenFlow enabled devices. Network intrusion detection scheme like NICE (Network Intrusion Countermeasure) is used to secure the virtual networks like SDN. The separation of control and the data plane are key aspects of SDN; however single-point security issues are brought with it. An attack on the controller leaves all low-level switches to become compromised and cannot deliver the packets correctly. Other security risks like anomalies in traffic and routing loops that make the packets never reach its destination. Although there are security risks that SDN brings, there are solutions to those risks being proposed in [9] in regards with the Intrusion detection stated above and in [10] proposing FRESCO as a modular security.

Page 8: EE552SDNAunAhsan57371357

Chapter 5: The Future of SDN

Software Defined networking is without a doubt the future of networking, with most of the world’s biggest companies like Google, HP, Alcatel-Lucent, Cisco, Juiper and Contrail are amongst the biggest competitors already coming out with SDN products. With backing of all the major players in networking, the shift in networking market caused by SDN together with NFV is bringing the biggest potential changes. It is inevitable that SDN becomes the norm in the near future, however each company has a different future planned for SDN, there needs to be standardised SDN platform like the OpenDaylight platform that is set out to make OpenDaylight to be the de facto standard for SDN, with support of OpenFlow and other traditional protocols like NETCONF and BGP etc. the standardisation of SDN is important for an industry wide adaptation.

NFV and SDN are approaches to the network that are beneficial for each other, however they do not depend on one another for implementation. The concept of SDN makes NFV and Network Virtualisation more interesting and vice-versa. Where SDN focuses on the networks decision to direct which network traffic goes to what device and takes which path, NFV focuses on the network services and NV ensures the capabilities of the network are in aligned with the virtualised environments they are supporting [11]. This advancement in these two approaches is the key in evolving the network.

Page 9: EE552SDNAunAhsan57371357

Chapter 6: Conclusions

In this paper, we briefly reviewed Software defined networking. The basics of control and the data plane were established. Introduction to the OpenFlow protocol was given as being the standard of communication between the control and the data plane in software defined networking. SDN and its basics as compared to the conventional networking was discussed, SDN originated from the college campus as a means to centralise the control plane and to eliminate the need to configure each control plane separately. The Figure 2 in chapter 4 shows the control plane and data plane difference in the two networks. We discussed some scalability issues arising from OpenFlow controllers like NOX-MT, and solution to the scalability issues through multiple controller set-up improving network throughput and improving scalability.

SDN is the clear future for the industry and together with NFV could possibly create the biggest shift in networking market in quite a while. SDN has many applications like developing of new protocols prior to implementing those protocols in the networks. With the control and data planes being separate and the ever growing internet, SDN allows adapting to the changing traffic compared to the conventional networks. Security and privacy are top concerns in today’s networks and OpenFlow and SDN create many new security issues in the network due to the Virtualisation Network. It is most important to secure the physical to virtual mapping in SDN/OpenFlow. However SDN and OpenFlow and relatively new fields and will see it grow and become the norm in the years to come.

Page 10: EE552SDNAunAhsan57371357

Refrences

[1] P. Pate, “NFV and SDN: What's the difference,” SDXcentral, 30 MArch 2013.[2] I. Pepelnjak, “MAnagement, control and data planes in network device snad

systems,” 2 august 2013. [Online]. Available: http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html. [Accessed 22 MARCH 2016].

[3] M. Rouse, “OpenFlow-Switch,” techtarget, MARCH 2013. [Online]. Available: http://searchsdn.techtarget.com/definition/OpenFlow-switch. [Accessed 22 MARCH 2016].

[4] Nick McKeown, et. al., “OpenFlow: Enabling Innovation in campus Networks,” WhitePaper, Stanford, 2008.

[5] D. Marschke, “is OpenFlow dead?,” techtarget, 15 july 2015. [Online]. Available: http://searchsdn.techtarget.com/tip/SDN-and-Openflow-Is-the-protocol-dead. [Accessed 21 march 2016].

[6] Cisco, “Cisco IOS commands,” Cisco, [Online]. Available: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf019.html#wp1000901. [Accessed 21 march 2015].

[7] Q. H. K. B. Fei Hu, “A survey on SDN and OpenFlowL From concept to implementation,” IEEE Communications surveys, vol. 16, no. 4, pp. 2181-2206, 2014.

[8] M. Casado, “OpenFlow Software,” stanford, [Online]. Available: http://yuba.stanford.edu/~casado/of-sw.html. [Accessed 21 march 2016].

[9] C.-J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, “NICE: Network intrusion detection and countermeasure selection in virtual network system,” IEEE Trans., vol. 10, no. 4, 2013.

[10]

S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson,, ““FRESCO: Modular composable security services for software-defined netowrks",” Proc. Netw. Distrib. Syst. Security Symp.,, Apr. 2013.

[11]

S. resources, “Which is better? NFV, SDN,” SDXCENTRAL, 2014. [Online]. Available: www.sdxcentral.com/resources/nfv/which-is-better-sdn-or-nfv/. [Accessed 21 march 2016].