Progetto, realizzazione e validazione sperimentale di un'applicazione SDN per Traffic Recovery e Load Balancing

(1)

Universit`a di Pisa

Corso di Laurea Magistrale in Ingegneria delle Telecomunicazioni Dipartimento di Ingegneria dell’Informazione

Progetto, realizzazione e

validazione sperimentale di

un’applicazione SDN per

Traﬃc Recovery e Load Balancing

Candidato: Nicola Santinelli Relatori:

Prof. Stefano Giordano Prof. Michele Pagano Ing. Davide Adami

Sessione di Laurea del 28/04/2014 Anno Accademico 2012/2013

(2)

(3)

Riassunto analitico

Nel corso degli ultimi anni, la comunità scientifica si è prodigata nell’esplorazione delle potenzialità fornite dal Software-Defined Networking, un paradigma che prevede la netta separazione tra piano dati e piano di controllo all’interno di una rete. Cos`ı facendo, il comportamento dei dispositivi risulta programmabile tramite un’applicazione di controllo.

In questo contesto, il presente elaborato documenta il lavoro di tesi intrapreso per progettare, realizzare e validare una tale applicazione avente funzionalità di Traffic Recovery e Load Balancing. Le stime riguardanti l’utilizzazione dei collegamenti e la banda occupata dai vari flussi, cos`ı come la rivelazione dei malfunzionamenti, sono state gestite sfruttando le peculiarità del protocollo OpenFlow.

L’aspetto relativo alla Traffic Recovery è stato affrontato con strategie sia reattive che proattive. In particolare, il traffico generato dalle sorgenti può essere suddiviso in quattro classi, caratterizzate da un livello di protezione via via cre-scente. Riguardo alla funzionalità di Load Balancing, sono state adottate e con-frontate tre possibili metriche per l’assegnazione dei costi ai vari collegamenti, in funzione del carico da essi sperimentato.

Parole chiave: Software-Deﬁned Networking, OpenFlow, Traﬃc Recovery, Protection, Restoration, Load Balancing.

(4)

(5)

Abstract

During the last years, Software-Deﬁned Networking (SDN) has been widely explored in order to understand the possibilities provided by this kind of ar-chitecture. Introducing a clean separation between the control plane and the data plane within the network, SDN allows a control application to program the behavior of the underlying infrastructure.

This thesis deals with designing, fulfilling and validating such an application with Traffic Recovery and Load Balancing tasks. The features of the OpenFlow protocol have been exploited in order to provide an estimate of links utilization and flows bandwidth, as well as to effectively detect link failures.

Traffic Recovery has been handled adopting both reactive and proactive strategies. More precisely, network traffic can be grouped into four classes with an increasing level of protection. With respect to Load Balancing, three alter-native ways of assigning a cost to a certain link, as a function of its load, have been defined and compared.

Keywords: Software-Deﬁned Networking, OpenFlow, Traﬃc Recovery, Pro-tection, Restoration, Load Balancing.

(6)

(7)

Indice

1 Introduzione 1 2 Software-Defined Networking 5 2.1 Necessità di cambiamento . . . 5 2.1.1 Nuovi servizi . . . 5 2.1.2 Vecchie infrastrutture . . . 6 2.2 Definizione di SDN . . . 7 2.3 Architettura stratificata . . . 8 2.4 Benefici introdotti da SDN . . . 10

2.5 Organizzazioni operanti in ambito SDN . . . 11

2.5.1 Open Networking Foundation . . . 11

2.5.2 Linux Foundation . . . 12

2.5.3 Internet Engineering Task Force . . . 12

3 OpenFlow 15 3.1 Proposta del mondo accademico . . . 16

3.2 Standard: OpenFlow 1.0.0 . . . 17

3.2.1 Flow-table . . . 17

3.2.2 Secure channel . . . 22

3.2.3 Panoramica sul protocollo . . . 22

3.2.4 Modiﬁca della ﬂow-table . . . 23

3.3 Questioni ancora aperte . . . 24

4 Ambiente di sviluppo 27 4.1 Dispositivi di rete virtuali: Mininet . . . 27

4.1.1 Mininet, in sintesi . . . 28

4.1.2 Vantaggi derivanti dall’utilizzo di Mininet . . . 28

4.1.3 Svantaggi derivanti dall’utilizzo di Mininet . . . 29

4.1.4 Dettagli implementativi . . . 29

4.2 Piattaforma di controllo: POX . . . 30

4.2.1 Confronto tra alcune delle pi`u popolari piattaforme per lo sviluppo di applicazioni di controllo in ambito SDN . . . 31

