Sofware Defined Networking Architecture and Openflow Network Topologies

Transcription

1 Sofware Defined Networking Architecture and Openflow Network Topologies Fahad Kameez, M.Tech.(VLSI and ES) Department of Electronics and Communication Rashtreeya Vidyalaya College of Engineering Bengaluru, India Abstract Networking is the process for sharing data between two or more devices by linking them together. Software defined Networking (SDN) is the recent advancement to the networking models that has more importance. SDN simplifies and automates the controlling of large network. In a conventional switch the data function for packet forwarding and control plane for routing decisions exist on the same device. SDN separates forwarding plane and control planes of the switch. While the data function still appears on the switch the control plane portion of the switch is moved to centralized system. For SDN to be practical there should common logical architecture in the devices managed by the controller and secure protocol between switch and controller. Openflow is one of the communication standard for the interface between the data plane of switch and control plane of controller. It is used for the interaction between a network switch, constituting the data plane, and a controller, constituting the control plane. Openflow is a protocol to facilitate communication between a Software defined Network controller and underlying network devices. Openflow enables the controller to create flow table entries in the switches, and also enables the analysis for underlying network topologies. The Mininet delivers simple network platform for developing Openflow applications. The main aim of this paper is to is provide an introduction to software defined networking and make new user familiar with the mininet tools and discuss various network topology of OpenFlow using mininet. Keywords sdn, openflow,openflow network topology, mininet I. INTRODUCTION Software Defined Networking (SDN) is a new networking paradigm in which the forwarding hardware is decoupled from control decisions. It promises to dramatically simplify network management and enable innovation and evolution. The main idea is to allow software developers to rely on network resources in the same easy manner as they do on storage and computing resources. The field of software defined networking is quite recent, yet growing at a very fast pace. Still, there are important research challenges to be addressed. 22 P. Narashimaraja, Assistant Professor Department of Electronics and Communication Rashtreeya Vidyalaya College of Engineering Bengaluru, India Software Defined Networking [3] is the key outcome of extensive research efforts over the last decade towards the transformation of the Internet to a more open, programmable, reliable, secure and manageable infrastructure. Conventional networks utilize special algorithms implemented on dedicated devices (hardware components) to control and monitor the data flow in the network, managing routing paths and determining how different devices are interconnected in the network. In general these routing algorithms and sets of rules are implemented in dedicated hardware components such as Application Specific Integrated Circuits (ASICs). ASICs are designed for performing specific operations. Packet forwarding is a simple example. In a conventional network, upon the reception of a packet by a routing device, it uses a set of rules embedded in its firmware to find the destination device as well as the routing path for that packet. Generally data packets that are supposed to be delivered to the same destination are handled in similar manner. This operation takes place in inexpensive routing devices. More expensive routing devices can treat different packet types in different A problem posed by this methodology is the limitation of the current network devices under high network traffic, which poses severe limitations on network performance. Issues such as the increasing demand for scalability, security, reliability and network speed, can severely hinder the performance of the current network devices due to the ever increasing network traffic. Current network devices lack the flexibility to deal with. different packet types with various contents because of the underlying hardwired implementation of routing rules. In SDN, the network intelligence is logically centralized in software-based controllers (the control plane), and network devices become simple packet forwarding devices (the data plane) that can be programmed via an open interface. The main concepts of SDN are: i) the separation of the network control plane from the data plane and, ii) a

