SDN e NFV: quali sinergie?

Transcript

1 48 Usa il tuo smartphone per visualizzare approfondimenti multimediali SDN e NFV: quali sinergie? Luigi Grossi, Eugenio Maffione, Giancarlo Marasso, Simone Ruffino

2 49 Le funzionalità di controllo e i servizi di rete sono oggi realizzati tramite dispositivi hardware proprietari. Inoltre il lancio di un nuovo servizio e l aggiornamento di uno esistente spesso richiedono un intervento fisico sulla rete, con impatti importanti in termini di time-to-market e costi. La NFV ( Functions Virtualisation) si propone di affrontare questi aspetti, facendo leva sulle tecnologie di virtualizzazione IT per consolidare apparati e funzionalità di rete su server standard e fornendo nel contempo una maggior flessibilità operativa. 1La virtualizzazione delle funzioni di rete La virtualizzazione delle funzioni di rete, nota come NFV, introduce un sostanziale cambio di paradigma nel modo i cui vengono realizzate le reti di telecomunicazioni, spezzando il legame tra hardware e software. Con NFV le funzionalità di rete (e.g. PCRF, AAA, DPI, GGSN) diventano infatti applicazioni software, denominate VNF VNF (Virtual Function), che l Operatore può istanziare su server COTS (Commercial Off- The-Shelf), ad esempio i classici blade system, sfruttando le tecnologie di virtualizzazione. Ciò viene realizzato tecnicamente tramite l utilizzo su ogni server di un livello di astrazione (denominato hypervisor), che permette di creare più server virtuali VM (Virtual Machine) sullo stesso server fisico (vedi la Figura 1). Le funzionalità di una VNF quindi vengono tipicamente realizzate attraverso moduli software in esecuzione su una o più VM, che possono svolgere compiti diver- VNF VNF VNF Compute ing Physical Machine Figura 1 - Modello di riferimento per NFV Storage si (e.g. load-balancing, processing della segnalazione, routing del traffico dati) e possono a loro volta essere istanziate su uno o più server fisici. Il meccanismo è analogo a quanto avviene oggi per i servizi IT in esecuzione su piattaforme di cloud computing, con la differenza che le VNF possono Esempi di applicazioni PDN/Serving GW MME e/o SGSN HSS DPI e/o firewall IMS/MMTel Policy Manager BRAS AAA DNS... VM #1 VM #2 Other VMs Hypervisor (e.g. VMWare) Server general purpose (e.g. x86) richiedere opportune ottimizzazioni sull hardware per soddisfare i requisiti di ritardo, scalabilità, ridondanza geografica e gestibilità tipici delle reti di telecomunicazioni. L impiego delle tecniche di virtualizzazione permette di rendere il software indipendente dal har-

