Software-defined networking

La tecnologia Software-defined networking (SDN) costituisce un nuovo approccio in ottica cloud computing alle architetture di rete, che ne facilita l'amministrazione e la configurazione al fine di migliorarne performance e facilitarne il monitoraggio^[1].

SDN suggerisce di centralizzare l'intelligenza di rete in un componente separato, disassociando il processo di forwarding dei pacchetti (data plane) da quello di routing (control plane). Il control plane è costituito da uno o più controller che sono considerati il cervello della rete, in cui è incorporata tutta l'intelligenza. Tuttavia, la centralizzazione dell'intelligenza della rete ha i suoi svantaggi riguardo a sicurezza^[1], scalabilità ed elasticità^[1] e rappresenta oggi il maggior difetto delle tecnologie SDN.

SDN è stata comunemente associata al protocollo OpenFlow (per la comunicazione remota con elementi di network plane allo scopo di determinare il percorso dei pacchetti di rete attraverso gli switch della rete) a partire dalla nascita di quest'ultimo nel 2011. A partire dal 2012^[2], tuttavia, molte compagnie hanno abbandonato OpenFlow e adottato tecniche differenti. Tra queste si possono ricordare Open Network Environment di Cisco Systems e Network Virtualization Platform di Nicira.

SD-WAN applica tecnologie simile alle reti WAN^[3].

La storia dei principi SDN può esser fatta risalire alla separazione tra control e data plane inizialmente utilizzata nella rete telefonica fissa per semplificare il provisioning e la gestione, molto prima che tale architettura venisse utilizzata nelle reti dati.

Le prime proposte di IETF di disaccoppiare le funzioni di controllo e di forwarding, risalgono ad una proposta di interfaccia standard pubblicata nel 2004 con il nome “Forwarding and Control Element Separation” (ForCES)^[4]. Il ForCES Working Group propose successivamente un'aggiuntiva architettura chiamata SoftRouter^[5]. Standard successivi che proponevano la separazione di control e data plane includono Linux Netlink as an IP Services Protocol^[6] e A Path Computation Element (PCE)-Based Architecture^[7].

Questi primi tentativi non riscossero successo per due motivi: il rischio insito nella separazione tra dati e controllo per gran parte della comunità internet, e la preoccupazione da parte dei vendor che la creazione di API standard tra control e data plane avrebbe potuto portare ad una maggiore concorrenza.

L'utilizzo di software open source in architetture che prevedono lo split tra dati e controllo, risale al Progetto Ethane del dipartimento di informatica di Stanford. La semplicità delle funzioni di switch in Ethane ha infatti portato alla creazione di OpenFlow^[8]. Al 2008 risale la creazione della prima API^[9] e allo stesso anno risale la creazione di NOX, un sistema operativo per le reti^[10].

Il lavoro su OpenFlow continuò a Stanford, portando alla creazione di banchi di prova per testare l'utilizzo del protocollo all'interno di un campus, e attraverso la WAN come backbone per connettere più campus^[11].

A partire dal 2009, in ambito accademico, cominciarono ad essere sviluppate reti basate su switch OpenFlow da NEC e Hewlett-Packard, così come su prototipi Quanta Computer^[12].

Al di fuori dell'ambito accademico, i primi sviluppi si devono a Nicira nel 2010 per controllare OVS (Open vSwitch) da Onix, sviluppato insieme ad NTT e Google^[13].

Al 2012 risale lo sviluppo di B4 da parte di Google^[14][15], che, successivamente, ha riconosciuto il primo sviluppo di OpenFlow con Onix all'interno dei propri data center^[16].

Nel 2011 fu fondata la Open Networking Foundation per promuovere lo sviluppo e l'utilizzo di OpenFlow e della tecnologia SDN.

Nel 2014, durante il Tech Field Day, Avaya ha tenuto una dimostrazione di tecnologia SDN utilizzando shortest path bridging (IEEE 802.1aq) insieme ad orchestration OpenStack per presentare una soluzione di software-defined datacenter^[17].

L'architettura SDN nasce con l'intento di essere dinamica, gestibile, economicamente efficiente e adattabile, cercando di essere funzionale per la natura dinamica e ad alto consumo di banda delle applicazioni odierne. Le architetture SDN disaccoppiano il controllo di rete e le funzioni di forwarding, dando la possibilità al controllo di rete di divenire direttamente programmabile e alla sottostante infrastruttura di essere astratta dalle applicazioni e dai servizi di rete^[18].

Il protocollo OpenFlow può essere utilizzato nelle tecnologie SDN. L'architettura SDN è:

