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

Traffic 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`a 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`a 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-Defined Networking, OpenFlow, Traffic Recovery, Protection, Restoration, Load Balancing.

(4)

(5)

Abstract

During the last years, Software-Defined 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-Defined Networking, OpenFlow, Traffic Recovery, Pro-tection, Restoration, Load Balancing.

(6)

(7)

Indice

1 Introduzione 1 2 Software-Defined Networking 5 2.1 Necessit`a 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 Modifica della flow-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)

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 grafi . . 58

5.5.4 Funzionamento background . . . 60

5.5.5 Tipologie di flusso . . . 70

5.5.6 Installazione dei percorsi: Load Balancing . . . 72

5.5.7 Reagire ad un malfunzionamento: Traffic 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 Traffic 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 Traffic 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 Bibliografia 215

(10)

(11)

Elenco delle figure

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 grafica 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 grafica 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 fine di un flusso 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 flusso 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)

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 (flussi UDP, R ∈ U [0.064, 2] Mbit/s) . . 119

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

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

7.40 LB vs. FC: link s1 − s2 (flussi TCP, seme 2017) . . . 127

(13)

Elenco delle figure xiii

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

7.52 LB vs. FC: utilizzazioni medie dei collegamenti (flussi 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 (flussi UDP, R ∈ U [0.064, 2] Mbit/s) . . . 172

(14)

C.2 LB vs. FC: utilizzazioni medie dei collegamenti (flussi UDP, R ∈ U [0.8, 5.2] Mbit/s) . . . 174 C.3 LB vs. FC: utilizzazioni medie dei collegamenti (flussi TCP, seme

2017) . . . 177 C.4 LB vs. FC: utilizzazioni medie dei collegamenti (flussi 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 specificare un flusso 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

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

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

la correttezza della funzionalit`a 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 (flussi 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`a di LB (Data Center) . . . 146 B.1 Caratteristiche relative ai flussi di traffico generati per verificare

(16)

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 grafici dell’appendice

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

una connessione (flussi 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 Traffic Recovery.

Load Balancing Il fine ultimo di una strategia di tipo Load Balancing (LB) `

e, letteralmente, quello di ottenere un “bilanciamento del carico” sperimentato all’interno dell’infrastruttura. Da un punto di vista pratico, ci`o che si ten-ta di fare `e 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 flusso2_.

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 flusso.

2_{Con il termine “flusso” (flow ) 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)

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 flusso.}

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. definizione di una metrica che mappi il livello di utilizzazione stimato in un nuovo valore, avente il significato 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)

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 API6del 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 grafici, sono affidate congiuntamente al capisot-tolo 7 ed alle appendici A, B e C.

Infine, il capitolo 8 conclude l’elaborato.

6_{Un’Application Programming Interface (API) specifica 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 specifiche di metodi, strutture dati, classi e variabili.

(21)

Capitolo 2

Software-Defined

Networking

In questo capitolo, viene fornita la definizione formale di Software-Defined Net-working, assieme alla descrizione della relativa architettura stratificata. In ag-giunta, sono citate le motivazioni che ne hanno spinto l’adozione da parte della comunit`a scientifica, i principali benefici derivanti dal suo utilizzo ed una sintesi delle iniziative intraprese da alcune tra le organizzazioni pi`u attive in questo ambito.

2.1 Necessit`

a di cambiamento

Nonstante il mondo dell’Information Technology (IT) abbia compiuto passi da gigante negli ultimi decenni, l’approccio alle problematiche di networking è ri-masto sostanzialmente invariato. Pur rappresentando il punto cruciale di molte infrastrutture della società contemporanea, le reti sono diventate complesse, chiuse e dominate da logiche proprietarie. Come risultato, operatori, ricercatori e produttori stessi si trovano nella sostanziale impossibilità di testare, e talvolta perfino concepire, nuove idee e soluzioni.

2.1.1 Nuovi servizi

La staticit`a delle architetture di rete convenzionali si pone in forte contrapposi-zione rispetto alle dinamiche esigenze di calcolo e di archiviacontrapposi-zione sollevate dai moderni Data Center (DC), dai campus universitari o dai fornitori di connet-tivit`a. Alcuni tra i principali catalizzatori della spinta verso l’adozione di un nuovo paradigma di networking sono stati i seguenti.

• Cambiamento dei modelli di traffico. Contrariamente a quanto av-viene con le classiche applicazioni client-server, dove il cuore di una con-nessione si sviluppa esclusivamente tra due attori – uno che necessita di

(22)

una prestazione (client ) e l’altro che `e in grado di fornirla (server ) – le applicazioni odierne accedono a database distribuiti su scala geografica, generando una mole consistente di traffico da macchina a macchina (dire-zione “est-ovest”), prima che possa avvenire la consegna vera e propria del contenuto all’utente che ne aveva fatto richiesta (direzione “nord-sud”). • IT come fenomeno di massa. L’esplosione di dispositivi quali

smart-phone, tablet e notebook, utilizzabili non solo per lo scambio di messaggi vocali, ma anche per la navigazione Web, per l’esecuzione di applicazioni locali e remote accessibili via rete e per la videoconferenza su piattafor-me sociali, ha comportato un aupiattafor-mento vertiginoso del volupiattafor-me di traffico rispetto ai decenni precedenti.

• Diffusione dei servizi di Cloud Computing. Con l’avvento del Cloud Computing, gli utenti odierni (privati o aziendali) si aspettano di accedere on-demand ad applicazioni, infrastrutture ed altre risorse IT. Una forni-tura di servizi di tipo self-service come questa necessita di un dimensio-namento eccezionalmente elastico delle risorse di calcolo, di archiviazione e di rete.

• Mole crescente di dati. La gestione degli odierni mega-dataset1 richie-de un massiccio ricorso all’elaborazione parallela da parte di migliaia di server, ciascuno dei quali necessita di essere direttamente connesso con gli altri tramite una topologia a maglia completa. Tutto questo va ad alimentare una costante ricerca di banda addizionale all’interno della rete.

2.1.2 Vecchie infrastrutture

Soddisfare i requisiti di mercato correnti `e praticamente impossibile con le architetture di rete tradizionali. Tra le principali limitazioni incontrate dai progettisti, le seguenti sono sicuramente degne di nota.

• Complessità. Se da un lato l’elevato numero di protocolli ha consen-tito la sopravvivenza delle infrastrutture di rete attualmente sul campo, dall’altro le ha condannate ad essere caratterizzate da uno straordinario livello di complessità. La definizione di tali protocolli, infatti, è avvenuta nel più completo isolamento ed in assenza del necessario livello di astrazio-ne. Perfino la semplice aggiunta o rimozione di un dispositivo coinvolge la modifica e l’aggiornamento manuali di file di configurazione, ACL, VLAN, policy di QoS sparse tra una moltitudine di switch, router, firewall e por-tali Web. La complessità ha, a sua volta, condotto all’immobilismo. Gli operatori rifuggono il cambiamento, visto che le configurazioni manuali richieste potrebbero portare all’inconsistenza tra gli stati della rete ed al-la conseguente interruzione del servizio. Questa natura statica si pone in netto contrasto con l’ambiete dinamico dei server odierni, nei quali le

1_{In informatica, un dataset `}_{e la rappresentazione in memoria volatile di un insieme di dati} strutturati in forma relazionale.

