Modulo QSPN - Esempio di uso degli indirizzi virtuali

Passo 8

In questo passo assegnamo alle nuove identità in 𝜑_N, un indirizzo definitivo nel g-nodo N. Per l'esattezza gli assegnamo l'indirizzo virtuale [2, 0].

Nel disegno seguente gli archi che collegano nodi che ora fanno parte della rete non sono più tratteggiati.

Poiché i nuovi indirizzi definitivi sono virtuali al livello 1, la loro assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per i nodi in 𝜑_N, né di un indirizzo interno al livello 2. I nodi in 𝜑_N avevano già assegnato un indirizzo interno al livello 1.

Ora ogni border-nodo in 𝜑_N chiede un ETP completo ai vicini che non appartengono a 𝜑_N tramite i suoi archi e li processa con questo nuovo indirizzo. Grazie ad essi:

Il nodo 𝜀_N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝜀_N-𝛽_B.
Il nodo 𝜀_N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝜀_N-𝛽_B. Il percorso sarebbe 𝜀_N-𝛽_B-𝛾_i(2,2). Si tratta di un percorso che rimarrà valido per poco tempo in quanto l'arco 𝛽_B-𝛾_i(2,2) sparirà presto. Ma a quel punto potrà avvalersi di un altro percorso, 𝜀_N-𝛽_i(1,2),N-𝛾_N-𝛿 che verrà scoperto a breve.
Il nodo 𝛾_N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛾_N-𝛽_B.
Il nodo 𝛾_N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾_N-𝛿.

Quindi diamo questi comandi:

nodo 𝜀

ip route add 10.0.0.2/31 via 169.254.96.141 dev eth1
ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1
ip route add 10.0.0.4/30 via 169.254.96.141 dev eth1

nodo 𝛾

ip route add 10.0.0.2/31 via 169.254.96.141 dev eth1
ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1
ip route add 10.0.0.4/30 via 169.254.253.216 dev eth1

I border-nodi in 𝜑_N potrebbero anche chiedere un ETP ai vicini che appartengono a 𝜑_N, ma effettivamente non lo otterrebbero perché questi non hanno completato il loro bootstrap.

Invece bisogna notare che i nodi in 𝜑_N che non sono border-nodi, sebbene chiedano un ETP completo a tutti i loro vicini e non ne ricevono nessuno, non devono considerare fallito il loro ingresso nella rete. Tra l'altro essi hanno ricevuto dalla loro precedente identità alcuni percorsi verso g-nodi di livello inferiore a 1 (il livello della migrazione).

Poi i border-nodi in 𝜑_N avendo completato la fase di bootstrap ritrasmettono un ETP completo ai vicini. In questo modo le conoscenze riprendono a propagarsi sia ai nodi interni a 𝜑_N che al di fuori. Riassumiamo queste nuove conoscenze:

Il nodo 𝛽_B sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛽_B-𝜀_N.
Il nodo 𝛽_B sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛽_B-𝛾_N. Supponiamo che preferisca il precedente arco 𝛽_B-𝜀_N.
Per ora, siccome l'indirizzo di destinazione è virtuale, questo non comporta alcun comando.
Il nodo 𝛽_B sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽_B-𝛾_N. Già sapeva di poterlo fare passando per l'arco 𝛽_B-𝛾_i(2,2). Per ora non cambia la rotta che già aveva impostata.
Il nodo 𝛼 sa di poter raggiungere il g-nodo [2, 0] passando per l'arco 𝛼-𝛽_B.
Per ora, siccome l'indirizzo di destinazione è virtuale, questo non comporta alcun comando.
Il nodo 𝛿 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛿-𝛾_N. Già sapeva di poterlo fare passando per l'arco 𝛿-𝛾_i(2,2). Questo nuovo percorso è certamente migliore, quindi cambia la rotta che già aveva impostata.
Per quanto sopra, il nodo 𝛾_i(2,2) apprende il percorso verso il g-nodo [0] costituito dagli archi 𝛾_i(2,2)-𝛿-𝛾_N. Per ora tale percorso non migliora il vecchio 𝛾_i(2,2)-𝛽_B, quindi non cambia la rotta che già aveva impostata.
Per quanto sopra, il nodo 𝛽_{i(1,2),i(2,2)} apprende il percorso verso il g-nodo [0] costituito dagli archi 𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2)-𝛿-𝛾_N. Per ora tale percorso non migliora il vecchio 𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2)-𝛽_B, quindi non cambia la rotta che già aveva impostata. Tra l'altro il gateway sarebbe rimasto lo stesso.
Per quanto sopra, il nodo 𝜀_i(2,2) apprende il percorso verso il g-nodo [0] costituito dagli archi 𝜀_i(2,2)-𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2)-𝛿-𝛾_N. Per ora tale percorso non migliora il vecchio 𝜀_i(2,2)-𝛽_B, quindi non cambia la rotta che già aveva impostata.
Il nodo 𝛽_i(1,2),N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛽_i(1,2),N-𝜀_N.
Il nodo 𝛽_i(1,2),N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛽_i(1,2),N-𝛾_N. Supponiamo che preferisca il precedente arco 𝛽_i(1,2),N-𝜀_N.
Il nodo 𝛽_i(1,2),N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽_i(1,2),N-𝛾_N.
Il nodo 𝛽_i(1,2),N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛽_i(1,2),N-𝜀_N. Il percorso sarebbe 𝛽_i(1,2),N-𝜀_N-𝛽_B-𝛾_i(2,2). Supponiamo che preferisca il precedente arco 𝛽_i(1,2),N-𝛾_N.
Il nodo 𝜀_N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝜀_N-𝛽_i(1,2),N. Questo percorso di sicuro non è migliore di quello che già conosceva attraverso l'arco 𝜀_N-𝛽_B.
Il nodo 𝜀_N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝜀_N-𝛽_i(1,2),N. Per ora di sicuro il nodo preferisce il percorso che conosceva: 𝜀_N-𝛽_B-𝛾_i(2,2).
Il nodo 𝛾_N sa di poter raggiungere il g-nodo [1, 0] passando per l'arco 𝛾_N-𝛽_i(1,2),N. Per ora di sicuro il nodo preferisce il percorso che conosceva: 𝛾_N-𝛽_B.
Il nodo 𝛾_N sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾_N-𝛽_i(1,2),N. Il percorso sarebbe 𝛾_N-𝛽_i(1,2),N-𝜀_N-𝛽_B-𝛾_i(2,2). Supponiamo che preferisca il precedente arco 𝛾_N-𝛿.

