Résumé

  • Le projet de travail RTGWG du 28 octobre, version 35 propose un réseau BGP privé pour suivre des terminaux aéronautiques mobiles. Les routeurs de bordure périphériques annoncent leurs destinations actives à un petit noyau, sans recevoir en retour la table complète. Les sessions BGP continues restent sur des liens terrestres sécurisés, loin des liaisons radio contraintes.
  • Un routeur du noyau peut parler eBGP à la fois dans ce réseau logique et dans le réseau sous-jacent. Le texte demande des AS locaux distincts et une politique de routage, ou des instances BGP séparées, afin que les annonces ne traversent pas cette frontière. Le dessin de deux réseaux ne remplace pas le filtre qui les sépare.

Le mouvement n’a pas besoin d’une audience mondiale

À chaque changement de zone radio, quelqu’un au sol doit savoir où joindre l’avion. Le projet ATN/IPS organise cette information dans un réseau logique propre aux communications aéronautiques. Il tient la conversation BGP continue sur le domaine terrestre bien connecté et sécurisé. Le lien radio reste un moyen d’atteindre l’appareil; il n’est pas le lieu où des voisins BGP échangent indéfiniment des tables. Le texte rappelle que ces liaisons peuvent être lentes, intermittentes et perturbées. Leur imposer le bavardage du routage serait une drôle de manière de protéger la communication qu’elles transportent.

L’architecture repose sur deux niveaux de routeurs de bordure. Les routeurs de périphérie annoncent au noyau les préfixes et adresses mobiles actifs chez eux. Ils reçoivent en retour des routes par défaut vers le noyau, sans mises à jour BGP du noyau. Les routeurs centraux échangent, au sein de leur partition, la table complète des destinations actives. Un déplacement à l’intérieur d’un même domaine périphérique peut rester local; le passage à un autre domaine change l’annonce qui désigne le point de rattachement. Le partage de l’information suit ainsi le besoin de chaque poste, plutôt que l’habitude de tout recopier partout.

Le projet n’exige pas un nouveau format de message BGP. Il emploie la mécanique de BGP-4 dans une topologie soigneusement bornée. Les liaisons périphérie-noyau sont des connexions directes protégées ou des tunnels sécurisés; les liaisons entre routeurs centraux demandent aussi une protection. BFD, défini par la RFC 5880, peut accélérer la détection de panne. La rapidité n’aide que si la route de remplacement appartient encore au bon domaine.

Un même boîtier, deux politiques

Le routeur central est le personnage le plus intéressant de cette histoire. Il peut tenir une session eBGP pour ATN/IPS et une autre pour l’INET qui sert de réseau sous-jacent. Les routes aéronautiques se résolvent à travers des routes de cet INET. Le routeur voit donc les deux univers. Le projet exige des AS locaux distincts et des politiques de routage, ou des instances BGP isolées, pour éviter que les routes passent de l’un à l’autre.

Il faut être précis sur le mot INET. Il désigne ici un réseau sous-jacent; ce n’est pas nécessairement la table publique mondiale. La fuite d’une annonce mobile vers ce réseau resterait une faute de séparation. Dans le sens inverse, un import trop large pourrait faire entrer dans le contrôle aéronautique un état qu’il n’était pas censé suivre. L’architecture indique où poser la frontière; l’opérateur doit encore écrire la politique d’import et d’export, attribuer les AS et tester ce que son routeur fait réellement. Le mot « privé » sur une diapositive ne bloque aucune route.

Une seconde variante déplace une partie de la charge de BGP vers un répertoire DNS. BGP ne porte alors que les adresses des routeurs de bordure; le répertoire associe un terminal mobile au routeur périphérique qui le sert. Quand le terminal change de domaine, le nouveau routeur remplace l’ancien enregistrement. La RFC 1035 donne la base du DNS; le projet décrit son usage dans une zone inverse. On gagne une table BGP moins liée au nombre de terminaux. On donne aussi à la fraîcheur de la correspondance un poids opérationnel: la meilleure route vers un routeur ne sert à rien si le répertoire désigne le mauvais routeur.

Le projet prévoit des raccourcis qui évitent certains détours de la topologie par défaut. Sa section sécurité distingue alors les chemins de contrôle protégés et les données sur un chemin optimisé, pour lesquelles elle demande une protection de bout en bout. Elle recommande aussi une limitation du trafic envoyé vers les liaisons radio à faible débit. Voilà deux endroits où une route correcte sur le papier peut encore produire un service médiocre dans l’avion.

La fiche officielle du Datatracker classe la version 35 comme projet actif du groupe de travail, à vocation informative. Les simulations et calculs de charge du texte sont des éléments de conception, pas une trace de trafic aérien mondial en production. Il manque une configuration et une trace d’export officielles d’un déploiement nommé pour juger son résultat. La responsabilité décrite par le projet, elle, est déjà concrète: lorsqu’un routeur porte deux domaines BGP, quelqu’un doit décider quelles routes ont le droit de franchir la porte.

Textes officiels