airolab: a framework toward eﬀective virtualization of...

AiroLAB: A Framework Toward Effective

Virtualization of Multi-hop Wireless Networks

Roberto Doriguzzi Corin, Roberto Riggio, Daniele Miorandi, and Elio Salvadori

CREATE-NET, via alla Cascata 56/D, IT - 38123, Povo, Trento, Italy

Abstract. In this work we introduce AiroLAB, a novel network virtu-alization framework specifically tailored to multi-hop wireless networks.AiroLAB departs from conventional network virtualization approachesby focusing on embedded, resource–constrained devices and by aimingat providing Wireless Internet Service Providers with an effective virtual-ization mechanism where network resources are shared between produc-tion traffic and a variable number of experimental slices allowing novelsolutions and services to be tested in a controlled yet realistic environ-ment. In the paper, the design choices at the hearth of AiroLAB arepresented, together with an early–stage prototype implementation andexperimental results obtained in a small–scale wireless network testbed.

Key words: network virtualization, multi–hop wireless networks, com-munications networks, embedded devices, resource constrained environ-ments

1 Introduction

Network Virtualization (NV) is currently regarded as one of the most promisingapproaches to unlock and enable innovation in today’s network [1, 2]. Generallyspeaking, NV can be seen as a tool for:

– Evaluating new, not necessarily backward compliant Internet architectures(“clean–slate approaches”) in large–scale realistic environments, thereby help-ing to overcome the current Internet ossification;

– Changing the functional role and business model of Internet Service Providers(ISPs) by decoupling the provisioning of physical infrastructure from the pro-visioning of communication/computing resources. In such a way, the role cur-rently covered, in most countries, by ISPs would be taken over by differ-ent entities: Infrastructure Providers, Virtual Network Providers and ServiceProviders. This could provide the basis for the introduction of new stakehold-ers in the Internet ecosystems improving the competition in this sector;

– Enabling the smooth and controlled introduction of novel services in an op-erational network by providing means to isolate them from already deployedapplications, thereby promoting innovation in telecommunication networks;

– Moving logical instances of nodes and services across an infrastructure in orderto optimize network performance and minimize operational expenditures. As

2 R. Doriguzzi et al.

an example, moving services close to the users may lead to a decrease inthe power consumption of a physical network, therefore contributing to alimitation of the network’s carbon footprint.

Challenges in NV research include the definition of appropriate and efficientalgorithms, architectures and protocols to effectively share a common physicalnetwork infrastructure, splitting it into several logical instances (generally re-ferred to as “slices”) composed of virtual links and virtual network nodes [3, 4].Network nodes should be fully programmable to allow the instantiation of severalnetwork instances, each one potentially based on a different architecture. Severalprojects worldwide are working on the various aspects underpinning NV: GENIin USA [5], 4WARD [6], FEDERICA [7] in Europe and AKARI in Japan [8].

NV solutions depend heavily on the network substrate on which they need tooperate. In particular, one challenging environment for NV solutions is that ofwireless multi–hop networks [9, 10]. Wireless multi–hop networks are emerging asa cost–effective paradigm for enabling communications in those scenarios wherethe deployment of a fixed wireline infrastructure is either non feasible (e.g., inthe case of mobile nodes such as vehicular ad hoc networks) or non economicallyattractive (e.g., access to Internet in developing countries). The complexity ofintroducing NV capabilities in such networks is exacerbated not only by thefragile stability of the wireless links, but also by the limited processing power andstorage capabilities typically available on the devices employed in such systems.

While several NV architectures and solutions have been proposed in recentyears, most (if not all) of them were developed for wired networks, characterizedby virtually unlimited processing/storage power and link bandwidth (Planet-Lab [11], VINI [12], G-Lab [13], etc). On the other hand, very few studies havebeen performed on resource–constrained environments in general, and multi–hopwireless networks in particular. Further, they have mainly focused on how dif-ferent wireless medium virtualization techniques affect the overall network slicesperformance in term of isolation and stability [14, 15].

In this paper we introduce AiroLAB, a novel virtualization framework specif-ically tailored to multi–hop wireless networks. AiroLAB aims at providing Wire-less Internet Service Providers (WISP) with an effective virtualization solution,allowing production traffic to share part of the available network resources witha variable number of network slices where novel solutions, such as new routingprotocols, services or network operation tools, can be experimentally tested in aseverely controlled yet realistic environment. In the rest of the paper, the build-ing blocks that are at the base of the AiroLAB’s architecture and the protocolsdevised in order to support its operations are presented, discussed and comparedwith existing solutions. A first prototypical implementation of AiroLAB includ-ing link channel capacity estimation is described, together with experimentalmeasurements obtained in a small–scale wireless network testbed.

The remainder of the paper is organized as follows. Sec. 2 surveys the mainchallenges in the design and development of network virtualization solutions formulti–hop wireless networks. Section 3 describes the AiroLAB architecture andprotocols. Section 4 reports and discusses the outcomes of experimental tests

AiroLAB 3

carried out with a first prototype implementation of the proposed framework.Comparison with existing relevant solutions is carried out in Sec. 5. Finally,Sec. 6 concludes the paper with a discussion of open issues and relevant researchdirections for improving the AiroLAB framework.

