|
|
@@ -0,0 +1,144 @@
|
|
|
+# Piattaforme e Software per la rete - lezione 14
|
|
|
+#### Giacomo Verticale
|
|
|
+###### 10 May 2016
|
|
|
+## Software Defined Networking con Openflow
|
|
|
+
|
|
|
+In una SDN sono presenti due flussi,
|
|
|
+Verso la forwarding table vanno i *pacchetti utente*
|
|
|
+Verso il controller vanno i *pacchetti di controllo*
|
|
|
+
|
|
|
+La parte di controllo consiste in una __RIB__ ovvero Routing Information Base
|
|
|
+
|
|
|
+Dallo switch contenente la forwarding table, i pacchetti vengono inviati
|
|
|
+alla tabella dello switch, che comunica con il controllore.
|
|
|
+
|
|
|
+L'interfaccia dal controllore al campo (insieme di nodi che gestiscono i pacchetti)
|
|
|
+viene chiamata __southbound__
|
|
|
+Per gli switch abbiamo una quasi __commoditizzazione__ dovuta dal fatto
|
|
|
+che i diversi switch hanno caratteristiche simili e prezzo simile che varia in base al
|
|
|
+costo dei pezzi utilizzati.
|
|
|
+I controllori invece essendo oggetti monolitici, si differenziano molto in base al vendor
|
|
|
+e l'interfaccia __northbound__ (interfaccia di controllo del controllore) varia in base al
|
|
|
+marchio.
|
|
|
+
|
|
|
+Se adotto un controllore per switch la rete ha una resistenza ai guasti
|
|
|
+Se invece avessi un controllore unico, la funzionalitá della rete dipende da quel singolo nodo.
|
|
|
+
|
|
|
+La pratica adottata é utilizzare piú controllori per vari switch, che comunicano tra di
|
|
|
+loro tramite l'interfaccia __east-west__.
|
|
|
+
|
|
|
+Anche per questa interfaccia ci sono diverse soluzioni in base al vendor, ma
|
|
|
+presumendo che una rete venga composta da controllori della stessa marca,
|
|
|
+il protocollo proprietario tra due controllori funziona.
|
|
|
+
|
|
|
+## Il protocollo OpenFlow (southbound)
|
|
|
+Il protocollo openflow é uno standard, non IEEE, non IETF, open non sta per open source
|
|
|
+ma per il fatto che chiunque puó usare lo standard senza pagare royalties.
|
|
|
+Esso definisce:
|
|
|
+- Modello astratto di switch
|
|
|
+- Azioni che il controllore puó compiere sullo switch
|
|
|
+- Protocollo
|
|
|
+
|
|
|
+La versione a cui facciamo riferimento é la `V.1.3 (2012)`, la V1.0 prevedeva un unica tabella
|
|
|
+di packet classification
|
|
|
+La versione attuale V.1.5 (2015) presenta nuove funzionalitá interessanti ma sono ancora troppo
|
|
|
+recenti per essere adottate dai vari prodotti.
|
|
|
+
|
|
|
+### Modello dello switch
|
|
|
+I pacchetti entrano dalle porte di ingresso e finiscono in una pipeline
|
|
|
+Pipeline:
|
|
|
+- Flow Table:
|
|
|
+ - Table 0
|
|
|
+ - Table 1
|
|
|
+ - ...
|
|
|
+ - Table N
|
|
|
+
|
|
|
+Le __Flow Table__ sono tabelle che fanno il match sui pacchetti e possono eseguire delle azioni.
|
|
|
+Il pacchetto che arriva porta con se un __action set__ inizialmente vuoto.
|
|
|
+La tabella, per ogni pacchetto puó aggiungere delle azioni all'action set di quest'ultimo.
|
|
|
+La tabella ha come input per ogni pacchetto:
|
|
|
+- Pacchetto
|
|
|
+- Porta di ingresso
|
|
|
+- Action set
|
|
|
+La tabella ha come output:
|
|
|
+- Pacchetto
|
|
|
+- Porta
|
|
|
+- Metadati
|
|
|
+- Action set
|
|
|
+
|
|
|
+Le istruzioni possono consistere in "saltare ad una tabella m" o saltare all'uscita.
|
|
|
+All'uscita vengono eseguite tutte le azioni presenti nell'action set.
|
|
|
+
|
|
|
+Inoltre é presente il client openflow e una group table
|
|
|
+La group table contiene dei cambiamenti da applicare globalmente a tutti i flussi del gruppo.
|
|
|
+
|
|
|
+Se un pacchetto non effettua il match su nessuna riga, viene attivata una regola di default se presente,
|
|
|
+altrimenti il pacchetto va scartato.
|
|
|
+
|
|
|
+Le __porte fisiche__ (per INPUT e OUTPUT)
|
|
|
+Le __porte logiche__ (per INPUT e OUTPUT) sono differenti dalle porte fisiche
|
|
|
+per il fatto che una singola porta fisica puó essere divisa in piú porte logiche per la gestione di diversi flussi.
|
|
|
+
|
|
|
+Tipicamente con una tipologia a stella voglio comunicare tra due estremi senza passare per il centro
|
|
|
+e per questo posso usare dei protocolli speciali di livello 2.
|
|
|
+
|
|
|
+Spesso per aumentare la velocitá di collegamento tra due link conviene usare piú collegamenti
|
|
|
+fisici piuttosto che comprarne uno di capacitá superiore.
|
|
|
+Normalmente lo spanning-tree spegnerebbe tre delle 4 porte ma posso aggregare i link in modo che lo switch
|
|
|
+li veda come un unico collegamento ed evito problemi di loop.
|
|
|
+
|
|
|
+Le __porte all__ (solo OUTPUT) che copiano il pacchetto su tutte le uscite (tranne la porta di ingresso),
|
|
|
+questo implementa il broadcast ethernet.
|
|
|
+
|
|
|
+La __porta controller__ (per input o output), che incapsula il pacchetto nel protocollo openflow
|
|
|
+e lo spedisce al controller.
|
|
|
+
|
|
|
+La __porta any__ Usata solo nei match
|
|
|
+
|
|
|
+La __porta local__ Usata solo se lo swtich viene collegato come un host,
|
|
|
+ovvero reindirizza il pacchetto ai livelli superiori dell'host su cui é implementato lo switch.
|
|
|
+
|
|
|
+## Flow Table
|
|
|
+é presente all'interno della pipeline
|
|
|
+é una lista di tante *flow entry*
|
|
|
+
|
|
|
+Match fields | Prioritá | Contatori| Istruzioni | Timeout | Cookie
|
|
|
+---|---|---|---|---|---
|
|
|
+
|
|
|
+I match fields possono essere:
|
|
|
+- Porta ingresso
|
|
|
+- Campi pacchetto
|
|
|
+- Metadati (da una tabella all'altra)
|
|
|
+
|
|
|
+Questi match possono solo essere esatti (o wildcard)
|
|
|
+Quindi non possono essere implementate tabelle di routing IP.
|
|
|
+La prioritá determina a paritá di match quale regola si attiverá.
|
|
|
+I timeout servono per far scadere le regole
|
|
|
+Possono essere:
|
|
|
+- Hard timeout: la regola rimane attiva per il periodo indicato
|
|
|
+- Idle timeout: il timeout viene resettato quando la regola effettua un match.
|
|
|
+
|
|
|
+Il cookie é un identificativo scelto univocamente per la regola.
|
|
|
+Servono per indicare una specifica regola nei comandi openflow.
|
|
|
+
|
|
|
+## Gestione di un pacchetto
|
|
|
+- Arriva pacchetto
|
|
|
+- Inizia da tabella n=0
|
|
|
+- Match tabella n?
|
|
|
+ - No: esiste riga default (table miss)?
|
|
|
+ - No: DROP
|
|
|
+ - Si: eseguo azione (vedi match:si)
|
|
|
+ - Si: Aggiorno contatori, reset timer, esegui istruzioni
|
|
|
+ - Aggiorna action set
|
|
|
+ - Esegui azioni immediate
|
|
|
+ - Aggiorna metadati
|
|
|
+ - Esiste istruzione GOTO?
|
|
|
+ - No: esegui action set
|
|
|
+ - Si: eseguo match con n della GOTO
|
|
|
+
|
|
|
+La tabella con indice massimo non puó avere istruzione GOTO, questo garantisce che il pipeline finisca
|
|
|
+per ogni pacchetto.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
