Ri-architettare il Broadband Network Gateway (BNG) in un mondo di virtualizzazione delle funzioni di rete (NFV) e cloud native

Sintesi

La domanda sempre crescente da parte dei consumatori di maggiore larghezza di banda e servizi a un prezzo inferiore ha portato le reti dei fornitori di servizi al loro limite economico ormai da alcuni anni. Inoltre, i fornitori di servizi di comunicazione (CoSP) devono supportare più tipi di tecnologia di accesso (xDSL, PON, FWA e DOCSIS) facendo un uso migliore delle reti in fibra esistenti e aumentando le prestazioni di erogazione dei servizi, il tutto in un contesto di ricavi in calo. Con il traffico dati dei clienti stimato in crescita a un tasso del 26% (anno su anno) dal 2017 al 2023,¹ le future soluzioni di rete devono mostrare un percorso per risolvere la sfida del tasso di crescita annuale composto (CAGR) dei dati di domani in modo conveniente e scalabile.

Il potenziamento delle prestazioni richiede l'adozione delle più moderne ed efficaci tecnologie e di un approccio olistico e facilmente attuabile. Questo documento propone la seguente serie di principi di progettazione per portare soluzioni basate su processori con architettura Intel® e virtualizzazione delle funzioni di rete (NFV) al livello successivo di prestazioni e automazione della rete utilizzando quanto segue:

• Configurazione server ottimizzata
• Modello Software "run-to-completion"
• Pacchetto I/O intelligente e distribuzione dei flussi
• Ridimensionamento indipendente dei piani di controllo e utente
• Qualità gerarchica delle considerazioni di servizio
• Distribuzione utilizzando i fondamenti di rete cloud native

Seguendo questi principi, Intel ha dimostrato che quasi 661 Gbps² di routing RFC2544 ( perdita di pacchetti zero) per un gateway di rete a banda larga virtuale (vBNG) in esecuzione su un singolo server con processore scalabile Intel® Xeon® di terza generazione. Questo documento descrive questo sforzo e propone un'architettura vBNG per la creazione di infrastrutture di rete e funzioni di rete per sfruttare meglio l'infrastruttura sottostante e affrontare la sfida del CAGR dei dati.

Per completare il passaggio del piano dati a banda larga in un ecosistema virtuale, questo documento propone anche un'architettura di distribuzione che utilizza il motore di orchestrazione dei container Kubernetes (K8s).

Broadband Network Gateway

Il BNG, noto anche come server di accesso remoto a banda larga (BRAS), è il punto di aggregazione perimetrale della rete utilizzato dagli abbonati per accedere alla rete del provider di servizi Internet (ISP). Attraverso il BNG, gli abbonati si connettono alla rete dell'ISP per scaricare il traffico di origine Internet e i servizi dell'ISP (ad es. Web, voce, dati e video).

Il vBNG è un'istanza software virtualizzata di quella che è tipicamente una grande appliance a funzione fissa basata su ASIC, solitamente situata in un ufficio centrale o in un punto di presenza metro (PoP).

Pipeline dell'applicazione di riferimento

Ogni generazione di tecnologie Intel (ad es. CPU, NIC, SSD, FPGA e acceleratori) offre nuove opportunità per migliorare le prestazioni e la qualità dell'esperienza (QoE) per gli utenti.

Il piano di controllo è responsabile dell'autenticazione e della gestione degli abbonati, compreso l'accesso al servizio di utilizzo mensile e la configurazione del piano dati, in base ai profili degli abbonati.

Il piano dati a monte gestisce il flusso di traffico dai router domestici degli utenti alla rete ISP. La dimensione media del pacchetto per il traffico a monte è generalmente inferiore a quella per il traffico downstream e la quantità di traffico upstream è normalmente da cinque a otto volte inferiore rispetto al traffico downstream. Mentre applicazioni come Instagram, Snapchat e Periscope hanno visto grandi quantità di dati che sono state inviate dagli utenti alla rete ISP, gli utenti della banda larga sono ancora in modo schiacciante consumatori netti di dati. Negli ultimi anni, la creazione di dati e contenuti ha ridotto il divario tra l'utilizzo della larghezza di banda upstream e downstream.

