Zusammenfassung

  • RFC 3077 ließ den Satelliten-Feed physisch unidirektional und simulierte mit Tunneln zwischen bidirektionalen IP-Schnittstellen den Sicherungsschichtverkehr, den Empfänger nicht über den Broadcast-Kanal senden konnten.
  • Die ebenfalls einseitigen DTCP-Ankündigungen halfen, Feeds zu entdecken und veraltete Tunnelendpunkte zu entfernen. Sie authentifizierten keinen Feed, wählten keine allgemein beste Route und belegten keine Zustellung an die Anwendung.

RFC 3077 erschien im März 2001 und behandelt ein physisches Problem: Zwei Geräte können über ihren gemeinsamen Broadcast-Link kein Gespräch in beide Richtungen führen. Ein Feed sendet über die unidirektionale Verbindung; ein Empfänger kann nur zuhören. Ein reiner Sendefeed kann seinerseits über diese Schnittstelle nichts empfangen. Viele Internetprotokolle setzen jedoch Links voraus, die Pakete in beiden Richtungen transportieren: Ein Router sendet an den nächsten Hop und erwartet Antworten oder Routing-Updates.

Die Lösung bestand nicht darin, den Satellitenempfänger zum Sender zu machen. Sowohl Empfänger als auch Feed brauchten zusätzlich eine normale bidirektionale Schnittstelle mit IP-Anbindung. Wollte ein Empfänger einen Sicherungsschicht-Frame an einen Feed senden, kapselte er ihn ein und transportierte ihn durch einen Tunnel zur Internetadresse des Feeds. Dieser entkapselte den Frame und übergab ihn an die Schnittstelle zur unidirektionalen Verbindung. Der Satelliten-Broadcast blieb der Downlink; der Tunnel stellte den Rückweg zwischen ausgewählten Knoten bereit.

Warum die Sicherungsschicht nachbilden, statt lediglich ein neues IP-Netz zu bauen? So konnten bestehende Protokolle höherer Schichten die Verbindung nutzen, ohne die Satellitenphysik kennen zu müssen. RFC 3077 beschreibt sechs Kommunikationsfälle eines bidirektionalen Broadcast-Netzes. Die Übertragung vom Feed zum Empfänger – Fall sechs – funktionierte bereits über das physische Medium. Die Tunnel sollten die übrigen fünf Fälle ermöglichen: Empfänger-zu-Feed, Empfänger-zu-Empfänger sowie Broadcast- und Multicast-Verkehr. Dadurch konnten etwa ARP und Routing zwischen direkt verbundenen Nachbarn an ihrer gewohnten Stelle im Stack bleiben.

Der physische Link erhielt dadurch aber keinen Rücksender.

Als Träger empfiehlt das Dokument Generic Routing Encapsulation (GRE), um unterschiedliche innere Pakete über IP zu transportieren. Im beschriebenen Format erreicht ein äußeres IP-Paket die bidirektionale Adresse des Feeds; der GRE-Header kennzeichnet das Sicherungsschichtprotokoll des Einweg-Links, und die Nutzlast enthält den ursprünglichen MAC-Frame. Andere Tunneltypen sind möglich, wenn beide Seiten deren Bedeutung vereinbaren. RFC 3077 passt den Tunnel an die Sicherungsschicht an, macht GRE aber nicht zu einem Autorisierungs- oder Sicherheitsmechanismus.

Weniger offensichtlich ist, wie der Empfänger den richtigen Feed für den Tunnel findet. Das Dynamic Tunnel Configuration Protocol (DTCP) nutzt dafür nicht den Internet-Rückweg. Seine HELLO-Nachrichten laufen von den Feeds über die unidirektionale Verbindung zu den Empfängern. JOIN kündigt einen aktiven Feed an; LEAVE kann dessen Abschaltung melden. HELLO enthält außerdem ein Intervall, einen Sequenzwert, den Tunneltyp und eine oder mehrere bidirektionale IP-Adressen des Feeds (FBIPs). Empfänger hören die DTCP-Multicast-Ankündigung ab und führen eine Liste aktiver Feeds mit Tunnelendpunkten und Zeitgebern.

