Confronto tra alcune delle pi` u popolari piattaforme per lo

SDN

Quando ci si appresta a scegliere quale controller SDN impiegare nella propria architettura, occorre tener conto di numerosi fattori.

Fra questi, riveste sicuramente un ruolo di spicco il linguaggio di program- mazione. Infatti, al di l`a del grado di dimestichezza che l’implementatore del progetto possiede con i vari Python, C++ e Java, l’adozione di un linguaggio piuttosto che un altro pu`o determinare una sensibile variazione delle prestazioni. Non solo. Un altro aspetto da prendere sempre in considerazione `e la curva di apprendimento, ovvero il grado di difficolt`a nell’imparare a scrivere delle policy per quel particolare controller.

Anche le dimensioni della comunit`a degli utenti che utilizzano e sviluppano il controller `e una variabile da non sottovalutare. Se molte persone sono coinvolte nella “vita” di una particolare piattaforma, le probabilit`a di trovare qualcuno in grado di fornire un supporto nel momento del bisogno saranno maggiori, rispetto a quelle che si avrebbero se utilizzassimo una soluzione pi`u elitaria.

Ultima, ma non per importanza, la connotazione southbound o northbound delle API fornite.

Connotazione southbound

Come si `e avuto modo di puntualizzare in precedenza, una piattaforma per lo sviluppo di applicazioni di controllo espone al programmatore una Northbound API. Ci`o nonostante, le API fornite dalla prima generazione di tali piattafor- me assomigliano molto all’interfaccia utilizzata per comunicare con gli switch, ovvero OpenFlow. Il programmatore deve perci`o adottare una mentalit`a “as- sembly”, di basso livello. Da tutto ci`o deriva la connotazione southbound di detta generazione.

La tabella 4.1 confronta sinteticamente quattro celebri controller che possie- dono una connotazione southbound.

NOX Inizialmente sviluppato a stretto contatto con OpenFlow, presso Nicira Networks, NOX [26] `e stato a tutti gli effetti il primo controller OpenFlow mai realizzato. Nel 2008, Nicira ha donato la propria creazione alla comunit`a scientifica e, a partire da allora, NOX ha costituito le fondamenta per numerosi progetti di ricerca, durante le prime esplorazioni del mondo SDN. Ne esistono due varianti:

• NOX-Classic, realizzato in C++/Python e non pi`u supportato;

• NOX (“new NOX”), scritto esclusivamente in C++, ben supportato e regolarmente aggiornato.

La versione del protocollo OpenFlow compatibile con la piattaforma `e la 1.0, ma esite una fork1 per le versioni 1.1, 1.2 e 1.3.

NOX rappresenta dunque una buona scelta se si possiede una solida co- noscenza del C++ e si `e alla ricerca di buone prestazioni, ottenibili grazie all’utilizzo di tale linguaggio di programmazione.

POX Attenendosi alla definizione che ne viene data sul sito del progetto, POX [27] `e il “fratello minore” di NOX. Ad oggi, supporta solamente OpenFlow 1.0, oltre ad alcune delle cosidette Nicira Extensions [16].

Dal punto di vista di un programmatore non esperto, l’utilizzo di Python rende POX pi`u appetibile di NOX: il codice risulta infatti decisamente meno ostico, sia da leggere che da scrivere, rispetto al C++. L’utilizzo ampiamente diffuso, il supporto efficace ed i continui aggiornamenti sono altri fattori che giocano a favore dell’adozione di POX come controller per la propria archi- tettura. Esso risulta infine appropriato per condurre studi, sperimentazioni e dimostrazioni, oltre ad essere un ottimo strumento per il primo apprendimento di soluzioni SDN.

D’altro canto, il linguaggio Python rende POX pi`u debole rispetto ad altri controller dal punto di vista delle performance. Lo scarto prestazionale viene evidenziato in figura 4.2, dalla quale emerge tuttavia il buon comportamento tenuto nei confronti di applicazioni NOX scritte in Python.

Ryu Da collocarsi nell’ambito dei controller implementati in Python, Ryu [31] `e una piattaforma open-source che supporta le versioni 1.0, 1.2 e 1.3 del protocollo OpenFlow, in aggiunta alle Nicira Extensions.

Cos`ı come accadeva per POX, anche Ryu paga un distacco in termini di per- formance nei confronti di altri controller SDN, a causa dell’utilizzo del linguaggio Python.

