Eine neue Architektur des Broadband Network Gateway (BNG) in einer Welt der Virtualisierung von Netzwerkfunktionen (NFV) und Cloud Native

Kurzübersicht:

Die ständig wachsende Nachfrage der Verbraucher nach mehr Bandbreite und Diensten für weniger Geld bringt die Netzwerke der Serviceanbieter schon seit einigen Jahren an ihre wirtschaftlichen Grenzen. Darüber hinaus müssen Anbieter von Telekommunikationsdiensten (Communications Service Provider, CoSP) mehrere Zugangstechnologien (xDSL, PON, FWA und DOCSIS) unterstützen, die vorhandenen Glasfasernetze noch besser ausnutzen und die Leistung der Servicebereitstellung verbessern, und das alles vor dem Hintergrund schwindender Umsätze. Angesichts des prognostizierten jährlichen Wachstums des Kundendatenverkehrs von 26 Prozent zwischen 2017 und 2023 ¹ müssen künftige Netzwerklösungen einen Ansatz bieten, um die Herausforderung des durchschnittlichen jährlichen Datenwachstums von morgen auf kosteneffiziente und skalierbare Weise zu lösen.

Um die Leistungsgrenzen zu erweitern, muss die neueste und beste Technik ganzheitlich und benutzerfreundlich bereitgestellt werden. In diesem Artikel werden die folgenden Designprinzipien vorgeschlagen, um Lösungen auf der Basis von Intel® Architecture Processors und der Virtualisierung von Netzwerkfunktionen (NFV) auf die nächste Leistungs- und Automatisierungsstufe zu heben:

• Optimierte Serverkonfiguration
• „Run-to-completion“-Softwaremodell
• Intelligente I/O-Paket- und Verkehrsflussverteilung
• Unabhängige Skalierung der Steuer- und Benutzerebenen
• Hierarchische Überlegungen zur Dienstgüte
• Bereitstellung mithilfe der Grundlagen des Cloud Native Networking

Unter Berücksichtigung dieser Prinzipien konnte Intel² für ein virtuelles Breitband-Netzwerk-Gateway (vBNG), das auf einem einzigen Server mit skalierbaren Intel® Xeon® Prozessoren der 3. Generation ausgeführt wird, eine Routing-Leistung von fast 661 Gbit/s gemäß RFC2544 (keine Paketverluste) erzielen. In diesem Artikel werden diese Bemühungen erläutert und eine vBNG-Architektur für die Errichtung von Netzwerkinfrastrukturen und Netzwerkfunktionen vorgestellt, um die zugrundeliegende Infrastruktur optimal zu nutzen und die Herausforderung des durchschnittlichen jährlichen Datenwachstums zu bewältigen.

Um die Verlagerung der Breitband-Datenebene in ein virtuelles Ökosystem zu ergänzen, wird in diesem Dokument auch eine Bereitstellungsarchitektur unter Verwendung der Container-Orchestrierungs-Engine Kubernetes (K8s) vorgestellt.

Broadband Network Gateway (Breitbandnetzwerk-Gateway)

Das BNG, auch Broadband Remote Access Server (BRAS) genannt, ist der Aggregationspunkt am Netzwerkrand, der von den Teilnehmern genutzt wird, um auf das Netz des Internetdienstanbieters (Internet Service Provider, ISP) zuzugreifen. Die Teilnehmer stellen über das BNG eine Verbindung zum ISP-Netz her, um den vom Internet ausgehenden Datenverkehr und ISP-Dienste (z. B. Web-, Sprach-, Daten- und Videodienste) herunterzuladen.

Das vBNG ist eine virtualisierte Software-Instanziierung einer typischerweise großen, ASIC-basierten Appliance mit festgelegter Funktion, die sich in der Regel in einer Hauptniederlassung oder einem Metro Point of Presence (PoP) befindet.

Referenzanwendungs-Pipeline

Jede Generation der Technik von Intel (z. B. CPU, Netzwerkadapter, SSD, FPGAs und Beschleuniger) bietet neue Möglichkeiten zur Verbesserung der Leistung und der Quality of Experience (QoE) für Benutzer.

Die Steuerebene ist für die Teilnehmerauthentifizierung und -verwaltung zuständig, einschließlich des monatlichen Nutzungsdienstzugangs und der Konfiguration der Datenebene basierend auf den Teilnehmerprofilen.

Die Upstream-Datenebene verwaltet den Datenverkehrsfluss von den Heimroutern der Benutzer zum ISP-Netzwerk. Die durchschnittliche Paketgröße im Upstream-Datenverkehr ist meist kleiner als die im Downstream-Datenverkehr und die Menge des Upstream-Datenverkehrs ist für gewöhnlich fünf bis achtmalgeringer als die des Downstream-Datenverkehrs. Zwar werden bei Anwendungen wie Instagram, Snapchat und Periscope große Datenmengen von den Benutzern über das ISP-Netzwerk übertragen, doch sind Breitbandbenutzer nach wie vor überwiegend Netto-Datennutzer. In den vergangenen Jahren ist die Kluft zwischen der Upstream- und Downstream-Bandbreitennutzung aufgrund der Erstellung von Daten und Inhalten geringer geworden.

