Telekinesis: Controlling Legacy Switch Routing with OpenFlow in Hybrid Networks

Transcription

1 : Controlling witch Routing with OpenFlow in Hybrid Networks Cheng Jin, Cristian Lumezanu, Qiang Xu, Zhi-Li Zhang, Guofei Jiang University of Minnesota, NEC Laboratories America, ABTRACT Hybrid networks contain both legacy and programmable network switches and allow operators to reap the benefits of oftware-defined networking (N) without upgrading the entire network. Previous research shows that adding N capabilities to switches at strategic places in a network and ensuring that each flow traverses at least one such switch is sufficient to achieve many N control paradigms, such as routing or access control. However, the control points are still limited to the N-enabled devices and operators cannot enforce fine-grained policies on the legacy paths between N switches. We present, a network controller that enables finergrained routing control over legacy paths in hybrid networks using OpenFlow. To update routing entries in legacy switches, we introduce a new flow control primitive,. Flow- Mod uses OpenFlow s PacketOut function to send a special packet on a specific interface of a legacy switch and remotely manipulate the forwarding entry associated with the source of the packet. Using simulations on random network topologies with varying degrees of OpenFlow deployment, we show that can provide more diverse path control than an OpenFlow-only controller: even when only 20% of switches are OpenFlow-enabled, we can update 70% of the paths. Categories and ubject escriptors C.2.1 [Computer-Communication Networks]: Network Architecture and esign; C.2.3 [Computer-Communication Networks]: Network Operations General Terms esign, Management Keywords ; Hybrid N Most of this work was conducted while the first author was an intern at NEC Laboratories America. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. OR2015, June 17-18, 2015, anta Clara, CA, UA. Copyright 2015 ACM. IBN /15/06$ OI: 1. INTROUCTION N provides a logically-centralized interface to control and interact with network devices. Operators perform network management tasks such as traffic engineering or access control through software programs executed from a centralized controller. The flexible control and expanded visibility offered by N [7] can reduce the cost of operating a network by half [2]. However, fully benefiting from N requires a considerable initial investment: network providers must upgrade or replace all legacy devices with programmable ones (e.g., whose forwarding tables are programmable remotely from a logically-centralized controller using a specialized protocol such as OpenFlow) 1. Recent work, both in academia and industry, attempts to reduce the capital expenditure of N while maintaining most of its benefits, by upgrading only a few, strategically chosen devices in a network. We refer to such networks as hybrid networks. Panopticon develops an optimization framework to determine the location of partial N deployment and enforces that every network flow traverse at least one N-enabled switch [5]. HybNET provides a common configuration mechanism for an existing hybrid network and automatically translates legacy to N configurations and vice versa [6]. VMWare s NX forgoes physical programmable switches altogether and implements N in hypervisors at the edge of the legacy network [4]. Although effective at controlling paths through N-enabled devices, neither Panopticon nor NX can dynamically affect the configuration of legacy switches and, consequently, the paths through the legacy nework. network paths between two N switches are coarsely controlled using VLANs or tunnels [5, 4] or simply left to the latitude of Layer 2 routing protocols such as TP or ECMP. HybNET proposes a netconf-based mechanism to change legacy switch routing but its speed (more than 10s to configure a switch) makes it incompatible with real world networks. In this paper, we explore the following question: can we extend the main capability of an N switch (that of allowing remote programming of its forwarding tables) to legacy devices in the same hybrid network? In other words, can we control paths through legacy switches with the same network controller used to manage the N devices? Towards answering this question, we introduce, a network management framework that enables fine-grained routing control over legacy paths in hybrid N using OpenFlow. To update routing entries in legacy switches, we propose a simple primitive,. When calling with respect 1 Throughout the paper, we interchangeably use the terms programmable, N(-enabled), or OpenFlow(-enabled) to refer to switches whose forwarding entries can be updated from a remote controller using OpenFlow.