(23)

Software-Defined Networking 7

moderne tecnologie di virtualizzazione hanno portato ad un significativo incremento nel numero di host che richiedono connettivit`a e messo in crisi le assunzioni sulla loro posizione.

• Scalabilità. Grazie alle informazioni a priori possedute sui modelli di traffico generato dalle applicazioni, un classico approccio finora adottato per consentire ad un DC di scalare al crescere della domanda di risorse è stato l’oversubscription. Tuttavia, la dinamicità del traffico odierno, e dunque la sua sostanziale impredicibilità, ha reso una soluzione di questo tipo impraticabile.

• Dipendenza dai produttori. Le aziende cercano di sviluppare nuove funzionalit`a e servizi innovativi per rispondere tempestivamente a cambia-menti nelle richieste dei clienti o nei bisogni del proprio business. Purtrop-po, tale aspirazione risulta soffocata dai cicli produttivi dei vendor, che possono talvolta coprire periodi di anni. La mancanza d’interfacce aperte e standardizzate limita considerevolmente la capacit`a degli operatori di “cucire su misura” la propria rete a seconda delle esigenze.

Il disallineamento tra le richieste di mercato e le funzionalità offerte dalle reti attuali ha portato l’industria delle telecomunicazioni ad un punto di non ritorno. Si è giunti perciò alla definizione dell’architettura Software-Defined Networking e, congiuntamente, alla standardizzazione dei protocolli ad essa associati.

2.2 Definizione di SDN

OpenDaylight [13]:

Software Defined Networking (SDN) separates the control plane from the data plane within the network, allowing the intelligence and state of the network to be managed centrally while abstracting the complexity of the underlying physical network.

Open Networking Foundation [4]:

This architecture decouples the network control and forwarding functions en-abling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services.

SDNCentral [3]:

Software-defined Networking (SDN) is a new approach to designing, building and managing networks. The basic concept is that SDN separates the network’s control (brains) and forwarding (muscle) planes to make it easier to optimize each.

Wikipedia [1]:

SDN allows network administrators to manage network services through ab-straction of lower level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forwards traffic to the selected destination (the data plane).

(24)

Dalle citazioni sopra riportate, tratte dai siti Internet di alcune tra le orga-nizzazioni/comunit`a pi`u competenti in materia, risulta chiaro il significato delle parole “Software-Defined Networking”.

Definizione 1 (Software-Defined Networking). Con il termine Software-Defined Networking (SDN) s’intende un’architettura di rete che introduce una netta se-parazione tra il “piano dati” (data plane o forwarding plane) ed il “piano di controllo” (control plane). L’intelligenza e lo stato della rete vengono gestiti in maniera centralizzata, astraendo in tal modo dai dettagli e dalla complessit`a dell’infrastruttura sottostante.

Un approccio di questo tipo rappresenta una vera e propria rivoluzione, dal momento che un apparato di rete tradizionale ospita al suo interno sia il piano di controllo che il piano dati. Per fissare le idee: il primo pu`o essere pensato come il “cervello” del dispositivo, mentre il secondo ne rappresenta il “braccio”. Focalizzandoci su un router [53], ad esempio, la gestione dei processi che im-plementano i vari protocolli di rete supportati, il mantenimento di una tabella di routing aggiornata e della relativa tabella di forwarding, l’esposizione d’in-terfacce utente, l’amministrazione del piano dati sono tutte funzionalit`a tipiche del piano di controllo. Il piano dati, dal canto suo, si occupa d’inoltrare il traffi-co basandosi sulla traffi-copia della tabella di forwarding che possiede (sincronizzata con l’originale, che risiede nel piano di controllo). L’implementazione di policer, firewall di tipo stateless e classi di servizio sono compiti avanzati realizzabili, anch’essi, dal piano dati.

Segnaliamo che, talvolta, l’acronimo SDN viene utilizzato per indicare una Software-Defined Network, ovvero una rete conforme al Software-Defined Net-working.

2.3 Architettura stratificata

Da un punto di vista di alto livello, una SDN si sviluppa su tre strati (layers) [43], come illustrato in figura 2.1a.

Lo strato più basso dell’architettura può essere denominato Infrastructure Layer. Tale livello rappresenta il piano dati della rete ed è costituito da disposi-tivi fisici e/o virtuali, cui verrà spesso fatto riferimento con il termine sintetico di “switch”. La funzione più elementare che uno switch deve compiere è quella d’inoltrare pacchetti in accordo ad un certo insieme di regole. Un approccio di tipo SDN affida la gestione, intesa come definizione ed installazione, di tali regole ad una singola2 entità centralizzata.

