Il SDN e le sue sinergie con la Network Function Virtualization

Il SDN (Software Defined Networking) è una proposta di organizzazione dell’architettura di rete, in cui lo strato di controllo è disaccoppiato da quello di forwarding e diviene programmabile. Le funzionalità di controllo, finora strettamente legate a dispositivi di rete implementati secondo un approccio “monolitico", migrano a tendere verso uno strato di controller SDN o “sistema operativo di rete” (Network OS) separato. I principi di astrazione introdotti dal modello e la definizione di relative interfacce di programmazione API (Appplication Programming Interface) tra gli strati dell’architettura mirano a consentire alle applicazioni di definire i servizi di rete tramite una vista logica della rete stessa, astraendo dalle specificità dei singoli dispositivi. La Figura A riporta una vista logica dell’architettura SDN, secondo l’attuale visione della Open Networking Foundation, principale ente impegnato nella definizione di standard per il mondo SDN. L’interfaccia tra il controllo e i dispositivi del data plane è costituita, in questo caso, dal protocollo OpenFlow, tuttavia questo protocollo non è l’unica possibilità di implementazione della cosiddetta API “SouthBound”.

 

Figura A - Architettura SDN (Fonte: ONF, Open Networking Foundation)

 

Lo strato dei controller SDN ha, tra gli altri, il compito di mantenere una vista globale della rete, sollevando le singole applicazioni dall’onere di ricostruire la topologia, permettendo loro di concentrarsi sui loro obiettivi specifici, quali ad esempio il calcolo degli instradamenti secondo opportune policy o di percorsi in grado di soddisfare a criteri di traffic engineering.
I benefici attesi da un’evoluzione verso il paradigma SDN sono da ricercare in una riduzione dei costi dei dispositivi di rete (CapEx), grazie ad una maggiore segmentazione del mercato, e dei costi operativi (OpEx), grazie ad una semplificazione dell’architettura di rete e delle procedure di gestione. Inoltre ci si aspetta che la programmabilità dell’infrastruttura di rete, attraverso interfacce aperte e standard, consenta di incrementarne la flessibilità e accelerare l’introduzione di nuovi servizi.
SDN ed NFV rappresentano due approcci complementari, e per molti versi interdipendenti, destinati a trarre beneficio da una loro integrazione nell’evoluzione della rete. Non a caso ormai quando si cita uno di questi due modelli, si assume spesso implicitamente una combinazione delle due tecnologie piuttosto che l’uso esclusivo di una delle due soluzioni.
Mentre il principale obiettivo di NFV è la realizzazione in modalità virtualizzata delle funzionalità di rete, le tecnologie SDN si candidano a giocare un ruolo fondamentale nel fornire all’Operatore la flessibilità nel controllo e nella programmazione flessibile della connettività nella rete sottostante, per combinarle in un’architettura di servizio. Infatti, il dispiegamento delle soluzioni NFV richiede di essere supportato da meccanismi potenti ed efficienti per la gestione dinamica della connettività, sia sul piano fisico che virtuale, per collegare tra di loro le funzionalità di rete virtualizzate VNF (Virtual Network Function).
Questo è il proprio il ruolo a cui la tecnologia SDN si presta naturalmente. Il controllo flessibile e dinamico della connettività e dell’inoltro del traffico attraverso la rete può sfruttare la programmabilità introdotta dall’architettura, che consente di supportare in modo efficiente e generalizzato i requisiti di policy routing, ovvero la possibilità di controllare il percorso dei flussi di traffico, introducendo le necessarie eccezioni alla logica di default dello “shortest path routing”. Per queste ragioni, una delle applicazioni di SDN che, ad oggi, rivestono particolare importanza è rappresentata dal “service function chaining”1, ovvero dell’inserimento sul percorso di forwarding del traffico di un numero di NF (Network Function) destinate a svolgere funzioni di servizio (es. firewall, DPI, ecc.).
In questo senso SDN rappresenta un ideale complemento ad NFV per definire la connettività tra le funzioni di rete al fine di realizzare il collegamento tra le Network Function richiesto dall’architettura del servizio. Le funzionalità (Figura B) posso essere realizzate da apparati fisici dedicati (NFx) o implementate in forma virtualizzata (VNFx), e possono essere ospitate su server presenti nel POP dell’edge di servizio o in data centre di rete. La possibilità di programmare in modo flessibile il percorso dei flussi di traffico attraverso le NF, ovvero di instaurare quello che nell’architettura NFV viene definito come “network function forwarding graph” (NF-FG) è quindi un elemento chiave della soluzione e la tecnologia SDN il modo per realizzarlo, con la possibilità di riconfigurare in modo dinamico e flessibile la connettività se ad esempio nel grafo del servizio deve essere inserita una nuova funzione o se una VNF migra in una diversa locazione di rete. 

 

Figura B - Service function chaining

 

Su questi principi architetturali di integrazione tra SDN ed NFV si registra ormai una convergenza molto ampia dell’industria. La flessibilità del modello SDN sembra offrire l’approccio adatto alle esigenze di controllo della connettività di rete. Un aspetto su cui invece assistiamo ancora alla proposta di soluzioni tecniche in parte diversificate è relativo all’implementazione del “forwarding graph” nel data plane. Le principali alternative al riguardo infatti consistono nell’uso:

  1. di OpenFlow per programmare le tabelle di forwarding dei dispositivi di rete;
  2. di meccanismi di tunneling utilizzati tipicamente per creare overlay di servizio sull’infrastruttura di rete;
  3. di nuovi meccanismi di incapsulamento dei pacchetti, quali la tecnica dei NSH (Network Service Header), proposta di recente in ambito IETF (Internet Engineering Task Force).

Ognuna delle alternative ha naturalmente punti di forza e limiti, siano essi la scalabilità o la mancanza di una standardizzazione, ed è auspicabile che con il maturare delle proposte si converga verso soluzioni interoperabili.

 

Torna all'articolo