3 50 dware sottostante, le cui specificità vengono mascherate dal sistema di virtualizzazione. Questo consente di: ottimizzare l uso delle risorse attivando sullo stesso server fisico più server virtuali che implementano diverse tipologie di servizio, in modo da sfruttare appieno la capacità disponibile e ridurre il consumo energetico; ampliare o ridurre in modo dinamico la capacità allocata in base al carico effettivo. Ciò può essere ottenuto incrementando o riducendo le risorse assegnate ad ogni VM o variando il numero delle VM che realizzano una specifica funzione; garantire alta affidabilità, in quanto a fronte di un malfunzionamento hardware le VM possono essere spostate da un server fisico all altro; riconfigurare la topologia della rete in tempo quasi reale per ottimizzarne le prestazioni e/o estenderne la distribuzione locale; ridurre significativamente TCO (Total Cost of Ownership) e Time-to-Market, sfruttando la maggiore agilità e flessibilità offerta da questa tecnologia. Occorre altresì segnalare alcuni punti di attenzione per l Operatore: le VNF non possono essere un semplice porting del software oggi utilizzato su hardware proprietario, ma vanno progettate per funzionare in ambiente cloud e sfruttarne appieno le caratteristiche; l Operatore si deve dotare di una piattaforma di orchestrazione per automatizzare la gestione del ciclo di vita delle VNF, al fine di evitare interventi manuali sulle VM e sull infrastruttura sottostante. È inoltre necessario che la piattaforma di orchestrazione interoperi con VNF di Vendor diversi; alcune componenti software sono già disponibili come open source e sono utilizzate in molti ambiti di produzione, anche in virtù del fatto che la loro apertura garantisce una maggiore protezione dai vendor lock-in rispetto alle soluzioni proprietarie. Non è da escludere che progetti simili siano avviati anche per la piattaforma di orchestrazione e che gli operatori possano avere un ruolo attivo; a differenza di quello che accade oggi la piattaforma hardware diventa comune a diverse funzionalità di rete e ciò potrebbe richiedere una revisione dei processi ed una diversificazione dei ruoli organizzativi. Le iniziative di standardizzazione ed il 2 ruolo dell open source Nel novembre 2012 un gruppo di Operatori, tra cui Telecom Italia, ha proposto la creazione di un gruppo di lavoro per incentivare l utilizzo della virtualizzazione nell industry. Da questa iniziativa è stato creato l ETSI ISG (Industry Specification Group) NFV ( Functions Virtualization) con durata biennale e l obiettivo di definire use case, requirement e un architettura di riferimento. Tale architettura, illustrata in Figura 2, introduce i diversi domini nei quali si divide una rete NFV: Infrastruttura, che comprende le risorse fisiche e quelle virtuali rese disponibili dallo strato di virtualizzazione; Virtual Functions, che comprende l insieme delle macchine virtuali che realizzano la funzione di rete o il servizio virtualizzato; Management and Orchestration, che comprende i tool necessari alla gestione degli altri domini. Il gruppo ha visto nel corso del 2013 una notevole crescita del numero di partecipanti dai 52 di Gennaio 2013 ai 184 di Febbraio 2014 dimostrando che l interesse per la tematica è alto. Nel corso del 2013 sono stati anche avviati numerosi PoC (Proof-of-Concept) con l obiettivo di dimostrare la fattibilità della virtualizzazione, coprendo molti degli use case definiti da ETSI. Alcuni sono stati dimostrati in occasione del Mobile World Congress di Barcellona ed altri lo saranno durante i principali eventi relativi ad NFV. Una sessione speciale dedicata ai PoC ETSI è prevista per il SDN World Congress di Düsseldorf in Ottobre. Inoltre è da segnalare che, sempre nell ambito delle aziende che partecipano al gruppo ETSI NFV, si sta formando un consorzio partecipato da Operatori e Vendor per la definizione di una Piattaforma NFV Open Source guidato dalla Linux Foundation. L obiettivo è quello di contribuire, a partire dai progetti open source già esistenti, alla realizzazione di una piattaforma di riferimento per NFV che recepisca i requisiti definiti in ETSI per la realizzazione di funzioni NFV Carrier Grade. Il focus iniziale sarà sul livello di virtualizzazione ed il relativo manager VIM (Virtual Infrastructure Manager), ma non è escluso che il consorzio, una volta formato, decida di inserire nel progetto anche una parte focalizzata sull orchestratore.

4 51 OSS/BSS Virtual Functions EMS#1 EMS#2 EMS#3 VNF#1 VNF#2 VNF#3 NS Catalogue VFV Instances Orchestrator VNF Manager(s) VFVI Resources VNF Catalogue Infrastructure Virtual Computing Virtual Storage Virtual Computing Hardware Virtualisation Layer Storage Hardware Hardware Resources Hardware Virtualised Infrastrutture Manager NFV Management and Orchestration Figura 2 - Architettura di riferimento per NFV 3Le tecnologie a supporto della NFV 3.1 Le CPU e l Hypervisor L'attuale generazione di server industry-standard offre CPU x86 multi-core, con numero di core sempre più crescente all evolvere della tecnologia. Questa potenza di calcolo viene sfruttata dalle architetture Cloud Computing per consolidare più carichi elaborativi sullo stesso hardware. Ciò è reso possibile dall utilizzo degli hypervisor, programmi software che consentono di presentare le risorse hardware a più istanze di VM (Virtual Machine), in modo che ciascuna di queste istanze possa essere utilizzata come un computer dedicato, con propri processori, memorie, reti, sistema operativo, ecc. Questa capability è realizzata sui processori commerciali (es. architettura X86) modificando opportunamente i Processing Mode, in modo che l hypervisor possa prendere il controllo del sistema con poteri superiori rispetto a quelli del sistema operativo stesso. Le moderne CPU, inoltre, forniscono livelli di privilegi di esecuzione che garantiscono che la singola VM non possa danneggiare l esecuzione delle altre macchine virtuali che condividono le stesse risorse fisiche, né possa interferire con i processi del sistema ospitante. Le piattaforme hardware e gli hypervisor sono i principali building blocks del dominio Infrastructure rappresentato in Figura Il Cloud Management System Al crescere del numero di server fisici su cui risiedono gli hypervisor è necessario prevedere un ulteriore livello di astrazione che consenta di vedere un insieme di macchine fisiche come un unico pool di risorse.

5 52 Il compito del CMS (Cloud Management System) è appunto quello di consentire, attraverso una console di gestione, di creare, attivare, migrare, sospendere o spegnere le VM, di distribuire i workload a seconda della disponibilità delle risorse e di configurare la connettività tra le applicazioni in relazione alle esigenze dei servizi che esse implementano. Il livello di servizio abilitato da un CMS è di tipo infrastrutturale IaaS (Infrastructure as a ) e i risparmi di costi operativi derivanti dagli automatismi forniti da un CMS rappresentano uno dei grandi vantaggi promessi da NFV. Sul mercato sono presenti diverse soluzioni di CMS, sia nell ambito di prodotti commerciali sia nell Open Source. Tra queste ultime assume particolare rilevanza OpenStack, progetto originariamente promosso da Rackspace e NASA e con oltre 200 società che si sono unite al progetto tra cui AT&T, AMD, Cisco, Dell, EMC, Ericsson, F5, HP, IBM, Intel, NEC, NetApp, Red Hat, SUSE, VMware, Oracle e Yahoo! OpenStack ha un architettura modulare, rappresentata in Figura 3 ed estendibile a plugin. Esso consente di gestire sia hypervisor (KVM, XEN, Vmware, Hyper-V e Linux container), sia bare metal e supporta, in ottica multi-tenant, la definizione di utenti con ruoli e autorizzazioni differenti. Il Cloud Management System costituisce, all interno dell Architettura ETSI di Figura 3, uno degli elementi principali del dominio di Management and Orchestration, ricoprendo il ruolo del Virtualised Infrastructure Manager. 3.3 L orchestrazione delle risorse Nell ambito NFV, la complessità e i requisiti delle funzioni da virtualizzare, la loro distribuzione geografica e la garanzia del rispetto dei livelli di servizio richiedono la presenza di un ulteriore elemento di controllo, che si occupi della gestione dell intero ciclo di vita delle VNF, rispetto all infrastruttura sottostante esposta dai CMS/ VIM, e fornisca tutti gli automatismi e gli strumenti necessari a gestire scalabilità e fail. Questa attività di coordinamento viene chiamata Orchestrazione e comprende i moduli Orchestrator e VNF Manager dell architettura ETSI di Figura 3. Essi complessivamente indirizzano, tra gli altri, i seguenti aspetti: s Instantiation: automatizzazione dell intero ciclo di vita delle VNF (deployment and post deployment) e procedure automatiche per assicurare high availability e fail-over; Component Monitoring: monitoraggio delle macchine virtuali che eseguono le VNF e monitoraggio applicativo (Application Performance Management) per lo stato di salute delle VNF; SLA Management: strumenti per la definizione degli SLA associati all esecuzione delle VNF e definizione di Alert in caso di violazione; Elastic Scaling: definizione di policy di Scaling-out, ovvero di Figura 3 - Moduli componenti di OpenStack Dashboard (Horizon) Compute (NOVA) Image (GLANCE) Object Storage (SWIFT) ing (QUANTUM) Block Storage (CINDER) Identity (Keystone)

