Implementare il paradigma Software-Defined Networking utilizzando OpenFlow switch protocol

www.democraziadigitale.eu

Implementare il paradigma

Software-Defined Networking

utilizzando OpenFlow switch protocol Elaborato Finale

Studente:

Francesco Ciclosi

Scuola di Scienze e Tecnologie

Corso di Laurea in Informatica L-31

Relatore:

Prof. Leonardo Mostarda

ANNO ACCADEMICO 2013/2014

Implementare il paradigma Software-Defined Networking utilizzando OpenFlow switch protocol – Camerino, 8/4/2015

Quest'opera di Francesco Ciclosi è distribuita con Licenza CC BY-SA 3.0 Italia [Commons Deed] [Legal Code]


Il paradigma SDN

Virtualizzazione

di rete

Ristrutturare l’architettura di networking garantendo l’interazione

tra applicazioni e rete

http://creativecommons.org/licenses/by-sa/3.0/it/deed.it





http://creativecommons.org/licenses/by-sa/3.0/it/legalcode




Filosofia di OpenFlow

Interfaccia di basso livello che espone un modello astratto del

piano di forwarding del nodo

Consente la comunicazione tra HAL e controller SDN

Svincola il piano di

forwarding dal vendor










La rete secondo il paradigma SDN

È un’unica entità governata da un unico piano

di controllo centralizzato

Le applicazioni si rivolgono ad essa pensando

esclusivamente alle proprie logiche di servizio

La sua complessità fisica è mascherata dal piano

logico esposto dai controller










Il livello del controller SDN










SDN: lo strato di controllo

È centralizzato e opera come un sistema

operativo di rete (NOS)

È composto da molteplici moduli software che

hanno come nucleo centrale il controller










SDN: i controller

Svolgono le funzioni fondamentali:

• espongono le northbound API verso le applicazioni

• gestiscono le comunicazioni tra i vari moduli

• gestiscono l’aggiunta di nuovi componenti

La loro implementazione fisica differisce da quella

logica (che è centralizzata)

Il modello fisico è separato, distribuito e replicato










SDN: la virtualizzazione di rete (1)

Tale approccio prevede il partizionamento

virtuale (slice) dell’infrastruttura di rete fisica

Più istanze di controllo possono utilizzare la slice

assegnata come se fosse un’infrastruttura fisica

dedicata

Diversi soggetti possono implementare schemi

di indirizzamento e protocolli completamente

indipendenti










SDN: la virtualizzazione di rete (2)

Consentire configurazioni oggi impossibili:

• effettuare il rinnovo della piattaforma hardware

senza impatto sull’erogazione dei servizi

• rendere disponibili nuove funzionalità in real time

• Implementare qualsiasi livello di ridondanza,

indipendente dalla topologia fisica sottostante

Al momento tale paradigma non è ancora

maturo per l’adozione in uno scenario reale










SDN: standardizzazione

Interessante l’attività del consorzio industriale

non-profit ONF (Open Networking Foundation)

ONF presiede le attività finalizzate allo sviluppo

di un modello per SDN

ONF guida dei gruppi di lavoro per definire:

• il protocollo standard di comunicazione OpenFlow

• il modello dell’hardware di rete OpenFlow










Lo switch logico OpenFlow

Op

enF

low

S

wit

ch S

pec

ific

atio

n 1

.5.0

(p

roto

col

0x06

)










OpenFlow: funzionamento delle porte (1)

Le porte sono le interfacce di rete utilizzate per lo

scambio tra i processi elaborativi di OpenFlow e

la rete

Non è assicurata la corrispondenza tra numero di

porte OpenFlow e numero di interfacce fisiche










OpenFlow: funzionamento delle porte (2)

I pacchetti:

• sono ricevuti su di una porta di ingresso

• sono processati dalla pipeline OpenFlow

• sono inoltrati tramite una porta di uscita

Uno switch OpenFlow compliant deve supportare:

• physical port

• logical port

• reserved port










OpenFlow: physical port e logical port

Physical port

• corrispondono alle interfacce fisiche dello switch

• possono corrispondere a porzione di interfaccia fisica

Logical port

• non esiste corrispondenza con interfacce fisiche

• possono includere l’incapsulamento dei pacchetti

• possono essere mappate su più physical port

• Possono utilizzare il campo di corrispondenza Tunnel-ID










OpenFlow: reserved port (1)

Sono utilizzate per specificare delle azioni generiche

di inoltro

Si dividono in:

• ALL, CONTROLLER, TABLE, IN_PORT, ANY e

UNSET la cui implementazione è obbligatoria

• LOCAL, NORMAL e FLOOD la cui implementazione

è facoltativa











ALL rappresenta ogni porta che lo switch può

usare per inoltrare un pacchetto

CONTROLLER rappresenta il canale di

comunicazione con i controller OpenFlow

TABLE rappresenta l’inizio della pipeline

OpenFlow

IN_PORT rappresenta la porta di ingresso











ANY indica al protocollo che la speciale

richiesta è applicabile anche a ogni altra porta

UNSET indica che nell’action-set non è stata

specificata nessuna porta di uscita

LOCAL rappresenta sia lo stack di rete locale

che lo stack di gestione dello switch

NORMAL rappresenta l’inoltro tramite la

normale pipeline non OpenFlow











FLOOD rappresenta il flooding dei pacchetti

effettuato utilizzando la tradizionale pipeline dello

switch non basata su OpenFlow










OpenFlow: standard port

Sono un particolare raggruppamento composto da:

• ogni physical port

• ogni logical port

• la reserved port LOCAL (se esistente)

Possono essere utilizzate all’interno di gruppi

Possono avere contatori, stato e configurazione










OpenFlow: modifica delle porte

Qualsiasi modifica a stato o configurazione delle

porte va subito comunicata al controller OpenFlow

Le variazioni effettuate sulle porte non vengono

propagate alle flow table e alle group table

I pacchetti inoltrati a delle porte che non esistono

saranno scartati










OpenFlow: l’elaborazione nella pipeline

La pipeline è l’insieme delle flow table connesse

tra loro

In uno switch OpenFlow queste flow table

forniscono i meccanismi di:

• corrispondenza del pacchetto;

• inoltro del pacchetto;

• modifica del pacchetto.










Flusso dei processi nella pipeline










La pipeline OpenFlow (1)

La pipeline contiene uno o più flow table

Ogni flow table è composta da più flow entry

Il processo di elaborazione della pipeline definisce

come avviene l’interazione tra i pacchetti e le flow

table

Le flow table sono numerate sequenzialmente da 0

Esiste un’elaborazione in ingresso e una in uscita










La pipeline OpenFlow (2)

Le flow table in ingresso successive alla prima sono

utilizzate o meno a seconda dei risultati delle

corrispondenze nella prima tabella

L’elaborazione di uscita è opzionale

Se non ci sono flow table di uscita il pacchetto sarà

elaborato dalla porta di uscita

Entrambe le elaborazioni hanno le stesse regole










Le tipologie di switch OpenFlow

OpenFlow only

• supportano esclusivamente le operazioni OpenFlow

• elaborano i pacchetti secondo la pipeline OpenFlow

OpenFlow hybrid

• supportano sia le operazione OpenFlow che le

normali operazioni di commutazione Ethernet

• Sono dotati di un meccanismo di classificazione per

gestire le due pipeline (OpenFlow e normale)










Elaborazione in una flow table

Il pacchetto viene confrontato in sequenza con

ogni flow entry finché non si trova una

corrispondenza, quindi si eseguono le sue istruzioni

Se non viene trovata una corrispondenza con le

flow entry il pacchetto è elaborato secondo le

istruzioni della table-miss

Se non è presente una table-miss il pacchetto viene

scartato










Composizione di una flow entry

Match fields usato per verificare la

corrispondenza con i pacchetti

Priority definisce l’ordine di precedenza

Instructions usato per modificare l’action-set o

il processo di elaborazione della pipeline

