Middleware per MANET WP3 Alessandro Ghioni CEFRIEL - Politecnico di Milano Milano - 17 Novembre ‘04 WP3

Posizionamento del middleware per le MANET in MAIS MAIS Reflective Architecture Gestione eventi Implementazione di alcune funzionalità, come la ricerca di informazioni nella MANET Implementazione degli R_Object per le MANET Definizione e implementazione di meccanismi di accesso e controllo delle informazioni del protocollo di routing Definizione e implementazione del protocollo di routing sicuro adattativo A-SAODV

Il middleware per le MANET La MANET è un ambiente decentralizzato, collaborativo, non affidabile Ciascun nodo partecipa all’infrastruttura, non esistono nodi “ gerarchicamente superiori” La MANET è una rete “fisicamente peer-to-peer” Ѐ naturale che il middleware per le MANET segua un paradigma peer-to-peer Ogni dispositivo ha al suo interno una parte del middleware Non tutti i dispositivi sono in grado di svolgere tutte le operazioni previste I dispositivi meno potenti possono utilizzare un “device d’appoggio” per alcune funzionalità, quali: Storage e condivisione delle immagini riflessive Gestione degli eventi Gestione di funzionalità avanzate come la ricerca di informazioni Non è necessario che il device d’appoggio sia in visibilità diretta Middleware: Tecnologie utilizzate Java per lo sviluppo della piattaforma Lo scambio dei messaggi XML per la sincronizzazione degli R_Object e dei Guess Object avviene tramite SOAP Lo storage delle immagini riflessive avviene su DB XML

MANET – Tecnologie e protocolli utilizzati AODV protocollo di routing più consolidato per le MANET. non fornisce garanzie di sicurezza meccanismo di delega per rispondere al posto del destinatario SAODV: proposta in letteratura garantisce autenticità e integrità dei messaggi di routing l’uso di firme digitali influisce negativamente sulle prestazioni A-SAODV (proposta CEFRIEL) stesse garanzie di sicurezza di SAODV prestazioni migliori di SAODV (da simulazioni) approccio “leggero” nella firma di messaggi di routing, rendendo adattativo il meccanismo di delega Ambiente di test e sviluppo: 5 Linux box (Fedora Core 2, Kernel 2.6) implementazione routing: AODV-UU (Uppsala University) Modulo Kernel + Demone di routing linguaggio C emulatore di MANET: MobiEmu

Interfacciamento tra middleware e A-SAODV La tabella di routing contiene le informazioni topologiche N.B.: informazioni parziali perchè il protocollo è un Distance Vector reattivo Informazioni reperibili nella tabella di routing per ogni destinazione: (le più significative) Prossimo nodo sul percorso Distanza (in hop) del destinatario Firme apposte sui messaggi di routing Eventi inviati dal demone di routing all’istanza del middleware Notifica nuovo vicino (visibilità radio) Controllo Parametro di soglia per il comportamento collaborativo Coppia di chiavi (pubblica/privata) appartenenti al dispositivo Lista di chiavi pubbliche di nodi trusted Meccanismi di interfaccia tra middleware e demone di routing File, Socket

Informazioni rese disponibili attraverso gli R_Object Observable distanza (in hop) da un nodo se l’informazione non è al momento presente nella tabella, il middleware potrebbe chiedere di effettuare un “ping” al nodo per ottenerla prossimo nodo sul percorso elenco dei nodi vicini Controllable soglia di collaborazione Eventi notifica arrivo nuovi vicini

Funzioni del middleware (aggregazione informazioni topologiche) Informazioni sugli altri nodi necessitano dell’interazione tra l’istanza del middleware su un dispositivo e le altre istanze Aggregando informazioni provenienti da altri nodi, il middleware può fornire alle applicazioni: il percorso (elenco nodi intermedi) verso un nodo, ottenuto per aggregazione interrogando progressivamente i “next hop” verso il nodo destinazione. mappa di una porzione della rete. ottenuta per aggregazione delle tabelle di routing interrogando i nodi facenti parte della porzione di rete di interesse. N.B.: Considerando anche il tempo necessario alla raccolta dell’informazione, questa potrebbe non essere aggiornata / coerente.

Interazione tra le istanze del middleware Le istanze del middleware poste sui dispositivi devono interagire per poter comunicare tra loro in pull (richiesta di R-Object) in push (notifica di eventi) perchè il middleware deve fornire un supporto alla ricerca di risorse/servizi per applicazioni collaborative decentralizzate esempio: risoluzione dei nomi di dominio Non può esistere un registro centralizzato bisogna studiare meccanismi di search/lookup tramite flooding: semplice, non particolarmente efficiente, tramite una Distributed HashTable (DHT): più complesso; probabilmente più efficiente; deve essere “tarato” sul caso MANET.

Ricerca tramite flooding sulle MANET Un nodo chiede a tutti i vicini informazioni circa una certa risorsa I nodi vicini, eventualmente, inoltrano la richiesta ai rispettivi vicini Esempio: Gnutella Considerazioni: il flooding è un meccanismo semplice permette la ricerca di informazioni (search) solitamente sulla base di stringhe di testo, interpretabili da ciascun nodo secondo la propria logica è potenzialmente pericoloso per l’operatività della rete si devono realizzare meccanismi conservativi orizzonte delle ricerche numerazione e gestione dei messaggi per evitare la creazione di maglie la notifica di eventi in flooding è relativamente agevole da realizzare rischia di saturare le risorse della rete e dei nodi

Ricerca tramite DHT sulle MANET Una DHT (Distributed HashTable) definisce i meccanismi per suddividere una tabella di hash logicamente unica tra più nodi distribuiti Esempi: Chord, Kademlia Ogni nodo è un peer partecipa allo spazio di indicizzazione globale è assegnatario di una porzione nello spazio di indicizzazione usa algoritmi e protocolli che rendono lo spazio coerente rendono le ricerche deterministiche definiscono una sorta di routing nella rete di overlay E’ una struttura di lookup, non di search permette di memorizzare e cercare una coppia <chiave,valore> ha buone prestazioni N nodi -> log(N) messaggi scambiati la notifica di eventi in questo caso si può realizzare con un meccanismo publish/subscribe

Conclusione Attualmente: Realizzazione del protocollo di routing sicuro adattativo Realizzazione delle classi riflessive e dei meccanismi di sincronizzazione Realizzazione dell’interfaccia tra il routing e il middleware In parallelo, considerando lo specifico dominio delle MANET per definire funzioni evolute per il middleware: Studio su meccanismi di search/lookup per risorse e servizi Studio delle funzionalità di sicurezza/trust per questi meccanismi

Alessandro Ghioni Nicola Simeoni Davide Cerri Giuseppe Gramazio Contatti Alessandro Ghioni Cefriel – Politecnico di Milano Area Middleware ghioni@cefriel.it Nicola Simeoni Cefriel – Politecnico di Milano Area Middleware simeoni@cefriel.it Davide Cerri Cefriel – Politecnico di Milano Area Middleware cerri@cefriel.it Giuseppe Gramazio Cefriel – Politecnico di Milano Area Middleware gramazio@cefriel.it