Protocolli e architetture di instradamento/Introduzione alle Software-Defined Network

Internet è ancora quella che è stata definita 30 anni fa: un tubo molto efficiente che trasporta bit ad alta velocità, con quasi gli stessi protocolli e la stessa filosofia.

Componenti di una SDN.

Gli apparati di rete sono monolitici: ogni router contiene, oltre all'hardware specializzato per l'inoltro dei pacchetti, il suo sistema operativo e le sue applicazioni. Questa infrastruttura è chiusa alle innovazioni: le componenti software non sono installabili dal cliente ma sono imposte dal costruttore dell'hardware, il quale non è interessato a innovare se è il leader del mercato (cioè Cisco).

Le Software-Defined Network (SDN) introducono la possibilità di programmare la rete, e sono basate su tre pilastri:

• separazione delle funzioni di controllo e di inoltro: il software, la componente intelligente, è separato dall'hardware;
• centralizzazione del controllo: l'intera rete è coordinata da un controller, composto da un sistema operativo di rete e da applicazioni di rete definite dall'utente (ad es. protocollo di instradamento, load balancer, firewall);
• interfacce ben definite:
  • northbound: il sistema operativo di rete espone delle API alle applicazioni di rete;
  • southbound: il sistema operativo di rete pilota i nodi della rete, composti da hardware semplice per l'inoltro dei pacchetti.

Il sistema operativo di rete è un livello software che offre una visione globale e astratta della rete alle applicazioni superiori. La visione "dall'alto" della rete consente ad esempio il traffic engineering: le decisioni sono prese dalla logica centralizzata del load balancer e sono perciò coerenti per tutti i nodi di rete:

• modalità proattiva: prima che l'apparato cominci a inoltrare i pacchetti, il controller riempie a priori la tabella di inoltro con tutte le regole necessarie per tutte le sessioni;
• modalità reattiva: quando arriva il primo pacchetto di una sessione, l'apparato lo manda al controller, il quale prende una decisione e comunica all'apparato la regola necessaria per l'inoltro dei pacchetti di quella sessione.

Uno strato di network slicing può far vedere al software anche una topologia di rete diversa dalla reale infrastruttura fisica: può essere configurato in modo da mostrare a ogni istanza di sistema operativo topologie virtuali differenti (ad es. un sottoinsieme dei link reali) → le politiche per il traffico di una certa azienda hanno effetto solo sulla porzione di rete appartenente all'azienda.

Problemi

• controller: può costituire un singolo punto di guasto e un collo di bottiglia;
• versatilità: un firewall ha bisogno di ispezionare tutti i pacchetti, non solo il primo pacchetto della sessione → un sacco di traffico sarebbe generato tra l'apparato e il controller;
• scalabilità: l'hardware per l'inoltro non può essere troppo semplice per ottenere alte prestazioni;
• economia: la semplificazione dell'hardware va contro gli interessi economici dei principali fornitori di rete.

OpenFlow

OpenFlow, introdotto attorno al 2008, è una implementazione dell'interfaccia southbound.

Può essere distribuito in vari modi:

• regole: tipicamente sono basate sul flusso, cioè definite in base alla tupla (indirizzi MAC, indirizzi IP, porte TCP);
• controller: tipicamente è fisicamente centralizzato, ma può anche essere fisicamente distribuito (seppur sempre logicamente centralizzato);
• modalità: tipicamente è reattiva, ma nulla vieta di usare la modalità proattiva.

A ogni regola sono associate una o più azioni, ad esempio:

• inoltra il pacchetto sulla/e porta/e;
• incapsula e inoltra al controller;
• scarta il pacchetto;
• invia alla pipeline di elaborazione classica (cioè la tabella di instradamento classica);
• modifica i campi (ad es. NAT: cambia gli indirizzi e le porte).

OpenFlow 1.3

Ha introdotto alcune funzioni interessanti:

• la tabella di inoltro è suddivisa in varie sottotabelle (ad es. firewall, instradamento, ecc.), e ogni applicazione accede alla sua sottotabella → il matching di ogni pacchetto è effettuato più volte attraverso le sottotabelle in sequenza;
• virtual switch (vSwitch, ad es. Open vSwitch): invece di essere implementato in hardware, OpenFlow è eseguito su uno switch emulato da un processo software → è possibile creare un tunnel logico GRE tra due vSwitch su due server diversi attraverso una rete di switch tradizionali: #Network Function Virtualization.

Problemi

• piano dati: si occupa solo dell'inoltro dei pacchetti → è adatto per ambienti (ad es. datacenter) dove l'inoltro dei pacchetti è un aspetto preponderante rispetto al piano dati, ma non sembra appropriato per la rete di un ISP;
• utilità: l'interfaccia di southbound è meno interessante di quella di northbound: serve per gli sviluppatori di sistemi operativi di rete, non per gli sviluppatori delle applicazioni;
• costo hardware: le regole possono essere basate su un gran numero di campi che rendono le entry molto ampie → le TCAM necessarie sono costose e scaldano parecchio;
• flessibilità: in contrapposizione alla Open Networking Foundation (ONF) (VMware), il progetto OpenDaylight (Cisco) preferisce il Network Configuration Protocol (NETCONF) che, invece di esplicitare le regole, non conosce la semantica dei valori letti o impostati → può essere usato dal controller SDN per configurare delle funzionalità avanzate sugli apparati, come le "rotte di backup" in caso di guasti rilevati essere critici nella rete di un ISP.

Piano dati

