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

Wireless extensions to the PlanetLab infrastructure Giovanni Di Stasi Consorzio Interuniversitario Nazionale per l’Informatica CINI Università di Napoli “Federico II” 1 Onelab Information Day - Napoli, 22/07/ 2008

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. 2 Onelab Information Day - Napoli, 22/07/ 2008

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 3 Onelab Information Day - Napoli, 22/07/ 2008

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 4 Onelab Information Day - Napoli, 22/07/ 2008

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 5 Onelab Information Day - Napoli, 22/07/ 2008

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 6 Onelab Information Day - Napoli, 22/07/ 2008

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 7 Onelab Information Day - Napoli, 22/07/ 2008

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 8 Onelab Information Day - Napoli, 22/07/ 2008

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 onelab00.dis.unina.it ■ onelab04.inria.fr 9 Onelab Information Day - Napoli, 22/07/ 2008

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 10 Onelab Information Day - Napoli, 22/07/ 2008

A simple UMTS experiment (3) ● Experiment results 11 Onelab Information Day - Napoli, 22/07/ 2008

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 12 Onelab Information Day - Napoli, 22/07/ 2008

Experiment 2 setup UMTS SIP OK & RTP flows Internet Non-OneLab node UoN running SIP softphone SIP INVITE onelab00.dis.unina.it Private OneLab coroglio.comics.unina.it node with UMTS running Asterisk 13

14

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) 15 Onelab Information Day - Napoli, 22/07/ 2008

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 16 Onelab Information Day - Napoli, 22/07/ 2008

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 17 Onelab Information Day - Napoli, 22/07/ 2008

Implementation details (4) ● 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 18 Onelab Information Day - Napoli, 22/07/ 2008

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) 19 Onelab Information Day - Napoli, 22/07/ 2008

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 operation and a wifi interface connected to the wifi ad-hoc network for experiments Internet 20 Onelab Information Day - Napoli, 22/07/ 2008

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 21 Onelab Information Day - Napoli, 22/07/ 2008

Example of a gateway service ● Monitoring information centralization  Remote administration tools can access this monitoring module to get information about this multi- hop network Onelab network Gateway The gateway collects, computes and stores in database the monitoring information. 22 Onelab Information Day - Napoli, 22/07/ 2008

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 23 Onelab Information Day - Napoli, 22/07/ 2008