Software Defined Networking and OpenFlow: a Concise Review

Transcription

1 Software Defined Networking and OpenFlow: a Concise Review Stefano Forti stefano.forti92@gmail.com MSc in Computer Science and Networking Scuola Superiore Sant'Anna - University of Pisa 1. Introduction Nowadays networks are preeminently based on Data Link Layer schemes that makes use of MAC addresses in order to forward frames and of a Spanning Tree Protocol to avoid loops and consequent useless network flooding [1]. Whenever a frame enters a switch it is forwarded (a) to the output port only, in case the destination MAC address is already known (b) to all ports (except for the one the packet is coming from) in order to learn where to send frames for that particular destination On one hand this approach is simple and plug-and-play but, on the other hand, it is totally inefficient in case of failure (e.g. broadcast storm may happen). Moreover, all network management and configuration operations are to be performed manually at each node by using tools such as Command-Line Interfaces, allowing to connect one-by-one to all routers in the network Simple Network Management Protocols, used to modify and apply configurations through remote changes of a configuration file NETCONF, designed to automating devices configuration by means of XML for efficiently manage management information Forwarding and Control Element Separation, XMPP, OpenStack, etc Despite the considerable effort in the direction of simplifying their control plane, networks are still difficult to manage due to the complexity of their functions and protocols, to their static configurations, to scalability issues encountered when advanced configurations are required and for the total lack of open, widely adopted, configuration and management tools. The big idea behind Software Defined Networks (SDN) is the physical decoupling and separation of the control plane from the forwarding plane, as shown above. The control plane is totally managed at software level whereas forwarding is performed by dedicated hardware. This concept of an operating system for networks leads to big improvements in terms of efficiency and allows network operations to be specified 1

2 with high level programs, reducing the need for designing and manually configure distributed control protocols. OpenFlow [2][3] is one of the possible protocols for SDN and it is defined to be directly programmable agile and dynamically adaptive centrally managed programmatically configured open standards-based and vendor neutral More generally speaking, any SDN technology should pursue the aforementioned objectives in order to achieve better manageability, scalability and network virtualization. 2. Basic OpenFlow OpenFlow uses the concept of flows to identify network traffic. For each flow, at each node, the controller is able to define a match rule which works exactly the same as one of the instruction within the Instruction Set of a CPU. Rules can be statically or dynamically programmed by the SDN control software (i.e. added, updated, deleted ) and are stored within a flow table. Rule (Switch Port, VLAN_ID, MACs, Eth Type, IP ) Action Stats All flow table entries contain a rule to identify the flow (input port, source, destination), an action to be performed (e.g. forward to port x, forward to controller, drop, modify fields, send to processing pipeline) and some statistics. In case a match is not found for an incoming packet, the default choice is to send it to the controller over a secure channel. The addition of flows can be reactive, i.e. required by the controller when no match for an incoming packet is found, or proactive, if the controller populates the flow table with all its knowledge from the very beginning. Of course the first approach is much more efficient under a flow table utilization point of view but the second is far more reliable with respect to controller failures and flow setup time. Needless to say, as usual, flow table entries must be kept alive and periodically refreshed. Finally, an interesting feature which fosters scalability is the pipelining of flow tables within a certain system, as shown below. 2

3 3. OpenFlow Messages [4] The OpenFlow controller and the switches must exchange messages in order to properly configure the flow tables. Here the most important ones, which are also needed to comprehend the following section, are listed. Message Name Type Description HELLO Immutable exchanged between the switch and controller upon connection startup FEATURES_REQ / FEATURES_REP Configuration useful for the controller to collect information about the switch capabilities PACKET_IN Asynchronous wrap to transfer a packet to the controller PACKET_OUT Asynchronous wrap to transfer a packet to a switch PORT_STATUS Asynchronous Inform the controller of a change on a port. FLOW_MOD Controller Command contains update to the flow table BARRIER Barrier ensures message dependencies are met METER Meters and Rate Limiters controls the rate of the packets 4. Discovery in Software-Defined Networks The word discovery in the SDN environment could refer to the following three distinct and consecutive situations discovery of the switches (topology) discovery of the links discovery of the hosts treated according to different procedures. SWITCHES DISCOVERY The discovery of the switches starts whenever a switch connects to the controller and sends the HELLO message for version negotiation to it; it receives back another HELLO message and the connection is then established. Afterwards, since a transport channel connection has been established between the controller and the switch, the former sends a FEATURE_REQ to the switch in order to determine its capabilities. A FEATURE_REP message, including all the features of the switch (e.g. MAC address, buffer capability, number of tables, ports ), is sent back as shown above. Eventually a SET_CONFIG message is sent to the switch so that it knows what to do with fragmented packets when they are received (i.e. match as-is, drop, reassemble and match, etc.). At this stage, the controller is aware of quite a lot of the topology of the network: switches and their ports. LINKS DISCOVERY The discovery of the links is carried out by the controller, periodically sending Link Layer Discovery Packets (LLDP) to the switches as PACKET_OUT messages which are then flooded through the network. Those messages are useful to identify links between switches. Consider as an example the network in the figure on the next page; suppose that S4 is the only non-openflow switch. 3

