Separazione del piano di controllo dal piano dati: il modello Software Defined Networking

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Separazione del piano di controllo dal piano dati: il modello Software Defined Networking Anno Accademico 2012/2013 Candidato: Andrea Scafuto matr. N

2

3 Indice Introduzione 4 Capitolo 1. Software Defined Networking 1.1 Introduzione a SDN Architettura Attuale Benefici del SDN 9 Capitolo 2. OpenFlow 2.1 Introduzione ad OpenFlow Inside OpenFlow Sicurezza Web Application Mininet 27 Conclusioni 29 Bibliografia III

4 Introduzione La rapida evoluzione della Rete ha portato con sè un enorme cambiamento nella gestione della sua architettura e con l'avvento del Cloud Computing è stato necessario ridefinire una serie di servizi che la vecchia rete non era in grado di soddisfare, parliamo dunque di Software as a Service(SaaS), Data as a Service (DaaS) e nella maggior parte dei casi di Plattform as a Service (PaaS)[1]. In questi modelli, i cloud providers installano le proprie applicazioni direttamente nella «nuvola», gli utenti accedono quindi al software tramite cloud clients e con questo approccio i consumatori evitano di gestire l'infrastruttura e la macchina che esegue l'applicativo, eliminando di fatto problematiche riguardanti l'installazione, la compatibilità e il supporto, semplificando dunque il concetto stesso di applicazione. Si tratta quindi di nuovi servizi che hanno dato una vera e propria svolta alla vecchia visione del Web, ma che hanno causato un appesantimento di quest'ultimo. Oltre alla suddetta questione relativa al cloud dobbiamo aggiungere anche un'altra problematica: il mobile computing. Le reti oggigiorno diventano sempre più grandi e affollate, a causa anche dei dispostivi mobili che costituiscono infatti un'importante fetta del traffico web. Tablet e smartphone sono una realtà che è impossibile ignorare e i dati parlano chiaro : nel 2012 il 13 % di tutto il traffico internet è stato veicolato da dipositivi mobili [2]. Ci sono Paesi in cui il fenomeno «mobile» è predominante, come ad esempio in India dove il Traffico Internet mobile ha raggiunto il 60% superando di fatto quello proveniente dai computer desktop [fig 1.1]. Questo trend è destinato, secondo gli analisti, ad estendersi anche in altri Paesi, diventando un fenomeno globale. Tutto ciò impatta direttamente sulle prestazioni e sulla gestione (gestibilità) della rete, sempre più affollata e appesantita dai vari layers che caratterizzano l'architettura. E' nata la necessità di introdurre un nuovo Network Virtualization, che permetta di astrarre 4

5 e di disaccoppiare il livello dati dal controllo rete tramite un software, assicurando quindi un elevato grado di programmabilità e di controllo che sia in grado di garantire alle aziende del settore la possibilità di mantenere un'elevata scalabilità dei propri sistemi e al tempo stesso flessibilità per futuri upgrade. In questo modo le reti di calcolatori riescono a tenere il passo con i nuovi paradigmi tecnologici, adattandosi rapidamente alle nuove esigenze di business. Fig 1.1 India,Mobile internet Traffic Analysis 5

6 Capitolo 1 Software Defined Networking 1.1 Introduzione a SDN Il Software Defined Networking(SDN) è l'architettura di rete che ci permette di disaccoppiare il controllo della rete dall'instradamento, consentendo quindi la diretta programmabilità del primo grazie ad un controller. Il controller può essere implementato in modo centralizzato, il che permette di avere una visione totale della rete, o tramite approccio distribuito, rendendo dunque il software load balanced e meglio utilizzabile su reti di ampia scala. Il SDN inoltre, semplifica la vita sia delle società che producono apparati per il networking, sia il modo di comunicare dei dispositivi stessi, i quali non devono più preoccuparsi dei vari protocolli che si interfacciano, ma dovranno semplicemente seguire le istruzioni del controller SDN. Le aziende quindi dovranno di fatto aggiornare i loro prodotti con un firmware che permetterà di gestire il nuovo protocollo. Il tutto va ad agevolare l'archiettura della rete, che subirebbe una notevole semplificazione[fig 1.2]. Fig Rete Attuale 6

