Situazione attuale delle reti e problematiche

1. Situazione attuale delle reti e problematiche

2. Il paradigma Client-Server

3. Situazione attuale delle reti La diffusione di: dispositivi mobili Wi-FI(smatphones, tablets, etc.) server virtualization(storage and network virtualization) servizi di clouding Riesaminare le strutture delle tradizionali architetture di rete.

4. Problematiche delle reti attuali • Dipendenza Dai Produttori • Complessità Strutturale • Staticità • Configurabilità • Scalabilità

5. Possibili soluzioni

6. Possibile soluzione Disaccoppiamento dello strato di controllo da quello dell’inoltro • Superare le barriere dei produttori, ottenendo una astrazione delle infrastrutture fisiche di rete. • Elasticità della rete: operazioni di riconfigurazione topologiche e di instradamento semplici e veloci . • Le reti si libereranno da molti protocolli: strumenti di rete devono limitarsi a seguire le istruzioni provenienti dal controller. Il Disaccoppiamento è la chiave della struttura di una SDN (Software Defined Network)

7. Software Defined Network

8. Architettura Software Defined Network C P O L N A T N R E O L F O R P W L A A R N D E I N G

9. Centralizzazione del controller Il controllo della rete deve essere disaccoppiato dall’HW e posto in un controller SW logicamente centralizzato. Completo controllo sulla rete: modificando il SW si fa in modo che la rete abbia un comportamento differente e un unico punto di controllo che permette di avere una visione dell’intera rete. vantaggio

10. Controlplane

11. Problematiche da affrontare

12. Problematiche SDN SDN introduce nuove problematiche: • la scalabilità di una rete SDN, • la consistenza della rete.

13. La scalabilità del controller SDN Inizialmente conviene pensare al controller come centralizzato, quindi come una applicazione che gira su un nodo della rete, collegato direttamente o indirettamente a tutti gli altri nodi. All’aumentare delle dimensioni della rete tuttavia possono sorgere problemi di performance: un singolo controller potrebbe non essere sufficiente a gestire un’intera rete. A questo punto conviene pensare il controller sempre come logicamente centralizzato, ma fisicamente distribuito su più nodi della rete.

14. Controlplane distribuito Uno switch può essere connesso a più controllori. Questo scenario risulta più robusto di una connessione 1:1, in quanto se un controllore dovesse fallire, ve ne sarebbe un altro attivo che prenderebbe il suo posto. Inizialmente tutti i controllori si dicono Equals, in quanto avranno tutti gli stessi permessi sugli switch che gestiscono. Successivamente uno sarà il Master, cioè colui che ha pieno accesso sullo switch e gli altri saranno Slave e potranno solo monitorare lo stato.

15. Consistenza della rete • come può il controller ottenere (e mantenere) una visione consistente della rete? • quali meccanismi deve attuare il controller per impostare uno stato nella rete, ad esempio modificare il comportamento di un nodo?

16. OPENFLOW

17. OpenFlow Questo protocollo è una interfaccia standard di comunicazione fra il piano di controllo e il piano di forwarding di una architettura SDN. OpenFlow utilizza il concetto di flusso per identificare il traffico di rete: tramite delle regole (match rules) si possono identificare e raggruppare tipologie di traffico differenti, con differente granularità. Il routing tradizionale IP non consente questa flessibilità, poichè è basato unicamente sulle tabelle di routing IP.

18. OpenFlowswitch

19. Flow table Ogni entry della flow table è composta da una coppia <pattern-azione>: • Pattern: è un filtro sul pacchetto. Un pattern identifica un insieme di pacchetti, ovvero un flusso di rete. • Azione: azione/i da eseguire una volta che il pacchetto coincide con il pattern. L’azione può essere ad esempio “inoltra alla porta i”, “scarta il pacchetto”, “spedisci il pacchetto al controller”, etc.

20. Pipeline Processing

21. PacketMatching

22. Actions • Ogni Flow Enrty ha un campo dedicato alle azioni che sono eseguite su di un pacchetto qualora avvenaga il matching. Queste possono essere: • Gestione delle Action Set • Esecuzione della Action Set • Indirizzamento ad una Flow Table

23. SecureChannel Il SecureChannelè l’interfaccia che connette l’OpenFlowSwitch al Controllore tramite l’utilizzo del Protocollo OpenFlow. L’OpenFlowProtocol supporta tre tipologie differenti di messaggi: • Controller-to-Switch: sono messaggi inizializzati dal controllore per gestire o ispezionare uno switch e possono anche non richiedere risposta. • Asynchronus: sono messaggi inizializzati dallo switch ed inviati al controllore per denotare eventi della rete, cambiamenti di stato dello switch o errori. • Symmetric: sono messaggi mandati sia dal controllore che dallo switch in maniera sincrona.

24. Tipi di OpenFlowSwitch

25. Nel caso in cui uno switch perde i collegamenti con tutti i suoi controller, a causa di una disconnessione, dei timers scaduti oppure di errori, deve immediatamente entrare in una delle due modalità. • FailSecure Mode: tutti i pacchetti dello switch che sono destinati ai controllers sono scartati. • FailStandalone Mode: disponibile solo sugli OpenFlow-Enabled Commercial Switch, porta lo switch ad agire come un normale dispositivo Ethernet.

26. Virtualizzazione di rete

27. Virtualizzazione di rete Un ulteriore ingrediente che è parte integrante della visione SDN è rappresentato dalla virtualizzazione di funzioni di rete. Obiettivo: • utilizzo di una stessa piattaforma hardware per realizzare più funzionalità di rete (NFV);

28. NETWORK FUNCTION VIRTUALIZATION

29. NFV Con il termine NFV si intende la capacità di allocare delle funzionalità di rete a piacimento su nodi della rete come se fossero delle entità SW astratte, componibili e estensibili.

30. Network functionvirtualization

31. Funzioni di rete da virtualizzare • Instradamento di pacchetti: router e NAT. • Funzionalità di bridging e switching. • Servizi di storage: NAS. • Strumenti di analisi: deep packet inspection (DPI),analizzatori di traffico. • Strumenti per test e diagnosi. • Funzioni di sicurezza: firewall, server di autenticazione. • Distribuzione di contenuti: server web e server video.

32. Funzioni di rete da virtualizzare • Sarà necessario “re-inventare le funzioni di rete”? • Quanto deve essere effettivamente “generico” l’HW?

33. Previsioni delle reti del futuro

34. Previsioni delle reti del futuro • Migrazione dell’intelligenza verso le parti più periferiche della rete, ovvero l’edge network. • Le reti diventeranno sempre più virtuali: le funzioni di rete saranno sempre più disaccoppiate dall’HW sottostante. • La rete di accesso sarà composta da commodity HW, su cui si potranno allocare le funzioni di rete desiderate a tutti i livelli della scala ISO/OSI (L3+).

35. Ritorno all’end-to-end Un pacchetto partirebbe da una rete edge, attraverserebbe il core (che opererebbe solamente a livelli 1-3 dello stack ISO/OSI) e poi arriverebbe di nuovo a una rete edge, dove verrebbe nuovamente trattato anche ai livelli superiori (livelli OSI 4+, ovvero dal livello di trasporto in su). • Migliori performance • Vantaggi in termini di qualità del servizio , poiché i nodi che forniscono le funzionalità sono più vicini agli utenti