2 logically centralized controller, communicating with the data plane over open and standardized interfaces and protocols. The control applications running on top of element (ii) see a network-wide view based on the abstraction of the distributed network state. To turn the concept of SDN into practical implementation, two requirements must be met. First, there must be a common logical architecture in all switches, routers, and other network devices to be managed by an SDN controller. This logical architecture may be implemented in different ways on different vendor equipment and in different types of network devices, so long as the SDN controller sees a uniform logical switch function. Second, a standard, secure protocol is needed between the SDN controller and the network device. Both of these requirements are addressed by OpenFlow, which is both a protocol between SDN controllers and network devices, as well as a specification of the logical structure of the network switch functions. OpenFlow provides an open protocol to program the flow table in different switches and routers. A network administrator can partition traffic into production and research flows. Researchers can control their own flows - by choosing the routes their packets follow and the processing they receive. In this way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP. On the same network, the production traffic is isolated and processed in the same way as today. II. SDN ARCHITECTURE Software-defined networking (SDN) is a new approach to designing, building, and managing networks that separates the network s control (brains) and forwarding (muscle) planes to better optimize each. SDN providers offer a wide selection of competing architectures, but at its most simple, the SDN method centralizes control of the network by separating the control logic to off-device computer resources. The SDN architecture allows for an enhance abstraction layer for network control, providing for a central overview of all major network components. Because the architecture separates the data plane from the control plane, provisioning, especially dynamic provisioning, is much more flexible. A controller is linked by a secure channel to an OpenFlow device, making it possible to externally manage network functions. SDN can be explained with four points. (a) The control and data planes are decoupled. Control functionality is removed from network devices that will become simple (packet) forwarding elements. (b) Forwarding decisions are flow based, instead of destination based. (c) Control logic is moved to an external entity, the so-called SDN controller or NOS. The purpose of Network Operating system (NOS) similar to that of a traditional operating system. (d) The network is programmable through software applications running on top of the NOS that interacts with the underlying data plane devices.the important components of SDN are as shown in the Fig 1. Fig. 1 SDN Controller: is the brains of the network. It allows SDN users to gain a central look at the entire network, and empowers network administrators to instruct switches and routers how the forwarding plane should direct network traffic. Centralized, programmable SDN environments can easily adjust to the rapidly changing needs of businesses. SDN can lower costs and limit wasteful provisioning, as well as provide flexibility and innovation for networks. SDN Applications: SDN Applications are programs that communicate behaviors and needed resources with the SDN Controller via Application Programming Interface (APIs). In addition, the applications can build an abstracted view of the network by collecting information from the controller for decision-making purposes. These applications could include networking management, analytics, or business applications used to run large data centers. SDN Networking Devices: The SDN networking devices control the forwarding and data processing 23

3 capabilities for the network. This includes forwarding and processing of the data path. The main advantages of SDN over traditional approach are that it allows you to quickly test and deploy new applications in real network, minimize capital and operating expenses and allows centralized management of each switch III. OPENFLOW Openflow is an "open" protocol to enable communication between a Software defined Network controller and network elements. An SDN controller links with OpenFlow-compatible devices using the OpenFlow [2] protocol running over the Secure Sockets Layer (SSL). Each device links to other OpenFlow devices and, possibly, to end-user devices that are the sources and destinations of packet flows. Within each switch, a series of tables typically implemented in hardware or firmware are used to manage the flows of packets through the switch. Openflow enables the controller to create flow table entries in the switches, and also enables the analysis for underlying network topologies. As shown in Fig. 2 an OpenFlow Switch consists of at least three parts: (1) A flow table, with an action associated with each flow entry, to tell the switch how to process the flow, (2) A secure channel that connects the switch to a remote control process (called the controller), allowing commands and packets to be sent between a controller and the switch using (3) The OpenFlow protocol, which provides an open and standard way for a controller to communicate with a switch. The OpenFlow[1] protocol describes message exchanges that take place between an OpenFlow controller and an OpenFlow switch. Typically, the protocol is implemented on top of SSL or Transport Layer Security (TLS), providing a secure OpenFlow channel. The OpenFlow protocol enables the controller to perform add, update, and delete actions to the flow entries in the flow tables. IV. OPENFLOW NETWORK TOPOLOGIES Mininet is a network emulator. It runs a collection of end-hosts, switches, routers, and links on a single Linux kernel. It uses lightweight virtualization to make a single system look like a complete network, running the same kernel, system, and user code. A Mininet host behaves just like a real machine. The programs can send packets through what seems like a real Ethernet interface, with a given link speed and delay. Packets get processed by what looks like a real Ethernet switch, router, or middlebox, with a given amount of queuing. Mininet enables to quickly create, interact with, customize and share a software defined network prototype, and provides a smooth path to running on hardware. Mininet's [4] virtual hosts, switches, links, and controllers are the real thing they are just created using software rather than hardware and for the most part their behavior is similar to discrete hardware elements. It is usually possible to create a Mininet network that resembles a hardware network, or a hardware network that resembles a Mininet network. Here we discuss some of the network topologies using mininet. A. Default Topology The default topology is the minimal topology, which contains one controller, one openflow switch and two hosts. $ sudo mn Fig. 2 Flow tables are used by switches to forward packets. A flow table is a collection of flow entries. Each entry has match fields, counters and instructions. Incoming packets are compared with the match fields of each entry and if there is a match, the packet is processed according to the action contained by that entry. Counters are used to keep statistics about packets. The packet can also be encapsulated and sent to the controller. 24 Fig. 3

