Dal punto di vista della rete fisica l’IP datagram è un blocco di dati.

La rete fisica ignora cioè come tali dati vengano utilizzati dall’IP. il primo compito di IP è quello di decidere come costruire il datagram affinché possa essere trasmesso in un frame fisico.

L’ideale sarebbe di poter mettere un singolo datagram in ogni frame, ottimizzando così la trasmissione e semplificando la logica.

Ma quale frame? Quello della rete di partenza? Quello della rete di arrivo? E se durante la trasmissione il datagram deve passare attraverso più reti con MTU differenti? Il punto è che non c’è modo di fare una scelta che assicuri di avere un datagram per frame. D’altra parte internet ha come obiettivo quello di svincolarsi dalle caratteristiche fisiche delle varie reti interconnesse fra loro.

La soluzione adottata è molto semplice. Le dimensioni del datagram sono scelte convenzionalmente secondo una logica del tutto indipendente dalle MTU delle singole reti fisiche, dopodiché, a seconda della rete in cui il datagram deve passare, questo è suddiviso in più pezzi di dimensioni inferiori alla MTU della rete fisica, detti frammenti (fragment).

Il datagram è anch’esso un frame, che potremmo chiamare logico per distinguerla da quello usata da una specifica rete fisica per trasmettere i dati.

E’ formato da una intestazione e da un’area dati.

All’atto della frammentazione, ogni frammento viene costruito replicando l’header del datagram, modificandone alcuni campi che vedremo in seguito, e aggiungendo a questo un pezzo dell’area dati originaria.

L’aspetto più importante di questo meccanismo è che il riassemblaggio dei frammenti non viene effettuato quando i vari frammenti rientrano in una rete fisica ad alto MTU, ma sempre e comunque presso l’host di destinazione.

Se due reti con MTU uguale a 1.500 ottetti sono separate da una rete con MTU più bassa, per esempio 500 ottetti, i frammenti che arriveranno a destinazione saranno di soli 500 ottetti.

In questo caso la frammentazione avviene nel primo gateway mentre il riassemblaggio avviene solo nell’host di destinazione.

Il protocollo IP richiede che sia gli host che i gateway siano capaci di gestire datagram di almeno 576 ottetti.

Questi devono essere capaci anche di gestire datagram grandi quanto l’MTU più grande tra quelle delle reti a cui sono connessi.

Ricordiamo che un gateway, per definizione, ha almeno due connessioni e quindi almeno due indirizzi IP.

Il rovescio della medaglia è che la perdita di anche un solo frammento comporta la perdita dell’intero datagram.

Dato che ogni frammento è trasmesso indipendentemente, passare attraverso reti a bassa MTU comporta un’elevata frammentazione anche nelle reti a maggiore MTU e comunque aumenta i rischi di perdita dei dati.

Quando un frammento arriva a destinazione, non è detto che il primo arrivi per primo, l’host fa partire un timer. Se questo scade prima che tutti i frammenti siano arrivati, il sistema cancella tutti i frammenti e considera perduto il datagram.

Il concetto di timer e di tempi è estremamente importante per l’IP ed è spesso usato per ottimizzare la rete.

Ogni datagram ha una scadenza. Se il datagram è ancora all’interno della rete quando il suo tempo è scaduto, viene cancellato definitivamente.

Serve ad evitare che un pacchetto possa restare all’infinito in internet a causa di un errore in una routing table. Queste tabelle infatti servono a gestire il processo di instradamento del pacchetto nella rete. Se una o più tabelle sono sbagliate, si potrebbero creare cammini chiusi in cui i datagram potrebbero rimanere intrappolati.

Il datagram.  è composto di un’intestazione e di un’area dati.

L’area dati contiene semplicemente una parte dei dati da trasmettere.  il datagram è piccolo mentre l’oggetto da trasmettere può essere anche molto grande, come per esempio un’immagine o un file compresso.

L’intestazione è invece alquanto più complessa. Vediamola in dettaglio.

I primi 4 bit contengono la versione del protocollo IP che è stato utilizzato per creare il datagram.

Rammentate, il tutto funziona se e solo se tutti seguono le stesse regole alla lettera.

