Differences between revisions 2 and 3

Modulo QSPN - Esempio di uso degli indirizzi virtuali

Passo 4

In questo passo assegnamo alla nuova identità di 𝛽, 𝛽_B, un indirizzo definitivo nel g-nodo g₁(𝛼). Per l'esattezza gli assegnamo l'indirizzo virtuale [2, 1, 0].

Nel disegno seguente gli archi di 𝛽_B con 𝛼 e 𝛾 non sono più tratteggiati in quanto 𝛽_B fa ora parte della rete.

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

Non ci sono, comunque, da fare nuove assegnazioni di indirizzi né di rotte verso nodi vicini.

Poiché il nuovo indirizzo definitivo di 𝛽_B è virtuale al livello 0, la sua assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per il nodo 𝛽, né di un indirizzo interno al livello 2, né di un indirizzo interno al livello 1.

Ora il nodo 𝛽_B chiede un ETP completo ai vicini tramite i suoi archi e li processa con questo nuovo indirizzo. Grazie ad essi:

Il nodo 𝛽_B sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛾-𝛽_B.
Il nodo 𝛽_B sa di poter raggiungere il nodo [0, 1, 0] passando per l'arco 𝛼-𝛽_B.

Quindi diamo questi comandi:

nodo 𝛽

ip route add 10.0.0.4/30 via 169.254.94.223 dev eth1
ip route add 10.0.0.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.2.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.1.0/32 via 169.254.69.30 dev eth1

Il nodo 𝛽_B avendo ora completato il suo bootstrap, comunica via ETP ai suoi vicini 𝛼 e 𝛾 tutti i percorsi che conosce. Quindi ora:

Il nodo 𝛼 sa di poter raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽_B.
Il nodo 𝛾 sa di poter raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽_B.

Sono due conoscenze nuove, ma che non cambiano il miglior percorso verso quelle destinazioni per 𝛼 e 𝛾. Quindi nessun comando verrà dato.

Inoltre ora:

Il nodo 𝛼 sa di poter raggiungere il nodo [2, 1, 0] passando per l'arco 𝛼-𝛽_B.

Anche questa è una conoscenza nuova, ma l'indirizzo di destinazione è virtuale. Quindi nessun comando verrà dato.

Ora che il nodo 𝛽_B ha trasmesso i suoi primi ETP ai diretti vicini 𝛼 e 𝛾, dopo aver atteso qualche istante per permettere la loro processazione da parte di 𝛼 e 𝛾, il nodo 𝛽_i(1,2) rimuove i suoi archi con nodi che non appartengono al suo g-nodo di livello 2. Si ricordi infatti che il livello più alto in cui i due g-nodi A e B differiscono è 2. Quindi 𝛽_i(1,2) rimuove il suo arco con il nodo 𝛼.

Questo fa si che il nodo 𝛼 non può più raggiungere il g-nodo [1] passando per l'arco 𝛼-𝛽_i(1,2). Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛼-𝛽_B.

Va quindi cambiata, dal nodo 𝛼, la rotta verso 10.0.0.4/30, sostituendo il gateway 𝛽_i(1,2) con 𝛽_B. Va poi rimossa, dal nodo 𝛼, la sua rotta verso 𝛽_i(1,2).

Va poi rimossa, dal nodo 𝛽, la rotta di 𝛽_i(1,2) verso 𝛼, e vanno rimosse o cambiate le rotte che eventualmente si appoggiavano su tale arco.

Quindi diamo questi comandi:

nodo 𝛼

ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.96.141 dev eth1
ip route del 169.254.27.218 dev eth1 src 169.254.69.30

nodo 𝛽

ip netns exec ntkv0 ip route del 10.0.0.0/30 via 169.254.69.30 dev ntkv0_eth1
ip netns exec ntkv0 ip route del 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218

Ora il nodo 𝛽_B, avendo rimosso un suo arco, comunica le variazioni apportate alla sua mappa tramite un ETP agli altri vicini. Quindi il nodo 𝛾, al ricevere tale ETP, sa che non può più raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽_i(1,2). Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛾-𝛽_B. Va quindi cambiata, dal nodo 𝛾, la rotta verso 10.0.0.0/30, sostituendo il gateway 𝛽_i(1,2) con 𝛽_B.

Quindi diamo questi comandi:

nodo 𝛾

ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.96.141 dev eth1

Riassumiamo l'elenco degli archi ora presenti e il grafo che descrive la rete.

