Zusammenfassung

  • Der RTGWG-Entwurf vom 28. Oktober, Revision 35 schlägt eine private BGP-Instanz für mobile Luftfahrtziele vor. Randrouter melden aktive Ziele an wenige Kernrouter und erhalten keine vollständigen BGP-Updates zurück. Fortlaufende BGP-Sitzungen laufen über gesicherte Bodenlinks, nicht über knappe Funkverbindungen zum Flugzeug.
  • Ein Kernrouter kann eBGP sowohl im Luftfahrt-Overlay als auch im darunterliegenden INET betreiben. Der Entwurf fordert getrennte lokale AS-Identitäten und Routing-Policy oder isolierte BGP-Instanzen, damit Routen nicht zwischen den Bereichen wandern. Die Bezeichnung „Overlay“ ist noch kein Exportfilter.

Eine Bewegung, aber kein Rundschreiben an alle

Wenn ein Flugzeug eine neue Bodenstation erreicht, muss die Gegenstelle den Weg dorthin kennen. Der ATN/IPS-Arbeitsentwurf hält solche Änderungen in einem Luftfahrt-Overlay. BGP-Sprecher stehen am Boden und verbinden sich über geschützte, gut angebundene Links. Die Funkstrecke kann langsam sein oder ausfallen; der Entwurf verbietet fortlaufendes BGP-Peering über gering leistungsfähige Luftfahrtverbindungen. Ein Funkkanal, der die eigentliche Kommunikation tragen soll, braucht nicht zusätzlich den gesamten Kontrollverkehr des Bodennetzes.

Die Aufgaben am Boden sind ungleich verteilt. Ein Stub-ASBR meldet die derzeit aktiven mobilen Präfixe und Adressen seines Bereichs an wenige Core-ASBRs. Vom Kern erhält er keine BGP-Updates; für unbekannte Ziele nutzt er Default-Routen zum Kern. Core-ASBRs tauschen innerhalb ihrer Partition die vollständige Tabelle aktiver Ziele aus. Wechselt ein Flugzeug innerhalb eines Stub-Bereichs die Funkzelle, kann die Bewegung dort verarbeitet werden. Erst beim Wechsel in einen anderen Stub-Bereich ändert sich der Sprecher für das mobile Ziel. Jeder Router hält so nur den Teil der Karte, den seine Aufgabe verlangt.

Das Verfahren baut auf BGP-4 auf und verlangt kein neues BGP-Nachrichtenformat. Stub und Kern peeren über geschützte Direktverbindungen oder sichere Tunnel. Auch Kernverbindungen brauchen Schutz. BFD nach RFC 5880 kann einen Ausfall schneller erkennen als konservative BGP-Timer. Ein schneller Wechsel ist wertvoll, sofern der Ersatzpfad nicht aus Versehen in einer anderen Routing-Domäne landet.

Der Kernrouter hat einen zweiten Arbeitgeber

Ein Core-ASBR kann in ATN/IPS eBGP sprechen und gleichzeitig eBGP im darunterliegenden INET betreiben. Eine Luftfahrtroute wird über Routen dieses Unterbaus aufgelöst. Derselbe Router kennt also beide Tabellen. Deshalb nennt der Entwurf getrennte lokale AS-Nummern und Routing-Policy oder getrennte BGP-Instanzen als Mittel, um die gegenseitige Weitergabe von Routen zu verhindern.

Das INET im Entwurf ist nicht zwingend die globale öffentliche Internet-Tabelle. Es kann ein Providernetz sein. Die Trennung bleibt zwingend für den Zweck des Entwurfs. Taucht ein mobiles Ziel im Unterbau auf, wird ein Bereich mit anderen Teilnehmern und Regeln zum Adressaten einer internen Änderung. Gelangen umgekehrt zu viele Unterbau-Routen in das Overlay, verändert sich die Grundlage für Entscheidungen der Luftfahrtseite. Eine Architekturzeichnung zeigt die Nahtstelle; die laufende Konfiguration entscheidet, ob sie dicht ist. Peer-Gruppen, AS-Werte, Import- und Export-Filter müssen denselben Strich ziehen wie das Diagramm.

Bei sehr großen mobilen Populationen sieht der Entwurf eine weitere Aufteilung vor. BGP trägt dann nur noch die Adressen der ASBRs; ein DNS-basiertes Verzeichnis ordnet einen mobilen Teilnehmer dem zuständigen Stub-ASBR zu. Nach einem Wechsel ersetzt der neue Stub den alten Eintrag. RFC 1035 liefert die DNS-Grundlage; der Entwurf beschreibt dafür eine Reverse-Zone. Damit wandert Last von der BGP-Tabelle zum Verzeichnis. Ein korrekter Weg zum alten Stub hilft dem Flugzeug nicht, wenn die Zuordnung nach einem Wechsel stehen geblieben ist.

Der Text beschreibt zudem kürzere Wege als den Grundpfad über einen Spannbaum. Sein Sicherheitsabschnitt unterscheidet geschützte Steuerung von Daten auf optimierten Wegen und verlangt dort Ende-zu-Ende-Schutz auf höherer Schicht. Stub-Router sollen den Verkehr zu schwachen Funkstrecken begrenzen. Eine elegante Bodenroute verliert ihren Wert, wenn sie am letzten Funkabschnitt mehr ausliefert, als dieser tragen kann.

Laut offiziellem Datatracker ist Revision 35 ein aktiver Arbeitsgruppenentwurf mit dem Ziel eines informativen Dokuments. Emulationen und Skalierungsrechnungen im Text sind Entwurfsdaten, keine gemessene weltweite Produktionslast. Für eine Aussage über die tatsächliche Trennung bei einem benannten Betreiber fehlen dessen Konfiguration und Routenexport-Trace. Schon jetzt steht fest, welche Entscheidung eine Implementierung braucht: Welche Route darf den BGP-Bereich verlassen, in dem sie entstanden ist?

Amtliche Originalquellen