4.3.1 Switch Ottico · In pratica, sul connettore a 25 piedini si trovano direttamente i segnali...

__________________________________________________________________

122

4.3.1 Switch Ottico

Figura 0.34 : Foto di uno degli switch ottici utilizzati

Gli switch ottici utilizzati sono dei dispositivi a tre porte il cui schema è riportato

nella Figura 0.357. Le tre porte costituenti lo switch sono indicate nello schema

con le lettere A, B e C.

Figura 0.357 : Schema di principio degli switch ottici utilizzati

Tramite un segnale elettrico di controllo si può cambiare lo stato del dispositivo

agendo sul circuito ottico al suo interno. Nello stato di riposo (stato 1), l’apparato

collega le porte A e B, mentre variando opportunamente il segnale di controllo si

può chiudere il circuito ottico al fine di collegare le porte A e C (secondo stato).

Agendo dunque sulla tensione di controllo del dispositivo è possibile commutare

il flusso ottico dalla fibra di esercizio alla fibra di backup.

La commutazione dallo stato 1 allo stato 2, avviene nel momento in cui si

presenta una differenza di potenziale maggiore o uguale a 4.5V sulla porta di

controllo dello switch. I livelli di tensione relativi alle possibili variazioni di stato

del dispositivo sono riportati nella tabella che segue.

A C

B

Porta di controllo

__________________________________________________________________

123

Oltre alla differenza di potenziale appena descritta, affinché possa avvenire la

commutazione dallo stato 1 allo stato 2, sono inoltre necessari almeno 40mA.

Proprio per questo motivo è stato realizzato un circuito in logica TTL, capace di

amplificare la corrente pari a 4mA disponibile all’uscita della porta parallela del

PC di management .

Il tempo di commutazione del dispositivo è pari a circa 3 ms.

4.3.2 La Porta parallela

L'interfaccia parallela del calcolatore, nella sua forma più utilizzata, è la periferica

più semplice che si possa immaginare. Non mi riferisco qui ai nuovi standard, tipo

EPP, ma al protocollo originale della parallela, che è supportato da tutti i PC,

dall'8088 in poi. In pratica, sul connettore a 25 piedini si trovano direttamente i

segnali corrispondenti ad alcuni bit di I/O, in logica TTL (con segnali a 0V e 5V).

Con "direttamente" intendo dire che i bit che vengono scritti dal processore sulle

porte di output appaiono sui piedini del connettore, e i bit della porta di ingresso

vengono letti dal segnale di tensione sul connettore. Il connettore parallelo

presenta 12 bit di output e 5 bit di input, più 8 segnali di terra. L'interfaccia

software si compone quindi di due porte di output ed una porta di input. Alcuni bit

subiscono una inversione tra quello che appare sul connettore e quello che viene

visto dal processore. I segnali elletrici utilizzati sono appartenenti alla famiglia

logcia TTL (Transistor-Transistor Logic) molto utilizzata, almeno in passato, che

presenta specifiche di ingresso/uscita non simmetriche: mentre un'uscita bassa

Tensione del segnale di controllo

comportamento

≤ 3 V Il disposito opera nel primo stato.

Il segnale ottico transita tra A e B

≤ 4,5 V ≥3V Il dispositivo non cambia stato Il percorso ottico non cambia

≥ 4,5V Il dispositvo opera nel secondo stato.

Il segnale ottico transita tra A e C

Tabella 0.1: Tabella dei livelli di tensione ai quali avvengono i cambiamenti di stato delgli switch

ottici

__________________________________________________________________

124

(0V) può assorbire una corrente significativa, un'uscita alta (5V nominali) non è in

grado di erogare più di 4 mA di corrente. E’ consigliabile l'uso di fotoaccoppiatori

per proteggere il calcolatore.

4.3.2.1 L'intefaccia software Ogni porta parallela del sistema viene vista tramite tre indirizzi di I/O consecutivi:

"base", "base+1", "base+2". Il registro "base+1" è un registro di input, e viene

usato per leggere i 5 segnali di ingresso del connettore, "base" e "base+2", invece,

sono registri di output, e quando vengono letti restituiscono l'ultimo valore scritto

(cioè lo stato attuale dei segnali al connettore). L'effettiva mappatura tra i bit nei

registri e i piedini del connettore è spiegata nella figura che segue.

Figura 0.368 : Descrizione dell’interfaccia parallela L'indirizzo base della porta parallela (detto ``BASE'' nel seguito) è 0x3bc per

/dev/lp0, 0x378 per /dev/lp1 e 0x278 per /dev/lp2.

La porta base+0, o semplicemente , (porta dati) controlla i segnali dei dati della

porta (da D0 a D7 per i bit da 0 a 7, rispettivamente; stati: 0 = basso (0 V), 1 =

alto (5 V)). Una scrittura in tale porta fissa i dati sui pin. Una lettura restituisce i

dati che sono stati scritti per ultimi. La porta base+1 (porta di Stato) è di sola

lettura e restituisce lo stato dei seguenti segnali d'ingresso:

__________________________________________________________________

125

♦ Bit 0 e 1, sono riservati.

♦ Bit 2 stato dell'IRQ

♦ Bit 3 ERROR (1 = alto)

♦ Bit 4 SLCT (1 = alto)

♦ Bit 5 PE (1 = alto)

♦ Bit 6 ACK (1 = alto)

♦ Bit 7 -BUSY (0 = alto)

La porta base+2 (porta di Controllo) è di sola scrittura (una lettura restituisce gli

ultimi dati scritti) e controlla i seguenti segnali di stato:

♦ Bit 0 -STROBE (0 = alto)

♦ Bit 1 AUTO_FD_XT (1 = alto)

♦ Bit 2 -INIT (0 = alto)

♦ Bit 3 SLCT_IN (1 = alto)

♦ Bit 4, quando impostato ad 1, abilita l'IRQ della porta parallela (che

si verifica nella transizione da basso ad alto di ACK)

♦ Bit 5 controlla la direzione del modo esteso (0 = scrittura, 1 = lettura)

ed è assolutamente di sola scrittura (una lettura di questo bit non

restituisce nulla di utile).

♦ Bit 6 e 7, sono riservati.

Configurazione dei pin (connettore a "D" femmina a 25-pin) (i = input, ingresso; o

= output, uscita):

1io -STROBE, 2io D0, 3io D1, 4io D2, 5io D3, 6io D4, 7io D5, 8io D6, 9io D7, 10i ACK, 11i -BUSY, 12i PE, 13i SLCT, 14o AUTO_FD_XT, 15i ERROR, 16o -INIT, 17o SLCT_IN, 18-25 Ground (Massa)

I pin da me collegati alla porta di controllo degli switch sono stati i PIN 2 e 3 della

sezione “base” avente come indirizzo di memoria utilizzato dal processore 0x378.

__________________________________________________________________

126

4.3.3 Amplificatore di corrente Le uscite della LPT1 forniscono,come appena detto, tensioni 0-5V erogando una

corrente, in corrispondenza dei 5 V, pari a circa 4mA. Lo switch ottico da me

utilizzato, affinché commuti il suo stato necessita di una tensione pari a 5V e di

una corrente pari a 40mA. Per queste ragioni ho realizzato un amplificatore di

corrente capace di amplificare la corrente in uscita dalla LPT1 di un fattore 10.

Tale amplificatore è stato realizzato utilizzando l’integrato 74AC541 secondo il

circuito mostrato in Figura 0.379. Tramite questo integrato si è potuto ottenere un

buffer digitale ovvero un circuito che mantiene inalterato il livello logico dall’

ingresso all’uscita ma che in corrispondenza di esso presenta due intensità di

corrente diverse. In sostanza si rende disponibile su ciascuna uscita una corrente

maggiore di quella fornita in ingresso; in questo modo il componente si comporta

da interfaccia tra la porta di controllo (LPT1) e la periferica controllata (switch

ottico).

Figura 0.379 : Schema circuitale dell'amplificatore di corrente implementato

__________________________________________________________________

127

All’interno dell’integrato sono presenti 8 buffer digitali disposti come in figura:

Figura 0.20 : Schema circuitale dell'integrato 74AC541

Sono state utilizzate due delle 8 uscite disponibili corrispondenti a due ingressi

collegati entrambi all’uscita della LPT1. Un’uscita è stata utilizzata per gestire lo

switch ottico, mentre all’altra è stato collegato un LED luminoso utilizzato per

evidenziare lo stato effettivo dello switch ottico:

♦ Switch stato 1 – led spento

♦ Switch stato 2 – led acceso

__________________________________________________________________

128

Capitolo 5

CONFIGURAZIONE DELLA RETE E PROVE

OGGETTIVE

Nel capitolo vengono riportate la descrizione completa delle prove effettuate ed i

risultati ottenuti, sono dapprima descritti i criteri con i quali si è scelto il setup del

test-bed, i tipi di servizi sotto test e le modalità con le quali si interviene sul

settaggio dei router.

5.1 TIPOLOGIE DI PROVE E NORMATIVE DI RIFERIMENTO.

Nel corso dei test, per la valutazione dei risultati, è stato fatto riferimento ad

opportune metriche che stabiliscono i requisiti minimi di QoS da rispettare per

alcuni tipi di servizi indipendentemente dalle condizioni di traffico. Le metriche

sono riportate nella tabella seguente:

Figura 5.1: Tabella requisiti minimi per alcuni servizi multimediali

__________________________________________________________________

129

La tabella si riferisce ad un traffico DiffServ (RFC 2474,RFC 2475) consigliato

ed è stata a sua volta ricavata dalla normativa ITU-T G1010 riportata in figura:

Figura 5.2: User-centric Delay and Packet Loss requirements – ITU G.1010*

Una prima prova di misure è stata effettuata con lo scopo di testare i limiti

hardware dei PC utilizzati come client, ed i limiti del software Chariot utilizzato

per simulare le sessioni di scambio dei dati. Dalle misure effettuate è risultata una

differenza di prestazioni tra i due client sia in termini di perdita dei pacchetti sia in

termini di jitter. Questo comportamento è stato registrato in completa assenza di

traffico di saturazione, quindi la differenza di prestazioni, che inoltre differiscono

anche a seconda del verso di trasmissione, è stata imputata alle schede di rete dei

due PC diverse sia per modello che per configurazione.

Le differenze sperimentate di cui si parla in realtà sono minime ma differenze di

prestazioni anche piccole su traffici molto grandi, quali quelli che si trattano nella

rete, impongono di non trascurare i dettagli e di cercare per quanto possibile le

soluzioni migliori ottenibili.

Si è reso dunque necessario un settaggio delle schede di rete nella ricerca di

trovare le condizioni ottime a partire dai materiali a disposizione.

0%

Packet Loss

Command/ control

(eg Telnet,Interactive

games)

Conversationalvoice and video

Voice/videomessaging

Streamingaudio/video

Transactions(eg E-commerce,Web-browsing, E-

mail access)

Messaging,Downloads

(eg FTP,still image)

FaxBackground

(eg Usenet)

5%

100 msec 1 sec 10 sec 100 sec

Zeroloss

Delay

__________________________________________________________________

130

5.1.1 Settaggio delle schede di rete

A causa delle differenti prestazioni sperimentate col Chariot si è proceduto per

esclusione a capire quali potessero essere le cause che generavano queste

differenze, seppure lievi.

In primo luogo si è pensato di mandare come flussi di test dei flussi di tipo

Netmeeting aumentandone gradualmente il throughput14 e tenendo nota dei valori

riscontrati a seconda della macchina e della scheda di rete della macchina stessa.

Un primo tentativo è stato quello di capire se i valori differenti che si

riscontravano cambiando i PC dipendessero dalla frequenza del clock dei

processori o dalle schede di rete. La vasta disponibilità di macchine presenti nel

laboratorio di reti ottiche dinamiche ha reso possibile questo tipo di prove.

Per prima cosa si è proceduto con una misura dei vari parametri: Throughput,

One-Way-delay, Lost Data, Jitter con flussi via via crescenti lasciando ogni

scheda di rete montata sul suo PC di origine. Quello che si riscontrava è che si

ottenevano parametri più buoni da macchine con processori meno potenti di altre,

Questo dato ha chiaramente evidenziato che le prestazioni differivano per la

diversità dei modelli delle schede di rete, per questo motivo su due PC diversi

sono state montate due schede di rete uguali, ma questo non ha portato ad un

miglioramento della situazione. Dunque le prestazioni dipendono in maniera

congiunta dalle schede di rete ed anche dal PC su cui sono montate. In seguito a

questa considerazione sono state montate tutte le schede di rete a dispostone su

tutti i PC a disposizione indistintamente fino a trovare le coppie ottime PC-scheda

per potere iniziare le prove.

Naturalmente per ognuna delle prove sono state create delle tabelle che non

vengono riportate in primo luogo per il numero elevato, in secondo luogo perché

non costituiscono delle informazioni importanti ai fini dell’indagine sulla qualità

del servizio.

Si riporta comunque per completezza un esempio di come questa prove siano state

effettuate, in questo caso specifico si presenta l’andamento di un flusso

14 Portata

__________________________________________________________________

131

Netmeeting (protocollo RTP) dalla macchina di indirizzo 192.168.6.28 alla

macchina di indirizzo 192.168.7.11 ripetendo la prova 5 volte, in seguito si inverte

il flusso e si ripetono altre prove; al termine delle prove i dati vengono mediati e

sulla base delle medie si traggono conclusioni su quali macchine e schede

adoperare.

Prova 1 (6.28 7.11) script Netmeeting 10Mbps)

Di cui si mostra il grafico dei valor medi:

0

1

2

3

4

5

6

7

8

9

10

Valori Medi

Valori Medi

Valori Medi 9,8575 1,25 0,0005 9,5

Throughtput (Mbps) One way delay (ms) Loss Data (%) Jitter (ms)

Throughtput (Mbps) One way delay (ms) Loss Data (%) Jitter (ms)

9,86 2 0 10

9,83 1 0,001 10

9,84 1 0,001 11

9,9 1 0 7

__________________________________________________________________

132

Prova 2 (7.11 6.28) script Netmeeting a 10Mbps

L’obbiettivo consiste nel decidere in quale verso mandare il flusso, valutando le

caratteristiche di test.

Throughtput(Mbps) One way Delay (ms) Loss Data (%) Jitter (ms)

9,94 1 0,001 3

9,96 1 0 3

9,84 1 0,01 11

9,97 1 0 3

Di cui si graficano dei valori medi:

0

1

2

3

4

5

6

7

8

9

10

10Mbps 7.11--->6.28

Valori Medi 7.11--->6.28

Valori Medi 7.11--->6.28 9,9275 1 0,00275 5

Throughtput(Mbps) One way Delay (ms) Loss Data (%) Jitter (ms)

Questo tipo di prova veniva ripetuto per valori di throughput sempre maggiori, su

più macchine al variare delle schede di rete.

__________________________________________________________________

133

5.2 CONFIGURAZIONE DEI ROUTER

5.2.1 Misure per il dimensionamento dell’Expedited Forwarding

Trovata la configurazione ottima per il settaggio delle schede di rete che

corrisponde a quella descritta nel paragrafo dei dispositivi utilizzati, circa le

prestazioni del server Chariot è stato deciso di instaurare delle sessioni con al

massimo 60 Mbit/s. Questa decisione è stata presa al fine di non stressare

eccessivamente le schede di rete dei client e la capacità computazionale dei PC

stessi.

La prima serie di misure finalizzata alla configurazione di una piattaforma di

servizi gestiti in maniera DiffServ è stata realizzata su rete scarica; il traffico

presente i rete, costituito da 5 flussi di videoconferenza (Netmeeting) da 10Mbit/s

etichettato EF15 è stato generato dal server Chariot ed in queste condizione è stato

valutato il comportamento di due diversi Drop Profile16 in termini di Throughput,

perdita dei pacchetti, Jitter massimo e One-Way-Delay massimo.

Il primo Drop Profile di seguito indicato come drop_profile_1 è riportato di

seguito in figura: [edit class-of-service drop-profiles] admin@lab1# expedited-forwarding { interpolate { fill-level [ 0 10 15 20 25 30 ]; drop-probability [ 0 20 50 75 100 ]; }

Figura 5.3: Drop Profile 1 della coda Expedited Forwarding Al 30% di riempimento della coda del traffico EF drop_profile_1 presenta una

probabilità di drop (scarto) pari al 100%. Questo profilo è molto restrittivo poiché

la coda della forwarding class EF non viene mai riempita completamente, ed è 15 Expedited Forwarding 16 Letteralmente “profilo di scarto” detta il comportamento che deve avere il router quando si carica una cosa in termini di scarto dei pacchetti.

__________________________________________________________________

134

stato pensato per garantire valori di jitter e di one-way-delay molto bassi anche

se a scapito di una perdita di pacchetti alta.

Nella tabella che segue sono riportati i risultati dei test riportati su 10 prove:

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) 1 0,12 11 2 2 0,06 10 1 3 0,04 11 1 4 0,004 11 1 5 0,04 11 1 6 0,009 10 1 7 0,058 10 1 8 0,03 10 1 9 0,005 12 1

10 0,1 11 2

Figura 5.4: Flussi Netmeeting EF su rete scarica con drop_profile_1 Per confrontare la tenuta del Drop Profile con situazioni più realistiche, lo stesso

traffico EF è stato invito su rete carica. Il traffico di saturazione è di tipo BE17 ed è

stato generato da quattro porte FastEthernet, con rate generato variabile tra 10 e

100 Mbit/s, e due porte GigabitEthernet con rate fisso di 800Mbit/s nei due versi

trasmissivi. Sono riportati in tabella i risultati del comportamento del

drop_profile_1 in termini di perdita dei pacchetti, jitter massimo e one-way-delay

massimo:


10 0,066 11 3

Figura 5.5: Flussi Netmeeting EF su rete carica con traffico BE, drop_profile_1

Anche in condizione di rete carica tutti i valori sono al di sotto di quelli riportati

nella tabella di riferimento di figura 11, ed inoltre sono comparabili con quelli 17 Best Effort

__________________________________________________________________

135

registrati nel caso di rete scarica. Questo comportamento ricalca in pieno le

caratteristiche cui mira l’approccio DiffServ che riserva ai flussi EF un

trattamento privilegiato. A dimostrazione del corretto funzionamento della QoS

differenziata mediante il server Chariot su rete carica nelle medesime condizioni

sono stati mandati: 4 flussi Netmeeting da 10 Mbit/s etichettati EF ed un flusso

Netmeeting da 10 Mbit/s etichettato BE, è stato quindi possibile confrontare le

modalità di trattamento delle due diverse tipologie di traffico.

Nella tabella che segue sono riportati i risultati dei test:

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF BE EF BE EF BE

1 0,01 24,8 11 9 4 50 2 0,05 25 11 15 4 50 3 0,065 24,9 11 15 3 50 4 0,004 24,8 10 13 4 50 5 0,035 25,1 10 17 4 50 6 0,1 24,9 13 12 4 50 7 0,006 24,8 10 18 4 50 8 0,11 24,7 13 24 5 50 9 0,07 24,8 11 25 4 50

10 0,08 24,8 11 16 3 49

Figura 5.6: 4 flussi Netmeeting EF, un flusso Netmeeting BE su rete carica con traffico BE, drop_profile_1 per EF

Le stesse misure sono state effettuate utilizzando un secondo Drop profile per il

traffico EF nel seguito indicato come drop_profile_2 ed illustrato in figura:

[edit class-of-service drop-profiles] admin@lab1# expedited-forwarding { interpolate { fill-level [ 0 50 75 100 ]; drop-probability [ 0 1 50 100 ]; }

Figura 5.7: Configurazione drop_profile_2 della coda Exedited Forwarding

__________________________________________________________________

136

Questo Drop Profile prevede una probabilità di drop del 100% solo dopo aver

raggiunto il 100% di riempimento della coda ed è meno aggressivo del

drop_profile_1 che prevedeva uno svuotamento della coda a partire dal 30% di

riempimento della stessa. Come previsto in questo caso diminuisce la perdità dei

pacchetti, ma aumentano in maniera sensibile sia il jitter massimo che il one-way-

delay massimo a causa del maggior tempo che i pacchetti passano all’interno della

coda. Di seguito vengono riportati i valori dei test ottenuti col drop_profile_2

nelle stessa condizioni del drop_profile_1.


10 0,09 13 4

Figura 5.8: 5 flussi Netmeeting EF su rete scarica con drop_profile_2

Figura 5.9: 5 flussi Netmeeting EF su rete carica con traffico BE con drop_profile_2


10 0,02 12 3

__________________________________________________________________

137

Figura 5.10: 4 flussi Netmeeting EF , un flusso Netmeeting BE su rete carica con traffico BE , drop_profile_2 per EF

Una nuova serie di misure è stata realizzando trasmettendo con il server Chariot 5

flussi Netmeeting EF con traffico di saturazione di tipo EF in modo da

congestionare completamente la coda EF e porci nella condizione limite per

questa tipologia di traffico. Da questo test è possibile confrontare i due Drop

Profile in maniera più netta, e dalle misure risulta che il parametro che subisce i

cambiamenti più rilevanti passando da un profilo all’altro è solo il one-way-

delay, gli altri parametri presentano infatti variazioni poco apprezzabili fra di loro

a seconda del profilo.

Di seguito si riporta una tabella di confronto tra i due one-way-delay sperimentati

con i due Drop Profile differenti:

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF BE EF BE EF BE

1 0,06 24,9 11 15 4 50 2 0,07 25 10 18 3 50 3 0,05 24,8 10 13 3 49 4 0,07 24,9 11 17 4 50 5 0,08 24,7 12 21 4 50 6 0,15 25 11 24 4 49 7 0,005 24,7 10 21 3 50 8 0,07 24,9 11 16 4 50 9 0,19 24,8 11 18 5 51 10 0,02 24,7 11 16 4 50

__________________________________________________________________

138

ONE WAY DELAY MAX

0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

one

way

del

ay m

ax in

ms

traffico con dropprofile_2traffico con dropprofile_1

Figura 5.11: Confronto tra one-way-delay massimi per i due Drop Profile

Dalle misure effettuate si è accertato che pur variando le dimensioni del buffer , il

Drop Profile o il Trasmission Rate associato alle code EF le perdite dei pacchetti

sono estremamente basse. Il motivo per cui pur avendo un Drop Profile molto

aggressivo si sperimentano basse perdite dei pacchetti è da imputare alla

configurazione dei router Juniper M10, infatti circa lo scheduling dei pacchetti è

possibile “settare” tre livelli di priorità:

• Bassa

• Alta

• Molto alta

Per il traffico Best Effort è stata scelta la prima, per il traffico Assured

Forwarding la seconda ed infine la terza per il traffico Expedited Forwarding;

quest’ultimo infatti deve essere più cautelato rispetto alle altre tipologie.

Le differenze che sussistono tra le tre classi sono le seguenti:

la classe con priorità alta, fintanto che si ha disponibilità di banda, viene servita

prima di quella con priorità bassa, la classe molto alta ha precedenza su tutte le

altre e la coda associata a questa classe è servita finché ci sono pacchetti da

spedire indipendentemente dalla banda disponibile. A causa di questo motivo le

__________________________________________________________________

139

perdite dell’EF sono sempre trascurabili, a parte il caso limite in cui la rete viene

caricata esclusivamente con traffico EF.

Per garantire la banda alle classi con priorità bassa ed alta viene allocata alla

classe con priorità molto alta una quantità di banda pari al traffico che fa fluire

nella rete; questo significa che per ottimizzare le risorse e configurare i router in

modo che tutti i servizi rispettino le metriche di QoS bisogna conoscere prima la

quantità ed il tipo di traffico dati presenti in rete.

5.2.2 Misure per il dimensionamento dell’Assured Forwarding. La successiva serie di misure è stata realizzata al fine di dimensionare

opportunamente le risorse di rete per gestire il traffico Assured Forwarding.

Anche in qusto caso durante le prove sono stati implementati due diversi Drop

Profile per il traffico AF18 riportate di seguito:

[edit class-of-service drop-profiles] admin@lab1# assured-forwarding { interpolate { fill-level [ 0 10 25 30 40 50 ]; drop-probability [ 0 1 25 60 80 100 ]; }

Figura 5.12: Configurazione del drop profile 3 della coda Assured Forwarding

18 Assured Forwarding

__________________________________________________________________

140

[edit class-of-service drop-profiles] admin@lab1# assured-forwarding { interpolate { fill-level [ 0 10 20 30 40 50 60 70 80 100 ]; drop-probability [ 0 1 2 3 5 20 40 80 100 ]; }

Figura 5.13: Configurazione del drop profile 4 della coda Assured Forwarding Il drop_profile_3 è più stringente del drop_profile_4, il secondo infatti prevede il

100% di probabilità di scarto dei pacchetti al 100% di riempimento del buffer

della coda, il primo invece presenta una probabilità di drop del 100% al 50% di

riempimento della coda.

Durante la prova sono stati generati mediante il server Chariot due flussi AF e tre

flussi EF, ciascuno costituito da streaming Netmeeting da 10 Mbit/s, il traffico di

saturazione inviato dall’analizzatore –generatore di traffico Anritsu MD1230A è

stato suddiviso come segue: due porte GigabitEthernet inviano sul link sotto test

traffico di tipo BE, due porte FastEthernet inviano traffico AF ed altre due porte

FastEthernet inviano traffico EF.

Il traffico totale presente in rete è dunque il seguente:

• EF: 32 Mbit/s (MD1230A) + 30 Mbit/s (server Chariot: 3 EF sotto test)

• AF: 80 Mbit/s (MD1230A) + 20 Mbit/s (server Chariot: 2 AF sotto test)

• BE: 800 Mbit/s (MD1230A)

In una prima sessione di misure per il traffico EF è stato impiegato il

drop_profile_1, per il traffico AF il drop_profile_2 ed infine il trasmission rate19

ed il buffer size20 dello scheduler map21 sono stati dimensionati in questo modo:

19 Trasmission rate control determina le effettive condizioni di traffico provenienti da ogni forwarding class configurata. Il rate è specificato in bit/s, ed è possibile limitare la banda

__________________________________________________________________

141

TRAFFICO TRANSMISSION RATE BUFFER SIZE

EF 10% 7%

AF 10% 9%

BE 73% 79%

NC 5% 5%

Figura 5.14: Configurazione dello Scheduler

I risultati ottenuti dalle misure sono riportati nelle tabelle e nei grafici che

seguono. Per completezza sono stati riportati anche i risultati del traffico EF pur

non essendo sotto analisi.

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF AF EF AF EF AF 1 0,05 0,08 10 10 6 8 2 0,14 0,11 11 10 6 9 3 0,072 0,064 11 10 7 9 4 0,056 0,022 10 9 7 10 5 0,13 0,1 11 10 7 10 6 0,08 0,1 11 11 8 11 7 0,08 0,08 11 12 8 11 8 0,06 0,02 10 10 8 11 9 0,075 0,07 10 10 9 11

10 0,071 0,094 10 11 10 12

trasmessa all’esatto valore configurato, o lasciare che il traffico in eccesso ricada su altre code laddove sia possibile 20 Buffer Size, si utilizza per avere un controllo sulla congestione di rete, prevede ad assorbire i pacchetti derivanti da picchi di traffico, quando il buffer si riempie i pacchetti in ecceso vengono scartati. 21 Vedi appendice

__________________________________________________________________

142

LOST DATA

00,020,040,060,08

0,10,120,140,16

1 2 3 4 5 6 7 8 9 10perc

entu

ale

pacc

hett

i per

sitraf f ico EF

traf f ico AF

JITTER MAX

0

24

6

8

1012

14

1 2 3 4 5 6 7 8 9 10

valo

ri di

jitt

er m

ax in

mse

c

traf f ico EF

traff ico AF

ONE WAY DELAY MAX

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10

one

way

del

ay in

mse

c

traf f ico EF

traf f ico AF

Figura 5. 15: Tabella e grafici della sessione di misure eseguita sul traffico AF

__________________________________________________________________

143

Figura 5.386: Confronto tra il throughput del traffico EF e del traffico AF

Dai valori riportati nelle tabelle e nei grafici si può notare come le perdite ed i

valori di one-way-delay del traffico AF siano molto basse e praticamente

comparabili con quelle del traffico EF. Si osservi inoltre che i valori riportati dal

traffico AF sono molto al sotto dei QoS requirements previsti dalla normativa

ITU-T G1010 di cui la tabella in figura 11.

Poiché ci si trova molto al di sotto dei valori previsti dalla normativa e dunque si

ha un discreto margine, sono stati variati il Drop Profile, il buffer size ed il

trasmission rate con lo scopo di ottimizzare le risorse di rete ed allineare il

traffico AF alle metriche di QoS.

Nella sessione di misure che segue il traffico di saturazione generato dal Chariot è

rimasto lo stesso, il buffer size ed il trasmission rate sono stati modificati come si

nota in tabella e, per il traffico AF è stato utilizzato il drop_profile_1.


EF 8% 7% AF 9% 9% BE 78% 79% NC22 5% 5%

Figura 5.39: Seconda configurazione dello Scheduler

22 NC non classificato

__________________________________________________________________

144

I risultati ottenuti sono riportati nelle tabelle e nei grafici che seguono; come

prima sono stati riportati per completezza anche i risultati dei valori del traffico

EF.

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF AF EF AF EF AF 1 0,12 5,4 11 11 5 28 2 0,1 5,3 11 12 5 29 3 0,012 5,28 11 11 6 29 4 0,081 5,11 11 11 6 29 5 0,1 5,64 10 10 7 29 6 0,016 5,2 11 12 7 30 7 0,013 5,36 10 11 8 31 8 0,06 5,54 10 11 7 31 9 0,007 5,31 10 10 8 31

10 0,14 5,34 17 9 9 32

__________________________________________________________________

145

LOST DATA

0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10perc

entu

ale

pacc

hett

i per

sitraf f ico EF

traf f ico AF

JITTER MAX

02468

1012141618

1 2 3 4 5 6 7 8 9 10

valo

ri di

jitt

er m

ax in

mse

c

traf f ico EF

traf f ico AF

ONE WAY DELAY MAX

0

5

10

15

20

25

30

35

1 2 3 4 5 6 7 8 9 10

one

way

del

ay in

mse

c

traf f ico EF

traf f ico AF

Figura 5.18: Tabella e grafici della sessione di misure del traffico AF

__________________________________________________________________

146

Figura 5.40: Confronto del throughput del traffico EF e del traffico AF

Dai valori delle tabelle e dai grafici si nota come le perdite di pacchetti ed i valori

del one-way-delay siano aumentate rispetto al caso precedente, in particolare le

perdite percentuali dell’AF superano i limiti imposti dalle metriche di QoS,

dunque le configurazioni del buffer size, del trasmission rate ed il Drop Profile

sono state nuovamente modificate passando ad una nuova sessione di prove.

Dopo vari tentativi si è giunti ad una situazione ottimale che rispetta i limiti

imposti dalla normativa e al contempo tende a distinguere i risultati ottenuti da

traffico AF e da traffico EF.

In questa nuova configurazione è risultato essere vincente il drop_profile_2 per il

traffico AF con i valori di buffer size e di trasmission rate riportati in tabella.

TRAFFICO TRANSMISSION

RATE BUFFER SIZE EF 8% 7% AF 10% 8% BE 78% 80% NC 5% 5%

Figura 5.20: Configurazione definitiva dello Scheduler

__________________________________________________________________

147

In questa nuova configurazione è stato possibile aumentare la quantità di traffico

di analisi (Chariot). Il traffico presente in rete è stato suddiviso in questa maniera:

• EF: 32 Mbit/s (MD1230A) + 20 Mbit/s (Chariot 2 EF sotto test)

• AF: 80 Mbit/s (MD1230A) + 26 Mbit/s (Chariot 3 AF sotto test)

• BE: 800 Mbit/s (MD1230A)

Ricordo che i flussi hanno un rate di 10Mbit/s ognuno ed il flusso AF generato dal

Chariot di 26 Mbit/s è composto da due flussi da 10 Mbit/s ed uno da 6Mbit/s; è

stato possibile introdurre quest’ultimo flusso in seguito alle modifiche apportate

alla configurazione. Il valore di 6 Mbit/s è stato ricavato per tentativi ed è da

intendersi come valore limite, infatti per valori di AF maggiori di questo la rete,

per come è stata dimensionata, non è più in grado di mantenersi sotto i limiti

dettati dalle metriche di QoS. I risultati ottenuti sono riportati nelle tabelle e nei

grafici che seguono e, come al solito, per completezza vengono riportati anche le

statistiche sul traffico EF.

PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms)

EF AF EF AF EF AF 1 0,13 1,43 11 11 3 36 2 0,04 1,48 10 10 3 36 3 0,14 1,49 11 9 3 33 4 0,066 1,51 9 10 3 36 5 0,005 1,43 10 10 4 36 6 0,025 1,49 10 10 3 38 7 0,134 1,496 12 10 3 36 8 0,004 1,452 8 10 3 35 9 0,077 1,448 10 10 3 36

10 0,012 1,452 10 10 3 36

__________________________________________________________________

148

LOST DATA

00,20,40,60,8

11,21,41,6

1 2 3 4 5 6 7 8 9 10perc

entu

ale

pacc

hett

i per

sitraf f ico EF

traf f ico AF

JITTER MAX

0

24

6

8

1012

14

1 2 3 4 5 6 7 8 9 10

valo

ri di

jitt

er m

ax in

mse

c

traf f ico EF

traf f ico AF

ONE WAY DELAY MAX

05

10152025303540

1 2 3 4 5 6 7 8 9 10

one

way

del

ay in

mse

c

traf f ico EF

traf f ico AF

Figura 5.41: Tabella e grafici sessione misure traffico AF

__________________________________________________________________

149

Figura 5.22: Confronto tra il througput del traffico EF e del traffico AF

5.2.3 Configurazione definitiva. Al termine di tutte queste misure è stata scelta come configurazione definitiva la

seguente:

• Traffico EF drop_profile_1

• Traffico AF drop_profile_2

• Scheduler come in figura 17.

La configurazione completa e definitiva di entrambi i router per queste prove

oggettive e per le prove soggettive che verranno descritte nel prossimo capitolo e

riportata in appendice.

Le misure che seguiranno sono state realizzata per testare l’efficienza della

gestione delle politiche di Qualità di Servizio.

Sulla rete settata secondo l’ultima configurazione descritta sono state effettuate

una serie di misure al fine di mostrare la differenza di trattamento, in termini di

perdite di pacchetto, one-way-delay e jitter, che uno stesso servizio riceve a

seconda della sua etichettatura.

__________________________________________________________________

150

5.3 TEST SUI SERVIZI

5.3.1 Test sui servizi di video conferenza. Le prime due serie di misure sono state effettuate sul servizio Netmeeting, lo

stesso usato per il settaggio delle configurazioni e dei carichi, che è un servizio di

tipo real time e richiede valori molto bassi per quanto riguarda i parametri di

bitter, one-way-delay, e perdita dei pacchetti percentuale.

