Welcome to EverybodyWiki ! Nuvola apps kgpg.png Sign in or create an account to improve, watchlist or create an article like a company page or a bio (yours ?)...

Central Office Re-Architected as a Data Center

Da EverybodyWiki Bios & Wiki.
Jump to navigation Jump to search


Central Office Re-Architected as a Data Center (CORD) è un nuovo design di Central Office (CO) per telecomunicazioni che sostituisce un hardware chiuso e proprietario con software in esecuzione su server, switch e dispositivi di accesso. Combina il Software-defined networking (SDN), la Network functions virtualization (NFV) e servizi cloud elastici per creare reti di accesso agili e convenienti.

Descrizione[modifica | modifica sorgente]

CORD ristruttura il Central Office come un data center. L'approccio di base verte sull'unificazione delle seguenti tre tecnologie correlate:

  • SDN: riguarda la separazione dei dati della rete e dei piani di controllo, rendendo quest'ultimo programmabile. CORD utilizza SDN non solo per semplificare l'infrastruttura di rete, ma anche come fonte di servizi innovativi che possono essere offerti ai clienti.
  • NFV: riguarda lo spostamento del piano dati da dispositivi hardware a macchine virtuali. Ciò riduce i costi di spese in conto capitale (CAPEX), attraverso il consolidamento dei server e la sostituzione di dispositivi ad alto margine con hardware di base e costi di spese operative (OPEX), attraverso una gestione basata su software. Può anche migliorare l'agilità dell'operatore e aumentare le opportunità di innovazione; non solo supporta le funzioni di rete nelle macchine virtuali, ma divide anche la funzionalità in elementi più piccoli.
  • Cloud: definisce lo stato dell'arte nella costruzione di servizi scalabili, sfruttando soluzioni basate su software, architettura di micro-servizi, piattaforme virtuali, scaling elastico e composizione di servizi, per consentire agli operatori di rete di innovare rapidamente. CORD estende inoltre l'idea di cloud per includere la fibra per l'abitazione e l'accesso wireless come servizio elastico.

Obiettivi[modifica | modifica sorgente]

Gli operatori di rete devono affrontare sfide significative, soddisfando richieste di larghezza di banda e fornendo servizi avanzati. Allo stesso tempo, l'introduzione di una nuova funzionalità richiede spesso mesi o anni. In risposta, gli operatori di rete sono alla ricerca di modi per trarre vantaggio sia dalle economie di scala che dall'agilità di cui godono i fornitori di servizi cloud.

L'obiettivo di CORD non è solo quello di sostituire i dispositivi hardware attuali con delle controparti basate su software più agili, ma anche di rendere l'ufficio centrale parte integrante della più ampia strategia cloud di ogni Telco, consentendo loro di offrire servizi più validi. Ciò significa che l'architettura software di CORD deve essere abbastanza generale da supportare un'ampia gamma di servizi, come servizi di accesso (ad es. Fiber-to-the-Home) e servizi cloud scalabili, servizi implementati nel piano dati (NFV) e servizi implementati nel piano di controllo (SDN), servizi forniti da un operatore fidato e da terzi non attendibili.

Hardware[modifica | modifica sorgente]

L'hardware ideale per CORD è costituito da una collezione di commodity server interconnessi da una struttura composta da white-box switch. Questi elementi hardware sono quindi organizzati in un'unità rack, denominata POD.

Figura 1: POD hardware ideale creato da commodity server, switch e blade I/O.

Un'implementazione iniziale di riferimento per CORD che include server, switch e OLT blade server, assemblati in due rack virtuali, è illustrata nella Figura 1. I server e gli OLT blade server sono interconnessi da una struttura switching a foglia, costituita da due switch centrali (spine switches) e due (top-of-rack) switch fogliari (leaf switches) per rack virtuale; Leaf-2 è collegato a un upstream router e gli OLT blade server sono collegati tramite GPON a ONT e router domestici.

Si noti che sono possibili diverse configurazioni dell'hardware del POD: gli switch fogliari selezionati hanno una capacità sufficiente per supportare fino a 24 server dual-port, gli switch centrali hanno una capacità sufficiente per supportare fino a 16 rack. È anche possibile configurare un "micro POD" che include solo switch foglia/ToR e che viene inserito in un rack parziale.

Blocchi Software[modifica | modifica sorgente]

