Views
OpenFlowHWRoadmaps
From OpenFlow Wiki
Contents |
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@openflow.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@openflow.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@openflow.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.