Tra le varie configurazioni di traffico provate, si riportano di seguito i casi più

significativi:

Caso limite AF.

Dal server Chariot sono stati inviati 6 flussi Netmeeting cosi ripartiti:

• 2 flusso EF da 10 Mbit/s

• 1 flusso BE da 10 Mbit/s

• 3 flussi AF per un totale di 30 Mbit/s

Al traffico prodotto dal Chariot vanno sommati gli 80 Mbit/s AF e i 32 Mbit/s EF

generati dalle FastEthernet dell’Anritsu MD1230A, più gli 800 Mbit/s generati

dalle interfacce GigabitEthernet dello stesso generatore.

Figura 5.23: Throughput caso limite AF

__________________________________________________________________

151

Rispetto al carico dei settaggi in questa prova il traffico del Chariot è stato

ulteriormente aumentato di 10 Mbit/s etichettati come traffico EF.

La scelta di questo particolare grafico sviluppato su una sessione di cinque minuti

anziché di uno è dovuto alla particolare resa cromatica che per contrasto rende

immediatamente conto della differenza del trattamento delle tre tipologie: EF, AF

e BE. Si può notare come i flussi a parità di bit-rate nominale sperimentino

prestazioni diverse in base alla classe di servizio di appartenenza. I flussi EF,

quelli più privilegiati hanno throughput poco variabile e praticamente uguale a

quello nominale, il flusso BE (quello celeste) come ci si aspettava ha perdite

notevoli e inaccettabili ed è altamente variabile. I tre flussi AF essendo in

condizioni limite sperimentano throughput più bassi dell’EF anche se comparabili,

ma presentano una variabilità notevole. Nonostante queste osservazioni i flussi

AF rimangono comunque nei limiti prestabiliti di QoS.

Figura 5.42: Lost Data caso limite AF

In questa figura è mostrato l’andamento delle perdite dei pacchetti. Come è ben

visibile i flussi EF (quelli rossi) hanno perdite nulle tanto che il Chariot non le

grafica, il flusso BE (quello celeste) ha perdite inacettabili ed i flussi AF (quelli

della zona verde e grigia) hanno perdite mediamnte intorno al 4% cioè al limite

dei valori imposti per la classe Assured Forwarding.

__________________________________________________________________

152

Figura 5.43: One-Way-Delay caso limite AF In quest’ultima figura relativa al caso limite AF è mostrato il ritardo ad una via

massimo sperimentato dai pacchetti. Per tutte le classi di servizio i valori di one-

way-delay sono bassi rispetto a quelli dettati dalla normativa di riferimento, ma

risulta evidente la differenza tra i vari flussi: il traffico EF sperimenta un ritardo

trascurabile rispetto agli altri due, mentre BE sperimenta il ritardo in assoluto più

grande, ciò è dovuto alla sua maggiore bufferizzazione.

Figura 5.26: Jitter massimo caso limite AF

Nella figura sopra è rappresentato il jitter massimo sperimentato dai pacchetti in

rete, si può notare come i flussi EF abbiano valori molto bassi, mentre per le altre

__________________________________________________________________

153

tipologie di traffico i valori sono ben più elevati, in particolare i valori del jitter

del traffico AF sono elevati poiché ci troviamo in una situazione limite e si

trovano risultati paragonabili a quelli della tipologia BE.

Caso generico.

Dal server Chariot sono stati inviati 5 flussi Netmeeting tutti da 10 Mbit/s, ripartiti

nel seguente modo:

• 1 flusso EF

• 2 flussi BE

• 2 flussi AF.

Diversamente dal caso precedente il traffico AF non è spinto al limite e dunque

sperimenta prestazioni molto simili a quelle dell’EF. Per quanto concerne i flussi

BE si nota che rimangono molto alti i valori delle perdite di pacchetto e di one-

way-delay massimo.

Figura 5.447: Throughput Caso Generico

__________________________________________________________________

154

Figura 5. 458: Lost Data Caso Generico

Figura 5.469: One-Way Delay Caso Generico

__________________________________________________________________

155

5.3.2 Test su servizio VoIP (Voice over IP) Il servizio Voice over IP analogamente al Netmeeting è un servizio di tipo real-

time. Richiede parametri di QoS molto stringenti e, come per il caso generico

Netmeeting, dalle misure effettuate non è evidente la differenza di prestazioni tra i

flussi EF e AF. Si rimane sempre al di sotto del limite di traffico AF che la rete

può supportare.

La configurazione del traffico inviato dal Server Chariot è la seguente: 5 flussi

VoIP per ogni classe di servizio. Il motivo di così pochi flussi è dovuto alle

limitazioni del software Chariot ed alle modalità di simulazione che non

permettono l’instaurazione di un numero maggiore di chiamate.

Figura 5.30: Throughput flussi VoIP

__________________________________________________________________

156

Figura 5.47: Lost Data flussi VoIP

Figura 5.48: One-Way Delay flussi VoIP

Dai grafici ottenuti dal Chariot sviluppati su un minuto si nota come il traffico BE

sperimenti perdite molto alte mentre i grafici AF ed EF abbiano entrambi perdite

molto basse. Per quanto riguarda il one-way-delay, la differenza tra i flussi EF-AF

ed i flussi BE è notevole, per i primi due inferiore ad 1 ms, per i flussi BE

superiore a 90 ms.

Tutte le misure che precedono riguardano servizi real-time è si mostra,

dall’evidenza delle prove, come il traffico BE non sia in grado di supportare

__________________________________________________________________

157

questo tipo di servizi. La differenza tra le due classi di servizio AF ed EF è

risultata meno evidente ma va osservato che:

Il traffico di tipo AF ha ottenuto risultati sempre sotto al limite massimo

consentito dalla normativa ITU-T G1010 di riferimento.

La classe di servizio EF, per come è configurata sui router, può supportare

una grande quantità di traffico real-time senza compromettere al qualità

del servizio.

I limiti alle quantità di traffico presenti nella rete sono dovuti sia alle risorse

hardware disponibili, sia ai parametri di QoS della classe AF.

I parametri di QoS esaminati nelle misure effettuate fino ad ora sono validi

esclusivamente per servizi real-time per i quali si passa sul protocollo RTP; nelle

misure che seguiranno verranno verranno presi in considerazione servizi di tipo

non real-time che viaggiano su protocolli tipo TCP per i quali non ha senso avere

informazioni sul jitter, sulle perdite e sul ritardo. Il parametro che si considererà di

qui in seguito è il throughput medio.

5.3.3 Servizio di trasferimento dati In questa sessione di test è stato impiegato per il Chariot uno script di simulazione

di un servizio FTP. Si tratta di un trasferimento di dati su protocollo TCP.

La configurazione dei flussi è la seguente:

• 1 flusso ftp EF

• 1 flusso ftp AF

• 1 flusso ftp EF

__________________________________________________________________

158

Figura 5.493: Throughput flussi ftp

Il bit-rate dei singoli flussi non è settabile sul Chariot come costante, ma è un

parametro variabile, dunque per analizzare il grafico non bisogna ragionare sui

valori assoluti del throughput, ma per differenza sulle singole classi.

Si nota dal grafico che mediamente il throughput del traffico EF e quello del

traffico AF sono simili, mentre quello del traffico BE (zona in basso del grafico) è

di un ordine di grandezza inferiore.

I risultati leggibili nel file di report prodotto dal Chariot riportano un throughput

medio del traffico EF di 1 Mbit/s, un throughput medio del traffico AF di 0,73

Mbit/s ed uno BE di 0,1 Mbit/s.

Una successiva prova è stata effettuata con un nuovo script di tipo file-send con

la seguente configurazione:

• 1 flusso file-send EF

• 1 flusso file-send AF

• 1 flusso file-send BE

__________________________________________________________________

159

Figura 5.504: Throughput flussi “file-send” I risultati di questo test mostrano in maniera più evidente la differenza di

prestazioni che i differenti flussi sperimentano in rete. Come si nota in figura, il

flusso EF (colore verde) ha un bit-rate molto maggiore degli altri con una media

fornita dal Chariot di circa 28 Mbit/s, il flusso AF (quello rosso nella zona

centrale del grafico) ha un throughput medio di circa 14 Mbit/s ed infine il

traffico di tipo BE è il meno performante di tutti con un throughput medio di

0.037 Mbit/s e quasi impercettibile sul grafico.

5.3.4 Servizi audio-video non real time In questa serie di misure vengono utilizzati degli script che simulano servizi di

streaming audio-video non real time che utilizzano il protocollo UDP, i servizi

testati sono Quick Time e Real Player.

Il primo test effettuato su servizio Real Player è stato realizzato con la seguente

configurazione:

• 1 flusso Real Player EF da 20 Mbit/s

• 1 flusso Real Player AF da 20 Mbit/s

• 1 flusso Real Player Be da 20 Mbit/s

__________________________________________________________________

160

Anche per questo tipo di traffico il parametro fondamentale è il throughput medio.

Figura 5.515: Throughput flussi “Real Player”

Come nel caso del VoIP e del Netmeeting, non c’è molta differenza tra i flussi EF

ed AF in termini di throughput che si aggira per entrambi intorno ai 19 Mbit/s

quasi il valore del throughput nominale. Il flusso BE è fortemente penalizzato e

presenta un throughput medio di 0,4 Mbit/s.

Il secondo test è stato realizzato sull’applicazione Quick Time. Durante la misura

è stato generato un flusso dello stesso traffico per ogni classe di servizio.

__________________________________________________________________

161

Figura 5.526: Throughput flussi “Quick Time” I risultati di questa ultima misura sono molto simili alla precedente: i flussi EF ed

AF hanno lo stesso throughput che ora è appena maggiore di 20 Mbit/s mentre il

flusso BE ha una portata di 0,42 Mbit/s. Tutte le misure presentate hanno dunque

convalidato la teoria DiffServ, quindi la rete realizzata è in grado di differenziare

la gestione del traffico in funzione del servizio specificato e della sua

classificazione.

La funzione differenziazione dei servizi è stata implementata con successo nei

router Juniper M10 che hanno dimostrato un comportamento ottimo nella gestione

delle classi di servizio.

In tutte le misure effettuate è evidente infatti come le due classi più privilegiate

Expedited Forwarding e Assured Forwarding siano cautelate anche in condizioni

di rete molto carica e dunque adatte a servizi particolarmente delicati come quelli

real time. Circa la classe Best Effert invece viene fortemente penalizzata e le

prestazioni del traffico sono basse qualunque sia il servizio considerato.

__________________________________________________________________

162

Capitolo 6

PROVE SOGGETTIVE E QUALITA’ PERCEPITA DALL’UTENTE FINALE

In questo capitolo vengono descritti nel dettaglio lo svolgimento delle prove per la

qualità percepita dall’utente finale ed i risultati ottenuti in termini di valutazione

Nello studio dei risultati si tiene conto dei parametri oggettivi di rete i quali

vengono comparati con i parametri soggettivi al fine di stabilirne una

correlazione.

6.1 TEST-BED SPERIMENTALE PER LA VALUTAZIONE SOGGETTIVA DELLA QUALITA’ DEL SERVIZIO.

Il test-bed utilizzato per le prove soggettive è lo stesso di quello utilizzato per le

misure oggettive a meno di necessarie modifiche descritte nel seguito. Il test-bed

è mostrato nella figura che segue:

Figura 6.53: Test-bed sperimentale per le prove soggettive.

conv e/o

Laboratorio valutazione della QoS multimediale – Ufficio IV ISCOM

Laboratorio trasmissivo reti ottiche -ISCOM-

conv e/o

CLIENT VLC LAN

laboratorio reti ottiche dinamiche – Ufficio III ISCOM

SERVER CHARIOT

SERVER MULTIMEDIALE (VLC LAN)

1,25 GBE 1,25 GBE

1,25 GBE

ANELLO OTTICO ROMA-POMEZIA

Fibra ottica smf 1550

Fibra ottica mmf

fe fe

Link sotto test Link di collegamento fra laboratori in fibra ottica mmf

Link di collegamento in fibra ottica smf

Link di collegamento FastEthernet

HUB

GENERATORE-ANALIZZATORE DI

__________________________________________________________________

163

Per lo svolgimento di queste prove è stato necessario l’impiego di un software che

trasmettesse e ricevesse streaming audio-video, tra i vari disponibili è stato scelto

il programma VLC Lan23. VLC è stato installato su un PC del laboratorio di reti

ottiche dinamiche del piano 1S24 in modo che funzioni da server ed il PC è stato

connesso direttamente al primo router; VLC è poi stato installato in un PC del

laboratorio per la qualità del servizio multimediale, sito al sesto piano, in modo

che funzionasse da client. I due laboratorio sono connessi in fibra ottica

multimodale tramite convertitori opto-elettronici.

Per consentire il funzionamento del test-bed sono state apportate delle modifiche

alla configurazione dei router Juniper M10. Il traffico che proviene dal server

VLC Lan non viene etichettato nel DSCP e per ovviare a questo problema nel

router 1 è stata introdotta una firewall.

Il sistema di gestione JUNOS offre diversi parametri con i quali filtrare il traffico

entrante in una interfaccia: indirizzo di sorgente, di destinazione, il protocollo di

trasporto utilizzato etc. nel caso del test-bed il parametro con il quale è stato

filtrato il traffico è l’indirizzo di sorgente. Tutto il traffico proveniente da un

determinato indirizzo viene classificato come appartenente ad una specifica classe

di servizio. La firewall è stata configurata in modo che un indirizzo appartenente

agli indirizzi di tipo 192.168.6.0/24 fosse etichettato expedited forwarding, un

altro assured forwarding e tutti gli altri disponibili vengono etichettati best effort.

23 Lettore multimediale Open Source e multipiattaforma per diversi formati audio e video; è anche server di streaming con possibilità di transcoding( UDP unicast e multicast, http etc.) ed è realizzato per reti a banda larga. Il sito di riferimento da cui è possibile scaricarlo è www.videolan.org 24 1S: primo sotterraneo

__________________________________________________________________

164

family inet { filter MF { term a { from { source-address { 192.168.6.20/32; } } then forwarding-class expedited-forwarding; } term b { from { source-address { 192.168.6.22/32; } } then forwarding-class assured-forwarding; } term c { then forwarding-class best-effort; } } }

Figura 6.54:Configurazione della firewall sul router 1 I pacchetti provenienti dall’indirizzo indicato nel firewall vengono classificati in

una CoS (Class of Service) e dunque memorizzati nella coda corrispondente, ma il

campo DSCP non viene riscritto dunque la firewall anche se classifica è inutile ai

fini del test-bed poiché i router sono configurati in modo da leggere il campo

DSCP. Il problema è stato risolto introducendo nella configurazione del router 1

un altro campo: il rewrite rule. Mediante questa dichiarazione è possibile

riscrivere il campo DSCP dei pacchetti in uscita da una interfaccia con un

qualsiasi valore.

Il router 1 poiché etichetta il campo DSCP perde il suo ruolo di Core Router circa

l’approccio DiffServ e diviene un Edge Router.

Il router 2 mantiene la stessa configurazione delle prove oggettive.

__________________________________________________________________

165

6.2 PROVE SOGGETTIVE Le valutazioni soggettive della qualità del servizio sono di fondamentale

importanza la buona riuscita del sistema sotto test è basata sul cliente.

Quando si parla di qualità percepita è importante analizzare le prestazioni

sperimentate dai pacchetti nella rete, ma è ancora più importante e necessario

studiare le reazioni degli utenti in corrispondenza di queste prestazioni. L’insieme

delle misure, oggettive e soggettive, può offrire un valido supporto per stabilire

se il sistema sotto test può garantire o meno la QoS richiesta per un particolare

servizio e se può soddisfare quello che il cliente si aspetta.

Le prove oggettive svolte in questo lavoro hanno riguardato la maggior parte dei

servizi presenti oggi in rete, ma per le prove soggettive ci si limita a porre sotto

test i servizi di tipo real-time per i quali è fondamentale lo studio della qualità

percepita dall’utente.

Il servizi real-time sui quali è stata studiata la qualità sono: IP-TV, ovvero la

trasmissione di immagini televisive e DVD su rete fissa.

Per la valutazione soggettiva di un sistema che supporti questi servizi l’ITU-T non

ha ancora redatto nessuna Raccomandazione e, poiché il grosso dei test tratta di

immagini televisive, come riferimento è stata presa la normativa ITU-R 550-11,

relativa alla qualità della televisione radio trasmessa, e adattata al sistema sotto

test.

6.2.1 Scelta delle immagini televisive.

Il primo passo per svolgere le valutazioni soggettive consiste nella scelta accurata

delle immagini che verranno proposte ai valutatori. Affinché i risultati siano

significativi, come raccomandato dalla normativa 500-11, il materiale audio-video

deve essere di alta qualità (ITU-R BT 601 4:2:2) e contenere “scene critiche”25

25 Per scene critiche si intende una serie di immagini scelte in modo da portare il sistema ai limiti del corretto funzionamento percepibile dall’utente; ad esempio scene molto movimentate, veloci cambi di scene, contrasti forti possono stressare il sistema e generare dei fastidiosi effetti mosaico o addirittura rendere la visione inaccettabile.

__________________________________________________________________

166

per il sistema sotto test. Circa la qualità del segnale trasmesso dal server si è

ritenuto opportuno utilizzare immagini compresse in formato MPEG-2 codificate

a 8 Mbit/s. Tra il del materiale audio video disponibile è stato scelto: un

DVD per le prove Wi-Fi26, in particolare il film Pearl Harbor per la completezza

della casistica delle immagini contenute, e tra le immagini televisive possibili

quelli riguardanti la scelta è ricaduta sullo sport e su video musicali. Lo sport è

stato privilegiato poiché le immagini sono molto dinamiche e dunque

caratterizzate da contenuti informativi variabili con picchi molto elevati, i video

clip sono stati considerati perché oltre ad impegnare il sistema dal punto di vista

delle immagini lo testano sotto il profilo audio.

Di seguito si riporta un elenco delle sequenze scelte, quattro di sport ed un video

clip per le prove su cavo, una scena piuttosto lunga per le prove “wireless”.

Cavo LAN:

• Gara di automobilismo

• Partita di tennis

• Nuoto sincronizzato

• Ciclismo

• Musica (video musicale)

Access Point:

• DVD (sequenza dal film Pearl Harbor)

Le immagini del nuoto sincronizzato hanno una criticità medio-bassa in quanto la

presenza di una grossa porzione di piscina che fa da sfondo ai movimenti da luogo

ad un bit rate piuttosto costante e non elevatissimo, quindi meno deteriorabile dai

disturbi della rete, lo stesso può dirsi per il tennis dove lo sfondo è pressoché

costante, il campo, ma a differenza del nuoto il movimento degli atleti quando

colpiscono la pallina è rapidissimo, quindi durante il gioco il throughput subisce

dei picchi violenti e non prevedibili. Il tennis offre le immagini ideali per vedere

la reazione del sistema a burst di traffico elevati. 26 Sono state fatte anche delle misure in cui la connessione non avveniva via cavo ma tramite un access point, di queste si parlerà nel seguito del capitolo.

__________________________________________________________________

167

La gara di automobilismo è stata scelta perché in questo caso l’immagine centrale

cambia con una velocità molto minore dello sfondo, il quale varia rapidamente

con lo spostarsi delle automobili. Questo contesto stressa molto il sistema in

quanto i quadri sono in continuo mutamento e quindi è da considerarsi ad alta

criticità. In ultima analisi sono state selezionate scene tratte dal ciclismo, in

particolare da una tappa alpina del giro d’Italia. La scelta è stata fatta per tre

motivi particolari: il primo è che ci sono inquadrature dall’alto con sfondi colorati

ed è interessante considerare come viene valutato l’effetto mosaico su immagini a

bassissimo contrasto, il secondo per la variètà delle inquadrature quindi la

possibilità di studiare come varia la percezione di uno stesso degrado al variare

dello zoom dell’immagine, il terzo consiste nel fatto che parte delle immagini

sono riprese in pieno giorno con molto sole e la percezione dell’utente è molto più

sensibile al degrado offerto dalla rete. Il ciclismo per tutti questi motivi è da

considerarsi di criticità medio alta.

Per quanto concerne le misure svolte utilizzando l’access point la sequenza scelta

è molto lunga e contempla tutte le casistiche di criticità che si trovano immerse

nei filmati scelti sopra. La prova è lunga perché i tempi di ripercussione del

degrado della rete sull’utente finale sono diversi rispetto ai tempi sperimentati con

i collegamenti via cavo di rete.

Di seguito si riportano dei fotogrammi estratti dalle varie sequenze scelte.

__________________________________________________________________

168

Figura 6.55: fotogramma tratto dalla sequenza di automobilismo.

Figura 6.56: fotogramma tratto dalla sequenza tennis.

__________________________________________________________________

169

Figura 6.57: fotogramma tratto dalla sequenza nuoto sincronizzato.

Figura 6.58: fotogramma tratto dalla sequenza ciclismo.

__________________________________________________________________

170

Figura 6.59: fotogramma tratto dalla sequenza musica

Figura 6.60: fotogramma tratto dal film Pearl Harbor

__________________________________________________________________

171

6.2.2 Registrazione delle sequenze Per avere il controllo assoluto del segnale sorgente la Raccomandazione 550-11

consiglia la registrazione delle sequenze su memorie digitali.

La prima fase ha previsto la registrazione direttamente dal segnale satellitare delle

sequenze di musica, ciclismo, nuoto sincronizzato, automobilismo e tennis in

formato MPEG-2, e l’estrazione della sequenza Pearl Harbor da supporto DVD

ancora codificato in MPEG-2 con rate fisso di 8 Mbit/s. I sei file audio-video

MPEG ottenuti sono stati divisi in due file complessivi: il primo della durata di tre

minuti contenente la sequenza tratta dal film, il secondo della durata di due minuti

e mezzo poiché somma delle cinque sequenze tratte da satellite ognuna della

durata di 30 secondi.

Una volta preparato il materiale di test è stato configurato il generatore di traffico

per la saturazione della rete.

Il traffico sotto test di queste prove, 8 Mbit/s per ogni classe di servizio, è minore

di quello utilizzato nelle misure oggettive e dunque si è reso necessario

aumentare il traffico di saturazione per stressare la rete; in particolare è stato

aumentato il traffico EF ed AF generato dall’MD1230A in modo che il traffico

complessivo presente nella rete potesse essere lo stesso delle prove oggettive.

Fissate le condizioni di saturazione della rete il file MPEG presente nel CD di

back up è stato trasmesso, su protocollo RTP, tramite il programma VLC LAN dal

laboratorio delle reti ottiche dinamiche del piano 1S al laboratorio per la

valutazione della qualità del servizio multimediale del sesto piano attraverso

l’anello ottico Roma-Pomezia.

Nel laboratorio della QoS la parte video dello streaming viene registrata frame per

frame in formato yuv8 non compresso, YUV 4:4:4, su hard disk ad alta capacità,

mentre la parte audio viene acquisita in formato wave su un secondo PC.

Il segnale video viene inizialmente codificato in formato RGB; tramite un

semplice algoritmo si passa dalle componenti Red Green Blue alle componenti

Y-luminanza e U,V-crominanza, attraverso le quali è possibile effettuare la

compressione video. Il formato YUV 4.4:4 non introduce perdite di informazione

rispetto al formato RGB in quanto per ogni pixel vengono considerate le

__________________________________________________________________

172

componenti Y-U-V, passando ad esempio ad altri formati come YUV 4:2:2

vengono perse informazioni sulla crominanza alla quale l’occhio umano risulta

essere poco sensibile.

Le operazioni di registrazione nel laboratorio della QoS multimediale vengono

svolte una volta per ogni classe di servizio ad eccezione della classe Assured

Forwarding per la quale vengono svolte due registrazioni corrispondenti a due

diversi valori del traffico di saturazione. I file audio e video ottenuti sono

rappresentativi del comportamento della rete riguardo ad ogni classe di servizio,

dai file vengono poi separate di nuovo le singole sequenze da 30 secondi per la

preparazione delle prove soggettive.

Poiché ogni sequenza è stata registrata frame per frame in formato abekas27 per

renderle tutte visibili all’utente portandole in formato avi 28 sono necessarie delle

conversioni intermedie operate da riga di comando. Nel caso delle prove

soggettive si lavora in DOS poiché le macchine a disposizione hanno sistema

operativo Windows XP.

Di seguito vengono riportati i passaggi per la creazione dei file avi.:

1. Si crea un file unico yuv per ogni sequenza concatenando i frame

2. I file ottenuti dal punto 1 in formato yuv 4:4:4 vengono convertiti in

formato 4:2:2

3. Dal formato 4:2:2 si passa al 4:2:0 utilizzato per le codifiche MPEG-1,

MPEG-2, MPEG-4 ed AVI.

4. Dal formato 4:2:0 si crea un file avi per ogni sequenza.

5. Tramite il software multimediale ULEAD si sincronizzano i file video avi

con i rispettivi file audio wave e si memorizza tutto in un unico file avi.

Dopo queste operazioni, per ogni classe di servizio, si hanno a disposizione 5

sequenze da 30 secondi e 1 da 3 minuti per un totale di 22 minuti di prove

valutabili. Prima di procedere alle prove soggettive è stata operata una nuova

cernita delle sequenze da sottoporre ai valutatori, infatti tutte le sequenze che

passano nella rete etichettate Best Effort dalla firewall risultano indecifrabili ed è 27 Formato yuv8. 28 Formato non compresso.

__________________________________________________________________

173

dunque di poco interesse procedere ad una valutazione. La scelta operata è stata

quella di eliminare tutte le sequenze della classe di servizio BE ottenendo come

vantaggio collaterale quello di tenere i valutatori impegnati per un tempo minore.

Per il ricevuto dal client VLC tramite l’access point oltre al traffico BE è stato

sottratto alla valutazione anche il traffico Assured Forwarding di tipo medium

quality poiché è risultato altrettanto indecifrabile e dunque di poco interesse per la

valutazione.

Figura 6.61: Laboratorio di registrazione sequenze.

__________________________________________________________________

174

6.2.3 Scelta del metodo di valutazione e preparazione della camera afonica

I metodi descritti nella Raccomandazione BT 500-11 adatti a questo tipo di prove

sono:

• SDSCE ( Double Stimulus for Continuos Evaluation)

• SSCQE ( Single Stimulus for Continuos Quality Evaluation)

Nel metodo SDSCE agli osservatori vengono presentati due stimoli

contemporaneamente, uno di riferimento ad alta qualità ed un altro degradato dal

sistema sotto test, ad esempio per compressione del filmato, e viene valutata la

differenza di qualità fra i due stimoli. Nel metodo SSCQE agli osservatori viene

proposto un solo stimolo alla volta cioè sequenze di qualità variabile che sono

chiamati a valutare senza aver alcun riferimento.

Nel caso di queste prove il compito degli osservatori è stato quello di valutare la

presenza o meno di disturbi, blocco immagini e pacchettizzazione non la qualità

assoluta delle immagini; per questi test è stato ritenuto più idoneo il metodo

SSCQE.

Per questo metodo è prevista la partecipazione di almeno 15 valutatori, non

esperti di queste attività, di età compresa tra i 18 ed i 35 anni.

Effettuata la scelta del metodo si è proceduto all’allestimento della camera silente.

Figura 6.62: Camera afonica

__________________________________________________________________

175

Per le valutazioni SSCQE il laboratorio per la valutazione della QoS multimediale

ha a disposizione il sistema software/hardware IQ++. La parte hardware è

composta da un dispositivo a cui vengono collegati, tramite cavo di rete, i

potenziometri , sliders, dotati di una scala a 5 livelli; il segnale proveniente dai

potenziometri viene campionato ogni 0,5 secondi ed alla posizione del cursore

viene associato un valore tra 0 e 255 rispettivamente cattiva qualità e qualità

eccellente. Durante i primi 5 secondi di ogni sequenza il software IQ++ non

registra alcun voto, poiché si suppone che questo lasso di tempo costituisca una

fase di training per i valutatori.

Seguendo la normativa BT 500-11 sono state disposte quattro postazioni

all’interno della camera silente in modo che la loro distanza fosse pari a 4 volte

l’altezza dello schermo e l’angolo di visuale maggiore di 30° rispetto al centro

dello schermo stesso.

6.3 LA SESSIONE DI TEST

6.3.1 Preparazione delle sequenze Affinché venga rispettata la Raccomandazione 500-11 è stato preparato uno script

in formato .txt in cui le sequenze sono ordinate in modo casuale. Nello

svolgimento delle prove sono stati impiegati due PC diversi, uno per la gestione

del sistema e l’altro per la gestione del proiettore nella camera afonica. Il software

IQ++ memorizza le votazioni secondo un ordine fisso delle sequenze presentate e

dunque lo stesso ordine deve essere rispettato durante la proiezione affinché i

risultati siano validi.

Gli osservatori prima dall’inizio delle prove hanno compilato una liberatoria per

la tutela della privacy e si sono sottoposti ad un esame visivo di idoneità.

__________________________________________________________________

176

Figura 6.63: Scheda sottoposta ai valutatori Prima del test la Raccomandazione BT 500-11 consiglia un addestramento

preliminare dei valutatori. In questa fase un esperto del laboratorio per la

valutazione della QoS multimediale spiega agli osservatori seduti nella camera

silente cosa vedranno durante il test, cosa saranno chiamati a valutare ed in che

modo dovranno usare il cursore messo loro a disposizione per le valutazioni.

__________________________________________________________________

177

Figura 6.64: l’esperto spiga come usare il cursore

Figura 6.65: Fase di training dei valutatori.

__________________________________________________________________

178

6.3.2 Fase di elaborazione dei dati. Per ognuna delle due sessioni (prove via cavo e prove Wi-Fi) e per ogni valutatore

il software IQ++ ha creato un file contenente i voti relativi al test, cioè il software

ha raccolto i voti su tutti i 7,5 minuti delle prove via cavo della prima sessione e

sui 6 minuti della prova Wi-Fi.

Il sistema come descritto al paragrafo precedente registra la posizione del cursore

ogni 0,5 secondi creando un vettore dei voti molto esteso, per questo motivo, per

l’elaborazione dei risultati è stato impiegato il software MATLAB.

La prima sessione di 7,5 minuti comprende le 15 sequenze totali da trenta secondi

ognuna da valutare; in particolare ogni sequenza originale è stata trasmessa tre

volte, una per ogni classe di servizio, ed è per questo che dalle cinque sequenze

originali alla fine se ne estraggono 15. Lo stesso procedimento è applicato per le

prove Wi-Fi, sessione 2,a partire dalla sequenza originale di 3 minuti se ne sono

ottenute tre per un totale di nove minuti, come già osservato alla fine i valutatori

sono stati chiamati a valutare solo sei minuti di filmato su nove corrispondenti a

due sole classi di servizio.

Le 15 sequenze via cavo da valutare vengono mescolate in ordine casuale in modo

che non si ripetano di seguito le stesse sequenze seppure appartenenti a classi di

servizio diverse.

Lo stesso è stato fatto per il Wi-Fi, anche se in questo caso non è stato necessario

generare un ordinamento casuale delle sequenze poiché quelle sottoposte a

valutazione erano soltanto due.

Di seguito si riportano dei fotogrammi di stesse sequenze tratte dalle tre differenti

classi di servizio sotto test con lo scopo di rendere visibile il deterioramento che

sperimentano le stesse sequenze quando trattate con classi di servizio differenti.

.

__________________________________________________________________

179

Figura 6.66: Fotogrammi presi dalle sequenza AUTOMOBILISMO oggetto di valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.

__________________________________________________________________

180

Figura 6.67: Fotogrammi presi dalle sequenza TENNIS oggetto di valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.

__________________________________________________________________

181

Figura 6.68: Fotogrammi presi dalle sequenza NUOTO SINCRONIZZATO oggetto di valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.

__________________________________________________________________

182

Figura 6.69: Fotogrammi presi dalle sequenza CICLISMO oggetto di valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.

__________________________________________________________________

183

Figura 6.70: Fotogrammi presi dalle sequenza tratta dal film Pearl Harbor oggetto di valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda.

__________________________________________________________________

184

Per procedere allo studio dei parametri di rete in corrispondenza degli andamenti

dei voti dei valutatori si è utilizzato una “sniffer”29 di rete, in particolare è stato

fatto uso del programma ETHEREAL, lanciandolo sul PC sorgente e su quello

destinazione e salvando i dati per poi studiarli in un secondo momento. Per

“allineare” i pacchetti si è proceduto in questa maniera: in primo luogo tramite il

comando net time di DOS si è provveduto a sincronizzare gli orologi dei due PC,

in modo tale che, tramite una funzione di ETHEREAL che permette di marcare i

pacchetti al tempo corrente si avesse la medesima scala temporale di riferimento;

in secondo luogo per riconoscere che sia in trasmissione sia in ricezione si

trattasse dello stesso pacchetto si è passati all’analisi del campo del pacchetti IP

Identification registrato dal programma nell’area INTERNET PROTOCOL.

Tramite ACCESS sono stati estrapolati tutti questi dati dal file di ETHEREAL

esportato in formato testo e messi per colonne; a questo punto il ritardo è stato

ottenuto per differenza dei tempi dei relativi pacchetti, il jitter è stato direttamente

fornito,così come il throughput.

Di seguito si riportano per via grafica i dati ottenuti dallo studio delle singole

sequenze per ogni singola classe di servizio.

I grafici vengono riportati in questa maniera: per ogni sequenza si riportano gli

andamenti dei valutatori, il throughtput ed il jitter per tutte e tre le classi di

servizio. Le sequenze hanno durata 30 secondi, ma il programma di elaborazione

delle valutazione non prende in considerazione l’intera sequenza temporale, ma

scarta i primi cinque secondi e gli ultimi due per motivi di training.

Per questa ragione i grafici che seguono relativamente all’andamento nel tempo

delle valutazioni hanno scala delle ascisse che va da 5 a 28 mentre quelli del

throughput e del jitter rappresentano anche loro un intervallo in ascisse di 23

secondi ma conservano il tempo originale della sequenza all’interno del file unico

(“provacavo “) dal quale sono state registrate. In ordinate i grafici delle

valutazioni hanno valori da 0 a 255. Nei grafici comparati verranno poi

normalizzati da 0 a 100.

29 Sniffer: dispositivo hardware o programma software in grado di catturare ed immagazzinare tutto il traffico indirizzato alla propria scheda di rete. Questa procedura detta sniffing può essere adoperata anche in modo promiscuo sulla LAN, in questo modo si memorizza tutto il traffico della sottorete che la propria scheda può ascoltare e che non è necessariamente indirizzato al proprio MAC.

__________________________________________________________________

185

6.4 RISULTATI OTTENUTI Per una analisi sistematica del gran numero di grafici ottenuti dallo svolgimento

delle prove di valutazione della qualità percepita si procede come segue:

prima si fa uno studio globale delle sequenze valutate cercando delle correlazioni

con i parametri percepiti, la stessa cosa si fa con le sequenze Wi-Fi.

Fatta una analisi globale si scende nel dettaglio di ogni singola sequenza

approfondendone lo studio.

6.4.1 Analisi globale delle sequenze via cavo.

Lo studio della qualità percepita mediamente non ha disilluso quanto ci aspettava

dopo lo svolgimento delle prove soggettive. Quello che appare evidente infatti è

che le tra classi di servizio vengano valutate in maniera differente e l’andamento

dei giudizi rispecchia la differenza della priorità. Nella figura che segue si

riportano gli andamenti globali dei giudizi forniti dai valutatori sulle cinque

sequenze “via cavo”.

ANDAMENTO COMPLESSIVO DIVISO PER SEQUENZE

0

10

20

30

40

50

60

70

80

90

100

0,0 20,0 40,0 60,0 80,0 100,0 120,0 140,0

TEMPO [s]

VOTA

ZIO

NI

ExpeditedAssured HQAssured MQ

Figura 6.71: Andamento delle valtazioni si tutte le sequenze. Nella figura appaiono delle aree separate, queste rappresentano le cinque sequenze

diverse che in seguito verranno studiate nel dettaglio. La separazione delle aree

__________________________________________________________________

186

avviene ad opera del software di acquisizione dei voti che sulle sequenze della

durata di 30 secondi scarta i primi cinque e gli ultimi due sfruttando come dati di

training i campioni contenuti in quasti secondi. Ciò che si deduce dal grafico è che

la classe di servizio Assured Forwarding High Quality si comporta mediamente

molto bene, con una media di 90/100 si tutti i tipi di sequenze disponibili. La

classe Expedited Forwarding risulta ottima, l’andamento della valutazione è

mediamente 100/100, in pratica non degrada le immagini originali. La classe

Assured Forwarding Medium Quality rappresenta l’Assured Forwarding in

condizione di rete molto congestionata e sperimenta da parte dei valutatori una

votazione media di 65/100.

DISTRIBUZIONE DEI VOTI

0,0000

0,1000

0,2000

0,3000

0,4000

0,5000

0,6000

0,7000

0,8000

0,9000

1,0000

0 10 20 30 40 50 60 70 80 90 100

VOTAZIONI


Figura 6.72: Distribuzione normalizzata dell’andamento delle votazioni.

Passando all’analisi dei parametri oggettivi che hanno caratterizzato le sequenze

giudicate dai valutatori in primo luogo si deve far riferimento al throughput.

Di seguito viene riportato un grafico che mostra l’andamento del throughput delle

tre differenti classi di servizio per tutte le sequenze.

__________________________________________________________________

187

CONFRONTO DEI THROUGHPUT

7000000

7500000

8000000

8500000

9000000

9500000

10000000

0 20 40 60 80 100 120 140

TEMPI [s]

Mbp

s

ExpeditedAss_hq_OFF_eAss_OFF_mq_e

Figura 6.73: Grafico dell’ andamento dei Throughput nelle tre diverse classi di servizio EF, AF HQ, AF MQ Come ci si aspettava i valori medi della classe EF e della classe AF HQ sono

molto simili e si discostano di poco, ciò e dovuto al fatto che il traffico AF HQ è

stato inviato su rete mediamente congestionata dunque in una situazione da

considerarsi non al limite e per questo il throughput non deteriora; per quanto

concerne l’AF MQ invece è questi stato inviato su una rete molto congestionata

ed è evidente dal grafico come il througput sia più basso dei primi due

mediamente di 1 Mbit/s.

DISTRIBUZIONE DEL THROUGHPUT

0

10

20

30

40

50

60

70

80

90

100

0 2000000 4000000 6000000 8000000 10000000 12000000


Figura 6.74: Distruinuzione normalizzata del throughput nelle tre diverse classi di servizio EF,

AF HQ ed AF MQ.

__________________________________________________________________

188

Si può dedurre anche per ispezione visiva del grafico che le perdite della classe di

servizio Assured Forwardin Medium Quality superano di gran lunga l’1 %

imposto dalla normativa ITU-T G 1010 questa violazione è stata accettata proprio

per investigare come degradasse la qualità percepita e capire un po’ meglio se poi

è proprio necessario avere dei parametri di rete ed end-user così stringenti o se è

lecito rilassare alcuni vincoli.

Altro parametro preso in considerazione è stato il jitter, ma dallo studio di questo

non si è giunti a considerazioni diverse d quelle fatte per il throughput; la cosa da

osservare è che è bassissimo per tutte e tre le classi di sevizio anche se differente.

CONFRONTO JITTER

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0,005

0 20 40 60 80 100 120 140

TEMPO [s]

SEC

ON

DI


Figura 6.75: Confronto del jitter per tutte le sequenze visionate per le classi EF, AF HQ ed AF MQ.

__________________________________________________________________

189

DISTRIBUZIONE JITTER NORMALIZZATA

0

10

20

30

40

50

60

70

80

90

100

0 0,002 0,004 0,006 0,008 0,01 0,012 0,014 0,016 0,018 0,02


Figura 6.76: Distribuzione del Jitter per le tre classi di servizio, le classi Ef ed AF HQ sono praticamente sovrapposte.

Di seguito si è proceduto ad uno studio di relazione fra i voti forniti dati valutatori

ed i parametri oggettivi di cui sopra cioè throughput e jitter. Al termine si è

ritenuto opportuno creare due grafici a dispersione che mettessero in relazione: 1)

il trhoughput e l’andamento dei voti,2) il jitter e l’andamento dei voti in modo da

delimitare delle aree entro le quali confinare la qualità percepita.

GRAFICO A DISPERSIONE DEL THROUGHPUT

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

7 7,5 8 8,5 9 9,5 10Milioni

THROUGHPUT

VOTA

ZIO

NE

NO

RM

ALI

ZZA

TA ExpeditedAssured HQAssured MQ

Figura 6.77: Grafico che evidenza le aree occupate dalle tre classi di servizio in relazione con il throughput e l’andamento dei voti.

__________________________________________________________________

190

GRAFICO A DISPERSIONE DEL JITTER

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

100,0

0,001 0,0011 0,0012 0,0013 0,0014 0,0015 0,0016 0,0017 0,0018 0,0019 0,002

MILLISECONDI

VOTA

ZIO

NE

NO

RM

ALI

ZZA

TA


Figura 6.78: Grafico che evidenza le aree occupate dalle tre classi di servizio in relazione con il jitter e l’andamento dei voti. Ciò che emerge da questo studio comparato dei valori forniti dai valutatori e dai

parametri di rete sono due fatti fondamentali:

• il primo è che il test-bed si comporta secondo le aspettative e cioè la tre

classi implementate tramite l’approccio DiffServ raccolgono dei giudizi

proporzionali alla loro importanza.

• Il secondo è che i valutatori hanno ritenuto buono anche il traffico AF HQ

che ha un costo di gestione molto minore dell’EF e che per rete

mediamente congestiona, come nel nostro caso e del resto come nel caso

della rete nazionale, ha un decadimento delle prestazioni meno che lineare

col costo di implementazione.

6.5 ANALISI DELLE SEQUENZE “VIA CAVO” In questo paragrafo si procede ad una accurata analisi di ogni singola sequenza per

capire come le varie tipologie di immagine reagiscano al degrado della rete e

soprattutto come vengano percepite dall’utente finale.

__________________________________________________________________

191

6.5.1 Automobilismo

La prima sequenza ad essere analizzata è l’automobilismo; questa tipologia di

immagini è stata giudicata come molto critica per la rete in quanto è costituita da

soggetti relativamente fermi all’interno dell’inquadratura (le automobili) e da

sfondi continuamente in movimento che richiedono molti bit di informazione.

Ciò che è vero per la rete, tipologia di immagine critica, non lo è per il valutatore.

Chi giudica infatti focalizza la propria attenzione sul soggetto e non sullo sfondo,

percependo poco eventuali effetti mosaico che si presentano al contorno

dell’inquadratura.

Nelle figura che segue è riportato il grafico dell’andamento delle valutazioni della

sequenza automobilismo per le tre tipologie di qualità del servizio.

Figura 6.79: Andamento delle valutazioni della sequenza AUTOMOBILISMO la linea rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ.

__________________________________________________________________

192

Dall’andamento delle valutazioni è abbastanza chiaro che le tre classi di servizio

proposto siano state percepite in modo diverso; l’EF va sempre bene tranne due

piccoli picchi imputabili a dei cambi di scena animati che molto probabilmente i

valutatori avevano cominciato a percepire come errore.

La classe AF HQ varia tra l’80% ed il 100%, le votazioni basse corrispondono

alle inquadrature dall’alto dove le macchine perdevano la loro centralità

all’interno dell’inquadratura ed il contorno risultava più visibile.

L’ AF MQ ricalca grossomodo lo stesso andamento dell’AF HQ solo che i difetti

delle immagini sono stati percepiti in maniera maggiore.

La differenza dell’andamento delle valutazioni tra EF ed AF HQ è dovuta alla

seppure minima variazione di throughput; infatti la classe AF HQ sperimenta

delle perdite intorno al punto percentuale dovute al tipo di “drop profile “

configurato sui router. In pratica per la classe AF si ammette che dopo il 50% di

riempimento della coda corrispondente si comincino a scartare i pacchetti; se tra

questi c’è un i-frame del codec MPEG-2, questi si ripercuote in maniera pesante

sul filmato, in particolare il degrado può ripercuotersi fino all’ i-frame successivo.

__________________________________________________________________

193


7000000

7500000

8000000

8500000

9000000

9500000

10000000

35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

TEMPI [s]

Mbp

s


Figura 6.80: Confronto dei throughput per la sequenza AUTOMOBILISMO Circa il Jitter non ci sono grosse considerazioni da fare, è molto basso e costante senza grosse fluttazioni.

CONFRONTO JITTER

0,001

0,0011

0,0012

0,0013

0,0014

0,0015

0,0016

0,0017

0,0018

0,0019

0,002

35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

TEMPO [s]

SEC

ON

DI


Figura 6.81: Confronto dei Jitter per la sequenza AUTOMOBILISMO

__________________________________________________________________

194

6.5.2 Tennis La seconda sequenza considerata è stata quella del tennis; la scelta è motivata per

caratteristiche di questo sport.

Nel tennis infatti lo sfondo è fisso e gli scambi sono molto veloci, questi danno

luogo a dei picchi di traffico molto elevati ed imprevedibili che posso degradare

con facilità nella rete.

Figura 6.82: Andamento delle valutazioni della sequenza TENNIS la linea rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ. Come è possibile osservare in figura la qualità percepita del traffico AF MQ

assume un andamento mediamente del 60 % e con forti oscillazioni. In pratica

quello che viene fuori dall’osservazione di questa sequenza e che ciò che non è

mediamente critico per la rete lo è per qualità percepita.

Il traffico AF MQ che rappresenta il traffico AF in condizioni di rete molto

congestionata, ci si aspetta vada meglio rispetto alla sequenza automobilismo,

quello che riscontra invece è che le perdite di pacchetto che si iscontrano durante

__________________________________________________________________

195

li scambi veloci del gioco si ripercuotono su tutta la sequenza degradando la

qualità percepita.

Circa le altre due classi dove le perdite di pacchetto sono molto imitate si

riscontrano valutazioni eccellenti (EF) e molto buone (AF HQ). Quello che

emerge dallo studio di questa sequenza è che una stesso valore di perdita dei

pacchetti ha una rilevanza maggiore rispetto ad altri tipi di immagini come ad

esempio la sequenza automobilismo.

Di seguito si riportano i grafici dei valori di throughput e jitter per le tre classi di

servizio considerate.


7000000

7500000

8000000

8500000

9000000

9500000

10000000

95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118

TEMPI [s]

Mbp

s


Figura 6.83: Confronto dei throughput per la sequenza TENNIS

CONFRONTO JITTER

0,001

0,0011

0,0012

0,0013

0,0014

0,0015

0,0016

0,0017

0,0018

0,0019

0,002

95 100 105 110 115

TEMPO [s]

SEC

ON

DI


Figura 6.84: Confronto dei Jitter per la sequenza TENNIS

__________________________________________________________________

196

Il throughput si presenta molto variabile per le tre classi e ciò è dovuto ai picchi di

traffico dovuti ai repentini cambi d’immagine, lo stesso vale per il jitter che in

alcuni casi risulta minore per la classe AF MQ rispetto alla classe HQ. La

mutevolezza dei valori del jitter è indice della mutevolezza dei valori del ritardo,

questo è dovuto ai buffer delle code del router ottimizzate per traffici

genericamente costanti. I picchi infatti saturano il buffer della cosa corrispondente

generando nel migliore di casi pacchetti ritardati e nel peggiore dei casi perdite.

6.5.3 Nuoto Sincronizzato La terza sequenza analizzata è stato il nuoto sincronizzato, il nuoto è stato scelto

perché lo sfondo è costante (la piscina) ed i movimenti delle atlete non

particolarmente veloci; la sequenza è da considerarsi non critica ne per la rete ne

per i giudizi che danno i valutatori.

Figura 6.85: Andamento delle valutazioni della sequenza NUOTO SINCRONIZZATO la linea

rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ.

__________________________________________________________________

197

La parte interessante di questa immagine è la reazione che hanno i valutatori alle

increspature delle onde data la buona luminosità delle immagini, infatti in queste

condizioni anche piccoli errori vengono certamente percepiti.

Il giudizio dato dai vantatori è mediamente superiore a quello che hanno fornito

sulle sequenze già descritte; la classe EF ha un comportamento eccellente, quello

della classe AF HQ ottimo e quello della classe AF MQ molto buono.

Quello della sequenza nuoto è un tipico caso in cui al gestore converrebbe

stipulare un contratto AF col cliente per il servizio IP-TV.


7000000

7500000

8000000

8500000

9000000

9500000

10000000

65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

TEMPI [s]

Mbp

s


Figura 6.86: Confronto dei throughput per la sequenza NUOTO SINCRONIZZATO

In queste condizioni di immagini i throughput sono mediamente più alti e dunque

le perdite basse; le code non saturano mai i ritardi sono costanti e di conseguenza

lo sono anche i Jitter per le tre classi di servizio.

__________________________________________________________________

198

CONFRONTO JITTER

0,001

0,0011

0,0012

0,0013

0,0014

0,0015

0,0016

0,0017

0,0018

0,0019

0,002

65 70 75 80 85

TEMPO [s]

SEC

ON

DI


Figura 6.87: Confronto dei Jitter per la sequenza NUOTO SINCRONIZZATO

6.5.4 Ciclismo La sequenza sul ciclismo non è stata scelta per caratteristiche particolare ma per le

varietà delle immagini presenti nel particolare filmato. Le immagini infatti

contemplano tutte le casistiche di interesse; ci sono riprese dall’alto dei corridori

su uno sfondo boschivo dove diventa poco percepibile da parte del valutatore

l’effetto mosaico ed immagini molto luminose dove l’occhio è più sensibile ad

eventuali errori.

__________________________________________________________________

199

Figura 6.88: Andamento delle valutazioni della sequenza CICLISMO la linea rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ.

L’ andamento delle tre tipologie di traffico è: eccellente per EF, molto buono per

AF HQ e discreto per AF MQ. Ciò che si osserva per la classe AF MQ da uno

studio comparato col throughput è che stessi valori di questo parametro

sperimentano giudizi differenti; buoni quando lo sfondo è colorato e l’iimagine è

presa dall’alto, meno buoni quando ci sono primi piani sui corridori e la

luminosità è alta. Con questa particolare sequenza si può osservare che la qualità

percepita dipende dal tipo di immagine a parità di condizioni di rete.

__________________________________________________________________

200


7000000

7500000

8000000

8500000

9000000

9500000

10000000

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

TEMPI [s]

Mbp

s


Figura 6.89: Confronto dei throughput per la sequenza CICLISMO Per quanto concerne i valori del one way delay e lecito dire che rimango costanti

per tutta la durata della sequenza per tutte le classi di servizio. Il jitter di

conseguenza non varia.

CONFRONTO JITTER

0,001

0,0011

0,0012

0,0013

0,0014

0,0015

0,0016

0,0017

0,0018

0,0019

0,002

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

TEMPO [s]

SEC

ON

DI


Figura 6.90: Confronto dei Jitter per la sequenza CICLISMO

__________________________________________________________________

201

6.5.5 Musica La sequenza tratta da un video clip è stata scelta con l’intento di studiare la

degradazione dell’audio, e come questo possa influire circa la qualità percepita.

Quello che si osserva è la una buona componente audio favorisce la qualità

percepita; uno stesso filmato che si sente bene ma si vede male mediamente è

giudicato meglio di un filmato che si vede bene ma si sene male. In questa

sequenza infatti i valutatori sono stati maggiormente attratti da quello che

sentivano piuttosto che da ciò che ascoltavano.

Figura 6.91: Andamento delle valutazioni della sequenza MUSICA la linea rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ. Comparando la valutazione con le immagini giudicate si è osserva che il giudizio

sale quando l’audio va bene anche in presenza di pesanti disturbi, ed il giudizio

cade pesantemente quando il sonoro degrada.

__________________________________________________________________

202


7000000

7500000

8000000

8500000

9000000

9500000

10000000

125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

TEMPI [s]

Mbp

s


Figura 6.92: Confronto dei throughput per la sequenza MUSICA

Il throughput grossomodo ricalca quello della sequenza ciclismo, ciò nonostante i

giudizi osservati risultano mediamente più bassi proprio questa particolare

attenzione posta dai valutatori su quello che ascoltavano. In pratica è un po’ come

se avessero livellato in alta le soglie di giudizio. Lo stesso avviene per il jitter di

cui si riporta il grafico di seguito.