2 to an OpenFlow switch A, a legacy switch B, a port on the legacy switch p, and a address m, instructs the Open- Flow switch to send a special packet (with m as the source ) to port p on the legacy switch. Assuming that B runs learning, it will update its forwarding entry for m. This mechanism allows us to remotely manipulate a forwarding entry on a legacy switch using OpenFlow and learning. is similar conceptually to Fibbing, a mechanism proposed by Vissicchio et al.to improve the flexibility and diversity of Layer 3 routing [9]. Indeed, and Fibbing share the same philosophy: that we can indirectly affect network routing by injecting fake and harmless information into the network. However, their scope and goals are different. works at layer 2 in hybrid N networks consisting of legacy and OpenFlow switches, with the goal of improving path diversity by providing more fine-grained legacy path control. Fibbing works in layer 3 legacy networks consisting of only legacy routers. It injects fake network topologies into link-state routing to improve routing flexibility, while ensuring loop-free paths. Not all network paths can be enforced by. Updating a forwarding entry for m to port p requires that the switch be accessible on port p. For this, p must be directly connected to an OpenFlow switch or be part of the layer 2 underlay that controls -level routing (e.g., spanning tree). Given a path to update, first checks whether the update is possible for every switch on the path and then attempts to enact it. Using experiments on random network topologies with varying degrees of OpenFlow deployment, we are able to update 70% of the paths, when only 20% switches in the network are OpenFlow-enabled. When there is no data traffic traversing the original path, can update the configuration to a new path using a constant overhead, proportional to the number of legacy switches on the new path but not on the old one. ata traffic on the original path may override the path updates if not all switches on the new path are updated quickly enough. To ensure that an update is eventually applied, adapts to the rate of underlying data traffic and adjusts the rate of special packets accordingly. We make the following contributions. First, we present an Open- Flow based primitive,, to remotely configure forwarding entries for legacy switch interfaces reachable from an N switch in the same hybrid network. econd, based on Flow- Mod, we design, a hybrid network controller that achieves better path diversity and more fine-grained path control than regular OpenFlow controllers deployed in a hybrid network. The rest of the paper is structured as follows. In ection 2, we discuss the motivation for deploying hybrid networks and present a short overview of path enforcement in layer 2 legacy and Open- Flow networks. ection 3 describes how to remotely manipulate legacy switch forwarding tables using OpenFlow and sketches the design for, our hybrid network controller. We present a preliminary evaluation in ection 4, followed by conclusions and an introspection into planned future work in ection BACKGROUN AN MOTIVATION In this section, we introduce hybrid layer 2 networks and discuss mechanisms to enforce a given path in either legacy networks or software-defined networks. 2.1 Hybrid Networks Hybrid networks (also called transitional networks by Levin et al.[5]) contain both OpenFlow and legacy switches. They provide a tradeoff to network providers between the cost to deploy and the benefit derived from having a software-defined network. Because providers do not need to upgrade the entire network, they can take advantage of the increased control and visibility provided by N at a fraction of the cost [5, 4, 6]. However, the increased control is still limited to the N-enabled devices. Neither of the existing hybrid networks provide a way to dynamically manage the configuration of legacy devices. Thus, legacy paths between N switches must be manually set up (e.g., with VLANs) or left in the care of layer 2 protocols such as TP. Next we present a short overview of path enforcement in both legacy networks and software-defined networks. 2.2 Path Enforcement networks. tandard layer 2 Ethernet switches perform two main functions: learning (the next-hop switch towards a destination address) and forwarding (a packet according to learned information). To learn the next-hop switch for a packet, layer 2 switches broadcast the packet on all ports except the one on which the packet arrived. To prevent loops they restrict the underlying topology to a spanning tree by turning off (e.g., using TP) or aggregating (e.g., using link aggregation) multiple links. To learn the port on which to forward a packet with a specific address, switches use learning: if a packet with source address m arrives on port p they assume that any future packet with destination addressmcan be delivered throughp. The path of a packet is static and changes only if there are topology or configuration changes in the network. To increase path diversity, operators can slice the network into multiple VLANs, each with its own spanning tree and set of forwarding entries. Figure 1a shows how to set up a path in a legacy network. The network builds a spanning tree to prevent broadcast loops. As a result, the traffic between and will be re-routed on the spanning tree. This limits path selection flexibility, as feasible paths must contain spanning tree links, and network performance, as paths may be much longer than necessary. oftware-defined networks. oftware-defined networking allows operators or software programs to remotely modify their forwarding entries from a logically-centralized controller using a specialized protocol such as OpenFlow [7]. Thus, switches learn about unknown destinations and routing policies without requiring expensive broadcast or complex configurations. Unlike legacy networks, N provides explicit and fast path control across the whole topology. If all switches in Figure 1a are OpenFlow switches, explicit rules can be added in the switches to easily set up any path between and, thereby improving both path selection flexibility and network performance. Hybrid networks. Hybrid networks retain some of the advantages of N with respect to path selection and network performance. When replacing a legacy switch with an OpenFlow switch, we add yet another point of control into the network, which may enable setting up new and better paths (see Figures 1a and 1b). Fully controlling paths in hybrid networks requires control of both the OpenFlow switches and the legacy switches on the paths. Although some switch vendors enable remote configuration (e.g., using netconf), this is usually slow and not amenable to the speed of real world networks. In the next section, we present a simple mechanism that allows us to use OpenFlow and the learning function in legacy switches to remotely configure forwarding entries on legacy switches. 3. EIGN At the heart of this paper lies a simple question: can we use OpenFlow to control and update forwarding entries on legacy network switches? In this section, we describe a simple mechanism that realizes such control on specific switches. We then introduce

