# SDN

## Piano di controllo di rete aperto

Astraendo il piano di controllo si ottiene un piano di controllo **aperto**, centralizzato rispetto alle macchine (che quindi si occupano solo di smistare i pacchetti). Sul piano di controllo e' possibile implementare applicativi quali SmartGrid, routing, TE, Mobility.

Il piano di controllo astratto (**NetOS**) puo' avere varie implementazioni, la piu' comune e' **openflow**.

## OpenFlow

SDN non e' openflow, openflow e' un'implementazione di SDN.

OpenFlow introduce delle astrazioni, la principale e' il **flusso**, che rappresenta la **granularita'** del controllo. I flussi sono identificati tramite 10 (circa) combinazioni di valori di *headers (vedi slides)*, valide per switch ethernet, router IP, NAT, firewall, etc. I flussi **non permettono di processare pacchetti individuali**, per cui non e' possibile effettuare **per-packet processing, deep packet inspection**, etc.

### Switch OpenFlow

Tre componenti:
* **Flow Table**: specifica l'azione che lo switch compie sul flusso. (inoltro verso porta x, scarto, etc).
* **Canale di comunicazione sicuro**: verso il controllore, per l'installazione di entries nella flow table, segnalazione di eventi, etc.
* **OpenFlow protocol**: per lo scambio di messaggi tra il processo del controllore e lo switch.

Tra le varie regole di gestione dei pacchetti:
* Pattern (bit-matching sul valore degli header files)
* Azioni (scarto, inoltro, modifica, invio al controllore, invio alla *processing pipeline* dell'hardware (se e' in grado))
* Priorita' per disanbiguare pattern sovrapposti
* Contatori: num bytes, num pacchetti

*(vedi slides per entries nella flow table)*
*(vedi slides per esempi)*

Quando un pacchetto e' ricevuto, si procede con il bit-match su ogni valore della flow table. Identificato il match, si procede all'azione definita. => **In base alle caratteristiche dell'header del pacchetto**, questo viene processato, e cio' vale per tutti i pacchetti di uno stesso tipo. Un flow e' quindi una categoria (astrazione) di pacchetti a cui corrisponde una determinata azione.
Inoltre, in base al tipo di device che voglio implementare (router, switch, firewall, etc) considero entry diverse nella fflow table. Cio' rende l'astrazione di OpenFlow molto potente e versatile. Notare che le regole di flusso definite nella flow table sono valide per tutti i device sulla rete.

* Ogni azione OpenFlow puo' essere configurata tramite vari parametri *(vedi slides)*

### Programmabilita' del controllore

Il controllore e' formato da un applicativo implementato sul NetOS e il NetOS stesso. Raccoglie processa eventi dagli switch, rispondendo con comandi inviati agli switch.

#### Esempio: controllo di accesso dinamico

*(vedi slides per disegno)*
1. ispezione del primo pacchetto del flusso da parte del controllore (sito in un punto centralizzato, es. server)
2. Il controllore consulta le sue policy riguardanti il pacchetto ispezionato
3. il controllore installa una regola per bloccare / instradare il flusso sull'**intera rete**
4. il traffico puo' fluire tra sorgente e destinazione

Senza SDN, il controllo di accesso dinamico e' molto piu' complesso, in quanto installare regole sull'intera rete e' molto piu' complesso.

#### Esempio: mobilita' trasparente

1. Flusso in corso
2. host si muove, inviando pacchetti attraverso un nuovo switch della stessa rete
3. il controllore modifica le regole per instradare il flusso, identificando un nuovo percorso ottimale
4. il traffico procede lungo il nuovo percorso

#### Esempio: load balancing (bilanciamento del carico)

0. Pre-installazione di policy di load balancing su switch
1. Due host connessi allo stesso switch
2. Il traffico dei due host e' **diviso** in base al source IP, attraverso path diversi sulla rete, per evitare il sovraccarico dei nodi.

Questo approccio e' statico, ma ci sono alternative piu' intelligenti che sfruttano un approccio dinamico.

#### Esempio: virtualizzazione della rete

Se considero una rete con **piu' di un controller**, la stessa rete deve essere **partizionata** (di modo che i controller non vadano in conflitto). Da una stessa rete fissa posso ottenere piu' reti virtuali logicamente separate.

### Protocollo OpenFlow
*(vedi slides)*
Utilizza TCP per lo scambio di messaggi.

#### Messaggi Controller to Switch

