6LoWPAN

Un article de Wikipédia, l'encyclopédie libre.

6LoWPAN est l'acronyme de IPv6 Low power Wireless Personal Area Networks[note 1] ou IPv6 LoW Power wireless Area Networks[note 2].

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êtes[1]. 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 :

  1. Le principal document de cette problématique est la RFC 4919[2].
  2. La spécification en elle-même est l'objet de la RFC 4944[3].

Description de la technologie[modifier | modifier le code]

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)[4]. Ces réseaux sont composés d’un grand nombre d’éléments[5],[6].

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 127 octets[7]. Avec les 25 octets de la sous-couche MAC (sans sécurisation)[8], il en résulte 102 octets au niveau liaison. En ajoutant la sécurisation de la couche de liaison de données (AES-CCM-128)[9], il ne reste que 81 octets disponibles au niveau IP. Il faut également tenir compte de la surcharge due aux en-têtes d'IPv6 (40 octets)[10], des éventuels en-têtes d'extension, d'UDP (8 octets)[11] ou de TCP (20 octets)[10]. Finalement les données utiles sont peu élevées (33 octets 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 1 280 octets[12].

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 sont[13] :

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 (40 octets), 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, RFC 4862[14]) est préconisée[15] 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 (RFC 3410[16]) 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)[17].
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[modifier | modifier le code]

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 1 280 octets et les envoie à son équivalent sur l’équipement distant dans des trames 802.15.4. Ces trames ne disposant que de 81 octets 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éception[18].

Chaque fragment est précédé d’un en-tête de fragmentation de 4 ou 5 octets. Cet en-tête contient les informations suivantes[19] :

  • 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).
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 fragments[20].

Pour pallier ce problème, un mécanisme de récupération des fragments a été proposé[21]. 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[modifier | modifier le code]

La RFC 4944[3] 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 4 octets, 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 locales[22]. Pour pallier ce problème, un draft IETF LOWPAN_HC1g[23] 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 deux[24].

Aujourd’hui la proposition du groupe 6LoWPAN est d’utiliser LOWPAN_IPHC[25]. 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 communication[26] :

  • Pour les communications sur un lien local, l’en-tête IPv6 peut être réduit à 2 octets(1-octet Dispatch et 1-octet LOWPAN_IPHC).
  • Pour des communications nécessitant plusieurs sauts IP, l’en-tête peut être compressé sur 7 octets (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 1re figure). Cette charge utile est dans le meilleur des cas de 70 à 75 octets. En effet, si l'on rajoute les informations de fragmentation comme indiqué dans le paragraphe ci-dessus, celle-ci diminuera à 65-70 octets pour ce cas de figure.

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 signification

01000001

paquet IPv6 non compressé

01010000

Broadcast LoWPAN

11000xxx

premier fragment

11100xxx

fragment

11110CPP

UDP Header

LOWPAN_NHC est proposé pour la compression de la couche transport[27]. 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é[28] d'associer les transmissions sur ces ports à Transport Layer Security (TLS) (RFC 5246[29]). 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 4303[30]).

Cependant, seul UDP est spécifié[31]. D’autres propositions ont donc été faites pour compresser TCP[32] et ICMP[33]. Il est donc nécessaire de spécifier la compression de chaque nouvel en-tête[34]. Pour pallier ce problème, 6LoWPAN_GHC[35] a vu le jour. Cette nouvelle proposition a pour objectif de comprimer n’importe quel type d’en-tête.

Routage[modifier | modifier le code]

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-over[36].

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équent[37] :

  • 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ées[38] :

  • 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 LOAD[39], DYMO-LOW [40], HI-LOW [41].

