Tipologie di flusso

A seconda del comportamento tenuto dall’architettura in caso di malfunziona- mento, i flussi potenzialmente gestibili vengono suddivisi in quattro categorie (tabella 5.2).

La tipologia di flusso meno protetta `e la “Bronze”. Quando il primo pac- chetto di un flusso appartenente a detta categoria giunge al controller, esso provvede ad installare esclusivamente il WP. Il calcolo, ed eventualmente l’in- stallazione, del RP avviene soltanto qualora un guasto dovesse colpire un link del primo percorso. Il meccanismo di TR riservato alla classe Bronze `e, dunque, quello della Restoration. L’intervallo di tempo che intercorre tra il verificarsi del malfunzionamento e la sua risoluzione, tramite l’attivazione di un nuovo percorso, viene detto Time To Repair (TTR). Quest’ultimo risulta costituito

Applicazione di controllo 71

da due componenti: la prima riguarda il tempo necessario ad accorgersi che il guasto `e effettivamente avvenuto, nota con il nome di Time To Detect (TTD); la seconda corrisponde al ritardo ulteriormente sperimentato a causa del calcolo del RP e dell’installazione delle regole corrispondenti nelle tabelle degli switch interessati.

La categoria di traffico successiva `e la “Silver”. In questo caso, contestual- mente all’installazione del WP, il controller provvede anche al calcolo, ed even- tualmente all’installazione, del RP. Come abbiamo gi`a avuto modo di precisare nel capitolo 1, WP e RP dovranno risultare “disgiunti nei link” (link disjoint ), in modo da assicurare che un singolo guasto non vada a compromettere il fun- zionamento di entrambi. Il meccanismo di TR riservato alla classe Silver, cos`ı come alle due successive, `e quello della Protection. Ci`o nonostante, le regole relative al RP possiedono una priorit`a inferiore rispetto a quelle del WP. Per questa ragione, qualora si verifichi un guasto al WP, occorrer`a eliminare espli- citamente le sue regole per far s`ı che il RP diventi attivo. Infatti, visto che la scansione delle regole installate nella flow-table di uno switch OpenFlow avviene per priorit`a (paragrafo 3.2), finch´e le regole relative al primo saranno presenti in tabella, quelle associate al secondo verranno ignorate. Cos`ı come accadeva per i flussi Bronze, il TTR risulta formato da due componenti: la prima `e pari al TTD; la seconda corrisponde al ritardo ulteriormente sperimentato a causa della rimozione delle regole ad alta priorit`a relative al WP. Si osservi come la seconda componente del TTR per un flusso Silver sia, almeno in linea teorica, inferiore rispetto a quella corrispondente ad un flusso Bronze.

Ad un livello ancora pi`u elevato di protezione incontriamo la classe “Gold”. Ancora una volta, contestualmente all’installazione del WP il controller provve- de al calcolo, ed eventualmente all’installazione, del RP. A differenza di quanto avviene per i flussi Silver, le regole relative al secondo possiedono la stessa prio- rit`a di quelle del primo. Questo comporta che il traffico generato sia inoltrato contemporaneamente su due percorsi disgiunti. In caso di malfunzionamento, sia esso riguardante il WP o il RP (ma non entrambi), la comunicazione end- to-end non viene compromessa. Si osservi come non vi sia alcun ritardo dovuto a rivelazioni di guasti e/o riparazioni di percorsi: tutte le contromisure sono gi`a state adottate. Chiaramente una strategia di questo tipo presenta lo svantaggio della duplicazione delle risorse di rete occupate. `E dunque realistico pensare che se un operatore desiderasse offrire ai propri clienti un servizio di questo tipo dovrebbe proporre a questi ultimi tariffe pi`u elevate, rispetto a quelle applicate agli utenti Bronze o Silver.

Concludendo, la tipologia di traffico cui `e riservato il massimo livello di pro- tezione `e la “Platinum”. Infatti, in aggiunta a tutti i benefici che caratterizzano i flussi Gold, il traffico Platinum gode anche dell’isolamento fisico dal resto della rete. L’operatore specificher`a cio`e un WP ed un RP validi per tutti `e soli i flussi Platinum. I link appartenenti a detti percorsi sperimentano, a loro volta, un trattamento particolare. Per garantire la separazione fisica tra i relativi flussi ed il resto del traffico, i costi di tali collegamenti vengono settati come “esagerata- mente elevati”, a prescindere dalla loro effettiva utilizzazione. Per essere sicuri che un link appartenente ad un percorso Platinum non possa mai essere sele-

zionato durante le varie esecuzioni dell’algoritmo di Dijkstra, ovvero che non vi venga mai inoltrato del traffico meno privilegiato, sar`a sufficiente imporre che il costo cplat corrispondente risulti sempre superiore a quello del percorso pi`u lungo esistente in rete, anche qualora tutti i collegamenti che compongono quest’ultimo fossero massimamente congestionati (u = 1). Attenendoci alla no- tazione introdotta precedentemente, il criterio di cui sopra pu`o essere espresso dalla disequazione cplat> (n − 1) cmax, da cui segue cplat cmax > n − 1 oppure, ponendo cplat= 10Z,

Z > X + log₁₀(n − 1) . (5.17) All’interno dell’applicazione implementata, si `e posto Z = 6. Si osservi che, con una scelta di questo tipo, la (5.17) `e rispettata per un numero n di switch al pi`u pari a 1000.

A meno d’indicazioni specifiche, tutti i flussi trattati dall’architettura sono considerati appartenenti alla categoria Bronze. Un utente che desideri riserva- re ad alcuni di essi un trattamento particolare pu`o sempre specificarlo grazie ad alcuni argomenti opzionali, resi disponibili al modulo tramite riga di co- mando. Nel dettaglio, si tratta di quattro stringhe: silverFlows, goldFlows, platinumFlows e platinumPaths. Le prime tre vengono utilizzate per specifi- care i campi caratteristici dei flussi che si desidera siano appartenenti alle classi Silver, Gold e Platinum, rispettivamente. L’ultima, invece, assume significato solamente se associata a platinumFlows, consentendo di specificare WP e RP relativi ai flussi Platinum. La sintassi da adottare per indicare uno o pi`u flussi privilegiati `e la seguente:

f l o w s = f l o w _ 1 : f l o w _ 2 : . . . : flow_n ,

con

f l o w _ i = srcIP , dstIP , p r o t o c o l , d s t P o r t ;

mentre quella necessaria per specificare i percorsi `e:

p a t h s = w : p a t h _ 1 / p : path_2 ,

con

p a t h _ i = dpid_1 - dpid_2 -... - d p i d _ n .