2 Challenges

In this section we first provide a list of requirements any network virtualizationenvironment shall satisfy regardless the technological domain it is applied to.Then, we analyze how such requirements need to be tailored to account for thepeculiar features of wireless multi–hop networks.

2.1 Requirements for a Virtualization Environment

An effective network virtualization shall satisfy the following general require-ments [3]:

– Scalability: depending on the network segment and technological domain underconsideration, the performance offered shall not depend on the number of slicesactive in the system.

– Isolation: a full isolation among slices should be guaranteed in order to improvetolerance to faults, security and privacy in the virtualized infrastructure. Inparticular, potential misconfiguration in one network slice should not affect ordestabilize the other ones.

– Legacy support : backward compatibility should be guaranteed in network vir-tualization environments by –at least– hosting a legacy implementation of anetwork instance (e.g. production network) in a slice.

– Flexibility: full programmability of the network elements must be ensuredespecially in environments where clean–slate approaches are to be investigated.

– Manageability: network management tasks on a single network slice should beperformed without the need for coordination across administrative boundaries.

– Heterogeneity: heterogeneity should be supported at different levels: underly-ing networking technologies; end–to–end virtual networks spanning heteroge-neous combinations of (sub)networks; end-user devices.

– Efficiency: the additional overhead introduced by the virtualization frameworkshall be minimal.

Two further requirements should be added to this list in the case network vir-tualization techniques are used for running concurrent research experiments [11]:

– Inter–experiments interference: network virtualization introduces some formof compromised performance for co–existing experiments. Any performancedegradation associated with experiments should be carefully quantified whenmapping virtualization to scientific experiments.


– Experiments repeatability: repeatability of results must be assured throughproper resource sharing techniques to avoid unpredictable performance acrossmultiple experiment runs.

Compared to existing approaches, these last two requirements are less rele-vant for our framework. Our aim is in fact to provide an environment for produc-tion networks, where operational traffic is fully guaranteed, while experimentalservices and protocols run on lower–priority slices. This scenario is a sort ofintermediate one between (i) a purely research approach, i.e. ORBIT [16] orGENI [5], where novel services or protocols are executed on shared but dedi-cated testbed infrastructures, and (ii) a conservative approach (pursued so farby most of the operators) where novel services or recent protocols are tested ona small-scale testbed separated from the main production network.

In this scenario, AiroLAB is a NV framework whose objectives are some-how similar to the ones pursued by solutions such as Cabernet [17, 18] andgeneralized in [19]; however, given the specific technological domain under con-sideration, we are providing an emphasis toward the possibility for a WISP toperform experimental activities in a controlled fashion directly on its produc-tion network, fostering the deployment of novel solutions and services. In sucha scenario, experimental traffic is expected to be given a best effort treatment,thus delivering the guaranteed service to the WISP customers. As a result, theshare of bandwidth made available for experimental services might change dy-namically and thus negatively affect the repeatability of experiments. It is theauthors’ standpoint that, in a production environment, repeatability shall betraded for performance isolation and scalability in order to give paying servicespreemptive access to the network resources.

2.2 Problem Definition and Challenges

Network virtualization in wireless networks needs to address two additional ma-jor issues: (i) how to isolate wireless resources belonging to network slices coex-isting at the same time to ensure minimal interference among them, and (ii) howto control wireless resource utilization to ensure that a slice does not infringe theresources of another slice. Several techniques have been proposed to guaranteethe isolation of wireless resources among concurrent slices[14]:

– SDM (Space Division Multiplexing), where physical wireless nodes are parti-tioned in space, forming separate sub–networks, thereby minimizing the inter-ference among different slices.

– FDM (Frequency Division Multiplexing), where different slices are partitionedin the frequency domain by leveraging on the availability of multiple wirelessinterfaces on each network node.

– CDM (Code Division Multiplexing), similar to FDM, but assigning differentcodes to each slice.

– TDM (Time Division Multiplexing), whereby slices are partitioned in the timedomain by assigning them a specific timeslot for their communication needs.

AiroLAB 5

While studies regarding the feasibility of each of these approaches (or com-binations thereof), with their pros and cons have been already provided in liter-ature [14, 20, 15], we are interested here in investigating techniques and archi-tectures to allow an effective isolation between concurrent slices on a multi–hopwireless network through a finer control of wireless and node resources usage inthe network.

In particular, AiroLAB aims at achieving a level of flexibility which noneof the aforementioned techniques, used in a stand–alone fashion, could provide.Further, we target the provisioning of methods for ensuring that a privileged slice(typically the one carrying the production traffic) can have guaranteed resourceswhile the ones devoted to experimental activities may share the remaining (pos-sibly time–varying) network resources.

3 AiroLAB Architecture and Design

In this section, we introduce the design of AiroLAB, a novel virtualization frame-work specifically tailored to multi–hop wireless networks. Such networks are usu-ally built using commodity components and are characterized by rather limitedcomputing capabilities, in comparison to the traditional carrier–class networkingequipment exploited in projects such as FEDERICA [7], AKARI [8] or GENI [5].As a matter of fact, we argue that a virtualization environment suitable forproduction–level wireless networks must satisfy the following requirements (indecreasing order of importance): efficiency, flexibility, and isolation, while con-straints on heterogeneity and scalability can be relaxed.