Upstream-Verarbeitungsphasen

Die Referenz-Pipeline von Intel implementiert die in Abbildung 3 dargestellten und im Folgenden beschriebenen Upstream-Verarbeitungsphasen:

Paket Rx (Receive): Der Polling-Modus-Treiber (Poll Mode Driver, PMD) des DPDK (Data Plane Development Kit) wird verwendet, um Schübe von Frames vom NIC-Port (Network Interface Controller, z. Dt. Netzwerkadapter) zu empfangen und sie direkt an einen Uplink-Thread zu senden und so mit der in den nächsten Abschnitten beschriebenen vBNG-Paketverarbeitung zu beginnen.

Zugriffssteuerungslisten (Access Control List, ACL): Die DPDK-ACL-Bibliothek wird verwendet, um eine geordnete Liste von Filtern (z. B. Masken, Bereiche usw.) auf das Frame anzuwenden. Diese umfassen Zulassungs- und Verweigerungsfilter und alle Filter werden pro Paket evaluiert.

Flow-Klassifizierung: Die DPDK-Flow-Klassifizierungs-Bibliothek wird zur Identifizierung der Sitzung und zur Klassifizierung des Pakets auf der Grundlage ausgewählter Felder (z. B. 5-Tupel) verwendet.

Metering Policing: Die DPDK Traffic Metering and Policing API wird verwendet, um ein Zwei-Raten-, Drei-Farben-Markierungs- und Policing-Plan auf den Datenverkehr anzuwenden.

DSCP-Rewrite: In dieser Phase wird die optionale Klassifizierung des Datenverkehrstyps und das Rewrite des DSCP-Feldes (Differentiated Services Code Point) unterstützt, um den Datenstrom einer vom Netzwerk unterstützten CoS (Class of Service) zuzuordnen.

NAT: Optional wird NAT 44 durchgeführt, um private Adressen in öffentliche Adressen umzuwandeln.

Routing: Die Kapselungen des Zugangsnetzes werden aus den Paketen der Datenebene entfernt und die Pakete werden zur Übertragung an die richtige Schnittstelle des Kernnetzwerks weitergeleitet. Alle Kernnetzwerk-Kapselungen, wie MPLS, werden entweder hier oder im Paket-Tx-Block angewendet.

Paket Tx (Transmit): Der DPDK-PMD wird verwendet, um Schübe von Frames an den NIC-Port zu senden.

Die Downstream-Datenebene wickelt den Verkehrs- und Datenfluss vom Internet und dem ISP-Netzwerk zum Endbenutzer ab. Sie verwaltet und plant den Datenverkehr für die mit dem BNG verbundenen Benutzer. Die Downstream-Funktion optimiert die Bandbreiten- und Ressourcennutzung zur Maximierung der Benutzer-QoE auf der Grundlage von Benutzertarifklassen und Verkehrsprioritäten. Ziel des ISP ist es, sicherzustellen, dass alle seine Teilnehmer Services auf höchstem Niveau erhalten und gleichzeitig der Nutzen der Netzwerkinfrastruktur maximiert wird. Prognosen zufolge wird sich der weltweite IP-Videodatenverkehr von 2017 bis 2022 vervierfachen, was einem durchschnittlichen jährlichen Wachstum von 29 Prozent entspricht.³ Dieser Trend wird die durchschnittliche Paketgröße des Downstream-Links in die Höhe treiben.

Downstream-Verarbeitungsphasen

Die Referenz-Pipeline von Intel implementiert die in Abbildung 4 dargestellten und im Folgenden beschriebenen Downstream-Verarbeitungsphasen:

Paket Rx: Der DPDK-PMD empfängt Frames vom NIC-Port und sendet diese direkt in einen Downlink-Thread, um mit der Verarbeitung der vBNG-Pakete zu beginnen, die in den nächsten Schritten erläutert wird.

Zugriffssteuerungslisten (ACLs): Die DPDK-ACL-Bibliothek wird verwendet, um eine geordnete Liste von Filtern (z. B. Masken, Bereiche usw.) auf das Frame anzuwenden. In dieser Phase wird das Reverse-Path-Forwarding blockiert.

NAT: Optional wird NAT 44 durchgeführt, um öffentliche Adressen in private Adressen umzuwandeln.

Verwaltung des Datenverkehrs: Jedes Paket durchläuft einen hierarchischen QoS (HQoS)-Block, um sicherzustellen, dass Pakete mit hoher Priorität bei der Übertragung von Paketen an das Zugangsnetzwerk priorisiert werden. Sie unterstützt einen skalierbaren, fünfstufigen hierarchischen Aufbau (Port, Subport, Pipe, Datenverkehrsklasse und Warteschlangen) von Traffic-Shapern und -Schedulern, um die Bandbreite für verschiedene von den Teilnehmern genutzte Dienste zu garantieren. Jede Pipe ist einem einzelnen Teilnehmer zugeordnet.

