SLICED PROGRAMMABLE NETWORKSOpenFlow [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 physical 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 network 1 at Stanford and a wide-area test-bed with a mix of wired and wireless technologies.

We present BeHop, a wireless testbed for dense WiFi networks often seen in residential and enterprise settings. BeHop aims to provide insights on the operation of dense deployments, and evaluate how different WiFi management strategies affect user experience and network behavior. It has sufficient flexibility to let us try different management techniques and setups (e.g. residential or enterprise, client or infrastructure-driven operation). It is deployed at a university dorm, where it acts as the main network for a diverse set of users and devices, exposing practical insights and implications on the operation of the network. In this paper we discuss the design and implementation of BeHop, and share our early experience over a five-month period.We want to control how the wireless channel is used: Our testbed should let us centrally control the power and channel of each AP. It should also let us control which AP serves a client on a per-client basis. This lets us try out, and compare, a number of different control strategies: channel and power allocation algorithms, load-balancing algorithms, client-driven association versus infrastructure-selected association, and 5GHz band-steering.We want the testbed to be real-world deployable: Our testbed should carry the traffic of real users, running any application they choose on any of their WiFiconnected devices (laptops, phones, tablets, DVRs, etc). This will let us evaluate our strategies and reveal their implications in a real setup. Furthermore, we want to eliminate (or at least minimize) the overhead for users to join the testbed. When our testbed

No abstract

DescriptionAn open platform called the NetFPGA has been developed at Stanford University. The NetFPGA platform enables researchers and instructors to build high-speed, hardware-accelerated networking systems. The platform can be used in the classroom to teach students how to build Ethernet switches and Internet Prototcol (IP) routers using hardware rather than software. The platform can be used by researchers to prototype advanced services for next-generation networks.15th IEEE Symposium on High-Performance Interconnects Unrecognized Copyright Information