(8)

viii Indice

5 Applicazione di controllo 39

5.1 Modulo LLDP . . . 41

5.1.1 Presentazione del componente . . . 41

5.1.2 Analisi del codice . . . 41

5.2 Modulo ARP . . . 43

5.3 Modulo statistiche . . . 49

5.4 Modulo ICMP . . . 54

5.5 Modulo PCE . . . 55

5.5.2 Programmazione Lineare su reti . . . 55

5.5.3 Rappresentazione di reti reali (o virtuali) tramite graﬁ . . 58

5.5.4 Funzionamento background . . . 60

5.5.5 Tipologie di ﬂusso . . . 70

5.5.6 Installazione dei percorsi: Load Balancing . . . 72

5.5.7 Reagire ad un malfunzionamento: Traﬃc Recovery . . . . 77

5.6 Lancio dell’applicazione . . . 81

6 Topologie 83 6.1 Primo scenario: dominio di routing . . . 84

6.2 Secondo scenario: Data Center . . . 84

6.3 Generatore di topologie casuali . . . 86

6.3.1 Due sommatorie notevoli . . . 86

6.3.2 Numero medio di switch generati . . . 86

6.3.3 Numero medio di link (da switch a switch) generati . . . 87

6.3.4 Numero medio di host generati . . . 89

6.3.5 Parametri utilizzati . . . 91

7 Esperimenti condotti sull’architettura realizzata 93 7.1 Load Balancing: corretto funzionamento – Dominio di routing . . 93

7.2 Traﬃc Recovery: corretto funzionamento – Dominio di routing . 99 7.2.1 Restoration . . . 99

7.2.2 Protection . . . 106

7.3 Load Balancing e Fixed Cost: confronti prestazionali – Dominio di routing . . . 114

7.3.1 Modello di sorgente . . . 114

7.3.2 Flussi UDP . . . 117

7.3.3 Flussi TCP . . . 127

7.4 Time To Detect e Time To Repair . . . 135

8 Conclusioni 143

(9)

Indice ix B Traﬃc Recovery: corretto funzionamento – Data Center 151

B.1 Restoration . . . 151

B.2 Protection . . . 159

C Load Balancing e Fixed Cost: confronti prestazionali – Data Center 169 C.1 Flussi UDP . . . 171 C.2 Flussi TCP . . . 176 D Codice 181 D.1 Algoritmo di Dijkstra . . . 181 D.2 Modulo ARP . . . 183 D.3 Modulo statistiche . . . 188 D.4 Modulo ICMP . . . 193 D.5 Modulo PCE . . . 195 Bibliograﬁa 215

(10)

(11)

Elenco delle ﬁgure

2.1 Architettura SDN . . . 9

3.1 Schema logico di uno switch OpenFlow . . . 17

3.2 Elaborazione dei pacchetti da parte di uno switch OpenFlow . . 21

4.1 Lightweight virtualization . . . 30

4.2 POX e NOX, confronti prestazionali . . . 33

5.1 Struttura modulare dell’applicazione di controllo implementata . 39 5.2 Gestione di un’ARP Request da parte di myARPModule.py . . . . 46

5.3 Gestione di un’ARP Reply da parte di myARPModule.py . . . 48

5.4 Rappresentazione graﬁca della relazione (5.4) . . . 50

5.5 Filtraggio passa-basso (smoothing) dovuto al procedimento se-guito per il calcolo della banda . . . 51

5.6 Stima del carico sperimentato da una porta appartenente ad uno switch OpenFlow . . . 53

5.7 Rappresentazione graﬁca dell’arco (i, j) . . . 56

