Facolta di Ingegneria. Tesi di Laurea Specialistica Classe delle lauree specialistiche in Ingegneria Informatica Classe n. 35/S

Transcript

1 Universita degli Studi di Napoli ƒfederico II Facolta di Ingegneria CORSO DI STUDI IN Ingegneria Informatica Tesi di Laurea Specialistica Classe delle lauree specialistiche in Ingegneria Informatica Classe n. 35/S Integrazione e controllo di applicazioni per la valutazione automatica della qualità di flussi VoIP su testbed virtuali OMF RELATORE Ch.mo Prof Roberto Canonico Correlatore Ing. Roberto Bifulco Ing. Giovanni Di Stasi CANDIDATO Pasquale Germino Matr. 885/186 ANNO ACCADEMICO 2009/2010

2 Tesi di Laurea Specialistica Classe delle lauree specialistiche in Ingegneria Informatica Classe n. 35/S Integrazione e controllo di applicazioni per la valutazione automatica della qualità di flussi VoIP su testbed virtuali OMF Relatore Ch.mo prof. Roberto Canonico Correlatori Ing. Roberto Bifulco, Ing. Giovanni Di Stasi Candidato Pasquale Germino matr. 885/186 Anno Accademico 2009/2010

3 Sommario Questo lavoro ha come obiettivo la valutazione della qualità fonica su reti IP virtuali, utilizzando il MOS(Mean Opinion Score). Nello specifico, la rete di valutazione è stata realizzata utilizzando Neptune, un sistema di emulazione di reti implementato presso l Università ƒfederico II di Napoli. Per quello che riguarda la valutazione del MOS sono stati utilizzati due applicativi, OMF e DITG, il primo un framework per controllare e gestire testbed di rete, il secondo una piattaforma in grado di produrre traffico su reti IP realizzata anch essa presso l Università Federico II di Napoli. Al termine degli esperimenti abbiamo valutato i risultati ottenuti nella rete virtuale confrontandoli con quelli ottenuti in una rete reale. I

4 Indice 1 Sistemi di emulazione cluster-based Cluster Virtualizzazione Virtualizzazione Completa Paravirtualizzazione Xen Emulazione Assistita Creazione e Gestione di una Macchina Virtuale Emulazione Neptune Scopo Architettura Struttura Implementazione Rete Virtuale Definizione Esperimento Dipendenze Descrittore Del Cluster Stati Di Un Esperimento Descrittore Topologia Come si usa OMF Scopo II

5 3.2 Architettura Aggregate Manager Experiment Controller Resource Controller Struttura Servizi installati Gestione dei collegamenti Server di scambio messaggi Database Flusso tipico di un esperimento Come si usa Tecniche e strumenti per la valutazione della qualità dei servizi VoIP MOS - Mean Opinion Score Metodi di misura della qualità fonica E-model DITG - Distributed Internet Traffic Generator Struttura di Esperimento Esperimento su Neptune Script di Test Analisi dei Risultati Grafici Mos Conclusioni e Sviluppi 47 A Installazione Xen 48 A.1 Installazione e configurazione di xend e configurazione bridge. 48 A.2 Creazione macchine virtuali (domu) A.3 Creazione Macchina Virtuale B Installazione Omf 53 B.1 MySql e PhpMyAdmin III

6 B.2 Aggregate Manager B.3 Experiment Controller B.4 XMPP-Extensible Messaging and Presence Protocol B.5 Resource Controller C Script Di Configurazione 59 C.1 topology.xml C.2 conf agm.xsl C.3 conf nodo.xsl C.4 conf nodo.xsl C.5 totale.sh Bibliografia 64 IV

7 Elenco delle figure 1.1 Architettura Xen Architettura Neptune Esperimento in Neptune Descrittore Cluster Neptune Stati di un esperimento Neptune Accesso Neptune Esperimento in OMF Architettura di OMF Struttura di OMF Layout suggerito Ciclo di vita di un esperimento in OMF Transmission Rating Factor Categorie di Qualità di Trasmissione Architettura D-ITG Struttura Di Test Neptune Struttura Di Test UFAM-UFC Decodifica D-ITG Mos 34 Mbps - 8 Mbps Mos 8 Mbps -34 Mbps Mos 34 Mbps - 8 Mbps Mos 8 Mbps -34 Mbps Mos 34 Mbps - 8 Mbps V

8 4.12 Mos 8 Mbps -34 Mbps A.1 Output Xen A.2 Xm List B.1 Installazione MySql B.2 Configurazione My Sql B.3 Amministrazione Openfire VI

9 Capitolo 1 Sistemi di emulazione cluster-based 1.1 Cluster Un computer cluster, o più semplicemente denominato cluster, è un insieme di computer connessi tramite una rete telematica. Lo scopo di un cluster è quello di distribuire una elaborazione molto complessa tra i vari computer componenti il cluster. In sostanza un problema che richiede molte elaborazioni per essere risolto viene scomposto in sottoproblemi separati i quali vengono risolti in parallelo. Questo ovviamente aumenta la potenza di calcolo del sistema. Fra le applicazioni che meglio si adattano ad essere implementate su cluster c è la virtualizzazione di risorse. 1.2 Virtualizzazione Con il termine Virtualizzazzione viene indicata la tecnologia per suddividere le risorse di un computer in diversi ambienti di esecuzione utilizzando varie tecniche di astrazione hardware e software in modo da separare l interfaccia logica dal computer fisico. Alle origini, negli anni 60, la virtualizzazione era una tecnica per ottimizzare l uso di risorse informatiche molto costose e relativamente rare, il proliferare 1

10 di server e PC ha creato la necessità di gestire e utilizzare in modo più efficiente queste risorse. La virtualizzazione delle infrastrutture è oggi una forte tendenza di settore, sebbene il concetto di virtualizzazione si diffonda ormai già da alcuni anni, perchè consente alle aziende di utilizzare in maniera più efficiente le risorse hardware e di ridurre i costi di gestione delle infrastrutture IT. Negli utimi anni è diventata la linea guida per lo sviluppo di nuovi processori nell ottica del risparmio energetico e nella necessità di aumentare le misure della sicurezza es. VMware Workstation, Virtual PC, e VirtualBox. La macchina virtuale o virtual machine nasce proprio dalla necessità di avere elevati standard di sicurezza su macchine che contengono dati sensibili. La stessa Intel ha contribuito al progetto Xen introducendo il supporto per la sua tecnologia VT-X 1 che se viene eseguito su sistemi dotati di questa caratteristica, Xen permette di creare delle macchine virtuali che consentono ai sistemi operativi ivi installati di girare senza modifiche, tecnologia simile, denominata AMD-V 2, sviluppata da AMD consente di ottenere lo stesso risultato con sistemi basati su processori AMD. Le diverse tecnologie di virtualizzazione sono le seguenti: ˆ Virtualizzazione Completa; ˆ Paravirtualizzazione; ˆ Emulazione assistita; Virtualizzazione Completa La Virtualizzazione Completa, consente l esecuzione di sistemi operativi non modificati (o non modificabili per ragioni di licenza) in un ambiente totalmente ricreato ed isolato dal sistema operativo che lo ospita; tale ambiente è realizzato da un apposito software che si occupa di emulare l hardware necessario traducendo le istruzioni eseguite dal sistema ospite in qualcosa che il Intel 1 Virtualization Technology 2 AMD Virtualization 2