7 L'invio del singolo datagramma, sull'interfaccia di rete, non sarà eseguito dall'hardware del singolo dispotivo di rete, ma dal controller SDN, il quale può essere programmato per lavorare con diversi flussi di dati, in maniera del tutto trasparente agli altri layers[fig 1.3]. Fig SDN Network In questo modo si potrebbe pensare di implementare varie API che permetterrebbero di estendere le funzionalità della rete, aggiornando il software del nostro controller e garantendo così un ventaglio di servizi che altrimenti dovremmo gestire in maniera separata, incrementando quindi notevolmente la complessità della rete. Il tutto potrebbe essere confezionato tramite il classico firmware update che i produttori di hardware effettuano regolarmente. Tuttavia, per rendere effettivamente possibile tutto ciò, è necessario stardardizzare un unico protocollo basato su SDN che permetta di uniformare i vari dispostivi. A questo scopo è nata la Open Networking Foundation(ONF). Si tratta di un consorzio no-profit che promuove l'ecosistema SDN in tutto il mondo, cercando di rivoluzionare la struttura attuale di internet. Oltre ottanta compagnie hanno aderito all'iniziativa promossa, tra cui società come: network operators, ISP, fornitori di dispositivi per networking e numerose start-up. 7

8 1.2 Architettura Attuale La Rete è composta da vari layers di switch e router. Se inizialmente tale soluzione era praticabile dato il basso numero di utenti e servizi offerti, oggi, con un panorama sempre più caotico e disorganizzato, questo approccio non è più possibile[3]. In precedenza gran parte del traffico rete seguiva il paradigma client-server, successivamente però le cose sono cambiate : numerose entità sono entrate in gioco per l'accesso di un singolo servizio, come per esempio gli applicativi multiserver. Sono subentrate quindi esigenze che hanno portato alla luce i limiti della vecchia struttura, come ad esempio le soluzioni Cloud, dove il client si trova a comunicare con un gran numero di terminali per accedere ad un unico servizio integrato. I cloud providers dovranno quindi garantire trasparenza ai customers, assicurando un elevato grado di security ai propri dati e al tempo stesso un instradamento ottimale. Il problema duale possiamo notarlo nel mobile computing, dove il client non è più «statico», ma nell'arco di una stessa sessione può cambiare la propria rete di appartenenza agganciandosi a diversi Access Point. A queste problematiche possiamo aggiungere anche l'aumento del volume di dati in circolazione sulla rete. Lavoriamo infatti ogni giorno con i cosiddetti big data e ciò è dovuto alla rapida evoluzione delle infrastrutture telematiche, la quale ha dato sia alle grandi aziende di IT che ai piccoli consumatori la possibilità di fruire di un elevato quantitativo di dati. Di tutto questo ne risentono i network data center che devono servire un incredibile numero di richieste. In questo scenario l'instradamento dei pacchetti tra le due entità diventa fondamentale, poiché non è possibile valutare a priori su quale delle reti il terminale mobile si troverà. Altro elemento da analizzare, nell'architettura attuale, è il crescente utilizzo di servizi 8

9 basati su Server Virtualization. Grazie a questo espediente è possibile risparmiare notevolmente sui costi delle infrastrutture, consentendo di ospitare su una sola macchina più sistemi in esecuzione, gestendo anche diversi sistemi operativi. Gli ambienti di utilizzo di queste soluzioni sono i più disparati: passiamo infatti dagli internet providers, che offrono servizi web classici (mail, ftp, hosting, etc), all'ambito aziendale, dove le classiche postazioni desktop stanno lasciando spazio ai cosiddetti thin client, soppiantando di fatto il concetto di personal computer. Da questa breve analisi si evince che questi aspetti sono diventati i fattori trainanti di un trend che ha portato a rivedere l'architettura della rete in favore di una soluzione orizzontale che possa gestire anche le problematiche annesse a questi nuovi servizi, tra cui spicca quella della sicurezza. 1.3 Benefici del SDN L'adozione di questo nuovo standard permetterà di gestire in maniera centralizzata diversi dispositivi di rete prodotti dai vari vendor, migliorando di fatto l'automazione del nostro sistema grazie a dei «wrapper» che ci garantiscono di astrarre le applicazioni che utilizziamo quotidianamente. Tutto ciò ricade a vantaggio dell'affidabilità della Rete. Difatti, isolando il controllo dall'instradamento riusciamo ad ottenere un nuovo livello di affidabilità e di sicurezza. Servizi come Home Banking e Trading online diventano strutturalmente più protetti, tutelando i customer con un elevato grado di confidenzialità e integrità dei dati. 9

