Le tecnologie per la rete del futuro

Mentre gli operatori di TLC sono chiamati a ripensare il proprio posizionamento nella catena del valore dei servizi offerti ai clienti, il panorama delle tecnologie di rete sta modificandosi rapidamente. Novità tecnologiche e rifocalizzazione degli investimenti in tecnologia stanno ponendo le basi per una nuova generazione di reti destinata a diventare matura con il prossimo avvento della quinta generazione dei sistemi cellulari. TIM sta guardando con attenzione ai segni iniziali di questa trasformazione, a cui contribuiscono a vario titolo i soggetti che impostano il loro business sui Data Center, le comunità Open Source e la ricerca accademica.
In questo articolo vengono analizzati alcuni elementi che secondo gli autori potranno giocare un ruolo significativo nel plasmare le reti del futuro e che fin da oggi sono oggetto di progetti esplorativi su come potrebbe trasformarsi la rete di TIM a partire dal 2020.

 

Introduzione

Gli operatori in questi anni hanno sperimentato il superamento del traffico voce da parte del traffico dati e hanno affrontato un processo di trasformazione delle proprie reti basato sulle tecnologie IP, inizialmente sviluppate per l’ambiente delle reti campus o aziendali.
La declinazione di queste tecnologie per i Service Provider ha prodotto una specializzazione dei nodi di rete guidata da requisiti peculiari: alte prestazioni, livelli di affidabilità e gestibilità riferiti spesso con il termine “Carrier Class”, funzionalità specifiche per uno sfruttamento commercialmente (ad esempio contabilizzazione del traffico, intercetto legale, …). La dimensione del mercato ha consentito lo sviluppo di aziende interamente dedicate ai Service Provider e in generale alla disponibilità di linee di prodotto ritagliate su questi requisiti.
Oggi l’evoluzione del mercato è contraddistinta da una prevalenza di volumi sul segmento Data Center, fattore determinante per una direzione di sviluppo nuova anche per le tecnologie di rete.
Le diverse generazioni tecnologiche hanno avuto un ciclo di vita che si è esteso fino a dieci o quindici anni. Stiamo per arrivare al decimo anno di vita delle tecnologie utilizzate oggi e questo lascia prefigurare che nel giro di tre o cinque anni assisteremo all’avvento di una nuova generazione. In questa congiuntura, stiamo anche assistendo ad una serie di trasformazioni che hanno tutte le potenzialità di modificare radicalmente l’industria del settore TLC attraverso una sostanziale fusione con l’industria del settore IT: NFV (Network Function Virtualization) è solo l’inizio, SDN (Software Defined Networks) è solo all’inizio.
Saper prevedere quali saranno le tecnologie nel prossimo futuro ed imparare a dominarle è essenziale per affrontare le trasformazioni in atto. Nel seguito di questo articolo si esaminano tre aspetti tecnologici che a nostro parere sono destinati ad avere maggior impatto nel prossimo futuro: l’evoluzione delle soluzioni tecnologiche ed architetturali all’interno dei Data Center, il concetto di “Disaggregazione” degli apparati di rete (Control Plane/User Plane, Hardware/Software) e le nuove tecnologie hardware per la commutazione di pacchetto.
A partire da questi elementi tecnologici è prevedibile che prendano forma le reti di domani, più pervasive, più flessibili e meno costose.

 

La spinta dei Data Center

Il mondo dei Data Center sta diventando un bacino di idee e di soluzioni per i Service Provider. Per ridurre i costi occorrono economie di scala ed il mondo delle TLC richiede oggi apparati troppo specializzati a fronte di un mercato troppo ristretto: guardare alle soluzioni del mondo Data Center è quasi una scelta obbligata. Seguendo questa linea, si è compiuta la transizione da servizi e da interfacce Circuit Based, a servizi e interfacce Packet Based (Ethernet ed IP sono lo standard di fatto che nessuno ormai mette più in discussione) e ora si guarda come ad un “must” all’introduzione di SDN ed NFV nelle reti di TLC. Ma le novità che questo ambiente ha prodotto negli ultimi anni sono molte e vale la pena di riconsiderare il cammino evolutivo e le condizioni che l’hanno determinato.
Nelle reti degli operatori la crescita del traffico Internet negli ultimi anni ha imposto incrementi di capacità significative: dal 2008 al 2014 il traffico Internet anno su anno è cresciuto in media del 35%, ovvero a fine 2014 il traffico totale era pari a circa 6,5 volte il traffico a fine 2008 (fonte Cisco [1]). Ma l’andamento all’interno dei Data Center ha seguito una dinamica decisamente più sfidante: Google ha dichiarato che nello stesso periodo ha registrato una crescita pari a 50 volte [2], quasi un raddoppio anno su anno. Un altro aspetto interessante è che la stragrande maggioranza del traffico dei Data Center è concentrato nelle comunicazioni interne al Data Center, come mostrato in figura 1.

 