𝛼-𝛽_B
𝛾-𝛽_B
𝜀-𝛽_B
𝛾-𝛽_i(1,2)
𝛾-𝛿
𝛿-𝜇
𝜀-𝛽_i(1,2)

Temporaneamente, il nodo 𝛽 non è in grado di comunicare con gli altri nodi della rete in quanto ha solo indirizzi virtuali al livello 0. Nonostante questo, il nodo è perfettamente in grado di inoltrare pacchetti provenienti da altri nodi e destinati ad altri nodi nella rete. Quindi sebbene 𝛽 sia un nodo punto di articolazione, il grafo resta connesso.

Proseguiamo con il passo 5.

Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step4 (last edited 2016-07-27 10:28:50 by lukisi)

-  ⇤ ← Revision 2 as of 2015-12-27 15:47:08 → 
  Size: 4840
  Editor: lukisi
  Comment:
+   ← Revision 3 as of 2016-01-06 16:03:42 → ⇥
  Size: 5440
  Editor: lukisi
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 4:
-In questo passo aggiungiamo un nuovo nodo al g-nodo g~-,,1,,-~(𝛼).
+In questo passo assegnamo alla nuova identità di 𝛽, 𝛽~-,,B,,-~, un indirizzo ''definitivo'' nel g-nodo g~-,,1,,-~(𝛼). Per l'esattezza gli assegnamo l'indirizzo ''virtuale'' [2, 1, 0].
 Line 6:
-Il nuovo indirizzo ''virtuale'' ''definitivo'' [2, 1, 0] viene assegnato a 𝛽. Quello che si forma è un nodo completamente nuovo, che si assegna a caso un nuovo identificativo, chiamiamolo 𝛽~-,,B,,-~, mantenendo comunque lo stesso indirizzo link-local che aveva prima.

Ad esso si associa un nuovo fingerprint, una nuova mappa dei percorsi vuota e un nuovo set di archi.

La duplicazione di un arco esistente tra due nodi è una operazione che i due nodi eseguono in accordo, dialogando tra loro tramite il vecchio arco. Ad esempio, tramite l'arco 𝛼-𝛽~-,,i(1,2),,-~ il nodo 𝛽~-,,i(1,2),,-~ comunica a 𝛼 di avere una nuova identità: 𝛽~-,,B,,-~. Quindi i due nodi realizzano il nuovo arco 𝛼-𝛽~-,,B,,-~.

Nel disegno seguente evidenziamo in rosso gli elementi nuovi.
+Nel disegno seguente gli archi di 𝛽~-,,B,,-~ con 𝛼 e 𝛾 non sono più tratteggiati in quanto 𝛽~-,,B,,-~ fa ora parte della rete.
-Line 16:
+Line 10:
-Riassumiamo l'esito di queste operazioni di concertazione nel seguente elenco di tutti gli archi ora esistenti:
+Riassumiamo l'elenco di tutti gli archi ora esistenti coi relativi indirizzi IP link-local:
-Line 18:
+Line 12:
+ . 169.254.69.30-169.254.96.141
 * 𝛼-𝛽~-,,i(1,2),,-~
 . 169.254.69.30-169.254.27.218
-Line 19:
+Line 16:
+ . 169.254.94.223-169.254.96.141
 * 𝛾-𝛽~-,,i(1,2),,-~
 . 169.254.94.223-169.254.27.218
 Line 20:
- * 𝛼-𝛽~-,,i(1,2),,-~
 * 𝛾-𝛽~-,,i(1,2),,-~
+ . 169.254.163.36-169.254.96.141
 * 𝜀-𝛽~-,,i(1,2),,-~
 . 169.254.163.36-169.254.27.218
-Line 23:
+Line 24:
+ . 169.254.94.223-169.254.253.216
-Line 24:
+Line 26:
- * 𝜀-𝛽~-,,i(1,2),,-~
+ . 169.254.253.216-169.254.119.176
-Line 28:
+Line 30:
-L'assegnazione del nuovo indirizzo ''definitivo'' a 𝛽~-,,B,,-~ non comporta un comando di assegnazione di indirizzo per il nodo 𝛽, poiché anche questo indirizzo è ''virtuale'' al livello 0.

Il nodo 𝛽 segnala al suo utilizzatore che non espone più il percorso verso il g-nodo [0], che prima si raggiungeva passando per l'arco 𝛼-𝛽~-,,i(1,2),,-~.