Aujourd'hui, seuls deux protocoles sont légitimes pour de larges déploiements :

  • LOADng (de l'anglais Lightweight On-demand Ad hoc distance-vector routing protocol – next generation), le successeur de LOAD, un protocole mesh-under, standardisé à l'ITU au sein de la recommandation ITU-T G.9903. Ce standard est notamment utilisé au sein du programme Linky de compteurs électriques communicants d'Enedis (déploiement en France de 35 millions de compteurs) et d’Enexis (déploiement aux Pays-Bas de 2,5 millions de compteurs).
  • RPL (de l'anglais Routing Protocol for Low power and Lossy Networks, « protocole de routage pour LLN »)[42], un protocole route-over, standardisé au sein du groupe de travail ROLL[43] de l’IETF chargé de la définition des mécanismes de routage pour les LLN (de l'anglais Low Power and Lossy Network, « réseaux à basse puissance et avec pertes »).

Les problématiques de routage pour de tels réseaux sont définies dans :

  • RFC 5548[44] : Routing Requirements for Urban LLNs ;
  • RFC 5673[45] : Industrial Routing Requirements in LLNs ;
  • RFC 5826[46] : Home Automation Routing Requirements in LLNs ;
  • RFC 5867[47] : Building Automation Routing Requirements in LLNs.
Schéma DAG

RPL est un protocole de routage IPv6 à vecteur de distance qui construit un DAG (de l'anglais Directed Acyclic Graph, « graphe orienté acyclique »)(voir schéma DAG). Il est implémenté en route-over.

Le LBR (de l'anglais Low power and lossy network Border Router, « routeur de bordure du réseau, de faible puissance et avec perte ») désigne l'équipement en bordure de réseau. Le LBR, de rang 1, est à la source du graphe orienté acyclique qui est construit par le protocole RPL précédemment cité. Le LBR et tous les équipements de rang supérieur forment une DODAG (de l'anglais Destination-Oriented Directed Acyclic Graph, « graphe acyclique orienté vers la destination »). Le LBR envoie un message d’information DIO (de l'anglais DODAG Information Object, « Objet d'information DODAG ») en multicast. Lorsqu’un équipement reçoit une nouvelle version de DIO, il calcule notamment son rang (par rapport à celui qu’il vient de recevoir) et propage son DIO. Vu d’un équipement, tous les équipements possédant un rang inférieur peuvent prétendre être parents. Les routes optimales (« parents ») au sein du DAG sont obtenues à partir de métriques et de contraintes[48].

Le LBR émet périodiquement des DIO pour mettre à jour le DAG. Lorsqu’un équipement rejoint le réseau ou perd le lien vers son « parent », il peut attendre le prochain DIO (de la minute à l’heure) ou demander l’envoi d’un DIO par un message de sollicitation DIS (de l'anglais DODAG Information Solicitation, « sollicitation d'information DODAG »). Les messages DIO sont émis avec l’algorithme Trickle. Cet algorithme définit principalement deux choses[49] :

  • un numéro de séquence qui permet de savoir si l’information reçue est une mise à jour ;
  • le délai entre chaque émission d’information (qui varie en fonction de paramètres).

En 2010, des tests d'implémentation de RPL sur un système d'exploitation Contiki ont démontré que cette solution était économe en mémoire, en énergie et que des réseaux de capteurs sans fil ainsi formés pouvaient fonctionner plusieurs années avec cette implémentation. Si la consommation mémoire est un critère clef, il faut noter que cette implémentation consommait 8 % de la mémoire vive disponible pour assurer la mise en œuvre de RPL dans un environnement composé de 10 voisins. La quantité de mémoire morte, pour le stockage du programme était, elle aussi, jugée non négligeable[50].

Autoconfiguration d'IP[modifier | modifier le code]

La RFC 4861 indique le mécanisme ND (de l’anglais Neighbor Discovery, « découverte de voisin ») qui permet une auto-configuration d’une adresse IPv6 sur un équipement. Ce mécanisme induit une utilisation intensive de messages multicast, il n’est pas utilisable dans l’état dans les réseaux 6LoWPAN.

De ce constat, le groupe de travail IETF 6LoWPAN a publié un draft[51] sur l’optimisation du ND afin d’alléger le processus d’autoconfiguration, que le LoWPAN soit routé en mesh-under ou en route-over[52].

Du fait que les équipements 6LoWPAN sont le plus souvent « endormis », des efforts particuliers ont été faits sur la limitation des messages RS (de l’anglais Router Solicitation, « sollicitation de routeur ») envoyés en multicast. Cette optimisation est effectuée en utilisant les messages RS uniquement pour trouver des routeurs par défaut valides lors de l’initialisation de l’équipement, ou à partir du moment où un routeur par défaut est considéré comme injoignable[52]. Une façon de limiter le multicast consiste, entre autres, à ne pas lancer de DAD (de l'anglais Duplicate Address Detection, « Détection d'Adresse en Doublon ») en cas d’utilisation d’EUI64[52].

Le LBR (de l'anglais Low power and lossy network Border Router, « routeur de bordure du réseau, de faible puissance et avec perte ») est dépositaire de la gestion du préfixe de l’adresse IPv6[53].

Les routeurs par défaut gèrent une table NCE (de l’anglais Neighbor Cache Entry, « entrée de table du cache listant les voisins ») où sont listées toutes les adresses du réseau 6LoWPAN. Lors d’une sollicitation, si une adresse n’est pas dans le cache, elle est considérée comme valide et est enregistrée avec une valeur « durée de vie ». Les adresses enregistrées dans le NCE peuvent être de trois types[54] :

  • Garbage-collectible (poubellisable) : Définie selon les critères donnés dans la RFC 4861. Il y a entre autres les adresses en cours de DAD et non encore validées.
  • Registered (Enregistrée) : Valide, avec une durée de vie explicite.
  • Tentative : Entrée temporaire avec une courte durée de vie, et qui a vocation à passer Registered.

Un paramétrage par défaut, adapté aux périodes de « sommeil » des équipements d’un LoWPAN, permet de conserver leurs adresses valides entre deux « réveils »[55]. Cette méthode permet de ne pas pénaliser les équipements en consommation d’énergie et évite de relancer une autoconfiguration à chaque réveil.

Ces éléments sont implémentés dans le New ND (nouveau ND) : ce message contient une ARO (de l’anglais Address Registration Option, « option d’enregistrement d’adresse »)[55], l’ARO permet au LBR de maintenir correctement ses NCE car elle est émise régulièrement par l’équipement qui transmet la Durée de Vie de son adresse au LBR.

Dans le cas d’un réseau routé en route-over les LR (de l'anglais Low power and lossy network Router, « routeur du réseau, de faible puissance et avec perte ») et LBR échangent des ABRO (de l'anglais Authoritative Border Router Option, « option de routeur de bordure autorisé »)[53], ces messages de type RA transportent des préfixes d’adresses, des informations de contexte, et l’adresse du LBR[53]. De plus les échanges de DAD en multi-sauts entre LR et LBR se font sur deux nouveaux messages ICMPv6 le DAR (de l'anglais Duplicate Address Request, « requête d'adresse double »)[54] et le DAC (de l'anglais Duplicate Address Confirmation, « confirmation d'adresse double »)[54].

Comparaison des ND(Neighbor Discovery) sur IPv6 et sur 6LoWPAN[56].

Une expérimentation d'autoconfiguration stateless a été réalisée en 2009 en utilisant des adresses LoWPAN de longueur 16 bits : la construction de l'adresse au démarrage de l'équipement se faisait sur trois vecteurs de distance en bonds, vers trois équipements « coordinators » référents (Vert, Bleu et Rouge), et d'une valeur aléatoire[57]. L'analogie a été prise avec les définitions de couleurs : trois vecteurs distance vers les références Vert, Bleu et Rouge[58].

En , une proposition d'autoconfiguration stateful a abouti à l'élaboration du LISAA (de l'anglais Lightweight IPv6 Stateful Address Autoconfiguration « autoconfiguration d'adresse IPv6 allégée et dynamique »)[59].

Le LBR travaille en mode proxy et possède un groupe d'adresses 16 bits à distribuer dans le LoWPAN. Ce groupe est divisé en blocs, divisés eux-mêmes en sous-blocs. Ces subdivisions créent une distribution hiérarchique de blocs d'adresses qui suit la topologie des LR[60]. Une expérimentation du LISAA a montré une faible latence dans l'autoconfiguration et une faible surcharge de l'en-tête. Par contre il a été remarqué une réponse lente lors des déplacements d'équipements[61].

La mise en place de la technologie RFID, au sein des capteurs faisant partie d’un réseau 6LowPAN, permettrait de réduire la consommation électrique de ces capteurs, du fait de la simplification de la phase de découverte et d’enregistrement de ceux-ci au sein du réseau 6LowPAN[62].

Mobilité[modifier | modifier le code]

Mobilité 6LoWPAN

Lorsqu’un équipement se déplace au sein d’un LoWPAN (mobilité intra LoWPAN) et qu’il ne perd pas la connectivité avec le CFD (de l'anglais Coordinator-Function Device, « équipement avec la fonction coordinateur »), il n’est pas nécessaire de gérer cette mobilité car le protocole de routage peut la supporter[63].

Par contre, lorsqu'un équipement se déplace d’un LoWPAN vers un autre (mobilité inter LoWPAN), il est nécessaire de gérer spécifiquement ce type de mobilité. Pour cela plusieurs scénarios sont proposés :

  • Adapter MIPv6 (RFC 3775[64]) pour 6LoWPAN. En compressant les en-têtes et les différents messages, il est possible de réutiliser MIPv6 pour 6LoWPAN[65].
  • Utiliser Proxy MIPv6 (RFC 5213[66]) pour pallier le problème de la signalisation qui ne peut pas être gérée par les nœuds[67].
  • Lightweight NEMO : une version légère de NEMO Basic Support Protocol (RFC 3963[68]) pour 6LoWPAN dont le but est de réduire la surcharge due à l’en-tête de mobilité en le compressant[69].
  • Inter-PAN : mécanisme de gestion de la mobilité au niveau de la couche adaptation de 6LoWPAN[70].
  • Inter-Mobility : protocole qui introduit de nouvelles entités, les 6LoWPAN PA (de l'anglais Proxy Agent, « agent mandataire »). Ces PA ont en charge la gestion de la mobilité[71].
  • Inter-MARIO : protocole dont la gestion des handovers est basée sur des équipements partenaires qui détectent le déplacement de équipements mobiles et initient la configuration. Cela permet d’accélérer la procédure de handover[72].
  • SPMIPv6 : protocole basé sur PMIPv6 (Proxy MIPv6) qui a pour but de réduire la consommation d’énergie. Pour cela la mobilité est gérée par deux nouveaux équipements le SMAG (de l'anglais Sensor network-based Mobile Access Gateway, « passerelle d'accès mobile pour les réseaux de capteurs ») et le SLMA (de l'anglais Sensor network-based Localized Mobility Anchor, « Point d’ancrage de mobilité localisée sur les réseaux de capteurs »)[73].

Pour gérer les cas où tous les équipements d’un LoWPAN se déplacent (Network Mobility), il est nécessaire d’implémenter le protocole NEMO (RFC 3963[68]) dans 6LoWPAN[63].

Supervision et Gestion de Réseau[modifier | modifier le code]

La supervision d'un réseau LoWPAN est assurée à partir d'un serveur applicatif (NMS) placé dans le domaine IPv6. Les requêtes SNMP (de l'anglais Simple Network Management Protocol, «Protocole Simple de Gestion de Réseau»), envoyées par le serveur de supervision vers les divers équipements, ne sont pas adaptées aux contraintes d'un LoWPAN : elles ont des tailles de paquets trop importantes et sont trop nombreuses.

6LoWPAN-SNMP[modifier | modifier le code]

La proposition d’un 6LoWPAN-SNMP[74] a été faite en s’appuyant sur des travaux en cours à l'IETF[75]. Elle consiste en l’utilisation d’un proxy (d'un serveur mandataire) qui relaie les paquets IPv6 en provenance d'internet vers le réseau LoWPAN en comprimant les requêtes SNMP[76] et en les émettant en broadcast ou multicast (Méthode BroadcastGetRequest)[77] pour limiter l’occupation de la bande passante : une requête répétitive com

We need Your Support. Make a Donation now! or