Network Automation SDN/NFV

Network Automation SDN/NFV
 

Network Automation SDN/NFV

La trasformazione digitale che TIM sta intraprendendo richiede di cambiare il modo di fare business e passa attraverso una profonda revisione degli attuali processi e delle soluzioni architetturali e sistemistiche mediante cui vengono erogati i servizi. Intraprendere questa trasformazione, oggi, significa introdurre soluzioni in grado di semplificare ed automatizzare le attività di dispiegamento e gestione delle reti, delle infrastrutture e dei servizi. I principi cardine su cui poggia questa evoluzione, verso la Network Automation, sono semplificazione, standardizzazione, astrazione e modularità.
I benefici attesi sono significativi: incremento dell’efficienza, riduzione della complessità e dei costi operativi, riduzione degli errori e successive rilavorazioni, maggiore flessibilità e reattività della rete nel recepire e soddisfare le esigenze legate all’evoluzione di funzionalità e servizi. Prerogative, queste, che consentiranno sia di ridurre i tempi dalla concezione al lancio di nuovi servizi (il time-to-market), sia di abilitare più diffusamente il self-provisioning delle offerte da parte dei clienti.
L’articolo analizza come siano perseguiti gli obiettivi di automazione nell’ambito della Network Function Virtualization e della Software Defined Network e come si stiano definendo, nel medio termine, architetture fortemente integrate ed automatizzate in tutti i segmenti della rete.

 

Introduzione

Spesso il termine Network Automation viene associato ai concetti “Software Defined” o “as a Service” proprio per sottolineare il ruolo centrale che la programmabilità riveste nel percorso di evoluzione e trasformazione della rete verso l’automazione. Questa programmabilità si traduce in molti casi nella scrittura di file e script (che descrivono in modo formale e strutturato la configurazione di un apparato o servizio) interpretati, composti ed eseguiti in modo guidato ed automatico da appositi programmi che rendono le operazioni facilmente ripetibili, eliminando progressivamente i possibili errori di esecuzione.
Nei domini di trasporto, IP, controllo di rete e servizi, la Network Automation si esplicita in due ambiti principali: la NFV (Network Function Virtualisation), che ha come obiettivo la realizzazione e l’esecuzione di funzioni di rete su generici server informatici, ed il SDN (Software Defined Networking), che si propone di centralizzare il controllo dei servizi di rete erogabili dalle infrastrutture IP. Le due soluzioni sono fortemente complementari e si integreranno nel medio periodo prefigurando un nuovo concetto integrato ed automatico della rete end-to-end.
TIM ha intrapreso un percorso di trasformazione della rete verso la digitalizzazione e l’automazione la cui attuazione comporterà non solo l’adattamento all’utilizzo delle nuove tecnologie ma anche la rivisitazione dei processi al fine di massimizzarne i benefici.

 

Le sfide dell’Automazione nella NFV

Una quota parte considerevole del percorso di trasformazione verso la Network Automation è passata, e sta passando, attraverso l’adozione del paradigma Network Functions Virtualisation, il cui scopo è quello di separare il software che implementa una data funzionalità di rete dall’hardware sui cui viene eseguito. Tale separazione è resa possibile da uno strato di astrazione denominato hypervisor. Una funzione di rete che rispetta il modello NFV viene detta VNF (Virtual Network Function).
A 3 anni dall’avvio di questo percorso, TIM dispone oggi di un’infrastruttura distribuita in corrispondenza dei 4 inner PoP che ospita circa 30 VNF a traffico (e.g., MMS, Rete Intelligente, AAA server, piattaforme VAS e presence, funzionalità SON a supporto dell’automazione della rete di accesso mobile). Oltre a ciò, più di 40 funzioni di rete risultano attualmente “in lavorazione”, ovvero di prossima virtualizzazione.
Al crescere del numero delle VNF, e quindi della dimensione e complessità dell’infrastruttura NFV, la piena automazione dell’infrastruttura virtualizzata e delle funzioni ospitate diventa un obiettivo irrinunciabile per poter garantire adeguati livelli di efficienza e qualità.

L’automazione del ciclo di vita delle VNF

Sebbene specializzata nell’espletare una ben determinata funzionalità di rete, dal punto di vista dell’architettura NFV una VNF costituisce un elemento atomico con il quale è possibile interagire mediante alcune operazioni standard che ne regolano il ciclo di vita (Life Cycle Management-LCM). Tra queste, ad esempio, vi è la creazione di una nuova istanza della VNF, un’operazione complessa che comporta la creazione delle relative risorse virtuali di calcolo, memoria e rete sull’infrastruttura e la loro configurazione a partire dal cosiddetto “descrittore”, contenente le immagini eseguibili ed i file con le caratteristiche specifiche di ciascuna componente. Per quanto complessa, la creazione di una VNF è generalmente ritenuta un’operazione di Base LCM in confronto a funzionalità “avanzate” come la capacità di adattare dinamicamente ed automaticamente la dimensione delle risorse virtuali al carico sostenuto (i.e., scaling) o l’abilità di ripristinare componenti qualora diventino indisponibili, ad esempio a seguito di un guasto (i.e., self-healing). Il Full LCM è dunque ottenibile solo laddove risultino abilitate sia le operazioni di Base LCM che quelle più avanzate.

 
 

Figura 1 - Architettura di riferimento per l'automazione NFV

Il modello di riferimento per l’automazione del LCM delle VNF e l’architettura generale della NFV  sono definiti nell’ambito di un ISG specifico di ETSI [1], avviato a gennaio 2013. La Figura 1 illustra all’interno della linea tratteggiata tale architettura ed evidenzia le tre tipologie di moduli che espletano funzionalità di gestione e orchestrazione, complessivamente identificati come MANO:

  • Uno o più VNFM (VNF Manager) deputati alla gestione automatizzata del ciclo di vita delle VNF dispiegate sull’infrastruttura.
  • Un NFVO (NFV Orchestrator) responsabile della gestione automatizzata del ciclo di vita dei Network Service. Oltre a ciò, l’NFVO orchestra l’utilizzazione delle risorse virtualizzate distribuite su più istanze di VIM autorizzando o proibendo le procedure richieste dai VNFM in base alla disponibilità residua e alle policy imposte dall’operatore.
  • Uno o più VIM (Virtualised Infrastructure Manager) cui viene demandata la gestione delle risorse virtualizzate, di calcolo, memoria e rete, messe a disposizione dall’ NFVI (Infrastruttura NFV), ovvero dalla totalità dei componenti che costituiscono l’ambiente sul quale le VNF vengono eseguite.

L’architettura così definita non è però sufficiente a supportare qualunque VNF. In alcuni casi è necessario disporre di componenti di automazione complementari ed interoperabili con quelle specificate da ETSI, rappresentate in Figura 1 dal blocco  funzionale denominato NFVOPS (NFV Operational Tools), che include ulteriori strumenti di automazione finalizzati all’erogazione di servizi di virtualizzazione alle VNF ed alla realizzazione di altre funzionalità utili a migliorare l’operatività dell’NFVI in senso ampio. Qui di seguito sono riportati due esempi significativi di utilizzo degli NFVOPS come elemento abilitante l’automazione delle VNF:

  • automazione dei servizi di connettività richiesti dalle VM, nel caso in cui questi debbano essere erogati dai nodi di rete che collegano tra di loro i server fisici e non possano essere modellati dal VIM;
  • raccolta di allarmi o notifiche di superamento soglia necessari all’implementazione delle logiche di closed control loop, ovvero l’innesco automatico da parte di VNFM e NFVO di azioni di lifecycle management correttive (e.g., scaling out, self-healing, etc.). Anche se lo standard ETSI sancisce che le informazioni di guasto e/o performance consumabili dalle funzioni di orchestrazione debbano esulare dalla componente applicativa e vengano recuperate direttamente dal VIM, laddove l’operatore disponga già di un proprio sistema di monitoraggio, si pone la tematica dell’integrazione con questi ultimi al fine di evitare interferenze e sovrapposizioni di ruoli.

L’architettura così definita evidenzia come l’automazione necessiti di una serie di sistemi cooperanti ciascuno specializzato a svolgere un ben preciso compito. Occorre, tuttavia, tenere in conto altri requisiti non funzionali ma indispensabili al fine di poter rendere tali sistemi fruibili in una realtà strutturata come quella di un operatore di telecomunicazioni. Tra questi particolarmente rilevante per la NFV è la necessità di garantire un accesso controllato all’infrastruttura, ottenibile tramite il partizionamento logico delle risorse virtualizzate consumabili tramite una o più istanze di VIM. A tal fine, si rende necessario che:

  • VIM e NFVO abilitino modelli di multi-tenancy ovvero consentano di implementare unità organizzative dette tenant – tipicamente corrispondenti a VNF, Network Service o strutture aziendali – e di associare loro una quota massima di risorse consumabili;
  • sussista una corrispondenza tra i tenant definiti a livello di NFVO e quelli a livello di VIM, così da assicurarsi che le quote impostate per i primi vengano effettivamente rispettate.

Maturità delle VNF commerciali

Per ottenere tutti i benefici attesi dal paradigma NFV, è fondamentale che le funzioni di rete siano caratterizzate da un’architettura interna pensata per essere eseguita su ambiente Telco Cloud, ovvero che risultino in possesso delle seguenti proprietà: astrazione dall’hardware sottostante, distribuzione delle informazioni di stato, elasticità e gestione automatizzata del ciclo di vita.
Come evidenziato da TIM con un’indagine condotta nel 2017 su un campione di oltre 300 VNF commerciali afferenti a numerosi domini di rete (e.g., accesso fisso/mobile, core mobile, user plane infrastrutturale, control plane infrastrutturale, VAS, etc.), anche i vendor stanno intraprendendo un percorso di maturazione che dovrebbe portare a questo obiettivo. Stando allo scenario odierno, i principali punti di attenzione risultano essere:

  • l’esigenza, tipicamente manifestata dalle VNF prestazionalmente più critiche (i.e., user plane e accesso), di “forare” lo strato di astrazione introdotto dall’hypervisor con tecniche quali CPU pinning, SR-IOV e NUMA;
  • il ritardo nel supporto della gestione del ciclo di vita, spesso collocato come ultimo potenziamento nelle roadmap di prodotto.

La Figura 2 rappresenta la percentuale di VNF coinvolte nella survey che supportano procedure di lifecycle management; si può osservare come l’adozione diffusa delle funzionalità più avanzate è attesa per la fine del 2018, vale a dire circa 12 mesi dopo rispetto alla disponibilità delle operazioni di gestione del ciclo di vita di base.

 

Figura 2 - Trend relativo alla disponibilità del VNF lifecycle management

Prossimi passi

Sebbene l’orchestrazione svolga il ruolo di motore per la gestione del ciclo di vita delle VNF, l’adempimento di molte operatività gestionali ed il raggiungimento di benefici end-to-end richiedono l’integrazione con strumenti aggiuntivi di automazione da coniugare con l’evoluzione e lo snellimento dei processi sottesi.
Non essendo possibile ricondurre tutti gli use case ad un insieme limitato e ben definito, la sfida consiste nell’individuazione di un compromesso tra la limitazione del numero di modelli di servizio supportati – che comporterebbe l’esclusione delle VNF meno mature e dunque la perdita di parte dei vantaggi economici derivanti dall’NFV – e l’adozione di un approccio esclusivamente “a progetto” – che si tradurrebbe in un peggioramento in termini di agilità e ripetibilità abilitati.
Concentrandosi sul livello di virtualizzazione delle risorse di computing, storage e networking vale la pena infine sottolineare come, parallelamente alle implementazioni proprietarie disponibili sul mercato da circa un decennio, stia affermandosi in veste di standard de facto una comunità open source potenzialmente molto più aperta e flessibile ma soggetta a modalità operative diverse rispetto a quelle cui i Telco sono abituati.
Il trend evolutivo delle VNF evidenziato dall’indagine interna unitamente al piano di attività che TIM si è data autorizzano a considerare il 2018 come l’anno nel quale l’automazione verrà abilitata in modo consistente su NFV.  TIM ha infatti in programma di compiere importanti passi in avanti rispetto al proprio percorso di trasformazione quali l’inserimento in rete dell’orchestratore NFV e la virtualizzazione di importanti funzioni di rete fissa e mobile sufficientemente mature, come ad esempio l’ EPC (Evolved Packet Core), l’IMS mobile / VoLTE e diverse componenti di front end dell’architettura Data Layer, come ad esempio HSS e PCRF.  

 