Fasi di elaborazione upstream

La pipeline di riferimento Intel implementa le fasi di elaborazione upstream mostrate nella Figura 3 e descritte di seguito:

Packet Rx (Ricezione): Il driver della modalità poll (PMD) del kit di sviluppo del piano dati (DPDK) viene utilizzato per ricevere esplosioni di frame dalla porta del controller di interfaccia di rete (NIC) e inviarli direttamente a un thread di uplink per iniziare l'elaborazione dei pacchetti vBNG , descritto nelle fasi successive.

Elenchi di controllo degli accessi: La libreria dell'elenco di controllo degli accessi (ACL) del DPDK viene utilizzata per applicare un elenco ordinato di filtri (ad es. maschere, intervalli, ecc.) al frame. Questi comprendono filtri di autorizzazione e negazione e tutti i filtri vengono valutati per pacchetto.

Classificazione del flusso: La libreria di classificazione del flusso DPDK viene utilizzata per identificare la sessione e classificare il pacchetto in base ai campi selezionati (ad es. 5 tuple).

Criteri di misurazione: L'API di monitoraggio e misurazione del traffico DPDK viene utilizzata per applicare uno schema di marcatura e polizia a due velocità e tre colori al traffico.

Riscrittura DSCP: Questa fase supporta la classificazione facoltativa del tipo di traffico e la riscrittura del campo del punto di codice dei servizi differenziati IP (DSCP) per mappare il flusso su una classe di servizio (CoS) supportata dalla rete.

NAT: Opzionalmente, NAT 44 viene eseguita per convertire indirizzi privati in indirizzi pubblici.

Routing: Gli incapsulamenti della rete di accesso vengono rimossi dai pacchetti del piano dati e i pacchetti vengono instradati all'interfaccia di rete core corretta per la trasmissione. Qualsiasi incapsulamento della rete principale, come MPLS, viene applicato qui o nel blocco Tx del pacchetto.

Packet Tx (Trasmissione): Il DPDK PMD viene utilizzato per inviare raffiche di frame alla porta NIC.

Il piano dati downstream gestisce il flusso di traffico e dati da Internet e dalla rete dell'ISP all'utente finale. Gestisce e programma il traffico verso gli utenti collegati al BNG. La funzione downstream ottimizza la larghezza di banda e l'utilizzo delle risorse per massimizzare la QoE degli utenti, in base alla classe tariffaria dell'utente e alle priorità del traffico. L'obiettivo dell'ISP è garantire che tutti i propri abbonati ricevano servizi secondo gli standard più elevati, massimizzando l'utilità dell'infrastruttura di rete. Entro il 2022, si prevede che il traffico video IP globale aumenterà di quattro volte dal 2017 al 2022, un CAGR del 29 percento,³ e questa tendenza aumenterà la dimensione media del pacchetto del collegamento downstream.

Fasi di elaborazione downstream

La pipeline di riferimento Intel implementa le fasi di elaborazione downstream mostrate nella Figura 4 e descritte di seguito:

Packet Rx: Il DPDK PMD riceve i frame dalla porta NIC e li invia direttamente a un thread di downlink per iniziare l'elaborazione dei pacchetti vBNG, descritta nelle fasi successive.

Elenchi di controllo degli accessi (ACL): La libreria dell'elenco di controllo degli accessi (ACL) del DPDK viene utilizzata per applicare un elenco ordinato di filtri (ad es. maschere, intervalli, ecc.) al frame. Questa fase blocca l'inoltro del percorso inverso.

NAT: Opzionalmente, NAT 44 viene eseguita per convertire indirizzi pubblici in indirizzi privati.

