Capitolo 3
Impostazione della simulazione
3.1
Scenario
Lo scopo di questa parte è spiegare con maggior chiarezza possibile le funzionalità presenti in Opnet per la creazione e gestione del traffico all’interno degli scenari simulati, iniziamo la nostra analisi spigando quali sono tutte le varie possibilità e caratterizzazioni.
Le macchine scelte per i nostri scopi sono macchine complesse che raccolgono al loro interno tutta la pila protocollare, grazie a queste possiamo dare vita a flussi dati mirati e con caratteristiche precise dato che abbiamo la possibilità di interagire fino al livello applicazione.
Questi End-system ci danno quindi la possibilità di creare delle applicazioni che hanno una sorgente un destinatario e tutta una serie di caratteristiche precedentemente impostate, in questo modo è molto semplice creare dei flussi specifici per i nostri scopi.
La gestione dei flussi ovvero la creazione e l'impostazione di tutti i parametri non è immediata e proprio per questo motivo nei prossimi paragrafi cercheremo di darne una descrizione esaustiva per la comprensione degli scenari che verranno presentati in seguito.
Una volta che abbiamo creato lo scenario scegliendo gli End-system , gli switch ed i link giusti dobbiamo fare in modo di creare del traffico all'interno della rete dato che fatta eccezione che per i pacchetti BPDU
inviati dallo switch per la conoscenza della topologia se definisco esplicitamente il traffico dati la rete rimarrà completamente scarica.
Per dichiarare questi flussi dalla barra delle applicazioni richiamo il Object Palette (1), lo stesso che utilizzo quando devo inserire nello scenario nuovi componenti e scelgo il campo Application dal menù a tendina che mi si presenta.
Una volta fatto questo aggiungo allo scenario un processo Application Config (2) e un processo Profile Config (3) che ora compaiono sullo scenario come delle icone.[Figura 22]
3.2
Application
Il processo Application si occupa della definizione dei flussi, all'interno di questo modulo è possibile dichiarare le caratteristiche specifiche di una certa sorgente di traffico.
L'immagine 23 rappresenta la schermata principale del processo di configurazione che si presenta quando, cliccando con il tasto destro del mouse sull’icona della Application Configuration, scegliamo le Advanced Edit Attributes; è questo il menù principale dal quale si decide quanti e quali sono i flussi dati da creare.
La finestra è complessa e presenta molti campi utili per impostare funzionalità particolari ma quello che ci interessa in questo momento è fissare l’attenzione sulla riga Application Definition, basta espandere questa riga e si apre un nuovo menù nel quale sono elencati i vari flussi dati supportati da questo scenario.
Figura 3. Description Table
scenario; ogni applicazione ha le sue caratteristiche precise e non è in alcun modo legata alle altre.
Come si vede nella figura 24 la finestra Application Description Table è formata da due colonne la prima con il nome dell’applicazione mentre la seconda, Description, con la descrizione di quest’ultima.
Il campo Description avendo al suo interno molte caratteristiche relative alle applicazioni è gestita con una ulteriore finestra che si apre non appena si clicca sulla colonna Description all’altezza della procedura da configurare. La Description Table che si apre presenta 9 righe, otto di queste sono associate alle principali fonti di traffico oggi presenti sulle reti e l’ultima è una applicazione Custom, è possibile cioè configurarla a proprio piacimento in tutte le sue parti.
Questa tabella è divisa in due colonne chiamate Attribute e Value, che descrivono rispettivamente l’applicazione e il suo stato attuale; il valore “attivo” è mutuamente esclusivo ovvero il valore può essere impostato solo su una delle applicazioni presenti mentre le altre devono risultare OFF. Nel Momento in cui vado ad impostare su “Attivo” una delle applicazioni ho la possibilità di scegliere tra una serie di valori predefiniti oppure di personalizzare completamente la tabella nella quale sono presenti tutte le caratteristiche della applicazione scelta.
E’ facile intuire che ogni applicazione deve avere una tabella propria in quanto le caratteristiche dei vari flussi sono assai diverse; a titolo di esempio nei prossimi paragrafi analizzeremo a fondo due delle applicazioni multimediali più interessanti ovvero la video conferenza e la trasmissione voce.
3.2.1 Video Conferencing
Come si vede dalla figura la tabella ci da la possibilità di scegliere il numero di Frame al secondo, la risoluzione dell’immagine da inviare, il nome con cui vogliamo chiamare l’applicazione, il tipo di servizio da usare, le impostazioni per l’utilizzo dell’RSVP ed infine il tipo di traffico.
Figura 4. Video Conferencing Table
Molti dei campi sono di facile intuizione perché fanno parte del nostro parlare comune ma comunque soffermiamoci ad analizzarne meglio alcuni per una descrizione esaustiva del problema.
Il Frame Interarrival Time Information è un campo che ci da la scelta sul numero di quadri che possiamo utilizzare per inviare il nostro video più è alto questo numero migliore è la fluidità del video ricevuto e di conseguenza il traffico creato è maggiore, sicuramente la scelta non è facile dato che dobbiamo tenere di conto dei link di cui disponiamo per non
generare ritardi e perdite, quindi la scelta è sempre un compromesso tra qualità e banda disponibile.
Il Frame Size Information è la risoluzione dell’immagine espressa in Pixel, anche in questo caso più è alta la risoluzione maggiore sarà la qualità del video ma allo stesso tempo l’occupazione di banda aumenta.
Posso interagire con questi valori rendendoli adatti alle esigenze della mia trasmissione dato che non necessariamente è presente il codec usato, quindi scegliendo l’opzione Edit dal menù del campo Value posso modificare le caratteristiche del flusso.
La finestra che si apre è molto interessante perché ci permette di modellare il flusso con una qualsiasi distribuzione, la variabile Constant è solo una delle possibilità. [Figura 26]
Figura 5. Frame Size Information Table
Le possibili distribuzioni sono mostrate da una tabella che si presenta espandendo il campo value e che ci da la possibilità di scegliere tra una
quantità di possibilità, per ognuna di queste è presente la possibilità di inserire i valori di riferimento.
Figura 6. Distribution Variable
A seconda della distribuzione scelta e dei valori della variabile aleatoria il flusso può assumere le più svariate forme e simulare una qualsiasi trasmissione e codec.
Le possibilità come abbiamo visto sono le più ampie e ci permettono di accostarci alla realtà moltissimo in modo da rendere il più attendibile possibile lo scenario di simulazione.
La stessa cosa può essere fatta per quanto riguarda
la rappresentazione dei frame al secondo questa volta la distribuzione della variabile invece di essere relativa alla dimensione in Byte del frame sarà il tempo di interarrivo dei frame in un secondo.
Il Type Of Service (TOS) ci da la possibilità di scegliere per ogni applicazione la giusta qualità del servizio che vogliamo associarci, in questo modo è possibile dare più banda ad un traffico voce piuttosto che ad un traffico Ftp, questa scelta è presente in ogni tabella che descrive un certo
flusso in modo tale che ogni applicazione goda delle priorità scelte per la rete in questione.
Figura 7. TOS/DSCP
L’immagine 28 rappresenta la schermata di gestione della qualità del servizio intesa come scelta del tipo di priorità da assegnare al singolo flusso, le possibilità vanno dal Best Effort (0) al Reserved (7) ovvero ben otto classi di traffico per cercare di distinguere meglio possibile le varie esigenze dei flussi a seconda della loro natura.
Questa assegnazione è importantissima per i nostri scopi in quanto in funzione di questa impostazione il pacchetto viene marcato nel campo TOS con il valore da noi scelto, questo ci permette di leggere l’informazione e passarla al momento della trasmissione sul campo Priority del TAG VLAN nell’incapsulamento del livello 2.
Nello switch possiamo quindi sapere la classe di priorità a cui appartiene il pacchetto senza aver bisogno di decapsulare il pacchetto, questa
informazioni in condizioni normali non ci è dato di saperla a meno che non venga utilizzato un router inoltre il processing del passaggio attraverso il nodo viene diminuito.
3.2.2 Voice
Come si vede dalla tabella relativa alla configurazione delle caratteristiche del traffico voce queste impostazioni sono più complesse in quanto devono definire un traffico che è molto più sensibile ai ritardi.
Figura 8. Voice Table
Il campo Silence Length ed il campo Talk Spurt Length rappresentano le variabili che modellano i tempi di parlato e di silenzio in una tipica trasmissione voce, come per la video conferenza possiamo scegliere la migliore soluzione attraverso la simulazione di distribuzioni probabilistiche.
La tabella per la gestione dei modelli probabilistici è quindi del tutto simile, ma questa volta la variabile rappresenta il tempo espresso in secondi del silenzio presente nella comunicazione in ingresso ed in uscita.
Figura 9. Silence Length Table
Il campo Encoder Scheme indica il codec voce, il simulatore contiene di default tutti gli standard utilizzati per le trasmissioni voce, come si può vedere dall’immagine di fianco.
E’ possibile avviare le simulazioni con codici specifici per il VoIP oppure utilizzare codifiche particolari come quella GSM, ognuna di queste produce un ben preciso traffico sulla rete e gode di certe caratteristiche che sono state standardizzate dagli organi preposti.
Il Voice Frames Per Packet gestisce il numero di frame che possono essere inseriti nel pacchetto durante la trasmissione, cioè il numero di frame che l’applicazione può passare allo strato inferiore della pila protocollare.
è un campo molto importante e delicato, anche in questo caso la scelta delle impostazioni è fondamentale dato che la comunicazione voce soffre molto degli eccessivi ritardi End-to-end.
Figura 10. Codec Voce
L’ultimo campo da analizzare è il Signaling, questa opzione ci da la possibilità di decidere se utilizzare un meccanismo di segnalazione durante la trasmissione voce, le possibilità non sono molte dato che opnet riproduce solo il protocollo SIP.
3.3
Profile
Il Profile Config si occupa della gestione dei flussi dati definiti precedentemente nell’ Application Config, è in questo processo che si decidono le caratteristiche di durata e ripetibilità di una certa applicazione, vediamo nel dettaglio la tabella Advanced Edit Attribute, rappresentata in figura 32, per capire quali sono le reali possibilità di configurazione di uno scenario.
L’attributo Profile Configuration è il campo che dobbiamo andare ad analizzare in dettaglio perché è da qui che parte tutta la gestione delle applicazioni.
Figura 11. Profiles Attributes
Espandendo l’attributo ci troviamo di fronte la tabella di gestione dei profili, vedi figura 33, da qui è possibile definir il numero e le caratteristiche dei profili che vogliamo inserire nello scenario di simulazione.
La tabella è suddivisa in 6 colonne che descrivono tutte le caratteristiche necessarie al corretto funzionamento del flusso dati, analizziamole una ad una.
arbitrario ma è utile che richiami il tipo di applicazione a cui facciamo riferimento in modo che non ci siamo fraintendimenti sul flusso generato dato che è possibile creare più profili riferendoli alla stessa applicazione.
Figura 12. Profile Configuration Table
Il campo Application una volta espanso ci permette di richiamare una delle applicazioni precedentemente definite nell’ Application Configuration collegando il nome del profilo specificato ad un preciso flusso dati.
Nella figura 34 si vede che dalla tabella Application Table è possibile richiamare all’interno dello stesso profilo anche più di una delle applicazioni definite e decidere per questi flussi un tempo di inizio, di fine e di ripetizione all’interno del profilo scelto.
Il campo Start Time Offset controlla il tempo che intercorre tra la fine dell’applicazione precedente e l’inizio della successiva mentre il campo Duration ne decide la durata, a secondo di questi due valori all’interno del profilo posso fare in modo che l’applicazione si ripeta più di una volta, questa scelta è gestita dal campo Repeatability.
Questo mi permette per una stessa sorgente di dare vita ad un traffico complesso formato ad esempio da una video conferenza e da un traffico
voce successivo alla chiusura di questa applicazione e inserire come traffico di Background una serie di sessioni Ftp o Telnet, il traffico può modellarsi su una funzione probabilistica o essere inserito ad un tempo preciso.
Figura 13. Application Table
Il campo Operation Mode decide se le applicazioni scelte in quel profilo possono partire insieme (Simultaneous) o una in serie all’altra (Serial), le scelte dei tempi per le singole applicazioni devono essere coerenti con questa scelta altrimenti lo scenario viene alterato e la simulazione perde di significato, la priorità è assegnata alla tabella Profile Configuration in quanto i tempi scelti per le applicazioni si riferiscono a intervalli interni al profilo. Le colonne Start Time, Duration e Repeatability indicano rispettivamente il tempo di inizio, la durata e la possibilità che venga ripetuta la trasmissione all’interno della simulazione, tutti questi campi possono essere gestiti in modo deterministico oppure come già visto precedentemente possono essere modellati su variabili probabilistiche in modo da avere la più ampia possibilità caratterizzazione della simulazione.
3.4
Workstation
L’ultima fase della configurazione del traffico sta nel associare i profili con le sue rispettive applicazioni ad una certa workstation, questa associazione viene fatta dal menù Advanced Edit Attribute e deve essere fatta per ogni end system a cui vogliamo associare del traffico.
Figura 14. Workstation Attribute
La figura 35-36 mostra che all’interno della tabella è presente un campo Application, questa opzione ci ricollega al lavoro di definizione dei flussi fatto fino a questo momento infatti espandendo l’attributo si aprono una serie di campi dai quali posso richiamare per questa specifica macchina i
profili creati.
Analizziamo i campi dell’attributo Application nel dettaglio per sfruttare al meglio tutte le potenzialità del simulatore.
Figura 15. Workstation Application
Il campo Destination Preferences ci da la possibilità di scegliere tra tutti gli end system quello su cui indirizzare il flusso dati che verrà generato da questa macchina; per fare questo devo assegnare alle macchine destinazione
dei nomi unici nel campo Client Address sostituendo il valore Auto Assigned. Espandendo l’attributo Supported Profile si apre la tabella di figura 37, una volta che ho associato ad una macchina il nome di un profilo non devo impostare nient’altro dato che precedentemente quel Profile Name è stato definito nei minimi dettagli; posso associare più di un profilo alla stessa macchina facendo attenzione che le scelte dei tempi siano coerenti.
Figura 16. Supported Profile Table
Gli ultimi due campi, il Supported Service e il Transport Protocol Specification sono due attributi che servono per definire rispettivamente i servizi supportati da quel end system ed il tipo di protocollo usato per le varie applicazioni.
3.5
Scenari simulati
In questo paragrafo saranno presentati degli esempi di simulazione con scenari molto semplici e trasmissioni standard utili per verificare la consistenza delle simulazioni con il traffico dati reale.
3.5.1 Scenario 1
Figura 17. Scenario 1
Ethernet 10/100 Mbit/sec a cui sono attaccati 10 end system tramite un link a 100 Mbit/sec.
La prima simulazione propone una videoconferenza ad alta qualità (Flusso 1) tra il “nodo 0” ed il “nodo 5” e nel medesimo intervallo di tempo una videoconferenza definita light (Flusso 2) tra il “nodo 7” ed il “nodo 2”.
Videoconferenza 1:
30 Frame/secÆ CONST (0.0333) 352x240 PixelÆ CONST (253440)
253440 Byte/Frame * 30 Frame/sec = 7603200 Byte/sec
Videoconferenza 2:
10 Frame/secÆ CONST (0.1) 128x120 PixelÆ CONST (17280)
17280 Byte/Frame * 10 Frame/sec = 172800 Byte/sec
Le altre macchine non producono nessun tipo di traffico quindi la simulazione deve ritrovare questi valori precisi e solo sui link di collegamento delle macchine in precedenza configurate.
Vediamo i risultati tramite i grafici che Opnet ci fornisce in uscita:
Analizzando link per link lo scenario dopo la simulazione si vede che non ci sono state trasmissioni se non sui collegamenti dei nodi 0,2,5,7 ed inoltre i grafici ottenuti sono perfettamente in linea con i conti precedenti.
Grafico 1. Videoconferenza 1 (Byte/Sec)
Il primo grafico si riferisce al flusso della videoconferenza 1 ovvero riguarda il link che unisce il nodo 0 con il 5.
Grafico 2. Videoconferenza 2 (Byte/Sec)
Il secondo grafico si riferisce al flusso della videoconferenza 2 ovvero riguarda il link che unisce il nodo 2 con il 7.
3.5.2 Scenario 2
Figura 18. Scenario 2
Lo scenario proposto è composto di un comune switch con 16 porte Ethernet 10/100 Mbit/sec a cui sono attaccati 15 end system tramite un link a 100 Mbit/sec.
La seconda simulazione propone 6 chiamate voce simultanee, per ogni chiamata abbiamo scelto un codec diverso in modo da poter confrontare tra loro i traffici generati e per vedere la corrispondenza con la banda dichiarata
per ogni codec.
Chiamata voce 1: Nodo 0Æ1
Encoder ITU G.711
Bit rate 64 Kbit/sec (8000Byte/sec)
Chiamata voce 2: Nodo 2Æ3
Encoder ITU G.711 (Voice Suppressed)
Chiamata voce 3: Nodo 4Æ5
Encoder ITU G.723.1
Bit rate 5.3 Kbit/sec (662 Byte/sec)
Chiamata voce 4: Nodo 6Æ7
Encoder ITU G.723.1 (Voice Suppressed)
Chiamata voce 5: Nodo 8Æ9
Encoder ITU G.729 CS-ACELP
Bit rate 8 Kbit/sec (1000 Byte/sec)
Chiamata voce 6: Nodo 10Æ11
Encoder ITU G.729 CS-ACELP (Voice Suppressed)
Grafico 3. Chiamata 1 Codec ITU G.711
Grafico 4. Chiamata 2
Grafico 5. Chiamata 3 Codec ITU G.723.1
Grafico 6. Chiamata 4
Grafico 7. Chiamata 5 Codec ITU G.729 CS-ACELP
Grafico 8. Chiamata 6
Codec ITU G.729 CS-ACELP (Voice Suppressed)
Come si può notare dai grafici ottenuti dopo la simulazione del secondo scenario, i risultati sono perfettamente in linea con i bit rate teorici.
I dati sopra riportati non si riferiscono al flusso dati effettivamente presente sul link ma all’uscita del codec usato dall’End-system, per arrivare a valutare l’effettiva occupazione di banda dobbiamo fare riferimento al traffico prodotto sui link interessati.
Nel seguito faremo riferimento a questi codec ma i valori appariranno maggiorati dato che utilizzeremo il valore dei dati presenti sui link; questo
significa che al valore teorico andrà sommata una quota pari ad eventuali incapsulamenti dei dati.
3.6
Scenario di Verifica
Figura 19. Scenario 3
Questo scenario serve a capire e verificare il funzionamento dello scheduler implementato in Opnet, per questo motivo abbiamo creato una situazione che ci possa aiutare a verificare facilmente i risultati ottenuti dalle
simulazioni prima di dare vita a scenari più complessi; questa è la prima prova che viene fatta con lo scheduler WFQ attivo a livello 2 inserito sul processo MAC degli switch presenti.
Questo scenario è formato da due switch con 16 porte ethernet 10/100 Mbit/sec a cui sono collegati 4 end system, i link che collegano i nodi TX_n sono da 10 Mbit/sec mentre quelli che collegano le postazioni RX_n sono da 100 Mbit/sec; il link di collegamento tra i due switch è volutamente scelto da 10 Mbit/sec in modo da creare un collo di bottiglia all’uscita dello switch.
Nel processo Application Configuration sono stati creati 4 flussi con un rate di 10000000 MBit/sec modificando le impostazioni predefinite e rendendo i flussi più adatti ai nostri scopi.
Ho impostato il numero di frame a 25/sec seguendo lo standard europeo (PAL) ed ho deciso di utilizzare 50000 byte per ogni frame in modo che alla fine dei calcoli risultasse il flusso voluto.
50000 Byte/frame * 25 frame/sec * 8 bit = 10000000 Mbit/sec
Il flusso 3, che collega il nodo TX_3 con il RX_3, ha una qualità del servizio impostata in modo tale che venga associato alla coda con peso 3, il flusso 2, che collega il nodo TX_2 con il RX_2, ha una qualità del servizio impostata in modo tale che venga associato alla coda con peso 2, il flusso 1, che collega il nodo TX_1 con il RX_1, ha una qualità del servizio impostata in modo tale che venga associato alla coda con peso 1, il flusso 0, che collega il nodo TX_0 con il RX_0, ha una qualità del servizio impostata in modo tale che venga associato alla coda con peso 0. Strutturando lo scenario in questo modo posso vedere facilmente il throughput in uscita dallo scheduler dello switch 0 sui link che uniscono lo switch 1 ai nodi RX_n dato che è presente un solo collo di bottiglia e non esiste altro traffico se non quello tra le macchine TX_0 con RX_0 , TX_1
con RX_1 e così via.
I grafici che otteniamo da questa simulazione devono essere coerenti con le occupazioni di banda impostate nello scheduler, verifichiamo con l’ausilio dei risultati.
Figura 20. Throughput
Nel processo Profile Configuration sono stati creati 4 diversi profili da associare alle macchine, i flussi sono impostati per partire ad istanti diversi: il flusso 3 parte all’istante 10 sec il flusso 2 parte a 30 sec il flusso 1 parte a
50 sec ed infine il flusso 0 parte a 70sec; la simulazione nel complesso dura 150 secondi (2 Min e 30 sec).
I risultati ottenuti sono ottimi, come possiamo vedere, il flusso che parte prima occupa la totalità della banda del link in uscita senza restrizioni dato che è l’unico flusso presenta in quel momento sulla rete, successivamente subentra un flusso che ha un peso maggiore e quindi il primo flusso lascia la maggior parte della banda al secondo flusso secondo i parametri impostati. Il secondo flusso ha un peso di 2 mentre il primo di 1 quindi la ripartizione della banda è così fatta :
(10000000 Mbit/sec ) / 3 = 3333333 Mbit/sec 1° Flusso Æ 3333333 Mbit/sec
2° Flusso Æ 6666666 Mbit/sec
questi valori sono riscontrabili dal grafico di figura 41 nell’intervallo di tempo 30-50 secondi.
Successivamente entra il terzo flusso che ha un peso maggiore di entrambi quelli presenti e quindi andrà ad occupare una porzione di banda maggiore rispetto a quella degli altri due, il terzo flusso ha un peso di 3 quindi la ripartizione della banda questa volta sarà :
(10000000 Mbit/sec ) / 6 = 1666666 Mbit/sec 1° Flusso Æ 1666666 Mbit/sec
2° Flusso Æ 3333333 Mbit/sec 3° Flusso Æ 5000000 Mbit/sec
questi valori sono riscontrabili dal grafico nell’intervallo di tempo 50-70 secondi.
dell’ultimo flusso che ha un peso di 4 e si prende anch’esso la sua parte di banda proporzionale al suo peso quindi ne prende la maggior parte.
Vediamo come si suddivide la capacità del canale in questo caso:
(10000000 Mbit/sec ) / 10 = 1000000Mbit/sec 1° Flusso Æ 1000000 Mbit/sec 2° Flusso Æ 2000000 Mbit/sec 3° Flusso Æ 3000000 Mbit/sec 4° Flusso Æ 4000000 Mbit/sec Figura 21. Throughput
I risultati ottenuti sono soddisfacenti e coerenti con le impostazioni sia dello scheduler che del simulatore, per essere sicuri che effettivamente le prestazioni siano coerenti con la logica usata abbiamo fatto altre prove come per esempio fare in modo che uno dei flussi si spenga dopo 120 secondi per vedere se i flussi si stabilizzano al rate giusto oppure applicare i flussi appena descritti in senso opposto
Come si vede dal grafico di figura 42 se ad un certo istante di tempo il flusso con peso maggiore cessa di essere attivo lo scheduler fa in modo che agli altri venga assegnata nuovamente la banda originale in funzione dei loro pesi, infatti possiamo verificare che la situazione risulta identica all’intervallo precedente.
I flussi rimasti attivi si ripartiscono il link da 10 Mbit/sec secondo i pesi
impostati occupando rispettivamente 5 Mbit/sec, 3.33 Mbit/sec, 1.66 Mbit/sec.
Abbiamo fatto un’ulteriore prova facendo in modo che il primo flusso ad occupare il canale sia quello con peso più alto per vedere se anche in questo caso lo scheduler si comporta in modo equo.
Come si vede dai risultati di figura 43 anche se il primo flusso ad entrare è quello con peso maggiore appena entrano gli altri il suo throughput si stabilizza al bit rate giusto.
Alla fine della simulazione i rate dei flussi risultano coerenti con i valori impostati e con le prove precedenti ovvero risulta che si sono stabilizzati rispettivamente a 4 Mbit/sec, 3 Mbit/sec, 2 Mbit/sec ed 1 Mbit/sec.
