Emulation extensions for OneLab nodes are provided by an external box (which can be real or simulated) that implements the required bandwidth limitations and packet delays. We call this box a DBox. The DBox sits on the link between the OneLab node and the rest of the network, and its presence is recorded in the NodeNetworks table of the database hosted on the Central Site.
Given that the current OneLab architecture does not have knowledge of which experiments are being run or when, the only feasible way to configure the DBox for an experiment is to leave the task to the user, who has to do it explicitly just before (or during) the experiment.
The situation is not different from multihomed nodes, where the choice of the actual network link to use (wired, UMTS, WiMax, etc.) is better left to the application.
In order to ease the task of the user, what we do provide are means to make this task as easy as adding a single line of code to the source (or the script) in charge of launching the experiment.
When an experiment needs to configure the DBox, or select a specific network link, etc. it will simply launch a one-line "netconfig ..." program with all the parameter required by the specific network link. In turn, "netconfig" will call the appropriate network configuration program (typically a 'setuserid' program to configure a local interface). In the case of the DBox, the latter will be accessible from the sliver using the same ssh keys used to access the Sliver.
The choice of an external command to configure the network has a number of advantages. First, it can be issued manually or automatically from within the setup script for the experiment, or from the experiment itself, irrespective from the programming language used. Secondly, it allows us to add support for more and more link types at a later time, while still using the same interface to configure them.
Database extensions concern the Central node. They only require one or a few extra field to describe the capabilities of a node in terms of additional network links, and the basic configuration information (e.g. interface names, DBox addresses, etc.) of those extra links.
Each node in the system must be equipped with the 'netconfig' code to configure the network links, and the configuration information to describe which links are available and how they can be controlled.
The 'netconfig' code will be shipped to the nodes as an RPM package, distributed using the same mechanisms used to bootstrap/update the code on the nodes. We expect this code to change very rarely.
The configuration information (interface names, DBox addresses, etc.) is updated using the same mechanism used to update the files in the /etc directory. This typically happens once per day, or as specified in the crontab.
In this implementation the DBox is a computer running FreeBSD and a modified version of the dummynet code. An ssh server running on the DBox will listen for configuration requests coming from the Node, authenticate the request using the credentials of the Sliver, and perform the required operation to configure the emulated link as required.
+----------+ +------------+
| Onelab | | |
| Node +-<-->-- + DBox +--<-->-- Internet
| | | |
+----------+ +------------+
The DBox only intercepts the traffic involving the experiment;
control traffic goes through unmodified.
pl_01@onelab8 $ # configure the link
pl_01@onelab8 $ netconfig.sh emu_802 5000 5 1Mbps 38dB
The 802.11 emulation link is configured with
5 active stations, 1Mbps of bandwidth
and a SNR of 38dB on 131.114.9.236:5000
pl_01@onelab8 $ # making the experiment
pl_01@onelab8 $ ./hping2 -s 5000 -c 1 onelab7.iet.unipi.it
HPING onelab7.iet.unipi.it (em0 131.114.9.134): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=131.114.9.134 ttl=64 DF id=266 sport=0 flags=RA seq=0 win=0 rtt=0.2 ms
--- onelab7.iet.unipi.it hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms