Veniamo adesso alla descrizione del test condotto per quantificare il tempo im- piegato dall’applicazione per reagire ad un malfunzionamento, ovvero per at- tuare la funzionalit`a di TR. L’esperimento impiega esclusivamente la topologia illustrata nel paragrafo 6.1. Il numero di host complessivamente presenti `e pari a 6, equamente distribuiti tra lo switch s1 (h1, h2 e h3) e lo switch s7 (h4, h5 e h6). Dopo aver generato la rete di figura 6.1, si procede quindi a produrre 3 flussi di traffico CBR, aventi le caratteristiche riportate nella tabella 7.6.
Banda (Mbit/s) Host sorgente Host destinatario
Flusso 1 1 h1 h4
Flusso 2 1 h2 h5
Flusso 3 1 h3 h6
Tabella 7.6: Caratteristiche relative ai flussi di traffico generati per quantificare TTD e TTR
Grazie alla funzionalit`a di LB, la cui corretta implementazione `e stata pre- cedentemente verificata, tali flussi seguiranno rispettivamente i percorsi: s1 → s3 → s7, s1 → s2 → s5 → s7 e s1 → s4 → s6 → s7. Per visualizzare lo scenario, si faccia riferimento alla figura 7.1.
A questo punto, uno tra i link utilizzati viene disattivato manualmente. L’esperimento “base”, appena descritto, `e stato ripetuto per un totale di 8 × 2 × 100 = 1600 volte. Per ciascuno degli 8 collegamenti utilizzati dai flussi presentati nella tabella 7.6 sono state condotte 2 serie da 100 ripetizioni: in una, il flusso corrispondente `e stato specificato come Bronze; nell’altra, come Silver. Supponendo di voler abbattere il link esistente tra gli switch s1 e s2, il comando utilizzato in Mininet `e il seguente:
net . c o n f i g L i n k S t a t u s (’ s1 ’,’ s2 ’,’ d o w n ’).
Per la parte relativa alle temporizzazioni, si `e fatto ricorso alla libreria time [34] del linguaggio di programmazione Python. In particolare, il meto- do time.time() restituisce il numero di secondi trascorsi da “epoca”3, rap- 3“Epoca” (epoch) costituisce l’origine dell’asse dei tempi. Nei sistemi Unix, essa coincide con la mezzanotte del 01/01/1970.
presentato in virgola mobile. `E importante sottolineare che, qualora si voglia memorizzare il valore restituito da time.time() in un file di testo (per successi- ve elaborazioni), `e caldamente consigliato l’utilizzo del metodo repr() al posto di str(), pena una consistente perdita di cifre significative.
Nel corso dell’esperimento, sono stati prelevati i valori relativi a 4 istanti temporali:
• tFail, all’interno dello script per il lancio della topologia, immediatamen- te precedente alla chiamata del metodo configLinkStatus();
• t, all’ingresso del metodo linkMod() della classe routingHandler (para- grafo 5.5), chiamato da handle PortStatus() a seguito della ricezione dell’evento corrispondente;
• tProt, immediatamente seguente alla rimozione delle regole relative al WP di un flusso Silver, all’interno del metodo recovery() della classe routingHandler, chiamato da linkMod();
• tRest, all’uscita dal metodo installPaths(), chiamato da recovery(), per il calcolo ed eventualmente l’installazione del RP per un flusso Bronze. Chiaramente, la differenza t−tFail fornisce il valore del TTD per la partico- lare ripetizione dell’esperimento, mentre il calcolo del TTR nel caso di flusso Sil- ver o Bronze viene effettuato tramite le relazioni tProt−tFail o tRest−tFail, rispettivamente.
Le figure 7.53 e 7.54 riportano i valori minimi, medi e massimi di TTD e TTR, raccolti durante le 1600 ripetizioni. I dati relativi ai flussi Bronze, ovvero alla funzionalit`a di Restoration, sono illustrati nelle figure 7.53b e 7.54b, quelli corrispondenti ai flussi Silver, ovvero alla funzionalit`a di Protection, vengono riportati dalle figure 7.53a e 7.54a.
`
E facile osservare come i valori di TTD risultino omogenei, indipendente- mente dal link e dal tipo di flusso considerati. Per quanto riguarda il TTR, invece, troviamo conferma a quanto avevamo gi`a ipotizzato nel paragrafo 5.5: i flussi Silver sperimentano, in media, un TTR inferiore rispetto ai flussi Bronze. Questo `e dovuto al minor numero di operazioni richieste dai primi, rispetto ai secondi, per realizzare la funzionalit`a di TR. Ricordiamo, infatti, che l’attiva- zione del RP per un flusso appartenente alla classe di traffico Silver richiede esclusivamente la rimozione delle regole OpenFlow corrispondenti al WP. Il cal- colo, ed eventualmente l’installazione, del primo `e gi`a avvenuto in concomitanza all’attivazione del secondo. Per un flusso Bronze, invece, l’attivazione del RP richiede, anzi tutto, la sua ricerca ed installazione, operazioni temporalmente pi`u dispendiose rispetto alla semplice rimozione di alcune regole.
Tali considerazioni vengono rafforzate dall’esame delle figure 7.55 e 7.56, le quali riportano i valori di Mean Time To Detect (MTTD) e di Mean Time To Repair (MTTR), in funzione dei link considerati. Interpretando TTD e TTR come variabili aleatorie, si `e provveduto a fornire ciascuno di essi del relativo “intervallo di confidenza” (confidence interval ) al 90%.
Esperimenti condotti sull’architettura realizzata 137
Nel calcolo di tale intervallo, `e stata adottata l’ipotesi di Gaussianit`a. A tal fine, si supponga di disporre di N variabili aleatorie {Xi}
N
i=1IID rappresentanti, ad esempio, i valori di TTD o TTR misurati nel corso degli esperimenti di cui sopra. Per ciascuna di esse, si ha
E [Xi] = µ ∀ i = 1, . . . , N, Var [Xi] = σ2 ∀ i = 1, . . . , N. Si consideri adesso la variabile aleatoria ˆµ, definita come
ˆ µ = 1 N N X i=1 Xi,
essa costituisce uno stimatore consistenete e non polarizzato del valor medio µ, essendo verificate le releazioni
E [ˆµ] = µ, Var [ˆµ] = σ 2 N.
L’ipotesi di Gaussianit`a, dunque, consiste nel supporre che ˆ µ ∈ N µ,σ 2 N . (7.5)
La determinazione dell’intervallo di confidenza al 100 × α% si traduce nella ricerca del valore ∆αtale che
P (|µ − ˆµ| ≤ ∆α) = α, (7.6) ovvero che P (ˆµ − ∆α≤ µ ≤ ˆµ + ∆α) = α. Se la (7.5) `e verificata, la (7.6) equivale a 1 − 2 Q ∆α σ/√N = α. Dopo alcuni passaggi algebrici, si giunge alla relazione
∆α= σ √ N Q −1 1 − α 2 .
Per un intervallo di confidenza al 90% il valore di α corrispondente `e 0.9. Consultando l’espressione in forma tabulata della funzione di distribuzione per una variabile aleatoria gaussiana standard, si ricava che Q−1(0.9) ≈ 1.65. Chia- ramente, non disponiamo del valore esatto di σ, ma `e pur sempre possibile effettuarne una stima (non polarizzata), grazie alla relazione
ˆ σ = v u u t 1 N − 1 N X i=1 (Xi− ˆµ) 2 .
MTTD (ms) MTTR (ms) Protection (Silver) 23.7827 ± 0.5848 27.3668 ± 0.6403
Restoration 23.2668 ± 0.5895 36.8622 ± 0.7230 Tabella 7.7: MTTD e MTTR complessivi
Dunque, per i nostri scopi
∆α= 1.65 × ˆσ √ N , (7.7) da cui segue P ˆ µ −1.65 × ˆ√ σ N ≤ µ ≤ ˆµ + 1.65 × ˆσ √ N ≈ 0.9.
Gli intervalli di confidenza mostrati nelle figure 7.55 e 7.56 sono stati ottenuti applicando fedelmente la (7.7), con N = 100.
La tabella 7.7 riporta i valori di MTTD e MTTR complessivi, ovvero indipen- denti dal particolare collegamento, sia per i flussi Silver che per i flussi Bronze. Chiaramente, il relativo intervallo di confidenza al 90% `e stato calcolato appli- cando la (7.7), con N = 800. `E significativo osservare che, indipendentemente dalla strategia di TR utilizzata, il requisito tipico delle reti ottiche di trasporto SONET/SDH viene mediamente rispettato. Esse, infatti, garantiscono un TTR al pi`u pari a 50 millisecondi.
Esperimenti condotti sull’architettura realizzata 139 s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 0 10 20 30 40 50 60 70 Link Time To Detect (ms) Minimo Medio Massimo
(a) Protection (Silver)
s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 0 10 20 30 40 50 60 70 Link Time To Detect (ms) Minimo Medio Massimo (b) Restoration
s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 0 10 20 30 40 50 60 70 Link Time To Repair (ms) Minimo Medio Massimo
(a) Protection (Silver)
s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 0 10 20 30 40 50 60 70 80 Link Time To Repair (ms) Minimo Medio Massimo (b) Restoration
Esperimenti condotti sull’architettura realizzata 141 s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 20 21 22 23 24 25 26 27 28 Link
Mean Time To Detect (ms)
Protection (Silver)
Protection (Silver) − Intervallo di confidenza al 90% Restoration
Restoration − Intervallo di confidenza al 90%
Figura 7.55: Mean Time To Detect
s1−s2 s1−s3 s1−s4 s2−s5 s3−s7 s4−s6 s5−s7 s6−s7 24 26 28 30 32 34 36 38 40 42 Link
Mean Time To Repair (ms)
Protection (Silver)
Protection (Silver) − Intervallo di confidenza al 90% Restoration
Restoration − Intervallo di confidenza al 90%
Capitolo 8
Conclusioni
Questo elaborato documenta il lavoro di tesi intrapreso per progettare, rea- lizzare e validare un’applicazione di controllo, conforme al Software-Defined Networking, avente funzionalit`a di Load Balancing e Traffic Recovery.
Il Load Balancing viene ottenuto sfruttando le statistiche relative alle por- te di uno switch che il protocollo OpenFlow mette a disposizione. A patto di giungere ad una rappresentazione astratta dell’infrastruttura sotto forma di grafo, tramite tali informazioni `e possibile far variare il costo di un certo arco in funzione del livello di utilizzazione sperimentato dal collegamento associato. La conseguente esecuzione dell’algoritmo di Dijkstra consente di determinare i cammini corrispondenti ai percorsi attualmente meno congestionati, sui quali inoltrare il traffico della rete. L’applicazione prevede, inoltre, la possibilit`a di utilizzare tre diverse tipologie di metrica, le quali si differenziano per la velocit`a con cui un certo link viene penalizzato.
Gli esperimenti condotti dimostrano che, grazie alla nostra euristica di Load Balancing, un flusso UDP sperimenta in media percentuali di perdita inferiori, rispetto a quelle che subirebbe qualora si dovesse adottare una strategia statica di assegnazione dei costi. Allo stesso tempo, un flusso TCP `e in grado di otte- nere rate trasmissivi mediamente superiori, se confrontati con quelli ottenibili optando per un criterio di tipo Fixed Cost.
La funzionalit`a di Traffic Recovery viene, a sua volta, implementata sfrut- tando le peculiarit`a del protocollo OpenFlow. Grazie al messaggio asincrono Port-Status, siamo in grado di rivelare tempestivamente l’esistenza di un mal- funzionamento. Nel ricollocare i flussi interessati, si procede in senso decrescente rispetto alla banda da essi occupata. Quest’ultima viene calcolata grazie alle statistiche di flusso prelevabili dalla tabella di uno switch.
L’applicazione `e in grado di gestire fino a quattro classi di traffico, le quali si differenziano per il livello di protezione riservato ai flussi corrispondenti. La tecnica di Traffic Recovery associata ad un flusso Bronze `e quella della Resto- ration. Ci`o significa che un eventuale Recovery Path viene calcolato solamente a guasto avvenuto. Esso pu`o coincidere sia con il percorso meno congestiona- to che con quello maggiormente congestionato disponibile al momento, ma pur
sempre dotato di banda residua sufficiente ad accogliere il nuovo flusso. La tecnica di recovery riservata alle classi di traffico successive, invece, `e quella della Protection. Il Recovery Path per tali flussi viene infatti calcolato conte- stualmente all’installazione del relativo Working Path. Per un flusso Silver, le regole relative al primo percorso sono caratterizzate da una priorit`a inferiore, rispetto a quelle utilizzate per il secondo. A seguito di un guasto, dunque, il Working Path deve essere rimosso dalle tabelle degli switch perch´e il Recovery Path possa attivarsi. I pacchetti appartenenti ai flussi Gold e Platinum, invece, vengono inoltrati contemporaneamente su due percorsi disgiunti, risultando per questo immuni nei confronti di guasti isolati. In aggiunta, la classe Platinum gode dell’isolamento fisico rispetto al resto dell’infrastruttura.
I test dimostrano che il Time To Repair sperimentato da un flusso Bronze `
e in media superiore rispetto a quello sperimentato da un flusso Silver, a causa del maggior numero di operazioni richieste per attuare la funzionalit`a di Traffic Recovery. In particolare, l’applicazione consente di ottenere un valore di Mean Time To Repair inferiore a 40 e 30 millisecondi, rispettivamente. Quest’ultimo risultato `e particolarmente significativo in quanto consente di affermare che, grazie alle strategie di recovery adottate, il vincolo dei 50 millisecondi tipico delle reti ottiche di trasporto `e mediamente rispettato.
Infine, segnaliamo che il lavoro di tesi presentato ha fornito il materiale utile per la stesura dell’articolo “Design and Performance Assessment of an SDN Control Application for Load Balancing and Traffic Recovery”, candidato ad essere pubblicato negli IEEE GLOBECOM 2014 Proceedings.
Appendice A
Load Balancing: corretto
funzionamento – Data
Center
In quest’appendice vengono riportati i grafici relativi all’esperimento condotto per verificare la validit`a della funzionalit`a di LB, relativamente alla topologia illustrata nel paragrafo 6.2.
Il test consiste nel generare la rete di figura 6.2 e nel produrre 2 flussi di traffico CBR, aventi le caratteristiche riportate nella tabella A.1. Ammesso che la funzionalit`a di LB sia stata implementata correttamente, tali flussi seguiranno cammini diversi all’interno del DC.
L’esito dell’esperimento viene sintetizzato dalla figura A.1. Le figure A.2-A.9 mostrano il carico complessivamente sperimentato da alcuni link della topologia, in funzione del tempo. `E stata cio`e effettuata una somma tra le bande relative alle 2 direzioni Simplex del collegamento Full Duplex considerato. Attenendoci a criteri di concisione per l’elaborato, si `e preferito omettere i risultati relativi ai collegamenti non interessati dai flussi in esame. Ciascun grafico riporta 3 andamenti sovrapposti, corrispondenti alle metriche illustrate nel paragrafo 5.5: BF, NE e WF.
Le figure A.2, A.3, A.6 e A.8 mostrano come il primo flusso venga inoltrato sul percorso s13 → s5 → s1 → s7 → s15, mentre le figure A.4, A.5, A.7 e A.9 evidenziano che il secondo flusso attraversa la sequenza di switch s13 → s6 → s3 → s8 → s15.
Si osservi come l’esito dell’esperimento non dipenda dalla particolare fun- zione costo utilizzata. Un tale comportamento `e senz’altro ascrivibile alla semplicit`a del test medesimo.
Banda (Mbit/s) Host sorgente Host destinatario
Flusso 1 6 h1 h5
Flusso 2 2 h2 h6
Tabella A.1: Caratteristiche relative ai flussi di traffico generati per verificare la correttezza della funzionalit`a di LB (Data Center)
s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14 s15 s16 s17 s18 s19 s20 h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 h11 h12 h13 h14 h15 h16 Flusso 1 Flusso 2
Load Balancing: corretto funzionamento – Data Center 147 10 20 30 40 50 60 70 80 90 100 0 1 2 3 4 5 6 7 Tempo (s) Banda (Mbit/s) BF WF NE
Figura A.2: LB: link s1 − s5
10 20 30 40 50 60 70 80 90 100 0 1 2 3 4 5 6 7 Tempo (s) Banda (Mbit/s) BF WF NE
10 20 30 40 50 60 70 80 90 100 0 0.5 1 1.5 2 2.5 Tempo (s) Banda (Mbit/s) BF WF NE
Figura A.4: LB: link s3 − s6
10 20 30 40 50 60 70 80 90 100 0 0.5 1 1.5 2 2.5 Tempo (s) Banda (Mbit/s) BF WF NE
Load Balancing: corretto funzionamento – Data Center 149 10 20 30 40 50 60 70 80 90 100 0 1 2 3 4 5 6 7 Tempo (s) Banda (Mbit/s) BF WF NE
Figura A.6: LB: link s5 − s13
10 20 30 40 50 60 70 80 90 100 0 0.5 1 1.5 2 2.5 Tempo (s) Banda (Mbit/s) BF WF NE
10 20 30 40 50 60 70 80 90 100 0 1 2 3 4 5 6 7 Tempo (s) Banda (Mbit/s) BF WF NE
Figura A.8: LB: link s7 − s15
10 20 30 40 50 60 70 80 90 100 0 0.5 1 1.5 2 2.5 Tempo (s) Banda (Mbit/s) BF WF NE
Appendice B
Traffic Recovery: corretto
funzionamento – Data
Center
In quest’appendice vengono riportati i grafici relativi agli esperimenti condotti per verificare la validit`a della funzionalit`a di TR, relativamente alla topologia illustrata nel paragrafo 6.2.
I grafici proposti riportano il carico complessivamente sperimentato da alcu- ni link della topologia, in funzione del tempo. `E stata cio`e effettuata una somma tra le bande relative alle 2 direzioni Simplex del collegamento Full Duplex consi- derato. Attenendoci a criteri di concisione per l’elaborato, si `e preferito omettere i risultati corrispondenti ai collegamenti non interessati dai flussi emulati.