Routing Dinamico: Netkit vs Network Simulator

Transcript

1 Network Infrastructures A.A Routing Dinamico: Netkit vs Network Simulator Emulazione vs Simulazione Name of authors: Davide Iori, Davide Manzo

2 2 I. Indice: 1. Emulazione Virtualizzazione e macchine virtuali User Mode Linux Netkit 2. Simulazione Simulazione Reti Network Simulator 3. Emulazione e Simulazione: Differenze 4. Routing Routing Dinamico Routing Information Protocol(RIP) 5. Caso studio 5.1 Routing dinamico in Netkit e Network Simulator 6. Netkit & Network Simulator: Confronto e differenze 6.1 Differenze architetturali 6.2 Differenze implementative 6.3 Differenze d'utilizzo 6.4 Can do, Can't do 7. Conclusioni

3 3 1. EMULAZIONE In generale un emulatore duplica le funzioni di un determinato sistema su un secondo sistema differente dal primo, ed è un programma che permette l'esecuzione di software originariamente scritto per un ambiente (hardware o software) diverso da quello dove l'emulatore viene eseguito. Un programma scritto per computer con sistema operativo Windows ad esempio, non gira su un computer con sistema operativo Linux. In tali casi, si crea sulla macchina ospitante un emulatore che riproduce virtualmente l'ambiente che è stato previsto per l'esecuzione di quel programma. Esistono varie categorie di emulatori, così come esistono diversi metodi per emulare una piattaforma. È possibile emulare completamente un ambiente sia hardware sia software oppure soltanto uno dei due. 1.1 VIRTUALIZZAZIONE E MACCHINE VIRTUALI: Nel corso degli anni l informatica ha cercato di spingere molto sul concetto di virtualizzazione: Trasformare un singolo computer in una varietà di computer utilizzabili contemporaneamente e dotati di sistemi operativi. I software presenti sul mercato sono in grado di emulare una o più macchine virtuali usando cpu, memoria, hard disk sulla macchina reale. Una macchina virtuale è un programma che emula un calcolatore. I programmi applicativi vengono scritti in un linguaggio che viene compilato per questo calcolatore immaginario e, una volta compilati, vengono eseguiti sulla macchina virtuale. Java, ad esempio, fa uso della macchina virtuale: i programmi scritti in Java vengono infatti compilati nel linguaggio bytecode, che gira sulla Java Virtual Machine. Le virtual machine, quindi, si possono considerare un "PC nel PC". Ossia, mediante una virtual machine è possibile installare un secondo sistema operativo in una macchina virtuale e farci girare software in un ambiente considerato più "protetto" che non la macchina host vera e propria. Come si può immaginare, al di là della lentezza (comunque relativa e proporzionale alla potenza della macchina host), non vi è alcun limite. Questi sistemi a volte emulano anche parti di hardware, e altre volte si limitano a replicare l'hardware della macchina host. Tuttavia, non emulano mai macchine con architettura completamente diversa (a partire dalla CPU) e, quindi, non sono considerati emulatori nel senso stretto del termine. 1.2 USER MODE LINUX Implementazione OS per macchine virtuali: Un processo UML è chiamato virtual machines, mentre la Linux box che ospita un vm è chiamata host machine (host). Molte virtual machines possono essere eseguite contemporaneamente sullo stesso host. UML fornisce le stesse funzioni di network come una comune macchina Linux. Si possono, perciò, realizzare collegamenti di rete tra le varie virtual machines attive > UML mi permette di far partire sul mio host tante macchine virtuali in modo di virtualizzare tanti devices, emulando, così, una computer network. 1.3 NETKIT Netkit è un laboratorio virtuale con le funzionalità di UML, possiamo definirlo come un front- end a UML. Contiene un UML kernel che è usato come kernel per le virtual machines e un insieme predefinito di comandi per le macchine virtuali. Ogni macchina virtuale possiede:

