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 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à 𝛼₁ che vuole collegare alla precedente identità di 𝛽.

• Il nodo 𝛼 ha creato una sua nuova identità 𝛼₁ e il nodo 𝛽 ha creato una sua nuova identità 𝛽₁ 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à: 𝛼₀, 𝛽₀, 𝛼₁ e 𝛽₁. Le caratteristiche appena descritte fanno si che sia possibile per 𝛼₀ inviare un messaggio a 𝛽₁ 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 𝛼₀ scegliere di avere solo un arco verso 𝛽₀ o solo un arco verso 𝛽₁: 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à 𝛼₁ 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à 𝛼₁ e il nodo 𝛽 ha creato una sua nuova identità 𝛽₁ 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, 𝛽₁, 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 𝛽₁ 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 = {𝛼-𝛽, 𝛽-𝛾, 𝛾-𝛿, 𝛿-𝜇}

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 passo 2.