Modulo QSPN - Esempio di uso degli indirizzi virtuali

Passo 3

In questo passo simuliamo l'ingresso di un nuovo nodo che forza la migrazione di 𝛽 in g₁(𝛼), che è non saturo.

Ora nella rete si aggiunge il nodo 𝜀 collegato solo al nodo 𝛽. Esiste l'arco 𝛽-𝜀, ma tale arco non è ancora comunicato al modulo Qspn in quanto il nodo 𝜀 non fa ancora parte della rete.

Il nuovo nodo si assegna questo indirizzo link-local:

𝜀 = 169.254.163.36

Si aggiunge questo arco all'elenco:

𝛽-𝜀

Diamo questi comandi ai nodi:

nodo 𝛽

ip r add 169.254.163.36 dev eth1 src 169.254.96.141

nodo 𝜀

ip l set eth1 up
ip a add 169.254.163.36 dev eth1
ip r add 169.254.96.141 dev eth1 src 169.254.163.36

Al livello più alto la rete è satura, non si può costituire un nuovo g-nodo di livello 2. Il nodo 𝜀 può fare ingresso solo in g₂(𝛽) poiché il suo unico vicino è 𝛽. Ma questo è saturo. Anche g₁(𝛽) è saturo. Supponiamo che decida di entrare in g₁(𝛽) = [1, 1]. Come soluzione si sceglie di far migrare 𝛽 in g₁(𝛼) = [1, 0], ma che 𝛽 resti come virtuale in [1, 1].

I due g-nodi interessati dalla migrazione di 𝛽 sono stati evidenziati nel disegno e contrassegnati con le lettere A e B.

Si noti che il livello più alto in cui i due g-nodi A e B differiscono è 2.

Il nodo 𝛽 trasforma il suo precedente indirizzo reale globale [1, 1, 1], in un indirizzo interno ai livelli da 1 a 2, cambiando il suo identificativo al livello 0 nel primo identificativo virtuale libero. Quindi diventa [2, 1, 1], che è virtuale al livello 0.

Per indicare che questo nodo è interno ai livelli da 1 a 2 lo chiamiamo da ora in poi 𝛽_i(1,2). Per indicare che è virtuale disegnamo un cerchio vuoto.

Questo è a tutti gli effetti lo stesso nodo di prima. Ad esso si associa la mappa dei percorsi finora appresi da 𝛽 e il set di archi e il fingerprint che aveva prima. In particolare, il fatto che gli archi sono gli stessi che aveva prima, significa che, ad esempio, l'arco 𝛼-𝛽_i(1,2) è costituito dalla coppia di indirizzi link-local 169.254.69.30 - 169.254.96.141 che prima identificava l'arco 𝛼-𝛽.

Siccome l'indirizzo reale viene rimosso e il nodo detiene ora un indirizzo virtuale a livello 0, dobbiamo rimuovere l'indirizzo nella classe 10.0.0.0/8 dal nodo. Nota: Se si adottano anche gli indirizzi interni ai g-nodi, e si generalizza dicendo che l'indirizzo è virtuale al livello i, dovremmo aggiungere che vengono rimossi l'indirizzo globale e gli indirizzi interni ai propri g-nodi di livello maggiore di i, ma non quelli interni ai propri g-nodi di livello minore o uguale a i.

Per rimuovere un proprio indirizzo, prima vanno cambiate le rotte nella classe 10.0.0.0/8 che lo usavano come source preferito, "src", di modo da non avere più affatto un source preferito. Tali rotte infatti non serviranno più per i pacchetti originati dal nodo, ma sono valide per i pacchetti inoltrati. Per il momento il nodo non ha nessun indirizzo valido nella classe 10.0.0.0/8.

Quindi diamo questi comandi:

nodo 𝛽

ip r change 10.0.0.0/30 via 169.254.69.30 dev eth1
ip r change 10.0.0.4/31 via 169.254.94.223 dev eth1
ip r change 10.0.0.6/32 via 169.254.94.223 dev eth1
ip a del 10.0.0.7/32 dev eth1

Il nodo 𝛽_i(1,2) comunica via ETP ai suoi vicini 𝛼 e 𝛾 che non è più possibile raggiungere tramite lui l'indirizzo [1, 1, 1]; e che ora è possibile raggiungere tramite lui l'indirizzo [2, 1, 1].

Questo ETP viene recepito solo dai nodi del g-nodo di livello 1, trattandosi di due percorsi verso singoli nodi, cioè solo dal nodo 𝛾. Inoltre la comunicazione relativa all'indirizzo virtuale [2, 1, 1] viene recepita dal nodo 𝛾 ma non comporta alcun comando.

Quindi diamo questi comandi:

nodo 𝛾

ip r del 10.0.0.7/32 src 10.0.0.6 via 169.254.96.141 dev eth1

I percorsi che 𝛽 aveva pubblicizzati valgono ora per 𝛽_i(1,2). Non c'è bisogno che 𝛽_i(1,2) li trasmetta di nuovo. Questo significa che:

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

Proseguiamo con il passo 4.