La Virtualizzazione di Rete: lo standard NFV

La NFV (Network Functions Virtualization) introduce un cambio di paradigma nel modo in cui vengono realizzate le reti di telecomunicazioni, scindendo lo stretto legame tra hardware e software presente negli apparati proprietari odierni e consentendo lo sviluppo di funzionalità e di servizi di rete come applicazioni software, in modo flessibile ed agile.L’Industry Specification Group NFV di ETSI sta guidando la standardizzazione del modello NFV riscuotendo grande attenzione da parte dell’Industria; altri enti e forum hanno quindi avviato attività sul tema NFV ed il progetto OPNFV ha rilasciato la prima release della Piattaforma NFV in Open Source.

 

1 - Cosa è NFV

La NFV (Network Functions Virtualization) introduce un sostanziale cambio di paradigma nel modo in cui vengono realizzate le reti di telecomunicazioni, spezzando il legame tra hardware e software presente negli apparati odierni [1]. Con NFV le funzionalità di rete, sia fissa che mobile, diventano infatti applicazioni software, denominate VNF (Virtual Network Function), che l’operatore può istanziare su server COTS (Commodity Off-The-Shelf), quali ad esempio i classici blade system HP, IBM o di altri fornitori, sfruttando le tecnologie di virtualizzazione (Figura 1). 

 

Figura 1 - Modello di riferimento per NFV

Ciò viene realizzato tecnicamente tramite l’utilizzo su ogni server di un livello software di astrazione, denominato strato di virtualizzazione o hypervisor, che permette di creare più macchine virtuali, le cosiddette VM (Virtual Machine), sulla stessa macchina fisica, in grado di eseguire applicazioni differenti nate per diversi sistemi operativi.
Le funzionalità di una VNF vengono realizzate attraverso moduli software in esecuzione su una o più VM, possono svolgere compiti diversi (e.g. load-balancing, processing della segnalazione, routing del traffico dati, etc.) ed 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 basso ritardo, scalabilità, ridondanza geografica e gestibilità tipici delle reti di telecomunicazioni.
Rendere il software indipendente dall’hardware sottostante, le cui specificità vengono mascherate dallo strato hypervisor, consente di:

  • ottimizzare l’uso delle risorse, quali CPU, memoria, storage e network, attivando sullo stesso server fisico più VM che implementano diverse tipologie di servizio, in modo da sfruttare appieno la capacità disponibile e ridurre il consumo energetico (consolidamento hardware);
  • ampliare o ridurre in modo dinamico la capacità allocata in base al carico effettivo (elasticità);
  • garantire alta affidabilità, in quanto a fronte di un malfunzionamento hardware le VM possono essere facilmente migrate da un server all’altro;
  • riconfigurare la topologia della rete quasi in tempo reale per ottimizzarne le prestazioni e/o estenderne la penetrazione;
  • ridurre il TCO (Total Cost of Ownership) e migliorare il Time-to-Market, sfruttando la maggiore agilità e flessibilità offerta da NFV nel dispiegamento dei servizi.
 

2 - La standardizzazione ETSI NFV

A partire da luglio 2012 un gruppo di operatori, tra cui Telecom Italia, ha avviato la discussione sulle potenzialità di applicazione delle tecnologie cloud alla rete, coniando il termine NFV, ed ha riconosciuto l’esigenza di guidare l’intera comunità industriale per portarne avanti l’introduzione all’interno delle proprie reti. Ciò ha dato origine, nel novembre del 2012, alla pubblicazione di un White Paper [2] che spiegava le ragioni di tale necessità ed auspicava la creazione di un gruppo di standardizzazione dove portare avanti i lavori di specifica necessari ad avere soluzioni di virtualizzazione interoperanti e condivise.
Nel gennaio del 2013 è stato quindi creato un nuovo ISG (Industry Specification Group) all’interno di ETSI sulla Network Functions Virtualization, con l’obiettivo di definire un’architettura di riferimento e dettare le linee guida per lo sviluppo ed il deployment di nodi di rete virtualizzati [3]. Nel periodo gennaio 2013 – gennaio 2015 si è svolto il lavoro del primo biennio di mandato dell’ISG, denominato Fase 1, che ha portato alla definizione del set di documenti di specifica GS (Group Specification), che oggi costituiscono il riferimento per l’Industria nel percorso verso la virtualizzazione.
L’interesse per queste tematiche da parte dell’intera industria è testimoniato dal numero di aziende che nel corso degli anni sono entrate a far parte del gruppo, dai 52 partecipanti iniziali a gennaio 2013 fino ad arrivare ai 272 partecipanti a maggio 2015.
Dei documenti sviluppati, quattro assumono carattere generale [4-7] in quanto relativi agli Use Case applicativi, i Requisiti generali, la Architettura e la Terminologia, mentre i restanti riguardano i domini architetturali menzionati precedentemente, oltre ad aspetti tecnici più specialistici come performance, sicurezza e affidabilità. A seguire riportiamo un approfondimento sulla Architettura NFV, descrivendone i componenti principali.