Routing: Die Kapselungen des Zugangsnetzes werden aus den Paketen der Datenebene entfernt und die Pakete werden zur Übertragung an die richtige Schnittstelle des Datennetzwerks weitergeleitet. Alle Zugangsnetz-Kapselungen wie VLAN, PPPoE usw. werden entweder hier oder im Paket-Tx-Block angewendet.

Paket Tx: Mithilfe eines DPDK-PMD (Polling-Modus-Treibers) werden Schübe von Frames an den NIC-Port übertragen.

Neuer architektonischer Vorschlag und Argumentation

Um einen BNG-Workload effektiv auf einem Allzweckserver bereitzustellen, sollten die folgenden Architektur- und Implementierungsaspekte berücksichtigt werden:

Implementierung eines Run-to-Completion-Modells

Eine der wichtigsten Überlegungen während der Entwicklung eines softwarebasierten BNG ist die Gewährleistung der Skalierbarkeit der Leistung, wie in der einleitenden Fragestellung dieses Artikels beschrieben. Das BNG sollte die minimale Anzahl von Ressourcen zugewiesen bekommen, die erforderlich ist, um die aktuelle Anzahl von aktiven Teilnehmern zu jeder Tageszeit zu unterstützen. Dies bedeutet, dass das BNG in der Lage sein muss, je nach aktueller Arbeitslast sowohl nach oben als auch nach unten zu skalieren.

Die Referenz-BNG-Pipeline von Intel verwendet ein Run-to-Completion-Modell zur Verarbeitung der Uplink- und Downlink-Pipelines. Dies hat zur Folge, dass alle auf einem Paket ausgeführten Pipeline-Funktionen auf demselben Kern ausgeführt werden. Das hat den Vorteil, dass die Pakete nicht zwischen den Kernen hin- und hergeschoben werden müssen, wodurch die Cache-Fehlzugriffe und die allgemeine Latenz reduziert werden. Ein unmittelbares Ergebnis dieses Designmusters ist, dass eine einzelne vBNG-Instanz nicht über einen einzelnen Kern hinaus skalieren kann. Die Skalierung über einen einzelnen Kern hinaus erfolgt durch die Erstellung einer neuen vBNG-Instanz, die auf einem anderen Kern ausgeführt wird. Der Netzwerkadapter (NIC) wird (mithilfe von benutzerdefinierten Headern, die vom Comms-DDP-Paket unterstützt werden) so programmiert, dass er bestimmte Teilnehmer an jede einzelne neue vBNG-Instanz weiterleitet (mehr dazu weiter unten in diesem Dokument).

Durch die Kombination eines Run-to-Completion-Modells und eines einzelnen Kerns, auf dem eine einzelne vBNG-Instanz ausgeführt wird, besteht für den Orchestrator keine Notwendigkeit, den internen Betrieb der zu skalierenden vBNG-Anwendung zu verstehen. Der Orchestrator kann die Kapazität hoch- oder runterskalieren, indem er die Anzahl der der BNG-Bereitstellung zugewiesenen CPU-Kerne erhöht oder verringert (5 vCPUs pro Instanz mit K8s), sodass eine lineare Skalierbarkeit auf einem bestimmten Server möglich ist. Der Orchestrator kann die Ressourcennutzung optimieren, wenn er Informationen über die Teilnehmerzahl (für ein bekanntes Verkehrsprofil) erhält, die eine einzelne Kerninstanz unterstützen kann, was je nach CPU-Modell variieren kann.

Trennung von Uplink- und Downlink-Verarbeitung

Die CPU-Ressourcennutzung durch die BNG-Uplink- und Downlink-Pipelines ist nicht symmetrisch, da der Downlink aufgrund der von Natur aus größeren Paketgrößen normalerweise mehr Zyklen pro Paket benötigt. Zur effektiven Planung eines BNG teilt die Referenz-Pipeline von Intel den Uplink und Downlink in zwei separate Container auf, die instanziiert und dann separat geplant werden können. Durch diese Trennung wird eine größere Flexibilität in Bezug auf das Scheduling und die CPU-Ressourcennutzung erreicht. So kann beispielsweise einer Downlink-Pipeline ein ganzer physischer Kern zugewiesen werden (zwei Hyperthreading-Kerne mit gemeinsamem Cache), während eine Uplink-Pipeline möglicherweise nur einen halben physischen Kern benötigt (einen Hyperthreading-Kern).

Zuweisung einer einzelnen I/O-Verbindung pro Pipeline

