Sei sulla pagina 1di 7

Il Livello Trasporto Servizi e protocolli di Trasporto

Obiettivi: Panoramica: r Forniscono una comunicazione application

logica tra i processi transport


r Comprendere i principi r Servizi del livello trasporto network
data link

costitutivi dei servizi del applicativi in esecuzione su physical


network

r multiplexing/demultiplexing data link

Tr
lievello trasporto: host differenti network physical

as
data link

po
r trasporto connectionless : UDP physical

rto
m multiplexing/demultiplex r I protocolli di trasporto network
r principi del trasferimento dati agiscono sugli end systems data link

log
ing physical network
affidabile

ico
data link
m Trasf . dati affidabile r Servizi di trasporto e di rete: physical

en
r Trasporto connection-oriented :

dt
m controllo flusso Livello network: network

oe
r data link
TCP

nd
physical
m controllo congestione trasferimento dati tra end
m trasferimento affidabile
r Realizzazione in systems application

m controllo del flusso transport


Internet r Livello trasporto : network

m Management della connessione data link


trasferimento dati tra physical

r principi controllo congestione processi


r controllo congestione del TCP m Si appoggia su, e migliora , i
servizi di livello network
LivelloTrasporto 3a-1 LivelloTrasporto 3a-2

Protocolli del Livello Trasporto Multiplexing/demultiplexing


Servizi di trasporto Internet: application
Segmento – unità di dati
transport Demultiplexing : consegna dei
r Consegna affidabile e network
data link network
scambiati tra entità di segmenti ricevuti ad opportuni
ordinata di tipo unicast physical data link livello trasporto processi di livello applicazione
Tr

network physical
(TCP)
as

m TPDU: transport
data link
po

physical
rto

m congestione
protocol data unit
network
data link
ricevente
log

m Controllo del flusso physical network


ico

data link
P3 P4
m setup della connessione physical
Dati del livello
en

M M
dt

network applicazione
r Consegna inaffidabile
oe

data link
application
nd

physical
(“best-effort”), disordinata header P1 transport P2
segmento M
di tipo unicast o multicast: application M network
transport application application
UDP network
segmento transport
data link Ht M transport
network
r servizi non disponibili: physical Hn segment network

m real-time
m garanzia sulla banda
m multicast affidabile
LivelloTrasporto 3a-3 LivelloTrasporto 3a-4

Multiplexing/demultiplexing Multiplexing/demultiplexing: esempi


Multiplexing:
raccolta dati dai processi di 32 bits
applicazione, imbustamento
dati con header (poi usati source port # dest port #
per il demultiplexing)
altri campi header
multiplexing/demultiplexing:
r Basati sui numeri di porta e
gli indirizzi IP del mittente
dati
e del destinatario
applicazione
m porte di source, dest in
(messaggi)
ogni segmento
m Porte well-known per
applicazioni specifiche Formato del segmento
TCP/UDP

LivelloTrasporto 3a-5 LivelloTrasporto 3a-6

1
Multiplexing/demultiplexing: esempi UDP: User Datagram Protocol [RFC 768]

r Il protocollo di trasporto di
Internet “senza fronzoli” Perchè esiste UDP?
r Servizio “best effort”, i
r Non occore stabilire una
segm. UDP possono essere: connessione (meno ritardi)
m persi
r semplicità: non occorre
m Consegnati all ’appl. fuori gestire la connessione
ordine r L’header del segmento è
r connectionless: piccolo
m non c ’è handshaking tra r Non c ’è controllo della
mittente e destinatario congestione : l ’UDP può
UDP spedire dati tanto
m ogni segmento UDP velocemente quanto lo si
viene trattato desidera
separatamente dagli
altri

LivelloTrasporto 3a-7 LivelloTrasporto 3a-8

UDP (2) UDP checksum


r Spesso è utilizzato per le Obiettivo: rilevare “errori” (per es., bit invertiti ) nei
applicazioni con streaming 32 bits
multimedia che sono segmenti trasmessi
Lung. in source port # dest port #
m loss tolerant
bytes length checksum
m rate sensitive segmento Mittente: Destinatario:
r Calcola il checksum del
r Altri usi UDP: UDP, header r contenuti del segmento
compreso trattati come sequenze di segmento ricevuto
mDNS
interi a 16-bit r Verifica se il checksum
m SNMP
r checksum: somma (in calcolato è uguale al valore
r Trasferimento affidabile dati dell’applicazione del campo checksum:
complemento a 1) dei
con UDP: aggiungere il (messaggi)
contenuti del segmento m NO – errore rilevato
controllo dell ’affidabilità al r Il mittente inserisce il m YES - nessun errore
livello applicazione
valore del checksum nel rilevato (non vuol dire che
m Recupero dell’errore non ci siano errori …)
campo checksum del
specifico per formato segmento UDP pacchetto UDP
l’applicazione!