In this section we will first illustrate the objectives and constraints that havedriven the AiroLAB’s design and then we will describe in details its architecture.Integration with currently available frameworks for automatic NV resources allo-cations, such as OMF [21], will be considered for future evolution of the AiroLABframework.

3.1 Baseline scenario

Most of the network virtualization architectures devised so far [7, 8, 5] aimat providing multiple isolated environments where experiments can be run inparallel over real–world networks. AiroLAB, on the other hand, aims at providingwireless networks operators with a comprehensive virtualization solution whereproduction traffic (i.e. the traffic generated by the end–users), shares part of theavailable network resources with a variable number of experimental slices wherenovel solutions, e.g. routing protocols, are being tested.

Fig. 1 sketches a simplified setup where a network, composed of three nodesorganized in a string topology, is running three distinct slices : one productionslice (A), and two experimental slices (B and C ). In this scenario, links aresymmetric and their capacity is assumed to be time–invariant. Moreover, meshrouters are equipped with a single radio interface. In the next sections we will


Fig. 1: Simplified deployment scenario.

generalize AiroLAB’s design to asymmetric links with fluctuating capacity inmulti–radio/multi–channel setups.

In this simplified scenario, the production slice A is assigned 80% of theresources in the network, while the two experimental slices equally share theremaining 20% of resources. It is worth noticing that, with our architecture, wedo not aim at supporting hundreds or even tens of concurrent slices, instead weforesee a scenario where 5 to 10 slices share the overall network resources. Suchlimitation is mandated by the computing and storage constraints that charac-terized currently used wireless multi–hop networking devices. As a matter offact, to the best of the authors knowledge, the most powerful embedded wire-less router processing board currently available on the market, the GateworksCambria GW2358-4, is equipped a 667MHz ARM CPU and 128MB of RAM.

Traffic shaping is performed at each node in order to limit the amount ofnetwork resources used by each sliver. In this simplified setup the resources thateach sliver can exploit are upper bounded by a fixed threshold derived fromthe relative performance goal given during the planning phase. As a result, sliceA “sees” an 800 Kb/s bidirectional link between node 1 and node 2, while theavailable bandwidth between node 2 and node 3 is 1600 Kb/s. In this setup somebandwidth is voluntary left unused. However scenarios where a sliver can havefull access to all the available bandwidth are also supported.

3.2 Link Capacity Estimation

Due to the use of a shared medium, estimating the capacity of a wireless link isnot trivial. Interference coming from external sources, changes in the propagationcharacteristics or interference from the same signal traveling along different pathsmake the link’s total capacity fluctuate over time. Even if we limit our attentionon communications realized using the IEEE 802.11 facility of standards, an idealestimator of the link capacity from an Access Point toward a generic Stationsshould take into account both the the data frame SNR (measured at the receivingstation) and the ACK frame SNR (measured at the access point). Such a level ofprecision is difficult to achieve without introducing additional signaling and/ormodifying the standard IEEE 802.11 MAC operations.

In this work we decided to use an indirect way of assessing a link’s totalcapacity based on the rate adaption functionalities already available in currentIEEE 802.11 devices. Rate adaptation algorithm aims at dynamically selecting

AiroLAB 7

the transmission rate in order to achieve optimal performance under varyingoperating conditions. Rate adaptation is left unspecified by the IEEE 802.11standard, as a result of the years a considerable number of solutions have beenproposed by both the academic and the industrial worlds.

Our work builds on top of mac80211 [22] an implementation of the IEEE802.11 stack for the GNU/Linux operating system. More specifically, mac80211is a framework that GNU/Linux developers can use to write drivers for IEEE802.11 wireless devices. At the time of this writing, the mac80211 frameworksupports two different rate–control algorithms: PID and minstrel. In this workwe focus on the latter algorithm.

The minstrel rate–control algorithm aims at selecting the transmission ratethat maximizes the throughput. In order to so, the algorithm collects statis-tics of all the packets that have been transmitted. This data is then exploitedto compute the probability of a successful transmission Pab between a pair ofnodes, a and b, for each available data-rate. In order to cope with environmen-tal changes, minstrel uses an Exponential Weighted Moving Average (EWMA)based approach. EWMA has a smoothing effect, so that new results have a largerinfluence on the selected rate. Finally, the empirical throughput Tab, is computedas follows:

Tab =PabB

Dtx

, (1)

where Dtx is the time spent for a single transmission, and B is the packetlength. AiroLAB uses Tab as an estimation of the wireless link capacity.

3.3 Providing Soft–Performance Isolation

