Reti di Calcolatori, A.A. 2005/06 M. Cesati / E.

Betti

Reti di calcolatori

Lezione 8
Lez. 8 — 1 M. Cesati / E. Betti

Il modello di riferimento

5 Application
4 Transport
3 Network
2 Data Link
1 Fisico
Lez. 8 — 2 M. Cesati / E. Betti

Schema generale della trasmissione

Nei livelli Network, Data Link e Fisico esistono tre distinte entità indipendenti
(hardware o software) che comunicano tra loro scambiandosi messaggi tramite le
opportune interfacce

1. L’entità di livello Network passa un pacchetto all’entità di livello Data Link

2. L’entità Data Link prepara un frame aggiungendo una testata ed una coda con-
tenenti informazioni di controllo
3. L’entità Data Link calcola il checksum del frame e lo inserisce in un opportuno
campo nella testata o nella coda del frame
4. L’entità Data Link passa il frame all’entità del livello Fisico
5. L’entità Fisico invia il frame per mezzo del canale di comunicazione
Lez. 8 — 3 M. Cesati / E. Betti

Schema generale della ricezione

1. L’entità Fisico riceve una sequenza di bit dal canale di comunicazione e la passa
all’entità Data Link

2. L’entità Data Link estrae il frame dalla sequenza di bit

3. L’entità Data Link calcola il checksum del frame e lo controlla con il checksum
nell’opportuno campo nella testata o nella coda del frame

4. L’entità Data Link:

• se il frame ha errori, adotta una opportuna procedura (ad esempio scarta il
frame ed eventualmente trasmette un ack negativo)
• se il frame è corretto, estrae il pacchetto dal frame rimuovendo la testata e la
coda e lo passa all’entità Network
Lez. 8 — 4 M. Cesati / E. Betti

Gestione sequenza di trasmissione e flusso (1)

Oltre alla costruzione dei frame ed alla rilevazione/correzione degli errori, il livello
Data Link può gestire

• il flusso dei frame (per evitare che il calcolatore ricevente sia sovraccaricato)

• la sequenza di trasmissione dei frame (soprattutto per evitare che frame duplicati
siano passati al livello Network ricevente)

Questi due obiettivi sono spesso ottenuti utilizzando un singolo protocollo

Lez. 8 — 5 M. Cesati / E. Betti

Gestione sequenza di trasmissione e flusso (2)

Le funzioni effettivamente svolte dal livello Data Link dipendono in realtà dal tipo di
servizio offerto:

• affidabile: controllo che i frame arrivino tutti, senza errori e senza duplicazioni
• non affidabile: controllo che i frame arrivati non contengano errori (quelli con
errori vengono semplicemente scartati; questo di solito è “gratis” perché imple-
mentato in hardware)

Si assume che il livello Data Link non ha mai necessità di spezzare un pacchetto del
livello Network in più frame

In pratica, i protocolli affidabili del livello Data Link sono anche connection-oriented
e garantiscono che i pacchetti raggiungono il livello Network della macchina destina-
zione nello stesso ordine in cui sono stati trasmessi dal livello Network al livello Data
Link della macchina sorgente
Lez. 8 — 6 M. Cesati / E. Betti

Acknowledgement

L’acknowledgement (ack) o conferma è un messaggio inviato dal ricevente al

trasmittente per informarlo che

• un frame è arrivato correttamente (positive ack)

• un frame è arrivato con errori (negative ack)

I messaggi di ack possono essere inviati come

• singoli frame (frame ack)

• all’interno di opportuni campi della testata dei frame normali (frame dati)

Il meccanismo di acknowledgement dei frame fallisce in caso di scomparsa di frame

Lez. 8 — 7 M. Cesati / E. Betti

Scomparsa di frame dati

Problema: un frame di dati è trasmesso ma scompare completamente; il ricevente

non invia nulla perché non deve dare alcuna conferma; il trasmittente aspetta una
conferma (negativa o positiva) che non arriverà mai

Soluzione: il trasmittente stabilisce, per ciascun frame dati, un termine utile entro il
quale deve arrivare il relativo ack. Se l’ack non arriva in questo periodo di tempo, il
frame dati viene ritrasmesso
Lez. 8 — 8 M. Cesati / E. Betti

Scomparsa di frame ack

Problema: un frame di ack scompare del tutto; il trasmittente, dopo aver aspettato in-
vano la conferma, invia un secondo frame di dati identico al precedente; il destinatario
riceve un frame dati duplicato

Soluzione: il trasmittente inserisce un numero di sequenza all’interno di ciascun fra-

me dati; il ricevente scarta tutti i frame aventi lo stesso numero di sequenza di quello
precedentemente ricevuto
Lez. 8 — 9 M. Cesati / E. Betti

