-
Notifications
You must be signed in to change notification settings - Fork 25
Projects and ideas for RouteFlow
This is an incomplete list of potential research projects around RouteFlow.
Please do not hesitate to contact us in case of any interest or suggestions!
RouteFlow allows to translate routes calculated from Linux-based open-source routing stacks (e.g., Quagga, BIRD, XORP) into OpenFlow entries (packet flow + actions) that are installed by means of an OpenFlow controller.
As today, RouteFlow is working with OpenFlow protocol version 1.0 and supports a number of open-source OpenFlow controllers (e.g., NOX, POX, Floodlight, Ryu).
This project would involve updating the current RouteFlow application on top of an OpenFlow 1.3 capable controller (e.g., C/C++ based NOX, Python based Ryu) and develop the required code changes to use the 1.3 APIs. Furthermore, the project should explore how to get use of newly introduced features in OpenFlow 1.x, such as IPv6, multiple-table support, group tables, TTL-decrement actions, and QoS flow metering options.
Expected results A new RouteFlow Prroxy application for the OpenFlow controller of choice (Ryu preferred) will implement the calls to OpenFlow 1.3 protocol commands and handlers, allowing to transform IP routes into multi-table flow entries using group-tables as actions to store next hop routers and the associate packet-rewriting actions.
In addition, the project code should merge a related code fork from the Vanderwecken project (lead by Josh Bailey from Google NZ) to support MPLS and new APIs to the open-source Quagga routing engine.
Knowledge Prerequisite Python, C/C++, OpenFlow, IP routing protocols (e.g., OSPF, BGP), JSON/REST.
Any of these are optional but not all of them.
Skill level Medium to high.
Mentors Christian Esteve Rothenberg or Marcelo Ribeiro Nascimento
The idea consists on letting OSPF Hello messages go through the OpenFlow data plane while keeping OSPF LSA be flooded inside the virtual networking environment. Additionally, alternative topology discovery and maintenance strategies may be investigated that will trigger the connectivity updates in the virtualized control plane.
Map multiple VMs to the same physical switches, i.e., a router virtualization approach with RouteFlow. May involve exploring integration opportunities with FlowVisor. May involve a vertically distributed lookup strategy (i.e., hybrid hardware/software FIBs in spirit of Fibium).
Support Live Router Mobility (cf. VROOM)
Control Plane: Have a "stand-by" environment to take over in case of failure may of the master RF-Server / Virtualized Control Plane. May require a disitributed control plane solution and VM advanced management (e.g., VM migration, start/stop) Data Plane: Use OpenFlow 1.x Group tables to store loop-free alternative routes as ready backups for fast re-routing purposes. See sketch idea here.
Run the RouteFlow control plane in a public cloud infrastructure such as Amazon´s EC. Measure latency, performance, etc. Are IP routing protocols ready to run remotely in the cloud? The work shall evaluate suitable frameworks (e.g., OpenStack, CloudStack) to store and retrieve the RouteFlow VMs (e.g., ImageService) and all in all contribute to provision and manage large networks of virtual machines, creating a redundant and scalable cloud computing platform for RouteFlow (cf. OpenStack Compute).
Research the application/service space of RouteFlow in spirit of the 'Platform as a Service' model for networking. Think of routing-as-a-service (RaaS), IP network-as-a-service (NaaS), and other convenient abstractions to provide new, simplified, modularized management approaches. This piece of work may complement or build upon the cloud computing framework adopted for the RouteFlow in the Cloud research topic. Frameworks, processes, objetives and tools from OpenStack Network Service or CloudStack may be part of the research playground.
Study, implement and evaluate IETF Simple Virtual Aggregation (S-VA) techniques: [1] IETF RFC 6769 [2] FIB table saving technique [3] Hitesh Ballani, Paul Francis, Tuan Cao, and Jia Wang, "Making Routers Last Longer with ViAggre," USENIX NSDI 2009, April 2009.
Architecture and Implementation updates to support IPv6 and evalaution of potential IPv4/v6 migration techniques
Something like (or integratation with) Autonetkit. (See SIGCOMM´12 Poster)
Port the RouteFlow-Controller app to Trema: An Open Source modular framework for developing OpenFlow controllers in Ruby/C. http://trema.github.com/trema/
Explore Redis as native pub/sub NoSQL DB (datastructure-oriented) as alternative for MongoDB
Use Libvirt to bootup VMs (or LXC containers) in a virtualization-agnostic fashion and on-demand as switches connect to the network
OpenFlow allows management of switch forwarding tables. However, there are various configuration options on a switch that cannot be managed such as setting OpenFlow controllers, or managing virtual interfaces. In particular, we currently use the ovs-vsctl tool in the rftest scripts to configure RFVS instances. If RFServer supported OVSDB directly, this would allow RouteFlow to dynamically add and remove ports from RFVS instances (and map those to new ports on VMs) without requiring RouteFlow to be restarted.
OVSDB post (+IETF Draft): http://networkheresy.com/2012/09/15/remembering-the-management-plane/
Create a more serious and configurable version of rfweb. This includes making web tools for creating and managing the configuration on the fly.
Investigate the scalability of RouteFlow among different dimensions under real-world conditions. Experimental validation in a meso scale testbed infrastructure.
Add TTL-decrement action (if supported by the datapath devices) Multi-tables
For even smaller changes, see TODO markings in the files.
- Tests and instructions for other virtualization environments
- Let the RFServer order the RFClient to set the VM's non-administrative interfaces to the same MAC Address
- Create a verbose mode for RFServer
- Configuration arguments for RFServer, RFClient and RFProxy (partially implemented)
- Make the messages prettier in rfweb
Design and implementation of a distributed database solution to store the RouteFlow state (e.g., Network view, network state, VM state, configuration, logs, events) in spirit of the NIB in ONIX by Koponen et al. Available distributed NoSQL data stores shall be evaluated (cf. NoSQL databases).
See the "RouteFlow reality check at Euro scale" project proposal for experiment examples.
Evaluation of implementations of the RouteFlow protocol IPC with modern alternative approaches (e.g., Messagepack vs. Thrift vs. Protocol Buffers) or Messages Queues technologies (e.g., ActiveMQ or RabbitMQ or ZeroMQ). Optionally, a companion wireshark plugin could be developed.
Have multiple Open VSwitches running on separate servers while providing the virtual plane connectivity. This task should help with scaling out and improved resiliency.
Let multiple physical switches act like a single router (e.g. BGP). A single VM in the virtualized control plane with as many interfaces as out-facing ports of the OpenFlow switches (cf. "scale-out router" in ONIX). Decide on how the FIB generated by Quagga in the single VM gets distributed in the OpenFlow data plane. May involve the design of a distributed lookup approach for efficient flow space in the dataplane (distribution may be "horizontal" throughout multiple physical switches or "vertical" by going up to the VM holding the complete FIB and caching the decision in the physical switches (cf. hybrid HW/SW FIBs as in Fibium). May involve investigation of an "intra-router" forwarding/switching matrix solutions. Related previous work: Design and Implementation of a Routing Control Platform (RCP)
RouteFlow allows to translate routes calculated from Linux-based open-source routing stacks (e.g., Quagga, BIRD, XORP) into OpenFlow entries (packet flow + actions) that are installed by means of an OpenFlow controller.
As today, RouteFlow operates in a single controller setup with compromises the high availability of the control plane. In recent OpenFlow protocol versions support for multiple controllers in Master/Slave modes of operation has been specified.
This project would involve designing a new OpenFlow controller mechanism that allows to have instances taking the role of Master or Slave, and switch over in case of controller failure. Addressign other high availability issues of the RouteFlow architecture are in scope of the project.
Expected results The RouteFlow Proxy application for the OpenFlow controller of choice with OpenFlow 1.2+ support (Ryu preferred) shall make use of the OpenFlow role change commands to inform OpenFlow switches about which controller is operating in which mode.
The multiple controllers should also implement the required mechanisms to detect whether its peers are alive, and take a consistent (consensus-based) decision on whether a role change (Master->Slave) is required.
Further results that may increase the overall availability of the RouteFlow-based control plane would be welcome.
Knowledge Prerequisite Python, C/C++, OpenFlow, IP routing protocols (e.g., OSPF, BGP), JSON/REST, NoSQL databases, distributed protocols, high availability protocols.
Any of these are optional but not all of them.
Skill level Medium to high.
Mentors Christian Esteve Rothenberg or Marcos Rogerio Salvador