11 sistema operativo ospitante sia in grado di eseguire. Come è possibile intuire la traduzione di ogni singola istruzione è molto onerosa a livello di potenza di calcolo, per ovviare a ciò è necessario eseguire la maggior parte delle istruzioni in modo nativo. Sebbene quindi esistano emulatori di CPU differenti dall architettura x86, come ad esempio Qemu che è in grado di emulare ARM, Alpha, MIPS, SPARC o Hercules che emula System/370, questi emulatori tendono ad essere molto lenti poichè devono tradurre ogni istruzione verso l architettura x86, eseguirla, e quindi tradurne il risultato verso l architettura emulata. Imponendo quindi un limite sull architettura virtualizzata (x86 virtualizza solo x86), è possibile velocizzare notevolmente l esecuzione dei sistemi guest mappando direttamente memoria e CPU(per quanto riguarda le istruzioni accessibili). Questo limite rende però impossibile virtualizzare sistemi x86 64 se il sistema operativo di base è i386, ciò succede perchè l architettura i386 prevede l esecuzione di codice in due modalità: ˆ Real Mode dove ogni processo ha completo accesso a tutto l hardware; ˆ Protected Mode vengono creati diversi livelli di protezione che possono essere immaginati come anelli concentrici sempre più restrittivi man mano che si procede verso l esterno Paravirtualizzazione La Paravirtualizzazione è una tecnica in cui il sistema operativo virtualizzato riesce a comunicare direttamente con il motore di virtualizzazione chiamato hypervisor. Questo comporta la necessità di modificare il kernel del sistema operativo da virtualizzare risultando problematico nel caso di prodotti come Windows che, per motivi di licenza, non permettono tale modifica. Mentre Xen 3 permette l installazione di sistemi operativi Linux con kernel modificato e driver personalizzati. Il vantaggio nell usare la paravirtualizzazione consiste nella maggior velocità di esecuzione delle applicazioni utente. 3 XEN-monitor di macchine virtuali Open Source 3

12 Figura 1.1: Architettura Xen 1.3 Xen Xen[2] è un monitor di macchine virtuali Open Source rilasciato sotto licenza GPL per piattaforma x86 e compatibili sviluppato presso il Computer Laboratory dell Università di Cambridge. Xen introduce modifiche sia nelle macchine host che nelle macchine guest. La macchina in cui verrà fatta la virtualizzazione (cioè, la macchina host) non sarà più una macchina x86, ma diventa una macchina con architettura Xenx86 e i sistemi operativi che si vogliono virtualizzare devono essere adattati per questa architettura. Xen è sostanzialmente un sottile strato software posto sopra l hardware (Figura 1.1). Questo strato è chiamato hypervisor e si interpone tra le macchine virtuali e l hardware, quest ultimo schedula gli accessi alle risorse fisiche della macchina ospite, da parte delle varie istanze delle macchine virtuali. Il primo sistema operativo guest, chiamato nella terminologia Xen Domain- 0, è caricato automaticamente quando l hypervisor si avvia e ottiene speciali privilegi di gestione e l accesso diretto all hardware della macchina reale. L amministratore di sistema effettua il login al Domain-0 per avviare qualunque operazione sui sistemi operativi guest, chiamati Domain-U. 4

13 1.3.1 Emulazione Assistita Emulazione assistita è conosciuta anche come Accelerated Virtualization o con nomi diversi a seconda del produttore. Xen la chiama Hardware Virtual Machine. Questa tecnica si appoggia a speciali funzioni della CPU (Intel VT e AMD-V) e permette l esecuzione direttamente in hardware di alcune chiamate della macchina virtuale. Con questa tecnica possiamo avere come guest sistemi x86 64 nonostante il sistema ospitante sia i Creazione e Gestione di una Macchina Virtuale Per creare una macchina virtuale devono essere definite le caratteristiche hardware, questo deve essere fornito mediante un file di configurazione o un dispositivo di memoria, per la parte software viene utilizzata di solito una immagine che contiene al suo interno l intera configurazione del file system, dai file di installazione del sistema operativo a quelli delle applicazioni. Xen, per la configurazione hardware prevede un file che rispetti lo schema seguente. kernel = "/xen/vmlinuz xen" ramdisk = "/xen/initrd xen" root= "/dev/hdb5 ro" disk = [ phy:/dev/hdb5,hdb5,w, file:/xen/swap.img,hda2,w ] memory = 64 vcpus = 1 builder = linux name = vm1 vif = [ mac=00:16:3e:65:3a:ca, bridge=xenbr0 ] dhcp = dhcp localtime = 0 on_poweroff = destroy on_reboot = restart on_crash = restart extra = TERM=xterm 5

14 Dove sono specificati i seguenti parametri: ˆ kernel: indica kernel utilizzato per l avvio; ˆ ramdisk: indica ramdisk utlizzato; ˆ root: indica la partizione della directory root del domu ; ˆ disk: indica il supporto fisico, il flag w indica che è accessibile in scrittura e viene utilizzato un file immagine come partizione di swap; ˆ memory: indica la memoria utilizzata in questo caso 64 MB ˆ vcpu: indica le cpu virtuali utilizzate; ˆ name: indica il nome del dominio domu ˆ vif: assegna un mac alla scheda di rete e la collega al bridge sul dom0 ; ˆ dhcp: indica l assegnamento automatico di Ip; ˆ localtime: attribuisce al domu lo stesso orologio in uso sul dom0 ; ˆ extra: indica come avviare il kernel; ˆ on poweroff, on reboot, on crash: indicano come gestire il dominio in caso di spegnimento, riavvio e crash. Una volta specificate entrambe queste informazioni, è possibile allocare la virtual machine, in Xen, ad esempio, si può adoperare il tool xm, la cui sintassi prevede semplicemente: xm create -c configfilename dove con create viene creata la macchina, -c la avvia in autoconsole ed infine con configfilename denotiamo il file di configurazione illustrato precedentemente. Tutto il resto della gestione della macchina virtuale è possibile farlo mediante l hypervisor. 6

15 1.4 Emulazione Un emulatore nel senso più generale possibile duplica le funzioni di un determinato sistema su un secondo sistema differente dal primo, rappresenta dunque un approccio ibrido che combina elementi reali con elementi astratti. A seconda dei requisiti dell esperimento si stabilisce quali elementi debbano essere implementati realmente e quali debbano essere trattati con un certo livello di astrazione. L emulazione consente di analizzare il comportamento di un sistema reale attraverso un modello concettuale ma permette altresì di interfacciare il sistema con il mondo esterno. L emulazione, coniugando l elevato livello di realismo e l uso efficiente delle risorse, si sta affermando come tecnologia principe per l analisi di nuovi protocolli di comunicazione. Possiamo individuare due tipi di emulazione: ˆ Emulazione Software ˆ Emulazione Hardware L emulazione software non è altro che un semplice traduttore di istruzioni che rende comprensibile all ambiente sul quale l emulatore gira le istruzioni del programma emulato. Nel caso invece dell emulazione hardware sarà necessario simulare la circuiteria e il comportamento fisico del sistema, di questo tipo di emulazione fa parte l emulazione di reti da noi esaminato. In particolare l emulatore di rete è un ambiente di test, in cui sono riprodotti tutti i problemi e le caratteristiche della rete di produzione, per realizzarlo è necessario avere dispositivi in grado di introdurre problemi nell ambiente di rete ed inoltre di avere dispositivi che generano traffico simile a quello che si trova nella rete di produzione. L emulatore processa ogni pacchetto in qualche modo, in relazione al tipo di rete da emulare, inoltre l idea di base è quella di introdurre su ciascun pacchetto gli stessi problemi, che si vedrebbero sulla rete di produzione. 7

