5. 6LoWPAN Routing Requirements (Exigences de routage 6LoWPAN)

Cette section définit une liste d'exigences pour le routage 6LoWPAN. Une propriété de conception importante spécifique aux réseaux à faible consommation est que les LoWPAN doivent prendre en charge plusieurs types de dispositifs et rôles, tels que:

• les nœuds hôtes alimentés par des batteries primaires ou utilisant la récupération d'énergie (parfois appelés "nœuds à énergie limitée")
• les nœuds hôtes alimentés sur secteur (un exemple de ce que nous appelons "nœuds à énergie abondante")
• les passerelles haute performance à énergie abondante (mais pas nécessairement alimentées sur secteur)
• les nœuds ayant diverses fonctionnalités (agrégateurs de données, relais, gestionnaire/coordinateur local, etc.)

En raison de ces différents types de dispositifs et rôles, les LoWPAN doivent prendre en compte les deux attributs principaux suivants:

• Conservation de l'énergie: certains dispositifs sont alimentés sur secteur, mais beaucoup fonctionnent sur batterie et doivent durer plusieurs mois à quelques années avec une seule batterie AA. De nombreux dispositifs sont alimentés sur secteur la plupart du temps mais doivent encore fonctionner sur batteries pendant des périodes éventuellement prolongées (par exemple, sur un chantier de construction avant que l'alimentation électrique du bâtiment ne soit activée pour la première fois).

• Faible performance: dispositifs minuscules, petites tailles de mémoire, processeurs peu performants, faible bande passante, taux de perte élevés, etc.

Ces attributs fondamentaux des LoWPAN affectent la conception des solutions de routage. Que les spécifications de routage existantes soient simplifiées et modifiées, ou que de nouvelles solutions soient introduites pour s'adapter aux exigences de faible consommation des LoWPAN, elles doivent satisfaire les exigences décrites ci-dessous.

5.1. Support of 6LoWPAN Device Properties (Support des propriétés des dispositifs 6LoWPAN)

Les objectifs généraux énumérés dans cette section doivent être satisfaits par les protocoles de routage 6LoWPAN. L'importance de chaque exigence dépend du type de nœud sur lequel le protocole s'exécute et du rôle du nœud. Les exigences suivantes prennent en compte la présence de nœuds alimentés par batterie dans les LoWPAN.

[R01] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) permettre une implémentation avec une petite taille de code et exiger un état de routage faible pour s'adapter à la capacité typique d'un nœud 6LoWPAN. De manière générale, la taille du code est limitée par la taille de la mémoire flash disponible, et la table de routage est limitée par la taille de la RAM, la limitant éventuellement à moins de 32 entrées.

La taille de la RAM des nœuds LoWPAN varie souvent entre 4 Ko et 10 Ko (minimum 2 Ko), et la mémoire flash du programme se compose normalement de 48 Ko à 128 Ko. (Par exemple, sur le marché actuel, le MICAz dispose de 128 Ko de flash programme, 4 Ko d'EEPROM et 512 Ko de ROM flash externe; le TIP700CM dispose de 48 Ko de flash programme, 10 Ko de RAM et 1 Mo de ROM flash externe.)

En raison de ces restrictions matérielles, le code DEVRAIT (SHOULD) tenir dans une petite taille de mémoire -- pas plus de 48 Ko à 128 Ko de mémoire flash, y compris au moins quelques dizaines de Ko de taille de code d'application. (En tant qu'observation générale, un protocole de routage de faible complexité peut aider à atteindre l'objectif de réduction de la consommation d'énergie, améliore la robustesse, nécessite un état de routage inférieur, est plus facile à analyser et peut être moins vulnérable aux attaques de sécurité.)

De plus, le fonctionnement avec des quantités limitées d'état de routage (telles que les tables de routage et les listes de voisins) DEVRAIT (SHOULD) être maintenu, car certaines tailles de mémoire typiques empêchent de stocker l'état d'un grand nombre de nœuds. Par exemple, les applications de surveillance industrielle peuvent nécessiter de prendre en charge un maximum de 20 sauts [RFC5673]. Les petits réseaux peuvent être conçus pour prendre en charge un nombre de sauts plus faible. Bien que le besoin pour cela soit fortement dépendant de l'architecture du réseau, il devrait y avoir au moins un mode de fonctionnement qui puisse fonctionner avec 32 entrées de transfert ou moins.

