[successivo] [precedente] [indice]

Routing Information Protocol

Il protocollo RIP e'un tipico esempio di protcollo Distance Vector, progettato come protocollo interno ad un sistema autonomo.

Il documento di riferimento e'RFC1058.

Nonostante le sue debolezze, RIP e'uno dei protocolli di routing piu'diffusi, e ne esiste ora una Versione 2 (RFC1338).

Le principali caratteristiche di RIP sono:

Formato del Messaggio

La testata del messaggio e' a 32 bit e contiene un byte di Comando e un byte di Versione. Correntemente le versioni possibili sono la 1 e la 2. Il byte di comando ha il valore 1 per una richiesta e 2 per un responso.

Segue una serie di record di descrizione di una stazione raggiungibile, ciascuno di 5 parole. Il campo Identificativo Famiglia Indirizzi era stato pensato originariamente per poter usare questo formato messaggio anche con XNS o X.25. In pratica RIP usa solo l'identificativo 2 per IP e ignora gli altri.

Il campo Indirizzo IP e' seguito da due campi a zero e dal campo Metrica, espressa in numero di salti e con valore compreso tra 0 e 16.

Protocollo

L'operazione normale e' l'invio di messaggi di responso in modo broadcast a intervalli regolari di 30 secondi o in seguito a richieste di aggiornamento.

Alla ricezione di un responso un router tenta di aggiornare la sua tabella di routing, che contiene i campi:

Il processamento avviene con le regole tipiche dei protocolli Distance Vector. Se un record e' stato modificato, viene settato il flag di modifica recente e fatti partire due temporizzatori: record recente e record valido.

Un record non piu' recente viene aggiornato anche se la sua metrica e' uguale a quella del messaggio di responso pervenuto: il record e' rinfrescato. I record di validita' scaduta vengono scartati.

Quindi viene preparato un messaggio di responso per ciascuna delle interfacce presenti; questo richiede un certo tempo di processamento per l'orizzonte diviso e il responso avvelenato.

Se il messaggio e' a intervalli normali e' completo, cioe' vengono trasmesse informazioni su tutti i vettori distanza di cui si e' a conoscenza. Se inveve e' inviato in seguito ad una richiesta di aggiornamento, contiene solo i vettori richiesti.

I messaggi di richiesta sono di due tipi: parziale o totale.

Una richiesta parziale contiene una lista di indirizzi di cui si chiede la metrica di raggiungibilita'. Il rispondente invia un responso con esattamente la stessa lista, con ciascun record fornito di metrica, infinita se irraggiungibile. Per le richieste parziali il rispondente non applica processamento di orizzonte diviso o altri simili.

Una richiesta totale include una lista di un solo campo, con l'indirizzo posto a 0.0.0.0.

Spesso l'attivita' di RIP di manutenzione automatica delle tabelle di routing viene limitata o completata dall'amministratore di sistema con configurazione manuale. RIP viene disabilitato su interfacce con un solo router, interfacce non broadcast o interfacce con limitazioni di sicurezza.

RIP Versione 2

La Versione 2 di RIP ha compatibilita' messaggio e protocollo all'indietro con la versione 1 e risolve o mitiga qualche tipico problema, pur rimanendo costretta dall'algoritmo Vector Distance. E' descritta in RFC1388.

Il messaggio include alcuni campi aggiuntivi ove prima vi erano degli zeri.

Il campo Dominio di Routing e' usato in congiunzione al campo Prossimo Salto per permettere a piu' sistemi autonomi di essere presenti sullo stesso cavo fisico. In realta' e' una eventualita' molto remota.

La Maschera di Sottorete permette una definizione migliore del routing di sottorete.

Autenticazione

RIP-2 prevede una procedura di autenticazione dei pacchetti. Il primo record di un messaggio puo' essere rimpiazzato da un segmento di autenticazione.

