Prove sperimentali

Prove sperimentali

6.1

Il testbed sperimentale

Le prove sperimentali per l’architettura client-server del sistema di misura sono state effettuate presso il Dipartimento di Ingegneria dell’Informazione dell’Università di Pisa, nei laboratori del TLC Netgroup.

Lo scopo primario delle prove svolte è stato quello di verificare l’ottem-peranza del progetto alle funzionalità fissate come obiettivo, in tutte le possibili circostanze. A tal proposito è stato allestito un banco di prova sperimentale composto da due PC, dotati entrambi degli strumenti relativi all’architettura MAID di cui si è discusso nel primo capitolo:

· PC1 (192.168.3.1): processore Pentium IV ad 1,76 GHz, con sistema

operativo Linux Slackware 9.1, kernel 2.4.25 con patch per MPLS · PC2 (192.168.3.2): processore Athlon-M a 2,8 GHz, con sistema

Il testbed di prova è schematizzato in figura 6.1.

Figura 6.1 – Testbed sperimentale

I due PC sono collegati in rete con tecnologia Fast Ethernet a 100 Mbit/s. Il PC1 possiede due interfacce di rete distinte, ad una delle quali è connesso direttamente il PC2. La seconda interfaccia del PC1 è connessa invece alla LAN del laboratorio, che consente anche l’accesso ad Internet. Entrambi i PC del testbed possono gestire l’instaurazione degli LSP con qualità del servizio DiffServ e rappresentare pertanto un MA-LER DS di un dominio MAID. Su di essi è presente il sistema di misura Metercontroller, sviluppato dall’Ing. Francesco Oppedisano nell’ambito del progetto TANGO.

Software utilizzato

Per lo svolgimento delle prove sono stati usati i seguenti software: · Programmi per la generazione di traffico (Brute [6-1], Rude [6-2])

PC 1

· Software applicativi dell’architettura MAID, appartenenti al progetto TANGO, per l’instaurazione e la gestione degli LSP con qualità del servizio (sono previsti per la componente DiffServ otto PHB)

· Sistema di misura Metercontroller; nel thread controller della compo-nente in user space è stato integrato il server realizzato per questa tesi di laurea

· Client Interface Manager, programma multi-client realizzato per questa tesi, per la connessione simultanea a più Metercontroller mediante i thread Client Interface

· Programma Tester, una semplice User Interface di prova realizzata sempre nell’ambito di questa tesi di laurea, con input da tastiera per la formazione e l’invio dei messaggi XML e output a schermo (senza interfaccia grafica) dei messaggi XML ricevuti, necessaria per il pilotaggio del CIM

· Meterplotter, software per il plotting in tempo reale dei dati di traffico salvati sull’hard disk dai moduli CI ed aggiornati ad ogni istante di campionamento, realizzato dall’Ing. Francesco Lamonica nel contesto del progetto TANGO

· Librerie (tuttora in fase di sviluppo) relative ai plug-in per le funzioni di stima nel CIM: in particolare sono stati utilizzati un estrapolatore lineare ed un estrattore di media con finestra mobile

6.2

Descrizione delle prove

Per la verifica della funzionalità dell’architettura client-server sono state effettuate più prove, variando la configurazione in modo da aumentarne man mano la complessità.

Prima sessione: singolo Metercontroller

Nella prima prova, mostrata schematicamente in figura 6.2, è stato creato uno LSP (id. 334) dal PC1 verso il PC2. Sul PHB best effort (BE) di questo LSP è stato mappato il traffico TCP proveniente dall’esterno del testbed e diretto verso il PC2, che consisteva in una sessione FTP ed alcune HTTP (il PC2 è stato connesso ad Internet usando il PC1 come gateway). Sul PC1 è stato eseguito dapprima il sistema di misura Metercontroller, quindi il Client Interface Manager ed il Tester. Una volta connesso il Tester al CIM, è stata richiesta la creazione di un CI connesso al controller locale (192.168.3.1). Si è poi richiesta una full connection al controller, quindi si è graficato in tempo reale l’andamento del traffico sullo LSP 334 mediante il Meterplotter. In figura 6.5 è mostrato uno screenshot della prima prova.

