capitolo 8 data link layer

CAPITOLO 8
DATA LINK LAYER
.
1
8. DATA LINK LAYER
I PROTOCOLLI DI LINEA (Data Link Layer Protocol) relativi al DATA LINK LAYER (DLL), ossia il
secondo livello dell’architettura di riferimento ISO/OSI, gestiscono il colloquio tra entità
fisicamente connesse (link), riducendo il tasso di errore introdotto dal mezzo di comunicazione
fisico.
Quindi il ruolo del DLL è quello di fornire i mezzi funzionali e procedurali per il trasferimento
trasparente, affidabile ed efficiente di unità dati tra le NETWORK LAYER ENTITY, nascondendo i
dettagli su come le risorse di comunicazione, fornite dal PHYSICAL LAYER, sono usate per fornire il
servizio.
Se si considera una linea punto-punto o una linea multipunto, opportunamente regolata attraverso
un meccanismo di polling-selecting, il DATA LINK LAYER non ha bisogno di risolvere il problema
della contesa per l’accesso al mezzo di comunicazione comune.
Viceversa nelle reti ad accesso comune, il DATA LINK LAYER risolve la contesa suddividendosi in
due sottolivelli:
il sublayer inferiore MAC (Medium Access Control) che si considera come un incremento del
Physical Layer e
il sublayer superiore LLC (Logicol Link Control) che svolge le funzionalità di linea.
Quindi, le funzionalità di linea, che esamineremo in questa sezione, riguardano il DLL o il sublayer
LLC del DLL per reti ad accesso comune.
L’insieme delle problematiche che il DATA LINK LAYER deve risolvere sono:
•
•
•
•
•
•
•
•
framing (definizione del formato dei messaggi);
sincronizzazione;
trasparenza dei dati;
controllo di errore;
controllo di sequenza;
recupero degli errori;
controllo di flusso;
gestione del collegamento;
I protocolli di linea si distinguono in
1.
CHARACTER-ORIENTED
2.
BIT-ORIENTED,
a secondo se l’unità informativa della frame (le PDU (PROTOCOL DATA UNIT) del DATA LINK
LAYER vengono dette frame, mentre le PDU del NETWORK LAYER vengono dette Packet; per gli
altri livelli si parla solo di N-PDU), è un insieme di caratteri (byte) opportunamente codificati (ad
esempio con codifiche ASCII e EBCDIC), o un flusso continuo di bit.
Il primo protocollo CHARACTER-ORIENTED fu il BSC (Binary Synchronous Control) trattato qui di
seguito nel paragrafo 8.6 .
Un’altra classificazione che si suole fare è quella di distinguere i protocolli di linea, in
a) SINCRONI
b) ASINCRONI.
La differenza, in questo caso, dipende dal fatto che i clock delle peer entity siano o meno
sincronizzati. Per essere precisi, l’entità ricevente, per interpretare correttamente il messaggio
speditole, deve essere in grado di determinare:
⇒ l’inizio di ogni bit (bit or clock synchronization),
2
⇒ l’inizio e la fine di ogni carattere (character or byte synchronization) e
⇒ l’inizio e la fine della frame (block or frame synchronization).
Nei protocolli asincroni, i due interlocutori ottengono la SINCRONIZZAZIONE A LIVELLO DI CARATTERE
introducendo dei pattern di bit opportuni (detti start e stop bits) per delimitare caratteri successivi.
Mentre la FRAME SYNCHRONIZATION, per entrambi i protocolli, è ottenuta incapsulando la frame
all’interno di opportuni delimitatori.
I protocolli moderni sono tutti bit oriented e sincroni; di seguito faremo riferimento a protocolli
sincroni bit oriented o character oriented.
8.1 Framing
Il FRAMING consiste nell’organizzare il flusso di dati entrante in frame (trame), aventi un opportuno
e ben definito formato: quindi bisogna determinare non solo la dimensione di ogni campo della
frame, ma anche il tipo di codifica usata. Il formato varia chiaramente da protocollo a protocollo;
comunque, una struttura di carattere generale potrebbe essere quella mostrata in Fig. 8.1-1.
Synchonization Address Control Data Field Error Check Synchonization
Field
Field
Field
(Packet)
Field
Field
Fig. 8.1-1: Formato della frame.
IL SYNCHRONIZATION FIELD
consente di distinguere l’inizio e la fine di una frame, mediante l’uso di opportuni pattern di bit.
• Nei protocolli character oriented, l’inizio di una frame è marcato con la sequenza di caratteri
ASCII DLE STX, mentre la fine con la sequenza DLE ETX; per evitare la presenza di sequenze
di questo tipo all’interno dei synchronization field si usa la tecnica del character stuffing (vedi
esempio in Fig. 8.1-2), la quale prevede l’inserimento di un carattere DLE prima di ogni
carattere DLE presente tra i due delimitatori.
DLE
STX
C
A
D
DLE
S
DLE
STX
C
A
D
DLE
DLE
DLE
ETX
S
DLE
ETX
Stuffed DLE
Fig. 8.1-2: Character stuffing.
• Invece, i protocolli bit oriented, usano come synchronization field il pattern di bit 01111110; per
evitare che questa sequenza sia ripetuta tra i due delimitatori si usa la tecnica del bit stuffing (to
stuff = inserire a forza)(vedi esempio in Fig. 8.1-3), che prevede l’inserimento di un bit 0 ogni
cinque bit 1 consecutivi, trovati all’interno dei delimitatori.
01111110 01110110010111110100011 01111110
01111110 0111011001011111 0 0100011 01111110
Stuffed bit
Fig. 8.1-3: Bit Stuffing
3
In entrambi i casi, una volta che la frame è giunta a destinazione, il ricevente dovrà fare,
rispettivamente, il destuffing o lo stripping.
Cioè, nel caso di protocollo bit oriented, sarà compito del ricevitore analizzare che valenza ha il bit
successivo ad una eventuale sequenza di cinque bit 1 consecutivi. Infatti se dopo cinque bit 1
troviamo
→ il bit 0, si effettua il bit stripping eliminandolo;
→ se, invece, il sesto è il bit 1 si esamina il settimo bit:
se è un bit 0 vuol dire che il tutto rappresenta flag,
viceversa significa che la trama è stata affetta da un errore che deve essere segnalato.
L’ADDRESS FIELD
contiene l’indirizzo del destinatario, mentre
IL CONTROL FIELD
contiene una serie di informazioni di controllo utilizzate per fare il controllo di sequenza e di flusso.
IL DATA FIELD
della frame (Fig. 8.1-1), contiene un pacchetto del Network Layer (come del resto bisognava
aspettarsi per quanto descritto nei capitoli precedenti); inoltre, la lunghezza di questo campo viene,
in genere, fissata in modo tale da avere un buon compromesso tra rendimento della linea e
probabilità di errore. Infatti, più grande è il DATA FIELD, maggiore è sia l’utilizzazione della linea
che la probabilità di errore. Infine
l’Error Check Field
contiene una sequenza di byte utilizzati per la rilevazione di eventuali errori presenti nella frame.
8.2 Controllo di Errore (Error Detection)
Quando dei dati vengono scambiati tra due interlocutori, è comune che, a causa di disturbi elettrici,
il segnale rappresentante lo stream di bit trasmesso venga alterato. La conseguenza è che il
ricevitore, in alcuni casi, potrebbe ricevere un messaggio diverso da quello trasmesso.
Quindi il controllo e la correzione degli errori sono delle funzioni indispensabili al fine di garantire
una comunicazione “affidabile” (una comunicazione in cui la probabilità di errore sia
ragionevolmente bassa).
Tipicamente gli errori si presentano in burst, cioè vengono persi o alterati intere sequenze di bit
(non singoli bit).
La tecnica di CONTROLLO DI ERRORE (nella letteratura anglosassone, la problematica del controllo
di errore è nota come Error Detection, in quanto con il termine Error Control si intende la
gestione dell’errore) più usata è quella del CYCLIC REDUNDANCY CHECK (CRC); essa è adatta a
rilevare errori multipli. Questo metodo considera una stringa di bit come un polinomio con
coefficienti 0 ed 1. Ad una generica frame, costituita da k bit, viene associato un polinomio di grado
k-1: per esempio alla stringa di bit 10101101 (k=8) corrisponde il polinomio
M(x)=1⋅ x7 + 0⋅ x6 + 1⋅ x5 + 0⋅ x4 + 1⋅ x3 +1⋅ x2 +0⋅ x1 +1⋅ x0 =
= x7 + x5 + x3 + x2 +1.
Per usare questo metodo le parti coinvolte nella comunicazione devono concordare un Polinomio
Generatore G(x) il quale deve avere sia il MSB che il LSB pari ad 1 (vedi tabella di Fig. 8.2-1).
4
L’idea alla base di questo metodo è quella di ricavare il checksum (Error Check Field) in modo tale
che il polinomio associato alla frame ottenuta sia divisibile per G(x) (le operazioni di somma
sottrazione sono fatte in modulo 2; ciò implica che non vi sono né riporti per le addizioni e né
prestiti nelle divisioni).
Dato il campo informativo di una frame, detto M(x) il polinomio da esso individuato, deve
necessariamente verificarsi che:
grado{M(x)} > grado{G(x)}
per poter ottenere un polinomio resto R(x) dal rapporto tra M(x) e G(x), grazie al quale si effettua il
controllo di errore. I passi previsti da questo controllo sono:
I. detto k il grado del polinomio G(x), si considera il polinomio xk⋅M(x)=M’(x), il quale è
ottenuto aggiungendo k zeri alla fine della stringa di bit del campo informativo della frame.
II. Dunque si divide M’(x) per G(x); detto Q(x) il quoziente e R(x)=M’(x) - Q(x)G(x) il resto (sarà
un polinomio al più di grado (k-1)), si trasforma R(x) in una sequenza di bit e si inserisce nel
campo di controllo di errore FCS della frame.
III. Quindi la stringa di bit associata al polinomio R(x) rappresenta il checksum.
IV. In ricezione, pervenuta la frame, si estrae il contenuto tra un flag e l’altro, escludendo il campo
FCS, e si divide il tutto per il polinomio generatore G(x): se il resto della divisione è uguale al
polinomio R(x), contenuto nell’FCS, la trama viene riconosciuta corretta, altrimenti viene
scartata.
Il tasso degli errori che si possono rilevare, usando questa tecnica di controllo di errore, è
notevolmente soddisfacente.
CRC-CCITT
CRC-16
CRC-12
x16 + x12 + x5 +1
x16 + x15 + x2 +1
x12 + x11 + x 3 + x2 +x+1
Fig. 8.2-1: Alcuni polinomi generatori standardizzati.
Nonostante il metodo esposto potrebbe sembrare laborioso, Peterson e Brown (nel 1961) lo hanno
applicato, effettuando tutti i calcoli necessari attraverso un circuito costituito da shift registers;
nonostante ciò, questo hardware non è quasi mai usato nella pratica.
8.3 Gestione degli Errori
Sinora abbiamo visto quali funzionalità devono essere presenti all’interno del DLL al fine di
rendere possibile il colloquio tra due peer entities.
Con le funzionalità sin ora descritte, il servizio offerto è di tipo Best-Try: infatti, quando una frame
arriva a destinazione corrotta, non viene attivato alcun meccanismo di recovery (recupero).
Questo può andare bene per un protocollo Connection-Less, ma è chiaramente insufficiente per un
protocollo Connection Oriented.
Vediamo di descrivere alcune tecniche di rilevazione e correzione degli errori, dette anche tecniche
di ERROR CONTROL.
L’AUTOMATIC REPEAT REQUEST (ARQ - richiesta di ripetizione automatica)
è una tecnica di ERROR CONTROL, nella quale l’entità ricevente controlla di volta in volta
l’integrità della frame ricevuta, preoccupandosi di inviare una frame di controllo, detta ACK
(ACKnowledgement), per confermare la corretta ricezione.
Nel caso in cui la frame dovesse arrivare corrotta, allora, l’entità ricevente può, semplicemente,
attendere che il sender rispedisca la frame, oppure può, immediatamente, inviare un NACK
(Negative ACKnowledgement) per sollecitare la ritrasmissione della frame.
Esistono in sostanza due tipi di ARQ:
5
A. IDLE RQ tipicamente utilizzato in protocolli character-oriented;
B. CONTINUOUS RQ usato soprattutto nei protocolli bit-oriented.
IDLE RQ
L’Idle RQ è stato ideato per consentire, in maniera affidabile, lo scambio tra interlocutori di
frame contenenti caratteri stampabili e di controllo.
Fissiamo la nomenclatura: tipicamente
le frame trasmesse vengono dette Information-Frame (I-Frame), mentre
l’entità trasmittente e ricevente vengono dette Primary (P) e Secondary (S).
Quindi l’IDLE RQ si preoccupa di garantire lo scambio di I-Frame tra P ed S mediante un
collegamento seriale.
L’Idle RQ prevede che P spedisca una I-Frame, attendendo l’ACK da S; solo dopo che
l’ultima frame spedita è pervenuta corretta a S, P può spedire una nuova I-Frame.
D’altro canto S invia un ACK solo nel caso in cui la I-Frame ricevuta è corretta (Fig. 8.3-1).
L’Idle RQ è noto in letteratura anche come Send-and-Wait o Stop-and-Wait: questi nomi
enfatizzano il fatto che, come detto, l’entità Primary spedisce una I-Frame, attendendo
l’ACK dalla Secondary
Nel caso in cui P non riceve l’ACK, entro un certo intervallo di tempo (in cui la I-Frame è
giunta corrotta a S o in cui l’ACK si è perso), tale entità trasmittente è autorizzata a rispedire
l’ultima I-Frame inviata.
Questa modalità di funzionamento è anche detta
⇒ Implicit Retransmission (Fig. 8.3-2), per distringuerla dalla modalità
⇒ Explicit Request (Fig. 8.3-3), nella quale S invia anche un NACK a P per sollecitare la
ritrasmissione della I-Frame che è pervenuta corrotta.
Osserviamo che in entrambe le configurazioni il timeout interval (intervallo di tempo entro
il quale si attende l’arrivo di un ACK o NACK) deve essere scelto opportunamente: esso
deve essere almeno pari al tempo che intercorre tra la ricezione della I-Frame e il
processamneto della stessa da parte di S, più il tempo necessario affinché l’ACK (o NACK)
sia ricevuto e processato da P.
Notiamo che, nel caso in cui l’ACK non sia perduto, P, allo scadere del timeout interval,
rispedisce l’ultima I-Frame non confermata, ed S riceve nuovamente la stessa frame. Questa
situazione è gestita dall’Idle RQ considerando due contatori: V(S) e V(R).
¾V(S) rappresenta il numero di sequenza da assegnare alla prossima frame da spedire,
¾mentre V(R) rappresenta il numero di sequenza della prossima frame attesa.
¾Si suppone, inoltre, che i numeri di sequenza non siano limitati, ossia possono crescere
indefinitivamente senza ripetersi.
Il contatore V(R) viene incrementato ogni volta che viene ricevuta una I-Frame corretta,
mentre V(S) viene incrementato ogni qual volta si riceve l’ACK per l’ultima I-Frame
trasmessa. Grazie a questi contatori, nel caso in cui un ACK venga perso, non si hanno
duplicati. Infatti, quando S riceve la I-Frame ritrasmessa da P, confrontando il suo contatore
V(R) con il numero di sequenza contenuto nella frame, si rende conto di essere di fronte ad
un duplicato. Trascura quindi questa I-Frame ed invia l’ACK a P per sincronizzarlo.
L’ACK (o NACK) contiene sempre il numero di sequenza dell’ultima frame ricevuta.
L’UTILIZZAZIONE DEL LINK con questa tecnica non è molto alta, ma può essere aumentata
usando l’explicit request. Così facendo, ogni qual volta una frame viene danneggiata, non è
necessario attendere un intero timeout interval per avere la ritrasmissione.
Il vantaggio che si ha con l’uso di questa tecnica è tanto maggiore quanto più alto è il BER
(bit error rate).
Per implementare questo protocollo IDLE RQ è sufficiente un link half-duplex.
6
Timer Started
Primary (P)
Timer Stopped
I(N)
Timer Stopped
I(N+1)
I(N)
Secondary (S)
Timer Started
ACK(N)
I(N)
Timer Started
I(N+2)
I(N+1)
ACK(N+1)
I(N+1)
Fig. 8.3-1: Comportamento del protocollo Idle RQ nel caso corretta trasmissione.
Timer Started
Timeout Interval
l
Primary (P)
I(N)
Timer Retarded
I(N)
I(N)
I(N)
I(N)
Secondary (S)
Timer Stopped
Timer Started
I(N+1)
ACK(N)
I(N)
Fig. 8.3-2: Idle RQ nel caso in cui si danneggia una I-Frame trasmessa - IMPLICIT RETRANSMISSION
Timer Started
Primary (P)
I(N)
I(N)
Secondary (S)
Timer Stopped Timer Started
I(N)
NACK(N)
I(N)
Timer Stopped
I(N)
Timer Started
I(N+1)
ACK(N)
I(N)
Fig. 8.3-3: Idle RQ nel caso in cui si danneggia una I-Frame - EXPLICIT REQUEST
CONTINUOUS RQ
Il Continuous RQ consente UTILIZZAZIONI DEL LINK decisamente migliori rispetto all’Idle
RQ, a spese di maggiori requisiti in termini di buffer.
Questa tecnica di ERROR CONTROL, contrariamente all’Idle RQ, prevede che P spedisca
continuamente I-Frame. Poiché, istante per istante, vi sono un certo numero di frame che
attendono l’ACK, P mantiene una lista detta Retransmission List, nella quale memorizza
tutte le I-Frame non ancora confermate. Ogni I-Frame contiene un numero di sequenza
distinto, scelto tenendo conto del contatore V(S).
Le I-Frame che S riceve correttamente, vengono inserite da S in una lista di attesa, detta
Link Receive List, per essere successivamente processate.
7
Inoltre per ogni frame ricevuta correttamente, S invia un ACK con numero di sequenza pari
a quello della I-Frame correttamente ricevuta.
La ricezione di un ACK da parte di P, porta alla rimozione della I-Frame (a cui l’ACK fa
riferimento) dalla Retransmission List.
In assenza di errori questa tecnica garantisce un utilizzazione del link che si avvicina al
100%, in quanto P può spedire I-Frame senza alcuna restrizione.
Nel caso in cui si verifica un errore, esistono due diverse tecniche di ritrasmissione previste
dal CONTINUONUS RQ, note come SELCTIVE REPEAT e GO-BACK-N.
IL SELECTIVE REPEAT prevede due varianti:
⇒ l’implicit retransmission
⇒ l’explicit request
proprio come nel caso dell’Idle RQ.
Nell’implicit retransmission, P procede alla ritrasmissione solo allo scadere di un
timeout interval associato ad una data I-Frame, che probabilmente è stata
danneggiata o addirittura persa.
Invece, nell’explicit request, S invia un NACK per richiedere la ritrasmissione di
una ben precisa I-Frame che è pervenuta corrotta. Anche in questo caso, se P non
ha ricevuto né l’ACK e né NACK, entro un prestabilito timer associato ad ogni IFrame, P ritrasmette la I-Frame in questione.
Ricordiamo però che uno degli obiettivi del DLL è di consegnare i pacchetti al
livello superiore nello stesso ordine con cui essi sono stati spediti.
Quindi, come mostra la Fig. 8.3-4, nel caso in cui una I-Frame viene corrotta, S
memorizza nella link receive list le successive frame che intanto continuano ad
arrivare. Non appena la I-Frame mancante (cioè la I-Frame corrotta) arriva, S
riordina la lista ed il tutto viene trasferito al livello superiore. La versione explicit
request funziona in modo analogo.
Fig. 8.3-4: SELECTIVE REPEAT nel caso dell’IMPLICIT RETRANSMISSION.
8
La tecnica Selective Repeat presenta il seguente problema: dovendo S bufferizzare
tutte le frame ricevute fuori ordine, si ha bisogno di notevoli capacità di memoria
dei buffer, presenti nel sottosistema di comunicazione, specialmente nel caso in cui
le frame hanno dimensioni notevoli. A causa di questo problema molti protocolli
preferiscono usare lo schema di controllo GO-BACK N.
IL GO-BACK N, come suggerisce lo stesso nome,
è uno schema di controllo in cui non appena S rileva una I-Frame fuori ordine,
informa P, implicitamente (sfruttando il timeout interval) o esplicitamente
(inviando un NACK), di iniziare a ritrasmettere le frame a partire da un certo
numero di sequenza. Mentre tutte le I-Frame arrivate fuori ordine vengono scartate
senza alcuna esitazione.
In Fig. 8.3-5 è mostrato il comportamento del GO-BACK N nel caso di explicit
request, mentre in Fig. 8.3-6 viene mostrato un esempio relativo al caso di implicit
retransmission.
È importante notare che nel GO-BACK N gli ACK possono essere cumulativi, ossia
un dato ACK può confermare tutte le frame che precedono la frame a cui l’ACK fa
riferimento. Osserviamo, infine, che poiché le frame vengono accettate solo in
ordine, allora non sorge il problema di mantenere grandi buffer per riordinare le
frame arrivate fuori sequenza.
Fig. 8.3-5: GO-BACK N nel caso di RICHIESTA ESPLICITA.
9
Fig. 8.3-6: GO-BACK N nel caso di RICHIESTA IMPLICITA.
Sin ora si è supposto che il traffico di I-Frame fosse solo da P ad S.
In generale, se il traffico è bidirezionale, si può usare una tecnica nota con il nome di piggybacking
(farcire il maiale), attraverso cui si invia l’ACK includendolo in un campo di controllo opportuno
della I-Frame da trasmettere. In pratica ogni I-Frame ha nel control field un campo che contiene il
numero di sequenza N(S) ed un campo contenente N(R), il quale rappresenta il numero di sequenza
dell’ultima I-Frame ricevuta correttamente.
8.4 Controllo di Flusso
Il controllo di flusso (Flow Control) consiste nell’impedire che P trasmetta ad un ritmo medio più
alto rispetto a quello che S può, o vuole, accettare; in questo modo si garantisce al riceiver buffer di
memorizzare tutte le I-Frame ricevute.
La condizione indispensabile per non incappare in una situazione di sovraccarico è che il tempo di
trasmissione di N trame deve essere inferiore al “tempo di ciclo”, ovvero al tempo di ritardo dovuto
al viaggio di andata e ritorno della trama lungo il link.
La tecnica tipicamente usata per realizzare il controllo di flusso è nota con il nome di
SLIDING WINDOW (FINESTRA SCORREVOLE).
Questa tecnica consiste nel porre un limite massimo al numero di I-Frame, che possono essere
spedite da P, attraverso un’azione auto-regolante.
Infatti P trasmette continuamente se S invia l’ACK (di corretta ricezione) con un ritmo
compatibile a quello con cui riceve le I-Frame. Nel caso in cui S dovesse trovarsi in affanno, gli
basta smettere di inviare ACK per bloccare P.
Per spiegare nel dettaglio questo metodo faremo riferimento alla Fig. 8.4-1, la quale rappresenta
la situazione in cui si trova ogni singola I-Frame spedita.
10
P View
Frame in corso
di trasmissione
Prima frame non
ancora confermata
Frame
spedibili
Frame in
volo
I(0) I(1) I(2) … I(i t-1) I(i t) … I(i r-1) I(i r) … I(c r) … I(c t) … I(s t) … I(s r) …
Senso di propagazione
Ultima Frame
Confermata
Conferme in volo
Frame ricevute
ma non ancora
confermate
Frame in corso
di ricezione
S View
fr
Fig. 8.4-1: Sliding Window
Dalla Fig. 8.4-1 si vede che la frame I(ct) è in corso di trasmissione, mentre la frame I(cr) è in
fase di ricezione; quindi le frame, comprese tra queste due, sono “in volo”, ossia si stanno
propagando nel mezzo di comunicazione.
La frame I(i t-1) è l’ultima di cui P ha ricevuto l’ACK, mentre non ha ancora avuto alcuna
conferma (né smentita) sulla corretta ricezione di I(it).
Il meccanismo dello SLIDING WINDOW, consiste nell’imporre a P di trasmettere solo I-Frame il
cui numero di sequenza appartiene ad un certo intervallo avente ampiezza pari ad ft, detto
finestra di trasmissione.
Nel caso rappresentato in Fig. 8.4-1, essendo it l’estremo inferiore di tale intervallo, P può
spedire solo le frame I(k) i cui numeri di sequenza sono tali che:
it ≤ k ≤ it + f t = st
Per quanto riguarda il ricevitore, S ha già confermato tutte le frame sino a I(ir-1), mentre non ha
ancora inviato l’ACK per la frame I(ir). Quindi l’estremo inferiore ir della finestra fr del
ricevitore è ovviamente diverso dall’estremo inferiore della finestra di trasmissione; S accetterà
solo le frame I(k) il cui numero di sequenza soddisfa la seguente relazione:
ir ≤ k ≤ ir + f r = s r
Dunque P non può trasmettere né le frame aventi numero di sequenza minore dell’estremo
inferiore della finestra di trasmissione (in quanto esse sono già state ricevute correttamente) e né
le I-Frame alla destra della finestra di ricezione (in quanto non ha ancora ricevuto il consenso da
S). S, invece, ignorerà tutte le I-Frame il cui numero di sequenza cade fuori dalla finestra di
ricezione.
Nel momento in cui arriva la conferma cumulativa relativa alle trame comprese tra i t e i r-1, il
margine inferiore della finestra di trasmissione verrà spostato ad i r. Conseguentemente verrà
traslata tutta la finestra: questo spiega il perché tale controllo di flusso è chiamato Sliding
Window (finestra scorrevole).
Tipicamente le finestre di trasmissione e di ricezione si sovrappongono parzialmente: infatti ft
ed fr devono essere scelte in modo tale che si abbia:
ir −1 ≤ st ≤ sr
Sinora abbiamo ipotizzato che i numeri di sequenza potevano crescere indefinitamente.
Ma questa ipotesi è tutt’altro che realistica.
11
Nella pratica non si usa una numerazione infinita, ma di tipo modulare. In generale i numeri di
sequenza possono crescere da 0 ad m-1 per una numerazione modulo m (gli incrementi devono
essere intesi in modulo m).
Ad esempio, in una numerazione modulo 8 (m=8), se sono state trasmesse le trame con
N(S)=5,6,7,0,1,2,3 (m-1=7) (Fig. 8.4-2), bisogna necessariamente aspettare che il ricevitore invii
l’ACK prima di trasmettere altre frame.
N(S) _
5
6
7
0
1
2
3
_ N(R) _
0
7
1
6
2
5
3
4
non può essere trasferito
prima dell’ACK della
frame 5
Fig 8.4-2: window control in una numerazione modulo 8
Esistono situazioni in cui utilizzare una finestra di ampiezza pari a 7, è molto limitante:
• in un collegamento via satellite, in cui il tempo di propagazione non è trascurabile rispetto
al tempo di trasmissione, o
• in link di capacità molto elevata,
un tempo di trasmissione di 7 trame potrebbe risultare decisamente inferiore al round trip delay;
per cui avere la possibilità di trasmettere non più di 7 trame, prima di ricevere l’ACK, può dar
luogo a situazioni di
⇒ deadlock – il protocollo non riesce ad evolvere in quanto c’è una situazione di
blocco (ad esempio due stazioni che aspettano qualcosa che non arriva e che non
potrà mai arrivare);
⇒ starvation – il sender può trasmettere, ma è impedito a farlo in quanto il
funzionamento corretto del protocollo impone che deve prima attendere l’ACK,
per cui la risorsa trasmissiva risulta essere bloccata.
Questo spiega perché il protocollo l’HDLC (trattato qui di seguito) utilizza anche la numerazione
modulo 128, in cui si possono riservare ai N(S) e N(R), del campo di controllo, 7 bit, che
corrisponde a poter trasmettere 127 trame alla volta prima di aspettare l’ACK.
Inoltre, per garantire che non vengano ricevute frame duplicate, bisogna far sì che ft ed fr
soddisfino la seguente relazione:
ft + f r ≤ m
Esistono protocolli in cui la dimensione delle finestre di trasmissione e ricezione può essere
negoziata in fase di apertura della connessione, mentre in altri protocolli tali dimensioni possono
essere variate dinamicamente in base alle esigenze del momento.
Lo Sliding Window è un controllo di flusso esplicito che consente di ottimizzare l’efficienza della
linea, ma che entra in crisi in una situazione di congestione.
12
Esistono anche tecniche di controllo di flusso preventivo, in cui il sender non può trasmettere se di
volta in volta il receiver non accetta di ricevere ulteriori informazioni.
8.5 Gestione del Collegamento
Sin ora abbiamo visto come sia possibile scambiare frame tra due entità connesse da un link seriale.
Affinché questo scambio possa avvenire, le entità che desiderano colloquiare devono poter
instaurare una connessione, ed analogamente, quando le due entità hanno concluso il loro colloquio
devono poter chiudere tale connessione. Quindi uno dei requisiti dei protocolli di linea è quello di
essere capaci di guidare il sistema, da una fase all’altra, seguendo una serie di procedure dipendenti
dal particolare protocollo.
8.6 Il Protocollo BSC (Binary Synchronous Control)
Il primo protocollo CHARACTER-ORIENTED fu il BSC (Binary Synchronous Control), introdotto
dall’IBM, in cui il messaggio era una collezione sequenziale di caratteri composti da 8 bit (7 bit
significativi + un bit di parità per il controllo di errore), secondo il codice ASCII.
carattere
Carattere di
controllo
Fig. 8.6-1: sequenza di caratteri
Per delimitare il campo dati si utilizzavano opportuni caratteri di controllo. Inoltre era anche
presente un header di caratteri di controllo. In ricezione, grazie alla presenza di questi caratteri, si
riusciva a delimitare il campo, ad identificare il tipo di messaggio di controllo pervenuto, ecc.
Quando non c’era nulla da trasmettere, venivano inviati in linea dei caratteri (di controllo) di
riempimento.
Il protocollo BSC era un protocollo two way alternate, in quanto permetteva l’invio di informazioni
in maniera alternata in entrambe le direzioni (come l’Alternate Bit Protocol).
Questo lo ha caratterizzato, impropriamente, di tipo “half-diplex”: in realtà ci si riferiva alla
capacità logica del messaggio di sfruttare o meno una linea di trasmissione e non alla possibilità di
realizzare, a livello fisico, un link che supporti simultaneamente la comunicazione nei due sensi
(full-diplex) o in maniera alternata (half-diplex).
In pratica, il protocollo BSC operava in handshake (a stretta di mano): una stazione, dopo aver
inviato un messaggio, doveva aspettare che il ricevitore inviasse un messaggio di controllo (ACK)
di corretta ricezione, prima di poter trasmettere il successivo messaggio.
Secondo questo criterio, se una stazione sta trasmettendo dati, l’altra sarà vincolata a inviare solo
ACK; a tal proposito si è pensato ad un meccanismo che permettesse alla stazione passiva, mediante
un opportuno messaggio di controllo, di richiedere l’uso della linea per inviare dati.
Il protocollo BSC è stato presto abbandonato e sostituito dal protocollo HDLC, perché non sfruttava
a pieno le capacità full-duplex delle linee.
13
8.7 Il protocollo HDLC (High-Level Data Link Control)
L’HDLC è nato come l’estensione del protocollo SDLC (Synchronous Data Link Control) della
IBM, dopo il superamento del BSC. Dopo essere stato standardizzato, ancora oggi rappresenta il
modello di riferimento classico per i protocolli di linea. Ad esempio il protocollo che viene
utilizzato nelle reti ISDN a banda stretta è una variante dell’HDLC.
L’HDLC, è un protocollo full-duplex (più correttamente two way symultaneus, visto che
permetteva il trasferimento di informazioni contemporaneamente in entrambe le direzioni del
collegamento), sincrono e bit-oriented, definito dall’ISO per essere usato sia in collegamenti puntopunto, che in collegamenti multipunto, in cui è presente una dorsale a cui è connessa una stazione
Master (principale) che controlla tutte le altre stazioni secondarie dette Slave.
Stazione Master
Stazione Master
Fig. 8.7-1:Configurazioni multipunto
In particolare la stazione Master si occupa
• del controllo di flusso
• del recupero degli errori e
• delle tecniche di arbitraggio per evitare collisioni sulla linea multipunto. In pratica la stazione
Master, attraverso la tecnica di pollin-selecting (to poll=stimolare una risposta), interagisce
ciclicamente con tutte le stazioni Slave, in modo round robin o con priorità, inviando messaggi
di controllo che informano quale delle stazioni secondaria è autorizzata a trasmettere per un
determinato lasso di tempo. Trascorso questo tempo, la stazione Master riprende il controllo per
interrogare se la stazione successiva intende trasmettere.
Il formato delle frame dell’HDLC è riportato in Fig. 8.7-2.
Bits
8
8o
multipli di 8
8 o 16
n
8 o 16
8
F
A
C
I
FCS
F
OPENING
FLAG
ADDRESS
CONTROL
INFORMATION
FRAME CLOSING
CHEK
FLAG
SEQUENCE
Fig. 8.7-2: Formato delle frame del protocollo HDLC.
IL
CAMPO
INFORMATION, (data field o information field) ha una lunghezza che dipende
dall’ampiezza del messaggio che si vuole trasmettere. Vedremo
successivamente che i pacchetti (o messaggi) di livello 3 del
protocollo X.25 (che regola l’accesso alle reti pubbliche a
commutazione di pacchetto) processati dall’HDLC, sono di
lunghezza variabile strutturati in gruppi di 8 bit. Questo significa che
il campo I è costituito da un numero di bit multiplo di 8.
14
IL
CAMPO
ADDRESS, formato da 8 bit o da un multiplo di ottetti, è fondamentale se l’HDLC è
utilizzato in una configurazione multipunto: infatti, in tal caso, in A è
contenuto l’indirizzo della stazione destinataria del messaggio. Viceversa
in una configurazione punto-punto, il campo A è ridondante ed è
mantenuto solo per avere l’uniformità del formato.
IL CAMPO CONTROL serve a specificare se il messaggio è di controllo o con dati. Se si tratta di
messaggio di controllo, C indica di che tipo di controllo si tratta.
Viceversa, se il messaggio contiene dati, in C troviamo delle informazioni
utili al funzionamento del protocollo.
I CAMPI FLAG, costituiscono rispettivamente lo start delimiter e l’end delimiter, e sono composti
dalla sequenza 01111110. Due frame contigue devono essere separate da almeno
un FLAG, mentre in assenza di traffico vengono inviati continuamente FLAG.
Quindi quando il ricevitore incontra l’ottetto 01111110, capisce che la trama si è
conclusa ed inizia a processare tutto quello compreso tra un flag di apertura e un
flag di chiusura. Un flag di chiusura di una trama può rappresentare il flag di
apertura della trama successiva.
Nell’HDLC, essendo un protocollo bit-oriented, la trasparenza dei dati, che
consente di trasferire in linea qualunque dato, senza che esso interferisca con i
meccanismi protocollari, è ottenuta utilizzando la tecnica del bit-stuffing.
Per come è organizzata la frame dell’HDLC, tra due flag si ha un numero di bit
che è multiplo di ottetti: quindi, visto che un carattere è composto da 8 bit (1
byte), perché l’HDLC non lo si può considerare un protocollo orientato a
carattere? La risposta è immediata se tiene conto dell’operazione di bit stuffing:
infatti dopo il bit stuffing non è detto che fra due flag si abbia ancora un numero
di bit multiplo di otto.
IL
CAMPO
FCS, contiene i bit di ridondanza calcolati su tutto il contenuto della frame (ossia
ADDRESS+CONTROL+INFORMATION) utili ad effettuare il controllo di errore.
La tecnica usata è quella del CRC (Cyclic Redundancy Check), con polinomio
generatore:
G(x) = x16 + x12 + x5 + 1
Quindi nel campo FCS viene riportato il polinomio resto
R(x)=P(x) - Q(x)G(x)
che nel nostro caso è al più del 15° grado: questo significa che in FCS è
inserita una stringa di massimo 16 bits.
Il ricevitore, pervenuta la frame, estrae il contenuto tra un flag e l’altro, esclude
il campo FCS e divide il tutto per G(x); Se il resto della divisione è uguale al
polinomio R(x), la trama viene riconosciuta corretta, altrimenti viene scartata.
Nel caso in cui il resto della divisione coincide con R(x), non si può essere certi
che la trama non sia affetta da errori: infatti l’errore potrebbe essere tale da
ottenere un polinomio P’(x) che, diviso per G(x), dia lo stesso resto R(x). In
queste situazioni ci si affida ad un meccanismo di controllo che risiede ad un
livello superiore, tipicamente al quarto livello Transport Layer, dove i controlli
vengono fatti end-to-end.
La Fig. 8.7-3, seguente, mostra le varie fasi del processo di composizione della frame, in
trasmissione e in ricezione, a partire da una DL-SDU (Data Link – Service Data Unit) proveniente
dal livello superiore (livello 3).
15
I
DL-SDU
DL
PCI
PROC
I
A
C
TRASMISSIONE
I
A
C
I
BIT
F
A
C
I
FCS
F
F
A
C
I
FCS
F
FLAG
STUFF
DL-SDU
DL
PCI
PROC
FCS
FCS
A
C
RICEZIONE
I
A
C
I
FCS
DE
FCS
FLAG
STUFF
Fig. 8.7-3: Data Link Frame Process
Le modalità secondo cui operano i due interlocutori, vengono dette, nella terminologia dell’HDLC,
MODI OPERAZIONALI. Questi sono raggruppati in due classi di procedura:
• UNBALANCED CONFIGURATION
• BALANCED CONFIGURATION
NELLA CONFIGURAZIONE UNBALANCED
solo uno dei due interlocutori, detto “Primario” (P), si occupa del recupero degli errori e del
controllo di flusso. Tipicamente un sistema multipunto è costituito da un primario e da un certo
numero di “Secondari” (S).
Inoltre per enfatizzare la sottomissione dei secondari, i messaggi inviati dal primario vengono
detti comandi, mentre i messaggi inviati dai secondari risposte.
In tale configurazione sono possibili due modi operazionali:
1. NRM (Normal Responce Mode) - I secondari possono iniziare la trasmissione di dati,
solo dopo aver ricevuto l’esplicito permesso da parte
del primario.
2. ARM (Asynchronous Responce Mode) - I secondari possono iniziare la trasmissione di
dati anche senza l’esplicito permesso del
primario.
LA CONFIGURAZIONE BALANCED
è applicabile solo a configurazioni punto-punto; in tal caso entrambi gli interlocutori possono
comportarsi sia da primario che da secondario. L’unico modo operazionale definito per questa
classe è l’ABM (Asyinchronous Balanced Mode), in cui entrambi gli interlocutori possono
inviare comandi e risposte senza dover richiedere il permesso dell’altra entità (ad esempio nelle
reti pubbliche, l’utente vuole garantita la possibilità di attivare una comunicazione in qualsiasi
momento lo desideri).
Il campo Address nella configurazione Balanced, viene usato solo per distinguere i comandi
dalle risposte.
Ogni combinazione (classe di procedura, modo operazionale) usa un certo set di comandi e risposte,
i quali vengono detti, nella terminologia dell’HDLC, “ELEMENTI DI PROCEDURA”.
Nella Fig. 8.7-4 è mostrata una tabella che contiene un elenco degli ELEMENTI DI PROCEDURA
utilizzati nella classe bilanciata.
16
Nella tabella (Fig. 8.7-4) si può osservare che il CAMPO DI CONTROLLO, nel caso di numerazione
modulo 8 (cioè non possono essere trasmesse più di 8 trame consecutive senza ricevere l’ACK), è
composto da 8 bit che permettono di discriminare i diversi tipi di frame.
In particolare
⇒ le Information Frame servono per trasmettere dati,
⇒ mentre le Supervisory Frame, servono per l’invio di informazioni sul controllo di flusso.
⇒ Infine le Unnumbered Frame sono usate per segnali di controllo, di inizializzazione o
disconnesione della connessione.
Tipo
Comandi
Control Field
Risposte
0 1 2 3
Information
0 N(S)
I (information)
Frame
1000
RR (Receive Ready)
Supervisory RR (Receive Ready)
1000
RNR (Receive Not Ready) RNR (Receive Not Ready)
Frame
REJ (Reject)
REJ (Reject)
1000
1111
DM (Disconnect Mode)
SABM (Set Asynchronous
1111
Balanced Mode)
Unnumbered
1100
DISC (Disconnect)
Frame
1100
UA (Unnambered Ack.)
FRMR (Frame Reject)
1110
4 5 6 7
P/F
N(R)
P/F
F
N(R)
N(R)
N(R)
000
P
100
P
010
F
110
F
001
P/F
P/F
Fig. 8.7-4: Elementi di procedura della classe bilanciata - formato
del campo di controllo in una numerazione modulo 8.
Il primo bit serve a capire se si tratta di una trama informativa (bit 0) o di una controllo (bit 1).
Il tipo di trama di controllo (supervisory o unnumbered) è deducibile dal secondo bit.
Per quanto riguarda le trame informative, troviamo dopo il primo bit i campi N(S), P/f e N(R); nella
numerazione modulo 8 solo 3 i bit che identificano N(S) e N(R), mentre nella numerazione 128
(Fig.8.7-5) N(S) e N(R) sono formati da 7 bit.
INFORMATION FRAME
Bits
1
2
3
4
5
0
N(S)
P/F
N(R)
6
7
8
SUPERVISORY FRAME
Bits
1
2
3
4
5
6
1
0
S
S
0
0
P/F
7
0
8
0
N(R)
Fig. 8.7-5: formato del campo di controllo in una numerazione modulo 128.
17
Date due stazioni A e B agli estremi di un collegamento,
N1(S), N1(R): campi delle trame trasmesse da B ad A
VA(S), VA(R), VA(K)
VB(S), VB(R), VB(K)
1
A
2
B
N2(S), N2(R): campi delle trame trasmesse da B ad A
VA(S) → Numero d’ordine dell’ultima trama inviata da A a B;
VA(R) → Numero d’ordine dell’ultima trama ricevuta corretta da A;
VA(K) → Numero d’ordine dell’ultima trama ricevuta corretta da B;
Fig. 8.7-6: comunicazione fra due stazioni A e B agli estremi di un collegamento
quando A riceve una trama informativa da B, si controlla che N2(S)=VA(R)+1 e si aggiornano i
contatori VA(R) e VA(K) nel seguente modo:
VA(R)= N2(S)
VA(K)= N2(R)-1
Il nodo A, prima di iniziare la trasmissione di una trama verso B, controlla la differenza
VA(S)-VA(K)
per verificare che la trama in questione rientri nella finestra di trasmissione di lunghezza W, cioè se
VA(S)-VA(K)≤W-1.
Se è vera tale condizione, il nodo compie le seguenti operazioni:
1. VA(S)= VA(S)+1;
2. N1(S)=VA(S);
3. N1(R)= VA(R)+1;
4. trasmette la trama.
In Fig. 8.7-7 è riportato per il protocollo HDLC un diagramma che rappresenta le fasi di
colloquio in una procedura bilanciata, con numerazione delle frame modulo 8.
Attraverso questo diagramma analizziamo le funzionalità di gestione della procedura di
collegamento, dalla fase di setup (esplicito) alla fase di chiusura del collegamento.
Osserviamo che L’INIZIALIZZAZIONE DEL LINK avviene mediante l’invio di una frame unnumbered di
tipo SABM (Set Asynchronous Balanced Mode cioè inizio modo asincrono bilanciato), alla quale
l’interlocutore ricevente comunica la sua disponibilità trasmettendo una frame UA (Unnumbered
Acknowledgemet).
Non appena l’entità A riceve la frame UA, si passa alla FASE DI TRASFERIMENTO DELLE
Durante questa fase, il controllo di sequenza ed il controllo di flusso, sono
implementati con un MECCANISMO A FINESTRA: questo prevede una finestra di ricezione di
ampiezza unitaria (fr = 1) e una finestra di trasmissione compresa tra 1 e 7 (ft ∈[1,7]).
INFORMAZIONI.
18
Ogni I-Frame contiene nel suo Control Field i due numeri di sequenza (vedi tabella di Fig. 8.7-4):
N(S) e N(R).
⇒ In N(S) troviamo il numero di sequenza delle frame immesse nella linea, mentre
⇒ in N(R) troviamo il numero di sequenza delle frame ricevute correttamente. Cioè N(R)
conferma la corretta ricezione delle N(R)-1 I- Frame (se N(R) > 0). Quindi N(R) effettua il
piggybacking dell’ACK: infatti in una comunicazione full-duplex, la stazione che inizia a
ricevere, può inviare l’ACK cumulativo, delle trame correttamente pervenute, inserendoli
nel campo N(R) della trama informativa che intende trasmettere.
Nel caso in cui non vi siano I-Frame da spedire su cui fare il piggybacking, vengono inviate delle
Supervisory frame del tipo RR (Receive Ready) o RNR (Receive not Ready), per indicare
disponibilità o meno a ricevere altre I-Frame. Il comando RNR è utilizzato specialmente se si
verificano condizioni di congestione dovute alla saturazione dei buffer di ricezione.
Inoltre N(S) e N(R) svolgono anche il controllo di flusso utilizzando la tecnica SLIDING WINDOW
prima esaminata.
Ogni FRAME RICEVUTA FUORI SEQUENZA viene scartata; in pratica quando l’entità ricevente rivela un
errore di sequenza, invia un messaggio di REJ (Reject) (tabella di Fig. 8.7-4) all’entità trasmittente,
la quale ritrasmette tutte le frame a partire dalla frame con il numero di sequenza N(R) presente nel
campo di controllo della frame REJ.
Per prevenire i problemi che potrebbero creare le PERDITE DEGLI ACK, ad ogni frame inviata è
associato un timer. Lo scadere del timer implica la ritrasmissione del comando, con il 5° bit del
campo di controllo posto ad 1 (questo bit viene detto Poll-bit per i comandi e Final-bit per le
risposte). Così si forza l’interlocutore ad inviare comunque una risposta, anche se questo si trova in
uno stato in cui non è necessario rispondere. La risposta è una Supervisory frame avente il 5° bit del
campo di controllo posto ad 1.
Se si riceve una trama errata, contenente ad esempio un campo di controllo non previsto, o un N(R)
non valido, o un campo informativo troppo lungo, il receiver invia un FRMR (Frame Reject cioè un
rifiuto di trama) che, pervenuto al trasmettitore, provoca l’invio di un SABM.
Nel caso in cui una frame viene ritrasmessa un certo numero di volte, senza ottenere alcuna risposta,
viene avviata la PROCEDURA DI RESET del link, che è analoga a quella di inizializzazione: infatti si
invia il comando di inizializzazione SABM a cui fa seguito la trasmissione di una frame UA da
parte dell’entità ricevente. Nel caso in cui non si ottiene risposta nemmeno all’SABM, dopo un
certo numero di ritrasmissioni, si procede alla disconnessione del collegamento.
LA PROCEDURA DI RISINCRONIZZAZIONE viene attivata ogni qual volta il recupero degli errori non è
effettuato mediante la semplice ritrasmissione della frame.
Terminato il colloquio fra le due entità, LA FASE DISCONNESSIONE è attivata mediante l’invio di un
comando DISC, al quale l’altro interlocutore deve rispondere con un UA.
19
ENTITA’ A
ENTITA’ B
SABM
UA
I, N(S)=0, N(R)=0
I, N(S)=0, N(R)=0
I, N(S)=1, N(R)=1
I, N(S)=2, N(R)=1
I, N(S)=3, N(R)=1
I, N(S)=4, N(R)=1
I, N(S)=5, N(R)=1
REJ, N(R)=2
RR, N(R)=1
I, N(S)=1, N(R)=5
I, N(S)=2, N(R)=5
perdita in linea
I, N(S)=3, N(R)=6
I, N(S)=4, N(R)=6
I, N(S)=2, N(R)=6
I, N(S)=3, N(R)=6
I, N(S)=4, N(R)=6
RR, I, N(R)=5
perdita in linea
tempo di
guardia
I, N(S)=2, N(R)=6
REJ, N(R)=5
I, N(S)=5, N(R)=6
DISC
UA
Fig. 8.7-7: Esempio di colloquio tra due entità nel protocollo HDLC in una procedura bilanciata.
20
COMMENTO DELLA FIG. 8.7-7
Le due entità A e B di fig. 8.7-2 hanno una finestra di trasmissione e pari a 5.
Inizialmente A e B si scambiano i messaggi SABM e UA per aprire la connessione.
La stazione di sinistra A riceve la prima trama informativa dalla stazione di destra
B, per cui incrementa il valore N(R) portandolo da N(R) = O a N(R)=1. In questo
modo, quando A invia la sua prima trama, la stazione B capirà che A ha ricevuto
correttamente la trama, con N(S)=O, che precedentemente gli aveva trasmesso.
Dal momento che B non trasmette alcuna trama, allo scadere del time out manda
un Receive Ready con N(R)=4, per indicare che ha ricevuto correttamente le trame
fino a quella con valore N(R) = 3.
Quando B trasmette ad A la trama con N(S)=2, si ha una perdita in linea: dunque
A, non appena riceve la trama con N(S) = 3, accorgendosi dell’errore, trasmetterà
il comando di Reject, con N(R)=2, per chiedere la ritrasmissione della trama
mancante, e di tutte quelle che erano state inviate successivamente ad essa.
Invece, nel caso in cui la stazione A perde il Receive Ready con N(R) = 5, trascorso
il tempo di guardia, B invierà nuovamente la prima trama di cui non aveva ricevuto
l'ACK. Quest’ultima, però, viene rigettata con un N(R) pari al valore dell'ultima
trama ricevuta correttamente, e quindi la trasmissione riprenderà dal punto
richiesto dalla stazione ricevente.
Quando la stazione A manda il DISC, B risponde con un UA chiudendo la
connessione.
8.8 Analisi dei Protocolli di Linea
In questa sezione vedremo di valutare le prestazioni, in termini di massimo THROUGHPUT (inverso
del tempo minimo che intercorre tra l’istante di trasmissione del 1° bit di una trama e l’istante di
trasmissione del 1° bit della trama successiva), che si ottengono con i due protocolli:
• STOP AND WAIT
• GO-BACK N
visti in precedenza.
Ricordiamo che il protocollo STOP AND WAIT non è altro che l’IDLE RQ, mentre il protocollo GOBACK N è una delle tecniche utilizzabili in caso di CONTINUOUS RQ.
L’analisi presentata qui di seguito, presuppone valide le seguenti ipotesi:
1.
2.
3.
4.
5.
i numeri di sequenza non sono limitati;
le frame hanno lunghezza fissa.
il round trip propagation delay tra il trasmettitore ed il ricevitore è noto e costante;
il processing delay al ricevitore è noto e costante;
il trasmettitore opera in condizioni di saturazione, ossia ha sempre delle frame da spedire
(questa ipotesi è essenziale visto che siamo interessati a ricavare il massimo throughput).
I risultati che otterremo evidenzieranno le principali differenze tra i due tipi di protocolli anzidetti.
PROTOCOLLO STOP AND WAIT
Nelle ipotesi presupposte, valutiamo il max throughput di questo protocollo.
Definiamo i seguenti tempi:
ti
tempo necessario per trasmettere una frame (dipende esclusivamente dalla
capacità del canale;.
21
tout time-out interval, ovvero il tempo che occorre aspettare dalla trasmissione di
tproc
tp
ts
una trama alla ricezione di un ACK;
tempo di processamento;
tempo di propagazione che impiega il messaggio, o l’ACK, trasmesso a
propagarsi lungo la linea;
tempo trascorso fino all’invio dell’ACK da parte del ricevente.
Osserviamo che il time-out interval tout deve soddisfare la relazione:
t out ≥ t p + t proc + t s + t p ≅ 2 ⋅ t p + t s
(1)
dove abbiamo lecitamente supposto il tempo di processamento tproc incluso all’interno del
tempo di propagazione. ts , come detto, rappresenta il tempo necessario a spedire l’ACK: esso
⇒ è trascurabile se il messaggio di ACK è breve,
⇒ mentre è notevole se il protocollo applica il piggy-backing, ovvero se la stazione, al
momento ricevente, utilizza la trama informativa, che intende trasmettere, per inviare
l’ACK. In tal caso è chiaro che ts è uguale al tempo di trasmissione ti relativo all’intero
messaggio. Quindi, dalla (1) segue che
t out ≥ 2 ⋅ t p + ti
dati
dati
A
B
A
ACK
B
ACK
Fig. 8.8-1: trasferimento di dati e ACK tra le due stazioni A e B
Nella condizione sfavorevole in cui la trama informativa, che viaggia da A a B, arriva quando è
già stata trasmessa la trama con dati, spedita da B verso A, è necessario considerare un ulteriore
ti che tenga conto del tempo di trasmissione della trama piggy-backing, la quale contiene la
conferma. Cioè assumiamo come tempo minimo di trasmissione tra una trama e la successiva
t out = 2 ⋅ t p + 2 ⋅ ti
(2)
Il tempo totale necessario affinché si concluda un ciclo nella trasmissione di una trama
confermata (Fig. 8.8-2) è:
tT = ti + tout
(3)
dove tT è anche detto “tempo di ciclo”.
New Frame i
…
ti
New (i+1) or Retransmitted (i) Frame
tout
ti
tT
…
time
Fig. 8.8-2: tempo minimo tra due frame successive
22
Per legare il comportamento prestazionale di tale protocollo con i parametri
•
•
•
•
d = distanza del collegamento;
C = capacità del link trasmissivo;
v = velocità di propagazione del mezzo (tipicamente 2×108 m/s per linee dati);
L = lunghezza della trama che circola;
si utilizza il fattore a, definito come il rapporto tra il tempo di propagazione sul link e il tempo
di trasmissione di un messaggio sull’interfaccia tra la stazione dati e il link:
a=
tp
ti
In tale accezione
tp =
lunghezza del mezzo [m]
d
=
velocità di propagazione [m / s ] v
ti =
lunghezza del messaggio [bit ]
L
=
capacità di trasmissione [bit / s ] C
Quindi
a=
d L
⋅
v C
In letteratura a può avere un’altra interpretazione, usata soprattutto nelle reti locali:
a=
=
tp
ti
=
C ⋅tp
L
=
numero di bit in transito tra i 2 capi del mezzo
=
lunghezza del messaggio
lunghezza del mezzo espresso in bit
numero di bit per messaggio
cioè, se i messaggi vengono trasmessi in modo continuativo, a rappresenta il numero di
messaggi che al massimo si possono trovare in volo sul link di comunicazione.
a potrebbe anche essere non intero, in quanto alcuni bit, dei messaggi trasmessi, possono non
essere arrivati a destinazione.
In ogni caso, il fattore a è un parametro importantissimo, che dipende dalla capacità del link e
che sarà tanto più grande, quanto maggiore è la distanza del collegamento. Genericamente, per
i vari tipi di collegamenti si ha:
a<<1
a<1
a>1
a>>1
→
→
→
→
HSLNS e sistemi multiprocessori
LANS
collegamenti terresti
collegamenti via satellite
Nell’analisi prestazionale del protocollo STOP-AND-WAIT conviene utilizzare la seguente
definizione per a:
a=
tT
>1
ti
(4)
visto che tT contiene il tempo di trasmissione ti del singolo messaggio.
23
Esattamente utilizzando la (2) e la (3) segue che
a=
tp
tT ti + t out ti + (2 ⋅ t p + 2 ⋅ ti )
=
=
= 3+ 2 > 3
ti
ti
ti
ti
Ritornando alla Fig. 8.8-2, allo scadere del tout, in virtù delle assunzioni fatte, o arriva un ACK,
e quindi una nuova frame può essere trasmessa, oppure dovrà essere ritrasmessa l’ultima frame.
Quindi, il sistema non può spedire più di una frame ogni tT secondi.
Ciò equivale a dire che, nel caso in cui non vi siano errori in trasmissione, il massimo
throughput
1
[ pack / sec]
MAX THROUGHPUT =
tT
In realtà, il throughput ottenibile sarà minore, in quanto il mezzo di comunicazione sarà affetto
da una certa probabilità di errore p (si trascurano gli errori sugli ACK). Detta q=(1-p) la
probabilità che una frame sia ricevuta correttamente, la probabilità di ricevere una frame
corretta dopo n ritrasmissioni (considerate indipendenti l’una dall’altra) è:
Prob{n ritrasmissioni}=pn q
Il numero medio di errori in trasmissione è quindi:
∑ n ⋅ pn ⋅ q
Quindi in caso di errori in linea, il tempo medio necessario per ricevere una frame
correttamente è pari a:
t v = tT + [tT ⋅ (Pr ob. 1 ritrasmissione + 2tT ⋅ (Pr ob. 2 ritrasmissioni + ...] =
[
]
[
]
= tT ⋅ 1 + ∑ n ⋅ p n ⋅ (1 − p) = tT ⋅ 1 + p ⋅ (1 − p) ∑ n ⋅ p n−1 =



d n
d
= tT ⋅ 1 + p ⋅ (1 − p) ∑
p  = tT ⋅ 1 + p ⋅ (1 − p) ∑ p n  =
dp 
dp





1 
d  1 
 = tT ⋅ 1 + p ⋅ (1 − p )
=
= tT ⋅ 1 + p ⋅ (1 − p) ⋅ 
2 
−
−
(
1
)
(
1
)
dp
p
p





1 − p + p 
t
= T
= tT ⋅ 

 (1 − p )  (1 − p)
Notiamo che nel caso in cui p = 0, ovvero non ci sono errori in linea, chiaramente tv coincide
con tT. In questa relazione sono stati trascurati gli errori che potrebbero danneggiare gli ACK.
Nelle ipotesi in cui il trasmettitore sia in saturazione, allora, tv rappresenta il tempo che
trascorre tra la corretta trasmissione di due frame.
Quindi il massimo throughput risulta essere l’inverso di tv, ossia:
λmax =
1 (1 − p) (1 − p)
=
=
tv
tT
a ⋅ ti
dove si è utilizzata la (4) per esprimere λmax in funzione di a.
24
Detto λ l’effettivo arrival rate delle frame, se si considera che
ρ=
λ
µ
con
1
= ti
µ
segue necessariamente che
ρ = λ ⋅ ti ≤ λmax ⋅ ti =
(1 − p )
(1 − p )
<1
ti =
a ⋅ ti
a
Questa relazione mostra chiaramente come il
THROUGHPUT DIMINUISCA ALL’AUMENTARE
DELLA PROBABILITÀ DI ERRORE E DEL FATTORE A.
Questo provoca un degradamento delle prestazioni del protocollo di linea, in termini di
throughput, all’aumentare della lunghezza d del collegamento (essendo d proporzionale al
parametro a).
PROTOCOLLO GO-BACK N
Vediamo adesso di analizzare le performance di un protocollo GO-BACK N, ritenendo valide le
stesse ipotesi supposte in precedenza, e supponendo, inoltre, che la finestra di trasmissione
abbia dimensione infinita.
Poiché, in questo protocollo, le frame vengono spedite continuamente, il tempo minimo che
trascorre tra due trasmissioni risulta essere pari al tempo necessario a spedire una frame;
Quindi, se non ci sono errori,
t T = ti
Invece in condizioni di errore, il tempo medio necessario per trasmettere una frame
correttamente è pari a:
 t
 
d  1 
 =
t v = t i + ∑ np n (1 − p )tT = t i 1 + T p(1 − p )∑ np n −1  =t i 1 + ap (1 − p) 
(
1
)
−
t
dp
p


i

 

1 + p (a − 1) 
1 − p + ap 
1 
= t i 1 + ap(1 − p )
= ti 

 = ti 
2 
(1 − p ) 
 (1 − p) 
 (1 − p) 

Poiché abbiamo supposto il sistema in condizioni di saturazione, il massimo throughput è:
λ max =
1 1  (1 − p ) 
= 

t v t i 1 + p ( a − 1) 
mentre il fattore di utilizzazione ρ risulta essere
 (1 − p ) 
ρ = λ ⋅ t i < λmax ⋅ t i = 

1 + p(a − 1) 
Anche in questo caso λ max diminuisce all’aumentare di p e di a.
Dalla formula appena trovata si deduce, però, che, fissato a, il massimo throughput
raggiungibile con il protocollo GO-BACK N risulta essere maggiore di quello ottenibile con il
protocollo di tipo STOP AND WAIT (l’uguaglianza si ha quando a = 1, condizione che non si può
25
mai verificare visto che amin=3), in quanto l’incidenza di a è molto smorzata dal fattore
moltiplicativo p:
λmax (GO − BACK − n) >> λmax ( STOP − AND − WAIT )
Quindi tanto maggiore è a, ossia tanto maggiore è la distanza del collegamento e/o la capacità
del mezzo, tanto è più vantaggioso un protocollo Go Back N rispetto ad un protocollo Stop and
Wait. Per a estremamente piccolo, il protocollo Go Back N è prestazionalmente equivalente al
protocollo Stop and Wait.
I protocolli reali hanno una finestra di trasmissione finita, al cui dimensione influenza il throughput.
Detta n la dimensione di tale finestra, n ti dovrà essere maggiore del tempo necessario a ricevere un
ACK, in modo da non avere idle time, anche nel caso in cui tutte le frame sono ricevute
correttamente. Si intuisce che rendere più grande l’ampiezza della finestra di trasmissione, permette
di diminuire l’overhead (rapporto tra la lunghezza del campo di controllo e la lunghezza totale della
trama) intrinsecamente presente in ogni protocollo di linea.
Quindi è estremamente importante dimensionare opportunamente la finestra di trasmissione,
visto che finestre troppo grandi causerebbero pesanti ritrasmissioni e quindi lunghi tempi di attesa.
Se si adotta un meccanismo Select Repeat (utilizzato nei collegamenti satellitari) si può aumentare
notevolmente l’ampiezza della finestra di trasmissione, utilizzando buffer di grande capienza, per
poter contenere tutte quelle trame che, eventualmente, devono essere riordinate.
8.9 Dimensionamento della Frame
La dimensione della frame, influenza chiaramente il throughput del protocollo di linea.
ƒUtilizzare frame troppo piccole equivale a spedire sul canale control bits, piuttosto che dati.
La presenza di un campo dati ristretto rispetto al campo di controllo della frame,
aumenterebbe notevolmente l’overhead, ma limiterebbe la probabilità di errore e di
ritrasmissione.
ƒViceversa se le frame sono troppo lunghe si ha una maggiore probabilità che queste vengano
corrotte: quindi per ottenere una corretta ricezione, sono necessarie più ritrasmissioni, con
conseguente riduzione del throughput.
Esiste una lunghezza ottima per le frame, la quale consente di massimizzare il data throughput.
Gli studi compiuti hanno mostrato che le variazioni del throughput sono contenute per lunghezze di
frame appartenenti ad un ampio intorno del proprio valore ottimo.
Per poter ricavare la lunghezza ottima della frame, è necessario conoscere
•
•
•
le caratteristiche del collegamento,
le modalità di ritrasmissione e
la probabilità di errore sul singolo link (collegamento).
PER COLLEGAMENTI SATELLITARI,
la probabilità pb, di avere un bit della frame corrotto, è uguale alla probabilità che venga inficiato da
errore un qualsiasi altro bit: cioè gli errori si presentano in modo random, ma uniformemente
distribuiti nel tempo e sulla distanza.
Detta l la lunghezza in bit del data field, ed l’ la lunghezza del control field, la probabilità p che
almeno un bit della frame sia affetto da errore è pari a:
p = 1 − (1 − p b ) l + l '
dove pb è la probabilità di errore sul singolo bit.
26
Dalla precedente relazione, fissati pb e l’, si può ricavare il valore ottimo di l. Inoltre per piccoli
valori di pb
 l + l'
(−1) k pbk =
= 1 − ∑ 
k =0  k 
 l + l' 2
 pb + ... ≅ (l + l ' ) pb
= 1 − 1 + (l + l ' ) pb − 
2


p = 1 − (1 − pb )
l +l '
l +l '
PER COLLEGAMENTI TERRESTRI,
invece, l’ipotesi di bit indipendentemente soggetti ad errori, non risulta essere valida, in quanto gli
errori si presentano per lo più a burst, ossia tendono a danneggiare un gruppo di bit in sequenza.
Degli esperimenti condotti hanno mostrato che la probabilità di errore risulta essere
proporzionale alla lunghezza della frame.
Quindi è importante esaminare come la lunghezza della frame influenza il throughput del protocollo
di linea.
Dato il protocollo di linea GO-BACK N, consideriamo una stazione A, in saturazione, che trasmette
frame con un rate pari a λmax frame/sec.
Il data rate medio (numero max di bit dati che è possibile trasmettere nell’unità di tempo), inviato
alla stazione ricevente è pari a:
D = λmaxl =
(1 − p)l
{ti [1 + (a − 1) p]}
Se C bps è la capacità trasmissiva del canale,
ti =
(l + l ' )
C
⇒ C=
(l + l ' )
ti
da cui segue che il data rate normalizzato alla capacità trasmissiva del link vale:
 (1 − p)   l 
t
(1 − p)l
D
 ⋅ 
=
⋅ i = 

C {ti [1 + (a −1) p]} (l + l' ) 1 + (a −1) p   l + l' 
Essendo D<C, tanto più D/C è prossimo all’unità, quanto più migliorano le prestazioni del sistema.
L’andamento di D/C è riportato in Fig.8.9-1, in cui l’ = 48 bits e pb=10 -5 .
È interessante notare come nella prima parte della curva, il rapporto D/C (data rate normalizzato),
cresce linearmente al crescere di l.
Le curve a campana mostrano che la lunghezza ottima per il campo dati della frame è di circa 1000
bits, visto che per l=1000 bits, D/C assume il valore massimo.
Per il protocollo HDLC, la lunghezza ottima della frame è di 1048 bits in cui
⇒ 1024 bits sono contenuti nel campo dati
⇒ e 24 bits nell’header.
27
D/C
1
0.9
Terrestrial link
2tp=100 msec
48 kbps
0.8
Satellite link
48 kbps
2tp=700 msec
4800 bps
0.7
0.6
0.5
0.4
0.3
0.2
10
100
1000
10000
l (bits)
Fig. 8.9-1: lunghezza l del campo dati in funzione del data rate normalizzato alla capacità
rasmissiva del link, in un del protocollo GO-BACK N in cui pb=10 -5 e l’ = 48 bits.
28