16 I principali emulatori di reti sono: ˆ Emulab[3]:un emulatore di reti che fornisce ai suoi utilizzatori una vasta gamma di funzionalità per la valutazione dei test effettuati. ˆ NetEm[4]: fornisce funzionalità di emulazione per l emulazione di reti geografiche, l attuale versione emula i parametri caratteristici di una rete come delay e Packet Loss. ˆ Dummy Net[5]: realizzato dall Università di Pisa è uno strumento originariamente concepito per testare protocolli di rete, usato anche per una varietà di applicazioni tra cui gestione della banda. ˆ Neptune: realizzato dall Università Federico II di Napoli è un emulatore di rete in cui i nodi sono macchine virtuali create utilizzando Xen e i link sono emulati utilizzando NetEm. 8

17 Capitolo 2 Neptune 2.1 Scopo Neptune (Network Emulation for Protocol Tuning and Evaluation) è un sistema per l emulazione di topologie di reti finalizzato, principalmente, alla valutazione di nuovi protocolli di comunicazione. Tale progetto è stato realizzato dall Università ƒfederico II di Napoli[6]. Gli obiettivi di questo progetto sono: ˆ Basso costo di implementazione: conseguito attraverso l uso di componenti hardware general purpose e strumenti software open source; ˆ Completo isolamento tra i diversi nodi emulati: ottenuto attraverso l uso della paravirtualizzazione offerta da XEN; ˆ Utilizzo efficace ed efficiente delle risorse disponibili: realizzato attraverso l uso di algoritmi per l allocazione delle risorse; ˆ Semplicità d uso: AJAX; grazie al livello di interazione delle applicazioni ˆ Elevate performance: derivate dal basso overhead richiesto dal funzionamento di XEN; 9

18 ˆ Sicurezza: conseguita attraverso l uso di tecnologie di comunicazione basate su tunneling SSH 1. Neptune consente l emulazione concorrente di diversi esperimenti in completo isolamento tra loro, l allocazione delle topologie di rete avviene in modo automatico. Alcune scelte progettuali fatte sono state inspirate dal sistema Emulab 2, mentre l emulazione di complesse topologie di reti è stata adottata la tecnica della paravitualizzazione attraverso l hypervisor XEN. La comunicazione tra il sistema Neptune e l hypervisor XEN avviene attraverso la libreria LibVirt, uno strato software che offre un livello di astrazione per la comunicazione con diversi tipi di hypervisor. 2.2 Architettura L organizzazione di Neptune segue un approccio centralizzato alla gestione dell intero sistema. Uno dei nodi del cluster, che definiremo Neptune Manager fornisce i servizi fondamentali (dhcp, dns, ecc..) ed ospita il software di gestione della configurazione del sistema. Da un punto di vista possiamo immaginare due livelli all interno del cluster: un livello su cui risiede il Manager, che è responsabile della realizzazione dei servizi di gestione del cluster e della comunicazione con l esterno; ed un livello su cui risiedono tutti gli altri nodi, che rappresenta l infrastruttura di emulazione vera e propria (Figura 2.1). 1 Secure Shell- Permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host 2 Emulab - Sistema per l emulazione cluster based 10

19 Figura 2.1: Architettura Neptune 2.3 Struttura Implementazione Rete Virtuale La realizzazione della rete virtuale consiste nella realizzazione di un certo numero di link bidirezionali fra determinati nodi. I nodi in questione sono macchine virtuali, gestite da hypervisor di diverse tecnologie, che risiedono su computer organizzati in un cluster, in cui la connettività è garantita da una rete LAN dove simulare i link fra i nodi con le relative proprietà (bandwidth, delay, loss rate, ecc.). E possibile adoperare sostanzialmente due tecniche di link multiplexing: ˆ IP aliasing: prevede che la definizione del link avvenga interamente al livello IP. Sulla stessa interfaccia vengono gestiti più indirizzi IP, ciascuno rappresentante un end-point di un link; ˆ One Link Per Interface: ogni end-point di un link richiede un interfaccia dedicata, ogni link, quindi, è modellato come una connessione diretta fra due interfacce di rete Definizione Esperimento Nella definizione di un esperimento sono definiti, due tipi di attori: ˆ Amministratore: ha il compito di gestire la configurazione di ogni nodo fisico facente parte del cluster; 11

20 Figura 2.2: Esperimento in Neptune ˆ Utente: definisce ed esegue esperimenti. In (Figura 2.2) è riportato uno schema di esecuzione di un esperimento Dipendenze Neptune richiede sistema operativo Linux, la versione GWT dipendenza dalle seguenti librerie: e la ˆ GWT Drag-and-Drop 2.5.6; ˆ GWTLib 1.2; ˆ gwt-canvas 0.4.0; ˆ gwt-mosaic Le seguenti librerie Java: ˆ libvirt 0.2.1; 3 GWT - Google Web Toolkit 12

21 Figura 2.3: Descrittore Cluster Neptune ˆ trilead-ssh2 build Descrittore Del Cluster Il cluster descriptor (Figura 2.3) ha il compito di descrivere la composizione, in termini di macchine fisiche, del cluster. Di ciascuna macchina, sarà descritta la composizione hardware, Ip delle interfacce di rete, il software installato e le virtual machine instanziate sulla macchina. 13

22 Figura 2.4: Stati di un esperimento Neptune Stati Di Un Esperimento Un esperimento può trovarsi nei seguenti stati: ˆ Undefined: l esperimento creato e ad esso sono stati associati un nome identificativo ed un amministratore, ma non le informazioni sulle risorse richieste; ˆ Defined: l esperimento è stato definito in tutte le sue parti, contiene anche le informazioni sulle risorse richieste; ˆ Waiting: l esperimento è in attesa di allocazione sul cluster; ˆ Running: l esperimento è pronto per l utilizzo. L ambiente di emulazione è totalmente configurato e funzionante. In (Figura 2.4) sono riportati i stati possibili in cui può trovarsi un esperimento e le possibili transizioni. 14

23 2.3.6 Descrittore Topologia Neptune per descriver la topologia utilizza il file topology descriptor.xml che descrivere in modo completo la configurazione di una particolare topologia. Di seguito viene riportata una topologia di rete descritta da Neptune costituita da 2 nodi ed un link. <?xml version="1.0" encoding="utf-8" standalone="no"?> <topology id="18apr_1"> <nodes> <node id="0"> <description/> <name/> <cpu amount="0" clock="0" name="" type=""/> <ram dimension="256"/> <hd dimension="2.0"/> <network_interfaces> <interface MAC="7E:8F:F2:23:6D:8B" name="eth0" type=""> <interface_binding type="hif"/> <ip address=" " subnetmask=" " type="control" version="4"/> </interface> <interface MAC="96:5B:1B:13:01:F1" name="eth1" type=""> <interface_binding type="bridge"/> <ip address=" " subnetmask=" " type="topology" version="4"/> </interface> </network_interfaces> <operative_system name="debian" password="antoxps" username="root" version="5.0"/> <software_configuration template="debian5_omfagr"> <sshserver port="22"/> <software name="omf-nodehandler" type="omf-software" version="5.1"/> <software name="omf-aggregatemanager" type="omf-software" version="5.1"/> </software_configuration> </node> <node id="1"> <description/> <name/> <cpu amount="0" clock="0" name="" type=""/> <ram dimension="256"/> <hd dimension="2.0"/> <network_interfaces> <interface MAC="BE:C9:87:21:DE:BF" name="eth0" type=""> <interface_binding type="hif"/> <ip address=" " subnetmask=" " type="control" version="4"/> </interface> <interface MAC="9E:6B:61:7C:5B:A8" name="eth1" type=""> <interface_binding type="bridge"/> 15

