Approfondimenti

invalid link: /content/tiportal/it/notiziariotecnico/archivio/2014-2/capitolo-05/approfondimenti-01.htmlIl SDN e le sue sinergie con la Network Function Virtualization

invalid link: /content/tiportal/it/notiziariotecnico/archivio/2014-2/capitolo-05/approfondimenti-02.htmlJolNet

invalid link: /content/tiportal/it/notiziariotecnico/archivio/2014-2/capitolo-05/approfondimenti-03.htmlEvidenze che emergono dai tavoli internazionali

 


SDN e NFV: quali sinergie?

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 (Network 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.

 

1 - La 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 (Virtual Network 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).

 

Figura 1 - Modello di riferimento per NFV

 

Le funzionalità di una VNF quindi vengono tipicamente realizzate attraverso moduli software in esecuzione su una o più VM, che possono svolgere compiti diversi (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 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 hardware 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.
 

2 - Le iniziative di standardizzazione ed il 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 (Network 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 Network 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.

 

Figura 2 - Architettura di riferimento per NFV

 

3 - Le 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 2.

 

3.2 - 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.
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 Service) 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 2,  uno degli elementi principali del dominio di Management and Orchestration, ricoprendo il ruolo del VIM (Virtualised Infrastructure Manager).

 

Figura 3 - Moduli componenti di OpenStack

 

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 2. Essi complessivamente indirizzano, tra gli altri, i seguenti aspetti:

  • Services Instantiation: automatizzazione dell’intero ciclo di vita delle VNF (deployment and post deployment) e procedure automatiche per assicurare high availability e fail-over;
  • Service 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 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;
  • Service 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 pay-as-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) Network 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 bare-metal 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.

 

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 Network, 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 Network 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 Network 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, Service 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 (cfr. 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 (Service 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.

 

Figura 4 - Integrazione OSS con l’architettura 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, dovranno avere una governance centralizzata.
Per l’Assurance, si evidenziano alcuni processi ritenuti rilevanti nel contesto NFV: il Service 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 Service 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.

 

6 - La Roadmap verso NFV

Ogni Network Function, nello stato attuale, può essere collocata all’interno di una specifica fase rispetto al percorso di migrazione verso NFV, a seconda del modo in cui essa è realizzata e dispiegata nella rete dell’operatore.
La Figura 5 sintetizza i diversi step nel percorso verso la sua trasformazione da appliance fisica (“Bare Metal”) a workload virtuale:

  • Step 0: Funzione di rete tradizionale, implementata su HW e SW proprietario. Attualmente, la maggior parte delle funzioni di rete si trovano in questo step: si pensi ad esempio a tutti gli apparati di rete core fisso/mobile, all’IMS, PCRF, le sonde DPI etc;
  • Step 1: funzione di rete implementata su server COTS. In questo step si trovano alcune piattaforme di funzioni realizzate mediante un SW dispiegato su HW “standard” COTS: i server DNS, diversi Application Server che ruotano intorno alla fonia fissa/mobile, il Virtual-PBX. Le funzioni di rete di questo tipo possono essere più facilmente virtualizzate;
  • Step 2:  funzioni di rete virtualizzate singolarmente su server COTS. Sono quelle funzioni già migrate su una piattaforma di virtualizzazione e realizzate mediante un insieme di Virtual Machine instanziate su server COTS dedicati e tipicamente forniti dallo stesso Vendor;
  • Step 3: in questo stato, le funzioni di rete sono virtualizzate e sono orchestrate insieme ad altre funzioni virtualizzate, per ottimizzare le risorse fisiche a loro disposizione, cioè i server COTS dispiegati in rete non sono dedicati alla singola funzione. In questa fase, l’orchestrazione si limita all’on-boarding automatico delle VNF e a gestire la connettività fra loro e con il resto della rete. In questo ambito l’apporto fornito dalla tecnologia Software Defined Networking risulta determinante per garantire l’adeguata dinamicità dei grafi di servizio (cfr. Box Il SDN e le sue sinergie con la Network Function Virtualization);
  • Step 4: la funzione di rete è non solo virtualizzata, ma pienamente gestita dall’Orchestratore, che si occupa anche del ciclo di vita e fornisce tutti gli automatismi e gli strumenti necessari a gestire scalabilità e fail delle VNF.

Telecom Italia ha avviato diverse attività interne volte a verificare lo stato di maturità delle soluzioni disponibili sul mercato e la possibilità di virtualizzazione di alcune piattaforme di rete.
Inoltre, nell’ambito di “Joint Open Lab”, l’iniziativa di collaborazione con il mondo accademico partita a metà del 2012, sta realizzando un testbed geografico SDN/NFV. Tale testbed (cfr. Box JolNet) collegherà i nuovi laboratori di innovazione congiunti, collocati all’interno degli atenei, tramite una infrastruttura di rete programmabile SDN e fornirà nel contempo anche risorse hardware e software distribuite in rete, utilizzabili per la sperimentazione di servizi evoluti in ambito NFV.

 

Figura 5 - Fasi di migrazione verso NFV e enabler tecnologici

 

Conclusioni

Grazie all’evoluzione delle capacità dei sistemi COTS, sempre più potenti e general purpose, si è potuto assistere ad una graduale e pervasiva trasformazione delle funzioni basate su elettronica ad-hoc verso realizzazioni puramente basate su software: ad esempio i codec software ora presenti sui nostri cellulari per il trattamento della voce e del video realizzano funzionalità un tempo possibili solo con hardware dedicato.
Lo stesso trend tecnologico è anche uno dei principali enabler della virtualizzazione in generale e, in particolare, della virtualizzazione delle funzioni di rete, dove la possibilità di rendere il software indipendente dal hardware diventa elemento dirompente per tutti gli attori del settore: i costruttori di apparati di telecomunicazione che sono ora chiamati ad allineare i loro prodotti agli scenari NFV, i costruttori di sistemi COTS attirati dall’opportunità di entrare nel mercato delle telecomunicazioni, se saranno in grado di soddisfare i nuovi requisiti “carrier grade”, i costruttori di software, in piena sinergia con le iniziative opensource, che potranno accrescere il proprio ruolo in ambito TLC con nuovi elementi mutuati da soluzioni tipicamente IT quali i sistemi di orchestrazione ed i controllori di infrastruttura cloud.
Le caratteristiche di dinamicità e scalabilità delle soluzioni virtualizzate NFV, possono poi abbassare significativamente la soglia di ingresso  al mercato di fornitori di servizi innovativi cui è data l’opportunità di gestire le offerte con cicli di vita molto rapidi, investimenti contenuti e grande scalabilità.
I benefici legati alla virtualizzazione delle funzioni di rete sono molteplici e riguardano la flessibilità nella creazione di nuovi servizi e la riduzione dei costi di esercizio. Questi sono resi possibili grazie alla sostanziale semplificazione dell’architettura hardware, all’automazione dei processi, al consolidamento dei workload su risorse condivise, all’ottimizzazione del loro utilizzo, anche in termini di risparmio energetico e, non ultima, all’opportunità di incrementare le risorse disponibili on demand.
Un'altra importante tecnologia, complementare a NFV, è SDN. Questa tecnologia, che si rivolge ad un ambito differente, ma con un analogo intento di semplificazione, è indirizzata ai dispositivi di rete e promuove  il disaccoppiamento della funzione di controllo, delegata ad uno strato superiore, da quella del puro forwarding dei flussi di traffico, che diventa quindi “programmabile”.
Sull’efficace integrazione di queste due nuove tecnologie, l’una orientata alle funzioni di rete e al renderle disponibili “on demand” e l’altra orientata al controllo del traffico per includere e far raggiungere queste funzioni attraverso i percorsi “fisici” di rete, si giocherà buona parte del loro successo e della effettiva creazione di un ecosistema NFV.
Anche se gli aspetti tecnici da risolvere sono ancora molti e la cornice temporale di una sua adozione su larga scala non è ancora definita, gli operatori di rete sono comunque propensi a considerare questa evoluzione tecnologica inevitabile, se non anche necessaria, e intendono studiarne tutti gli aspetti al fine di poter operare di volta in volta scelte che consentano di trarne i benefici funzionali ed economici limitando i rischi di questo cambio di paradigma su una rete oggi solidamente basata su competenze e tecnologie in evoluzione ma in un contesto di regole e processi ampiamente collaudati.

 

Bibliografia

  1. Antonio Manzalini, Vinicio Vercellone, Mario Ullio “Software defined networking: sfide e opportunità per le reti del futuro”, – Notiziario Tecnico Telecom Italia Numero 1 – 2013
  2. Giovanni Lofrumento “Dalle Centrali Telefoniche alle Centrali Computazionali: verso il Cloud Computing”, Notiziario Tecnico Telecom Italia Numero 2 – 2010
  3. Guido Montalbano, Cataldo Tiano, Fabio Valant “Cloud Computing: le soluzioni dei Telecom Italia” – Notiziario Tecnico Telecom Italia Numero 1 – 2011
  4. ETSI GS NFV 002 v.1.1.1 (2013-10) – “Network Functions Virtualisation (NFV); Architectural Framework
  5. OpenStack Documentation: http://docs.openstack.org/
  6. ETSI NFV Management and Orchestration - An Overview - http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdf
  7. http://www.donbot.com/Futurebot/NewTech/NT01360MoravecsGraphFirstModification.html
  8. Managing the Virtualized Network: How SDN & NFV Will Change OSS, http://www.heavyreading.com/details.asp?sku_id=3082&skuitem_itemid=1515
  9. Ivano Guardini, Elena Demaria, Roberto Minerva, Antonio Manzalini e altri “Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges & Call for Action”, http://portal.etsi.org/nfv/nfv_white_paper.pdf
  10. ETSI Network Functions Virtualisation, http://www.etsi.org/technologies-clusters/technologies/nfv
  11. Elena Demaria, Andrea Pinnola : “Network Functions Virtualisation (NFV): Network Operator Perspectives on Industry Progress”,
    http://portal.etsi.org/nfv/nfv_white_paper2.pdf
  12. ETSI, “NFV Terminology for Main Concepts in NFV” Oct 2013,
    http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf
  13. ETSI, “NFV Use Cases”,  invalid link: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV 001v010101p.pdfhttp://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV 001v010101p.pdf
  14. ETSI, “NFV Virtualization Requirements”, Oct 2013, 17 pp.,
    invalid link: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV 004v010101p.pdfhttp://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV 004v010101p.pdf
  15. M. Cohn, “NFV, An Insider’s Perspective: Part 1: Goals, History, and Promise” Sep 2013,
    invalid link: http://www.sdncentral.com/education/nfv-insidersperspective- part-1-goals-history-promise/2013/09/http://www.sdncentral.com/education/nfv-insidersperspective- part-1-goals-history-promise/2013/09/
  16. M. Cohn, “NFV Insider’s Perspective, Part 2: There’s a Network in NFV – The Business Case for SDN” Sep 2013, http://www.sdncentral.com/education/nfv-insiders-perspective-part-2-theres-network-nfv-business-case-sdn/2013/09/
  17. M. Cohn, “NFV Group Flocks to Proof-of-Concept Demos” Aug 2013, http://www.sdncentral.com/technology/nfv-group-flocks-to-proof-ofconcept-models/2013/08/
  18. W. Xu, et al., “Data Models for NFV” IETF Draft, Sep 2013, http://tools.ietf.org/html/draft-xjz-nfv-model-datamodel-00
  19. CloudNFV, http://www.cloudnfv.com/page1.html
  20. Intel, “Open simplified Networking Based on SDN and NFV” 2013, 7 pp., http://www.intel.com/content/dam/www/public/us/en/documents/whitepapers/sdn-part-1-secured.pdf
  21. J. DiGiglio, and D. Ricci, “High Performance, Open Standard Virtualization with NFV and SDNhttp://www.windriver.com/whitepapers/ovp/ovp_whitepaper.pdf
  22. Frank Ohlhorst “OpenStack: An Overview”, http://www.networkcomputing.com/cloud-infrastructure/openstack-an-overview/d/d-id/1233990?
 

comments powered by Disqus