[R02] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) causer une consommation d'énergie minimale en utilisant efficacement les paquets de contrôle (par exemple, en minimisant le multicast IP coûteux, qui provoque une diffusion de lien vers l'ensemble du LoWPAN) et en routant efficacement les paquets de données.

Une façon d'optimiser la durée de vie de la batterie consiste à obtenir une surcharge minimale de messages de contrôle. Comparée à des fonctions telles que les opérations de calcul ou la prise d'échantillons de capteurs, la communication radio est de loin le facteur dominant de consommation d'énergie [Doherty]. La consommation d'énergie de la transmission et/ou de la réception dépend linéairement de la longueur des unités de données et de la fréquence de transmission et de réception des unités de données [Shih].

La consommation d'énergie de deux contrôleurs de radiofréquence (RF) exemplaires pour les nœuds à faible consommation est présentée dans [Hill]. La radio TR1000 consomme 21 mW lors de la transmission à 0,75 mW, et 15 mW pendant la réception (avec une sensibilité du récepteur de -85 dBm). Le CC1000 consomme 31,6 mW lors de la transmission à 0,75 mW, et 20 mW pendant la réception (avec une sensibilité du récepteur de -105 dBm). L'endurance énergétique sous le concept d'une source d'alimentation idéalisée est expliquée dans [Hill]. Sur la base de l'énergie d'une batterie AA idéalisée, le CC1000 peut transmettre pendant environ 4 jours consécutifs ou recevoir pendant 9 jours consécutifs. Notez que la disponibilité pour les tâches réelles dépend de la fréquence de communication et d'autres opérations à faible cycle de service, ainsi que de la capacité énergétique fournie par la batterie.

Dans certains cas, la surcharge introduite par le protocole de routage est importante. [Doherty] rapporte que dans le protocole LEACH utilisé pour le routage hiérarchique, les paquets de données et de protocole proposés dans [Heinzelman] consomment 97% de l'énergie de transmission à un débit de 100 bits par seconde. Dans les cas où l'exigence de surcharge des paquets de contrôle n'est pas aussi exigeante, les paquets de contrôle jouent toujours un rôle important. Pour les données de capteur du réseau personnel sans fil à faible débit et faible consommation (LR-WPAN), ZigBee (IEEE 802.15.4) utilise le routage AODV dans la transmission de données de capteur, les paquets de protocole de routage consomment environ 15% de l'énergie de transmission, tandis que la consommation d'énergie de transmission des paquets de données est d'environ 85% [Doherty]. Par conséquent, les protocoles de routage DEVRAIENT (SHOULD) envisager d'utiliser des mécanismes de routage efficaces et des formats de paquets de protocole d'échange simples.

[R03] Les messages de contrôle du protocole de routage 6LoWPAN NE DEVRAIENT PAS (SHOULD NOT) dépasser la taille d'une seule trame MAC IEEE 802.15.4 (maximum 127 octets) pour éviter les coûts coûteux de fragmentation et de réassemblage.

La taille maximale du paquet de couche physique d'une seule trame IEEE 802.15.4 est de 127 octets [IEEE802.15.4]. Dans le cas où LLC/SNAP transporte le type de trame Ethernet, un en-tête IPv6 de 40 octets plus un en-tête UDP nécessite 8 octets, et donc, la charge utile UDP est de 74 octets. En général, afin de garder le protocole simple et d'éviter la fragmentation et le réassemblage de trames, les messages de contrôle du protocole de routage 6LoWPAN DEVRAIENT (SHOULD) être envoyés en quantités limitées et être aussi petits que possible.

5.2. Support of 6LoWPAN Link Properties (Support des propriétés des liaisons 6LoWPAN)

