Steuerung des Teilnehmerverkehrs in der Telco Edge Cloud
Edge Computing ist nicht neu, hat aber mit der Digitalisierung der Betreibernetze eine neue Bedeutung erlangt. Diese Chance hängt von der effizienten Lenkung des Unternehmens- oder Teilnehmerverkehrs auf die richtige Edge-Anwendung oder den richtigen Dienst ab. Operatoren und neue unabhängige Softwareanbieter erforschen innovative Verwendungsmöglichkeiten und Dienste, und die Betreibergemeinschaft entwickelt über die Standardisierungsgremien (wie das Broadband Forum) neue Architekturansätze, um ihre derzeitigen Festnetzressourcen zu verbessern und diese schnell entstehenden Möglichkeiten zu nutzen.
Die Industrie konvergiert darin, die „Edge“ als Orte mit einer maximalen Round Trip Time (RTT) zum Endbenutzer von 20 Millisekunden (ms) zu definieren.1 Diese Art von Zugriffslatenz entspricht den meisten Verwendungszwecken wie Augmented und Virtual Reality (AR/VR), Edge-Videoanalyse und Vehicle-to-Everything (V2X) Kommunikation.
Zu diesen Edge-Dienststellen gehören:
- Von Kommunikationsdienstleistern (CoSP) betriebene Standorte, einschließlich zentraler Büros und regionaler Rechenzentren (DCs) oder angemieteter Platz in Colocation oder von neutralen Hosts bereitgestellten DCs.
- Von Cloud Service Providern (CSP) betriebene Standorte, einschließlich angemieteter Fläche in den Rechenzentren von Colocation-Anbietern.
- Der Enterprise Edge, Standorte wie Zweigstellen, Industriestandorte, regionale Rechenzentren und angemieteter Raum in Rechenzentren von Colocation-Anbietern.
Die Branche hat gerade erst damit begonnen, verschiedene Verwendungszwecke zu erforschen, und es wird immer deutlicher, dass die Latenz- und Bandbreitenvorteile, die das Glasfasernetz bietet, für die Einführung von hochwertigen Edge-Diensten wie Internet der Dinge (IoT), AR/VR und Videoanalyse entscheidend sein werden. Diese Merkmale rücken die Rolle des von CoSP betriebenen Edge in den Mittelpunkt der Wertschöpfungskette für die Bereitstellung von Edge-Diensten.
Die Pandemie hat auch einen neuen Schwerpunkt auf robuste Breitbandverbindungen zu Hause gelegt. Heimarbeit, hybride Arbeitsbedingungen und Heimunterricht setzen das Festnetz unter Druck. Breitbandanschlüsse sind nicht mehr der Luxus, der sie einst für einen einfachen Internet- oder IP-TV-Zugang waren. Infolge der COVID-19-Pandemie ist er de facto zum Mittel geworden, mit dem viele Menschen auf ihre Back-Office-Anwendungen zugreifen, und in der Tat wurde der feste Breitbandzugang zum Mittel, mit dem Schulkinder über Online-Tools für die Videozusammenarbeit Zugang zum Klassenzimmer erhielten. In den Jahren 2020 bis 2021 wuchs der Festnetzverkehr mit einer noch nie dagewesenen CAGR von 40 Prozent.2 Im gleichen Zeitraum gab es auch dramatische Veränderungen in der Symmetrie des Datenverkehrs, wobei der Uplink-Verkehr (Online-Zusammenarbeit) ebenfalls dramatisch zunahm. Vor der Pandemie lag das Verhältnis von Uplink zu Downlink bei 1:8, doch während der Pandemie sank es auf 1:5,3 was neue Anforderungen an die Architektur des Festnetzes stellte.
Auch die größeren CSPs sind auf dem Vormarsch. Amazon hat Outpost auf den Markt gebracht, Microsoft hat Azure Stack für das Netzwerk eingeführt und Google hat Google Anthos für den Edge eingeführt. Diese Ansätze beruhen auf der Prämisse, Edge-Compute-Plattformen einzusetzen, die mit den von den CoSPs verfügten Edge-Cloud-Strategien verbunden und kompatibel sind. Die neuen Anwendungs- und Serviceergebnisse in Verbindung mit der Wahrnehmung der Erlebnisqualität werden bei der Auswahl eines Breitbandanbieters wichtiger sein als die traditionellen Tests der Bandbreitengeschwindigkeit.
Mit einem flexibleren Ansatz und der Möglichkeit, Zugangstechnologien dynamisch bereitzustellen, um mehr Bandbreite oder niedrigere Latenzen über mobile oder feste Zugangstechnologien anzubieten, verfügt der CoSP über eine neue Fähigkeit, die auf die angebotene Edge-Anwendung oder den Dienst abgestimmt werden kann.
Bei der Verwendung in Unternehmen sieht es ähnlich aus. Edge IOT erfordert eine flexiblere anwendungsspezifische Bereitstellung, die durch neue Festnetztechnologien und eine komplementäre Entwicklung der Breitbandstandards ermöglicht werden kann.
Die Lösung muss eine Verschmelzung von technischen und betrieblichen Ansätzen sein, um sowohl Cloud-Anwendungen als auch Netzwerkdienste auf derselben Plattform an einer Vielzahl von Edge-Standorten anzubieten. Ermöglicht wird dies durch die gleichen verteilten Cloud Central Office (CO)-Technologien, die heute auf dem Breitbandforum auftauchen, in Verbindung mit anwendungsspezifischen Steuerungsfunktionen, die es dem Betreiber ermöglichen, automatisch anwendungsspezifische Merkmale über sein Zugangsnetz bereitzustellen.
Angesichts moderner Anwendungsentwicklungszyklen muss das neue digitale Festnetz in der Lage sein, sich schnell und in Echtzeit an neue Anwendungsanforderungen anzupassen. Das bedeutet, dass die klassische Zeit für die Entwicklung eines neuen netzbasierten Dienstes nicht mehr ausreicht und dass neue Methoden zur Steuerung des Datenverkehrs am Rande des Netzes und zur Bereitstellung von Diensten der nächsten Generation am Rande des Netzes eingesetzt werden müssen.
Nicht alle Dienste sind gleich. In Zukunft werden einige von ihnen einen Mehrwert für Kunden mit besonderen Anforderungen bieten. Die Kunden werden mit den angeforderten Diensten verbunden, die an dem Ort bereitgestellt werden, der die Anforderungen an die Latenzzeit und die Bandbreite des Dienstes am besten erfüllen kann, um das richtige Endkundenerlebnis zu bieten.
Die Aufrüstung eines herkömmlichen Festnetzes kann ein zeitaufwändiger und schwieriger Prozess sein. Diese Netzwerke wurden oft mit statisch konfigurierten Verbindungen zwischen dem Kunden und dem Breitband-Netzwerk-Gateway (BNG), das den Kunden verbindet, eingerichtet. Dies bedeutet, dass Wartungsaktivitäten wie Netzwerk-Upgrades und das Hinzufügen neuer Kapazitäten oft spät in der Nacht und mit langen Planungs- und Bereitstellungszyklen durchgeführt werden, die oft „Mann im Lieferwagen“ oder Gabelstapler-Upgrades beinhalten. Infolgedessen sind die Netzwerke oft überdimensioniert, um die Anzahl der Wartungsarbeiten zu minimieren, was zu Ineffizienzen bei Stromverbrauch, Kapazität und Platzbedarf führt.
Es ist eine Weiterentwicklung der Festnetzarchitektur erforderlich, die eine kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) von Entwicklungszyklen sowie einen Zero-Touch-Upgrade-Betrieb ermöglicht. Live-Teilnehmersitzungen werden dynamisch bewegt, ohne dass der Dienst beeinträchtigt wird, und die vom System verbrauchten Ressourcen können nach oben und unten skaliert werden, um die Nachfrage und den Stromverbrauch zu erfüllen.
Der letzte, aber nicht unbedeutende Aspekt ist die Konvergenz der Netzwerke. Seit 2017 arbeiten das Broadband Forum (BBF) und das 3rd Generation Partnership Project (3GPP) gemeinsam an einer Reihe von Standards, die in den kommenden Jahren die Konvergenz von Festnetz und Mobilfunk ermöglichen werden. Das bedeutet, dass die Netze für den Festnetzzugang und den mobilen Zugang zusammenwachsen werden. Der Wandel des Festnetzes hin zu einer stärker auf den Mobilfunk ausgerichteten Steuerungsplattform bedeutet, dass die Festnetzbetreiber die gleichen Cloud-nativen Ansätze verfolgen müssen, die heute für 5G eingesetzt werden.
Architektur Grundlagen der Verkehrslenkung am Rande des Festnetzzugangs
Diese Architektur ist eine vereinfachte Ansicht, die die Schlüsselarbeiten des Broadband Forums in den Projekten Cloud Central Office, Disaggregated BNG und Subscriber Session Steering integriert. Die Architektur ermöglicht eine nahtlose Entwicklung hin zu einer stärkeren Konvergenz von Festnetz und 5G-Netzen, da das Service Gateway auch eine Access Gateway Function (AGF) sein kann, wie in der BBF Wireless Wireline Convergence-Arbeit definiert.
Ein wichtiger Schlüssel zu dieser neuen Architektur ist die Abkehr von der traditionellen statischen Verbindung zwischen einem Teilnehmer und den Diensten. Vielmehr bietet das Netzwerk eine dynamische Auswahl von Eingangsdiensten und eine Lastausgleichsfunktion für Sitzungen, die den Netzwerkbetrieb vereinfacht, die Ausfallsicherheit verbessert und sicherstellt, dass die Sitzungen der Teilnehmer mit Service-Gateways verbunden werden, die die Serviceanforderungen der Kunden erfüllen können, einschließlich Edge-Services mit niedriger Latenz.
Zudem ermöglicht die Architektur eine Cloud-native und disaggregierte Implementierung, bei der die Funktionen in Software auf einer Cloud-Infrastruktur (an geografisch getrennten Standorten) bereitgestellt werden. Dies ermöglicht eine verbesserte Ausfallsicherheit und eine schnellere Entwicklung und Bereitstellung neuer Funktionen und verbundener Dienste.
Die wichtigsten Komponenten dieser Architektur werden in den folgenden Abschnitten beschrieben.
Service Gateway (SG) ist ein allgemeiner Name für die Funktion, die für die Bereitstellung des erforderlichen Netzwerks für den Teilnehmer und den Zugriff auf Anwendungsdienste verantwortlich ist. Beispiele für ein Service Gateway sind Broadband Network Gateway (BNG), Access Gateway Function (AGF) und Provider Edge Router (PE). Das Service Gateway ist in Funktionen der Kontroll- und Benutzerebene unterteilt, die auf Protokollen der Control User Plane Separation (CUPS) basieren.
Die Service Gateway Control Plane (SG-CP) ist die Steuerungskomponente der Service-Gateway-Benutzerebene, wobei jede Steuerebene in der Lage ist, viele Service-Gateway-Benutzerebenen zu steuern. Er ist für Funktionen wie die Authentifizierung von Abonnenten und die Zuweisung von IP-Adressen zuständig.
Service Gateway User Plane (SG-UP) ist die Komponente der Benutzerebene des SG und ist für die Weiterleitung des Datenverkehrs und den Zugang des Benutzers zu den erforderlichen Netzwerk- und Anwendungsdiensten verantwortlich. Nutzerebenen werden sowohl an Edge- als auch an Core-Standorten eingesetzt, so dass die Dienste mit angemessenen Latenzzeiten bereitgestellt werden können, um das gewünschte Anwendungserlebnis für den Endbenutzer zu bieten. Darüber hinaus können die Benutzerebenen je nach Bedarf als Hardware- oder Softwarefunktionen implementiert werden, um die Anforderungen des Betreibers an Flexibilität und Verkehrsweiterleitung zu erfüllen.
Die Steuerungsebene der Sitzungssteuerung ist für die Identifizierung der Benutzerebene zuständig, mit der ein Teilnehmer verbunden werden soll. Session Steering Control Plane ist für die Identifizierung der Benutzerebene verantwortlich, mit der ein Teilnehmer verbunden werden soll. Der Schlüssel dazu ist die User Plane Selection Function (UPSF), die jedes Mal abgefragt wird, wenn eine neue Teilnehmersitzung aufgebaut wird. Sie identifiziert das Service Gateway und die Benutzerebene, die die Service- und Latenzanforderungen des Teilnehmers erfüllen und gleichzeitig für eine ausgeglichene Last in der Domäne sorgen. Die UPSF ist zudem für die proaktive und reaktive Identifizierung aller erforderlichen Änderungen in der Zuordnung von Service-Gateway und Benutzerebene als Reaktion auf Netzwerkänderungen und Wartungsaktivitäten verantwortlich.
Die Verkehrslenkungsfunktion (Traffic Steering Function, TSF) ist für die Weiterleitung der Pakete für eine bestimmte Sitzung an und von der richtigen Benutzerebene verantwortlich. Dies ist eine relativ einfache Cross-Connect-Funktion, die in den Physical Access Node oder einen Aggregations-Switch oder Router eingebaut werden kann.
Access Session Detection (ASD) ist die Funktion, die erkennt, dass eine neue Sitzung aktiv ist und mit dem richtigen Service Gateway und der richtigen Benutzerebene verbunden werden muss. Das erste Signal für eine neue Sitzung hängt von der Art der Teilnehmersitzung ab, aber es handelt sich um Aktivitäten wie das Hochfahren eines Ports am physischen Knoten oder den Empfang von Sitzungsanforderungspaketen von einem privaten oder geschäftlichen Standort. Wie bei der Verkehrslenkungsfunktion kann auch die Funktion der Erkennung von Zugangssitzungen vom physischen Zugangsknoten oder von jedem anderen Element übernommen werden, das eine neue Sitzung als erstes Lebenszeichen erkennen kann.
Die Access Node Control Functions sind das Ergebnis der Disaggregation des herkömmlichen Zugangsknotens, wobei die Steuerungsebene in der Cloud-Umgebung eingesetzt werden kann und die zugangstechnologiespezifische Steuerung des physischen Zugangsknotens ermöglicht.
Der Physical Access Node ist für den Abschluss der Glasfaser- oder Kupferanschlüsse von Haushalten und Unternehmen zuständig.
Was hat sich verändert? Unterstützende Demonstration und wichtige Verwendungszwecke
Um die Architektur zu testen, begannen Intel, Vodafone und BISDN mit dem Bau eines funktionsfähigen Laborprototyps.
Intel arbeitete mit BISDN zusammen, um die BNG Session CP (SG-CP) Erweiterungen bereitzustellen, die die Interaktion mit der User Plane Selection Function (UPSF) ermöglichen, die von Vodafone entwickelt und gebaut wurde. Intel stellte auch die Verkehrslenkungsfunktion (TSF) zur Verfügung, die auf einem programmierbaren Intel® Tofino™ 64 x 100G Ports P4 Switch implementiert wurde. Dabei wurde die vom Programmierprotokoll unabhängige Sprache der Packet Processors (P4) verwendet, die einen programmatischen und flexiblen Ansatz für die Klassifizierung des Festnetzverkehrs ermöglichte. Der Intel Tofino-Switch leitet den mit einem bestimmten Teilnehmerkontext verbundenen Datenverkehr vom Zugangsnetz zu der spezifischen BNG User Plane-Instanz, die durch den Steuerungsprozess identifiziert wurde, und in umgekehrter Richtung von der BNG User Plane zum Zugangsnetz.
Die Demo wurde im Intel Labor durchgeführt und für das Broadband World Forum (BBWF) 2021 aufgezeichnet. Der Schwerpunkt der Demo lag darauf, zu zeigen, wie einige der in der Einleitung genannten Probleme durch die Verwendung dieses Ansatzes angegangen und gelöst werden können.
Die erste Demo erläutert, wie das gesamte System, einschließlich aller Schlüsselkomponenten der Kontroll- und Benutzerebene, auf einer Kubernetes Edge Cloud instanziiert werden kann und anschließend neue Abonnenten zum System hinzugefügt werden. Der wesentliche Unterschied besteht in der Einbeziehung der UPSF, die der SG-CP nun abfragt, um die aktuelle Auslastung des SG-UP zu ermitteln und zu entscheiden, auf welchem SG-UP ein neuer Teilnehmer instanziiert werden soll. Dies ermöglicht dem Betreiber eine viel dynamischere Kontrolle über die Ressourcennutzung und verringert die Auswirkungen eines Ausfalls, bei dem ein überlasteter SG-UP außer Betrieb geht und viele aktive Abonnenten vom Netz trennt. Dieser Bereitstellungsansatz ist dynamischer und Cloud-ähnlicher und verwendet die gleichen Ansätze, die heute in vielen 5G-Kernimplementierungen verwendet werden.
In der zweiten Demo ging es um die Auswahl von Diensten. Sie zeigt, wie das System verwendet werden kann, um Abonnenten dynamisch mit neuen Edge-Diensten zu verbinden. In einem solchen Fall erstellt der SG CP eine Verknüpfung in der UPSF, die eine Liste von Servicegruppen-IDs enthält, und die SG-UPs können den Zugriff auf diese Services ermöglichen. Das Einrichten einer neuen Sitzung ähnelt der oben beschriebenen Sequenz, aber in diesem Fall enthält die Betreiberrichtlinie (z.B. Radius-Server) zusätzliche Informationen über die Dienste (Dienstgruppen-IDs), die der neue Teilnehmer benötigt. Auch in diesem Fall entscheidet die UPSF anhand der aktuellen Auslastung, mit welchem SG-UP der Teilnehmer verbunden werden soll, und ermöglicht den Zugang zu den angeforderten Edge-Services. Dies ermöglicht es den Betreibern, dynamisch neue SG-UPs zu erstellen und zuzuweisen, basierend auf den Merkmalen der neu verfügbaren Dienste.
Das Zugangsnetz wird flexibler und dienstleistungsorientierter, damit die Betreiber ihre Netzbereitstellung und ihre Ausgaben mit umsatzbringenden Diensten abstimmen können.
Beim nächsten Verwendungszweck geht es um die Wartung vor Ort: die Entfernung eines in Betrieb befindlichen SG-UP oder die Aktualisierung eines neuen SG-UP auf eine neuere Softwareversion mit neuen Funktionen oder Verbesserungen. Dies ist heute häufig der Fall, wenn Betreiber neue Funktionen (z. B. IPv4-zu-IPv6-Dienste) oder Fehlerbehebungen einführen müssen, die Eingriffe von Mitarbeitern im Lieferwagen oder Ausfallzeiten spät in der Nacht erfordern können. Hier führen wir das Konzept eines Shards ein. Ein Shard ist eine Gruppe von Abonnenten, die auf die gleiche Weise behandelt werden. Der Operator stellt einen Antrag auf Löschung des SG-UP und der UPSF identifiziert dann einen anderen in Betrieb befindlichen SG-UP, der die derzeit aktiven Shards/Abonnenten unterstützen kann. Dann installieren Sie über den richtigen SG-CP die vorhandenen Zustände der Teilnehmer auf dem neu ausgewählten SG-UP. Anschließend benachrichtigt die UPSF die TSF, um die betroffenen Shards an die neu ausgewählten SGUPs umzuleiten und auch den Downstream-Verkehr in Richtung des Endbenutzers neu zu konfigurieren. Die Shards werden von dem unterversorgten SG-UP zum neu ausgewählten SG-UP bewegt. Wenn diese Bewegung abgeschlossen ist, sendet UPSF die endgültige Löschnachricht an den SG CP. Der SG-UP wird aus dem Dienst genommen und kann dann mit einer neuen Software aufgerüstet und anschließend im K8-Edge-Cluster neu instanziiert werden.
Ein weiterer Verwendungszweck ist die grüne Strategie und die Energieoptimierung. Die UPSF ist so eingerichtet, dass sie in regelmäßigen Abständen die Auslastung der einzelnen in Betrieb befindlichen SG-UPs überprüft und dabei die tageszeitlichen Verkehrsheuristiken berücksichtigt. Zu Stoßzeiten skaliert der UPSF die SG UP-Instanzen, um den Spitzenverkehr zu bewältigen, der in der Regel am Abend auftritt. Umgekehrt kann der UPSF beim „Abschalten“ die Subscriber Shards neu ausbalancieren und die SG-UP Knoten „einskalieren“, indem er die zugrunde liegenden Ressourcen abschaltet und den damit verbundenen Strom spart.
Um diese neue Flexibilität und Skalierung zu ermöglichen, werden die Knoten der Service-Benutzerebene (SG-UP) als Cloud-native Mikrodienste implementiert. Dadurch können die Benutzerebenen in Kubernetes (k8) Clouds mit mehreren Standorten bereitgestellt und entsprechend dem Durchsatz- und Latenzbedarf der an diesen Standorten gehosteten Dienste dimensioniert/skaliert werden.
Diese Cloud-native-basierte User-Plane-Architektur ähnelt dem Ansatz, der bei 5G verfolgt wird, und implementiert jeden BNG-Mikrodienst in Software unter Verwendung der Vektor-Paketverarbeitungs-Technologien (VPP), die im FD.IO-Projekt verfügbar sind. Jeder BNGUP ist als Docker-Container POD mit zwei Instanzen implementiert, von denen jede zwei Intel® Xeon® SP 6338N Prozessorkerne der neuesten Generation verbraucht.
Für die BNG-Anwendung, die den Intel® Ethernet Network Adapter E810 verwendet, wird das Telecommunication (Comms) Dynamic Device Personalization (DDP) Package verwendet. Sobald dieses Paket hinzugefügt wird, kann die Ethernet-Steuerung den Datenverkehr auf der Grundlage der Header-Felder des Point-to-Point-Protokolls über Ethernet (PPPoE) lenken und so die Entlastung der Steuerungsebene unterstützen. Das DDP PPPoE-Profil ermöglicht es dem Netzwerkadapter, Pakete auf der Grundlage der eindeutigen PPPoE-Headerfelder, nämlich der Protokoll-ID, an bestimmte virtuelle Funktionen/Warteschlangen weiterzuleiten.
Die Instanzen von Cloud BNG-UP, die in der Demonstration verwendet wurden, wurden vom Berliner Institut für Software Defined Networking (BISDN) und Intel entwickelt (siehe Link zum Papier).
Der Durchsatz eines auf einem Intel® Xeon® Prozessor basierenden Servers mit zwei skalierbaren Intel Xeon® Prozessoren der 3. Generation 6338N, auf dem vBNG Container-Instanzen laufen. Der Durchsatz skaliert linear, wenn wir von vier bis zweiunddreißig vBNG-Instanzen mit einer Schrittweite von vier Instanzen einsetzen. Bei der Verwendung von zweiunddreißig Instanzen beträgt der Durchsatz 661 Gbps bei Verwendung der RFC2544-Testmethodik mit 0,001% Paketverlust. Dies wird durch die Verwendung von 96 Datenverarbeitungskernen erreicht (1,5 Kerne pro Instanz für zweiunddreißig 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.
Diese Flexibilität des Ansatzes eignet sich gut für die Grundlagen und die Flexibilität, die für die Steuerung des Randverkehrs in einer Architektur mit mehreren Standorten erforderlich sind.
Dieses Diagramm ist ein Auszug aus der Demo von Vodafone, Intel und BISDN, die auf dem BBWF 2021 gezeigt wurde. https://youtu.be/k9P6a71FwNo.
In der Abbildung sind die verschiedenen beteiligten Komponenten deutlich zu erkennen: die Teilnehmer und Shards, die Verkehrslenkungsfunktion und die aktiven Benutzerebenen, die den Zugang zu den Edge-Diensten ermöglichen.
Fazit
Für die Anbieter von Festnetz-Zugangsdiensten bietet sich eine große Chance, ihre Netze zu differenzieren, indem sie sich von der traditionellen statischen Zuordnung von Teilnehmern zu Diensten wegbewegen und es ermöglichen, einzelne Teilnehmersitzungen an den richtigen Ort zu leiten, um ihre Dienstanforderungen zu erfüllen, einschließlich angemessener Latenzzeiten für Edge-Anwendungen. Gleichzeitig besteht die Notwendigkeit, die kontinuierliche Bereitstellung neuer CI/CD-ähnlicher Softwarefunktionen im Netzwerk zu unterstützen, ohne dass lange Planungszyklen und Netzwerkausfälle erforderlich sind.
Es wurde eine neue, dynamischere Fixed Access-Architektur definiert, die Cloud Native-Prinzipien unterstützt, damit die Kontroll- und Benutzerebene des Netzwerks als schnelle Reaktion auf eine Zunahme des Kundenverkehrs oder der Service-Anforderungen skaliert werden kann und neue Funktionen auf der Kontroll- und Benutzerebene in einem kontinuierlichen Bereitstellungsansatz ohne kostspielige und zeitraubende Wartungsausfälle eingeführt werden können.
Aus der Perspektive des einzelnen Teilnehmers kann das Netzwerk seine Sitzungen jetzt dynamisch mit einem Service-Gateway am richtigen Standort verbinden, um die Anforderungen der jeweiligen Anwendung zu erfüllen, einschließlich neuer Anwendungen, die von der Bereitstellung an Edge-Compute-Standorten mit niedriger Latenz profitieren.
Anhang
vBNG-Server | |
---|---|
Plattform |
Intel® Serversystem der Produktreihe M50CYP1UR |
CPU |
2x Intel® Xeon® Gold 6338N Prozessor, 2,2 GHz, 32 Kerne |
BIOS, Microcode |
SE5C6200.86B.0020.P24.2104020811, 04/02/2021, 0xd0002c1 |
Speicher |
16x 32GB DDR4 |
Festplatte |
Intel® SSD DC S4600 der Produktreihe SSDSC2KG96(960GB) |
Netzwerkkarte |
4x Intel® Ethernet-Netzwerkadapter E810 -2CQDA2 (früher Chapman Beach genannt) |
Software | |
Host-Betriebssystem |
Red Hat Enterprise Linux 8.2 (Ootpa) |
vBNG |
vBNG 20.11 |
Linux-Container |
Docker-Version 20.10.5, Build 55c4c88 |
DPDK |
DPDK-v20.11 |
BIOS-Einstellungen |
P-Zustand deaktiviert, Intel® Hyper-Threading-Technik aktiviert, Enhanced Intel SpeedStep® Technik deaktiviert, Intel® Turbo Boost-Technik deaktiviert, C-Zustände deaktiviert, SRIOV und VTd aktiviert |
Anwendungskonfiguration pro Instanz
Uplink | |
---|---|
Framegröße: 650B*; Abonnenten: 4K/Instanz; 1x vCPU pro Instanz | |
ACL |
SE5C6200.86B.0020.P24.2104020811, 04/02/2021, 0xd0002c1 |
Flow-Klassifizierung |
16x 32GB DDR4 |
Policer/Metering |
Intel® SSD DC S4600 der Produktreihe SSDSC2KG96(960GB) |
Routing |
|
Downlink | |
Framegröße: 504B*; Abonnenten: 4K/Instanz; 2x vCPU pro Instanz | |
ACL |
Reverse Path Forwarding – eine Regel pro Teilnehmer (4k) |
HQoS |
4 Level HQoS - Port, Pipe, Verkehrsklasse und Warteschlange |
Routing |
Eine Route pro Teilnehmer (4K) |
*Die angegebene Bildgröße ist die maximale Größe des Bildes zu einem beliebigen Zeitpunkt der Verarbeitung. (z. B. Uplink 128 Byte = 120 Byte +{2x4Byte access vlan tags}) | |
Informationen zur Konfiguration der Testumgebung und relevante Variablen | |
Datenverkehrs-Generator |
IXIA* NOVUS* 100GE8Q28 |
Verbindungsdetails |
Ixia-Ports und DUT-Ports sind Back-to-Back verbunden (acht Verbindungen) |