Encadrant : Laurent FRANCK

Présentation au sujet: "Encadrant : Laurent FRANCK"— Transcription de la présentation:

1 Encadrant : Laurent FRANCK
Architectures réseaux pour communications interplanétaires Simon PAILLARD Encadrant : Laurent FRANCK Mercredi 6 septembre 2006

2 Contexte Développement des missions spatiales lointaines (Vénus, Mars)
Défi des télécommunications spatiales : délai, débit, connectivité, consommation énergétique Systèmes standardisés par le CCSDS (CFDP: plus de 250 engins spatiaux équipés) CCSDS : Consultative Committee for Space Data Systems CFDP : CCSDS File Delivery Protocol

3 Problématique Des contraintes communes avec certains cas terrestres : capteurs, champs de bataille, systèmes à bas prix. Multiplicité des systèmes terrestres (filaires ou radio) et spatiaux > comment les interconnecter ?

4 Plan Introduction Contraintes des environnements
Limites des solutions traditionnelles Architecture « Delay Tolerant Network » Travaux menés et résultats Conclusion

5 Contraintes des environnements spatiaux
Délai de propagation Connectivité Débit Taux d'erreur binaire (BER)

6 Contraintes : délai Proportionnel à la distance entre l'émetteur et le récepteur Délai sol-satellite GÉO : 125 ms Délai Terre-Mars : jusqu'à 22 minutes !

7 Contraintes : connectivité (1)
Visibilité non permanente (masquage par une planète par ex.) > intermittence des liens, partition du réseau Jusqu'à l'absence de connectivité de bout-en- bout !

8 Contraintes : connectivité (2)
Exemple de connectivité résultante : > très faible potentiel de transmission par rapport au coût

9 Contraintes : distance
Importantes pertes en espace libre : entre la Terre et Mars (56 millions de km) en bande X (8.4Ghz) : 266 dB, soit ! Compromis débit vs. BER (choix de modulation, code correcteur) Ordre de grandeur : débit : 8 à 256 kb/s taux d'erreur binaire : jusqu'à 10-3

10 Limites des solutions traditionnelles terrestres (1)
Série d'hypothèses optimistes non vérifiables dans tous les environnements : lien bidirectionnel délai aller-retour (RTT) faible pertes de bout en bout faibles connectivité assurée de bout en bout coût raisonnable de la bande passante même couche réseau partagée

11 Limites des solutions traditionnelles terrestres (2)
Hypothèses ainsi induites : la conversation comme seul moyen de corriger les erreurs et de gérer la sécurité une seule route entre source et destination les mécanismes de fiabilité et sécurité peuvent n'être que de bout-en-bout émetteur récepteur

12 Architecture « Delay Tolerant Network » (1)
Expression du besoin d'une architecture pour les réseaux spatiaux intermittents au sein du CCSDS Intérêt pour l'InterPlaNetary Internet (IPN, dont Vint Cerf) Champ d'application plus large que l'IPN Travail sous la tutelle du DTN Research Group (Internet Research Task Force)

13 Architecture DTN Principes (1)
Principe des services postaux : « store and forward » Transmissions de messages, et non pas de paquets ou de flux Pas d'interactivité Mécanismes de fiabilité et sécurité gérés par chacun des noeuds traversés Réseau de réseaux régionaux hétérogènes

14 Architecture DTN Principes (2)
« store and forward » avec intermittences > capacité de transmission améliorée

15 Architecture DTN Piles de protocole
Protocole « bundle » de transmission des messages Plusieurs sous-couches de convergences, adaptées aux différents environnements

16 Architecture DTN Définition des modes de contact
Classification de la connectivité des liens en présence : 4 modes contact permanent contact à la demande contact intermittent opportuniste contact intermittent planifié

17 Implémentation logicielle
Logiciels de référence sur Démon de noeud DTN Applications : dtnping dtnsend / dtnrecv dtncat et d'autres dtn*

18 Travaux menés et résultats : Portage DTN pour borne WiFi
Intérêt du sans-fil dans les solutions DTN faible coût, compacité, mobilité alimentation par batterie > portage du projet DTN pour les bornes WiFi Linksys WRT54G Intégration du patch au projet officiel Travail de collaboration avec le responsable

19 Travaux menés et résultats : Scénario cible (1)
Intermittence via la couverture WiFi Dummynet : latence, BER