Ein LEAVE erlaubt die sofortige Entfernung eines Eintrags. Bleiben HELLO-Nachrichten aus, läuft er schließlich ab. Das Signal hat eine klare Grenze: Der Feed kann ausgefallen sein oder der Einweg-Link selbst. In beiden Fällen lässt sich die bidirektionale Erreichbarkeit über diesen Feed nicht mehr voraussetzen. Der Zeitgeber bestimmt, was der Empfänger nicht weiter versuchen sollte; er diagnostiziert weder die defekte Komponente noch belegt er die Zustellung eines Anwendungspakets.

Die Feed-Auswahl bleibt lokal. Jeder Empfänger wählt seinen eigenen Standard-Feed. Eine kürzere Round-Trip-Time nennt die RFC nur als Beispiel, nicht als gemeinsame Optimierungsregel. Ein Administrator kann einen anderen angekündigten Tunnelendpunkt bevorzugen, den er besser erreicht. Selbst die für den Betrieb benötigte MAC-Adresse des Feeds auf dem Einweg-Link (FUMAC) erhält in der RFC kein einheitliches Entdeckungsverfahren. Das Nachrichtenformat koordiniert den Austausch; die lokale Konfiguration entscheidet weiterhin, welcher Pfad nützlich ist.

Das Wort „bidirektional“ kann eine Kostenasymmetrie verdecken. Ein geostationärer Satellitenlink kann laut Beispiel rund 250 Millisekunden Einweg-Laufzeit hinzufügen; auch die Internet-Rückroute schwankt. RFC 3077 warnt, dass reaktive Adressauflösung wie ARP einen Feed auf eine Antwort warten lassen kann, während sich Pakete anstauen und schließlich Puffer erschöpfen oder Pakete verwerfen. Das ist ein von der Spezifikation beschriebener technischer Risikofall, kein Messwert eines benannten Dienstes. Die Pfade werden verbunden, aber nicht gleich in Laufzeit, Kapazität oder Zuständigkeit.

Fällt der Einweg-Link aus, müssen Empfänger ihre Tunnel deaktivieren. Andernfalls könnte ein Router weiterhin Pakete über den Tunnel empfangen und daraus fälschlich auf einen aktiven darunterliegenden Link schließen. Routingprotokolle wie RIP können den Zustand eines Nachbarn anhand empfangener Pakete beurteilen. Auch beim Ausfall eines Feeds soll unnötiger Tunnelverkehr enden. Ein entkapselter Frame ist nur ein Schritt in der Kette, kein Nachweis für eine stabile Route oder einen erfolgreichen Dienst.

Vertrauen gehört zu einer weiteren Schicht. RFC 3077 warnt vor ARP- und IP-Spoofing, durch das nicht autorisierte Knoten Zugang zum Dienst erhalten könnten. Die RFC nennt die Authentifizierung von Tunneln als Gegenmaßnahme, spezifiziert aber kein Verfahren. Routingprotokolle auf dem nachgebildeten Link müssen verfügbare eigene Authentifizierungsmechanismen einsetzen, damit nicht autorisierte Empfänger keine falschen Routen einspeisen. JOIN und die von DTCP angekündigten Endpunkte sind Meldungen, keine Zugangsdaten.

Die Spezifikation verspricht auch keine automatische Interoperabilität. Ein Einsatzprofil muss das MAC-Format und den Tunneltyp festlegen; bei einer Alternative zu GRE müssen sich beide Enden zusätzlich auf die Bedeutung dieses Typs einigen. Multicast-Routingkonfiguration und Skalierung bleiben außerhalb des Umfangs. RFC 3077 macht einen Einweg-Link nutzbar, indem er ihn mit einem Rücknetz zusammensetzt. Die unterschiedlichen Pfade werden dadurch weder einheitlich noch automatisch vertrauenswürdig.

Primärquellen