L'Identificativo di Famiglia in questo caso e' 0xFFFF. Il campo Autenticazione contiene una password in chiaro. Questo non e' gran che come metodo di autenticazione, ma vi era la costrizione di mentenere la compatibilita' all'indietro del formato messaggio, e non vi erano altri campi disponibili.

Multicasting

Il multicasting di RIP-2 e' ottenuto semplicemente trasmettendo all'indirizzo di destinazione 224.0.0.9. Non vie' bisogno del protocollo IGMP, poiche' i messaggi RIP-2 sono semplicemente inviati su tutte le reti direttamente connesse, ai router vicini, e non richiedono forwarding.

Poiche' i router con versione vecchia RIP-1 non capirebbero i messaggi con multicasting, la specifica di RIP-2 prevede un periodo di transizione di lunghezza non specificata in cui i messaggi vengono semplicemente trasmessi in modalita' broadcast.

Sincronizzazioni

RIP soffre di un effetto comune anche ad altri protocolli di routing: la tendenza col tempo a sincronizzare il momento di invio di messaggi normali di aggiornamento, nonostante inizialmente siano inviati ad intervalli casuali.

L'effetto e' causato dal verificarsi ogni tanto di collisioni o perdite di pacchetti IP prolungate, che suscitano una richiesta di aggiornamento a RIP e un azzeramento del temporizzatore di aggiornamenti normali. L'effetto tende a propagarsi rapidamente ai router vicini finche' tutti i router sono in sincronia, con picchi improvvisi di traffico sulla rete.

La soluzione e' di randomizzare l'invio di aggiornamenti regolari da un minimo di 15 a un massimo di 45 secondi, che mantiene la stessa frequenza media di aggiornamento.

Acknowledged Updates

Su reti non broadcast come X.25 o ISDN, ove tipicamente la fatturazione e' a traffico, messaggi di aggiornamento regolari non sono desiderabili.

Una proposta di estensione a RIP prevede il solo uso di aggiornamenti a richiesta e suggerisce di introdurre nuovi comandi per Richieste a Sollecito, Conferme a Sollecito e Responsi a Sollecito.

Vengono introdotti pero' effetti strani e complicazioni:

Supporto di Metriche Multiple

E' spesso proposto di cambiare il significato di metrica ad includere la velocita' del collegamento oltre che il numero di salti. Con un intervallo di valori di metrica da 0 a 16 una mappatura lineare di classi di velocita' non e' possibile.

E' stata proposta l'introduzione di una scala logaritmica. La metrica avrebbe due componenti: numero di salti e banda passante. Quest'ultima sarebbe definita come 10 per il logaritmo decimale della velocita' di trasmissione in kilobit al secondo.

Vi sono anche altre proposte, ma il tutto e' ben lontano da decisioni finali.

Risoluzione Loop

In caso di formazione di loop un algoritmo di Distance Vector inizia a "contare ad infinito". Per esempio, con un loop a tre stazioni, l'incremento di metrica e' di tre punti per ogni aggiornamento a sollecito, con un intervallo casuale tra 1 e 5 secondi. Per arrivare ad infinito (16) servono 5 cicli di aggiornamento, per un tempo totale per tre stazioni tra i 15 e i 75 secondi. Visto che vi sara' congestione nel loop in questo tempo, il periodo di convergenza puo' essere ulteriormente e notevolmente allungato.

Una soluzione proposta e' quella detta "Source Tracing" ed implica l'aggiunta di un campo di Primo Salto sia alla tabella di routing che ai messaggi di aggiornamento.

Il primo salto e' posto inizialmente a 0. Quando un router B riceve da un router A un messaggio di aggionamento in cui un record ha campo primo salto a 0, allora B pone l'indirizzo di A nel campo primo salto. Se il campo primo salto e' diverso da zero non viene modificato.

Quando l'informazione di routing viene a tornare ad A dopo la formazione di un loop, la stazione A ha modo di accorgesi del loop, poiche' il campo primo salto coincide col suo proprio indirizzo.

Naturalmente l'estensione Source Tracing non e' facilmente implementabile in una rete ormai molto complessa e ben assestata.