1

Sistemi e Tecnologie della Comunicazione

Lezione 22: transport layer: introduzione, funzionalita’

2

Funzione del livello di trasporto

Il livello di trasporto ha lo scopo di fornire allo strato superiore un servizio di trasferimento dei dati end to end, mascherando completamente al livello superiore il fatto che tra i due host terminali esista una rete di qualsiasi tipo, topologia, tecnologia e complessita’ per OSI lo strato superiore e’ il livello di sessione per TCP/IP lo strato superiore e’ il livello di

applicazione Per assolvere le sue funzioni lo strato di

trasporto utilizza i servizi dello strato di rete

3

Necessita’ dello strato di trasporto

Perche’ introdurre un nuovo strato? lo strato di rete opera su tutte le macchine attraversate dai

dati, indipendentemente in mancanza di uno strato che operi esclusivamente sui

nodi terminali della comunicazione l’utente della rete non puo’ tenere sotto controllo cosa accade ai dati una volta che lasciano l’host sorgente

lo strato di trasporto rende trasparente allo strato superiore la complessita’ (l’esistenza!) della sottorete

La presenza di uno strato intermedio tra applicazione e rete puo’ offrire un meccanismo per rendere affidabile una comunicazione su sottoreti inaffidabili

Inoltre offre al suo utente una interfaccia indipendente dalle diverse tecnologtie dello strato di rete

4

Servizi forniti allo strato superiore

Lo strato di trasporto puo’ offrire servizio affidabile orientato alla connessione servizio inaffidabile non orientato alla connessione

In modo analogo ai servizi equivalenti dello strato di rete:

il servizio orientato alla connessione realizza un trasferimento dei dati affidabile (controllo della integrita’, della completezza, dell’ordine) e permette di gestire controllo di flusso; i dati vengono trasferiti con un procedimento in tre fasi

si stabilisce la connessione si inviano i dati attraverso la connessione si chiude la connessione

il servizio non orientato alla connessione fornisce un meccanismo di trasferimento dati “best-effort”: ogni blocco di dati viene inviato e ci si dimentica di lui; se arrivano, bene, se no l’applicazione dovra’ farsi carico di operare azioni correttive (se necessarie)

6

Protocollo di trasporto Il livello di trasporto realizza le sue funzioni

comunicando con il processo paritario secondo un protocollo definito

Le informazioni vengono scambiate tramite la trasmissione di blocchi di dati

in OSI si chiamano TPDU (Transport Protocol Data Unit) in TCP/IP si chiamano segmenti (ma spesso anche

pacchetti) Il protocollo si dovra’ occupare dei meccanismi per

gestire i diversi eventi (ove necessari): come si stabilisce la connessione come si chiude una connessione controllo di flusso controllo degli errori, ritrasmissioni e acknowledge ordinamento in sequenza dei dati

Le problematiche sono simili a quelle del livello di data link

7

Differenze rispetto al data link

Il fatto che a livello di trasporto i due terminali siano separati da una rete provoca complicazioni

a livello 2 un pacchetto o arriva o non arriva, mentre a livello 4 la sottorete provoca ritardi e riapparizione di pacchetti che si credevano perduti e quindi ritrasmessi, con conseguente duplicazione

il numero delle connessioni cui il livello di trasporto deve far fronte e’ molto piu’ elevato che nel caso del data link layer: non sara’ possibile dedicare a tutte i buffer necessari alle comunicazioni

8

Ritardo dei pacchetti e numeri di sequenza

Come visto a livello di data link, la gestione delle funzioni di acknowledge e ritrasmissione prevede di utilizzare numeri di sequenza sulle TPDU inviate in una connessione

Il fatto che la rete possa ritardare il recapito dei pacchetti comporta delle necessita’ sulla scelta dei numeri di sequenza

Vediamo un esempio che mostra come partire sempre da 0 puo’ comportare dei problemi:

si stabilisce una connessione e si iniziano ad inviare TPDU con seq = 0

dopo 10 secondi la TPDU con seq = X si ferma in un router congestionato; viene reinviata dopo il tempo di timeout e la connessione si chiude

si apre subito un’altra connessione, nuovamente con seq = 0 a questo punto la TPDU originaria si sblocca ed arriva a

destinazione prima che una TPDU con seq = X della nuova connessione venga inviata