Quindi diamo questi comandi:

nodo 𝛽

ip netns exec ntkv0 ip route add 10.0.0.2/31 via 169.254.163.36 dev ntkv0_eth1
ip netns exec ntkv0 ip route add 10.0.2.2/31 via 169.254.163.36 dev ntkv0_eth1
ip netns exec ntkv0 ip route add 10.0.0.4/30 via 169.254.94.223 dev ntkv0_eth1

nodo 𝛿

ip route change 10.0.0.0/30 via 169.254.94.223 dev eth1 src 10.0.0.5

Ora i border-nodi in 𝜑_N, avendo trasmesso i primi ETP e atteso qualche istante per la loro processazione da parte dei vicini, con le loro identità in 𝜑_i(2,2) rimuovono i loro archi con nodi che non appartengono al loro g-nodo di livello 2. Si ricordi infatti che il livello più alto in cui i due g-nodi M e N differiscono è 2. Quindi 𝜀_i(2,2) rimuove il suo arco con 𝛽_B e 𝛾_i(2,2) rimuove il suo arco con 𝛽_B.

Ricordiamo che:

Il nodo 𝛽_B conosce un percorso verso il g-nodo [1] per l'arco 𝛽_B-𝛾_N.
Il nodo 𝛾_i(2,2) conosce un percorso verso il g-nodo [0] per l'arco 𝛾_i(2,2)-𝛿.
Il nodo 𝛽_{i(1,2),i(2,2)} conosce un percorso verso il g-nodo [0] per l'arco 𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2).
Il nodo 𝜀_i(2,2) conosce un percorso verso il g-nodo [0] per l'arco 𝜀_i(2,2)-𝛽_{i(1,2),i(2,2)}.

Quindi diamo questi comandi:

nodo 𝛽

ip r change 10.0.0.4/30 via 169.254.94.223 dev eth1 src 10.0.0.3
ip route del 169.254.241.153 dev eth1 src 169.254.96.141
ip route del 169.254.24.198 dev eth1 src 169.254.96.141

nodo 𝜀

ip netns exec ntkv1 ip route change 10.0.0.0/30 via 169.254.42.4 dev ntkv1_eth1
ip netns exec ntkv1 ip route del 169.254.96.141 dev ntkv1_eth1 src 169.254.241.153

nodo 𝛾

ip netns exec ntkv1 ip route change 10.0.0.0/30 via 169.254.253.216 dev ntkv1_eth1
ip netns exec ntkv1 ip route del 169.254.96.141 dev ntkv1_eth1 src 169.254.24.198

Aggiorniamo il disegno.

Gli stessi border-nodi in 𝜑_N che hanno rimosso questi archi, ora comunicano le variazioni apportate alla loro mappa tramite un ETP agli altri vicini. Si aggiungono queste conoscenze:

Il nodo 𝛽_{i(1,2),i(2,2)} non ha più il percorso 𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2)-𝛽_B per raggiungere il g-nodo [0], ma solo 𝛽_{i(1,2),i(2,2)}-𝛾_i(2,2)-𝛿-𝛾_N. Dovrebbe cambiare la rotta che aveva impostata, ma il gateway rimane lo stesso quindi non darà alcun comando.

Non risultano necessari altri comandi.

Proseguiamo con il passo 9.