OpenFlow 0.9.0 RC1 has been released as 0.9 preview release. The package is available on the downloads page, and the corresponding spec is on the OpenFlow Wiki. NetFPGA is not yet supported for this release, but will be soon.

OpenFlow was mentioned in an article titled “Building a crash-proof internet” which recently appeared in the NewScientist magazine (pp.38-41, no. 2714, June 2009). It described the motivations for building large-scale, programmable, realistic testbed as well as the NSF’s GENI project. OpenFlow is introduced as a practical platform to accelerate this effort.

The article is online here.

When developing applications using OpenFlow, a small network of OpenFlow switches is often needed for testing and debugging. Using a simulated network for such development would be ideal, allowing more people to develop efficiently at their own pace. The ”OpenFlow Virtual Machine Simulation” (OpenFlowVMS) package is developed to create that virtual simulated network in your very own desktop/laptop.

OpenFlowVMS is a set of Python scripts that create that virtual simulated network automatically, letting developers concentrate on their real tasks and not fight the details of setting up a testbed.  The original version of this tool is developed by Ben and the folks at Nicira.  This version is a near complete rewrite using Python and XML for configuration.  Part of this tool is developed with support of DoCoMo USA Labs.  You can get the package and updates from

http://www.openflowswitch.org/wk/index.php/OpenFlowVMS.

Hope you will enjoy having your very own OpenFlow network(s).

We are delighted to announce that the OpenFlow team has had three demonstration proposals and a poster accepted at SIGCOMM 2009. Be sure to stop by our booth to learn more about the potential of OpenFlow.

• OpenPipes: A modular pipeline, built using OpenFlow, that allows functional modules to be moved around in the network, from one subsystem to another, while the system is running.
  
• Flowvisor:  A special purpose OpenFlow controller that allows multiple researchers to run experiments safely and independently on the same production OpenFlow network.
• Plug-n-Serve: A server-load-balancer, built from commodity components, that tries to minimize response time by controlling the load on the network and the servers using customized flow routing.
• OpenRoads(poster): A framework for OpenFlow-enabled wireless mobility research.

OpenFlow, I believe, provides an easy way to use actual switching/routing devices in an academic setting. There seem to be a few universities that are teaching OpenFlow in a lecture or are using OpenFlow for their course projects. Following is a quick list that I generated to appease my curiosity. If I missed your university, please send us a mail.

Georgia Tech, Spring 2009
CS 4255/6255: Network Management
Instructor: Russ Clark
What? Project + Lecture

Columbia University, Spring 2009
CSEE W4140: Networking Laboratory
Instructor: Jong Yul Kim
What? Project

U Toronto, Fall 2008
CSC 2203: Packet Switch and Network Architectures
Instructor: Yashar Ganjali
What? Lecture

Seoul National University, Fall 2008
Topics in Internet  (4541.774)
Instructor: Yanghee Choi
What? Lecture

FlowVisor is a special purpose controller that allows multiple researchers to concurrently manage the same OpenFlow-enabled network. If we say a network slice is a collection of physical resources and classes of traffics, then FlowVisor is the logic that manages resource allocation among slices and enforces isolation between them. Thus using FlowVisor, research and production traffic can safely co-exist on the same underlying hardware.

We believe that FlowVisor will be an important component on the path of enabling research in your network.

For more information about FlowVisor or to download the code and try it yourself, please go to:

http://www.openflowswitch.org/wk/index.php/FlowVisor

As anyone following the openflow-spec mailing list will have noticed, we are in the process of narrowing down the feature set for OpenFlow 0.9. The latest iteration of the feature list is now on the OpenFlow 0.9 wiki page. This is not final yet, and will change. Also none of this is in the publicly available reference implementation as of today.

Over the next weeks we will add these features to the reference implementation as well as controllers. We will also talk to some of our partners to understand the implications for their implementations. This will likely result in changes. If you have any feedback, please joint the discussion on openflow-spec.

Yesterday, I announced a new OpenFlow debugging tool: liboftrace.  oftrace is a library for parsing and analyzing openflow messages (as defined in openflow.h) from a network dump, i.e., from tcpdump or wireshark.  I imagine (hope? that people will find their own uses for this, but the two initial motivating applications for this library are:

ofstats: a program which calculates the controller processing delay, i.e., the difference in time between a packet_in message and the corresponding packet_out or flow_mod message.

and

ofdump: a program that simply lists openflow message types with timestamps by switch/controller pair.

liboftrace is a C library with a swig (www.swig.org) wrapper that allows it to be used from your favorite scripting language.  Both ofstats and ofdump applications have been ported to python (pyofdump.py and pyofstats.py) and are included in the tarball as examples.

More description and the actual code are available at:

http://www.openflowswitch.org/wk/index.php/Liboftrace

If (when) you find bugs, please post them to our bug tracking system at :

http://www.openflowswitch.org/bugs/oftrace

Dan Talayco

Up to now, the OpenFlow group at Stanford has provided reference implementations of OpenFlow for two different platforms, the software switch (which runs on any PC with several network interfaces) and the NetFPGA implementation. The challenge with this is that both of these implementations have a low total bandwidht (< 10 Gb/s) and typically low fan out (< 10 ports). With these limitations, some future OpenFlow features such as QoS are hard to test in a realistic way.

To address this problem, we have recently started an effort to develop an OpenFlow reference implementation that runs on a hardware switch. Our goal here is not to compete with the production quality implementations from NEC and HP, but to create a research platform for ourselves and other universities to test out experimental features.

The person spearheading this effort is our newest team member, Dan Talayco. Dan has a background in developing software for switches from his work at Broadcom, and in an earlier life was a faculty at Franklin and Marshall college. Expect to see more from him on this blog in the next few months.

Welcome Dan!

Tatsuya Yabe

Mikio Hara

The OpenFlow team at Stanford has two new members. We are extremely happy to welcome Mikio Hara and Tatsuya Yabe from NEC Japan that will spend the next two years in the Clean Slate lab working on OpenFlow and the next generation networking infrastructure.

Mikio and Tatsuya already joined late last year, and Tatusya has already taken over the NetFPGA port of OpenFlow and recently led the release of  the OpenFlow 0.8.9(r2).

Mikio is taking over the next release of the OpenFlow software reference implementation. Welcome Mikio and Tatsuya!