|
⇤ ← Revision 1 as of 2015-12-18 09:16:29
Size: 2012
Comment:
|
Size: 5552
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| * ''E'' = {𝛼𝛽, 𝛽𝛾, 𝛾𝛿, 𝛿𝜇} | * ''E'' = {𝛼-𝛽, 𝛽-𝛾, 𝛾-𝛿, 𝛿-𝜇} |
| Line 12: | Line 12: |
| 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 è direttamente collegato al nodo 𝛼 e al nodo 𝛾. Invece il nodo 𝛼 non è direttamente collegato al nodo 𝛾. | 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 𝛾. |
| Line 14: | Line 14: |
| Ogni 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. | 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. * 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. 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. Quando due nodi duplicano un loro arco, operazione che i due nodi agli estremi di un arco esistente fanno di concerto, in realtà stanno costruendo il nuovo arco su una diversa identità per ogni nodo. 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 𝛽. 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. Sia un nodo 𝛽 che riceve un generico pacchetto IP (non prodotto dal demone ''ntkd'' ma da una qualunque applicazione) che deve inoltrare verso una certa destinazione 𝛾. Per il nodo 𝛽, identificare l'arco (ad esempio 𝛼-𝛽) su cui il pacchetto è stato ricevuto è più complesso. Sarebbe molto utile per poter poi basare il routing del pacchetto su questa informazione. Per ora resta un problema aperto. Scriviamo l'elenco degli indirizzi link-local che i nodi si sono assegnati: |
| Line 21: | Line 45: |
| Inoltre aggiunge una rotta verso i diretti vicini per ogni arco che ha realizzato. | Ricordiamo l'elenco degli archi attualmente formatisi: * 𝛼-𝛽 * 𝛽-𝛾 * 𝛾-𝛿 * 𝛿-𝜇 Per ogni arco che realizza, inoltre, ogni nodo aggiunge una rotta verso i diretti vicini. |
Modulo QSPN - Esempio di uso degli indirizzi virtuali
Passo 1
Consideriamo un grafo connesso G = (V, E).
V = {𝛼, 𝛽, 𝛾, 𝛿, 𝜇}
E = {𝛼-𝛽, 𝛽-𝛾, 𝛾-𝛿, 𝛿-𝜇}
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 𝛾.
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 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.
- 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.
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.
Quando due nodi duplicano un loro arco, operazione che i due nodi agli estremi di un arco esistente fanno di concerto, in realtà stanno costruendo il nuovo arco su una diversa identità per ogni nodo.
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 𝛽. 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.
Sia un nodo 𝛽 che riceve un generico pacchetto IP (non prodotto dal demone ntkd ma da una qualunque applicazione) che deve inoltrare verso una certa destinazione 𝛾. Per il nodo 𝛽, identificare l'arco (ad esempio 𝛼-𝛽) su cui il pacchetto è stato ricevuto è più complesso. Sarebbe molto utile per poter poi basare il routing del pacchetto su questa informazione. Per ora resta un problema aperto.
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 passo 2.