di Carmelo Nucera

SEGNALAZIONE ED INDIRIZZAMENTO IN UNA RETE ATM

La segnalazione su di un link ATM dipende dal tipo di "interfaccia" (UNI,NNI).

La standardizzazione da parte di ATM Forum è terminata solo per UNI (UNI 3.1) basato su Q.2931 di ITU-T basato a sua volta su Q.931, protocollo di segnalazione di ISDN. Questi protocolli fanno viaggiare i loro pacchetti in maniera "sicura" (garantendo cioè che non ci siano perdite di questi pacchetti come, d'altronde, deve essere per una cosa così importante come la segnalazione) basandosi su tecniche di ritrasmissione.

La tecnica ATM usa un meccanismo di instaurazione della comunicazione "un passo per volta", tipico di tutti i sistemi di telecomunicazione telefonica. La richiesta di connessione viene propagata attraverso la rete fino alla destinazione finale. E' da notare che il percorso che fa il traffico di segnalazione è il medesimo che poi farà il traffico utente.

La sequenza dei passi è la seguente:

• Un host invia un messaggio di Setup allo switch cui è connesso segnalando quale é l'host da raggiungere e quale é il QoS richiesto.
• Lo switch risponde con una procedura di Call Proceeding e chiama le funzioni di routing per determinare dove inoltrare (cioè a quale switch od host) la richiesta di connection setup.
• Una volta che l'ultimo switch ha comunicato la richiesta all'host finale, quest'ultimo può o meno accettare la connessione. Se la rifiuta invia indietro un Release altrimenti un Accept .

ATMForum in UNI 3.1 ha semplificato il Q.2931 ma ha anche aggiunto funzionalità proprie di ATM come la segnalazione per il point-to-multipoint e quella relativa all'aggiunta, ad una connessione point-to-multipoint già in atto, di un altra "foglia" ovvero di un altro host.

La caratteristica più importante di UNI 3.1 e che esso standardizza il formato degli indirizzi ATM. vediamo come.

L'ITU-T ha una sua struttura di indirizzi (simili ad un numero telefonico) nello standard E.164 scelto per la B-ISDN. ATMForum ha esteso E.164 poiché esso non é adatto ad un sistema privato.

Quando ATM Forum ha sviluppato questo sistema di indirizzamento ha valutato due approcci che differiscono nella maniera in cui l'indirizzamento ATM viene visto in relazione ai protocolli che usano ATM, come ad esempio IP. Questi protocolli hanno un proprio sistema di indirizzi e basandosi su questi le proposte si sono divise:

• Una scelta, cosiddetta peer model, era quella di usare lo stesso schema di indirizzamento di protocolli come IP per la rete ATM ovvero gli host ATM sarebbero stati identificati non con un proprio indirizzo bensì con l'indirizzo del protocollo che usava ATM. Questo significava semplificare la risoluzione degli indirizzi (necessaria ad es. in Ethernet con ARP) ma significava legare ATM ad IP nonché però la necessità di adottare tecniche di routing proprie di IP e quindi connectionless e slegate dalla realtà di ATM perché necessariamente "generiche" come lo é IP (non dovendo essere legato ad un particolare tipo di rete).



• La scelta alternativa cosiddetta overlay model era quella di creare un sistema di indirizzi proprio di ATM e quindi anche metodi di routing propri di ATM. Lo svantaggio in questo approccio risiede nella necessita di un sistema di risoluzione di indirizzi ma con il vantaggio di poter sfruttare tecniche di routing più moderne e più adatte ad una rete ATM.

Nonostante la apparente semplicità del primo approccio si è deciso di disaccoppiare gli indirizzamenti ed orientarsi su di un modello overlay perché in realtà così facendo si facilita l'introduzione di ATM non legandola ad alcun protocollo ed inoltre favorendo uno sviluppo indipendente rispetto ad IP (cosa che velocizzerà l'implementazione dei protocolli essendo del tutto nuovi). Il prezzo da pagare e la necessità di una risoluzione degli indirizzi IP nonché la possibilità che si vreifichi un routing subottimo end-to-end (ad esempio se la rete ATM cambia introducendo nuovi collegamenti, la rete IP che la sovrasta non necessariamente ne deve essere a conoscenza per cui utilizzerà le vecchie tabelle di routing potendo invece sfruttare nuovi link. Questa cosa non sarebbe successa se l'indirizzamento fosse stato IP perché cosi ogni cambiamento veniva posto a conoscenza del livello IP stesso).

La scelta di ATMForum è stata quella di basarsi su di una semantica di indirizza proposta dal ISO e cioè l'OSI Network Service Access Point (NSAP) però gli indirizzi proposti da ATMForum non sono propriamente NSAP, anche se noi d'ora in poi ci riferiremo ad essi con questo acronimo.

ATMForum ha proposto una forma per la codifica di indirizzi ITU-T E.164 all'interno di un indirizzo NSAP cosi da identificare un host al di fuori di una rete privata mentre ha scelto altre due forme per l'indirizzamento locale cosi da avere tre tipi di indirizzo NSAP

Tutti gli indirizzi NSAP sono costituiti da tre parti:

• AFI Authority and Format Identifier: identifica il tipo di indirizzo IDI (vedi sotto)
• IDI Initial Domain Identifier: identifica l'autorità che ha rilasciato quel tipo di indirizzo
• DSP Domain Specific Part: contiene le informazioni di routing vere e proprie ed e diviso in High Order DSP ed End System Identifier (il quale e simile al concetto di indirizzo MAC)

Nel formato NSAP Format E.164 l'IDI e un numero ITU-T. In DCC Format l'IDI e un Data Country Code che specifica il paese (specifica ISO 3166) rilasciato dal membro ISO del paese (in Italia l'UNI Ente Unificazione Normativa Italiana ) mentre in ICD Format l'IDI é un International Code Designator (specifica ISO 6523) rilasciato dal British Standard Institute e che serve per particolari organizzazioni internazionali.

L'ATMForum consiglia l'uso dei formati DCC o ICD per uso privato così da non sovrapporsi agli indirizzi degli operatori pubblici che usano E.164. Un'organizzazione che vuole un proprio indirizzo NSAP lo richiede ad organismi di standardizzazione locale (in Italia UNI). Proprio come chi richiede un indirizzo IP in Italia lo fa ad esempio al GARR. Ogni organizzazione é libera poi di gestire il campo ESI come più le piace in ambito della sua sottorete.

Il campo SEL ha solo funzioni di multiplexing e non serve per il routing.

Per facilitare l'amministrazione degli indirizzi, ATMForum ha sviluppato un protocollo di registrazione denominato ILMI.

Questo protocollo permette ad un host quando fa il boot di specificare allo switch cui e connesso il suo indirizzo ESI (che é unico nella sottorete) e di ricevere di conseguenza il suo indirizzo ATM che servirà per il routing.

Da notare come la gerarchicitá degl'indirizzi ATM permettano un routing efficiente già al livello ATM al contrario di altri sistemi come Ethernet nel quale l'indirizzo e unico e lo schema é di conseguenza "flat", efficiente per una rete locale ma non scalabile, per cui necessita di un supporto come IP per un interconnessione su grande scala. Un sistema come ATM con la sua gerarchia di indirizzi permette di evitare il fenomeno detto "flooding" (alluvione) nel quale per cercare un host la rete invia messaggi a tutte le sue sottoparti, cosa possibile solo in scala locale ma sarebbe impensabile ad esempio che la rete telefonica (sicuramente la rete più gerarchica esistente nonché la più grande) per contattare un numero lo cercasse in tutto il mondo!

Per finire facciamo una digressione sul confronto modello OSI ed ATM.

Infatti proprio in base all'indirizzamento alcuni sostengono che il livello ATM sia equiparabile al livello 2 OSI mentre altri notano che esso ha funzionalità proprie del livello 3. In realtà il modello OSI non concepisce il concetto di reti sovrapposte e di indirizzamenti sovrapposti (come quello ATM e quello IP) per cui un paragone non é significativo.