Communiquer au-delà des limites terrestres
Alors que nos satellites et sondes spatiales s'aventurent toujours plus loin dans le système solaire, une uqestion fondamentale se pose, comment maintenir des communications fiables avec des appareils et infrastructures spatials situés à des centaines de millions de killomètres ?
Les protocoles Internet classiques, conçus pour des échanges quasi-instantanés, s'avèrent totalement inadaptés lorsque la lumière elle-même met plusieurs minutes à parcourir la distance entre deux nœuds. Cette contrainte physique a poussé les ingénieurs à repenser entièrement l'architecture des communications spatiales.
Le résultat ? Le Delay Tolerant Networking (DTN), un système capable de fonctionner malgré des latences extrêmes, des interruptions fréquentes et des connexions intermittentes. Cet article propose une petite analyse technique des mécanismes du Deep Space Networking, en analysant le fonctionnement du Bundle Protocol et de la couche de convergence TCP.
Dans l'immensité de l'espace, les communications ne suivent pas les règles habituelles d'Internet. Les signaux mettent plusieurs minutes, voire des heures, à parcourir les distances qui séparent la Terre des sondes spatiales. Pour relever ce défi, les ingénieurs ont développé une architecture réseau particulière, le DTN, ou Delay Tolerant Networking.
Une architecture conçue pour la latence
Le DTN désigne un réseau d'informations capable de supporter des latences de plusieurs minutes et de fonctionner sur de très longues distances. Contrairement aux protocoles Internet traditionnels qui nécessitent des connexions continues, cette technologie adopte une approche dite de "store-and-forward", chaque nœud du réseau stocke les données jusqu'à ce que le nœud suivant devienne disponible.
Dans l'exemple qu'on va voir plus bas, un hôte A envoie un paquet segmenté à un hôte B, qui le relaie ensuite vers un hôte C.
Cette chaîne de transmission permet de contourner les interruptions de communication fréquentes dans l'environnement spatial.
L'annonce d'identité, première étape du dialogue
Avant tout transfert de données, les nœuds du réseau doivent s'identifier.
Si on sélectionne l'un des paquet UDP encadré en rouge, on voit dans la section data , un hôte qui annonce son DTN endpoint id.
Donc, l'hôte 10.0.0.1 annonce que son endpoint id est n1 (comme s'il annonçait son nom sur le réseau).
Cette phase ne constitue pas encore un transfert de données à proprement parler. Il s'agit simplement d'une annonce d'identité, une présentation préalable qui permettra aux futurs échanges de s'effectuer de manière ciblée et efficace.
Au-delà des annonces d'identité, le réseau révèle sa structure à travers d'autres types de paquets. Les paquets TCPCL (TCP Convergence Layer) constituent des indicateurs précieux, même lorsqu'ils ne transportent aucune donnée.
Ces paquets de maintien de connexion, bien que simples, remplissent une fonction essentielle, ils maintiennent les liens actifs entre les nœuds malgré l'absence de trafic de données.
En envoyant périodiquement ces signaux de présence, chaque hôte sollicite une réponse de son interlocuteur, confirmant ainsi que la connexion demeure opérationnelle.
L'analyse de ces seuls paquets KEEPALIVE permet déjà d'esquisser la topologie du réseau. En observant qui échange des signaux de maintien avec qui, il devient possible de se faire une idée générale de quels hôtes peuvent voir les autres. Chaque paquet KEEPALIVE envoyé et reçu trace une ligne de visibilité dans l'architecture du réseau spatial, révélant les connexions directes entre les différents nœuds avant même qu'un quelconque transfert de données n'ait lieu.
On voit que l'hôte 10.0.0.3 envoie un KEEPALIVE à l'hôte 10.0.0.4 etc... (on peut voir un peu plus bas des paquet ACK pour les KEEPALIVE)
N° |
Source |
Destination |
7 |
10.0.0.3 |
10.0.0.4 |
8 |
10.0.0.1 |
10.0.0.3 |
9 |
10.0.0.3 |
10.0.0.1 |
19 |
10.0.0.2 |
10.0.0.4 |
20 |
10.0.0.2 |
10.0.0.1 |
21 |
10.0.0.1 |
10.0.0.2 |
Cette cartographie fait apparaître des zones d'ombre significatives l'hôte 10.0.0.1 n'envoie pas de KEEPALIVE à 10.0.0.4, et inversement. Le même phénomène s'observe entre 10.0.0.3 et 10.0.0.2.
Ces absences de communication ne sont pas anodines. Elles suggèrent la présence d'obstacles entre certains nœuds, comme une planète dont la masse bloquerait les transmissions directes.
Dans l'environnement spatial, la ligne de vue constitue souvent la condition essentielle d'un échange réussi, deux hôtes séparés par un corps céleste ne peuvent simplement pas se voir, et donc pas communiquer directement.
De retour dans Wireshark, l'analyse se concentre désormais sur le moment où les données commencent réellement à transiter. Un premier paquet se distingue par une longueur nettement supérieure aux précédents, donc il y a probablement de la data à l'intérieur.
BUNDLE over TCP
Le Bundle Protocol ne constitue pas un protocole de transport, mais bien une couche applicative. Cette distinction est fondamentale, d'autres applications peuvent s'appuyer sur lui pour fonctionner dans l'environnement spatial.
Disons qu'on veut créer un service SFTP ou FTP dans l'espace à travers la galaxie, c'est possible. L'utilisateur taperait ses commandes FTP habituelles, mais ces commandes transiteraient par le Bundle Protocol pour acheminer les données.
Le terme "bundle" se traduit littéralement par "ensemble" ou "paquet". Il désigne une unité de données encapsulée, conçue pour être transférée d'un point à un autre du réseau.
Ce bundle peut contenir des natures de données très variées mesures scientifiques collectées par des instruments, images capturées par des caméras embarquées, vidéos, ou tout autre type d'information nécessitant un acheminement fiable malgré les contraintes de l'espace profond.
On va définir bundle comme = un ensemble. Ce bundle a besoin d'être transféré, il pourrait contenir, des données scientifique, de l'image ou de la vidéo etc...
À l'intérieur d'un bundle, on retrouve différents segments de bundle, comme l'illustre le schéma ci-dessous.
Chaque segment constitue une portion du bundle original, facilitant ainsi sa transmission progressive à travers le réseau.
Dans le cas observé, le bundle en cours de transfert depuis le premier hôte vers le relayeur a été divisé en quatre segments distincts. Si l'un des segments échoue ou subit une corruption durant le transit, seule cette portion devra être retransmise, plutôt que l'intégralité du bundle. Cette granularité améliore considérablement l'efficacité du transfert dans un environnement où chaque bit transmis représente un investissement en temps et en énergie.
Ces segments de bundle contiennent eux-mêmes des segments TCP. Cette structure en poupées russes révèle l'architecture multicouche du système le Bundle Protocol opère au niveau applicatif, tandis que TCP assure le transport.
Cette double segmentation permet de conjuguer les avantages de chaque protocole. TCP gère la fiabilité du transport immédiat entre deux nœuds adjacents, tandis que le Bundle Protocol orchestre le cheminement global des données à travers l'ensemble du réseau spatial, même lorsque les connexions sont intermittentes ou retardées de plusieurs minutes.
Une segmentation non alignée
Un aspect crucial mérite d'être souligné, un segment TCP peut contenir simultanément des données provenant du segment de bundle A et des données provenant du segment de bundle B.
Cette absence d'alignement strict entre les couches reflète la flexibilité du système.
TCP fragmente les données selon ses propres contraintes de taille de paquet, sans se préoccuper des délimitations logiques établies par le Bundle Protocol au niveau supérieur.
Typiquement dans le 6e segment TCP on pourrait voir un header, indiquant qu'un nouveau bundle arrive bientôt.
Dans la frame 14 on peut voir que les frames #11, #13, et #14 on été sollicité pour créer ce bundle, les valeurs dans les parenthèses indique la quantité de données contenue dans ce segment de bundle.
Chaque frame contient une portion des données nécessaires à la constitution du bundle complet. Les valeurs inscrites entre parenthèses indiquent la quantité de données contenue dans chaque segment de bundle. Ces métadonnées permettent au système récepteur de vérifier l'intégrité du transfert en connaissant précisément combien d'octets chaque frame est censée apporter, le nœud peut s'assurer qu'aucune donnée n'a été perdue ou corrompue durant la transmission.
Cette comptabilité rigoureuse constitue un garde-fou essentiel dans un environnement où les erreurs de transmission peuvent survenir à tout moment, et où redemander des données implique d'attendre plusieurs minutes supplémentaires.
Afin de simplifier la lecture et l'analyse des captures réseau, deux nouvelles données vont être ajoutées aux colonnes de Wireshark. Mais avant de procéder à cette personnalisation de l'interface, il convient de comprendre en détail chaque champ contenu dans la zone "TCP Convergence Layer".
- La partie encadrée en rouge correspond au TCP Convergence Header. Il convient de noter que cette en-tête contient davantage de champs que dans les simples paquets TCPCL KEEPALIVE observés précédemment.
- La partie en
vert identifie le champ de type de paquet. Dans ce cas précis, il s'agit de données (data), signalant que ce segment transporte une charge utile plutôt qu'un message de contrôle.
- Dans la partie en
rose il y a un bit qui indiquerait si c'est le début du bundle
- Concernant la partie en
bleu c'est l'inverse, il y a un bit qui indiquerait si c'est la fin dubundle
- Et enfin la partie
jaune indique la taille du tcp bundle segment.
On va vouloir ajouter une column pour :
- le type de paquet (
VERT)
- Début du bundle (
ROSE)
- Fin du bundle (
BLEU)
On pourra donc identifier plus facilement les début et fin de bundle. un élément cependant ressort, on remarque qu'a la frame N°49 les valeurs qui indique le début ou la fin d'un bundle sont toutes les deux a TRUE, c'est son propre bundle.
Il sert de rapport, en disant a l'hôte 10.0.0.1 "j'ai bien livré le bundle"
L'analyse des captures réseau révèle ainsi certaines mécaniques du Deep Space Networking.
Un détail intéressant apparaît à la frame n°49 les marqueurs de début et de fin sont tous les deux à TRUE. Cela signifie qu'il s'agit d'un bundle complet qui tient dans un seul segment.
En d'autre termes, il s'agit d'un accusé de réception, adapté aux délais de plusieurs minutes caractéristiques de ces réseaux.
De la théorie du DTN aux captures réseau concrètes, on voit comment ces systèmes fonctionnent réellement. Chaque paquet KEEPALIVE maintient les connexions, chaque segment de bundle transporte sa part de données, et chaque bit de contrôle assure que rien ne se perde en route.
Dans un environnement où même la lumière met du temps à voyager, ces protocoles permettent de maintenir des communications fiables avec des sondes à des millions de kilomètres.
Ressource intéressantes :