6 53 aggiunta di nuove istanze di VNF a fronte di un maggior carico, o di Scaling-in, ovvero riduzione delle stesse a fronte di una riduzione del carico; Software Upgrade: gestione delle fasi di aggiornamento, anche a caldo, del software di una VNF; Termination: arresto di un servizio e di tutte le VNF quando non è più necessario. L'automazione fornita dall orchestrazione, che evita all Operatore l interazione diretta con i CMS/ VIM, consente di ridurre sostanzialmente i costi operativi e il rischio di errore umano. In prospettiva, un approccio di questo tipo, potrebbe anche essere esteso per abilitare verso la Clientela la fornitura di servizi di rete in modalità self-service e payas-you-go. 3.4 Le nuove tecnologie Carrier Grade In ambito IT le architetture multicore, per le quali è ipotizzata un evoluzione in strati sovrapposti che dovrebbe consentire il proseguimento della validità della legge di Moore oltre i limiti fisici di densità dei chip monostrato, costituiscono il naturale supporto hardware per i sistemi virtualizzati del prossimo futuro. In quest ottica i costruttori hanno iniziato ad integrare nelle nuove CPU funzionalità specifiche per gli hypervisor. Parallelamente, le soluzioni per Data Centre stanno evolvendo verso architetture modulari in rack in cui i moduli, separatamente estraibili a caldo e interconnessi da sistemi ottici, sono visti come un unico sistema di calcolo, aumentando il beneficio di consolidamento delle risorse e consentendo una maggiore affidabilità complessiva. Rispetto a quanto descritto che è già parte di un evoluzione in atto per supportare le soluzioni virtualizzate di IT, si stanno osservando anche due ulteriori trend che indirizzano le specificità dei workload delle VNF, che possono presentare requisiti aggiuntivi rispetto ai requisiti tipici dei workload applicativi (IT) e richiedere pertanto la disponibilità di risorse hardware e software con determinate caratteristiche. In particolare, infatti: le VNF che gestiscono la segnalazione nel livello di controllo della rete, possono includere al loro interno processi che devono essere eseguiti con garanzie di latenza deterministica; le VNF che lavorano sul traffico user plane, devono anche poter ricevere, processare e trasmettere pacchetti di traffico a througput vicini al line rate delle schede fisiche, senza limitazioni dovute ai layer software che virtualizzano l hardware sul quale sono ospitate. I due trend tecnologici che si osservano per affrontare le peculiarità delle VNF riguardano: l hardware: tramite la proposizione di piattaforme Carrier Grade che si differenziano per: a) chipset Communication Oriented per supportare la virtualizzazione dell accelerazione hardware di encryption e compression; b) Card con meccanismi di offloading per lo switching tra VM; c) nuove architetture di processore che rendono minima la differenza tra le prestazioni del processing su piattaforma virtualizzata e quelle di su sistema baremetal COTS dedicato. il software: tramite la customizzazione di sistemi operativi, di derivazione Linux, per fornire, oltre a scheduler di processo ad alta risoluzione ed il supporto al processing real time, anche l esposizione diretta (pass-through) delle caratteristiche hardware dedicate al networking. Tali sistemi operativi Carrier Grade offrono inoltre una serie di caratteristiche aggiuntive per concorrere al raggiungimento degli SLA dei servizi ospitati in grado di supportare l operatività nelle fasi critiche di patching, upgrade e fail (live patching, checkpointing & snapshot, hot swapping, fast migration). L infrastruttura COTS per NFV tende, quindi a differenziarsi, almeno per il momento, rispetto all infrastruttura normalmente utilizzata in ambito IT, dove, da una parte l adozione di hardware network oriented, attualmente più costoso, non porterebbe grande giovamento, in quanto i workload IT sono tipicamente CPU intensive, e dall altra l uso di scheduler ad alta risoluzione si tradurrebbe in un puro spreco di risorse computazionali, in quanto il razionale sottostante per l ambito IT è l oversubscription (ovvero massimo utilizzo dello stesso hardware per gestire il maggior numero di workload) più che l ottimizzazione della latenza di processo. È da ritenere tuttavia che, in futuro, vi sia un appiattimento verso l alto delle caratteristiche hardware e quindi, anche solo per economia di scala, si possa convergere verso una soluzione infrastrutturale comune sia per l ambito IT che NFV, pur restando diverse le caratteristiche utilizzate.

7 54 4 Il posizionamento dei Vendor Il panorama dei vendor che presentano soluzioni che afferiscono al paradigma NFV è molto vasto e comprende: Vendor tradizionali del mondo, attivi nell offerta sia di versioni virtualizzate dei loro prodotti basati oggi su appliance fisiche, sia di soluzioni di orchestrazione dedicate a NFV; Vendor di provenienza IT che dispongono di soluzioni consolidate per l orchestrazione di applicazioni IT e che ora estendono la loro linea di prodotti per coprire anche le peculiarità dell orchestrazione NFV; Startup, che intravedono l opportunità di inserirsi in un mercato ora più aperto ed estremamente promettente, sia nell ambito delle Function, sia in quello delle piattaforme di orchestrazione; Vendor di hardware, con le piattaforme COTS Carrier Grade, orientate alla gestione di workload NFV, che cominciano a supportare anche requisiti ambientali (es. condizionamento, power supply etc.) tipici degli ambienti di Centrale, rilassando quindi quelli più stringenti relativi ai DataCentre IT; Vendor di software infrastrutturale: con i sistemi operativi Carrier Grade, in grado di coprire i requisiti critici di latenza di processing e throughput dei workload NFV. Alcuni vendor stanno fortemente investendo sul tema e hanno attivato programmi volti al consolidamento delle best practices e alla interoperabilità all interno dell ecosistema stesso, mentre altri, più legati a difendere posizioni di mercato tradizionali ormai consolidate, presentano prodotti ancora poco maturi e con roadmap di evoluzione in via di definizione. Tuttavia, l enfasi sempre via crescente da parte di tutti attorno all NFV lascia presupporre che nei prossimi 6-12 mesi la competizione nell offerta di soluzioni NFV mature possa aumentare. 5 I sistemi di gestione nelle VNF L avvento della tecnologia NFV costituisce un forte elemento di discontinuità per l ecosistema di un Operator, soprattutto per i diversi paradigmi funzionali e di gestione che propone e che non potranno non riguardare un accurata revisione dei propri processi e dei sistemi a supporto. Mentre l OSS tradizionale è progettato ponendo al centro l apparato di rete e quindi considerando le problematiche di integrazione ad ogni cambio di versione e modello e i limiti di interazione che si possono manifestare, con NFV il concetto di apparato di rete sostanzialmente scompare, sostituito dalle componenti delle VNF distribuite nel Cloud dove i sistemi di gestione opereranno, oltre che sui tradizionali FCAPS, anche nell ottica real-time per far raggiungere alla rete gli obiettivi di qualità, elasticità e di efficienza della nuova architettura distribuita. Per questa ragione il modello informativo/dati di molti sistemi dovrà evolvere ed indurrà un cambiamento di scenario del panorama OSS costituendo sia una forte innovazione che un elemento di criticità importante, tenendo conto che vi sarà un periodo non breve di coesistenza tra due mondi gestionali diversi, che dovranno garantire insieme l uniformità gestionale e contemporaneamente sostenere i nuovi dettami dell evoluzione della rete. Considerando i due macro processi di Fullfilment e Assurance, il primo di questi contiene un importante sotto processo, Creation, che si occupa del Design & Deployment del servizio e spazia dall ingegnerizzazione del catalogo alla verifica di fattibilità tecnica su base cliente. Con NFV i sistemi di supporto dovranno essere in grado di garantire la fase di Design, tenendo presente la distribuzione nel Cloud e quindi le relazioni tra VNF, infrastruttura e link di connessione, e dovranno essere in grado di simulare in back-office le policy imposte e l impatto su diverse distribuzioni ed attivazioni delle funzionalità di rete virtuali. Ultimata la fase di Design subentrerà il Deployment e l Activation del servizio in Rete e ciò avverrà attraverso l interfaccia Os-Nfvo (Figura 4) con cui avviene il governo dell architettura NFV. Tale interfaccia, ancora in corso di definizione, di fatto costituisce lo strumento per l aggiornamento automatico del catalogo da parte dell OSS-Creation, per la presa in carico dell ordinativo di lavoro ( Order) e per l inoltro all OSS delle informazioni relative alle risorse di rete (NFV, logiche e fisiche) impegnate per un determinato servizio. La Figura 4 illustra lo scenario di integrazione OSS-NFV. Il Fullfilment subirà quindi un forte impatto dall introduzione NFV, non solo a livello di sistemi di supporto, ma anche di processo ed in particolare nella gestione dell ecosistema delle VNF, che eseguite su piattaforma hardware comune,