• Direttamente programmabile: il controllo della rete è direttamente programmabile perché è disaccoppiato dalle funzioni di forwarding.
• Agile: L'astrazione del controllo dal forwarding permette agli amministratori di modificare dinamicamente il flusso di traffico nell'intera rete per soddisfare le necessità di cambiamento.
• Gestita centralmente: L'intelligenza della rete è (logicamente) centralizzata all'interno dei controller SDN che mantengono una vista globale della rete, la quale appare alle applicazioni ed ai motori di policy come un unico switch logico.
• Programmaticamente configurata: SDN permette ai gestori della rete di configurare, gestire, rendere sicure e ottimizzare le risorse di rete in maniera molto veloce attraverso script automatizzati che essi stessi possono scrivere, in quanto non devono basarsi su software proprietario.
• Basata su standard aperti e indipendente dai vendor: Se implementata attraverso standard aperti, SDN semplifica il disegno e manutenzione della rete poiché le istruzioni sono fornite dai controller SDN invece che da molteplici dispositivi e protocolli proprietari.

La seguente lista identifica e definisce i principali componenti di un'architettura SDN^[19]:

Le applicazioni SDN sono programmi, che, in maniera esplicita, diretta e programmatica comunicano i propri requisiti di rete e desiderata circa il comportamento della rete ai controller SDN attraverso la Northbound Interface (NBI). Inoltre, essi possono mantenere una vista astratta della rete per i propri scopi.

Una applicazione SDN è formata da una SDN Application Logic e da uno o più driver NBI.

Le applicazioni SDN possono esse stesse esporre un altro layer di controllo astratto di rete, mostrando una o più interfacce NBI di alto livello attraverso i rispettivi agenti NBI.

Il controller SDN è un'entità logicamente centralizzata con il compito di

1. Tradurre i requisiti provenienti dall'Application Layer SDN verso il Datapath SDN.
2. Fornire alle Applicazioni SDN una vista astratta della rete (che può includere statistiche ed eventi).

Un controller SDN è formato da uno o più agenti NBI, la SDN Control Logic, ed i driver di Interfaccia Control to Data-Plan (CDPI).

La definizione di Controller SDN come un'entità logicamente centralizzata non prescrive ne' preclude dettagli di implementazione come la federazione di controller multipli, la connessione gerarchica tra controller, interfacce di comunicazione tra controller, ne' la virtualizzazione o slicing di risorse di rete.

Il Datapath SDN è un dispositivo logico di rete che espone visibilità e controllo sulle sue capacità offerte di forwarding ed elaborazione dati. La rappresentazione logica può comprendere tutte o parte delle risorse del sub-strato fisico. Un Datapath SDN comprende un agent CDPI ed un insieme di una o più dispositivi di forwarding del traffico e nessuna o più funzioni di elaborazione del traffico. Questi possono includere il semplice forwarding verso le interfacce esterne, l'elaborazione interna del traffico o funzioni di terminazione.

Uno o più SDN Datapath possono essere contenuti all'interno di un unico (dal punto di vista fisico) elemento di rete, una combinazione fisica integrata di risorse di comunicazione, gestite in maniera unitaria. Un Datapath SDN può anche essere definito attraverso elementi di rete fisici multipli.

Questa definizione logica non prescrive ne' preclude dettagli di implementazione come la mappatura logica-fisica, la gestione delle risorse fisiche condivise, la virtualizzazione o slicing del Datapath SDN, interoperabilità con elementi non SDN, ne' le funzionalità di elaborazione dati, che possono includere funzionalità di livello 4-7 del modello OSI.

La SDN CDPI è l'interfaccia definita tra un controller SDN ed un SDN Datapath, che offre almeno

1. Controllo programmatico di tutte le operazioni di forwarding
2. Esposizione delle capacità sottostanti
3. Reporting statistico
4. Notifica di eventi

Uno dei principi di SDN è l'aspettativa che CDPI sia implementato in maniera aperta, neutrale rispetto ai vendor ed inter-operabile.

SDN NBIs sono le interfacce tra le applicazioni SDN e i controller SDN e tipicamente forniscono una vista astratta della rete ed abilitano l'espressione diretta del comportamento della rete ed i suoi requisiti. Ciò si può verificare a qualunque livello di astrazione (latitudine) e attraverso diversi insiemi di funzionalità (longitudine). Uno dei principi di SDN è l'aspettativa che queste interfacce siano implementate in maniera aperta, neutrale rispetto ai vendor ed inter-operabile.

• Definizione di SDN sul sito della Open Networking Foundation, su opennetworking.org.
• Corso di SDN su Coursera, su coursera.org (archiviato dall'url originale il 7 febbraio 2018).
• Abilitazione di NFV tramite OpenFlow SDN (PDF), su opennetworking.org (archiviato dall'url originale il 14 luglio 2014).
• Aspetti di sicurezza in Data Center su rete SDN (PDF), su opennetworking.org (archiviato dall'url originale il 14 luglio 2014).

Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete