Free license available.

IP su ATM

di: Fabrizio Badini

NHRP

Come notato in precedenza, il limite del modello classico di IP su ATM (RFC 1577) risiede nella limitazione imposta dal passaggio attraverso i router di una LIS impedendo l'instaurarsi di "cut-through routes" (detti anche "short-cut") ovvero dei collegamenti diretti tra due host appartenenti alla stessa rete ATM ma non alla stessa LIS.

All'interno di IETF il gruppo ROLC (Routing Over Large Clouds) ha prodotto il protocollo Next Hop Routing Protocol NHRP con cui si intende risolvere il problema dell'assenza di cut-through routes.

NHRP è costruito a partire dal RFC 1577 sostituendo al concetto di LIS quello di LAG (Local Address Group) all interno di una Non Broadcast Multiple Access network (NBMA) cioè di una rete che non permette facilmente il broadcast o multicast pur permettendo l'interconnessione diretta degli host. Una singola NBMA network può essere divisa in domini amministrativi diversi (che vanno a coincidere con i LAG) ad esempio per implementare una politica di "firewalling" quindi come vedremo NHRP può essere applicato all'interno di un dominio amministrativo impedendo però l'interconnessione diretta di host in domini diversi. Per correttezza si deve dire che il termine LAG è stato introdotto dal RFC 1937 che parla genericamente di "Local/Remote forward decision in Switched Data Link subnetworks", in NHRP lo stesso concetto viene detto "Logical NBMA Subnetwork".

Al posto dell'ATMARP server si usa l'NHRP server (NHS). Ogni NHS mantiene una tabella con il mapping IP-ATM di tutti gli host raggiungibili direttamente (nel LAG) oppure attraverso router collegati al dominio gestito dallo stesso NHS. Ovviamente i nodi si devono registrare ad un NHS cui sono "di appartenenza" al momento del boot.

Gli NHS possono essere fatti in due modi:

Nella maniera "server" ogni NHS della NBMA è configurato staticamente (a mano) con gli indirizzi IP delle sottoreti servite da ognuno degli altri NHS della NBMA. E' una soluzione adeguata solo per reti piccole.
Nella maniera "fabric", invece, ogni NHS acquisce la conoscenza sugli host serviti dagli altri host mediante un protocollo di scambio dei dati tra gli NHS che utilizza le informazioni di NHRP Register (quando un host si registra presso il suo NHS) oppure mediante richieste NHRP Resolution (quando un host chiede un mapping IP-ATM). Inoltre, si assume che l'NHS che serve un particolare host sia posizionato lungo il percorso verso l'host stesso. Questo significa che ogni router sul bordo di un dominio deve anche essere un NHS ma sopratutto che le informazioni di mapping, come vedremo, passano indietro attraverso l'NHS che le ha chieste agli altri NHS, aggiornando così la propria cache.

Comunque il modo in cui gli NHS sono costituiti, server o fabric, è trasparente al protocollo NHRP e al modo in cui gli host risolvono i loro collegamenti. Il modo in cui funziona l'NHRP è il seguente: quando un host deve trasmettere un pacchetto e quindi ha necessità di risolvere un indirizzo IP formula la richiesta all'NHS da cui è servito. La richiesta è inviata nel payload di un pacchetto IP. Se l'NHS può risolvere direttamente l'indirizzo (ovvero il destinatario appartenga alla stessa LAG), ritorna al richiedente il mapping IP-ATM del destinatario. Se, invece, l'host destinatario non è situato all'interno della LAG servita, l'NHS invia la richiesta di mapping verso il prossimo NHS sul percorso verso il destinatario, da qui il nome di Next Hop (per capire qual'è il prossimo NHS verso il destinatario vedi dopo) . Si continua così finchè non si aariva all'NHS che risolve l'indirizzo il quale viene "ritornato" al richiedente sullo stesso percorso che unisce gli NHS coinvolti nella richiesta. Il motivo fondamentale per far ritornare indietro il mapping lungo lo stesso percorso è che, così facendo, gli NHS possono mettere nella loro cache questo mapping così da poterlo riusare da lì a breve se richiesto, ma sopratutto gli NHS aggiornano la conoscenza di quali sottoreti sono servite da quali NHS. Infatti gli NHS al boot sono configurati in modo da conoscere un solo NHS ma mentre funzionano accrescono la loro conoscenza topologica della rete.

Mentre l'NHRP lavora e prima di instaurare il collegamento diretto tra gli host, si possono mandare i pacchetti ad un router (che lavora come in RFC 1577) evitando così problemi di latenza, creando però un problema di assenza di ordinamento dei pacchetti. Da notare che una rete connection oriented non consegna mai i pacchetti in ordine sbagliato poichè tutti i pacchetti seguono lo stesso percorso mentre in questo caso, essendoci per costruzione due percorsi diversi (quello di connessione diretta e quello RFC 1577 per evitare la latenza), c'è la possibilità che i pacchetti arrivino in ordine errato e quindi si deve gestire questa situazione. E' vero che IP non garantisce l'ordinamento ma, spesso, applicazioni funzionanti su IP over ATM danno per scontato che venga garantito l'ordinamento.

Una caratteristica di NHRP è la necessità di fare il "detecting" di eventuali loop presenti nella rete NBMA poichè essendoci la possibilità di tali loops è necessario evitare che, soprattutto gli NHS si trovino in un loop mentre nel frattempo la rete usa l'RFC 1577, così che non si riesce ad instaurare una connessione diretta. Oppure gli NHS possono inviare pacchetti (e quindi fare da proxy router) qualora il destinatario finale non sia in grado di stabilire una connessione diretta.

Un altra capacità di NHRP è quella di supportare l'aggregazione di indirizzi, ovvero un NHS non ritorna solamente l'indirizzo dell'host con cui raggiungere il destinatario (ovvero se presente l'egress router che separa le NBMA dalle legacy LAN oppure un router di firewalling) bensì anche una "subnet mask" associata a quella sottorete informando così tutti gli NHS sul percorso della locazione di siti con uguale subnet mask trovata, evitando inutili queries da parte degli NHS per successive richieste di mapping su quella sottorete.

Abbiamo già detto che è facile implementare una politica di firewalling, basta ritornare anzichè il mapping dell'host appartenente ad una LAG, quello di un router che fà il firewall per quella sottorete, per completare il lavoro si devono installare NIC di ogni host della sottorete amministrativa della NBMA con un filtraggio a livello ATM per accettare solo connessioni provenienti dal firewall.

L'unico problema che sembra porre NHRP è l'eventualità che, in alcuni casi ancorchè sporadici, si possa instaurare un loop, in collegamenti "cut-through" tra router, stabile; nel senso che il protocollo di routing (del livello IP es.EGP) non si accorga della presenza del loop. Questo è dovuto al fatto che i dati fluiscono su percorsi diversi rispetto alle informazioni di mapping le quali passano attraverso gli NHS e quindi reti (LAG) veramente adiacenti. Così i dati vengono passati in loop tra i router ma il protocollo di aggiornamento delle routing table non vede il loop in quanto non considera i router adiacenti come non considera adiacenti gli NHS che fanno capo ai router in questione. ATMForum ha risolto il problema dando la possibilità ad un NHS di interferire con il lavoro di un router. Quando un NHS scopre che un cambiamento nella topologia della rete (ovviamente topologia virtuale essendoci solo virtual connetion) può aver invalidato le tabelle di routing a tal punto da creare un loop, invia un messaggio di "purge" ai router coinvolti così che essi cancellino le loro tabelle e le ricostruiscano ex-novo.