Per quanto riguarda il software, l'implementazione di riferimento per CORD sfrutta quattro progetti open source, come mostrato nella Figura 2.

Figura 2: Componenti software open source in CORD.
  • OpenStack: è la suite di gestione dei cluster che fornisce la funzionalità di base laaS ed è responsabile della creazione di macchine e reti virtuali.
  • Docker: fornisce il mezzo container-based per distribuire e interconnettere servizi. Svolge anche un ruolo chiave nella configurazione e nella distribuzione del CORD stesso.
  • ONOS: è il sistema operativo di rete che controlla la struttura dei white-box switch sottostante e i network sovrastanti, consentendo l'erogazione del servizio all'utente finale direttamente dalla struttura, se possibile.
  • XOS: è un framework per assemblare e comporre servizi. Unifica i servizi dell'infrastruttura OpenStack, i servizi del piano di controllo ONOS e qualsiasi piano dati o servizio cloud.

Processo di trasformazione[modifica | modifica sorgente]

Trasformare l'ufficio centrale di oggi in CORD è un processo in due fasi.

Virtualizzare i dispositivi legacy[modifica | modifica sorgente]

Il primo passo per riorganizzare l'ufficio centrale come un data center comporta la virtualizzazione dei dispositivi hardware esistenti, trasformando ciascun dispositivo nel suo hardware di base più una controparte software. Nel processo, le funzionalità sono probabilmente disaggregate e ristrutturate in nuovi modi.

Figura 3: ufficio centrale formato da tre dispositivi (CPE, OLT, BNG) da virtualizzare e disaggregare

Virtualizzare l'OLT[modifica | modifica sorgente]

L'Optical Line Termination dirige il collegamento ottico nel Central Office, con ogni punto di terminazione fisico che aggrega un insieme di connessioni. Dato il numero e il costo dei dispositivi OLT in un CO, la virtualizzazione dell'OLT può potenzialmente produrre risparmi significativi in ​​termini di CAPEX e OPEX.

Virtualizzare il CPE[modifica | modifica sorgente]

Un Customer Premise Equipment, spesso chiamato "router domestico" o "gateway residenziale", viene installato nei locali dei clienti. A causa del loro elevato numero, rappresentano una fonte significativa di costi CAPEX e OPEX, oltre ad un ostacolo all'introduzione di nuovi servizi. Spesso gestiscono un insieme di funzioni essenziali (ad es. DHCP, NAT) e servizi opzionali (ad es. Firewall, Parental Control, VoIP) per conto di abbonati residenziali. Estendendo le funzionalità del CPE al cloud, possono essere forniti nuovi servizi e funzionalità di assistenza clienti, che non si potevano implementare prima a causa di limitazioni hardware.

Virtualizzare il BNG[modifica | modifica sorgente]

Un BNG è uno dei dispositivi più complessi e costosi in un ufficio centrale, e fornisce i mezzi attraverso i quali gli abbonati si connettono a Internet. Gestisce un indirizzo IP instradabile per conto di ciascun abbonato e fornisce all'abbonato alcuni tipi di connettività di rete.

