Enabling Software Defined Networking using OpenFlow

Transcription

1 Enabling Software Defined Networking using OpenFlow 1 Karamjeet Kaur, 2 Sukhveer Kaur, 3 Vipin Gupta 1,2 SBS State Technical Campus Ferozepur, 3 U-Net Solutions Moga Abstract Software Defined Networking (SDN) brings a drastic change from conventional vendor specific networking to vendor agnostic networking, providing more flexibility and large reduction in Capital and Operating expenditure to network operators. SDN enables separation of control logic from data forwarding and this allows network researchers to develop their own logic to control data flows and packets. OpenFlow is a part of SDN technology that determines how a controller communicates with network devices. The controller is responsible for making control decisions for every traffic flow in the network using OpenFlow. An OpenFlow external controller implements control logic and is responsible for determining the actions that the switch should perform. OpenFlow is an open SDN standard that consists of two main entities, the OpenFlow switch, which implements the forwarding plane, and the Controller, which implements the control plane. They communicate using secure connection that is implemented over a protocol, named OpenFlow. In this paper, we will discuss about SDN architecture, OpenFlow components, flow tables, OpenFlow messages and future research areas. Index Terms Software Defined Networking, OpenFlow, Southbound API. I. INTRODUCTION OpenFlow is Software-Defined Networking (SDN) based technology that is different from the conventional model of networking where what actions to perform is decided by the switch. OpenFlow [1] separates control logic from data forwarding logic, which allows the researchers to generate their own logic for controlling data flows and packets. In OpenFlow external controller (mostly external PC or VM) contains the control logic and which actions should be performed by the switch is decided by this controller. OpenFlow Protocol is used for communication between data plane and controller. Fig. 1 Separate Control Plane and Data Plane In traditional networks, data forwarding and decision logic are located on routers and switches itself (Fig. 1). OpenFlow abstracts these two planes. So no compulsion for both to be on same device. It offers flexibility for decision logic to be shifted to an outside controller. The controller provides centralized network decision logic. II. SDN ARCHITECTURE The OpenFlow Controller can insert flow entries by two methods known as reactive and proactive. In reactive mode, the first packet called Packet In event causes the controller to install flow entries into switches resulting in efficient utilization of costly memory. The drawback is that it introduces little latency. Other drawback is that in case of connection problems between switch and controller, the switch loses its functionality. In Proactive mode, Controller installs flow entries at the time of connection thus eliminating latency. Thus in case of connection problems between switch and controller, the switch does not lose its functionality. But it is required to aggregate (use wildcard) rules to cover all flows. In traditional networks, switches, routers, firewalls, load balancers are specialized vendor specific hardware devices having tightly coupled data and control plane. The functionality of these devices cannot be changed dynamically. In SDN, data planes are cheap commodity silicon devices. Decoupled Control plane will use OpenFlow protocol to communicate with data plane. On top of control plane, network applications such as switching, routing, firewall and load balancer can be implemented by using combination of flow table entries (Fig. 2). 34

2 Controller independently sets up every flow in per flow based routing. There is one entry per flow in flow table. Exact match is performed for flow entries. It is a requirement for fine grain control. In aggregated flow routing, a single entry can represents large number of flows. Each category of flows contains one flow entry. It uses wildcard flow entries for aggregated flow based routing. Single controller communicates with distributed data planes in the centralized control plane. There are many centralized controllers such as NOX [2], POX [3], OVS [4], Trema [5], Floodlight [6], Flowvisor [7], Beacon [8] and Maestro [9]. B. FlowTable It is the most important building block for OpenFlow switches. Every packet entering into switch has to pass through one or more than one flow tables. A table may have one miss entry containing wildcard in all match fields with lowest priority value of 0. OpenFlow can be used with wide variety of network traffic involving various protocols and services. The sequence of packets is called flow. Combination of flow entries on more than one switch specifies a flow which is bound to a particular path. The main building blocks of table entries are: The drawback of centralized control plane is that it represents a single point of failure. Onix [10], HyperFlow [11] and Kandoo [12] represent the idea of distributed controllers. In SDN, the use of multiple controllers for controlling switches is allowed. III. OPENFLOW An OpenFlow switch consists of OpenFlow agent/client software used for communicating with the controller. It contains group and flow tables for packet lookups and forwarding decisions. Meter table is used for QOS. Flow tables exchange data in the form of metadata. Controller and Switch understand a common language called OpenFlow Protocol. The various building blocks of OpenFlow protocol are: A. Messages The messages that are exchanged between an OpenFlow controller and an OpenFlow switch are specified by OpenFlow protocol. There are three types of messages: Controller initiates messages between control plane and switch for directly controlling or viewing state of switch. Symmetric messages are exchanged without any side requesting them. Asynchronous messages are sent by the switch itself to the controller without controller asking for it. Fig. 2 SDN Network Architecture 1) Match Fields: Match the packets with values in the fields. The match fields may contain required and optional fields (Table I). The OpenFlow switches must support the required fields. 2) Action/Instructions: The various actions that can be taken. It could be forwarding the packet to specific port, all ports except incoming port, dropping the packet, modifying header fields and sending the packet to the controller. The instruction could be to modify action set or send to pipeline processing. Required Fields Ingress Port Ethernet Source and Destination Address IPv4 or IPv6 Source and Destination Address TCP or UDP Source and Destination Ports Ipv4 or IPv6 Protocol Number Optional Fields Physical Port Metadata Ethernet Type Vlan id and priority ICMP or ICMPv6 type Code Fields TABLE I MATCH FIELDS Description Physical or Virtual port on which the packet arrived Entry can be a wildcard(match any value), exact value or bit masked value in which only some address bits are checked Entry can be a wildcard(match any value), exact value or bit masked value in which only some address bits are checked Wildcard or exact match value Match specified value Description Used to specify underlying physical port when packet is received on logical port Additional data that is passed from one flow table to another during packet processing Ethernet Type Field Vlan Header Fields Wildcard or exact math value 3) Action/Instructions: The various actions that can be taken. It could be forwarding the packet to specific port, 35