Gestione del traffico: Ogni pacchetto viene eseguito attraverso un blocco QoS (HQoS) gerarchico per garantire che i pacchetti ad alta priorità abbiano la priorità durante la trasmissione di pacchetti alla rete di accesso. Supporta la costruzione gerarchica scalabile a cinque livelli (porta, sottoporta, pipe, classe di traffico e code) di traffic shaper e scheduler per garantire la larghezza di banda per i diversi servizi utilizzati dagli abbonati. Ogni pipe è assegnata a un singolo abbonato.

Routing: Gli incapsulamenti della rete di accesso vengono rimossi dai pacchetti del piano dati e i pacchetti vengono instradati all'interfaccia di rete dati corretta per la trasmissione. Qualsiasi incapsulamento della rete di accesso, come VLAN, PPPoE ecc., viene applicato qui o nel pacchetto Txblock.

Packet Tx: Utilizzando un driver in modalità polled DPDK (PMD), i burst di frame vengono trasmessi alla porta NIC.

Nuova proposta e motivazione dell'architettura

Per distribuire efficacemente un carico di lavoro BNG su un server generico, è necessario considerare i seguenti aspetti dell'architettura e dell'implementazione:

Implementazione di un modello Run to Completion

Una delle considerazioni chiave quando si progetta un BNG basato su software è garantire la scalabilità delle prestazioni in base alla dichiarazione del problema all'inizio di questo documento. Al BNG dovrebbe essere assegnato il numero minimo di risorse necessarie per supportare l'attuale numero di abbonati attivi in qualsiasi momento della giornata. Ciò significa che il BNG deve essere in grado di scalare sia verso l'alto che verso il basso in base al carico di lavoro corrente.

La pipeline BNG di riferimento Intel utilizza un modello run-to-complete per elaborare le pipeline di uplink e downlink. Di conseguenza, tutte le funzioni della pipeline eseguite su un pacchetto vengono eseguite sullo stesso core. Ciò ha dei vantaggi in quanto i pacchetti non devono spostarsi tra i core, riducendo così al minimo gli errori di cache e la latenza complessiva. Un risultato diretto di questo modello di progettazione è che una singola istanza vBNG non può aumentare oltre un singolo core. Il ridimensionamento oltre un singolo core viene effettuato creando una nuova istanza vBNG che viene eseguita su un core diverso. La NIC è programmata (utilizzando intestazioni personalizzate supportate dal pacchetto Comms DDP) al volo per indirizzare abbonati specifici a ogni nuova singola istanza vBNG (ulteriori informazioni su questo più avanti nel documento).

La combinazione di un modello di esecuzione fino al completamento e un singolo core che esegue una singola istanza vBNG elimina la necessità per l'orchestratore di comprendere il funzionamento interno dell'applicazione vBNG per la scalabilità. L'orchestrator può aumentare o diminuire la capacità aumentando o diminuendo il numero di core CPU assegnati alla distribuzione BNG (5 vCPU per istanza con K8), consentendo una scalabilità lineare su un determinato server. L'agente di orchestrazione può ottimizzare l'utilizzo delle risorse quando viene fornito con informazioni relative al numero di abbonati (per un profilo di traffico noto) che può supportare una singola istanza core, che può variare in base allo SKU della CPU.

Separazione dell'elaborazione di Uplink e Downlink

L'utilizzo delle risorse della CPU da parte delle pipeline di uplink e downlink BNG non è simmetrico poiché il downlink normalmente richiede più cicli per pacchetto a causa delle dimensioni dei pacchetti intrinsecamente maggiori. Per programmare in modo efficace un BNG, la pipeline di riferimento Intel divide il collegamento uplink e downlink in due contenitori separati che possono essere istanziati e quindi programmati separatamente. Questa separazione offre una maggiore flessibilità nella pianificazione e nell'utilizzo delle risorse della CPU. Ad esempio, a una pipeline di downlink può essere assegnato un core fisico completo (due core hyperthreaded fratelli) mentre una pipeline di uplink potrebbe richiedere solo metà di un core fisico (un core hyperthread).

Assegnazione di una singola connessione I/O per pipeline