Le convenzioni, e di conseguenza i protocolli, seguono un processo di evoluzione, per cui un datagram creato con una versione più recente potrebbe creare problemi a un protocollo più vecchio se questi non avesse modo di accorgersene in tempo.

I 4 bit successivi danno la lunghezza dell’intestazione misurata in parole da 32 bit. Questa è necessaria agli algoritmi usati per leggere il datagram (parsing algorithms).I campi dell’intestazione potrebbero non risultare un multiplo intero di 32, è necessario porre alla fine dell’intestazione un campo di riempimento. il programma di ricezione ha bisogno di conoscere anche la lunghezza totale del datagram, cioè la lunghezza dell’intestazione più quella dell’area dati.

Questa è memorizzata nei bit dal 16 al 31 inclusi, e il suo valore è espresso in ottetti, al contrario del precedente.

Il campo è lungo 16 bit, il datagram non può essere più grande di 216 ottetti, cioè 65.535 byte.

Il campo tra la lunghezza dell’intestazione e quella totale del datagram identifica il tipo di servizio che va offerto al pacchetto, ed è formato da un campo di 3 bit che specifica l’importanza che va data al datagram, e da tre campi da 1 bit ciascuno che identificano il tipo di trasporto desiderato per questo pacchetto.

Non tutte le reti fisiche supportano questo campo, perciò esso è considerato come una raccomandazione e non un obbligo. In ogni caso il campo di priorità può contenere valori da 0 a 7. Lo zero è il valore di base di un normale pacchetto, mentre il 7 rappresenta la richiesta di precedenza più elevata, e va usato per i datagram che contengono dati per il controllo della rete stessa.

I tre bit relativi al tipo di trasporto servono a definire il livello di qualità relativo al trasferimento del pacchetto. Se impostati a uno, richiedono rispettivamente: di evitare al massimo ritardi nel recapitare il pacchetto al destinatario, di fornire la massima capacità di trasferimento, e di garantire un’elevata affidabilità durante il trasporto.

E’ difficile poter fornire tutti e tre questi servizi contemporaneamente. Spesso la rete non riesce a garantirne neanche uno solo.

I tre campi successivi vengono utilizzati nel meccanismo di frammentazione spiegato poco fa, e in particolare sono quelli che permettono all’host che riceve i vari frammenti di riassemblare il tutto per ottenere il datagram originario.

Sono fondamentali in quanto non è prevista alcuna comunicazione tra il mittente e il destinatario su come ricomporre il datagram, tanto più che la frammentazione finale può essere il risultato di più frammentazioni successive. i vari frammenti possono arrivare in qualunque ordine, dato che possono avere seguito cammini differenti. Dulcis in fundo, anche se l’intestazione di ogni frammento è ottenuta da quella del datagram originale, il quarto campo dell’intestazione di un frammento contiene la sua lunghezza totale, e non quella di tutto il datagram. Quest’ultima informazione deve essere calcolata dal destinatario in qualche modo. Ed ecco il perché di questi tre campi.

Il primo campo serve a identificare univocamente il datagram ed è lungo 16 bit. Tutti i frammenti che appartengono a uno stesso datagram hanno lo stesso identificativo. Il secondo campo è una maschera di 2 bit che controlla il meccanismo di frammentazione. Il primo bit specifica se il datagram può essere frammentato: se impostato a uno, la frammentazione non è permessa. Il secondo bit serve a marcare l’ultimo frammento. Vedremo tra un attimo a cosa serve. Il terzo campo contiene la posizione dei dati del frammento nel blocco originale di dati misurato in parole da 64 bit. Questo campo si chiama fragment offset.

Esempio: se un frammento ha un offset 7, vuol dire che il primo bit dei suoi dati corrisponde al quattrocento quarantanovesimo bit dei dati del frammento originale, dato che 7 * 64 + 1 fa appunto 449. Così si può ottenere la lunghezza totale del datagram originario. Basta sommare l’offset e la lunghezza totale dell’ultimo frammento, riconoscibile grazie al secondo bit del campo di controllo.