5.8 Equivalenza tra un collegamento Full Duplex ed una coppia di collegamenti Simplex . . . 60

5.9 Rappresentazione di una rete reale (o virtuale) tramite un grafo . 61 5.10 Costo associato ad un collegamento in funzione della sua utiliz-zazione (X = 3, Y = 1) . . . 67

5.11 Relazione temporale tra la ﬁne di un ﬂusso e la ricezione delle prossime statistiche . . . 74

5.12 Elaborazione di un pacchetto IP da parte di myPCEModule.py . . 76

5.13 Ribaltamento delle metriche BF, NE e WF rispetto all’asse delle utilizzazioni (X = 3, Y = 1) . . . 79

5.14 Operazioni eseguite per ogni ﬂusso inoltrato su un collegamento interessato dal guasto . . . 80

6.1 Dominio di routing . . . 84

6.2 Data Center (fat-tree di ordine k = 4) . . . 85

7.1 LB: dominio di routing . . . 94

(12)

xii Elenco delle ﬁgure 7.3 LB: link s1− s3 . . . 95 7.4 LB: link s1_{− s4 . . . 96} 7.5 LB: link s2_{− s5 . . . 96} 7.6 LB: link s3_{− s7 . . . 97} 7.7 LB: link s4_{− s6 . . . 97} 7.8 LB: link s5_{− s7 . . . 98} 7.9 LB: link s6_{− s7 . . . 98}

7.10 TR: dominio di routing (Restoration) . . . 100

7.11 TR: link s1_{− s2 (Restoration) . . . 102} 7.12 TR: link s1_{− s3 (Restoration) . . . 102} 7.13 TR: link s1− s4 (Restoration) . . . 103 7.14 TR: link s2− s5 (Restoration) . . . 103 7.15 TR: link s3− s7 (Restoration) . . . 104 7.16 TR: link s4− s6 (Restoration) . . . 104 7.17 TR: link s5− s7 (Restoration) . . . 105 7.18 TR: link s6− s7 (Restoration) . . . 105

7.19 TR: dominio di routing (Protection) . . . 110

7.20 TR: link s1_{− s2 (Protection) . . . 111}

7.25 Modello di sorgente ON/OFF . . . 115

7.26 Distribuzione di Pareto . . . 116

7.27 LB vs. FC: link s1_{− s2 (ﬂussi UDP, R ∈ U [0.064, 2] Mbit/s) . . 119}

7.28 LB vs. FC: link s1− s3 (ﬂussi UDP, R ∈ U [0.064, 2] Mbit/s) . . 119

7.38 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi UDP, R_∈ U [0.064, 2] Mbit/s) . . . 125

7.39 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi UDP, R_∈ U [0.8, 3.2] Mbit/s) . . . 126

7.40 LB vs. FC: link s1_{− s2 (ﬂussi TCP, seme 2017) . . . 127}

7.41 LB vs. FC: link s1− s3 (ﬂussi TCP, seme 2017) . . . 128

(13)

Elenco delle ﬁgure xiii

7.50 LB vs. FC: link s6_{− s7 (ﬂussi TCP, seme 2017) . . . 132}

7.51 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi TCP, seme 2017) . . . 133

7.52 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi TCP, seme 2016) . . . 134

7.53 Time To Detect . . . 139

7.54 Time To Repair . . . 140

7.55 Mean Time To Detect . . . 141

7.56 Mean Time To Repair . . . 141

A.1 LB: Data Center . . . 146

A.2 LB: link s1_{− s5 . . . 147} A.3 LB: link s1_{− s7 . . . 147} A.4 LB: link s3_{− s6 . . . 148} A.5 LB: link s3− s8 . . . 148 A.6 LB: link s5− s13 . . . 149 A.7 LB: link s6_{− s13 . . . 149} A.8 LB: link s7_{− s15 . . . 150} A.9 LB: link s8_{− s15 . . . 150}

B.1 TR: Data Center (Restoration) . . . 153