Non è solo importante inoltrare i pacchetti nella giusta direzione, ma anche offrire dei servizi orientati al piano dati che elaborano i pacchetti (ad es. firewall, NAT, monitor di rete).

Service Function Chaining senza SDN

Service Function Chaining (SFC) senza SDN.

Oggi i servizi si possono aggiungere ai router di accesso (BNG), oltre che con le service card, collegando dei box chiamati appliance: un'appliance è un dispositivo hardware separato e discreto con software integrato (firmware) dedicato a fornire uno specifico servizio. Le appliance sono collegate in cascata con fili fisici a formare una catena di servizi statica, e ogni pacchetto deve essere elaborato da un servizio dopo l'altro prima di poter uscire dall'apparato.

Svantaggi

• agilità nella fornitura di nuovi servizi: l'appliance deve essere collegata fisicamente all'apparato;
• flessibilità: per collegare una nuova appliance è necessario spezzare temporaneamente la catena interrompendo il servizio di rete;
• affidabilità: un'appliance guasta spezza la catena interrompendo il servizio di rete;
• ottimizzazione: ogni appliance ha a disposizione una quantità fissa di risorse, e nei picchi di lavoro non può sfruttare le risorse eventualmente lasciate libere in quel momento da un'altra appliance.

Service Function Chaining con SDN

Service Function Chaining (SFC) con SDN.

Ogni appliance è collegata a una porta di uscita e una porta di ingresso di uno switch OpenFlow, e i flussi di traffico attraversano una catena di servizi decisa dinamicamente tramite regole OpenFlow che definiscono percorsi da una porta all'altra dello switch.

Vantaggi

• flessibilità: l'aggiunta di una nuova appliance richiede una modifica al volo della regola OpenFlow da parte del controller SDN senza interrompere il servizio di rete;
• affidabilità: è sufficiente una modifica al volo della regola OpenFlow da parte del controller SDN per ripristinare il servizio di rete;
• business: è possibile differenziare i percorsi in base al cliente (azienda) → il traffico passa solo per i servizi che il cliente ha acquistato.

Svantaggi

• agilità nella fornitura di nuovi servizi: l'appliance deve essere collegata fisicamente all'apparato;
• ottimizzazione: ogni appliance ha a disposizione una quantità fissa di risorse, e nei picchi di lavoro non può sfruttare le risorse eventualmente lasciate libere in quel momento da un'altra appliance;
• retrocompatibilità: occorre sostituire gli apparati con switch che supportano OpenFlow.

Network Function Virtualization

Network Function Virtualization (NFV).

I servizi sono implementati in un processo puramente software: lo switch è collegato a vSwitch OpenFlow emulati su più server remoti, e ogni server è dotato di un hypervisor in grado di eseguire delle macchine virtuali (VM) al cui interno sono eseguiti i servizi.

Scalamento

Le prestazioni di un servizio possono essere migliorate in tre modi:

• scale up: vengono assegnate più risorse hardware alla VM → ciò può non essere sufficiente se il servizio non è in grado di sfruttare l'hardware disponibile adeguatamente (ad es. un programma single-thread non trae molto beneficio da un ambiente multi-thread);
• scale out: più VM sono eseguite in parallelo su uno stesso server fisico → è necessario un load balancer per mandare il traffico alla VM meno carica, e le VM necessitano sincronizzazione;
• più server: più VM sono eseguite in parallelo su più server fisici → è necessario un ulteriore load balancer per mandare il traffico al server meno carico.

Vantaggi

• agilità nella fornitura di nuovi servizi: un nuovo servizio può essere attivato dinamicamente scaricando ed avviando la sua immagine software;
• ottimizzazione: le risorse hardware del server sono condivise tra le VM;
• retrocompatibilità: se lo switch non supporta OpenFlow, è possibile sfruttare il tunnel GRE tra i vSwitch senza dover sostituire l'apparato;
• consolidamento: di notte è possibile ridurre il numero di VM eseguite in parallelo (scale in) e diminuire le risorse hardware assegnate (scale down).

Svantaggi

• traffico: il classico modello NFV può richiedere ai pacchetti di viaggiare da un server all'altro attraverso lo switch, intasando la rete su cui i server sono distribuiti;
• efficienza: i server hanno CPU general-purpose, non hardware dedicato (ad es. line card), e non sono attualmente disponibili tecnologie efficaci di accelerazione hardware;
• migrazione: quando l'utente si sposta, l'istanza della VM deve essere spostata sul server più vicino e deve essere avviata nel più breve tempo possibile;
• scalabilità: l'architettura è potenzialmente molto scalabile, ma soffre di problemi di sincronizzazione e di bilanciamento del carico quando più istanze del servizio sono eseguite in parallelo.

OpenStack

Componenti di un sistema OpenStack.

OpenStack, introdotto nel 2010, è un sistema operativo distribuito open source:

• Linux:
  • controlla il singolo host locale su cui è eseguito;
  • l'unità di esecuzione è il processo;
• OpenStack:
  • è eseguito su un server remoto, chiamato controller node;
  • controlla più server fisici distribuiti nella cloud, chiamati compute node;
  • l'unità di esecuzione è la macchina virtuale.

Ogni compute node include i seguenti componenti:

• sistema operativo tradizionale: controlla l'hardware locale del server fisico;
• agente: riceve i comandi dal controller node, per esempio per lanciare le VM;
• vSwitch (ad es. Open vSwitch): connette il server all'infrastruttura di rete.

Uno dei compiti del controller node è lanciare le VM sul compute node correntemente meno carico.