3 all ports except incoming port, dropping the packet, modifying header fields and sending the packet to the controller. The instruction could be to modify action set or send to pipeline processing. 4) Priority: Relative importance of flow table entries. High priority means more important entry. 5) Counters: It is used to collect statistics regarding various parameters such as number of bytes and packets received on per port, per flow entry, per flow table basis, duration of flows and number of dropped packets. 6) Cookie: A data field value that is send to the switch in a flow mod message, used to identify a set of flows. 7) Timeouts: Each entry contains two timeouts. Idle timeout defines the time in seconds after which flow entry will be removed if no matching packet is found. In case of hard timeout, the entry is removed irrespective of whether the match is found or not. Zero values means that entries are never timed out. If both times are set, the flow is removed when the first of these two expires. C. OpenFlow version specification The development of OpenFlow can be traced back to 2006, when Martin Casado, a Phd research scholar at Stanford University, developed Ethane [13]. It used flow based centrally managed controller to implement network security. This initiative finally lead to OpenFlow due to further research at Stanford and University of California. Open Networking Foundation (ONF) is user driven body dedicated for the adoption and promotion of SDN Open Standards. The main contribution of ONF [14] is OpenFlow standard which enables the communication between control plane and data plane (Table II). ONF drives the development of OpenFlow specifications [15]. OpenFlow v1.1, target at WAN research. On packet match, look at instructions. Allows multiple tables. OpenFlow v1.2, described as Extensible Protocol, supports for IPv6 and multiple controllers. OpenFlow v1.3, meter table was added to implement QOS. OpenFlow v1.4, Optical ports, bundles, eviction, flow monitoring. D. OpenFlow pipeline processing The development OpenFlow switches contain many flow tables with each having large number of flow entries. OpenFlow pipeline processing determines how the packets are dealt with in flow tables (Fig. 3). A switch can contain one or more than one flow tables. The multiple tables are arranged as pipeline. The tables are labeled with numbers starting from from 0 and in incremental order. When the packet is send to the table, additional information such as ingress port, metadata and action set is also presented. The action set is empty and metadata is blank for Table 0. If the packet matches with one or multiple entries, then the highest priority entry is selected. Various actions taken can be Update counters linked with this entry. Apply instructions linked with match flow entry. Forward the packet to next table in flow pipeline, group table, meter table, or to an output port. In last table of pipeline, sending to another flow table is not possible. TABLE II OPENFLOW VERSIONS Open Flow Specifications Version Year Features v1.0 Dec 2009 Single Table, stress on L2 and IPv4 Header Fields v1.1 Mar 2011 Multiple table, MPLS, group table v1.3 June 2012 Meter table, multiple parallel channels between switch and controller v1.4 Aug 2013 Better support for optical ports, incremental improvements OpenFlow v1.0 is first stable and most deployed version presently. Released in dec. 2009, targeted at campus research. If the packet matches in flow table, perform specified action. 36 The packet is finally send to an output port, combined action set is executed and packet is queued for output. E. OpenFlow Ports The OpenFlow supports physical, logical and reserved types of ports [17]. These could be used as Ingress (receive interface) or Output (forward Interface) ports. F. Table-Miss Entry If packet matches with table-miss entry, then one of these actions can be performed: Send packet to controller. Direct packet to another flow table down the

