Over past summer Ericsson research at San Jose, CA started a project called OpenFlow-MPLS to add MPLS support to OpenFlow. The project is now complete and available via the Project’s Page on the Openflow Wiki.

The implementation includes a user space switch, a kernel space switch and NetFPGA implementation and is based on OpenFlow v0.89.

It supports MPLS by adding two tupels to standard OpenFlow tupels, which can match on up to two top of the stack MPLS labels. The rewrite action is supported in flow table for MPLS tags, but other MPLS related actions (Push, Pop, TTL and EXP bits operations) are supported via MPLS-enabled virtual ports.

Attribution

Update:  A patch has been added as indigo-1.0-alpha-2.tgz.  This addresses a critical memory leak.

Indigo is the code name of the OpenFlow 1.0 software release for the Quanta LB4G, a 48-port Gigabit switch with 4 10 Gbps uplinks based on the Broadcom 56514.  The code targets other Broadcom devices as well, although this release supports only the LB4G.  The code is the follow-on to the Stanford-LB4G software release from last September.  Indigo differs from the previous release in several ways:

• Supports OpenFlow 1.0
• Linux user space code:  Only the minimal device drivers are installed in the kernel.  The majority of the code uses the OpenFlow udatapath implemenation.
• Hardware driver abstraction:  The code is written to a new hardware abstraction API that extends the current user space software table structure allowing easier porting to new hardware platforms.  The API header file and updated OpenFlow code is also available (see below).
• Targets other Broadcom devices including reference designs for the 56634 and 56820.

This is an alpha release and still has some known issues, but should provide a basis for experimentation.  Your feedback is strongly encouraged to help prioritize features and make this usable for OpenFlow deployments in the enterprise, data center, and wide-area network.

The initial release notes are available here.  A very preliminary hardware roadmap page is available here.

To receive access to the software or to provide feedback regarding the package, please send email to info@openflowswitch.org and include “LB4G” in the subject line.

This week Guru Parulkar and I (Guido Appenzeller) will visit the seven Universities that are part of the GENI OpenFlow Campus Trials that are taking place this year. The reason why we will spend the week mostly in planes, cars and meetings with IT folks is that we feel we don’t fully understand yet what it will take to deploy OpenFlow at these universities. It is one thing to read a proposal or listen to a 30 minute presentation at a conference, but a very different thing to actually talk to the people who will have to deploy and support the hardware and software that will run production traffic.

Unless the winter weather stops us, we will within five days visit:

• Rutgers
• Princeton
• GeorgiaTech
• Clemson
• University of Indiana (Bloomington)
• University of Wisconsin at Madison
• Washington University

We hope to post a short update from each university while we are on the road, as well as an overall summary at the end. This should be interesting. Stay tuned.

Today we are releasing version 1.0 of the OpenFlow Switch Specification as well as the OpenFlow Switch Reference Implementation. You can find it on the download page or pull it directly from the public git repository.

Unlike previous releases, OpenFlow 1.0 is the first release of the standard that we feel is ready to be implemented in generally available products. We have been running OpenFlow in our Stanford network over the past months, and it has proven itself for both production use as well as experimentation.

OpenFlow 1.0 adds a number of key features. The largest addition is Slicing, a simple QoS mechanism that allows the isolation of traffic in OpenFlow networks. Smaller changes include matching IP addresses in ARP packets, Flow Cookies to identify flows, selective port statistics and matching on the ToS bits in the IP header. The release also includes a large number of small changes to the specification and bug fixes in the reference implementation. For a complete list of changes read the Release Notes or the more detailed Wiki Page.

Hardware accelerated OpenFlow 1.0 capable switches are expected to become available over the next months and we will keep you updated on the OpenFlow Blog and the OpenFlow-Announce Mailing List. On the controller side the reference controller supports 1.0 and there is a version of NOX with partial support available. If you deploy OpenFlow 1.0, feedback and bug reports are highly welcome via Trac or the openflow-discuss mailing list.

This release would not have been possible without the work of (in alphabetical order) Guido Appenzeller, Peter Balland, Martin Casado, David Erickson, Glen Gibb, Brandon Heller, Mikio Hara, Bob Lantz, Masayoshi Kobayashi, Nick McKeown, Justin Pettit, Ben Pfaff, Rob Sherwood, Srini Seetharaman, Dan Talayco, Jean Tourrilhes, Tatsuya Yabe, KK Yap, Yiannis Yiakoumis as well as to the many other members of the OpenFlow community that provided valuable suggestions, feedback and testing.

Thanks to all of you!

Brandon, Glen and Guido

We are pleased to announce the availability of release candidates for the OpenFlow 1.0 specification and reference switch.

The release candidates are being made available to provide the community with an opportunity to provide feedback prior to the official release. We plan on making the release official by the end of year (12/31) so please provide feedback before this date. Bugs reported in the reference software may not be corrected prior to the official release depending upon their severity; we plan to make a bug fix release in the new year that will address as many bugs as possible.