24 <ip address=" " subnetmask=" " type="topology" version="4"/> </interface> </network_interfaces> <operative_system name="debian" password="antoxps" username="root" version="5.0"/> <software_configuration template="debian5_omfnode"> <sshserver port="22"/> <software name="omf-nodemanager" type="omf-software" version="5.3"/> </software_configuration> </node> </nodes> <links> <link id="link0" type="fullduplex"> <end_point nodeid="0" type="source"> <multiplexing tech="olpi"/> <interface name="eth1"/> </end_point> <end_point nodeid="1" type="destination"> <multiplexing tech="olpi"/> <interface name="eth1"/> </end_point> <property name="bandwidth" value="100kbps"/> <property name="delay" value="0ms"/> <property name="loss" value="0.0%"/> <property name="duplicate" value="0.0%"/> <property name="corrupt" value="0.0%"/> </link> </links> </topology> 2.4 Come si usa Il sistema è accessibile attraverso una interfaccia web-based, molto interattiva, realizzata in tecnologia AJAX(Figura 2.5) Gli utenti del sistema sono divisi in due categorie: ˆ Amministratori; ˆ Utenti semplici; L amministratore ha il completo accesso a tutte le funzionalità del programma, si occupa della creazione e gestione degli utenti del sistema. E tenuto a creare nuovi esperimenti per gli utenti che ne fanno richiesta. Deve 16

25 Figura 2.5: Accesso Neptune decidere come e quando allocare un esperimento. Ha il pieno controllo delle macchine fisiche e si occupa della loro amministrazione. Il sistema gli consente di monitorare le performances dei vari nodi, inoltre può controllare l avanzamento del processo di allocazione delle topologie ed eventualmente correggere eventuali malfunzionamenti. Fornisce agli utenti dei templates di topologie per semplificare il procedimento di definizione dei nuovi esperimenti. Ha piena visione dello stato del cluster e della dislocazione dei nodi virtuali sulle macchine fisiche. L utente ha il compito di descrivere le topologie di rete da emulare e quindi fare richiesta per la loro allocazione sul cluster, e può decidere se condividere il proprio esperimento con altri utenti. La definizione di un esperimento implica la descrizione della topologia di rete. Quest - operazione, per le topologie di piccole dimensioni, può avvenire attraverso l uso di un interfaccia grafica, mentre per la descrizione di grosse topologie è conveniente descrivere la rete attraverso un file XML. Ad ogni utente viene data la possibilità di visionare solo gli esperimenti di suo intereresse, e non vedere gli esperimenti creati da altri utenti. 17

26 Capitolo 3 OMF 3.1 Scopo OMF 1 è un framework generico per controllare e gestire testbed di rete. Nel lavoro di tesi che è stato svolto, è stato utilizzato per la gestione di esperimenti su topologie di rete emulate. OMF, come detto, costituisce un ambiente di lavoro che, in generale, mette a disposizione : ˆ Un linguaggio spefico del dominio applicativo, detto OEDL 2, che permette all utente di descrivere: le risorse necessarie per un esperimento e la loro configurazione; le applicazioni da usare in un esperimento e le misure da acquisire da esse; i diversi task da compiere durante un esperimento, il tempo e gli eventi che le generano. ˆ Un insieme di strumenti software, che: accetta come ingresso l esperimento descritto in precedenza; 1 OMF - Object Management Framework 2 OEDL - OMF Experiment Description Language 18

27 Figura 3.1: Esperimento in OMF inizializza ed imposta le risorse necessarie con le configurazioni e le applicazioni con cui svolgere gli esperimenti; invia i comandi alle risorse per eseguire effettivamente gli esperimenti all istante o all evento appropriato; acquisisce dati di misura provenienti dalle applicazioni e/o dalle risorse. Come detto in precedenza, OMF ha in ingresso uno script descritto in OEDL, disloca e configura questo esperimento sui nodi della rete emulata descritta dall utente. Successivamente, inizializza e controlla l esecuzione, mentre l esperimento viene eseguito, i dati sensibili vengono misurati e accumulati secondo le esigenze dell utente. I valori acquisiti vengono memorizzati in un database per analisi successive, oppure, possono essere riutilizzati direttamente da OMF nel corso dell esperimento per variare dinamicamente alcuni parametri di lavoro. OMF ha come utilizzatori, due tipi di figure: 19

28 ˆ Lo Sperimentatore, il quale, ha a disposizione un insieme di strumenti per descrivere ed impostare gli esperimenti, eseguirli ed acquisirne i risultati. ˆ L operatore ha, invece, a disposizione un gruppo di servizi per gestire in modo efficiente le risorse reali o emulate a disposizione ( resettare i nodi, acquisire informazioni sullo loro stato, installare nuovi sistemi operativi ). E importante notare che gli strumenti software di OMF non sono studiati per una piattaforma hardware specifica, nonostante ciò è stato installato e configurato su una molteplicità di sistemi basati su differenti tipi di tecnologie. 3.2 Architettura L architettura di OMF segue un approccio di tipo distribuito. In un generico testbed di OMF sono coinvolte tre entità: ˆ Aggregate Manager ˆ Experiment Controller ˆ Resource Controller Aggregate Manager L Aggregate Manager gestisce tutte le risorse presenti nel testbed, fornisce allo sperimentatore l accesso ad un sottoinsieme di queste risorse con la possibilità di imporre delle restrizioni, la versione attuale dell Aggregate Manager svolge, in particolare, le seguenti attività: ˆ Gestisce le risorse come lo Chassis Manager che è un controllore usato per l accensione e lo spegnimento di una risorsa. Ovviamente, è presente solo nel caso in cui la risorsa è reale e non emulata. 20

29 ˆ Gestisce un database di informazioni per le risorse disponibili e tutte le informazioni relative al testbed. ˆ Avvia o ferma il software Frisbee che distribuisce/salva le immagini degli hard disk (o delle eeprom) dei dispositivi da/per una repository di tali immagini. Anche questa mansione è maggiormente orientata più ai testbed fisici che a quelli emulati. ˆ Può gestire il boot remoto dei dispositivi. ˆ Fornisce accesso remoto e permette query ad un possibile database di misurazioni. Chassis Manager E costituito da una scheda elettronica integrata o integrabile nella mainboard del nodo che gestisce l alimentazione del dispositivo, ossia un componente che comunica via ethernet con l Aggregate Manager. Frisbee Frisbee è un sistema per salvare, trasferire ed installare immagini complete di Hard Disk. E pensato per operare in un contesto di rete LAN e permette di inviare via Ethernet in modo simultaneo le immagini dei dischi a tutti i client interessati. Frisbee è inoltre, dotato di una tecnica di compressione che aumenta notevolmente la velocità di trasferimento dei dati Experiment Controller L Experiment Controller è l entità software responsabile di dislocare, controllare ed organizzare l esperimento secondo le intenzioni dell utilizzatore, accetta in ingresso ed elabora l Experiment Description. Coopera con l Aggregate Manager del testbed per configurare le risorse sperimentali in accordo con la descrizione, una volta che le risorse sono configurate l Experiment 21