En raison des conditions topologiques des LoWPAN, les défaillances de liaison et les échecs de transmission se produisent fréquemment. Une fiabilité accrue des paquets ou l'utilisation de transmissions de sauvegarde supplémentaires peut être nécessaire. La gestion des conditions de réseau inattendues (telles que les paquets de données ou de contrôle perdus, les liaisons unidirectionnelles, la qualité de liaison variable) est cruciale pour concevoir des protocoles de routage robustes et fiables. Les protocoles de routage doivent non seulement être conscients de ces types de conditions de réseau dans leur conception, mais doivent également utiliser la fonctionnalité fournie par l'interconnectivité 6LoWPAN pour garantir que les données peuvent être livrées de manière fiable de la source à la destination. Les exigences suivantes prennent en compte les caractéristiques des liaisons dans les LoWPAN.

[R04] La conception des protocoles de routage pour les LoWPAN DOIT (MUST) prendre en compte la fiabilité de la liaison, le taux d'erreur de liaison, la qualité de liaison et la stabilité de liaison pour l'optimisation du routage.

Les liaisons sans fil à faible consommation sont intrinsèquement peu fiables, et il existe plusieurs raisons de perte de paquets, telles que:

• De nombreux dispositifs peuvent être en mode veille la plupart du temps, il peut donc ne pas y avoir de voisins en écoute lors de la transmission de paquets.
• Les facteurs environnementaux tels que les EMI, les obstacles des bâtiments et des infrastructures, le terrain, etc., peuvent provoquer des échecs de transmission ou transformer des liaisons symétriques en liaisons asymétriques et vice versa.
• La congestion, en particulier dans les réseaux de capteurs, où la communication multi-sauts et le trafic de routage de nombreuses sources convergeant vers la passerelle augmentent la probabilité de congestion autour des nœuds proches de la passerelle [Shelby-6LoWPAN].
• Le spectre sans fil est généralement partagé et nécessite une coordination entre plusieurs technologies sans fil utilisant les bandes ISM, et les réseaux fonctionnant dans ces bandes peuvent être affectés par les interférences d'autres réseaux ou dispositifs.

Par conséquent, la conception des protocoles de routage 6LoWPAN DOIT (MUST) prendre en compte la fiabilité de la liaison, le taux d'erreur de liaison, la qualité de liaison et la stabilité de liaison pour l'optimisation du routage.

[R05] La conception des protocoles de routage pour les LoWPAN DOIT (MUST) prendre en compte les liaisons asymétriques.

Les protocoles de routage 6LoWPAN DOIVENT (MUST) prendre en charge les liaisons asymétriques car de nombreuses liaisons pratiques dans les LoWPAN sont asymétriques (par exemple, les liaisons entre les nœuds de détection à faible consommation et les stations de base à énergie abondante) [Shelby-CoAP]. Dans de tels cas, la sélection des chemins de routage DOIT (MUST) gérer les liaisons asymétriques.

[R06] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être robustes aux changements dynamiques de perte de liaisons.

Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être robustes aux variations de perte de liaison pour gérer la nature peu fiable des liaisons IEEE 802.15.4. Les liaisons typiques connectées aux nœuds LoWPAN peuvent ne pas être disponibles en permanence. Les variations de perte de liaison peuvent être dues à divers facteurs tels que le mouvement des nœuds, l'épuisement de la puissance/batterie, les cycles de sommeil, l'évanouissement du signal ou la réduction de la puissance du signal reçu, et les interférences, et peuvent entraîner la désactivation des liaisons pendant des périodes prolongées. Les protocoles de routage DEVRAIENT (SHOULD) gérer les caractéristiques de ces liaisons de manière adéquate.

[R07] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être conçus pour gérer correctement les tailles de trames possibles.

Dans certains LoWPAN, la taille maximale possible des paquets de contrôle est très limitée (jusqu'à 127 octets dans une seule trame MAC IEEE 802.15.4) car la couche MAC ne dispose pas de prise en charge native de la fragmentation et du réassemblage.

La taille maximale de trame signifie que de petits en-têtes et une faible surcharge de messages d'état DOIVENT (MUST) être imposés. Les paquets de contrôle DEVRAIENT (SHOULD) être suffisamment petits pour tenir dans une seule trame de couche liaison. Cependant, la flexibilité est toujours nécessaire lors de la construction de messages; la conception des messages DOIT (MUST) tenir compte de l'espace requis pour les en-têtes IPv6 standard et d'autres en-têtes (tels que les en-têtes de couche liaison et les en-têtes de couche d'adaptation), et DOIT (MUST) également pouvoir accueillir les options requises par d'autres protocoles de routage et les protocoles IETF existants.

