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