Die Referenz-Pipeline von Intel sollte auf einem BNG-Dataplane-Server ausgeführt werden, der mit einem einfachen Leaf-Switch verbunden ist, der sowohl den Zugangs- als auch den Datennetzverkehr weiterleiten kann. Bei dieser Konfiguration leitet der Switch den von den Zugangsnetz-Ports ausgehenden Uplink-Verkehr zur Verarbeitung an die BNG-Ports weiter und leitet die von den BNG-Uplink-Pipelines zurückkehrenden Pakete an die Datennetz-Ports weiter. Für den Downlink-Verkehr ist der Datenfluss umgekehrt. Wie schon erwähnt, nimmt der Uplink-Verkehr immer mehr zu, macht aber grundsätzlich nur ein Achtel des Downlink-Verkehrs in einem kabelgestützten Netzwerk aus. Daher ist es wahrscheinlich, dass ein BNG, das getrennte, dedizierte physische Ports für Zugangs- und Datennetzwerk-Port-Verbindungen verwendet, die verfügbare I/O-Bandbreite der Uplink-Ports nicht ausreichend nutzt. Die gemeinsame Nutzung von physischen Ports auf einem Netzwerkadapter zwischen Upstream- und Downstream-Verkehr ermöglicht vielmehr die volle Ausschöpfung der I/O-Bandbreite. Da eine vBNG-Instanz in zwei getrennte Pipeline-Anwendungen aufgeteilt ist, verarbeitet jede Pipeline lediglich den Datenverkehr für eine einzige Richtung. Der gesamte Datenverkehr wird über den einfachen L2-Switch zum und vom Server geleitet, sodass nicht für jede Pipeline dedizierte Zugangs- und Datennetzwerk-Ports erforderlich sind. Der Server benötigt im Grunde nur eine einzige I/O-Verbindung, über die er Datenverkehr vom Switch empfängt und verarbeiteten Datenverkehr zur Weiterleitung an den Switch zurücksendet.

Das Routing des Teilnehmerverkehrs zu einer vBNG-Instanz erfolgt über eine dedizierte SR-IOV-Verbindung (Single Root Input/Output Virtualization), die ankommende Pakete in Übereinstimmung mit ihrem SR-IOV-Switch (mit DDP) an das vBNG senden kann. Die SR-IOV ermöglicht die Aufteilung und gemeinsame Nutzung eines einzigen physischen NIC-Ports durch mehrere Pipeline-Instanzen, die jeweils über einen eigenen I/O-Port, d. h. eine virtuelle Funktion (VF), verfügen. Die SR-IOV bietet zudem Flexibilität bei der Nutzung physischer Netzwerkadapter, z. B. durch die Zuweisung eines physischen Netzwerkadapters nur für den Downlink-Verkehr oder die gemeinsame Nutzung eines Netzwerkadapters für den Uplink- und den Downlink-Verkehr. Es wird erwartet, dass der Downlink- und Uplink-Verkehr dieselbe physische NIC nutzen werden, sobald die NIC-Geschwindigkeiten die 100-Gigabit-Grenze erreichen, und genau diese Prinzipien beeinflussen die derzeitige Bereitstellungsarchitektur des vBNG.

I/O-Ausgleich auf dem Server

Bei Zweiprozessor-Servern werden interne Verbindungen wie Plattform-Controller-Hubs (PCHs) und SATA-Controller in der Regel an CPU 0 angeschlossen. Dies kann zu einer ungleichen Verteilung der PCIe-I/O-Bandbreite zwischen den CPUs führen, wobei der größte Teil der Bandbreite mit CPU 1 verbunden ist. Zum Abgleichen der Bandbreite führt die Intel vBNG-Anwendung Funktionen der Steuerebene auf CPU 0 und Funktionen der Datenebene auf CPU 1 aus.

Bei der Bereitstellung eines BNG auf einem Allzweckserver muss sichergestellt werden, dass genügend I/O-Bandbreite vorhanden ist, um die verfügbaren CPU-Ressourcen auf der Plattform vollständig auszuschöpfen (d. h. das Ziel ist es, CPU- und nicht I/O-gebunden zu sein). Mit der Einführung der Trennung von Steuer- und Benutzerebene (Control and User Plane Separation, CUPS)⁴ für BNG kann ein ganzer Server für den Betrieb der BNG-Datenebene dediziert werden. Die gesamte Datenverarbeitung findet zugunsten der Leistungseffizienz an einem einzigen Sockel statt, weshalb zur Erzielung einer optimalen Leistung an jeden Sockel die gleiche Anzahl von I/Os angeschlossen werden muss. Die Bereitstellung von 2x16 oder 4x8 Lane PCIe Gen 4 (16 GT/s)-Steckplätzen an jedem Sockel bietet eine insgesamte I/O-Bandbreite von 800 Gbit/s auf dem Server, die gleichmäßig auf die beiden Sockel verteilt ist (Einzelheiten zur Serverkonfiguration finden Sie im Anhang).

Verteilung von Datenflüssen über einen Netzwerkadapter (NIC)

Wie oben erwähnt, verfügt jede BNG-Instanz über eine festgelegte Anzahl von vCPUs, die den Teilnehmerverkehr verarbeiten. Zur Aufteilung der Teilnehmerflüsse auf die vCPUs ist eine Art Verteiler erforderlich. Diese Aufgabe des Verteilers kann mithilfe von Software und dem Einsatz dedizierter Kerne durchgeführt werden. Allerdings bringt dieser Ansatz einige Nachteile mit sich. Zum einen kann diese Verteilerfunktion zu einem Leistungsengpass führen, da alle Datenflüsse diese Softwarefunktion passieren müssen. Zum anderen verringert sich die Anzahl der CPU-Zyklen, die für die eigentliche Verarbeitung des BNG-Workloads zur Verfügung stehen, wenn ein oder mehrere Kerne der Verteilung gewidmet sind, sodass die Anzahl der BNG-Teilnehmer sinkt, die der Server verarbeiten kann.

Diese Nachteile können durch die Verteilung der Datenflüsse im Netzwerkadapter auf SR-IOV VFs oder Warteschlangen im PMD überwunden werden. Dadurch wird der Software-Engpass beseitigt, die Latenz im System verringert und das BNG erhält die CPU-Kerne und -Zyklen, die andernfalls von der Verteilerfunktion verwendet würden.

Zuweisung einer einzelnen I/O-Verbindung pro Pipeline

Device Config Function (DCF)

Der Intel® Ethernet-Netzwerkadapter E810 ist ein Netzwerkadapter, der Datenflussverteilung mithilfe der DCF-Technik unterstützt. Die DCF legt Regeln für den Datenfluss über eine vertrauenswürdige VF fest, die es dem Benutzer ermöglicht, die physische SR-IOV-Funktion zur Verwaltung und Erfassung von Metriken an den Linux-Treiber zu binden (siehe Abbildung 8). Bei der Verteilung von Datenflüssen im Intel® Ethernet-Netzwerkadapter E810 ist zu beachten, dass für die Verteilung von Datenflüssen zwischen VFs der SR-IOV-Switch und für die Verteilung von Datenflüssen zwischen Warteschlangen der Flow Director (FDIR) oder Receive Side Scaling (RSS) verwendet wird. Bei der BNG-Bereitstellung werden die Datenflüsse mithilfe von VFs verteilt. Dies ist auch der Hauptgegenstand dieses Artikels. Weitere Informationen zu RSS und FDIR erhalten Sie in anderen Whitepapern zum Thema Telekommunikationsunternehmen von Intel.

Dynamic Device Personalization

Neben DCF gibt es die Dynamic Device Personalization (DDP)⁵, die es dem SR-IOV Switch ermöglicht, mehr Paket-Header-Typen als die vorgegebene Menge zu filtern, ohne das Ethernet-Controller-NVM-Image neu zu laden. Für die Bereitstellung der BNG-Anwendung wird das Telecommunication (Comms) Dynamic Device Personalization (DDP)-Paket verwendet. Nach dem Hinzufügen dieses Pakets kann der Ethernet-Controller den Verkehr anhand der PPPoE-Header-Felder an die Offload-VF der Steuerungsebene weiterleiten. Das DDP-PPPoE-Profil ermöglicht es dem Netzwerkadapter, Pakete anhand der eindeutigen PPPoE-Header-Felder (die im nächsten Abschnitt näher beschrieben werden) an bestimmte VFs und Warteschlangen weiterzuleiten.

Weiterleitung von Paketen der Steuerungsebene

Für den Datenverkehr der Steuerungsebene, wie PPPoE-Sitzungsaufbau oder PPPoE-Link-Steuerpakete, muss die BNG-Datenebene diese Pakete identifizieren und zur Verarbeitung an die Steuerungsebene weiterleiten. In einem herkömmlichen BNG befinden sich die Steuerebene und die Datenebene am selben Ort und eine lokale Software-Warteschlange wird verwendet, um Pakete zwischen ihnen zu bewegen. Seit der Einführung der CUPS befinden sich die Steuerebene und die zugehörige Datenebene sehr wahrscheinlich an unterschiedlichen physischen Orten im Netzwerk. In diesem Fall muss die BNG-Datenebene Steuerpakete an die Steuerebene weiterleiten, indem sie eine physische Verbindung zur Weiterleitung herstellt.

Über HQoS

Hierarchische QoS ist eine Funktion, die innerhalb der vBNG-Downlink-Pipeline implementiert ist. Sie gewährleistet, dass die Datenverkehrspriorität beibehalten wird, wenn der aus dem Kernnetzwerk kommende Datenverkehr für die Übertragung über die Zugangsnetz-Pipeline mit reduzierter Bandbreite zu einem Teilnehmer eingeplant wird, und dass die verfügbare Bandbreite an einem bestimmten Port effizient auf alle Benutzer aufgeteilt wird. Der HQoS-Scheduler kann entweder in den Netzwerkadapter (NIC) implementiert werden, sofern Unterstützung dafür vorhanden ist, oder als Softwarefunktion in der Paketverarbeitungs-Pipeline vor der Übertragungsfunktion. Wie bereits erwähnt, verfügt jede Downlink-Pipeline über eine einzige virtuelle Funktionsverbindung für die I/O. In den folgenden Abschnitten werden drei Modelle für die Implementierung von HQoS vorgestellt:

