Mon blog

La norme IEEE 802.15.4 standardise un protocole de communication radio conçu pour des équipements légers, ayant peu de ressources (que ce soit des ressources de calcul ou bien en électricité). Le groupe de travail 6lowpan de l'IETF travaille à adapter IP à ces objets légers et à ce protocole radio. La réussite de 6lowpan permettrait le développement d'un véritable Internet des objets, connectant des engins qui ne sont en général pas classés parmi les ordinateurs.

Qu'est-ce qu'un « Low-Power Wireless Personal Area Networks » (LowPAN) ? Comme résumé par la section 1 du RFC, c'est un réseau de machines communiquant sans fil, à faible distance, avec IEEE 802.15.4. Et ces machines ont presque toujours peu de puissance électrique, un coût faible (donc peu de mémoire et peu de CPU) et le réseau ne va pas vite. Typiquement, les membres d'un « LowPAN » sont des capteurs et autres dispositifs de surveillance et de détection. Quel protocole de couche 3 (et au-dessus) faire tourner sur 802.15.4 ? Il existe un protocole privé, qui bénéficie d'un marketing virulent, Zigbee. Il est donc stratégiquement important qu'il soit remplacé par un protocole ouvert, c'est le but du groupe de travail 6lowpan. Ce RFC 4919 en est le premier document, qui décrit le problème à résoudre, en partant de l'hypothèse que les LowPAN utiliseront IPv6 (d'où le chiffre six au début du nom du groupe). Le second RFC publié a été le RFC 4944, contenant les détails pratiques d'utilisation d'IP sur 802.15.4.

La section 2 reprend l'ensemble des caractéristiques d'un LowPAN et permet d'imaginer les problèmes qu'elles peuvent poser à un déploiement d'IP traditionnel. Entre autres :

• paquets de petite taille, le maximum de 802.15.4 étant de 127 octets. Avec les différents en-têtes obligatoires (notamment de chiffrement), il n'y a parfois plus que 81 octets libres pour IP.
• Les adresses des machines d'un LowPAN peuvent être des adresses IEEE de 64 bits mais aussi des adresses abrégées de seulement 16 bits.
• Capacité très faible : à 868 Mhz (une des fréquences normalisées), il n'y a que 20 kb/s.
• Les machines d'un LowPAN peuvent s'organiser en étoile ou bien dans un réseau maillé.
• Grand nombre de machines connectées, bien plus élevé que le nombre d'ordinateurs.
• Machines peu fiables, souvent en panne, déplacées, à la batterie qui se vide...
• Connectivité d'une machine souvent interrompue par ses périodes de sommeil (pour économiser le courant).

On le voit, ces caractéristiques sont très différentes de celles des Vax sur lesquels avait été programmée l'implémentation de TCP/IP à Berkeley !

Dans ce cadre, plutôt difficile, sur quoi peut compter le concepteur de protocoles pour 6lowpan ? La section 3 liste ces suppositions de base, sachant que certaines pourront évoluer dans le temps (après tout, la loi de Moore s'applique ici aussi et peut améliorer la situation) :

• Il y aura une séparation entre les machines les plus « bêtes » (RFD, Reduced Function Devices) et des machines plus évoluées (FFD, Full Function Devices), qui pourront prendre à leur charge certaines des activités, notamment de coordination.
• Le réseau devra utiliser IP, système déjà déployé, connu, et pour lequel il existe d'innombrables applications et plein d'outils de gestion du réseau.
• Contrairement aux concurrents comme Zigbee, IP est ouvert, et accessible à tous. Il n'enferme pas chez un vendeur ou un cartel de vendeurs.
• Le fait d'utiliser IP permet des interconnexions relativement faciles avec le reste de l'Internet.

Mais il y a aussi des problèmes concrets à résoudre, qui font l'objet de la section 4.

• Vu le nombre d'objets attendus dans un LowPAN, il faut disposer de beaucoup d'adresses, ce qui impose IPv6, avec son immense espace d'adressage.
• Comme il n'est pas question de gérer tous ces objets à la main, il faut un système d'auto-configuration. Là encore, IPv6 a tout ce qu'il faut.
• La faible capacité du lien va nécessiter la compression des en-têtes (curieusement, ROHC - RFC 5795 - n'est pas cité).
• Le protocole de routage (section 4.2) devra à la fois gérer des topologies variées et ne pas être trop bavard, pour économiser la capacité du réseau. Il devra également tenir compte de l'exigence d'économie d'énergie (les protocoles existants ont été conçus pour des systèmes très différents de ceux d'un LowPAN).
• Les équipements du LowPAN doivent autant que possible se configurer tout seuls : en effet, ils seront très nombreux (trop pour être configurés à la main un par un), avec des moyens d'entrée/sortie très limités, et souvent planqués dans des endroits difficiles d'accès.
• Ce genre d'exigences ne va pas en général dans le sens de la sécurité. 802.15.4 impose un chiffrement (avec AES) mais ne dit rien de la gestion des clés (comment communiquer les clés à l'objet ?), de la sécurité dans les couches hautes. La section 4.4 insiste donc sur l'importance de développer des mécanismes de sécurité (voir aussi la section 6).

Bref, il va y avoir du travail. La section 5 donne les buts à atteindre :

• Comme IP impose une taille minimale de paquets à sa couche 2, que cette taille est de 1280 octets en IPv6 (section 5 du RFC 2460), bien au delà des 81 octets libres, dans le pire cas, avec 802.15.4, il va falloir développer un mécanisme de fragmentation et réassemblage au niveau 2.
• Comme l'en-tête IPv6 fait au minimum 40 octets, que l'en-tête TCP atteint 20 octets, il ne resterait que 21 octets pour les données ! Il est donc impératif de spécifier un mécanisme de compression des en-têtes.
• Pour l'auto-configuration IPv6, il faut définir une correspondance entre les adresses IEEE 802.15.4 et les identificateurs d'interface utilisés par IP. Ces deux premiers points ont été traités dans le RFC 4944.
• Un protocole de routage pour le réseau maillé doit être créé. Il existe des expériences diverses (RFC 3561, RFC 3626, RFC 3684), mais souvent pour des réseaux avec moins de contraintes que les LowPAN. (Voir un autre travail sur ce sujet dans le RFC 5826.)
• Une des raisons de l'utilisation d'IP est la disponibilité de nombreux protocoles et outils, par exemple SNMP pour la gestion. Mais un agent SNMP est un logiciel complexe, peut-être trop pour l'objet LowPAN typique. Peut-être faudra t-il créer un profil simplifié de SNMP.
• Même au niveau application, certains ajustements seront peut-être nécessaires. Par exemple, une usine à gaz comme SOAP est sans doute trop consommatrice de ressources. (À noter qu'il existe déjà une liste de diffusion sur les problèmes spécifiques aux applications, 6lowapp, qui évoluera peut-être en un groupe de travail.)

Où en sont les mises en œuvre de 6LowPAN ? Un exemple avec le source disponible est apparemment celle de NXP, JenNet-IP.