Il modello TCP/IP

Nell'ambito delle architetture di rete si può tranquillamente dire che lo standard di fatto è la suite di protocolli TCP/IP^2.1. Anche TCP/IP può essere studiato con un approccio a strati, e la figura mostra un parallelo con il modello ISO-OSI.

Figure: Lo stack ISO-OSI a confronto con quello TCP/IP.

Si nota che i due livelli più bassi della pila OSI corrispondono a quello che in TCP viene chiamato livello host-rete, in effetti questo strato sottostante è non meglio specificato, la suite TCP/IP copre la pila OSI a partire dal livello di rete. Si nota anche che in TCP/IP non sono previsti i livelli di presentazione e sessione, se si ritiene che alcune delle loro caratteristiche siano utili devono essere implementate dall'applicazione.

Di seguito verranno presentate le caratteristiche salienti dei tre protocolli IP, TCP, UDP.

Internet Protocol (IP)

Secondo il modello ISO-OSI, IP [6] è un protocollo di livello 3, cioè di livello rete (vedi figura ), è a livello IP che gli host hanno visibilità della rete e non più dei soli host direttamente collegati ad essi.

Per capire le funzionalità offerte da IP è sicuramente utile analizzarne la struttura dell'header riportato in figura .

Figure: L'header di IP.

Ora analizzeremo i vari campi:

Version:

4bit
Descrive la versione del protocollo utilizzato.

IHL (IP Header Length):

4bit
Contiene la lunghezza dell'header (in parole di 32 bit), questa è un 'informazione necessaria perché con le opzioni l'header può essere anche più lungo dei canonici 20 byte.

Type of service:

8bit
Permette di indicare il tipo di servizio richiesto.

Total length:

16bit
Contiene la lunghezza totale del pacchetto (quindi header+payload)

Identification:

16bit
In caso di frammentazione tutti i frammenti conterranno lo stesso identificativo, quindi questo campo è necessario per permettere all'host di ricongiungere tutti i frammenti.

