Software-defined networking

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

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 monitoring[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[2], scalabilità ed elasticità [3] 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[4] , 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 [5].

Storia

[modifica | modifica wikitesto]

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)[6]. Il ForCES Working Group propose successivamente un'aggiuntiva architettura chiamata SoftRouter[7]. Standard successivi che proponevano la separazione di control e data plane includono Linux Netlink as an IP Services Protocol[8] e A Path Computation Element (PCE)-Based Architecture[9].

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[10]. Al 2008 risale la creazione della prima API [11] e allo stesso anno risale la creazione di NOX, un sistema operativo per le reti[12].

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[13].

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[14].

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[15].

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

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[19].

Concetti fondamentali

[modifica | modifica wikitesto]

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[20].

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.

Componenti architetturali

[modifica | modifica wikitesto]
Descrizione ad alto livello di un'architettura SDN.

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

Applicazione SDN

[modifica | modifica wikitesto]

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.

Controller SDN

[modifica | modifica wikitesto]

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.

SDN Datapath

[modifica | modifica wikitesto]

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.

Interfaccia Control to Data Plane (CDPI)

[modifica | modifica wikitesto]

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.

Interfacce NorthBound (NBI)

[modifica | modifica wikitesto]

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.

Note

[modifica | modifica wikitesto]
  1. ^ Benzekki Kamal et al.Software‐defined networking (SDN): a survey., Security and Communication Networks 9, no. 18 (2016): 5803-5833.
  2. ^ Benzekki Kamal et al.Devolving IEEE 802.1 X authentication capability to data plane in software‐defined networking (SDN) architecture., Security and Communication Networks 9.17 (2016): 4369-4377.
  3. ^ Benzekki Kamal et al Software‐defined networking (SDN): a survey., Security and Communication Networks 9, no. 18 (2016): 5803-5833.
  4. ^ Software-defined networking is not OpenFlow, companies proclaim, su searchsdn.techtarget.com. URL consultato il 5 febbraio 2018 (archiviato dall'url originale il 5 febbraio 2018).
  5. ^ Predicting SD-WAN Adoption, su blogs.gartner.com, gartner.com, 15 dicembre 2015. URL consultato il 27 giugno 2016.
  6. ^ L. Yang (Intel Corp.), R. Dantu (Univ. of North Texas), T. Anderson (Intel Corp.) & R. Gopal (Nokia.), Forwarding and Control Element Separation (ForCES) Framework, su tools.ietf.org, aprile 2004.
  7. ^ T. V. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo, The SoftRouter Architecture (PDF), su conferences.sigcomm.org, Nov 2004.
  8. ^ J. Salim (Znyx Networks), H. Khosravi (Intel), A. Kleen (Suse), and A. Kuznetsov (INR/Swsoft), Linux Netlink as an IP Services Protocol, su tools.ietf.org, luglio 2003.
  9. ^ A. Farrel (Old Dog Consulting), J. Vasseur (Cisco Systems, Inc.), and J. Ash (AT&T), A Path Computation Element (PCE)-Based Architecture, su tools.ietf.org, agosto 2006.
  10. ^ Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, and Nick McKeown (Stanford University), Ethane: Taking Control of the Enterprise (PDF), su cs.brown.edu, agosto 2007.
  11. ^ N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner., OpenFlow: Enabling Innovation in Campus Networks (PDF), su ccr.sigcomm.org, aprile 2008.
  12. ^ N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker., NOX: Towards an Operating System for Networks (PDF), su benpfaff.org, luglio 2008.
  13. ^ GENI. Campus OpenFlow topology, su groups.geni.net, 2011.
  14. ^ Kuang-Ching “KC” Wang, Software Defined Networking and OpenFlow for Universities: Motivation, Strategy, and Uses (PDF), su internet2.edu, 3 ottobre 2011. URL consultato il 5 febbraio 2018 (archiviato dall'url originale il 3 gennaio 2018).
  15. ^ What are SDN Controllers (or SDN Controllers Platforms)?, su sdxcentral.com. URL consultato il 5 febbraio 2018 (archiviato dall'url originale il 28 gennaio 2018).
  16. ^ Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs Hölzle, Stephen Stuart and Amin Vahdat (Google), B4: Experience with a Globally-Deployed Software Defined WAN (PDF), su cseweb.ucsd.edu, agosto 12–16, 2013.
  17. ^ brent salisbury, Inside Google's Software-Defined Network, su networkcomputing.com, 14 maggio 2013. URL consultato il 5 febbraio 2018 (archiviato dall'url originale l'8 dicembre 2018).
  18. ^ Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, Amin Vahdat, Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network, su research.google.com, 2015.CS1 maint: Multiple names: authors list
  19. ^ Camille Campbell, Avaya Debuts Networking Innovations at 'Tech Field Day', su avaya.com, 6 febbraio 2014.
  20. ^ Software-Defined Networking (SDN) Definition, su Opennetworking.org. URL consultato il 26 ottobre 2014.
  21. ^ SDN Architecture Overview (PDF), su Opennetworking.org. URL consultato il 22 novembre 2014 (archiviato dall'url originale il 20 febbraio 2015).

Collegamenti esterni

[modifica | modifica wikitesto]
Controllo di autoritàLCCN (EN) sh2014000092 · J9U (EN, HE) 987007579386805171
  Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete
Estratto da "https://it.wikipedia.org/w/index.php?title=Software-defined_networking&oldid=140444694"