polimd/Piattaforme Software per la Rete/MOD1/lesson_14.md

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.