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 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`a. Come `e stato gi`a 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. `E 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 disponibilit`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`a dai dispo- sitivi di rete non solo possa renderli pi`u semplici, ma anche pi`u economici. Ci`o 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.
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`a. Come verr`a illustrato nel paragrafo 4.2, le varie piat- taforme di controllo esistenti supportano specifiche versioni del protocol- lo OpenFlow. Non sempre la pubblicazione di una nuova versione dello 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`a 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.
Capitolo 4
Ambiente di sviluppo
Come specificato nel paragrafo 2.3, un’architettura SDN consiste in (1) una o pi`u applicazioni di controllo, implementate grazie alle API esposte da (2) una piattaforma di controllo, la quale comunica con (3) i dispositivi di rete sottostanti (reali e/o virtuali) grazie ad un’interfaccia standardizzata che, nella maggior parte dei casi, coincide con quella specificata dal protocollo OpenFlow. La realizzazione di un’applicazione di controllo rappresenta il fine ultimo del lavoro di tesi preso in esame, e su questo aspetto ci soffermeremo nel seguito dell’elaborato (capitolo 5).
Il presente capitolo, invece, vuole trattare i livelli pi`u bassi caratterizzanti la struttura a strati di una SDN. Esso risulta suddiviso in due parti: nel pa- ragrafo 4.1 si descrive l’ambiente grazie al quale `e stato possibile emulare, su un singolo laptop, delle infrastrutture di rete virtuali; nel paragrafo 4.2 vengono illustrati gli aspetti salienti della piattaforma per la realizzazione di applicazioni di controllo utilizzata.
4.1
Dispositivi di rete virtuali: Mininet
In questo paragrafo vengono trattate le caratteristiche salienti di un nuovo am- biente per lo sviluppo di prototipi di rete, chiamato Mininet [19][44], il quale risponde all’esigenza d’implementare rapidamente modelli funzionalmente cor- retti, in grado di essere inseriti direttamente in un’infrastruttura reale. Gli utenti possono realizzare nuove funzionalit`a all’interno della rete, cos`ı come ar- chitetture completamente diverse da quelle gi`a esistenti; testarle su topologie di dimensioni importanti, utilizzando del traffico generato da applicazioni reali; ed infine impiegare il medesimo codice e gli stessi script di verifica in una rete aziendale.
Grazie alle peculiarit`a del sistema operativo Linux, Mininet funziona sor- prendentemente bene su un singolo laptop, considerata la sua capacit`a di lan- ciare reti con bande dell’ordine del Gbit/s, provviste di centinaia di nodi.
4.1.1
Mininet, in sintesi
Mininet `e un sistema per generare rapidamente prototipi di rete di grandi di- mensioni, disponendo delle risorse limitate di un laptop. Grazie alla lightweight virtualization, un singolo sistema riesce ad agire come un’infrastruttura com- plessa. Nonostante altre piattaforme impieghino la stessa tecnica, Mininet si differenzia da queste per la propensione verso soluzioni di tipo SDN.
Un host generato con Mininet si comporta come una macchina reale: vi si pu`o accedere da remoto tramite il protocollo SSH oppure lanciarvi un qualsiasi tipo di applicazione. Si ha cos`ı l’impressione di osservare pacchetti inviati attraverso vere interfacce Ethernet, caratterizzate da una certa velocit`a trasmissiva ed un certo ritardo, che vengono processati da veri dispositivi di rete, siano essi switch Ethernet, router o middlebox.
4.1.2
Vantaggi derivanti dall’utilizzo di Mininet
Nel seguito vengono citati alcuni dei principali vantaggi derivanti dall’utilizzo di Mininet.
• Velocit`a. Lanciare una rete, la cui topologia non risulti eccessivamen- te complicata, richiede solamente pochi secondi. Questo comporta un significativo incremento nella rapidit`a del ciclo di sviluppo.
• Topologie personalizzate. Oltre ai comandi messi a disposizione dalla CLI, grazie ai quali `e possibile lanciare strutture di rete elementari, il sistema `e dotato di una API [23] scritta in Python, con la quale l’utente `
e libero di specificare la topologia che pi`u si addice alle proprie esigenze: da una struttura che contempli un singolo switch ad una che assomigli maggiormente ad una rete di Internet, da uno scenario che ricalchi la backbone della Stanford University ad uno studiato appositamente per i DC.
• Programmi reali. Tutto ci`o che risulti eseguibile su una piattaforma Linux `e compatibile con le capacit`a di un host in Mininet. Si pensi, ad esempio, a due applicazioni molto popolari quali Iperf e Wireshark. • Approccio SDN. Gli switch generati con Mininet sono programmabili
tramite il protocollo OpenFlow. Un progetto SDN che funzioni corret- tamente su Mininet pu`o essere facilmente adattato per impiegare degli switch OpenFlow reali.
• Multi-piattaforma. Mininet funziona su laptop, su server, su macchina virtuale o su piattaforma Cloud.
• Condivisione e riproducibilit`a dei risultati. Chiunque possieda un PC pu`o eseguire il codice sviluppato da un utente e verificarne il corretto funzionamento.
Ambiente di sviluppo 29
• Facilit`a di utilizzo. Per ideare e lanciare un esperimento in Mininet `e sufficiente saper scrivere uno script in Python.
• Progetto open-source. Gli utenti sono invitati ad esaminare il codice sorgente ed eventualmente modificarlo, correggerlo o richiederne amplia- menti ed estensioni.
• Sviluppo costante. Mininet `e costantemente in fase di sviluppo. Se gli utenti ritengono che non funzioni correttamente, che sia mal progettato o che “non abbia senso” possono segnalarlo sull’apposita mailing list, af- finch´e la comunit`a degli utilizzatori e sviluppatori possa cercare di fornire spiegazioni e suggerimenti per risolvere il problema.
4.1.3
Svantaggi derivanti dall’utilizzo di Mininet
Chiaramente, esistono anche dei punti a sfavore riguardanti l’utilizzo di Mininet all’interno del proprio progetto. Tra i pi`u significativi, ricordiamo i seguenti.
• Eseguire il tutto in un unico sistema ospite comporta che le risorse dispo- nibili debbano essere equamente spartite tra gli host e gli switch della rete generata.
• Dal momento che Mininet utilizza un singolo kernel Linux per tutti gli host virtuali, non `e possibile eseguire del software che dipenda da altri sistemi operativi, quali BSD o Windows.
• Se l’utente necessita di comportamenti personalizzati da parte dei dispo- sitivi di rete, `e suo compito ricercare l’implementazione di un controller SDN che soddisfi le proprie esigenze o, in alternativa, svilupparne uno per proprio conto.
• Al momento della stesura di questo documento, gli host virtuali venivano automaticamente isolati dalla LAN dell’utente. A meno di configurazioni esplicite, dunque, essi non avevano accesso ad Internet.
• Diversamente da quanto avviene per un simulatore, Mininet non possiede una nozione molto accurata di tempo virtuale. Ci`o comporta che le misure temporali siano basate esclusivamente sul tempo reale.
Gli sviluppatori affermano che dette limitazioni non sono intrinseche di Mi- ninet, ma piuttosto dovute alla particolare implementazione adottata. Il loro superamento risulta, quindi, un mero “problema di codice”.
4.1.4
Dettagli implementativi
Per creare una rete, Mininet emula ogni parte di essa: i link, gli host, gli switch ed i controller. I meccanismi impiegati sono quelli della lightweight virtualiza- tion (figura 4.1), disponibili su tutte le distribuzioni dei sistemi operativi Linux: processi eseguiti nei network namespaces e virtual Ethernet pairs.
Figura 4.1: Lightweight virtualization
I link Un virtual Ethernet pair, o veth pair, si comporta come un cavo che collega due interfacce virtuali: i pacchetti inoltrati tramite una di esse vengono consegnati all’altra. Dette interfacce appaiono al mondo esterno come delle porte Ethernet realmente funzionanti. I veth pair possono essere installati in uno switch virtuale, quale un bridge Linux o uno switch OpenFlow implementato a software.
Gli host I network namespaces sono dei “contenitori” per lo stato della re- te. Essi forniscono processi (e gruppi di processi) aventi propriet`a esclusiva d’interfacce, porte e tabelle di routing.
In Mininet, un host `e semplicemente uno shell process (bash), situato nel proprio network namespace. Ogni host possiede una o pi`u interfacce Ethernet virtuali ed `e collegato ad un “processo padre” (parent process), chiamato mn, che invia comandi ed esamina l’output.
Gli switch Gli switch OpenFlow realizzati a software forniscono gli stessi mec- canismi d’inoltro e consegna dei pacchetti tipici di un commutatore hardware. Ne esistono due tipologie: user-space e kernel-space.
I controller I controller possono essere situati ovunque nella rete, sia essa reale o simulata, purch´e si disponga di connettivit`a a livello IP tra questi e la macchina sulla quale vengono lanciati gli switch virtuali.