The OFELIA project ended in October 2013 after three years of work on building a pan-European OpenFlow-based test bed. During this period we witnessed no less than a revolution in communication networks. What used to be a research idea – separating control and data planes in the internet – is now one of the hottest developments for data centres, and increasingly as well for carrier networks. Software-defined networks (SDN) are currently the dominating research area for data centres, but not much is being done outside of this because of the diversity and complexity of managing such networks.
What sparked the OpenFlow solution was the attempt to create a standardised interface between networking hardware and the operating system needed to configure and control it. OpenFlow was developed within the Clean Slate Programme at Stanford University and supported by Deutsche Telekom Laboratories from its early days.
A popular analogy to such an interface is the BIOS (Basic Input/Output System) that was made open by IBM in the late 1970s, allowing garage start-ups like Microsoft to develop an operating system independent from the underlying hardware, the personal computer.
In retrospect, the act of standardising BIOS was a historical moment, as it decoupled the innovation cycles of software and hardware, leading to an explosion of software and applications that changed everyone’s lives.
OFELIA set out to create a pan-European test bed for OpenFlow, providing European students and industrial researchers with a tremendous opportunity to test their applications.
The test bed was constructed while similar efforts were underway or about to start in the US (GENI), Japan (JGN-X), China and Brazil. Currently, any researcher can use the current test facility to deploy and test new routing protocols, content delivery strategies, or new addressing schemes for a future internet. These control applications are the core of what will be a network operating system.
WHAT DOES OFELIA OFFER?
The short answer is: a slice of a network and a way to use OpenFlow’s capabilities, which allows users to create a virtual network and it through secure and standardised interfaces.
Researchers can dynamically create virtual machines and connect these to a networking substrate that is controlled by their own OpenFlow controller. The virtual machines are on standard Linux installations that can act as traffic sources or sinks (traffic simulators). It is the controller implementation that sets the forwarding rules in switches and lets the researcher define paths through the internet.
The control plane is sliced by means of FlowVisor, a shimtype controller that assigns parts of the overall address space (a combination of ports/MAC/IP addresses and wildcarded header fields) to a slice in a network. The network can be shared by filtering the OpenFlow messages and assigning them to the appropriate controller.
Some limitations…and ways to overcome them
FlowVisor does not actually slice the forwarding capacity, so the scope of experimentation is limited for quality-of-service (QoS) tests. As the entire OFELIA test bed is implemented as an overlay over the legacy internet in large parts, bandwidthhungry applications are currently out of scope.
The OFELIA network is based on a mix of OpenFlow-enabled Ethernet switches (the majority being NEC’s IP8800) running OpenFlow v.1.0. In the meantime (until the end of 2013) OpenFlow standardisation has progressed to version 1.4.
As FlowVisor limits the current controllers and the installed hardware to v1.0, the research facility becomes less attractive. Because of this, the FIRE project ALIEN was started in 2012 to improve programmability of both the OFELIA hardware as well as the control framework.
ALIEN’s first results are multi-version data paths and new tools for control slicing that remove the need for FlowVisor.
At the end of 2013 a new types of virtual machine was added to OFELIA’s servers. SPIRENT, one of the major providers of network testing equipment, has provided a number of licenses for their virtual TestCenter appliances. This means that any OFELIA user now can install professional network testing equipment on several parts of the network and use them as sources/sinks for highly specific network traffic.
WHO USES OFELIA, AND WHO COULD USE IT?
Mainly, still, but not exclusively, OFELIA is used for master theses and student projects. Increasingly, teaching activities take place that use parts of the test bed. We also see small- and medium-sized enterprises using the service for functional and performance product testing. So far, technically, experiments deal with routing and different forms of addressing, and only very recently with first end-user applications like distributed video caching, content delivery network strategies and so on.
Software-defined network (SDN) changes the landscape of communication networks. The recent OpenDayLight initiative appears to be an attempt to define a full-blown operating system deployable across a number of switches from different vendors.
This will naturally decrease the role of current system integrators, as the glue between the pure hardware and the network operators will be open source and supported by a bigger community. At the same time, network operators need to become more software literate, rather than just being able to change a few configuration scripts. This leads to DevOps software development methods and completely different skill sets needed by network operators.
OFELIA will continue to grow in the coming months and years, as new islands – nodes or facilities – become part of the project’s test bed network from the ALIEN and FIBRE projects.
Many problems still remain to be solved, such as improving usability, shortening the work flow for successful experiments and creating bigger and more powerful network infrastructure. During 2013, software development together with the GENI project office was started. The results will hopefully end up in a common clearing house, easing the way for researchers to use GENI and OFELIA.
By signing a memorandum of understanding, OFELIA’s island owners have ensured the test facility will continue to be available in 2014 and 2015. The agreement provides for a not-for-profit foundation that will continue to steer the technical development of the test bed control framework, provide a platform for the resulting open source software, and guarantee the stable operation of the existing test bed. The biggest challenge ahead will be how to reach out to real users, as the debate over net neutrality continues to be a controversial topic. SDN provides an elegant way out of the dilemma for users and network providers.