Soft–performance isolation between slivers is provided using the Hierarchical To-ken Bucket (HTB) techniques supported by the Linux kernels 2.6.x. HTB allowsnetwork administrators to implement precise traffic shaping policies. Before de-scribing the AiroLAB approach for providing performance isolation, this sectionbriefly summarizes the main features of HTB. HTB organizes traffic classes ina tree structure; each class is assigned an average rate (rate) and a maximumrate (ceil). Three class types exist: root, inner and leaf. A root class correspondsto a physical link; its bandwidth is the one currently available for transmission.Leaf classes, placed at the bottom of the hierarchy, correspond to a given typeof traffic (e.g., TCP-controlled or VoIP etc.). Two internal token buckets aremaintained for each class. Classes which have not exceeded their rate can un-conditionally transmit; classes which have exceeded their allowed rate but nottheir upper limit (ceil) can transmit only borrowing unused bandwidth, if avail-able, from other classes. In order to borrow bandwidth, a request is propagatedupwards in the tree. A request that would exceed the ceil limit is terminated.A request that would satisfy the allowed rate is accepted. A request that wouldnot satisfy the allowed rate constraint but the ceil one is propagated upwardsuntil the procedure is completed.


Fig. 2: AiroLAB wireless channel estimator architecture.

Due to the stochastic nature of the wireless links capacity, an HTB scheduleralone is not able to deliver performance fairness among competing traffic flows inwireless networks. In order to address such an issue we devised and implementeda wireless channel monitor which exploits the channel statistics computed by thewireless driver in order to properly distribute the available bandwidth among theslivers running in a node. Figure 2, sketches the the architecture of the AiroLABwireless channel monitor. The overall link capacity Tab is assigned to the HTB’sroot class, while each sliver is associated to a leaf class in the HTB hierarchy.Available bandwidth is distributed among the slivers according to some inputpolicies. Through such policies it is possible to assign each sliver with a minimum,maximum and/or an average bandwidth. An additional relative priority can bespecified for slivers that share the same traffic class, if no relative priority isspecified the bandwidth available for that traffic class is equally shared betweenthe competing slivers. The wireless channel monitor is implemented in the form ofa software process running within each wireless router and periodically updatesthe HTB’s configuration in order to reflect the actual channel capacity. HTB’sconfiguration is also updated if either a new slice is deployed over the networkor if the policies have changed.

3.4 Node–Level Architecture

In this section we shall describe the AiroLAB node’s architecture (see Fig. 3)in details. AiroLAB is built around OpenVZ [23], an open source virtualizationsolution for the GNU/Linux operating system, and Click, an open source modu-lar router currently available on GNU/Linux, all the children of BSD, and MACOSX.

AiroLAB 9

Fig. 3: AiroLAB node–level architecture.

OpenVZ consists of a modified Linux kernel tree that supports virtualiza-tion, isolation and resource management and a set of user level tools that al-lows the installation, configuration and maintenance of the virtual environments(also known as containers). Container–based virtualization solutions are typi-cally characterized by reduced overhead and thus better performance. They alsoprovide good performance isolation (in terms of CPU cycles, memory consump-tion, and storage), because processes running within a container do not signifi-cantly differ from processes running in the hosting system. Thus, it is possible toapply existing resources sharing techniques, such as HTB for traffic scheduling.The major drawback of container–based virtualization solutions is that, since asingle kernel is used for every sliver, kernel modifications are not allowed.

Within OpenVZ, each Virtual Environment (VE) performs and executes ex-actly like a stand–alone host; a container can be rebooted independently andcan have root access, users, IP addresses, memory, processes, files, applications,system libraries and configuration files. Moreover, OpenVZ provides a resourcemanagement system that controls the amount of resources available for the en-vironments. The controlled resources include parameters such as CPU power,disk space, and set of memory-related parameters. Furthermore, unlike alterna-


Table 1: Taxonomy of network virtualization techniques and relevant features [26].

Containers Containersw/ Click

Hypervisors HostedVMM

Scalability Good Good n.a. n.a.

Fault/Security Isolation n.a. n.a. Good Good

Performance Isolation Good Good Good Good

Flexibility Poor Good Good Good

Code Re–Usability n.a. Poor Poor Good

Efficiency Good Good Good n.a.

tive container-based solutions such as Linux–VServer [24], OpenVZ provides fullvirtualization of the networking subsystem allowing each virtual environment tocreate its own internal routing or firewall setups.

Due to the limitations imposed by the use of OpenVZ, namely the impossibil-ity to run customized kernel images in different slivers, we decided to implementour own wireless network virtualization stack in user–space using the Click mod-ular router [25]. It is worth noting that, our approach is not meant to replaceOpenVZ, but rather to extend it in order to support flexible virtualization of thewireless resources. A Click router is built by assembling several packet processingmodules, called Elements, forming a directed graph. Each element is in chargeof a specific function such as packet classification, queuing, and interfacing withnetworking devices. Click comes with an extensive library of elements supportingvarious types of packet manipulations. Such a library enables easy router config-uration by simply choosing the elements used and the connections among them.Finally, a router configuration can be easily extended by writing new elements.Albeit characterized by a higher overhead in comparison to pure kernel–levelimplementation, Click–based solutions are highly customizable allowing us tocircumvent the flexibility limitations of typical container based solutions [26].

Table 1 summarizes the trade–offs involved in the most relevant virtualizationtechniques currently available, namely containers, hypervisor, and hosted VMM.AiroLAB belongs to the second columns (Containers w/ Click) in that on theone hand container–based virtualization is used to achieve performances andscalability, and, on the other hand, user–space wireless network virtualizationdelivers high flexibility in terms of packet processing capabilities.