Timeouts definisce la soglia temporale o di

inattività per la rimozione

Altri campi sono: counters, cookie e flags










Il processo di corrispondenza (1)










Il processo di corrispondenza (2)










La flow entry table-miss

Verifica la corrispondenza dei pacchetti senza

corrispondenza con le altre flow entry

È una flow entry senza valori e con il campo

priority uguale a zero (è una wildcard)

Svolge almeno due funzioni:

• Invia il pacchetto al controller utilizzando la

reserved port CONTROLLER

• scarta il pacchetto con l’istruzione Clear-Actions










Flow entry: le istruzioni obbligatorie

Write-Actions action(s)

• Unisce l’azione o l’insieme di azioni specificate

nell’attuale action-set

• Se l’azione esiste già sarà sovrascritta, altrimenti aggiunta

Goto-Table next-table-id

• Indica la tabella successiva nel processo di elaborazione

della pipeline di OpenFlow










Flow entry: le istruzioni facoltative

Apply-Actions action(s)

• Applica immediatamente l’azione o l’insieme di azioni

specificate senza modificare l’action-set

Clear-Actions

• Cancella ogni azione presente nell’action-set

Write-Metadata metadata/mask

• Scrive il valore dei metadati di mascheramento

Stat-Trigger stat thresholds










Flow table: verifica ed esecuzione










OpenFlow: l’action-set

È associato a ogni pacchetto e inizialmente vuoto

Può essere modificato da una flow entry

• Con le istruzioni Write-Action e Clear-Action

Può contenere al massimo un’azione per tipologia

Ha un ordine predefinito di esecuzione delle azioni










Tipologie di azioni in un action-set

group applica al pacchetto le azioni

contenute nel bucket del gruppo

output inoltra il pacchetto tramite la porta ivi

specificata

set applica al pacchetto ogni azione set-field

altre azioni sono: copy TTL inwards, pop, push-

MPLS, push-PBB, push-VLAN, copy TTL

outwards, decrement TTL, qos










Action-set: alcune regole generali

L’output action è sempre l’ultima azione ad

essere eseguita

Se vengono specificate sia un output action che

una group action, la group action verrà eseguita e

l’output action scartata

Se non sono specificate ne un output action che

una group action, il pacchetto sarà scartato










OpenFlow: la group table

È costituita da un gruppo di voci

Consente la rappresentazione di metodi di invio

alternativi (tipo SELECT e ALL)

È composta da group entry, ciascuna contenente:

• group identifier identifica univocamente il gruppo;

• group type determina la semantica del gruppo;

• counters conta le elaborazioni effettuate dal gruppo;

• action buckets è una lista ordinata di bucket di azione.










I group type obbligatori

indirect

• È un tipo di gruppo che contiene un unico bucket

• Consente a flow entry o group entry multipli di

puntare a un identificatore di gruppo comune

all

• Esegue tutti i bucket contenuti nel gruppo

• È usato per l’inoltro in broadcast o in multicast










I group type opzionali

select

• Esegue un bucket tra quelli definiti nel gruppo

• Un algoritmo di selezione determina il bucket che

elaborerà i pacchetti

fast failover

• Esegue il primo bucket del gruppo che è disponibile










La struttura di OpenFlow switch protocol

Il protocollo è implementato utilizzando messaggi

OpenFlow trasmessi sul canale OpenFlow

Il file openflow.h definisce ogni struttura che descrive

i vari tipi di messaggio

Ogni messaggio inizia con un’intestazione comune

La struttura del messaggio può includere altre

strutture










L’intestazione OpenFlow

struct ofp_header {

uint8_t version; /* OFP_VERSION. */

uint8_t type; /* One of the OFPT_ constants. */

uint16_t length; /* Length including this ofp_header. */

uint32_t xid; /* Transaction id associated with this packet.

Replies use the same id as was in the request

to facilitate pairing. */

};

OFP_ASSERT(sizeof(struct ofp_header) == 8);










Principali tipi di messaggio OpenFlow (1)

OFPT_HELLO