Il campo successivo, posto a partire dal 64° bit dell’intestazione, è lungo un byte e serve a stabilire quanto a lungo un datagram può rimanere nella rete. Data l’evidente difficoltà di sincronizzare gli orologi di tutti gli hosts e i gateway della rete, si è deciso di semplificare il meccanismo come segue:

Ogni gateway che processa il pacchetto decrementa il campo di uno quando questo arriva e memorizza il tempo di arrivo. Se il pacchetto non riparte subito ma rimane in attesa nel gateway, il valore di questo campo viene ulteriormente decrementato di una unità per ogni secondo di attesa. Come il campo arriva a zero, il datagram viene cancellato dalla rete e un messaggio di errore viene rispedito al mittente.

Il campo seguente, lungo 8 bit, identifica il protocollo di alto livello utilizzato che ha generato i dati contenuti nel datagram, e definisce di fatto il loro formato. Ne riparleremo in seguito, quando vedremo i protocolli applicativi.

Abbiamo quindi un campo di controllo di 16 bit che serve a verificare l’integrità dell’intestazione, e che utilizza il meccanismo di checksum ben conosciuto nel mondo del software. Il valore è la somma complementata a uno delle parole da 16 bit che compongono l’intestazione, addizionate con il metodo del complemento a uno.

Quindi vengono gli indirizzi IP del mittente e del destinatario, ognuno lungo 32 bit.

Per finire abbiamo un campo di lunghezza variabile che può contenere varie opzioni, e quindi il campo di riempimento di cui abbiamo già parlato. Queste opzioni non sono presenti in tutti i datagram e vengono usate prevalentemente nelle verifiche e nella identificazione dei problemi della rete.

Parliamo ora di due aspetti fin qui solo accennati i: meccanismi di instradamento dei pacchetti (routing) e la gestione degli errori. Incominceremo a salire nella torre dei protocolli Internet, introducendo il primo protocollo che si poggia sull’IP, e precisamente lo User Datagram Protocol (UDP). Si tratta ancora di un protocollo molto legato all’IP, ma comunque considerato al di sopra di questo.

L’ IP è un protocollo connectionless. Questo vuol dire che non esiste un collegamento diretto tra i due host che si scambiano dati, bensì una rete di connessioni attraverso la quale si possono identificare vari potenziali cammini da un host all’altro. Il cammino attraverso il quale i dati giungono all’host destinatario è scelto dinamicamente e può variare per ogni singolo pacchetto di dati.

Tale scelta non avviene quando il pacchetto parte, ma è il risultato di numerose decisioni prese a ogni singolo gateway. Per questo motivo i gateway sono detti anche router. Tali scelte possono dover tenere conto di molti elementi, quali la priorità del messaggio, il carico di rete, la capacità delle reti intermedie, e via dicendo. La base tuttavia del meccanismo sono le tabelle di instradamento (routing table). Vediamo di che si tratta.

Consideriamo prima una singola rete fisica. Se un host vuole spedire un messaggio a un altro host nella stessa rete, non deve far altro che incapsulare il messaggio in un datagramma IP fornendo quindi l’indirizzo IP del destinatario, e passare il tutto al livello inferiore. Questi provvederà a ricavare dall’indirizzo IP l’identificativo del destinatario nella rete fisica, a incapsulare il datagramma in un frame, e a spedire direttamente il tutto all’host finale. Questa tecnica si chiama instradamento diretto (direct routing).

Vediamo adesso quello che succede quando abbiamo due reti interconnesse tramite un gateway. L’host mittente si accorge che il destinatario non è nella sua rete fisica, dato che il network id del suo indirizzo IP è diverso da quello a cui deve spedire il datagramma. Spedisce allora il messaggio al gateway passando sia il datagramma che l’indirizzo IP del gateway al livello inferiore. Il

messaggio arriva quindi direttamente al gateway che estrae l’indirizzo IP del destinatario, si accorge che fa parte della seconda rete a cui è connesso, e spedisce quindi il tutto all’host finale attraverso la rete fisica. Questa tecnica si chiama di instradamento indiretto (indirect routing).

Se vi siete persi le puntate precedenti:

Tcp / Ip parte 1

Tcp / Ip parte 2

Tcp / Ip parte 3

Tcp / Ip parte 4

Tcp / Ip parte 6