Software Defined Networks and Beyond. Outline

Transcript

1 LEZIONE 28 Uno degli argomenti più nuovi sulle reti attuali, il che vuol dire che i prodotti non sono ancora disponibili perchè non si sa ancora dove si andrà a parare. Fulvio Risso, Politecnico di Torino 1 Outline Introduction Software-Defined s Definition Components OpenFlow Data Plane processing Function Virtualization and Service Chaining Beyond NFV/NSC Standarization bodies Open ing Foundation, Open Daylight 2 The Internet, after 30+ years (1) Internet is still the one we defined 30 years ago Almost the same protocols, same philosophy Internet is a very efficient pipe that transports bits at high speed Gli ultimi 30 anni nel mondo delle reti sembrano avere cristallizzato tutto. Internet è del 1980, TCP lì attorno, R, OSPF, BGP... utilizziamo cose definite 30 anni fa. Questo è curioso, perchè in altri campi del computing c'è stata un'evoluzione pazzesca. Internet è dunque un "tubo": una delle cose che non ha Internet è un "valore aggiunto" a quel tubo. Questo vuol dire che siamo obbligati a usare Internet come lo conosciamo: bit si hanno, bit restano. Una delle ragioni della staticità è la monoliticità degli apparati di rete: questi apparati infatti hanno un componente per fare forwarding (linecard), un SO che gestisce la macchina e tutta una serie di applicazioni (il demone OSPF, il modulino che fa NAT). Tutte le componenti sono all'interno del box di rete: nessuno può modificarli, tranne il costruttore. 3 The Internet and the difficulties to innovate No control on applications Limited control on network paths Cannot extend the Closed to innovations in the infrastructure Questo è molto diverso rispetto a quanto accade in altri mondi. Quando io compro un telefonino io decido che SO mettere sopra. Sono poi sempre io a decidere che applicazioni mettere sopra. Come utente - non ho controllo sulle applicazioni (non posso mettere il mio demone di routing) - non posso estendere il SO e aggiungere funzioni che mi servono - ho un controllo abbastanza limitato rispetto ai percorsi di rete (a OSPF diamo i costi ed è lui che decide i percorsi). Una delle innovazioni dell'ultimo periodo sono stati i programmi P2P, che però girano ai bordi della rete (e non sulla rete). Sarebbe bello scaricare un file da New York e prenderne alcuni pezzettini da una macchina che è più vicina a me. Il problema è che un host vede un client che sta a New York come uno che sta a Torino. 4