3 LE6 OpenFlow (a) A legacy network with six switches. The spanning tree created by PT (depicted by the blue links) dictates network paths. Figure 1: Path setup in legacy and hybrid networks. (b) A hybrid N network. All the links in the spanning tree and adjacent to the OpenFlow switch can be used. the preliminary design of, a controller for hybrid N networks that provides fine-grained control over both N and legacy paths. 3.1 Goal and Assumptions Assumptions: We consider a layer 2 hybrid network with both programmable and legacy switches. We control the programmable switches with OpenFlow, but we cannot directly update the legacy switch forwarding entries. While technically feasible, remote configuration for legacy switches (e.g., using netconf) is slow and unreliable [6]. A forwarding entry consists of a destination address m and an action (e.g., send to port, drop ) to be applied to packets whose destination ism. We also assume that each legacy switch runs learning and that the legacy network is configured, either manually or automatically, to avoid routing loops (e.g., with TP). We call the collection of legacy links that results after this configuration the network underlay. The underlay is a always a tree or a collection of trees. Goal: Given a configured path (i.e., a sequence of switches) P between two hostsaandb attached to a hybrid network and a new pathp, we want to enforcep in the network, i.e., change the path between A and B from P top. P P Figure 2: An example of P and P. (1,6,2) and (4,7,5) are the subpaths needed to be updated. 3.2 Idea Our insight is to use OpenFlow switches to send special packets to the legacy switches on the new path. These packets take advantage of learning to manipulate legacy switches into updating a single forwarding entry in their routing tables. For example, if we want to modify the action of a routing entry for m from send to port p1 to send to port p2, we create a packet whose source address is m and make sure it arrives at the switch on port p2. The learning algorithm sees the packet arriving onp2 and assumes its source address m is reachable on p2, therefore updating the corresponding forwarding entry. UpdatingP top requires updating all switches onp but not on P and all switches where the two paths diverge and converge 2. For example, in Figure 2, we must update all switches except switch 3. We refer to an update subpath as a sequence of adjacent switches that must be updated during a path change. In Figure 2, (1,6,2) and (4,7,5) form subpaths. All special packets that we use to remotely manipulate a legacy switch s forwarding table must arrive at the switch on a link that is part of the path we want to install. This leads to the two conditions that a path P needs to satisfy before it can be enforced: Condition 1: All legacy links on path P (i.e., links that have at least one legacy switch as endpoint) must be either part of the legacy layer 2 network underlay (e.g., the spanning tree) or adjacent to an OpenFlow switch. This guarantees that each legacy link on P is reachable from an OpenFlow switch. Condition 2: Every update subpath of P must contain at least one OpenFlow switch. Otherwise, no OpenFlow switch in the network can send a special packet that reaches a switch on the update subpath through a link part ofp, even if the update subpath is part of the layer 2 underlay. 3.3 We now present the preliminary design of, a hybrid network controller that can modify forwarding tables on both OpenFlow and legacy switches. mirrors the design of a general OpenFlow network controller and adds two components: path verification and path update. Given a network configuration (i.e., forwarding tables on all switches and the network underlay) and a new path P to enforce between two endpoints attached to the network, first checks whether the path P is feasible and then proceeds to update each switch on the subpaths. We present the two components in detail below Path Verification Given a pathp and the current network configuration, path verification determines whether P is feasible in the network. First, it 2 We assume the reverse paths are updated as well.