30 Controller comunica con il Resource Controller ed invia i comandi che effettivamente realizzeranno l esperimento. Experiment Description L experiment description è uno script fornito in ingresso all experiment controller, che elenca le risorse necessarie all esperimento e l insieme di azioni da svolgere per realizzarlo Resource Controller Il Resource Controller è l entità che risiede in ognuna delle risorse disponibili nel testbed, ogni instanza di esso attende i comandi emanati dall Experiment Controller, li esegue, e restituisce tutte le informazioni che pervengono dall esecuzione del comando. In sintesi, il Resource Controller è responsabile dell esecuzione dei comandi di esperimento inviati ad una risorsa. In aggiunta a questa funzione di controllo, è attualmente responsabile di alcune funzioni di gestione della risorsa, come la ricezione e la scrittura dell immagine del disco nella memoria del dispositivo controllato. In aggiunta a queste tre entità fondamentali, non bisogna tralasciare un altro componente essenziale al sistema: l OEDL il linguaggio attraverso cui viene descritto l esperimento di OMF, basato sul linguaggio Ruby[15]. E un Domain-Specific Language con tutti i costrutti necessari per lo svolgimento degli esperimenti. Lo script definito in questo linguaggio è elaborato dall Experiment Controller e contiene la definizione della topologia e le azioni da compiere sui nodi. 22

31 Figura 3.2: Architettura di OMF 23

32 3.3 Struttura La struttura di lavoro di OMF è essenzialmente composta da: ˆ Un Aggregate Manager ˆ Uno o più Experiment Controller ˆ Una pluralità di nodi L aggregate manager e gli experiment controller hanno una funzione di gestione, monitoraggio e raccolta dei dati provenienti dai nodi. I nodi sono, invece, oggetto dell azione di OMF, dove su ognuno di essi risiede l entità detta Resource Controller, che, come detto in precedenza, gestisce il nodo sia per ciò che riguarda il download dell immagine disco che per l esecuzione dei comandi emanati dall experiment controller. L Aggregate Manager, allo stato attuale di OMF, è sempre unico, mentre gli Experiment Controller possono essere più d uno, il numero dei nodi dipende dall esperimento, e tutti questi elementi possono essere reali o virtualizzati. Una visione globale si può avere dalla (Figura 3.3) Il compito svolto da OMF per mettere a disposizione dello sperimentatore un ambiente flessibile di testing, si riassume, schematicamente nelle seguenti azioni: ˆ Istanziare una rete di controllo che permette di collegare le entità di gestione e quelle di sperimentazione. ˆ Scambiare messaggi espressi in formato comune a tutti gli elementi per svolgere tutte le attività, sia di gestione che di sperimentazione. ˆ Conoscere tutti i nodi di sperimentazione disponibili e le loro caratteristiche. ˆ Mappare tutti i nodi assegnando un ordinamento logico e poterli assegnare agli esperimenti. 24

33 Figura 3.3: Struttura di OMF ˆ Erogare i comandi necessari seguendo una tempificazione dettata dallo script di esperimento. ˆ Ricevere i messaggi di ritorno dai nodi relativi a compiti di gestione o di acquisizione risultati. Queste caratteristiche vengono implementate utilizzando diversi elementi software: ˆ Servizi sul S.O. di ogni entità coinvolta. ˆ Un database. ˆ Un server di messaggistica. ˆ Un linguaggio di scripting appositamente adattato. 25

34 3.3.1 Servizi installati OMF prevede su ogni macchina, reale o virtuale, l installazione di uno o più servizi, come illustrato precedentemente. In genere, l Aggregate Manager e l Experiment Controller sono ospitati sulla stessa macchina, e dal punto di vista implementativo, sono costituiti da due servizi impostati come autopartenti che comunicano tramite Openfire[13]. Il primo inoltre, accede anche al database per il recupero delle informazioni sui nodi. Il Resource Controller risiede su ognuno dei nodi e comunica attraverso Openfire, anch esso è un servizio impostato come autopartente Gestione dei collegamenti L ambiente naturale di di OMF sono le reti telematiche sia cablate che wireless. Essendo studiato principalmente per ambienti di testbded, in cui i nodi e i collegamenti sono entità reali, le potenzialità sono concentrate nella gestione flessibile dell ambiente di test. Grazie, infatti, all OEDL è facilmente allestibile un esperimento fra nodi di prova. Per rendere attuabile questa potenzialità, OMF utilizza due reti(figura 3.4): ˆ Rete di Controllo ˆ Rete di Esperimento Server di scambio messaggi OMF utilizza, per mettere in comunicazione tutte le entità coinvolte, un server di messaggistica istantanea chiamato Openfire. Questo server, scritto in Java, utilizza il protocollo XMPP 3. Ha il compito di gestire tutta la messaggistica che viaggia tra gli apparati di gestione e i nodi. E dotato di un database interno in cui vengono mappati tutti i nodi di esperimento. 3 XMPP- E l abbreviazione di Extensible Messaging and Presence Protocol. E un insieme di protocolli aperti di messaggistica istantanea e presenza basato su XML 26

35 Figura 3.4: Layout suggerito Risiede, attualmente sulla macchina che ospita l Aggregate Manager ed ha un interfaccia Web di configurazione, la sua configurazione viene fatta solo una volta all atto dell installazione. In particolare, il software dell Aggregate Manager figura nel server XMPP con il ruolo di amministratore Database OMF ha tra i suoi elementi fondamentali un database MYSQL che contiene: ˆ Tutte le informazioni necessarie relative ai nodi, nella fattispecie: Indirizzo IP e MAC della rete di controllo, Informazioni relative allo hardware del dispositivo, includenti il tipo di scheda madre, il produttore ed altre informazioni di supporto, ID univoco assegnato ad ogni dispositivo, 27

36 La posizione logica di ogni nodo, identificata dalle tre coordinate X, Y, Z. 4 ˆ Informazioni relative al testbed/emulazione, ossia: Nome ed ID del testbed IP della rete di controllo Indirizzi IP dei servizi ausiliari Il database, va popolato, attualmente in modo manuale eseguendo le query riguardanti i nodi aggiungendo tutti i dati necessari. In questo lavoro di tesi, la fase di popolamento del database è stata automatizzata attraverso appositi script(appendice C) di installazione, è prevista anche l aggiunta di PHPMyAdmin per facilitare l inserimento dei dati Flusso tipico di un esperimento Qui viene descritto l andamento tipico di un esperimento in OMF. ˆ l utente compone uno script di esperimento e lo passa all Experiment Controller; ˆ l Experiment Controller interpreta lo script ed invia le richieste all Aggregate Manager per la configurazione delle risorse necessarie; ˆ i servizi dell Aggregate Manager inizializzano e configurano queste risorse; ˆ quando le risorse sono pronte, l Experiment Controller invia i comandi al Resource Controller di ogni nodo; ˆ il Resource Controller interpreta i comandi ed esegue le azioni. ˆ l esperimento è attualmente in fase di Running 4 Ogni nodo, infatti, viene inteso come punto in uno spazio a tre dimensioni e quindi, disposti in una griglia virtuale identificati da un ID 28