Rein softwarebasiertes Modell

Ein rein softwarebasiertes Modell implementiert den HQoS-Scheduler vollständig in der Software. Wie in Abbildung 12 dargestellt, wird jeder vBNG-Downlink-Pipeline ein Teil der Gesamtbandbreite des Ports zugewiesen, und jede Pipeline passt ihren Datenverkehr an diese Sub-Port-Rate an. Vorteil dieser Methode ist, dass keinerlei Hardware-Support erforderlich ist und dass die HQoS-Scheduler-Instanzen mit Downlink-Paketverarbeitungs-Pipelines skaliert werden können. Der Nachteil dieser Methode ist, dass ungenutzte Bandbreite in einer vBNG-Instanz nicht mit einer anderen Instanz geteilt werden kann, was zu einer suboptimalen Nutzung der Bandbreite des Ports führen kann.

Hybrides Hardware/Software-Modell

Ein Hybrid-Modell kann verwendet werden, wenn die Ressourcen auf dem Netzwerkadapter (z. B. Warteschlangen, Scheduler/Shaping-Knoten) nicht ausreichen, um den HQoS-Scheduler vollständig zu implementieren. Bei diesem Modell implementiert jede BNG-Instanz einige Scheduling/Shaping-Ebenen der Hierarchie in der Software, während die restlichen Ebenen im NIC implementiert werden. Die Entscheidung über die Aufteilung der Hierarchie zwischen Software und Hardware hängt von der Anzahl der NIC-Ressourcen ab. Der Vorteil dieses Modells besteht darin, dass die ungenutzte Bandbreite einer BNG-Instanz von anderen Instanzen genutzt werden kann.

Vollständiges HQoS-Offload-Model

Ein vollständiges HQoS-Offload-Modell erfordert einen Netzwerkadapter, der den vollständigen Offload der HQoS-Verarbeitung aller vBNG-Instanzen unterstützen kann. Ein großer Vorteil dieses Modells ist, dass die CPU bei HQoS keine Rolle spielt und somit CPU-Zyklen für andere Pipeline-Blöcke frei werden. Die vorgeschlagene vBNG-Architektur unterstützt alle drei Modelle, und zwar in Abhängigkeit von den Eigenschaften der zugrunde liegenden Hardware.

Orchestrierung des BNG

Die in diesem Dokument vorgeschlagene vBNG-Architektur schränkt die Art der Virtualisierung einer vBNG-Instanz nicht ein. So kann beispielsweise entweder eine vollständige Virtualisierung der virtuellen Maschine (VM) oder Linux-Container verwendet werden. Besteht ein vBNG aus zwei individuellen Pipelines, mag die Bereitstellung jeder einzelnen Pipeline in einem separaten Container besser sein, da dies im Vergleich zur Bereitstellung in virtuellen Maschinen eine leichtgewichtigere Virtualisierungsoption darstellt. Zudem ermöglichen Container eine schnellere Initialisierung und Wiederherstellung von Instanzen, die der Konvention der hohen Verfügbarkeit in Netzwerkbereitstellungen entsprechen. Für die Bereitstellung einer vBNG-Instanz sowohl in der Referenzanwendung als auch in diesem Artikel wird ein Container-Paar von der Orchestrierungs-Engine Kubernetes gestartet. In diesem Abschnitt wird erörtert, wie dies unter der übergeordneten Konvention einer Cloud-Native Network Function (CNF) erreicht wird. Die beiden größten Einflussfaktoren auf das Design und die Bereitstellung des vBNG sind die CUPS-Architektur und das Cloud-Native Networking. Bei der zuvor beschriebenen CUPS sind die Steuer- und die Benutzerebene zwei separate Entitäten, die über eine festgelegte API kommunizieren. Dieser Abschnitt befasst sich hauptsächlich damit, wie das vBNG Cloud-Native Networking bei hohen Durchsatzraten erreicht. Die folgenden, auch in anderen Dokumenten zum Thema Festnetz von Intel erwähnten Konventionen müssen von einer Telekommunikationsanwendung eingehalten werden, damit diese als CNF eingestuft werden kann:

• Hohe Leistung – Die CNF muss die Vorteile von Enhanced Platform Awareness (EPA) nutzen, um eine niedrige Latenz und einen hohen Durchsatz zu erzielen.
• Flexible Platzierung – Die CNF muss flexibel platziert werden können, damit sie auf jeder Plattform bereitgestellt werden kann, die EPA-Funktionen unterstützt, und sie muss für die bereitgestellte EPA-Infrastruktur geeignet sein.
• Lebenszyklus-Management – Die CNF muss mithilfe automatischer, telemetriebewusster Controller sicherstellen, dass sie bei steigender Arbeitslast Ressourcen skalieren und bei sinkender Arbeitslast Ressourcen reduzieren kann.
• Hohe Verfügbarkeit – Die CNF muss für den erforderlichen Workload stets hohe Verfügbarkeit bieten, indem sie eine extreme Fehlertoleranz in die Komponentenarchitektur einbindet, um das Service Level Agreement von nahezu keinen Ausfallzeiten zu erfüllen. Die CNF muss außerdem das HA-Schema nutzen, um Wartungen von Schnittstellen für schnelle und einfache Service-Upgrades ohne Auswirkungen auf den von ihr bereitgestellten Service durchzuführen.
• Observability (Beobachtbarkeit) – Die CNF muss sicherstellen, dass alle Netzwerk- und Leistungsmetriken von Workloads über eine einfach zu bedienende Plattform zugänglich sind. So ist ein schnelles Debugging und eine schnelle Modifizierung des Netzwerks möglich.

