The CONFINE testbed infrastructure can not only be used for real world testbeds, it can also be used as a completely virtualized testbed for local experiments (Virtual Confine Testbed - VCT). Each CONFINE node is implemented as a (kernel-based) virtual machine KVM on a host system (which in case of the VCT in the current state is an LXC container). These virtual machines are connected by a Linux bridge. This supplies the researcher with a means to test an experiment in a local CONFINE environment before deploying it on the real testbed, where other users can be influenced by its misbehaviour due to errors in the configuration or design.
VCT container provides a CONFINE environment with perfect links out of the box. Usually this is not enough for thorough testing of an experiment designed for wireless networks, where imperfect links are not uncommon. A simple link error model along with a set of scripts using only EBTables and IPTables subsystem to generate configurable packet loss between each pair of virtualized CONFINE nodes has already been provided by Fraunhofer FKIE. The details can be found on link error model wiki page.
The link error model is a simple solution for creating topologies and imperfect links in VCT. However, some experiments have more elaborate needs. These can be met by combining the VCT with the network simulator NS3, which offers (among other things) more realistic signal propagation models as well as link layer models with interference. Below, step by step instructions for using NS3 with VCT as well as a simple example scenario can be found.
First, NS3 must be installed in the vct container. Log into the container, download and build NS3, test the build:
~$ mkdir ns3 ~$ cd ns3 ~/ns3$ hg clone http://code.nsnam.org/ns-3-allinone ~/ns3$ cd ns-3-allinone ~/ns3/ns-3-allinone$ ./download.py ~/ns3/ns-3-allinone$ ./build.py --enable-examples --enable-tests --enable-sudo ~/ns3/ns-3-allinone$ cd ns-3-dev ~/ns3/ns-3-allinone/ns-3-dev$ ./test.py
More Information and tutorials can be found in NS3 Wiki
A simple example with 2 nodes and 1 slice is depicted above. Each sliver needs to have an isolated interface (named e.g. wlan0). The parent of the isolated interface in the node the sliver is running on (e.g. eth1), has a corresponding vnet interface in the vct container. This vnet interface needs to be assigned a vlan device with the vlan ID the slice got from the controller. The new vlan device is responsible for removing vlan tags from outgoing packets and appending them to incoming packets. This is necessary, as NS3 doesn't support vlan tagging. (A more difficult alternative solution would be a patch for NS3 with vlan tag support).
A vlan device like the one on the left in the picture can be created as follows:
~# ip link add link vnet1 vnet1.256 type vlan id 256
According to the default vct naming convention a vnet interface corresponding to the isolated interface of a given sliver can be found by comparing the MAC addresses - all but the first two digits of a vnet MAC must match the MAC of the corresponding isolated interface in the sliver (first two hex digits of a vnet MAC are always 'fe' and of a sliver '52')
Next, create a tap device that will be connected to NS3 raw socket:
~# tunctl -t tap0
Then create a bridge and connect the vlan and tap devices together:
~# brctl addbr br-0 ~# brctl addif br-0 tap0 ~# brctl addif br-0 vnet1.256
Now all the interfaces can be started:
~# ifconfig br-0 up ~# ifconfig tap0 promisc up ~# ifconfig vnet1.256 promisc up
The steps above need to be repeated for each sliver that is to be represented as a node in the NS3 simulation.
According to the original code in NS3, a raw socket gets the same MAC Address as the tap device it is connected to. In our use case, this results in wrong addressing when slivers are communicating over the NS3 emulated wireless channel. In order to fix this problem, the default behaviour needs to be changed to use a different method for setting the MAC addresses (which is already part of the code). Here, the MAC addresses are “learned” from the initial (broadcast) ARP requests and the device is configured on the fly. Using this method, the emulated device within NS3 is assigned the same address as used within the LXC container / sliver. This is essential for using an 802.11 Ad-Hoc channel. The attached patch changes a few lines in the code of TapBridge to enable this method. The source file can be found here.
Substitute the file …/ns-3-allinone/ns-3-dev/src/tap-bridge/model/tap-bridge.cc with the supplied source file and recompile ns3:
A simple scenario with realistic signal propagation and 2 nodes can be found here. The names of the tap devices might need to be adjusted. Copy the scenario to …/ns-3-allinone/ns-3-dev/scratch/ and recompile NS3. After the necessary slivers and interfaces have been created and configured (don't forget to configure the isolated interfaces in the slivers) run the scenario with:
/home/vct/ns3/ns-3-allinone/ns-3-dev# ./waf --run vct-test