2.1 - L’Architettura NFV

L’architettura NFV (Figura 2), si compone di tre domini: il dominio delle funzioni di rete virtualizzate (Virtual Network Functions), il dominio dell’infrastruttura di virtualizzazione (NFV Infrastructure), ed il dominio MANO (MANagement and Orchestration). Ciascun domino comprende a sua volta un insieme di componenti, elementi basilari specifici del dominio [6].
All’interno del dominio delle funzioni di rete virtualizzate [8] troviamo le VNF, cioè le componenti che esplicano le funzioni di rete e permettono la realizzazione dei servizi relativi, ed i rispettivi EM (Element Manager), i quali realizzano le tipiche funzionalità di gestione di telecomunicazione delle VNF.

 

Figura 2 – Architettura di Riferimento ETSI

Il dominio dell’infrastruttura di virtualizzazione [9], denominato NFVI (NFV Infrastructure), costituisce l’ambiente nel quale vengono dispiegate, gestiste ed eseguite le VNF. Esso è costituito da componenti hardware generici il cui compito è sostanzialmente quello di fornire un pool di risorse fisiche di calcolo, di archiviazione e di connettività. Tali risorse vengono poi astratte da uno strato intermedio di virtualizzazione tramite il quale avviene il disaccoppiamento delle VNF dall’hardware sul quale vengono eseguite. Le funzioni esposte dallo strato di virtualizzazione sono quindi le astrazioni del computing, storage e network sottostanti.
Il dominio MANO [10], infine, è l’ambiente di gestione ed orchestrazione delle risorse infrastrutturali e delle funzioni virtualizzate con l’obiettivo finale di consentire la gestione dei servizi di rete sulla infrastruttura virtualizzata. A tal fine presenta tre componenti fondamentali che vengono qui di seguito descritti.
Il VIM (Virtualised Infrastructure Manager) è dedicato alla gestione dell’NFVI, ed è responsabile della allocazione delle risorse necessarie al dispiegamento delle VNF. Inoltre, raccoglie e notifica ai componenti interessati informazioni riguardanti performance e malfunzionamenti della infrastruttura. In base alla disponibilità di diversi sottodomini infrastrutturali, si prevede che un operatore possa decidere di dispiegare più di un VIM all’interno della propria rete.
Il VNFM (VNF Manager) è deputato alla gestione del ciclo di vita di una o più VNF. Esso avvierà le procedure per istanziare, scalare, modificare e terminare le funzioni di rete virtualizzate sotto il suo controllo. La maggior parte delle funzionalità svolte dal VNFM vengono considerate generiche, ovvero applicabili a qualsiasi VNF; si ammette tuttavia la possibilità che alcune VNF ‘complesse’ possano necessitare di procedure specifiche gestibili da VNFM altrettanto specifici (verosimilmente, prodotti dalla stesso fornitore della VNF). Si prevede inoltre che un Operatore possa decidere di dispiegare più di un VNFM in base alla distribuzione delle VNF sull’infrastruttura.
L’ NFVO (NFV Orchestrator) riveste una grande importanza all’interno dell’architettura. A questo componente sono infatti riservati due compiti fondamentali. Il primo consiste nella gestione del ciclo di vita dei NS (Network Service): analogamente al ruolo che riveste il VNFM per le VNF, sarà l’NFVO ad avviare le procedure per istanziare, scalare, modificare e terminare i servizi di rete. Il secondo compito è quello dell’orchestrazione delle risorse disponibili nell’infrastruttura tramite più VIM: di fatto, l’architettura impone che tutte le richieste di allocazione di risorse vengano preventivamente autorizzate dall’NFVO o vi transitino attraverso. Esso agirà in accordo all’effettiva disponibilità di risorse e nel rispetto delle policy imposte dall’operatore. Contrariamente a quanto definito per VIM e VNFM, al momento si ritiene che l’NFVO debba essere unico.