5.3. Support of 6LoWPAN Characteristics (Support des caractéristiques 6LoWPAN)

Cette section considère les caractéristiques fondamentales du réseau qui peuvent affecter la conception des protocoles de routage 6LoWPAN.

[R08] La conception des protocoles de routage 6LoWPAN DEVRAIT (SHOULD) prendre en compte les modèles de trafic, la densité du réseau, les rôles ou fonctions possibles des nœuds, et l'utilisation et le nombre de différentes configurations de réseau.

Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être capables de gérer une variété de topologies LoWPAN différentes, telles que:

• Modèles de trafic point à point, point à multipoint, multipoint à point ou multipoint à multipoint
• Trafic de communication concentré en un seul point (par exemple, passerelle)
• Densité variable d'hôtes et de routeurs, rapport routeur-hôte variable
• La fonctionnalité du routeur peut être différente de la fonctionnalité de l'hôte ou peut être sur le même nœud
• Différentes fonctionnalités de nœuds, telles que les nœuds contraints et non contraints, ou les nœuds effectuant des fonctions telles que le routage, le relais, l'agrégation, etc.
• Différentes configurations de réseau, telles que pair à pair, étoile, réseaux maillés
• Formation dynamique de réseau et changements de topologie pendant la période post-déploiement (runtime)
• Taille de réseau variable; la taille des réseaux peut également être très diverse, allant de réseaux avec quelques nœuds à plusieurs centaines de nœuds ou plus
• Le partitionnement du réseau peut se produire et doit être géré

[R09] La métrique utilisée par les protocoles de routage 6LoWPAN DEVRAIT (SHOULD) prendre en considération les effets combinés des attributs de nœud et de liaison.

Il est important d'incorporer la qualité de liaison et les attributs de nœud dans les métriques de routage pour minimiser la consommation d'énergie et garantir une livraison réussie. Par exemple, le chemin le plus court avec le nombre minimum de sauts peut ne pas être le chemin le plus économe en énergie car il peut passer par des nœuds très congestionnés ou par des liaisons qui subissent plus d'erreurs et nécessitent donc plus de retransmissions.

Concernant les types de métriques, les métriques de routage devraient pouvoir représenter efficacement:

• Métriques de liaison: Indication de puissance du signal reçu (RSSI), Indication de qualité de liaison (LQI), Nombre de transmissions attendues (ETX), débit, latence
• Métriques de nœud: état (sommeil, éveillé, écoute), énergie restante, nombre de sauts, informations géographiques (par exemple, coordonnées GPS)
• Métriques composites (liaison et nœud)

D'autres métriques possibles DEVRAIENT (SHOULD) également être considérées, telles que:

• Fiabilité
• Robustesse
• Stabilité

[R10] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être conçus pour atteindre à la fois l'évolutivité et la longévité dans les 6LoWPAN.

Les exigences d'évolutivité et de longévité sont des caractéristiques fondamentales des LoWPAN:

• Évolutivité: Un LoWPAN peut ne contenir que quelques nœuds (par exemple, pour un réseau personnel ou un réseau corporel), mais peut également contenir un nombre beaucoup plus élevé de dispositifs (par exemple, surveillance d'une infrastructure urbaine ou d'une autoroute). Pour les applications domotiques, il est envisagé que le protocole de routage DOIVE (MUST) prendre en charge 250 dispositifs dans le réseau [RFC5826], tandis que les protocoles de routage pour les réseaux de capteurs à l'échelle métropolitaine DOIVENT (MUST) être capables de regrouper un grand nombre de nœuds de détection en régions contenant de l'ordre de 10^2 à 10^4 nœuds de détection chacune [RFC5548]. Il est donc nécessaire que les mécanismes de routage soient conçus pour être évolutifs pour fonctionner dans des réseaux de tailles diverses. Cependant, en raison d'un manque de taille de mémoire et de puissance de calcul, le routage 6LoWPAN peut limiter les entrées de transfert à un petit nombre, tel qu'un maximum de 32 entrées de table de routage. En particulier dans les grands réseaux, le mécanisme de routage DOIT (MUST) être conçu de telle sorte que le nombre de routeurs soit inférieur au nombre d'hôtes.