New features

New features added to the 1.0 specification include:

• Slicing support (multiple queues per port with minimum bandwidth guarantees)
• Matching on IP fields inside ARP packets
• Matching on IP ToS bits
• Improved flow duration resolution in stats/expiry
• Opaque flow cookies added to flows
• Ability to retrieve port stats for individual ports
• User-specifiable datapath description added to desc stats

The updated specification also includes numerous clarifications. For a more detailed list of changes please see the release notes (http://www.openflowswitch.org/wk/index.php/OpenFlow_1.0_release_notes) and the development wiki (http://www.openflowswitch.org/wk/index.php/OpenFlow_v1.0). (more…)

As of this evening, an OpenFlow 1.0 alpha release is running in a small test network at Stanford. It is used for the production traffic for a small number of lab rats test users on the 3rd floor of the Gates CS building. Congratulations to Glen Gibb and KK Yap for bringing up the network with the reference controller and a modified version of Nox respectively. Also thanks to Masayoshi, Mikio and Brandon for their help with the build and the test network. The final OpenFlow 1.0 release is expected in the next weeks.

The video of OpenFlow Demo at GEC6 is available now. It demonstrated how to connect the OpenFlow network at Stanford to the GENI Clearing House and how to reserve a virtual slice on the network and run an experiment on it.

It is split into four parts (clicking on the links below starts the video):

• Part1: Setting up a local OpenFlow Substarte (5 min)
• Part2: Managing Aggregates and Users (2.5 min)
• Part3: Protecting your Network (2 min)
• Part4: Creating a Slice and running Experiments (7 min)

Enjoy!

There was another major demonstration of OpenFlow last week at SuperComputing 2009 conference in Portland, Oregon. It was jointly implemented with Ciena Corp.,  a major provider of communications networking equipment, software and services. This was the first demonstration of an OpenFlow implementation on a hybrid packet/circuit switch, in support of the draft experimental extensions to the OpenFlow specification for circuit switches.

As a proof of concept, we built a simple OpenFlow enabled packet and circuit switch network using carrier-class Ciena CoreDirector CI  switches. The CDs natively support the OpenFlow protocol for their packet and circuit switching fabrics. We then built an application in the OpenFlow controller that sets up, modifies and tears down packet and circuit flows on demand and dynamically responds to network congestion. Learn more about the demo in the OFC’10 invited paper on the publications page. Our larger goals and motivations are detailed here.

Thanks to Dan Getachew, Preeti Singh, Lyndon Ong, Jim Archuleta, Puneet Gupta, Ashok Kumar, Ritesh Ralhan and the rest of the Ciena development team, as well as Yiannis Yiakoumis, KK Yap, and Vinesh Gudla from the Stanford side. Thanks also to  the Ciena Marketing and Sales teams for putting together the demo booths, material  and other support — it was good to see the buzz the demo created in the Research & Educational Networks (REN) community.  Photo Gallery: SC09

We had another major demo of OpenFlow today at the GENI Engineering Conference in Salt Lake City, Utah. The demo showed the use of a GENI Clearing House to reserve a virtual network slice across OpenFlow Networks at Stanford University, across the Internet2 Backbone and at Princeton University.

It was great to see that now a small number of projects inside GENI are making progress towards becoming deployable systems. Compliments to Rob Ricci’s demo of ProtoGENI which was very well done.

The evening before the major demo at the plenary, we also exhibited at the demo session that was held in the tower of the Rice Eccles Stadium. Thanks to Rob Sherwood, Srini Seetharaman, Jad Naous,  Masayoshi Kobayahsi, Sapan Bhatia, Tony Mack, and Andy Bavier for the hard work that it took to make this happen. It was worth it!

Photo Gallery: GEC6

OpenRoads (a.k.a. OpenFlow Wireless) won the best poster at SIGCOMM this year.  This platform can be thought of as the wireless extensions of OpenFlow.  The OpenRoads platform has been developed to support our vision for the future mobile Internet (as described in a technical report “Blueprint for Introducing Innovation into the Wireless Networks we use every day“).  Our long term goal is for others to innovate in their production wireless network using OpenFlow.

The OpenRoads Team

n-casting between WiFi-WiMAX using OpenRoads is an example of our vision.  It was also part of SIGCOMM’s best demonstration.  An improved demonstration was shown in Mobicom and won honorable mention.  This demonstration has been shown in several other occasions, such as the OpenFlow workshop at Stanford.  If you have not yet seen the demonstration, a video of it is available on this website.

Now you are also able to reproduce this demonstration.  We are proud to make this demonstration available to the community.  This includes instructions for the physical setup and streaming server.  We have also made available the source code for the network controller, wireless client and visualization.  More importantly, we make OpenFlow Wireless available to public, to promote innovation in the wireless networks we use every day.

n-casting and OpenFlow Wireless are made available to you by the team pictured above, with the help of many others.