Canali OpenFlow

Il canale OpenFlow è il mezzo attraverso il quale il controller e lo switch possono scambiarsi informazioni. L’associazione tra un controller e uno switch non è necessariamente di tipo uno-a-uno. È infatti possibile che uno switch possa essere gestito contemporaneamente da più controller in caso di clustering per soddisfare i requisiti di high availability e scalability. In caso di controller multipli i canali di comunicazione sono esclusivi, ogni controller ha un canale di comunicazione dedicato con ciascun switch.

L’interazione tra un controller e uno switch può essere di tre tipologie: • Controller-to-switch.

42

• Asynchronous. • Symmetric.

La comunicazione Controller-to-switch parte dal controller e può essere sincrona o asincrona. Di questa tipologia fanno parte quei messaggi che son- dano le funzionalità, le configurazioni o lo stato di uno switch. Il messaggio più importante impiegato in questo tipo di comunicazione è sicuramente il messaggio di inoltro di un pacchetto che consente l’instradamento. In detta- glio i messaggi scambiati utilizzando questo tipo di comunicazione sono:

• Features: con questo messaggio il controller può richiedere allo switch logico di ottenere informazioni basilari come la sua identità e quali funzionalità è in grado di supportare. Questo tipo di richie- sta è comunemente effettuata in fase di inizializzazione del canale OpenFlow.

• Configuration: il controller può leggere e scrivere parametri di configurazione presenti all’interno dello switch.

• Modify-State: messaggio inviato dal controller per la gestione dello stato corrente degli switch. Lo scopo principale di questo messaggio è l’aggiunta, rimozione o modifica di Flow Entry e Group Entry, l’aggiunta o rimozione di action bucket nelle Group Entry e la manipolazione delle proprietà associate alle porte dello switch.

• Read-State: messaggio impiegato dal controller per ottenere infor- mazioni dallo switch quali configurazione corrente, dati statistici e funzionalità supportate.

• Packet-Out: tramite questo messaggio il controller ha l’abilità di iniettare pacchetti nel data plane di uno switch e di specificare quale porta di uscita dovrà utilizzare per l’inoltro di tali pacchetti. • Barrier: utilizzato dal controller per assicurarsi che le dipendenze

richieste da alcuni messaggi siano rispettate e per ricevere da parte dello switch notifiche di completamento delle operazioni di inte- resse.

• Role-Request: utilizzato dal controller per impostare o richiedere il ruolo del suo canale OpenFlow o il proprio Controller ID. Utile nell’eventualità in cui uno switch sia associato a più di un control- ler.

43 La comunicazione di tipo Asynchronous parte su iniziativa dello switch, il quale può inviare al controller aggiornamenti sullo stato corrente delle sue risorse. Messaggi relativi allo stato possono riguardare ad esempio le porte e i flussi, fa parte di questa categoria anche l’invio di un pacchetto al controller. I messaggi appartenenti a questa tipologia sono:

• Packet-in: il messaggio di tipo Packet-In è il modo che uno switch ha a disposizione per inviare un pacchetto in attraversamento al controller. Ci sono due motivazioni che portano all’utilizzo di que- sto messaggio: potrebbe esserci un’azione esplicita di invio del pacchetto al controller risultante da un match nella Flow Table op- pure nel caso in cui lo switch non ha informazioni a sufficienza su come trattare il pacchetto in questione e demanda il suo processa- mento al controller.

• Flow-removed: notifica il controller dell’avvenuta rimozione di una Flow Entry in una Flow Table. Questo messaggio viene inviato come risposta in caso di richiesta esplicita di rimozione della Flow Entry da parte del controller oppure a seguito della scadenza di uno dei time-out associati al flow.

• Port-status: il comportamento che si aspetta da uno switch è quello di notificare il controller ogni qual volta la configurazione o lo stato di una porta cambia, ad esempio a causa di un intervento manuale dell’utente o di una caduta improvvisa di un link.

• Role-Staus: informa il controller sulla modifica del suo ruolo. Quando un nuovo controller si elegge master autonomamente, lo switch deve inviare questo messaggio al controller precedente. • Controller-status: comunica al controller un cambiamento nello

stato di un canale OpenFlow. Questo messaggio risulta particolar- mente utile per supportare la procedura di failover nel caso i cui i controller non fossero più in grado di comunicare tra loro.

• Flow-monitor: messaggio inviato al controller in caso di modifica di una Flow Table.

L’ultima tipologia di comunicazione, Symmetric, può essere iniziata dal controller o da uno switch ed è utile per lo scambio di informazioni di con- trollo. I messaggi appartenenti a tale categoria sono:

• Hello: messaggio scambiato tra switch e controller durante il pro- tocollo di inizializzazione della connessione.

44

• Echo: messaggio inviato dal controller o dallo switch a cui segue obbligatoriamente un messaggio dello stesso tipo in risposta, utile per assicurarsi la presenza della connessione tra controller e switch o per misurare la latenza o la larghezza di banda della connessione. • Error: consente ad uno dei due end-point della connessione di no-

tificare all’altro il verificarsi di un errore. Spesso impiegato da uno switch per notificare il controller del fallimento di una sua richie- sta.

• Experimenter: fornisce una modalità standard per consentire agli switch OpenFlow di scambiare con il controller messaggi apparte- nenti a funzionalità non ancora parte della specifica.

Per la comunicazione tra controller e switch, OpenFlow garantisce la con- segna di tutti i messaggi inviati, che possono essere raggruppati in messaggi

Bundle. Per quanto invece riguarda l’ordinamento dei messaggi è possibile

ottenerlo utilizzando messaggi Barrier.

Uno switch riconosce una connessione con un controller attraverso un identificatore univoco chiamato Connection URI. Questo URI deve essere conforme alla sintassi specificata dal documento RFC 3986 e può avere una delle seguenti forme:

• protocol:name-or-address:port • protocol:name-or-address

I valori ammisibili per protocol possono essere tcp o udp per le connes- sioni principali o tcp, udp, tls o dtls per connessioni ausiliarie. Per quanto riguarda il campo name-or-address i valori ammissibili sono l’hostname o l’indirizzo IP del controller. Il campo port indica la porta della connessione al controller.

Una volta stabilita la connessione tra switch e controller, le due parti ini- ziano il protocollo di negoziazione scambiandosi messaggi di tipo Hello con- tenente la più alta versione del protocollo supportata; in caso di successo è possibile procedere alla comunicazione di tipo operativo. In caso di caduta della connessione tra controller e switch, quest’ultimo tramite il messaggio

Controller-status deve notificare tale evento a tutti gli altri controller. Nel

caso critico di interruzione della comunicazione con tutti i controller lo switch deve entrare immediatamente, a seconda della sua configurazione e imple- mentazione, o in fail secure mode o in fail standalone mode. Nella prima mo- dalità l’unica modifica al suo comportamento consiste nello scartare tutti i pacchetti e i messaggi destinati al controller; nella seconda modalità lo switch

45 si comporta come uno switch o un router Ethernet di tipo legacy, modalità disponibile solo in caso di switch OpenFlow-hybrid.