CONFRONTO JITTER

0,001

0,0011

0,0012

0,0013

0,0014

0,0015

0,0016

0,0017

0,0018

0,0019

0,002

125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

TEMPO [s]

SEC

ON

DI


Figura 6.93: Confronto dei Jitter per la sequenza MUSICA

__________________________________________________________________

203

6.6 ANALISI DELLE SEQUENZE Wi-Fi

Figura 6.94: Test-be sperimentale per le prove Wi-Fi Le prove fatte su Wi-Fi sono state effettuate su una sola sequenza della durata di

tre minuto proposta ai valutatori per sole due classi di servizio: Exedited

forwarding ed Assured Forwarding High Quality. La scelta di proporre solo due

delle classi di servizio rispetto alle tre proposte nella prova via cavo consta nel

fatto che la classe AF con rete molto congestionata (AF MQ) risultava

completamente degradata e dunque di poco interesse ai fini della valutazione.

La sequenza è stata scelta lunga per vedere come eventuali errori si propagassero

nel tempo all’interno della sequenza.

Evidentemente il supporto Wi-Fi non supporta la QoS e dunque i valori dei

throughput che giungevano alla macchina client erano praticamente identici per le

due classi.

__________________________________________________________________

204

Wi-Fi CONFRONTO THROUGHPUT

0

1000000

2000000

3000000

4000000

5000000

6000000

7000000

8000000

9000000

10000000

0 20 40 60 80 100 120 140 160 180

TEMPO [s]

Mbp

sEXP_wifi_eAss_Hq_wifi_e

Figura 6.95: Confronto tra i valori dei throughput della sequenza Wi-Fi per la classe di servizio EF linea rossa, ed AF HQ linea blu.

La sovrapponibilità dei valori dei throughput è ancora più evidente nel grafico

della distribuzione di seguito.

DISTRIBUZIONE DEL THROUGHPUT

0

10

20

30

40

50

60

70

80

90

100

0 2000000 4000000 6000000 8000000 10000000 12000000

EXP_wifi_eAss_Hq_wifi_e

Figura 6.96: Distribuzione del throughput delle due sequenze Wi-Fi, EF linea rossa ed AF HQ linea blu

__________________________________________________________________

205

La sovrapponibilità del throughput è indice che le due C.o.S vengano trattate alla

stessa maniera dunque che non ci siano garanzie di Q.o.S. I jitter delle due classi

di servizio non sono molto alti ma mediamente sovrapponibili.

Wi-Fi CONFRONTO DEI JITTER

0

0,001

0,002

0,003

0,004

0,005

0,006

0,007

0,008

0,009

0,01

0 20 40 60 80 100 120 140 160 180

TEMPO [s]

SEC

ON

DI


Figura 6.97: Confronto tra la classe EF line rossa, e la classe AF HQ linea blu

DISTRIBUZIONE NORMALIZZATA DEL JITTER PER Wi-Fi

0

10

20

30

40

50

60

70

80

90

100

0 0,002 0,004 0,006 0,008 0,01 0,012 0,014 0,016 0,018 0,02


Figura 6.98: Distribuzione del jitter per le classi EF linea rossa ed AF HQ linea blu

__________________________________________________________________

206

I valori di throughput e di Jitter sono in pratica gli stessi, nonostante questo i

valori dei giudizi espressi dai valutatori sono differenti.

Figura 6.99: Andamento delle valutazioni per la sequenza Wi-Fi per le classi EF linea rossa ed AF linea blu. La notevole differenza della qualità percepita dipende dalla variazione sui ritardi

che i due flussi sperimentano nella rete; nel flusso EF i ritardi sono contenuti entro

I cinque millisecondi, mentre per il flusso AF HQ i ritardi si attestano mediamente

sui venti millisecondi. Nonostante il valore medio del ritardo AF HQ sia al disotto

di quanto specificato e dalla normativa ITU-T G1010 e dalla normativa Y1541 per

il supporto Wi-Fi questi valori si dimostrano insufficienti per una discreta qualità

percepita che nei fatti si rivela essere Bassa con valori medi di 40/100.

In conclusione quella wireless è una tecnologia ancora non matura per il supporto

efficiente di servizi di tipo real-time.

__________________________________________________________________

207

Capitolo 7

MISURE OGETTIVE DEL TEMPO DI RIPRISTINO

7.1 INTRODUZIONE In questo capitolo verranno presentati i risultati più significativi ottenuti dalle

misure riguardanti il tempo di ripristino del servizio ottenuto utilizzando il sistema

di protezione proposto in questo lavoro.

In particolare verranno mostrati i seguenti risultati:

♦ Tempo di interruzione fisica del collegamento

♦ Tempo di detection del guasto da parte dei router Juniper M10

♦ Tempo di interruzione relativo a servizi real time simulati

♦ Tempo di interruzione relativo a servizi non-real time

Infine verranno indicati i tempi che si otterrebbero se il ripristino del servizio

fosse compiuto esclusivamente dall’algoritmo di routing OSPF senza beneficiare

dell’intervento del sistema di protezione.

7.2 TEMPO DI INTERRUZIONE DEL COLLEGAMENTO Tra tutti i risultati ottenuti dall’analisi delle prestazioni del sistema questo è

sicuramente il più significativo. E’ infatti di fondamentale importanza capire per

quanto tempo il collegamento fisico tra i due apparati terminali risulti fuori

servizio in seguito ad un guasto improvviso. Questo tempo rappresenta il periodo

nel quale le interfacce ottiche dei router relative al link sotto test presentino uno

stato di down. Per ottenere la misura esatta di questo tempo è stato utilizzato un

__________________________________________________________________

208

oscilloscopio a campionamento continuo, la cui descrizione è riportata nel

capitolo precedente, e di uno splitter di potenza 90:10.

Tramite lo splitter di potenza è stato possibile spillare il 10% della potenza ottica

presente nelle immediate vicinanze di una delle interfacce dei due router

terminali. Tale potenza è stata inviata verso l’oscilloscopio mediante un

convertitore opto-elettrico affinché il segnale fosse conforme alle caratteristiche

dello strumento di misura utilizzato. In questo modo è stato possibile monitorare

costantemente l’andamento della potenza ottica in ingresso/uscita dalle interfacce

dei router. Nella Errore. L'origine riferimento non è stata trovata. viene

mostrato lo scenario appena descritto.

Figura 7.1 : Banco di misura del tempo di interruzione fisica del collegamento

Una volta allestito il banco di misura come in figura si è proceduto a simulare un

guasto improvviso del link di working. Il tempo di ripristino del sistema di

protezione misurato è risultato essere pari a 20 ms. Questo tempo è il risultato

della somma dei seguenti fattori:

LINUX BOX

ROUTER 1 ROUTER 2PXC LINEA DI SERVIZIO

LINEA DI BACKUP

10% 90%

Convertitore Opto-Elettrico

OSCILLOSCOPIO

Traffico dati Collegamenti Fast Ethernet Collegamento ottico Gbe primario Collegamento ottico Gbe Secondario

LINUX BOX

CLIENT B

__________________________________________________________________

209

♦ Tempo di invio del segnale di allarme da parte dei router

♦ Tempo di elaborazione del PC di controllo

♦ Tempo di commutazione degli switch ottici

♦ Tempi di propagazione dei segnali tra i vari apparati interessati

Il tempo appena descritto è mostrato nella Errore. L'origine riferimento non è

stata trovata. direttamente fornita dallo strumento di misura utilizzato (Le Croy).

Figura 7.2 : Immagine del tempo di fuori servizio fornita dall' oscilloscopio

Questo risultato evidenzia una considerevole efficienza, in termini di velocità di

ripristino della situazione precedente al guasto, del sistema da me proposto.

7.3 TEMPO DI REAZIONE DEL ROUTER AL GUASTO Tutto quello che è stato illustrato nel paragrafo precedente riguarda

esclusivamente lo strato fisico della rete. E’ necessario ora approfondire il

comportamento del sistema ai livelli superiori al primo, per capire le effettive

conseguenze di un guasto e di un relativo ripristino relativamente ai possibili

servizi disponibili oggi nella rete .

__________________________________________________________________

210

Come già detto, il testbed di rete considerato consiste in due router IP/MPLS

connessi tramite un collegamento GbE (1000BaseLX) punto-punto su fibra ottica

monomodale.

E’ di centrale importanza capire qual è il tempo impiegato dal router per la

rilevazione del guasto al livello software su connessioni punto-punto GbE.

Un’ analisi di questo tipo è stata svolta dalla Scuola Superiore Sant’ Anna di Pisa

nel Laboratorio Nazionale di Reti Fotoniche di Pisa, proprio sui router Juniper

M10.

Secondo quanto affermato dai suddetti centri di ricerca, i router Juniper M10

presentano dei tempi di reazione al guasto che oscillano tra 40ms e circa 1 sec. Il

tempo medio misurato è di 0.573 s, la deviazione standard 0.275 s, il tempo

minimo 42 ms, il massimo 1.091 s. Fig. 2 mostra i risultati ottenuti in termini di

distribuzione dei tempi suddetti.

Figura 7.3 : Tempo di reazione al guasto dei rouetr Juniper (misurato dalla S.S.S.A.)

Confrontando quindi questi risultati con i risultati descritti nel precedente

paragrafo è possibile misurare il ritardo introdotto dal router per il definitivo

ripristino del servizio.

Si nota quindi che la distribuzione dei valori risulta piuttosto uniforme fra 0.1 s e

1 s, tale quindi da far presupporre una verifica dello stato delle interfacce da parte

del router solo di una volta al secondo. Ciò quindi determina tempi di ripristino

del guasto decisamente maggiori rispetto al tempo potenzialmente offerto dal

sistema di protezione proposto in questo lavoro.

__________________________________________________________________

211

Figura 7.4 : Schematizzazione dei tempi di ripristino Infatti qualsiasi metodo di ripristino della connettività attivato dal router su questo

tipo di connessione, ad esempio MPLS Fast Reroute su un percorso alternativo,

risulta pesantemente influenzato dal tempo di reazione al guasto.

L’evoluzione dei router commerciali dovrà quindi necessariamente tenere conto di

questi aspetti e integrare meccanismi più efficienti per la reazione al guasto.

La reazione del router, nel nostro sistema, si articola nelle seguenti fasi:

♦ In seguito al guasto, il router invia l’allarme considerando l’interfaccia

non attiva (down)

♦ il sistema di protezione fornisce un collegamento alternativo dopo 20ms

facendo tornare le interfacce in uno stato attivo (up)

♦ il router interroga l’interfaccia e trovandola attiva instrada di nuovo il

traffico sul link disponibile

Nel laboratorio di reti ottiche dinamiche ho svolto delle misure relative a questo

tempo che hanno confermato quanto offerto dalla letteratura suddetta. Tali misure

sono state realizzate utilizzando il generatore/analizzatore di traffico ANRITSU

MD1230A. Tramite questo dispositivo, collegato direttamente con il router 1, è

stato possibile generare un traffico IP a 30 Mb/s su protocollo ICMP ed

indirizzare tale traffico verso un PC collegato direttamente con il router 2. In

questo modo il traffico generato, dopo aver percorso il link sotto test, è stato

ricevuto sul PC tramite l’ analizzatore di protocollo ETHEREAL. Nella figura che

segue è riportato schematicamente quanto detto.

T [ms] 20 0

Tempo di ripristino fisico del collegamento

~500Tempo medio di

reazione del router al guasto

Intervallo di reazione al guasto da parte dei router

Tmin 40 Tmax 1000

__________________________________________________________________

212

Figura 7.5 : Configurazione utilizzata per misurare il tempo di reazione al guasto dei router

Di seguito vengono riportate le immagini fornite dal software utilizzato dove

vengono evidenziati i tempi di reazione significativi misurati. Più precisamente la

Figura 7.6 mostra il tempo minimo di reazione ottenuto pari a 40ms, mentre la

mostra un tempo medio alto di reazione ottenuto pari a 600ms. Viene mostrato sia

il report dei pacchetti IP ricevuti dallo sniffer che l’andamento del throughput

fornito dal software nei due casi.

LINUX BOX LINUX BOX

PC-SNIFFER

ROUTER 1 ROUTER 2PXC PXC LINEA DI SERVIZIO

LINEA DI BACKUP

Traffico dati Collegamenti Fast Ethernet Collegamento ottico Gbe primario Collegamento ottico Gbe Secondario

ANRITSU 1230MD

__________________________________________________________________

213

Figura 7.6 : Interruzione minima del traffico (40ms)

Figura 7.7: Interruzione medio alta del traffico (600ms)

__________________________________________________________________

214

7.4 TEST SUI SERVIZI Affinché fosse possibile stabilire l’effettiva applicabilità di questo sistema di

protezione ad un contesto reale si è proceduto a misurarne le prestazioni

relativamente ai diversi servizi disponibili attualmente nella rete.

Ciò è stato possibile grazie all’impiego del software Chariot NetIQ generalmente

utilizzato per misure oggettive della QoS. Le prestazioni del sistema sono state

valutate su diversi tipi di traffico e su tre diverse classi di servizio. Il test bed

infatti è stato configurato in accordo con l’approccio Diffserv over MPLS. In

assenza di guasti simulati sono stati configurati i router facendo riferimento ad

opportune metriche che stabiliscono i requisiti minimi di QoS da rispettare per

alcuni tipi di servizi indipendentemente dalle condizioni di traffico nella rete. Le

metriche sono riportate nella Tabella 7.1.

Tabella 7.1: Requisiti minimi per alcuni servizi multimediali

La tabella si riferisce ad un traffico DiffServ (RFC 2474,RFC 2475) consigliato

ed è stata a sua volta ricavata dalla normativa ITU-T G1010 riportata Figura 7.8:

Figura 7.8 : User-centric Delay and Packet Loss requirements – ITU G.1010*

0%

Packet Loss

Command/ control

(eg Telnet,Interactive

games)

Conversationalvoice and video

Voice/videomessaging

Streamingaudio/video

Transactions(eg E-commerce,Web-browsing, E-

mail access)

Messaging,Downloads

(eg FTP,still image)

FaxBackground

(eg Usenet)

5%

100 msec 1 sec 10 sec 100 sec

Zeroloss

Delay

__________________________________________________________________

215

7.5 TEST BED UTILIZZATO PER LE MISURE CON IL SOFTWARE CHARIOT

Passiamo ora a descrivere le modalità in cui sono state svolte le misure con il

software chariot.

Lo schema utilizzato per questo tipo di prove è rappresentato nella Figura 7.9.

Figura 7.9 : Test bed utilizzato per le misure con il software chariot

Nell’ anello ottico, che collega i due router Juniper, è stato inserito il generatore

analizzatore di traffico Anritsu MD1230A presente nel “laboratorio reti ottiche

dinamiche”. Tramite questo strumento, descritto dettagliatamente nel capitolo

precedente, è stato possibile saturare il link ottico sotto test fino al suo limite (1,25

Gbit/s), ottenendo così la possibilità di effettuare delle misure in ogni condizione

di carico della rete.

Le interfacce dei router sono state utilizzate nel seguente modo:

Laboratorio reti ottiche trasmissive -ISCOM-

Laboratorio reti ottiche dinamiche – Ufficio III ISCOM

CLIENT-1 CHARIOT

MULTIMEDIA SERVER

1,25 GBE 1,25 GBE

ANELLO OTTICO ROMA-POMEZIA Fibra ottica smf 1550 1,25 GBE

Fibra ottica MMF

Fe Fe

GENERATORE ANALIZZATORE

DI TRAFFICO

CLIENT-2 CHARIOT

SERVER CHARIOT

Convertitore Elettro-ottico

Convertitore Opto-elettrico

PXC PXC

Linea di backup

Linea di servizio

Laboratorio valutazione della QoS multimediale – Ufficio IV ISCOM Hub

__________________________________________________________________

216

♦ 2 Fast Ethernet ed 1 Gigabit Ethernet (TX/RX) sono state collegate al

generatore/analizzatore di traffico Anritsu, per congestionare la rete ed al

fine di metterci nelle probabili condizioni in cui può trovarsi una rete di

trasporto metropolitana.

♦ 2 Fast Ethernet sono state collegate ai Client Chariot

♦ 1 Gigabit Ethernet è stata utilizzata per collegare i due router con

l’anello Roma-Pomezia (ge-0/0/0).

Per quanto concerne la quarta porta Fast Ethernet disponibile, nel primo router è

stata collegata ad un convertitore elettro-ottico per permettere il collegamento tra

il laboratorio di reti ottiche dinamiche ed il laboratorio di valutazione della QoS.

Il traffico di saturazione può essere etichettato in accordo con l’approccio

DiffServ.

Nel laboratorio della Qos multimediale è presente un server di dati realizzato

mediante l’istallazione del software Chariot prodotto dalla NetIQ. La versione

client di questo programma è stata istallata sui PC del laboratorio di reti ottiche

dinamiche. Mediante l’interazione tra queste tre macchine (server più due client) è

stato possibile effettuare uno scambio di traffico dati tra i client collegati ai due

diversi router (dunque alle estremità dell’anello), e misurarne i parametri

significativi di interesse. I dati scambiati posso essere di diverso tipo, ad esempio

video conferenza realizzata mediante sessione Netmeeting, “download” di dati di

tipo FTP (File Transfer Protocol), sessioni di VoIP (Voice over IP) etc; inoltre

tramite il server Chariot è possibile decidere il rate del traffico inviato e marcare il

campo DSCP dei pacchetti IPv4 in accordo con l’approccio DiffServ30.

Quando i flussi etichettati dal Chariot giungono ad uno dei due router viene subito

