Nel nostro articolo precedente, abbiamo avuto una buona panoramica dell'SDN come tecnologia, perché è necessaria e come l'industria IT la sta adottando. Ora, approfondiamo un livello e comprendiamo l'architettura di SDN e il ruolo del protocollo Openflow nell'implementazione della tecnologia.
L'SDN è sostanzialmente costituito da tre livelli:
- Livello applicazione
- Livello di controllo
- Livello infrastruttura
Cerchiamo di comprendere questi livelli con un approccio dal basso verso l'alto.
Livello infrastruttura è composto da varie apparecchiature di rete che formano la rete sottostante per inoltrare il traffico di rete. Potrebbe essere un insieme di switch di rete e router nel data center. Questo livello sarebbe quello fisico su cui verrebbe impostata la virtualizzazione della rete attraverso il livello di controllo (dove i controller SDN si troverebbero a gestire la rete fisica sottostante).
Livello di controllo è la terra del piano di controllo in cui risiederebbe la logica intelligente nei controller SDN per controllare l'infrastruttura di rete. Questa è l'area in cui ogni fornitore di rete sta lavorando per creare i propri prodotti per controller e framework SDN. Qui in questo livello, molta logica aziendale viene scritta nel controller per recuperare e mantenere diversi tipi di informazioni di rete, dettagli sullo stato, dettagli sulla topologia, dettagli statistici e altro ancora.
Poiché il controller SDN serve per la gestione delle reti, deve disporre di una logica di controllo per casi d'uso della rete nel mondo reale come commutazione, routing, VPN L2, VPN L3, regole di sicurezza del firewall, DNS, DHCP e clustering. Diversi fornitori di reti e persino comunità open source stanno lavorando all'implementazione di questi casi d'uso nei loro controller SDN. Una volta implementati, questi servizi espongono le loro API (in genere basate su REST) al livello superiore (livello applicazione), cosa che semplifica la vita agli amministratori di rete che quindi utilizzano le app sopra i controller SDN per configurare, gestire e monitorare la rete sottostante. Il livello di controllo si trova nel mezzo ed espone due tipi di interfacce:Northbound e Southbound.
- Interfaccia in direzione nord :è pensato per la comunicazione con il livello superiore dell'applicazione e sarebbe generalmente realizzato tramite le API REST dei controller SDN. S interfaccia in uscita :è pensato per la comunicazione con il livello di infrastruttura inferiore degli elementi di rete e sarebbe generalmente realizzato tramite protocolli in direzione sud:Openflow, Netconf, Ovsdb, ecc.
Livello applicazione è un'area aperta per sviluppare il maggior numero possibile di applicazioni innovative sfruttando tutte le informazioni di rete sulla topologia della rete, lo stato della rete, le statistiche della rete, ecc. Possono essere sviluppati diversi tipi di applicazioni come quelle relative all'automazione della rete, alla configurazione della rete e gestione, monitoraggio della rete, risoluzione dei problemi di rete, politiche di rete e sicurezza. Tali applicazioni SDN possono fornire varie soluzioni end-to-end per le reti aziendali e di data center del mondo reale. I fornitori di rete stanno presentando il loro set di applicazioni SDN. Ad esempio, Brocade ha le seguenti applicazioni molto utili:
- Ottimizzatore di flusso di broccato
- Router virtuale broccato
- Consigliere di rete broccato
HPE è anche un fornitore che dispone di SDN App Store, che contiene anche molte app SDN di diverse aziende. Ad esempio:
- Ottimizzatore di rete HPE
- Protezione di rete HPE
- Visualizzatore di rete HPE
- NEC UNC per controller HP SDN VAN
- Bilanciatore del carico SDN di Aricent
- Direzione di flusso intelligente TechM
- Bilanciatore del carico del server TechM
Dopo aver toccato brevemente Openflow nell'articolo precedente, ora tratteremo i dettagli della comunicazione in direzione sud dal livello di controllo al livello dell'infrastruttura (switch di rete) tramite il protocollo Openflow.
Openflow è stato determinante nella rivoluzione dell'SDN, nel senso che è stato fondamentale per mostrare la separazione del piano di controllo dal piano dati. Openflow è la specifica standard fornita da Open Networking Foundation (ONF) e si sta evolvendo nel tempo con il supporto di vari requisiti delle attuali reti mondiali. La versione corrente del protocollo Openflow è la 1.5.1.
Openflow è un protocollo che fornisce specifiche standard per la comunicazione tra il controller SDN e le apparecchiature di rete (in genere switch). Consente di prendere decisioni di routing da parte dei controller SDN e lasciare che le regole di inoltro, le regole di sicurezza vengano inviate agli switch nella rete sottostante.
Il controller e gli switch SDN devono implementare le specifiche Openflow in modo che possano comprendere il linguaggio comune dei messaggi Openflow. Per controllare gli switch di rete, il controller SDN inserisce le regole negli switch in modo che possano prendere decisioni quando il traffico di rete li raggiunge. Gli switch devono mantenere tali regole nella tabella Openflow. Secondo Openflow, tali regole sono chiamate "flussi" e sono archiviate in "tabelle di flusso".
In generale, i flussi portano tre tipi di informazioni:
- Campi di corrispondenza:definiranno i criteri per abbinare i pacchetti in base ai loro campi di intestazione:L2 (indirizzi ethernet di destinazione di origine, ID VLAN, priorità VLAN, ecc.), L3 (IPv4/ Indirizzo di destinazione di origine IPv6, tipo di protocollo, DSCP e così via), campi L4 (porta di destinazione di origine TCP/UDP/SCTP), campi ARP, campi ICMP, campi MPLS e così via
- Azioni:definiranno cosa fare con un pacchetto se soddisfa i criteri. Le azioni sarebbero come rilasciare, inoltrare su una porta dello switch, modificare il pacchetto (ID VLAN push/pop, etichetta MPLS push/pop, incrementare/decrementare IP TTL), inoltrare a una coda di porta specifica, ecc.
- Contatori:per tenere traccia di quanti pacchetti corrispondono al flusso
Per essere precisi, i flussi contengono alcune informazioni in più che possono essere controllate ulteriormente nelle specifiche di Openflow.
Il canale o la connessione openflow è una configurazione tra switch e controller in modo che il controller possa comunicare con lo switch per configurarlo, gestirlo e monitorarlo. Secondo le specifiche di Openflow, Openflow viene eseguito su una connessione TCP o TLS e il controller è in ascolto per la connessione sulla porta 6653. Switch dovrebbe avviare la connessione e inviare la richiesta di connessione al controller.
Facoltativamente, la connessione può essere avviata anche dal lato controller e, in questo caso, lo switch sarà in modalità passiva per ascoltare la connessione. Sia da qualsiasi lato, sarebbe una normale configurazione della connessione TCP o TLS, una volta stabilita, i messaggi Openflow vengono scambiati tramite la connessione TCP o TLS. Ad esempio, di seguito è riportato il comando dello switch virtuale Openflow open source (OpenVswitch) per avviare la connessione TCP con il controller:
ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653
Qui, 192.168.56.101 è l'IP del controller e 6653 è la porta del controller su cui sarebbe in ascolto per la connessione.
Openflow definisce vari messaggi per abilitare la comunicazione tra switch e controller, inclusi messaggi di configurazione della connessione, messaggi di configurazione, messaggi di statistiche dello switch, messaggi keep-alive, messaggi di eventi asincroni, messaggi di errore, messaggi dello sperimentatore e altro ancora.
Cerchiamo di capire brevemente i messaggi di Openflow:
- Una volta stabilita la connessione TCP, il messaggio Openflow HELLO viene scambiato tra entrambe le entità per negoziare la versione Openflow su cui avverranno ulteriori comunicazioni. È necessario in quanto potrebbe essere possibile che lo switch e il controller siano in esecuzione su diverse versioni di Openflow. Entrambi concorderanno sulla versione più alta supportata.
- Al termine della negoziazione della versione, il controller invia prima un messaggio di richiesta di funzionalità Openflow per ottenere principalmente l'ID del percorso dati del messaggio di risposta al passaggio e per determinare quali funzionalità supporta lo switch.
- Per configurare switch per gestire il traffico di rete, messaggi Openflow come voci di flusso possono essere inviati dal controller. Questi sono mantenuti nelle tabelle di flusso all'interno degli interruttori.
- Per raggruppare le voci di flusso, i gruppi possono essere configurati dal controller tramite messaggi di gruppo che possono essere archiviati in tabelle di gruppo all'interno degli switch.
- Per ottenere i dettagli delle statistiche da switch, messaggi Openflow come statistiche di flusso, statistiche di porta, statistiche di coda, statistiche di gruppo, statistiche di tabella, ecc. possono essere inviati dal controller.
- Per verificare la vitalità della connessione, la richiesta di eco e la risposta, i messaggi Openflow possono essere inviati dal controller o dallo switch.
- Messaggi asincroni Openflow come la rimozione della regola di flusso dallo switch, l'applicazione di errore di configurazione dallo switch, lo stato della porta su/giù dallo switch e così via possono essere inviati dallo switch al controller di aggiornamento.
Finora, abbiamo esaminato l'architettura SDN, i suoi livelli e il ruolo di Openflow per realizzare il principio fondamentale SDN per separare il piano di controllo dal piano dati. Ora dobbiamo vedere come il controller potrebbe utilizzare Openflow per configurare e gestire la rete sottostante.
Fondamentalmente, il controller dovrebbe implementare un codice plug-in di Openflow con il quale può inviare, ricevere e comprendere messaggi Openflow da e verso gli switch Openflow nella rete sottostante.
Per configurare gli switch Openflow, il controller deve inserire le regole di flusso nelle tabelle di switch Openflow in base alle quali quest'ultimo può gestire il traffico di rete che li colpisce. Il messaggio Openflow per le voci di flusso ha un ampio set di campi tuple per criteri di corrispondenza (campi L2, L3, L4, ecc.) Di pacchetti provenienti dalla rete, che nel complesso aiuterebbero a configurare le regole ACL, le regole dei criteri di sicurezza, le regole di larghezza di banda di limitazione della velocità QoS, regole di routing, regole di mirroring delle porte e regole di modifica dei pacchetti.
Per monitorare gli switch Openflow, Openflow fornisce vari messaggi di richiesta e risposta per recuperare informazioni sulle statistiche di switch e di rete e messaggi di eventi per aggiornare il controller in merito a modifiche manuali o guasti avvenuti sul lato switch, inclusi l'evento di rimozione del flusso, le modifiche UP/DOWN dello stato delle porte e altro ancora.
Per eseguire alcune attività specifiche del fornitore sugli switch Openflow, Openflow fornisce messaggi sperimentali in cui i fornitori hanno la libertà di definire il corpo del messaggio e scambiare informazioni personalizzate tra controller e switch. È così che Openflow viene utilizzato da molte applicazioni SDN per fornire soluzioni per un facile controllo e gestione della rete.
This article is co-authored by Tarun Thakur.
Riferimenti:
- https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
- https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
- http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/