Abbiamo visto che la decisione di inoltro presso un router in internet si basa sull'indirizzo di destinazione del pacchetto IP. Tuttavia abbiamo anche visto che stiamo assistendo ad una proliferazione di middlebox che effettuano molte funzioni del livello 3.
Cosa intendiamo per middle-box...
- NAT che riscrivono gli indirizzi dei pacchetti e i numeri di porta
- Firewall che bloccano il traffico basandosi sui valori dei campo dell'intestazione o re-indirizzano i pacchetti per elaborazioni supplementari
- Load-balancer inoltrano i pacchetti che richiedono un dato servizio.
Questa proliferazione, switch di livello 2 e router di livello 3, con hardware, software e interfacce specifiche ha sicuramente causato un bel mal di testa agli operatori di rete.
Ricordiamo che l'inoltro basato sulla destinazione è causato da:
- Match: ricerca di corrispondenza con l'IP di destinazione
- Action: invio del pacchetto attraverso struttura di commutazione a una specifica porta di uscita
Consideriamo un paradigma più generale, dove:
- Match: può essere effettuato su più campi dell'intestazione associati a differenti protocolli corrispondenti a diversi livelli nello stack dei protocolli
- Action: può includere l'inoltro a uno o più porte di uscita:
- Inoltro basato su destinazione (IP)
- Bilancio di carico dei pacchetti su più porte di uscita (load-balancing)
- Riscrittura dei valori (NAT)
- Bloccare, scarte un pacchetto (firewall)
- …
Nell'inoltro generalizzato, la tabella di inoltro discussa fino ad ora viene generalizzata.
Poiché l'inoltro può avvenire non solo mediante indirizzo di destinazione.
Gli switch di livello 2 o i router di livello 3 diventano packet switch nella terminologia SDN.
Openflow...
OpenFlow è uno standard di successo, pioniere del paradigma match-action e della rivoluzione SDN.
Ogni occorrenza (riga) in una tabella di inoltro match-action, nota come tabella di flussi, in OpenFlow, contiene quando segue:
- Un insieme di valori dei campi dell'intestazione con i quali il pacchetto entrante verrà confrontato. Come nel caso dell'inoltro basato sulla destinazione, il confronto implementato a livello hardware è effettuato molto più rapidamente nelle memorie TCAM. Un pacchetto che non abbia riscontrato in alcuna occorrenza della tabella dei flussi può essere scartato o inviato a un controller remoto per ulteriori elaborazioni. Nella pratica una tabella di flussi può essere implementata attraverso molteplici tabelle, ma qui ci focalizzeremo sull'astrazione di una singola tabella.
- Un insieme di contatori che vengono aggiornati quando i pacchetti vengono associati a un'occorrenza nella tabella dei flussi. Tali contatori possono contenere il numero di pacchetti associati a tale occorrenza e l'informazione temporale sull'ultimo aggiornamento dell'occorrenza.
- Un insieme di azioni che devono essere intraprese quando un pacchetto è associato a un'occorrenza della tabella di flussi. Le azioni possono essere: inoltro di un pacchetto a una data porta di uscita, scarto del pacchetto, effettuazione delle copie di un pacchetto e il loro invio a più porte di uscita e/o la riscrittura di alcuni campi dell'intestazione.
In OpenFlow il pacchetto viene unificato e contiene campi relativi a diversi livelli della pila: collegamento, rete, trasporto. Tale pacchetto contiene i campi "verificabili" con cui si può fare match, l'action invece è quell'azione che corrisponde al match. Se ci sono più match si verifica l'azione in base alla priorità.
Esempi di Openflow...
Supponiamo di avere l'esempio illustrato in figura:
Primo esempio: inoltro semplice
Supponiamo che i pacchetti da h5 o h6 (a sinistra nella figura) destinati a h3 o a h4 (a destra nella figura) debbano essere inoltrati dal router s3 al router s1, evitando quindi l'uso del collegamento tra s3 e s2.
L'occorrenza della tabella dei flussi in s1 sarebbe:
Il traffico in arrivo dalla porta di ingresso 1 (dov'è connesso s3), con IP sorgente 10.3.*.* e IP di destinazione 10.2.*.* (host 3, 4) devono essere inoltrati (action) sull'uscita 4.
Ovviamente servirebbe un'occorrenza della tabelle dei flussi in s3, in modo che i datagrammi da h5 o h6 siano inoltrati a s1 sull'interfaccia di uscita 3:
Infine è necessaria un'occorrenza della tabella dei flussi in s2 in modo che i datagrammi inviati da s1 siano inviati agli host della sotto-rete di s2 in cui sono presenti, appunto, gli host di destinazione.
Secondo esempio: load balancing
Come secondo esempio si consideri uno scenario di bilanciamento del carico, nel quale i datagrammi da h3 destinati a 10.1.*.* debbano essere inoltrati sul collegamento da s2 a s1, mentre i datagrammi da h4 destinati a 10.1.*.* debbano essere inoltrati sul collegamento tra s2 e s3 e quindi da s3 a s1. Si noti che tale comportamento non potrebbe essere effettuato con l'inoltro basato su destinazione IP. In questo caso la tabella dei flussi di s2 sarebbe:
Le occorrenze delle tabelle dei flussi sono necessari anche in s1 in modo da inoltrare i datagrammi ricevuti da s2 a h1 o h2; anche in s3 è necessaria una tabella dei flussi per inoltrare i datagrammi ricevuti sull'interfaccia 4 da s3 a s1 tramite l'interfaccia 3.
Terzo esempio: firewalling
Si consideri infine uno scenario in cui s2 desideri ricevere su qualunque sua interfaccia il traffico inviato da host attaccati a s3.
OpenFlow è un protocollo che ad oggi non è implementato nella internet che conosciamo. L'inoltro in internet sfrutta sempre l'inoltro attraverso l'hardware e non l'inoltro software accennato con SDN. Inoltre vista l'enorme estensione della internet odierna, cambiare approccio per applicare OpenFlow risulterebbe un lavoro molto lungo e costoso. Tuttavia, OpenFlow è utilizzato all'interno di reti aziendali o relativamente piccole, come nei data center, o ancora in campus universitari, o ancora in grosse aziende del settore.