10 Il Software Defined Networking permetterà inoltre un miglioramento generale delle performance della rete attraverso la semplificazione dell'architettura. Inoltre la possibilità di gestire i data-flow e assicurerà all'utente una miglior esperienza finale[4].parliamo della possibilità di veicolare in maniera più efficiente traffico voce, dati e video sulla rete, relegando a questi flussi un livello reale di priorità. Questa nuova tecnologia nasce come un vero e proprio sistema operativo di rete che permette la comunicazione tra vari domini applicativi[fig 1.4]. Fig Network Os Il SDN tramite il relativo controller permette un notevole risparmio di tempo anche per la gestione della rete : amministratori e network operator, agendo su questo controller, potranno agire sulla rete modificando in tempo reale i flussi di dati. Quello che tempo fa veniva eseguito in settimane di lavoro è ora possibile farlo in poche ore, rispondendo dinamicamente alle esigenze della rete. Siamo in grado quindi di gestire, configurare e manutenere la rete operando direttamente sul controller centralizzato, o meglio sul software che lo gestisce. Tramite delle API possiamo quindi implementare i vari servizi di rete, andando in contro a quelle che sono le nostre finalità in termini di Business. 10

11 Tutto ciò si traduce in una minore spesa per Servicing della rete, dal momento che si riduce drasticamente l'intervento umano nella manutenzione, che può essere eseguita tramite software (limitando così anche i vari downtimes). Il maggior pregio di questa tecnologia comunque è l'immediata disponibilità di questo protocollo che molte aziende stanno già adottando e che può essere infatti facilmente integrabile nella struttura attuale. Sul mercato è gia possibile trovare numerosi apparati che dispongono di questa tecnologia e altri vendor stanno aggiornando la propria offerta, migrando verso questa soluzione. Parliamo di colossi del networking come Verizon, Cisco, ZTE e tanti altri che stanno investendo su quello che è il primo protocollo commerciale basato su tecnologia Software Defined Networking ovvero OpenFlow. Secondo recenti stime il mercato globale legato questa tecnologia passerà dagli attuali 198 milioni di dollari ai 2,10 miliardi nei prossimi 5 anni, cifre che hanno incoraggiato altri investitori a supportare SDN diventando una realtà che il settore deve prendere in considerazione.[5]. 11

12 Capitolo 2 OpenFlow 2.1 Introduzione a OpenFlow Quello che oggi chiamiamo Software Defined Networking nasce grazie agli sforzi di Nick McKeown e Scott Shenker, docenti di Informatica delle università di Stanford e Berkeley. Inizalmente il progetto, chiamato Ethane, fu avviato con lo scopo di migliorare la sicurezza delle rete grazie ad un nuovo protocollo flow-based.[6] Con Ethane i ricercatori volevano progettare una rete governata da «Policy» definite dai network administrators attuate poi dai vari switch della rete, come ad esempio una policy che permetteva ad un determinato utente di utilizzare solo http. Nei primi stadi di sviluppo Ethane permetteva sulla carta di ottenere diversi benefici rispetto allo scenario attuale : la possibilità di realizzare switch con hardware meno costoso, routing e gestione della sicurezza grazie ad un controller dedicato che gestisce i dati come flussi (Flow). Ogni flusso sulla rete deve ottenere i permessi dal controller, il quale verifica se la comunicazioni tra le entità in gioco è consentita dalla Policy. Se il controller quindi autorizza il flusso viene calcolata una route che verrà percorsa da quest' ultimo e sarà successivamente aggiornata la FlowTable di ogni switch presente sul percorso scelto. Con Ethane gli switch gestiscono semplicemente le FlowTable. Nello specifico, le entries di queste tabelle saranno popolate dai dati valutati dal controller che così facendo 12

