Reagire ad un malfunzionamento: Traffic Recovery

scomposta in due fasi: (1) rivelazione del guasto e (2) attivazione del RP. Rivelazione del guasto

La rivelazione di eventuali guasti `e affidata alla ricezione dei messaggi asincroni, di tipo Port-Status, previsti dal protocollo OpenFlow (paragrafo 3.2). Detti messaggi contengono il numero della porta coinvolta dal cambiamento di stato e l’identificativo dello switch cui essa appartiene.

Una volta ricevuto l’evento PortStatus, viene invocato il metodo linkMod() il quale, oltre a rimuovere gli archi corrispondenti all’interno di topology e le regole per il blocco dei messaggi ARP inoltrati tramite flooding, provvede a lanciare la procedura responsabile per l’attivazione del RP.

Segnaliamo che, in un primo momento, avevamo pensato di effettuare la rivelazione dei guasti tramite gli eventi sollevati dal modulo discovery.py. Procedendo nel lavoro di tesi, una tale strategia si `e rivelata inadeguata. Come specificato nel paragrafo 5.1, infatti, il funzionamento del modulo `e basato sullo scambio di messaggi LLDP tra gli switch che compongono la rete. Sottoponen- do l’infrastruttura a carichi elevati, abbiamo osservato come venissero avviate delle procedure di TR, pur in assenza di reali malfunzionamenti. Un tale incon- veniente era dovuto alla mancanza di banda sufficiente per assicurare il corretto scambio dei messaggi LLDP.

Attivazione del RP

La procedura responsabile per l’attivazione dei RP `e recovery(). Il metodo riceve in ingresso gli identificativi degli switch ai capi del link interessato ed i numeri di porta corrispondenti.

Come prima cosa, tra tutti i flussi gestiti dai due switch, si selezionano quelli che, al momento del guasto, stavano inoltrando del traffico sulle rispettive porte. I flussi individuati (se ce ne sono) vengono quindi organizzati in una lista ed ordinati in senso decrescente, rispetto alla banda occupata. L’ordinamento della lista impone che i flussi caratterizzati da un rate elevato sperimentino un

TTR inferiore, rispetto a quelli che inoltrano traffico a velocit`a pi`u contenute. Tale scelta `e dettata da una semplice costatazione: a parit`a di TTR, i primi perderebbero un numero maggiore di pacchetti rispetto ai secondi.

Si ricorda che la stima della banda occupata da un flusso `e prerogativa del modulo myStatsModule.py (paragrafo 5.3), il quale solleva appositamente l’e- vento NewFlowStats, cui myPCEModule.py `e abbonato. La memorizzazione dei dati viene affidata al dizionario flowStats, la cui struttura ricalca esattamente quella di lastFlowLoad.

Per ogni flusso contenuto all’interno della lista, si esamina il valore assunto dal campo cookie delle regole corrispondenti. In questo modo, si `e in grado di risalire alla classe di traffico cui esso appartiene.

Se il flusso in esame `e Platinum, non occorre eseguire alcuna azione. Infatti, essendo i pacchetti corrispondenti inviati contemporaneamente su due percorsi disgiunti, un singolo guasto non potr`a intaccare il funzionamento di entrambi. La comunicazione proseguir`a, dunque, sul “ramo” ancora attivo.

