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: Relatore:

ELISA BENETTI Dott.ssa CRISTINA DE CASTRO

Correlatore:
Dott. PAOLO TOPPAN

Anno Accademico 2005/2006

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.

II
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.

III
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

IV
 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

V
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.

1
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

2
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

3
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

4
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.

5
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

6
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

7
 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.

8
 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

9
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:

10
 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

11
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

12
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, è

13
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

14
 • 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

15
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.

16
 Fig. 8: rappresentazione LDAP dell’emergenza software

Fig. 9: classi MTMminutes e rispettive ACL sul server LDAP

17
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)

18
 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

19
 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.

20
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

21
 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.

22
Fig. 13: flusso di ingressi e di uscite dei blocchi del sistema abilitante
per l’attivazione di applicazioni

blocco input output

Apache IP applicazioni consentite
dn
gruppi di appartenenza
ACL
livello di emergenza
LDAP/MySql IP gruppi di appartenenza
dn ACL
livello di emergenza
BDE IP livello di emergenza
dati rete
dati geografici
Tab. 1: blocchi del sistema abilitante con rispettivi ingressi ed uscite

23
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.

24
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).

25
 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)

26
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
i
m ≥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).

27
 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.

28
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.

29
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.

30
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

31
 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:

32
 - 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

33
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

34
 • 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.

35
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 }

36
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

37
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 peso del link peggiore (banda minima

migliore 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?

38
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

39
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:

40
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

41
 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

42
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).

43
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

44
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.

45
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).

46
 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.

47
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

48
è 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.

49
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

50
 • 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

51
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

52
:
$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:

53
 $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

54
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):

55
 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):

56
 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

57
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.

58
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.

59
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

60
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,

61
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

62
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

63
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

64