la vecchia TPDU verra’ accettata e si ha un errore

9

Ritardo dei pacchetti e numeri di sequenza

Per ovviare a questo problema, si devono prendere delle precauzioni:

lo strato di rete deve essere in grado di invalidare pacchetti troppo vecchi

in questo modo un numero di sequenza gia’ utilizzato puo’ essere riutilizzabile dopo un tempo pari o superiore al tempo di vita massimo dei pacchetti

la assegnazione dei numeri di sequenza iniziali deve essere fatta in modo da essere sicuri che non esistano sulla rete TPDU con numerazione valida

solitamente i numeri di sequenza iniziali di una connessione vengono scelti (da chi inizia la connessione) con un valore legato ad un orologio

una scelta opportuna rende impossibile avere ritardati con numeri di sequenza validi che possano essere interpretati in modo errato

10

Stabilire la connessione

Il problema della inaffidabilita’ della sottorete e dei duplicati ritardati si presenta anche nella fase di inizializzazione della connessione

Per risolverli e’ stato sviluppato un meccanismo detto handshake a 3 vie:

il client invia una TPDU di Connection Request in cui propone un certo valore iniziale di sequenza

il server risponde con un acknowledge che riporta il valore iniziale di sequenza proposto dal client, ed il valore di sequenza proposto dal server per il traffico in senso inverso

il client invia una terza TPDU che riporta l’acknowledge per il numero di sequenza iniziale proposto dal server, e riporta nuovamente il proprio numero di sequenza iniziale (eventualmente questa TPDU puo’ anche trasportare i primi dati)

11

Handshake a tre vie Il meccanismo visto risponde positivamente ai problemi di

duplicati sulla rete sempre nella ipotesi che non possano esistere

contemporaneamente sulla rete TPDU con lo stesso numero di sequenza (vedi slide precedenti)

In figura a sinistra la procedura normale, a destra cosa accade se arriva una Connection Request ritardata relativa ad una vecchia connessione

12

Handshake a tre vie (cont.)

In figura e’ mostrato cosa accade se arriva una Connection Request ritardata relativa ad una vecchia connessione, seguita dalla TPDU di acknowledge finale, anch’essa ritardata

Poiche’ host 2 ha proposto come seq il valore y e riceve l’acknowledge per z si accorge che deve scartare la TPDU

13

Rilascio della connessione Anche qui ci sono problemi da affrontare La connessione puo’ essere rilasciata in modo asimmetrico o

simmetrico

Nel modo asimmetrico la disconnessione viene decisa da uno dei due, che invia una TPDU Disconnect Request e chiude

Questo puo’ comportare la perdita di dati, come mostrato in figura: dopo la disconnessione l’host 2 non accetta piu’ i dati in ingresso

14

Rilascio simmetrico Il rilascio simmetrico richiede che le parti siano

entrambe consapevoli e daccordo Sorge il problema (insolubile) di essere entrambi

sicuri che l’altro sia daccordo (problema dei due eserciti)

15

Rilascio simmetrico (cont.)

La soluzione adottata usualmente e’ un handshake a tre vie con timeout:

il primo invia una TPDU Disconnect Request, ma lascia la connessione aperta in ricezione ed avvia un timer

il secondo invia in risposta una TPDU Disconnect Request lasciando aperta la connessione, ed avvia un timer

il primo risponde alla DR ricevuta con una TPDU di ACKe chiude la connessione

in caso di perdita delle TPDU i timeout provocheranno, a seconda dei casi, una ritrasmissione o il rilascio definitivo della connessione anche in assenza di riscontro

Questa soluzione garantisce quasi sempre che nessun dato venga perduto

16

Rilascio simmetrico (cont.)

17

Controllo di flusso e buffering

Come visto per il data link layer, il controllo di flusso puo’ essere gestito tramite un protocollo sliding window

Questo protocollo richiede che vengano dedicati buffer in trasmissione per contenere le TPDU inviate e non ancora riscontrate, e buffer in ricezione per contenere dati ricevuti in ordine non corretto

Tuttavia il livello di trasporto presenta problemi che non affliggono il data link layer

un host puo’ dover gestire a livello di trasporto centinaia di connessioni contemporanee: si devono trovare le risorse per i buffer

