|
|
Il fine di un protocollo di routine del tipo Link state è quello di adattare i routers alle modifiche della rete. Questo può essere fatto solo se il database di link state viene aggiornato dopo ogni modifica dello stato del link. Ad esempio analizziamo il seguente grafo delle reti:
Immaginiamo che il link 1 diventi indisponibile. I nodi A e B rileveranno il cambio di stato su questo link e dovranno quindi aggiornare, di conseguenza, i corrispondenti records nel database e inviarli a tutti gli altri nodi. Il protocollo da utilizzare per questo scopo dovrebbe essere veloce ed affidabile, ossia avere le caratteristiche di "flooding" (allagamento). Subito dopo aver rilevato la caduta del link 1, il nodo A invia al nodo D il seguente messaggio di aggiornamento sul link 3:
Da A, a B, link 1, distanza = infinita
il nodo D ritrasmetterà immediatamente il messaggio al nodo E sul link numero 6, per essere infine inviato a B sul link 4 e a C sul link 5. In effetti il messaggio sarà lievemente più complesso di quanto esposto. Se non venissero prese sufficienti precauzioni, potrebbe verificarsi che un vecchio messaggio torni indietro e comprometta il database. Per questo, ogni messaggio contiene un avviso dell'ora o un numero del messaggio che abilita il nodo in ricezione a distinguere le vecchie e le nuove informazioni. L'algoritmo flooding può quindi essere espresso molto semplicemente nel modo seguente:
Riceve il messaggio. Verifica la presenza del record nel database.
Se il record non e' presente lo aggiunge nel database e diffonde il messaggio.
Altrimenti, se il numero nel database e' minore del numero del messaggio, rimpiazza il record con il nuovo valore e diffonde il messaggio.
Altrimenti, se il numero nel database e' maggiore trasmette il valore del database in un nuovo messaggio, attraverso l'interfaccia di arrivo.
Altrimenti, se i numeri sono uguali, non fa nulla.
In questo algoritmo l'operazione di diffusione causerà la trasmissione del messaggio su tutte le interfacce ad eccezione di quelle di arrivo. Se assumiamo che il numero iniziale associato con il record del database era 1, il messaggio inviato da A sarà:
Da A, a B, link 1, distanza = infinita, numero = 2
D aggiornerà il proprio database e diffonderà il messaggio ad E che, a sua volta, aggiornerà il proprio database e invierà il messaggio a B e C, i quali aggiorneranno i loro records e tenteranno di inviare, a loro volta, i messaggi a C e B rispettivamente. Quando riceveranno il secondo messaggio C e B rileveranno che il numero e' uguale a quello nel database e quindi non ritrasmetteranno oltre. L'algoritmo flooding si ferma qui. Nello stesso tempo, B avrà trasmesso il nuovo stato del link 1 a C ed E:
Da B, ad A, link 1, distanza = infinita, numero = 2
Il protocollo provvederà ad aggiornare D e, di seguito, A e, quindi, saranno calcolati i nuovi percorsi. Il database dopo il flooding si presenterà dunque cosi:
Da |
A |
Link |
Distanza |
Numero |
A |
B |
1 |
Inf. |
2 |
A |
D |
3 |
1 |
1 |
B |
A |
1 |
Inf. |
2 |
B |
C |
2 |
1 |
1 |
B |
E |
4 |
1 |
1 |
C |
B |
2 |
1 |
1 |
C |
E |
5 |
1 |
1 |
D |
A |
3 |
1 |
1 |
D |
E |
6 |
1 |
1 |
E |
B |
4 |
1 |
1 |
E |
C |
5 |
1 |
1 |
E |
D |
6 |
1 |
1 |
Poiché l'obbiettivo e' quello di mantenere la rete operativa per un tempo molto lungo, può accadere che la sequenza dei numeri possa eccedere il numero di bit assegnati per la loro codifica nei pacchetti o nei record del database; normalmente i protocolli usano una numerazione circolare a 32 bit ma necessitano di una specifica convenzione al fine di definire con certezza quando un numero X e' più grande di un numero Y.
Tutto quanto riportato in questa pagina è a puro scopo informativo personale. Se non ti trovi in accordo con quanto riportato nella pagina, vuoi fare delle precisazioni, vuoi fare delle aggiunte o hai delle proposte e dei consigli da dare, puoi farlo mandando un email. Ogni indicazione è fondamentale per la continua crescita del sito.