20 Travaux menés et résultats : Scénario cible (2)
Passerelles TCP / DTN > réseau DTN transparent pour l'application de réception des données des capteurs Preuve de fonctionnement : > les mesures des capteurs passent par le DTN >> MAIS PAS DE MÉTRIQUE ACCESSIBLE !

21 Travaux menés et résultats : Modélisation intermittence
WiFi : pas de contrôle de l'intermittence > modélisation par script interposé Scénarios de référence retenus :

22 Travaux menés et résultats : Type de trafic et métriques
Métrique de performances : goodput (débit applicatif) Mesure du goodput : envoi continu (back to back) SINON >

23 Travaux menés et résultats : Envoi continu et mesures
Choix de la couche de convergence UDP pas d'interactivité Résultats et problèmes soulevés messages tronqués à 50ko ! détection de faux bundles dupliqués > sur bundles, 200 reçus désactivation de la suppression des dupliqués > génération spontanée de paquets entre la source et le destinataire.

24 Travaux menés et résultats : Envoi continu et mesures
Choix de la couche de convergence TCP, sensible à la latence > intercation des mécanismes TCP Résultats et problèmes soulevés fermeture problématique par le script d'une connexion TCP active en envoi continu erreur de segmentation de la pile DTN en envoi discontinu, on vérifie le résultat du premier scénario : > gestion de l'intermittence vérifiée, pas d'évaluation quantitive

25 Conclusion Problématiques de recherche encore ouvertes : multicast, routage, LTP Intérêt d'un standard au champ d'application large > Fort potentiel de développement d'applications asynchrones à bas coût Manque de maturité du logiciel référence > performances difficiles à quantifier

26 Contributions Portage pleinement fonctionnel de la suite logicielle DTN pour l'architecture MIPS et le système OpenWrt basé sur µClibc Réalisation de passerelles TCP Crossbow (réseau de capteurs) <-> DTN Livrable 2 de l'action R&T CNES « Communications asynchrones en environnement intermittent et contraint »

27 Références Consultative Committee for Space Data Systems, Delay Tolerant Networking Research Group, Internet Research Task Force, S. Burleigh et. al., « Delay-Tolerant Networking: An Approach to Interplanetary Internet », IEEE Communications Magazine, Juin 2003 V. Cerf et. al., « Delay Tolerant Network Architecture », draft-irtf-dtnrg-arch-05.txt, Septembre 2006 K. Scott, S. Burleigh, « Bundle Protocol Specification », draft-irtf-dtnrg-bundle-spec-04.txt, Mai 2006 Forrest Warthman, « Delay-Tolerant Networks (DTNs): A Tutorial », v1.1, Mars 2003 Michael Demmer, Eric Brewer, Kevin Fall, Sushant Jain, Melissa Ho, Robin Patra, « Implementing Delay Tolerant Networking », tech. report IRBTR , Intel Research Berkeley, pdf, Décembre 2004 Interplanetary Internet, Philo Juang, Hidekazu Oki, Yong Wang, Margaret Martonosi, Li-Shiuan Peh, Daniel Rubenstein, « Energy-Efficient Computing for Wildlife Tracking: Design Tradeoffs and Early Experiences with ZebraNet », ASPLOS-X conference, San Jose, Octobre 2002 CNES, ENST, TÉSA, « Communications asynchrones en environnement intermittent et contraint », Livrable 1 Robert RUMEAU, Laurent FRANCK, « Comparaison entre les reseaux mobiles ad hoc et les réseaux tolérants au délai » OpenWrt, Wireless Freedom, OpenWrt building packages howto, Dummynet, A. Lindgren et A. Doria, « Probabilistic Routing Protocol for Intermittently Connected Networks », draft-lindgren-dtnrg- prophet-02.txt, Mars 2006 Jeff Thorn, « Deciphering TinyOS Serial Packets », Octave Tech Brief #5-01, Mars2005,

28 Annexe Structure des bundles (1)
Entête d'un bundle | Version | Proc. Flags | COS Flags | SRR Flags | | [Header length] | | Destination scheme offset | Destination SSP offset | | Source scheme offset | Source SSP offset | | Report-to scheme offset | Report-to SSP offset | | Custodian scheme offset | Custodian SSP offset | | | Creation Timestamp (8 bytes) | Lifetime | | Dictionary length | | Dictionary byte array (variable) | | [Fragment offset] | | [Total application data unit length] |

29 Annexe Structure des bundles (1)
Charge utile d'un bundle | Header type | Proc. Flags | Header length(*****) | | | | Bundle Payload (variable) | / /