|
Size: 8594
Comment:
|
← Revision 7 as of 2016-07-27 10:27:12 ⇥
Size: 111
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Modulo QSPN - Esempio di uso degli indirizzi virtuali = == Premessa == In ogni nodo, il demone ''ntkd'', quando inizia la sua attività, si sceglie un identificativo casuale in uno spazio sufficientemente grande per supporre che sia univoco a livello dei domini di collisione in cui partecipa con le sue interfacce di rete. Un intero di 32 bit è più che sufficiente. Inoltre il demone ''ntkd'', per ogni interfaccia di rete che gestisce nel nodo, attiva l'interfaccia di rete e si assegna un indirizzo [[http://en.wikipedia.org/wiki/Link-local_address|link-local]] in IPv4 scelto a caso. Questo indirizzo serve alle comunicazioni del demone ''ntkd'' coi nodi diretti vicini. E anche per individuare il nodo come gateway per una destinazione nelle tabelle di routing. L'associazione tra l'indirizzo MAC di una interfaccia di rete e il suo indirizzo IP link-local rimane la stessa per tutta la durata della vita del demone ''ntkd''. Può succedere che il demone ''ntkd'' in un nodo, per quanto riguarda in particolare le operazioni del modulo QSPN, assuma diverse identità. Ad esempio il nodo 𝛽 che era nel g-nodo ''g'' e migra in ''h'' vuole mantenere una posizione in ''g'' e prenderne una nuova in ''h''. In questo momento, il demone ''ntkd'' crea una sua nuova identità, per la quale si sceglie un altro identificativo casuale. Inoltre il demone ''ntkd'', sopra ogni interfaccia di rete che gestisce, realizza una nuova pseudo-interfaccia con un distinto indirizzo MAC e un distinto indirizzo IP link-local. Infine, per ogni arco che la precedente identità del demone aveva con un nodo diretto vicino, la nuova identità ne crea un duplicato. Avviene inoltre, una sorta di scambio di attributi degli archi tra le due identità. In questo senso. La vecchia identità assume ora la gestione della posizione che il nodo 𝛽 mantiene in ''g''. La nuova identità assume la gestione della posizione nuova che il nodo 𝛽 prende in ''h''. Il controllo delle interfacce di rete che prima erano gestite dalla vecchia identità passa ora alla nuova identità. La vecchia identità gestisce ora le pseudo-interfacce create prima, le quali infatti sono temporanee. Gli archi che erano gestiti dalla vecchia identità rimangono gestiti dalla vecchia identità. Non cambia il loro ''identificativo di arco'', che come sappiamo è un concetto interno al modulo QSPN e di cui il suo utilizzatore non si deve occupare. Per ognuno di questi archi, però, cambia l'interfaccia di rete su cui è appoggiato l'arco nel nodo 𝛽 e il relativo indirizzo IP link-local. Infatti ora la vecchia identità gestisce le pseudo-interfacce create prima, con i loro indirizzi IP link-local. Per quanto riguarda l'interfaccia di rete su cui è appoggiato l'arco nel vicino 𝛾 all'altro estremo, qualora a migrare è un intero g-nodo e il vicino 𝛾 ne fa parte, anch'essa diventa la nuova pseudo-interfaccia che anche il nodo 𝛾 ha creato, con il relativo indirizzo IP link-local. Altrimenti resta la stessa. Gli archi duplicati, invece, mantengono le interfacce di rete su cui sono appoggiati da entrambi gli estremi e i relativi indirizzi IP link-local. Quando tali archi sono passati alla nuova identità del modulo QSPN, ricevono anche un nuovo ''identificativo di arco'' ciascuno. === Motivazioni della pseudo-interfaccia di rete === Tutte le comunicazioni che i nodi si scambiano tra i moduli del demone ''ntkd'', sia quelle in UDP broadcast, sia quelle in UDP unicast, sia quelle in TCP, sono tali che il nodo che le riceve è in grado di identificare l'arco su cui sono state inviate (intendendo con ''arco'' in questo contesto quella entità logica che indica esattamente una specifica identità del nodo corrente e una specifica identità del nodo collegato). Inoltre le comunicazioni in broadcast contengono informazioni sufficienti a riconoscere quali identificativi di nodo devono considerarsi tra i destinatari del messaggio e quali invece devono ignorarlo. Consideriamo due nodi vicini, 𝛼 e 𝛽, collegati tra loro sopra un unico segmento di rete, cioè da un solo arco fisico. Supponiamo che entrambi abbiano due identità: 𝛼~-,,0,,-~, 𝛽~-,,0,,-~, 𝛼~-,,1,,-~ e 𝛽~-,,1,,-~. Le caratteristiche appena descritte fanno si che sia possibile per 𝛼~-,,0,,-~ inviare un messaggio a 𝛽~-,,1,,-~ e accertarsi che venga processato dalla giusta identità di 𝛽 e che questi sappia identificare la giusta identità di 𝛼 come mittente del messaggio. Inoltre è possibile per 𝛼~-,,0,,-~ scegliere di avere solo un arco verso 𝛽~-,,0,,-~ o solo un arco verso 𝛽~-,,1,,-~: in questi casi anche un messaggio broadcast può essere preparato in modo tale che solo la giusta identità di 𝛽 lo processi. In conclusione, i messaggi che due nodi vicini si scambiano tra i moduli del demone ''ntkd'' possono raggiungere la corretta identità dei nodi senza bisogno di creare nuove pseudo-interfacce di rete. Ma ci sono dei motivi per cui si rende necessario creare nuove pseudo-interfacce allo scopo di individuare la giusta identità del nodo alla quale è stato trasmesso un generico pacchetto IP da inoltrare. Si individuano questi motivi: * Corretto instradamento di pacchetti IP che hanno come destinazione un indirizzo ''interno'' ad un g-nodo. * Realizzazione di un circuito fisso tra due end-point, per lo sfruttamento dei percorsi disgiunti acquisiti. === Distinti stack di network === Quando un nodo 𝛽~-,,0,,-~ assume una identità aggiuntiva 𝛽~-,,1,,-~, oltre a creare delle pseudo-interfacce apposite coi loro nuovi indirizzi MAC, si crea un nuovo completo stack di network, o network namespace. Questo permette alle due distinte identità, le quali esistono in distinti g-nodi ''g~-,,0,,-~'' e ''g~-,,1,,-~'' di livello ''j'', di avere indirizzi IP ''interni'' al g-nodo di livello ''j'' che non si influenzino a vicenda. Un pacchetto IP che ha per destinazione un indirizzo IP ''interno'' al g-nodo ''g~-,,0,,-~'' può giungere al nodo 𝛽 attraverso una delle pseudo-interfacce di ''𝛽~-,,0,,-~''. Quindi sarà gestito dall'identità 𝛽~-,,0,,-~. Anche se l'identità 𝛽~-,,1,,-~ dovesse avere in ''g~-,,1,,-~'' lo stesso indirizzo IP ''interno'' che il pacchetto IP riporta come indirizzo destinazione (oppure sorgente) questo non interferirà con le operazioni che il network namespace di 𝛽~-,,0,,-~ porta avanti. == Passo 1 == Consideriamo un grafo connesso ''G'' = (''V'', ''E''). * ''V'' = {𝛼, 𝛽, 𝛾, 𝛿, 𝜇} * ''E'' = {𝛼-𝛽, 𝛽-𝛾, 𝛾-𝛿, 𝛿-𝜇} {{drawing:grafo1.adraw}} Ogni elemento di ''V'' è un nodo. Diciamo, per semplicità, che ogni nodo ha una interfaccia di rete, che chiamiamo "eth1". Immaginiamola come una interfaccia radio, nel senso che tramite essa il singolo nodo rileva soltanto gli altri nodi che sono sufficientemente vicini. Con questo intendo dire che, ad esempio, il nodo 𝛽 con la sua interfaccia "eth1" è direttamente collegato al nodo 𝛼 e al nodo 𝛾. Invece il nodo 𝛼 non è direttamente collegato al nodo 𝛾. Scriviamo l'elenco degli indirizzi link-local che i nodi si sono assegnati sull'interfaccia "eth1": * ''IP(''𝛼'',eth1)'' = 169.254.69.30 * ''IP(''𝛽'',eth1)'' = 169.254.96.141 * ''IP(''𝛾'',eth1)'' = 169.254.94.223 * ''IP(''𝛿'',eth1)'' = 169.254.253.216 * ''IP(''𝜇'',eth1)'' = 169.254.119.176 Ricordiamo l'elenco degli archi attualmente formatisi: * 𝛼-𝛽 * 𝛽-𝛾 * 𝛾-𝛿 * 𝛿-𝜇 Per ogni arco che realizza, inoltre, ogni nodo aggiunge una rotta verso i diretti vicini. Diamo questi comandi ai nodi: * nodo 𝛼 . {{{ ip link set eth1 up ip address add 169.254.69.30 dev eth1 ip route add 169.254.96.141 dev eth1 src 169.254.69.30 }}} * nodo 𝛽 . {{{ ip link set eth1 up ip address add 169.254.96.141 dev eth1 ip route add 169.254.69.30 dev eth1 src 169.254.96.141 ip route add 169.254.94.223 dev eth1 src 169.254.96.141 }}} * nodo 𝛾 . {{{ ip link set eth1 up ip address add 169.254.94.223 dev eth1 ip route add 169.254.96.141 dev eth1 src 169.254.94.223 ip route add 169.254.253.216 dev eth1 src 169.254.94.223 }}} * nodo 𝛿 . {{{ ip link set eth1 up ip address add 169.254.253.216 dev eth1 ip route add 169.254.94.223 dev eth1 src 169.254.253.216 ip route add 169.254.119.176 dev eth1 src 169.254.253.216 }}} * nodo 𝜇 . {{{ ip link set eth1 up ip address add 169.254.119.176 dev eth1 ip route add 169.254.253.216 dev eth1 src 169.254.119.176 }}} Proseguiamo con il [[../Step2|passo 2]]. |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step1.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step1"