4 4 - una console (terminal window) - una memoria ( presa in prestito dalla memoria dell' host) - un filesystem (memorizzato in un singolo file dell'host filesystem) - (una o più) network interfaces Domini di collisione: Insieme di nodi che concorrono per accedere allo stesso mezzo trasmissivo - Ogni network interface può essere connesa a un (virtual) collision domain - Ogni virtual collision domain può essere connesso a molte interfacce Progetto: L'approccio consigliato è quello di disegnare la topologia della rete che si vuole emulare. L'idea è di avere diverse virtual machines connesse a collision domain in modo da comunicare tra loro. Netkit permette di configurare una virtual machines in modo da giocare il ruolo di host, router o switch. Netkit fornisce agli utenti due insieme di comandi: v- prefixed commands (vcommands) l- prefixed commands (lcommands) vcommands > agiscono come strumenti a basso livello per avviare e configurare un'unica macchina virtualeact as low level tools for and starting up single virtual configuring machines lcommands > forniscono un ambiente easier- to- use per configurare un laboratorio complesso costituito da molte macchine virtuali

5 5 2. SIMULAZIONE Una simulazione è un modello della realtà che consente di valutare e prevedere lo svolgersi dinamico di una serie di eventi susseguenti all'imposizione di certe condizioni da parte dell'utente. Un buon esempio dell'utilità di usare i calcolatori per simulare può essere trovato nel campo di network traffic simulation. Scopo della simulazione: Analisi delle prestazioni Ottimizzazione Capacity planning Progetto: analisi di sistemi ipotetici SIMULAZIONE RETI I Sistemi di telecomunicazione sono complessi sistemi real- world, contenenti molti componenti differenti che interagiscono tra loro secondo complesse relazioni. La simulazione è un'approccio che può essere usato per modellare complessi sistemi stocastici, sistemi per il forecasting o per la valutazione delle prestazioni. Nell'ambito della ricerca delle comunicazioni e delle reti di calcolatori, la simulazione delle reti (network simulation) è una tecnica dove un programma modella il comportamento di una rete o per studiare le interazione tra differenti entità di rete (hosts/routers, data links, packet, etc,...) usando formule matematiche, o per catturare e riprodurre osservazioni da una rete di produzione. Una sola workstation è necessaria per eseguire una simulazione. Il simulatore permette di esaminare facilmente un'ampia varietà di scenari in un tempo relativamente breve. E' possibile simulare topologie di rete complesse, difficili e costose da realizzare. E' Facile testare l'impatto di modifiche nei protocolli simulati. 2.2 NETWORK SIMULATOR Cos'è Ns: Ns is a discrete event simulator targeted at networking research. Ns provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. NS è nato con lo scopo di offrire un supporto per la ricerca in ambito networking: Progettazione di nuovi protocolli, studio del traffico,... Confronto tra le varie versioni di un protocollo È l'unico simulatore che implementa l'intera pila protocollare di una rete di telecomunicazioni complessa. Funzionalità: Reti cablate:»routing;»trasporto: TCP, UDP, SCTP

6 6»Sorgenti di traffico: web, ftp, cbr,..»discipline di coda: drop- tail, FQ, SFQ,... Reti wireless:»ad hoc routing e mobile IP»Reti satelittari Architettura: NS è un simulatore ad eventi discreti (le variabili di stato assumono valori discreti) con modello di tempo continuo (le variabili di stato sono sempre definite) e avanzamento del tempo event- driven. Il simulatore vede una lista di eventi. L'accesso ad essa è gestito da uno scheduler che: - Prende il primo evento della lista e lo esegue invocando l'handler associato, poi passa all'evento successivo della lista; - Ciascun evento si verifica in un istante di tempo simulato, ma impiega una quantità arbitraria di tempo reale; OTCL & C++: Ns usa due linguaggi: Un linguaggio interpretato per descriver la topologia della rete e la dinamica della simulazione. Si tratta di OTcl, una versione ad oggetti del linguaggio di scripting Tcl; Per contro il nucleo di NS è scritto in C++; Tale scelta non è stata casuale in quanto i progettisti hanno voluto separare la parte di controllo da quella dei dati. C++ per implementare il simulatore, ovvero i protolli di rete (MAC, network, transport, application); OTcl per eseguire i comandi dell'utente, ovvero per descrivere lo scenario simulativo: topologia, caratteristiche dei link, tipo di traffico, protolli supportati,... Il simulatore supporta una gerarchia di classi in C++ (gerarchia compilata), e una simile gerarchia di classi all'interno dell'interprete OTcl (gerrachia interpretata). Le due gerarchie sono strettamente legate una all'altra. C'è una corrispondenza 1- to- 1 tra una classe della gerarchia interpretata e una della gerarchia compilata. L'estensione, che fa da ponte tra le variabili e le funzioni OTcl e C++, è una libreria chiamata TclCL che crea una corrispondenza biunivoca tra la gerarchia delle classi da condividere tra C++ e OTcl.