Quindi diamo questi comandi:
 * nodo 𝛽
 . {{{
ip r del 10.0.0.0/30 via 169.254.69.30 dev eth1
}}}
+Poiché il nuovo indirizzo ''definitivo'' di 𝛽~-,,B,,-~ è ''virtuale'' al livello 0, la sua assegnazione non comporta un comando di assegnazione di indirizzo IP globale nella rete per il nodo 𝛽, né di un indirizzo ''interno'' al livello 2, né di un indirizzo ''interno'' al livello 1.
-Line 40:
+Line 34:
- . Questa destinazione però non sarà esposta dal modulo poiché si tratta del massimo distinto g-nodo di 𝛽~-,,i(1,2),,-~ per 𝛽~-,,B,,-~.
-Line 46:
+Line 39:
-ip r add 10.0.0.2/32 via 169.254.69.30 dev eth1
+ip route add 10.0.0.4/30 via 169.254.94.223 dev eth1
ip route add 10.0.0.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.2.2/32 via 169.254.69.30 dev eth1
ip route add 10.0.1.0/32 via 169.254.69.30 dev eth1
-Line 55:
+Line 51:
+Inoltre ora:
 * Il nodo 𝛼 sa di poter raggiungere il nodo [2, 1, 0] passando per l'arco 𝛼-𝛽~-,,B,,-~.

Anche questa è una conoscenza nuova, ma l'indirizzo di destinazione è ''virtuale''. Quindi nessun comando verrà dato.
-Line 59:
+Line 60:
-Andrebbe quindi cambiata, dal nodo 𝛼, la rotta verso 10.0.0.4/30. Ma cambiare da 𝛽~-,,i(1,2),,-~ a 𝛽~-,,B,,-~ è superfluo trattandosi del medesimo indirizzo link-local.
+Va quindi cambiata, dal nodo 𝛼, la rotta verso 10.0.0.4/30, sostituendo il gateway 𝛽~-,,i(1,2),,-~ con 𝛽~-,,B,,-~. Va poi rimossa, dal nodo 𝛼, la sua rotta verso 𝛽~-,,i(1,2),,-~.
-Line 61:
+Line 62:
-Andrebbe poi rimossa, dal nodo 𝛼, la sua rotta verso 𝛽~-,,i(1,2),,-~, ma poiché esso ha una rotta verso 𝛽~-,,B,,-~ che ha il medesimo indirizzo link-local non serve alcun comando.
+Va poi rimossa, dal nodo 𝛽, la rotta di 𝛽~-,,i(1,2),,-~ verso 𝛼, e vanno rimosse o cambiate le rotte che eventualmente si appoggiavano su tale arco.
-Line 63:
+Line 64:
-Andrebbe poi rimossa, dal nodo 𝛽, la rotta di 𝛽~-,,i(1,2),,-~ verso 𝛼, ma poiché 𝛽~-,,B,,-~, che è lo stesso nodo, ha una rotta verso 𝛼 non serve alcun comando.
+Quindi diamo questi comandi:
 * nodo 𝛼
 . {{{
ip route change 10.0.0.4/30 src 10.0.0.2 via 169.254.96.141 dev eth1
ip route del 169.254.27.218 dev eth1 src 169.254.69.30
}}}
 * nodo 𝛽
 . {{{
ip netns exec ntkv0 ip route del 10.0.0.0/30 via 169.254.69.30 dev ntkv0_eth1
ip netns exec ntkv0 ip route del 169.254.69.30 dev ntkv0_eth1 src 169.254.27.218
}}}

Ora il nodo 𝛽~-,,B,,-~, avendo rimosso un suo arco, comunica le variazioni apportate alla sua mappa tramite un ETP agli altri vicini. Quindi il nodo 𝛾, al ricevere tale ETP, sa che non può più raggiungere il g-nodo [0] passando per l'arco 𝛾-𝛽~-,,i(1,2),,-~. Però abbiamo detto prima che aveva appreso di poterlo fare passando per l'arco 𝛾-𝛽~-,,B,,-~. Va quindi cambiata, dal nodo 𝛾, la rotta verso 10.0.0.0/30, sostituendo il gateway 𝛽~-,,i(1,2),,-~ con 𝛽~-,,B,,-~.

Quindi diamo questi comandi:
 * nodo 𝛾
 . {{{
ip route change 10.0.0.0/30 src 10.0.0.6 via 169.254.96.141 dev eth1
}}}