Controllo del flusso

Il meccanismo degli acknowledgement è utile anche per il controllo del flusso di

trasmissione

Una strategia per il controllo del flusso consiste nell’attesa di una autorizzazione
esplicita del destinatario all’invio di nuovi frame

Questa comunicazione può essere inserita all’interno di un frame ack che conferma
la corretta ricezione di un frame dati precedente
Lez. 8 — 10 M. Cesati / E. Betti

Struttura (semplificata) di un frame

Nell’analisi dei protocolli di trasmissione e flusso del livello Data Link è utile far
riferimento ad un frame convenzionale:

kind seq ack info chk

• kind: tipo di frame (dati o ack)

• seq: numero di sequenza del frame

• ack: informazioni legate all’acknowledgement

• info: il messaggio (pacchetto del livello Network)

• chk: checksum del frame

Lez. 8 — 11 M. Cesati / E. Betti

Protocolli unidirezionali

Prendiamo in considerazione alcuni schemi di protocolli del livello Data Link per il
controllo di trasmissione e flusso:

• Protocollo utopia

• Protocollo simplex stop-and-wait

• Protocollo PAR
Lez. 8 — 12 M. Cesati / E. Betti

Protocollo utopia

Il protocollo utopia è il più semplice possibile. Si assume che:

• i dati sono spediti in una sola direzione

• il livello Network trasmittente è sempre pronto ad inviare dati

• il livello Network ricevente è sempre pronto a ricevere dati

• il livello Data Link ha a disposizione buffer di dimensione infinita

• il tempo necessario per analizzare i frame è trascurabile

• il canale di comunicazione (ossia il livello Fisico) è esente da errori e non perde

alcun frame
Lez. 8 — 13 M. Cesati / E. Betti

Protocollo utopia – Trasmissione

La procedura logica eseguita dall’entità del livello Data Link trasmittente:

while (true) {
receive_network(packet);
frame = build_frame(packet);
send_physical(frame);
}

Viene utilizzato il campo info del frame, non vengono utilizzati i campi di controllo
kind, ack, seq e chk
Lez. 8 — 14 M. Cesati / E. Betti

Protocollo utopia – Ricezione

La procedura logica eseguita dall’entità del livello Data Link ricevente:

while (true) {
wait_data_physical(buffer);
frame = extract_frame(buffer);
packet = extract_packet(frame);
send_network(packet);
}

Notare che il canale di comunicazione deve essere wire-like: due bit spediti uno dopo
l’altro devono essere ricevuti nello stesso ordine
Lez. 8 — 15 M. Cesati / E. Betti

Protocollo utopia – Svantaggi

La assunzione meno realistica del protocollo utopia:

• il livello Network ricevente è in grado di accettare pacchetti a qualunque velocità

o equivalentemente:

• il livello Data Link ricevente ha a disposizione un buffer per i frame ricevuti di

dimensione infinita

Un protocollo più evoluto del protocollo utopia è in grado di controllare il tasso di

trasmissione dei frame per evitare il sovraccarico del ricevente
Lez. 8 — 16 M. Cesati / E. Betti

Ritardo fissato in trasmissione

Per risolvere il problema della congestione del ricevente si può introdurre un ritardo
fissato tra l’invio di un frame ed il successivo

Questo approccio è conveniente solo in casi molto particolari (ad esempio, reti di
comunicazioni sincrone con ricevente ben dimensionato)

In generale è da scartare:

• l’intervallo temporale tra la ricezione di un frame e la sua trasmissione a livello

Network può variare considerevolmente

• se il progettista della rete imposta il ritardo di trasmissione dei frame sul caso
peggiore, la rete di comunicazione è sotto-utilizzata
Lez. 8 — 17 M. Cesati / E. Betti

Protocollo simplex stop-and-wait

Si assume che:

• i dati sono spediti in una sola direzione (ma i frame devono poter viaggiare in
entrambe le direzioni!)

• il canale di comunicazione (ossia il livello Fisico) è esente da errori e non perde

alcun frame

Il più semplice protocollo simplex stop-and-wait è basato sull’invio di un frame ack

ogni volta che un pacchetto è stato trasmesso con successo all’entità Network rice-
vente

Il canale di comunicazione deve essere half-duplex o full-duplex

Lez. 8 — 18 M. Cesati / E. Betti

Protocollo simplex stop-and-wait – Trasmissione

La procedura logica eseguita dall’entità del livello Data Link trasmittente:

while (true) {
receive_network(packet);
frame = build_frame(packet);
send_physical(frame);
wait_data_physical(buffer);
}
Lez. 8 — 19 M. Cesati / E. Betti

Protocollo simplex stop-and-wait – Ricezione

