Wireless extensions to the PlanetLab infrastructure Giovanni Di - - PowerPoint PPT Presentation

1

Wireless extensions to the PlanetLab infrastructure

Giovanni Di Stasi

Consorzio Interuniversitario Nazionale per l’Informatica CINI Università di Napoli “Federico II”

Onelab Information Day - Napoli, 22/07/ 2008

2

Onelab goals

• Federate

 Provide an European administration for Onelab nodes

in Europe.

• Deepen

 Deepen PlanetLab monitoring capabilities.

• Extend

 Extend PlanetLab into new environments, beyond the

traditional wired Internet.

Onelab Information Day - Napoli, 22/07/ 2008

3

Onelab wireless extension

• WiMAX

 Université Catholique de Louvain

• Wireless ad hoc networks

 France Telecom

• Emulated links

 Università di Pisa

• UMTS

 Università di Napoli & Alcatel Italia Onelab Information Day - Napoli, 22/07/ 2008

4

Good reasons for UMTS

• UMTS is a third generation (3G) cell-phone tecnology

 First Generation (1G) mobile systems were designed

to offer a single service, i.e., speech.

 Second Generation (2G) mobile systems were also

designed primarily to offer speech with a limited capability to offer data at low rates.

• UMTS as a 3G tecnology is designed to offer both

speech and data (at higher rates)

 Is capable to deliver new kinds of services

■Video calls, streaming video, etc. ■Real WWW access

Onelab Information Day - Napoli, 22/07/ 2008

5

UMTS properties

• Packet oriented, IP transport
• Asymmetric data rates for up-link/down-link

 Up to 7.2 Mb/s in downlink and 2.0 Mbit/s uplink (with

hsdpa)

• Roaming between UMTS and GSM as well as satellite

networks

• It is a big step towards the unification of voice and data

networks

Onelab Information Day - Napoli, 22/07/ 2008

6

UMTS in OneLab

• Private UMTS micro-cell made available by ALCATEL

ITALIA

 At 3G Reality Center in Vimercate

• Public UMTS connectivity

 used at CINI laboratory in Napoli

• Both types of connectivity have their motivations

 A private UMTS network can be adapted and

configured to match the experiment requirements

 Public UMTS connectivity is widely available and

better suited to replicate real world scenarios

Onelab Information Day - Napoli, 22/07/ 2008

7

UMTS in OneLab: usage model

• The Ethernet interface is used for control data and UMTS

for the experiments

 The default route is set to the Ethernet interface

• A slice user can use the UMTS connection

 specifying the destinations for which the UMTS connection

is required

 by explicitly setting the UMTS ppp interface as the source

IP address

Onelab Information Day - Napoli, 22/07/ 2008

8

UMTS in OneLab: usage model (2)

• Users control the umts interface by means of a

special command

• umts commands:

■umts start, to start the connection ■umts stop, to stop the connection ■umts status, to check the status of the connection ■umts add/del destination address/netmask, to add a

destination

• Proper mechanisms (a la sudo) need to be used to

perform actions requiring root permissions on the node

Onelab Information Day - Napoli, 22/07/ 2008

9

A simple UMTS experiment

• Programs utilized: umts frontend and D-ITG

 D-ITG is a traffic generator and measurement tool

developed by the COMICS group at University of Napoli;

UMTS Internet

■onelab04.inria.fr

• nelab00.dis.unina.it

Onelab Information Day - Napoli, 22/07/ 2008

10

A simple UMTS experiment (2)

• Commands issued:

■ssh -l pl_umts onelab00.dis.unina.it ■umts start ■umts add 138.96.250.144 #id address of onelab04.inria.ft ■ITGSend -a 138.96.250.144 -C 122 -c 1024 -x log ■umts del 138.96.250.144 ■ITGSend -a 138.96.250.144 -C 122 -c 1024 -x log

Onelab Information Day - Napoli, 22/07/ 2008

11

A simple UMTS experiment (3)

• Experiment results

Onelab Information Day - Napoli, 22/07/ 2008

12

Voip-over UMTS: simple ex. 2

• The purpose of this experiment is to show the kind of

experiments that can be executed thanks to the UMTS gateway

 Simple echo test

• UMTS Node with Asterisk
• Non-Onelab node with Ekiga

 Difficulties in performing these experiments in OneLab

nodes

■No X server running → CLI-based application ■No sound card driver → use of tools supporting

recorded TRP dumps

Onelab Information Day - Napoli, 22/07/ 2008

13

Experiment 2 setup

UMTS Internet UoN

• nelab00.dis.unina.it

coroglio.comics.unina.it

SIP INVITE

SIP OK & RTP flows

Private OneLab node with UMTS running Asterisk Non-OneLab node running SIP softphone

14

15

UMTS in OneLab: implementation details

• Kernel-level drivers had to be integrated in the Linux kernel of

OneLab nodes

• User level PPP daemon and auxiliary tools (gcom, wvdial and

umts-tools) included in the Private Onelab package repository

 Kernel drivers and userlevel software automatically installed

when node is added to the UMTS nodegroup

• The umts-tools implement the user interface and manage the

UMTS interface (by calling the helper tools gcom and wvdial)

Onelab Information Day - Napoli, 22/07/ 2008

16

Implementation details (2)

• In order to overcome the necessity of running the programs

that need root privileges, the umts-tools exploit a new feature recently included in PlanetLab: vsys

• vsys allows a program that runs in the slice context (the umts

program in our case) to communicate with another program (backend) that runs in the root context

 To make that possible vsys creates two named pipe in the slice