Figura 1 - Distribuzione del traffico per i Data Center (fonte Cisco)

Questa situazione contingente ha messo in moto la ricerca, da parte degli OTT, di soluzioni per il networking interno ai Data Center alternative a quelle impiegate sino ad alcuni anni fa, quando venivano utilizzati gli stessi apparati delle reti dei Service Provider: la necessità di mantenere un andamento dei costi costante o in diminuzione al crescere del traffico rappresenta un “must” anche per i Service Provider, tuttavia è evidente come curve di crescita molto diverse abbiano imposto urgenze e quindi soluzioni diverse. Gli OTT hanno cominciato a progettare in proprio le soluzioni di Networking, al fine di perseguire obiettivi di maggiore efficienza ed economia.
Per gli scopi di un Data Center gli apparati utilizzati nelle reti geografiche hanno una serie di caratteristiche che non sono particolarmente utili: l’hardware è appesantito dalla necessità di avere ampi banchi di memoria ad accesso molto rapido per gestire le tabelle di routing Internet e mantenere buffer molto profondi per minimizzare le perdite in condizioni di congestione sui link; il software contiene decine di protocolli che sono necessari per l’ambiente eterogeneo delle reti geografiche e dell’interconnessione con i clienti; in generale vi è l’enfasi sull’affidabilità intrinseca degli apparati e del software, poco rilevanti all’interno dei Data Center. Da questo genere di valutazioni derivano le scelta di utilizzare “Merchant Silicon”, che sappia fornire switching ad alta capacità a basso costo, e di limitare al massimo le funzionalità software, implementando quelle di controllo su piattaforme esterne.
La spinta successiva è stata quella di condividere i progetti e standardizzare “de facto” le soluzioni: per gli attori di questa rivoluzione (in primis Google e Facebook) le tecnologie e gli stessi Data Center non sono parte del Core Business (unica eccezione Amazon che conseguentemente si muove con strategie diverse) e quindi lo scopo ultimo è l’abbattimento dei costi, più facilmente perseguibile quanto più le soluzioni sono largamente adottate. E questo vale non solo per le soluzioni di networking, ma per tutte le componenti interne al Data Center.
Ecco allora Facebook che lancia Open Compute Project [3], cui si uniscono tra gli altri Microsoft, Intel e Rackspace (attualmente aderiscono anche operatori come AT&T e DT): il progetto mira a standardizzare di fatto l’approccio “bare metal” per tutte le componenti dei Data Center a partire dai server, ma con particolare attenzione alla componente di networking. I risultati sono oggi tangibili con un vasto numero di prodotti “senza marchio” (whitebox switch) che hanno prestazioni in termini di throughput nell’ordine del Terabit/s e sono venduti direttamente da aziende che in passato assemblavano prodotti commercializzati da altri (ad esempio Quanta, Accton, …).
Sul fronte del software, il tema della disaggregazione del piano di controllo dal piano di forwarding nelle piattaforme di rete dà vita all’Open Networking Foundation [4], che vede di nuovo tra i protagonisti Facebook e Microsoft, questa volta con Google e Yahoo, ma che coinvolge da subito NTT, AT&T, Verizon e Deutsche Telekom. L’impiego di controller per comandare elementi di rete è fondamentale per risolvere alcuni problemi di scalabilità e di flessibilità per le reti dei Data Center. Gli elementi controllati non sono però solo gli switch fisici, ma anche quelli “virtuali”: nel 2007 il kernel Linux ha inglobato la prima versione di KVM e dal 2009 è disponibile la prima versione di Open vSwitch; anche la virtualizzazione sta seguendo sempre più la strada dell’Open Source e della diffusione a basso costo su larga scala.
Nell’era della virtualizzazione sono tuttavia gli strumenti di gestione dell’infrastruttura (Virtual Infrastructure Manager - VIM) l’elemento più importante: OpenStack, CloudStack e OpenNebula sono alcuni dei progetti collaborativi che sviluppano soluzioni di “cloud management”. Queste soluzioni, tra le quali oggi OpenStack sembra quella vincente, sono essenziali per ridurre i costi operativi e la complessità della gestione di un’infrastruttura che integra migliaia di apparati fisici e decine di migliaia di macchine virtuali. Si osservi che tutte queste soluzioni si pongono principalmente l’obiettivo di ottimizzare l’utilizzo delle risorse di calcolo e configurano reti “overlay” per far comunicare le VM (Virtual Machine) tra loro e con il mondo esterno, trascurando l’ottimizzazione della distribuzione del traffico sulla rete fisica. La configurazione della rete di comunicazione avviene ex-post rispetto alla scelta di dove posizionare le VM e nelle soluzioni odierne non pone vincoli su quest’ultima.
La ricerca di efficienza all’interno dei Data Center va avanti e propone oggi un’ulteriore evoluzione tecnologica: le VM sono inefficienti a causa della duplicazione del sistema operativo; quello che effettivamente è necessario è una forte segregazione tra processi assegnati a diversi Tenant. Il mondo dei Linux container (funzionalmente per altro presente in tutti i principali sistemi operativi per piattaforma server, si vedano ad esempio le jail in FreeBSD) che è già apparso da anni (prima integrazione in Linux nel 2008) offre una soluzione tecnologica a questo problema: si tratta allora di integrare la gestione dei container a più alto livello e questo origina progetti Open Source come Docker [5] o Kubernetes [6], che Google ha di recente trasformato in uno sviluppo cooperativo con altre aziende1. Fra i motivi della mossa di Google sembrerebbe esserci la ricerca di nuove soluzioni alle problematiche di networking nel mondo dei container.
Ad una analisi attenta appare chiaro che la ricetta dei Data Center non è così semplice e va metabolizzata: il percorso virtuoso sembra partire da un’analisi del cosa (le semplificazioni possibili) e solo in un secondo momento prendere in esame il come (le soluzioni tecnologiche). Riportando questo concetto al mondo dei Service Provider, ripensare le soluzioni TLC in ottica IT, semplificandole ed eventualmente rinunciando ad alcune caratteristiche non essenziali, può essere un passo importante e premiante. Metabolizzare il percorso dei Data Center significa comprendere che SDN ed NFV sono solo strumenti e la vera rivoluzione sta nella semplificazione: virtualizzare funzioni elementari (eliminando le complessità inutili) e utilizzare SDN per collegare le funzioni elementari in servizi. Per fare questo occorre prima di tutto passare da nodi di rete monolitici a funzioni elementari e modulari: ed è per questo motivo che il tema della disaggregazione sta diventando uno dei cardini dei progetti più innovativi.

 

La disaggregazione dei nodi di rete

Uno dei temi che sta prepotentemente tornando alla ribalta da qualche tempo a questa parte, ricorrendo in varie forme nelle strategie enunciate e nelle iniziative messe in atto dall’industria del settore è quello della disaggregazione. Si tratta in effetti di un concetto che era già presente nella proposta originale del paradigma SDN e del protocollo OpenFlow come mezzo per realizzarlo. Tuttavia questo principio di netta separazione tra le componenti di forwarding e di controllo dei nodi di rete, anche in chiave di implementazione, è poi passato temporaneamente in secondo piano quando sono apparse le prime applicazioni concrete dell’approccio SDN, come le soluzioni di Flexible Service Chaining o di Transport SDN. L’industria, con i vendor più affermati in prima fila, ha fin qui privilegiato dunque la possibilità di realizzare, mediante l’approccio SDN, forme di controllo dell’instradamento del traffico, tramite l’introduzione di controller dedicati, in grado di imporre opportune eccezioni rispetto al routing di default, per realizzare in modo estensivo funzioni di policy routing e traffic engineering.
Tuttavia, come dicevamo, stiamo assistendo ad un ritorno ai principi fondanti di SDN, che ora si sposano anche con la tendenza sempre più forte a fondersi con il mondo dell’Open Source. Su questo fronte da almeno un anno a questa parte si registra un grande fermento di iniziative in nord America, con attività e sviluppi che coinvolgono operatori di rete, istituzioni di ricerca, nuovi entranti nel mondo dei vendor e principali provider OTT. Il tema della disaggregazione delle piattaforme di rete è da sempre caldeggiato da un pioniere dell’approccio software-defined e di OpenFlow, come Nick McKeown della Stanford University, quale arma per scardinare l’architettura monolitica dei nodi di rete, piattaforme la cui forte integrazione verticale è di ostacolo all’evoluzione della rete, responsabile del persistere di situazioni di oligopolio del mercato e fonte di costi crescenti, in grado di minacciare in prospettiva la sostenibilità del business [7]. La visione di fondo a cui si ispirano le diverse iniziative è illustrata in vedi figura 2 dove i nodi della rete, che sono oggi costituiti da un aggregato monolitico di hardware, sistema operativo e funzionalità proprietarie devono tendere a divenire architetture aperte e modulari, dove l’hardware di switching è basato su chipset commerciali e il sistema operativo è Open Source, su cui possono essere sviluppate ed integrate le applicazioni in modo molto più libero e flessibile.

 

Figura 2 - Da nodo monolitico a ecosistema multi-vendor

In fondo si tratta di avviare nel settore del networking la stessa trasformazione che da anni ha ormai pervaso il mondo del computing. Un’evoluzione in questo senso è abilitata dalla crescita del software Open Source e della sempre maggiore disponibilità di chipset commerciali. Tutto questo dovrebbe indirizzare la necessità sempre più sentita da parte degli operatori di ridurre i costi, ma al contempo di avere margini di differenziazione, facendo leva sull’apertura della piattaforma ed in particolare sulle applicazioni sviluppate sul sistema operativo di rete, dove c’è spazio per le funzionalità proprietarie che ne definiscono il vero valore aggiunto.
La trasformazione è avviata e pare ormai inarrestabile, parafrasando John Donovan, vice-president di AT&T, potremmo dire che “non c’è forza che possa arrestare un principio economico quando i tempi sono maturi per la sua realizzazione” [8]. A questo riguardo AT&T sostiene che mira a trasformare il 75% della sua rete applicando questi principi e utilizzando le tecnologie SDN e NFV entro il 2020.
I principi di disaggregazione ed apertura delle piattaforme adottati nel ridisegnare l’architettura dei nodi e dei sistemi di rete si prestano ad essere applicati a diversi livelli ed in diversi ambiti. Per illustrare le diverse possibili accezioni, vogliamo citare alcune delle iniziative più significative tra le tante in questo filone in continua evoluzione. Partiamo dal nodo di rete come piattaforma di routing, a questo proposito il progetto Atrium [9], varato e sponsorizzato da ONF (Open Networking Foundation), ha dimostrato l’implementazione e l’interoperabilità di un peering router BGP  vedi figura 3 basato sull’integrazione di uno switch OpenFlow, come hardware di forwarding, con un controller SDN (OpenDaylight o ONOS) e una suite di software di routing (Quagga) entrambi Open Source.

 

Figura 3 - Implementazione di un peering Router secondo il paradigma della disaggregazione

Lo switch OpenFlow può essere acquisito da uno dei tanti vendor sul mercato oppure, e qui si innesta un ulteriore possibile livello di disaggregazione, essere sviluppato a partire da un hardware di tipo “bare metal switch” compatibile con il framework del già citato OCP (Open Compute Project) su cui integrare figura 4 componenti di software in buona parte disponibili in open-source ed in parte proprietarie e legate al fornitore del chipset (es. Broadcom).

 

Figura 4 - Modello di switch sviluppato in OCP