2.2 - Le attività di ETSI NFV Proof of Concept

Il gruppo NFV ha voluto evidenziare la forte attenzione ad incidere sull’evoluzione della rete sin dall’inizio lanciando l’iniziativa delle PoC (Proof of Concept) con logo ‘ETSI NFV’ [11-12]: si tratta di dimostrazioni congiunte tra almeno due vendor ed un Operatore, che mirano a dimostrare la fattibilità e l’interoperabilità delle implementazioni NFV.
Si è così definita una modalità di lavoro che ha incoraggiato i vendor e gli operatori ad identificare e realizzare scenari coerenti con l’architettura NFV che servissero a validare e portare avanti la realizzazione di funzionalità virtualizzate e delle componenti relative.
Un momento importante di esposizione delle PoC è stata la ‘PoC Zone’ presente all’SDN Wolrd Congress di Dusseldorf nell’ottobre del 2014 con 14 PoC dimostrate durante la conferenza [13]; si attende anche una maggiore partecipazione per la PoC Zone prevista nell’evento del 2015. Ad oggi, le PoC con etichetta NFV sono 36 di cui 21 già realizzate e 15 ancora in corso. Si registra come quest’attività abbia consentito di dimostrare in anticipo i concetti della virtualizzazione e di accelerare le realizzazioni da parte dei vendor in modo da poter dimostrare la fattibilità di un’architettura basata su NFV.

2.3 - Lavori in corso: la Fase 2

Data la validità dei risultati conseguiti, si è deciso che il gruppo ETSI NFV avesse le carte in regola per proseguire con il suo mandato al fine di portare a maturazione il lavoro svolto. Nel gennaio del 2015 si è così aperta la Fase 2, con l’obiettivo di produrre specifiche normative che abilitino l’interoperabilità end-to-end di dispositivi e servizi [14]. A tal fine, sono stati istituiti cinque WG (Working Group), ciascuno dei quali è attivo su una tematica differente. In particolare, i team di esperti relativi ad affidabilità (NFV REL) e sicurezza (NFV SEC) hanno proseguito le attività avviate in Fase 1, mentre sono stati definiti tre nuovi gruppi di lavoro riguardanti gli aspetti di gestione dell’ecosistema (NFV EVE), le interfacce e le architetture (NFV IFA), il testing (NFV TST).
Il WG NFV IFA in questo momento sta assorbendo la maggior parte delle energie dei partecipanti. Data l’importanza, ricordiamo che il WG al suo interno è strutturato in quattordici WI (Work Item) articolati come segue:

  • quattro WI riguardano le tecniche di accelerazione hardware impiegabili in ambito NFV e, di fatto, costituiscono un blocco deputato ad ottenere su hardware ‘generico’ prestazioni equivalenti a quelle ottenibili con hardware dedicato, tema molto sentito dai vendor;
  • sei WI sono deputati a specificare le interfacce del dominio MANO, assieme agli elementi informativi che vi transitano; si tratta di attività fondamentali per ottenere la gestibilità della piattaforma ed un ambiente multivendor ed interoperabile;
  • due WI si occupano dei template informativi di Network Service (NS) e VNF, descrittori di alto livello contenenti regole da rispettare per la loro definizione, sia in fase di dispiegamento che, più in generale, durante tutto il ciclo di vita
  • un WI descrive i requisiti funzionali validi per l’intera architettura;
  • un WI, di carattere informativo, riporta le varie opzioni architetturali ammesse dal modello ETSI NFV.

