OpenFlow-Wireless Federation with Brazilian Islands

Content Centric Networks (CCNs) have become of major importance lately, due to their novelty of service provisioning relieved from addressing schemes. However, most of the approaches so far perform content mapping to network addresses based on complex Domain Name Service (DNS) system setups. In this demo, our experimental setup alters the regular operation of the Address Resolution Protocol (ARP) and manages to provide different load balancing techniques in the allocation of content requests to servers, by exploiting OpenFlow (OF) resources. Our platform is evaluated under real conditions, using the federated infrastructure of three different FIBRE testbeds,
spanning the two continents of Europe and Brazil.

 Figure 1(a)

For the purposes of this demo, resources from three wireless facilities are exploited, the Brazilian testbeds of Universidade Federal de Goias (UFG) and Universidade Federal do Rio de Janeiro (UFRJ), and the European NITOS testbed of University of Thessaly (UTH). NITOS testbed features two OF switches, one of which will be used to intercept the ARP traffic.

The three testbeds are configured in one VPN network, supporting Ethernet-Bridging, thus placing the resources under one single virtual LAN, as depicted in Fig. 1(a). The three islands are already federated using the cOntrol and Management Framework, named OMF. The basic building blocks of OMF are the Experiment Controller (EC) and the Resource Controller (RC). During an experiment, the user interacts with an EC instance, which orchestrates the behavior of the experiment resources, on which RCs are running. A measurement software framework closely related to OMF, named OMF Measurement Library (OML), is being used to handle experiment measurements at NITOS.

Figure 1(b)

 We will be using multiple nodes from the UFG and UFRJ testbeds, that would on pairs provide different services, emulating a scenario for server redundancy in a Cloud Computing system. All the content servers offering the same service would have the same IP address. If a server should offer more than one service, the server will be using multiple IP addresses using virtual subinterfaces. Multiple nodes from the NITOS testbed will be acting as the clients requesting content from the servers. All the nodes are configured with an IP address from the same local IP network. When the first client requests the service providing the corresponding URL, it retrieves the shared IP address, which should be translated to a MAC one initiating an ARP request.

The OF switch propagates normally this ARP request, while on the receipt of the multiple ARP replies, it selects and forwards only one of them, using a round-robin way. In Fig. 1(b) we present some measurements from our proposed setup, that have been aggregated using the OML framework. We have measured the number of the total bytes transferred to each server, and the total bytes that have been passing through the OF switch. As one can deduce from the figure, total traffic that passes by the switch is almost equally divided between the two available content servers.

PlanetLab-NITOS Federation

Figure 1: The scenario of our user association experiment

1. Resources involved

A synergy between two different testbeds is established for the purposes of the experiment, namely between the NITOS wireless testbed, located at the premises of the  University of Thessaly, and the large-scale distributed Planetlab Europe wired testbed. The University of Thessaly has two Planetlab nodes deployed at their facilities. These nodes are connected to two wireless nodes of NITOS, configured to operate as access-points. A third wireless NITOS node, in range with the former two, is used as the station sending the traffic. This traffic is destined to a remote Planetlab node, located at the INRIA facilities in Paris, France. The synergy between the two testbeds is depicted in Figure 2.

Figure 2: The synergy of NITOS and PLE during the experiment

2. Experiment Description

The three wireless nodes at NITOS are running modified versions of the MadWifi open-source driver. At the APs the drivers read a delay value from a specific proc-file. This value is obtained for each node through periodic pings to the destination node at INRIA taking place at the application level at regular time intervals. Each AP advertises this value through beacons, so that wireless stations in their neighborhood can take this parameter into account for their association decision. At the station side, the driver has been modified, so that the station associates to the AP with the lowest delay value, rather than to the AP with the highest RSSI. Again, it is clear that alternative policies using combined metrics of RSSI, delay and other parameters are straightforward to implement.

Figure 3: The actual scenario - Delay emulation through Dummynet

In order to control the delay of the different routes to the destination, a network emulator is being used on the destination side, Dummynet in particular. We configure Dummynet to apply different delays to the streams arriving from the two APs at NITOS and change this configuration periodically on the fly, as the experiment is running. The APs running the periodic ping applications sense these changes and update the relative proc-files accordingly.

Download the experiment description in OMF:

experiment.rb

3. Related paper

You can also download the relevant paper accepted in Tridentom 2012:

Keranidis_Federation_TridentCom_2012_paper.pdf

4. Demonstration through OMF

Figure 4: Screenshot from our Demonstration Video

The whole experiment is orchestrated through the OMF testbed control and management framework. NITOS has adopted OMF as its software framework and Planetlab nodes can incorporate OMF software upon request.

Video Streaming using PlanetLab and NITOS

Federation of heterogeneous testbeds has lately become of major importance for the research community. One major targets of the Openlab project is the design and development of a federation framework that would enable experimentation with heterogeneous resources across Europe. In this concept, many different tools for federating the control and experimental plane of testbeds have been proposed. Special efforts have been conducted in the context of Openlab, especially in federation schemes between wireless and wired testbeds, such as the one between the wireless NITOS and the wired Planetlab Europe (PLE) testbeds.

Two well known, currently under development, frameworks that aid in testbed federation are SFA and OMF. In the federation, SFA (Slice Federation Architecture) aims at providing a control plane federation tool between testbeds. The goal of the SFA is to provide a minimal interface that enables testbeds of different technologies and/or belonging to different administrative domains to federate without losing control of their resources. Experimenters are able to combine all available resources and run advanced networking experiments of significant scale and diversity.

On the other hand, OMF (Control and Management Framework) is a framework for controlling, instrumenting and managing testbeds. Experimenters use OMF to describe, instrument and execute their experiments. It can become very handy for testbed administrators, since it can achieve experimental plane federation among different, even heterogeneous, testbeds. NITOS wireless testbed and PLE are already federated through OMF and SFA, giving the experimenter the ability to run large scale networking experiments, combining wireless and wired resources across Europe.

As a proof of concept for the aforementioned federation techniques, we built a representative experiment in OMF exploiting NITOS and PLE nodes. In this demo, we use a last hop wireless NITOS node that requests video transmission from a remote PLE node (Central Coordinator Server). This server relays the request to all its peer nodes (named Cache Servers), which up to this point are totally transparent to the end user. The Cache nodes ping the wireless remote client and report their delays back to their Central Coordinator Server. The Coordinator replies to the client with the hostname of the Cache server that reports the lowest end to end delay. Upon the selection of the appropriate Cache Server, the video streaming service is enabled.

In order to ensure that the quality of the streaming services remains uninterrupted, the peer nodes continue to ping the wireless client at certain time intervals and report these values back to their Coordinator. Through this procedure, the Coordinator is able to detect any possible performance degradation in the wired part that links the various servers to the public Internet (i.e. congestions inducing higher delays, fallen links) and therefore inform any of the redundant Cache servers to start their streaming services and report back to the end client the new hostname of the active Cache Server that currently offers the highest available video quality.