8 55 OSS Layer FULFILLMENT Design Deployment catalog/inventory Activation Catalog/ Inventory Alignment Order ETF MANO Os-Nfvo NFV Orchestrator (NFVO) NFV Catalog VNF Catalog NFV Instances NFVI Resources NFV-MANO Problem managelent Quality Management Capacity Management Data Analytics, Alarms/QoS Monitoring, Accouting and Usage records EMS Vetn-Vnfm ASSURANCE NFVI Nf-Vi Figura 4 - Integrazione OSS con l architettura NFV dovranno avere una governance centralizzata. Per l Assurance, si evidenziano alcuni processi ritenuti rilevanti nel contesto NFV: il Problem & Quality Management ed il Capacity Management (quest ultimo del tutto nuovo dovuto all introduzione della virtualizzazione in Rete). In questo ambito l impatto dipenderà caso per caso dal ruolo del sistema stesso. In taluni casi sarà minimale e concentrato soltanto sull adeguamento delle interfacce, in altri casi sarà consistente, ma molto dipenderà dalla flessibilità del modello dati dell OSS. Ad esempio ci si attende che i sistemi di monitoraggio abbiano sufficiente flessibilità sia per accogliere che rappresentare i nuovi indicatori NFV, mentre in altri casi, come per i sistemi di troubleshooting, l impatto sarà molto elevato perché occorrerà gestire il nuovo concetto di Graph dell NFV ossia il legame VNF, infrastruttura e link tra VNF. Come illustrato in Figura 4, in ambito Assurance oltre all interfaccia Os-Nfvo occorrerà integrare anche quella rivolta agli EMS (Element Manager) e quella rivolta all infrastruttura di virtualizzazione (NFVI). L effettiva complessità e disponibilità funzionale dell OSS di Assurance dipenderà anche da quanto reso disponibile dal fornitore della tecnologia NFV essendo tali interfacce un ambito al momento non oggetto di standardizzazione. In generale comunque possiamo asserire che l NFV induce un beneficio nel processo di Assurance in quanto l OSS non dovrà più dialogare con gli apparati di rete con tutti i limiti specifici, ma disporrà di interfacce informatiche moderne, che consentiranno più celerità nella gestione di nuovi servizi, un inventory sempre allineato e la disponibilità di informazioni in realtime. Un notevole contributo esterno al raggiungimento dell efficacia gestionale delle NFV crediamo possa giungere anche da quanto prodotto dal Tele Management Forum, che con l Information and Business Process Frameworks potrà contribuire fortemente alla definizione del modello informativo e dei processi di gestione.

9 56 Il SDN e le sue sinergie con la Function Virtualization Il SDN (Software Defined ing) è una proposta di organizzazione dell architettura di rete, in cui lo strato di controllo è disaccoppiato da quello di forwarding e diviene programmabile. Le funzionalità di controllo, finora strettamente legate a dispositivi di rete implementati secondo un approccio monolitico", migrano a tendere verso uno strato di controller SDN o sistema operativo di rete ( OS) separato. I principi di astrazione introdotti dal modello e la definizione di relative interfacce di programmazione API (Appplication Programming Interface) tra gli strati dell architettura mirano a consentire alle applicazioni di definire i servizi di rete tramite una vista logica della rete stessa, astraendo dalle specificità dei singoli dispositivi. La Figura A riporta una vista logica dell architettura SDN, secondo l attuale visione della Open ing Foundation, principale ente impegnato nella definizione di standard per il mondo SDN. L interfaccia tra il controllo e i dispositivi del data plane è costituita, in questo caso, dal protocollo OpenFlow, tuttavia questo protocollo non è l unica possibilità di implementazione della cosiddetta API SouthBound. Lo strato dei controller SDN ha, tra gli altri, il compito di mantenere una vista globale della rete, sollevando le singole applicazioni dall onere di ricostruire la topologia, permettendo loro di concentrarsi sui loro obiettivi specifici, quali ad esempio il calcolo degli instradamenti secondo opportune policy o di percorsi in grado di soddisfare a criteri di traffic engineering. I benefici attesi da un evoluzione verso il paradigma SDN sono da ricercare in una riduzione dei costi dei dispositivi di rete (CapEx), grazie ad una maggiore segmentazione del mercato, e dei costi operativi (OpEx), grazie ad una semplificazione dell architettura di rete e delle procedure di gestione. Inoltre ci si aspetta che la programmabilità dell infrastruttura di rete, attraverso interfacce aperte e standard, consenta di incrementarne la flessibilità e accelerare l introduzione di nuovi servizi. SDN ed NFV rappresentano due approcci complementari, e per molti versi interdipendenti, destinati a trarre beneficio da una loro integrazione nell evoluzione della rete. Non a caso ormai quando si cita uno di questi due modelli, si assume spesso implicitamente una combinazione delle due tecnologie piuttosto che l uso esclusivo di una delle due soluzioni. Mentre il principale obiettivo di NFV è la realizzazione in modalità virtualizzata delle funzionalità di rete, le tecnologie SDN si candidano a giocare un ruolo fondamentale nel fornire all Operatore la flessibilità nel controllo e nella programmazione flessibile della connettivi- Figura A - Architettura SDN (Fonte: ONF, Open ing Foundation) APPLICATION LAYER Business Applications CONTROL LAYER s API API s API INFRASTRUCTURE LAYER

10 57 Edge POP VNF4 VNF4 VNF4 DC Rete Geografica VNF1 VNF2 VNF3 VNF4 Figura B - function chaining tà nella rete sottostante, per combinarle in un architettura di servizio. Infatti, il dispiegamento delle soluzioni NFV richiede di essere supportato da meccanismi potenti ed efficienti per la gestione dinamica della connettività, sia sul piano fisico che virtuale, per collegare tra di loro le funzionalità di rete virtualizzate (VNF: Virtual Function). Questo è il proprio il ruolo a cui la tecnologia SDN si presta naturalmente. Il controllo flessibile e dinamico della connettività e dell inoltro del traffico attraverso la rete può sfruttare la programmabilità introdotta dall architettura, che consente di supportare in modo efficiente e generalizzato i requisiti di policy routing, ovvero la possibilità di controllare il percorso dei flussi di traffico, introducendo le necessarie eccezioni alla logica di default dello shortest path routing. Per queste ragioni, una delle applicazioni di SDN che, ad oggi, rivestono particolare importanza è rappresentata dal service function chaining 1, ovvero dell inserimento sul percorso di forwarding del traffico di un numero di NF ( Function) destinate a svolgere funzioni di servizio (es. firewall, DPI, ecc.). In questo senso SDN rappresenta un ideale complemento ad NFV per definire la connettività tra le funzioni di rete al fine di realizzare il collegamento tra le Function richiesto dall architettura del servizio. Le funzionalità (Figura B) posso essere realizzate da apparati fisici dedicati (NFx) o implementate in forma virtualizzata (VNFx), e possono essere ospitate su server presenti nel POP dell edge di servizio o in data centre di rete. La possibilità di programmare in modo flessibile il percorso dei flussi di traffico attraverso le NF, ovvero di instaurare quello che nell architettura NFV viene definito come network function forwarding graph (NF-FG) è quindi un elemento chiave della soluzione e la tecnologia SDN il modo per realizzarlo, con la possibilità di riconfigurare in modo dinamico e flessibile la connettività se ad esempio nel grafo del servizio deve essere inserita una nuova funzione o se una VNF migra in una diversa locazione di rete. Su questi principi architetturali di integrazione tra SDN ed NFV si registra ormai una convergenza molto ampia dell industria. La flessibilità del modello SDN sembra offrire l approccio adatto alle esigenze di controllo della connettività di rete. Un aspetto su cui invece assistiamo ancora alla proposta di soluzioni tecniche in parte diversificate è relativo all implementazione del forwarding graph nel data plane. Le principali alternative al riguardo infatti consistono nell uso: a) di OpenFlow per programmare le tabelle di forwarding dei dispositivi di rete; b) di meccanismi di tunneling utilizzati tipicamente per creare overlay di servizio sull infrastruttura di rete; c) di nuovi meccanismi di incapsulamento dei pacchetti, quali la tecnica dei NSH ( Header), proposta di recente in ambito IETF (Internet Engineering Task Force). Ognuna delle alternative ha naturalmente punti di forza e limiti, siano essi la scalabilità o la mancanza di una standardizzazione, ed è auspicabile che con il maturare delle proposte si converga verso soluzioni interoperabili vinicio.vercellone@telecomitalia.it 1 La nozione iniziale di Function Chaining è stata generalizzata dal concetto di Function Composition, laddove quest ultimo tiene conto della possibilità di combinare le funzioni anche in topologie ( Function Graph ) più complesse di una semplice concatenazione.

