Se un segnale vocale è ridotto a pacchetti, ed è costretto a condividere un collegamento con traffico dati burst (traffico con alcuni pacchetti dati di grandi dimensioni) allora non importa quanto piccoli possano essere fatti i pacchetti vocali, essi incontreranno sempre pacchetti dati di dimensioni piene. In condizioni normali di accodamento le celle potrebbero sperimentare ritardi massimi di accodamento. Per evitare questo problema, tutti i pacchetti ATM, o “celle”, sono della stessa piccola dimensione. Inoltre, la struttura a celle fisse significa che ATM può essere prontamente commutata dall’hardware senza i ritardi intrinseci introdotti dai frame commutati e instradati via software.
Quindi, i progettisti di ATM hanno utilizzato piccole celle di dati per ridurre il jitter (varianza di ritardo, in questo caso) nel multiplexing dei flussi di dati. La riduzione del jitter (e anche dei ritardi end-to-end round-trip) è particolarmente importante quando si trasporta il traffico vocale, perché la conversione della voce digitalizzata in un segnale audio analogico è un processo intrinsecamente in tempo reale, e per fare un buon lavoro, il decoder (codec) che fa questo ha bisogno di un flusso uniformemente spaziato (nel tempo) di dati. Se l’elemento di dati successivo non è disponibile quando è necessario, il codec non ha altra scelta che produrre silenzio o indovinare – e se i dati sono in ritardo, sono inutili, perché il periodo di tempo in cui avrebbero dovuto essere convertiti in un segnale è già passato.
Al tempo della progettazione di ATM, 155 Mbit/s di gerarchia digitale sincrona (SDH) con 135 Mbit/s di carico utile era considerato un collegamento di rete ottica veloce, e molti collegamenti di gerarchia digitale plesiocrona (PDH) nella rete digitale erano notevolmente più lenti, variando da 1.544 a 45 Mbit/s negli Stati Uniti, e da 2 a 34 Mbit/s in Europa.
A 155 Mbit/s, un tipico pacchetto dati completo di 1.500 byte (12.000 bit), sufficiente a contenere un pacchetto IP di dimensioni massime per Ethernet, richiederebbe 77,42 µs per essere trasmesso. In un collegamento a velocità inferiore, come una linea T1 da 1,544 Mbit/s, lo stesso pacchetto impiegherebbe fino a 7,8 millisecondi.
Un ritardo di accodamento indotto da diversi pacchetti dati di questo tipo potrebbe superare la cifra di 7,8 ms più volte, oltre a qualsiasi ritardo di generazione del pacchetto nel pacchetto più corto del discorso. Questo è stato considerato inaccettabile per il traffico vocale, che ha bisogno di un basso jitter nel flusso di dati che viene alimentato nel codec se si vuole produrre un suono di buona qualità. Un sistema di voce a pacchetto può produrre questo basso jitter in diversi modi:
- Utilizzando un buffer di riproduzione tra la rete e il codec, uno abbastanza grande da far superare al codec quasi tutto il jitter dei dati. Questo permette di smussare il jitter, ma il ritardo introdotto dal passaggio attraverso il buffer richiede cancellatori d’eco anche nelle reti locali; questo era considerato troppo costoso all’epoca. Inoltre, aumentava il ritardo attraverso il canale, e rendeva difficile la conversazione su canali ad alto ritardo.
- Utilizzare un sistema che fornisce intrinsecamente basso jitter (e minimo ritardo complessivo) al traffico che ne ha bisogno.
- Operare su una base di utente 1:1 (cioè, un tubo dedicato).
La progettazione di ATM mirava a un’interfaccia di rete a basso jitter. Tuttavia, le “celle” sono state introdotte nel progetto per fornire brevi ritardi di accodamento pur continuando a supportare il traffico di datagrammi. ATM divideva tutti i pacchetti, i dati e i flussi vocali in pezzi da 48 byte, aggiungendo un’intestazione di routing da 5 byte a ciascuno di essi in modo che potessero essere riassemblati in seguito. La scelta dei 48 byte fu politica piuttosto che tecnica. Quando il CCITT (ora ITU-T) stava standardizzando ATM, le parti degli Stati Uniti volevano un carico utile di 64 byte perché questo era sentito come un buon compromesso tra carichi utili più grandi ottimizzati per la trasmissione di dati e carichi utili più corti ottimizzati per applicazioni in tempo reale come la voce; le parti dall’Europa volevano carichi utili di 32 byte perché le piccole dimensioni (e quindi i brevi tempi di trasmissione) semplificano le applicazioni vocali rispetto alla cancellazione dell’eco. La maggior parte delle parti europee alla fine hanno accettato gli argomenti fatti dagli americani, ma la Francia e pochi altri hanno resistito per una lunghezza di cella più corta. Con 32 byte, la Francia sarebbe stata in grado di implementare una rete vocale basata su ATM con chiamate da un capo all’altro della Francia che non richiedevano la cancellazione dell’eco. 48 byte (più 5 byte di intestazione = 53) furono scelti come compromesso tra le due parti. Le intestazioni a 5 byte furono scelte perché si pensava che il 10% del carico utile fosse il prezzo massimo da pagare per le informazioni di routing. ATM ha multiplexato queste celle da 53 byte invece di pacchetti che hanno ridotto il jitter di contesa delle celle nel caso peggiore di un fattore di quasi 30, riducendo la necessità di cancellatori di eco.
Struttura della cellaModifica
Una cella ATM consiste in un’intestazione di 5 byte e un carico utile di 48 byte. La dimensione del carico utile di 48 byte è stata scelta come descritto sopra.
ATM definisce due diversi formati di cella: interfaccia utente-rete (UNI) e interfaccia rete-rete (NNI). La maggior parte dei collegamenti ATM usa il formato di cella UNI.
|
Diagramma di una cella UNI ATM
|
Diagramma di una cella NNI ATM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GFC = Il campo di controllo generico del flusso (GFC) è un campo di 4bit che è stato originariamente aggiunto per supportare la connessione di reti ATM a reti di accesso condivise come un anello DQDB (distributed queue dual bus). Il campo GFC è stato progettato per dare alla User-Network Interface (UNI) 4 bit in cui negoziare il multiplexing e il controllo del flusso tra le celle di varie connessioni ATM. Tuttavia, l’uso e i valori esatti del campo GFC non sono stati standardizzati, e il campo è sempre impostato su 0000. VPI = Virtual path identifier (8 bit UNI, o 12 bit NNI) VCI = Virtual channel identifier (16 bit) PT = Payload type (3 bit) PT bit 3 (msbit): Cella di gestione della rete. Se 0, cella dati utente e si applica quanto segue: PT bit 2: Explicit forward congestion indication (EFCI); 1 = congestione della rete sperimentata PT bit 1 (lsbit): Bit ATM da utente a utente (AAU). Usato da AAL5 per indicare i limiti dei pacchetti. CLP = Cell loss priority (1 bit) HEC = Header error control (CRC a 8 bit, polinomio = X8 + X2 + X + 1)
ATM usa il campo PT per designare vari tipi speciali di celle per scopi operativi, amministrativi e di gestione (OAM), e per delineare i confini dei pacchetti in alcuni livelli di adattamento ATM (AAL). Se il bit più significativo (MSB) del campo PT è 0, questa è una cella dati utente, e gli altri due bit sono usati per indicare la congestione della rete e come bit di intestazione di uso generale disponibile per i livelli di adattamento ATM. Se l’MSB è 1, questa è una cella di gestione, e gli altri due bit indicano il tipo. (Segmento di gestione della rete, gestione della rete end-to-end, gestione delle risorse, e riservato per uso futuro.)
Alcuni protocolli di collegamento ATM usano il campo HEC per guidare un algoritmo di framing basato su CRC, che permette di localizzare le celle ATM senza alcun overhead oltre a quello altrimenti necessario per la protezione dell’intestazione. Il CRC a 8 bit è usato per correggere gli errori di intestazione a bit singolo e rilevare gli errori di intestazione a più bit. Quando vengono rilevati errori di intestazione multi-bit, la cella corrente e quelle successive vengono abbandonate fino a quando non viene trovata una cella senza errori di intestazione.
Una cella UNI riserva il campo GFC per un sistema locale di controllo di flusso/submultiplexing tra utenti. Questo è stato pensato per permettere a diversi terminali di condividere una singola connessione di rete, nello stesso modo in cui due telefoni ISDN (Integrated Services Digital Network) possono condividere una singola connessione ISDN di base. Tutti e quattro i bit GFC devono essere zero per default.
Il formato della cella NNI replica quasi esattamente il formato UNI, eccetto che il campo GFC a 4 bit è riassegnato al campo VPI, estendendo il VPI a 12 bit. Così, una singola interconnessione NNI ATM è in grado di indirizzare quasi 212 VP fino a quasi 216 VC ciascuno (in pratica alcuni dei numeri VP e VC sono riservati).
Tipi di servizioModifica
ATM supporta diversi tipi di servizi tramite AAL. Gli AAL standardizzati includono AAL1, AAL2, e AAL5, e i raramente usati AAL3 e AAL4. AAL1 è usato per i servizi CBR (constant bit rate) e l’emulazione di circuito. Anche la sincronizzazione è mantenuta in AAL1. Da AAL2 a AAL4 sono usati per servizi a bitrate variabile (VBR), e AAL5 per i dati. Quale AAL è in uso per una data cella non è codificato nella cella. Invece, è negoziato o configurato dagli endpoint su una base di connessione virtuale.
Dopo la progettazione iniziale di ATM, le reti sono diventate molto più veloci. Un frame Ethernet full-size da 1500 byte (12000 bit) impiega solo 1,2 µs per trasmettere su una rete da 10 Gbit/s, riducendo la necessità di piccole celle per ridurre il jitter dovuto alla contesa. Alcuni ritengono che questo sia un caso per sostituire ATM con Ethernet nella dorsale di rete. Le maggiori velocità di collegamento da sole non alleviano il jitter dovuto alle code. Inoltre, l’hardware per implementare l’adattamento del servizio per i pacchetti IP è costoso a velocità molto alte. In particolare, a velocità di OC-3 e superiori, il costo dell’hardware di segmentazione e riassemblaggio (SAR) rende ATM meno competitivo per IP rispetto al Packet Over SONET (POS); a causa del suo carico utile fisso di 48 byte, ATM non è adatto come livello di collegamento dati direttamente sottostante IP (senza la necessità di SAR a livello di collegamento dati) poiché il livello OSI su cui opera IP deve fornire un’unità di trasmissione massima (MTU) di almeno 576 byte. I limiti di prestazione SAR significano che le interfacce ATM dei router IP più veloci sono STM16 – STM64 che in realtà si confrontano, mentre dal 2004 POS può operare a OC-192 (STM64) con velocità più elevate previste in futuro, limiti basati sulla segmentazione e riassemblaggio (SAR).
Su collegamenti più lenti o congestionati (622 Mbit/s e sotto), ATM ha senso, e per questo motivo la maggior parte dei sistemi ADSL (Digital Subscriber Line) asimmetrici usano ATM come livello intermedio tra il livello di collegamento fisico e un protocollo di livello 2 come PPP o Ethernet.
A queste velocità inferiori, ATM fornisce un’utile capacità di trasportare più circuiti logici su un singolo mezzo fisico o virtuale, anche se esistono altre tecniche, come Multi-link PPP ed Ethernet VLAN, che sono opzionali nelle implementazioni VDSL. La DSL può essere usata come metodo di accesso per una rete ATM, permettendo a un punto di terminazione DSL in un ufficio centrale telefonico di connettersi a molti fornitori di servizi internet attraverso una rete ATM ad ampio raggio. Negli Stati Uniti, almeno, questo ha permesso ai fornitori DSL di fornire accesso DSL ai clienti di molti fornitori di servizi internet. Poiché un punto di terminazione DSL può supportare più ISP, la fattibilità economica della DSL è sostanzialmente migliorata.