esaminato il campo DSCP, questo determina il trattamento che subirà il pacchetto.

In seguito il pacchetto viene inoltrato sull’interfaccia GigabitEthernet di uscita

verso l’interfaccia GigabitEthernet di ingresso dell’altro router il quale, in seguito

ad un ulteriore studio del campo DSCP, adotterà una opportuna politica di QoS ed

instraderà i flussi verso una sua interfaccia di uscita che in questo caso è una

FastEthernet.

30 DiffServ: politica di gestione della QoS, nel nostro caso realizzata utilizzando i tre bit sperimentali della Shim header MPLS

__________________________________________________________________

217

Circa la descrizione del test-bed in esame va osservato che la totalità del traffico

che entra ed esce dalle interfacce dei router Juniper, ovvero il traffico di

saturazione dell’Anritsu e quello di test del Chariot, è traffico etichettato; i due

router non svolgono alcuna operazione sui pacchetti ma applicano semplicemente

il PHB (Per Hop Behaviour) relativamente alla classe di servizio cui

appartengono. I due router Juniper sono quindi configurati come Core Router.

Affinché fossero rispettati i requisiti minimi imposti dalla normativa sono stati

configurati sui router i drop profile31 relativi alle tre diverse classi di servizio

implementate: Expedited Forwarding , Assured Forwarding e Best Effort.

Il Drop Profile utilizzato per la classe di servizio Expedited Forwarding è

riportato in Figura 7.10:

Figura 7.10 : Drop Profile della coda Expedited Forwarding

Al 30% di riempimento della coda del traffico EF il Drop Profile presenta una

probabilità di drop (scarto) pari al 100%. Questo profilo è molto restrittivo poiché

la coda della forwarding class EF non viene mai riempita completamente, ed è

stato pensato per garantire valori di jitter e di one-way-delay molto bassi anche

se a scapito di una perdita di pacchetti alta.

Anche in condizione di rete carica tutti i paramertri di rete considerati, througput

one-way delay jitter e loss data, sono risultati al di sotto di quelli riportati nella

tabella di riferimento di Tabella 7.1. Questo comportamento ricalca in pieno le

caratteristiche cui mira l’approccio DiffServ che riserva ai flussi EF un

trattamento privilegiato.

31 Drop Profile: Descrive la probabilità di scarto dei pacchetti all’interno di una coda, in relazione al grado di occupazione della stessa

[edit class-of-service drop-profiles] admin@lab1# expedited-forwarding { interpolate { fill-level [ 0 10 15 20 25 30 ]; drop-probability [ 0 20 50 75 100 ];

}

__________________________________________________________________

218

Il Drop Profile utilizzato per la classe di servizio Assured Forwarding è riportato

nella Figura 7.11.

Figura 7.11 : Configurazione del drop profile della coda Assured Forwarding

In seguito all’osservazione dei risultati ottenuti dalle misure, è stato possibile

osservare come le perdite di dati ed i valori di one-way-delay del traffico AF siano

molto basse e praticamente comparabili con quelle del traffico EF.

Infine il buffer size ed il trasmission rate configurati sui router sono riportati nella

Figura 7.12.


EF 8% 7% AF 9% 9% BE 78% 79% NC32 5% 5%

Figura 7.12: Configurazione dello Scheduler

Grazie a questa configurazione è stato possibile rispettare i limiti imposti dalla

normativa di riferimento, in assenza di guasti simulati nella rete.

32 NC non classificato

[edit class-of-service drop-profiles]admin@lab1# assured-forwarding { interpolate { fill-level [ 0 10 20 30 40 50 60 70 80 100 ]; drop-probability [ 0 1 2 3 5 20 40 80 100 ]; }

__________________________________________________________________

219

7.5.1 Test sui servizi simulati Le misure che seguiranno sono state realizzate per testare il tempo necessario per

il ripristino software del traffico in seguito ad un link faiulre del collegamento di

esercizio. Di conseguenza non verranno considerati i limiti imposti dalla

normativa in termini di Lost Data, Jitter, Throughput medio e one-way delay, in

quanto i parametri misurati vengono decisamente alterati dal guasto della risorsa

primaria volutamente realizzato.

Il traffico di saturazione totale, prodotto dal generatore MD1230A, presente in

rete al momento dello svolgimento delle misure è stato il seguente:

♦ Expedited Forwarding: 32 Mbit/s

♦ Assured Forwarding: 80 Mbit/s

♦ Best Effort: 800 Mbit/s

7.5.2 Test di ripristino su servizi di video conferenza

A dimostrazione del corretto funzionamento della QoS differenziata ottenuta

mediante il server Chariot su rete carica in assenza di guasti simulati viene

riportata una sessione di misure effettuata su servizio Netmeeting. In particolare

dal server Chariot sono stati inviati 6 flussi Netmeeting cosi ripartiti:

♦ 2 flussi EF da 10 Mbit/s

♦ 1 flusso BE da 10 Mbit/s

♦ 3 flussi AF da 10 Mbit/s

Al traffico prodotto dal Chariot vanno sommati gli 80 Mbit/s AF e i 32 Mbit/s EF

generati dalle FastEthernet dell’Anritsu MD1230A, più gli 800 Mbit/s generati

dalle interfacce GigabitEthernet dello stesso generatore.

__________________________________________________________________

220

Figura 7.13 : Throughput delle tre classi di servizio

La scelta di questo particolare grafico sviluppato su una sessione di cinque minuti

è dovuto alla particolare resa cromatica che per contrasto rende immediatamente

evidente la differenza del trattamento delle tre tipologie: EF, AF e BE. Si può

notare come i flussi a parità di bit-rate nominale sperimentino prestazioni diverse

in base alla classe di servizio di appartenenza. I flussi EF (rosso - rosa), quelli più

privilegiati hanno throughput poco variabile e praticamente uguale a quello

nominale, il flusso BE (celeste) come ci si aspettava ha perdite notevoli e

inaccettabili ed è altamente variabile. I tre flussi AF(verde e grigio) essendo in

condizioni limite sperimentano throughput più bassi dell’EF anche se comparabili,

ma presentano una variabilità notevole. Nonostante queste osservazioni i flussi

AF rimangono comunque nei limiti prestabiliti di QoS.

Figura 7.14: Lost Data delle tre classi di servizio

__________________________________________________________________

221

In Figura 7.14 è mostrato l’andamento delle perdite dei pacchetti. Come è ben

visibile i flussi EF (rosso-rosa) hanno perdite nulle tanto che il Chariot non le

grafica, il flusso BE (celeste) ha perdite inaccettabili ed i flussi AF ( verde e

grigio) hanno perdite mediamente intorno al 4% cioè al limite dei valori imposti

per la classe Assured Forwarding.

Figura 7.15: One-Way-Delay delle tre classi di servizio In Figura 7.15 relativa al caso limite AF è mostrato il one-way delay massimo

sperimentato dai pacchetti. Per tutte le classi di servizio i valori di one-way-delay

sono bassi rispetto a quelli dettati dalla normativa di riferimento, ma risulta

evidente la differenza tra i vari flussi: il traffico EF sperimenta un ritardo

trascurabile rispetto agli altri due, mentre BE sperimenta il ritardo in assoluto più

grande, ciò è dovuto alla sua maggiore bufferizzazione.

__________________________________________________________________

222

Figura 7.16 : Jitter massimo delle tre classi di servizio

Nella Figura 7.16 è rappresentato il jitter massimo sperimentato dai pacchetti in

rete, si può notare come i flussi EF abbiano valori molto bassi, mentre per le altre

tipologie di traffico i valori sono ben più elevati, in particolare i valori del jitter

del traffico AF sono elevati poiché ci troviamo in una situazione limite e si

trovano risultati paragonabili a quelli della tipologia BE.

Dopo aver dimostrato il corretto funzionamento del test bed in relazione alla QoS

passiamo a mostrare i risultati ottenuti dalle misure relative al sistema di

protezione proposto in questo lavoro.

Le prime due serie di misure sono state effettuate sul servizio Netmeeting. Il

servizio di video conferenza è un servizio di tipo real time che usa il protocollo

RTP per il trasferimento dei dati. Si riportano di seguito i casi più significativi:

♦ simulazione di un guasto singolo all’interno della sessione di prove

♦ simulazione di guasti multipli all’interno di una sessione di prove

Guasto singolo:

Dal server Chariot sono stati inviati 12 flussi Netmeeting cosi ripartiti:

♦ 4 flusso EF da 10 Mbit/s ognuno

♦ 4 flusso BE da 10 Mbit/s ognuno

♦ 4 flussi AF da 10 Mbit/s ognuno

__________________________________________________________________

223

per un totale di 120 Mbit/s. Ricordo che al traffico prodotto dal Chariot va sempre

sommato il traffico di background prodotto dall’Anritsu descritto all’inizio del

paragrafo.

Il grafico di Figura 7.17, sviluppato su una sessione di 30 secondi, mostra il

trattamento differenziato delle tre tipologie di traffico, EF, AF e BE, anche in

presenza di una interruzione fisica. Tale interruzione è stata realizzata agendo

manualmente direttamente sulla fibra di esercizio. Come si deduce da una

semplice analisi del grafico, il traffico subisce una momentanea interruzione per

poi venire completamente ripristinato dopo un tempo pari a circa 400ms. Si può

notare come il guasto nella rete, non degrada le prestazioni che i flussi a parità di

bit-rate nominale sperimentano in base alla classe di servizio di appartenenza.

Figura 7.17 : Andamento del throughput in caso di guasto singolo per servizio Netmeeting

__________________________________________________________________

224

Figura 7.18 : Andamento del Lost Data in caso di guasto singolo per servizio Netmeeting

Nella Figura 7.18 è riportato l’andamento del lost data relativo alle tre classi di

servizio implementate. Il grafico evidenzia le conseguenze, in termini di pacchetti

persi, in seguito alla momentanea caduta del servizio.

Guasti multipli:

In questa sessione di prove sono stati simulati cinque guasti consecutivi del

collegamento primario, opportunamente distanziati nel tempo. Come è stato già

detto in precedenza il sistema di protezione sotto test è in grado di sopperire

solamente a guasti singoli, infatti le seguenti prove sono state effettuate

interrompendo il collegamento primario solo dopo aver, ogni volta, ripristinato la

situazione iniziale.

Questo è stato fatto sostanzialmente per due motivi:

♦ Evidenziare un comportamento coerente nel tempo del sistema sotto test

♦ Evidenziare la totale trasparenza al traffico del passaggio dal

collegamento di back up al collegamento di esercizio effettuato per

predisporre il sistema a reagire ai guasti successivi al primo.

Dal server Chariot sono stati inviati 12 flussi Netmeeting tutti da 10 Mbit/s,

ripartiti nel seguente modo:

♦ 4 flusso EF da 10 Mbit/s ognuno

♦ 4 flusso BE da 10 Mbit/s ognuno

♦ 4 flussi AF da 10 Mbit/s ognuno

__________________________________________________________________

225

Osservando la figura si nota inoltre che, le relative protezioni, effettuate per

ripristinare il traffico, non alterano, anche in questo caso, il comportamento delle

tre diverse classi di servizio.

Figura 7.19 : Andamento del throughput in caso di guasti multipli per servizio Netmeeting

Figura 7.20 : Andamento del Lost Data in caso di guasti multipli per servizio Netmeeting

In Figura 7.20 sono riportate le perdite di dati riscontrate nel corso dell’intera

sessione di prova. Da questo e dal precedente grafico si può notare che le perdite

relative alle diverse interruzioni sono decisamente diverse. La terza e la quarta

simulazione di guasto hanno causato un’interruzione del servizio pari a circa 300

ms ottenendo quindi una bassissima perdita di pacchetti; al contrario le altre

interruzioni offrono tempi di fuori servizio leggermente più lunghi e delle perdite

di dati ovviamente maggiori. Questa variabilità di risultati è dovuta al tempo di

reazione dei router descritto nei precedenti paragrafi.

__________________________________________________________________

226

7.5.3 Commutazione volontaria del mezzo trasmissivo Le interruzioni, relative al caso appena descritto, sono state realizzate volutamente

a distanza di 30 secondi l’una dall’altra, mentre il passaggio inverso, dalla fibra di

back up alla fibra di esercizio, è stato effettuato nei 4 secondi successivi ad ogni

simulazione di guasto. Risulta evidente, da una rapida ispezione di entrambi i

grafici, che il ritorno alla situazione precedente al guasto non genera alcuna

conseguenza sul traffico dati in questione. Essendo la video conferenza un traffico

di tipo real time interattivo, e quindi il traffico più critico in termini di Lost Data,

si può affermare che un eventuale azione volontaria riguardo la commutazione del

mezzo trasmissivo ( per ragioni legate a manutenzione o a riconfigurazione della

rete) non infici sulle prestazioni relative a nessun tipo di servizio disponibile oggi

nella rete.

Questa affermazione è stata confermata dai risultati ottenuti da tutte le misure

effettuate su questo sistema su tutti i tipi di servizio real-time e non real-time.

E’ opportuno inoltre osservare che, in corrispondenza di una commutazione

volontaria del mezzo trasmissivo, l’interfaccia del router dovrebbe percepire una

mancanza di potenza ottica per il tempo che gli switch ottici richiedono per

effettuare lo scambio (3ms). In realtà il router, in questo caso, non invia nessun

allarme il che significa che il LOL viene inviato solamente quando la mancanza di

luce persiste per un tempo maggiore a 3ms. Questo risultato è da sottolineare in

vista di un inserimento futuro di dispositivi ottici all’interno della rete, ad esempio

convertitori di lunghezza d’onda. E’ infatti utile rimarcare che qualora l’intervento

su tali dispositivi occupi un tempo minore o uguale a 3ms, il router non viene in

nessun modo coinvolto e il traffico da esso instradato non subisce alcuna

degradazione.

7.5.4 Test di ripristino su servizio VoIP (Voice over IP)

Il servizio Voice over IP analogamente al servizio Netmeeting è un servizio di

tipo real-time, quindi richiede parametri di QoS molto stringenti. Come per il caso

__________________________________________________________________

227

generico Netmeeting, dalle misure effettuate in assenza di guasti simulati, non è

evidente la differenza di prestazioni tra i flussi EF e AF.

La configurazione del traffico inviato dal Server Chariot, utilizzata per le misure,

è stata:

♦ 15 flussi VoIP Expedited Forwarding

♦ 15 flussi VoIP Assured Forwarding

♦ 15 flussi VoIP Best Effort

per un totale di 45 flussi.

Anche per questo servizio si sono effettuate alcune misure su guasto singolo ed

alcune misure su guasti multipli consecutivi. Tutte le prove riguardanti questo

servizio sono state realizzate sullo standard G.711.

Guasto singolo:

Nella Figura 7.21 viene graficata, tramite l’andamento del throughput,

l’interruzione del servizio dovuta ad un guasto singolo all’interno di una sessione

di prova della durata di 2 minuti. Da una rapida ispezione dl grafico è possibile

notare che prima del guasto del link di esercizio i flussi appartenenti alla classe di

servizio Best Effort presentano un throughput mediamente minore ed un

andamento molto più variabile rispetto alle CoS AF ed EF. In seguito al ripristino

del servizio le tre CoS offrono, per un tempo limitato, prestazioni identiche in

termini di throughput medio. Questo accade poichè il traffico di background

presente in rete è il medesimo di quello utilizzato per le prove sul servizio di

video conferenza, ma in questo caso l’occupazione di banda del servizio sotto test

è decisamente inferiore. Questo comporta che in seguito all’interruzione, le code

dei router si svuotano quasi totalmente e, data la limitata occupazione di banda del

servizio, tutte le code dei router potranno essere servite con una frequenza tale da

non generare perdite.

Dopo un determinato lasso di tempo le priorità imposte sulle code dei router per le

tre diverse CoS causano il riempimento della coda dedicata al BE che torna a

presentare le medesime prestazioni precedenti al guasto.

__________________________________________________________________

228

Figura 7.21 : Andamento del throughput in caso di guasto singolo per servizio VoiP

Quanto appena descritto dall’analisi dell’andamento del throughput medio è

confermato dal grafico che descrive l’andamento delle perdite nella Figura 7.22.

L’interruzione del servizio sperimentata dalla misura appena descritta è stata di

circa 900ms.

Figura 7.22 : Andamento del Lost Data in caso di guasto singolo per servizio VoiP

Guasti multipli:

Analogamente a quanto visto per il servizio Netmeeting le misure relative ad

interruzioni multiple del link di servizio sono state realizzate per evidenziare due

aspetti:

♦ un comportamento coerente nel tempo del sistema sotto test

__________________________________________________________________

229

♦ la totale trasparenza al traffico del passaggio dal collegamento di back

up al collegamento di esercizio effettuato per predisporre il sistema a

reagire ai guasti successivi al primo.

In questo caso sono stati simulati due guasti a distanza di 1minuto e 20 secondi, in

una sessione di prova della durata complessiva di 3 minuti.

Figura 7.23 : Andamento del throughput in caso di guasti multipli per servizio VoiP

Figura 7.24 : Andamento del Lost Data in caso di guasti multipli per servizio VoiP

E’ evidente che i risultati ottenuti sono completamente in linea con quanto detto in

precedenza per il caso di singolo guasto, ed è importante sottolineare che anche

per questo servizio la commutazione tra il link di back up ed il link di working

non genera alcuna conseguenza parametri di rete misurati.

__________________________________________________________________

230

La classe di servizio EF, per come è configurata sui router, può supportare una

grande quantità di traffico real-time senza compromettere la qualità del servizio.

Nelle misure che seguiranno verranno presi in considerazione servizi di tipo non

