Free license available.

IP su ATM

di: Fabrizio Badini

Classic IP over ATM

La prima proposta per la risoluzione del problema: "come trasportare IP su di una rete ATM funzionante in modo nativo" è stata formulata nel RFC 1577. Il trasporto di IP su ATM coinvolge due aspetti:

L'incapsulamento del pacchetto IP all'interno del frame AAL/ATM
La risoluzione degli indirizzi

Inoltre IETF ha definito che sia AAL5 l'adaptation layer da usare in quanto può fornire servizi ABR ed UBR proprio come una rete best effort. E' da notare che, benché AAL5 possa trasportare frame sino ad 65536 byte, RFC 1577 e le successive specifiche hanno stabilito una MTU di 9180 byte su reti ATM per fornire una compatibilità con reti Switched Multimegabit Data Service (SMDS).

Incapsulamento

Come nel caso del LANE, ci sono vantaggi nel mantenere aperte le connessioni e nel riusarle, diminuendo i tempi di latenza dovuti all'instaurazione di una connessione (connection re-use). Però ciò comporta che il livello di rete conosca "cosa" gli arriva su di una particolare connessione.

Il frame prodotto da AAL5 non presenta, nel trailer che lo identifica al livello trasporto prima di essere diviso in celle al livello ATM, alcuna informazione di tipo così che se tra due host vi è un canale su cui vengono multiplexate più connessioni di protocolli trasporto diversi (es. IP ed IPX), dalla osservazione del frame AAL5 è impossibile risalire al protocollo usato. Per risolvere questo problema esistono due strade alternative:

Ci si accorda a priori che tra due host un Virtual circuit venga usato solamente per un tipo di protocollo: il vantaggi risiede nella velocità ottenuta perché si salta uno strato in cui si deve riconoscere il protocollo, lo svantaggio è l'inutile crescita delle connessioni aperte.
Ci si accorda a priori che alcuni bit del payload AAL5 siano usati per identificare il protocollo: il vantaggio consiste nel risparmio del numero di connessioni, lo svantaggio nella necessità di un layer che riconosca questi bit necessari all'identificazione della connessione.

IETF non ha imposto una delle due tecniche ma ha lasciato liberi gli host di scegliere di volta in volta il tipo di sistema usato per il riconoscimento.

Nel caso in cui si usano dei bit del payload AAL5 parliamo di LLC/SNAP encapsulation (Logical Link Control/SubNetwork Attachment Point standard IEEE 802.2). E' un particolare header che precede il pacchetto IP in cui il campo LLC (3 byte) ed il campo SNAP (5 byte) specificano il protocollo usato.

Ad esempio per IP l'LLC/SNAP vale, in esadecimale, AA AA 03 00 00 00 08 00.

Risoluzione degli indirizzi

In una rete non-broadcast come ATM non è possibile effettuare un broadcast per trasmettere un pacchetto ARP e risolvere, sia pure attraverso alcuni router, l'indirizzo a cui trasmettere per il "next hop" verso l'host finale. La presenza di permanent VCI/VPI complica ancor di più questo problema poiché queste connessioni sono fatte "a mano" cosicché il software è all'oscuro del mapping IP - VCI/VPI.

L'RFC 1577 risolve questo problema introducendo il concetto di Logical IP Subnet (LIS). Una LIS è caratterizzata dalle seguenti proprietà:

tutti i membri di una LIS condividono lo stesso numero di sottorete IP
tutti i membri di una LIS sono connessi direttamente sulla NBMA
gli host o i router al di fuori della LIS (es. connessi ad una legacy LAN) sono accessibili tramite uno o più router.
i membri di una LIS si connettono direttamente tra loro

Quindi è esattamente una sottorete dal punto di vista IP solo che è costituita da host che appartengono tutti alla stessa rete ATM. Ogni LIS si comporta come una LAN che ha un router (ovvero un host che fa parte di più LIS); è per questo che RFC 1577 viene detto Classical IP in quanto ricostruisce il comportamento di IP su una rete classica.

E' da notare che host su due LIS diverse non possono comunicare direttamente nonostante facciano parte della stessa rete ATM e tra di loro si possa instaurare una connessione diretta. Si deve passare per forza attraverso i router e questo è il grande limite di RFC 1577.

Uno dei motivi per dividere una rete ATM in LIS è il limite fisico nella memoria riservata, in ogni host e soprattutto negli switch, per il numero di connessioni contemporaneamente aperte. Come abbiamo già detto, poiché è dispendioso aprire una connessione, si tende a riusare connessioni già aperte a scapito però della memoria in ogni nodo della rete. Se però dividiamo una rete in sottoreti il numero di connessioni si abbassa per forza.

Per risolvere il problema del "binding" dell'indirizzo IP con indirizzo ATM, all'interno di ogni LIS vi è un ATMARP server che tiene traccia del mapping IP address - ATM address. Esso viene interrogato da ogni host come un normale ARP; si chiama l'ATMARP server (cui ci si connette in fase di boot su di un VCI/VPI fisso) e si chiede il mapping.

Al contrario di un normale ARP, in cui si può avere risposta positiva oppure non si ha risposta (gli host su di una rete classica come Ethernet devono stare "silenziosi" perché la richiesta di ARP arriva a tutti e un nodo non può sapere se qualcuno risponderà prima di lui poiché la sua conoscenza della rete è limitata) un ATMARP server può dare risposte positive o negative (in quanto se non riesce a fare il mapping lui, nessun altro nella LIS è in grado di farlo per cui può rispondere negativamente essendo sicuro che tutti aspettano la sua risposta).

Routing e risoluzione di indirizzi all'interno di una LIS

Routing tra varie LIS

L'ATMARP server raccoglie informazioni sul suo data base ogniqualvolta un host fa una richiesta di mapping poiché è tenuto a specificare il suo mapping IP-ATM address.

Nel caso di circuiti permanenti si è introdotto il concetto di Inverse ATMARP, ovvero un host da una parte del Permanent VC, invia dall'altra parte una richiesta di mapping senza sapere nulla di cosa vi possa essere dall'altra parte. L'inverse ATMARP è anche usato dall'ATMARP server per aggiornare periodicamente il suo data base (infatti ogni host deve essere sempre connesso attraverso un VC all'ATMARP server e quest'ultimo può inviare sulla connessione i pacchetti che vuole).