Archive for July, 2010

At CPqD and together with the University of Campinas, we are working on a line of research that tries to marry open source routing software (Quagga) with programmable switches (OpenFlow).

OpenFlow is an initiative lead by Stanford University to open up networking devices (switches, routers, access points, base stations) by defining a standard protocol to define the packet forwarding actions. The main abstraction consists of a flow — though the flow table abstraction is still subject to refinements to best expose actual hardware resources — basically formed by any combination among a dozen pieces of information forming the context (i.e., packet header fields up to the transport layer plus incoming port) of a packet to be handled by a device.
You can find more details reading the current specification or the multiple academic papers on OpenFlow. Or even better, put your hands on OpenFlow by following this tutorial (recently held by Stanford people in the major distributed systems Brazilian conference).

OpenFlow is certainly not the first approach to enable some degree of network programmability — the so sought holly grail of network infrastructure providers. Related work can be dated back to the 90´s and the efforts in programming telecommunication networks, the OPENSIG community, IEEE 1520, MPOA (Multi-protocol over ATM), GSMP (General Switch Management Protocol) RFC3292, the active network research thread, and more recently work being done at IETF forces WG (Forwarding and Control Element Separation).

While the motivation behind all this body of work is more or less the same (enabling new features, lowering costs, new revenue streams, etc.). To my understanding, the fundamental difference of the OpenFlow approach is its pragmatism. OpenFlow does not aim at trying to satisfy everybody´s needs and a pragmatic way starts by trying to re-use existing hardware capabilities (e.g, ACL in switches and routers) and defining a simple set of matching rules and associated actions (e.g., forward, discard, send to controller, re-write header XYZ). This way, OpenFlow could be enabled on existing hardware by means of a firmware update. And more importantly, industry attention has been attracted and we can already buy OpenFlow-enabled equipment and prototypes from big players like Cisco, HP, NEC, Extreme, and Juniper are on their way to the product line.

We have called our work QuagFlow and will be presented as a poster in this year´s SIGCOMM edition in New Delhi. See a preview below.

QuagFlow Sigcomm poster quagga openflow

Now that we are progressing with our vision and implementation of QuagFlow, along more literature research, we regret not having cited in our poster version the work by Lakshman et al. at Bell/Lucent on the SoftRouter Architecture. We are coming to a design close to what the SoftRouter has been pursuing on separating control software from routers. Their approach is based on the ForCES protocol vs our OpenFlow interface. Its unclear to me how far their prototypical work has gone along these years. Would like very much to know, especially as we should expect to face a set of similar challenges along our journey.

Further Reading:


Computing history has shown that open, multi-layer hardware and software stacks encourage innovation and bringcosts down. Only recently this trend is meeting the net-working world with the availability of entire open source net-working stacks being closer than ever. Towards this goal, weare working on QuagFlow, a transparent interplay between the popular Quagga open source routing suite and the lowlevel vendor-independent OpenFlow interface. QuagFlow isa distributed system implemented as a NOX controller ap-plication and a series of slave daemons running along thevirtual machines hosting the Quagga routing instances.

Read Full Post »