RouteFlow –Replacing the Cisco and Juniper Routers in your Network?

We caught up with Christian Esteve Rothenberg of CPqD and RouteFlow fame last week right before he left Brazil for Europe to attend the HotSDN 2012 SIGCOMM workshop in Finland, and to take a well-deserved vacation in his native Spain. The RouteFlow project is highly respected within the SDN community and offers a glimpse into an SDN future where Cisco and Juniper routers could lose their dominance.

SDNCentral: What do you think of the Nicira acquisition by VMware?

Christian: I think it’s a nice match, and makes a lot of sense. VMware plus a network virtualization platform provides an end-to-end solution, essentially an OTT (over-the-top) datacenter. This is not unlike the OTT video trend in the cable and carrier-world. In this case, the top is the software layer and the bottom is servers and other hardware. It’s a smart move for VMware; after all, the Nicira team was already working with VMware’s virtual switch and cloud infrastructure (and OpenStack of course). And it’s a great financial outcome for the Nicira team–congratulations to Martin, Scott and Nick!

SDNCentral: I also see that last week your team at CPqD released an OpenFlow 1.2 Toolkit with Ericsson in Brazil. What’s that about?

Christian: Well, we recognize that in order to get the community moving ahead with the latest versions of OpenFlow, we need to help provide the environment. The goal of this toolkit is to make it really simple to experiment with version 1.2 of the protocol. We’ve packaged a controller, a soft-switch simulation environment, debugging tools and test harness, all in a convenient VM. Specifically, you get a software switch, an updated NOX controller, wireshark plug-in, and updated OFTest cases. What you can architect and simulate with this is incredible—five years ago, we wouldn’t even dream of having reasonable scale network simulations within a VM. The next step is to get version 1.3 going and we expected that in 2-3 months.[Ed.’s note: see the end of this interview for links to downloads].

SDNCentral: For some of our readers who might not be familiar with RouteFlow, can you provide a short description of the project?

Christian: RouteFlow is about bringing together IP routing protocols and OpenFlow networks. It is simple yet powerful idea, mainly, to run IP routing protocols (e.g., BGP, OSPF, IS-IS) on centralized platforms that provide the control plane of OpenFlow-enabled forwarding devices. RouteFlow is all Apache-licensed and consists of three main software components: one that sits on OpenFlow controllers (RF-Proxy), one that runs along any Linux-based routing engine (RF-Client), and another one that runs standalone defining the IP to OpenFlow mapping service. Altogether, RouteFlow acts as an indirection layer for routing protocol messages and allows to control the actual IP forwarding state via the RIB-(to-FIB)-to-OpenFlow process.

The RouteFlow project serves two main goals: The first one is allowing a deployable migration path to SDN offering a controller-centric hybrid networking approach. The second one is providing a platform for innovation around IP routing and forwarding. RouteFlow proposes a cost-effective routing architecture that combines the flexibility of software and open source routing protocols with the line-rate performance of OpenFlow hardware.

SDNCentral: Who is CPqD and what is CPqD’s role in the project?

Christian:CPqD is an independent institution focusing on innovating Information and Communication Technologies (ICT). With headquarters in Campinas, a Silicon Valley-like region in the state of Sao Paulo, Brazil, the solutions provided by CPqD are used by several organizations and entities in the telecommunication, energy, finance, and other industries, in both corporate and government sectors. Having worked in the market for over 35 years, it relies on more than 1,300 highly creative and skilled professionals dedicated to achieving high levels of quality. Today, CPqD has the largest and most important R&D program in Latin America striving to make the country more competitive and advance digital inclusion, supplying the market with product technologies, mission-critical systems, technological services, and consulting services.

If you allow me for a comparison with the US scenario, CPqD can be presented as the Bell Labs of AT&T, after privatization. CPqD  was the R&D unit spun-off from Brazil’s former  state telecommunications system Telebrás.

Our team at CPqD gave birth to RouteFlow and is currently the main developer and maintainer of the open source project.

SDNCentral: Who else is involved in this project and how many active contributors are there?

Christian: The community around RouteFlow has been growing steadily and counts with contributions from universities in Brazil [University of Campinas (Unicamp), Universidade Federal do Estado do Rio de Janeiro (UniRio), University of Sao Carlos (Ufscar)] and in the US (Indiana University). Matt Davy and Chris Small from Indiana were among the first users seeing value in RouteFlow. They have contributed with new UI extensions and their hand-on experiences on OpenFlow hardware testbeds. We are also collaborating with NTT MCL around the potential applications of RouteFlow-like architectures for service providers, mainly around BGP routing services. We received also code contributions (e.g., an SNMP plugin) from Google, with whom we are also collaborating together with ISC´s Open Source Routing (OSR) towards an open source label router that will bring MPLS label distribution and forwarding capabilities to OpenFlow 1.2 networks via the RouteFlow orchestration layer.

