<div dir="ltr">Scrivo due note, così evitiamo di ripeterle durante la riunione.<div>Sono note che poi potranno essere spese per una futura nostra documentazione.</div><div><br></div><div>ROUTING</div><div><br></div><div><div>
Due parole sui protocolli papabili. Vi è inoltre la volontà di formalizzare/documentare per le newentry.</div><div><br></div><div>OLSR è un protocollo Link-State e Proattivo (table-driven).</div><div>Il link-state (routing basato sullo stato del collegamento) utilizza il concetto di mappa distribuita, ossia un elenco di tutti i link della rete</div>
<div>con relativo costo. Tutti i routers hanno una copia di tale mappa che viene aggiornata in continuazione</div><div><br></div><div><br></div><div>Ogni nodo, periodicamente, usa la tecnica del flooding, chiamata in </div>
<div>questo caso Link State Broadcast, per inviare a tramite tutti i suoi </div><div>link diretti un messaggio Link State Packet (LSP), contenente tutte le informazioni sui link tra il mittente del messaggio e tutti i suoi vicini. </div>
<div>Alla ricezione di tale messaggio, ogni router, aggiorna la propria routing table e lo rispedisce a tutti i suoi vicini diretti tranne quello da cui arriva tale</div><div>messaggio.</div><div><br></div><div>In questo modo tutti i routers hanno sempre memorizzata la mappa della rete aggiornata in una struttura ad albero ed il cammino più conveniente si ottiene con un algoritmo shortest path ( vedi Dijkstra ).</div>
<div><br></div><div>Il fatto che OLSR sia table-driven (ovvero guidato da tabelle di scambio) ha un vantaggio e uno svantaggio:</div><div><br></div><div>PRO: Tutti i possibili percorsi di routing vengono calcolati e </div>
<div>modificati senza sapere se verranno in futuro utilizzati ( visione a </div><div>360° della rete ). Otteniamo una tabella di routing biblica, immensa, </div><div>omnicomprensiva (impossibile da consultare senza grep !).</div>
<div><br></div><div>CONTRO: FLOOD e carico di sistema. il primo scaturisce dall'attività </div><div>di annunciazione di ogni nodo, il secondo scaturisce dal fatto che lo </div><div>"shortest-path" richiede elaborazione computazionale pari al numero di </div>
<div>nodi. Quindi più si espande la rete più questi due fattori crescono. </div><div>La propagazione di tutte le tabelle di tutti i nodi </div><div>riduce la banda disponibile (over-head di rete), il carico computazionale ai dispositivi </div>
<div>riduce la reattività degli stessi.</div><div><br></div><div>Ad ogni modo per OLSRd non è necessario questo flooding venga inviato da tutti i nodi, ma basta che</div><div>a inviarlo siano un ristretto numero di vicini del nodo comunicante. </div>
<div>Questo set di nodi prende il nome di MPR (Multipoint Relays) - </div><div>definito anche Optimized Flooding (MPR).</div><div><br></div><div>La tecnica MPR nasce dall’osservazione che in una situazione di broadcast</div>
<div>non ottimizzato ogni nodo riceve più volte le stesse informazioni causando</div><div>un notevole spreco di banda e di potenza di calcolo.</div><div><br></div><div>L ’RCF di OLSR descrive inoltre un semplice algoritmo euristico per calcolare il </div>
<div>sottoinsieme di MPR. L’Optimized Flooding fa si che un nodo elegga tra i suoi vicini (nei-</div><div>ghbor) il minimo insieme che consente di raggiungere tutti i 2-hop-neighbor</div><div>(tutti i vicini a distanza di due hop). Serve quindi capire quanti MPR deve</div>
<div>avere ogni nodo (tuning) e quali informazioni topologiche far distribuire ai</div><div>propri MPR: chiedo a SPAX e GIGI quali parametri vorremmo analizzare </div><div>al fine di argomentare le esperienze trascorse.</div>
<div><br></div><div>andiamo a BATMAN, questo si basa piuttosto che sul Link-State, usando </div><div>le tabelle di routing come media, sul Distance-Vector che si basa sull’algoritmo di Bellmann-Ford.</div><div>Ogni nodo mantiene un database con le distanze minime tra se stesso e tutte le possibili destinazioni. </div>
<div>A intervalli regolari invia ai nodi adiacenti un distance-vector,  un </div><div>insieme di coppie indirizzo-distanza, chiamate annunci. La distanza è </div><div>espressa come numero di hop o con criteri più generali che tengono </div>
<div>conto di velocità, carico e affidabilità dei collegamenti.</div><div><br></div><div>A partire da tali dati, utilizzando l’algoritmo di Bellman-Ford, il router co-</div><div>struisce una tabella che associa ad ogni destinazione conosciuta la distan-</div>
<div>za che lo separa dalla destinazione e il primo passo del percorso calcolato.</div><div>Quando riceve il distance-vector, un nodo puù usare queste informazioni per</div><div>ricalcolare la sua tabella di routing e, a differenza dei Link-State, questo</div>
<div>messaggio non viene forwardato.</div><div><br></div><div>Con BATMAN un router ricalcola le proprie tabelle se:</div><div><br></div><div>• cade una linea attiva direttamente connessa</div><div>• riceve da un router vicino un annuncio per una destinazione non cono-</div>
<div>sciuta</div><div>• riceve da un router vicino un annuncio per una destinazione già nota,</div><div>ma a costo più basso rispetto a quello memorizzato </div><div>• riceve da un router vicino un annuncio per una destinazione che lo stesso</div>
<div>router aveva già annunciato precedentemente con costo più elevato </div><div>• scade il tempo massimo di vita (TTL) per una destinazione in tabella</div><div><br></div><div>Sicuramente a fare più paura è l'ultima condizione, ovvero la </div>
<div>scadenza del TTL, perchè si traduce in tempi di attesa per aspettare </div><div>che il dispositivo "sperimenti" nuovi percorsi (andando a </div><div>casaccio...Con il pericolo di creare loops...), poichè trovare il percorso migliore richiede più tempo </div>
<div>non avendo l’intera topologia a disposizione per il calcolo e questa </div><div>complessità si traduce nella pratica in velocità di convergenza più bassa.</div><div><br></div><div>la configurazione dei router risulta molto più semplice e la</div>
<div>necessità di memoria (RAM) in essi è bassa poichè ogni router deve memorizzare solo le informazioni sui collegamenti da se stesso verso gli altri nodi</div><div>e non sull’intera rete, questo si traduce in un minor costo.</div>
<div><br></div><div>Quello che un nodo batman annuncia si chiama Originator Messages e </div><div>contiene solo il primo hop verso una destinazione (e non tutto lo </div><div>scibile come le tabelle floddate da OLSR).</div>
<div><br></div><div>A seguito della terza generazione di Batman è stata ideata la versione </div><div>Advanced che consente di gestire il routing a livello 2 per mezzo di </div><div>un modulo del kernel. </div><div><br></div>
<div>Confronti utili:</div><div><br></div><div>Se la rete supera le centinaia di nodi OLSR impiega molte risorse per </div><div>il calcolo del path più corto, mentre batman divide la conoscenza e </div><div>delega il routing agli hop di competenza.</div>
<div><br></div><div>Una rete mesh basata su B.A.T.M.A.N. viene inondata a intervalli regola-</div><div>ri da Originator Messages fino a che non vengono ricevuti dal destinatario</div><div>almeno una volta o finche il pacchetto non viene perso causa fine del TTL</div>
<div>o problemi di comunicazione. Il protocollo ritiene significativa ogni perdita</div><div>di pacchetti per trovare il percorso migliore.</div><div><br></div><div>DOMANDA: è capitato che OLSR forwardasse roba vecchia di nodi andati </div>
<div>giù ? Con Batman questo non sarebbe possibile.</div><div><br></div><div>Per integrare i due, piuttosto che avere entrambi sui medesimi nodi </div><div>non sarebbe meglio e innovativo (dati gli scopi di ninux) sperimentare </div>
<div>soluzioni miste con l'adozione di messaggi HNA per gli annunci a </div><div>sistemi differenti (OLSR->HNA->BATMAN e viceversa).</div><div><br></div><div>Potremmo sperimentare newSPIG con OLSR e Capizzanux con Batman i quali </div>
<div>comunicano tramite HNA ? Sarebbe il primo esperimento ufficiale dentro </div><div>ninux oppure a Roma hanno già fatto ?</div><div><br></div><div>Prima di procedere:</div><div><br></div><div>Un host malintenzionato potrebbe inviare OGM che annunciano l’esisten-</div>
<div>za di nodi inesistenti per causare un overflow nelle tabelle di routing degli</div><div>altri nodi e un eccessivo carico di CPU, così anche per il flooding di </div><div>OLSR.</div><div><br></div><div>Sappiamo bene che sicurezza e mesh non vanno daccordo ma dobbiamo </div>
<div>perlomeno sperimentare, adoperare, formalizzare, degli strumenti di </div><div>diagnosi semi-automatica e isolamento del problema per evitare di </div><div>avere grandi problemi in una futura grande rete.</div><div><br>
</div><div>Penso che a tale merito il routing a terra sia di aiuto.</div><div><br></div><div><br></div></div></div>