Summary

  • Le projet IETF du 31 octobre 2026, cosigné par Wesley Eddy, place deux relais TIPTOP sur un trajet spatial de démonstration; au moins cinq autres nœuds conservent une pile IP ordinaire.
  • Un relais peut stocker des paquets quand la liaison est coupée et qu'aucune autre route n'existe. La file a une limite, donc une politique d'abandon. Après l'attente, un itinéraire imposé auparavant peut être périmé.

La liaison revient; que reste-t-il dans la file ?

Le délai radio entre la Terre et Mars varie de quatre à 24 minutes dans le texte original de l'IETF. La rotation et les conjonctions ajoutent des coupures. Une réponse prend longtemps; une occasion d'émettre peut aussi manquer complètement. Eddy, Marc Blanchet et Tony Li proposent alors de laisser certains paquets attendre dans un relais jusqu'au prochain contact, parfois des heures ou des jours.

L'astuce ne consiste pas à réinventer l'en-tête IP. Le champ TTL d'IPv4 fonctionne en pratique comme un compteur de sauts; IPv6 le nomme ainsi. Une longue attente en mémoire ne le consomme pas. Le changement opérationnel se trouve dans le relais qui borde la liaison intermittente. Si son interface est arrêtée et qu'aucun autre chemin ne mène à la destination, il peut garder le paquet et l'expédier lorsque la route reparaît.

Cette réserve n'est pas infinie. Le projet décrit une file profonde avec une capacité et une règle d'abandon configurées. À saturation, le relais choisit quels paquets jeter selon la classe de trafic, les adresses ou d'autres champs. Un redémarrage ou une corruption de mémoire peut vider la réserve. Le transport fiable de bout en bout traite la récupération; le relais, lui, peut rester en service au mieux. Voilà un choix de priorité que le responsable de la mission doit écrire avant la première file pleine.

Dans le schéma du projet, deux hôtes adaptés encadrent deux relais TIPTOP. Le centre de mission, le réseau du fournisseur et le véhicule traversent aussi au moins cinq nœuds IP ordinaires. Un orchestrateur prépare les antennes, les modems et les routes pour chaque fenêtre de contact. La spécialisation se concentre à quelques points de passage; c'est là que les limites de stockage et la décision de jeter deviennent visibles.

Un plan de route a aussi une date

Les protocoles habituels vérifient périodiquement que leur voisin répond. Sur une liaison très lente ou coupée, cette conversation tourne à vide. Le projet préfère un contrôleur et des routes programmées à partir des contacts prévus. BGP peut relier les domaines, tandis qu'un domaine traversant la coupure doit annoncer par procuration les préfixes de l'autre côté.

Une route explicite pose un dernier piège. Le paquet arrive à son relais, attend, puis retrouve un ciel différent. Le reste du chemin prévu peut avoir cessé d'exister. Ajouter une route de secours dans chaque paquet gaspillerait une bande passante déjà rare. Les auteurs confient plutôt au relais le calcul de la suite. La décision de transmettre survit à l'attente seulement si le relais peut la refaire.

Le projet ne contient aucun journal d'un relais TIPTOP déployé; les horaires de contact, la taille de file, les pertes et les recalculs diraient combien de paquets ont effectivement été livrés.

Source originale