13 permetteranno una semplificazione spostando tutta la complessità del lavoro su quest ultimo. I primi che si interessarono alla creazione di un nuovo protocollo di rete basato su SDN furono gli esperti della Open Networking Foundation(ONF) che diedero vita ad OpenFlow. Il protocollo ha ricevuto nel corso degli anni l'attenzione di importanti aziende dell'it come Google e Facebook, le quali implementano attualmente nei propri data center questa tecnologia. In particolare, il colosso di Mountain View si avvale dei servizi di OpenFlow per gestire meglio il carico della rete nei periodi di intenso traffico. La prima versione di OpenFlow fu definita nel dicembre del 2009, per poi arrivare alla versione 1.2 rilasciata nel Febbraio Nell'arco di questo periodo la Open Networking Foundation non ha avuto vita facile : nel gennaio del 2012 infatti un'indagine condotta da Gartner ha evidenziato quelli che sono i limiti del progetto, accostando OpenFlow alla famosa vicenda di ATM[7]. Nonostante le difficoltà OpenFlow è riuscito a conquistare i favori delle grandi aziende dell'it che ripongono grande fiducia in questo framework, a sostegno di tutto ciò troviamo i numerosi finanziamenti stanziati per l'ecosistema. Tra i vari colossi del Networking spicca HP che ha profuso un grade sforzo per la diffusione di questa tecnologia[8], portando sul mercato un notevole ventaglio di apparati che supportano OpenFlow :solo nel 2012 sono stati installati oltre 60 sistemi in tutto il mondo, l'80 % di questi situati tra Nord America ed Europa [fig 2 ]. Altre aziende stanno rilasciando nuovi firmware per supportare in maniera ibrida OpenFlow, in questo modo è possibile gestire sia il classico traffico che quello basato su tecnologia SDN. 13

14 Fig 2 - HP Openflow World market 14

15 2.2 Inside OpenFlow Analizzeremo in seguito come è realizzato uno switch che implementa il framework Open Flow[9]. Fig 2.1 OpenFlow Switch Attualmente l'inoltro dei pacchetti negli switch è eseguito tramite l'utilizzo di tabelle associative in hardware, realizzate con tecnologia CAM (Contenent adressable Memory) o TCAM. La soluzione proposta dal ONF non vuole sostituirsi a quella attuale, bensì si affianca per offrire nuovi strumenti per il management della rete. OpenFlow prevede l'utilizzo di un canale sicuro (secure channel) che permette la connessione dello switch al controller della SDN, una «Group Table» e più tabelle di flusso (Flow Table) [fig 2.1]. L'accesso al canale deve essere esclusivamente concesso al controller. Qualora terzi dovessero intercettare i dati o le istruzioni che il controller lancia sul canale ai vari switch verrebbe minata l'integrità del traffico, causando una modifica del flusso dei 15

16 dati su una determinata rete e prioritizzando un traffico malevolo. Le Flow Table sono popolate da entry che prevedono contatori, instructions per l'action set e una regola per il matching. Quest'ultima viene definita direttamente su alcuni campi dell'header del pacchetto, i quali vengono successivamente inseriti all'interno di uno specifico record definito OpenFlow Extensible Match (OXM), nel quale troviamo: Indirizzo IP Sorgente Indirizzo IP Destinatario Indirizzo Hw Sorgente Indirizzo Hw Destinatario Porto sorgente TCP o UDP L'utilizzo dell' OXM aumenta notevolmente la flessibilità e la rapidità di esecuzione, limitando le operazioni di gestione dei campi a favore di una struttura fissa che può essere opzionalmente estesa. Le instructions ci danno la possibilità di variare l'action set relativo ai pacchetti. Distinguiamo fondamentalmente 5 tipi di azioni classificate in 2 tipologie Required e Optional: Output : con la quale inoltriamo il pacchetto su una determinata porta dello switch o sul controller ; Set Queue : che viene utilizzato per impostare il queue ID di un pacchetto. Quando quest' ultimo sarà in seguito inoltrato su una determinata porta tramite l'istruzione Output, verrà schedulato secondo il valore della queue ID impostata 16

17 precedentemente ( questa istruzione viene utilizzata ad esempio per la Quality of Service (QoS)). Drop : di solito è usato per scartare determinati pacchetti. Group : processa i pacchetti per gruppo, ogni gruppo poi viene caratterizzato in maniera indipendente. Push-Tag/Pop-Tag : alcuni switch supportano le funzionalità di push/pop dei tags pricipalmente utilizzato per integrare OpenFlow con le vecchie reti. I contatori vengono utilizzati per gestire la durata di una regola all'interno della tabella. In pratica ad ogni regola viene associato un timer che ne stabilisce la validità. La regola verrà poi eliminata quando il contatore arriverà a zero. OpenFlow distingue inoltre due tipologie di messaggi : Controller/Switch (che sono inviati dal controller e possono usualmente anche non essere seguiti da una risposta dello switch) e Switch/Controller (che vengono invece inoltrati dallo switch verso il controller). I diversi tipi di messaggi Controller/Switch possono essere : Features : di solito lanciato in seguito alla creazione del canale OpenFlow, prevede che sia il controller ad inviare questo messaggio richiedendo risorse allo switch ; Configuration: viene utilizzato per settare o valutare i parametri di configurazione dello switch ; Modify/State : usati per gestire lo stato dello switch, comprendono sia servizi di QoS, cambiando quindi le proprietà delle porte dell'apparato di rete, sia il management della OpenFlow Table, aggiungendo, eliminando o modificando le entries ; 17