2 Software Defined s Paradigm that introduces the possibility to program the network Based on three pillars Separation of control and forwarding functions Centralization of control Well-defined interfaces (northbound and southbound) SDN components Well-defined API Open? Northbound API Simple forwarding switches (in principle, a lookup table) Simpler, faster, cheaper Complex (user-defined) applications Execution environment for control applications (controller) WAN load balancer Routing protocol Extensible Open source? NetOS Open interface to the hardware Standard protocol between controller and data plane switches Southbound API 5 Ecco dunque che nasce l'idea delle SDN. Vogliamo pilotare le reti via SW (posso mettere applicazioni che lavorano sulla rete, definendo il modo in cui è fatta la rete). SDN = proposta di reti di nuova generazione in cui l'utente può modificare come vengono inoltrati i pacchetti (equivalente di nuovi meccanismi di routing fatti in maniera diversa) L'architettura prevede un disaccoppiamento dalla parte HW (che ovviamente rimane nel nodo) da tutto il resto che invece viene tirato fuori. Gli apparati di rete dunque diventeranno "stupidi", come gli switch di L2, mentre tutto il resto viene fatto girare in un server esterno ai box di rete. Le decisioni di inoltro vengono prese dai moduli SW che pilotano gli HW, che è una cosa che succede già adesso: così però c'è separazione tra forwarding e controllo. Seconda idea: centralizzazione del controllo. C'è un server che fa girare l'equivalente dell'ospf. Routing centralizzato. Ci piace poco, perchè siamo arrivati al routing distribuito che invece piace tanto. In certi ambiti, però, il controllo centralizzato è ragionevole: in reti ad alta affidabilità le topologie cambiano abbastanza poco di frequente. Centralizzazione a livello logico, non necessariamente a livello fisico. Le interfacce tra i vari componenti devono essere ben definite, north (tra le APP e SO) e south (tra OS e HW). Questo perchè? La northbound serve per poter scrivere app che vanno sul determinato OS. L'obiettivo principale è permettere di far scrivere agli utenti app che controllano la rete: ci dev'essere dunque un'interfaccia che permette il dialogo con l'os. L'OS a sua volta è in grado di controllare l'intera rete pilotando i box fisici: interfaccia southbound, questa roba una volta non c'era. Dev'essere standard perchè magari voglio avere device differenti. L'OS lo compriamo non necessariamente da chi mi ha venduto l'apparato di rete. 6 An SDN packet flow example WAN load balancer Controller Esempio: mi arriva un pacchetto destinato a una macchina. L'HW non sa che farsene. SDN dice: "prendi il pacchetto e mandalo al controller". L'OS prende il pacchetto e capisce che dev'essere destinato al load balancer, dandolo all'applicazione. Il load balancer decide che il pacchetto dev'essere mandato su X: scrive all'os la decisione, l'os comunica la decisione all'hw e il pacchetto viene inviato. Sul nodo successivo ricomincia il tutto. Un po' lento, no? PCK > X In realtà la decisione si riferisce non al pacchetto ma a una network tuple (una serie di campi configurabili, MAC_S - MAC_D - _S - _ D, Port_S, Port_D): una volta ispezionato il PCK inserisco una regola per cui tutto il traffico che risponde a determinati requisiti fa un suo percorso. La decisione è poi istanziata su uno o più nodi di rete. Se in futuro vengono ricevuti pacchetti che matchano la regola, i pacchetti che arrivano verso il controller sono limitati. Spesso si usano queste regole con le sessioni TCP. 7 Possible functions Synchronization between different physical controllers Virtualization of the network topology Single logical configuration transformed into multiple physical commands 10