La pipeline di riferimento Intel deve essere eseguita su un server dataplane BNG connesso a uno switch foglia di base in grado di instradare sia l'accesso che il traffico della rete dati. Con questa configurazione, lo switch instrada il traffico di uplink proveniente dalle porte della rete di accesso alle porte BNG per l'elaborazione e instrada i pacchetti di ritorno dalle pipeline di uplink BNG alle porte della rete dati. Il flusso è invertito per il traffico in downlink. Come accennato in precedenza, la quantità di traffico in uplink sta aumentando nel tempo, ma in genere è solo un ottavo del traffico in downlink in una rete fissa. Pertanto, è probabile che un BNG che utilizzi porte fisiche separate e dedicate per l'accesso e connessioni alle porte della rete dati utilizzi in modo insufficiente la larghezza di banda di I/O disponibile delle porte di uplink. Al contrario, la condivisione delle porte fisiche su una scheda di rete tra il traffico upstream e downstream consente di utilizzare completamente la larghezza di banda di I/O. Poiché un'istanza vBNG è suddivisa in due applicazioni pipeline separate, ciascuna pipeline gestisce solo il traffico per una singola direzione. Tutto il traffico viene instradato da e verso il server tramite il semplice switch L2, in modo tale che ogni pipeline non richieda accessi dedicati e porte di rete dati. Il server richiede effettivamente solo una singola connessione I/O su cui riceve il traffico dallo switch e restituisce il traffico elaborato allo switch per l'inoltro.

L'instradamento del traffico dell'abbonato a un'istanza vBNG viene eseguito tramite una connessione dedicata Single Root Input/Output Virtualization (SR-IOV) che può inviare i pacchetti in arrivo al vBNG in conformità con il suo switch SR-IOV (con DDP). SR-IOV consente di dividere e condividere una singola porta NIC fisica tra più istanze della pipeline, ciascuna con la propria porta I/O, ad esempio una funzione virtuale (VF). SR-IOV offre anche flessibilità nell'uso delle NIC fisiche, come dedicare una NIC fisica al solo traffico di downlink o condividere una NIC tra il traffico di uplink e downlink. Poiché le velocità della scheda di rete raggiungono i 100 gigabit, si prevede che il traffico di downlink e uplink condividerà la stessa scheda di rete fisica e questi influenzeranno l'architettura di distribuzione del vBNG.

Bilanciamento dell'I/O sul server

Con i server dual socket, le connessioni interne come Platform Controller Hub (PCH) e controller SATA sono comunemente collegate alla CPU 0. Ciò può comportare una distribuzione non uniforme della larghezza di banda I/O PCIe tra le CPU, con la maggior parte della larghezza di banda collegata alla CPU 1. Per bilanciare la larghezza di banda, l'applicazione Intel vBNG esegue le funzioni del piano di controllo sulla CPU 0 e le funzioni del piano dati sulla CPU 1.