La tendenza a sviluppare piattaforme di rete a partire da bare metal switch hardware, i cosiddetti whitebox switch, è stata inaugurata dai maggiori OTT. Il team di networking di Facebook ha recentemente portato avanti un’iniziativa per riprogettare gli switch per le infrastrutture di rete dei propri data Center e relativo sistema operativo, applicando i concetti di disaggregazione e di controllo con approccio SDN. I nuovi nodi di rete sono stati dispiegati in produzione in diversi data Center da ormai un anno. Gli switch sono basati su hardware conforme alle specifiche OCP e sono rivestiti dal sistema operativo Open Source FBOSS sviluppato da Facebook e basato su Linux [10]. Più che un sistema operativo, FBOSS è un set di applicazioni che sfrutta le API OpenNSL (Open Network Switch Library) fornite da Broadcom ed espone tramite un FBOSS Agent un’interfaccia che consente ad applicazioni di controllo di automatizzare gli aspetti di configurazione, monitoraggio e troubleshooting; un altro gruppo di applicazioni consiste poi nei protocolli di routing/forwarding, per esempio BGP.
Sono molte anche le iniziative commerciali che si innestano nel filone della disaggregazione. Prima fra tutte quella del nuovo entrante Cumulus Networks [11]. Cumulus sostiene che il suo punto di forza consiste nell’avere sviluppato la prima versione del sistema operativo Linux (basata sulla distribuzione Debian) per uno switch, un Linux completamente standard dunque, ma ottimizzato per il networking. Cumulus per questo ha lavorato sulla componente ONIE (Open Network Install Environment) del framework OCP. ONIE è una sorta di BIOS o ambiente di preinstallazione, in questo modo il costruttore può sviluppare uno switch che al boot lancia un installer che permette all’utente di scegliere il sistema operativo che desidera installare sullo stesso, ad esempio Cumulus Linux appunto. Sebbene la configurazione dello switch sia gestita interamente da Linux, le funzionalità di packet switching e routing non vengono implementate direttamente dal kernel. Al contrario, a questo scopo Cumulus ha sviluppato un componente software (denominato switchd), una sorta di driver che gira in user space e rappresenta l’elemento originale della sua soluzione. Switchd intercetta i comandi di configurazione di rete forniti in Linux e li traduce in richieste alle API del chipset di switching (utilizzando l’SDK proprietaria fornita dal costruttore degli ASIC). È significativo che, sempre in questa linea di tendenza, molto recentemente anche Dell abbia annunciato la disponibilità del suo sistema operativo di rete di nuova generazione (Dell Networking OS10) basato su Linux Debian.
Fin qui abbiamo elencato iniziative che mirano ad applicare i principi di disaggregazione ai singoli nodi di rete, tuttavia è in corso un’iniziativa molto significativa, il progetto CORD (Central Office Re-architected as a Data Center) [12] avviato da AT&T in collaborazione con ON.Lab [13], che mira a ridisegnare la centrale utilizzando soluzioni e architetture mutuate dai data Center. In questo ambito, il principio della disaggregazione è applicato a ciascuno degli elementi di cui è costituita la tipica sede di centrale, come mostrato ad esempio nella figura 5, individuando i singoli blocchi funzionali che li compongono, per poi ripensarne l’ingegnerizzazione su di un’infrastruttura basata su una switch fabric da data Center e utilizzando tecnologie di controllo SDN e di virtualizzazione NFV. Si tratta di un approccio che AT&T definisce con il termine re-factoring.

 

Figura 5 - Refactoring funzionale di un OLT in architettura CORD

Una volta adottato l’approccio della disaggregazione è immediato anche ripensare a come distribuire le funzioni elementari tra moduli software e moduli hardware, ed in ultima analisi ripensare quali siano i requisiti dell’hardware da impiegare nelle reti di domani: il pensiero dominante negli ultimi anni è stato che l’architettura x86 fosse destinata a sostituire qualunque tipo di hardware facendo leva su prestazioni sempre crescenti e che quindi si trattasse di ridisegnare tutte le funzioni solo in software. Ma anche su questo aspetto stanno emergendo alternative diverse e più promettenti.

 

Switching in hardware o in software?