4 pipeline. Drop the packet. G. Instructions and Action Set Every flow entry contains a set of instructions. These instructions get executed when a packet matches the flow entry. An instruction contains a list of actions to be added to action set or it can have a list of actions that can be applied immediately on the packet, or instructions can modify pipeline processing. Four types of instructions can be (Fig. 4). 1) Send packet to pipeline: The Goto-Table instruction sends the packet to particular flow table in pipeline. The Meter instruction will send packet to specified meter table. 2) Perform action on packet: Fig. 4 Instruction Set 1) Clear Actions: Clear actions set. 2) Apply Actions: Immediately apply actions. 3) Write Actions: Combine actions with already present actions. 4) Write Metadata: write metadata. 5) Goto-Table: send to specified table. H. Group Table and Meter Table Fig. 1 Multiple Table Processing 3) Update action set: Merge specified actions or clear all the actions action set. The purpose of Group tables is to perform specific forwarding tasks like load-balancing or failover (Fig. 5). Flow table allow you to forward or drop packet to one port. On other hand, group table allows flow table to forward to a random port from a group of ports (load-balancing) or a first active port from a group of ports (failover) or all ports from group of ports (multicast). The goal of Meter tables is to apply QOS on flows such as rate limits. 4) Update Metadata: The Metadata is used for moving data from one table to next table. An Action Set [16] is an accumulated list of actions. It gets accumulated while packets go through each table and get executed when packet exits the processing pipeline. Each packet has an action set associated with it. By default, this action set is empty initially. Action set is moved across flow tables. With Write-Action instruction or a Clear-Action instruction contained in flow table entry, action set can be modified linked with that match. When there are not any Goto-Table instructions, processing stops and the actions in the set get executed. Various instructions to change action set are: Fig. 5 OpenFlow Tables IV. CONCLUSION Use either OpenFlow is very promising technology for implementing programmable networks. OpenFlow switches can be used as multilayer network devices such as learning switch, router, firewall and load balancer. It is very important to remember that OpenFlow does not mean that it is whole SDN but it is a fact that it is one of the most important building blocks of SDN. Proper 37

5 integration of OpenFlow with wireless networks, data centers and cloud are future research areas. Distributed control plane architecture required for high availability and reliability is another challenge area. The flow tables size, delay introduced in southbound communications are other future research areas. REFERENCES [1] Lara, Adrian, Anisha Kolasani, and Byrav Ramamurthy. "Network innovation using openflow: A survey." (2013): [2] J. U. Duncombe, Infrared navigation Part I: An assessment of feasibility, IEEE Trans. Electron Devices, vol. ED-11, pp , Jan [3] Pox at [4] Open Networking Foundation OpenFlow Switch Specification Technical Report. Open Networking Foundation [5] Trema openflow controller framework [6] Floodlight, an open sdn controller at [7] R. Sherwood, M. Chan, A. Covington, G. Gibb, M. Flajslik, N. Handigol, T.Y. Huang, P. Kazemian, M. Kobayashi, J. Naous, et al. Carving research slices out of your production networks with openflow. ACM SIGCOMM Computer Commun. Review, 40(1): , [8] Erickson, David. "The beacon open flow controller." In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, pp ACM, [9] EugeneNg, ZhengCai AlanL Cox TS. "Maestro: Balancing Fairness, Latency and Throughput in the OpenFlow Control Plane." [10] Koponen, Teemu, Martin Casado, Natasha Gude, Jeremy Stribling, Leon Poutievski, Min Zhu, Rajiv Ramanathan et al. "Onix: A Distributed Control Platform for Large-scale Production Networks." In OSDI, vol. 10, pp [11] Tootoonchian, Amin, and Yashar Ganjali. "Hyperflow: a distributed control plane for openflow." In Proceedings of the 2010 internet network management conference on Research on enterprise networking, pp USENIX Association, [12] Hassas Yeganeh, Soheil, and Yashar Ganjali. "Kandoo: a framework for efficient and scalable offloading of control applications." In Proceedings of the first workshop on Hot topics in software defined networks, pp ACM, [13] Casado, Martin, Michael J. Freedman, Justin Pettit, Jianying Luo, Nick McKeown, and Scott Shenker. "Ethane: Taking control of the enterprise." ACM SIGCOMM Computer Communication Review 37, no. 4 (2007): [14] Open Network Foundation at [15] Ren, Tiantian, and Yanwei Xu. "Analysis of the New Features of OpenFlow 1.4." In 2nd International Conference on Information, Electronics and Computer. Press, [16] Mirzaei, Saber, Sanaz Bahargam, Richard Skowyra, Assaf Kfoury, and Azer Bestavros. "Using Alloy to Formally Model and Reason About an OpenFlow Network Switch." (2013). [17] 38