5.5 Modulo PCE
5.5.6 Installazione dei percorsi: Load Balancing
Veniamo adesso alle modalit`a d’installazione dei percorsi che i flussi gestiti dal- l’architettura dovranno seguire. Ci`o che verr`a detto `e da intendersi riferito alle comunicazioni tra host connessi a switch differenti. Il traffico interno ad una sot- torete, infatti, viene gestito tramite le regole installate a seguito della ricezione dell’evento HostEvent.
Applicazione di controllo 73
Flussi Bronze, Silver e Gold
Come ormai abbiamo avuto modo di ribadire pi`u e pi`u volte, quando uno switch OpenFlow non sa come gestire un pacchetto in transito, ovvero non possiede una regola valida all’interno della propria tabella, provvede ad inviare quest’ultimo al controller. In una tale eventualit`a, il metodo della classe chiamato in causa `e
handle PacketIn().
Per prima cosa, il componente verifica di aver ricevuto un pacchetto IP. In caso contrario, non viene eseguita alcuna azione, assumendo che esistano altri moduli responsabili per la gestione di tipologie di messaggio differenti (paragrafo 5.2).
Una volta appurato che il pacchetto ricevuto sia effettivamente IP, viene ri- cercata la presenza dell’indirizzo di destinazione all’interno del dizionario hosts. Qualora la ricerca fornisse un esito negativo, la procedura terminerebbe solle- vando l’evento Unknown, a beneficio del modulo myICMPModule.py (paragrafo 5.4). Tale evento contiene gli indirizzi MAC e IP del default gateway della sot- torete cui appartiene la sorgente, in aggiunta alla porta dello switch cui essa `e collegata.
Se invece si `e a conoscenza della posizione dell’host destinatario, si passa all’installazione delle regole necessarie per la riscrittura degli indirizzi MAC, presenti nelle trame che contengono i pacchetti appartenenti al flusso in esame. In questa fase, gli switch coinvolti saranno esclusivamente quelli “di frontiera”, quelli cio`e cui sono connessi la sorgente e la destinazione del flusso. La prima, infatti, incapsuler`a i propri pacchetti all’interno di trame destinate al proprio default gateway. Dette trame presenteranno, come indirizzo sorgente, il MAC dell’host in esame e, come indirizzo di destinazione, il MAC associato alla porta dello switch OpenFlow cui `e connesso. D’altra parte, l’host di destinazione vorr`a vedersi recapitare delle trame il cui indirizzo sorgente contenga il MAC del default gateway per la sottorete cui appartiene, ed il cui indirizzo di destinazione coincida il proprio MAC. Poich´e uno switch OpenFlow non `e un router, tali operazioni dovranno essere esplicitamente richieste.
Giunti a questo punto, occorre effettuare la classificazione del flusso con cui si ha a che fare. Tale operazione si rende necessaria per l’assegnamento di un valore opportuno al campo cookie delle regole corrispondenti (paragrafo 3.2). Nel seguito, risulter`a chiaro come disporre di un tale identificatore opaco possa essere utile qualora si dovessero attuare delle operazioni di TR. La tabella 5.3 illustra le corrispondenze tra i vari tipi di flusso ed i relativi valori assunti dal campo cookie.
Si passa quindi all’installazione delle regole necessarie per istradare il flusso in esame lungo il percorso a costo minimo pi`u aggiornato di cui si dispone. Ab- biamo gi`a avuto modo di osservare come tale percorso, che assume il significato di WP, dovrebbe risultare il meno congestionato all’interno della rete. Il metodo della classe, studiato appositamente per portare a termine un compito di questo tipo, `e installPath(). Esso riceve in ingresso l’albero dei cammini minimi, memorizzato in cheapestPaths, avente come radice il nodo del grafo corrispon- dente allo switch cui `e connessa la sorgente del flusso. Da tale albero, viene
Tipo di flusso cookie
Platinum 4000
Gold 3000
Silver 2000
Bronze 1000
Tabella 5.3: Corrispondenze tra tipo di flusso e valore assunto dal campo cookie di una regola OpenFlow
(k − 1) δ statistiche fine flusso k δ statistiche t ∆
Figura 5.11: Relazione temporale tra la fine di un flusso e la ricezione delle prossime statistiche
ricavata la sequenza di switch che i pacchetti appartenenti al flusso dovranno attraversare, assieme alle porte corrispondenti. Coerentemente con ci`o che `e stato detto in precedenza, le regole installate in questa fase avranno priorit`a pi`u elevata rispetto alle altre e sar`a assegnato loro il corretto valore per il campo cookie, a seconda della classe di traffico cui il flusso appartiene. Si osservi che, una volta identificato il percorso da far seguire ai pacchetti, esso rester`a valido almeno per l’intera durata della connessione, nonostante sia verosimile che le condizioni di carico relative ai collegamenti della rete possano subire delle variazioni. Volendo assicurarsi che il contenuto delle flow-table si rinnovi con sufficiente frequenza, le regole di un WP specificate da installPaths() sono dotate di idle timeout (paragrafo 3.2).
Per quanto riguarda la scelta del valore da assegnare a tale campo, si fac- cia riferimento alla figura 5.11. Se indichiamo con δ il passo con il quale myStatsModule.py interroga gli switch della rete e con ∆ la variabile aleatoria rappresentante l’intervallo di tempo che intercorre tra la fine di un flusso e la rice- zione delle prossime statistiche, possiamo supporre che ∆ risulti uniformemente distribuita tra 0 e δ:
∆ ∈ U [0, δ] , E [∆] = δ/2,
ovvero che, mediamente, un flusso termini a δ/2 secondi dalla prossima ricezione di statistiche. Non esiste, infatti, alcuna ragione particolare secondo la quale dovrebbe essere pi`u probabile che l’ultimo pacchetto del flusso transiti ad un certo istante, piuttosto che ad un altro.
Secondo questo ragionamento, se lo stesso flusso si ripresentasse prima di δ/2 secondi e se le regole corrispondenti fossero gi`a state rimosse dalle tabel-
Applicazione di controllo 75
le degli switch, l’installazione del nuovo WP farebbe riferimento all’albero dei cammini minimi calcolato al passo precedente. Dovendo attingere comunque ad informazioni non aggiornate, potremmo pensare di non rimuovere le regole gi`a presenti all’interno della tabella, facendo seguire al flusso il percorso installato precedentemente. Si osservi come una scelta di questo tipo si traduca in un valore di idle timeout pari a δ/2.
Tale strategia potrebbe rivelarsi inadeguata per passi d’interrogazione par- ticolarmente contenuti. Negli esperimenti presentati nel capitolo 7, ad esempio, abbiamo imposto δ = 5 secondi. In quel contesto, si `e preferito un idle timeout pi`u conservativo, pari a 10 secondi, rispetto ai 2.5 dettati dalla trattazione precedente.
Infine, se il flusso in esame appartiene alle classi Silver o Gold, si passa al calcolo ed eventualmente all’installazione del RP, con le distinzioni discusse precedentemente. Per far s`ı che WP e RP risultino disgiunti nei link, viene crea- ta una topologia “ad-hoc”, memorizzata all’interno del dizionario customTopo, contenente gli stessi archi presenti in topology ad esclusione di quelli gi`a utiliz- zati per il WP. Su detta topologia, si va ad eseguire l’algoritmo di Dijkstra per la determinazione di un nuovo albero dei cammini minimi, avente come radice il nodo corrispondente allo switch cui `e connessa la sorgente del flusso. Detto albero viene fornito nuovamente in ingresso al metodo installPaths(), il quale provveder`a ad immettere le regole relative al RP all’interno delle tabelle degli switch interessati.
Nel caso di flusso Gold, tali regole saranno caratterizzate dagli stessi campi impiegati per il WP (cookie e idle timeout compresi). Se il flusso, invece, ap- partiene alla classe Silver, esisteranno alcune differenze. Anzi tutto, come detto in precedenza, le regole relative al RP per un flusso Silver possiedono priorit`a inferiore, rispetto a quelle associate ad un WP. Secondariamente, esse saranno dotate di hard timeout, anzich´e di idle timeout. Il RP, infatti, dovrebbe ri- sultare disponibile per tutta la durata della connessione da proteggere. Se le regole corrispondenti possedessero un idle timeout, si potrebbe incorrere nel rischio di vederle scadere prima del verificarsi del guasto. D’altra parte, dette regole non possono neanche essere impostate come permanenti. Ci`o comporte- rebbe che, qualora il flusso in esame dovesse ripresentarsi in seguito allo scadere delle regole associate al WP, esso verrebbe inoltrato sul vecchio RP, invece che sul percorso pi`u scarico attualmente disponibile. Dotare di hard timeout le regole corrispondenti al RP per un flusso Silver, dunque, ci `e parsa una buo- na soluzione di compromesso. L’ideale sarebbe disporre di alcune informazioni sulle durate delle connessioni interessanti l’infrastruttura sotto osservazione, in modo da impostare un valore coerente di hard timeout. All’interno della nostra applicazione, abbiamo fissato tale valore pari a 10 minuti.
Una rappresentazione sintetica del metodo handle PacketIn() viene for- nita dal diagramma di flusso di figura 5.12.
Pacchetto IP
destinazione
nota solleva evento
installa regole per riscrittura indirizzi MAC
flusso Gold flusso Silver
cookie = 3000 cookie = 2000 cookie = 1000
installa regole per WP flusso Gold o Silver costruisci topologia “ad-hoc” ∃ RP installa regole per RP END n s n n s s n s n s
Applicazione di controllo 77
Flussi Platinum
L’installazione dei percorsi relativi a flussi Platinum ricalca esattamente quella seguita per i Gold. L’unica differenza consiste nel fatto che per i primi non occorre attendere la ricezione di un pacchetto per poter avviare la procedura. Dal momento che, assieme ai campi caratteristici, l’utente `e tenuto a specificare esplicitamente WP e RP seguiti da detti flussi, il componente dispone gi`a di tutte le informazioni necessarie per poter memorizzare le relative regole, nel momento stesso in cui la rete viene avviata.
La procedura che si occupa d’installare le regole relative ai percorsi seguiti dai flussi Platinum `e platinumEntries().