Post on 01-May-2015
Alessandro Ghioni
CEFRIEL - Politecnico di Milano
Middleware per MANET
WP3
Milano - 17 Novembre ‘04
2Middleware per MANET
Posizionamento del middleware per le MANET in MAIS
Definizione e implementazione del protocollo di routing sicuro adattativo A-SAODV
Definizione e implementazione di meccanismi di accesso e controllo delle informazioni del protocollo di routing
Implementazione degli R_Object per le MANET
Implementazione di alcune funzionalità, come la ricerca di informazioni nella MANET
MAIS Reflective Architecture
Gestione eventi
3Middleware per MANET
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-Ѐ naturale che il middleware per le MANET segua un paradigma peer-to-peerpeer
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”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• JavaJava per lo sviluppo della piattaforma
• Lo scambio dei messaggi XML per la sincronizzazione degli R_Object e dei Guess Object avviene tramite SOAPSOAP
• Lo storage delle immagini riflessive avviene su DB DB XMLXML
4Middleware per MANET
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)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-UUAODV-UU
(Uppsala University)• Modulo Kernel + Demone di routing
• linguaggio C• emulatore di MANET: MobiEmuMobiEmu
10 Mb/s100 Mb/s2 Mb/s
MobiEmu MASTER
MobiEmu SLAVE
MobiEmu SLAVE
MobiEmu SLAVE
MobiEmu SLAVE
5Middleware per MANET
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
6Middleware per MANET
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
7Middleware per MANET
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
AggregandoAggregando 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.
8Middleware per MANET
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 centralizzatoNon 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.
9Middleware per 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
10Middleware per MANET
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 diindicizzazione
• 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
11Middleware per MANET
Conclusione
AttualmenteAttualmente:
• 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 paralleloIn parallelo, considerando lo specifico dominio delle specifico dominio delle
MANETMANET 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
12Middleware per MANET
Contatti
Alessandro Ghioni
Cefriel – Politecnico di Milano
Area Middleware
ghioni@cefriel.it
Davide Cerri
Cefriel – Politecnico di Milano
Area Middleware
cerri@cefriel.it
Nicola Simeoni
Cefriel – Politecnico di Milano
Area Middleware
simeoni@cefriel.it
Giuseppe Gramazio
Cefriel – Politecnico di Milano
Area Middleware
gramazio@cefriel.it