Figura 6.2 – Prima sessione: prima prova

Nella seconda prova sono stati creati due LSP. Sul PHB BE del primo, di id. 234, è stato mappato il traffico TCP come per la prova precedente. Sul BE del secondo, di id. 334, è stato mappato il traffico UDP (CBR) generato con Brute da un PC del laboratorio esterno al testbed e diretto al PC2 via PC1. La figura 6.3 mostra schematicamente la seconda prova. Sul PC1 sono stati eseguiti il Metercontroller, il CIM ed il Tester, ed è stata richiesta una full

192.168.3.1 Metercontroller CIM Tester LSP 334 BE

PC 1

PC 1

PC 2

PC 2

connection. Sono stati monitorati con il Meterplotter entrambi gli LSP; in figura 6.6 è possibile vedere uno screenshot.

Figura 6.3 – Prima sessione: seconda prova

Seconda sessione: multiplo Metercontroller

Per testare la funzionalità multi-client del CIM si è creato un LSP di id. 2000 dal PC2 al PC1, in aggiunta ai due dal PC1 al PC2 (id. 234 e 334) della prova appena descritta. Sul PC2 sono stati eseguiti il Metercontroller ed un generatore di traffico (Rude), il cui traffico UDP è stato mappato sullo LSP 2000. Sul PC1 sono stati eseguiti Metercontroller, CIM e Tester. Sono stati creati due moduli CI, uno connesso al controller locale (192.168.3.1) ed uno connesso al controller sul PC2 (192.168.3.2). La prova è mostrata in figura 6.4. Per ciascun controller è stata richiesta una full connection, e sono stati monitorati con il Meterplotter tutti e tre gli LSP. La figura 6.7 mostra uno screenshot relativo a questa prova.

Nelle prime due sessioni descritte sono stati testati con successo tutti gli altri comandi che può ricevere il controller: change parameters, lsp delete, abort, clear, commit, stop e tutti i tipi di db access.

192.168.3.2 192.168.3.1 LSP 234 BE Metercontroller CIM Tester LSP 334 BE

PC 1

PC 1

PC 2

PC 2

Figura 6.4 – Seconda sessione: prima prova

Terza sessione: predizioni statistiche

In questa sessione di prove sono stati testati i due comandi già operativi nell’ambito delle predizioni statistiche: estimators list e add estimator. Le librerie di plug-in di stima disponibili al momento comprendono due sem-plici tipi di stimatore:

· Estrapolatore lineare (chiamato linear nel protocollo di richiesta). La funzione non riceve parametri in ingresso e calcola la stima del campione successivo secondo la seguente formula:

· Media degli ultimi n campioni (chiamato media). La funzione riceve in ingresso la dimensione n della finestra di campioni sui quali effettuare

la media. Questo tipo di operazione ha un effetto di smoothing (passa basso) sull’andamento del traffico, tanto più marcato quanto maggiore è la finestra. La formula è la seguente:

192.168.3.2 192.168.3.1 LSP 2000 BE LSP 234 BE Metercontroller CIM Tester LSP 334 BE

PC 1

PC 1

PC 2

PC 2

[ ]

i

1

2X

[ ] [ ]

i

X

i

1

X

ˆ

+

=

−

−

[ ]

_∑

[ ]

−

=

+

k

i

X

n

1

1

i

X

ˆ

Nella prima prova di questa sessione la configurazione del testbed è la stessa della seconda prova della prima sessione, con un solo Metercontroller sul PC1 e due LSP (id. 234 e 334). Sono stati agganciati lo stimatore linear e lo stimatore media (con il parametro n posto a 25) allo LSP 234. In figura

6.8 è mostrato uno screenshot relativo a questa prova: la traccia in rosso è relativa alle misure, quella in blu alla stima lineare, quella in verde alla stima tramite media degli ultimi 25 campioni.