Senza entrare nei dettagli, evidenziamo come i lavori sulle interfacce siano un ambito sensibile sia per gli operatori che per i fornitori: se i primi mirano a rendere obbligatoria la maggior parte delle funzionalità supportate dal modello in modo da avere garantita più libertà possibile nel dispiegamento dei servizi offerti, i secondi spingono per rilassare alcuni requisiti convertendoli in opzionali così da limitare l'impegno derivante dall'implementazione di tali funzionalità. Telecom Italia è attivamente impegnata a supportare soluzioni il più possibile interoperanti e aperte.
Anche per il ciclo di Fase 2, l’ISG NFV ha ottenuto a gennaio 2015 dal Board ETSI 2 anni di tempo per completare i suoi lavori di specifica. Si prevede che tutti i documenti GS relativi al WG IFA entreranno nello stadio di ‘Final Draft’ a gennaio 2016, giungendo alla pubblicazione della prima release a marzo 2016. Nell’ultima riunione plenaria (maggio 2015) è stato deciso di rendere pubblicamente accessibili tutti i documenti in formato Draft di qualunque WG, lanciando un segnale di forte apertura nei confronti del mondo esterno e, al contempo, favorendo e incentivando la ricezione di feedback da parte dell’Industria.
Viste le richieste di collaborazione già pervenute, è lecito aspettarsi che enti, consorzi e forum interessati al lavoro di ETSI si attivino sul tema. E’ quindi utile una panoramica sull’ecosistema degli standard e la relazione con l’Open Source.

 

3 - L’ecosistema degli standard e la relazione con l’Open Source

La visione NFV sta trasformando il modo in cui le reti vengono concepite, realizzate e gestite ma per realizzarsi richiede il supporto dell’intero ecosistema degli standard sino ad abbracciare il mondo dell’Open Source.
La tecnologia NFV è già proposta infatti in applicazioni di nicchia nelle reti correnti ma la sua applicazione su larga scala richiede di andare oltre al confine delle specifiche ISG NFV, pensate per essere indipendenti dal contesto specifico di applicazione della rete, e di declinarle progressivamente sui diversi contesti di rete.
Per le reti mobili, il 3GPP avendo apprezzato la evoluzione prevista ha avviato dallo scorso anno un approfondimento specifico sulla gestione delle reti cosiddette ‘miste’ cioè con componenti sia fisici che virtualizzati; per fare questo è stato definito uno specifico Study Item di cui si riporta un approfondimento [15].
Si è poi avviato un primo dibattito sulla evoluzione delle architetture mobili virtualizzate; la prospettiva derivata è che si accoglierà l’evoluzione prevista nella prossima release 14 che sarà orientata alla quinta generazione (5G) del radiomobile. Il 5G sarà la prima tecnologia radiomobile nativamente virtualizzata facendo leva sulle tecnologie NFV ed SDN [16], secondo il consorzio NGMN di cui Telecom Italia fa parte. Forte attenzione sta inoltre ricevendo il gruppo di MEC (Mobile Edge Computing), anche esso un ISG ETSI [17], lanciato a fine del 2014 con l’idea di arrivare a specificare gli aspetti rilevanti di diffusione in rete [18]; si tratta di un’applicazione dei concetti della virtualizzazione ad applicazioni di rete mobile.
Nell’ambito delle reti fisse, ed in particolare della Multiservice BroadBand Network, dal 2014 il BBF ha avviato i suoi studi sul tema, collegando il tema NFV anche all’impiego delle tecniche SDN [19].
Dal 2014 il TMF (TeleManagement Forum) ha avviato il progetto ZOOM (Zero-touch, Orchestration, Operations and Management) per approfondire gli aspetti di gestione e interoperability della NFV con le reti attuali [20].
NFV ha generato una grande attenzione nell’industria ed ha ottenuto progressivamente un cambio di paradigma nell’industria relativamente a come verranno realizzate le reti del futuro. Uno dei modi che sono stati identificati dalla comunità NFV per facilitare ed accelerare la introduzione ed il dispiegamento di NFV è attraverso la partecipazione a progetti Open Source. L’Open Source consente di governare le realizzazioni di riferimento in un modo ‘agile’ con il potenziale vantaggio di definire un possibile standard ‘de facto’.
L’Open source per NFV è anche attrattivo perché diverse delle comunità che vanno a sviluppare dei componenti di base del progetto sono già esistenti, come ad esempio la comunità OpenStack con il suo componente di gestione della infrastruttura di virtualizzazione (VIM) di tipo general purpose, che fornisce una buona base di partenza.

 