Anche qualora il flusso in esame fosse Gold non si richiederebbe alcuna con- tromisura. In realt`a, poich´e in questo caso non sussiste quella separazione fisica che invece `e presente nel caso di flusso Platinum, sarebbe auspicabile modificare la regola installata nella tabella dello switch cui `e connessa la sorgente, la quale impone d’inoltrare il traffico contemporaneamente su due percorsi. In tal mo- do, si potrebbero liberare risorse sui link ancora funzionanti, ma appartenenti al percorso interessato dal guasto. Effettuare un’operazione di questo tipo risulta particolarmente agevole nel caso in cui tale switch coincida con quello esaminato dalla procedura e, perci`o, verr`a attuata solo in questa circostanza.

Se il flusso in esame `e Silver, come abbiamo gi`a avuto modo di osservare, si rende necessaria la rimozione delle regole relative al WP. Esse infatti, possedendo una priorit`a pi`u elevata rispetto a quelle del RP, impedirebbero a quest’ultimo di attivarsi.

Infine, se il flusso in esame `e Bronze, occorre effettuare la procedura di Re- storation. In particolare, si tenta d’individuare un percorso alternativo nella rete e, qualora la ricerca fornisse un esito positivo, d’installare le regole corri- spondenti. Il RP `e ricercato all’interno di una topologia “ad-hoc”, memorizzata nel dizionario customTopo, ottenuta eliminando da quella reale il link colpito dal malfunzionamento. Se il flusso `e UDP, la nuova topologia viene privata anche di quei collegamenti la cui banda residua risulta inferiore a quella occupata dal flusso stesso, in accordo alle statistiche pi`u aggiornate. In caso di flusso TCP, un tale accorgimento risulta superfluo: la sorgente, infatti, `e in grado di regolare il rate di trasmissione in base alle perdite sperimentate.

I costi dei link rimanenti possono essere assegnati in accordo a due strategie. La prima corrisponde all’istradamento del flusso da ricollocare sul percorso at- tualmente pi`u scarico. Di fatto, dunque, si possono utilizzare i costi presenti nel dizionario topology. La seconda, invece, prevede che il flusso in esame venga inoltrato sul percorso attualmente pi`u carico, ma comunque in grado di conte- nerlo. Per far questo, `e sufficiente ribaltare rispetto all’asse delle utilizzazioni la metrica impiegata abitualmente per le funzionalit`a di LB (figura 5.13). In tal modo, infatti, a basse utilizzazioni corrispondono costi elevati e viceversa.

Applicazione di controllo 79 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 100 200 300 400 500 600 700 800 900 1000 Utilizzazione Costo NE BF WF

Figura 5.13: Ribaltamento delle metriche BF, NE e WF rispetto all’asse delle utilizzazioni (X = 3, Y = 1)

L’applicazione prevede che nel caso in cui le metriche utilizzate siano WF o NE, si debba attuare la prima strategia. Se invece si decidesse di adottare la policy BF, i meccanismi di Restoration si adeguerebbero alla seconda.

Su customTopo viene quindi eseguito l’algoritmo di Dijkstra per la deter- minazione di un nuovo albero dei cammini minimi, avente come radice il no- do corrispondente allo switch cui `e connessa la sorgente del flusso. Il metodo installPaths() `e, ancora una volta, responsabile per l’installazione delle rego- le, i cui campi cookie e idle timeout saranno caratterizzati dagli stessi valori impiegati per il WP. In aggiunta alle consuete operazioni, la procedura modifi- ca i valori di utilizzazione corrispondenti ai nuovi collegamenti sui quali viene reistradato il flusso considerato, assieme i relativi costi.

Se il flusso in esame adotta UDP come protocollo di trasporto, la nuova uti- lizzazione viene calcolata sommando al vecchio valore il rapporto tra la banda del flusso stesso e la velocit`a nominale dei link attraversati (supposta nota). In caso di utilizzo del protocollo TCP, invece, la nuova utilizzazione `e posta diret- tamente pari ad 1. L’aggiornamento delle utilizzazioni dei collegamenti, appar- tenenti al RP selezionato, `e necessaria per assicurarsi che pi`u flussi interessati dallo stesso guasto non vengano ricollocati tutti sullo stesso percorso.

La rimozione delle regole corrispondenti al vecchio WP viene affidata allo scadere del campo idle timeout.

Flusso

Platinum o Gold

Silver rimuovi regole

relative a WP

costruisci topologia “ad-hoc”

BF policy “inverti”

costi dei link

∃ RP installa regole per RP, aggiorna utilizzazioni e costi END s n s n s n s n

Figura 5.14: Operazioni eseguite per ogni flusso inoltrato su un collegamento interessato dal guasto

Applicazione di controllo 81