4.3.1 Use of User-Mode Linux
User-Mode Linux (UML) is a port of the Linux kernel to Linux. It implements a Linux virtual machine running on a Linux host. Its hardware is virtual, being constructed from resources provided by the host. UML can run essentially any application that can be run on the host [97]. To the host kernel, the UML instance is a normal process. To the UML processes, the UML instance is a kernel. Processes interact with the kernel by mak- ing system calls, which are like procedure calls except that they request the kernel to do something on their behalf [98]. As of Linux 2.6.0, UML has been integrated into the main kernel source tree. While UML was designed for the x86 processors, it has since been por- ted to other architectures including IA-64 and PowerPC. One example in which UML is being used for large scale network experimentation is ORBIT1.“ORBIT is a two-tier labor-
atory emulator/field trial network testbed designed to achieve reproducibility of experimentation, while also supporting evaluation of protocols and applications in real-world settings.”
UML enables Linux virtual machines (VMs) to be run as Linux applications within a host Linux OS instance. This allows the user to run different copies of Linux safely in user space without affecting the overall stability of the host operating system. It is also possible to further restrict a virtual machine in UML to specific hardware thus improving host stability. The UML instances contain a full Linux OS and so can have great flexibility and functionality for experimentation. In Cloonix-Net, UML functionality also allows us to run different VMs with different Linux kernels. Thus, it is possible to create a virtual network with different entities, each having its own unique role, communicating together as if in a real network testbed, but operating on a single Linux host.
Other network emulators that utilise virtualisation technologies exist - these use paravir- tualisation as opposed to full virtualisation like UML. Such tools include IMUNES (Integ- rated Network Topology Emulator/Simulator) [99] and CORE (Common Open Research Emulator) [100]. IMUNES is a network emulator model based on FreeBSD that allows for the existence of multiple virtualised network stacks within the kernel. Processes in user space can be grouped to these virtual stacks and subsequently communicate through virtual links between them. These groups are the virtual nodes.
CORE (which is based on IMUNES), is a lightweight, real-time network emulator that allows the user to create topologies that consist of real and virtual nodes. It is able to emulate nodes (e.g. routers and PCs) and the links between them. CORE supports wired and wireless links to a certain extent. It does not virtualise Layers 1 and 2 but instead focuses on Layer 3 emulation. Like IMUNES, it uses FreeBSD and implements an actual TCP/IP stack. But because both use paravirtualisation, all the virtual images share the same kernel, filesystem, processor, memory, clock and other resources. With regards to mobile network protocol testing, a custom network stack is required as certain network layer protocols need to be modified (e.g. NEMO and Mobile IP). As a result, the separ- ation of kernel and filesystem offered by UML through full virtualisation provides for a simpler and more flexible platform to undertake such testing, though at the price of scalability.
4.3.2 On the Use of Simulators
One popular tool for mobile systems is simulation, e.g. using OMNET2and NS23. While
simulation is used widely within the research community, there is a reliance on that com- munity to support collaboration and reproduction of new functionality. This may be sporadic in development and the maturity of code that results may be variable. In order for the existing mobile network standards such as NEMO to be used effectively in these platforms, there has to be considerable investment of time, to port the existing Linux code into the simulators, and then test and maintain existing code ports to the simulator as well as development of the main operational code base. Also, there needs to be effort in setting up connectivity scenarios, calibration and subsequently running the simula- tion. However, given that there is already existing code that has been verified and shown to work, it seems a natural progression to use that code directly where possible, as the results based on the ported code may not be the same as those of the actual code. With virtualisation (via UML), we have the ability to run real working code in a controllable and reproducible environment. While newer simulators such as NS34 are planning to
permit incorporation of system code, such tools still lack maturity. (Note: OMNET does include a module of a working FreeBSD stack with real code).
4.3.3 On the Use of Testbeds
Another option is the use of testbeds to conduct experiments. Often, accurate and real- istic testbeds are expensive and time consuming to procure, setup and configure. Also, a designated, controlled space has to be allocated and managed, especially for wireless testbeds, where interference is a big concern. Additionally, for large testbeds, one must also consider the overall management and upkeep of the operational nodes, both in terms of finance and the manpower needed. In testbed experiments, some form of tuning or calibration is required every time new hardware is incorporated (e.g. after a hardware upgrade, or to replace a failed component), before experiments can begin. Some freely accessible testbeds exist, such as ORBIT5 and Emulab6. However, these still have lim-
itations in terms of configuration, customisation, privacy and scheduling. PlanetLab 7 is another example. It has issues regarding congestion, especially when it gets closer to certain conference deadlines. I am in favour of the usage of testbeds, and I believe that they should be incorporated whenever possible. However, I take the position that using the VM approach using UML would allow researchers to be better informed before pro- gressing to a full test-bed: the VM approach is complimentary to a testbed experiment. VM results, where the effects of wireless transmission are not considered, could poten- tially offer a ‘best case baseline’ for comparison with testbed results. Also, results from a VM approach could potentially be used to target and narrow down specific areas of interest, which can then be fully explored with testbed experiments, thereby saving time and effort. 2http://www.omnetpp.org/ 3http://www.isi.edu/nsnam/ns/ 4http://www.nsnam.org/ 5http://www.orbit-lab.org/ 6http://www.emulab.net/ 7http://www.planet-lab.org/
55
4.3.4 On the Use of VMware
One of the first tools, I considered, apart from Cloonix-Net was VMware8. VMware spe-
cialises in virtualisation software. Under the academic license, VMware software was readily available for use, and there is a large and growing community of researchers con- tributing to libraries of ‘VM appliances’, custom configured VMware images that can be used ‘off-the-shelf’. Using VMware virtualisation software (which runs on all major platforms - Windows, Linux and Mac), I explored its capabilities in fulfilling our require- ments for mobile network testing. VMware has the advantage of a large community, which provides support for the ‘VM applicances’. It is also very easy to create and share VMware images. Ultimately however, our main concern was that there was not enough operational flexibility for mobile network testing.
Below is a brief description of the three basic modes of network connectivity in VMware: 1. Bridged: where VMware uses the physical interface of the host to directly emulate the virtual interface in the virtual machine. Here the virtual machine appears as a separate machine on the (real, physical) LAN.
2. Host-only: where a virtual interface is created on the host, which is connected to the virtual interface in the virtual machine. This sets up communication between the host and virtual machine only.
3. NAT: where a virtual interface on the host is connected to the virtual interface on the virtual machine. The host acts a Network Address Translation (NAT) router for all egress and ingress packets. In this mode, the virtual machine does not appear visible (at least at the IP layer) to the outside world.
These modes made it difficult to create useful network topologies for experimentation. The only option available was to create a virtual experimental network, with all virtual machines on the Bridged mode. This created two main obstacles. The first was to setup and configure Virtual LANs (VLANs) on the real, physical network to allow suitable to- pologies to be configured. The second obstacle was to figure out how to emulate mobility of the machines, to triggerinitialisation,rendezvousandhandoff events. This had to be im- plemented by dynamically tearing down specific existing VLAN connections (to simulate when a mobile node leaves a network) and simultaneously setting up new VLAN con- nections (to simulate when a mobile node joins a network). It was found that the effort required to manage these VLANs dynamically for an experimental scenario (which re- quires sending specific commands to an ethernet switch and waiting for those commands to be activated) introduced a level of complexity of configuration that reduced greatly the appeal of VMware for this purpose.
4.3.5 On the General Use of Virtualisation
For the use of VMs, the following advantages make it worthwhile for use in experiment- ation of mobile network scenarios:
1. It is quick to get up and running with experimentation, especially with the avail- able Mobile IPv6 and NEMOv6 network configuration provided. Also, hardware requirements will be relatively modest. There is no need to acquire any additional hardware or special equipment - the basic requirement is a desktop machine cap- able of running virtual machines, which could easily be an existing machine. 2. It is straightforward to share experiments for the purposes of collaboration or to
allow for other researchers to use your configurations and/or reproduce experi- mental results.
3. Using of virtual machines means that any calibration or setting up of a network en- tity (e.g. mobile router or mobile node) need not be re-done. By simply copying the existing virtual machine, another entity of similar type can be created and added to the test network.
4. It becomes a trivial task to make backups and to archive existing experiments, both after completion, and ‘snapshots’ of experiments in progress.
5. In the case of UML, exclusion of wireless effects makes for simpler experimental configuration. The interpretation of such experimental results is directed primar- ily on the architecture of the protocol (which may be of greater concern to the re- searcher). The VM can also be archived, shared or re-configured easily. There will however come a point when wireless effects will be needed to be investigated. 6. Migration from virtual experiments to emulation and testbed experiments is a nat-
ural progression, and could use the existing VM images for deployment on real testbed systems. The kernel of existing virtual machines can simply be copied over to real world machines, similarly for file-systems.
There are also some drawbacks to consider with the use of VMs:
1. Researchers will have to invest time in learning to use the Linux operating system (in our case Debian); though these skills will be transferable.
2. For the creation of new VM images, some form of setup and calibration is required in the first instance, in a similar fashion as for a testbed (though not with the same level of effort, as we do not have to deal with the nuances of real hardware). 3. There is the possibility of experimental results being effected by artefacts or per-
formance bottlenecks occurring as a result of the operating system of the host ma- chine, rather than effects/behaviour of the experimental VMs. These may be diffi- cult to predict, detect or filter from experimental results.
4. Currently, virtual networks (consisting of multiple VMs) have to be run on a single host machine. As it is not yet possible to distribute the load of hosting these virtual machines, the number that can be hosted effectively is bounded by the hardware specifications of the host machine. This may lead to relatively small-scale experi- ments (e.g. 8-10 nodes) unless especially capable host machines are available.
57 5. For more complex operational testing, additional management tools might be re- quired. For the creation of network topology we have Cloonix-Net; it is conceiv- able that if new functionality needs to be added, a new management tool will be required, or Cloonix-net would have to be extended.