4 s Flow Table: Match Action src=, dst= Output: src=, dst= Output: s Flow Table: Match Action src=, dst= Output: src=, dst= Output: src=, dst= src=, dst= OpenFlow OpenFlow (a) Enforce the path between 1 and 1 in the initial stage where no traffic between end-hosts. Figure 3: An example of path update in a hybrid network. (b) Change the path between 1 and 1 to a new one: (,,,), while the connection is still alive. verifies if all legacy links on path P are part of the legacy layer 2 network underlay or adjacent to an OpenFlow switch, following Condition 1. econd, for every update subpath of P, verifies whether at least one switch is OpenFlow enabled, following Condition 2. If both conditions hold, updates the forwarding entries in one or more OpenFlow switches (for subpaths starting or ending with at least one OpenFlow switch) or uses one OpenFlow switch to send a message (for legacy links part of the underlay). Algorithm 1 presents the steps taken when verifying the feasibility of a path. Algorithm 1 : Path Verification Algorithm P 1: for x P k y k do 2: for each legacy link e LE i do 3: if e LE i not in the underlay and e LE i switches then 4: returnp is infeasible 5: end if 6: end for 7: tag 0 8: for each switch n i do 9: ifn i is OpenFlow enabled then 10: tag 1 11: break 12: end if 13: end for 14: iftag = 0 then 15: returnp is infeasible 16: end if 17: end for 18: return P is feasible contains only legacy Path Update To support forwarding entry updates on legacy switches, we introduce a new primitive, called. We use to generate and send special packets to the switch we want to control. The only requirement we enforce on the header of these packets is that their source address should be the same as the associated with the forwarding entry we want to change. pecial packets may have any time. However, to limit the side-effects to the network, we send ARP packets, as they update only ARP caches in hosts and switches. To send a special packet, we use OpenFlow s PacketOut functionality, which allows us to use any OpenFlow switch we control to put a packet on the data plane. We must be careful to call PacketOut with respect to an OpenFlow switch that can reach the intended legacy switch using a link that is on the new path we want to enforce. Algorithm 2 presents the path update process. Figure 3 shows an example of path update. Initially, the path between and is (,,) and we want to update it to (,, OF 6, ). This requires changing the forwarding entries on (to forward packets for to rather than ) and on (to forward packets for to rather than ). calls to send special packets from to. The packets contain the address of as their source address and trigger the learning algorithms on switches and to update their forwarding tables according to the incoming interfaces. When updating a path, automatically updates the reverse path as well. For brevity, we omit the description of reverse path change but reflect it in Figure 3. In this example, as the subpath(,,) starts or ends with one OpenFlow switch, i.e., we can also simply update the forwarding entry in to redirect traffic from to on the link (,). In this way, will change the forwarding entry to forward future packets for to after it receives one data packet from. Algorithm 2 : Path Update Algorithm P 1: for x P k y k do 2: tag 0 3: for each switch n i do 4: if n i is OpenFlow enabled then 5: add forwarding rules in n i forp 6: iftag = 0 then 7: call to send special packets 8: tag 1 9: end if 10: end if 11: end for 12: end for 3.4 iscussion The key to our path enforcement is to make legacy switches react to fake packets sent along the path we want to set up. When setting up a new path, we change the state of the legacy switches at

