E.T. nach Hause telefonieren – mit IP

Mindestens bei solcher Echtzeitkommunikation ist dies für die meisten sehr eingängig. Zu große Latenzen oder hohe Jitter-Werte reduzieren die Nutzbarkeit der Anwendung deutlich, wenn das Gegenüber nicht mehr verstanden werden kann oder die Kommunikation einseitig wirkt. Dies ist auch ein Grund, warum diese Anwendungen abhängig von den Anforderungen UDP als Transportprotokoll nutzen. Im Extremfall können Latenzen, geringe Bandbreiten und ähnliches im Netzwerk auch dazu führen, dass eine Verbindung gar nicht zustande kommt.

Wenn wir einige dieser Probleme und Effekte bereits im Internet auf der Erde erleben können, wie problematisch muss diese Kommunikation dann erst sein, wenn IP-Verbindungen nicht nur terrestrisch gebunden stattfinden? Wenn also Kommunikation zu anderen Planeten, Satelliten und Raumfahrzeugen benötigt wird, entstehen solche Herausforderungen in ganz anderem Maße.

Mit der IP-Kommunikation im Weltall bzw. genauer mit der IP-Adress-Vergabe für Systeme im Weltraum haben wir uns bereits in einem Blog-Beitrag im März dieses Jahres (https://www.comconsult.com/ip-adressen-fuer-marsmaennchen/) befasst. Neben dieser Thematik gibt es aber auch RFC-Dokumente, welche die technischen Anforderungen an Kommunikation im Weltall genauer beleuchten. Tatsächlich wurde bereits vor 25 Jahren festgestellt, dass der IP-Stack nicht geeignet wäre für die Kommunikation im Weltall (RFC4838; https://datatracker.ietf.org/doc/html/rfc4838).

Während die Anforderungen an Kommunikationsverbindungen im Weltraum für die meisten irdischen Netzwerke nicht wirklich relevant erscheinen, geben sie dennoch einen interessanten Einblick in die möglichen Hürden und Tücken von IP-Kommunikation. Welche Probleme stellen sich nun, wenn E.T. tatsächlich nach Hause telefonieren möchte? Hierzu sei auf die entsprechenden Entwürfe bei der IETF (https://datatracker.ietf.org/doc/draft-ietf-tiptop-usecase/ und https://datatracker.ietf.org/doc/draft-many-tiptop-ip-architecture/) verwiesen. Auf einige der dort beschriebenen Punkte gehen wir im Folgenden kurz ein.

Problemstellung bei der Kommunikation im Weltall

Der Kommunikation in Sci-Fi-Universen, wie Star Wars oder Star Trek, ist unter anderem gemeinsam, dass diese unmittelbar stattfindet. Captain Picard kann direkt mit dem Headquarter der Sternenflotte sprechen, obwohl dieses Lichtjahre entfernt ist. In unserer Welt ist dies natürlich nicht so einfach. Solange wir also nicht die Subraum-Kommunikation gemeistert haben, müssen wir uns mit einigen Einschränkungen begnügen. Und diese Einschränkungen treffen nicht nur zu, wenn man Daten von einem an das andere Ende der Galaxie schicken möchte, sondern bereits bei vergleichsweise kleinen Entfernungen von wenigen Lichtminuten, z.B. bei den ca. 3 bis 22 Lichtminuten zwischen Erde und Mars.

Welche Charakteristika sind für die Netzwerkkommunikation im Weltall denn konkret zu benennen? Die IETF listet hierbei insbesondere die folgenden Aspekte:

• Begrenzte Rechen- und Energie-Ressourcen
• Verbindungsabbrüche und vordefinierte Übertragungsfenster, bspw. wenn Raumfahrzeuge oder Relay-Stationen im Orbit in Funkschatten anderer Himmelskörper geraten
• Asymmetrische Bandbreiten oder sogar „Einbahnstraßen“
• Lange und schwankende Übertragungsdauern

Es ist sicherlich klar, dass Raumfahrzeuge, welche völlig losgelöst von irdischer Infrastruktur unterwegs sind, energiesparend arbeiten müssen. Dies resultiert aufgrund entsprechender Energiesparmaßnahmen in einer Nicht-Verfügbarkeit durch geplante Downtime während des Flugs. Offene Kommunikationsbeziehungen müssen dies natürlich berücksichtigen. Timer dürfen in dieser Zeit nicht ablaufen und müssen sich der Situation anpassen.

Ähnliche Effekte ergeben sich dann, wenn Geräte über Relays kommunizieren müssen oder sich im Funkschatten eines Planeten befinden und damit die Erde nicht durchgehend erreichen können. Ebenso sind asymmetrische Bandbreiten oder sogar Verbindungen ohne Rückkanal denkbar. Übertragungsdauern schwanken und können ja nach Abstand zwischen der Erde und dem Raumfahrzeug oder dem Planeten durchaus sehr unterschiedlich ausfallen und sich deutlich ändern. Diese Schwankungen sind sicherlich deutlicher als im Internet der Erde.

Besondere Konstellationen, bei denen ein Verbindungsweg durch andere Himmelskörper blockiert wird, erschweren die Kommunikation. Steht zum Beispiel die Sonne zwischen Mars und Erde (ca. alle 26 Monate), führt dies üblicherweise zu einem Verbindungsverlust der direkten Verbindung von ca. zwei Wochen. Zwischen Erde und Jupiter läge eine vergleichbare Situation alle 13 Monate vor, und zwischen Erde und Saturn alle 12,4 Monate. Grundsätzlich würden daher für IP-Verbindungen Relay-Stationen im Weltall vorzusehen sein, die Daten weiterleiten und die Verbindung aufrechterhalten. Dies führt unweigerlich zu sehr unterschiedlichen und sich dynamisch verändernden Verbindungseigenschaften im Zeitverlauf.

Auswirkungen auf Kommunikationsprotokolle

Die oben beschriebenen Problemstellungen führen dazu, dass bestimmte Parameter bei der IP-Kommunikation im Weltraum beachtet werden müssten und dass bestimmte Protokolle besser geeignet sind als andere.

Für Netzwerke in räumlicher Nähe der Erde ist es durchaus möglich, die bestehenden IP-Protokolle mit geringen Anpassungen zu verwenden. Der Mond befindet sich in ca. 1,4 Lichtsekunden Entfernung, so dass die meisten Werte für Time-Outs etc. ohne größere Bedenken bestehen bleiben können. Wenn man allerdings die weitere Nachbarschaft betrachtet, trifft dies nicht unbedingt zu.

Ein Netzwerk besteht hierbei aus regulären Netzwerkknoten (z.B. auf der Erde), welche wie bisherige Netzwerktechnik funktionieren, und aus Geräten, die gezielt für die Kommunikation im Weltall vorgesehen sind. Diese werden von der IETF als „Taking IP To Other Planets (TIPTOP)“-Geräte bezeichnet. Letzteres teilt sich in Endgeräte, weiterleitende Geräte und „Full Nodes“, die beides kombinieren. Ergänzt wird dies um entsprechende Management-Systeme.

Einige der von der IETF beschriebenen Empfehlungen basieren auf bestehenden Vorgaben der Interagency Operations Advisory Group (IOAG – https://www.ioag.org/Public%20Documents/Lunar%20communications%20architecture%20study%20report%20FINAL%20v1.3.pdf). Grundlegende Layer-2-Verfahren sind dort definiert. Ebenso kann davon ausgegangen werden, dass auf einem Himmelskörper die gleichen Verfahren genutzt werden wie auf der Erde. Dies gilt auch für das Routing dort, da die herkömmlichen Mechanismen anwendbar sein werden.

Spannend wird hierbei dann aber die Verbindung zwischen den Himmelskörpern und an dieser Stelle die IP-Mechanismen. Routing-Protokolle und vergleichbare Grundfunktionen eines IP-Netzwerks sind üblicherweise auf zeitnahe Meldungen benachbarter Router angewiesen. Diese Algorithmen sind auf hohe Latenzen nicht ausgelegt und können deswegen im Netzwerk zwischen Planeten nicht angewendet werden. Hier müssen also alternative Lösungen genutzt werden.

Hinsichtlich des Routings muss auch berücksichtigt werden, dass bestimmte Wege über Orbitalstation und Relays nur zu bestimmten Zeiten genutzt werden können. Auch wenn die Bandbreitenbegrenzung es notwendig macht, dass Pfade explizit bestimmt werden müssten, widerspricht dies der Verfügbarkeit der Wege und liefert einen weiteren Grund dafür, dass herkömmliche Routing-Mechanismen nicht genutzt werden können.

Das Paketformat von IPv4 und IPv6 selber wird nicht geändert, da ansonsten Inkompatibilitäten zu bestehenden Systemen zu befürchten wären.

Grundsätzlich müssen Protokolle darauf ausgelegt sein, dass sie mit langen Laufzeiten, geringen Bandbreiten, hohen Paketverlustraten und Verbindungsausfällen über lange Zeiträume arbeiten können.

Daraus ergeben sich bereits Grundannahmen, wie die Anwendung eines Store-and-Forward-Prinzips. Datenpakete müssen über die nötigen Zeiträume zwischengespeichert werden. Dies gilt wegen der langen Zeitfenster auch über Neustarts, Konfigurationsänderungen etc. hinaus. Datenpakete, welche im Speicher sind, sollten nach einem Neustart weiterhin verfügbar sein. Warteschlangenmechanismen müssen ebenfalls die berechenbaren Verfügbarkeitszeitfenster der Verbindungen zur Auswahl der zu verwerfenden Pakete berücksichtigen. Die entsprechenden Mechanismen und Stacks müssen auf das Internet im All getunt sein.

Paketverluste können aufgrund der Laufzeiten erst nach erheblicher Zeit festgestellt werden. Klassische Protokoll-Timer müssen hierauf angepasst werden. Dies hat auch einen Einfluss auf Verfahren, bei denen verschiedene Netz-Knoten sich abstimmen. Diese konvergieren aufgrund der langen und sehr unterschiedlichen Laufzeiten eventuell nicht mehr und lassen sich daher nicht nutzen.

Während UDP als Transport-Schicht-Protokoll aufgrund der extremen Einfachheit sehr robust reagiert und daher ohne Anpassung nutzbar wäre, existieren bei TCP einige Parameter, welche an die Laufzeiten im Weltall angepasst werden müssen. Verbindungen sollten langlebig aufgebaut werden, um den zeitintensiven Drei-Wege-Handshake möglichst selten durchführen zu müssen. Bei Raumfahrzeugen wäre es sogar denkbar, für einige Systeme diesen Handshake bereits vor dem Start abzubilden und damit gänzlich zu vermeiden. Dies gilt folglich auch für Sicherheitsmechanismen mit Schlüsselaustausch, da diese weitere Latenzen hinzufügen würden.

Einige Funktionen, wie die Retransmissions bei TCP, scheinen das Effizienzziel einer Verbindung völlig zu verfehlen, da diese mit entsprechenden Time-Outs die Dauer für den Transport eines Pakets durchaus vervielfachen würden. Standard-Zeitfenster von z.B. einer Sekunde würden hier ohnehin nicht funktionieren. Das gilt für eine ganze Reihe von Timern, die in Netzwerkprotokollen, wie beispielsweise DNS, Anwendung finden. Grundsätzlich ist demnach festzustellen, dass jedwede Timer für die jeweilige Verbindung individuell gewählt sein müssen. Die meisten Protokolle sind also passend zu parametrisieren.

Spezielle Transportprotokolle, wie bspw. QUIC (RFC9000), bieten Mechanismen zum Zwischenspeichern der Schlüssel und Verbindungsinformationen. Ähnliches trifft analog für Mechanismen zu, bei denen Features während des Verbindungsaufbaus abgestimmt werden. Da QUIC auf UDP basiert, stellen sich viele der für TCP gültigen Bedenken hier nicht. Auf der anderen Seite implementiert QUIC aber ähnliche Grundfunktionen von TCP, wie beispielsweise Congestion Control. Darüber hinaus können mehrere Streams unmittelbar innerhalb QUIC übertragen werden, so dass Verbindungsauf- und -abbauten reduziert werden können. Bei Wahl und Konfiguration entsprechender Parameter kann QUIC unmittelbar eingesetzt werden. Dies stellt insbesondere eine Alternative zu HTTPS dar.

Neben diesem Ansatz wird ein gesondertes Space Communications Protocol Specification Transport Protocol (SCPS-TP) angeführt, welches bestehende TCP-Parameter anpasst. Dieses wurde bereits produktiv auf der Strecke Mars-Erde getestet.

Vorgenannte Überlegungen betreffen natürlich auch Protokolle auf Anwendungsebene. HTTP inklusive möglicher RESTful-HTTP-Funktionen müssen entsprechend angepasste Parameter und Timer verwenden. Fallabhängig kann QUIC in Frage kommen.

Neben den eigentlichen von Anwendungen verwendeten Kommunikationsprotokollen sind auch die Anbindung an Netzwerkdienste und Systeme, wie DNS zur Namensauflösung, zu betrachten. Es müssen entsprechende lokale DNS-Server mit Caching verfügbar sein, um Anfragen und Antworten in einem realistisch nutzbaren Zeitrahmen zu ermöglichen.

Ebenso müssen verschiedenste Anpassungen an Prozessen und Verfahren zur Sicherheit der IP-Kommunikation beachtet werden. Sicherheitszertifikate sind grundsätzlich rechtzeitig unter Berücksichtigung der Laufzeiten und möglicher Nicht-Verfügbarkeiten zu aktualisieren. Denial-of-Service-Angriffe auf das Netzwerk stellen ebenfalls eine besondere Herausforderung dar, da Puffer Daten über erhebliche Zeiträume zwischenspeichern müssen. Bereits an den Komponenten, welche das Netzwerk eines Planeten über interplanetare Verbindungen an andere Systeme anbinden, muss mit Hilfe entsprechender Firewall-Systeme der Datenverkehr gesichert und gefiltert werden.

Diese Punkte stellen nur einen Teil der Probleme dar, die sich bei verbindungsorientierter Kommunikation im Weltall ergeben. Man müsste also durchaus neue Protokolle entwickeln oder Parameter entsprechend anpassen.

Insgesamt stellt die IP-Kommunikation zwischen Himmelskörpern sicherlich ein Extrem dar, welches wir in terrestrischen Projekten in dieser deutlichen Ausprägung nicht erwarten. Es ist aber dennoch hinsichtlich der Anforderungen ein spannendes Gedankenspiel, bei dem man durchaus nachvollziehen kann, welche Schwierigkeiten und Herausforderungen relevant sind.

Quelle: Bilder sind KI-generiert, abgerufen am 15.07.2026