Funzioni di base:
* features: controllore interroga lo switch in merito a una certa feature, lo switch risponde
* configure: settare parametri di config
* modify-state: modifica di entry nella flow table
* packet-out: controllore ordina di inviare paccheto a una specifica porta di uscita dello switch

#### Messaggi Switch to Controller

Funzioni di base:
* packet-in: trasferisce il pacchetto al controllore
* flow removed: rimozione di una entry nella flow table dello switch
* port status: informa riguardo al cambiamento di stato di una interfaccia

Gli operatori di rete non devono occuparsi dei messaggi, in quanto essi sono gestiti dal NetOS, e sono comandati tramite linguaggi di alto livello (tra cui POX, una versione di NOX in Python).
Il controllore SDN e' quindi il cervello della rete, che implementa un modello **event-based** (il protocollo OpenFlow) realizzato tramite ambienti vari (NOX, POX, etc).

### Sviluppi futuri

* SDN su reti wireless/cellulari (per rendere piu' economica e flessibile la struttura mobile)

### Applicazione a Data Center

Un data center massivo richiede una struttura gerarchica di dispositivi (switch) di costi estremamente elevati e gestione complessa. Un SDN permette di costruire switch *custom-built* abbattendo costi, e gestendo unificamente la rete semplifica la gestione.

### Futuro: che fine faranno gli standard?

Supponendo che SDN prenda piede come gestione della rete, tutti gli standard che finora sono implementati nell'RFC avranno valore minore. Gli standard definiranno le interfacce, mentre il controllore implementera' le regole definite dagli amministratori di rete (e non dalle aziende costruttrici dell'hardware).

# Randomizzazione nelle reti

Introduzione volontaria di comportamenti random in una rete. Utilizzata in molti protocolli:
* multiple access Ethernet
* rimozione di sincronizzazioni indesiderate (comportamenti patologici di una rete deterministica)
* gestione attiva di una coda (router, etc)
* BitTorrent load balancing
* generic load balancing (potenza delle due scelte causali)
* routing random a due hop (per ottenere soluzioni piu' eleganti

## Randomizzazione in Ethernet

I protocolli di accesso multiplo regolano la gestione di conflitti su un canale ethernet condiviso, e fanno uso di randomizzazione in quanto le ritrasmissioni sono effettuate dopo un tempo casuale (**algoritmo di backoff esponenziale**). Sull'ethernet cablato questo non si verifica piu', ma il protocollo Wifi fa largo utilizzo di questa tecnica. *(vedi slides per schizzo di Metcalfe, inventore di ethernet)*.

Un protocollo di accesso multiplo e' quindi un **algoritmo distribuito** che regola la trasmissione su un canale ethernet, e sfrutta la capacita' di ethernet di fare sensing durante la trasmissione per identificare le collisioni (**CSMA/CD**). 
*(vedi slides per CSMA/CD pseudocodice)*.

### Backoff esponenziale

1. Prima collisione (per un pacchetto): scegli k a caso in {0,1}, due valori possibili. Attesa e' `k * 512`. 
2. Ogni successiva collisione raddoppio l'intervallo (2,4,8,16...,1024 valori, 10 collisioni max, kmax = 1023).
3. Una volta che il messaggio e' stato trasmesso, il contatore delle collisioni viene resettato a 0 e l'algoritmo ricomincia da (1) con un nuovo pacchetto.

Nota: diversamente da TCP, non si tiene traccia dei precedenti valori di congestione (TCP regola la congestion window in base ai valori precedenti). In ethernet, la finestra e' legata alla cautela nel trasmettere (e non all'aggressivita', come in TCP). Ethernet fa **multiplicative increase, complete decrease**, il che lo rende molto aggressivo sulla trasmissione di nuovi pacchetti.

### Analisi di CSMA/CD: Modello prestazionale

L'obbiettivo di un modello prestazionale ha l'obbiettivo di comprendere quantitativamente le prestazioni di CSMA/CD.
Supponiamo:
* Lunghezza fissa dei pacchetti
* Tempo di trasmissione dei pacchetti pari ad 1 unita' di tempo
* **throughput S**: numero di pacchetti trasmessi senza collisione (con successo) nell'unita' di tempo (da trovare). Nota: **S** avra' un valore massimo (asintotico) di 1, essendo che e' misurato su 1 unita' di tempo. 
* **a (alpha)**: intervallo di propagazione end-to-end (intervallo durante il quale possono avvenire collisioni). **Intervallo di vulnerabilita'.**