This article is an editorial note submitted to CCR. It has NOT been peer reviewed. Authors take full responsibility for this article’s technical content. Comments can be posted through CCR Online. This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too.

Network operation is inherently complex because it consists of many functions such as routing, firewalling, VPN provisioning, traffic load-balancing, network maintenance, etc. To cope with this, network designers have created modular components to handle each function. Unfortunately, in reality, unavoidable dependencies exist between some of the components and they may interact accidentally. At the same time, some policies are realized by compositions of different components, but the methods of composition are ad hoc and fragile. In other words, there is no single mechanism for systematically governing the interactions between the various components. To address these problems, we propose a clean-late system called Maestro. Maestro is an “operating system ” that orchestrates the network control applications that govern the behavior of a network, and directly controls the underlying network devices. Maestro provides abstractions for the modular implementation of network control applications, and is the first system to address the fundamental problems originating from the concurrent operations of network control applications, namely communication between applications, scheduling of application executions, feedback management, concurrency management, and network state transition management. As the