Il livello intermedio costituisce quel piano di controllo del quale, in accordo alla definizione fornita nel paragrafo 2.2, i vari dispositivi sono stati privati. Non esiste una nomenclatura unanime con cui riferirsi allo strato in esame. `E possibile incontrare indiscriminatamente i termini di Network Operating System, Control Layer, Controller Platform o, semplicemente, Controller. Il compito del

2_L’unicit`_{a `}_{e da intendersi in chiave logica, dal momento che detta entit`}_{a potrebbe essere} implementata tramite pi`u componenti, ciascuno situato in macchine o moduli distinti.

(25)

(a) Strati caratterizzanti un’architettura di tipo SDN

(b) Interfacce esposte dalla piattaforma di controllo: Northbound e Southbound API

(26)

piano di controllo è duplice: da un lato è responsabile dell’amministrazione degli switch, i quali andranno istruiti sulle modalità d’istradamento dei pacchetti in transito, dall’altro deve occuparsi di fornire alle applicazioni di alto livello una visione astratta e centralizzata dell’infrastruttura sottostante.

Infine, l’Application Layer include al suo interno “applicazioni di controllo” (controller applications) in grado di coprire le esigenze pi`u disparate: dal routing al LB, dall’implementazione di un firewall al monitoraggio della rete.

Ond’evitare futuri fraintendimenti, ci preme puntualizzare la convenzione adottata all’interno dell’elaborato riguardo alla nomenclatura dei componenti di una SDN che, come detto, non gode di uniformità nella letteratura speciali-stica. Nel seguito, verrà fatto riferimento al piano di controllo di un’architettura SDN con l’espressione “piattaforma per la realizzazione di applicazioni di con-trollo” oppure (più frequentemente) con le forme abbreviate di “controller” e “controller SDN”. Una pratica di questo tipo potrebbe generare confusione dal momento che i termini “controller” e “controller SDN” sono spesso utilizzati co-me sinonimi di “applicazione di controllo”. Cerchiamo dunque di chiarire, una volta per tutte, la differenza tra le due casistiche [48]. In uno scenario SDN, un’applicazione di controllo specifica come i dispositivi di rete debbano maneg-giare i pacchetti ricevuti. Un programmatore sviluppa le proprie applicazioni di controllo usufruendo di una piattaforma di controllo, la quale fornisce un’API basata su di una qualche interfaccia standardizzata. L’API esposta dalla piatta-forma di controllo, e sfruttata dal programmatore per implementare le proprie applicazioni, è detta Northbound API. Con Southbound API ci si riferisce invece all’interfaccia impiegata dalla piattaforma per comunicare con i dispositivi di rete (figura 2.1b). Il protocollo OpenFlow (capitolo 3) costituisce un esempio d’interfaccia di questo tipo.

A questo punto, ogni ambiguità dovrebbe essere risolta: a seconda del con-testo nel quale verrà inserito, infatti, risulterà chiaro se il termine “controller” debba essere inteso come piattaforma oppure come applicazione di controllo.

2.4 Benefici introdotti da SDN

Un’architettura come quella appena descritta introduce molteplici vantaggi, se confrontata con le organizzazioni di rete precedentemente adottate. Tra questi, i seguenti sono sicuramente degni di nota.

• Semplificazione. Il progetto e la gestione di una rete risultano notevol-mente semplificati, grazie al controllo che si è in grado di esercitare su di essa attraverso una singola entità logicamente centralizzata. I dispositivi che compongono l’infrastruttura sperimentano, a loro volta, una signifi-cativa riduzione di complessità. Avendo limitato i loro compiti alla mera esecuzione degli ordini impartiti dal controller, essi non sono più tenuti a comprendere ed eseguire quella moltitudine di protocolli che popola la pila protocollare di un qualunque apparato di rete tradizionale.

(27)

• Stabilità. Sviluppando dei componenti in grado di automatizzare molti compiti di gestione della rete, si è in grado di ridurre l’esposizione ad instabilità dovute a errori di configurazione da parte di operatori e tecnici. • Flessibilità. L’adozione del SDN consente agli operatori di telecomunica-zioni di programmare (ed eventualmente riprogrammare) la propria rete, in modo da rispondere a specifiche necessità di mercato o a particolari richieste da parte dei clienti, nel momento stesso in cui queste vengono sollevate.

• Innovazione. Se il piano di controllo e il piano dati fossero gestiti da componenti hardware, lo spazio lasciato alla sperimentazione sarebbe ben poco, essendo il software ed il firmware di tali dispositivi difficilmente accessibili. Avendo invece accesso a componenti software che gestiscono il piano di controllo, si lascia molto spazio alla sperimentazione di nuove soluzioni quali, ad esempio, nuovi protocolli di routing o alternative ad IP. Per una breve trattazione riguardante le problematiche ancora aperte del SDN si rimanda al paragrafo 3.3.

2.5 Organizzazioni operanti in ambito SDN

In questa sezione vengono passate in rassegna alcune tra le organizzazioni/co-munit`a pi`u attive in materia di SDN.

2.5.1 Open Networking Foundation

L’Open Networking Foundation (ONF) [4] `e un’organizzazione non a scopo di lucro, user-driven, votata alla crescita ed al successo del SDN.

L’obiettivo di ONF `e quello di concepire un nuovo paradigma di networking, riuscendo in tempi brevi ad introdurre sul mercato nuovi standard e soluzioni SDN innovative. A tal fine, l’organizzazione si adopera per promuovere un processo di sviluppo aperto, collaborativo, focalizzato sulle esigenze dell’utente finale.

Il Software-Defined Networking, cos`ı come viene interpretato da ONF, pu`o essere paragonato ad un vero e proprio “terremoto culturale” in grado di scon-volgere il modus operandi di, potenzialmente, ogni compagnia provvista di rete propria.

Fondata nel 2011 da Deutshe Telekom, Facebook, Google, Microsoft, Verizon e Yahoo!, attualmente ONF conta pi`u di cento membri, tra i quali figurano “giganti” delle telecomunicazioni quali Cisco, Ericsson, Juniper e Huawei, oltre all’italiana Telecom Italia. Per l’elenco completo delle aziende partecipanti si suggerisce di visitare [5].

Il risultato pi`u importante finora conseguito da ONF consiste sicuramente nell’evoluzione di OpenFlow da proposta accademica a vero e proprio standard commerciale. OpenFlow, che consente la programmabilit`a del piano dati da

(28)

parte di un controller remoto, `e a tutti gli effetti il primo protocollo SDN che sia mai stato proposto e costituisce (ad oggi) l’elemento imprescindibile per una qualunque architettura di rete definita a software. Per maggiori dettagli sul protocollo OpenFlow si rimanda al capitolo 3.