We have seen remarkable user interest in the github repositories, the mailing lists and the project web page activity, with over 7000 unique visitors coming from more than 1500 different cities from 100+ countries.

SDNCentral: Why was the project started?

Christian: The roots of the project are back in early 2010 in the context of the MSc thesis studies of my colleague Marcelo Ribeiro. Marcelo was working on a L2/L3 switch prototype (using merchant silicon and Quagga) for our industrial partner Padtec.  Our network technology evolution manager Marcos Salvador and myself suggested Marcelo to bear his MSc topic towards trying to remove the Quagga routing protocol stack from the switch itself to a remote server that would interact with the switch via OpenFlow. A few months later, the first working prototype was successfully controlling the OpenFlow-enabled NetFPGAs of our lab. This first design was baptized as QuagFlow and was presented as a poster at SIGCOMM 2010 in New Delhi. The interest grew and the project was further incubated within the advanced control plane research agenda of the Project GIGA at CPqD. In May 2011, RouteFlow was officially launched as an open source project… and, in June 2012, Marcelo finally defended his MSc thesis at University of Campinas, advised by Prof. Maurício Magalhães and myself.

SDNCentral: What are the long term goals of the project?

Christian: So far, the project has “only” achieved putting together the basic platform that allows gluing together virtualized IP routing engines and OpenFlow-enabled gear. You can turn your collection of OpenFlow equipments into a routed network. While it may be an attractive proposition in terms of cost/performance, the RouteFlow project aims at bringing more value than replicating at a fraction of the cost what you can do today with traditional IP networks. We believe that the project may evolve and adopt different forms depending on the use case and network domain under consideration, e.g., home networks, access networks, service provider edge, data centers, etc.  We expect specific services to be built on top the basic RouteFlow infrastructure, for instance, to perform new security functions, ease network management, customized path selection, etc.

SDNCentral: Do you envision RouteFlow being able to command a datacenter’s worth of switches – 100s or more and act as if it’s one big AS? Or will it be a more distributed model, with each VM calculating the routes of an attached switch (physical or virtual) and updating the effective “FIB” of the switch?

Christian: In spirit of SDN, we expect RouteFlow to allow for new network abstractions that ease the hazards of network management, for instance, providing a single router abstraction when convenient. Keller and Rexford have referred to this vision as the ’Platform as a Service’ model for networking. Our initial focus was on the viability of the 1:1 mapping of VMs to physical switches. More recently, we have started to play with new mappings such as N:1, where a number of OpenFlow switches are aggregated into a single routing instance. This was the MSc topic of Carlos Correa at UniRio, who, advised by Professor Lucena and myself, was able to proof the concept of an AS-wide abstract BGP routing service, where a single VM closes the eBGP sessions with legacy neighboring routers and RouteFlow correctly distribute the FIBs along the OpenFlow edge switches, effectively separating EGP from the intra-domain forwarding strategy, which could be for instance 100% SDN.

SDNCentral: What’s the role of routing in a big SDN network?

Christian: We are seeing SDNs of multiple kinds being announced. However, what we rarely see are the answers to how SDN islands shall interact with the legacy routing elements and networks as a whole. While you can redefine routing at your will in your own domain with SDN, at the end of the day, you will need to attract IP traffic to (and correctly sent out of) your SDN deployment. Hence, some hybrid networking approach is called for, that is, some way of interconnecting both control and data planes of legacy and SDN elements. RouteFlow proposes a way to offer flexible legacy IP routing logic in the controller domain, others are offering hybrid switches that run both OpenFlow and  legacy control planes, the seamless blending together is still however largely to be investigated.

SDNCentral: Is running Quagga or whatever open source routing stack on the host the right answer? Or do you envision creating a more customized routing stack that is geared towards SDNs?

Christian: We believe that open source is the right answer, be it Quagga, XORP, Bird, or whatever proven routing protocol stack is available. Note however that the software architecture of such routing protocol stacks was thought for traditional device-centric deployments, some of them with limited available CPUs. While Quagga has been shown to work well in many production environments, I would not say that it is ready for prime time for every large scale SDN attempt. The folks of Open Source Routing are working on re-architecting Quagga towards  a high quality code base. However, rethinking the infrastructure of a routing stack like Quagga in the light of SDN is still an open research question.