• Longévité: La procédure de réparation de route et les messages de contrôle associés NE DEVRAIENT PAS (SHOULD NOT) nuire à la consommation d'énergie globale des protocoles de routage.

[R11] La procédure de réparation de route et les messages de contrôle associés NE DEVRAIENT PAS (SHOULD NOT) nuire à la consommation d'énergie globale des protocoles de routage.

La réparation locale améliore le débit et la latence de bout en bout, en particulier dans les grands réseaux. Comme les routes sont réparées rapidement, moins de paquets de données sont abandonnés et un plus petit nombre de transmissions de paquets de protocole de routage sont nécessaires, car les routes peuvent être réparées sans découverte de route initiée par la source [Lee]. Une considération importante ici peut être d'éviter l'épuisement prématuré de l'énergie, même si cela compromet d'autres exigences.

[R12] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) permettre des topologies dynamiquement adaptatives et des nœuds mobiles. Lors du support de topologies dynamiques et de nœuds mobiles, la maintenance des routes devrait garder à l'esprit l'objectif d'un état de routage minimal et d'une surcharge minimale des messages de protocole de routage.

La mobilité topologique des nœuds peut être le résultat d'un mouvement physique et/ou d'un environnement radio changeant, ce qui rend très probable que la mobilité doive être gérée même dans un réseau avec des nœuds physiquement statiques. Les 6LoWPAN n'utilisent pas de protocole séparé pour maintenir la connectivité aux nœuds mobiles, mais s'attendent à ce que le protocole de routage le gère.

De plus, certains nœuds peuvent se déplacer d'un 6LoWPAN à un autre et sont censés devenir des membres fonctionnels de ce dernier 6LoWPAN dans un délai limité.

Les applications de surveillance de bâtiments, par exemple, ont un certain nombre d'exigences en matière de temps de récupération et de stabilisation pour la mobilité qui varient entre 5 et 20 secondes (Section 5.3.1 de [RFC5867]). Pour les applications plus interactives telles que celles utilisées dans les systèmes domotiques, où les utilisateurs fournissent des entrées et attendent un retour instantané, les exigences de mobilité sont également plus strictes et, pour les déplacements au sein d'un réseau, un temps de convergence inférieur à 0,5 seconde est généralement requis (Section 3.2 de [RFC5826]). Dans les environnements industriels, où l'équipement mobile (par exemple, les grues) se déplace, le protocole de routage doit prendre en charge des vitesses de véhicule allant jusqu'à 35 km/h [RFC5673]. Actuellement, les 6LoWPAN ne sont normalement pas utilisés pour une mobilité aussi rapide, mais l'association et la désassociation dynamiques DOIVENT (MUST) être prises en charge dans les 6LoWPAN.

Il existe plusieurs défis qui devraient être relevés par un protocole de routage 6LoWPAN afin de créer un routage robuste dans des environnements dynamiques:

• Nœuds mobiles changeant leur emplacement à l'intérieur d'un LoWPAN: Si le modèle de mouvement des nœuds est inconnu, la mobilité ne peut pas être facilement détectée ou distinguée par les protocoles de routage. Les nœuds mobiles peuvent être traités comme des nœuds qui disparaissent et réapparaissent ailleurs. Le suivi des modèles de mouvement augmente la complexité et peut être évité en gérant les nœuds mobiles à l'aide de mises à jour de route réactives.

• Déplacement d'un LoWPAN par rapport à d'autres LoWPAN (inter)connectés: Au sein de chaque réseau stub, (un ou plusieurs) nœuds de passerelle relativement puissants (6LBR) doivent être configurés pour gérer les LoWPAN mobiles.

• Nœuds rejoignant ou quittant définitivement le LoWPAN: Afin de faciliter les mises à jour de table de routage, de réduire la taille de ces mises à jour et de minimiser les messages de contrôle d'erreur, les nœuds quittant le réseau peuvent annoncer leur désassociation au routeur de périphérie le plus proche ou à un nœud spécifique (le cas échéant) qui se charge de l'association et de la désassociation locales.