Network Automation: come l’automazione cambia il modo di gestire le reti IP

Le soluzioni architetturali e sistemistiche mediante cui oggi vengono erogati e gestiti i servizi di connettività sulle infrastrutture di rete IP, pur assicurando già un discreto livello di automatizzazione nell’esecuzione delle varie fasi delle attività di configurazione e manutenzione, sono ancora improntati ad una organizzazione dei processi che presuppone lo svolgimento di molte attività manualmente.
Introdurre strumenti per inseguire e gestire la crescente complessità della rete e dei suoi sistemi non è più sufficiente ad affrontare le nuove sfide della trasformazione digitale; è necessario perseguire una riorganizzazione più profonda del modello architetturale e dei relativi processi.
La strada per affrontare questa trasformazione è tracciata, il mondo del computing e dell’information technology ha già intrapreso con successo questo percorso molti anni fa. L’evoluzione in questo ambito ha portato all’organizzazione dell’architettura secondo principi di astrazione e modularità e all’introduzione di interfacce aperte.
Trasposto nel contesto delle reti di telecomunicazione, il modello da adottare è quello del SDN. Esso prevede di introdurre opportuni livelli di astrazione, che permettano di confinare la complessità ed esportarne una rappresentazione che consenta agli strati più alti della catena di gestione di semplificare notevolmente l’interazione con la rete e governarne in modo efficace l’evoluzione.

 

L’architettura di riferimento del dominio E2E SDN per la network automation dei servizi di connettività IP

La Figura 3 illustra l’architettura di riferimento della piattaforma E2E SDN Controller per l’introduzione della network automation nel dominio dei servizi di connettività e trasporto IP. La piattaforma ha il compito di gestire e controllare le risorse di dominio end-to-end, ossia tutti gli elementi di rete coinvolti nella catena con cui viene erogato il servizio di connettività. Per superare le limitazioni dei tradizionali modelli verticali a “silos”, la piattaforma realizza in modo integrato e sinergico anche le funzioni di raccolta ed elaborazione dei dati di monitoraggio delle risorse del dominio di riferimento.

 

Figura 3 - Architettura di riferimento della piattaforma E2E SDN Controller per l’introduzione della network automation nel dominio dei servizi di connettività e trasporto IP

Per semplicità possiamo riassumere l’organizzazione dell’E2E SDN Controller in termini di tre macro-componenti. Il componente “IP Connectivity Management and Control” (Figura 3) svolge tutte le funzioni di configurazione e controllo degli elementi di rete. Espone un’interfaccia API “intent-based” verso i sistemi OSS di orchestrazione di servizio, mediante la quale riceve richieste ad alto livello, relative alla gestione del ciclo di vita dei servizi di connettività IP offerti a catalogo, che vengono tradotte in modo automatico e consistente in configurazioni. I servizi a catalogo sono specificati tipicamente nel linguaggio di modellizzazione YANG [2].  Il componente si interfaccia quindi in modo attivo con le risorse per modificarne lo stato operativo, realizzando le operazioni di (ri-)configurazione ed interazione con il piano di controllo necessarie. Per il provisioning di servizi che coinvolgono l’utilizzo di risorse di altri domini (ad esempio NFV) il componente si interfaccia anche con i rispettivi orchestratori.
Il componente “Metrics and KPI Collection and Generation” (a destra in Figura 3) svolge le funzioni di raccolta dei dati di monitoraggio delle risorse del dominio, garantendo l’osservabilità continua dello stato operativo degli elementi di rete e di successiva elaborazione per generare le metriche ed i KPI associati ai servizi di connettività gestiti. I dati raccolti ed elaborati vengono poi inviati ai sistemi OSS che ne effettuano la storicizzazione e li utilizzano ai fini di analisi e reportistica.
I due componenti illustrati si scambiano informazioni necessarie a programmare la raccolta dei dati e l’elaborazione delle metriche prestazionali e relative soglie di verifica, in relazione al modello di servizio associato, ovvero a notificare eventuali aggiornamenti sullo stato della rete.
Tra il lato attivo dell’attuazione delle richieste di servizio e quello della raccolta dei dati di monitoraggio, si inserisce la funzione di “Closed-Loop Logic”. Quest’ultima consente di sviluppare ed installare sulla piattaforma E2E SDN Controller delle “app” che codificano in modo programmatico delle logiche di intervento automatico, al verificarsi di determinati eventi in rete (“Network events” in Figura 3). Queste possono consistere ad esempio in azioni correttive o attivazione di funzionalità di misura. Le “app” di Closed-Loop Logic mirano a rimediare in modo autonomo una varia casistica di possibili anomalie, nella prospettiva di evoluzione verso il modello di “Self-driving network”.

 

