From OpenFlow Wiki

Introduction

This page describes current and planned hardware and software support for OpenFlow Switching on various platforms. In particular, this page provides information about platforms such as ports to OEM or vendor reference platforms that may not be available through typical commercial channels. These platforms may be made available to individuals or research/educational institutions for development and experimentation.

Safe Harbor Disclaimer

Last updated: 1/11/10

Forgive the disclaimer:

This webpage includes forward looking statements related to availability and capabilities of various products. These forward-looking statements are subject to uncertainties and risks that could cause actual availability and capabilities to vary substantially from what is indicated here. No implied or expressed warranty is provided regarding these statements.

Additions to This Page

If you wish to have your OpenFlow Switching hardware support described on this page, please send email to info@openflowswitch.org.

Broadcom OpenFlow Hardware Support

Platforms Addressed

Quanta LB4G

56514 based 48 GE + 4 XE platform with two management ports and one serial port.

Broadcom 56634 Reference Design

56634_A0 and B0 based 49 GE + 4 XE platform with two management ports and one serial port. Note that there may be limitations in the accessibility of both GE and XE ports as OpenFlow ports.

Broadcom 56820 Reference Design

56820_A0 24 XE + 4 GE platform with two management ports and one serial port.

Kernel Implementation

This was the original development for OpenFlow Switching on Broadcom based designs. A binary release was made in September of 2009. It supported OpenFlow 0.8.9r2.

Current Status

Binary release from 9/09 is available by request to info at openflowswitch.org.

Forward Plans

Although the kernel implementation code continues to exist in the Indigo release (see below) development is not currently active on this part of the project. Future development will depend on the evaluation of performance of the user space code in the Indigo release.

Indigo: User Space Implementation

This is a user space implementation based on OpenFlow 1.0 and supporting the LB4G and the 56634 and 56820 reference designs. Only minimal device drivers are inserted as kernel modules; all other functionality is implemented in user space.

While the environment maintains the kernel space code, it is not functional as of this time (1/11/10).

Current Status

A draft of the release notes is available here: Indigo Release Notes

Under development and verification. The code is currently being validated on the LB4G and 56634 platforms. Features currently under test include:

• Exact and wildcard matching on ingress port numbers
• Exact and wildcard matching on all OpenFlow 1.0 packet fields (see Table 2 on page 3 in the 1.0 Spec) EXCEPT:
  • Not currently matching IP TOS field
  • Not currenlty matching on the IP address in ARP packets
• Single and multiple output actions
• VLAN rewrite
• VLAN priority code point rewrite
• Slicing (enqueue action) (8 queues)

An alpha version of the code should be available in the beginning of February, 2010. Please send email to info at openflowswitch.org with a request for access.

Forward Plans

Expected source release date to approved parties (under Broadcom NDA): Available

Expected binary release date: February 18, 2010 for LB4G

Planned Feature Support

• Match IP address in ARP packets (date TBD)
• Support source and/or destination MAC address rewrite (date TBD)
• Support of 56634 and 56820 reference designs
• Provide binary library so users can build their own OpenFlow code to be linked with the hardware driver.

OpenFlow Hardware API

For the Indigo software development, a hardware API has been developed and integrated with the user datapath (openflow/udatapath). The header file for this API is available here: OpenFlow Switching hardware API header file. This API extends the udatapath software table object.

HAL Development

Currently, there is a discussion to define a Hardware Abstraction Layer. There are two approaches to this (with interpolation in between):

• Define a layer which is comprehensive to provide a full abstraction of a switch which supports OpenFlow in a "hybrid" environment.
• Define a minimal abstraction which covers the OpenFlow Switching protocol only.

The development began (see the header file mentioned above) in the context of adding hardware support to the existing software switch implementations. As a result, it focused on the second approach.

The current development derives from an implementation involving Open vSwitch in a hybrid environment and so focuses on the first approach.

Here are some thoughts about hardware abstractions for OpenFlow Switching deployments.