TCP PEP und QoS-Softwaremodule für das HTS-Satellitenkommunikationssystem
Kunde
Ein globaler Anbieter von Satellitentelekommunikationsgeräten.
Herausforderung
Der Kunde wandte sich an uns, um ein QoS-Modul zu entwickeln und das Transmission Control Protocol (TCP) durch einen Performance-Enhancing Proxy (PEP) zu implementieren, der eine optimale TCP-Leistung über geostationäre Satelliten ermöglicht.
Die große Entfernung der geostationären Umlaufbahn von der Erdoberfläche (etwa 36.000 km) führt zu einer erheblichen Signalverzögerung von etwa 0,5 Sekunden. In diesem Fall können TCP-Verbindungen innerhalb von VLAN-, GTP- und GRE-Tunneln liegen, die auf der entfernten Seite wiederhergestellt werden müssen.
Es kann vorkommen, dass identische TCP-Verbindungen (mit derselben Kombination aus IP-Adressen und TCP-Ports) in verschiedenen Tunneln vorhanden sind. Es muss sichergestellt werden, dass diese korrekt verarbeitet werden.
Die ungefähren Geschwindigkeitsanforderungen für die Software betragen 5 Gbit/s auf einem 4-Kern Intel Xeon Prozessor mit einer Basisfrequenz von 2 GHz.
Die nächste Phase unseres Projekts beinhaltete die Entwicklung eines leistungsstarken QoS-Softwaremoduls für Satelliten mit hohem Durchsatz (HTS). Die Hauptaufgaben dieser Phase bestanden darin, einen neuen QoS-Kernel für die ASAT-III PHS-Software zu entwickeln und den alten Kernel im ASAT-II QPS-Server zu ersetzen.
Die letzte Aufgabe war die Implementierung des entwickelten QoS-Systems mithilfe des CISCO CONFD-Toolkits in das Software Development Kit (SDK) des Kunden, basierend auf Intels Data Plane Development Kit (DPDK).
Bild 1: QoS-Modul in der allgemeinen SDK-Struktur des Kunden
Lösung
1. Konzeptentwicklung
Bei der Gestaltung der Architektur und des Entwicklungsplans für die zukünftige Software haben wir mögliche technische Probleme und Lösungen im Voraus berücksichtigt. Um zum Beispiel zu verhindern, dass sich TCP-Verbindungen aus verschiedenen VLANs und Tunneln innerhalb des leistungssteigernden Proxys kreuzen, müssten wir die IP-Adressen und TCP-Ports jeder TCP-Verbindung durch eine eindeutige Kombination ersetzen. Auf der Gegenseite würden diese Werte dann wieder durch die ursprünglichen ersetzt – nachdem der leistungssteigernde Proxy übergeben wurde. Falls erforderlich, würden wir die IP-Adressen, TCP-Ports sowie VLAN-, GRE- und GTP-Tunnel wiederherstellen.
Alle Informationen über die ursprünglichen IP- und TCP-Port-Werte, VLAN-, GTP- und GRE-Parameter sowie Tunnel werden während der TCP-Verbindungsherstellung durch den performance-steigernden Proxy übertragen.
2. Softwareentwicklung
Das Projekt bestand aus zwei Phasen: Zunächst entwickelten und prototypisierten wir die Software für das Transmission Control Protocol (TCP). In der zweiten Phase integrierten wir es in das SDK des Kunden.
Wir entwickelten die Software zur Implementierung von TCP auf Basis freier Software und überprüften sie auf die Einhaltung der grundlegenden Funktions- und Geschwindigkeitsanforderungen.
Der Software-Prototyp wurde auf der Grundlage der Linux eBPF-Technologie entwickelt.
Zusätzlich entwickelte unser Engineering-Team das grundlegende QoS-ASAT-II-Modul auf dem von unserem Kunden bereitgestellten Betriebssystem-Image. Der Linux 3.16.7 Kernel und die libnetfilter_queue 1.0.2 Bibliothek wurden als Hauptkomponenten zur Erstellung des Moduls verwendet, einschließlich benutzerdefinierter Einstellungen der Kernel-Lösung und der NetLink-Schnittstelle, die eine Leistungsoptimierung und erweiterte L2-Funktionen bieten. Der QoS-Kernel ASAT-II nutzte die iptables NFQUEUE-Dienstprogramme und die libnetfilter-Bibliothek zur Verarbeitung von Paketen in der User-Space-Anwendung.
In der zweiten Phase implementierten wir das QoS-System im SDK des Kunden unter Verwendung der DPDK-Technologie. Die Durchsatzrate des Systems erreicht ~1 Million Pakete pro Sekunde (pps).
Bild 2: Die grundlegende HTS QoS-Architektur
Bild 3: Beispiel einer QoS-Architektur
Geschäftswert
Die fertige Software wird in Kommunikationssystemen über geostationäre Satelliten eingesetzt.