la dimensione dei buffer e’ un altro problema: le applicazioni possono richiedere di trasferire blocchi dati di dimensioni molto differenti (dal singolo carattere di una sessione telnet a svariati KB di un file transfer); allocare buffer di dimensioni definite puo’ costituire un problema

lo strato applicativo potrebbe liberare i buffer in ricezione in modo lento, generando una situazione in cui una TPDU e’ stata riscontrata in quanto ricevuta, ma il buffer allocato dalla TPDU non e’ ancora libero

18

Alternative in funzione della sottorete

In caso di sottorete inaffidabile, il trasmittente deve mantenere i dati nei buffer

in questo caso il ricevente potrebbe non utilizzare buffer specifici per la connessione, ma ad esempio un pool di buffer per tutti, richiedendo la disponibilita’ di buffer dinamicamente e scartando le TPDU in caso di indisponibilita’ (comunque il trasmittente conserva i dati)

Se la sottorete offre un servizio affidabile: se il ricevente rende disponibili buffer in ricezione, il

trasmittente potrebbe farne a meno se pero’ il ricevente non puo’ garantire spazio sufficiente

di buffer, l’affidabilita’ della sottorete garantisce il recapito ma non l’accettazione, quindi la risorsa di buffer deve essere allocata anche in trasmissione

19

Alternative in funzione della TPDU size

Se le TPDU hanno generalmente una dimensione simile si puo’ allocare un pool di buffer uguali

In caso contrario questa soluzione rappresenta uno spreco di risorse

utilizzare buffer di dimensioni medie puo’ essere piu’ efficiente, ma le TPDU di grosse dimensioni vanno a occupare piu’ buffer, complicandone notevolmente la gestione

possono essere utilizzati buffer a dimensione variabile, ma anche questo complica la gestione dei dati

una terza possibilita’ e’ l’utilizzo di un grosso buffer circolare per ogni connessione

in questo caso si semplifica la gestione dei buffer, ma di nuovo si ha spreco di risorse per connessioni a basso carico trasmissivo

20

Alternative in funzione della applicazione

Applicazioni che utilizzano TPDU piccole possono essere efficientemente gestite tramite un pool comune ed allocazione dinamica dei buffer in trasmissione e ricezione (TPDU piccole significa buona probabilita’ di trovare buffer disponibili)

Applicazioni tipo file transfer richiedono invece la disponibilita’ in ricezione di un pool di buffer pari alla window size (come nel caso del data link layer), per sfruttare al meglio la banda disponibile

21

Gestione dinamica dei buffer

Poiche’ le caratteristiche delle diverse connessioni possono cambiare rapidamente, e le esigenze sono differenti, la soluzione adottata e’ che le due parti regolino dinamicamente le allocazioni

ad esempio, se due stazioni dedicano un pool comune di buffer alle connessioni attive tra i due host, e ad un certo punto il numero di connessioni aumenta, il ricevitore potra’ comunicare al trasmittente che il numero di buffer per una singola connessione e’ diminuito

Il protocollo di trasporto deve prevedere questa possibilita’

22

Buffer dinamici come window size

L’utilizzo della gestione dinamica dei buffer permette al ricevente di regolare la velocita’ del trasmittente in funzione della quantita’ di buffer disponibili in ricezione; di fatto il numero di buffer disponibili in ricezione definisce la window size

Quello che viene fatto dal protocollo e’ sostanzialmente la seguente cosa:

il trasmittente (all’atto dell’attivazione della connessione) richiede un certo numero di buffer in funzione delle sue esigenze

il ricevente risponde concedendo il numero di buffer che puo’ offrire, ed il ricevente memorizza il numero e tiene conto della disponibilita’ di buffer in ricezione durante tutta la trasmissione

ad ogni TPDU inviata il trasmittente riduce il numero di buffer che il ricevente ha disponibili

quando arriva a zero il trasmittente si ferma ad ogni acknowledge, il ricevente comunica quanti buffer ha

disponibili

23

Separazione ack/window size

Tuttavia, come gia’ detto, gli eventi “TPDU riscontrata” e “buffer liberato” nello strato di trasporto non sono contemporanei

questo e’ essenzialmente dovuto al fatto che “chi libera il buffer” e’ un applicativo scritto dall’utente (non dal progettista della rete), che magari riceve 4 KB di TPDU ma le legge un byte per volta

