|
|
I routers OSPF comunicano tramite il protocollo OSPF, che viene direttamente imbustato in IP (protocol type = 89) ed e', a sua volta, composto da 3 sotto-protocolli: Quest'ultimo, e' utilizzato per gli aggiornamenti di routing e per la gestione dell' "età" dei records del database. Tutti i pacchetti condividono un unico header comune.
Nel caso del "simple authentication", il campo Authentication prevede una password di 8 caratteri. L'amministratore di rete puo' definire una password diversa per ciascuna connessione punto-punto o per ciascuna rete. Nonostante non sia un ottimo metodo di autenticazione, questa e' comunque una buona garanzia contro possibili errori, ad esempio di configurazione. La procedura di "cryptographic authentication" ricorda molto la procedura di autenticazione del protocollo RIP; quando questa procedura viene utilizzata, gli 8 bytes del campo Authentication vengono ridefiniti per contenere una chiave, un campo lunghezza e un numero di sequenza. La chiave identifica la password segreta, utilizzata per la procedura di autenticazione e l'algoritmo di autenticazione. L'algoritmo standard e' denominato MD5; quando viene utilizzato questo algoritmo, il mittente calcola un checksum MD5 sulla concatenazione dei pacchetti OSPF, chiave segreta, campo lunghezza producendo un messaggio di sommario lungo 16 bytes. Questo messaggio viene appeso al pacchetto OSPF e viene considerato come un "rimorchio" e non una parte integrante del pacchetto: la sua lunghezza non viene inclusa nella lunghezza del pacchetto OSPF. Alla ricezione, il ricevente esegue lo stesso calcolo, basato sul segreto associato alla chiave e compara il risultato al sommario ricevuto; se i valori sono uguali, il pacchetto e' autentico, altrimenti il pacchetto verra' scartato.
Il protocollo "Hello" viene utilizzato per 2 scopi ben precisi:
I pacchetti "Hello" vengono trasmessi solo tra nodi vicini e mai propagati. Il campo "Type" dell'header comune vale 1 per questo protocollo. Il formato del pacchetto e' il seguente:
Per quanto concerne la verifica dell'operativita' del link, questo è dichiarato operativo se i pacchetti possono scorrere in entrambe le direzioni ed entrambi i router hanno lo stesso valore del bit E.
Quando due routers OSPF stabiliscono la connessione su di un link punto a punto, devono sincronizzare i propri database; sui link di una rete questo accade tra i routers ed il DR o il BDR. La sincronizzazione iniziale avviene tramite il protocollo "exchange"; di seguito sara' il protocollo flooding ad occuparsi di mantenere sincronizzati i database. Il protocollo Exchange e' asimmetrico; il primo step del protocollo consiste nel selezionare un "master" e uno "slave" e solo di seguito i due routers si scambieranno la descrizione dei propri database. A questo preciso scopo il protocollo utilizza il "Database Description Packet", di seguito riportato e per il quale il campo "Type" dell'header comune assume il valore 2:
I campi successivi (che possono essere ripetuti) sono la descrizione dell’header di un LSA, ed hanno quindi lo stesso significato.
Il router che vuole iniziare la procedura emette un pacchetto vuoto "Database Description" con I, M e MS settati ed il numero di sequenza settato ad un valore arbitrario. L’altro router risponde emettendo un pacchetto DD di "Acknowledgment", con lo stesso numero di sequenza ed i bit I ed M settati a 1 e MS a 0 (slave). Il primo router può quindi iniziare ad inviare le descrizioni da lui possedute ed emette pacchetti DD con I settato a 0, M ed MS settati ad 1 (eccetto M per l’ultimo pacchetto). I pacchetti saranno numerati in sequenza ed inviati uno alla volta. Lo slave risponde ad ogni pacchetto con un DD Acknowledgment che riporta la sua descrizione del database, caratterizzato dallo stesso numero di sequenza ma con il bit MS settato a 0. Se il master non riceve l’Ack entro un certo intervallo ri-invia il pacchetto originale DD. Se viceversa e' lo slave che non ha finito di trasmettere le sue descrizioni:
Durante lo scambio sia il master che lo slave controllano di avere l’LSA inviato dalla controparte, e questo non deve essere più vecchio di quello ricevuto. Se questo non è verificato, l’LSA viene inserito nella lista degli LSA da richiedere. Al termine della procedura di exchange la richiesta verra' effettuata tramite i pacchetti di Link State Request:
Questi pacchetti, identificati dal campo "Type" dell'header comune con il valore 3, vengono inviati alla fine dei DD se sono stati rilevati LSA da sincronizzare. Richiedono all’altro router di trasmettere il LSA completo corrispondente ai campi Link_State_Type, Link_State_ID e Advertising_Router indicati. Possono essere fatte piu' richieste insieme; i tre campi sopra elencati possono essere ripetuti piu' volte in un pacchetto OSPF. Gli LSA richiesti sono inviati attraverso il protocollo di flooding.
Il protocollo flooding viene utilizzato per diffondere (processo di forwarding) a tutta la rete il nuovo stato di un link. Questi aggiornamenti vengono inviati, attraverso il pacchetto di "Link State Update", nel caso di:
Il pacchetto "Link State Update", che caratterizza il campo "Type" dell'header comune con il valore 4, e' di seguito riportato:
Gli LSA del pacchetto Link State Update vengono normalmente riconosciuti, attraverso una conferma dell'avvenuta ricezione, con il pacchetto di Link State Acknowledgment, che caratterizza il campo "Type" dell'header comune con il valore 5, e che e' di seguito riportato:
Ciascun pacchetto di acknowledgment contiene una serie di campi con lo stesso formato del pacchetto di "database description" del protocollo di exchange. A tutti gli effetti, il Link State Advertisment (LSA) e' l'effettiva struttura dati che trasporta le informazioni ed e' la corrispondente del LSP visto per l'algoritmo teorico Link State. Per quanto concerne il funzionamento dell'algoritmo di flooding, si faccia riferimento alla sezione dedicata a questo preciso scopo, nella descrizione dell'algoritmo Link State.
|
0: No authentication