• Viene inviato tra switch e controller per negoziare la

versione del protocollo da utilizzare e per

inizializzare la sessione

OFPT_ECHO_REQUEST/REPLY

• Vengono inviati tra switch e controller per verificare

la latenza, misurare la larghezza di banda oppure

solo per verificare il perdurare della connessione











OFPT_FEATURES_REQUEST

• È utilizzato dal controller per identificare lo switch e

scoprire le sue funzionalità di base

OFPT_FEATURES_REPLY

• È utilizzato dallo switch in risposta a un messaggio

di tipo OFPT_FEATURES_REQUEST ricevuto

precedentemente dal controller











OFPT_BARRIER_REQUEST

• Viene utilizzato dal controller per governare il processo di

elaborazione dei messaggi

• Ha tre funzioni

o Garantisce l’ordinamento dei messaggi

o Notifica al controller il completamento delle operazioni

o Assicura che lo stato inviato dal controller sia applicato al datapath

OFPT_BARRIER_REPLY

• Utilizzato dallo switch in risposta al messaggio di richiesta











OFPT_SET_CONFIG

• Viene utilizzato dal controller per impostare i parametri di

configurazione dello switch

• Lo switch esegue la richiesta senza inviare una risposta

OFPT_PORT_STATUS

• Viene utilizzato dallo switch per comunicare al controller

l’aggiunta, la modifica o la rimozione di una porta dal

datapath











OFPT_PACKET_IN

• Viene utilizzato dallo switch per incapsulare e quindi

inviare al controller un pacchetto

OFPT_PACKET_OUT

• Viene utilizzato dal controller per far trasmettere un

pacchetto al di fuori del datapath










Configurazione di OpenFlow su switch

CISCO serie Nexus 3100 Supporto solo per le versioni 1.0 e 1.3 di OpenFlow

Supporto solo per pochi controller

• POX, IXIA, OpenDayLight e XNC 1.0

È richiesto il Cisco Plug-in for OpenFlow 1.1.5

• Distribuito come file .OVA (Open Virtual Application)

• Eseguito in un Virtual Service for Application (VSA)

• Trasforma il device in uno switch ibrido










Mininet: una piattaforma di prototipazione

Mininet utilizza la virtualizzazione leggera offerta da

Linux ed è composta da 4 elementi:

• link una connessione cablata virtuale tra due interfacce

• host un processo della shell trasferito all’interno del

proprio spazio dei nomi di rete

• switch uno switch software basato su OpenFlow e

realizzato di default in kernel-space

• controller possono essere collocati ovunque nella rete

purché raggiungibili via IP dalla VM Mininet










Schema interno di una rete Mininet

Ove

rhea

d d

i un

ho

st

emula

to ≈

1 M

b










Strumenti di lavoro: Putty

È un client (anche) SSH che viene collegato con

un emulatore di terminale per la gestione

remota dei sistemi informatici










Strumenti di lavoro: PSFTP

Utilizza il

protocollo PSFTP

disponibile in

SSHv2

Consente il

trasferimento

sicuro dei file tra

due sistemi










Strumenti di lavoro: WinSCP

Client grafico che utilizza i protocolli SFTP e

SCP per il trasferimento sicuro dei file










Strumenti di lavoro: xterm

È l’emulatore standard di

terminale in ambiente Linux

Supporta più sessioni simultanee

su uno o più display

Si appoggia al gestore grafico X

Windows (X11) che fornisce

ambiente e componenti base per

realizzare l’interfaccia grafica

VM

Mininet










Strumenti di lavoro: xming

Software in grado

di fornire il

supporto per l’X

forwarding in

ambiente Windows










Gestione di più nodi con xterm










Mininet: la topologia minimale

sudo mn crea la topologia

sudo mn - c resetta l’ambiente virtuale










sudo mn –topo single, 6










Tipologie di switch disponibili in Mininet

Kernel switch

o sono implementati di default da Mininet

Switch eseguiti in user space o sono implementati con: $ sudo mn –switch user+

o basse performance per operato dello scheduler della CPU

