Carving Research Slices Out of Your Production Networks with OpenFlow Rob Sherwood, Michael Chan,Glen Gibb, Nikhil Handigol,Te-Yuan Huang,Peyman Kazemian, Masayoshi Kobayashi, David Underhill, Kok-Kiong Yap, Guido Appenzeller, and Nick McKeown Deutsche Telekom Inc. R&D Lab, Stanford University, NEC System Platforms Research Labs 1. SLICED PROGRAMMABLE NETWORKS OpenFlow [4] has been demonstrated as a way for researchers to run networking experiments in their production network. Last year, we demonstrated how an OpenFlow controller running on NOX [3] could move VMs seamlessly around an OpenFlow network [1]. While OpenFlow has potential [2] to open control of the network, only one researcher can innovate on the network at a time. What is required is a way to divide, or slice, network resources so that researchers and network administrators can use them in parallel. Network slicing implies that actions in one slice do not negatively affect other slices, even if they share the same underlying phys- ical hardware. A common network slicing technique is VLANs. With VLANs, the administrator partitions the network by switch port and all traffic is mapped to a VLAN by input port or explicit tag. This coarse-grained type of network slicing complicates more interesting experiments such as IP mobility or wireless handover. Here, we demonstrate FlowVisor, a special purpose OpenFlow controller that allows multiple researchers to run experiments safely and independently on the same production OpenFlow network. To motivate FlowVisor’s flexibility, we demonstrate four network slices running in parallel: one slice for the production network and three slices running experimental code (Figure 1). Our demonstration runs on real network hardware deployed on our production net- work 1 at Stanford and a wide-area test-bed with a mix of wired and wireless technologies. Categories and Subject Descriptors: C.2.2 – Computer Systems Organization [Computer-Communication Networks]: Network Architecture and Design; C.4 – Computer Systems Organization [Performance of Systems] General Terms: Management, Design, Experimentation Keywords: Flowvisor, OpenFlow, Architecture, Virtual networks, Network slic- ing 2. FLOWVISOR ARCHITECTURE Architecturally, FlowVisor acts as a transparent proxy. Network devices generate OpenFlow protocol messages, which go to the FlowVisor and are then routed by network slice to the appropri- ate researcher(s) (Figure 1). OpenFlow messages from researcher controllers are vetted by the FlowVisor to ensure that the isolation between slices is maintained before being forwarded to switches. 1 That is, the network where the authors read their daily mail, surf the web, etc. Figure 1: FlowVisor allows multiple researchers to operate in parallel on slices of an OpenFlow network. FlowVisor acts as a transparent proxy between network devices, OpenFlow con- trollers, and other FlowVisor’s. Thus, the FlowVisor appears as a virtual controller to the switches and as a network of virtual switches to the researcher controllers. FlowVisor is intentionally architecturally neutral: it makes no assumption about the function or operation of the switches or con- trollers, save that they speak OpenFlow. We architect FlowVisor as a transparent proxy for three reasons: Centralized policy enforcement All control traffic, from switch to controller and from controller to switch, traverses the FlowVi- sor. This provides FlowVisor a complete view of the net- work’s state and allows it to enforce policy by dropping or rewriting OpenFlow control messages. Additionally, central- izing policy decisions makes it easier to reason about the set of allowable actions and debug errors should they occur. Recursive delegation Recursive delegation is the ability to re-delegate control of a subset of a network slice. Because FlowVisor acts as a transparent proxy, it is possible to cascade FlowVi- sor instances, making recursive delegation trivial. We ex- pect recursive delegation will be an important property for virtual networks as it eases network administration overhead and improves resource allocation. Decouple control and virtualization technologies Rather than build- ing virtualization support directly into the OpenFlow proto- col itself, we intentionally keep the control and virtualization