3 Software layer that offers a global view of the network to upper applications Right now, we have to configure each single device VLAN, access lists, policies, QoS, The configuration may be incoherent on different devices A NetOS wants to give us the possibility to setup and application that operates across the whole network E.g., check that a new user that connects to the network (from any port) is not infected; if so, give him his privileges/configuration Easy to implement in a centralized controller NetOS may have more features (and a broader scope) in the future 11 SDN and slices >PCK Isolated slices Operating System 1 App App App App App App App App Operating System 2 Operating System 3 Virtualization or Slicing Layer Many operating systems, or Many versions Operating System 4 Open interface to hardware Open interface to hardware Un'altra cosa interessante sono le slices di rete: nome un po' pomposo per parlare di virtualizzazione e VLAN (tecnologia che permette di avere su un'unica infrastruttura fisica tante logiche). Questa esigenza ce la può avere anche un'operatore, che si trova a dover trasportare traffico di tante entità distinte (le nostre ADSL, le aziende che vogliono collegarsi...). SDN permette di realizzare anche questi sistemi: nel momento in cui arriva il pacchetto, decido a livello di controller a chi deve andare e via. A differenza delle VPN tradizionali che sono end to end, l'operatore ha anche il controllo della rete in modo da dire "i pacchetti del Poli passano sopra, quelli dell'uni sotto e non c'è intersezione". In pratica abbiamo il controllo di un tot. di nodi sui quali possiamo installare un nostro sistema operativo. L'operatore di rete mette il suo SO e in più, appunto, esporta la possibilità di installare ulteriori SO su porzioni della macchina. 12 SDN applications Path optimization Fat trees Traffic engineering Bello. Tutto bello. Noi cosa faremmo se avessimo SDN? Boh. Quando io immetto dei dati nella rete, voglio che arrivino dall'altra parte, e questi sono problemi del provider. Le applicazioni ci sono eh, ma tutte per gente particolare: operatori e gestori di data center. Agli utenti finali frega poco. Per flow paths Virtual circuit emulation VM migration Service chaining (presented later) 13 SDN deployment Stable, local networks Datacenters Il deployment di tecnologie SDN non l'ha fatto quasi nessuno. Tranne Google. I vantaggi che ne derivano sono: - network optimization migliore (i link tra i vari data server non permettevano di controllare bene il traffico). Enterprise Edge services (possible) Service chaining model No network service providers so far Except Google 14

4 The good and the bad of SDN Good Bad virtualization forwarding (slicing) hardware E.g., virtual operators, Against the interest of VPNs with network (not major network vendors only edge) support Not scalable (hardware operating system speedup needed) API Focus only on the network as an unique entity In generale, quali sono le cose buone e quelle cattive? Oltre ai vantaggi riportati, gli svantaggi principali sono dati dalla semplificazione dell'hardware: se il mercato degli apparati di rete si trasforma in un mercato in cui tutti riescono a fare tutto, ai grandi questa cosa non piace. Inoltre se io ho in mente altre applicazioni, come ad esempio il firewall, queste non possono sempre girare in maniera centralizzata. 15 LEZIONE 29 OpenFlow è lo standard definito per la southbound interface. A nord non ho standard, perchè il valore è concentrato dove c'è l'applicazione. OpenFlow 16 Introduction OpenFlow idea launched around 2008 Ancestors (e.g., Ethane) published even earlier OpenFlow and SDN Represents a way to implement the southbound interface of SDN SDN can be implemented also with other technologies SDN is what to do, OpenFlow is how to do Flow-based, centralized controller, reactive control E' stato introdotto attorno al 2008 e ha diviso un po' la comunità tra convintissimi e schifatissimi. Si tende a mettere insieme OpenFlow e SDN dicendo che SDN è OpenFlow: in realtà non è vero, come abbiamo visto. OpenFlow è una delle possibili definizioni della southbound interface. E' flow-based (lavora su flussi di traffico e non sui singoli pacchetti), lavora con un controller centralizzato (non prevede controller distribuiti) e c'è un controllo di tipo reattivo (il deployment è fatto secondo la seguente strategia: arriva del traffico al data plane, che non sa come gestirlo, si contatta il controller e il controller dice come fare). Non vuol dire che non si può usare in modalità proattiva, ma nessuno lo fa 17 Software Layer Layer MAC src MAC dst OpenFlow Flow Table Abstraction OpenFlow Firmware Flow Table Src Dst TCP sport TCP dport Action(s) * * * * * port 1 port 1 port 2 port 3 port Controller PC 18 OpenFlow è costituito dal protocollo di scambio tra il controller e il PC, che richiede che il nodo di rete abbia una tabella con tante righe. Su ogni riga c'è un insieme di dati di rete che ci permette di selezionare il flusso del traffico. A ogni riga c'è associata un'azione. Nell'esempio il traffico destinato a dev'essere inoltrato sulla porta 1. La cosa è strettamente parente di un packet filter. In origine si faceva su sessioni TCP (MAC_S, MAC_D _S, _D). Una volta identificato un flusso associamo un'azione. Quando un pacchetto arriva nel nodo viene fatta un'operazione di matching con tutte le righe presenti nel nodo: se c'è match si fa l'azione, altrimenti si manda il pacchetto al controller (cosa fatta con una regola a più bassa precedenza). Sull'oggetto OpenFlow non c'è un control plane. L'equivalente, ad esempio, di un demone OSPF, va messo sul controller.

5 OpenFlow Basics: Flow Table Entries Rule Action Stats Packet + byte counters Azioni previste: 1. tutti i pacchetti che matchano una certa regola vanno su una porta 2. prendi il pacchetto e mandalo al controller 3. butta via (4. manda alla tradizionale pipeline di processing del router) (5. modificare dei campi, utile se dobbiamo implementare NAT) 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline 5. Modify Fields (optional) Switch port VLAN ID MAC src MAC dst Ether type src dst proto TCP sport TCP dport + mask for selecting which fields to match 19 The good and the bad of OpenFlow Good Bad Vantaggi e svantaggi. Funzionicchia e prima non ce l'avevamo. Prestazioni ridicole, scalabilità ridicola, va bene solo per applicazioni control plane. A possible way to implement SDN So far, probably the only available choice FORCES? May be suitable for some (limited) environment Datacenters, enterprise campus forwarding hardware OpenFlow 2.0 still a dream Does not seem appropriate to large networks (ISP) Mainly focused on the network Although some data planeoriented primitives are being introduced 26 Secondo alcuni il dataplane è molto più importante del controlplane, specie nell'ottica dell'utente finale a cui interessa molto più ricevere pacchetti (e riceverli senza problemi di sicurezza). Data plane processing 30 Service Chaining (now) [ ] ==== ISP edge router WAN accelerator IDS Monitor QoS Uno dei problemi grossi degli operatori, soprattutto al bordo della rete, è la quantità di box che si usano per fare una certa funzione. Nell'esempio noi siamo collegati con la nostra ADSL a un BIRAS (nodo gigantesco che concentra un tot. di connessioni). Ci può essere la necessità di monitorare il traffico: metto un network monitor. Ci può essere bisogno di QoS, perchè magari qualcuno sta succhiando troppa banda: altro box. C'è la necessità di connessioni di rete protette: firewall + IDS. Due box. E così via. Il numero di box discreti che fanno una sola cosa e vanno messi nella rete diventano esorbitanti. Il box per fare network monitor può lavorare in modalità passiva (riceve copia del traffico e poi ci fa le sue elaborazioni), ma tipo il box che fa QoS proprio no. Mettere un box poi ha i suoi bei costi (analisi + lavoro effettivo) 31

6 Service Chaining (with SDN) Flow table SDN controller WAN accelerator monitor QoS OpenFlow switch La soluzione che si sta proponendo è: ma perchè non usare Open- Flow per risolvere questo problema dei moduli in cascata? Prendiamo il BIRAS e colleghiamolo a uno switch OpenFlow. Prendiamo un FW e colleghiamolo allo switch con 2 link. Poi prendiamo un controller e configuriamo una regola che sfrutti il FW. Il firewall è in cascata sul traffico, ma il FW non è fisicamente in cascata sul filo. In questo modo posso cambiare facilmente la configurazione del controller. Così via per altri moduli. Passiamo da un'architettura lineare a una di tipo stellato, realizzando una catena di servizi con la granularità che più mi piace. Questo scenario è estremamente interessante per un operatore. IDS 32 NSC characteristics Agility in provisioning new services Install the box, then routing is done via software instead of connecting the box to the other with physical wires Maintenance and reliability Cabling is done once Different customers can have different service chains routing done via software, even possible to change its decisions based on other parameters (e.g., application layer content) Difficult to partition a physical appliance among different tenants Many small business customers, each asking for a firewall service 33 Functions Virtualization VM 1 VM Hypervisor WAN accelerator VM 2 Flow table App1 App2 SDN controller Step immediatamente successivo a NSC. Dal punto di vista concettuale non cambia nulla. I box prima infatti erano box fisici. In NFV mi compro un server sul quale metto un hypervisor, dentro creo una o più macchine virtuali e su quelle installo il mio firewall. Vantaggio: molto più flessibile sul provisioning della risorsa. Prima magari abbiamo un firewall che lavora al 5% della CPU e il 95% non lo uso. Così sul server invece posso far girare più network function. L'OpenFlow switch però non è più sufficiente a mandare il traffico al posto giusto: il traffico va al server, e nell'hypervisor ci dev'essere una specie di "smistatore" dallo switch fisico agli switch logici. IDS VM 1 QoS VM 2 NetMon VM 3 OpenFlow switch Evitiamo così di avere tonnellate di HW per una sola network function. Diventa più facile partizionare il carico su N server diversi. VM Hypervisor The good and the bad of NFV Good Bad Data plane-oriented Not very efficient Can leverage data center Data plane tasks are resources (VMs, network) simple and may benefit and existing (software) from (simple) hardware frameworks acceleration Potentially very scalable Syncronization problems Easy to assign a different when an application service instance to each instance need to be tenant installed in multiple VMs 34 Detto così è tutto molto bello, ma non è chiaro se il mondo alla fine sarà così: l'openflow switch è stupido, e questo può essere un problema. Specie perchè i grandi non sono contenti. Questa roba però può essere una figata, perchè se io voglio implementarmi un mio personal firewall caricandolo sul nodo di rete diventa una cosa multipiattaforma (nel senso che indipendentemente dal dispositivo fisico che uso per accedere alla rete ho sempre le mie politiche implementate). D'altro canto ci possono essere problemi di scalabilità e dunque bisogna fare VM un po' più "stringate" 35

7 Some considerations about NFV The classical NFV model may require packets to travel several times back and forth to the switch VMs are good when we need to consolidate many (tiny) application instances on the same physical servers Traffic increase Scaling in An application that requires so many resources that even a dedicated server is not enough must be handled by hand Scaling out 36 Non è detto che il mondo migri a OpenFlow. E' possibile che il mondo migri ad architetture specifiche per la rete, ma non troppo specifiche. Gli apparati futuri potrebbero avere componenti in qualche maniera general purpouse e componenti un po' più orientati al mondo delle reti. Future integrated routers for NFV (1) General purpose processing linecards processing linecards 37 Future integrated routers for NFV (2) s with general purpose processing + network processing More efficient (possibility to exploit hardware accelerators) More scalable Reduced network traffic to/from the router s may become hybrid platforms supporting different kind of applications From network applications to traditional VMs Different hardware accelerators may be available Each application can be mapped on the best processing component Mapping can be done even at finer granularities (at the module level) 38 Qui è riportata la differenza visiva. SDN prende gli stessi dati e li riporta in uscita. In NFV/NSC ho due box distinti: un router stupido che manda i dati su box che modificano i dati. Nel futuro ci si aspetta una cosa più integrata, in cui i box di rete abbiano la capacità di modificare il traffico. SDN vs. NFV/NSC Web cache ache NAT all SDN NFV/NSC (today) NFV/NSC (future) 40

8 Hard to define a suitable southbound API Destination Port L2 bridging Bus, crossbar Critica su OpenFlow. In OpenFlow il router è sostanzialmente una lookup table. E Open- Flow ci permette di configurarla. Se invece dobbiamo fare anche data plane, il modello del router si complica. Il modello di sx non è assolutamente adatto se voglio fare una rete in cui voglio personalizzare gli applicativi data plane. Net 1 Net 2 port1 port3 Memory (TCAM, SRAM, DRAM) Deep Packet Inspection Net 3 Net 4 port1 port2 L3 routing Dedicated ASICs Lookup table VPN accelerators QoS NAT processor The view of a router from a perspective The view of a router from a Computing perspective 41 Slim or fat routers? SDN predicts routers are slim Data plane performance requirements (and the relative simplicity of data plane tasks) suggest that (at least edge) routers need to be fat Slim routers suggest that the network will become a dumb pipe Fat routers may suggest that the network will still have advanced processing capabilities Hence, intelligence Hence, value Slim routers are good for low value, low margins vendors Fat routers are good for current network vendors 42 Standardization 43 Standardization bodies Open ing Foundation Vmware Open standards for SDN OpenDaylight Open source framework (including architecture), to accelerate and advance a common, robust SDN platform IETF Service Chaining working group Uno dei grossi problemi è che quando ci sono troppi appetiti dal punto di vista economico, cominciano a esserci problemi. OpenFlow è stato preso da VMWare, che ha definito una fondazione che tanto open non è e sta cercando di standardizzare OpenFlow. Il problema è che Cisco e VMWare non vanno d'accordo, così Cisco ha rilanciato con OpenDayLight, in cui non si punta a fare uno standard ma cerca di rilasciare in open source il numero maggiore di componenti. ETSI Functions Virtualization 44

9 OpenDaylight 45 Are standards really needed? User program User program User program Non è neanche chiaro se gli standard siano necessari. Se noi facessimo infatti una correlazione tra mondo delle reti e mondo dei PC troveremmo un sacco di somiglianze. Dal punto di vista architetturale c'è una notevole correlazione: ci sono standard nei PC? Pochi. Compilers Programming languages Libraries Northbound interface Southbound interface Also general computing has northbound and southbound interfaces, and no standards exist 46 Thanks for your attention! 47