|
Size: 8397
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 == Ogni nodo 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. Può succedere che un nodo assuma diverse identità. Ad esempio il nodo 𝛽 che era nel g-nodo ''g'' e migra in ''h'' vuole mantenere una identità in ''g'' e costituirne una nuova in ''h''. Allora per la nuova identità, quella in ''h'', il nodo si sceglie un altro identificativo casuale. Poi il nodo attiva la sua 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'indirizzo link-local di un nodo resta sempre quello. Quando il nodo assume una ulteriore identità continua comunque a comunicare con il medesimo indirizzo link-local; infatti ogni messaggio (del demone ''ntkd'') ricevuto contiene comunque informazioni sufficienti a individuare l'identità del nodo che la deve processare e l'identità dell'altro nodo che l'ha inviato. Dopo inizia la rilevazione di altri nodi nelle prossimità con cui formare un arco. Quando si forma un arco ognuno dei due nodi vertici lo rappresenta con una struttura dati che contiene: * Il nome dell'interfaccia di rete del proprio nodo su cui l'arco è costruito. Da qui, anche l'indirizzo MAC del proprio nodo. * L'indirizzo MAC dell'altro nodo. * L'identificativo del proprio nodo collegato all'arco. Questo serve perché un singolo nodo può avere diverse identità. * L'identificativo dell'altro nodo collegato all'arco. * L'indirizzo link-local dell'altro nodo. . L'indirizzo link-local del proprio nodo, ricordiamo, è fisso e vale per tutte le sue identità. Queste caratteristiche permangono per l'arco anche se, ad esempio, il nodo all'uno o all'altro capo migrando cambiasse il suo indirizzo (i suoi identificativi ai vari livelli) nella rete. Due nodi 𝛼 e 𝛽 vicini, i quali cioè hanno un arco che li collega, dialogando tra loro per mezzo di questo arco possono duplicarlo in una di queste forme: * Il nodo 𝛼 ha creato una sua nuova identità 𝛼~-,,1,,-~ che vuole collegare alla precedente identità di 𝛽. * Il nodo 𝛼 ha creato una sua nuova identità 𝛼~-,,1,,-~ e il nodo 𝛽 ha creato una sua nuova identità 𝛽~-,,1,,-~ e i due vogliono collegare queste due nuove identità. 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. 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. Da questo si evince che non c'è alcuna necessità per il nodo 𝛼 (o 𝛽) di "duplicare" la propria interfaccia di rete per duplicare efficacemente un suo arco allo scopo di trasmettere su di esso comunicazioni al demone ''ntkd''. Invece, se si tratta di duplicare un arco allo scopo di riconoscere la provenienza di un generico pacchetto IP, le cose sono diverse. Sia un nodo 𝛽 che riceve un generico pacchetto IP (non prodotto dal demone ''ntkd'' ma da una qualunque applicazione) dal nodo 𝛼. Il nodo 𝛽 sa qual'è l'interfaccia di rete ''n'' su cui lo ha ricevuto; inoltre analizzando il frame Ethernet che incapsula il pacchetto IP individua l'indirizzo MAC ''m'' del diretto vicino che lo ha trasmesso. Tramite ''n'' e ''m'' si può risalire ad uno specifico arco gestito dal modulo Qspn soltanto se l'indirizzo MAC ''m'' esiste ed è unico tra gli archi gestiti dal modulo Qspn con l'interfaccia ''n''. Quindi: * Se il nodo 𝛼 ha creato una sua nuova identità 𝛼~-,,1,,-~ che vuole collegare alla precedente identità di 𝛽: allora 𝛽 deve ricevere il pacchetto sulla sua interfaccia ''n'' e vedere in esso un indirizzo MAC ''m’'' distinto da ''m''. Quindi 𝛼 deve "duplicare" la propria interfaccia di rete. * Se il nodo 𝛼 ha creato una sua nuova identità 𝛼~-,,1,,-~ e il nodo 𝛽 ha creato una sua nuova identità 𝛽~-,,1,,-~ e i due vogliono collegare queste due nuove identità: allora 𝛽 deve ricevere il pacchetto sulla sua interfaccia ''n’'' distinta da ''n'' e vedere in esso un indirizzo MAC ''m’'' distinto da ''m''. Quindi 𝛼 e 𝛽 devono "duplicare" la propria interfaccia di rete. Abbiamo detto che un nodo 𝛽 che era nel g-nodo ''g'' e migra in ''h'' vuole mantenere la sua vecchia identità in ''g'' e costituirne una nuova, 𝛽~-,,1,,-~, in ''h''. Per far funzionare correttamente il lavoro del modulo Qspn su entrambe le identità è necessario che anche gli archi di 𝛽 vengano duplicati negli archi di 𝛽~-,,1,,-~ al fine di trasmettere su di essi comunicazioni al demone ''ntkd''. Ma quali sono i motivi per cui si rende necessario duplicare un arco allo scopo di riconoscere la provenienza di un generico pacchetto IP? 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 delle rotte disgiunte acquisite. == 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: * 𝛼 = 169.254.69.30 * 𝛽 = 169.254.96.141 * 𝛾 = 169.254.94.223 * 𝛿 = 169.254.253.216 * 𝜇 = 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 l set eth1 up ip a add 169.254.69.30 dev eth1 ip r add 169.254.96.141 dev eth1 src 169.254.69.30 }}} * nodo 𝛽 . {{{ ip l set eth1 up ip a add 169.254.96.141 dev eth1 ip r add 169.254.69.30 dev eth1 src 169.254.96.141 ip r add 169.254.94.223 dev eth1 src 169.254.96.141 }}} * nodo 𝛾 . {{{ ip l set eth1 up ip a add 169.254.94.223 dev eth1 ip r add 169.254.96.141 dev eth1 src 169.254.94.223 ip r add 169.254.253.216 dev eth1 src 169.254.94.223 }}} * nodo 𝛿 . {{{ ip l set eth1 up ip a add 169.254.253.216 dev eth1 ip r add 169.254.94.223 dev eth1 src 169.254.253.216 ip r add 169.254.119.176 dev eth1 src 169.254.253.216 }}} * nodo 𝜇 . {{{ ip l set eth1 up ip a add 169.254.119.176 dev eth1 ip r 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"