37 ˆ durante la fase di esecuzione vengono eventualmente comunicate le misurazioni necessarie; ˆ al termine dell esperimento sono disponibili i suoi risultati per una eventuale analisi; 3.4 Come si usa In questa sezione viene descritto il ciclo di vita di un esperimento svolto con OMF. I passi base da compiere per portare a termine un esperimento sono essenzialmente quattro: 1. Sviluppo o adattamento del software da valutare: questa fase consiste nello sviluppo del software da provare sulla rete emulata, quest ultimo può essere un applicativo sviluppato in un qualsiasi linguaggio di programmazione, oppure, si può utilizzare un tool già pronto pensato specificamente per l analisi di parametri di interesse. 2. Sviluppo dell esperimento: la seconda fase consiste,invece, nello sviluppare una Application Definition e successivamente una Experiment Description. L Application Definition può essere vista come un interfaccia che rende le entità costituenti OMF capaci di interagire e sovraintendere con l applicativo definito in precedenza. Questa interazione può consistere nel passaggio di parametri, nell acquisizione di misurazioni o nell accesso agli archivi che contengono il software da testare. L Experiment Description, invece, elenca le risorse necessarie richieste dall esperimento, che, come detto, possono essere costituite da nodi e link fisici o emulati, e le azioni da compiere su di esse al fine di realizzare l esperimento. E uno schedulatore di eventi che definisce quali azioni compiere sui nodi e quando farlo. 3. Esecuzione dell esperimento: avviando l entità software preposta all esecuzione, parte il coordinamento dei nodi e del software sperimentale su di essi. 29

38 Figura 3.5: Ciclo di vita di un esperimento in OMF 4. Accesso ed analisi dei risultati: in questo quarto passo, si accede alle misure raccolte durante l esecuzione dell esperimento ed alla sua analisi. Per fare ciò, nella fase precedente, devono essere stati definiti dei parametri sottoposti a misurazione. 30

39 Capitolo 4 Tecniche e strumenti per la valutazione della qualità dei servizi VoIP Voice over IP (Voce tramite protocollo internet), acronimo VoIP, è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione internet o un altra rete dedicata che utilizza il protocollo IP, anzichè passare attraverso la normale linea di trasmissione telefonica. Ciò consente di eliminare le relative centrali di commutazione e di economizzare sulla larghezza di banda occupata. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati in forma digitale, e ciò solo nel momento in cui necessario, cioè quando uno degli utenti collegati stà parlando. Le conversazioni VoIP non devono necessariamente viaggiare su internet, ma possono anche usare con mezzo trasmissivo una qualsiasi rete privata basata sul protocollo IP, per esempio una LAN all interno di un edificio o di un gruppo di edifici. I protocolli utilizzati per codificare e trasmettere le conversazioni VoIP sono solitamente denominati Voice over Ip, la tecnologia VoIP richiede due tipologie di protocolli di comunicazioni in parallelo, uno per il trasporto dei dati(pacchetti voce su IP) in tal caso, nella grande maggioranza delle implementazioni di VoIP viene adottato il protocollo RTP(Real-Time Transport Protocol), ed una per la segnalazione della conversazione, ossia per riconvertire i dati in voce, per sincronizzarla e riordinarla quindi cronologicamente. 31

40 Per quello che rigarda la segnalazione possiamo avere: ˆ SIP (Session Initiation Protocol) della IETF; ˆ H.323 della ITU; ˆ Skinny Client Control Protocol, protocollo proprietario della Cisco; ˆ Megaco conosciuto anche come H.248; ˆ IAX, usato dai server Asterisk. 4.1 MOS - Mean Opinion Score La qualità di un servizio fonico fornito da una rete di telecomunicazioni è universalmente riconosciuta come una grandezza soggettiva, pertanto si deve partire dalla considerazione che è il solo utente finale a poter dare una valutazione del servizio fornitogli. L ITU-T 1 definisce il MOS(Mean Opinion Score)come il valor medio dei punteggi di opinione, ossia di valori di una scala predefinita che dei soggetti attribuiscono alla loro opinione sulle performance del sistema di trasmissione telefonica in esame, in seguito ad una conversazione effettuata. È da precisare che il MOS può essere misurato solo effettuando test in laboratorio. I valori di MOS vanno da 1 (bad) a 5 (excellent). Questi vengono attribuiti a seconda della qualità della voce percepita dai soggetti partecipanti al test. Inoltre, test di ascolto effettuati in condizioni diverse (ottenute ad es.cambiando le frasi da ascoltare, la lingua utilizzata o le condizioni di ascolto)possono condurre a valori di MOS diversi; pertanto valori di MOS ottenuti in condizioni diverse non possono essere confrontati direttamente. 1 International Telecommunication Union - regola le comunicazioni telefoniche e telegrafiche 32

41 Nella norma ITU-T P.800 sono descritte le varie tipologie di test attraverso le quali è possibile effettuare una misura di qualità fonica, che sono le seguenti: ˆ Conversation-opinion tests: test è svolto da coppie di soggetti che conversano utilizzando il sistema telefonico da testare; al termine delleconversazioni esprimono un giudizio (Excellent=5, Good=4, Fair=3, Poor=2, Bad=1) la cui media è detta MOSc (conversational MOS); ˆ Listening tests/acr (Absolute Category Rating): un gruppo di soggetti è sottoposto all ascolto di brevi frasi trasmesse per mezzo del sistema telefonico da testare, al cui termine esprimono un giudizio (Excellent=5, Good=4, Fair=3, Poor=2, Bad=1) la cui media è detta MOS; ˆ Listening tests/dcr (Degradation Category Rating): un gruppo di soggetti è sottoposto all ascolto di brevi frasi trasmesse per mezzo del sistema telefonico da testare, e delle frasi stesse senza la trasmissione ossia si ha a disposizione il campione di riferimento, al cui termine esprimono un giudizio relativo alla degradazione, la cui media è detta DMOS (degradation MOS); ˆ Listening tests/ccr (Comparison Category Rating):stesso procedimento del DCR con la differenza che i campioni (originale e trasmesso) sono fatti ascoltare in ordine casuale, senza cioè che i soggetti sappiano quale stanno ascoltando; la scala usata è differente e il valor medio è detto CMOS (comparison MOS). Da queste definizioni si deduce pertanto quanto accennato in precedenza, ossia che una caratteristica fondamentale della qualità fonica è quella di essere una misura soggettiva, ottenibile in maniera esatta soltanto attraverso la valutazione da parte di più soggetti dell ascolto di una conversazione. 33

42 4.1.1 Metodi di misura della qualità fonica Metodi di misura soggettivi ed oggettivi Il metodo di misura descritto nel paragrafo precedente per la valutazione della qualità fonica è evidentemente un metodo di misura soggettivo, in quanto dipende prevalentemente dai soggetti coinvolti nel test. Un procedimento quale quello descritto per la misura della qualità fonica è naturalmente molto dispendioso, sia in termini di tempo che in termini economici: è necessario allestire un laboratorio secondo rigorose specifiche e coinvolgere un certo numero di persone. I metodi oggettivi hanno una enorme diffusione, per la semplicità di implementazione, per i minori costi, per la semplice riproducibilità di test e per la validazione di prototipi di sistemi di comunicazione. La qualità fonica misurata per mezzo di uno specifico strumento di misura è invece sempre una stima della qualità fonica percepita dal cliente e, quindi, è una quantità fortemente legata allo strumento di misura impiegato. Pertanto, quando per la valutazione della qualità fonica di una rete di telecomunicazioni si ricorre all utilizzo di una macchina, si deve sempre tenere conto del grado di affidabilità delle stime che essa è in grado di fornire e, altro aspetto determinante per la corretta interpretazione dei risultati, si deve anche tenere conto dei fattori da cui dipende l algoritmo di stima della qualità fonica implementato in quella macchina e quelli da cui non ne è influenzato. Questi ultimi aspetti, assieme agli errori di misura tipici dei campionamenti reali, quindi finiti, acquistano grande importanza soprattutto quando le misure raccolte sono poi utilizzate per effettuare i confronti tra due diverse reti di telecomunicazioni (benchmarking). Metodi di misura intrusivi e non intrusivi (o parametrici) Per metodo di misura intrusivo si intende un metodo che effettua la stima del valore di MOS mediante introduzione di un campione vocale nella rete da testare. La stima del MOS viene effettuata confrontando il campione vocale ricevuto con quello trasmesso. In questa categoria rientrano, ad esempio, il 34