[R13] Un protocole de routage 6LoWPAN DEVRAIT (SHOULD) prendre en charge divers modèles de trafic -- point à point, point à multipoint et multipoint à point -- tout en évitant un trafic multicast excessif dans un LoWPAN.

Les 6LoWPAN ont souvent des modèles de trafic point à multipoint ou multipoint à point. De nombreuses applications émergentes incluent également la communication point à point. Les protocoles de routage 6LoWPAN devraient être conçus en tenant compte du transfert de paquets depuis/vers plusieurs sources/destinations. Les documents actuels du groupe de travail ROLL expliquent que la charge de travail ou le modèle de trafic des cas d'utilisation pour les LoWPAN a tendance à être hautement structuré, contrairement aux transferts de données de n'importe quel point à n'importe quel point qui dominent les charges de travail typiques des clients et des serveurs. Dans de nombreux cas, l'exploitation d'une telle structure peut simplifier les problèmes difficiles découlant de contraintes de ressources ou de variations de connectivité.

5.4. Support of Security (Support de la sécurité)

La sécurité est une question critique pour les réseaux à faible consommation. Toute solution pour les protocoles de routage 6LoWPAN DEVRAIT (SHOULD) satisfaire les exigences de sécurité de base suivantes. Ces exigences DOIVENT (MUST) s'appliquer au mécanisme de routage et à l'échange de données réseau, tout en évitant une consommation d'énergie excessive et une utilisation de la puissance de traitement.

[R14] Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) prendre en charge les services d'intégrité des messages, d'authentification de la source des messages et de confidentialité des messages pour se défendre contre les menaces de routage.

Compte tenu de l'importance de la sécurité des protocoles de routage et de la nature des menaces de sécurité pour les 6LoWPAN (par exemple, comme décrit dans [ROLL-SEC]), les protocoles de routage DEVRAIENT (SHOULD) prendre en charge:

• L'intégrité des messages, pour empêcher la modification des messages de protocole par les nœuds intermédiaires
• L'authentification de la source des messages, pour empêcher les attaques d'usurpation d'identité provenant de sources falsifiées
• La confidentialité des messages, pour empêcher l'écoute passive

L'actualité des messages devrait également être prise en compte. Les messages obsolètes peuvent eux-mêmes constituer une forme d'attaque, auquel cas des services d'actualité au niveau de la couche application elle-même ou conjointement avec les fonctions de sécurité de la liaison de données sont utiles pour les 6LoWPAN.

Les protocoles de routage DOIVENT (MUST) être protégés contre les attaques telles que la relecture, l'injection, la modification, etc., qui peuvent conduire à des menaces incluant des boucles de routage ou de topologie, un déni de service ciblé sur des nœuds spécifiques, la génération de fausses informations de routage, l'épuisement des ressources ou le partitionnement du réseau [ROLL-SEC].

Le support de la sécurité sera une option et, s'il est activé, il se conformera à toutes les règles d'utilisation des protocoles de routage 6LoWPAN sécurisés. En mettant en œuvre la sécurité de la couche liaison (sécurité en mode CCM* tel que défini dans la sous-clause 7.6 de IEEE 802.15.4) et en ajoutant des mécanismes de sécurité et de vérification de l'intégrité des messages spécifiques au protocole de routage (tels que les horodatages ou les numéros de séquence), une résistance à la plupart des menaces de sécurité peut être obtenue.

La conception DOIT (MUST) tenir compte du coût des opérations lourdes que le protocole DOIT (MUST) effectuer. Par exemple, l'utilisation de clés publiques peut entraîner une consommation d'énergie plus élevée par rapport aux clés symétriques. Des solutions générales pour les opérations de sécurité nécessitant de grandes quantités d'état de nœud (telles que la gestion d'adresse/clé, l'authentification, l'établissement de clé de couche liaison) devraient être utilisées dans tous les protocoles LoWPAN pour économiser la surcharge. Les protocoles de routage 6LoWPAN DEVRAIENT (SHOULD) être conçus pour prendre en charge l'activation de ces fonctionnalités, et ces fonctionnalités elles-mêmes devraient veiller à ne pas consommer une puissance excessive.

5.5. Support of Mesh-Under Forwarding (Support du transfert mesh-under)