Quando si distribuisce un BNG su un server per uso generico, è importante assicurarsi che vi sia una larghezza di banda di I/O sufficiente per utilizzare completamente le risorse CPU disponibili sulla piattaforma (ad esempio, l'obiettivo è quello di essere vincolato alla CPU e non all'I/O) . L'avvento di Control and User Plane Separation (CUPS)⁴ per BNG consente a un intero server di essere dedicato all'esecuzione del piano dati BNG. Tutta l'elaborazione dei dati è localizzata su un singolo socket per l'efficienza delle prestazioni, che richiede la connessione di una quantità uguale di I/O a ciascun socket per ottenere prestazioni ottimali. Il provisioning di slot PCIe Gen 4 (16 GT/s) a 2x16 o 4x8 corsie su ciascun socket fornisce una larghezza di banda I/O totale di 800 Gbps sul server, equamente bilanciata tra i due socket (consultare l'Appendice per i dettagli sulla configurazione del server).

Distribuzione dei flussi tramite una scheda di interfaccia di rete (NIC)

Come descritto sopra, ogni istanza BNG ha un numero prestabilito di vCPU che elaborano il traffico degli abbonati. È necessaria una qualche forma di distributore per suddividere i flussi di abbonati tra le vCPU. Questa attività del distributore può essere eseguita nel software utilizzando core dedicati, ma questo approccio presenta diversi svantaggi. Innanzitutto, questa funzione di distribuzione può diventare un collo di bottiglia delle prestazioni poiché tutti i flussi devono passare attraverso questa funzione software. In secondo luogo, avere uno o più core dedicati all'esecuzione della distribuzione riduce la quantità di cicli della CPU disponibili per eseguire l'effettiva elaborazione del carico di lavoro BNG, riducendo così il numero di abbonati BNG che il server può gestire.

Questi svantaggi possono essere superati distribuendo i flussi nella NIC ai VF SR-IOV o alle code nel PMD, che elimina il collo di bottiglia del software, riduce la latenza attraverso il sistema e fornisce al BNG i core della CPU e i cicli che altrimenti sarebbero utilizzato dal compito del distributore.

Assegnazione di una singola connessione I/O per pipeline

Funzione di configurazione del dispositivo (DCF)

La scheda di rete Ethernet Intel® E810 è una scheda di rete che supporta la distribuzione del flusso utilizzando la tecnologia Device Config Function (DCF). DCF imposta le regole di flusso tramite un VF affidabile che consente all'utente di mantenere la funzione fisica SR-IOV associata al driver Linux per la gestione e la raccolta delle metriche, come mostrato nella Figura 8. Quando si distribuiscono i flussi nella scheda di rete Ethernet Intel® E810, è necessario notare che per la distribuzione dei flussi tra i VF viene utilizzato lo switch SR-IOV e per la distribuzione dei flussi tra le code, viene utilizzato Flow Director (FDIR) o Receive Side Scaling (RSS). Nella distribuzione BNG, i flussi sono distribuiti utilizzando VF, quindi questo è l'obiettivo di questo documento. Ulteriori informazioni su RSS e FDIR sono disponibili in altri white paper di Intel Telco.

Personalizzazione dinamica del dispositivo

Accanto a DCF c'è la personalizzazione dinamica del dispositivo (DDP)⁵ che consente allo switch SR-IOV di filtrare più tipi di intestazione dei pacchetti rispetto alla quantità predefinita senza ricaricare l'immagine NVM del controller Ethernet. Per la distribuzione dell'applicazione BNG, viene utilizzato il pacchetto DDP (Telecommunication (Comms) Dynamic Device Personalization). Una volta aggiunto, questo pacchetto consente al controller Ethernet di indirizzare il traffico in base ai campi di intestazione PPPoE sul piano di controllo offload VF. Il profilo DDP PPPoE consente alla scheda di rete di instradare i pacchetti a VF e code specifici in base ai campi di intestazione PPPoE univoci (descritti più dettagliatamente nella sezione successiva).

Inoltro di pacchetti di aerei di controllo

Per il traffico del piano di controllo, come l'impostazione della sessione PPPoE o i pacchetti di controllo del collegamento PPPoE, il piano dati BNG deve identificare e inoltrare questi pacchetti al piano di controllo per l'elaborazione. In un BNG tradizionale, il piano di controllo e il piano dati si trovano nello stesso posto e una coda software locale viene utilizzata per spostare i pacchetti tra di loro. Con l'avvento di CUPS, il piano di controllo e il piano dati corrispondente si trovano molto probabilmente in posizioni fisiche diverse nella rete. In questo caso, il piano dati BNG deve passare i pacchetti di controllo al piano di controllo generando un collegamento fisico per inoltrarli.

Considerazioni sull'HQoS

La QoS gerarchica è una funzione implementata all'interno della pipeline di downlink vBNG. Garantisce che la priorità del traffico sia preservata quando il traffico proveniente dalla rete principale è programmato per la trasmissione sul tubo della rete di accesso a larghezza di banda ridotta a un abbonato e la larghezza di banda disponibile su una determinata porta è condivisa in modo efficiente tra tutti gli utenti. Lo scheduler HQoS può essere implementato in NIC se il supporto è disponibile o come funzione software nella pipeline di elaborazione dei pacchetti prima della funzione di trasmissione. Come discusso in precedenza, ogni pipeline di downlink ha una singola connessione di funzione virtuale per l'I/O. Le sezioni seguenti descrivono tre modelli per l'implementazione dell'HQoS:

Modello solo software

Un modello solo software implementa completamente lo scheduler HQoS nel software. Come mostrato nella Figura 12, ogni pipeline di downlink vBNG è ripartita in parte della larghezza di banda complessiva della porta e modella il suo traffico in base a quella velocità della sottoporta. Il vantaggio di questo metodo è che non è necessario il supporto hardware e consente di ridimensionare le istanze dello scheduler HQoS con pipeline di elaborazione dei pacchetti downlink. Lo svantaggio di questo metodo è che la larghezza di banda inutilizzata in un'istanza vBNG non può essere condivisa con un'altra istanza, il che potrebbe portare a un utilizzo non ottimale della larghezza di banda della porta.

Modello ibrido hardware/software

Un modello ibrido può essere utilizzato quando le risorse sulla scheda di rete (ad es. code, scheduler/nodi di modellatura) non sono sufficienti per implementare completamente lo scheduler HQoS. In questo modello, ogni istanza BNG implementa alcuni livelli di pianificazione/shaping della gerarchia nel software e i livelli rimanenti sono implementati in NIC. La decisione di dividere la gerarchia tra software e hardware dipende dal numero di risorse NIC. Come vantaggio, questo modello consente di condividere la larghezza di banda inutilizzata da un'istanza BNG tra altre istanze.

Modello offload HQoS completo

Un modello di offload HQoS completo richiede una scheda di rete in grado di supportare l'offload completo dell'elaborazione HQoS da tutte le istanze vBNG. Uno dei principali vantaggi di questo modello è che la CPU non gioca un ruolo in HQoS, liberando cicli della CPU per altri blocchi della pipeline. L'architettura vBNG proposta supporta tutti e tre questi modelli, a seconda delle capacità dell'hardware sottostante.

L'orchestrazione del BNG

L'architettura vBNG proposta in questo documento non limita il modo in cui un'istanza vBNG viene virtualizzata. Ad esempio, è possibile utilizzare la virtualizzazione completa della macchina virtuale (VM) o i contenitori Linux. Quando un vBNG comprende due singole pipeline, la distribuzione di ciascuna in un container separato può/può essere migliore in quanto è un'opzione di virtualizzazione leggera, rispetto alla distribuzione in macchine virtuali. I container consentono inoltre un'inizializzazione e un ripristino più rapidi delle istanze secondo la convenzione nelle distribuzioni di rete ad alta disponibilità. Per la distribuzione di un'istanza vBNG sia nell'applicazione di riferimento che in questo documento, il motore di orchestrazione Kubernetes avvia una coppia di container. Questa sezione discuterà ulteriormente come ciò viene raggiunto nell'ambito della convenzione ombrello di una funzione di rete nativa del cloud (CNF). Le due maggiori influenze sulla progettazione e implementazione del vBNG sono l'architettura CUPs e il Networking Cloud-Native. Il CUPS descritto in precedenza rende il controllo e il piano utente due entità separate che comunicano su un'API impostata. Questa sezione si concentrerà principalmente su come il vBNG ottiene il Networking CloudNative a velocità di trasmissione elevate. In altri documenti Intel wireline si fa riferimento anche alle seguenti convenzioni a cui un'applicazione di telecomunicazioni deve attenersi per considerarsi un CNF:

• Altamente performante: il CNF deve sfruttare le funzionalità Enhanced Platform Awareness (EPA) per garantire bassa latenza e throughput elevato.
• Posizionamento agile: il CNF deve consentire il posizionamento flessibile per essere distribuito su qualsiasi piattaforma predisposta per le funzionalità EPA e deve essere generico per l'infrastruttura EPA fornita di seguito.
• Gestione del ciclo di vita: utilizzando controller automatici che supportano la telemetria, il CNF deve garantire di poter ridimensionare le risorse con carichi di lavoro in aumento e ritirare le risorse con carichi di lavoro in diminuzione.
• Alta disponibilità: il CNF deve sempre presentare un'elevata disponibilità per il carico di lavoro richiesto, integrando un'estrema tolleranza ai guasti nell'architettura dei componenti per soddisfare il Service Level Agreement di quasi zero tempi di inattività. Il CNF deve inoltre utilizzare lo schema HA per mantenere le interfacce per aggiornamenti dei servizi rapidi e semplici senza alcun effetto sul servizio che fornisce.
• Osservabilità: il CNF deve garantire che tutte le metriche di rete e prestazioni dei carichi di lavoro siano esposte attraverso una piattaforma di facile utilizzo che consenta un rapido debug e modifica della rete.

Distribuzione del piano dei dati

La distribuzione di vBNG segue un modello rigoroso di microservizi in cui ogni elemento della distribuzione dell'applicazione è separato nell'unità di esecuzione più piccola possibile che non influirà sulle prestazioni. La distribuzione completa del piano dati (non piano di controllo) è suddivisa in 3 componenti:

• Gestione del DP BNG
  • In breve, questa sezione è vista come l'interfaccia tra il piano di controllo e il piano dati in una distribuzione CUPS completa
  • Questa sezione è responsabile di:
    • Ricevere la configurazione del piano dati (agente PFCP)
    • Impostazione e memorizzazione della configurazione del piano dati (etcd)
    • Recupero dei dati di telemetria dalle istanze del piano dati
    • Gestione della scala di pod/istanze vBNG
• Piano dati BNG
  • Discussa in precedenza questa sezione è responsabile di:
    • I pod di inoltro vBNG Uplink e Downlink
    • L'agente Telnet etcd (questo agente sembra essere condiviso tra BNG DP Management e BNG Data Plane ma fisicamente è distribuito nel Piano dati)
• Infrastruttura
  • ​Questa sezione utilizza la CPU e i Device Manager di K8 per fornire tutte le funzionalità EPA richieste dalla specifica CNF per un throughput performante
  • Questa sezione è responsabile di:
    • Il K8s Kubelet (gestisce lo stato del contenitore del nodo)
    • Il K8s CPU Manager (fornisce vCPU esclusive ai contenitori vBNG)
    • Il plug-in del dispositivo SRIOV (fornisce funzioni virtuali SR-IOV su richiesta ai contenitori vBNG)
    • Topology Manager (assicura che le risorse ricevute dall'host siano allineate alla topologia NUMA)
    • Lo stack di flusso unificato (utilizza DCF e DDP per impostare le regole dello switch SR-IOV consentendo la scalabilità in base ai campi di intestazione dell'abbonato)

Distribuzione del piano di controllo

Il piano di controllo utilizzato nella distribuzione BNG è costruito da BiSDN. Questo segue la stessa architettura di microservizi degli altri componenti nella distribuzione BNG in cui ogni elemento viene distribuito come entità contenitore. Per l'implementazione di BNG, il BNG Control Plane può essere distribuito sullo stesso cluster di BNGDP Management e BNG Data Plane o in un cluster remoto separato per comandare più cluster BNG. Se distribuito nello stesso cluster, utilizza le stesse interfacce di rete container (CNI) come con altri componenti BNG; vedere la figura 16. Se l'ingegnere delle operazioni di rete richiede che il BNG Control Plane sia posizionato in un cluster remoto, dovrebbe configurare qualcosa come il controller di ingresso K8s sul Data Plane Cluster per garantire che l'accesso esterno al BNG Control Plane sia regolato e bilanciato il carico affinché l'agente DPPFCP riceva e analizzi i messaggi.

Panoramica sull'implementazione

Combinando tutte le proposte di architettura discusse in precedenza, è possibile creare una soluzione BNG scalabile, orchestrabile e abilitata per CUPS che utilizza in modo efficiente l'I/O e le risorse di calcolo di un server basato su processore Intel®. Questa soluzione può aiutare i CoSP a soddisfare la necessità di fornire una larghezza di banda sempre crescente a un costo inferiore, come indicato all'inizio del documento. La Figura 17 fornisce una panoramica di alto livello di un'implementazione CUPS completa insieme a tutto il traffico a banda larga in ingresso e in uscita.

Benchmark delle prestazioni⁶

Le misurazioni delle prestazioni sui blocchi della pipeline blu sono state eseguite su un server dual socket con tecnologia Intel® Hyper-Threading (tecnologia Intel® Hyper Threading) abilitata, tecnologia Intel SpeedStep® avanzata e tecnologia Intel® Turbo Boost disabilitata. Lo stesso profilo di traffico è stato applicato a tutte le istanze (4.000 flussi, dimensione del pacchetto downlink/uplink = 650B) ed è stato misurato il throughput cumulativo (downlink+uplink) in tutte le istanze. I blocchi grigi opzionali non sono stati abilitati.

Throughput di un server basato su processore Intel® Xeon® con due processori scalabili Intel® Xeon® di terza generazione 6338N che eseguono istanze di container vBNG. Il throughput si ridimensiona in modo molto efficace poiché distribuiamo da quattro a trentadue istanze vBNG con incrementi di quattro istanze.

Con trentadue istanze distribuite, il throughput è di 661 Gbps quando si utilizza la metodologia di test RFC2544 con una perdita di pacchetti dello 0,001%. Ciò si ottiene utilizzando 96 core di elaborazione dati (1,5 core per istanza per trentadue istanze). Tutte le risorse utilizzate dall'applicazione BNG sono locali al socket. Si scopre che è legato all'I/O ma non alla CPU.

Qualcosa da notare con questi risultati è che sono stati eseguiti in una configurazione "Solo Docker" in cui K8 non è stato utilizzato per aumentare e ridurre le istanze.

Riepilogo

La fattibilità futura delle apparecchiature di rete basate su NFV in esecuzione su server generici dipende dalla capacità di gestire un volume di traffico sempre crescente in modo conveniente. Questo documento presenta considerazioni sull'architettura e dati di benchmarking che dimostrano l'enorme potenziale per l'elaborazione di pacchetti basata su NFV. Inoltre, i CoSP possono fornire connettività di rete e nuovi servizi dall'edge della rete utilizzando una combinazione di soluzioni BNG e service-edge. Ripensando al modo in cui le funzioni di rete virtualizzate vengono create e distribuite, emergono nuove possibilità, come ad esempio:

1. Ridefinizione dell'unità di prestazioni dal numero di macchine virtuali o container al numero di core che offrono un aumento quasi lineare del throughput di uplink e downlink.
2. Creazione di un modello indipendente dall'architettura della funzione di rete virtuale (VNF) (ovvero VM, container o baremetal).
3. Generazione di un prezzo deterministico per modello di casa che rimane prevedibile con il CAGR del traffico.
4. Aumentare la disponibilità della rete convertendo il grande monolito di sistemi in sistemi distribuiti, che consente ai CoSP di gestire meglio i domini di errore e contenere le aree interessate, riducendo così al minimo le tempeste di connessione e i tempi di interruzione.
5. Creazione di un'infrastruttura perimetrale multifunzione in grado di gestire sia NFV che servizi.

Le prestazioni grezze di BNG non sono una risposta a un singolo punto dati, ma una discussione sulla posizione della rete, la densità degli abbonati, la larghezza di banda media per abbonato e il CAGR del traffico durante il ciclo di vita della distribuzione. L'architettura vBNG presentata in questo documento consente ai CoSP di modellare il throughput di uplink e downlink e di scalare il controllo e il funzionamento del piano utente in modo indipendente su server generici in modo prevedibile e affidabile.

*Tutti i vfs sono legati al modulo igb_uio per l'uso dell'applicazione.
**La dimensione della struttura indicata è la dimensione massima della struttura in qualsiasi momento dell'elaborazione.
(ad es. uplink 128Byte =120byte +{2x4Byte access tag vlan})