Questo fatto obbliga a separare la funzione dell’acknowledge dalla definizione della window disponibile (cioe’ dei buffer disponibili in ricezione)

Di fatto il ricevente puo’ inviare un riscontro relativo a tutte le TPDU trasmesse, ma comunque indicare disponibilita’ di buffer a zero (quindi bloccare il trasmittente)

Quando l’applicativo libera uno o piu’ buffer, il ricevente inviera’ un nuovo ack (relativo sempre all’ultima TPDU rucevuta) ma comunicando la nuova disponibilita’ di buffer

questo puo’ generare uno stallo, perche’ le TPDU di controllo non vengono riscontrate e non hanno timeout: se l’ultima TPDU (ack+nuovi buffer liberi) si perde, il trasmittente resta fermo ed il ricevente pure

per risolvere questa situazione ogni host deve periodicamente trasmettere una TPDU di controllo per fornire l’ack e la situazione dei buffer

24

Controllo della congestione

Quando il collo di bottiglia e’ la rete, il controllo di flusso non e’ sufficiente

Il controllo di questa situazione nel livello di trasporto e’ compito del trasmittente

Il livello di trasporto non definisce meccanismi; generalmente a livello pratico si utilizza la tecnica seguente:

il trasmittente utilizza come parametro di misura il numero di TPDU che non hanno ricevuto un ack prima del timeout

ciclicamente viene effettuata una analisi di questo dato quando si verifica un aumento dei timeout, il trasmittente

riduce la velocita’ di trasmissione, ad esempio riducendo la window size (anche se c’e’ disponibilita’ di buffer in ricezione)

25

Indirizzamento: TSAP Un processo applicativo deve specificare a quale

applicazione remota vuole connettersi Lo strato di trasporto puo’ servire contemporaneamente

diverse applicazioni quando riceve una connection request, (o dati in una

trasmissione connection less) deve sapere a quale applicazione trasmetterli

E’ necessario quindi associare univocamente ad una applicazione un punto di accesso al trasporto

In pratica si devono utilizzare indirizzi a livello di trasporto, per identificare l’applicazione destinataria dei dati

Questi indirizzi in OSI sono chiamati TSAP (Transport Service Access point)

in TCP/IP esiste una cosa equivalente: in questo caso gli indirizzi sono chiamati porte

26

Quale TSAP?

Un applicativo server deve quindi registrarsi presso il protocollo di trasporto (tramite la primitiva LISTEN) per creare la associazione “applicazione-TSAP”

L’applicativo client, per connettersi con il server, deve sapere a priori a quale TSAP remoto (di quale NSAP remoto, cioe’ di quale indirizzo di rete) connettersi

Per conoscere l’NSAP, generalmente esiste un applicativo di conversione nome-indirizzo che risolve questo problema (si presuppone che almeno si conosca il nome)

in OSI si chiama servizio di directory (X.500) in TCP/IP si chiama Domain Name System

Per conoscere il TSAP si puo’ (parzialmente) utilizzare un sistema simile

27

TSAP “ben noti”

La soluzione adottata usualmente e’ quella di associare sempre lo stesso TSAP a tutte le applicazioni server (sui diversi host) che svolgono la stessa funzione

server web server di posta elettronica server di connessione remota server di sincronizzazione oraria server di file transfer

L’applicativo client in questo modo puo’ specificare al livello di trasporto a quale TSAP di quale host deve essere fatta la connessione, in quanto il TSAP e’ predefinito dallo standard dell’applicativo server

28

TSAP ad hoc I TSAP ben noti sono quelli che offrono servizi standardizzati

servizi che rispondono ad un protocollo ben definito generalmente lo standard specifica il TSAP da utilizzare (piu’

spesso si limita a suggerirlo) in TCP/IP esiste un sistema che, analogamente al DNS, associa

una stringa di caratteri alle porte dei servizi, ma a differenza del DNS non e’ distribuito: le associazioni si trovano in un file di testo residente sull’host e letto dagli applicativi (/etc/services in unix-linux)

Se si devono utilizzare applicativi sviluppati per funzioni specifiche, la strategia da utilizzare e’ quella di definire un TSAP per questo servizio sulle sole macchine interessate dalla applicazione

il client in qualche modo deve essere messo al corrente del TSAP da utilizzare

buona norma e’ quella di non utilizzare TSAP assegnati ai servizi standardizzati