Click is used both within each sliver (guest click) and at the host operatingsystem level (host click). More specifically, the Click instance running within asliver provides the guest environment with a set of virtual interfaces (ath0, ath1,. . . , athN ) implemented as Linux TAP devices. A TAP device operates at layer2 of the traditional ISO/OSI networking stack and simulates an Ethernet device.User-space process, running within a sliver, can exploit the virtual interfaces toimplement their routing strategy. Communication over the virtual interfaces canbe done using three different frame formats:

– 802.3 headers (Ethernet). Used to expose a standard Ethernet interface.

AiroLAB 11

– 802.11 headers (WiFi). Used to expose a wireless interface complaint with theIEEE 802.11 protocol. In this case the user–space applications must properlyencapsulate their traffic in 802.11 frames.

– Radiotap. Used to expose a raw wireless interface. In this case the user–spaceapplications must properly encapsulate their traffic using the radiotap [27]header format. The radiotap header format is a mechanism to supply addi-tional information about 802.11 frames, from the driver to user–space appli-cations, and from a user–space application to the driver for transmission.

In either situation, outgoing traffic is encapsulated by the guest click processand sent to the host click process through the virtual interface eth0 providedby the OpenVZ Container. Please note that, if the user-space application isalready using the radiotap header, no additional encapsulation is performed bythe guest click process and the frame is delivered unchanged to the host operatingsystem. The host click process receives the incoming frame and dispatches it tothe suitable device according to a set of policies maintained by the Link Broker.

The Link Broker is a software module that can expose different connectivitygraphs to the various slivers without requiring that the nodes must be physi-cally separated (i.e., out of radio range). Connectivity graphs are defined on aper-slice basis allowing us to define a different topology for each slice. This isparticularly useful to test novel routing strategies on a subset of the nodes. More-over, if wireless routers are equipped with multiple radio interfaces, it is possibleto create multiple slices (whose cardinality equals the number of radio interfaces)operating on orthogonal frequency bands, implementing therefore an FDM wire-less network virtualization solution. Hybrid solutions where only a subset of theslivers operates on orthogonal frequencies are also supported. Albeit networkconnectivity graphs are defined at deployment time, they can change duringthe network operations in order to create connectivity scenarios that simulatedifferent operating conditions (i.e. link failures/outages).

3.5 Network–Level Configuration: an example

Figure 4 sketches a possible use case, where a production slice exploiting a stableversion of a routing protocol is running in parallel with an experimental slicewhere novel routing strategies are being tested. In this scenario the Link Brokeris used to expose two different connectivity graphs to the the production andthe experimental slices. On the other hand, the Wireless Channel Monitor isused to redistribute the available link bandwidth among the competing slices,80% to the production slices and 20% to the experimental slices in this cases.Please note that a minimum bandwidth, e.g. 1 Mb/s, can also be allocated tothe production slice.

4 Experimental set up and results

This section provides (i) an overview of the hardware and software setup usedin the experimental activities, (ii) a description of the experimental scenarios


Fig. 4: Network–level configuration: an example with one production slice and oneexperimental slice sharing a common physical substrate.

where the tests were conducted, and (iii) a report and discussion of the testsoutcomes.

4.1 Hardware/Software Platform Setup

The hardware used in our experimental activity consists of ALIX nodes providedby PC Engines [28]. Wireless routers are built exploiting the PCEngines ALIX2C2 (500MHz x86 CPU, 256MB of RAM) processor board. Operating systemand application are stored on a 1 GB Compact Flash. Connectivity is provided bytwo Ethernet channels, two miniPCI slots and one serial port. PCEngines ALIXboards are equipped with two Mikrotik R52 WiFi IEEE 802.11a/b/g cards basedon the Atheros AR2412 chipset.

OpenWRT [29] has been selected as operating system for our testbed. Open-WRT is a minimalist BusyBox/Linux distribution released under a GPL license.It provides an automated system for downloading the source code for both thekernel and the userspace tools, and compiling it to work on any supported plat-form. Moreover, it is characterized by a small memory and disk footprint makingit suitable for a wide rage of networking devices. Finally, it provides hardwareconfiguration and maintenance abstraction through a custom system and pack-age configuration facility called UCI (Universal Configuration Interface) andexploiting MIB-like structure in order to streamline device management usingSNMP [30]. Customizations to the standard OpenWRT distribution include sev-eral scripts and tools necessary to manage the virtual environments. Moreover,the original OpenWRT kernel has been with a kernel provided by OpenVZ whichwas configured and recompiled to be installed on our nodes. The software con-figuration of the wireless routers is summarized in Table 2.

AiroLAB 13

Table 2: AiroLAB Software Setup.

Operating system OpenWRT trunk (release 14748)

Linux kernel OpenVZ 2.6.18-028stab056

Wireless drivers MadWiFi trunk (release 2568)

Virtualization tools vzctl 3.0.23, vzquota 3.0.12

4.2 Experimental Settings

