SoftEye: Visualization controller for local area network software

SoftEye: Visualization controller for local area network software defined networks Carter Yagemann ([email protected]) Abstract ​
— ​
Both for educational and operational purposes, it is valuable to be able to see a real time visualization of the network being controlled by a software defined network controller. SoftEye is an SDN controller implementation built upon the popular POX platform and tested in mininet. SoftEye is designed to be able to dynamically make a working local area network out of any arbitrary topology of switches without any configuration or setup while also providing a real time graph visualization of the network it is controlling. To achieve this goal, SoftEye builds upon the already established layer 2 learning (L2L) algorithm by introducing an intermediate link discovery step. The research contributions of this project are the recognizing of L2L’s shortcomings for visualization and the proposed improved algorithm which is called layer 2 learning with intermediate link discovery (L2L­ILD). I. INTRODUCTION I.I. Background Software defined networking introduces a modern approach to networking and follows the similar evolution which has lead to virtual machines and network storage. By separating the control and data planes, SDN can achieve behavior which would not be possible in traditional networks. This newfound flexibility allows SDN to achieve unparalleled levels of granularity when making networking decisions which is invaluable in achieving goals like maintaining certain degrees of quality of service. The core components which make up an SDN are the controller and SDN compatible switches. SDN works by having the switches connect to the controller which acts like the brains for the switch’s networking decisions. Every switch maintains a list of flow rules which define how incoming packets should be handled and when a packet which matches no flow rules is received, the switch forwards the packet to the controller. The controller can then parse this packet and instruct the switch on how to handle it. Actions can include dropping the packet, modifying it, and sending it out one or more ports. In addition to being able to reactively respond to unfamiliar packets, controllers can also insert flow rules into switches. When switches receive packets which match one or more flow 1 rules, the switch will take appropriate action without having to consult the controller. This reduces overhead by decreasing the frequency with which the switch needs to communicate with the controller. Flow rules can be explicitly deleted by the controller or configured to expire under set conditions allowing the SDN to stay operable as the network topology changes during normal operation. There are multiple standards and platforms for SDN as this technology is relatively young. In this project, the OpenFlow standard for controller­switch communication was used and the controller was implemented using the POX platform. POX is a python based platform which allows for quick prototyping of OpenFlow SDN controllers. POX handles the TCP server functionality and concurrent connections, requiring the developer to only define the controller logic. This logic can then be loaded into POX as a component. SoftEye’s implementation is as a POX component and the source code is available as an open source repository [3]. I.II. Motivation Many proposed algorithms for managing SDN are shown to work effectively, but do so via a learning phase. Due to this learning phase, it is not completely obvious how an SDN controller will manage a network. Both for educational and operational reasons, it is valuable for a network engineer to be able to see in real time what the topology is of the network the controller is managing and to be able to see what the controller is doing in order to shape the network. The goal of SoftEye is to create a controller which can not only create a working local area network without need for configuration, but also provide in real time a graph of the topology as well as visually represent the flows being inserted into the network. The reason SoftEye is intended to work without configuration is simply to make for a more interesting implementation. It is more interesting and valuable to visualize a topology which the controller had to figure out on its own rather than a topology which the network engineer has already programmed into the controller. The latter case is still holds value by allowing the network engineer to confirm that the controller is acting as expected, but this is less interesting. II. RELATED WORK The majority of the work related to the SoftEye project consists of survey papers [1][2]. These papers compile together the various popular SDN algorithms and platforms and evaluates their effectiveness. Among these evaluations are analysis of the POX platform and the layer 2 learning algorithm (L2L), both of which make up the foundation for the SoftEye project. SoftEye builds upon the L2L algorithm to achieve visualization which the L2L algorithm alone cannot 2 accomplish. More about the nature of this shortcoming and how SoftEye overcomes it is explained in the design section. III. PROBLEM DEFINITION SoftEye’s problem definition is two fold. First, SoftEye should be an SDN controller which can make a working local area network out of any arbitrary topology of switches without the need for any configuration. In other words, it should just work. Second, SoftEye should be able to provide a real time visualization of the network as well as provide a real time visualization of the flow rules being inserted into the network switches. As it turns out, this problem is not as trivial as just taking an existing SDN controller and slapping a graphical interface on it. While many algorithms can solve the first condition, they do so by deriving as little information about the topology as possible and, as it turns out, this derived information is too lacking to be able to fully visualize the network, thereby failing the second condition. The algorithms that fall into this category are mostly comprised of layer 2 forwarding algorithms, of which the L2L algorithm is apart of. On the other hand, many layer 3 routing algorithms derive the information necessary for full network visualization, but do so at a cost. Namely, they have to be configured by a network engineer with some preliminary information in order to make sense of the network topology. This means that they achieve the second condition but fail the first condition. In order to meet both conditions simultaneously, a middle ground is necessary which requires a new algorithm. This new algorithm, layer 2 learning with intermediate link discovery (L2L­ILD), is the major research contribution of this project. IV. DESIGN IV.I Layer 2 Learning Layer 2 learning (L2L) works using a combination of flooding and stored port­device pairs. In the beginning, the network starts with no flow rules. As a result, every packet sent into the network is going to be forwarded to the controller as the switches won’t initially know how to handle them. When a packet comes into the controller, the first thing it does is parse the sender’s MAC address and retrieves the port number which the packet came into the switch on. The controller then stores this pair as an entry in a table for that switch. By doing so, the controller has now learned that for that switch, that device can be reached over that port. After updating the appropriate switch table, the controller next checks if the destination has a corresponding port in the table. If it doesn’t, then that means that the controller doesn’t yet know how to reach that device from that switch. Consequently, the controller will instruct the 3 switch to flood the packet out all the ports except the port which the packet came into the switch on. As the packet floods through the network, it will eventually reach its intended destination. On the other hand, if the destination does have a corresponding port in that switch’s table, then the controller does know how to reach that device from that switch. The controller will respond to the switch by telling it to forward the packet out the appropriate port and the controller will also insert a flow rule telling the switch to use that port for all future packets which have the same destination. This means that in the future, that switch will be able to handle packets for that destination without having to spend time consulting the controller. IV.II Layer 2 Learning’s Shortcoming Because of L2L’s flooding step, it is able to make a working local area network out of any topology. However, L2L is not able to provide a full visualization of the network. The problem is that in L2L’s implementation, each switch is represented as a separate table within the controller. This is fine for networking purposes because all any individual switch cares about is how to forward the packet closer to its final destination. However, if the controller tries to visualize a topology from this information alone, it ends up with blind spots. If the controller assumes that one device can only be connected to the network at one point at a time, a reasonable assumption given that the controller uses MAC addresses for L2L and not IP addresses, it can infer which switch is directly connected to a particular device by observing which switch receives a packet from that device first. The switch directly connected to the device is going to be the first switch to receive a packet from that device and is therefore going to be the first switch to request that the device be added as a node to the graph. This allows the controller to visualize the links between devices and switches, but what about switches and other switches? As it turns out, the controller cannot infer what the links are connecting switches to other switches using L2L. The controller knows when a switch isn't directly connected to the device because of the previously mentioned inference, but the negative of this inference only tells the controller that the next hop will be to a switch; not which switch it'll be. This creates a blind spot as the controller knows the switches are interconnected somehow, but not exactly how. IV.III Layer 2 Learning with Intermediate Link Discovery To overcome this shortcoming, SoftEye uses a newly designed packet called an intermediate link discovery (ILD) packet. It's a very simple packet which contains an Ethernet physical layer and the ILD layer which simply holds a switch's DPID; a unique identifier for that switch. When a switch comes online and registers with the controller, the controller crafts an ILD packet containing that switch's DPID and then the controller instruct the switch to send that packet to its neighbours out all ports. When the directly connected switches get this packet and 4 send it to the controller, the controller now knows that there is a direct link between the switch which received the packet and the switch whose DPID is in the packet. Because of the extra step in this algorithm, it has been named layer 2 learning with intermediate link discovery (L2L­ILD). This novel algorithm is the primary research contribution of the SoftEye project. Using L2L­ILD, the blind spot problem is resolved. This process of sending a packet to a networking device’s neighbours is similar to how some border gateways discover each other, but different in that the controller creates and consumes the packet rather than the networking device. V. PERFORMANCE EVALUATION First, SoftEye’s implementation works. By using the new L2L­ILD algorithm, SoftEye is able to visualize the topology of any network. Figure 1 shows the visual output generated by SoftEye. In this visualization, switches are nodes with “SID_” prepended to their names while device names are prepended with “HMAC_”. The edges of the graph represent the links in the network and when flows are added for a particular device, this is visually represented by having the link between that device and the directly connected switch flash red. Figure 1. The graphical output produced by SoftEye. There is, however, a performance impact as a result of having the controller generate this graphical output. In testing with mininet against the standard L2L implementation, which has no 5 graphical output, using a variety of topologies, it was found that the time needed for the controller to forward packets to an unfamiliar destination increased as much as 10 times. However, once the controller learns the location of the devices, it can insert flows and then the performance of L2L­ILD is identical to L2L. It should be noted that this performance decrease is purely due to the overhead of having to render a visual graph of the topology and is not due to the L2L­ILD algorithm itself. The L2L­ILD algorithm only differs from the L2L algorithm in how it handles switches upon initial registration with the controller and the difference in performance was experimentally found to be negligible. VI. CLOSING REMARKS The source code repository for SoftEye has been open sourced making it publicly available online [3]. This repository contains the POX component code as well as instructions on how to load the code into POX. Anyone is welcomed to download and modify this code for experimentation and learning. VI. REFERENCES [1] Alexander Shalimov, Dmitry Zuikov, Daria Zimarina, Vasily Pashkov, and Ruslan Smeliansky. 2013. Advanced study of SDN/OpenFlow controllers. In ​
Proceedings of the 9th Central & Eastern European Software Engineering Conference in Russia​
(CEE­SECR '13). ACM, New York, NY, USA, , Article 1 , 6 pages. DOI=10.1145/2556610.2556621 http://doi.acm.org/10.1145/2556610.2556621 [2] Danny Yuxing Huang, Kenneth Yocum, and Alex C. Snoeren. 2013. High­fidelity switch models for software­defined network emulation. In ​
Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking​
(HotSDN '13). ACM, New York, NY, USA, 43­48. DOI=10.1145/2491185.2491188 http://doi.acm.org/10.1145/2491185.2491188 [3] https://bitbucket.org/carter­yagemann/softeye/
6