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)

5 Primitive di servizio Le primitive di servizio costituiscono l’interfaccia che lo strato di trasporto rende disponibile allo strato superiore Per il servizio connection oriented si possono elencare in LISTEN: lo strato superiore notifica al trasporto che e’ pronto a ricevere una connessione CONNECT: lo strato superiore chiede allo strato di trasporto di effettuare una connessione (si traduce nell’invio da parte del trasporto di un messaggio “Connection Request” al destinatario) SEND: lo strato superiore chiede al trasporto di inviare dati RECEIVE: lo strato superiore chiede allo strato di trasporto di trasmettergli i dati in arrivo DISCONNECT: lo strato superiore chiede di chiudere la connessione (si traduce nell’invio da parte dello strato di trasporto di un messaggio “Disconnection Request”) Per il servizio connection less, le due primitive SEND e RECEIVE possono essere sufficienti

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 ACK e 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