A cura di Frank Yue, Technical Marketing Manager for the Service Provider vertical at F5 Networks
Siamo tutti d’accordo sul fatto che la Network Functions Virtualization (NFV) ha fatto significativi passi avanti negli ultimi due anni. Ci sono decine di dimostrazioni di operatori che hanno collaborato in community o consorzi con vendor e alcuni service provider hanno annunciato la disponibilità di architetture NFV nella propria offerta.
Occorre però fare un passo indietro e guardare alcune delle realtà associate al modello architetturale NFV. Esistono storie di successo, ma ci sono ancora molte sfide e ostacoli da affrontare per la diffusione di una soluzione NFV-based.
Quali sono le 4 principali sfide perché l’NFV diventi un’architettura standard?
• Il primo problema è che oggi non ci sono standard per la comunicazione fra componenti NFV. Abbiamo interfacce come Ve-Vnfm, Nf-Vi, or Vn-Nf, ma non hanno una definizione al di là del nome. Molte community stanno lavorando per creare modelli di comunicazione per le interfacce elencate, ma ci vorrà del tempo. Nel frattempo, abbiamo bisogno che la Network Functions Virtualization funzioni.
• La seconda sfida è rappresentata dal fatto che la NFV è un ambiente multivendor per natura. Occorre mettere a disposizione differenti componenti, come NFVI, VNF e MANO, da diversi vendor e renderli interconnessi e aperti. Nel frattempo, abbiamo bisogno di standard aperti, che non sono necessariamente open source, ma aperti a chiunque nell’architettura multivendor voglia vederli, potendo interagire con le diverse componenti.
• La terza sfida è usare un singolo sistema di orchestrazione per fare da ponte fra le soluzioni hardware esistenti e quelle virtuali. Per ragioni di prestazioni, legacy e di funzionalità, il prossimo futuro sarà rappresentato da un network ibrido realizzato sia con hardware proprietario che mediante servizi virtualizzati. I sistemi di gestione e orchestrazione dovrebbero avere la capacità di interagire con le soluzioni fisiche proprietarie così come con le tecnologie virtualizzate. Se la funzione è la stessa, non c’è motivo per cui un sistema di gestione e orchestrazione tratti i due sistemi in modo differente.
• La quarta sfida è rappresentata dal fatto che l’orchestrazione che offre l’automazione richiesta per l’agilità e l’elasticità ha bisogno di analisi e previsioni che combinino le diverse tecnologie e i diversi vendor. Questi sistemi sono in fase di sviluppo, ma a oggi non esistono. Ci vorrà tempo perché i vendor, i service provider e le aziende lavorino insieme per svilupparli. È fondamentale che il sistema “carrier class” sia testato, affidabile e dalle capacità comprovate, e supporti le richieste di un tipico service provider avendo al tempo stesso la capacità di gestire più vendor, le più disparate tecnologie, le specifiche policy di un cliente e faccia tutto questo con una visione di insieme del network come ecosistema.
Queste sfide vanno analizzate e affrontate. La Network Functions Virtualization può portare dei significativi vantaggi in termini di costi, efficienza e agilità di business. L’industria dei service provider troverà il modo di risolvere questi problemi e rendere la NFV un elemento di successo. Speriamo accada presto.
