Bart Salaets, Systems Engineering Director di F5 Networks, evidenzia i vantaggi della la virtualizzazione delle funzioni di rete e i passaggi per gestire la Gi-LAN. Dopo molti anni di discussione e prove, la virtualizzazione delle funzioni di rete (NFV) si è ora spostata dal piano concettuale alla realizzazione pratica. Alcuni service provider hanno già iniziato ad adottare le piattaforme infrastrutturali NFV e altri hanno già all’attivo delle implementazioni NFV-enabled. Virtualizzare l’evolved packet core (EPC) e la Gi-LAN oggi è uno dei temi che attrae maggiormente il settore mobile.
Prima di distribuire una Gi-LAN virtuale è necessario compiere delle scelte fondamentali. La prima riguarda il consolidamento: “Dobbiamo consolidare diverse funzioni Gi-LAN in una singola funzione di rete virtuale (VNF) o dobbiamo scomporre completamente l’architettura Gi-LAN in molte VNF separate?” La seconda riguarda la scalabilità: “Come si può scalare efficacemente questa architettura in orizzontale, dato che una singola macchina virtuale può non offrire una capacità sufficiente per gestire il carico di lavoro Gi-LAN?”
Negli anni, per continuare a garantire la sicurezza e i vantaggi economici, gli operatori mobile hanno adottato molte tecnologie sulle proprie Gi-LAN: l’ottimizzazione del TCP, l’ottimizzazione video, l’arricchimento dell’header, l’ispezione approfondita dei pacchetti, il Gi-firewalling e il carrier-grade NAT (CGNAT). Mentre storicamente molte di queste funzioni erano distribuite su piattaforme diverse, spesso offerte da vendor differenti, negli ultimi anni gli operatori mobile si stanno impegnando sempre più a consolidare e semplificare la architettura Gi-LAN.
Consolidare o segmentare? Attraverso il consolidamento gli operatori di telefonia mobile sono stati in grado di ridurre significativamente il TCO. Durante la migrazione della Gi_LAN verso una piattaforma NFV – che si basa su un hardware comune “off-the-shelf” – si può però essere tentati di segmentare l’architettura in diverse VNF separate, ciascuna dedicata a una singola funzione. Questa architettura scomposta offre sicuramente dei vantaggi se le diverse funzioni Gi-LAN sono applicabili ciascuna a un gruppo specifico di flussi.
Basandosi sulle policy aziendali attraverso l’interazione con la Policy and Charging Rules Function (PCRF), un motore di classificazione del servizio intelligente all’ingresso della Gi-LAN è in grado di determinare quali flussi devono essere indirizzarti e/o quali servizi correlati a funzioni specifiche che sono distribuite come VNF separate. A questo punto quelle VNF dovranno solo processare il traffico sul quale devono agire, e il tutto si tradurrà in una distribuzione molto efficiente del traffico attraverso tutti le VNF.
Tuttavia, se le funzioni Gi-LAN devono essere applicate a quasi tutto il traffico, la scomposizione delle funzioni non porterà alcun vantaggio. Prendete come esempio l’ottimizzazione del TCP e i firewall Gi; quasi tutto il traffico Gi-LAN deve essere elaborato da queste due funzioni, quindi averle consolidate in un’unica VNF consente di guadagnare un’efficienza simile al deployment fisico. Infatti, non vi è alcuna necessità di un intelligent service classifier per effettuare una selezione delle VNF e un hair-pinning dentro e fuori dal livello SDN per spostare il traffico da un VNF all’altro. Inoltre, aggiungere una funzione di firewall in cima a una funzione di ottimizzazione TCP aggiunge veramente poco in termini di overhead CPU; per questo il valore del consolidamento si applica ancora in un ambiente NFV.
Scalabilità e capacità delle macchine virtuali La seconda sfida è rappresentata da come trattare i flussi di lavoro più grandi di quello che una singola VNF è in grado di gestire. Alcuni vendor scelgono di consentire a una VNF di comporsi di molte macchine virtuali (VM). La maggior parte delle funzioni della Gi-LAN sono operazioni stateful, il che significa che il traffico in entrata e uscita degli stessi flussi deve essere elaborato sulla stessa macchina virtuale. Di conseguenza, se il traffico di uscita arriva su una VM diversa da quella che ha elaborato il traffico in ingresso, è necessaria una comunicazione inter-VM per riportare il traffico verso la stessa macchina virtuale. Tutto questo implica una riduzione delle prestazioni.
F5 ha scelto di seguire l’approccio secondo il quale una VNF viene sempre distribuita come una singola macchina virtuale e la scalabilità dell’architettura verso più VM diventa un fattore di design esterno, affrontabile adottando diverse tecniche scale-out, che vanno da quelle molto semplici a quelle avanzate. Un’architettura scale-out molto semplice è quella basata sull’ hashing del traffico IP-based attraverso le diverse macchine virtuali con una strategia di routing Equal-cost multi-path (ECMP). Una tecnica che, purtroppo, presenta alcuni inconvenienti e non è praticabile nella maggior parte dei casi d’uso sulle Gi-LAN. Un approccio SDN-based per controllare la distribuzione del traffico può evitare alcune delle limitazioni del ECMP ma le capacità rimarrebbero comunque limitate e molto dipendenti dal player SDN che si è scelto.
L’approccio più flessibile e avanzato per scalare qualsiasi funzione Gi-LAN, totalmente indipendente dalla rete sottostante e/o SDN, è sicuramente offerto da un sistema di bilanciamento del carico software-based (che è anche distribuito come VM). Tale sistema “stateless” permette di scalare praticamente all’infinito, dato che più macchine virtuali per il bilanciamento del carico stateless possono essere aggiunte senza perdere consistenza rispetto a come il traffico è distribuito su tutte le VM che forniscono le funzioni Gi-LAN.
Alla luce di queste considerazioni ritengo che gli operatori di telefonia mobile debbano riflettere attentamente sugli aspetti legati al consolidamento e alla scalabilità durante la migrazione della loro architettura Gi-LAN da fisico a virtuale.
