|
Size: 6008
Comment:
|
← Revision 6 as of 2016-07-27 10:29:36 ⇥
Size: 111
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Modulo QSPN - Esempio di uso degli indirizzi virtuali = == Passo 7 == In questo passo simuliamo l'ingresso di un nuovo nodo che forza la migrazione del g-nodo di livello 1 [1, 1] nel g-nodo di livello 2 [0], 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. {{drawing:grafo8.adraw}} Il nuovo nodo si assegna questo indirizzo link-local: * 𝜆 = 169.254.109.22 Si aggiunge questo arco all'elenco: * 𝜀-𝜆 Diamo questi comandi ai nodi: * nodo 𝜀 . {{{ ip r add 169.254.109.22 dev eth1 src 169.254.163.36 }}} * nodo 𝜆 . {{{ ip l set eth1 up ip a add 169.254.109.22 dev eth1 ip r add 169.254.163.36 dev eth1 src 169.254.109.22 }}} Il nodo 𝜆 vuole fare da gateway per una sottorete di due nodi gestita autonomamente. Quindi vuole riservarsi un g-nodo di livello 1. Al livello più alto la rete è satura, non si può costituire un nuovo g-nodo di livello 2. Il nodo 𝜆 vuole entrare in g~-,,2,,-~(𝜀) = [1] ma è saturo. Come soluzione si sceglie di far migrare tutto il g-nodo 𝜑 = g~-,,1,,-~(𝜀) = [1, 1] in [0], ma che resti come virtuale in [1]. I due g-nodi di livello 2 interessati dalla migrazione di 𝜑 sono stati evidenziati nel disegno e contrassegnati con le lettere ''M'' e ''N''. Si noti che il livello più alto in cui i due g-nodi ''M'' e ''N'' differiscono è 2. Il g-nodo 𝜑 migra in una operazione atomica, cioè tutti i suoi nodi migrano insieme, senza attendere l'uno le operazioni dell'altro. Alcune operazioni sulle proprie strutture dati interne le faranno tutti i nodi. Alcuni comandi per il sistema operativo andranno dati su tutti i nodi. Le trasmissioni di ETP dovute ai cambi di indirizi di 𝜑 invece le faranno solo i border-nodi e le comunicheranno solo all'esterno. Le richieste di un ETP completo le faranno solo i border-nodi ai nodi esterni. Con gli ETP ricevuti i border-nodi acquisiranno nuovi percorsi e propagheranno ai nodi interni questi percorsi con ETP che viaggeranno solo internamente. Procediamo. Il g-nodo 𝜑 trasforma il suo precedente indirizzo [1, 1] in un indirizzo ''di connettività'' ai livelli da 2 a 2, cambiando il suo identificativo al livello 1 nel primo identificativo ''virtuale'' libero nel g-nodo di livello 2 [1], cioè 2. Quindi diventa [2, 1], che è ''virtuale'' al livello 1. In realtà questa operazione la fanno i singoli nodi che costituiscono 𝜑. Si noti che 𝜑 = {𝛽~-,,i(1,2),,-~, 𝛾, 𝜀} e in particolare 𝛽~-,,i(1,2),,-~ è un indirizzo ''di connettività'' ai livelli da 1 a 2. Esaminiamoli uno alla volta. Il nodo 𝛽~-,,i(1,2),,-~ trasforma il suo precedente indirizzo ''virtuale'' al livello 0 e ''di connettività'' ai livelli da 1 a 2 [2, 1, 1], in un indirizzo sempre ''di connettività'' ai livelli da 1 a 2, cambiando il suo identificativo al livello 1 nell'identificativo scelto prima, cioè 2. Quindi diventa [2, 2, 1], che è ''virtuale'' al livello 0. Il nodo 𝛽~-,,i(1,2),,-~ aveva un indirizzo ''virtuale'' al livello 0, quindi non si era assegnato nessun indirizzo IP. Perciò non è necessario dare comandi per la rimozione dell'indirizzo. ~-'''Nota:''' Se si adottano anche gli indirizzi interni ai g-nodi, un indirizzo ''virtuale'' al livello ''i'' ma non ai livelli inferiori ha ''i'' indirizzi interni; quindi se diventa poi ''virtuale'' al livello ''j'' con ''j'' < ''i'' deve rimuovere ''i'' - ''j'' indirizzi. Nel nostro caso nessuno.-~ Ricordiamo inoltre che 𝛽~-,,i(1,2),,-~ aveva un indirizzo ''di connettività'' ai livelli da 1 a 2. Invece, per quanto riguarda gli indirizzi assegnati a sé, il nodo guarda solo il proprio indirizzo ''definitivo'', cioè 𝛽~-,,B,,-~. Siccome 𝛽~-,,B,,-~ non è mutato ed è ''reale'', sappiamo che il nodo 𝛽 ha un indirizzo e non deve essere rimosso. Il nodo 𝛽~-,,i(1,2),,-~ assume in questo momento un indirizzo ''virtuale'' al livello 1. Questo significa che tutto il suo g-nodo di livello 1 ha assunto in questo momento un indirizzo ''virtuale'' al livello 1. Quindi tutte le destinazioni di livello inferiore (nel nostro caso solo il livello 0) diventano non più raggiungibili con un indirizzo IP. Perciò il nodo deve rimuovere tutte le rotte verso tali destinazioni. ~-'''Nota:''' Se si adottano anche gli indirizzi interni ai g-nodi, ...-~ Quindi diamo questi comandi: * nodo 𝛽: . {{{ ip r del 10.0.0.6/32 src 10.0.0.3 via 169.254.94.223 dev eth1 ip r del 10.0.0.7/32 src 10.0.0.3 via 169.254.163.36 dev eth1 }}} Il nodo 𝛾 trasforma il suo precedente indirizzo ''reale'' ''definitivo'' [0, 1, 1], in un indirizzo ''di connettività'' ai livelli da 2 a 2, cambiando il suo identificativo al livello 1 nell'identificativo scelto prima, cioè 2. Quindi diventa [0, 2, 1], che è ''virtuale'' al livello 1. Il nodo 𝜀 trasforma il suo precedente indirizzo ''reale'' ''definitivo'' [1, 1, 1], in un indirizzo ''di connettività'' ai livelli da 2 a 2, cambiando il suo identificativo al livello 1 nell'identificativo scelto prima, cioè 2. Quindi diventa [1, 2, 1], che è ''virtuale'' al livello 1. ~-'''Nota:''' Se si adottano anche gli indirizzi interni ai g-nodi, i nodi 𝛾 e 𝜀 avendo un indirizzo ''virtuale'' al livello 1 mantengono l'indirizzo interno al proprio g-nodo di livello 1. Con ciò, sebbene dopo queste prime operazioni non sarà temporaneamente possibile una comunicazione fra un nodo interno a 𝜑 e un nodo esterno a 𝜑, saranno invece possibili le comunicazioni tra due qualsiasi nodi interni a 𝜑, nel nostro caso 𝛾 e 𝜀, se utilizzano gli indirizzi interni. Ad esempio, una connessione TCP tra 𝛾 e 𝜀 che si apre prima di queste operazioni resta funzionante durante queste operazioni e anche dopo il loro completamento. Stessa cosa per una nuova connessione che si apre durante questo periodo.-~ |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloQspn/UsoIndirizziVirtuali/Step7.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloQSPN/Esempio1/Step7"