B.2 TR: link s1− s5 (Restoration) . . . 154 B.3 TR: link s1− s7 (Restoration) . . . 155 B.4 TR: link s3_{− s6 (Restoration) . . . 155} B.5 TR: link s3_{− s8 (Restoration) . . . 156} B.6 TR: link s4_{− s6 (Restoration) . . . 156} B.7 TR: link s4_{− s8 (Restoration) . . . 157} B.8 TR: link s5− s13 (Restoration) . . . 157 B.9 TR: link s6− s13 (Restoration) . . . 158 B.10 TR: link s7− s15 (Restoration) . . . 158 B.11 TR: link s8_{− s15 (Restoration) . . . 159}

B.12 TR: Data Center (Protection) . . . 163

B.13 TR: link s1_{− s5 (Protection) . . . 165} B.14 TR: link s1− s7 (Protection) . . . 165 B.15 TR: link s3− s6 (Protection) . . . 166 B.16 TR: link s3− s8 (Protection) . . . 166 B.17 TR: link s5_{− s13 (Protection) . . . 167} B.18 TR: link s6_{− s13 (Protection) . . . 167} B.19 TR: link s7_{− s15 (Protection) . . . 168} B.20 TR: link s8_{− s15 (Protection) . . . 168}

C.1 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi UDP, R∈ U [0.064, 2] Mbit/s) . . . 172

(14)

xiv Elenco delle ﬁgure C.2 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi UDP, R∈

U [0.8, 5.2] Mbit/s) . . . 174 C.3 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi TCP, seme