Nella seconda e nella terza prova di questa sessione la configurazione del testbed è invece uguale a quella dell’unica prova della seconda sessione, con tre LSP attivi (id. 234 e 334 da PC1 a PC2, id. 2000 da PC2 a PC1), due Metercontroller ed altrettanti moduli CI ad essi collegati. In regime di full connection su entrambi i controller, nella seconda prova lo stimatore linear è stato agganciato allo LSP 2000, come è mostrato in figura 6.9, dove il rosso è la traccia del traffico ed il blu quella della stima.

Nella terza prova lo stimatore linear è stato agganciato sia allo LSP 234 che al 2000. Lo screenshot relativo a questa terza prova è mostrato in figura 6.10: col Meterplotter è stato seguito l’andamento del traffico per i due LSP (in rosso per il 234 ed in verde per il 2000) e l’andamento delle due stime (in blu ed in viola, rispettivamente).

Le funzioni di agganciamento stimatore e lista degli stimatori si sono in questa sessione dimostrate operative. Dalla pagina seguente in poi sono presentate tutte le figure relative alle tre sessioni di prova effettuate ed appena descritte.

6.3

Conclusioni

Le prove sperimentali hanno evidenziato la completa funzionalità del sistema sviluppato per questa tesi di laurea, pertinentemente agli obiettivi proposti, che si limitavano alla piena operatività del monitoring remoto. Il sistema di misura Metercontroller, dotato dell’architettura client-server sviluppata in questo progetto di tesi sperimentale, costituisce uno strumento utile e flessibile per la gestione di un dominio MPLS-DiffServ. Allo stato attuale delle cose, esso è pronto per le applicazioni di monitoring dell’intera frontiera del dominio, e fornisce il supporto per l’implementazione delle predizioni statistiche del traffico e per l’impostazione di soglie di attenzione sia sui dati rilevati che sulle loro stime. Alcune funzioni statistiche sono già operative.

Il sistema si presta a numerosi sviluppi futuri volti sia al suo completamento che al suo utilizzo per applicazioni avanzate di traffic engineering.

Per quanto riguarda il monitoring, è auspicabile la creazione di una User Interface grafica, secondo i dettami già spiegati nel paragrafo 4.5. Essa completerebbe di fatto il sistema per quanto riguarda la presentazione dei valori misurati al network administrator, che potrebbe disporre su più finestre dei dati di traffico dei vari MA-LER DS, scegliendo comodamente per ciascuno di essi LSP e PHB desiderati, con la possibilità di variare per tutti i Metercontroller i parametri di funzionamento (ad esempio aumentare o diminuire il rate di campionamento). L’interfaccia grafica semplifichereb-be notevolmente anche la fase di richiesta delle operazioni e la conseguente fase di creazione ed invio dei messaggi XML.

ed interpretazione che per l’invio dei messaggi sullo estimate socket, ed è già in grado di rispondere alla richiesta estimators list. Le altre richieste sono passate ai moduli CI, dove l’implementazione dell’esecuzione dei task di stima (che coinvolge l’accesso al database locale di traffico) non è stata ancora completata, con l’eccezione dell’agganciamento di uno stimatore ad uno LSP (richiesta add estimator). Conseguentemente, buona parte della messaggistica di replica descritta nel paragrafo 5.5.2 non è ancora operativa (pur essendo pronte le strutture e le funzioni per l’invio del messaggio, una volta generato). Per quanto riguarda tali repliche, l’implementatore delle funzioni per le stime e le soglie dovrà semplicemente inviare messaggi avvalendosi degli strumenti già presenti a tale scopo ed ottemperando al protocollo.

Ulteriori espansioni del progetto potrebbero prevedere l’automatizzazione delle procedure di admission control alla frontiera del dominio. Si potrebbe decidere di consentire l’accesso ad un nuovo flusso dati in base alle misure di traffico ottenute in tempo reale (che fotografano istante per istante il carico della rete), oppure in base alle predizioni statistiche. Questo consenti-rebbe di sfruttare con maggiore efficienza le risorse disponibili, instradando il traffico in modo intelligente ed efficace.