2.5.2 Linux Foundation

La Linux Foundation [12] `e un’organizzazione non a scopo di lucro che si propone di “unire migliaia di menti curiose in un libero ed aperto scambio d’idee”.

Tramite servizi di consulenza personalizzati e grazie a moderni programmi di addestramento per i nuovi membri, la Linux Foundation si offre di guidare l’utente tra le molteplici opportunit`a del mondo open-source, consentendogli di ottenere il massimo dal proprio investimento in Linux.

Oltre a questo, l’organizzazione assolve al compito di garante della libertà e dell’apertura del citato sistema operativo, sostenendo la comunità di sviluppa-tori kernel e verificandone, al tempo stesso, neutralità ed indipendenza.

Compagnie quali Cisco, Google, HP, IBM, Intel e Samsung si sono affidate alla Linux Foundation prendendo parte al programma Linux Foundation Colla-borative Projects, il cui scopo `e quello di “diffondere il DNA di Linux in nuovi settori”. Tramite la propria adesione, un’azienda punta a rendere vincenti i propri progetti di collaborazione, beneficiando di un’infrastruttura organizzati-va, tecnica e promozionale adeguata. In questo contesto si colloca l’iniziativa OpenDaylight.

Il progetto OpenDaylight [13][14] mira ad accelerare l’adozione del SDN da parte di svariate tipologie di aziende, che spaziano dai network provider ai fornitori di servizi di Cloud Computing. Al momento della stesura di questo documento, la comunit`a di sviluppatori stava realizzando una piattaforma SDN modulare e facilmente estendibile, rigorosamente open-source, che potesse ri-spondere alle esigenze di standardizzazione sollevate dal mondo imprenditoriale. Tale piattaforma avrebbe supportato un’ampia gamma di protocolli e, a detta degli sviluppatori, sarebbe stata in grado di evolvere rapidamente nella direzione seguita dal SDN, libera dalle volont`a dei produttori. Il primo rilascio avrebbe preso il nome di Hydrogen. Per l’elenco completo delle aziende partecipanti si suggerisce di visitare [15].

2.5.3 Internet Engineering Task Force

L’Internet Engineering Task Force (IETF) [17] `e una comunit`a aperta, di ca-ratura internazionale, composta da progettisti di rete, operatori, produttori e ricercatori interessati all’evoluzione di Internet ed al suo corretto funzionamento. L’organizzazione si dice lieta di accogliere al suo interno chiunque sia interessato a contribuire.

L’obiettivo di IETF è “far s`ı che Internet funzioni meglio”. La missione è quella di produrre documenti di alta qualità, tecnicamente ed ingegneristica-mente rilevanti, che possano influenzare positivaingegneristica-mente il modo in cui le persone progettano, utilizzano ed amministrano Internet.

(29)

La maggior parte delle mansioni viene portata avanti dai “gruppi di lavo-ro” (working groups), organizzati in “aree” (areas) a seconda dell’argomento d’interesse. Le discussioni tra membri appartenenti allo stesso gruppo di lavoro sono effettuate tramite le mailing list. Durante l’anno vengono organizzati tre incontri, ciascuno dei quali ha sede in un diverso continente: Europa, Asia e Nord America.

Recentemente, anche in IETF si `e sollevato l’interesse verso problematiche di tipo SDN. Al momento della stesura di questo documento, l’esito dello studio si limitava ad una serie di draft, stadio intermedio nella vita di uno standard prima che questi venga adottato con il nome di Request For Comments (RFC) o, altrimenti, abbandonato.

In uno dei primi documenti proposti [37], si parlava di Software Driven Networks come di un approccio che consentisse alle applicazioni di “conversare con” e “manipolare” il software di controllo presente nei dispositivi di rete. Dovrebbe risultare evidente come un’interpretazione di questo tipo differisca notevolmente dal significato universalmente attribuito al SDN (paragrafo 2.2). Non si parlava, infatti, di rimuovere il piano di controllo dai dispositvi per situarlo in una entit`a esterna, logicamente centralizzata, ma semplicemente di fornire alle applicazioni un modo d’intervenire sull’esistente.

Nel seguito, l’organizzazione si è allineata al pensare comune, abbandonando il draft citato e cominciando ad esaminarne di nuovi [38]. Si è passati ad adottare la terminologia usuale di Software-Defined Networking e ad interpretarla come introduzione di un livello di astrazione che separi il piano dati dal piano di controllo, cos`ı da consentire una più rapida innovazione ad entrambi i livelli.

Oltre ai documenti menzionati, ne esistono altri che si occupano d’impieghi pratici della tecnologia SDN, in ambiti quali la sicurezza, il supporto per la mobilit`a o l’interazione con il protocollo BGP. Per informazioni pi`u dettagliate si consiglia di visitare [18].

(30)

(31)

Capitolo 3

OpenFlow

In questo capitolo viene descritto OpenFlow [7][41][42], un protocollo che con-sente di programmare la flow-table di uno switch.

`

E importante sottolineare come “OpenFlow” e “Software-Defined Networ-king” non debbano essere intesi come sinonimi. Mentre il Software-Defined Networking consiste nel disaccoppiamento tra piano dati e piano di controllo, come è stato ampiamente discusso nel capitolo 2, OpenFlow si limita a speci-ficare le modalità con cui debba avere luogo una comunicazione tra controller e switch, in uno scenario di questo tipo. Si tratta cioè di una (tra le possibili) Southbound API che lo strato di controllo può adottare per interagire con i dispositivi di rete sottostanti (paragrafo 2.3). Volendo utilizzare una notazione matematica:

OpenFlow ⇒ SDN, ma SDN ; OpenFlow.