Il BNG virtualizzato del CORD, chiamato virtual Router (vRouter), è implementato come un programma di controllo ospitato da ONOS, che gestisce i flussi attraverso la struttura degli switch per conto dei sottoscrittori di un abbonamento. Non viene fatto alcun tentativo per riprodurre molte delle funzioni ausiliarie storicamente raggruppate in un dispositivo BNG, sebbene in alcuni casi (ad esempio, l'autenticazione dei sottoscrittori), tale funzionalità sia fornita da un altro servizio (ad es., VOLT).

Framework dei servizi[modifica | modifica sorgente]

Il secondo passo nella riprogettazione dell'Ufficio Centrale come datacenter consiste nella gestione degli elementi software derivanti dal primo passaggio (più eventuali servizi cloud aggiuntivi) tramite un sistema end-to-end funzionante e controllabile.

Servizi scalabili[modifica | modifica sorgente]

Mentre i termini vOLT, vSG e vRouter vengono utilizzati per fare riferimento alla controparte virtualizzata dei tre dispositivi fisici, sono tutti e tre forniti come servizi. Mentre potremmo chiamare questi servizi in base alle loro controparti, la nuova architettura non richiede più questa funzionalità per essere raggruppata, quindi è più intuitivo pensare al processo di virtualizzazione descritto come risultante di tre generici servizi:

  • vOLT, un programma di controllo in esecuzione su ONOS. Implementa Access-as-a-Service, in cui ad ogni abbonato corrisponde una VLAN.
  • vSG, una funzione del piano dati ridimensionata su un set di containers. Implementa l'abbonamento come servizio (Subscriber-as-a-Service), in cui ad ogni abbonato corrisponde un pacchetto di sottoscrizione.
  • vRouter, un programma di controllo in esecuzione su ONOS. Implementa Internet come servizio (Internet-as-a-service), in cui ad ogni abbonato corrisponde a una sottorete instradabile.
Figura 4: grafo dei servizi CORD, che include due servizi di accesso: vOLT e VG.Fast.

Se a questi tre nuovi servizi viene aggiunta una Content Delivery Network (CDN), abbiamo un esempio dei tre tipi di servizi descritti nell'introduzione: un servizio cloud (CDN), un servizio per il piano dati (vSG) e due servizi del piano di controllo (vOLT e vRouter).

Ciò comporta che l'ufficio centrale illustrato nella Figura 3 viene nuovamente strutturato come mostrato nella Figura 4. Per illustrare la generalità di CORD come piattaforma configurabile, la Figura 4 include anche un servizio vG.Fast per rappresentare una seconda possibile tecnologia di accesso.

Si noti che il grafico in Figura 4 è semplificato per concentrarsi sui servizi che forniscono valore diretto agli utenti finali. Non viene però mostrata una collezione di altri servizi di base che includono ONOS e OpenStack.

Livelli di astrazione[modifica | modifica sorgente]

Il grafico mostrato in Figura 4 rappresenta le specifiche di alto livello fornite da un operatore di rete, le quali devono essere mappate sui server, switch e blade server sottostanti. Ciò è una diretta conseguenza di una raccolta nidificata di astrazioni che CORD stratifica sopra i componenti mostrati in Figura 2.

CORD definisce le seguenti astrazioni (e i meccanismi corrispondenti che le implementano):

  • Grafico di servizio: rappresenta un insieme di relazioni di dipendenza tra un insieme di servizi. La composizione del servizio CORD è una relazione di locazione tra un servizio provider e un servizio tenant. La titolarità del servizio è ancorata a un titolare principale (ad es., abbonato) associato a uno o più account utente.
  • Servizio: rappresenta un programma multi-tenant elastico e scalabile, che include i mezzi per istanziare, controllare e ridimensionare le funzionalità. CORD elabora un controller di servizio che esporta un'interfaccia multi-tenant e un insieme scalabile di istanze di servizio che vengono istanziate in una sezione.
  • Partizione: rappresenta un contenitore di risorse a livello di sistema in cui vengono eseguiti i servizi, inclusi i mezzi per specificare in che modo tali risorse sono incorporate nell'infrastruttura sottostante. CORD modella una partizione come un insieme di macchine virtuali e di reti virtuali; le VM sono implementate dai componenti IaaS sottostanti (OpenStack e Docker), mentre le VN sono implementate da ONOS.
  • Rete virtuale: rappresenta un'interconnessione tra un insieme di istanze. CORD supporta diversi tipi di VN, inclusi Privato (collega le istanze all'interno di una sezione), Accesso Diretto (utilizzato da un servizio tenant per accedere a un servizio provider indirizzando direttamente ogni istanza al provider) e Accesso Indiretto (utilizzato da un servizio tenant per accedere a servizio provider).

Il meccanismo alla base del supporto di CORD per le reti virtuali è implementato da una coppia di applicazioni di controllo eseguite su ONOS. Il primo, chiamato VTN, installa le regole di flusso in OvS in esecuzione su ciascun server per implementare l'indirizzamento diretto o indiretto. Il secondo, chiamato Segment Routing, implementa i flussi aggregati tra i server attraverso la struttura di switching.

Voci correlate[modifica | modifica sorgente]

Collegamenti esterni[modifica | modifica sorgente]


Tema(i) : internet



Altri articoli del tema internet : girly, Cloud computing, MilanoToday, SCP Foundation, Herobrine, Risula, Wangazine




Questo articolo wiki "Central Office Re-Architected as a Data Center" è da Wikipedia The list of its authors can be seen in its historical and/or the page Edithistory:Central Office Re-Architected as a Data Center.


Impossibile trovare il file HTML FacebookLikeButton.html


Compte Twitter EverybodyWiki Follow us on https://twitter.com/EverybodyWiki !