[Ninux-Calabria] ODG 10 Dicembre 20013

Clauz clauz a ninux.org
Lun 9 Dic 2013 21:24:45 UTC


Ciao, ninux Calabria.
Contravvengo alla prima direttiva. Rispondo inline, tagliando qua e la'.

On 12/09/2013 01:34 PM, Giuseppe De Marco wrote:
> Ad ogni modo per OLSRd non è necessario questo flooding venga inviato da
> tutti i nodi, ma basta che
> a inviarlo siano un ristretto numero di vicini del nodo comunicante. 
> Questo set di nodi prende il nome di MPR (Multipoint Relays) - 
> definito anche Optimized Flooding (MPR).
> 
> La tecnica MPR nasce dall’osservazione che in una situazione di broadcast
> non ottimizzato ogni nodo riceve più volte le stesse informazioni causando
> un notevole spreco di banda e di potenza di calcolo.
> 
> L ’RCF di OLSR descrive inoltre un semplice algoritmo euristico per
> calcolare il 
> sottoinsieme di MPR. L’Optimized Flooding fa si che un nodo elegga tra i
> suoi vicini (nei-
> ghbor) il minimo insieme che consente di raggiungere tutti i 2-hop-neighbor
> (tutti i vicini a distanza di due hop). Serve quindi capire quanti MPR deve
> avere ogni nodo (tuning) e quali informazioni topologiche far distribuire ai
> propri MPR: chiedo a SPAX e GIGI quali parametri vorremmo analizzare 
> al fine di argomentare le esperienze trascorse.

Nell'OLSRd attuale il meccanismo degli MPR e' disabilitato e si fa
flooding. Il motivo e' che si utilizza una metrica chiamata ETX e basata
sui pacchetti persi. I berlinesi hanno visto che rispetto all'hop count
dell'RFC, l'ETX va meglio, ma non e' compatibile con gli MPR. Consiglio
questa pagina:
http://www.open-mesh.org/projects/open-mesh/wiki/The-olsr-story

> andiamo a BATMAN, questo si basa piuttosto che sul Link-State, usando 
> le tabelle di routing come media, sul Distance-Vector che si basa
> sull’algoritmo di Bellmann-Ford.

Non gli dire che sono distance vector! BATMAN e' la terza via :)

> Ogni nodo mantiene un database con le distanze minime tra se stesso e
> tutte le possibili destinazioni. 
> A intervalli regolari invia ai nodi adiacenti un distance-vector,  un 
> insieme di coppie indirizzo-distanza, chiamate annunci. La distanza è 
> espressa come numero di hop o con criteri più generali che tengono 
> conto di velocità, carico e affidabilità dei collegamenti.

Uhm, sinceramente non so com'e' ora, ma una volta l'idea fondamentale
era il meccanismo degli OGM aka Originator Messages. L'idea e' che ogni
nodo generi in broadcast gli OGM, e che ogni nodo che riceve un OGM li
inoltri a sua volta, flooddando la rete. I nodi contano il numero di OGM
che ricevono per ogni coppia (destinazione, link) e i pacchetti vengono
poi inoltrati verso il link da cui si sono ricevuti piu' OGM.

Ah, di fatto batmand (L3) non e' piu' mantenuto, metre BATMAN advanced
(L2) ha un sacco di sviluppatori attivi.

> Confronti utili:
> 
> Se la rete supera le centinaia di nodi OLSR impiega molte risorse per 
> il calcolo del path più corto, mentre batman divide la conoscenza e 
> delega il routing agli hop di competenza.
> 
> Una rete mesh basata su B.A.T.M.A.N. viene inondata a intervalli regola-
> ri da Originator Messages fino a che non vengono ricevuti dal destinatario
> almeno una volta o finche il pacchetto non viene perso causa fine del TTL
> o problemi di comunicazione. Il protocollo ritiene significativa ogni
> perdita
> di pacchetti per trovare il percorso migliore.
> 
> DOMANDA: è capitato che OLSR forwardasse roba vecchia di nodi andati 
> giù ? Con Batman questo non sarebbe possibile.

Si', succede, di solito per brevi periodi.

> Per integrare i due, piuttosto che avere entrambi sui medesimi nodi 
> non sarebbe meglio e innovativo (dati gli scopi di ninux) sperimentare 
> soluzioni miste con l'adozione di messaggi HNA per gli annunci a 
> sistemi differenti (OLSR->HNA->BATMAN e viceversa).
> 
> Potremmo sperimentare newSPIG con OLSR e Capizzanux con Batman i quali 
> comunicano tramite HNA ? Sarebbe il primo esperimento ufficiale dentro 
> ninux oppure a Roma hanno già fatto ?

Non mi sembra sia stato fatto. Da queste parti BATMAN non e' molto
popolare... Perche' non includere anche BMX nel confronto? Penso che per
una rete decentralizzata, per come e' strutturato, prometta molto bene.

> Prima di procedere:
> 
> Un host malintenzionato potrebbe inviare OGM che annunciano l’esisten-
> za di nodi inesistenti per causare un overflow nelle tabelle di routing
> degli
> altri nodi e un eccessivo carico di CPU, così anche per il flooding di 
> OLSR.

Si', potresti annunciare anche migliaia di nodi inesistenti senza grossi
problemi. O fare replay o wormhole attacks. La mia tesi di laurea e'
stata l'integrazione di PGP in OLSR ma e' troppissimo pesante per essere
usato in pratica...

> Sappiamo bene che sicurezza e mesh non vanno daccordo ma dobbiamo 
> perlomeno sperimentare, adoperare, formalizzare, degli strumenti di 
> diagnosi semi-automatica e isolamento del problema per evitare di 
> avere grandi problemi in una futura grande rete.

Molto figo, direi :)

Mi raccomando, vi aspetto al prossimo battlemesh in Germania!!!!!
http://battlemesh.org/BattleMeshV7

Clauz




-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131209/15f9b919/attachment.pgp>


Maggiori informazioni sulla lista Calabria