7 7 FIGURA 1 C++ & OCTL

8 8 3. EMULAZIONE E SIMULAZIONE: DIFFERENZE Si tende a distinguere gli emulatori di un sistema dai simulatori del sistema stesso. Sebbene il risultato finale possa considerarsi, dagli utenti finali, lo stesso le differenze tra i due sono fondamentali. Tali differenze riguardano sostanzialmente tre aspetti primari: Architettura software Obiettivi Prestazioni e Accuratezza Architettura software: Un emulatore necessita sempre del software del sistema (ottenuto con il processo di dumping), limitandosi ad emulare l'hardware in modo da poter interpretare correttamente i file contenenti i dump del software che rimane scritto in un linguaggio comprensibile solo al sistema emulato e non a quello emulante. Un simulatore, invece, si prefigge di arrivare allo stesso risultato, riscrivendo però (in tutto o in parte) le routine del programma da simulare, in modo da renderlo comprensibile alla macchina su cui gira. Obiettivi: Un simulatore si prefigge di riprodurre le PERFORMANCE di una sistema reale (latency time, packet loss, bandwith,...) Un emulatore si prefigge di riprodurre le FUNZIONALITA' di un sistema reale (configurazione, architettura, protocolli) con un'attenzione limitata alle performance Prestazioni: Non essendoci alcuna emulazione dell'hardware (che prende diversi cicli- macchina), un simulatore è per forza di cosa più veloce, tuttavia è poco preciso nel riproporre fedelmente il software simulato. Quindi Simulatore: Veloce ma poco accurato Emulatore: Lento ma accurato

9 9 4. ROUTING Il routing è l'instradamento effettuato a livello di rete. Consente a due nodi A e B, non collegati direttamente, di comunicare tra loro mediante la collaborazione di altri nodi posti su un cammino nella rete che connette A e B. I router usano tabelle di instradamento i cui elementi sono blocchi di indirizzi IP contigui, che sono detti route o rotte. Metodi di popolamento delle tabelle di routing: routing statico (aggiornamento manuale) routing dinamico 4.1 ROUTING DINAMICO Le tabelle di instradamento vengono popolate da appositi protocolli di routing. I lavori svolti dai protocolli di routing dinamico sono: Comunicare con altri dispositivi per scambiarsi dati sulla rete. Gestire le tabelle di routing, ovvero, aggiungere le rote selezionando la migliore nel caso ce ne siano più di una per una stessa destinazione (questo viene fatto secondo una logica propria del protocollo, che è poi il motivo per cui viene usato quello piuttosto che un altro). Eliminare le rotte non più valide. Adattare dinamicamente la tabella di routing a eventuali cambi di topologia, siano essi provvisori (interfaccia che cade), o meno (aggiunta di un dispositivo, spostamento, rimozione). 4.2 ROUTING INFORMATION PROTOCOL (RIP) Appartiene alla categoria dei Distance Vector Protocol Ogni nodo scambia informazioni solo con i nodi adiacenti Utilizzato in reti di piccole- medie dimensioni Genera un traffico addizionale relativamente contenuto Applica l'algoritmo di Bellman- Ford Utilizza il conteggio del numero di salti (hop count) come metrica di routing Periodicamente i router adiacenti si scambiano i vettori per aggiornare le tabelle di routing