La domanda che ci si pone a questo riguardo è se valga la pena di continuare a sviluppare dei componenti specializzati per gli apparati di rete ed eventualmente con quale grado di flessibilità. Ovvero se vi sia ancora spazio per lo sviluppo di NPU (Network Processing Unit) flessibili, e quindi per un’industria specializzata in questo campo. Per azzardare una previsione su questo aspetto occorre confrontare le prospettive di evoluzione tecnologica delle due tecnologie.
La capacità delle soluzioni hardware general purpose, CPU (Central Processing Unit) basate su architettura x86, di reggere i requisiti in termini di throughput e ancor più di efficienza (throughput per unità di consumi elettrici) è un tema dibattuto. Il punto di partenza è che la differenza di capacità tra un chipset x86 e un ASIC dedicato allo switching è molto ampia, almeno un ordine di grandezza, e vi sono segnali che in futuro potrebbe anche ampliarsi. La scelta effettuata qualche anno fa di contenere la frequenza di clock non al di sopra di 3GHz-3,5GHz, per limitare la crescita dei consumi energetici, ha portato all’adozione delle architetture multi-core per le CPU. La crescita del numero di core per chipset è dell'ordine di 2-4 core per ogni nuova generazione: si era partiti con 4, ora si è intorno a 32, se all'inizio la nuova generazione raddoppiava la capacità rispetto alla precedente, ora il guadagno in percentuale è marginalizzato e lo sarà sempre di più in futuro. L’unico modo per superare questa situazione è un cambio di architettura di chipset che non pare all’orizzonte.
Sul lato dei chipset dedicati, l’evoluzione a 3-5 anni su cui l’industria sta scommettendo prevede la possibilità di realizzare una tecnologia per NPU 20-25 volte superiore in prestazioni rispetto al presente, con consumi limitati a poche decine di Watt e completamente programmabile. L’aspetto più sorprendente è sicuramente quello della programmabilità, che dovrebbe consentire la realizzazione di chipset flessibili (lo stesso prodotto potrà essere utilizzato per tutte le esigenze di switching e tutte le applicazioni), consentendo di beneficiare maggiormente di economie di scala. È radicata infatti la convinzione che una NPU programmabile costi di più o sia meno performante di una NPU con processamento completamente definito in hardware (10 volte più lenta o 10 volte più esigente in termini di potenza di alimentazione). Tuttavia altri tipi di processori dedicati programmabili, ad esempio i DSP (Digital Signal Processor) o le GPU (Graphic Processing Unit) presentano curve di crescita delle prestazioni e decrescita del costo per unità di capacità molto più pronunciate di quelle delle CPU. Inoltre, un prototipo di switch programmabile, con hardware indipendente dal “tipo” di commutazione, è stato sviluppato da Texas Instruments nel 2013 [14]. Questo prototipo presentava una penalizzazione di circa il 10-15% rispetto alla versione non programmabile ed offriva un insieme limitato di 6 primitive, sufficiente a specificare qualunque protocollo si volesse commutare.
Un’evoluzione di questo tipo può prefigurare il futuro predominio di soluzioni di tipo NPU rispetto a quelle basate sull’uso delle CPU per la realizzazione di funzioni di rete ad alta capacità di throughput. Può però anche indirizzare il mercato delle NPU verso una situazione di sostanziale monopolio, come già si è verificato per le CPU dove Intel riesce a mantenere negli ultimi anni una marginalità sui ricavi stabilmente superiore al 60%.
Una prospettiva di mercato più aperta potrebbe essere abilitata dallo sviluppo di un’architettura standard per l’hardware di switching. Su questa linea, le università americane di Stanford e Princeton hanno avviato attività di ricerca che hanno già portato ad una prima specifica di un modello architetturale denominato PISA (Protocol Independent Switch Architecture). Per programmare gli switch realizzati secondo questa architettura  vedi figura 6, è stato anche specificato un linguaggio chiamato P4 [15], per il quale sono già disponibili il software compilatore e una serie di programmi rilasciati in Open Source per realizzare vari tipi di switch a pacchetto (Ethernet, IP, MPLS).

 

Figura 6 - Modello funzionale di un switch PISA

Questo progetto sta raccogliendo un vasto interesse nella comunità accademica e nell’industria anche perché potrebbe dare ai fornitori tradizionali una serie di vantaggi:

  • ’hardware risulta programmabile anche dopo che è stato venduto e dispiegato in campo;
  • molteplicità di applicazioni e ambiti di utilizzo per lo stesso prodotto;
  • le idee più preziose appartengono al progettista del software e non devono essere svelate alla manifatturiera che ne cura la produzione in volumi.

Anche qualche operatore sta seguendo da vicino l’iniziativa (AT&T, Comcast, SK Telekom) immaginando di avere a disposizione in questo modo un software di switching unico e certificato dall’operatore con i seguenti vantaggi:

  • comportamento uniforme di tutti i nodi di rete;
  • possibilità di selezionare i fornitori di hardware sulla base della capacità di corretta esecuzione del codice proposto dall’operatore;
  • possibilità di far eseguire al fornitore dell’hardware un insieme predefinito di test vincolanti per l’accettazione del prodotto.
 

