Embed Size (px)
Citation preview
Università degli studi di Ferrara
FACOLTA’ DI INGEGNERIA Tesi di laurea in Ingegneria Informatica
BASI DI DATI
Ottimizzazione delle risorse di rete nel progetto InSeBaLa della RER:
modelli, simulazioni ed analisi dinamica dei percorsi di banda migliore
Tesi di laurea di: ELISA BENETTI
Relatore: Dott.ssa CRISTINA DE CASTRO
Correlatore:
Dott. PAOLO TOPPAN
Anno Accademico 2005/2006
II
Desidero innanzitutto ringraziare la Dott.ssa Cristina De Castro e il Dott. Paolo Toppan per avermi assistita, spronata e incoraggiata in corso d’ opera e durante la stesura di questa tesi. Ringrazio il Progetto InSeBaLa della Regione Emilia Romagna che ha supportato la mia attività di stage e tesi e i gruppi del CNIT e dell’ IEIIT-CNR di Bologna, per avermi permesso di vivere con loro questa esperienza di ricerca. Grazie a mio padre per avermi sostenuto in questi anni con la sua solita allegria ed ottimismo nei confronti della vita. Ringrazio gli amici che hanno creduto in me e i colleghi per le intense ore di studio vissute insieme divertendoci comunque, sempre. Grazie alle zie per l’ affettuosa costante presenza. Grazie nonno, di tutto, questa laurea è anche per te....e grazie mamma che dalla mia nascita hai vissuto ogni giorno della tua vita mettendomi al primo posto, e così hai fatto anche in questi tre anni, sempre pronta ad offrirmi pazientemente una spalla su cui piangere ma anche a darmi una scossa per farmi reagire e tornare a lottare. Grazie a tutti voi per essere stati al mio fianco fino ad oggi, siete stati i migliori “compagni di viaggio” che potessi desiderare.
III
Sommario Contesto: l’attività di tesi e tirocinio si è svolta presso la sezione di Bologna del centro IEIIT-CNR, e riguarda il progetto InSeBaLa (Integrazione di Servizi su Banda Larga) della Regione Emilia Romagna. Scopo del progetto è l’integrazione fra le reti regionali e l’implementazione di una piattaforma comune per il rilascio di servizi su banda larga orientati al lavoro cooperativo. Una funzionalità fondamentale di tale piattaforma è l'“emergenza software”, un particolare tipo di ottimizzazione di rete basata sul rilascio selettivo di risorse e servizi a seconda del grado di coinvolgimento dell’utente in una situazione critica.
Temi trattati: il contributo di questa tesi e dell’attività di tirocinio riguarda lo sviluppo del modulo che gestisce situazioni di emergenza dovute al carico di rete. In particolare, sono stati definiti e realizzati modelli per la rappresentazione della rete fisica e dello scheduling dei controlli di carico. È stato anche messo a punto ed implementato un algoritmo di routing basato sull'algoritmo di Dijkstra, che, al variare dei rilevamenti di banda disponibile, ricalcola dinamicamente i percorsi di banda ottima. In cooperazione con un altro tesista, Sig. Fabio Brunelli, sono state perfezionate le strutture per la rappresentazione del modello sul sistema informativo sottostante la piattaforma. In vista di uno studio approfondito di valutazione del modello, sono stati anche effettuati studi preliminari sul modello di simulazione di rete Ns2 e sulle problematiche della sua installazione.
Parole chiave: emergenza software, modelli di rete e di scheduling dei controlli, modelli di routing, Ns2.
IV
Indice
Introduzione ...............................................................................................1
1. Il progetto InSeBaLa delle “Scrivanie Distribuite”
1.1. Finalità e linee guida.........................................................................3
1.2. Architettura d’integrazione...............................................................4
1.2.1. Il sistema abilitante LDAP/MySql...........................................5
1.2.2. Accesso ai servizi.....................................................................6
2. La funzionalità “Emergenza Software” per l’ottimizzazione di rete
2.1. Finalità, definizione e requisiti........................................................13
2.2. Architettura dell’emergenza software.............................................15
2.2.1. Rappresentazione LDAP dell’emergenza...............................16
2.2.2. Fasi dell’autenticazione ed accesso ai servizi.........................16
2.2.3. Architettura globale dell’emergenza software........................19
2.3. Il blocco decisore emergenza ed il database di rete.........................20
2.3.1. Integrazione del blocco decisore nel sistema abilitante..........21
3. Modello della rete, del routing e del monitoraggio
3.1. Rappresentazione e simulazione del grafo di rete...........................24
3.1.1. Modello ed algoritmo di simulazione del grafo di rete...........25
3.2. Modello di scheduling dei controlli per il monitoraggio del carico
di rete................................................................................................29 3.2.1. Rappresentazione gerarchica dei controlli.............................30
3.2.2. Il framework SNMP e le misure utilizzate.............................30
3.3. Un algoritmo di routing basato sull’algoritmo di Dijkstra...............36 3.3.1. Modifica dell’algoritmo di Dijkstra per il calcolo del
percorso di banda ottima e del relativo link peggiore ............37
3.3.2. Scelte di implementazione e valutazione delle prestazioni....38
V
3.4. Schema del database di rete.............................................................40
3.5. Analisi dinamica dei percorsi di banda migliore.............................43
4. Studi preliminari ed installazione di Ns2
4.1. Generalità........................................................................................45
4.2. Problematiche di installazione........................................................47
4.3. Simulazioni.....................................................................................48
4.3.1 Generalità algoritmo Link-State..............................................48
4.3.2 Generalità algorimo Distance Vector.......................................51
4.3.3 Operazioni preliminari.............................................................52
4.3.4 Confronti..................................................................................55
5. Conclusioni e sviluppi futuri...............................................................59
Bibliografia e sitografia.............................................................................60
Lista delle tabelle ......................................................................................63
Lista delle figure........................................................................................63
Contenuto del cd........................................................................................64
1
Introduzione La crescente complessità e le potenzialità d’interazione delle tecnologie dell’informazione rendono necessario l’utilizzo di piattaforme per la gestione integrata di dati, risorse e servizi [1][2][3][4]. Lo scopo primario di queste architetture è fornire un sistema abilitante comune per l’accesso integrato alle diverse funzionalità offerte, ma ci sono altri vantaggi, ad esempio la riduzione della ridondanza, il contenimento dei costi di amministrazione e politiche di sicurezza sviluppate a livello di azienda e quindi più efficacemente controllate. D’altro canto, il rilascio di molti servizi multimediali a banda larga su reti wired o wireless impone un monitoraggio costante del traffico di rete e delle risorse. L’ottimizzazione e l’adattatività di rete rivestono di conseguenza un ruolo fondamentale e coinvolgono aspetti anche assai diversi [5][6][7][8].
Il progetto InSeBaLa [9][10][11][12][13] nasce quindi con l’intento di creare una rete regionale avanzata, integrata nelle tecnologie, capace di omogeneizzarne di nuove e di sviluppare inoltre una piattaforma comune, per l’accesso integrato a servizi multimediali su banda larga. Questa piattaforma prevede infine, sotto diversi aspetti, l’ottimizzazione delle risorse di rete ed è proprio in questo contesto che nasce il lavoro presentato in questa tesi. Una funzionalità fondamentale del sistema abilitante è infatti l'”emergenza software”, ideata appositamente per questo ambiente. L'emergenza software realizza un particolare tipo di ottimizzazione di rete e gestione della sicurezza negli accessi, basate sul rilascio selettivo di risorse e servizi in base al grado di coinvolgimento dell’utente in una situazione critica, sia essa dovuta a problemi di traffico di rete (emergenza rete) o ad eventi catastrofici sul territorio (emergenza geografica). In quest'ottica, i diritti di un utente non sono più definiti staticamente in base all'appartenenza a gruppi, ma anche in base al livello di emergenza rilevato nel luogo da cui l'utente effettua il login.
2
Lo sviluppo del “blocco decisore emergenza”, il modulo che stabilisce il livello di emergenza in corso, ha richiesto la definizione e la simulazione della rete fisica e della rete "logica", che indica lo scheduling dei controlli di carico. È stato inoltre sviluppato un algoritmo di routing basato sull'algoritmo di Dijkstra che, al variare dei rilevamenti di banda disponibile, ricalcola dinamicamente i percorsi di banda ottima. Questo tipo di meccanismo di erogazione adattativa di servizi alle condizioni esterne rende la piattaforma InSeBaLa del tutto innovativa rispetto ad altre piattaforme integrate di accesso a servizi multimediali su banda larga. Il testing è stato effettuato presso il WiLAB di Bologna, su un’architettura di rete fortemente eterogenea, con le stesse caratteristiche della rete regionale. In Fig. 1 sono evidenziati i tre poli della rete per il testbed, posizionati nei pressi della Facoltà d’Ingegneria dell’Università degli Studi di Bologna. Data questa eterogeneità si sono potute valutare le prestazioni di applicazioni multimediali in presenza di link diversi, verificando la loro qualità di servizio.
Fig. 1: rete per il testbed
3
Capitolo 1 Il progetto InSeBaLa delle “Scrivanie Distribuite” Le molteplici possibilità d’ interazione delle tecnologie dell’ informazione, in un crescendo di complessità, portano all’ imprescindibile utilizzo di piattaforme che forniscano all’ utente la possibilità di avere una gestione unificata di dati, risorse, servizi.
1.1 Finalità e linee guida Il progetto InSeBaLa nasce in questo contesto e si propone nel contempo di incrementare e migliorare l’integrazione fra le reti regionali e di sviluppare una piattaforma comune, detta delle Scrivanie Distribuite (PSD), per l’accesso integrato a servizi multimediali su banda larga. Tramite questa piattaforma si vuole offrire all’utente un unico strumento user-friendly per l’utilizzo di servizi d’alta tecnologia orientati al lavoro cooperativo real-time e l’accesso a dati e risorse senza vincoli di postazione. InSeBaLa coinvolge sia partner di ricerca che partner industriali, ciascuno dei quali si dedica a diverse tematiche e servizi.
Più in dettaglio, nel contesto dell’utilizzo da parte della pubblica amministrazione, sono stati evidenziati i seguenti scenari applicativi:
− lavoro collaborativo, real time oppure asincrono − accesso ubiquo ai propri dati ed alle proprie risorse
Il lavoro cooperativo a distanza prevede che gli utenti possano comunicare come se fossero faccia a faccia, condividere e gestire documenti di ogni tipo e risorse di scrivania, creare gruppi di lavoro remoti avendo la possibilità di scegliere i partecipanti e notificare eventi di vario tipo, come
4
la richiesta di partecipazione, la modifica di documenti e la richiesta di apertura di canali di comunicazione audio/video.
L’accesso ubiquo deve permettere ad un utente di ritrovare i propri dati e le proprie impostazioni d’ufficio accedendo da postazioni remote, quali altri uffici, altre città, il palmare. Una funzionalità importante dell’accesso ubiquo è la firma digitale, che garantisce valore legale, integrità, autenticità e non ripudio dei documenti, oltre a semplificare gli iter procedimentali, portando a maggiore efficienza ed al contenimento della spesa pubblica.
A fronte di queste necessità, si è deciso di fornire i seguenti servizi:
− servizi per la comunicazione: instant messaging, Voice over IP (che garantisca la reperibilità telefonica dell’utente sempre con la stessa modalità), chiamate tetra, videoconferenza, servizi di rubrica.
− servizi per il lavoro di gruppo real-time remoto, da effettuarsi con il supporto dei servizi di condivisione e comunicazione di contenuti audio e video, anche off-line, condivisione di documenti e comunicazione testuale, composizione di documenti a più mani sul web, piattaforme groupware e sistemi PIM avanzati, e-learning.
− servizi per l’accesso ubiquo: localizzazione di periferiche o di altri strumenti e risorse, firma digitale.
Il sistema deve anche gestire l’accesso sicuro e l’assegnazione dei diritti d’utente e provvedere all’ottimizzazione delle risorse di rete. Deve infine essere aperto ed estendibile, per potersi adattare a vari scenari della Regione Emilia-Romagna e della Pubblica Amministrazione ed integrare in futuro ulteriori servizi e funzionalità che si dovessero rendere utili e necessarie.
1.2 Architettura d’integrazione Il cuore del sistema di integrazione è un pool di server che definiscono il sistema informativo e le comunicazioni fra gli applicativi e permettono l’autenticazione, la gestione dei diritti e l’accesso integrato a risorse e servizi (Fig. 2). Di questo blocco fa parte anche il servizio di gestione
5
dell’emergenza. L’accesso al sistema avviene tramite un front-end, che colloquia con il blocco centrale e da questo riceve le indicazioni per l’abilitazione dei servizi.
Fig. 2: architettura di base per i requisiti d’ambiente
Benchè non sia possibile sottovalutare l’enorme diffusione di alcuni prodotti software che sono entrati ormai a far parte del lavoro quotidiano d’ufficio, si è scelto di sviluppare tutte le applicazioni della piattaforma utilizzando prodotti open source, che garantiscono maggiore controllo e flessibilità. Questi servizi sono stati opportunamente modificati, ottimizzati ed integrati. Altri servizi sono stati realizzati ex-novo.
1.2.1 Il sistema abilitante LDAP/MySql
Nello sviluppo del sistema abilitante, cruciale è stata la scelta del software per lo sviluppo del sistema informativo. Questo software deve garantire funzionalità fondamentali quali autenticazione, ridondanza e sincronizzazione ed interfacciarsi ai diversi servizi offerti. Deve infine permettere l’estensibilità dello schema delle risorse, per consentire – a fronte dell’arricchimento di oggetti e servizi - di aggiungere elementi allo schema dei dati senza comportare oneri pesanti per ritornare a regime.
6
Il sistema informativo dell’ambiente che si è delineato deve gestire gli accessi e fornire un’infrastruttura comune per una vasta gamma di applicazioni eterogenee. A tal fine deve rappresentare sia informazioni aggiornate poco di frequente, come utenti, servizi, risorse fisiche e logiche (dati statici), che informazioni in rapidissima evoluzione come lo stato delle connessioni (dati dinamici).
Questi requisiti hanno portato alla definizione di un’architettura ibrida, che fa uso del server di directory LDAP [14-22] per le informazioni statiche e di un server MySql per le informazioni dinamiche.
I server di directory come LDAP, attualmente utilizzati dai principali vendor per lo sviluppo di piattaforme integrate (cfr. MS Active Directory), sono ottimizzati per le letture, il che li rende particolarmente adatti all’utilizzo per dati di tipo statico. Per quanto riguarda l’estensibilità dello schema, i database supportano cambiamenti di schema, ma sono eventi rari e complessi, mentre lo schema di una directory permette notevole flessibilità. Vi sono ulteriori, molteplici requisiti soddisfatti da un servizio di directory: autenticazione, personalizzazione del profilo utente, accesso integrato ai servizi con un unico login, diritti di gruppo gerarchici, centralizzazione delle configurazioni e degli aggiornamenti, resistenza ai guasti, sicurezza tramite i protocolli SSL e TLS, supporto di certificati digitali, ridondanza e gestione trasparente del fail-over.
Di particolare rilevanza in questa scelta è anche il fatto che l’utilizzo di standard come LDAP garantisce interoperabilità fra sistemi e servizi eterogenei, cosa che i modelli semiproprietari dei database non possono fornire. LDAP non è però adatto a gestire dati dinamici, per la qual cosa è più adatto un server relazionale. Per questo motivo è nata l’idea dell’utilizzo congiunto di un server LDAP e di un server relazionale MySql.
Resta da risolvere il problema della flessibilità dello schema dei dati dinamici: un server relazionale è adatto ed efficiente per la gestione di tali dati, ma, nell’impostazione tradizionale, non permette buona flessibilità dello schema, se non con costi pesanti in termine di rivisitazione dello
7
schema stesso, ad esempio per problemi di denormalizzazione e ricaricamento dei dati. Per garantire comunque flessibilità dello schema senza oneri di ricostruzione, si è definito uno schema ad hoc pseudo-relazionale, che permette di aggiungere attributi dinamicamente.
LDAP è un sistema organizzato gerarchicamente, in cui ogni oggetto ha un identificatore unico detto dn (Distinguished Name) ed è descritto mediante una serie di attributi che lo contraddistinguono. Il dn non specifica solo il nome dell’oggetto, ma identifica anche la sua posizione all’interno dell’albero.
La struttura dell’albero LDAP per InSeBaLa (Fig. 3) prevede sei classi di primo livello. La struttura completa della gerarchia di classi si può consultare tramite bind anonimo all’indirizzo [6] (Fig. 4). In questa sede si vuole invece sottolineare il ruolo di tali classi nell’architettura d’integrazione:
− Contacts: contiene i dati di utenti senza login (utenti esterni al sistema)
− Applications: comprende i servizi al momento disponibili
− Ddc (emergenze): struttura dati dell’emergenza; tiene memoria dei diritti degli utenti e dei gruppi a seconda del livello di emergenza in atto
− Groups: contiene la struttura dei gruppi, utilizzata dal sistema abilitante per offrire servizi personalizzati in base al gruppo di appartenenza dell’utente
− Oid: contiene i numeri univoci che individuano gli oggetti dell’albero (la base di partenza è stata assegnata da IANA)
− People: contiene i dati di tutti gli utenti in possesso di login
8
Fig. 3: classi LDAP di primo livello Una rappresentazione relazionale classica delle proprietà di connessione di un oggetto, sia esso una persona o una risorsa, prevede la definizione di una tabella per ogni oggetto e, all’interno di ciascuna tabella, attributi che descrivono le proprietà dinamiche relative alla connessione di quell’oggetto. Ad esempio: Persona(id_utente, login effettuato, IP)
Auditing(id_utente, id_risorsa, esitoAccesso, dataAccesso, oraAccesso) Per i motivi sopra discussi, questo tipo di rappresentazione non è flessibile. Si è quindi deciso di definire uno schema pseudo-relazionale ad hoc del tutto anomalo rispetto ad un tradizionale schema relazionale, costituito da tre tabelle:
− una tabella Objects(obj_id, name) con gli identificatori e le principali proprietà degli oggetti del database, siano essi utenti, risorse o servizi. Ogni oggetto avrà un identificatore importato da LDAP.
9
Fig. 4: classi LDAP di primo livello su ldapweb.bo.cnit.it
− una tabella Attributes(attr_id, name) che contiene la lista degli attributi man mano definiti.
− una tabella Values(obj_id, attr_id, value) che, per ogni coppia (obj_id, attr_id) contiene l’indicazione che l’attributo attr_id è proprio dell’oggetto obj_id ed il valore che quell’attributo ha per quell’oggetto
Si noti anche che, per quanto riguarda le prime due tabelle, lo schema proposto è a metà fra tabelle relazionali e cataloghi di sistema. L’ultima
10
tabella, Values, è di fatto un prodotto cartesiano (obj_id, attr_id) e tiene i valori effettivi degli attributi.
La ricostruzione dell’informazione relativa a tutti gli attributi di un oggetto comporta di conseguenza la navigazione delle tre tabelle tramite join, anziché – come nella soluzione tradizionale – l’accesso ad una sola tabella. D’altro canto, l’estensione dello schema con un nuovo attributo viene fatta tramite due semplici registrazioni nella tabella Attributes e nella tabella Values.
La struttura dati sopra descritta entra in azione all’atto del login, che restituisce all’utente un’interfaccia del tipo di Fig. 5. Questo front end è regolato da una procedura di login che, nell’architettura proposta, è un’operazione complessa, comprensiva di più fasi fra loro interconnesse e basate sull’interazione LDAP/MySql.
Tale complessità dipende dalla presenza di una funzionalità, detta “Emergenza Software”, che realizza un particolare tipo di ottimizzazione di rete e gestione della sicurezza negli accessi. L’emergenza software, argomento del Cap. 2 ed ambito della tesi, si basa sul rilascio selettivo di risorse e servizi in base al grado di coinvolgimento dell’utente in una situazione critica, sia essa dovuta a problemi di traffico di rete (emergenza rete) o ad eventi catastrofici sul territorio (emergenza geografica).
Così come l'architettura ibrida LDAP/MySql permette una notevole flessibilità e scalabilità, l’erogazione adattativa di servizi alle condizioni esterne rende la piattaforma InSeBaLa del tutto innovativa rispetto ad altre piattaforme integrate di accesso a servizi multimediali su banda larga.
1.2.2 Accesso ai servizi e loro comunicazione
Un punto importante nel processo di integrazione è stata la risoluzione del problema di lanciare applicativi da web. Il metodo ideato agisce sui registri di sistema di Windows e consente di avviare applicativi presenti sul PC direttamente da un browser Web, sfruttando una sintassi del tipo:
11
Fig. 5: interfaccia di accesso ai servizi
http://[nomeapplicativo].[valoriparametri].
Per quanto riguarda la comunicazione fra applicativi in sessioni di lavoro cooperativo, si è pensato ad un utilizzo evoluto del server Jabber di messaggistica. Il server Jabber è stato adattato per la notifica di eventi e inviti, il passaggio dei parametri per l’avvio degli applicativi, il settaggio automatico di parametri di configurazione per la connessione a un server e l’avvio automatico dei client. Ciò ha permesso di risolvere il problema della dinamicità dei parametri di connessione tra i vari servizi della piattaforma causato dalla mobilità degli utenti.
Possiamo ora dettagliare lo schema di Fig. 1, in particolare il blocco di server che costituiscono il sistema integrante (Fig. 6).
Fra i client ed il blocco LDAP/MySql si interpone un server Apache, che provvede ad interrogare LDAP. Le query sono strutturate in XML: il client invia l’identificativo dell’utente, Apache interroga LDAP e restituisce la
12
lista dell’abilitazione alle applicazioni. L’interfaccia web è sviluppata in php. Il server Jabber provvede a gestire la comunicazione fra gli applicativi.
Fig. 6: architettura del sistema abilitante
13
Capitolo 2 La funzionalità “Emergenza Software” per l’ottimizzazione di rete
L’emergenza software è un blocco chiave nella realizzazione della piattaforma delle scrivanie distribuite e nasce dall’idea di gestire in modo ottimale il sistema integrante, rendendolo più efficiente ed adattativo rispetto a condizioni che possono richiedere un suo diverso funzionamento [26][27]. L’obiettivo è ottenere:
• un sistema ottimizzato nelle prestazioni • adattatività temporale rispetto a condizioni ambientali esterne
(disponibilità delle risorse di rete, tipologia di connessione, eventi critici, zona geografica, ecc…)
• scalabilità in base alla tipologia dell’utente
Per ottenere questo, andiamo a dettagliare i requisiti dell’emergenza software e proporre di conseguenza una possibile architettura.
2.1 Finalità, definizione e requisiti Per emergenza software (Fig. 7) si intende più precisamente il rilascio selettivo di servizi e risorse ai soli utenti e gruppi logici coinvolti in una situazione critica. Ad esempio, in caso di incendi o emergenze sanitarie, è opportuno che tutte le risorse ed i servizi siano messi il più possibile a disposizione di chi gestisce l’emergenza, rendendo quindi più efficaci gli interventi.
Un altro caso è la riduzione della disponibilità di banda in una particolare zona, ad esempio per guasti o manutenzioni. In questa situazione, è
14
opportuno che, ai soli utenti di quella zona, vengano limitati i servizi più pesanti in termini di banda, come i servizi di videoconferenza.
In questo contesto, i diritti non sono solo basati sull’appartenenza dell’utente ad una data categoria avente dati diritti, ma anche in base al “livello di emergenza” in corso.
Fig. 7: gestione integrata dell’emergenza Al variare del livello di emergenza, particolari utenti e gruppi diversamente coinvolti avranno diversi diritti. Ad esempio, in una situazione normale, un utente della Pubblica Amministrazione avrà accesso a tutti i servizi di videoconferenza per il lavoro congiunto. In caso di incendio, al fine di alleggerire il carico di rete e spostare le risorse verso chi ne ha bisogno, i diritti di tale utente verranno ristretti alla sola messaggistica ed i vigili del fuoco avranno invece a disposizione tutti i servizi. Lo stesso dicasi per una ridotta disponibilità di banda in una data zona. Da questi scenari si capisce come il termine “emergenza” abbia, in questo contesto, un significato esteso, non riferito necessariamente solo a crisi o calamità, ma, più in generale, a situazioni e condizioni che influiscono sulla disponibilità di servizi e applicazioni della piattaforma.
L’architettura dell’emergenza software definisce e valuta:
• situazioni di emergenza
15
• opportuni livelli di emergenza
• come modulare i privilegi di utenti/gruppi a seconda del livello di emergenza
• quali servizi rendere disponibili (ed a chi) ai diversi livelli di emergenza.
Il meccanismo che regola il rilascio selettivo dei servizi, se non vi è alcuna situazione di emergenza, rende disponibili tutti i servizi. Se è in atto una situazione di emergenza, gestisce due azioni congiunte:
• richiesta di nuove sessioni (abilitazione o meno dei servizi)
• gestione di sessioni attive (blocco dei servizi che sono già attivi a chi non ne ha più diritto)
Nel primo caso, si deve verificare quali servizi sono disponibili per l’utente che ha richiesto la sessione al livello di emergenza in corso.
Nel secondo caso, occorre effettuare un refresh dei servizi disponibili, ad esempio tramite un nuovo login trasparente all’utente. Con un time out sufficiente a salvare la sessione, si interrompono i servizi cui l’utente, nella situazione di emergenza in corso, non è più abilitato. Le modalità di gestione di questa situazione sono in fase di valutazione.
2.2 Architettura dell’emergenza software La rappresentazione dei requisiti e delle azioni suddette è effettuata sul sistema LDAP, che interagisce con il resto del sistema abilitante e con un modulo di valutazione del livello di emergenza.
L’architettura dell’emergenza prevede dunque:
• la rappresentazione LDAP dei diritti d’accesso
• la procedura di autenticazione ed il rilascio dei servizi disponibili al livello di emergenza in corso
• il calcolo del livello di emergenza in corso
16
2.2.1 Rappresentazione LDAP dell’emergenza
Si è utilizzato LDAP come strumento per memorizzare le informazioni sugli utenti, sui gruppi di appartenenza degli utenti, sui diritti per ogni livello di emergenza. La rappresentazione LDAP dell’emergenza software (Figg. 8, 9) prevede la definizione di due classi di primo livello, application e ddc. La classe application contiene l’elenco e le proprietà dei servizi disponibili. La classe ddc ha tante sottoclassi MTMminutes quanti sono i livelli di emergenza. Ogni classe MTMminutes mantiene Access Control List del tipo (can, who, what). Le ACL di ogni MTMminutes indicano quali servizi sono disponibili per i diversi gruppi di utenti. Ad esempio, al livello di massima emergenza (MTMminutes = 1), si ha: CAN = 0, WHO = *, WHAT = *, ossia tutti i servizi sono bloccati (tranne il login) per tutti gli utenti.
Al momento del login, dunque, l’insieme delle applicazioni rese disponibili all’utente viene stabilito dinamicamente come segue:
• si legge il valore del livello di emergenza, dato dinamico registrato in MySql e stabilito dal modulo di gestione dell’emergenza
• si legge su LDAP a quali gruppi cui appartiene l’utente
• in base a questi due dati, si analizzano le access list LDAP e si stabiliscono i diritti
2.2.2 Fasi dell’autenticazione ed accesso ai servizi
La struttura dati LDAP sopra descritta entra in azione all’atto del login, che restituisce all’utente un’interfaccia del tipo di Fig. 5.
17
Fig. 8: rappresentazione LDAP dell’emergenza software
Fig. 9: classi MTMminutes e rispettive ACL sul server LDAP
18
Questo front end è regolato da una procedura di login che, nell’architettura proposta, è un’operazione complessa, comprensiva di più fasi fra loro interconnesse e basate sull’interazione fra tutti i server componenti il sistema abilitante.
In prima istanza, analizzeremo il caso di un utente fisso e lasceremo in sospeso la struttura del blocco decisore dell’emergenza. Nel paragrafo 2.2.3 prenderemo invece in considerazione tutti i fattori indicati.
La prima fase è il login tramite dn LDAP e password, verificati mediante protocollo LDAP dal server LDAP che detiene le credenziali.
La seconda fase prevede che vengano registrati sul server di stato alcuni dati relativi alla connessione. Al momento, questi dati sono l’identificatore dell’utente, importato da LDAP, l’avvenuta connessione e l’IP Nella terza fase dell’autenticazione, il server di stato MySql riceve i dati sulla connessione dell’utente autenticato, riceve il valore del livello d’emergenza in corso dal modulo di valutazione emergenza e restituisce tale livello a LDAP. In base a questo valore si scende nella classe MTMminutes corrispondente e si leggono le ACL, per determinare quali funzionalità sono disponibili in quel momento e per quell’utente. Tre sono dunque le variabili: utente (e quindi gruppi di appartenenza), istante temporale (situazione attuale), IP (posizione dell’utente).
L’algoritmo che gestisce l’emergenza software comprende i seguenti blocchi logici:
1. connessione e bind dell’utente
2. ricerca dei gruppi a cui appartiene l’utente
3. ricerca delle applicazioni disponibili per ciascun gruppo cui appartiene l'utente (questo fa sì che, ad uno stesso livello di emergenza, per utenti diversi siano disponibili diverse applicazioni)
4. scansione delle ACL corrispondenti al livello dell’emergenza in corso e ricerca delle applicazioni effettivamente disponibili (questo fa sì che, a livelli di emergenza diversi, uno stesso utente trovi disponibili diverse applicazioni diverse)
19
5. attivazione dinamica delle funzionalità effettivamente fruibili da quel particolare utente in quel particolare momento e in quel particolare luogo
In riferimento all’intera architettura (Fig. 10), il client fornisce ad un web server l’identificativo LDAP dn; il web server inoltra il dn a LDAP, che lo utilizza per determinare i gruppi a cui appartiene l’utente. MySql acquisisce e comunica il livello di emergenza e, con queste due informazioni, si consultano le ACL su LDAP per determinare quali applicazioni possono essere abilitate.
Fig.10: fasi del login ed accesso ai servizi Le Figg. 11, 12 mostrano i servizi resi disponibili ad uno stesso utente a due diversi livelli di emergenza.
2.2.3 Architettura definitiva dell’emergenza software
Fino ad ora, i dati in ingresso al sistema abilitante per la decisione di quali servizi attivare sono stati l’identificativo dn dell’utente (indipendente dalla sua dislocazione) ed un unico valore di emergenza. Prendiamo ora in considerazione i seguenti aspetti:
1. il livello di emergenza deve essere calcolato automaticamente in base al monitoraggio dell’emergenza geografica e del carico di rete
2. l’emergenza non è più un parametro globale, ma dipende dalle diverse aree logiche e geografiche
3. i servizi erogati all’utente non vengono più stabiliti a priori in base al livello di emergenza ed ai gruppi di appartenenza, ma anche in
20
base all’attuale ubicazione geografica dell’utente stesso e quindi al livello attuale d’emergenza della zona in cui si trova
A fronte di questi requisiti, l’architettura per la gestione dell’emergenza software si è evoluta come illustrato in Fig. 11: il client fornisce al web server sia il dn che l’IP. Il primo serve ad effettuare l’autenticazione e stabilire i gruppi di appartenenza, il secondo serve a dare indicazioni sull’ubicazione geografica dell’utente.
Tali parametri vengono inoltrati al blocco LDAP/MySql, che a sua volta trasmette l’IP ad un nuovo “blocco decisore dell’emergenza”. Questo blocco, oltre all’IP, riceve periodicamente in ingresso dati sul carico di rete e dati sull’emergenza geografica. In base a questi tre fattori in ingresso, stabilisce e restituisce in uscita il valore del livello di emergenza per l’IP indicato e lo trasmette al blocco LDAP/MySql, che può ora procedere a stabilire i diritti con le stesse modalità di prima.
Fig. 11: decisione del livello di emergenza
2.3 Il blocco decisore emergenza ed il database di rete Esplodiamo ora il blocco decisore emergenza per illustrarne il funzionamento (Fig. 13).
L’architettura del BDE comprende diversi blocchi che interagiscono ed utilizzano un database di struttura della rete. Quest’ultimo verrà illustrato nel prossimo capitolo.
21
Il BDE prende in ingresso l’IP, che viene utilizzato da diversi moduli. Prima di tutto, l’IP e dati sulla situazione della rete vengono analizzati dal “blocco decisore emergenza rete”: un opportuno scheduling di controlli e misure SNMP permettono di stabilire se un link è attivo e con quali prestazioni, se l’apparato è saturo, se è necessario attivare il link di backup, ecc. In base a questi dati, il modulo crea una tabella (Tab. 1) che ad ogni IP associa un valore di “emergenza rete”.
Un secondo blocco, a partire da indicazioni sulle zone geografiche, marca una zona con un dato livello di emergenza e, tramite un reverse DNS, dice quali IP appartengono a quella zona. Crea una tabella, in cui a ciascuna zona corrispondono i relativi IP.
Un ulteriore blocco, il “blocco decisore emergenza geografica”, prende in ingresso l’IP e dati su eventuali emergenze sul territorio e, appoggiandosi ai dati del blocco reverse DNS, crea una tabella che ad ogni IP associa un valore di “emergenza geografica”.
L’ultimo modulo prende in ingresso i valori di emergenza rete ed emergenza geografica, applica una funzione di merge (media, valore più alto, ecc.) e crea una tabella che ad ogni IP associa il livello di emergenza totale e restituisce finalmente il livello di emergenza dell’IP considerato.
2.3.1 Integrazione del blocco decisore nel sistema abilitante
Si vuole ora descrivere il funzionamento dell’emergenza software in modo più algoritmico, in riferimento alla sua integrazione nel sistema abilitante, dettagliando quali dati vengono utilizzati e quali restituiti da ciascun blocco componente il sistema abilitante. In Fig. 13 e Tab. 1 sono rappresentati il web server Apache, il blocco LDAP/MySql ed il blocco decisore emergenza (BDE), ciascuno con i rispettivi ingressi e le rispettive uscite.
Il blocco Apache (1) riceve dal client l’IP ed il dn, li inoltra al blocco LDAP/MySql (2) e salva l’IP nel database dinamico MySql. Per decidere
22
Fig. 12: architettura del blocco decisore emergenza
quali applicazioni attivare, Apache richiede poi al blocco (2) i gruppi di appartenenza dell’utente e le ACL del livello di emergenza relativo all’IP da cui è stato effettuato il login. I gruppi sono dati già in possesso del blocco (2); le ACL dipendono invece dal livello di emergenza, che deve essere fornito dal blocco decisore emergenza (3) in base all’IP. Il blocco (3) prende dunque in ingresso l’IP da Apache, dati sullo stato della rete e dati geografici e, per l’IP in questione, restituisce ad Apache il livello di emergenza. Apache trasmette questo dato al blocco (2), ne riceve le ACL e determina finalmente le applicazioni da attivare.
23
Fig. 13: flusso di ingressi e di uscite dei blocchi del sistema abilitante per l’attivazione di applicazioni
blocco input output Apache IP
dn gruppi di appartenenza ACL livello di emergenza
applicazioni consentite
LDAP/MySql IP dn livello di emergenza
gruppi di appartenenza ACL
BDE IP dati rete dati geografici
livello di emergenza
Tab. 1: blocchi del sistema abilitante con rispettivi ingressi ed uscite
24
Capitolo 3 Modello della rete, del routing e del monitoraggio Questa tesi è focalizzata su quella parte del blocco decisore emergenza che valuta l’emergenza di rete.
Per analizzare il carico è essenziale definire dei modelli di rappresentazione della rete sia in base alla sua topologia fisica che in base alle modalità di interrogazione SNMP.
La prima parte dei risultati ottenuti in questa tesi riguarda lo studio di modelli di rappresentazione e simulazione di questi oggetti. È stato poi ideato e sviluppato un algoritmo di routing, variante dell’algoritmo di Dijkstra, che utilizza queste strutture e calcola il percorso migliore.
Quando il livello di emergenza cambia, cambia anche la situazione di carico di rete. Questo algoritmo, dunque, al variare del livello di emergenza, permette di valutare dinamicamente i percorsi di carico ottimale.
Questi modelli vengono poi trasferiti sul blocco LDAP/MySql, per permettere l’interscambio di informazioni con il modulo decisore dell’emergenza rete.
3.1 Rappresentazione e simulazione del grafo di rete Nel caso più generale, la rappresentazione di una rete fisica è un grafo, che possiamo definire come segue:
• i nodi sono coppie (Ni, Di), in cui Di è un descrittore contenente l’elenco degli IP connessi al nodo Ni
• gli archi sono terne (Ni, Nj, dati), dove dati è un insieme di informazioni quali la velocità di connessione, la direzione, il costo, prestazioni, ecc.
25
Per gestire il caso in esame, individuiamo alcune caratteristiche e parametri che caratterizzano il grafo della rete fisica, per valutare poi alcune strutture di rappresentazione.
Il grafo G(N, E) che rappresenta la rete fisica è orientato e con collegamenti misti. Ciò vuol dire che esistono sia collegamenti simmetrici, percorribili in entrambe le direzioni con le stesse caratteristiche di velocità, o di altri parametri, che collegamenti asimmetrici, che prevedono caratteristiche diverse a seconda del senso di percorrenza (si pensi a tratti ADSL, in cui le velocità di download e di upload sono molto diverse).
Si intende che due o più nodi sono connessi se c’è un percorso che li congiunge e che assicura determinate caratteristiche. Ad esempio, due nodi collegati da un percorso si intendono connessi se la velocità di connessione supera una data soglia di tolleranza.
Funzioni che utilizzano misure SNMP stabiliscono se è attivo un link fra due router, misurando i byte transitati su un link, la banda residua (controllando così l’avvicinarsi di una situazione di saturazione), il carico della cpu, ecc. In base a questi dati viene deciso il livello di emergenza.
3.1.1 Modello ed algoritmo di simulazione del grafo di rete
In base a questi requisiti, si è deciso di di definire il grafo di rete come segue: i nodi rappresentano router e sono definiti da coppie (IP, interfaccia). Un arco che congiunge due nodi Ni e Nj è costituito da un link di andata Ni à Nj e da da un link di ritorno Nj à Ni, ciascuno pesato con il parametro banda disponibile (Fig. 15).
Il grafo viene rappresentato tramite l’insieme dei suoi link, di andata e/o di ritorno, ossia tramite terne del tipo (nodo partenza, nodo arrivo, banda disponibile in questa direzione).
26
Fig. 14: modello della rete fisica
Ad esempio, il grafo di Fig. 14 viene memorizzato così:
(A, B, 100 M) (B, A, 100 M) (A, C, 200 M) (C, A, 60 M) (B, D, 1 G) (D, B, 200 M) (C, D, 50 M) (D, C, 50 M)
I parametri in ingresso per la costruzione del grafo sono i seguenti:
• il numero n di nodi
• la percentuale di interconnessione (numero effettivo di link diviso per il numero totale possibile di link)
• percentuale di asimmetrie, ossia di valori diversi fra il link di andata e quello di ritorno
• il valore di hop (numero di nodi attraversati in un cammino)
27
Raccolti i parametri in ingresso, il primo passo è la creazione degli archi che definiscono il grafo.
Il primo parametro da applicare è quello relativo all’hop. L’idea principale è quella di seguire una disposizione a stella, con un nodo centrale, un certo numero (variabile) di diramazioni che partono da ogni nodo ed una profondità, che rappresenta il raggio (hop) della stella.
Dato il numero di nodi n ed il raggio hop, il numero minimo di diramazioni che dovrà avere ogni nodo per coprire, in hop passi, tutti i nodi del grafo è dato dall’intero minimo m tale che:
Σ i = 0..hop mi ≥ n Questa sommatoria conta tutti i nodi appartenenti a una stella di raggio hop: m0 =1 è il nodo centrale, m1 le m diramazioni dol nodo centrale, m2 le m diramazioni da ognuno degli m nodi precedenti, e così via fino alle ultime mhop diramazioni. Di conseguenza, trovando il valore minimo di m che soddisfa la sommatoria, imponiamo che tutti i nodi del grafo facciano parte di questa stella (Fig. 15). Nel caso peggiore, due nodi sono agli antipodi, sull’ ultimo giro di diramazioni. Dovendo passare per forza dal centro della stella, il cammino che li congiunge sarà lungo 2*hop. I collegamenti che mancano per raggiungere la percentuale di link effettivi, vengono scelti in modo randomizzato tra le possibili permutazioni di coppie di nodi ancora disponibili (Fig. 16). Creati gli archi come detto a partire dalle permutazioni delle coppie di nodi senza ripetizioni, si creano così i collegamenti di andata. Dei link generati si crea poi il link di ritorno (Fig. 17).
28
Fig. 15: vincolo di hop
Fig. 16: vincolo di connettività I collegamenti così determinati garantiranno dunque che un nodo qualunque del grafo raggiungerà un altro nodo qualunque compiendo al massimo 2*hop passi (linea tratteggiata in Fig. 17).
I pesi degli archi, simmetrici o no, sono anch’essi valori random scelti fra alcuni predefiniti. In base alla percentuale di asimmetrie, si sceglie quali ritorni sono asimmetrici e a questi viene assegnato un nuovo peso, diverso da quello dell’andata.
29
I dati vengono salvati sia su file di testo che su tabella MySql, per verifiche di prestazioni che serviranno più avanti.
L’algoritmo è stato sviluppato in C++ ed è incluso nel cd che accompagna questa tesi.
Fig. 17: completamento del grafo e percorso più lungo
3.2 Modello di scheduling dei controlli per il monitoraggio del carico di rete Sono state illustrate la rappresentazione e la simulazione della rete fisica, con tutti i router ed il parametro di banda residua che interessa per le misure. Date le dimensioni effettive della rete regionale, è impensabile sottoporla costantemente ed interamente a controlli ed aggiornare frequentemente tutti i link del grafo.
È dunque necessario trasformare la struttura del grafo in una di navigazione meno onerosa. Per fare questo, si è pensato di dare ad alcuni nodi dignità superiore ad altri.
In pratica, andiamo a fare una distinzione fra la rappresentazione della rete fisica e di quella “logica”, quest’ultima intesa come struttura che rispecchi come sono pianificati i controlli.
30
3.2.1 Rappresentazione gerarchica dei controlli
Per rappresentare lo scheduling di misure sulla struttura di rete si è pensato di classificare i nodi in base alla diversa periodicità e granularità dei controlli del carico di banda. Utilizzando questo criterio, si è stabilito di disporre i router in un albero di scheduling dei controlli. Viene scelto un nodo padre ed ogni livello ha nodi controllati con la stessa frequenza. Altri criteri di clustering sono l’importanza dei nodi e le zone di appartenenza. Nell’esempio in Fig. 18, il nodo più importante - e quindi più frequentemente controllato - è fe1 (ad es. ogni 10 minuti). Il nodo cnitbo1 appartiene alla seconda fascia di frequenza di controllo (30 minuti) e ha fra i nodi figli cnitbo2 e cnitbo3 (90 minuti).
Fig. 18: modello dell’albero di scheduling
3.2.2 Il framework SNMP e le misure utilizzate
Il protocollo SNMP (Simple Network Management Protocol) ([rfc 1157, 1901, 2271] per le versioni 1, 2, 3 rispettivamente) permette il monitoraggio ed il controllo di dispositivi al fine di rilevare il carico di rete, misurare prestazioni, risolvere problemi di rete e pianificare l’espansione della rete stessa.
È generalmente utilizzato su reti TCP/IP ma può essere implementato anche su reti IPX o AppleTalk.
31
Il framework SNMP utilizza il protocollo SNMP per lo scambio di informazioni ed è basato su un modello manager/agent costituito da:
1. componenti base: cosa deve essere monitorato e come
2. comandi base per il monitoraggio ed il controllo
3. sistema informativo: come rappresentare e dove mantenere le informazioni
1. Componenti base - su ogni elemento della rete è installato un agente che colloquia con il gestore del framework. Più in dettaglio, troviamo: Network element: dispositivi hardware (computer, router, ecc.) che vengono connessi alle reti. SNMP agent: moduli software che risiedono sui network element, con il compito di memorizzare informazioni e renderle comprensibili a SNMP. NMS (Network Management Station): è il manager, che esegue monitoraggio e controllo. Ogni rete gestita ne ha anche più di uno. Il software da installare su ciascun nodo da gestire è minimo: la maggior parte delle capacità di elaborazione risiede sui manager.
2. Comandi base - read, con cui il manager effettua il monitoraggio di variabili degli element; write, per il controllo e la scrittura di variabili su element; trap, con cui gli element comunicano in modo asincrono a NMS il verificarsi di particolari eventi; operazioni trasversali, con cui il manager determina quali variabili sono supportate da un element e dedurre di conseguenza informazioni da tabelle di variabili come le routing table.
3. Sistema informativo – di ogni elemento della rete si decide quali proprietà rappresentare e come. Gli oggetti di base sono:
• Managed object: una caratteristica o una proprietà che deve essere gestita.
• MIB (Management information base): consiste di un insieme di managed object memorizzati nel database MIB.
• SMI (Structure of management information): sono il linguaggio e la sintassi usati per descrivere i managed object contenuti nel MIB, mediante un formato indipendente dalla
32
piattaforma. Si usa un sottoinsieme dello standard ISO ASN.1 (Abstract Syntax Notation) sia per definire il formato dei pacchetti scambiati dal protocollo di gestione che per rappresentare gli oggetti che devono essere gestiti.
L’interazione dei componenti finora indicati è illustrata in Fig. 19: su ogni device risiede un agent che provvede a scambiare informazioni con il framework manager.
L’allocazione del database si intenda puramente logica, mirata a partizionare i dati relativi ai diversi elementi.
Fig. 19: interazione dei componenti base Analizziamo ora la struttura del MIB SNMP. Il MIB SNMP, che attualmente utilizza la rappresentazione MIB-2 (rfc 1213), è una collezione di managed objects, ossia di proprietà degli elementi della rete. Ogni managed object può essere di tipo scalare (valore di una proprietà di una singola istanza) o tabulare (collezione di valori di proprietà di oggetti correlati). Un managed object è identificato da un OID proveniente dallo standard ISO ASN.1, referenziato per nome o per descrittore. Ad esempio:
33
- iso.identified-organization.dod.internet.management.MIB-2.ip
- 1.3.6.1.2.1.4
indicano entrambi il valore dell’ip del modulo MIB identificato dal percorso indicato nell’OID.
Grazie agli OID, in maniera formalmente identica alla rappresentazione degli oggetti LDAP, i managed objects sono organizzati in una struttura ad albero (SNMP tree) del tipo indicato in Fig. 20: a livello 1 ci sono le diverse organizzazioni per le standardizzazioni, ciascuna delle quali fornisce l’identificazione ad altri gruppi associati ed ai relativi sottogruppi, risorse di rete, oggetti di rete.
Fig. 20: struttura del SNMP MIB tree
34
I moduli sottostanti la classe MIB-2 sono moduli standardizzati orientati ai componenti hardware ed ai protocolli di rete. L’intera collezione di queste sottoclassi è:
• System: contiene informazioni di carattere generale sul device di rete • Interfaces: contiene le informazioni relative alle interfacce di rete • Address Translation: contiene informazioni relative alla
conversioni degli indirizzi (es. da logico a fisico), esiste per compatibilà con MIB-I
• Ip: contiene informazioni relative al protocollo IP • Icmp: contiene informazioni relative al protocollo ICMP • Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di
questo gruppo esistono solo per la durate della sessione TCP • Udp: contiene informazioni relative al protocollo UDP • Egp: contiene informazioni relative al protocollo EGP (protocollo
utilizzato da un router per scambiare informazioni tra Autonomous System)
• Transmission: sperimentale, contiene informazione sui mezzi trasmissione utilizzato da ogni interfaccia di rete
• Snmp: contiene informazioni relative al protocollo SNMP.
I messaggi SNMP si possono così classificare:
• GetRequest: utilizzata per interrogare un MIB su un agent SNMP
• GetNextRequest: utilizzata per leggere un MIB in modo sequenziale
• GetBulk: permette di leggere un MIB con un’unica richiesta, anzichè utilizzare più messaggi GetNextRequest
• SetRequest: modifica il valore all'interno di un MIB accessibile in lettura/scrittura
• GetResponse: identifica la risposta fatta da un agent SNMP ad un'interrogazione di una management station
35
• Trap: permette all'agent di inviare un messaggio al verificarsi di un determinato evento
Alcune trap predefinite sono:
ü coldStart: generata quando l'agente SNMP si reinizializza e la configurazione è stata cambiata (es.: reboot del sistema)
ü warmStart: generata quando l'agente SNMP si reinizializza ma senza cambiamenti nella configurazione
ü linkDown: generata quando il collegamento con l'agent non funziona correttamente
ü linkUp: generata quando il collegamento con l'agent viene ripristinato
ü authenticationFailure: generata da un'autenticazione con l'agent non andata a buon fine (es.: nome di comunità errato)
ü egpNeighborLoss: generata da problemi di EGP (Exterior Gateway Protocol - utilizzato dai router)
ü enterpriseSpecific: evento definito dal produttore del device A volte può essere problematico risalire dalla risposta SNMP all’evento che l’ha causata.
Può essere utile utilizzare il protocollo SNMP per monitorare l’evento caduta( o meno) di un link. Il router ad una richiesta SNMP può fornire il numero di byte transitati dall’interfaccia in analisi. Se due misurazioni successive restituiscono lo stesso numero di byte (e viceversa nell’interfaccia di backup i byte iniziano a crescere) possiamo assumere che sia caduto il link più importante e sia entrato in funzione il backup. Nulla vieta di ipotizzare il verificarsi di altri eventi, quali intasamento della memoria del processore, ecc.
36
3.3 Un algoritmo di routing basato sull’algoritmo di Dijkstra Si vuole completare il modello definendo un algoritmo di routing sulla rete simulata. Fra tutti i percorsi da un router Ni ad un router Nj nel grafo G(N, E), si vuole trovare quello ottimo in termini di banda e, di questo, trovare il “collo di bottiglia”, ossia il link di banda residua peggiore, sia per tenere sotto controllo lo stato delle connessioni che per sapere quali sono le prestazioni minime garantite. Questo problema, opportunamente adattato, è un problema di calcolo di percorso minimo. Per fare questo, dunque, si è deciso di adattare la rappresentazione dei pesi degli archi e definire una variante dell’algoritmo di Dijkstra, che ricordiamo brevemente.
Descrizione dell’algoritmo di Dijkstra: dati due nodi x e y, il problema del cammino minimo consiste nel fornire un cammino da x a y di peso minimo. Scopo dell’algoritmo di Dijkstra è determinare il percorso di peso minimo che connette un nodo sorgente a ciascuno degli altri nodi (Single Source Shortest Path Problem). I nodi del grafo vengono visitati in maniera simile ad una ricerca in ampiezza o in profondità. In ogni istante, l’insieme N dei nodi del grafo è diviso in tre parti: l’insieme dei nodi visitati V, l’insieme dei nodi di frontiera F, (che sono i nodi successori dei nodi visitati, ossia raggiungibili lungo un arco che esce da essi) ed i nodi sconosciuti, che sono ancora da esaminare. Per ogni nodo z, l’algoritmo tiene traccia di un valore dz, inizialmente posto uguale a ∞, e di un nodo uz, inizialmente indefinito. L’algoritmo consiste semplicemente nel ripetere il seguente passo: si prende dall’insieme F un qualunque nodo z con dz minimo, si sposta z da F in V, si spostano tutti i successori di z sconosciuti in F, e per ogni successore w di z si aggiornano i valori dw e uw. L’aggiornamento viene effettuato con la regola:
dw ← min {dw, dz + pa }
37
dove a è l’arco che collega z a w e pa è il suo peso. Se il valore di dw è stato effettivamente modificato, allora uw viene posto uguale z. La regola segue un’idea piuttosto naturale: se sappiamo che con peso dz possiamo arrivare fino a z, allora arrivare a w non può costare più di arrivare a z e spostarsi lungo un arco fino a w. L’aggiornamento di uw permette di ricordare che, al momento, il cammino di peso minimo che conosciamo per arrivare da x in w ha come penultimo nodo z. L’algoritmo parte con V = ∅, F = {x}, dx = 0 e prosegue finché y non viene visitato, o finché F = ∅: in questo caso, y non è raggiungibile da x lungo un arco orientato. Se usciamo solo nel secondo caso, alla fine dell’algoritmo dz contiene, per ogni nodo z, il peso di un cammino minimo da x a z; inoltre, il vettore u permette di ricostruire l’albero dei cammini minimi con origine in x.
3.3.1 Modifica dell’algoritmo di Dijkstra per il calcolo del percorso di banda ottima e del relativo link peggiore
Per trovare il percorso ottimo in termini di banda da un router Ni ad un router Nj e, di questo, trovare il il link di banda residua peggiore, adattiamo la rappresentazione dei pesi nel modo che segue.
Ogni peso nel suo inverso rispetto a 1Gbit: 1Gbit diventa 1, 200 Mbit diventa 5, ecc., come illustrato in Fig. 21:
Fig. 21: grafo originale e corrispondente grafo con pesi complementati
38
In questo modo, intuitivamente, i link peggiori hanno maggiore rilevanza degli altri nella somma dei pesi effettuata da Dijkstra. Ad ogni iterazione si aggiorna anche il maggior peso trovato sul percorso. Ad esempio, in riferimento al grafo di Fig. 21, prendendo il nodo A come origine e facendo variare il nodo destinazione, si ottengono i dati di Tab. 2:
destinazione percorso migliore
peso del link peggiore (banda minima garantita)
B A à B 10
C A à C 5
D A à B à D 10
E A à C à E 20
Tab. 2: percorsi ottimi sul grafo di Fig. 22 e rispettivi tratti peggiori L’algoritmo di Dijkstra è stato modificato aggiornando i nodi secondo la seguente regola:
dw2 ← min{dw, dz + pa },
se dw2 ≠ dw, allora dw ← max{dz , pa }
dove a è l’arco che collega z a w e pa è il suo peso. Se il valore di dw è stato effettivamente modificato, allora uw viene posto uguale z.
Anche questo algoritmo è stato sviluppato in C++ ed è incluso nel cd che accompagna questa tesi.
3.3.2 Scelte di implementazione e valutazione delle prestazioni
Sempre per motivi di prestazioni a fronte di utilizzo su di una rete reale, si è deciso di prendere in considerazione i seguenti fattori:
(1) dove memorizzare le terne del grafo?
(2) su quale struttura in memoria centrale trasferire i dati del grafo per eseguire l’algoritmo di Dijkstra?
39
L’algoritmo di simulazione del grafo è stato sviluppato in due varianti: la prima salva i dati su un file di testo, la seconda li salva in una tabella MySql. Per una più ampia e flessibile rappresentazione del grafo, sarebbe opportuno utilizzare tabelle, ma, ai fini dell’analisi di una rete reale su cui si opera con l’algoritmo di Dijkstra, occorre valutare se siano più efficienti i file di testo o le tabelle. Per quanto riguarda le strutture dati da utilizzare nell’algoritmo di Dijkstra, si utilizzano generalmente matrici di adiacenza oppure liste di adiacenza. L’una e l’altra rappresentazione hanno diverse caratteristiche di complessità spaziale e di accesso. Quel che interessa in questo caso è la complessità temporale dell’algoritmo di Dijkstra, che è O(|E|.log|N|) con liste di adiacenza opportunamente visitate, e O(|N|2) con le matrici di adiacenza. A seconda della percentuale di interconnessione, l’implementazione con liste di adiacenza può risultare conveniente. In particolare, è conveniente se il grafo è sufficientemente sparso, ossia con |E| di ordine inferiore o uguale a O(|N|2/ log |N|).
Nel caso di una rete reale possiamo ipotizzare una percentuale di collegamento tra nodi di circa il 10%, quindi si rientra nel caso di un grafo molto sparso. Per questo motivo si è scelto di implementare l’algoritmo con liste di adiacenza. I dati del grafo, dunque, siano essi presi da file di testo o da tabella, vengono trasferiti su liste di adiacenza in memoria centrale per poi essere analizzati.
Resta da valutare se utilizzare file di testo oppure tabelle MySql. Il grafico di Fig. 22 mostra le prestazioni dell’algoritmo di Dijkstra modificato calcolate rispetto ai cicli di clock all’aumentare del numero dei nodi. I parametri del grafo sono: link effettivi 2%, asimmetrie 20%, hop 4.
L’utilizzo dei file di testo (linea con i quadri) rispetto a tabelle MySql (linea con i cerchi) è leggermente più efficiente. Ciò non dipende dall’algoritmo, ma dai tempi di caricamento dei dati. Nel caso di file di testo, infatti, questi sono trascurabili, mentre caricare dati da una tabella comporta un tempo di connessione di circa 10-15 cicli di clock. Questa
40
stessa stima comprende anche la cancellazione dei dati originari dopo il caricamento, trascurabili nel caso di file di testo. Non calcolando questa parte, i grafici si allineano. Si è dunque deciso di memorizzare il grafo su tabella.
Fig. 22: prestazioni dell’algoritmo di Dijkstra al variare del numero di nodi, utilizzando file di testo e tabella MySql.
Link effettivi 2%, asimmetrie 20%, hop 4
3.4 Schema del database di rete Definiti i modelli componenti il sistema di rappresentazione e monitoraggio della rete, vediamo quale tipo di strutture utilizzare per memorizzarli. Queste strutture costituiscono il database di rete, che diventa una parte integrante fondamentale del Blocco Decisore Emergenza. Gli oggetti da rappresentare sono:
• il grafo della rete fisica: link e banda residua • l’albero dello scheduling dei controlli • informazioni sui link per effettuare le query SNMP
Per quanto riguarda il grafo, è stata definita una tabella MySql “net_graph” che rappresenta tutti i link del grafo, avente il seguente schema:
41
net_graph
id nodeA nodeB value measure status e la seguente semantica:
nodeA primo estremo del link nodeB secondo estremo del link value non ancora utilizzato: indica il livello di
emergenza measure misura di banda residua status per sviluppi futuri: indica dice se il link è
da analizzare oppure no
In Fig. 23 è illustrato lo schema LDAP di scheduling sui nodi della rete testbed di Bologna. Il nodo più importante - e quindi più frequentemente controllato - è cnitbo1 (ogni 10 minuti). I nodi cnitbo2 e cnitbo3 appartengono alla seconda fascia di frequenza di controllo (ogni 30 minuti) e così via. Infine, la tabella “net_graph_routers” contiene quelle informazioni del link che permettono di effettuare le query. Lo schema è: net-graph routers id node node_dest iprouter interf … MIB_in MIB_out MIB_speed e la semantica è:
iprouter interface interfaccia di rete del router snmp_v versione di snmp: v1, v2 o v3. Con v3 si
devono utilizzare username e password e la connessione è criptata
community monitor/control/trap
42
usr per snmp v3 pw per snmp v3 MIB_in OID snmp del router per trovare il campo
che contiene gli ottetti dei byte transitati in ingresso
MIB_out OID snmp del router per trovare il campo che contiene gli ottetti dei byte transitati in uscita
MIB_speed OID snmp del router per trovare il campo che contiene la velocità di default di quell'interfaccia
Fig. 23: struttura di scheduling sui nodi della rete testbed di Bologna
43
3.5 Analisi dinamica dei percorsi di banda migliore Come abbiamo visto, lo scheduling delle misure SNMP sulla rete avviene in base ad una gerarchia LDAP di alcuni router di maggiore importanza, classificati in base alla frequenza dei controlli. Vediamo ora qual è il ruolo dell’algoritmo di Dijkstra modificato nell’ambito di questo modello.
L’algoritmo di Dijkstra e l’utilizzo dei suoi risultati vengono gestiti dinamicamente: se le misure SNMP rilevano peggioramenti o altri cambiamenti, si ridefiniscono i pesi dei link del grafo della rete fisica e si riapplica Dijkstra sul “nuovo” grafo, trovando i nuovi percorsi migliori.
In riferimento all’esempio di Fig. 24, i passi sono i seguenti:
1. Si applica Dijkstra per trovare il percorso migliore e vengono individuati i 2 link in grassetto di Fig. 24b, che formano il percorso ottimo (costo 25, banda minima assicurata 50 Mbit).
2. Nell’arco dei controlli previsti, i link vengono testati con SNMP ed i valori di banda residua aggiornati di conseguenza. Sono peggiorati alcuni link, evidenziati dalle linee tratteggiate: link AC, passato da 200 a 50 Mbit; link BD, passato da 200 a 20 Mbit). Allo stesso modo, è migliorato un percorso precedentemente scartato (sul percorso ABE, il link BE è passato da 50 a 100 Mbit).
3. Poiché sono state rilevate modifiche, si riapplica Dijkstra, che restituisce un nuovo percorso ottimo fra i due nodi (percorso in grassetto ABE).
44
Fig. 24: (a) grafo iniziale e (b) relativo percorso ottimo AE; (c) variazioni rilevate dalle misure SNMP e riassegnazione dinamica dei pesi; (d) nuovo percorso ottimo AE
45
Capitolo 4 Studi preliminari ed installazione di Ns2 Abbiamo ora a disposizione la simulazione di una rete su cui misurare la banda residua, uno scheduling delle misure ed un algoritmo di routing che determina i percorsi di banda migliore e le prestazioni minime garantite. In vista di uno studio approfondito di valutazione del modello rispetto al routing effettivo, sono stati effettuati studi preliminari sul simulatore di rete Ns2 [23][24][25] e sulle problematiche della sua installazione. Infine, una breve discussione sugli algoritmi di routing link state e Distance Vector, supportati da Ns2.
4.1 Generalità Ns2 è un simulatore di reti ad eventi tempo-discreti ed orientato agli oggetti, con funzionalità molteplici sia nell’ambito delle reti cablate che in quello delle reti wireless. Utilizza un motore di simulazione scritto in C++ e permette all'utente di interagire con il simulatore tramite un front-end Tcl/OTcl interpretato. La realtà è modellata come una successione di eventi gestiti da uno scheduler, e gli oggetti comunicano fra loro attraverso lo scambio di pacchetti. Ns2 utilizza due linguaggi, C++ ed Otcl, che hanno diverse finalità. Il C++ è rapido da eseguire ma più lento da modificare, e ciò lo rende adatto per implementazioni dettagliate di protocolli ed algoritmi di elaborazione dei pacchetti. Otcl invece è lento da eseguire ma può essere modificato molto rapidamente, poiché permette l’interazione utente-simulatore. Viene utilizzato, ad esempio, per descrivere o modificare la topologia della rete.
46
La coesistenza dei due linguaggi comporta l’utilizzo di due gerarchie di classi, una C++ (gerarchia compilata), l’altra OTcl (gerarchia interpretata). L’utilizzo di entrambe ha motivazioni simili a quelle dell’utilizzo dei due linguaggi: da una parte la gestione del traffico di rete, dall’altra il controllo ed il setup della rete. Le due gerarchie sono strettamente correlate l’una all’altra. Dal punto di vista dell’utente, infatti, c’è una corrispondenza 1:1 tra una classe nella gerarchia interpretata ed una classe in quella compilata. La radice di questa gerarchia è la classe TclObject. La Fig. 25 mostra i primi livelli. L’utente può creare nuovi oggetti del simulatore attraverso l’interprete, all’interno del quale vengono istanziati e dal quale vengono associati immediatamente ad un oggetto corrispondente nella gerarchia compilata. La gerarchia di classi interpretata è automaticamente stabilita attraverso i metodi definiti nella classe TclClass, mentre gli oggetti istanziati dall’utente, vengono associati all’oggetto della gerarchia compilata attraverso i metodi definiti nella classe TclObject.
Fig. 25: gerarchia Ns2 I risultati della simulazione possono essere visualizzati sia in file di testo che in modalità grafica tramite nam e xgraph (Fig. 26).
47
Fig. 26: visualizzazione dei risultati della simulazione
4.2 Problemi di installazione di Ns2 Per installare Ns2 su sistema operativo Windows, è necessario appoggiarsi alla piattaforma Cygwin (Fig. 26), che simula l’ambiente Linux. Installando Ns2 da shell di Cygwin, si può riscontrare questo tipo di errore (o molti altri similari): Tcl-8.4.11 : ./configure: line 7624: syntax error near unespected token ) ' ./configure: line 7624: OSF*) ' Questo accade perchè determinate versioni di bash trovano un errore sintattico nei file ./configure delle cartelle Tcl-8.4.11, Tk-8.4.11, otcl-1.11. In questi tre file si devono trovare tutte le ricorrenze di /relid' e sostituirle con /relid . Al termine dell’ installazione vengono illustrate le variabili di ambiente che devono essere aggiunte nel file ~/.bash_profile. Controllare che nel PATH non vi siano file o cartelle il cui nome contenga uno spazio: questo viene considerato un errore da Cygwin.
48
4.3 Simulazioni Gli algoritmi di routing più usati nele reti reali, anche attualmente, restano il Link-State ed il Distance Vector, che sono infatti compresi nei moduli del simulatore NS2 e verranno quindi usati per efettuare i confronti con l’algoritmo di Dijkstra modificato.
4.3.1 Generalità algoritmo Link State
I protocolli di tipo Link State sono basati sul concetto di “mappa distribuita”: tutti i nodi posseggono una copia della mappa della rete, che viene regolarmente aggiornata. In seguito esamineremo come la mappa sia in effetti rappresentata da un database, come avvengono gli aggiornamenti ai nodi della rete, perchè questi aggiornamenti devono essere sicuri ed infine perchè alcuni protocolli della famiglia Link State vengono denominati "shortest path first" (SPF) Il principio alla base dell'instradamento di tipo Link State è molto semplice: invece di calcolare i percorsi migliori in modo distribuito, tutti i nodi mantengono una copia intera della mappa della rete ed eseguono un calcolo completo dei migliori percorsi da questa mappa locale. La mappa è contenuta in un database, dove ciascun record rappresenta un link nella rete. Ad esempio, la rete in Fig. 27:
Fig. 27: rete di esempio per Link-State
49
è rappresentata dalla seguente tabella:
da a link peso
A B 1 1
A D 3 1
B A 1 1
B C 2 1
B E 4 1
C B 2 1
C E 5 1
D A 3 1
D E 6 1
E B 4 1
E C 5 1
E D 6 1
Tab.3: rappresentazione tabellare della rete di Fig. 27 Ciascun record è inserito da una stazione responsabile di ciò e che contiene un identificatore di interfaccia, nel nostro caso il numero di link, e le informazioni che descrivono lo stato del link: la destinazione e la distanza o metrica. Con queste informazioni ogni nodo può facilmente calcolare il percorso più breve da se stesso a tutti gli altri nodi. Poichè tutti i nodi contengono lo stesso database ed eseguono lo stesso algoritmo di route-generation, i percorsi sono coerenti e non si verificano loop. Ad esempio, se inviamo un pacchetto dal nodo A al nodo C nella rete riportata in precedenza, ci baseremo sui calcoli tra i nodi A e B. Il nodo A può rilevare, tramite il database, che il percorso più corto verso C passa attraverso il nodo B e quindi invia il pacchetto sul link numero 1 . Il nodo B, a sua volta, invierà il pacchetto sul link numero 2.
50
I pacchetti inviati da un router e che, ricevuti dai vari router della rete, permettono la costruzione della mappa della rete, sono detti Link State Packet (LSP). Il Link State Packet (LSP) contiene informazioni sullo stato di ogni link connesso al router:
• identità di ogni vicino connesso all'altro estremo del link (sulle LAN possono esserci migliaia di vicini)
• costo del link • numero di sequenza per il LSP (a seguito di frequenti variazioni di
topologia un router può ricevere un LSP vecchio dopo uno nuovo, quindi deve essere in grado di valutare il più recente)
• checksum • lifetime (la validità di ogni LSP è limitata nel tempo, diversamente
un errore sul numero di sequenza potrebbe rendere un LSP valido per anni)
Un LSP viene generato periodicamente, oppure quando viene rilevata una variazione nella topologia locale (adiacenze), ossia :
• viene riconosciuto un nuovo vicino • il costo verso un vicino e' cambiato • si e' persa la connettivita' verso un vicino precedentemente
raggiungibile Il LSP è trasmesso in flooding su tutti i link del router e tutti i router del dominio di routing ricevono il LSP. All'atto del ricevimento di un LSP il router compie le seguenti azioni:
• se non ha mai ricevuto LSP da quel router o se il LSP è più recente di quello precedentemente memorizzato (campo Sequence Number), memorizza il pacchetto e lo ritrasmette in flooding su tutte le linee eccetto quella da cui l'ha ricevuto
• se il LSP ha lo stesso numero di sequenza di quello posseduto non fa nulla
51
• se il LSP è più vecchio di quello posseduto trasmette al mittente il pacchetto più recente
4.3.1 Generalità algoritmo Distance Vector
Il routing Distance Vector (routing basato sul vettore delle distanze), noto anche come routing di Bellman-Ford, è un tipo di algoritmo di routing dinamico, che tiene conto del carico istantaneo della rete. Questo opera in modo tale che ogni nodo conosca, basandosi su misure effettuate, il ritardo o la distanza che lo separa dai suoi nodi adiacenti e quindi comunicandogli periodicamente queste informazioni. Combinando i dati ricevuti da ciascun router si riesce a creare e a tenere sempre aggiornata una tabella, ossia un vettore, nel quale è specificata la stima del minor tempo o della minore distanza associata ad ogni destinazione, e quale sia la linea che conduce a questa. Un processo di aggiornamento è riportato qui di seguito:
Si consideri una sottorete come in Fig. 28.
Fig. 28: sottorete di esempio per Distance Vector
52
Si supponga che F abbia stimato i ritardi dai routers vicini C,I,G ed E:
• C sa di poter raggiungere A in 5 msec , quindi F che ha calcolato un ritardo da C di 2 msec, sa di poter raggiungere A tramite C in 5+2=7 msec
• E sa di poter raggiungere A in 2 msec , quindi F che ha calcolato un ritardo da E di 3 msec, sa di poter raggiungere A tramite E in 2+3=5 msec
• G sa di poter raggiungere A in 3 msec , quindi F che ha calcolato un ritardo da G di 3 msec, sa di poter raggiungere A tramite G in 3+3=6 msec
• I sa di poter raggiungere A in 6 msec , quindi F che ha calcolato un ritardo da I di 1 msec, sa di poter raggiungere A tramite I in 6+1=7 msec
Il valore migliore è 5, quindi F crea nella sua tabella di routing un valore associato ad A registrando il ritardo pari a 5 msec e la linea di trasmissione E. Quindi, al contrario di altri algoritmi tra i quali il Link-State, il Distance Vector non fa conoscere a ciascun router la topologia dell'intera rete, ma solo dei suoi vicini. Questo porta a diverse problematiche, tra le quali il problema del conto all'infinito.
4.3.2 Operazioni preliminari
Per il confronto con ns2 occorre effettuare alcune operazioni preliminari. Innanzitutto, l’algoritmo di creazione del grafo - oltre a memorizzare il grafo stesso in un file .txt - crea anche un file in linguaggio tcl con gli stessi nodi, link e pesi. In altre parole, si rappresenta il grafo in un formato leggibile da ns2. Per prima cosa è necessario invocare la classe simuator per istanziare il motore di simulazione:
set ns [new simuator]
Si settano quindi il colore dei pacchetti che verranno trasmessi, ed il nome del file .nam che permetterà la visualizzazione grafica della simulazione
53
: $ns color 1 Blue set nf [open outpr5.nam w] $ns namtrace-all $nf
Viene poi definita la procedura che chiude la simulazione e specificato l’algoritmo di routing da adottare per tutti i nodi. I confronti sono stati effettuati sia con Link-state che Distance Vector:
proc finish {} { global ns nf tf $ns flush-trace close $nf close $tf exec nam outpr5.nam & exit 0 } $ns rtproto LS (o $ns rtproto DV)
Si procede ora alla descrizione del grafo, che in un file .tcl si suddivide in due parti principali. Prima si crea un oggetto di tipo node per ogni nodo del grafo, assegnando inoltre ad ognuno di essi un nome univoco:
set n0 [$ns node]
Si definiscono poi i collegamenti tra i nodi, letti dal file di testo contenente la loro lista. Questi in ns2 possono essere definiti in due modi: monodirezionali (simplex-link) o bidirezionali (duplex-link). In questa simulazione verranno usati solo collegamenti simplex-link dal momento che, come è stato precedentemente spiegato, vi è una certa percentuale di asimmetria nella rete ed i link di andata e ritorno vanno distinti. Specifichiamo infatti per ogni collegamento monodirezionale, il suo costo:
54
$ns simplex-link $n0 $n1 0.3Mb 10ms DropTail $ns cost $n0 $n1 1000
Per il corretto funzionamento di Link-State e Distance Vector in ns2, vengono aggiunti un nodo sorgente ed un nodo destinazione. Al fine di visualizzare lo scorrimento dei pacchetti tra i due nodi fissati, si sdevono definire ed assegnare gli agenti necessari. Gli agent sono gli elementi dove si realizza la geerazione a livelo di rete delle unità informative che devono essere trasmesse e la rimozione delle stesse dopo la ricezione. In ns2 sono presenti diversi tipi di agent per gestire diversi protocolli di trasporto (TCP, UDP,...) e per ogni protocollo di trasporto sono definiti un agent trasmettitore e un agent ricevitore. In questi confronti verrà efinito un protocollo tcp con trasmettitore e ricevitore assegnati ai nodi di partenza ed arrivo, gli stessi nodi fissati anche nell’algoritmo di Dijkstra modificato:
set tcp [new Agent/TCP/Newreno] $ns attach-agent $n40 $tcp set sink [new Agent/TCPSink/DelAck] $ns attach-agent $n41 $sink $ns connect $tcp $sink $tcp set fid_ 1 set ftp [new Application/FTP] $ftp attach-agent $tcp $ftp set type_ FTP
Infine non resta che stabilire istanti di inizio dell’ invio di pacchetti e di fine simulazione, e lanciare la simulazione stessa:
$ns at 0.1 "$ftp start" $ns at 30.0 "finish" $ns run
55
4.3.3 Confronti
Viene eseguito il programma che genera un grafo casuale di 40 nodi in cui il nodo 0 ed il nodo 20 sono stati fissati come partenza ed arrivo. Dopo la generazione del file di testo contenente tutti i link della rete ed il file .tcl corrispondente descritto prcedentemente, calcola tramite l’algoritmo di Dijkstra modificato il percorso minimo mostrandone a video tutti i nodi intermedi e la banda minima garantita, ovvero il costo del link peggiore (Fig. 29):
Fig 29: Dijkstra modificato primo confronto
Il percorso trovato in questo esempio risulta essere: 0-1-5-20. Evidenziando i suddetti link, facenti parte del percorso, nel file di testo contenente tutti i collegamenti del grafo, troviamo conferma della distanza minima tra sorgente e destinazione e del costo del link peggiore (Fig. 30):
56
Fig. 30: File di testo contenente la lista dei collegamenti del grafo
Eseguiamo infine il file .tcl creato e visualizzando la simulazione grafica dello stesso grafo con ns2 utilizzando il protocollo di routing Link-State, possiamo notare come il percorso minimo trovato corrisponda alla stessa sequenza di nodi risultante dall’algoritmo di Dijkstra modificato (Fig. 31):
57
Fig. 31: Output .nam con protocollo Link-State
Rieseguendo nuovamente il programma di creazione del grafo e algoritmo di Dijkstra modificato, ma specificando nel file .tcl l’utilizzo del protocollo Distance Vector, si è ottenuto il seguente confronto:
Fig. 32: Dijkstra modificato secondo confronto
58
In Fig. 32 in un grafo di 30 nodi, sempre con nodo 0 e 20 fissati come partenza ed arrivo, l’algoritmo di Dijkstra modificato trova come percorso minore 0-1-20. Dall’esecuzione del file .tcl otteniamo (Fig. 33):
Fig. 33: Output .nam con protocollo Distance Vector
Anche nelconfronto con il protocollo Distance Vector i due percorsi minimi risultano identici.
59
Conclusioni e sviluppi futuri Come illustrato nei capitoli centrali della tesi, partendo dallo sviluppo di un programma che , inseriti 4 parametri dall’ utente (numero di nodi del grafo, percentuali di link effettivi esistenti, pecentuale di asimmetria degli archi e hop minimo), crei una rete che rispetti questi vincoli, si è proceduto alla creazione di un algoritmo di Dijkstra modificato valutabile su questa rete.
Sempre a questo scopo è stato studiato il simulatore NS2, che tra i suoi moduli contiene gli algoritmi di routing Link-State e Distance Vector e confrontando entrambi con i percorsi minimi trovati dall’ algoritmo di Dijkstra modificato, questi percorsi sono risultati i medesimi.
Uno sviluppo interessante da effettuare sarebbe lo studio comparato del comportamento di questi algoritmi in una rete dinamica (piu simile quindi ad una reale), in cui, al variare dei link ( ad esempio caso di un link momentaneamente off ) scattasse nuovamente il calcolo di Dijkstra dell’eventuale nuovo percorso minimo.
60
Bibliografia e sitografia Piattaforme integrate:
[1] Citrix - Access on Demand: Remote Desktop Solutions, www.citrix.com
[2] Sun, Inktomi CorpRedback Networks Inc. et al. (http://www.sun.com)
[3] www.fujitsu.com
[4] www.cisco.com
Adattatività:
[5] T. Kwon, Y. Choi, C. Bisdikian, M. Naghshineh, QoS Provisioning in
Wireless/Mobile Multimedia Networks Using an Adaptive Framework,
ACM Wireless Networks, vol. 9, no. 1, 5159, 2003
[6] Nidal Nasser, Real-Time Service Adaptability in Multimedia Wireless
Networks, Q2SWinet05, Montreal, Quebec, Canada, 2005
[7]Taekyoung Kwon , Yanghee Choi , Sajal K. Das, Bandwidth Adaptation Algorithms for Adaptive Multimedia Services in Mobile Cellular Networks, Wireless Personal Communications: An International Journal, v.22 n.3, p.337-357, September 2002 [8] Ruiz, P.M. Garcia, E. Agora Systems S.A., Madrid, Spain Improving user-perceived QoS in mobile and wireless IP networks using real-time adaptive multimedia applications, 15-18 Sept. 2002 Progetto InSeBaLa:
[9] www.bo.ieiit.cnr.it/insebala.php
[10] www.insebala.com
[11] http://www.wilab.org/insebala/ [12] C. Donzelli, C. Fontana, A. Ravaioli, P. Toppan, M. Patella, C. De Castro, An LDAP/SQL-based Architecture for Broadband Services, Proc. of
61
IASTED Int. Conference on Communication Systems and Applications (CSA 2006), Banff, Canada, July 3rd-5th 2006. [13] C. Donzelli, C. Fontana, A. Ravaioli, P. Toppan, M. Patella, C. De
Castro, Software Emergency: Network Optimisation via the Selective
Release of Broadband Services, TR IEIIT-CNR-04-06
LDAP:
[14] W. Yeong, T. Howes, S. Kille, Lightweight Directory Access
Protocol, IETF RFC 1777, 1995 http://www.ietf.org/rfc/rfc1777.txt.
[15] M. Wahl, T. Howes, and S. Kille, Lightweight Directory Access
Protocol (v3), IETF RFC 2251, 1997, www.ietf.org/rfc/rfc2251.
[16] Ehlenberger, R. Gorthi, S.Tuttle et al, Understanding LDAP Design
and Implementation, IBM International Technical Support Organization,
2004, www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf
[17] T.A. Howes, M.C. Smith, G.S. Good, Understanding and Deploying
LDAP Directory Services, Addison Wesley 2003, 2^ ed.
[18] G. Carter , LDAP System Administration, O'Reilly, 2004
[19] D. Kandlur, H. Schulzrine, D. Verma, X. Wang, Measurement and
Analysis of LDAP Performance, Network Systems Department –
IBM T.J. Watson Research Center,
www.cse.buffalo.edu/~xwang8/public/paper/LDAP_sigmetrics.pdf
[20] V. Koutsonikola, A. Vakali, LDAP: framework, practices, and trends,
Internet Computing, IEEE, Volume 8, Issue 5, Sept.-Oct. 2004 Page(s):66
- 72 Digital Object Identifier 10.1109/MIC.2004.44
[21] C.S. Yang, C.Y. Liu, J. H. Chen, C.Y. Sung, Design and
implementation of secure Web-based LDAP management system,
Proceedings of 15th International Conference on Information Networking,
62
2001, Page(s):259 – 264, Digital Object Identifier
10.1109/ICOIN.2001.905437
[22] L. Kaining, Y.T. Xian, T. Yun, J. Zou, Design and implementation of
DHCP & LDAP directory service integrated management system, IEEE
2002 International Conference on Communications, Circuits and Systems
and West Sino Expositions, Volume 1, 2002 Page(s):758 – 762 vol.1
Simulazione, ns2:
[23] http://www.isi.edu/nsnam/ns/ [24] http://nile.wpi.edu/NS/ (Jae Chung, Mark Claypool, NS by example) [25] The ns Manual (formerly ns Notes and Documentation) - The VINT Project. A collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC. Kevin Fall, Editor & Kannan Varadhan, Editor Monitoraggio:
[26] L. Li, M. Thottan, B. Yao, S. Paul Distributed Network Monitoring
with Bounded Link Utilization in IP Networks, IEEE INFOCOM 2003
[27] R. Subramanyan, J.Miguel-Alonso, J. A. B. Fortes, A scalable SNMP
based distibuted monitoring system for heterogeneous network computing,
Proceedings of SC2000, Dallas, Texas, 2000
63
Lista delle tabelle: Tab. 1: blocchi del sistema abilitante con rispettivi ingressi ed uscite
Tab. 2: percorsi ottimi sul grafo di Fig. 22 e rispettivi tratti peggiori Tab. 3: rappresentazione tabellare della rete di Fig. 1
Lista delle figure: Fig. 1: rete per il testbed Fig. 2: architettura di base per i requisiti d’ambiente
Fig. 3: classi LDAP di primo livello
Fig. 4: classi LDAP di primo livello su ldapweb.bo.cnit.it
Fig. 5: interfaccia di accesso ai servizi
Fig. 6: architettura del sistema abilitante
Fig. 7: gestione integrata dell’emergenza
Fig. 8: rappresentazione LDAP dell’emergenza software
Fig. 9: classi MTMminutes e rispettive ACL sul server LDAP
Fig.10: fasi del login ed accesso ai servizi Fig. 11: decisione del livello di emergenza
Fig. 12: architettura del blocco decisore emergenza
Fig. 13: flusso di ingressi e di uscite dei blocchi del sistema abilitante per l’attivazione di applicazioni
Fig. 14: modello della rete fisica
Fig. 15: vincolo di hop
Fig. 16: vincolo di connettività Fig. 17: completamento del grafo e percorso più lungo
Fig. 18: modello dell’albero di scheduling
Fig. 19: interazione dei componenti base
Fig. 20: struttura del SNMP MIB tree
64
Fig. 21: grafo originale e corrispondente grafo con pesi complementati Fig. 22: prestazioni dell’algoritmo di Dijkstra al variare del numero di nodi, utilizzando file di testo e tabella MySql. Link effettivi 2%, asimmetrie 20%, hop 4 Fig. 23: struttura di scheduling sui nodi della rete testbed di Bologna Fig. 24: (a) grafo iniziale e (b) relativo percorso ottimo AE; (c) variazioni rilevate dalle misure SNMP e riassegnazione dinamica dei pesi; (d) nuovo percorso ottimo AE
Fig. 25: gerarchia Ns2
Fig. 26: visualizzazione dei risultati della simulazione Fig. 27: rete di esempio per Link-State
Fig. 28: sottorete di esempio per Distance Vector Fig 29: Dijkstra modificato primo confronto Fig. 30: File di testo contenente la lista dei collegamenti del grafo Fig. 31: Output .nam con protocollo Link-State Fig. 32: Dijkstra modificato secondo confronto Fig. 33: Output .nam con protocollo Distance Vector
Contenuto del cd • Algoritmo di creazione di un grafo di rete con memorizzazione sia su
file di testo che su tabelle mysql • Algoritmo di Dijkstra modificato • Copia di questa tesi in formato elettronico