DF (Don't Fragment):

1bit
Flag che se settata ad 1 ordina ai router di non frammentare il pacchetto.

MF (More Fragment):

1bit
Flag che se settata ad 1 indica che questo datagramma è un frammento di un pacchetto più grande, e non è l'ultimo (che infatti avrà il flag posto a zero).

Fragment Offset:

13bit
Indica in che posizione del datagram va inserito questo frammento.

Time to live:

8bit
É il contatore utilizzato per determinare il tempo di vita dei pacchetti. Tipicamente viene decrementato ad ogni salto.

Protocol:

8bit
Indica quale è il protocollo di livello superiore utilizzato (e quindi permette di interpretare correttamente l'header che segue).

Header checksum:

16bit
Controllo di errore (solo sull'header).

Source address:

32bit
Indirizzo IP della sorgente.

Destination address:

32bit
Indirizzo IP della destinazione.

Options:

0 o più parole da 32bit
Estensioni dell'header che permettono di includere nuove funzionalità, oppure di provare nuove soluzioni.

É subito evidente che non è presente un campo con la numerazione dei pacchetti, infatti IP non ha bisogno di questo tipo di informazione in quanto non gestisce in alcun modo la perdita di pacchetti.

Inoltre è interessante notare la presenza del campo Type of service: secondo le idee dei progettisti, tale informazione avrebbe dovuto permettere di introdurre in qualche modo il concetto di qualità del servizio sulla rete Internet. Infatti tale campo è composto a sua volta da più sottocampi che sono:

• [Precedence]Indica di fatto una priorità, utilizza 3 bit e quindi si possono specificare 8 livelli diversi di priorità
• [D,T,R]Questi 3 flag permettono all'host di specificare che cosa ritiene più importante tra ritardo, capacità di trasmissione e affidabilità.

Questi campi in teoria dovrebbero permettere ai router di effettuare delle scelte, ad esempio decidere quale è il migliore link in uscita per un determinato pacchetto, oppure quali pacchetti possono essere momentaneamente accodati e quali invece devono essere spediti subito. In realtà tali informazioni sono di fatto ignorate dai router probabilmente anche per motivi di semplicità.

Dall'analisi dei campi dell'header viene messo in evidenza inoltre che un pacchetto IP può subire una frammentazione, cioè può essere suddiviso in più pacchetti IP, questo tipicamente avviene perché le dimensioni del pacchetto eccedono la MTU (Maximum Transmission Unit), cioè la massima unità trasferibile. Questa è una cosa da tenere in considerazione, in quanto la perdita di anche un solo frammento comporta la perdita di tutto il pacchetto iniziale.

Multicast

IP sostanzialmente prevede tre distinte modalità di trasmissione che si distinguono per il tipo di indirizzo destinazione utilizzato, esse sono l'unicast il broadcast ed il multicast.

Il primo caso è quello più semplice, la trasmissione è del tipo uno a uno, l'indirizzo destinazione identifica in modo univoco un host, e i pacchetti vengono inoltrati verso quest'ultimo.

Nel caso del broadcast la trasmissione è del tipo uno a tutti (su una specifica rete), quindi tutti gli host riceveranno i pacchetti.

Infine c'è il multicast, in questo caso la trasmissione è del tipo uno a molti.

Figure: Le tre modalità di trasmissione di IP

[Unicast]

[broadcast]

[Multicast]

La figura mostra quanto avviene, le linee punteggiate rappresentano il percorso dei dati.

Nel caso del multicast l'indirizzo IP utilizzato (appartenente agli indirizzi compresi tra 224.0.0.0 e 239.255.255.255) identifica un cosiddetto gruppo multicast, tramite il protocollo IGMP (Internet Group Management Protocol) gli host possono comunicare al gateway della loro sottorete quali gruppi vogliono sottoscrivere e quest'ultimo si occuperà di ricevere i pacchetti diretti a questi gruppi ed inoltrarli verso l'host. Il modo in cui il gateway riceve tali pacchetti dipende dal protocollo di routing multicast utilizzato.

Attualmente il multicast non è supportato su tutta la rete Internet in quanto solo pochi router implementano i protocolli di routing multicast, tuttavia è possibile sperimentarne l'utilizzo aderendo al circuito Mbone. In pratica diverse sottoreti multicast sono state collegate tramite dei tunnel, cioè dei semplici collegamenti unicast sui quali i pacchetti multicast viaggiano incapsulati in normali pacchetti IP, l'instradamento è gestito dai protocolli di routing multicast all'interno delle sottoreti mentre sui tunnel vengono usati i normali protocolli di instradamento unicast (figura ).

Figure: Mbone

IPv6

Quello descritto finora è il protocollo IP nella sua versione numero 4. Ormai questo protocollo ha i giorni contati, diversi problemi hanno reso indispensabile una nuova versione denominata IPv6 (versione 6). Il problema principale è sicuramente legato agli indirizzi disponibili, ogni indirizzo IP è composto da 32 bit, il che significa che si hanno a disposizione 2³² possibili combinazioni, cioè poco più di 4 miliardi. Tuttavia la forte crescita della richiesta degli indirizzi, unita allo spreco che si effettua assegnandoli per classi^2.2, ci sta portando velocemente verso l'esaurimento degli indirizzi disponibili. Nel 1990, intuendo la nascita di questi problemi, l' IETF iniziò a lavorare sulla nuova versione di IP, i principali requisiti su cui si è puntato sono riportati di seguito.

1. Supportare molti miliardi di host, anche nel caso di allocazione inefficiente dello spazio.
2. Ridurre la dimensione delle tabelle di routing.
3. Semplificare il protocollo in modo da permettere ai router di smistare più velocemente i pacchetti.
4. Fornire una maggiore sicurezza (mediante autenticazione e privacy).
5. Prestare più attenzione al tipo di servizio, in particolare per i dati real time.
6. Rendere facile l'evoluzione del protocollo.
7. Permettere la coesistenza con l'attuale versione di IP (IPv4).

Dopo aver analizzato diverse proposte fu scelta la soluzione indicata fino a quel momento come SIPP (Simple Internet Protocol Plus) e le fu dato il nome di IPv6. La nuova versione ha indirizzi molto più lunghi, 128 bit, ciò dovrebbe risolvere definitivamente il problema degli indirizzi, inoltre ha un preambolo più semplice (7 campi contro i 13 di IPv4), questa semplificazione è stata possibile anche grazie ad una migliore gestione delle opzioni, campi che prima erano obbligatori sono divenuti opzionali. IPv6, inoltre supporta direttamente la sicurezza, e maggiore attenzione è stata prestata alla diversificazione dei tipi di servizio.

Queste caratteristiche possono essere apprezzate meglio analizzando l'header (vedi figura ).

Figure: L'header di IPv6

Version:

4bit
Versione del protocollo

Priority:

4bit
Può essere utilizzato per distinguere, tramite priorità, i vari flussi di pacchetti, i valori da 0 a 7 sono riservati a trasmissioni che possono essere rallentate, i valori da 8 a 15 sono riservati al traffico in tempo reale.

Flow Label:

24bit
L'etichetta di flusso verrà utilizzata per permettere di creare una pseudoconnessione con particolari esigenze, come ad esempio il mantenere contenuti i ritardi o l'avere a disposizione una certa banda. I router guarderanno nelle loro tabelle interne per stabilire quale trattamento applicare. Le etichette di flusso sono un tentativo per avere contemporaneamente la flessibilità delle reti a datagrammi e le garanzie delle reti connection oriented.

Payload Length:

16bit
Indica quanti byte seguono l'header, quindi misura il solo payload.

Next Header:

8bit
Indica quale dei sei header di estensione segue quello standard, oppure nel caso che non ci siano altri header di estensione indica a quale gestore di protocollo di trasporto debba essere passato il pacchetto.

Hop Limit:

8bit
É analogo al campo TTL di IPv4, indica quanti salti può effettuare il pacchetto prima che venga considerato obsoleto.

Source Address:

128bit
Indirizzo della sorgente.

Destination Address:

128bit
Indirizzo della destinazione.

Si può notare che mancano del tutto i campi legati alla frammentazione, infatti in IPv6 si è cercato di evitare che i pacchetti possano essere frammentati. Quindi innanzitutto tutti gli host e i router conformi con IPv6 devono supportare pacchetti di almeno 576byte, questo già rende la frammentazione meno probabile, inoltre quando un router riceve un pacchetto troppo grande, invece di frammentarlo al volo risponde con un messaggio di errore, tutto questo nell'ottica che il fatto che l'host spedisca pacchetti della giusta dimensione è in ultima analisi più efficiente della frammentazione al volo. Rispetto ad IPv4 manca anche il campo checksum, in effetti le reti attuali sono molto più affidabili, ed inoltre il calcolo della checksum rallentava troppo le operazioni di routing.

User Datagram Protocol (UDP)

UDP [5] è un protocollo non orientato alla connessione che, come mostrato in figura si pone a livello 4 (trasporto) della pila OSI.

Figure: L'header di UDP.

In figura è mostrato l'header di UDP. Segue la descrizione dei campi che lo compongono:

Source port:

16bit
Numero di porto della sorgente.

Destination port:

16bit
Numero di porto della destinazione.

UDP length:

16bit
Lunghezza di tutto il pacchetto UDP.

UDP checksum:

16bit
Controllo di errore sull'header.

Come vediamo UDP aggiunge veramente poco ad IP, in pratica la differenza fondamentale tra i due è l'introduzione dei numeri di porto, grazie ai quali diviene possibile effettuare una multiplazione di più flussi di traffico diretti verso uno stesso indirizzo IP. Quindi ad esempio più applicazioni possono funzionare contemporaneamente su uno stesso host, le informazioni verranno correttamente instradate verso la giusta applicazione grazie all'indicazione del numero di porto. Di fatto gli end-point a livello trasporto sono specificati dalle coppie [Indirizzo IP, Numero di Porto].

Transmission Control Protocol (TCP)

TCP [4] offre numerose funzionalità, ed è senza dubbio il protocollo di trasporto più utilizzato. Tra le caratteristiche salienti dobbiamo certamente ricordare che è un protocollo orientato alla connessione ed affidabile. In pratica gli applicativi vedono la connessione TCP come un circuito fisico dedicato ed hanno la certezza che tutto quello che viene spedito arriva all'altro capo della connessione, ed inoltre che anche l'ordine viene preservato. Anche TCP sfrutta il multiplexing delle connessioni grazie ai numeri di porto così come si è visto per UDP.

Una trasmissione inaffidabile e basata sui pacchetti (cioè quello che offre IP) viene trasformata in un flusso di byte con garanzie di affidabilità.

Inoltre vengono usati meccanismi di controllo di flusso e di congestione per evitare di congestionare l'host ricevente o la rete, queste funzionalità vengono garantite utilizzando meccanismi sliding window con gestione dell'acknoledgement. Tutto questo chiaramente ha un prezzo, l'uso di tecniche sliding window rende necessario un buffering dei dati ricevuti e quindi introduce dei ritardi nel passaggio dei dati ai livelli superiori.

L'analisi del header di TCP (figura) ci aiuta capire meglio il suo funzionamento.

Figure: L'header di TCP

Source port:

16bit
Numero di porto della sorgente.

Destination port:

16bit
Numero di porto della destinazione.

Sequence number:

32bit
Identifica, nello stream di byte da trasmettere, la posizione del primo byte nel pacchetto.

Acknoledgement number:

32bit
Contiene il numero del byte immediatamente successivo all'ultimo correttamente ricevuto dalla destinazione.

TCP header length:

4bit
Indica la lunghezza dell'header, questa informazione è necessaria in quanto il campo opzioni è di lunghezza variabile.

Flag:

6bit
URG (Urgent) indica che il campo urgent pointer è valido, ACK (Acknoledgement) indica che il campo acknoledgement number è valido, PSH (Push) serve a sollecitare lo svuotamento del buffer di trasmissione, RST (Reset) resetta la connessione, SYN (Syncronization) sincronizzazione usata nella creazione e nella chiusura della chiusura, FIN (Final) il trasmettitore ha raggiunto la fine dei dati da trasmettere.

Window size:

16bit
Specifica la dimensione della finestra di ricezione.

Checksum:

16bit
Controllo di errore, a differenza di IP e UDP il controllo è esteso anche ai dati.

Urgent pointer:

16bit
In determinate situazioni TCP permette la trasmissione ad alta priorità di dati, in questo caso l'urgent pointer indica la posizione di inizio di questi dati all'interno del pacchetto.

Options:

0 o più parole da 32bit
Tra le principali opzioni abbiamo la dimensione massima del payload, oppure la possibilità di utilizzare il selective repeat come algoritmo sliding window.

Footnotes

... TCP/IP^2.1

Sarebbe più corretto dire TCP-UDP/IP.

... classi^2.2

Le grosse aziende comprano intere classi di indirizzi, raramente però li utilizzano tutti.