La comunità open source SDN approva il codice dei controller e ora accetta contributi per i componenti e i servizi aggiuntivi.
Tre mesi dopo la nascita dell’OpenDaylight Project, la comunità open source SDN (Software Defined Networking) ha approvato il codice relativo ai controller SDN e ora accetta i contributi per i componenti aggiuntivi, come i servizi di mappatura per la gestione del flusso di traffico.
Fino a poco tempo fa, la maggior parte delle chiacchiere su OpenDaylight era concentrata sul fatto che il processo di scelta del codice relativo ai controller sarebbe stato dominato dai fornitori più grandi e più danarosi, in particolare Cisco. A riprova di questo, nel mese di giugno, lo specialista di tecnologie SDN Big Switch si era dimesso dal suo ruolo di leadership dell’organizzazione, accusando la tecnologia del consorzio di essere troppo Cisco-centrica.
La panoramica dei controller OpenDaylight
L’organizzazione ha raggiunto un consenso piuttosto ampio sulla strategia di sviluppo di un controller che è diventata nota come la “proposta Dixon-Erickson” (così chiamata dal cognome dei contributori Colin Dixon, un ricercatore di IBM, e David Erickson, un ricercatore della Stanford University). La proposta combina elementi di contribuzione al codice forniti da Big Switch, Cisco e altri vendor.
Lo schema di progettazione del controller si basa su un livello di astrazione dei servizi che utilizza il linguaggio dell’interfaccia Java Open Service Gateway Initiative (OSGi) in abbinamento a interfacce di programmazione delle applicazioni (API) più comuni per abilitare i plug-in utili a creare applicazioni modulari. In alcuni casi, queste applicazioni – chiamate bundle – costituiranno delle caratteristiche chiave del controller, come la virtualizzazione di rete, ma risiederanno all’esterno del controllore centrale. Altre caratteristiche, come ad esempio l’autorizzazione dell’utente, saranno incorporate nel controller.
Sopra questo strato software ci sono delle API aperte verso l’alto, sulle quali potranno essere costruite altre applicazioni. Questo schema differisce dallo sviluppo tipico della rete software defined dove tutte le applicazioni, come ad esempio i servizi Layer 4-7, giacciono sopra una semplice API aperta verso l’alto. Erickson sostiene che “in generale ci sono alcune applicazioni e funzionalità di base che devono esistere obbligatoriamente all’interno del controller”, come quelle relative alla scoperta dei device e dei codici (device and code discovery). A questo punto, però, il consorzio sta ancora cercando di capire “quali funzionalità debbano essere incluse nel controller e quali possono, invece, esistere nel bundle OSGi” o come modulo caricabile, chiarisce David Meyer, Chief Technology Officer e Chief Scientist di Brocade, nonché Presidente del comitato direttivo tecnico di OpenDaylight.
Se le funzioni sono integrate nel controller, rimane aperta la questione di capire quale margine di libertà potranno avere gli utenti di queste applicazioni e servizi nell’intervenire sul controller stesso.
Lo scopo di un’API aperta è quello di incoraggiare lo sviluppo di applicazioni creative, non di imbrigliare i clienti all’offerta di un singolo vendor. “Noi non vogliamo mettere del codice specifico del progetto nel controller – sostiene Meyer -. Ma se la presenza del codice può aiutare lo sviluppo di altri progetti, allora può valere la pena incorporarlo”.
Finora sono stati presentati alcuni progetti aggiuntivi, chiamati “boot-strap”, che potrebbero in futuro essere parte del controller oppure vivere come bundle. NEC ha presentato la sua piattaforma Virtual Tenant Network, una soluzione di virtualizzazione e provisioning delle reti. IBM ha sviluppato la sua piattaforma di virtualizzazione di rete, battezzata DOVE. ConteXtream ha proposto un elenco di servizi di mappatura utili a creare soluzioni di gestione dei flussi in stile NFV (Network Functions Virtualization). Altre proposte includono un sistema di rilevamento delle intrusioni e uno strumento di modellazione YANG che potrebbe essere utilizzato al fine di creare servizi di astrazione piuttosto elementari.
Poiché questi progetti sono piuttosto controversi, OpenDaylight formerà un gruppo consultivo di utenti che potrà utilizzare il codice e anche sottomettere alla comunità nuove funzionalità su base continuativa, chiarisce Jim Zemlin, Direttore Esecutivo della Linux Foundation, che ospita OpenDaylight. L’obiettivo per i membri, ha detto, non dovrebbe essere quello di ottenere l’incorporazione del codice, ma piuttosto di spingere la diffusione e l’adozione di qualsiasi codice migliori i progetti coinvolti.
In definitiva, nelle intenzioni di OpenDaylight si arriverà a un momento in cui ci sarà una versione integrata del codice del controller e diverse applicazioni o funzioni boot-strap.
Secondo Meyer, il controller e le prime funzionalità saranno già disponibili a partire dal prossimo mese di dicembre.