real-time che viaggiano su protocolli tipo TCP . Il parametro che si considererà di

qui in seguito è il throughput medio.

7.5.5 Test di ripristino su servizi audio-video non real time

Per osservare il comportamento del sistema di protezione riguardo a questo tipo di

servizi si è utilizzato il generatore/analizzatore di traffico Anritsu MD1230A in

modalità ‘passante’. Il dispositivo in questione offre infatti la possibilità di essere

utilizzato per graficare il throughput del traffico che lo attraversa. Per fare ciò si

sono utilizzate quattro interfacce Fast Ethernet nella modalità descritta in Figura

7.25.

Figura 7.25 : Configurazione del Test bed per misure su streaming non real-time

Lo streaming media è composto principalmente da quattro elementi:

LINUX BOX LINUX BOX

CLIENT

ROUTER 1 ROUTER 2PXC PXC LINEA DI SERVIZIO

LINEA DI BACKUP

SERVER MULTIMEDIALE

Generatore/Analizzatore di traffico ANRITSU

__________________________________________________________________

231

1) Encoder: digitalizza il contenuto in un formato compresso con una speciale

sequenza di trasmissione. Il flusso di dati può essere codificato per differenti

bitrate33, in modo da consentire agli utenti una fruizione ottimizzata secondo il

loro metodo di accesso.

2) Streaming Server: computer appositamente configurato per la gestione di file

multimediali. Fornisce l’accesso ai contenuti agli utenti che lo richiedono.

3) Rete di distribuzione: Internet o Virtual Private Network (VPN).

4) Client: applicazione che gira su un terminale e consente di vedere il contenuto

dello streaming. Il processo di streaming può essere così sintetizzato (Figura 7.26):

♦ Un evento viene registrato

♦ Il contenuto è sottoposto a editing e digitalizzato

♦ Il contenuto digitale audio/video viene codificato per lo streaming.

♦ Il media file viene memorizzato su un apposito server.

♦ Il file invia lo streaming all’utente che lo richiede.

♦ L’utente visualizza il contenuto grazie a una utility come Windows

Media Player, Real Player o QuickTime.

33 Prodotto tra la frequenza di campionamento e il numero di bit utilizzati durante il processo di quantizzazione. A un bitrate elevato corrispondono una migliore qualità del video, ma anche maggiori dimensioni

Figura 7.26 : Componenti dello streaming

__________________________________________________________________

232

I pacchetti che giungono al destinatario sono prima inseriti in un buffer e poi

decompressi in successione dal player; il contenuto viene riprodotto mentre si

continuano a ricevere i pacchetti dello stesso flusso.

Il vantaggio principale dello streaming sta proprio nel fatto che non bisogna

scaricare completamente il file prima di utilizzarlo. Supponiamo ad esempio di

voler vedere un filmato con un bitrate compatibile con la velocità della nostra

connessione. Se la dimensione del file fosse molto grande, il download potrebbe

durare anche parecchi minuti. Grazie allo streaming invece possiamo iniziare la

visione dopo appena pochi secondi.

Inoltre ogni singolo pacchetto, dopo essere stato utilizzato, può essere scartato.

Ciò consente di non occupare spazio su disco e di non dare il possesso del file

all’utente.

Abbiamo visto che lo strato IP non offre alcun tipo di qualità di servizio e le unità

informative possono essere perse, duplicate, ritardate o consegnate fuori sequenza.

Per garantire un trasporto affidabile si usa normalmente il protocollo TCP, ma le

ritrasmissioni e il controllo di flusso/congestione causano dei ritardi inaccettabili

per una comunicazione in real-time.

Per le trasmissioni multimediali si utilizza allora il protocollo UDP (User

Datagram Protocol), che fornisce un servizio senza connessione, non affidabile,

senza controllo di flusso e congestione. Lo streaming multimediale si basa su

diversi tipi di protocolli:

♦ RTP (Real-time Transport Protocol): gestisce l’effettivo trasferimento

dei dati.

♦ RTCP (Real-time Control Protocol): consente di ottenere informazioni

sulla qualità della trasmissione.

♦ RTSP (Real-time Streaming Protocol): consente di controllare il flusso

di informazioni trasmesse.

♦ RDT (Real Data Transport): protocollo proprietario della Real Networks

per la comunicazione tra RealServer e RealPlayer.

♦ PNM (Progressive Networks Media): protocollo proprietario della Real

Networks per lo streaming audio.

__________________________________________________________________

233

♦ SDP (Session Description Protocol): ha lo scopo di fornire informazioni

sulla sessione multimediale (nome, indirizzi IP, porte, formati...)

♦ MMS (Microsoft Media Server): protocollo proprietario della Microsoft,

usato con le architetture Windows Media Technologies.

♦ HTTP (Hyper Text Transfer Protocol): adoperato nello streaming on

demand.

Per realizzare uno streaming non real time è possibile utilizzare protocolli che si

appoggiano su TCP come HTTP o RTCP. In questo modo nel momento in cui si

verifica una perdita di pacchetti il protocollo può richiedere una ritrasmissione

degli stessi garantendo una continuità del flusso di immagini all’utente. Questo è

possibile data la natura non interattiva del servizio.

Nel caso di queste misure si è simulata la situazione nella quale un client richiede

un servizio di video on demand ad un server remoto. La trasmissione dei dati

avviene avvalendosi del supporto del protocollo TCP.

Nel laboratorio di reti ottiche dinamiche è presente un server multimediale che è

stato utilizzato come sorgente di traffico. Nella Figura 7.28 viene mostrato

l’andamento del throughput relativo a due stream codificati in MPEG-2 ad 8

Mbps etichettati diversamente in assenza di simulazioni di guasto. Per rendere più

evidente la differenza di prestazioni dei due flussi sono state considerate solo la

CoS EF e la CoS BE. Il traffico di background è il medesimo di quello utilizzato

nelle prove precedenti.

Figura 7.27 : Protocolli utilizzati per lo streaming

__________________________________________________________________

234

Figura 7.28 : Throughput di due streaming appartenenti a due CoS ( blu-EF, verde-BE)

La linea verde rappresenta i throughput relativo al flusso BE che risulta

decisamente minore del throughput relativo al flusso EF rappresentato dalla linea

blu.

Nella Figura 7.29 è invece graficata l’interruzione del sevizio relativa al guasto

della risorsa primaria. E’ evidente, dal grafico, che in seguito all’interruzione, il

traffico EF viene ripristinato prima del traffico BE grazie alla maggiore priorità

riservata alla coda EF nei router rispetto alle code relative alle altre CoS. Subito

dopo viene ripristinato anche il flusso BE che per un tempo finito successivo al

ripristino presenta un throughput medio più alto dell’EF. Questo è imputabile al

fatto che nell’attesa che la coda dell’EF venga servita la coda BE accumula dati

che dovranno essere tramessi con un rate più elevato nel momento in cui la coda

BE viene servita, al fine di garantire una continuità del flusso video lato cliente.

Inoltre è da sottolineare che il guasto e il relativo ripristino risultano totalmente

trasparenti all’utente grazie alla bufferizzazione preventiva del video ed al

contributo offerto dal TCP nel ritrasmettere i dati persi.

__________________________________________________________________

235

Figura 7.29 : Andamento del througput di due streming video non real time in caso di guasto

7.5.6 Test di ripristino su servizio di trasferimento dati In questa sessione di test, analogamente alla precedente, si è fatto uso del

generatore/analizzatore di traffico Anritsu MD 1230A al fine di monitorare il

comportamento del sistema su questo tipo di servizo.

Il servizio di trasferimento dati è stato realizzato trasmettendo dei dati da un

server ad un client in seguito ad una richiesta dello stesso.

La Figura 7.30 mostra l’andamento del throughput relativo ai due flussi

diversamente etichettati ( BE – verde ; EF – blu ) in seguito ad una simulazione di

guasto.

Come si può osservare l’andamento ricalca quanto visto nel paragrafo precedente

per il servizio audio-viedo non real time.

Queste analogie fra i due servizi sono dovute al fatto che anche il servizio FTP

(File Transer Protocol) è non real-time ed al fatto che anche questo tipo di servizio

__________________________________________________________________

236

utilizza il protocollo TCP. Anche in questo caso si può notare che il flusso EF

viene ripristinato prima del flusso BE e che, successivamente al ripristino, è

presente un momentaneo aumento di throughput per il flusso BE.

Infine è importante sottolineare che anche in questo caso il guasto, ed il relativo

ripristino, avviene in maniera totalmente trasparente all’utente.

Figura 7.30 : Andamento del throughput di due flussi FTP in caso di guasto

7.6 RISPRISTINO DEL SERVIZIO MEDIANTE PROTOCOLLO OSPF

In questo paragrafo verranno riportati i risultati ottenuti dalle misure del tempo di

ripristino del servizio, ottenuto utilizzando il protocollo di routing OSPF in luogo

del sistema di protezione oggetto di questo lavoro. Più precisamente si è voluto

misurare il tempo in cui il protocollo OSPF riesce riconoscere un cambiamento

improvviso della topologia della rete ed a reagire di conseguenza ripristinando il

corretto flusso di dati.

__________________________________________________________________

237

A tal proposito si è utilizzato il terzo router presente nel labotorio di reti ottiche

dinamiche affinché fosse disponibile una via alternativa tra i due client interessati

alla comunicazione. La situazione appena descritta è rappresentata in Figura 7.31.

Figura 7.31 : Ripristino del servizio mediane protocollo di routing OSPF

Dalle misure effettuate è stato possibile constatare che il tempo di ripristino del

servizio con queste modalità è mediamente pari a 8 secondi. Infatti, una volta

riconosciuto il link failure il protocollo OSPF deve cancellare il ramo relativo dal

grafo originario, e procedere ad un calcolo di tutte le strade alternative per

raggiungere la destinazione, scegliendo fra queste la via più convenientee stilando

quindi la nuova tabella di instradamento. E facile osservare che nel nostro caso la

via alternativa è una sola e che, in una situazione di rete reale, nella quale

aumentano decisamente il numero di nodi ( router ) e di rami, il tempo di calcolo

relativo ad una riconfigurazione dinamica della rete crescerebbe notevolmente.

Infatti il tempo di calcolo di una nuova tabella di instradamento da parte

dell’algoritmo di dijkstra (algoritmo utilizzato dal protocollo OSPF per il calcolo

delle tabelle di instradamento e dei relativi percorsi) è pari a N*log L dove N è il

numero di rami ed L è il numero di nodi.

CLIENT A CLIENT B

Router 1 Router 2

Router 3

__________________________________________________________________

238

Questo processo è estremamente costoso in termini temporali e può durare anche

40 o 50 secondi. Tali tempi non sono accettabili per un servizio real-time a

pagamento come IP-TV, Netmeeting etc.

Sempre in collaborazione con il laboratorio della QoS e grazie all’utilizzo del

server Chariot si è potuto misurare il tempo di fuori servizio della rete registrato

su un traffico Netmeeting. E’ stato scelto questo servizio perché, essendo

interattivo, è decisamente il più sensibile a quelle situazioni capaci di causare

rilevanti perdite di dati, quale è il caso di un guasto improvviso nella rete.

Nella Figura 7.32 è riportato l’andamento del throughput in caso di guasto

singolo del link d’esercizio.

Figura 7.32 : Andamento del throughput in caso di guasto gestito dall'OSPF su servizio

Netmeeting

Anche se, come già detto, si sta considerando il caso di singolo guasto, sono ben

visibili due interruzioni del servizio ognuna delle quali pari a circa 9 secondi. Il

motivo della seconda interruzione è dovuto ad un ritorno alla situazione

precedente al guasto. E’ infatti importante notare che nel momento in cui il link

guasto viene ripristinato, il protocollo di routing percepisce la presenza di un

nuovo ramo e quindi un’altra possibile via per raggiungere il nodo. Viene quindi

intrapreso il medesimo procedimento seguito dopo il guasto del link di esercizio,

ovvero viene ricalcolata nuovamente la tabella di instradamento.

Nella Figura 7.33 è visibile l’andamento delle perdite nella situazione appena

descritta ed è un ulteriore conferma che per applicazioni di tipo real time non è

__________________________________________________________________

239

ammissibile che la protezione del traffico venga demandata solamente ad un

algoritmo di routing dinamico quale è l’OSPF.

Figura 7.33 : Andamento del Lost Data in caso di guasto gestito dall'OSPF su servizio

Netmeeting

Capitolo 8

PROVE SOGGETTIVE E QUALITA’ PERCEPITA DALL’UTENTE FINALE

8.1 ELEMENTI NORMATIVI PER LA VALUTAZIONE SOGGETTIVA DELLA QUALITA’ DEL SERVIZIO

In questo capitolo viene illustrata una rassegna di normative e metodi per la

valutazione della qualità del servizio percepita dall’utente finale per servizi di tipo

real-time quale ad esempio l’IP-TV, più una breve descrizione degli enti

normativi stessi. Verranno inoltre descritti nel dettaglio le modalità di

svolgimento delle prove per la qualità percepita dall’utente finale ed i risultati

ottenuti in termini di valutazione.

Lo studio dei risultati sotto questo punto di vista ha il solo scopo di evidenziare la

correlazione esistente tra il tempo di fuori servizio misurato oggettivamente e

l’effettiva percezione dell’utente di tale situazione.

8.2 NORMATIVE ITU-T ED ITU-R

8.2.1 Enti per la valutazione delle QoS La Qualità del servizio consiste di due aspetti fonadamentali:

♦ QoS di rete: controllo della correttezza del flusso informativo e delle

prestazioni di rete.

♦ QoS del contenuto: controllo della correttezza del contenuto del

flusso informativo in relazione alla percezione dell’utente del servizio.

La valutazione della QoS è da qualche anno in fase di standardizzazione; gli enti

che se ne stanno occupando sono:

__________________________________________________________________

241

♦ E.T.S.I. (European Telecomunications Standard Institut): è

un’organizzazione indipendente e no-profit il cui obiettivo è quello di

produrre standards per le telecomunicazioni del presente e del futuro.

L’ ETSI è ufficialmente responsabile delle standardizzazioni della

ICT ( Information & Communication Technologies ) in Europa.

♦ A.N.S.I. (American National Standards Institute): è

un’organizzazione privata e no-profit che amministra e coordina il

sistema di standardizzazione e valutazione di conformità di sistemi di

telecomunicazione negli Stati Uniti. L’obiettivo di questo istituto è

quello di migliorare sia la competitività globale del commercio degli

Stati Uniti sia la qualità della vita degli statunitensi promuovendo e

facilitando i campioni di consenso ed i sistemi volontari di valutazione

di conformità a salvaguardia della loro integrità.

♦ I.T.U. (International Telecomunication Union): è un organismo

internazionale per la standardizzazione delle specifiche tecniche

riguardanti vari campi delle telecomunicazioni. L’ ITU ha tra i suoi

obiettivi di massima quello di mantenere ed estendere la cooperazione

internazionale per il miglioramento delle telecomunicazioni, quello di

offrire l’assistenza tecnica ai Paesi in via di sviluppo e quello di

promuovere a livello internazionale l’adozione di un approccio più

generale alle questioni riguardanti le telecomunicazioni, tutto ciò in

vista della globalizzazione dell’economia e della società

dell’informazione.

L’ ITU è costituita da tre settori:

♦ ITU-T Telecomunication Standardization: ha come obiettivo la

produzione efficiente e veloce di standard di alta qualità

(Reccomendations) che riguardano tutti i campi delle

telecomunicazioni.

♦ ITU-R Radiocomunications : è il settore che riguarda le

radiocomunicazioni e gioca un ruolo fondamentale nella gestione

dello spettro delle radio-frequenze e delle orbite satellitari.

__________________________________________________________________

242

♦ ITU-D : è il settore dello sviluppo ed è nato di recente con l’intento di

favorire lo sviluppo armonico delle telecomunicazioni nei Paesi in via

di sviluppo fornendo loro l’assistenza necessaria.

8.2.2 QoS della rete Per la valutazione della QoS di rete la ITU-T ha pubblicato quattro normative:

• G 1010- Categorie della QoS multimediale END-USER

Questa Raccomandazione definisce un modello di riferimento per le categorie

della QoS multimediale realizzato tenendo conto del punto di vista dell’utente

finale. In considerazione delle aspettative di qualità di un utente finale riguardo

alle applicazioni multimediali sono state create 8 categorie basate sui valori di

perdita delle informazioni e ritardo dei pacchetti. Lo scopo della G 1010 è quello

di stabilire i fattori chiave che influenzano la Qualità del Servizio percepita

dall’utente finale.

Fattori che influenzano la QoS End-USER:

1. Delay: è dato dalla somma di molti termini tra cui il tempo necessario per

stabilire un particolare servizio una volta richiesto dall’utente. Il ritardo ha

un impatto notevole sulla soddisfazione dell’utente soprattutto per

applicazioni multimediali interattive .

2. Jitter: il jitter è definito come la variazione del ritardo end-to-end ed è

causato principalmente dalla variazione del cammino e dal differente

ritardo di accodamento all’interno dei router dei pacchetti IP. Per le

applicazioni più sensibili al jitter è prevista una bufferizzazione aggiuntiva

(buffer di play-out) lato user che diminuisce o elimina il jitter.

3. Perdita di informazione: ha un effetto diretto sulla qualità del servizio e

non riguarda solo la perdita dei pacchetti all’interno della rete o errori di

trasmissione ma anche la degradazione dovuta alla compressione del

segnale sorgente.

Date post:	13-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

4.3.1 Switch Ottico · In pratica, sul connettore a 25 piedini si trovano direttamente i segnali...

Documents