11 58 JolNet JoLNet è una sperimentazione geografica di rete che Telecom Italia ha lanciato per verificare i vantaggi e le problematiche poste dalle future reti basate sui paradigmi SDN/NFV. Allo stesso tempo JoLNet costituisce un testbed aperto alle maggiori università italiane per stimolare la nascita di nuove idee, di nuove soluzioni e di nuove applicazioni, secondo il nuovo modello di collaborazione tra Telecom Italia ed il mondo accademico inaugurato con il progetto "JoL", Joint Open Lab, partito a metà del 2012 e che ha portato, ad oggi, alla realizzazione di 8 nuovi laboratori di innovazione collocati all interno di un gruppo selezionato di atenei italiani (Politecnico di Torino, Politecnico di Milano, Scuola Superiore Sant'Anna di Pisa, Università di Catania e Università di Trento). La rete (FiguraA) è costituita da 12 switch che integrano il protocollo Openflow: 6 di questi costituiscono il backbone e sono collegati tra loro a maglia completa; 6 switch estendono la rete SDN all interno delle sedi JoL. Accanto agli switch sono impiegati 6 server, su cui sono supportate, su macchine virtuali secondo l approccio NFV, le funzionalità che prescindono dal semplice forwarding dei pacchetti: Piano di Controllo, DNS, AAA, Virtual router, L insieme costituito dalla piattaforma di switching programmabile e dalla piattaforma di calcolo è la realizzazione che oggi più si avvicina a quelli che possiamo immaginare come nodi di rete del futuro, che avranno nella flessibilità e nella completa programmabilità gli elementi determinanti per una sensibile riduzione dei costi operativi e per una più veloce introduzione dei servizi. La rete fisica è suddivisa in partizioni logiche, in modo da rendere tra loro indipendenti le attività sperimentali condotte dagli atenei: queste sono realizzate utilizzando l applicativo Flowvisor che si interpone tra gli switch Openflow ed il controller; sulla base di opportune regole (ad esempio su base identificativo di VLAN) Flowvisor smista i pacchetti di controllo provenienti dagli switch verso il Controller di competenza, eventualmente dedicato alla specifica sperimentazione. Ogni Controller può modificare in questo modo l instradamento dei soli pacchetti relativi ad una data partizione: questo permette sia di utilizzare contemporaneamente più Controller diversi, sia di sperimen- Figura A Customer Nodo AAA Control Layer User Profile Application Management & Configuration Customer Controller Application Customer Nodo Application Rete IP DataCentre Application Nodo Nodo OperStack OF Controller OF Controller OperStack Nodo Appliance Appliance FlowVisor OperFlow Switch FlowVisor OperFlow Switch Appliance Appliance FlowVisor OperFlow Switch FlowVisor OperFlow Switch Customer Customer