context

■what the frontend writes in the first pipe is receveid by the

backend program

■What the backend writes in the second pipe is received by the

frontend program

Onelab Information Day - Napoli, 22/07/ 2008

17

Implementation details (3)

• What the backend does: it starts and stops the connection and checks

the UMTS status using wvdial

• Creates a new routing table to be used by the slice with only a default

rule (using iproute2) – that is to work out the multi-homing issue:

 ip route add default dev ppp0 table 10

• Adds a rule in order to use the routing table just created for each

destination specified by the user in the frontend

 ip rule add to <dest_ip/dest_netmask> fwmark <slice_mark> table 10

• Only packets generated inside the slice and directed to one of the

destinations specified by the user will get routed through the UMTS interface according to the forwarding rules included in table 10

Onelab Information Day - Napoli, 22/07/ 2008

18

• The backend program also adds a rule in order to have packets with

source address equal to the UMTS interface address routed through the UMTS interface:

 ip rule add from <ppp0_ip> fwmark <slice_mark> table 10  But how does the user set the source ip address?

Ex: wget --bind-address <umts_int_ip> http://some/where/something

• It also adds with iptables rule in order to avoid other slices to use the

UMTS interface:

 Discard every packet not marked and using dev ppp0 as output interface

Implementation details (4)

Onelab Information Day - Napoli, 22/07/ 2008

19

Future of the UMTS component after OneLab

• Will it be part of PLE after the end of OneLab ?

 The software has been integrated into the OneLab repository, so

if we find a PLE member wishing to pay for UMTS connectivity, there is a chance for UMTS to survive

 Expression of Interest in using the UMTS work done in OneLab

by Sue Moon at KAIST (Korea) in June

 Mobile Telecom European operators might be asked to offer

limited UMTS connectivity for experimental purposes

■ First contacts with Vodafone Italy

 UMTS connectivity might be paid by slice owners using it (in a

PlanetLab gold – like scenario)

Onelab Information Day - Napoli, 22/07/ 2008

20

Wireless Ad-Hoc Component

• The objective has been to integrate Wireless Ad-hoc

Networks to Planetlab

• Chosen architecture:

 Access to the private networks is made possible by

Onelab nodes that act as gateways

■These nodes have a wired interface for management

• peration and a wifi interface connected to the wifi ad-hoc

network for experiments

Internet Onelab Information Day - Napoli, 22/07/ 2008

21

Wireless Ad-Hoc Component (2)

• Ad hoc nodes without Onelab code

 More flexibility in network and node configuration  Possibilities to have different kinds of nodes

• Gateway contains particular functions providing services

 For monitoring purposes  For network services  ...

• Other approach was to have Onelab code in every node

 Less choice in terms of kinds of nodes  Onelab nodes without an Ethernet connection

Onelab Information Day - Napoli, 22/07/ 2008

22

Example of a gateway service

• Monitoring information centralization

 Remote administration tools can access this

monitoring module to get information about this multi- hop network

Gateway Onelab network

The gateway collects, computes and stores in database the monitoring information.

Onelab Information Day - Napoli, 22/07/ 2008

23

Wireless Ad-Hoc Component (3)

• The gateway has a IEEE 802.11g wireless interface

 Supported by the madwifi driver, added to the Onelab

codebase

• Ad-hoc networks comprise notebooks and PDAs with

a wifi IEEE 802.11g wireless interface

 Madwifi for notebooks, hostap for the PDAs

• Olsr protocol for routing inside the Ad-hoc network

 UNIK implementation with some modifications that

account per-packet signal/noise data provided by kernel drivers

Onelab Information Day - Napoli, 22/07/ 2008

24

Dummynet Box Component

• A Dummynet box emulates wireless links with user-

specified characteristics

Onelab Information Day - Napoli, 22/07/ 2008

25

Dummynet Box Component (2)

• Configurable parameters of the wireless link:

 MAC side effects:

■association delay ■link level retransmissions ■raw bandwidth

• Support for run-time variations of these parameters

Onelab Information Day - Napoli, 22/07/ 2008

26

Setup of a Dummynet Box

• Users issue a command on a node to define an emulated wireless link

for a certain port/IP (individual or range)

• The DBox checks credentials (downloaded periodically from the PLC),

verifies conflicts for the same port/IP, and install/updates the rules

• Rules are deleted explicitly or on a timeout.

Onelab Information Day - Napoli, 22/07/ 2008

27

WiMAX component

• Objective:

 Extends PlanetLab with WiMAX connectivity

• Problems in getting the license

 Received only on June 9th  Valid until December 31st 2008

• Currently no private testbed available (they are working on

it)

Onelab Information Day - Napoli, 22/07/ 2008

28

Conclusions

• Wireless extensions to OneLab

 Useful for researchers  Challenging for developers

■How to share wireless resources (usage model) ■How to manage heterogeneous nodes (nodegroups) ■How to let users execute privileged commands ■How to do slice-specific routing

• Lessons learned

 In OneLab we followed a bottom-up approach, and specific

solutions were adopted for each wireless extension

 In the future we might recognize a few general “design patterns” to

be adapted to any possible extension

29

WiMAX testbed

• Some measurements perfomed

with a public provider

• Traffic sent from LABO to

WiMAX and vice versa

 Wireless link of 200 m  10 minutes every two hours Onelab Information Day - Napoli, 22/07/ 2008

30

WiMAX experiment result

Onelab Information Day - Napoli, 22/07/ 2008