In order to assess the effectiveness of the AiroLAB framework in preventing traf-fic on a privileged slice being affected by traffic from other (lower–priority) slices,the scenario described in 3.1 has been set up. Evaluation of multi–radio/multi–channel setting with asymmetric link is left as future work. Moreover, comparisonwith a purely Space Division Multiplexing (SDM) approach is out of the scopeof this work in that (i), such a study has already been carried out in [15, 20], and(ii) the particular deployment scenario envisioned for AiroLAB, namely virtu-alization of production–quality networks, would require a experimental stagingnetwork which would undermine the proposed system’s main goal of sharing asingle infrastructure for both paying services and experimentation activities.

The network deployment is sketched in Fig. 5 and consists of two wirelessnodes, each one running two or more slivers (or virtual nodes) sharing the samewireless interface. The experimental setup includes a wireless node connectedto a PC lying on a desk in Office 1. Changes in link quality are emulated bymoving the second node from Office 1 to another room. A continuous UDP flow isgenerated among the two nodes; its rate is such that the wireless link is alwayssaturated. Through such a test, we want to test the ability of the proposedarchitecture to effectively preserve production traffic in challenging conditions.

As described in Sec. 3, we used the HTB packet queuing discipline to controlthe outbound bandwidth of a given link. Our HTB configuration defines a trafficclass for each sliver currently active within a given node. For each class, theminimum/guaranteed (rate) and the maximum (ceil) throughput are specified.Afterward, the HTB configuration defines which packets belong to which classdepending on the source IP address. In this way, it is possible to limit theoutbound bandwidth on a per–slice basis. Figure 6 shows the node setup for thecase of two slivers: on node A, HTB ensures that the outbound bandwidth tocarry the UDP stream is divided between the two slivers as configured.

4.3 Experimental Outcomes and Analysis

As AiroLAB is concerned with the provisioning of isolation and guaranteed per-formance to a privileged slice, tests were focused on the ability to ensure isolationin terms of guaranteed throughput over the shared wireless medium. Resultshave been obtained by averaging the samples obtained as nuttcp benchmarksover 300 seconds with an averaging interval of 10 seconds. It is worth stressingthat, AiroLAB aims at providing a virtualization architecture where experimen-tal services and protocols can be tested and evaluated over a production network


Fig. 5: The testing setup involved 2 nodes deployed in a typical office environment.One of the nodes is powered by means of a a rechargeable battery and is moved aroundin order to assess the capability of the wireless channel monitor to adapt to changingoperating conditions.

Fig. 6: Representation of the packet scheduling process for the case with two slivers.

with minimal impact on the operational traffic. In such a scenario experimen-tal repeatability is traded for performance isolation between a single privilegedproduction slice and several concurrent experimental and/or monitoring slices.