I punti di forza possono essere individuati nell’ampio spettro di versioni OpenFlow disponibili e nella compatibilit`a con OpenStack, un sistema operativo orientato al Cloud Computing, in grado di controllare le risorse di calcolo, di memoria e di rete all’interno di un DC.

1_{In software engineering, si ha una project fork quando degli sviluppatori si appropriano di} una copia del codice sorgente da un modulo per avviare un percorso di sviluppo indipendente, creando cos`ı una porzione di software distinta.

Ambiente di sviluppo 33

Figura 4.2: POX e NOX, confronti prestazionali

Floodlight Floodlight [25] `e un controller open-source, scritto in Java, che an- novera nella propria comunit`a di sviluppatori figure provenienti da Big Switch Networks, costantemente attive nell’identificazione e correzione di bug oltre che impegnate nell’implementazione di plug-in e funzionalit`a addizionali. Attual- mente, il controller supporta soltanto la versione 1.0 del protocollo OpenFlow.

La compatibilit`a con OpenStack e le ottime prestazioni ottenibili grazie al- l’adozione del linguaggio Java sono controbilanciate da una curva di apprendi- mento decisamente “ripida”.

Connotazione northbound

Utilizzando una piattaforma avente connotazione southbound, l’implementazio- ne di una policy si traduce nella progressiva installazione di numerose regole all’interno delle tabelle degli switch.

Un approccio di questo tipo, per quanto inevitabile, rende difficile la rea- lizzazione di funzionalit`a indipendenti. Se si decide (come risulta naturale) di scrivere pi`u moduli autonomi, ciascuno necessario per portare a termine un com- pito isolato, occorre assicurarsi che le regole installate da un componente non entrino in conflitto con quelle preparate da un altro. Inoltre, pi`u l’applicazione che ci proponiamo di realizzare risulta complessa, pi`u diventa pressante il biso- gno di disporre di un linguaggio di alto livello, ovvero di una piattaforma avente connotazione northbound, che consenta di distaccarsi dai dettagli strutturali dell’interfaccia utilizzata per comunicare con i dispositivi.

Pyretic Avendo ben presenti dette problematiche, Pyretic [30][47][48] inco- raggia i programmatori a concentrarsi su come specificare una policy di rete, seguendo un elevato livello di astrazione, piuttosto che su come implementarla tramite i meccanismi di basso livello forniti dal protocollo OpenFlow. Pyretic `e una piattaforma per lo sviluppo di applicazioni di controllo basata sul linguag- gio Python. Tale piattaforma si colloca all’interno del progetto Frenetic [24][46],

nell’ambito del quale gli autori hanno progettato un livello di astrazione sempli- ce e di alto livello per la programmazione di una SDN, assieme ad un runtime system per la generazione automatica di regole di basso livello da installare negli switch.

Con Pyretic, il programmatore specifica una policy valida per la rete nel suo complesso, tramite una funzione che mappa un Located Packet (LP), ovvero un pacchetto assieme alla propria posizione, in un insieme di LP. Le regole OpenFlow effettivamente utilizzate per spostare i pacchetti da un punto ad un altro non vengono mai prese in considerazione.

Se specificato dall’operatore, il comportamento tenuto da una policy pu`o essere fatto variare nel tempo. Si `e allora in presenza di una “policy dinamica” (dynamic policy).

Invece di fondere assieme numerose porzioni di codice, assicurandosi che non interferiscano mutumente, `e possibile combinare l’effetto di pi`u policy utilizzan- do i cosidetti policy composition operators.

• La Parallel Composition (PaC) fornisce l’illusione di pi`u policy che opera- no simultaneamente su copie separate degli stessi pacchetti. Formalmente, date due funzioni f e g che agiscono su un LP p, la PaC calcola l’unione tra gli insiemi f (p) e g (p).

• La Sequential Composition (SeC) fornisce l’illusione di un modulo che opera sui pacchetti prodotti da un altro. Formalmente, date due funzioni f e g che agiscono su un LP p, la SeC applica g ad ogni LP in f (p), producendo cos`ı un nuovo insieme di LP.

Sia la PaC che la SeC possono essere applicate indifferentemente a policy statiche o dinamiche.

Infine, Pyretic consente di distaccarsi dalla topologia in esame consenten- do all’utente di applicare le proprie policy ad una visione astratta della rete sottostante. Pi`u dispositivi reali possono essere trattati come un unico switch virtuale o, alternativamente, uno switch reale pu`o essere rappresentato come un insieme di dispositivi virtuali.