Bereitstellung der Datenebene

Die Bereitstellung des vBNG folgt einem strengen Microservice-Modell, bei dem jedes Element der Anwendungsbereitstellung in die kleinstmögliche ausführbare Einheit aufgeteilt wird, die die Leistung nicht beeinträchtigt. Die vollständige Bereitstellung der Datenebene (nicht in der Steuerungsebene) ist in drei Komponenten unterteilt:

• BNG DP Management
  • Kurz gesagt ist dieser Abschnitt die Schnittstelle zwischen der Steuerebene und der Datenebene in einer vollständigen CUPS-Bereitstellung
  • Dieser Abschnitt ist zuständig für:
    • Konfiguration der Empfangsdatenebene (PFCP-Agent)
    • Einrichten und Speichern der Konfiguration der Datenebene (etcd)
    • Abrufen von Telemetriedaten von den Instanzen der Datenebene
    • Verwaltung der Skalierung von vBNG-Pods/Instanzen
• BNG-Datenebene
  • Wie bereits erwähnt, ist diese Abteilung zuständig für:
    • Die vBNG-Weiterleitungs-Pods Uplink und Downlink
    • Der Telnet-etcd-Agent (Dieser Agent wird vom BNG DP Management und der BNG-Datenebene gemeinsam genutzt, wird aber physisch in der Datenebene bereitgestellt)
• Infrastruktur
  • ​In diesem Abschnitt werden die CPU- und Komponentenmanager von K8 verwendet, um alle von der CNF-Spezifikation geforderten EPA-Funktionen für einen hohen Durchsatz bereitzustellen
  • Dieser Abschnitt ist zuständig für:
    • Das Kubelet von K8s (verwaltet den Containerzustand des Knotens)
    • Der K8s CPU-Manager (versorgt die vBNG-Container mit exklusiven vCPUs)
    • Das SRIOV-Komponenten-Plugin (versorgt die vBNG-Container bei Bedarf mit virtuellen SR-IOV-Funktionen)
    • Der Topologie-Manager (stellt sicher, dass die vom Host empfangenen Ressourcen auf die NUMA-Topologie ausgerichtet sind)
    • Der vereinheitlichte Flow-Stack (verwendet DCF und DDP, um SR-IOV-Switch-Regeln festzulegen, die eine Skalierung auf der Grundlage von Teilnehmer-Header-Feldern ermöglichen)

Bereitstellung der Steuerebene

Die in der BNG-Bereitstellung verwendete Steuerebene wird von BiSDN entwickelt. Diese weist dieselbe Mikrodienstarchitektur auf wie die anderen Komponenten der BNG-Bereitstellung, bei der jedes Element als Container-Entität bereitgestellt wird. Bei der BNG-Bereitstellung kann die BNG-Steuerebene auf demselben Cluster wie das BNGDP-Management und die BNG-Datenebene oder in einem separaten Remote-Cluster zur Steuerung mehrerer BNG-Cluster bereitgestellt werden. Wenn sie in demselben Cluster bereitgestellt wird, verwendet sie dieselben Container-Netzwerkschnittstellen (Container Network Interfaces, CNI) wie andere BNG-Komponenten (siehe Abbildung 16). Sollte der Netzwerk-Operations-Engineer verlangen, dass die BNG-Steuerebene in einem Remote-Cluster platziert wird, wird von ihm erwartet, dass er beispielsweise den K8s Ingress Controller auf dem Datenebenen-Cluster einrichtet, um sicherzustellen, dass der externe Zugriff auf die BNG-Steuerebene reguliert und die Last ausgeglichen wird, damit der DPPFCP-Agent Nachrichten empfangen und analysieren kann.

Überblick der Bereitstellung

Durch die Kombination aller zuvor erörterten Architekturvorschläge ist es möglich, eine skalierbare, orchestrierbare und CUPS-fähige BNG-Lösung zu schaffen, die die I/O- und Rechenressourcen eines Servers mit Intel® Prozessoren effizient nutzt. Diese Lösung kann CoSPs dabei unterstützen, die zu Beginn des Artikels beschriebene Notwendigkeit zu erfüllen, immer größere Bandbreiten zu geringeren Kosten bereitzustellen. Abbildung 17 bietet einen allgemeinen Überblick über eine vollständige CUPS-Bereitstellung sowie über den gesamten eingehenden und ausgehenden Breitbandverkehr.