18 Read/State : impiegati per raccogliere informazioni statistiche dallo switch ; Packet-out : che inviano i pacchetti su una specifica porta dello switch e inoltrano quelli ricevuti attraverso il messaggio Packet-in ; Barrier request/reply : utilizzati per la gestione delle notifiche dei pacchetti che hanno completato le operazioni ; Role-Request : impiegato in particolari configurazioni del framework che prevede l'utilizzo di più Controller ; Vediamo ora i messaggi che invia lo switch verso il controller. Nello specifico questi cadono sotto il nome di Asynchronous Message : Packet-In : trasferisce il controllo del pacchetto al Controller. Flow-Removed : informa il controller della cancellazione di una entry della Flow Table. Error : lo switch può inoltre notificare errori al controller usando questo specifico messaggio. Port-status : comunica al controller del cambiamento di una porta per l'inoltro dei pacchetti, per esempio a causa di malfunzionamenti del link. In OpenFlow distinguiamo 3 differenti tipi di porte: Fisiche, Logiche e Riservate. Le prime corrispondo alle interfacce di rete che dispone fisicamente lo switch. Se stiamo parlando, per esempio, di uno switch Ethernet saranno le varie uscite RJ-45 che troveremo sul dispositivo. Le porte Logiche costituiscono un'astrazione e vengono utilizzate per implementare funzionalità esterne ad OpenFlow. Esse non corrispondono direttamente alle porte fisiche, 18

19 ma possono essere mappate su una di queste per implementare i vari servizi, il tutto in maniera trasparente ad OpenFlow (il protocollo infatti tratterà indistintamente le due tipologie di porte). Le porte logiche sono spesso utilizzate per l'incapsulamento dei pacchetti per la procedura del Tunneling.Le porte riservate sono utilizzate in modo esclusivo dal Controller e dagli altri componenti del framework. Analizziamo ora gli altri due elementi dello schema: Group Table e Flow Table. Una Group Table consiste in un insieme di entries, caratterizzate nel seguente modo: Group Idenfier : è una stringa di 32 bit che identifica univocamente un gruppo; Group Type : determina la tipologia del gruppo; Counters : vi è un timer che viene aggiornato quando i pacchetti son processati come gruppo; Action Buckets: costituiscono un insieme di istruzioni che deve eseguire il gruppo. 19

20 Le Flow Table invece sono strutturate con i seguenti moduli: Match fields: in questo campo troviamo la porta di ingresso e l'header del pacchetto; Priority : indica la priorità del flusso; Counters : implementano i contatori della tabella; Instructions : serve a modificare l'action-set della tabella; Timeouts: mostra la lifetime del flusso; Cookie: sono utilizzati dal controller per raccogliere dati statistici. 2.3 Security L'introduzione di OpenFlow, come tutte le innovazioni, offre sia benefici sia problematiche riguardo la gestione della sicurezza. L'adozione di questo protocollo risulta particolarmente vantaggiosa per differenti motivi. L'architettura tipica dei sistemi basati su SDN garantisce ad esempio agli amministratori di rete la possibilità di modificare le caratteristiche della rete molto velocemente rispetto alla 20

