BBN Technologies today announced $10.5 million in NSF funding for large-scale prototype deployments of new networking technologies (Full Press Release). It is exciting to see a first generation of GENI research move from the laboratory to live networks across the continent.
Currently negotiations for on scope and amounts for the individual projects are ongoing and nothing is final yet. That being said the current plans are for a substantial part of the funding to be used in OpenFlow deployments at a number of universities and backbone networks. Schools previously mentioned as participating include Princeton, Rutgers, Clemson, Wisconsin, Indiana, Georgia Tech and University of Washington with NLR and Internet2 connecting them. A number of networking hardware vendors have committed to providing OpenFlow enabled switches and routers for the deployments. We’ll update you on the details as they are being announced.
In the men time congratulations and thanks to Chip Elliot (pictured to the right) and his team at the GPO for having taken another major step to move the GENI vision forward.
Manuel Palacin from the University Politecnico di Torino (Italy) and the Technical University of Catalonia-UPC (Spain) recently completed a thesis on “OpenFlow Switching Performance“. The thesis presents an interesting performance evaluation of the OpenFlow reference implementation (ver 0.8.9_rev2), and compares it against that achieved by Linux Routing (ip_forwarding) and Bridging (bridge tools). Using an Agilent tester for generating packets with different MAC address, IP addresses and UDP port numbers, Manuel measured the latency and throughput achieved by the three software switching schemes.
The thesis presents performance observed by the Agilent tester, while varying the:
Packet size
Link load
Flow table entries (viz. exact match hashtable and wild card linear table)
Topology (2 input port -> 1 output ports, or 1 input port -> 1 output port)
Heterogeneity of flow size
Before each run, Manuel inserts entries to Routing (using explicit “route add”), Switching (using separate MAC learning stage), and OpenFlow (using dpctl without secchan to controller). Then, allowed the Agilent tester to forward packets over a window of 1 minute and measured the throughput/latency achieved. The summary of performance results are:
Performance difference is noticeable at high load and small packet size; Bridging is worse off than OpenFlow (which in turn is worse off than Routing for certain cases)
Hash table matching is quicker and supports more throughput, in comparison to wild card matching
OpenFlow is fairest in scheduling flows, closely followed by Routing. Bridging technology seems unfair to large flows
This thesis conducted a comprehensive test of switching performance, and provides interesting ballpark numbers for throughput and latency.
FlowVisor is a network virtualization layer built on top of OpenFlow. The FlowVisor allows a single physical network to be sliced into multiple logical OpenFlow networks, allowing researchers to run multiple OpenFlow controllers on the same set of devices. The technical report details the FlowVisor’s design and slicing mechanisms as well as an evaluation of how well the FlowVisor enforces isolation between slices.
The features described in the tech report have been included in the newly released FlowVisor version 0.4, including:
* preliminary bandwidth isolation between slices
* improved OpenFlow message rate limting for switch CPU isolation
* per-slice virtual topologies
Both the technical report and the new version are available from the FlowVisor’s webpage:
Enterprise GENI, the OpenFlow based Network Substrate that is part of the large-scale GENI effort funded is featured on the GENI home page today. GENI uses the FlowVisor with an added-on Aggregate Manager to virtualize a network. Recently at Stanford we demonstrated how to use eGENI together with PlanetLab, allowing control of both computing and network infrastructure through a single framework. For more information, have a look at the article.
NEC switches have been supporting OpenFlow since the earliest deployment on an experimental network here at Stanford. This started with prototype development in November of 2008 and a more complete deployment started in April of 2009. NEC provided the first hardware accelerated OpenFlow switch and hence arguably has one of the most mature OpenFlow implementations.
Two types of switches from the IP8800 series — the IP8800/S3640-24T2XW and the IP8800/S3640-48T2XW — are currently deployed including both 24 and 48 port GE switches, each with 2 10-gigabit ports. A total of five switches are used in the immediate OpenFlow deployment here in the Gates building on Stanford’s campus.
VLANs have been deployed on the switches to differentiate between OpenFlow and non-OpenFlow traffic. Within the OpenFlow category, both “production” and “experimental” networks are configured. The OpenFlow production network serves many researchers with normal network connectivity providing email, web and the usual network resources. The experimental networks provide segmented access to such projects as OpenPipes (PDF) and OpenRoads (PDF) with development and demos running continuously.
The NEC switches support multiple virtual OpenFlow instances to be running on a physical switch, each with its own quota of flows. The switch hardware accelerates:
Matching on the full OpenFlow 10-tuple.
The L2 MAC destination address rewrite action.
Forwarding to multiple output ports (multicasting).
The NEC switches have provided a stable platform carrying a large part of our local traffic. NEC has been very effective at ensuring that their switches support the latest OpenFlow specifications.
The OpenFlow demo “Lossless Handover with n-casting between WiFi-WiMAX on OpenRoads” won an honorable mention at MobiCom 2009 in Beijing this week. Congratulations to Kok-Kiong Yap, Te-Yuan Huang, Masayoshi Kobayashi, Michael Chan, Rob Sherwood, Guru Parulkar and Nick McKeown. This is the second award for the OpenRoads team in the past months after their Best Poster Award at SIGCOMM 2009.
The Abstract for the Poster can be found on TY’s home page and a video explaining the demo is embedded above. The video embedded below gives an overview of the technology and is also available in an HD version.
The release of OpenFlow software for the Quanta LB4G gigabit Ethernet switch provides a platform for researchers and users of OpenFlow with a low cost option for high port count, hardware accelerated, OpenFlow controlled switches. The switch provides line rate switching across 48 gigabit ports. Initial support of 4 10-gigabit ports is also provided.
This is an experimental platform for OpenFlow development and research. For a production ready, supported switch, see the Toroki Lightswitch 4810 announced here.
A PowerPC 8541 CPU running at 825 MHz powers the switch. Two independent gigabit Ethernet management interfaces are provided, directly connected to the CPU for out-of-band management and control.
The hardware supports between 1000 and 2000 flows in hardware depending on usage. Once installed, traffic matching flows will be forwarded by hardware at line rate.
The software is based on OpenFlow 0.8.9r2 with support for OpenFlow 0.9 under development. The distribution includes the u-boot boot loader, a Linux kernel image (2.6.15) and the kernel modules necessary to bring up and run the hardware as an OpenFlow switch. Basic OS functionality is provided by the popular BusyBox utilities. Configuration and user applications may be saved to the flash file system to be restored across reboot.
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.
Let us know what features you’d like to see added to the LB4G software package.
Yan Luo, Pablo Cascon, Eric Murray and Julio Ortega (photos of the team to the left) have implemented OpenFlow for the Netronome NFE-i8000 Network Processor Card. The joint project between the University of Massachusetts at Lowell and the University of Granada, Spain is not only adds another platform to OpenFlow, it can also claim the title as the first port of OpenFlow on a network processor card. Right now their implementation is limited to exact matches and only tested with the reference controller, but according to Prof. Luo the team is working on wild card matches as well.
The Netronome NFE-i8000 card is a PCI Express card that fits into a PC and includes 4x 1Gb/s SFP port, a 16-core IXP2855 Netowork Processor, 768MB RDRAM for packet buffering and 40MB SRAM for flow table operations. One feature that makes this hardware stand out is that it accomodates up to 250k flow table entries. Read below for details on the implementation.
For the actual implementation, Professor Luo wrote:
“We developed the OpenFlow-NP software on both the host side and the NIC side. On the host side, we implemented the software based on OpenFlow specification release 0.8.9~2. The OpenFlow software communicates with the NIC card through a kernel module called “hwtable_nfei8k_mod”. This module functions in the similar way as hwtable_nf2_mod to support the passing of OpenFlow commands from the host to the NP, and the values of statistical counters from the NP to the host. The NIC side software maintains a flow table in the SRAM of the card. The NP on the NIC writes new flow table entries/actions and clears out existing entries/actions. These operations are triggered by the OpenFlow switching software (i.e. secchan) upon receiving new flows or detecting expired flows. Incoming packets are switched immediately at the NIC level by the NP if they belong to a known flow and the NP finds a matched entry in the flow table, leading to faster switching performance. Experiment data show that the packet delay can be reduced by up to 20% compared to a dumb NIC based reference design. The current release of OpenFlow-NP (v0.8) handles only extact flow entries while the wildcard entries are under development. The flow statistics are not fully supported in this release.”
More details of the OpenFlow-NP project and source code are available on the Project Page.
Professor Aditya Akella at the University of Wisconsin-Madison is teaching an advanced graduate level class on rethinking the internet architecture that makes heavy use of OpenFlow. A major part of the class is practical experimentation with OpenFlow. Specifically students will write NOX modules that implement new protocols which can then be run on the OpenFlow topology that he has set up. Some of the OpenFlow nodes in the topology are NetFPGA cards, thus it is additionally possible to try out new forwarding hardware. For more information have a look at the class home page and the reading list.
BBN Technologies today announced $10.5 million in NSF funding for large-scale prototype deployments of new networking technologies (Full Press Release). It is exciting to see a first generation of GENI research move from the laboratory to live networks across the continent.
Yan Luo