5 2. Unicast Gratuitous ARP src_=, dst_= 1.Request 3. Reply 4. Unicast Gratuitous ARP src_=, dst_= (a) (b) (c) 5.Request 6. Reply (d) (e) (f) Figure 4: An example of path flapping. and are legacy switches, and is an OpenFlow switch. Assume the connection between and has been set up, and traffic is going on the path (,). We want to change the path to (,,). only injects special packets towards. the intersection between the old (existing) path and the new path. However, the state may revert if data packets on the reverse original path arrive at a switch after our special packets. The late packet, which has the same source as our special packet but arrives on a different port, modifies the forwarding table on the switch to the original entry. We call this phenomenon path flapping. Next we present an example of path flapping and discuss a solution. In Figure 4, the original path between and is (,) and the new path to be setup is (,,). Changing the path requires updates to both legacy switches. uring the path change process, and communicate to each other (Figure 4a). However, after updates switch to forward traffic for to instead of (Figure 4b), a late reply from arrives at on the original path. This changes the forwarding entry associated with back to send to and nullifies the outcome of (Figure 4c). To guarantee the path change, must send another special packet. Note that the problem would persist even if we sent special packets to both legacy switches which updated their configuration at the same time: there is a small probability that a packet between and is on the wire between and when the updates are applied. To overcome path flapping, we propose that continually injects special packets until legacy switches reach a stable state. This happens when data packets start traversing the new path in both directions. The controller can detect such events by deploying a matching rule on an OpenFlow switch that lies on the new path but not on the old one. How often injects special packets depends on the rate of data packets traversing the old path. Ideally, we would inject special packets to at least match the rate of the data packets. However, we also must be careful to limit the network overhead, as a high rate of special packets can limit the OpenFlow switch functionality and in extreme cases introduce congestion in the network. In this paper, we assume that path updates in are not atomic and that a path can flap back and forth before stabilizing. Recent work in software-defined networking studied how to perform consistent network updates, such that all packets follow either the old or the new path [8, 3]. uch work is orthogonal to the goals of this paper but is part of one of the directions we consider for future work. 4. PRELIMINARY EVALUATION We built a proof-of-concept prototype for based on the Pox OpenFlow controller to which we add the path verification and path update components. Our preliminary evaluation focuses on two key questions: 1) can significantly increase the degree of control that we have over the network?, and 2) what is the cost of such increased control in terms of network overhead? We use Mininet [1] to simulate a hybrid network. To mimic legacy switches, we set OV into standalone mode and disconnect them from the controller. All other switches in the network run as normal OpenFlow switches. We configure VLANs on switches to construct the static network underlay. We also add a default rule with low priority in all OpenFlow switches to drop all packets, in order to avoid forwarding any packets received from legacy switches which are used to conduct learning. When we want to enable a path going through an OpenFlow switch, we add explicit forwarding rules with higher priority. We use Tcpdump to capture all packets in the network in order to measure the overhead of path update. 4.1 Feasibility We show that provides more diverse path control