10 10 5. CASO STUDIO Oggetto dell'esperimento: Routing Information Protocol. Obiettivo dell'esperimento: Emulare e Simulare uno scenario comune nel quale si mostra il comportamento del protocollo RIP nel caso di modifiche nella topologia della rete. Software usato nell'esperimento: Network Simulator v. 2, Netkit v. 2.6 Topologia E stata presa in considerazione un infrastruttura di rete come quella in figura 2, con cinque router collegati tra loro, e due host, collegati il primo al router r1 tramite il dominio di collisione G e il secondo al router r4 tramite il dominio di collisione H. FIGURA 2 TOPOLOGIA Sono stati assegnati gli indirizzi IP ad ogni dispositivo e ad ogni dominio di collisione, come mostrato in figura 3. FIGURA 3 ASSEGNAZIONE INDIRIZZI IP ALLE INTERFACCE DI RETE E AI DOMINI DI COLLIZIONE Abbiamo utilizzato quest ultima topologia per configurare le virtual machines del Lab realizzato con Netkit, in particolare per ogni dispositivo emulato X viene scritto un file X.startup

11 11 con tutte le informazioni sulle interfacce di rete. Per esempio il router r1 avrà un file r1.startup con le seguenti informazioni: /sbin/ifconfig eth netmask broadcast up /sbin/ifconfig eth netmask broadcast up /sbin/ifconfig eth netmask broadcast up /sbin/ifconfig eth netmask broadcast up Per quanto riguarda la gestione della topologia in Network Simulator, i dispositivi sono indicati come nodi, e non c è differenziazione tra router, pc o switch, quindi abbiamo realizzato del codice da passare all interprete per realizzare la topologia con 7 nodi (0,1,2,3,4,5,6,7) collegati tra loro da archi che rappresentano i link, inoltre per ogni link abbiamo specificato il tipo (bidirezionale), la capacità e la gestione della coda (DropTail). In Figura 4 è mostrata la topologia mostrata in output dal simulatore, FIGURA 4 TOPOLOGIA NS e il codice scritto per realizzarla è il seguente: set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] set n5 [$ns node] set n6 [$ns node] $ns duplex-link $n0 $n1 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n1 $n5 1Mb 10ms DropTail $ns duplex-link $n1 $n4 1Mb 10ms DropTail $ns duplex-link $n2 $n3 1Mb 10ms DropTail $ns duplex-link $n5 $n4 1Mb 10ms DropTail $ns duplex-link $n3 $n4 1Mb 10ms DropTail $ns duplex-link $n4 $n6 1Mb 10ms DropTail

12 12 Routing Dinamico in Netkit e Network Simulator Netkit, in quanto emulatore, ci permette di andare su ogni virtual machine e di poter interrogare la tabella di routing, per esempio andando sul router r1 e digitando sul terminale il commando route avremmo in output la routing table di r1 come mostrato in figura 5. FIGURA 5 TABELLA DI ROUTING DI "R1" Le informazioni gestite fino a questo punto sono insufficienti per poter realizzare un emulazione del routing dinamico, infatti per poter gestire un routing di questo tipo va attivato su ogni dispositivo router un demone che ci permetta di eseguire il protocollo RIP. Netkit utilizza un demone denominato Zebra che interagisce con vari protocolli (tra cui RIP) e col kernel della macchina virtuale. Questo demone deve essere avviato manualmente, andando sul terminale di ogni router e digitando /etc/init.d/zebra start. Una volta avviato il demone sui vari router si può notare che le tabelle di routing si sono aggiornate, infatti se ritorniamo sul router r1 avremo una tabella di routing come quella in figura 6. FIGURA 6 TABELLA DI ROUTING DI "R1" Dopo aver attivato il demone Zebra, e in particolare il protocollo RIP, possiamo spostarci su una virtual machine per sniffare, tramite tcpdump, i pacchetti RIP scambiati dai router, infatti inserendo il comando tcpdump i ethx v n s 1518 otterremo un output come quello in figura 7. Per quanto riguarda Network Simulator non abbiamo bisogno di attivare alcun demone, occorrerà soltanto inserire all interno del codice, la linea di comando $ns rtproto DV, che permette l avvio del protocollo RIP all interno del simulatore. Una volta avviato NS, notiamo, come mostrato in figura 8, che inizialmente c è uno scambio di pacchetti etichettati rtprotodv che stanno a rappresentare i pacchetti contenenti i Distance Vector scambiati tra i vari router.

