di Carmelo Nucera

IP su ATM - 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. é 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).

 

Protocollo IP funzionante su ATM in modo nativo (IETF)

Abbiamo già detto che protocolli di livello rete, come IP, devono essere potenziati per poter essere usati direttamente su ATM. Attualmente il lavoro fatto per IP è molto ed in particolare IETF ha prodotto alcuni standard:

• Classic IP over ATM (RFC1577)
  E' la prima tecnica proposta ed offre innumerevoli vantaggi rispetto ad IP non nativo su ATM
• NHRP
  E' la tecnica sinora più avanzata proposta per far funzionare IP nativo su reti ATM
• MARS
  E' un protocollo dedicato al multicasting, problema particolarmente difficile su reti ATM

Il motivo principale per l'uso di un protocollo nativo su ATM è l'opportunità di sfruttare il QoS control ed evitare di ricorrere ad AAL5 che può garantire solo servizi ABR ed UBR. E' vero che IP, essendo stato sviluppato per reti LAN e WAN con tecnologia best effort, non "richiede" che sia garantita una certa QoS ma applicazioni di tipo multimediale, ed in prospettiva IPv6, non possono che essere avvantaggiate da questa scelta.

Ci sono alcune proposte per "bypassare" il livello IP facendo funzionare le applicazioni direttamente su ATM (con l'utilizzo di specifiche API) oppure su di un livello di rete "minimo" (es. TCP and UDP over Lightweight IP TULIP oppure TCP and UDP over Nonexistent IP TUNIP di IETF) con l'argomentazione che il TCP/IP non possa essere scalato facilmente verso velocità elevate. Quest'ultima argomentazione, in realtà, è errata in quanto IP è un protocollo "leggero" (in quanto connectionless) mentre il vero collo di bottiglia è il livello di trasporto TCP. Se la rete su cui si appoggia IP dà "più garanzie" non è necessario un protocollo "pesante" come il classico TCP ma se ne può adottare una versione "light".

Al contrario uno stack di protocolli "minimo" limita l'utilizzo della rete solo ad applicazioni che utilizzino ATM in modo "quasi puro" (e ciò è auspicabile solo in un futuro non vicino) mentre l'eterogeneità dei tipi di reti impone l'utilizzo di IP per garantire lo sviluppo di applicazioni cost-effective.

IETF sta procedendo nella direzione di arricchimento di IP mediante la nozione di Integrated Services Internet cioè di una rete che integri in Internet servizi aggiuntivi come i "multimediali". Per esempio è stato sviluppato il protocollo RSVP (Resource ReserVation Protocol) per permettere alla rete di riservare le risorse