6 Fraction of uccessful Path Update witches 500 witches 1000 witches Fraction of OpenFlow witches Fraction of uccessful Path Update x (Faster) ata Interval-ingle 1.4x (Fast) ata Interval-ingle 1.8x (low) ata Interval-ingle 2x (lower) ata Interval-Both n pecial Packets Figure 5: ucceed ratio of path updates with as a function of the fraction of OF switches. Figure 6: Cost to enforce a path update with as a function of the number of special packets. compared to a controller that manages only the OpenFlow devices. Using randomly generated network topologies with hundreds to thousands of switches and at various degrees of OpenFlow deployment, we compute the fraction of successful path updates. For each fraction of OpenFlow switch deployment, we run a hundred experiments on random topologies with 100, 500, 1000 switches respectively. We randomly generate a pair of old and new paths between two hosts, and verify whether the new path can be updated by. Our results present average across all runs. Figure 5 presents the success ratio of path updates with, while varying the OpenFlow switch coverage and the network size. Even when only 20% of the switches are OpenFlow-enabled, can update 70% of the paths. Increasing the OpenFlow coverage increases the percentage of successful path updates. The figure also shows that the size of the network has little effect on the additional diversity unraveled by : when the total number of switches increases from 100 to 1000, the fraction of successful path updates does not change much. This indicates that can serve large-scale networks. 4.2 Overhead Enforcing a new path introduces network overhead due to the special packets we send from OpenFlow switches. If there is no path flapping, it suffices to send a single packet for every switch whose configuration we want to update. With path flapping, the number of packets we send depends on the rate of the data traffic in the network. Using the same setup as above, we randomly generate a pair of old and new paths between two hosts, such that updating to the new path essentially requires updating at least the two switches at the intersection between the old path and the new path 3. As mentioned earlier in ection 3.3.1, if one of the intersection switch is OpenFlow enabled, we can simply update a forwarding entry in the OpenFlow switch to redirect traffic on the link in the new path. Using to send special packets accelerates the path update but it is not mandatory. Otherwise, must call to send special packets towards the intersection switches. We experiment in the more general case where both intersection switches are legacy to measure the network overhead of path update. We continually send ICMP traffic between the hosts. 3 The fewest number of switches needed to be updated is two, and it is more likely that these two intersection switches are not OpenFlow-enabled. We define the interval between data packets as the data interval. We also inject special packets from an OpenFlow switch on the new path. The time between consecutive special packets is the control interval. We vary the size of the control interval among 1, 1.4, 1.8, and 2 times that of the data interval. Figure 6 shows the cumulative distribution of the number of special packets needed to apply an update on a switch according to the ratio between the data and control intervals. As expected, the number of special packets needed to apply an update increases with the interval between special packets. Injecting special packets with the source of both hosts, rather than a single one, can change the path faster (green line on Figure 6), albeit at twice as much network overhead. This is because switches do not need to wait until the direct path is changed to update their forwarding entries for the reverse path. 5. ICUION AN CONCLUION We presented a preliminary design for, a hybrid network controller that manages forwarding entries on both legacy and OpenFlow-enabled switches. The main idea behind is that we can use OpenFlow to send special packets on selective interfaces of legacy switches to influence the internal learning of these switches. This allows us to remotely manipulate the forwarding entries on these switches. This paper is only a first step towards enabling routing control over legacy paths in hybrid networks using OpenFlow. There are still many interesting issues to be addressed. First, we want to improve the path enforcement mechanism adjusting to the dynamic network factors, such as data interval and latency. econd, we will explore the benefits of the strategic OpenFlow switch placement. Although can improve path control with random Open- Flow switch locations, we believe a more careful deployment can increase the path diversity significantly. 6. ACKNOWLEGMENT We thank the anonymous reviews for their valuable feedback. The bulk of this work was conducted while the first author was an intern at NEC Laboratories America. This research was supported in part by NF grants CN , CN and CRI , a Raytheon/NF subcontract /CN , TRA grant HTRA and o ARO MURI Award W911NF

7 7. REFERENCE [1] Mininet. [2] oftware efined Networks tudy. pr-n-nfv-eployment.asp. [3] KATTA, N. P., REXFOR, J., AN WALKER,. Incremental consistent updates. In HotN (2013). [4] KOPONEN, T., AN ET AL. Network virtualization in multi-tenant datacenters. In UENIX NI (2014). [5] LEVIN,., CANINI, M., CHMI,., CHAFFERT, F., AN FELMANN, A. Panopticon: Reaping the Benefits of Incremental N eployment in Enterprise Networks. In UENIX Annual Technical Conference (2014). [6] LU, H., ARORA, N., ZHANG, H., LUMEZANU, C., RHEE, J., AN JIANG, G. HybNET: Network Manager for a Hybrid Network Infrastructure. In Middleware (2013). [7] MCKEOWN, N., ANERON, T., BALAKRIHNAN, H., PARULKAR, G., PETERON, L., REXFOR, J., HENKER,., AN TURNER, J. OpenFlow: enabling innovation in campus networks. ACM igcomm CCR 38 (2008), [8] REITBLATT, M., FOTER, N., REXFOR, J., CHELINGER, C., AN WALKER,. Abstractions for network update. In ACM igcomm (2012). [9] VIICCHIO,., VANBEVER, L., AN REXFOR, J. weet little lies: Fake topologies for flexible routing. In ACM HotNets (2014).