L’incomprensione `e (almeno in parte) giustificabile data la notevole importanza rivestita da OpenFlow nel contesto delle reti definite a software, essendo:

• il primo protocollo SDN proposto dal mondo accademico (Stanford Uni-versity [41]);

• il primo protocollo SDN ad aver visto effettivamente la luce come standard (Open Networking Foundation [4]);

• il primo protocollo SDN per diffusione e utilizzo, in ambito sia commerciale che universitario.

Il capitolo si articola in tre parti: nel paragrafo 3.1 vengono presentate le motivazioni che hanno portato all’ideazione di OpenFlow ed il razionale che ne ha guidato la stesura; nel paragrafo 3.2 si descrivono pi`u nel dettaglio gli aspetti salienti del protocollo, oltre ai componenti e alle funzioni basilari da implementare in uno switch per far s`ı che questi possa comunicare con un con-troller remoto; nel paragrafo 3.3 si passano in rassegna alcune problematiche

(32)

caratterizzanti le architetture SDN che adottano OpenFlow come Southbound API.

La versione dello standard che è stata presa come riferimento, specificata in [42], è la 1.0.01_{. Nonostante nel corso degli anni siano state proposte revisioni e} aggiornamenti a tale documento2_{, la scelta `}_{e stata guidata da tre considerazioni:} 1. al momento della stesura di questo elaborato, tale versione era la più

diffusa [40];

2. le funzionalit`a ed i concetti cardine propri del protocollo sono gi`a integral-mente presenti;

3. la piattaforma per lo sviluppo di applicazioni di controllo utilizzata (pa-ragrafo 4.2) supporta esclusivamente questa versione.

3.1 Proposta del mondo accademico

In [41] viene denunciata la “fossilizzazione” (ossification) delle infrastrutture di rete, dovuta all’elevato numero di dispositivi e protocolli presenti sul campo ed alla riluttanza nei confronti di sperimentazioni che coinvolgano traffico aziendale (paragrafo 2.1). Una situazione di questo tipo non lascia spazio all’osservazione di soluzioni innovative in scenari sufficientemente realistici. Come risultato, la maggior parte delle proposte fornite dalla comunit`a scientifica resta “su carta”, non posta dinanzi alla prova dei fatti.

Gli autori, essendo essi stessi ricercatori e dunque coinvolti in prima persona in questo tipo di problematiche, si sono chiesti se fosse possibile condurre espe-rimenti all’interno del proprio campus universitario facendo in modo che, da un lato, gli amministratori di rete non si sentissero a disagio nell’impiegare disposi-tivi sperimentali nella propria infrastruttura e, dall’altro, i ricercatori potessero ottenere il pieno controllo sulla porzione di traffico in esame, senza per questo interferire con il normale funzionamento degli apparati.

Partendo dalla sostanziale indisponibilit`a da parte dei produttori ad “aprire i contenitori”, esponendo cos`ı l’interno dei propri dispositivi, McKeown et al. hanno adottato un intelligente compromesso che fornisce ai ricercatori un ap-proccio uniforme per condurre esperimenti su switch e router eterogenei senza dover scrivere un software di controllo specifico per un certo marchio, e che ga-rantisce tuttavia ai manifatturieri la riservatezza richiesta nei confronti di anni di lavoro spesi per superare la concorrenza.

La soluzione consiste nell’osservare che la maggior parte dei router e degli switch Ethernet presenti sul mercato `e provvista di flow-table, generalmente rea-lizzate come TCAM, che lavorano a velocit`a di linea per implementare firewall, NAT, compiti di QoS e raccolta di statistiche. Nonostante l’effettiva implemen-tazione di tali flow-table possa variare da produttore a produttore, il protocollo

1_{Wire Protocol 0x01.}

2_{L’elenco completo delle versioni del protocollo gi`}_{a standardizzate, o ancora in fase di} ratificazione, pu`o essere ricostruito consultando [6] e [8].

(33)

OpenFlow 17

Figura 3.1: Schema logico di uno switch OpenFlow

OpenFlow sfrutta un insieme di funzionalit`a comuni che `e possibile individuare al loro interno, consentendo di programmarne il contenuto da remoto.

Con un approccio di questo tipo, un amministratore di rete può, ad esem-pio, suddividere il traffico in due porzioni: aziendale e sperimentale. I ricer-catori hanno cos`ı la possibilità di controllare direttamente i propri pacchetti, decidendone il percorso seguito ed il trattamento riservato loro dai vari disposi-tivi, essendo in grado di testare soluzioni innovative quali protocolli di routing all’avanguardia, policy di sicurezza a prova d’intruso, nuovi schemi d’indirizza-mento e perfino alternative ad IP. Allo stesso tempo, il traffico aziendale rimane isolato, continuando ad essere trattato secondo le modalità usuali. Si osservi, infine, come l’hardware degli apparati non sia stato minimamente modificato, rispettando in questo modo il bisogno di piattaforme chiuse sollevato dalle case produttrici.

3.2 Standard: OpenFlow 1.0.0

Uno switch che comunichi con un controller, utilizzando il protocollo OpenFlow, viene denominato “switch OpenFlow”3 _{(OpenFlow Switch).}

Come illustrato in figura 3.1, uno switch OpenFlow `e logicamente costi-tuito da una “tabella” (flow-table), necessaria per svolgere funzioni associate ai pacchetti in transito quali ricerca (lookup) ed inoltro, e da un “canale di comuni-cazione sicuro” (secure channel ), che ne consente l’interazione con un controller remoto.

3.2.1 Flow-table

La flow-table determina il trattamento riservato a ciascun pacchetto proces-sato dallo switch. Essa contiene un insieme di “regole” (flow entries), il cui inserimento e la cui rimozione sono prerogative del controller.

Ciascuna regola (tabella 3.1) `e provvista di:

(34)

Campi Contatori Azioni

Tabella 3.1: Struttura generale di una regola presente all’interno della tabella di uno switch OpenFlow

Campo Lunghezza (bit)

Ingress port variabile

Ethernet source address 48

Ethernet destination address 48

Ethernet type 16 VLAN id 12 VLAN priority 3 IP source address 32 IP destination address 32 IP protocol 8 IP ToS bits 6