SDNCentral: Were you all involved in Google’s big WAN SDN router/switch project? What do you think of it?

Christian: We were not involved in Google´s WAN project. Google has shown through a real-world example that SDN can scale to the WAN. Google´s approach to SDN is itself an example and an exception at the same time, since Google is almost unique in terms of budget, economies of scale, and, may be more important, engineering and software development capacity.

Their architecture is similar to RouteFlow in that it re-uses Quagga routing protocols running in centralized servers with the route computation results being installed as OpenFlow entries in their own developed networking equipment. The routing process is augmented with network-wide traffic engineering capabilities running in high-performance clusters. Altogether they are capable of running their inter-datacenter WAN in levels of utilization never seen before.

While we know that they have been playing with RouteFlow, my guess is that both projects are contemporary but independent efforts in evolving the routing landscape with OpenFlow/SDN. Their ability and motivation to develop their own glue between Quagga and OpenFlow is out of question.

SDNCentral: What help or participation are you looking for from the community? How can they get involved?

Christian: We embrace any type of contributions from the community, from bug reports and fixes to more advanced features in both the core RouteFlow platform and the services that could be defined on top of it. The amount of hours that the users collectively put into trying out the software with different OS versions and OpenFlow environments are of tremendous value. On the research side we welcome for instance new ideas around BGP security, OAM extensions, and the general problem of high availability in controller-based networks. On the production side we would like to engage new pilots with real traffic and requirements of larger-scale production networks. We would like experienced network administrations to contribute to a wish list with their top IP configuration and management headaches, so that the RouteFlow community can come up with new automation tools and user interfaces that change the status quo.

SDNCentral: Congratulations for the RouteFlow paper being accepted into HotSDN, can you tell us what you’re expecting from the event? 

Christian: We are glad that our paper on RouteFlow made it to exclusive list of accepted papers in the HotSDN workshop, to be hosted during this year´s SIGCOMM conference, the tier-1 academic event of the networking community. HotSDN will gather visionaries and practitioners of OpenFlow in particular and SDN in general. From the technical program we shall expect advances not only in the design of controllers and switches but also in programming and debugging SDN environments, fundamental pieces of work to deliver the SDN promises. In addition to the state of the art discussions, participating in such cutting edge events is paramount to get involved with the community, engage new users, and devise new opportunities for collaborations.

SDNCentral: So what specific other papers are you interested in?

Christian: Other papers of interest to me are those in the track on programmability and verifying configurations.. These are definitely reusable pieces of work in any OpenFlow development that can help with better state and consistency management. On the controller and switch side, I’m looking forward to learning more about research into ASIC and counter issues. I realize that some of these are narrow areas of research, but they are definitely important. Other items of interest include the controller placement paper and slice abstraction, as well as IBM’s research on graph theory primitives. Of course, I’ll be looking forward to Nicira’s paper on Fabric—I’m sure it’ll be interesting.

SDNCentral: Thank you for your time, Christian! And wishing you the best at HotSDN and a good summer vacation!

- Official project site:  http://go.cpqd.com.br/routeflow

- Github repository:  https://github.com/CPqD/RouteFlow/

OpenFlow 1.2 Toolkit Resources

Checkout more SDN Interviews:

• Featured Interview: Radware CTO, Avi Chesla, Discusses SDN Strategy in Application Delivery And Security
• Featured Interview: Deep-Dive into Juniper’s SDN Controller and Strategy with Ankur Singla, Former CEO of Contrail
• Exclusive Interview: Yukio Ito Of NTT Communications on SDN Benefits
• What’s New at ON.Lab? An Open Conversation with Guru Parulkar, Bill Snow And Larry Peterson
• Join SDNCentral’s First Fireside Chat Where We Talk SDN with Arista
• Featured Interview with Nuage Networks CEO Sunil Khandekar
• Breaking News: Alcatel-Lucent’s SDN Spinout Nuage Launches
• Exclusive Interview: Toshiya Asaba, CEO of Stratosphere, SDN JV Spinout from IIJ and ACCESS
• Featured Interview: Behind the Scenes at the Open Networking Summit (ONS)
• Featured Interview: SDN Startup Plexxi’s CEO, David Husak

About the Author

.

Roy Chua

Entrepreneurial marketing executive with 20+ years of experience in enterprise SaaS, cloud computing… More

Connect with the AuthorWebsiteLinkedInTwitterGoogle+