21 soluzione classica. Ciò si riflette su una gestione più efficiente della sicurezza: basti pensare al caso di un attacco di malware che viene rilevato su una porzione della nostra rete. Grazie a questo approccio centralizzato l'area infetta può essere facilmente isolata, dirigendo quindi il traffico sui nodi sicuri, successivamente poi si procederà col curare l'area attaccata. Ma le policy di rete di OpenFlow non offrono solo vantaggi in termini di sicurezza, permettono infatti anche una miglior gestione della privacy. Sappiamo bene che la natura stessa di IP rende difficile il controllo del routing dei dati, le informazioni contenute nei pacchetti IP prima di giungere a destinazione possono anche attraversare numerosi Paesi, con OpenFlow abbiamo per la prima volta la possibilità di assicurare che i dati privati rimangono all'interno dei confini nazionali. Gli ISP potranno quindi offrire nuovi servizi per tutelare i propri clienti, in particolare le aziende che da sempre hanno a che fare con queste problematiche. A beneficio anche della Quality of Service, che dispone di un metodo in grado di modellare il traffico in base alle esigenze degli utenti, immaginiamo uno scenario tipico: un traffico sensibile alla latenza, come per esempio uno streaming video, può seguire il percorso più breve, mentre i flussi caratterizzati da un'ingente quantità di dati prenderà un'altra strada, la fruizione dei contenuti diventa quindi molto più efficiente rispetto all'attuale scenario. Con OpenFlow si apre un nuovo capitolo per il networking, offrendo per la prima volta una programmazione semplificata della rete tramite un'interfaccia standard. Questa facilità di programmazione consente di creare un layer di controllo affidabile per centralizzare l'intelligence della rete. Si intuisce facilmente il fatto che il controller è il fulcro dell'intero ecosistema, di conseguenza è necessario prima di tutto tutelarlo. 21

22 L'accesso non autorizzato potrebbe infatti potenzialmente far cadere l'intera rete nelle mani degli attaccanti. E' necessario quindi verificare le connessioni tra il controller e i vari nodi della rete (switch), cosa questa che può essere realizzata tramite SSL o nella nuova versione TLS. La fase di inizializzazione del protocollo è molto semplice: lo switch avvia la connessione con il controller (conoscendone l'indirizzo IP) e stabilisce in seguito una comunicazione TLS o TCP. Nel caso di TLS sarà necessaria un'operazione preliminare per l'autenticazione sul canale tramite lo scambio di certificati basati su private-key. Successivamente le due unità si scambiano messaggi di controllo OFPT_HELLO per verificare la versione del protocollo operativa, altrimenti in caso contrario viene restituito un messaggio errore e la connessione termina. Nel caso in cui si verifichi un'interruzione della comunicazione tra Controller e Switch il sistema prevede due modalità di funzionamento: Fail Secure Mode e Fail Standalone Mode. Con la prima lo switch si limita a scartare tutti i pacchetti e i messaggi destinati al controller. In Fail Standalone Mode invece, lo switch funziona senza OpenFlow e quindi l'instradamento dei pacchetti dipenderà dalla logica implementata nel firmware del costruttore. OpenFlow prevede l'utilizzo di controller multipli per aumentare l'affidabilità e la tolleranza ai guasti/attacchi dell'intera rete.[fig 2.3] 22

23 Fig2.3 Controller Multipli Nell'evenienza in cui uno dei controller viene a mancare, può essere rapidamente sostituito da un altro che si sincronizza con tutti gli switch e riprende le varie operazioni. I vari controller possono funzionare secondo due modalità: Equal e Master/Slave. Con la prima modalità tutti i controller hanno accesso completo agli switch e di fatto vengono considerati tutti allo stesso modo dagli apparati di rete. Questa funzionalità viene implementata di default dal protocollo OpenFlow. Un controller poi può richiedere di lavorare in modalità Slave. Secondo questa configurazione l'unità di controllo ha accesso in sola lettura ai vari switch, di solito in questi scenari esiste sempre un controller che riveste il ruolo di Master, col quale è possibile avere accesso completo a tutti gli switch della rete. 23

24 2.4 Web Application Fig 2.4 Web Application layer Il controller, come abbiamo visto, è strutturato in maniera tale da proteggersi anche da eventuali attacchi, con OpenFlow ci stiamo quindi dirigendo sempre di più verso un Network Os che implementa servizi e un'interfaccia per la programmabilità della rete. La natura open source del protocollo apre la possibilità sia al mondo delle università che delle aziende di investire su nuove soluzioni per le reti[10]. Il Framework della Open Networking Foundation è un ecosistema completo sul quale è possibile scrivere per la prima volta delle Web Application. Introducendo una soluzione comune a tutti gli apparati di rete riusciamo ad abbattere anche i costi di sviluppo del software, al tempo stesso rendiamo la nostra architettura indipendente dai vari vendor. Abbiamo parlato in precedenza di API e applicazioni che possono essere scritte per implementare nuove funzionalità.[fig 2.4] 24