La procedura logica eseguita dall’entità del livello Data Link ricevente:

while (true) {
wait_data_physical(buffer);
frame = extract_frame(buffer);
packet = extract_packet(frame);
send_network(packet);
frame = build_frameack();
send_physical(frame);
}
Lez. 8 — 20 M. Cesati / E. Betti

Protocollo simplex stop-and-wait + timer (1)

Nessun canale di comunicazione reale è del tutto privo di errori

⇒ la assunzione meno realistica del protocollo simplex stop-and-wait è che ogni

frame trasmesso venga ricevuto correttamente

L’uso di un timer (da parte dell’entità trasmittente) e di checksum insieme al protocollo

simplex stop-and-wait sembra essere sufficiente:

• quando il trasmittente invia un frame, fa partire un timer

• se non arriva il relativo frame ack entro la scadenza del timer, il trasmittente invia
nuovamente il frame

• il ricevente invia un frame ack solo quando riceve un frame senza errori
Lez. 8 — 21 M. Cesati / E. Betti

Protocollo simplex stop-and-wait + timer (2)

Lo svantaggio principale del protocollo simplex stop-and-wait unito con l’uso del timer
è che l’entità Data Link ricevente non è in grado di gestire i pacchetti duplicati

Infatti, tutti i pacchetti duplicati vengono trasmessi al livello Network:

• Il trasmittente invia un frame dati

• Il destinatario riceve il frame dati correttamente, ed invia il frame ack
• Il trasmittente non riceve il frame ack
• Scaduto il timer, il trasmittente invia per la seconda volta il frame dati
• Il destinatario riceve il frame dati correttamente, ed invia il frame ack
• Il trasmittente riceve il frame ack

Lo stesso pacchetto è stato passato al livello Network ricevente due volte

Lez. 8 — 22 M. Cesati / E. Betti

Protocollo PAR

È necessario aggiungere al protocollo simplex stop-and-wait con timer la capacità

del livello Data Link destinatario di distinguere frame dati già ricevuti in precedenza

Ciò che si ottiene è un protocollo PAR (Positive Acknowledgement with Retransmis-

sion), anche chiamato protocollo ARQ (Automatic Repeat Request)

Il metodo più semplice per distinguere i frame dati consiste nel memorizzare nel
campo seq della testata del frame un numero di sequenza, incrementato automati-
camente dal livello Data Link trasmittente per ciascun diverso frame dati

Quando il destinatario riceve un frame dati con lo stesso numero di sequenza del
frame ricevuto in precedenza, riconosce un frame duplicato e lo scarta
Lez. 8 — 23 M. Cesati / E. Betti

Protocollo PAR – Numeri di sequenza

Quanti bit devono essere riservati nella testata del frame per il campo seq?

Nel caso di protocolli di tipo PAR, un frame dati è inviato solo dopo la ricezione del
frame ack relativo al frame dati inviato prima

Se dunque il livello Data Link ha ricevuto un certo frame con numero di sequenza m,
il prossimo frame dati che riceverà potrà solo essere:

m + 1 in caso di ricezione corretta del frame ack, oppure

m in caso di perdita del frame ack

Sono sufficienti due soli numeri di sequenza, quindi seq può essere costituito da un
singolo bit
Lez. 8 — 24 M. Cesati / E. Betti

Protocollo PAR – Trasmissione

La procedura logica eseguita dall’entità del livello Data Link trasmittente:

seq = 0; receive_network(packet);
while (true) {
frame = build_frame(packet,seq);
send_physical(frame);
timed_wait_data_physical(buffer);
if (frame_arrival) {
frame = extract_frame(buffer);
if (checksum(frame) && frame.ack == seq) {
receive_network(packet);
seq = 1 - seq;
}
}
}
Lez. 8 — 25 M. Cesati / E. Betti

Protocollo PAR – Ricezione

La procedura logica eseguita dall’entità del livello Data Link ricevente:

seq = 0;
while (true) {
wait_data_physical(buffer);
frame = extract_frame(buffer);
if (checksum(frame)) {
if (frame.seq == seq) {
packet = extract_packet(frame);
send_network(packet);
seq = 1 - seq;
}
frame = build_frameack(1 - seq);
send_physical(frame);
}
}
Lez. 8 — 26 M. Cesati / E. Betti

Protocollo PAR – Normale funzionamento

Mittente Destinatario

1
x→
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh

← ack(1) 1
h
( ( ( ((((
((( (
(((((
((( ((((
(
(((((

0
→
hhhh
hhhh
hhhh
hhhh x+1
hh hhh
hhh
hhhh

← ack(0) 0
h
(((
((( (((
(((
(( (((
( (((
((((
(((
(
1
x+2 →
hhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
1
h
h

ecc.
Lez. 8 — 27 M. Cesati / E. Betti

Protocollo PAR – Errore su frame dati

Mittente Destinatario

1
x→
hhhh

hhhh

*

hhh
h






Timeout

A
A
A
A
1AA
x→
hhh
hhh
hhhh
hhhh
hhhh
hhhh
hhhh

← ack(1) 1
hh
h
(( (((
( (((((
((((
((((
(((
(((
(((
(
0
→
hhhh
hhhh
hhhh
hhhh x+1
hh hhhh
hhhh
0
hh
h

ecc.
Lez. 8 — 28 M. Cesati / E. Betti

Protocollo PAR – Errore su frame ack

Mittente Destinatario

1
x→
hhhh

hhhh

hhhh
hhhh

hhhh

hhhh
hhhh

← ack(1) 1

h
((((
Timeout

A
((((
((( ( ( ( (
(
A
(( ((((
((((

*
A
A
1AA
x→
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh

← ack(1) 1 (non passato al liv. Network)

h
(((
((((((
(((
(((((
( (((
((((
(((
(
0
x+1 →
hhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
0
h
h

ecc.
Lez. 8 — 29 M. Cesati / E. Betti

Protocollo PAR – Lunghezza del timer

La scelta dell’intervallo a cui impostare il timer per la ri-trasmissione è critica

• se il valore del timer è troppo lungo, il protocollo è inefficiente perché ogni frame
ack perso provoca lunghi “stalli”

• se il valore del timer è troppo corto, il mittente può ri-trasmettere un frame dati
mentre il frame ack atteso sta per essere correttamente ricevuto

L’ultimo scenario è particolarmente disastroso se l’entità Data Link trasmittente non

ha modo di associare ciascun frame ack al numero di sequenza del relativo frame
dati

Perciò il campo ack del frame ack contiene il numero di sequenza del frame dati a
cui l’acknowledgement si riferisce
Lez. 8 — 30 M. Cesati / E. Betti

Protocollo PAR (ack anonimo) – Timeout troppo corto

Mittente Destinatario

1
x→
hhhh
hhhh


hhhh
hhhh

hhhh
Timeout
hhhh
hhhh

← ack() 1
A h
((((
A  ( (
1 ( (
AA (((
((((
x→
hhhh (
hhhh
( ( ((((
(h
( h h
((((( hhhh


hhhh

0 hhhh
hhhh

x+1 →
hhhh
1 (non passato a liv. Network)
hhhh hh
(
((((
← ack()
hhh ( ( (
hhh (((
h (h
(h
( ((h hhh

*
( ( ( hh
( ( (
( ( (((
((


1
x+2 →
hhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh

← ack()
h
h
((((
(((
(( ( ( ( (
1 (non passato a liv. Network)
(((
((((
((((
((((
(

0
x+3 →
hhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
0
h
(h
(
((( ((((
ecc.
Lez. 8 — 31 M. Cesati / E. Betti

Protocollo PAR (ack anonimo) – No ack su frame duplicati

Mittente Destinatario

1
x→
hhhh

hhhh

hhhh
hhhh

hhhh

hhhh
hhhh

← ack() 1

h
((((
Timeout

A
((((
((( ( ( ( (
(
A
(( ((((
((((

*
A
A
1AA
x→
hhhh

hhhh

hhhh
hhhh

hhhh

hhhh
hhhh
1 (non passato al liv. Network)

h
Timeout

A
A
A
A
1AA
x→
hhhh

hhhh

hhhh
hhh

hhhh

hhhh
hhhh
1 (non passato al liv. Network)

h
h
Timeout

A
AA

ecc.
Lez. 8 — 32 M. Cesati / E. Betti

Protocollo PAR (ack con numero) – Timeout troppo corto

Mittente Destinatario

1
x→
hhhh
hhhh


hhhh
hhhh

hhhh
Timeout
hhhh
hhhh

← ack(1) 1
A h
((((
A  ( (
1 ( (
AA (((
((((
x→
hhhh (
hhhh
( ( ((((
(h
( h h
((((
( hhhh


hhhh
0 hhhh
hhhh

x+1 →
hhhh
1 (non passato a liv. Network)
h hh
(



h h hhhh ((((
← ack(1) hhh ( ( (
h (h
(h(((

((h
Timeout
( hhh

*

( ( ( hh
( ( (
A ( ( (((
A (
(
0
x+1 →
AA
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh
hhhh

← ack(0)
h
(
((( ( ( ( ( ( ( (((
0
( ( ((((
(
((((
((((
(

1
→
hhhh
hhhh
hhhh
hhhh x+2
hh hhhh
hhhh
1
hh
h
( ( ( (((
(((
ecc.