L’architettura CORD e il dimostratore FutureNet

Proseguendo il percorso verso la digitalizzazione e l’automazione, un passo successivo consiste nel ripensare completamente l’architettura di una centrale di telecomunicazioni o CO (Central Office), reinterpretando ed integrando in ottica evolutiva i principi di NFV ed SDN. L’idea alla base di questa rivoluzione è quella di rendere le centrali sempre più simili a datacenter eliminando, per quanto possibile, la presenza di apparati dedicati a specifiche funzioni.
L’esempio principale di architettura di questo tipo è costituito da CORD (Central Office Re-architected as a Datacenter), un concetto lanciato inizialmente da AT&T e portato avanti dal progetto Open CORD [3] che ha l’obiettivo di realizzarne una Reference Implementation basata su software open source.
Un aspetto che rende particolarmente interessante la proposta CORD è la standardizzazione dell’architettura del CO che scala in accordo con le dimensioni della centrale (numero di clienti attestati) e con le funzioni di rete virtualizzate che devono essere ospitate nella centrale stessa.
L’architettura di riferimento di un CO realizzato secondo il concetto CORD è mostrata in Figura 4.

 

Figura 4 - Architettura di Riferimento CORD

Il cuore di questa architettura è un datacenter composto da una serie di server, sui quali risiedono le funzioni di rete virtualizzate, collegati fra loro da una fabric. La fabric ha una topologia di tipo leaf and spine, realizzata con switch white box, che fornisce connettività in modo non bloccante e garantisce scalabilità e ridondanza. Al datacenter sono quindi collegati gli apparati utilizzati per realizzare la rete di accesso verso i clienti e la rete di trasporto verso altri CO.
Il nodo CORD prevede la connessione di clienti residenziali e business attraverso una rete di accesso fissa o mobile e realizza un’implementazione di riferimento a supporto di tre use case specifici:

  • R-CORD: per i servizi di connettività con rete fissa per la clientela residenziale (GPON, XGSPON, NGPON2 …)
  • E-CORD: supporta i servizi avanzati di connettività (VPN, SD-WAN, …) per la clientela business, in ambito metropolitano e geografico
  • M-CORD: supporta i nuovi servizi mobili 5G in modalità distribuita verso l’edge della rete

La piattaforma software di CORD si basa su una pluralità di progetti open source (vedi Figura 5), tra cui:

  • OpenStack/Docker: forniscono rispettivamente le funzioni di IaaS per creare e gestire macchine virtuali e reti virtuali e una soluzione per istanziare elementi di servizio mediante la tecnologia dei container; nella release 6.0, pianificata per la metà del 2018, è previsto il passaggio a una gestione dei container con kubernetes [4]
  • ONOS: SDN controller che gestisce sia gli switch “white-box” della fabric sia le reti overlay (VTN, Virtual Tenant Network) realizzate su di essa;
  • XOS: Framework di orchestrazione per assemblare e comporre i servizi all’interno del singolo nodo. 
 
 

Figura 5 - CORD: Architettura del Software di Controllo