E’ stata quindi lanciata a fine 2014, sotto l’egida della LINUX FOUNDATION e con la partecipazione di 32 aziende tra cui Telecom Italia, la OPNFV (Open Platform for NFV) per accelerare lo sviluppo di una comunità Open Source [21]. La prima release della Piattaforma OPNFV, denominata ‘Arno’ prendendo come motivo guida i nomi dei fiumi, rilasciata a giugno 2015, prevede un kit articolato di componenti quali OpenStack, KVM, OpenDayLight ed altri [23].

 

Conclusioni

La virtualizzazione si sta sempre più dimostrando l'innovazione che cambierà le reti di telecomunicazioni nei prossimi anni permettendo agli operatori di migliorare i processi di sviluppo e dispiegamento attraverso i quali offrono i loro servizi. La tecnologia di base aveva visto la sua nascita ed adozione in ambito IT e la sua applicazione alle tradizionali reti di telecomunicazione non era stata prevista. Grazie all'iniziativa di un gruppo di operatori, tra cui Telecom Italia, si è potuto intercettare la nascente opportunità consentendo di definire un’architettura di riferimento che fosse condivisa da costruttori ed operatori e di lanciare un'attività di standardizzazione che consentisse di ottenere prodotti interoperanti ed un ambiente multi-vendor che si va progressivamente consolidando [24].
Il successo dell'iniziativa non è solo dimostrato dall'ampio numero di aziende coinvolte in ETSI NFV (oggi più di 270) ma anche dalle numerose attività correlate che sono in qualche modo state originate dai lavori del gruppo, in primis l'iniziativa OPNFV per la realizzazione di una piattaforma open source in grado di soddisfare i requisiti propri degli operatori di telecomunicazione.
Occorre comunque proseguire nelle attività internazionali affinché le promesse della virtualizzazione siano pienamente mantenute e si possa realizzare un ambiente aperto ed interoperabile nel quale sperimentare più agevolmente nuovi servizi. La sfida per gli operatori e per Telecom Italia sarà quella dell’adozione non solo di una nuova tecnologia e di nuove soluzioni ma anche di un adattamento degli skill e dei propri processi di ingegnerizzazione ed esercizio in chiave moderna e più legata ai modelli delle web companies derivati dal mondo del Cloud. In questo, la partecipazione a progetti Open Source come OPNFV ed OpenStack potrà consentire di derivare utili conoscenze e modalità di sviluppo e dispiegamento del software di rete virtualizzato.

 

