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

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 𝛽₀ assume una identità aggiuntiva 𝛽₁, 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₀ e g₁ 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₀ può giungere al nodo 𝛽 attraverso una delle pseudo-interfacce di 𝛽₀. Quindi sarà gestito dall'identità 𝛽₀. Anche se l'identità 𝛽₁ dovesse avere in g₁ 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 𝛽₀ porta avanti.

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