Tra le caratteristiche fondamentali dell’architettura CORD vanno certamente indicate la separazione tra piano dati e piano di controllo, secondo il paradigma SDN e la disaggregazione delle funzioni di rete, che può essere coniugata sia dal punto di vista software, sia da quello hardware.
Per quanto riguarda il software, la disaggregazione è basata sulla scomposizione delle funzionalità di controllo in componenti indipendenti, ciascuna potenzialmente realizzata da un diverso fornitore.
La disaggregazione dell’hardware prevede che le funzionalità del data plane siano realizzate da blocchi elementari che svolgono una singola funzione, indipendentemente dal particolare servizio, e controllabile da sistemi operativi e controller di terze parti. Un esempio è costituito dagli switch “white box”, cioè hardware specializzato per il forwarding elettronico di pacchetti. Analogamente ci possono essere “white box ottici” che svolgono commutazione ottica di lunghezze d’onda o terminazione ottica di segnali provenienti dalla rete di accesso o di trasporto.
La disaggregazione delle funzioni di rete ha conseguenze dirompenti sull’architettura hardware delle centrali, in quanto comporta la quasi totale eliminazione di apparati dedicati a specifici servizi.
Più in dettaglio, il piano dati a pacchetto è realizzato dalla Switching Fabric, sia per ciò che riguarda lo switching interno al nodo, sia per il forwarding a livello IP verso il resto della rete e, insieme al piano di controllo virtualizzato, sostituisce completamente switch o router integrati verticalmente a livello di hardware e software.
Per quanto riguarda i nodi di accesso (OLT) la disaggregazione hardware porta ad eliminare le funzionalità di commutazione del piano dati realizzate dalla Switching Fabric del nodo, mentre la terminazione del livello fisico della rete ottica di accesso (PON) è implementata mediante blade specializzate o attraverso dispositivi pluggable inseribili direttamente nelle porte degli switch white-box della Fabric.
Per rendere il controllo e la configurazione delle terminazioni della rete di accesso indipendenti dalle specifiche implementazioni dei diversi partner tecnologici è stato introdotto nell’architettura CORD uno strato software di astrazione chiamato vOLT-HA (Virtual Optical Line Termination - Hardware Abstraction), che espone verso il controllo di rete delle interfacce di gestione e configurazione unificate e indipendenti dal fornitore e dalla tecnologia utilizzata.
La disaggregazione del nodo di trasporto ottico, in aggiunta alla separazione del piano dati da quello di controllo, prevede la suddivisione del nodo di trasporto, attualmente monolitico, in una serie di moduli funzionali controllati separatamente e che possono eventualmente essere realizzati da costruttori differenti [nota 1].
In quest’ottica, TIM ha sviluppato il dimostratore FutureNet dedicato all’evoluzione della rete, per verificare la fattibilità e la convenienza delle tecnologie e dei principi alla base dell’approccio CORD. Il dimostratore FutureNet riproduce un’area metro in cui alcuni nodi di accesso multi-servizio sono interconnessi attraverso una rete di trasporto disaggregata e controllata da un controller Transport-SDN. Nel dimostratore sono stati implementati gli use case per i servizi residenziali, mobili ed enterprise.
Il software CORD ha per il momento una maturità limitata che lo rende adatto principalmente allo sviluppo di PoC (Proof of Concept), ma la sua rapida evoluzione e continuo aggiornamento lo rendono decisamente interessante per applicazioni nel medio/lungo termine.
Fra gli obiettivi principali del dimostratore FutureNet c’è anche la verifica sperimentale della possibilità di integrare lo strato software CORD in un’architettura generale di controllo ed orchestrazione e la definizione di requisiti e linee guida per il deployment. In particolare, sembra molto interessante l’integrazione con la piattaforma di orchestrazione e automazione open source ONAP (Open Network Automation Platform) [5].

 

Conclusioni