Transport source port / ICMP type 16

Transport destination port / ICMP code 16

Tabella 3.2: Campi utilizzabili in una regola OpenFlow per specificare un flusso

• campi, presenti nelle intestazioni di trame, pacchetti e segmenti, da far combaciare con i pacchetti in transito;

• contatori (o statistiche) da aggiornare ad ogni corrispondenza; • zero o pi`u azioni da applicare ai pacchetti corrispondenti.

Campi

La versione in esame del protocollo OpenFlow specifica dodici campi, elencati in tabella 3.2, tramite i quali `e possibile discriminare tra flussi differenti. Il primo campo fa riferimento ad un numero di porta dello switch OpenFlow, mentre gli undici rimanenti sono individuabili all’interno delle intestazioni di trame, pacchetti e segmenti.

Un flusso TCP, ad esempio, pu`o essere specificato tramite tutti e dodici i campi consentiti. Un flusso IP, invece, potrebbe non necessitare dei campi corrispondenti ai numeri di porta utilizzati dal livello di trasporto.

Ogni regola presente in tabella contiene, per ciascun campo, un valore spe-cifico oppure any, se questi non `e rilevante. In quest’ultimo caso si parla di campo “jolly” (wildcard ).

Se lo switch supporta l’impiego di “maschere di rete” (subnet masks) per gli indirizzi IP, esse possono essere sfruttate per introdurre un ulteriore livello di granularit`a nell’elaborazione dei pacchetti.

(35)

OpenFlow 19

Contatori

Ciascuno switch OpenFlow mantiene dei contatori a livello di tabella, di flusso, di porta e di coda.

La tabella 3.3 riporta i contatori da implementare obbligatoriamente. Le voci “Duration” si riferiscono al tempo trascorso dall’installazione del flusso all’in-terno della flow-table, mentre il campo “Receive Errors” include una qualunque tipologia di errore esplicitamente notificata.

Elaborazione dei pacchetti

Ciascun pacchetto ricevuto da uno switch OpenFlow viene confrontato con le regole presenti in tabella4_{(figura 3.2).}

Nel caso in cui venga individuata una regola valida, ovvero una regola che combaci con il pacchetto in transito, ogni azione ad essa associata verrà eseguita. L’assenza di azioni per tale regola causa lo scarto del pacchetto. Se una regola di questo tipo non è presente, il pacchetto sarà inviato, tramite il canale di comunicazione sicuro, al controller. Esso è infatti responsabile della gestione di quei pacchetti che lo switch non saprebbe altrimenti come trattare.

Un pacchetto “combacia” con una regola (matches a flow-table entry) se tutti i valori contenuti negli undici possibili campi delle relative intestazioni (trama contenente, pacchetto stesso e segmento contenuto), più il numero di porta dalla quale è stato ricevuto, corrispondono con quelli definiti in tabella. Il confronto con un campo jolly darà sempre esito positivo.

La scansione delle regole installate nella flow-table avviene per priorità. Il livello più alto di priorità è riservato a quelle regole che specificano una corri-spondenza esatta, che non possiedono cio`_{e alcun campo avente come valore any.} Per tutte le altre, invece, la priorità può essere indicata utilizzando il campo ap-positamente studiato. Regole con priorità più elevata5vengono consultate prima di quelle a priorità inferiore. Se esistono più regole valide caratterizzate dalla stessa priorità, lo switch è libero di scegliere quale prendere in considerazione.

Per ogni pacchetto che combacia con una certa regola, i relativi contatori vengono aggiornati di conseguenza.

Azioni

Ad ogni regola presente in tabella vengono associate zero o più azioni, le quali determinano come lo switch debba trattare i pacchetti per i quali si verifichi una corrispondenza. Come è già stato detto, l’assenza di azioni causa lo scarto del pacchetto. Qualora invece vengano specificate più azioni, queste andranno applicate nell’ordine di apparizione.

Le azioni contemplate dalla versione del protocollo OpenFlow esaminata ven-gono suddivise in due categorie: “obbligatorie” (Required Actions) e “opzionali” (Optional Actions). Visto che uno switch `e tenuto a supportare solamente quelle

4_{Esiste la possibilit`}_{a che uno stesso switch OpenFlow possieda pi`}_{u di una flow-table.} 5_{Valori pi`}_{u elevati corrispondono a priorit`}_{a pi`}_{u elevate.}

(36)

Contatore Lunghezza (bit) Tabella Active Entries 32 Packet Lookups 64 Packet Matches 64 Flusso Received Packets 64 Received Bytes 64 Duration (secondi) 32 Duration (nanosecondi) 32 Porta Received Packets 64 Transmitted Packets 64 Received Bytes 64 Transmitted Bytes 64 Receive Drops 64 Transmit Drops 64 Receive Errors 64 Transmit Errors 64

Receive Frame Alignment Errors 64

Receive Overrun Errors 64

Receive CRC Errors 64

Collisions 64

Coda

Transmit Packets 64

Transmit Bytes 64

Transmit Overruns Errors 64

Tabella 3.3: Tipologie di contatore obbligatoriamente implementate da uno switch OpenFlow

(37)

OpenFlow 21

Figura 3.2: Elaborazione dei pacchetti da parte di uno switch OpenFlow

obbligatorie, al momento della connessione con un controller sar`a suo compito indicare quali azioni opzionali `e in grado di comprendere (e quindi di eseguire). Azioni obbligatorie

1. Forward.

• ALL – Uno switch OpenFlow deve essere in grado d’inoltrare un pacchetto da tutte le sue interfacce, esclusa quella dalla quale `e stato ricevuto.

• CONTROLLER – Uno switch OpenFlow deve essere in grado d’in-capsulare un pacchetto ed inviarlo al controller.

• LOCAL – Uno switch OpenFlow deve essere in grado di recapitare un pacchetto alla propria pila protocollare.

• TABLE – Uno switch OpenFlow deve essere in grado di applicare ad un pacchetto le azioni specificate all’interno della propria tabella6_. • IN PORT – Uno switch OpenFlow deve essere in grado d’inoltrare

un pacchetto attraverso la porta dalla quale `e stato ricevuto. 2. Drop. Uno switch OpenFlow deve essere in grado di scartare un pacchetto

