Final Class Project (3-to-9 month projects) :
This is an incomplete and potentially outdated list of potential research projects around the RouteFlow technology.
Complexity, duration, implementation vs. analysis requirements vary from topic to topic.
Some projects are more like a small feature implementation requiring well-planned development activities while other topics require a more in-depth research better suited for a MSc or even PhD thesis.
Please do not hesitate to contact us in case of any interest or suggestions!OPEN [Updated in March 2013!]NEW!: Check the Ideas list for the Google Summer of Code 2013
- Separating state dissemination from topology maintenance
- 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.
- Router Multiplexing
- 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).
- Router Migration:
- Support Live Router Mobility (cf. VROOM)
- Improved resiliency
- 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.
- RouteFlow in the Cloud
- 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).
- RouteFlow-as-a-Service (RaaS)
- 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.
- Simple Virtual Aggregation
- Study, implement and evaluate IETF Simple Virtual Aggregation (S-VA) techniques:
- Architecture and Implementation updates to support IPv6 and evalaution of potential IPv4/v6 migration techniques
- Auto-configuration for the virtual networking and Quagga engines.
- RouteFlow over NEC´s Trema controller platform
- Port the RouteFlow-Controller app to Trema: An Open Source modular framework for developing OpenFlow controllers in Ruby/C. http://trema.github.com/trema/
- Graphic User Interface (GUI) extensions
- Explore Redis as native pub/sub NoSQL DB (datastructure-oriented) as alternative for MongoDB
- Study MongoDB (or alternative data store) in cluster mode
- Use Libvirt to bootup VMs (or LXC containers) in a virtualization-agnostic fashion and on-demand as switches connect to the network
- Study EXA BGP as "routing engine"
- Real-world scalability
the scalability of RouteFlow among different dimensions under
real-world conditions. Experimental validation in a meso scale testbed
- Moving to OpenFlow 1.2
- Add TTL-decrement action (if supported by the datapath devices)
- LXC support
- Towards a network state database
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).
- Investigate "hooks" into Quagga's Zebra DB to reflect link up/down events
- Experiment with RouteFlow on the now open Ofelia testbed facilities (How to experiment?)
- A more expressive and performing RouteFlow IPC
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.
- A distributed virtual networking environment.
multiple Open VSwitches running on separate servers while providing the
virtual plane connectivity. This task should help with scaling out and
- RouteFlow-Controller application for Floodlight
- RouteFlow-Controller application for Ryu (1.0 and 1.2)
- Router Aggregation
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)