Il percorso di trasformazione di TIM in una Digital Telco richiede anche di trasformare in profondità il modo di gestire le infrastrutture ed i servizi di rete, introducendo soluzioni in grado di semplificare ed automatizzare le attività ed i processi. La Network Automation rappresenta quindi un passaggio fondamentale per gestire sempre meglio la crescente complessità della rete e dei suoi sistemi. L’evoluzione avviata in questo senso, consentirà non solo di incrementare significativamente l’efficienza delle attività di gestione della rete, ma si rifletterà positivamente anche sulla customer-experience, attraverso la riduzione dei tempi di attivazione dei servizi e abilitando più diffusamente modelli di self-provisioning. Le aree in cui la Network Automation gioca un ruolo fondamentale sono innanzi tutto quella della NFV, per la realizzazione software delle funzionalità di rete e quella della gestione e controllo della connettività IP attraverso soluzioni di SDN. In ambito NFV, l’automazione è cruciale nel fornire soluzioni per rispondere in modo efficace alle sfide poste dalla gestione della complessità infrastrutturale e delle peculiarità dei requisiti applicativi. Nell’ambito delle reti IP, l’evoluzione in ottica di Network Automation significa fare leva sui principi di astrazione e semplificazione, insiti nell’approccio SDN, per gestire il ciclo di vita dei servizi di connettività IP, traducendo in modo automatico e consistente le richieste espresse ad alto livello in operazioni di controllo e configurazione di rete. Queste due aree evolutive, già oggi fortemente complementari nel supportare la trasformazione verso il nuovo modello di Digital Telco, saranno verosimilmente destinate ad integrarsi ulteriormente e compenetrarsi nel futuro. È il caso dell’architettura CORD, su cui TIM sta conducendo sperimentazioni, che combina le dimensioni NFV e SDN con i principi della disaggregazione, prefigurando la trasformazione dei siti di centrale secondo un modello mutuato dal mondo dei datacenter.

 

Note

  1. Maggiori dettagli possono essere trovati nella documentazione dell’iniziativa OpenROADM [6], dove sono stati individuati e modellizzati con il linguaggio YANG i moduli base per la realizzazione di una rete di trasporto ottica disaggregata.
 
 

Acronimi

  • AAA - Authentication Authorization Accounting
  • API - Application Programming Interface
  • CO - Central Office
  • CORD - Central Office Re-architected as a Datacenter
  • CPU - Central Processing Unit
  • E-CORD - Enterprise-CORD
  • EM - Element Manager
  • EPC - Evolved Packet Core
  • ETSI - European Telecommunications Standards Institute
  • GPON - Gigabit-capable Passive Optical Network
  • HSS - Home Subscriber Service
  • IaaS - Infrastructure as a Service
  • IMS - IP Multimedia Subsystem
  • ISG - Industry Specification Group
  • LAN - Local Area Network
  • LCM - Life Cycle Management
  • LTE - Long Term Evolution
  • M-CORD - Mobile-CORD
  • MANO - MANagement and Orchestration
  • MMS - Multimedia Messaging Service
  • NFV - Network Functions Virtualisation
  • NFVO - NFV Orchestrator
  • NFVI - NFV Infrastructure
  • NGPON2 - Next-Generation Passive Optical Network 2
  • NUMA - Non-Uniform Memory Access
  • OLT - Optical Line Termination
  • ONAP - Open Network Automation Platform
  • OSS - Operations Support System
  • PCRF - Policy and Charging Rules Function
  • PoC - Proof of Concept
  • PON - Passive Optical Network             
  • R-CORD - Residential CORD
  • SD-WAN - Software Defined Wide Area Network
  • SDN - Software Defined Networking
  • SR-IOV - Single Root Input/Output Virtualization
  • VIM - Virtualised Infrastructure Manager
  • VLAN - Virtual LAN
  • VNF - Virtualised Network Function
  • VNFM - VNF Manager
  • VAS - Value-Added Service
  • VoLTE - Voice over LTE
  • vOLT-HA - Virtual Optical Line Termination - Hardware Abstraction
  • VPN - Virtual Private Network
  • VTN - Virtual Tenant Network
  • VXLAN - Virtual eXtensible LAN
  • XGSPON - 10-Gigabit-capable Symmetric Passive Optical Network
  • XML - eXtensible Markup Language
  • YANG - Yet Another Next Generation
 

comments powered by Disqus