25 Attualmente non esistono app per le reti, ne tantomeno i numerosi vendor si adoperano per estendere le funzionalità dei propri dispostivi. Molti ritengono che la concausa principale di questa assenza è dovuto al fatto che le aziende produttrici di apparati per networking vogliono mantenere per i router lo status di risorsa critica. Grazie al framework OpenFlow è stato possibile per la prima volta scrivere applicazioni in grado di offrire nuovi servizi, quindi sia i ricercatori che le aziende possono muoversi in questa direzione per un cambiamento radicale del concetto di Network. Per esempio a Stanford è nato un progetto chiamato ElasticTree che ha come scopo valutare il dispendio energetico dei Data Center.[11] La gestione del consumo energetico è uno dei maggiori grattacapi per le aziende e purtroppo questo fenomeno risulta essere in continua ascesa. Causa diretta di questa impennata nei consumi è la crescente richiesta di nuovi servizi internet (IPTV, Voip, etc) che veicolano un grosso quantitativo di dati. Per fare un esempio, mediamente uno switch a 48 porte assorbe circa 150 W in idle, mentre quando è a pieno regime arriviamo ai 185 W. Capiamo quindi che il consumo è direttamente collegato al carico del dispositivo, potremmo quindi implementare un software che valuti il carico della rete e di conseguenza possa anche disattivare gli apparati e i link non utilizzati. Tutto ciò è già possibile realizzarlo grazie ad un tool che raccoglie le informazioni di un'applicazione basata su OpenFlow. Grazie a questi software riusciamo quindi a ridurre la spesa energetica delle aziende, e al tempo stesso renderle più verdi.con ElasticTree è stato possibile ridurre i consumi degli impianti sino al 60%, semplicemente spegnendo i link non utilizzati. 25

26 Il risparmio energetico è solo uno dei nuovi risvolti che offre OpenFlow, potremmo infatti pensare ad applicazioni che offrono un servizio di Load-Balancing e MPLS. OpenFlow ha catturato anche l'interesse di numerose start-up che stanno cercando di soddisfare quelle che sono le necessità della rete attuale. Fig 2.5 Load Balancer Aster*x si propone come un software che permette di offrire un servizio di Load Balancing distribuito alle reti basate su OpenFlow.[12] La gestione del traffico di rete sta diventando l'attività fondamentale per i fornitori di servizi internet, purtroppo nei sistemi attuali viene implementato tramite costosi apparati che aumentano l'overhead della rete stessa. Gli sviluppatori di Aster*x ritengono corretto gestire tale attività tramite il cosiddetto Smart Routing, in questo modo il Load Balancing diventa una primitiva del network grazie al controller che valuta i percorsi tra i vari nodi, e con un opportuno algoritmo può ridurre il carico di lavoro dei punti nevralgici della rete.[fig 2.5] 26

27 Nonostante queste premesse, alcuni esperti del settore non vedono ancora di buon occhio la soluzione proposta dall'open Networking Foundation, molti ritengono infatti che una soluzione così radicale possa compromettere l'intero stato della rete e per questo effettuare dei test per valutare la bontà del protocollo risulta essere una scelta obbligata Mininet Il Testing è una delle attività fondamentali nello sviluppo di una piattaforma IT e conosciamo bene gli sforzi economici necessari per affrontare tale procedura. In questo caso potremmo utilizzare un approccio basato sulla simulazione dei nodi della rete tramite macchine virtuali. Questo tipo di testing risulta estremamente valido, poiché ci permette di poter utilizzare più configurazioni differenti e al tempo stesso offrire un ambiente di analisi più realistico. Purtroppo però le reti sono costituite da numerose migliaia di nodi, di conseguenza l'elevato numero di nodi da virtualizzare innalza notevolmente i costi per la procedura di test rendendo possibile la soluzione virtualizzata solo in determinati ambiti (topologie piccole). E' sorta l'esigenza di sviluppare un ambiente per il testing che fosse in grado di emulare i nodi sulla rete e al tempo stesso ci permettesse le classiche operazioni di benchmarking. Per ovviare a queste problematiche è stato sviluppato Mininet. Si tratta di un simulatore che ci permette di prototipare le reti basate su tecnologia Software Defined Networking[13]. E' stato sviluppato da alcuni ricercatori dell'università di Stanford con l'intento di creare un ambiente di testbed facile da installare. 27