Bibliografia

  1. L.Grossi, E.Maffione, G.Marasso, S.Ruffino, “SDN e NFV: Quali Sinergie?”, Notiziario Tecnico Telecom Italia Numero 2 – 2014,
    http://www.telecomitalia.com/tit/it/notiziariotecnico/archivio/2014-2/capitolo-05.html
  2. I.Guardini, E.Demaria, R.Minerva, A.Manzalini e altri “Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges & Call for Action”, http://portal.etsi.org/nfv/nfv_white_paper.pdf
  3. ETSI Network Functions Virtualisation, http://www.etsi.org/technologies-clusters/technologies/nfv
  4. ETSI, “NFV Use Cases”, Oct 2013 
    http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf
  5. ETSI, “NFV Virtualization Requirements”, Oct 2013,
    http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01
  6. ETSI, “Network Function Virtualisation (NFV); Architectural Framework” , Oct 2013, http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf
  7. 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
  8. ETSI GS NFV-SWA 001 “Network Functions Virtualisation (NFV); Virtual Network Functions Architecture“, http://www.etsi.org/deliver/etsi_gs/NFV-SWA/001_099/001/01.01.01_60/gs_NFV-SWA001v010101p.pdf 
  9. ETSI GS NFV-INF 001, “Network Functions Virtualisation (NFV); Infrastructure Overview“,
    http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/001/01.01.01_60/gs_NFV-INF001v010101p.pdf  
  10. ETSI GS NFV-MAN 001, “Network Function Virtualisation (NFV); Management and Orchestrationhttp://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf
  11. http://nfvwiki.etsi.org/index.php?title=PoC_Framework
  12. Marc Cohn, “NFV Group Flocks to Proof-of-Concept Demos” Aug 2013, https://www.sdxcentral.com/articles/contributed/nfv-group-flocks-to-proof-of-concept-models/2013/08/
  13. ETSI NFV PoC ZONE, Posted by Aurélie Sfez on 24 October 2014 in Blog ETSI NFV, http://www.etsi.org/technologies-clusters/technologies/nfv
  14. Full Steam Ahead for NFV in Phase 2, Posted by Marc Cohn, Ciena Corporation    on 17 March 2015, in Blog ETSI NFV,
    http://www.etsi.org/technologies-clusters/technologies/nfv
  15. S.Bizzarri, “Aspetti di Gestione per le Reti Virtualizzate in 3GPP”, Notiziario Tecnico Telecom Italia Numero 2 - 2015
  16. 5G Initiative Team, “NGMN 5G WHITE PAPER”, https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf
  17. http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing
  18. D.Sabella, A.Vaillant, “Il  Mobile Edge Computing”, Notiziario Tecnico Telecom Italia Numero 2 - 2015
  19. https://www.broadband-forum.org/marketing/download/mktgdocs/MR-316.pdf
  20. M.Banzi, C.Corbi, “Standard per i sistemi di gestione delle reti e servizi digitali”, Notiziario Tecnico Telecom Italia Numero 2 – 2015
  21. https://www.opnfv.org/ e https://wiki.opnfv.org/
  22. The Rise of Open Platform for NFV – Interview with Christopher Price”, Notiziario Tecnico Telecom Italia Numero 2 - 2015
  23. https://www.opnfv.org/arno
  24. E.Demaria, A.Pinnola et alii, “Network Functions Virtualisation (NFV): Network Operator Perspectives on Industry Progress”, 
    https://portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV_White_Paper3.pdf

 

 

ACRONIMI

BRAS - Broadband Remote Access Server
BSS - Business Support System
COTS  - Commercial Off-The-Shelf
CPU  - Central Processing Unit
DNS  - Domain Name System
DPI  - Deep Packet Inspection
EM  - Element Manager
EPC  - Evolved Packet Core
GGSN - Gateway GPRS Support Node
HW  - Hardware
IaaS  - Infrastructure as a Service
IFA - Infrastructure and Architecture
IMS  - IP Multimedia Subsystem
ISG  - Industry Specification Groups
IT  - Information Technology
MANO - Management and Orchestration
MEC - Mobile Edge Computing
MME - Mobility Management Entity
NFV  - Network Functions Virtualization
NFVI - NFV Infrastructure
NFVO - NFV Orchestration
NS - Network Service
OS  - Operating System
OSS  - Operations Support System
PDN GW - Packet Data Network Gateway
PoC  - Proof of Concept
R&D  - Research and Development
SA5 - Systems and Service Aspects WG 5
SDN  - Software Defined Networking
SGSN - Serving GPRS Support Node
SLA  - Service Level Agreement
SW  - Software
TCO  - Total Cost of Ownership
VIM  - Virtual Infrastructure Manager
VM  - Virtual Machine
VNF  - Virtual Network Function
VNFM - VNF Manager
WG  - Working Group
WI  - Work Item
ZOOM  - Zero-touch, Orchestration, Operations and Management

 

comments powered by Disqus