L'architecture 6LoWPAN actuelle permet le transfert multi-sauts via le routage mesh-under [RFC4944]. Une caractéristique clé de cette approche est que la capacité à prendre en charge le transfert mesh-under et le routage route-over peut être une exigence dans les protocoles 6LoWPAN. Mais la question de savoir si cela constitue une exigence pour les protocoles de routage 6LoWPAN reste ouverte. À cet égard, nous devons considérer les exigences pour ces deux approches différentes (l'une utilisant le routage IP, l'autre utilisant son propre mécanisme de transfert).

Le mécanisme de transfert mesh-under utilise des adresses de couche liaison (adresses MAC), il s'arrête donc à la frontière d'un sous-réseau IP. Lorsqu'il est utilisé conjointement avec le routage route-over qui utilise des adresses IPv6 et des tables de routage, il peut nécessiter des informations inter-couches, y compris sa propre table de transfert.

Pour cette raison, le mécanisme de transfert mesh-under peut fournir ses propres messages de maintenance de topologie et table de transfert pour les opérations associées. Cela peut être comparable aux fonctionnalités requises par les protocoles de routage route-over, qui sont utilisés pour la découverte de voisins/liaisons, la gestion des entrées de table de transfert, la maintenance de topologie et la découverte de chemin.

Par conséquent, une question clé est de savoir comment ces deux approches (route-over et mesh-under) devraient être combinées, comment elles peuvent fonctionner en coordination, évitant ainsi toute redondance ou problèmes d'interopérabilité qui pourraient survenir. Les travaux futurs devraient se concentrer spécifiquement sur ces questions architecturales.

5.6. Support of Management (Support de la gestion)

Pour la gestion de réseau, les exigences suivantes DEVRAIENT (SHOULD) être prises en compte.

Les LoWPAN peuvent nécessiter d'être configurés et initialisés dynamiquement, par exemple, après la mise sous tension d'une passerelle, elle ne sait pas quels nœuds appartiennent à son sous-réseau. La capacité des nœuds à rejoindre un réseau est intrinsèquement indépendante de la technologie de routage, bien que certains protocoles de routage puissent faciliter ce processus. Les protocoles de routage DEVRAIENT (SHOULD) prendre en charge l'initialisation et la configuration du réseau. Cela peut impliquer une interaction entre le protocole de routage et d'autres fonctions telles que l'attribution d'adresse, l'autoconfiguration et la découverte de voisins.

Pour la surveillance et le débogage, la capacité d'obtenir des paramètres de protocole de routage pertinents, la configuration actuelle et l'état actuel des fonctionnalités du routeur et de l'hôte est importante. Il devrait être possible d'obtenir des informations telles que les tables de routage, les tables de voisins, les comptages de messages et les informations de qualité de liaison. Des interfaces pour les fonctions de diagnostic, de détection de pannes, de surveillance et de rapport d'événements/alarmes devraient être envisagées. Bien que dans certains cas des protocoles et interfaces existants puissent être disponibles à cette fin, des solutions spécifiquement adaptées aux LoWPAN peuvent être nécessaires.

Parce que certains LoWPAN entrent généralement périodiquement en mode veille, il devrait être possible de contrôler le modèle de veille/réveil des nœuds afin que les informations puissent être collectées avec une latence inférieure.

La capacité à prendre en charge l'évolution du protocole de routage et à modifier les paramètres de routage en fonction des circonstances et des modèles de trafic est importante. Par exemple, il peut être nécessaire de sélectionner un type de métrique, d'ajuster les valeurs de temporisation ou de sélectionner/modifier le mode du protocole (s'il est pris en charge). Une possibilité consiste à basculer vers un protocole complètement différent. Cependant, cela peut ne pas être faisable en raison des exigences de taille de code. Les utilisateurs devraient pouvoir prendre en charge les implémentations de plusieurs protocoles de routage.

Les aspects de gestion supplémentaires suivants devraient être pris en compte:

• Capacités de gestion de dispositif et de configuration de topologie de nœud
• Gestion de la sécurité, y compris la gestion des clés
• Gestion du planning de sommeil
• Gestion de la qualité de service
• Réparation de chemin, détection de pannes et contrôle
• Intégration et coordination inter-couches