Architectures réseaux pour communications interplanétaires Simon PAILLARD

1. Architectures réseauxpourcommunications 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 SystemsCFDP : 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 desenvironnements 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 10-24 ! • 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 DTNPrincipes (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 DTNPrincipes (2) • « store and forward » avec intermittences> capacité de transmission améliorée

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

16. Architecture DTNDéfinition des modes de contact • Classification de la connectivité des liens en présence : 4 modes contact permanentcontact à la demande contact intermittent opportunistecontact intermittent planifié

17. Implémentation logicielle • Logiciels de référence sur http://dtnrg.org • 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 DTNpour les bornes WiFiLinksys 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 40000 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, http://www.ccsds.org • Delay Tolerant Networking Research Group, Internet Research Task Force, http://dtnrg.org/ • 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-04-020, Intel Research Berkeley, http://www.dtnrg.org/papers/demmer-irb-tr-04-020.pdf, Décembre 2004 • Interplanetary Internet, http://ipnsig.org/ • 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 », http://www.princeton.edu/~mrm/zebranet.html, 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, http://openwrt.org • OpenWrt building packages howto, http://wiki.openwrt.org/BuildingPackagesHowTo • Dummynet, http://www.dummynet.com/ • 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, http://weblog.cs.uiowa.edu/294s05-project/uart/slides/deciphering-serial-packets.pdf

28. AnnexeStructure 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. AnnexeStructure des bundles (1) • Charge utile d'un bundle +----------------+----------------+----------------+----------------+ | Header type | Proc. Flags | Header length(*****) | +----------------+----------------+----------------+----------------+ | | | Bundle Payload (variable) | | | / / / / | | +-------------------------------------------------------------------+