43 PESQ, algoritmo standardizzato dall ITU e pertanto largamente diffuso e lo SQuad, algoritmo per la misura di qualità fonica su reti radiomobili. I metodi non intrusivi, invece, effettuano una stima del MOS a partire da parametri e caratteristiche della rete considerata, per questo motivo sono detti anche parametrici. Il metodo non intrusivo più diffuso ed utilizzato è l E-model[25] algoritmo standardizzato dall ITU, quello da noi utilizzato per la valutazione del MOS sulla nostra rete E-model A partire dall analisi di un insieme di misure pertinenti la connessione sotto esame, l E-Model fornisce infatti un indice di qualità globale della connessione, detto Transmission Rating Factor ed indicato con R, variabile in una scala da 0(qualità pessima) a 100(qualità ottima), definito semplicemente come: R = R o I s I d I e + A (4.1) Ove i fattori indicati rappresentano: ˆ Ro: rappresenta il rapporto segnale rumore(snr); ˆ Is: rappresenta il fattore di degrado che si manifesta all inizio del segnale vocale; ˆ Id: rappresenta il fattore di degrado che si manifesta a causa del ritardo del segnale vocale; ˆ Ie: rappresenta il fattore di degrado che si manifesta a causa di specifici apparati utilizzati per la connessione; ˆ A: tale contributo rappresenta un vantaggio che certi sistemi di telecomunicazione hanno rispetto ai sistemi convenzionali su rete fissa. Di seguito è riportato l andamento del fattore R. 35

44 Figura 4.1: Transmission Rating Factor Il valore medio stimato del MOS può essere ricavato dalle seguenti: R + R (R 60) (100 R) se 0 < R < 100 MOS = 1 se R se R 100 Con la raccomandazione ITU-T G.109 sono state introdotte le categorie di qualità di trasmissione vocale rappresentate in (Figura 4.2), in corrispondenza di ben determinati intervalli di variazione del fattore R. In accordo agli articoli[26, 27, 28] l equazione (4.1) si riduce alla seguente: R = 93.4 I d I e eff (4.2) Dove I d è in funzione del delay(ritardo) ed I e eff è in funzione del tipo di codec utilizzato e del Packet Loss(pacchetti persi). In particolare il valore di I d è dato da: I d = 0.024d (d 177.3)H(d 177.3) (4.3) dove d è il delay (in ms) ed H rappresenta la funzione di Heavyside. Per quanto riguarda il fattore I e eff (equipment impairment factor),esso rappresenta il fattore di degrado che si manifesta a causa di specifici apparati utilizzati per la connessione come, ad es., particolari codec a basso bit rate, e dalla loro robustezza al packet loss. 36

45 Figura 4.2: Categorie di Qualità di Trasmissione Può essere definito dalla seguente: I e eff = I e + (95 I e ) P pl P pl + B pl (4.4) dove I e è il fattore proprio del codec nel caso ideale, ossia in assenza di perdità di pacchetti, P pl è la percentuale dei pacchetti persi, B pl è la robustezza del codec alla perdita di pacchetti. Di solito i parametri I e e B pl sono standardizzati per alcuni codec. Codec G711 L algoritmo più semplice e storicamente più utilizzato è il Codec G711. Questo non effettua compressione della voce ma ne effettua semplicemente un campionamento prelevando 8000 campioni in un secondo. Ogni campione è in un byte di dati, pertanto ogni campione discretizza il livello vocale in uno tra 256 intervalli, tale tipo di codec presenta un MOS instrinseco pari a

46 4.2 DITG - Distributed Internet Traffic Generator D-ITG[29] è stato realizzato presso il Dipartimento di Informatica e Sistemistica dell Università ƒfederico II di Napoli è una piattaforma in grado di produrre traffico IPv4/IPv6, disponibile sia per Windows che per Linux. I suoi flussi di traffico possono essere generati considerando IDT 2 e Packet Size 3, inoltre tale applicativo è in grado di riprodurre i modelli di traffico come TCP, UDP, ICMP e VoIP. La sua architettura è costituita da(figura 4.3): ˆ ITGSend: si occupa dell invio dei processi di comunincazione; ˆ ITGRecv: si occupa della ricezione dei processi di comunicazione; ˆ ITGLog: si occupa di effettuare il salvataggio dei log delle comunincazioni; ˆ ITGManager: si occupa di effetuare il controllo remoto; ˆ TSP(Traffic Specification Protocol): si occupa della comunincazione tra le entità DITG; ˆ ITGDec: analizza i log ottenuti ricavando Jitter, Delay, Packet Loss e Throughput. 2 Inter Departure Time - L intervallo di tempo che impiega la sorgente di traffico a generare due pacchetti consecutivi. 3 Packet Size -Dimensione dei pacchetti considerando esclusivamente il carico utile. 38

47 Figura 4.3: Architettura D-ITG 4.3 Struttura di Esperimento Dopo aver illustrato il concetto di MOS e aver visto l applicativo D-ITG, vediamo nei dettagli il lavoro di tesi come si è svolto. Nel realizzare la struttura è stata replicata la stessa riportata in[30], in tale documento è stata valutata la qualità vocale in un sistema VoIP, considerando come scenario di misurazione, quello costitutito da due end-point, il primo presso la Federal University of Amazonas (UFAM) nella città di Manaus, ed il secondo presso la Federal University of Ceará (UFC) nella città di Fortaleza. Questi due end-point sono collegati indirettamente mediante Rio De Janero, i link sono asimmetrici, il link che collega UFAM con Rio ha una banda pari a 8Mbps mentre il link che collega UFC con Rio ha una banda di 34Mbps(Figura 4.5). 39

48 Figura 4.4: Struttura Di Test Neptune Figura 4.5: Struttura Di Test UFAM-UFC 40

