Les Réseaux DTN

Delay Tolerant Networks: Réseaux tolérants aux délais

III - Fonctionnement d'un DTN

Fonctionnement d'un DTN         (haut de page)

Les méthodes de store and forward sont utilisées dans la vie de tous les jours. On peut citer par exemple l'acheminement d'un courrier, d'un e-mail, d'un message vocal, etc. Pour cela, l’utilisation d’espace de stockage s’avère nécessaire.

Les espaces de stockage présent sur les nœuds réseaux conservent les données indéfiniment. Ils sont dits à stockage persistant, en opposition avec les mémoires à court terme. Les routeurs utilisés sur Internet sont basés sur des mémoires à court terme pour mettre en file d'attente les paquets entrants pendant la consultation de la table de routage et le transfert de ces données sur un port de sortie libre.

A l'inverse, les réseaux DTN utilisent des espaces de stockage plus importants (disque dur). En effet, pour les raisons ci-dessous, l'utilisation de stockage persistant est indispensable:

- Le lien de communication de la source vers la destination peut être indisponible pour une durée indéterminée
- Un nœud du réseau peut émettre ou recevoir des données plus rapidement ou de manière plus fiable que les autres nœuds du réseau.
- Un message transmis doit être retransmis en cas d'erreur sur le réseau ou si les informations ne sont pas acceptées pour être transférés.