Open vSwitch (OVS) o sono implementati con: $ sudo mn –switch ovsk

o vengono eseguiti in kernel space










Caso di test: una semplice topologia










Caso di test: creazione della topologia

Eseguire il comando dalla console della VM:

• $ sudo mn --topo single,3 --mac

--switch ovsk –controller remote

Avviare un controller sulla VM Mininet (in

ascolto su IP 127.0.0.1 porta TCP6633)

digitando da console:

• $ controller pcpt:










Test di connettività

Nel caso in cui il

controller non è stato

avviato

Nel caso in cui il

controller è stato

avviato










Test di bitrate

Calcola il massimo bitrate teoricamente

raggiungibile dalla rete

Dipende dall’implementazione dello switch in

kernel space oppure in user space










Analisi delle tabelle di flusso (1)

Inizialmente sono vuote e vengono via via popolate

in base alle istruzioni ricevute dal controller

• $ dpctl dump-flows tcp:127.0.0.1:6634










Analisi delle tabelle di flusso (2)










Pacchetti

OpenFlow

scambiati

nell’utilizzo

di un ping










Creare una topologia con le API Python

È possibile definire una

topologia personalizzata

usando degli script

Python

• $ sudo mn -x --custom

/home/test.py --topo

TopoTest










Caso di studio

In questa fase si verificherà il comportamento di

un device programmabile con OpenFlow

Si testeranno 4 implementazioni di switch

Il controller utilizzato sarà remoto e basato su

POX










Caso di studio: 4 comportamenti testati • dumb hub ogni pacchetto viene inviato al controller

e poi trasmesso su tutte le porte del device. Non

vengono installate flow entry

• lazy hub nel device è installata una sola flow entry

che consente il broadcast su ogni porta

• pair switch nel device sono istallate delle flow entry

(per la coppia di MAC) che consentono il traffico. Il

device invia i pacchetti sulla giusta porta

• ideal pair switch il device si comporta come un pair

switch, ma utilizza due flow entry per coppia di MAC










Il controller POX

Non garantisce le migliori

performance

È semplice e flessibile

Ottimo per i test di

funzionalità










Avviare POX

Eliminare eventuali istanze orfane in esecuzione

• $ ps -A | grep controller

• $ sudo killall controller

Avviare il controller (dalla cartella di POX)

• $ ./pox.py log.level --DEBUG misc.of_component










Avviare Wireshark Dalla console di Mininet con X11 forwarding abilitato

• $ sudo wireshark &

Impostare of nella casella filter per filtrare OpenFlow

Impostare la cattura sull’interfaccia lo e click su start










Inizializzare l’ambiente (1)

Dalla console di Mininet avviare l’ambiente

• $ sudo mn --topo single, 3 --mac --switch ovsk --

controller remote

Dalla CLI di Mininet avviare le connessioni

xterm verso i 3 host

• CLI> xterm h1 h2 h3










Inizializzare l’ambiente (2)

Dalla console xterm del processo host h2

• # tcpdump -XX -n -i h2-eth0

Dalla console xterm del processo host 3

• # tcpdump -XX -n -i h3-eth0

Dalla console xterm del processo host h1

• # ping -c1 10.0.0.2










Caso di studio: dumb hub (1)

La comunicazione ICMP ha avuto esito positivo

Il lasso temporale è ampio e dovuto alla

comunicazione tra switch s1 e controller POX











Ogni processo host rileva il medesimo traffico

sulle sue interfacce











Alto scambio di messaggi OpenFlow tra switch e

controller dovuto al non utilizzo delle flow entry











Inviando 10 richieste ICMP di tipo 8 il tempo di

esecuzione (in millisecondi) è alto e costante

Coerente con il non utilizzo delle flow entry










Caso di studio: lazy hub (1)


Il lasso temporale è enorme e dovuto

all’installazione preliminare della flow entry











Ogni processo host rileva il medesimo traffico

sulle sue interfacce











Due differenti scambi di messaggi OpenFlow

All’avvio delle connessione tra controller POX e