In the first scenario, three slices are running simultaneously. The privilegedslice (#1) has higher transmission priority and a minimum guaranteed outboundbandwidth set to 5 Mb/s, while the remaining two slices (#2 and #3) have aminimum guaranteed outbound bandwidth of 128 Kb/s. Moreover, slice #1 and#2 have no upper bounds on the maximum throughput they can inject in thewireless link, while slice #3 has a 5 Mb/s limit. The graph plotted in Fig. 7 showsthe throughput distribution per slice in different conditions of available wirelesslink capacity. As expected, AiroLAB guarantees that, even when link conditionsare worsening, at least 5 Mb/s are allocated to slice #1 while the remaining link

AiroLAB 15

0

5

10

15

20

25

30

35

0 50 100 150 200

Thro

ughput (M

b/s

)

Time (seconds)

Channel capacitySlice #1Slice #2Slice #3

Fig. 7: Average throughput for the three slices in the first scenario. The privilegedslice #1 has a minimum guaranteed bandwidth set to 5 Mb/s. Slices #2 and #3 havea minimum guaranteed bandwidth of 128 Kb/s. Slice #3 has an upper bound to thebandwidth set to 5 Mb/s.

0

5

10

15

20

25

30

35

0 50 100 150 200

Thro

ughput (M

b/s

)

Time (seconds)

Channel capacitySlice #1Slice #2Slice #3

Fig. 8: Average throughput for the three slices in the second scenario. The privilegedslice #1 has a minimum guaranteed bandwidth set to 5 Mb/s. Slices #2 has an upperbound to the bandwidth set to 5 Mb/s.

capacity is left available for use in a best effort fashion. It is worth noting that ifthe link capacity is lower than 5 Mb/s only slice #1 will be allowed to transmit.

In the second scenario, the privileged slice has 5 Mb/s of guaranteed out-bound bandwidth, while Slice #2 and #3’s outbound bandwidth is limited to 5Mb/s. The results, reported in Fig. 8, show that the upper bound limit imposedto both slice #2 and #3 lets the maximum throughput experienced by slice #1be higher than in the previous scenario. It is worth noting that, the throughputof slice #1 can go below 5 Mb/s if the radio conditions become bad, however thisis an expected behavior given the volatile nature of the communication medium.

The third scenario presents two slices only, where one slice requires a limitedbut stable available bandwidth. The privileged slice (#1) has higher priorityand a minimum guaranteed outbound bandwidth set to 2 Mb/s and an upperbound of 3 Mb/s, while slice #2 has a minimum guaranteed outbound bandwidthset to 128 Kb/s. The results, reported in Fig. 9, show that also in the worse


0

5

10

15

20

25

30

35

0 50 100 150 200

Thro

ughput (M

b/s

)

Time (seconds)

Channel capacitySlice #1Slice #2

Fig. 9: Average throughput for the two slices in the third scenario. The privileged slice(#1) has a minimum guaranteed outbound bandwidth set to 2 Mb/s and an upperbound of 3 Mb/s. #2 has a minimum guaranteed outbound bandwidth set to 128Kb/s.

Table 3: Overhead introduced by the AiroLAB wireless channel monitor.

Scenario #1 Scenario #2 Scenario #3

Average 0,22 0,24 0,12

Minimum 0,11 0,12 0

Maximum 0,40 0,38 0,41

Std Deviation 0,09 0,07 0,08

Confidence interval (95%) ±0,01 ±0,01 ±0,01

working condition, AiroLAB guarantees the outbound throughput of slice #1by adaptively tuning the bandwidth provided to slice #2.

We further evaluated the efficiency of the proposed framework, in terms ofoverhead introduced by AiroLAB. We considered the following performance met-ric, which represents the share of the channel capacity that remains unused:

η =

C −∑

i

θi

C, (2)

where C is the total capacity available and θi is the throughput of slice #i.The results, averaged over each single test, are reported in Table 3.

5 Related Work

Other groups have proposed mechanisms to obtain virtualization in wirelessnetworks. All of them have been focusing mainly on using network virtualizationto run large–scale testbeds where several experiments could run concurrentlyon the same physical infrastructure. Very few have been considering how toleverage these techniques in real production networks. Due to their strong focuson creating a stable testing environment where experiments should be repeatable

AiroLAB 17

and should not affect each other when running on concurrent slices, most of theworks have focused on evaluating wireless virtualization strategies. This hasbeen obtained by exploring both dimensions of (i) virtualization of the wirelessmedium and (ii) virtualization of the network node.

In [14], the authors have presented their experiences in the design and imple-mentation of a TDM-based wireless virtualization on a large-scale indoor 802.11wireless testbed facility (ORBIT). Two major challenges have been identified:

– node synchronization, where NTP mechanisms do not provide an adequatelevel of precision to allow all network nodes to perform tasks at specific times;

– device state, due to the limited access to the state stored on the wirelessdevices.

Even though more expensive mechanisms to guarantee node synchronizationcould be potentially used (based, e.g., on the use of GPS), the main outcomeof this paper is that TDM presents limits in the virtualization of the wirelessmedium.

The work presented in [15] compares two wireless virtualization strategies:SDM and Virtual Access Points. VAP is a logical abstraction running on a physi-cal AP while emulating the behavior of a conventional AP to all network stations.Compared to a TDM mechanism, VAP does not require strict synchronizationamong different nodes. However, this scheme is limited to fixed star topologiesand it needs traffic shaping mechanism to ensure fair access to wireless resourcesamong experiments. The paper reveals benefits and weaknesses for both space(SDM) and time separation (VAP) schemes. Furthermore, it provides a policymanager for controlling inter-experiment interference by assigning and enforc-ing bandwidth assigned to each slice in VAP-based testbeds. However, the mainlimitation of the proposed approach is that incorporating arbitrary topologies ina slice or across VAPs allocated to the experiment is not feasible.

A detailed analysis of the performance of an FDM based mechanism forvirtualizing wireless networks is presented in [20]. Virtualization is obtainedhere by using multiple wireless interfaces per node and by assigning differentchannel frequencies to each interface. Then, each interface is assigned to a virtualdevice running inside the wireless node. A performance comparison betweena virtualized radio node and a non–virtualized one is presented in terms ofthroughput, delay, and jitter. Cross–coupling effects between two experimentshave been investigated by studying the transient behavior associated with suddenchanges in traffic on one of the slices. While showing the advantage of FDMas robust wireless virtualization strategy (and feasible, due to the widespreadavailability of multi-radio devices), this paper highlights the limitations of aUser-Mode Linux (UML) approach to node virtualization, especially in specificexperimental conditions (e.g. UDP experiments using small packets or whenworking in saturation conditions).

In [31] the authors compared the performance of two different node virtual-ization approach: UML and OpenVZ, while considering FDM as the option forthe virtualization of the wireless medium. OpenVZ shows more stable behavior


than UML with UDP experiments using small packets as well as when workingin link saturation; it also provides excellent isolation in terms of the observedtransient response of the experiments.

While OpenFlow has some similarities with AiroLAB’s objectives, especiallyin term of sharing a production network with experimental traffic [32], this ini-tiative does not focus on a virtualization mechanism, but instead leverages anovel architecture to control the traffic passing through switches and APs byidentifying flows and policies for handling them.

6 Conclusions and Discussion

In this paper, we have presented AiroLAB, a wireless network virtualization solu-tion aimed at providing suitable means to support experimental testing of novelnetworking solutions on production networks, while preserving guarantees per-formance for production traffic. The design choices at the basis of AiroLAB havebeen presented and discussed. A prototype implementation has been presented,and outcomes of experimental activities, performed on a small-scale testbed,reported and discussed.

While the results presented appear encouraging, the framework needs to befurther developed before reaching the stability level needed to support its widedeployment. One research direction that appear of interest for enhancing the cur-rent architecture (mainly in terms of efficiency and scalability) is to use an FDMapproach, whereby different slices are associated with a dedicated wireless in-terface in a multi–radio deployment. Finally, we intend to integrate AiroLAB’swireless networks virtualization capabilities within currently available frame-works for automatic NV resources allocations, such as OMF [21].

References

1. A. Feldmann, M. Kind, O. Maennel, G. Schaffrath, and C. Werle, “Network Vir-tualization: An Enabler for Overcoming Ossification,” ERCIM News, vol. 77, pp.21–22, April 2009.

2. P. Papadimitriou, O. Maennel, A. Greenhalgh, A. Feldmann, and L. Mathy, “Im-plementing Network Virtualization for a Future Internet,” in Proc. of 20th ITC

Specialist Seminar on Network Virtualization, Hoi An, Vietnam, 2009.3. N. M. K. Chowdhury and R. Boutaba, “Network Virtualization: State of the Art

and Research Challenges,” IEEE Communications Magazine, July 2009.4. “Technical Document on Overview Wireless, Mobile and Sensor Networks,” The

GENI Project Office, Tech. Rep. GDD-06-14, 2006.5. GENI project, http://www.geni.net.6. 4WARD project, http://www.4ward-project.eu.7. FEDERICA project, http://www.fp7-federica.eu.8. AKARI project, http://akari-project.nict.go.jp.9. R. Bruno, M. Conti, and E. Gregori, “Mesh Networks: Commodity Multihop Ad

Hoc Networks,” IEEE Communications Magazine, vol. 43, no. 3, pp. 123 – 131,Mar. 2005.

AiroLAB 19

10. I. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey,” Elsevier

Computer Networks, vol. 47, no. 4, pp. 445 – 487, Mar. 2005.11. Planet Lab project, http://www.planet-lab.org.12. VINI project, http://www.vini-veritas.net.13. German-Lab project, http://www.german-lab.de/.14. G. Smith, A. Chaturvedi, A. Mishra, and S. Banerjee, “Wireless Virtualization on

Commodity 802.11 Hardware,” in Proc. of ACM WinTECH, Montreal, Quebec,Canada, 2007.

15. R. Mahindra, G. Bhanage, G. Hadjichristo, I. Seskar, D. Raychaudhuri, andY. Zhang, “Space Versus Time Separation for wireless virtualization On an In-door Grid,” in Proc. of EURO NGI, Krakow, Poland, 2008.

16. Orbit Lab, http://www.orbit-lab.org/.17. N. Feamster, L. Gao, and J. Rexford, “How to lease the Internet in your spare

time,” ACM SIGCOMM Computer Communications Review, pp. 61–64, January2007.

18. Y. Zhu, R. Zhang-Shen, S. Rangarajan, and J. Rexford, “Cabernet: Connectivityarchitecture for better network services,” in Proc. of Workshop on Rearchitecting

the Internet, 2008.19. G. Schaffrath, C. Werle, P. Papadimitriou, A. Feldmann, R. Bless, A. Greenhalgh,

A. Wundsam, M. Kind, O. Maennel, and L. Mathy, “Network Virtualization Archi-tecture: Proposal and Initial Prototype,” in Proc. of ACM SIGCOMM Workshop

on Virtualized Infastructure Systems and Architectures, Madrid, Spain, 2009.20. S. Singhal, G. Hadjichristo, I. Seskar, and D. Raychaudhuri, “Evaluation of UML

based wireless network virtualization,” in Proc. of EURO NGI, Krakow, Poland,2008.

21. OMF, cOntrol and Management Framework, http://omf.mytestbed.net.22. Linux Wireless, http://linuxwireless.org/.23. OpenVZ, http://openvz.org/.24. Linux-VServer, http://Linux-VServer.org/.25. E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “The Click

modular router,” ACM Transaction on Computer System, vol. 18, no. 3, pp. 263– 297, Aug. 2000.

26. A. Nakao, R. Ozaki, and Y. Nishida, “Corelab: An emerging network testbed em-ploying hosted virtual machine monitor,” in Proc. of ACM ROADS, Madrid, Spain,2008.

27. Linux Radiotap, http://www.radiotap.org/.28. “PC Engines.” [Online]. Available: http://www.pcengines.ch/29. “OpenWRT Linux Distribution.” [Online]. Available: http://openwrt.org/30. J. Case, M. Fedor, M. Schoffstall, and J. Davin, “A simple network management

protocol,” IETF RFC 1157, May 1990, http://www.ietf.org/rfc/rfc1157.txt.31. G. Bhanage, I. Seskar, Y. Zhang, and D. Raychaudhuri, “Evaluation of OpenVZ

for wireless testbed virtualization,” WINLAB Rutgers University, Tech. Rep. 331,2008.

32. OpenFlow project, http://www.openflowswitch.org.

airolab: a framework toward eﬀective virtualization of...

Documents