Verso il 5G con le nuove tecnologie

L’evoluzione delle tecnologie qui descritta può segnare un momento di discontinuità significativa con il recente passato. Il modo di costruire le reti sarà molto diverso da quello che conosciamo oggi e la stessa industria dei fornitori di tecnologia è di fronte a sfide che potrebbero modificarla profondamente.
Guardando all’evoluzione delle architetture di rete, il prossimo grande cambiamento già messo in cantiere è quello dell’avvento del 5G, la quinta generazione dei sistemi cellulari. Come descritto in [rif. Articolo Evoluzione Core Network], la core network del 5G ha l’ambizione di ridisegnare la gestione di accessi legacy e nuovi accessi, accessi mobili e accessi fissi, in una prospettiva di convergenza che enfatizzerà virtualizzazione e controllo software. Guardando invece all’evoluzione del business degli operatori di TLC, è necessario far evolvere l’infrastruttura di rete verso una piattaforma che abiliti la creazione dinamica di nuovi servizi sia per l’operatore stesso sia per terze parti. Le reti che saranno costruite dal 2020 in avanti avranno principalmente lo scopo di realizzare una piattaforma di servizi in linea con le aspettative del 5G: questo obiettivo si troverà ad incrociarsi con la maturità delle nuove tecnologie qui descritte.
TIM ha già iniziato ad affrontare una significativa trasformazione di rete ponendosi l’obiettivo della Network Automation e facendo leva sulle tecnologie di virtualizzazione e sulle prime soluzioni disponibili di Software Defined Network. Per alimentare ulteriormente l’Innovazione, TIM ha anche riconosciuto che questo è il momento più propizio per iniziare a studiare e sperimentare modelli di rete orientati al 5G e capaci di capitalizzare le opportunità che saranno aperte dalle nuove tecnologie. Ripensare le centrali di TLC sulla base dei paradigmi dei Data Center di nuova generazione, sfruttando al massimo l’hardware che si renderà disponibile a scaffale e il software Open Source può rappresentare la chiave per rimanere competitivi nei prossimi decenni. Immaginare una rete del futuro che risponda alle esigenze di servizio, sia allineata con il mercato delle tecnologie e faccia leva su professionalità in grado esprimere tutte le potenzialità del software è una sfida da raccogliere oggi.

 

Bibliografia

  1. http://blogs.cisco.com/sp/the-history-and-future-of-internet-traffic
  2. Arjun Singh et alii, “Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s DataCenter Network”, SIGCOMM ’15, London, United Kingdom.
  3. http://www.opencompute.org/
  4. https://www.opennetworking.org/about/onf-overview
  5. https://www.docker.com/
  6. http://kubernetes.io/
  7. Nick McKeown, "SDN, open-source and ONOS", ONOS Summit, December 2014,
    http://tiny-tera.stanford.edu/~nickm/talks.html
  8. John Donovan, “Hitting the Open Road: Software-Accelerating Our Network with Open Source”, AT&T Innovation Space Blog, June 2015, http://about.att.com/innovationblog/061714hittingtheopen#sthash.FlHhTK7P.dpuf
  9. “Project Atrium An Open Source SDN Distribution”, http://opensourcesdn.org/ossdn-projects/?id=2
  10. Adam Simpkins, “Facebook Open Switching System ("FBOSS") and Wedge in the open”, Marzo 2015,
    https://code.facebook.com/posts/843620439027582/facebook-open-switching-system-fboss-and-wedge-in-the-open/
  11. Cumulus Networks, “Cumulus Linux”, https://cumulusnetworks.com/cumulus-linux/overview/
  12. “Central Office RE-architected as a Data Center (CORD)” White Paper, June 2015, http://onosproject.org/wp-content/uploads/2015/06/Technical-Whitepaper-CORD.pdf
  13. http://www.onlab.org
  14. Pat Bosshart,  Glen Gibb, Hun-Seok Kim, George Varghese, Nick McKeown, Martin Izzard, Fernando Mujica and Mark Horowitz, Forwarding Metamorphosis:
    Fast Programmable Match-Action Processing in Hardware for SDN, SIGCOMM 2013
  15. http://www.p4.org
 

comments powered by Disqus