switch s1 per installare la flow entry che consente il

traffico broadcast su ogni porta

Al momento del ping tra il processo host h1 e il

processo host h2 per consentirne il traffico











Inviando nuovamente 4 richieste ICMP di tipo 8

dall’host h1 all’host h2 il tempo di esecuzione (in

millisecondi) è basso e costante

Lo switch ha già una flow entry per questo traffico










Caso di studio: lazy hub (5) Inviando ora 5 richieste ICMP di tipo 8 dall’host h1

all’host h3 il tempo di esecuzione (in millisecondi) è

alto per il primo ping e basso per i restanti

Lo switch deve inizialmente contattare il controller

per ottenere una flow entry










Caso di studio: pair switch (1)

Inviando più pacchetti la comunicazione ICMP

ha globalmente esito positivo ma i primi si

perdono a causa dell’overhead necessario

all’installazione delle flow entry











Ogni processo host

rileva un differente

traffico sulle sue

interfacce perché lo

switch inoltra a tutti

solo il traffico

broadcast











Scambio di messaggi OpenFlow in occasione della

connessione controller/switch

Installazione della flow entry per il traffico broadcast











Scambio di messaggi OpenFlow in occasione del

ping tra l’host h1 e l’host h2 finalizzato a consentire

il traffico medesimo












ripetizione del ping tra l’host h1 e l’host h2

Essendo trascorsi alcuni minuti le flow entry

contattare nel device non erano più valide










Caso di studio: pair switch (6) Inviando ora 5 richieste ICMP di tipo 8 dall’host h1

all’host h2 (attendendo almeno 60 secondi dal

precedente ping)

Le flow entry saranno scadute e lo switch dovrà

nuovamente contattare il controller










Caso di studio: ideal pair switch (1)


L’invio del primo pacchetto ha richiesto più

tempo per l’installazione della nuova flow entry

nel device e per la comunicazione con il controller











Ogni processo host rileva un

differente traffico sulle sue

interfacce perché lo switch

inoltra a tutti solo il traffico

broadcast












connessione controller/switch

Installazione della flow entry per il traffico broadcast











Scambio di messaggi OpenFlow in occasione del

ping tra l’host h1 e l’host h2 finalizzato a consentire

il traffico medesimo











Eseguendo in rapida sequenza due ping tra gli

host h1 e h3, l’idle timeout non sarà raggiunto

A seguito del primo

scambio ICMP

verranno installate

delle flow entry ancora

valide al momento del

secondo scambio












ripetizione del ping tra l’host h1 e l’host 3

Essendo ancora valide le flow entry, il device non

dovrà contattare nuovamente il controller










Conclusioni (1)

La vera novità del paradigma SDN consiste

nella possibilità di svicolare la topologia logica

del piano di controllo da quella fisica dei nodi di

rete che effettuano il forwarding del traffico

Le soluzioni SDN dovrebbero essere indirizzate

verso l’implementazione della cosiddetta

virtualizzazione di rete










Conclusioni (2)

Il protocollo OpenFlow può essere considerato

un fattore abilitante di una rete flessibile e

programmabile

Urge che il suo processo di definizione subisca

un’accelerazione per renderlo standardizzato e

maturo

Occorre garantire più device che supportino

OpenFlow specie nelle ultime versioni










Conclusione finale

Il paradigma SDN potrà farci assistere nei

prossimi anni a una rivoluzione epocale nel

mondo del networking se:

• saprà dimostrare la sua fattibilità tecnologica anche

in un contesto reale di produzione

• il processo di standardizzazione sarà terminato e

consolidato










I miei contatti linkedin

http://it.linkedin.com/pub/francesco-ciclosi/62/680/a06/

facebook

https://www.facebook.com/francesco.ciclosi

twitter

@francyciclosi

www

http://www.francescociclosi.it







Implementare il paradigma Software-Defined Networking utilizzando OpenFlow switch protocol

Presentations & Public Speaking

Transcript of Implementare il paradigma Software-Defined Networking utilizzando OpenFlow switch protocol