13 13 FIGURA 7 PACCHETTI RIP VISTI DAL ROUTER "R1" FIGURA 8 SCAMBIO PACCHETTI RIP IN NS Comunicazione tra due host (pc1 & pc2) Se ora decidessimo di attivare uno scambio di dati tra il pc1 e il pc2 sia il simulatore che l emulatore ci rispondere allo stesso modo, ma mostrando informazioni diversi. Infatti entrambi indicherebbero il percorso seguito dai pacchetti secondo il protocollo RIP, ma mentre il primo mostra graficamente (figura 9) il percorso dei pacchetti sui vari rami del grafo rappresentante la topologia studiata, il secondo ci permetterebbe di andare su un dispositivo qualsiasi della rete per controllare il flusso dei pacchetti. In questo caso possiamo utilizzare il terminale del pc1 per tracciare i pacchetti inviati al pc2, come output otterremmo le interfacce di rete attraversate. NS oltre a mostrare graficamente il percorso dei pacchetti ci permette di ottenere informazioni statistiche e prestazionali sull intero sistema, che sarebbero impossibili da analizzare su infrastrutture di rete reali.

14 14 FIGURA 9 TRACCIA DEI PACCHETTI IN NS Guasti FIGURA 10 TRACCIA DEI PACCHETTI IN NETKIT Per verificare il comportamento del protocollo RIP abbiamo verificato vari casi di guasti all interno del sistema. Come primo esempio abbiamo considerato il guasto del link 1-4, ovvero il link che collega direttamente r1 a r4. Anche in questo caso la reazione protocollare è la stessa sia per il simulatore che per l emulatore: il traffico si interrompe momentaneamente, i router intercettano il guasto e si scambiano nuovamente i Distance Vector, dopodiché il traffico viene ristabilito sul cammino più breve. Come al solito abbiamo lo stesso risultato mostrato in forme diverse, NS ci mostrerà di nuovo graficamente il percorso dei dati, i nodi attraversati (0,1,5,4,6), mentre Netkit ci consente sia di controllare come al solito le interfacce di rete attraversate, sia di andare su ogni singolo router e verificare che le tabelle di router si sono andate aggiornando dinamicamente, permettendoci così di controllare l azione del protocollo RIP. FIGURA 11 GUASTO IN NS FIGURA 12 TRAFFICO RISTABILITO SU UN SECONDO CAMMINO (NS)

15 Network Infrastructures A.A FIGURA 13 TABELLA DI ROUTING DEL ROUTER "R1" DOPO IL GUASTO (NETKIT) FIGURA 14 INTERFACCE ATTRAVERSATE DAI PACCHETTI DOPO IL GUASTO (NETKIT) Ovviamente con un altro esempio di guasto su un link, vediamo che il protocollo gestisce il danno allo stesso modo, quindi il traffico cambierà nuovamente il suo cammino, i nodi/interfacce di rete attraversate cambieranno, i Distance Vector scambiati dopo il guasto porteranno con se informazioni aggiornate(figura 16), e andranno a modificare le tabelle di instradamento su ogni router. FIGURA 15 CAMMINO DOPO IL SECONDO GUASTO (NS)

16 16 FIGURA 16 "SNIFF" DEI PACCHETTI RIP SUL ROUTER "R1" (NETKIT) Un ultimo caso che abbiamo voluto analizzare è lo studio al simulatore e all emulatore al momento della riattivazione di un link, infatti se il collegamento 1-4 torna funzionante, i nostri strumenti ci permettono di verificare che il traffico viene ristabilito sul percorso più breve, una volta che tutte le informazioni vengono riaggiornate tramite il protocollo RIP. Anche in quest ultimo caso il simulatore ci permette di andare ad analizzare le statistiche sull intero sistema, mentre Netkit ci fornisce come al solito vari modi per interagire con le virtual machines e per verificare il comportamento della singola macchina emulata. FIGURA 17 LINK 1-4 RISTABILITO E TRAFFICO REINDIRIZZATO (NS) FIGURA 18 INTERFACCIA DI RETE DI NUOVO ATTIVA E FUNZIONANTE (NETKIT)