4 As shown in Fig. 3 a controller c0, switch s1 and host h1 and h2 are created. $ sudo mn topo single,5 Creates a topology with six single hosts all connected to the same switch as shown in Fig 6 and Fig. 7. Fig 4 The Fig. 4 shows how the default topology might look. mininet> nodes Displays available nodes as shown in Fig. 3 mininet>h1 ping h2 Test connectivity between host can be checked as shown in Fig. 5. Fig. 7 C. Linear topology Linear topology contains n switches and n hosts. It also creates a link between each switch and each host and among the switches as shown in Fig. 8. $ sudo mn topo linear,4 Fig. 5 mininet>pingall Test connectivity between all pair of host is checked as shown in Fig. 5. B. Single Topology The default topology is a single switch connected to two hosts. To increase the number of single hosts topo command can be used. Fig. 8 In linear topology each switch is connected to single host and also there is link between switches as shown in Fig. 9. Fig. 6 Fig. 9 25

5 D. Tree Topology Tree topology contains n levels. Each switch has two hosts. If level is more than one top level switch will be connected to two switches which inturn connected to two switches and finally to two hosts shown in Fig. 10 and Fig. 11 /home/mininet/mininet/custom/test.py and the snapshot is given in Fig 12. Fig. 10 Fig. 12 $ sudo mn --custom ~/mininet/custom/test.py --topo mytopo Fig. 13 Fig. 11 E. Custom Topology Mininet s API allows you to create custom networks with a few lines of Python. With a few lines of Python code, flexible topology can be created, which can be configured based on the parameters you pass into it, and reused for multiple experiments. Custom topologies can be easily defined as well, using a simple Python API, and an example is provided in /home/mininet/mininet/custom/topo-2sw-2host.py. The topo-2sw-2host.py has been modified and file test.py has been created in Fig 14 26

6 V. CONCLUSION Sofware Defined Networking and OpenFlow technology is touching its peak these days. This technology is used to design an effective and real time network. Various tools are required to design and implement an OpenFlow based network. Mininet emulator is a handy tool for networking researchers to emulate real operational network and to test their innovative ideas and new protocols. As it is openflow enabled, it is very much suitable for SDN research. Existing Mininet is enhanced to create custom topologies in a user friendly manner. The custom topology can be specified either through the command line or through the configuration file. The main aim of this paper is to make new user familiar with the mininet tools and various network topology used in OpenFlow. Real systems are very painful to reconfigure. Virtual machines allow easier topology changes but suffer from scalability issues. REFERENCES [1] Rakesh k. Jha, Pooja Kharga, Idris Z. Bholebawa, Sangeet Satyarthi, Anuradha and Shashi Kumari, OpenFlow Technology: A Journey of Simulation Tools, I.J. Computer Network and Information Security, [2] OpenFlow Switch Specification Version.1.0 Implemented (Wire Protocol 0x02 ) February 28, [3] Software-Defined Networking: The New Norm for Networks at [4] The Mininet Team. (2012, August) Mininet: An Instant Virtual Network on your Laptop (or other PC) - Mininet. [Online]. Available: mininet.org /. [5] Mininet Topologies at m/2013/ 11/ min i net-asan-sdn-testplatform. [6] Karamjeet Kaur, Japinder Singh and Navtej Singh Ghumman, Mininet as Software Defined Networking Testing Platform, International Conference on Communication, Computing & Systems, [7] Python at [8] Feamster, Nick, Jennifer Rexford, and Ellen Zegura. "The road to SDN: an intellectual history of programmable networks." ACM SIGCOMM Computer Communication Review 44, No. 2 (2014): [9] Nunes, B.; Mendonca, M.; Nguyen, X.; Obraczka, K.; Turletti, T., "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks," Communications Surveys & Tutorials, IEEE, Vol. 1, No.99, pp. 18. [10] Shenker, Scott, M. Casado, T. Koponen, and N. McKeown. "The future of networking, and the past of protocols." Open Networking Su mmit (2011). 27