Tout ou partie des données (en provenance d'une application) sont déplacés d'un espace de stockage d'un nœud du réseau vers l'espace de stockage du nœud suivant tout au long d'un chemin qui permettra éventuellement de joindre le destinataire.

Lors du transfert de données (ou d'une portion de ces données) depuis un nœud du réseau vers le suivant, la taille du message est annoncée de manière à réserver l'espace de stockage nécessaire et la bande passante pour le transfert.

Bundle Layer         (haut de page)

Les réseaux DTN mettent en œuvre les techniques « store and forward » de commutation de données en superposant au protocole existant une nouvelle couche protocolaire appelée couche bundle (bundle layer). La bundle layer permet de relier les spécificités des couches inférieures des différentes régions, ainsi une application peut communiquer à travers des réseaux de natures différentes.

Le protocole Bundle se situe entre la couche applicative et les couches spécifiques à chaque région. Dans le cas de TCP/IP, il se situe ainsi comme une couche supérieure à la couche transport.

La couche Bundle permet de stocker puis de transférer les messages (aussi appelés Bundle) entre les nœuds du réseau. Ainsi, un seul protocole est utilisé à travers l’ensemble du réseau qui constitue le DTN. Seuls les protocoles inférieurs sont alors spécifiques à l’environnement de communication de chaque région.

Le « bundle protocol » a la particularité de pouvoir fonctionner d'ores et déjà au dessus de plusieurs protocoles : des protocoles de transport comme UDP ou TCP, mais aussi de manière « brute » au-dessus d'Ethernet, ainsi que sur le protocole Bluetooth, ou encore directement par fichier interposé.

D'autres couches de convergence seront développées dans le futur, afin de fonctionner au-dessus de réseaux de capteurs, de réseaux très longue distance ou encore de réseaux destinés aux environnements « tactiques ». Ainsi la très attendue couche LTP (Licklider Transmission Protocol) se place comme le remplaçant de TCP dédié aux communications interplanétaires.

Cette variété permet d'utiliser la couche protocolaire sous-jacente la mieux adaptée aux caractéristiques de chacun des environnements de transmission, et surtout d'utiliser la couche bundle au-dessus de différents réseaux hétérogènes.

Les Bundles sont constitués de trois éléments :

  • Les données de l'application source
  • Des informations de contrôle et de traitement fourni par l’application source vers l’application destinatrice
  • Un entête Bundle, inséré par la couche Bundle. Cet entête peut être de taille variable et arbitrairement long.

Ils étendent ainsi le principe d’encapsulation utilisé dans le protocole TCP/IP ou le modèle OSI.

Nœud Réseau         (haut de page)

Dans un réseau DTN, un nœud est une entité possédant une couche Bundle. Il peut s’agir d’host, de routeur, de passerelle qui agissent en tant que source, destinataire ou d’élément de retransmission des messages asynchrones (bundle).

L’host émet ou reçoit les bundles. Il en est soit la source, soit le destinataire mais ne transfert pas les bundles. Il nécessite une capacité de stockage afin de conserver les bundles dont il est la source jusqu’à ce qu’un lien de communication du réseau DTN soit accessible.

Le routeur transfert les bundles au sein d’une seule région DTN. Il peut supporter de manière facultative le principe du custody transfer.

La passerelle transfert les bundles entre plusieurs régions DTN. Comme les hosts et les routeurs, ils disposent d’un espace de stockage. Il supporte également le concept du custody transfer. Enfin, les passerelles assurent la conversion des données des couches protocolaires inférieures. (source type TCP/IP, destination autre)

Les nœuds sont regroupés en région en fonction de leur technologie. Les passerelles entre régions fournissent des points de contrôle, des ressources en capacité de stockage et de retransmission, de transcodage, etc.

Routage DTN         (haut de page)

Le réseau DTN est un environnement de nature déconnecté du fait de ses caractéristiques. Différentes solutions permettent d’assurer un routage correct au sein des réseaux DTN.

  • Persistance des liens : contact en permanence, contact à la demande.
  • Connections programmées, mise en place d’une synchronisation temporelle sur l’ensemble du DTN
  • Connections opportunistes, en fonction des éléments présents dans l’environnement.

Afin de connaître le réseau, les nœuds DTN utilisent des vecteurs sommaires. Ceux-ci contiennent des éléments d’identification du nœud ainsi que leur localisation. Ils peuvent également communiquer des informations permettant de programmer leur prochaine communication. Ce peut être le cas par exemple pour des éléments dont le déplacement est régulier, tel les satellites. Ainsi, lors du passage suivant du satellite à portée du nœud, celui-ci pourra alors communiquer avec le satellite si besoin.

Custody Transfer         (haut de page)

Les réseaux DTN supportent la retransmission de données perdues ou corrompues que ce soit au niveau transport ou au niveau de la couche bundle. Néanmoins, les protocoles de transport ne pouvant assurer le contrôle de bout en bout à travers le réseau DTN, la fiabilité de celui-ci est assuré par la couche Bundle.

Le protocole Bundle possède la capacité de retransmettre des données en utilisant ce que l’on appelle le custody tranfer. Ces transferts sont convenus par les couches Bundles des différents nœuds réseaux rencontrés à travers le DTN.

Lorsqu’un nœud réseau doit transmettre un message à un autre nœud du réseau, celui-ci demande le transfert (custody transfer) afin d’envoyer le message considéré et met en place un délai de retransmission des données basé sur l’acquittement par le destinataire de ces données. Lorsque le nœud DTN accepte le transfert, il envoie un acquittement à l’émetteur l’informant que celui-ci a accepté le transfert du bundle et l’a reçu. Si aucun acquittement ne parvient à la source avant la fin du délai de retransmission, la source réémet le message en question.

Le délai de retransmission des données peut être déterminé pour chaque routeur selon les informations de routage DTN ou décidé localement en fonction de l’expérience que le nœud source possède avec le nœud destinataire.


Un nœud du réseau doit conserver les données à transmettre jusqu'à ce que celles-ci soient acquittés, ce qui veut dire que le nœud destinataire a accepté le transfert, ou bien jusqu’à ce que le TTL arrive à expiration, ce TTL étant supérieur au délai de retransmission.

Enfin, pour garantir la fiabilité de bout en bout, la source doit demander lors du transfert des données l’acquittement du transfert ainsi qu’un accusé de réception. Auquel cas, la source conserve les données jusqu’à ce qu’elle reçoive cet accusé.

Identifiant région, identifiant nœud de réseau.         (haut de page)

Un DTN est un réseau de réseaux dont chacun de ces réseaux est appelé régions. Au sein d’une même région, les spécificités sont homogènes. Chacune de ces régions possède un identifiant de région (region ID) qui est connu des autres régions DTN. Cet identifiant de région est notamment utilisé pour identifier un nœud réseau. Les passerelles DTN ont des membres dans 2 régions ou plus et sont les seules à pouvoir communiquer d’une région à une autre.

Le projet IPN a utilisé ce principe pour identifier les différentes régions de ce réseau inter planétaire. L’identifiant se déduit par la lecture d’une arborescence comme présenté dans l’exemple ci-dessous.

Nous trouvons donc les identifiants réseaux jupiter.sol.int, venus.sol.int, etc. Une donnée transmise depuis un élément du réseau jupiter.sol.int et dont la destination est localisée dans le réseau earth.sol.int devra être traitée par deux passerelles. La première afin de transcoder les données provenant de jupiter.sol.int vers le réseau backbone ipn.sol.int et la seconde afin d’acheminer ces données depuis le réseau backbone vers le réseau earth.sol.int.

Afin de pouvoir acheminer correctement les données, chaque nœud réseau se voit attribuer un identifiant. Celui-ci est composé de l’identifiant région vu précédemment et un identifiant d’entité. Le routage à travers différentes régions DTN se base uniquement sur l’identifiant région. En revanche, le routage interne à une région DTN utilise uniquement l’identifiant entité. Celui-ci correspond à l’adressage utilisable dans ce réseau. Par exemple, pour un réseau TCP/IP, l’identifiant entité aura pour valeur l’adresse IP ou le nom auquel cette adresse correspond.

Supposons qu’un nœud réseau se situant sur terre veuille communiquer avec un destinataire situé sur mars. Les identifiants étant par exemple :

Source : (earth.sol.int, source.fr)

Destinations : (mars.sol.int, jesuisunmartien.mar)

Le champ identifiant région de la source et de la destination étant différent, cette communication devra transiter par le réseau backbone. Dans un premier temps, les données seront donc transmises dans la région earth.sol.int afin d’atteindre une passerelle vers ce backbone. La passerelle va identifier dans l’identifiant la région destinatrice, en l’occurrence mars, et va s’appuyer sur le réseau backbone (ipn.sol.int) afin de joindre la passerelle en bordure de la région mars. Celle-ci constatera alors que les données sont à transmettre au sein de la région dont elle fait partie, elle utilisera donc la partie entité, ici définit arbitrairement comme étant jesuisunmartien.mar, afin de transmettre les données au bon destinataire. Cet exemple démontre ainsi l’utilisation des différentes parties de l’identifiant réseau lors d’un envoi de données entre deux régions différentes.

La vie d’un Bundle : de la création jusque la destination.         (haut de page)

Afin d’expliquer le traitement subi par les données à transmettre à travers le réseau, nous utiliserons l’exemple vu précédemment entre la planète terre et mars.

La première étape consiste à créer le message (ou Bundle) qui doit être envoyé. L’application source qui désire transmettre des informations demandent la création du Bundle. Il transmet un entête qui se compose de plusieurs parties. Les identifiants source (earth.sol.int, source.fr) et destination (mars.sol.int, jesuisunmartien.mar), des informations de qualité de service désiré, une signature qui permet de crypter les données et les données utilisateurs (comprenant les informations de traitement pour le destinataire). La couche Bundle de la machine source.fr vérifie la signature, crée ensuite le Bundle en ajoutant l’entête correspondant en y ajoutant sa propre signature et stocke celui-ci dans l’espace de stockage afin de l’envoyer sur le réseau.

La source transmet alors ce message vers la passerelle permettant de joindre la région backbone. En effet, la source s’appuie sur une table de routage qui lui indique que pour atteindre la région mars, il doit transférer les données vers le nœud (earth.sol.int, passrl1.com). Il connait également le moyen de communiquer avec cette passerelle, par exemple TCP/IP. La source transmet alors une copie du message à cette passerelle en s’appuyant sur TCP/IP. Un compteur de délai de retransmission est alors utilisé, la source attend alors un acquittement des données par la passerelle.

Lorsque la passerelle reçoit les données, elle vérifie dans un premier temps les droits alloués à la source contenu dans la signature ajouté par la couche bundle source. Si celle-ci possède les autorisations nécessaires, la couche Bundle de la passerelle remplace cette signature par sa propre signature et stocke le message dans son espace de stockage. La passerelle consulte alors sa table de routage interne et détermine que pour atteindre la destination, il doit transmettre les données vers (mars.sol.int, passrl2.mar). Il vérifie si le TTL du message permettra d’atteindre cette passerelle. Auquel cas, la passerelle 1 autorise le transfert, met à jour l’entête Bundle et acquitte les données. La machine source recevant l’acquittement détruit alors les données correspondantes de son espace de stockage.

La passerelle 1 envoi alors les données vers la passerelle 2 lorsque celle-ci est joignable en utilisant le type de protocole approprié. La passerelle 2 située sur mars reçoit ces données. Elle vérifie alors la signature de ce message. Il vérifie ainsi que le bundle transmis provient d’une source autorisée et remplace alors la signature de la passerelle 1 par la sienne. Il sauvegarde ensuite le bundle dans son espace de stockage. La passerelle consulte alors sa table de routage afin d’acheminer les données vers le destinataire final. Il vérifie l’accessibilité de celui-ci, le moyen de communiquer avec lui et s’assure que le TTL soit assez élevé pour parvenir à joindre le destinataire final. Ces vérifications effectuées, la passerelle accepte le transfert, met à jour le bundle et confirme l’opération à la passerelle 1 qui détruit alors la copie qu’elle avait conservée.

La passerelle 2 envoi le message au destinataire final (mars.sol.int, jesuisunmartien.mar) qui vérifie alors l’authenticité du message grâce à la signature insérée par la passerelle 2. Auquel cas, celui-ci est stocké dans sa mémoire persistante et en informe la passerelle 2 par un acquittement, cette passerelle détruisant à son tour la copie dans son espace de stockage. La couche Bundle du destinataire fait alors appel à l’application destinatrice grâce aux champs renseignés dans l’identifiant entité. Selon la qualité de service demandé, le destinataire peut éventuellement créer un nouveau bundle pour informer l’émetteur de la réception et de l’intégrité des données.

< retour    haut de page   suivant >

Site par Damien Schrifve et Thomas Le Ravallec

Gabarit CSS © 2008 Elephorm et Alsacréations