4 S1 sends an LLDP through port 1 which is received on port 1 at S3 and forwarded to the controller within a PACKET_IN message. Thus the controller finds out that there is a link connecting port 1 of S1 to port 1 of S3. Analogously, the connection between port 2 of S1 and port 2 of S2 is registered at the controller and so on and so forth with all the other switches and links. A discovery table is rapidly fulfilled with all direct links at the controller. Even though it is not a scalable choice, LLDP packet may be periodically send to detect failures in the network. Since S4 is a non-openflow switch it is not connected to the controller. In addition to LLDP that are discarded it will receive Broadcast Domain Discovery Packets (BDDP) which are instead broadcasted to S2 and S3 and reported to the controller. Thus, the controller will be informed about an indirect connection between port 2 of S3 and port 1 of S2. Spanning Tree Protocol is also used to avoid loop formation. HOSTS DISCOVERY The final step of the topology discovery consists of knowing where hosts are attached and how it is possible for them to communicate. Suppose H1 wants to ping H2. It forwards an Address Resolution Protocol (ARP) request to S1 on port 3. Being no previously installed rule for the incoming flow, a PACKET_IN containing the ARP request is sent to the controller. The triple <H1, S1, port 3> is added to the hosts table, since the controller discovered the new host. Then a PACKET_OUT is sent to S1, asking to flood the ARP request that cannot be resolved by the controller at the moment. ARP requests are then flooded to S2 and S3. Assuming S2 is reached first, then a PACKET_IN is sent to the controller, a PACKET_OUT with the request to flood is received back and the ARP request reaches H2 via port 3. H2 immediately sends an ARP reply, forwarded to the controller. Once again, the hosts table at the controller may be updated with the entry <H2,S2, port 3> and the path from H2 to H1 can be computed. Hosts Table Host Switch Port H1 S1 3 H2 S2 3 The controller sends a FLOW_MOD message to S2 containing the 4-tuple [<inport: 3, src: H2, dst: H1>, outport:2] and another to S1 with [<inport: 2, src: H2, dst: H1>, outport:3]. Both S1 and S2 update their 4

5 flow tables. A PACKET_OUT is sent by the controller to S2 and forwarded to S1 without its intervention; that is the ping reply. Easily enough the flood H1-H2 is established. H1 performs an ICMP request to S1 which forwards it to the controller inside a PACKET_IN. The controller installs the rules [<inport:3, src: H1, dst: H2>, outport: 2] and [<inport:2, src: H1, dst: H2>, outport: 3] in S1 and S2 respectively and sends a PACKET_OUT to S1 in order to issue the initial request. 5. Conclusions Not so incredibly, the main weakness of SDN resides in its power. In fact, a completely centralized architecture inevitably brings to a series of scalability and reliability issues that comprehend controller failures and control channel failures. Nevertheless, although being designed for Ethernet networks, SDN technology in all its flavours is gaining popularity in a variety of networking scenarios such as data centers, wireless networks and optical backbones. For what concerns the latter, a few OpenFlow extensions exist and have been tested by wellfamous company (e.g. Google) with impressive outcomes that bode well for future deployments; yet, at the moment, elder tools such as NETCONF seem to provide a more reliable alternative. References [1] Tanenbaum, Andrew S., and David J. Wetherall. Computer Networks: Pearson New International Edition: University of Hertfordshire. Pearson Higher Ed, [2] The Open Networking Foundation Website with plentiful of information about SDN and the OpenFlow architecture. [3] Foundation, Open Networking. "Software-defined networking: The new norm for networks." ONF White Paper (2012). [4] Flowgrammable is a non-profit, all volunteer team, composed of engineers, researchers, and students; dedicated to increasing the adoption of Software Defined Networking. [5] Google by Urs Hoelzle, Open Networking Summit