6LoWPAN est l'acronyme de IPv6 Low power Wireless Personal Area NetworksEn français, Les réseaux personnels sans fil à faible consommation. ou IPv6 LoW Power wireless Area NetworksEn français, Les réseaux sans fil à faible consommation..
C'est également le nom d'un groupe de travail de l'IETF. Le groupe 6LoWPAN a défini les mécanismes d'encapsulation et de compression d'entêtes permettant aux paquets IPv6 d'être envoyés ou reçus via le protocole de communication IEEE 802.15.4. IPv4 et IPv6 sont efficaces pour la délivrance de données pour les réseaux locaux, les réseaux métropolitains et les réseaux étendus comme l'internet. Cependant, ils sont difficiles à mettre en œuvre dans les capteurs en réseaux et autres systèmes contraints en raison, notamment, de la taille importante des en-têtesG. Mulligan 2007, Introduction.. 6LoWPAN devrait permettre à IPv6 d'intégrer ces matériels informatiques contraints et les réseaux qui les interconnectent.
La spécification de base développée par le groupe 6LoWPAN est connue sous la forme de deux principales RFC : Le principal document de cette problématique est la RFC 4919RFC 4919, 2007, page 1. La spécification en elle-même est l'objet de la RFC 4944RFC 4944, 2007, page 1.
Description de la technologie
Un LoWPAN est constitué d'un ensemble d’équipements ayant peu de ressources (CPU, mémoire, batterie) reliés au travers d’un réseau limité en débit (jusqu’à 250 kbit/s)IEEE Std 802.15.4-2006, page 13. Ces réseaux sont composés d’un grand nombre d’élémentsZ. Shelby et Al. 2009, introductionJP. Vasseur et Al. 2010, introduction.
En 802.15.4, la taille maximale du PSDU (de l'anglais Physical layer Service Data Unit, « Unité de données service de la couche physique ») est de IEEE Std 802.15.4-2006, page 45. Avec les de la sous-couche MAC (sans sécurisation)IEEE Std 802.15.4-2006, page 159, il en résulte au niveau liaison. En ajoutant la sécurisation de la couche de liaison de données (AES-CCM-128)IEEE Std 802.15.4-2003, page 172, il ne reste que disponibles au niveau IP. Il faut également tenir compte de la surcharge due aux en-têtes d'IPv6 ()RFC 2460, page 4, des éventuels en-têtes d'extension, d'UDP ()RFC 768, page 1 ou de TCP (). Finalement les données utiles sont peu élevées ( sur UDP et 21 sur TCP, voir figure ci-dessous) et ne permettent pas de respecter les spécifications d'IPv6 qui imposent un MTU minimal de RFC 2460, page 24. thumb|center|upright=4|Problème d'intégration d'un paquet IPv6 sur une trame 802.15.4 Pour s'adapter au support 802.15.4, l'équipement doit fragmenter un paquet IPv6 en plusieurs trames 802.15.4, et l'équipement distant doit ré-assembler toutes les trames 802.15.4 reçues pour régénérer le paquet IPv6 d'origine. Ces tâches sont consommatrices de ressources (mémoire et CPU) et génèrent de la latence (bufferisation, temps de création/vérification des entêtes).
Les problèmes inhérents aux LoWPANs sontRFC 4919, 2007 page 4-9 : La fragmentation et le ré-assemblage les contraintes de tailles de paquet imposées par IPv6 et par 802.15.4 posent un problème de fragmentation/réassemblage excessif. La compression de l'entête IPv6 avec l'entête IPv6 actuel (), la charge utile est réduite. La compression de l'entête IPv6 est donc une nécessité pour optimiser les transferts de données sur un réseau 6LoWPAN. Le routage les réseaux LoWPAN sont constitués d'une multitude de nœuds. Ils sont organisés en topologie de type « mesh » (multi-hop) ou en étoile. Un protocole de routage permettant de supporter de tels réseaux doit être mis en place. Celui-ci doit en plus répondre aux contraintes des nœuds eux-mêmes (faibles CPU et mémoire) ainsi qu’à celles du 802.15.4 (faible débit et petits paquets). De par leur taille, les équipements 802.15.4 sont facilement transportables. La mobilité doit donc être prise en compte. L'autoconfiguration d'IP L’autoconfiguration d'adresse IPv6 de type stateless (SLAAC, ) est préconiséeRFC 4919, page 8 car elle réduit la sollicitation sur les équipements. Celle-ci nécessite la génération d'un identifiant d’interface de type EUI-64 ou de type short à 16 bits sur les équipements. La supervision et la gestion du réseau la supervision/gestion d’un réseau 6LoWPAN est un élément essentiel. SNMP () est déjà utilisé largement dans les réseaux IP et possède l’avantage d’avoir une multitude d’outils existants. En raison des contraintes imposées par 802.15.4 et des caractéristiques des équipements, l'adéquation de SNMPv3 à 6LoWPAN reste à déterminer. Les contraintes sur les applications « hautes » À cause des caractéristiques des LoWPANs, les applications nécessitant beaucoup de ressources ne sont pas forcément appropriées. Il peut donc être nécessaire d’adapter les applications aux contraintes des LoWPANs (ressources des équipements, débit et taille de paquets réduit sur 802.15.4)RFC 4919, 2007, page 8. La sécurité afin de contrôler l’intégrité des données transmises sur un réseau 6LoWPAN, la sécurisation du transfert des données devrait être implémentée au niveau IP, en plus de celle offerte par IEEE 802.15.4 (via AES).
Fragmentation et ré-assemblage La couche adaptation de 6LoWPAN se situe entre la couche réseau et la couche liaison du modèle OSI. Elle reçoit de la couche réseau des paquets IPv6 de et les envoie à son équivalent sur l’équipement distant dans des trames 802.15.4. Ces trames ne disposant que de de libre (cf Description de la technologie), la couche adaptation doit fragmenter les paquets IPv6 avant de les envoyer et les ré-assembler à la réceptionRFC4944, page 5.
Chaque fragment est précédé d’un en-tête de fragmentation de 4 ou . Cet en-tête contient les informations suivantesRFC4944, pages 11-12 : 5 bits pour dispatch : permet d’identifier qu’il s’agit d’un fragment. Le premier fragment aura la valeur « 11000 » et les suivants « 11100 » ; 11 bits pour datagram_size : taille du paquet IP avant fragmentation ; 16 bits pour datagram_tag : identifiant commun à tous les fragments d’un même paquet IP ; 8 bits pour datagram_offset : position du fragment dans le paquet IP (uniquement présent dans les fragments suivant le premier).
thumb|center|upright=4|En-têtes de fragmentation 6LoWPAN. Si un seul fragment est perdu, le paquet IP ne peut pas être reconstitué. Le problème avec ce mécanisme de fragmentation est qu’il faudra alors émettre à nouveau tous les fragmentsP. Thubert et Al. 2010, page 3 .
Pour pallier ce problème, un mécanisme de récupération des fragments a été proposéP. Thubert et Al., 2010. Il introduit un nouvel en-tête de fragmentation et surtout un mécanisme d’acquittement des fragments. L’acquittement permet à l’expéditeur de ne retransmettre que les fragments non reçus (non acquittés).
Compression d'en-tête
La RFC 4944 définit le mécanisme de compression des en-têtes IPv6 pour LowPAN : LOWPAN_HC1. Elle intègre aussi la compression de l'en-tête UDP sur , mais n'autorise pas la compression du Checksum. De plus, elle restreint la plage des ports UDP de 61616 à 61631 afin de compresser à 4 bits cette valeur.
Cette compression d'en-tête IPv6 ne peut s’appliquer que sur les adresses de liens localesA. Ludovici et Al. 2009, page 4. Pour pallier ce problème, un draft IETF LOWPAN_HC1gJ. Hui et Al. 2007 a été publié. LOWPAN_HC1g s'applique sur les adresses globales pour les communications multi-sauts IP. Ces deux mécanismes de compression (LOWPAN_HC1 et LOWPAN_HC1g) sont complémentaires. Il est donc nécessaire d'implémenter les deuxA. Ludovici et Al. 2009, page 5.
Aujourd’hui la proposition du groupe 6LoWPAN est d’utiliser LOWPAN_IPHCJ. Hui et Al. 2011. Il permet de remplacer LOWPAN_HC1 et LOWPAN_HC1g. Les octets IPHC résultent de la compression de l'en-tête IPv6. Ils intègrent principalement les informations de qualité de service (DSCP et ECN), des prochains en-têtes, le nombre de sauts et les adresses source/destination compressées.
Avec LOWPAN_IPHC le taux de compression dépend du type de communicationJ. Hui et Al. 2011, page 6 : Pour les communications sur un lien local, l’en-tête IPv6 peut être réduit à (1-octet Dispatch et 1-octet LOWPAN_IPHC). Pour des communications nécessitant plusieurs sauts IP, l’en-tête peut être compressé sur (1-octet Dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address et 2-octet Destination Address). L'exemple ci-dessous montre l'augmentation de la charge utile par rapport à la problématique d'origine (voir ). Cette charge utile est dans le meilleur des cas de 70 à . En effet, si l'on rajoute les informations de fragmentation comme indiqué dans le paragraphe ci-dessus, celle-ci diminuera à 65- pour ce cas de figure. thumb|center|upright=4|Trame 802.15.4 sur IPv6 avec compression de l'entête IPv6 et de l'entête de fragmentation.
L'octet Dispatch a la même fonction que l'EtherType, il permet de déterminer le type de paquet au-dessus du 802.15.4. + Table 1 : Quelques exemples de valeurs possible pour l'octet Dispatch. Valeur signification01000001paquet IPv6 non compressé01010000Broadcast LoWPAN11000xxxpremier fragment11100xxxfragment11110CPPUDP Header
LOWPAN_NHC est proposé pour la compression de la couche transportJ. Hui et Al. 2011, page 14. De plus, afin d'éviter une surcharge de l'utilisation des ports UDP et surtout afin de contrôler l'intégrité des messages, il est préconiséJ. Hui et Al. 2011, page 17 d'associer les transmissions sur ces ports à Transport Layer Security (TLS) (RFC 5246RFC5246, 2008). La compression du checksum est maintenant possible mais uniquement autorisée lorsque la couche supérieure utilise du tunneling (par exemple : IPsec Encapsulating Security Payload tunnel mode (RFC 4303RFC4303, 2005).
Cependant, seul UDP est spécifiéJ. Hui et Al. 2011, page 16. D’autres propositions ont donc été faites pour compresser TCPA. Ayadi et Al. 2010 et ICMPC. O'Flynn 2010. Il est donc nécessaire de spécifier la compression de chaque nouvel en-têteC. Bormann 2011, page 3. Pour pallier ce problème, 6LoWPAN_GHCC. Bormann 2011 a vu le jour. Cette nouvelle proposition a pour objectif de comprimer n’importe quel type d’en-tête.
Routage thumb|right|upright=1.5|Schéma de routage 6LoWPAN. Le schéma de routage de 6LoWPAN peut être réalisé selon deux modalités différentes : mesh-under et route-overE. Kim et Al. 2011.
Mesh-under consiste à implémenter un routage au niveau de la couche adaptation (qui prend place entre la couche liaison et la couche réseau du modèle OSI), alors que route-over réalise cette implémentation au niveau de la couche réseau (voir schéma de routage 6LoWPAN). Dans route-over, le paquet IPv6 est reconstitué sur chaque équipement intermédiaire afin de prendre la décision de routage. À contrario, dans mesh-under, la décision de routage se fait au niveau 6LoWPAN et donc seulement avec les fragments du paquet IPv6. Dans ce cas, le paquet IPv6 n’est reconstitué que sur l'équipement destinataire. Par conséquentA. Chowdhury et Al. 2009, page 5 : mesh-under permet d’avoir un délai de transmission plus court ; route-over est plus efficace dans des conditions dégradées (perte de paquets).
Des versions améliorées de mesh-under et route-over ont été proposéesA. Ludovici et Al. 2011, pages 5-7 : Controlled mesh under : En analysant le contenu de l’en-tête du premier fragment, un équipement peut savoir quels sont les prochains fragments attendus. Si le prochain fragment reçu ne correspond pas au fragment attendu, l’équipement demande sa réémission ; Enhanced route over : Un circuit virtuel est créé en associant l’adresse IPv6 et le champ datagram_tag de l’en-tête du premier fragment. Le circuit virtuel est alors emprunté par tous les fragments ayant le même datagram_tag.
Dans un premier temps, plusieurs protocoles de routage ont été développés par la communauté 6LoWPAN, tel que LOADK. Kim et Al. 2007 (a), DYMO-LOW K. Kim et Al. 2007(b), HI-LOW K. Kim et Al. 2007(c).
Aujourd'hui, seuls deux protocoles sont légitimes pour de larges déploiements :