LivelloTrasporto 3a-9 LivelloTrasporto3a-10

Principi di trasferimento affidabile Reliable data transfer (1)


r Importante per i livelli applicazione, trasporto, data link rdt_send(: invocata dal liv. sup., deliver_data(): invocata
r È nella top-10 delle problematiche di rete importanti! (per es., dall’ appl.). Passa i dati da dalla rdt per consegn. dati
inviare ai livelli sup. del destin.

Lato Lato
invio ricezione

udt_send(): invocata da rdt rdt_rcv (): invocata quando i


r Le caratteristiche di un canale inaffidabile determinano la per trasferire pacchetti al pacchetti arrivano al lato ricezione
complessità di un protocollo per il trasferimento affidabile dest. sul canale inaffidabile
dei dati (rdt – reliable data transfer)
LivelloTrasporto3a-11 LivelloTrasporto3a-12

2
Reliable data transfer: Introduzione Rdt1.0: trasferim. affidabile su canale affidabile
r Sviluppiamo incrementalmente le parti r Il canale sottostante è perfettamente affidabile
mittente e destinatario di un protocollo rdt m Non ci sono errori nei bit
r Consideriamo solo trasferimenti m Non si perdono pacchetti
monodirezionali r FSMs separate per mittente e destinatario:
m ma le info di controllo vanno in ambedue le direzioni! m Il mittente invia dati nel canale sottostante
r mittente e destinatario come macchine a stati m Il destinatario legge dati dal canale sottostante
finiti
evento che causa la transizione
azioni intraprese per la transizione
stato: se siamo in
questo “stato ” il stato Stato
1 evento
prossimo stato è 2
univocamente azioni
determinato dal
prossimo evento
LivelloTrasporto3a-13 LivelloTrasporto3a-14

Rdt2.0: canale con errori sui bit rdt2.0: specifica delle FSM
r Il canale può alterarei bits del pacchetto
m il checksum UDP usato per rilevaregli errori sui bit
r la questione: come recuperare gli errori :
m acknowledgements (ACKs): il destinatario dice
esplicitamenteal mittenteche il pkt ricevuto è OK
m negative acknowledgements (NAKs): il destinatario dice
esplicitamenteal mittenteche il pkt ricevuto ha errori
m Il mittente ritrasmette i pkt se riceve un NAK
m Un esempio umano che usa ACK e NAK?
r Nuovi meccanismi nel rdt2.0 (rispetto a rdt1.0):
m Rilevamento errori
m Feedback del destinatario: msg di controllo (ACK,NAK)
dal dest->mitt
FSM del mittente FSM del destinatario
LivelloTrasporto3a-15 LivelloTrasporto3a-16

rdt2.0: in azione (nessun errore) rdt2.0: in azione (scenario errori)

FSM del mittente FSM del destinatario FSM del mittente FSM del destinatario
LivelloTrasporto3a-17 LivelloTrasporto3a-18

3
rdt2.0 rdt2.1: gestione ACK/NAK corrotti

Che succede se si altera Trattamento duplicati :


un ACK/NAK? r il mitt. aggiunge sequence lato
r Il mitt. non sa cosa è
accaduto al dest.!
number a ciascun pkt
r il mitt. ritrasmette il pkt
mittente
r Non può ritrasmettere e corrente se ACK/NAK
basta: possibili duplicati corrotti
r dest. scarta (non consegna
Che fare? ai livelli superiori) i pkt
r ACK/NAK del mittente e duplicati
ACK/NAK del dest? Che
succede se si perde un stop and wait
ACK/NAK del mittente? il mittente invia un solo
r ritrasmettere, ma si pacchetto e poi attendela
possono ritrasmettere risposta del destinatario
pacchetti ricevuti
correttamente!
LivelloTrasporto3a-19 LivelloTrasporto3a-20

rdt2.1: gestione ACK/NAK corrotti rdt2.1: discussione


lato
Mittente: Destinatario:
destinatario
r aggiunta di seq# al pkt r Deve controllare se i l
pacchetto ricevuto è
r bastano due seq# (0,1)
un duplicato
Perchè? m lo stato indica se il seq
r deve controllare se # del pacchetto atteso
deve essere 0 o 1
vengono ricevuti
ACK/NAK corrotti r nota: i l dest. non può
sapere se i l suo ultimo
r Il doppio degli stati ACK/NAK è stato
m lo stato deve ricevuto
“ricordare” se il pkt correttamente dal
“corrente” ha seq# 0/1 mittente

LivelloTrasporto3a-21 LivelloTrasporto3a-22

rdt2.2: un protocollo NAK -free rdt3.0: canali con errori e perdite


FSM
r stesse funzionalità di Nuova ipotesi: il canale Un approccio: il mittente
Mittente attende un “ragionevole”
rdt2.1, usando solo ACK sottostante può anche
ammontare di tempo per un
r invece di NAK, i l dest. smarrire pacchetti (sia ACK
invia ACK per l’ ultimo dati che ACK) r Ritrasmette se non riceve ACK
pkt ricevuto OK m checksum, seq. #, ACK, entro questo tempo
ritrasmissioni sono di r se il pkt (o l’ACK) era solo in
m il dest. deve includere
esplicitamenteil seq # aiuto ma non bastano ritardo (non smarrito):

del pkt di cui fa l’ACK D: come gestire gli m la ritrasmissione genera un


! smarrimenti?
duplicato ma i seq. # sono già
r un ACK duplicato in grado di gestirlo
provoca dal mittente la m il dest. Deve specificare il

stessa azione di un seq # del pkt di cui fa ACK


r Ci vuole un countdown timer
NAK: ritrasmetti il pkt

LivelloTrasporto3a-23 LivelloTrasporto3a-24

4
rdt3.0 Mittente rdt3.0 in azione

LivelloTrasporto3a-25 LivelloTrasporto3a-26

rdt3.0 in azione Performance del rdt3.0

r rdt3.0 funziona, ma le prestazioni sono molto basse!


r esempio: link da 1 Gbps, ritardo prop. 15 ms e-e, pacchetto 8KB :

8kb/pkt
T Trasm. = = 8 microsec
10**9 b/sec
frazione del tempo 8 microsec
Utilizzazione = U =mitt. impegn. spedire= = 0.00015
30.016 msec

m 1KB pkt ogni 30 msec -> 33kB/sec throughput su un link 1 Gbps


m Il protocollo limita l ’uso delle risorse fisiche (teoricamente
potrei andare a 128MB/sec!!!).

LivelloTrasporto3a-27 LivelloTrasporto3a-28

Protocolli Pipelined Go-Back-N


Pipelining: i l mittente accetta l’ esistenza di molti Mittente:
pacchetti “in viaggio”, non ancora riscontrati r k-bit seq # nell ’header del pkt

m L’intervallo di numeri di sequenza s i deve incrementare r “finestra” consentita di (al massimo) N pacchetti consecutivi non
riscontrati
m Bufferizzazione al mittente e/o al destinatario

r ACK(n): riscontra tutti i pkts fino a seq # n - “ACK cumulativo”


m può nascondere ACK duplicati (vedi destinatario)
r Due generiche forme di protocolli pipelined: r Un solo timer
r timeout(n): ritrasmetti il pkt n e tutti i pacchetti con seq #
go-Back-N, selective repeat maggiori nella finestra
LivelloTrasporto3a-29 LivelloTrasporto3a-30

5
GBN: FSM estesa del mittente GBN: FSM estesa del destinatario

Destinatario semplice:
expectedseqnum++;

r ACK-only: invia sempre un ACK per i l pkt


correttamente ricevuto col pi ù alto seq # in-ordine
m può generare ACK duplicati
m deve solo ricordareexpectedseqnum
r Pkt fuori ordine :
m scarta (non bufferizza) -> non c’è buffer al destinatario!
m dai un ACK per il pkt con il più alto seq # in ordine

LivelloTrasporto3a-31 LivelloTrasporto3a-32

GBN in Selective Repeat


azione
r destinatario riscontra individualmente tutti i pkt
correttamente ricevuti
m Bufferizza i pkt, come necessario, per poterli alla fine
consegnare in ordine al livello superiore
r mittente re-invia solo i pkt per i quali non riceve
ACK
m timer del mittente per ciascun pkt non riscontrato
r Finestra del mittente
m N seq # consecutivi
m Limita di nuovo i seq # dei pkt inviati e non riscontrati

LivelloTrasporto3a-33 LivelloTrasporto3a-34

Selective repeat: finestre mittente/destin. Selective repeat


sender receiver
Dati dall’ alto: pkt n in [rcvbase, rcvbase+N-1]
r Se c’è un seq # disponibile r invia ACK(n)
nella finestra, invia pkt r Fuori ordine: buffer
timeout(n): r In ordine: consegna, avanza
r reinvia pkt n, riavvia timer la window al prossimo pkt
non ancora ricevuto
ACK(n) in [sendbase,sendbase+N ]:
pkt n in [rcvbase-N,rcvbase-1]
r segna pkt n come ricevuto
r ACK(n)
r if n è il più piccolo unACKed
pkt, avanza window base al altrimenti:
prossimo unACKed seq # r ignora

LivelloTrasporto3a-35 LivelloTrasporto3a-36

6
Selective repeat:
Selective repeat in azione un dilemma
Esempio:
r seq #: 0, 1, 2, 3
r window size=3

r Il destinatario non
distingue le due
situazioni!
r in (a) sbaglia e
considera come nuovi
pkt i duplicati

Q: che relazione tra la


dimensione dei seq # e
quella della window?
R: Win_size <=
MaxSeq_range#/2

LivelloTrasporto3a-37 LivelloTrasporto3a-38

Potrebbero piacerti anche