che combaci con una regola per la quale non vengano specificate azioni da eseguire.

(38)

Azioni opzionali 1. Forward.

• NORMAL – Uno switch OpenFlow pu`o essere in grado d’inol-trare un pacchetto in accordo al suo processing tradizionale (non OpenFlow).

• FLOOD – Uno switch OpenFlow pu`o essere in grado d’inoltrare un pacchetto sul minimo spanning tree per la rete, esclusa l’interfaccia dalla quale `e stato ricevuto.

2. Enqueue. Uno switch OpenFlow può essere in grado d’inoltrare un pac-chetto tramite una coda collegata ad una porta. La particolare configura-zione della coda determina la tipologia d’inoltro ed è pensata per attuare funzionalità di QoS.

3. Modify-Field. Uno switch OpenFlow pu`o essere in grado di modificare alcuni campi presenti nelle intestazioni di trame, pacchetti e segmenti. Tra gli altri, `e possibile riscrivere gli indirizzi MAC sorgente e destinatario, cos`ı come gli indirizzi IP ed i numeri di porta TCP o UDP.

3.2.2 Secure channel

Il canale di comunicazione sicuro costituisce l’interfaccia tramite la quale cia-scuno switch OpenFlow si collega ad un controller. Grazie a tale interfaccia, il controller è in grado di configurare e amministrare lo switch specificando, in ul-tima analisi, le modalità d’inoltro dei pacchetti. Come risposta, riceverà eventi da quest’ultimo.

Nella versione del protocollo presa in esame non viene standardizzata la coesistenza di pi`u controller.

3.2.3 Panoramica sul protocollo

Il protocollo OpenFlow contempla l’utilizzo di tre tipologie di messaggi: “da controller a switch” (controller-to-switch), “asincroni” (asynchronous) e “sim-metrici” (symmetric).

Messaggi da controller a switch

Tali messaggi vengono generati dal controller e possono necessitare o meno di una risposta da parte dello switch. Tra questi, rivestono particolare interesse:

• Modify-State – utilizzati per aggiungere, eliminare oppure modificare le regole della flow-table;

• Read-State – utilizzati per raccogliere dagli switch statistiche (valori dei contatori) riguardanti tabelle, porte oppure singoli flussi;

• Send-Packet – utilizzati per forzare l’invio di un pacchetto attraverso una porta specifica dello switch.

(39)

OpenFlow 23

Messaggi asincroni

Tali messaggi sono generati dallo switch, senza che il controller ne abbia fatto richiesta.

• Packet-In – evento sollevato in corrispondenza di ogni pacchetto per il quale non `e stata individuata una regola valida in tabella o, equivalen-temente, per ogni pacchetto che combaci con una regola la cui azione preveda l’invio dello stesso al controller;

• Flow-Removed – evento sollevato in corrispondenza della rimozione di una regola dalla flow-table;

• Port-Status – evento sollevato in corrispondenza di un cambiamento di stato relativo ad una porta (aggiunta, modifica o rimozione);

• Error – evento sollevato in corrispondenza di problemi di vario tipo. Messaggi simmetrici

I messaggi “simmetrici” possono essere generati sia dal controller che dallo switch, senza che la controparte ne abbia fatto richiesta. Per maggiori dettagli si rimanda a [42].

3.2.4 Modifica della flow-table

Il messaggio pi`u importante del protocollo `e sicuramente quello che consente al controller di apportare modifiche alla tabella di uno switch: OFPT FLOW MOD (messaggio da controller a switch, di tipo Modify-State).

Tramite tale messaggio `e possibile aggiungere, rimuovere o modificare una o pi`u regole presenti all’interno della flow-table. Il campo command, con l’au-silio del campo flags, viene utilizzato proprio per indicare in quale delle tre casistiche rientri il messaggio in esame.

Se il campo command assume il valore OFPFC ADD, siamo in presenza di un ten-tativo di aggiunta di una nuova regola. Prima di far questo però, lo switch è te-nuto a verificare che non esista alcuna regola “in conflitto”7con quella da aggiun-gere. Nel caso in cui la verifica dia esito negativo, l’operazione andrà sicuramente a buon fine. Qualora invece una regola di questo tipo esistesse, il comportamen-to tenucomportamen-to dallo switch verrebbe determinacomportamen-to dal flag OFPFF CHECK OVERLAP. Se tale flag risulta settato, lo switch dovrà rifiutarsi di aggiungere la regola in con-flitto, inviando al controller il messaggio di errore appropriato. Altrimenti, la regola già esistente dovrà essere rimossa (assieme ai suoi contatori) in favore della nuova.

Se il campo command assume il valore OFPFC MODIFY, siamo in presenza di un tentativo di modifica di una regola, assunta come gi`a esistente. Nel ca-so in cui tale regola sia effettivamente presente in tabella, le relative azioni

7_{Due regole sono in conflitto se: (1) uno stesso pacchetto pu`}_{o combaciare con entrambe e} (2) sono caratterizzate dalla stessa priorit`a.

(40)

vengono aggiornate in accordo con quanto specificato nel messaggio, mentre i valori corrispondenti a contatori e temporizzazioni sono lasciati inalterati. In caso contrario, lo switch si comporta come se avesse ricevuto un messaggio OFPFC ADD.

Infine, se il campo command assume il valore OFPFC DELETE, siamo in presenza di un tentativo di rimozione di una regola, assunta come gi`a esistente. Nel caso in cui tale regola sia effettivamente presente in tabella, si provvede alla sua rimozione e, qualora il flag OFPFF SEND FLOW REM risulti settato, all’invio al controller di un messaggio asincrono, di tipo Flow-Removed. In caso contrario, non si richiede alcuna azione.