Leistungs-Benchmarking⁶

Die Leistungsmessungen auf den blauen Pipeline-Blöcken wurden auf einem Zweiprozessor-Server mit aktivierter Intel® Hyper-Threading-Technik (Intel® HT-Technik) und deaktivierter erweiterter Intel SpeedStep® Technik und Intel® Turbo-Boost-Technik durchgeführt. Auf alle Instanzen wurde das gleiche Verkehrsprofil angewandt (4.000 Flows, Downlink/Uplink-Paketgröße = 650 B) und der gesamte Durchsatz (Downlink+Uplink) aller Instanzen wurde gemessen. Die optionalen grauen Blöcke wurden nicht aktiviert.

Durchsatz eines Servers mit Intel® Xeon® Prozessoren mit zwei skalierbaren Intel® Xeon® 6338N Prozessoren der 3. Generation, der die vBNG-Container-Instanzen ausführt. Der Durchsatz lässt sich äußerst effektiv skalieren, wenn in Viererschritten angefangen von 4 bis hin zu 32 vBNG-Instanzen bereitgestellt wird.

Bei 32 bereitgestellten Instanzen beträgt der Durchsatz 661 Gbit/s unter Verwendung des Testverfahrens RFC2544 mit einem Paketverlust von 0,001 %. Dies wird durch den Einsatz von 96 Datenverarbeitungskernen erreicht (1,5 Kerne pro Instanz für 32 Instanzen). Alle von der BNG-Anwendung verwendeten Ressourcen befinden sich lokal auf dem Sockel. Es wird festgestellt, dass er zwar I/O-, aber nicht CPU-gebunden ist.

Bezüglich dieser Ergebnisse ist anzumerken, dass sie in einer reinen Docker-Konfiguration ausgeführt wurden, wobei K8 nicht zum Hoch- und Runterskalieren von Instanzen verwendet wurde.

Zusammenfassung

Die künftige Realisierbarkeit von NFV-basierten Netzwerkkomponenten, die auf Allzweckservern ausgeführt werden, hängt von der Frage ab, inwieweit es möglich ist, das ständig wachsende Verkehrsvolumen auf kostengünstige Weise zu bedienen. In diesem Artikel werden architektonische Überlegungen und Benchmarking-Daten dargelegt, die das enorme Potenzial einer NFV-basierten Paketverarbeitung aufzeigen. Darüber hinaus können CoSPs mit einer Kombination aus BNG- und Service-Edge-Lösungen Netzwerkkonnektivität und neue Services vom Netzwerkrand aus bereitstellen. Durch neue Denkansätze hinsichtlich der Erstellung und Bereitstellung von virtualisierten Netzwerkfunktionen ergeben sich neue Möglichkeiten, wie z. B:

1. Die Neudefinition der Leistungseinheit von der Anzahl der VMs oder Container auf die Anzahl der Kerne, die eine nahezu lineare Steigerung des Uplink- und Downlink-Durchsatzes ermöglichen.
2. Die Schaffung eines Modells, das unabhängig von der Architektur der virtuellen Netzwerkfunktion (VNF) ist (d. h. VM, Container oder Baremetal).
3. Die Erstellung eines deterministischen Modells für den Preis pro Wohneinheit, das entsprechend der durchschnittlichen jährlichen Wachstumsrate des Datenverkehrs vorhersehbar bleibt.
4. Die Erhöhung der Netzwerkverfügbarkeit durch die Umwandlung großer monolithischer Systeme in verteilte Systeme, die es CoSPs ermöglichen, Fehlerdomänen besser zu verwalten und befallene Bereiche abzugrenzen, sodass Überbelastungen aufgrund von Verbindungen und Ausfallzeiten minimiert werden können.
5. Die Schaffung einer multifunktionalen Edge-Infrastruktur, die sowohl NFV als auch Services abdecken kann.

Die rohe BNG-Leistung ist keine Antwort in Form eines einzelnen Datenpunkts, sondern eine Erörterung des Netzwerkstandorts, der Teilnehmerdichte, der durchschnittlichen Bandbreite pro Teilnehmer und des durchschnittlichen jährlichen Wachstums des Datenverkehrs über den gesamten Lebenszyklus der Bereitstellung hinweg. Die in diesem Dokument vorgestellte vBNG-Architektur ermöglicht es CoSPs, den Uplink- und Downlink-Durchsatz zu modellieren und die Funktionen der Steuer- und Benutzerebene unabhängig voneinander auf Allzweckservern auf vorhersehbare und zuverlässige Weise zu skalieren.

*Alle vfs sind zur Verwendung durch die Anwendung an das Modul igb_uio gebunden.
**Die angegebene Frame-Größe ist die maximale Größe des Frames zu einem beliebigen Zeitpunkt während der Verarbeitung.
(z. B. Uplink 128 Byte = 120 Byte +{2x4Byte access vlan tags})