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.
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:
- J. Hamilton. Networking: The last bastion of mainframe computing.
- Jacobus Van der Merwe and Charles Kalmanek,
Network Programmability is the answer!
What was the question again?
Or, is there really a case for Network Programmability? - T.V. Lakshman. T. Nandagopal. R. Ramjee. K. Sabnani. T. Woo.
The SoftRouter Architecture - M. Ribeiro Nascimento, C. Esteve Rothenberg, M. R. Salvador and M. F. Magalhães. “QuagFlow: Partnering Quagga with OpenFlow“. To appear in ACM SIGCOMM 2010 Poster Session, Aug. 2010, New Delhi, India.
ABSTRACT
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.
Hi,
I read your paper and I am also working on openflow which is little bit related to your work I am trying to get the rib of the openflow switches. Can you please guide me how can I achieve this using openflow
Thanks in advanced.
Hi!
I am afraid there is no such a RIB in OpenFlow switches other than the flow table. You need to use the flow stats messages to pull the contents of the flow table and then derive/reconstruct the RIB as necessary. In QuagFlow we are more concerned with getting the RIB that Quagga generates and translate it into suitable OpenFlow entries. What are the goals of your OpenFlow application?
how you manage to translate the Quagg RIB into Openflow entries ? will you make it available over the Internet?
Actually, we are translating the Forwarding tables (FIB) from the linux network stack. We are not translating from the routing information (RIB) that Quagga maintains in its database (Zebra). The latter would be also possible and we may consider this future direction as it could enable new routing re-distribution and FIB generation policies (cf. new ways for interconnecting routing protocol instances: http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p219.pdf ).
The current prototype is still in alpha version but we expect to be able to share the code towards the end of the year. If you have interest in getting the code prior to the public release please contact me via e-mail (esteve @ cpqd.com.br). Thanks for your interest and feel free to contact us!
Hi,
congrats for your job on QuagFlow!
I’m a postgraduate student at UNI-RIO (Federal University of the Rio de Janeiro State), and I’m looking at the network virtualization area as a possible focus for my dissertation.
Last months I gave a deep dive into OpenFlow and got in contact with NOX, FlowVisor, some tutorials that happened in SBRC 2010 and, last week, with QuagFlow (found the poster PDF through Google Scholar).
Please, I would like to ask: do you have any public documentation about your project beyond the poster? It could be a more detailed or “under the hood” view, tutorial, anything!
My only interest is in getting into contact with the state-of-the art in the area and, maybe, searching for a interesting contribution to make.
Again, congrats and success!
Carlos.
Hi Carlos,
thanks for your comment! Your request is very timely as we are currently working out the best way to go public with the project. We still need to resolve some issues regarding license and so on.
We are really looking forward to create a community around the QuagFlow paradigm on hardware-accelerated open-source software routers. Contributions in any form will be more than welcome! We will notify you as soon as we have some news.
In the meanwhile, and as you pointed to virtualization as a possible focus for your research work, I can share with you one specific topic that deserves deeper thoughts. As today, our hypervisor-based virtualization approach naively dedicates one VM for each Quagga instance.
The VM resource requirements of Quagga are low (memory footprint and computational overhead), especially if we use a lightweight linux distribution to run only Quagga with some additional tools.
As we scale up the number of switches and Quagga instances, we need however to optimize the design of the virtualized control plane.
One area we want to explore is moving towards container-based virtualization approaches such as OpenVZ or
Linux-VServer.
The following paper provides an excellent overview of the state of the art: http://www.cs.princeton.edu/~mef/research/vserver/paper.pdf
IMO, one interesting research topic would be understanding the tradeoffs (e.g., isolation vs. efficiency) of the different virtualization approaches and make a clever design choice for the purposes of the QuagFlow virtual routing services. Let me know what you think. We can continue the conversation via E-Mail if you like.