49 La trasmissione sulla rete ha utilizzato: ˆ Codec G711; ˆ Bit Rate di 64kbps; ˆ pacchetti RTP di 40 bytes; Nella prima parte dei test sono state effettuate telefonate da UFAM verso UFC, con 5, 10, 20, 30 e 40 chiamate simultanee della durata di 180s ognuna, nella seconda parte si sono ripetuti gli stessi tipi di test ma procedendo da UFC verso UFAM 4.4 Esperimento su Neptune Prima di illustrare l esperimento, bisogna fare una premessa, visto che nel paper in oggetto non viene riportato alcun parametro relativo al delay della rete, si è proceduto all esecuzione dei test considerando che il delay nel caso di reti satellitari è compreso tra [ ]ms, perciò abbiamo valutato il mos sulla nostra rete virtualizzata in tre casi: 1. Delay 250ms 2. Delay 500ms 3. Delay 900ms Dopo aver chiarito i parametri di test vediamo come è stato fatto tutto ciò nei dettagli. Utilizzando Neptune(Figura 4.4) si è implementata una rete virtuale, costituita da 3 nodi costituiti da un immagine minimale debian su cui sono disponibili i servizi DITG, ed un 4 nodo che avrà anch esso un immagine minimale debian, ma in questa a differenza dei nodi è presente il servizio Aggregate Manager di OMF (Capitolo3), per l intera configurazione della rete di esperimento si sono utilizzati gli script in (Appendice C). I nodi 0-1 sono 41

50 stati collegati con un link con banda pari a 8Mbps, mentre i nodi 1-2 sono stati collegati con un link con banda pari a 36Mbps, tutto ciò per rispecchiare la rete reale illustrata precedentemente. A questo punto con l ausilio di OMF, si è proceduti all esecuzione della simulazione del traffico VoIP utilizzando D-ITG, con uno script che non fa altro che avviare il Receveir su un nodo in ascolto e il Sender sul nodo che simula traffico Voip della durata di 180s con codec G Script di Test Di seguito è riportato un file experiment.rb tale file, è stato richiamato sulla macchina in cui era presente l Aggregate Manager, tale file richiede in ingresso un file script10.sh. experiment.rb defapplication( Receiver, App1 ) { app app.shortdescription = "Applicazione D-ITG" app.path="./itg/itgrecv" } defapplication( Sender, App2 ) { app app.shortdescription = "Applicazione D-ITG" app.path="./itg/itgsend script10.sh -l /ITG/result/res10 } info("gruppo Receiver") defgroup( uno, [1,1]) { node node.addapplication( Receiver ) } info("gruppo Sender") defgroup( due, [1,2]) { node node.addapplication( Sender ) } 42

51 whenallinstalled() { node wait 5 allgroups.startapplications wait 200 Experiment.done } info("esperimento D-ITG Completato") script10.rb Tale script viene utilizzato da experiment.rb prevede 10 telefonate simultanee, la sintassi è: ˆ -a (INDIRIZZO A CUI INVIARE TRAFFICO); ˆ -t (DURATA DELLA SIMULAZIONE); ˆ -rp (PORTA DI INVIO); ˆ VoIP -x G711.1 (TRAFFICO VOIP CON CODEC G711); ˆ -h (TIPO DI PROTOCOLLO) -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP -a t rp Voip -x G h RTP 43

52 Figura 4.6: Decodifica D-ITG 4.5 Analisi dei Risultati I risultati ottenuti da D-ITG sono stati decodificati con ITGDec, che ci ha restituito Packet Loss, Delay e Jitter(Figura 4.6). Da questi parametri ottenuti abbiamo ricavato il valore del MOS, per ogni insieme di telefonate, e riportato nei grafici successivi, negli stessi grafici abbiamo anche riportato il valore del MOS ottentuto nella rete reale Grafici Mos Di seguito riportiamo nei grafici i valori del MOS introducento sulla rete rispettivamente delay di 250 ms, 500 ms e 900 ms. 44

53 Figura 4.7: Mos 34 Mbps - 8 Mbps Figura 4.8: Mos 8 Mbps -34 Mbps Figura 4.9: Mos 34 Mbps - 8 Mbps 45

54 Figura 4.10: Mos 8 Mbps -34 Mbps Figura 4.11: Mos 34 Mbps - 8 Mbps Figura 4.12: Mos 8 Mbps -34 Mbps 46

55 Capitolo 5 Conclusioni e Sviluppi 47

56 Appendice A Installazione Xen Premettiamo che le intere installazioni illustrate nei capitoli successivi sono state fatte mediante terminale root su una versione Debian Lenny A.1 Installazione e configurazione di xend e configurazione bridge Come prima cosa se nella macchina è presente exim4 effettuare un remove con il seguente comando: apt-get remove exim4 Controllare il kernel Xen disponibile, digitando: apt-cache search xen-linux-system- Verranno allora elencati i kernel disponibili, nel nostro caso abbiamo ottenuto xen-linux-system xen-686 Abbiamo quindi digitato: apt-get install xen-linux-system xen-686 Con il comando: apt-get install xen-tools abbiamo installato una serie di script che automatizzano gran parte delle operazioni necessarie alla creazione delle macchine virtuali. 48

57 Configurare /etc/xend-config.sxp decommentando le seguenti righe se non lo sono. (network-script network-bridge) (vif-script vif-bridge) il secondo è lo script di creazione dell interfaccia collegata al bridge. Riavviare il demone per rendere effettive le modifiche, con il comando /etc/init.d/xend restart A.2 Creazione macchine virtuali (domu) Prima di creare la macchina virtuale è necessario modificare il file xentools.conf al path: /etc/xen-tools/ Le variazioni sono: ˆ Configurare l utilizzo di lvm per creare la macchina con: lvm = xen-lvm ˆ Selezionare deboostrap come metodo di installazione per le nostre macchine virtuali con: deboostrap = 1 ˆ Scegliere la dimensione dell hard disk della macchina virtuale: size=10gb ˆ Definire la memoria utilizzabile della macchina virtuale: memory = 512Mb 49

58 ˆ Dimensionare la partizione di swap: swap = 512Mb ˆ Definire il tipo di filesystem: fs = ext3 ˆ Scegliere la distribuzione da installare: dist = etch ˆ Configurare la rete: gateway = x.x.x.x netmask = x.x.x.x ˆ Riportare la versione corretta del kernel: kernel = /boot/vmlinuz xen-686 initrd = /boot/initrd.img xen-686 ˆ Per creare macchine con architettura a 64bit specificare: arch=amd64 ˆ Infine specificare il mirror da cui verrà scaricata la distribuzione: mirror = 50

59 A.3 Creazione Macchina Virtuale Per la creazione della macchina virtuale viene utilizzato il file modificato nel paragrafo precedente xen-tools.conf dal comando: xen-create-image --ip x.x.x.x --hostname prova Questo comando creerà anche il file /etc/xen/prova.cfg con tutte le caratteristiche della macchina realizzata(figura A.1). Se si vuole creare una macchina virtuale senza editare il file xen-tools.conf lo si può fare direttamente con il comando: xen-create-image --ip x.x.x.x --hostname=prova1 --size=4gb --dist=lenny --memory=512m --ide --dhcp --dir=prove che crea una macchina con le caratteristiche editate nella directory prove. Prima di avviare la macchina creata, dobbiamo aggiungere al file di configurazione della macchina, che sarà al path: etc/xen/prova1.cfg la seguente riga: extra = console=hvc0 xencons=tty per evitare lo stallo della macchina e l utilizzo di Pygrub. 1 Dopo aver creato una macchina virtuale possiamo gestirla utilizzando i seguenti comandi: ˆ xm list: elenca tutte le macchine presente nel dom0; ˆ xm console domain: accede alla console del dominio; ˆ xm shutdown domain: spegne il dominio scelto; ˆ xm reset domain : resetta il dominio scelto; ˆ xm help : help dei comandi xm possibili. 1 PyGRUB è un bootloader ispirato a grub, ma scritto in python che consente a Xen di avviare la macchina virtuale. 51

60 Figura A.1: Output Xen Figura A.2: Xm List 52