17 17 6. NETKIT & NS: CONFRONTO E DIFFERENZE L'esperimento effettuato ci ha permesso di individuare le caratteristiche fondamentali che distinguono il simulatore NS e l'emulatore Netkit. Tali differenze sono il frutto di una minuziosa analisi effettuata da due diverse prospettive: USER SIDE: Come l'user può interagire con il software Cosa l'user può e non può implementare usando una piattaforma software o l'altra SOFTWARE SIDE: Come vengono implementati gli elementi costitutivi di una rete di calcolatori Come funzionano e qual'è l'architettura alla base del simulatore e dell'emulatore 6.1 DIFFERENZE ARCHITETTURALI Network simulator è un simulatore orientato agli oggetti, scritto in C++, con un interprete Otcl come frontend. Il simulatore supporta una gerarchia di classi in C++ e una simile gerarchia all'interno dell'interprete. Le due gerarchie sono strettamente connesse una con l'altra; dalla prospettiva dell'utente, c'è una corrispondenza 1- to- 1 fra le classi della gerarchia compilata e quelle della gerarchia interpretata. Quindi, quello che a livello architetturale succede durante la simulazione è descritto dal seguente scenario generale: Lo script OTcl, scritto dall'utente, viene dato in pasto all'interprete OTcl, L'interprete si serve di una libreria chiamata TclCL che crea una corrispondenza biunivoca tra la gerarchia delle classi da condividere tra C++ e OTcl, L'interprete esegue la simulazione specificata nello script e visualizza i risultati. Nel nostro caso particolare, l'interprete analizza lo script topologia.tcl. Crea al suo interno la gerachia degli oggetti OTcl specificati nello script stesso. Ad esempio, quando l'interprete elabora il comando $ns rtproto DV crea l'oggetto Otcl corrispondente e viene stabilita la relazione biunivoca tra tale oggetto e l'oggetto C++ rtprotodv : è tale oggetto che ha al suo interno il codice che implementa le caratteristiche del protocollo da utilizzare nella simulazione. Viene eseguita la simulazione e visualizzati i risultati. FIGURA 19 STRUTTURA NS- 2

18 DIFFERENZE IMPLEMENTATIVE: Come vengono realizzati gli elementi della rete Ns implementa gli oggetti della rete sottoforma di classi C++; Sono presenti classi che implementano le caratteristiche di un nodo, di un link, di un agente, di un'applicazione... Netkit non implementa il concetto di oggetto. Con Netkit ogni host risiede su una virtual machine ed essa può emulare le funzioni di un PC, di uno Switch o di un Router. Come faccio a specificare un link? Non è possibile, non ha senso dire che ho una virtual machines che emula un link...esso non è un host! Al contrario Netkit implementa il concetto di dominio di collisione attraverso la definizione di opportune interfacce di rete: ad esempio, l'host1 e l'host2 sono virtualmente connessi allo stesso dominio di collisione attraverso le loro interfacce di rete. 6.3 DIFFERENZE D'UTILIZZO: Come l'utente interagisce col software Ns è un simulatore che prende in input uno script di simulazione e lo interpreta mostrandone i risultati dal punto di vista prestazionale. L'utente cosa deve fare? Scrivere lo script in linguaggio OTcl utilizzando le funzioni che, attraverso il core C++ di Ns, il simulatore fornisce. Netkit è un emulatore che si basa sul concetto di virtual machines. Per questo, non esiste il concetto di linguaggio di scripting con il quale l'utente può interfacciarsi con il software. Quello che deve fare l'utente è interagire con ogni macchina virtuale così come farebbe con l'host che la macchina stessa sta emulando. Esempio: link fra il nodo (1) e il nodo (2) della topologia va down: Ns: specificato nello scripting; Netkit: mandare down l'interfaccia di rete di un host attraverso il terminal di quella determinata vm; 6.4 CAN DO, CAN'T DO NS non distingue tra host e router. Ns permette di specificare i protocolli di routing e le politiche di coda che devono osservare i pkt's quando transitano sulla rete, ma non permette la configurazione di un router come in Netkit. Infatti, non possiede al suo interno un demone che via Telnet permette, ad esempio, la configurazione di un router: Ns non emula l'hw, non usa il concetto di virtual machine, ma di object oriented class. Con Netkit un host generico è una virtual machine che possiede il terminale di quell'oggetto: è come se avessi realmente a disposizione un router e vi accedessi per configurarlo tramite il demone zebra (è la virtual machine che emula su un host il router). In NS, ho soltanto del codice scritto in C++ che viene utilizzato, insieme allo script, dall'interprete per costruire la simulazione ed eseguirla: ho bisogno di un routing protocol dinamico? Ns mi mette a disposizione la classe.cc che mi implementa tal meccanismo e tramite l'interprete lo simulo. Data questa struttura, si può concludere che Ns viene utilizzato prevalentemente per: avere, con sufficiente accuratezza, delle risposte prestazionali riguardo esperimenti altrimenti irrealizzabili nella realtà; Realizzare simulazioni di topologie costose e innovative; L'implementazione in laboratorio di nuovi protocolli o modifiche di quelli esistenti a fini di ricerca; Simulare la ridistribuzione di risorse fra link e nodi con successive analisi del traffico e delle