2017) . . . 177 C.4 LB vs. FC: utilizzazioni medie dei collegamenti (ﬂussi TCP, seme

(15)

Elenco delle tabelle

3.1 Struttura generale di una regola presente all’interno della tabella di uno switch OpenFlow . . . 18 3.2 Campi utilizzabili in una regola OpenFlow per speciﬁcare un ﬂusso 18 3.3 Tipologie di contatore obbligatoriamente implementate da uno

switch OpenFlow . . . 20 4.1 Confronto sintetico tra alcune delle piattaforme che presentano

una connotazione southbound . . . 31 4.2 Principali attributi caratterizzanti un evento sollevato da of 01 . 37 5.1 Tassonomia delle configurazioni di linea . . . 59 5.2 Strategie di TR adottate per le diverse tipologie di flusso . . . . 70 5.3 Corrispondenze tra tipo di flusso e valore assunto dal campo

cookiedi una regola OpenFlow . . . 74 7.1 Caratteristiche relative ai flussi di traffico generati per verificare

la correttezza della funzionalità di LB (dominio di routing) . . . 94 7.2 Caratteristiche relative ai flussi di traffico generati per verificare

la correttezza della funzionalità di Restoration (dominio di routing) 99 7.3 Caratteristiche relative al flusso di traffico generato per verificare

la correttezza della funzionalit`a di Protection (dominio di routing)106 7.4 LB vs. FC: Percentuale di perdita media sperimentata durante

una connessione (ﬂussi UDP) . . . 124 7.5 LB vs. FC: rate medio sperimentato durante una connessione

(flussi TCP) . . . 135 7.6 Caratteristiche relative ai flussi di traffico generati per

quantifi-care TTD e TTR . . . 135 7.7 MTTD e MTTR complessivi . . . 138 A.1 Caratteristiche relative ai flussi di traffico generati per verificare

la correttezza della funzionalità di LB (Data Center) . . . 146 B.1 Caratteristiche relative ai flussi di traffico generati per verificare

(16)

xvi Elenco delle tabelle B.2 Caratteristiche relative al flusso di traffico generato per verificare

la correttezza della funzionalit`a di Protection (Data Center) . . . 159 C.1 Legenda relativa alle lettere utilizzate nei graﬁci dell’appendice

C per indicare i collegamenti della rete di ﬁgura 6.2 . . . 170 C.2 LB vs. FC: percentuale di perdita media sperimentata durante

una connessione (ﬂussi UDP) . . . 176 C.3 LB vs. FC: rate medio sperimentato durante una connessione

(17)

Capitolo 1

Introduzione

Nel corso degli ultimi anni, la comunità scientifica si è prodigata nell’esplorazione delle potenzialità fornite dal Software-Defined Networking (SDN), un paradigma che prevede la netta separazione tra piano dati e piano di controllo all’interno di una rete (paragrafo 2.2). Cos`ı facendo, il comportamento dei dispositivi risulta non soltanto configurabile ma anche programmabile da remoto, tramite un’applicazione di controllo.

In questo contesto, il presente elaborato documenta il lavoro di tesi intrapreso per progettare, realizzare e validare una tale applicazione avente funzionalit`a di Load Balancing e Traﬃc Recovery.

Load Balancing Il fine ultimo di una strategia di tipo Load Balancing (LB) è, letteralmente, quello di ottenere un “bilanciamento del carico” sperimentato all’interno dell’infrastruttura. Da un punto di vista pratico, ciò che si ten-ta di fare è distribuire equamente il traffico generato dagli host della rete su, potenzialmente, tutti i collegamenti (links) di cui si dispone. Il problema con-siste dunque nel determinare, di volta in volta, il percorso1 _{migliore sul quale}

inoltrare i pacchetti appartenenti ad un certo ﬂusso2_.

Nel mondo delle reti tradizionali, tale problematica è nota con il termine di routing e la sua risoluzione è affidata a protocolli distribuiti, denominati Interior Gateway Protocols (IGP). Tra i più popolari IGP attualmente in circolazione si ricordano RIP, OSPF ed IS-IS. A meno di configurazioni particolari, detti protocolli intendono la bontà di un percorso come una proprietà nota a priori, specificata cioè una volta per tutte dall’amministratore della rete oppure deter-minata autonomamente dall’IGP considerato, del tutto slegata dalle particolari

1_{Un “percorso” (path) `}_{e caratterizzato da un router (switch) d’ingresso, da un router}

(switch) di uscita e da un insieme di router (switch) e link intermedi, sui quali vengono inoltrati i pacchetti appartenenti ad un ﬂusso.

2_{Con il termine “ﬂusso” (ﬂow ) s’intende una successione di pacchetti accomunati dai valori}

assunti da un insieme di campi presenti nelle intestazioni dei pacchetti stessi, delle trame che li contengono o dei segmenti in essi contenuti.

(18)

2 Capitolo 1 condizioni nelle quali versa l’infrastruttura. Tale approccio, per quanto semplice ed intuitivo, potrebbe risultare non appropriato.

Si supponga, ad esempio, di disporre di due sottoreti separate da un “dominio di routing”, ovvero da un insieme di router (se si tratta di una rete tradizionale) o di switch (nel caso di rete SDN) arbitrariamente connessi3_{(paragrafo 6.1). In}

uno scenario di questo tipo, la pratica di cui sopra porterebbe all’utilizzazione di due soli percorsi tra tutti quelli possibili, peraltro costituiti dallo stesso insieme di collegamenti da attraversare in entrambe le direzioni4_{. Chiaramente, non `e}

possibile parlare di LB.

Un’eventualità come quella appena descritta risulta sconveniente, quanto-meno da due punti di vista. In prima battuta, un operatore che abbia investito consistenti somme di denaro per mettere in campo la propria infrastruttura non sarà sicuramente disposto a vederla, per larga parte, inutilizzata. Seconda-riamente, anche ammesso di poter trascurare gli aspetti economici riguardanti la gestione della propria rete, permane un problema dal punto di vista delle prestazioni. Al crescere del numero di flussi simultaneamente attivi, infatti, au-menta il livello di congestione dei pochi link servibili. A causa della mancanza di “strade” alternative, grazie alle quali sarebbe possibile alleggerire il carico da essi sperimentato, ciò si traduce inevitabilmente in:

• un incremento delle percentuali di perdita;

• una riduzione della banda5_{ottenibile da ciascun ﬂusso.}

Per avvicinarsi maggiormente ad una spartizione equa del traffico generato all’interno della rete, si potrebbe pensare d’intendere la bontà di un percorso come una proprietà variabile nel tempo, dipendente cioè dall’attuale livello di congestione sperimentato dai link che lo costituiscono. Nel capitolo 5 verrà illustrato come l’applicazione implementata sia in grado di raggiungere un tale obiettivo. Per adesso, ci preme solamente enfatizzare i due aspetti cardine della strategia impiegata:

1. stima in tempo reale dell’utilizzazione di ogni collegamento all’interno della rete;

2. deﬁnizione di una metrica che mappi il livello di utilizzazione stimato in un nuovo valore, avente il signiﬁcato di costo del collegamento.

Il primo punto è stato gestito sfruttando le peculiarità del protocollo OpenFlow, il quale costituisce la più diffusa tra le interfacce utilizzabili dal piano di con-trollo per comunicare con i dispositivi di rete. Riguardo al secondo, sono state adottate e confrontate tre metriche alternative per l’assegnazione dei costi ai vari collegamenti, in funzione del carico da essi sperimentato.

3_{In realt`}_{a, si richiede che per ogni coppia di router (switch) della rete esista almeno un}

percorso in grado di connetterli.

4_{Stiamo supponendo che i link siano bidirezionali.}

5_{Una precisazione `}_{e d’obbligo: nel seguito, il termine “banda” sar`}_{a sempre inteso come}

rate, adottando la prassi valida nel mondo delle reti di telecomunicazioni. Dimensionalmente, dunque, la banda verr`a espressa in ‘bit/s’ (o in unit`a di misura equivalenti, quali ‘byte/s’ e ‘pacchetti/s’).

(19)

Introduzione 3 Traffic Recovery La terminologia utilizzata in questo e nei restanti capitoli, relativamente a tali problematiche, trae ispirazione da quella impiegata in [39]. La funzionalità di Traffic Recovery (TR) consiste essenzialmente nella capa-cità di reagire ad un malfunzionamento che colpisce un percorso attivo. Tale reazione si manifesta attraverso l’attivazione di un nuovo percorso, alternati-vo al primo. Ai fini della comprensione di ciò che verrà esposto nel seguito, è bene sottolineare come il calcolo di un percorso e la sua attivazione siano due operazioni non necessariamente concomitanti.

Come risulterà chiaro dalla lettura del presente elaborato, in condizioni di funzionamento ordinario, il primo pacchetto di un nuovo flusso verrà recapitato al piano di controllo, il quale, secondo un proprio algoritmo (paragrafo 5.5), deciderà quale percorso debbano seguire i pacchetti corrispondenti e provvederà ad istruire coerentemente gli switch interessati. Un percorso di questo tipo viene indicato come “percorso working” (Working Path, WP) per il flusso in esame. Supponiamo che un guasto colpisca uno (o più di uno) dei link costituenti il WP, ovvero che quest’ultimo risulti inutilizzabile. Per mantenere integra la comunicazione ent-to-end in tali circostanze, si rende necessario inoltrare il traffico su un nuovo percorso, chiamato anche “percorso recovery” (Recovery Path, RP) per il flusso in esame. Riassumendo: un WP trasporta traffico utente in condizioni “normali”; un RP trasporta traffico utente quando il relativo WP si guasta. E importante precisare come uno stesso percorso possa risultare` “working” per un certo flusso e, allo stesso tempo, “recovery” per un altro. Quest’ultimo aspetto differenzia le tecniche di TR adottate in questo lavoro da quelle tipicamente impiegate nelle reti ottiche di trasporto.

Il concetto di TR può essere scisso ulteriormente in Protection e Restoration. La differenza tra le due sfaccettature è legata al tipo di allocazione delle risorse portata avanti durante l’attivazione del RP. Nel caso in cui venga adottato un approccio di tipo Protection, il calcolo del RP viene effettuato contestualmente al calcolo del WP. Si tratta cioè di una strategia “proattiva” (proactive) o “pre-ventiva”. Si osservi come, in questo caso, WP e RP debbano risultare “disgiunti nei link” (link disjoint), in modo da assicurare che un singolo guasto non vada a compromettere il funzionamento di entrambi. Qualora, invece, la scelta ricades-se su un approccio di tipo Restoration, il calcolo del RP avverrebbe solamente in corrispondenza di un malfunzionamento interessante il relativo WP. Siamo cioè di fronte ad una strategia “reattiva” (reactive).

In questo lavoro di tesi, abbiamo scelto di consentire la suddivisione del traffico generato dalle sorgenti in quattro classi, caratterizzate da un livello di protezione via via crescente. Per i flussi appartenenti alla classe “meno priori-taria”, la tecnica di TR adottata è quella della Restoration. Il traffico generato dalle successive, invece, gode di una strategia di tipo Protection. Per quei flussi definiti dall’operatore come particolarmente “sensibili”, infine, è prevista una variante di Protection ancora più robusta di quella già menzionata. I pacchet-ti appartenenpacchet-ti a detpacchet-ti flussi, infatpacchet-ti, vengono inoltrapacchet-ti contemporaneamente su due percorsi disgiunti, ciascuno dei quali può essere inteso come WP.

(20)

4 Capitolo 1 Struttura dell’elaborato Il resto del documento è organizzato come segue. Nel capitolo 2 viene fornita la definizione formale di Software-Defined Networ-king e la descrizione della relativa architettura stratificata. In aggiunta, sono citate le motivazioni che ne hanno spinto l’adozione da parte della comunità scientifica, i principali benefici derivanti dal suo utilizzo ed una sintesi delle iniziative intraprese da alcune tra le organizzazioni più attive in questo ambito. Il capitolo 3 tratta approfonditamente del protocollo OpenFlow ed in parti-colare della specifica 1.0.0. Vengono inoltre passate in rassegna alcune proble-matiche caratterizzanti le architetture SDN che sfruttano tale protocollo.

Nel capitolo 4 sono raccolti alcuni cenni sull’emulatore Mininet e sulla piat-taforma di controllo POX. Grazie al primo `e stato possibile generare le topologie di rete considerate, mentre le API6_{del secondo hanno consentito la scrittura}

del-l’applicazione di controllo, oggetto di questo lavoro di tesi. Detta applicazione viene esaminata nel dettaglio all’interno del capitolo 5 ed il codice corrispondente pu`o essere recuperato consultando l’appendice D.

Il capitolo 6 passa in rassegna le topologie di rete impiegate all’interno de-gli esperimenti condotti sull’architettura implementata. La descrizione di detti esperimenti e la raccolta dei risultati corrispondenti, espressi principalmente sot-to forma di graﬁci, sono aﬃdate congiuntamente al capisot-tolo 7 ed alle appendici A, B e C.

Inﬁne, il capitolo 8 conclude l’elaborato.

6_{Un’Application Programming Interface (API) speciﬁca come alcuni componenti software}

debbano interagire gli uni con gli altri. In pratica, un’API viene frequentemente espressa sotto forma di libreria. Al suo interno si possono trovare le speciﬁche di metodi, strutture dati, classi e variabili.

(21)

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à 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 metpor-te a disposizione. A patto di giungere ad una rappresentazione astratta dell’infrastruttura sotto forma di grafo, tramite tali informazioni è 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à di utilizzare tre diverse tipologie di metrica, le quali si differenziano per la velocità 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 è in grado di otte-nere rate trasmissivi mediamente superiori, se confrontati con quelli ottenibili optando per un criterio di tipo Fixed Cost.

La funzionalità di Traffic Recovery viene, a sua volta, implementata sfrut-tando le peculiarità 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 è 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 è quella della Resto-ration. Ciò significa che un eventuale Recovery Path viene calcolato solamente a guasto avvenuto. Esso può coincidere sia con il percorso meno congestiona-to che con quello maggiormente congestionacongestiona-to disponibile al momencongestiona-to, ma pur

(22)

144 Capitolo 8 sempre dotato di banda residua sufficiente ad accogliere il nuovo flusso. La tecnica di recovery riservata alle classi di traffico successive, invece, è 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à 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é 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 è in media superiore rispetto a quello sperimentato da un flusso Silver, a causa del maggior numero di operazioni richieste per attuare la funzionalità 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 è 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 è mediamente rispettato.

Inﬁne, 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 Traﬃc Recovery”, candidato ad essere pubblicato negli IEEE GLOBECOM 2014 Proceedings.