I valori OFPFC MODIFY e OFPFC DELETE possiedono le relative versioni STRICT. In assenza della porzione STRICT, i valori any sono attivi e tutti i flussi che combaciano con la descrizione fornita nel messaggio vengono modificati o rimos-si. Se invece la porzione STRICT è presente, tutti i campi della regola, compresi quelli aventi valore any e la priorità, sono confrontati con i corrispondenti va-lori all’interno del messaggio. In tal caso, solo i flussi effettivamente identici vengono modificati o rimossi. Ad esempio, se il controller invia un messaggio valido per la rimozione di una regola nel quale tutti i campi possiedono il va-lore any, il comando OFPFC DELETE rimuove tutte le regole presenti in tabella, mentre OFPFC DELETE STRICT elimina soltanto quelle che si applicano a tutti i pacchetti, con la priorità assegnata.

Il campo cookie costituisce un identificatore “opaco” (opaque), non viene cio`e considerato nelle operazioni di confronto della regola con un pacchetto, e viene settato dal controller. Un esempio di utilizzo per tale campo viene fornito nel paragrafo 5.5.

I campi idle timeout e hard timeout, espressi in secondi, determinano la frequenza con la quale uno switch rimuove autonomamente le regole presenti in tabella. Se idle timeout è settato ma hard timeout è nullo, la regola viene rimossa dopo idle timeout secondi d’inattività da parte del flusso associato. Se idle timeout è nullo ma hard timeout è settato, la regola viene rimossa dopo hard timeout secondi, indipendentemente dal fatto che il flusso associato sia attivo o meno. Se entrambi sono settati, la regola verrà rimossa al primo periodo d’inattività del flusso pari a idle timeout oppure trascorso un intervallo di tempo pari a hard timeout, a seconda di quale evento si verifichi per primo. Infine, se entrambi i timer sono nulli, la regola è considerata permanente. L’unico modo per rimuovere una regola permanente consiste nell’inviare allo switch un messaggio OFPT FLOW MOD il cui campo command assuma il valore OFPFC DELETE, secondo le modalità illustrate precedentemente.

3.3 Questioni ancora aperte

A controbilanciare i benefici illustrati nel paragrafo 2.4, esiste un certo numero di sfide che chiunque sia interessato a realizzare una SDN la cui Southbound API coincida col protocollo OpenFlow si trova a dover affrontare, tutte

(41)

lega-OpenFlow 25

te sostanzialmente alla forte dipendenza dell’architettura nei confronti di un controller centralizzato.

• Sicurezza. Data l’importanza rivestita dal controller all’interno della rete, tale componente potrebbe diventare obiettivo stimolante per un po-tenziale opponent. Il controller, infatti, ha accesso all’intera infrastruttura e necessita dunque di protezione nei confronti di eventuali intrusioni. Un ulteriore punto di vulnerabilit`a pu`o essere individuato nel canale di comunicazione tra switch e controller.

• Disponibilità. Come è stato già osservato, uno switch OpenFlow inoltra i pacchetti secondo alcune regole memorizzate all’interno della propria ta-bella. Tuttavia, qualora si rendesse necessaria una modifica di tali regole, i dispositivi di rete si dovrebbero rivolgere al controller. È fondamenta-le, dunque, mantenere sempre attive le connessioni tra quest’ultimo e gli switch. Detto in altri termini, il controller di una SDN costituisce un single point of failure.

Un altro aspetto da non sottovalutare riguarda il tempo impiegato per creare un nuovo flusso, ovvero il ritardo sperimentato a causa dell’instal-lazione di quelle regole necessarie per la gestione di pacchetti che gli switch non saprebbero altrimenti come trattare. Se tale componente risulta trop-po elevata, i requisiti di distrop-ponibilit`a della rete potrebbero non essere rispettati.

• Scalabilit`a. Il controller rappresenta il “collo di bottiglia” (bottleneck ) dell’architettura. Se troppi pacchetti dovessero essergli recapitati, potreb-bero sorgere dei cali prestazionali. Una rete ben progettata deve fare in modo che la maggior parte del traffico venga gestita direttamente dagli switch, senza che sia necessario l’intervento del controller.

Sarebbe interessante, inoltre, valutare la dipendenza di un tale fenomeno dal numero di nodi che compongono la rete. In particolare, non `e ancora chiaro se soluzioni di questo tipo possano essere impiegate nel core della rete.

• CAPEX e OPEX. `E ancora oggetto di dibattito se OpenFlow e SDN siano in grado di abbattere la “spesa di capitale” (capital expenditure o CAPEX) e la “spesa operativa” (operating expenditure o OPEX) di un’organizzazione.

I fautori di OpenFlow sostengono che rimuovere la complessità dai dispo-sitivi di rete non solo possa renderli più semplici, ma anche più economici. Ciò potrebbe ridurre la spesa di capitale. Tuttavia, il protocollo presenta tuttora alcune limitazioni e la presenza di hardware avanzato all’interno della rete risulta ancora necessaria. Inoltre, fare in modo che il controller risulti sempre raggiungibile dagli switch causa l’aumento del costo della porzione CAPEX.

(42)

Abbiamo gi`a osservato come l’adozione di un approccio SDN riduca dra-sticamente il numero di configurazioni manuali, le quali richiedono tempo per essere approntate e sono inoltre soggette ad errori. Questo aspetto comporta una diminuzione della spesa operativa. D’altra parte, spostare la complessit`a all’interno di un piano di controllo centralizzato richiede lavoro ed esperienza. Progettisti, sviluppatori software e sperimentatori sono solo alcuni esempi di figure professionali necessarie, la cui retribuzione va ad accrescere la parte OPEX.

• Compatibilità. Come verrà illustrato nel paragrafo 4.2, le varie piat-taforme di controllo esistenti supportano specifiche versioni del protocol-lo OpenFprotocol-low. Non sempre la pubblicazione di una nuova versione delprotocol-lo standard si traduce in un aggiornamento del software di dette piattaforme. Un problema analogo consiste nel modificare il software dei vari dispo-sitivi di rete per fare in modo che questi riescano a realizzare le nuove funzionalità introdotte dagli aggiornamenti dello standard.

Infine, le applicazioni di controllo implementate dagli utenti devono af-frontare le medesime difficolt`a. In particolare, non esiste la certezza che un’applicazione funzionante sotto una certa versione risulti tale anche con un’altra.