Differences between revisions 1 and 2

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.

Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step8 (last edited 2016-07-27 10:29:58 by lukisi)

-  ⇤ ← Revision 1 as of 2016-01-10 18:00:16 → 
  Size: 5269
  Editor: lukisi
  Comment:
+   ← Revision 2 as of 2016-01-13 07:32:45 → ⇥
  Size: 9491
  Editor: lukisi
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 22:
+ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1
-Line 27:
+Line 28:
+ip route add 10.0.2.2/31 via 169.254.96.141 dev eth1
-Line 41:
+Line 43:
- * 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),,-~. Per ora non cambia la rotta che già aveva impostata.
+ * 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.
-Line 46:
+Line 51:
+ * 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,,-~-𝛿.
-Line 48:
+Line 57:
+ * 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
}}}
-Line 49:
+Line 68:
-'''TODO''' Riassumiamo l'elenco di tutti gli archi ora esistenti coi relativi indirizzi IP link-local:
 * 𝛼-𝛽~-,,B,,-~
 . 169.254.69.30-169.254.96.141
 * 𝛼-𝛽~-,,i(1,2),,-~
 . 169.254.69.30-169.254.27.218
 * 𝛾-𝛽~-,,B,,-~
 . 169.254.94.223-169.254.96.141
 * 𝛾-𝛽~-,,i(1,2),,-~
 . 169.254.94.223-169.254.27.218
 * 𝜀-𝛽~-,,B,,-~
 . 169.254.163.36-169.254.96.141
 * 𝜀-𝛽~-,,i(1,2),,-~
 . 169.254.163.36-169.254.27.218
 * 𝛾-𝛿
 . 169.254.94.223-169.254.253.216
 * 𝛿-𝜇
 . 169.254.253.216-169.254.119.176
+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.

{{drawing:grafo11.adraw}}

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 [[../Step9|passo 9]].