19 19 prestazioni; Testing: non è concepibile andare a mettere le mani su strutture operative dato che ciò le renderebbe indisponibili all'utente; opportuni test e modifiche vengono eseguite in laboratorio simulando il funzionamento di tali strutture.

20 20 7. CONCLUSIONI: Emulare o Simulare? Dipende... Se si vogliono rilevare le PRESTAZIONI di protocolli esistenti, di nuovi protocolli, di particolari topologie, di cosa succede se viene assegnata la banda in un certo modo e via dicendo, allora usare Network Simulator. Se si vuole capire come realmente FUNZIONANO e configurano gli elementi della rete, usare Netkit. Attraverso l'emulatore posso eseguire gli stessi esperimenti che eseguirei con Network Simulator ma con un'approccio orientato alla funzionalità piuttosto che alle prestazioni. Per questo, vi sono scenari per i quali, la simulazione risulta avvantaggiata rispetto all'emulazione. Nel caso, ad esempio, della realizzazione di nuovi protocolli, con Network Simulator basta scrivere la classe C++ che specifica tale protocollo e inserirla nel core di Ns; con Netkit, il concetto di virtualizzazione implica che se voglio utilizzare un nuovo protocollo devo poterlo emulare: devo riscrivere il kernel! Si capisce come, in questo particolare esperimento, l'uso del simulatore sia da preferirsi a quello dell'emulatore. Infine, si ricordi che Netkit prevede l'utilizzo di una macchina virtuale per ogni elemento della rete che si vuole emulare. La macchina virtuale utilizza delle risorse che sono di proprietà della macchina ospitante e come è noto le risorse sono limitate: un host può ospitare non più di 200 virtual machines e ciò limita la dimensione degli scenari che si desidera emulare. Tali limitazioni, invece, non sono presenti con Network Simulator che non prevede l'uso di virtual machines, ma ogni elemento della rete è semplicemente un oggetto istanza della classe Nodo: ciò permette la simulazione di topologie che prevedono la presenza di milioni di nodi.

21 II. References [1-01] F.Maguolo Ns2: How to setup a simulation, Department of Information Engineering University of Padova. [1-02] S.Ivanov, A. Herms and G. Lukas Experimental Validation of the ns- 2 Wireless Model using Simulation, Emulation, and Real Network, [1-03] The Network Simulator ns [1-04] J. Banks, J. S. Carson, and B. L. Nelson, Discrete- Event System Simulation, 2nd ed. Prentice Hall, [1-05] Netkit: The poor man's system to experiment computer networking [1-06] Netkit- lab_ .pdf [1-07] Routing Information Protocol [1-08] Simulation [1-09] Emulation [1-10] Smith, James E.; Nair, Ravi (2005). "The Architecture of Virtual Machines". Computer (IEEE Computer Society) 38 (5): [1-11] BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS, RFC 922, Jeffrey Mogul, October 1984 [1-12] Network Simulation [1-13] Network Emulation