8. Routes Montantes

Cette section décrit comment RPL découvre et maintient les routes Montantes. Elle décrit l'utilisation des Objets d'Information DODAG (DIO), les messages utilisés pour découvrir et maintenir ces routes. Elle spécifie comment RPL génère et répond aux DIO. Elle décrit également les messages de Sollicitation d'Information DODAG (DIS), qui sont utilisés pour déclencher des transmissions DIO.

Comme mentionné dans la Section 3.2.8, les nœuds qui décident de rejoindre un DODAG DOIVENT provisionner au moins un parent DODAG comme route par défaut pour l'instance associée. Cette route par défaut permet à un paquet d'être transmis vers le Haut jusqu'à ce qu'il atteigne finalement un ancêtre commun à partir duquel il sera routé vers le Bas jusqu'à la destination. Si la destination n'est pas dans le DODAG, alors la racine du DODAG peut être en mesure de transmettre le paquet en utilisant une connectivité vers l'extérieur du DODAG ; si elle ne peut pas transmettre le paquet à l'extérieur, alors la racine du DODAG doit le rejeter.

Un message DIO peut également transporter des informations de routage explicites :

• DODAGID : Le DODAGID est une adresse IPv6 Globale ou Locale Unique de la racine. Un nœud qui rejoint un DODAG DEVRAIT provisionner une route hôte via un parent DODAG vers l'adresse utilisée par la racine comme DODAGID.

• Préfixe RIO : La racine PEUT placer une ou plusieurs options d'Information de Route (RIO) dans un message DIO. Le RIO est utilisé pour annoncer une route externe qui est accessible via la racine, associée à une préférence, comme présenté dans la Section 6.7.5, qui incorpore le RIO de [RFC4191]. Il est interprété comme une capacité de la racine par opposition à une annonce de routage, et il NE DOIT PAS être redistribué dans un autre protocole de routage bien qu'il DEVRAIT être utilisé par un routeur RPL d'entrée pour sélectionner un DODAG lorsqu'un paquet est injecté dans un domaine RPL depuis un nœud attaché à ce routeur RPL. Une Fonction Objectif PEUT utiliser les routes annoncées dans le RIO ou la préférence pour ces routes afin de favoriser un DODAG par rapport à un autre pour la même instance.

8.1. Règles de Base DIO

1. Pour les champs de Base DIO suivants, un nœud qui n'est pas une racine de DODAG DOIT annoncer les mêmes valeurs que son parent DODAG préféré (défini dans la Section 8.2.1). De cette façon, ces valeurs se propageront vers le Bas du DODAG sans changement et seront annoncées par chaque nœud qui a une route vers cette racine de DODAG. Ces champs sont les suivants :

   1. Ancré (G)
   2. Mode de Fonctionnement (MOP)
   3. Préférence DAG (Prf)
   4. Version
   5. RPLInstanceID
   6. DODAGID

2. Un nœud PEUT mettre à jour les champs suivants à chaque saut :

   1. Rang (Rank)
   2. DTSN

3. Le champ DODAGID défini par chaque racine DOIT être unique au sein de l'Instance RPL et DOIT être une adresse IPv6 routable appartenant à la racine.

8.2. Découverte et Maintenance des Routes Montantes

La découverte de route Montante permet à un nœud de rejoindre un DODAG en découvrant des voisins qui sont membres du DODAG d'intérêt et en identifiant un ensemble de parents. Les politiques exactes de sélection des voisins et des parents dépendent de l'implémentation et sont pilotées par l'OF. Cette section spécifie l'ensemble de règles que ces politiques doivent suivre pour l'interopérabilité.

8.2.1. Voisins et Parents au sein d'une Version de DODAG

Les algorithmes de découverte de route Montante et le traitement de RPL sont en termes de trois ensembles logiques de nœuds link-local. Premièrement, l'ensemble des voisins candidats est un sous-ensemble des nœuds qui peuvent être atteints via le multicast link-local. La sélection de cet ensemble dépend de l'implémentation et de l'OF. Deuxièmement, l'ensemble des parents est un sous-ensemble restreint de l'ensemble des voisins candidats. Enfin, le parent préféré est un membre de l'ensemble des parents qui est le prochain saut préféré dans les routes Montantes. Conceptuellement, le parent préféré est un parent unique ; bien que, cela puisse être un ensemble de plusieurs parents si ces parents sont également préférés et ont un Rang identique.

Plus précisément :

1. L'ensemble des parents DODAG DOIT être un sous-ensemble de l'ensemble des voisins candidats.

2. Une racine de DODAG DOIT avoir un ensemble de parents DODAG de taille zéro.

3. Un nœud qui n'est pas une racine de DODAG PEUT maintenir un ensemble de parents DODAG de taille supérieure ou égale à un.

4. Le parent DODAG préféré d'un nœud DOIT être un membre de son ensemble de parents DODAG.

5. Le Rang d'un nœud DOIT être supérieur à tous les éléments de son ensemble de parents DODAG.

6. Lorsque la Détection d'Inaccessibilité des Voisins (NUD) [RFC4861], ou un mécanisme équivalent, détermine qu'un voisin n'est plus accessible, un nœud RPL NE DOIT PAS considérer ce nœud dans l'ensemble des voisins candidats lors du calcul et de l'annonce des routes jusqu'à ce qu'il détermine qu'il est à nouveau accessible. Les routes passant par un voisin inaccessible DOIVENT être supprimées de la table de routage.

Ces règles garantissent qu'il existe un ordre partiel cohérent sur les nœuds au sein du DODAG. Tant que les Rangs des nœuds ne changent pas, le respect des règles ci-dessus garantit que la route de chaque nœud vers une racine de DODAG est sans boucle, car le Rang diminue à chaque saut vers la racine.

L'OF peut guider la sélection de l'ensemble des voisins candidats et de l'ensemble des parents, comme discuté dans [RFC6552].

8.2.2. Voisins et Parents à travers les Versions de DODAG

Les règles ci-dessus régissent une seule Version de DODAG. Les règles de cette section définissent comment RPL fonctionne lorsqu'il existe plusieurs Versions de DODAG.

8.2.2.1. Version de DODAG

1. Le tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) définit de manière unique une Version de DODAG. Chaque élément de l'ensemble de parents DODAG d'un nœud, tel que transmis par le dernier message DIO entendu de chaque parent DODAG, DOIT appartenir à la même Version de DODAG. Les éléments de l'ensemble des voisins candidats d'un nœud PEUVENT appartenir à différentes Versions de DODAG.

2. Un nœud est membre d'une Version de DODAG si chaque élément de son ensemble de parents DODAG appartient à cette Version de DODAG, ou si ce nœud est la racine du DODAG correspondant.

3. Un nœud NE DOIT PAS envoyer de DIO pour des Versions de DODAG dont il n'est pas membre.

4. Les racines de DODAG PEUVENT incrémenter le DODAGVersionNumber qu'elles annoncent et ainsi passer à une nouvelle Version de DODAG. Lorsqu'une racine de DODAG incrémente son DODAGVersionNumber, elle DOIT suivre les conventions de l'Arithmétique des Numéros de Série décrites dans la Section 7. Les événements déclenchant l'incrémentation du DODAGVersionNumber sont décrits plus loin dans cette section et dans la Section 18.

5. Au sein d'un DODAG donné, un nœud qui n'est pas une racine NE DOIT PAS annoncer un DODAGVersionNumber supérieur au DODAGVersionNumber le plus élevé qu'il a entendu. Supérieur est défini comme l'opérateur plus grand que dans la Section 7.

6. Une fois qu'un nœud a annoncé une Version de DODAG en envoyant un DIO, il NE DOIT PAS être membre d'une Version de DODAG précédente du même DODAG (c'est-à-dire, avec le même RPLInstanceID, le même DODAGID, et un DODAGVersionNumber inférieur). Inférieur est défini comme l'opérateur moins que dans la Section 7.

Lorsque l'ensemble de parents DODAG devient vide sur un nœud qui n'est pas une racine, (c'est-à-dire, le dernier parent a été supprimé, faisant en sorte que le nœud ne soit plus associé à ce DODAG), alors les informations du DODAG ne devraient pas être supprimées avant l'expiration d'un minuteur local spécifique à l'implémentation. Pendant l'intervalle précédant la suppression de l'état du « vieux » DODAG, le nœud sera en mesure d'observer si le DODAGVersionNumber a été incrémenté si de nouveaux parents apparaissent. Cela aidera à protéger contre la possibilité de boucles qui pourraient survenir si ce nœud devait par inadvertance rejoindre l'ancienne Version de DODAG dans son propre sous-DODAG précédent.

À mesure que le DODAGVersionNumber est incrémenté, une nouvelle Version de DODAG se propage vers l'extérieur depuis la racine du DODAG. Un parent qui annonce le nouveau DODAGVersionNumber ne peut pas appartenir au sous-DODAG d'un nœud annonçant un DODAGVersionNumber plus ancien. Par conséquent, un nœud peut ajouter en toute sécurité un parent de n'importe quel Rang avec un DODAGVersionNumber plus récent sans former de boucle.

Par exemple, supposons qu'un nœud a quitté un DODAG avec le DODAGVersionNumber N. Supposons qu'un nœud avait un sous-DODAG et a tenté d'empoisonner ce sous-DODAG en annonçant un Rang de INFINITE_RANK, mais ces annonces peuvent s'être perdues dans le LLN. Alors, si le nœud a observé un voisin candidat annonçant une position dans ce DODAG d'origine au DODAGVersionNumber N, ce voisin candidat pourrait possiblement avoir été dans l'ancien sous-DODAG du nœud, et il existe un cas possible où l'ajout de ce voisin candidat comme parent pourrait causer une boucle. Dans ce cas, si ce voisin candidat est observé comme annonçant un DODAGVersionNumber N+1, alors ce voisin candidat est certain d'être sûr, puisqu'il est certain de ne pas être dans le sous-DODAG du nœud d'origine, car il a pu incrémenter le DODAGVersionNumber en entendant la racine du DODAG pendant que ce nœud d'origine était détaché. Pour cette raison, il est utile pour le nœud détaché de se souvenir des informations du DODAG d'origine, y compris le DODAGVersionNumber N.

Le moment exact où une racine de DODAG incrémente le DODAGVersionNumber dépend de l'implémentation et est hors de portée de cette spécification. Les exemples incluent l'incrémentation du DODAGVersionNumber périodiquement, lors d'une intervention administrative, ou lors de la détection au niveau de l'application d'une perte de connectivité ou d'une inefficacité du DODAG.

Après qu'un nœud a transitionné vers et annoncé une nouvelle Version de DODAG, les règles ci-dessus le rendent incapable d'annoncer la Version de DODAG précédente (DODAGVersionNumber antérieur) une fois qu'il s'est engagé à annoncer la nouvelle Version de DODAG.

8.2.2.2. Racines de DODAG

1. Une racine de DODAG sans possibilité de satisfaire l'objectif défini par l'application NE DOIT PAS définir le bit Ancré (Grounded).

2. Une racine de DODAG DOIT annoncer un Rang de ROOT_RANK.

3. Un nœud dont l'ensemble de parents DODAG est vide PEUT devenir la racine de DODAG d'un DODAG flottant. Il PEUT également définir sa DAGPreference de telle sorte qu'il soit moins préféré.

Dans un déploiement qui utilise des liens non-LLN pour fédérer un certain nombre de racines LLN, il est possible d'exécuter RPL sur ces liens non-RPL et d'utiliser un routeur comme « racine de dorsale ». La racine de dorsale est la racine virtuelle du DODAG et expose un Rang de BASE_RANK sur la dorsale. Toutes les racines LLN qui sont apparentées à cette racine de dorsale, y compris la racine de dorsale si elle sert également de racine LLN elle-même, exposent un Rang de ROOT_RANK au LLN. Ces racines virtuelles font partie du même DODAG et annoncent le même DODAGID. Elles coordonnent les DODAGVersionNumbers et d'autres paramètres DODAG avec la racine virtuelle sur la dorsale. La méthode de coordination est hors de portée de cette spécification (à définir dans de futures spécifications compagnons).

8.2.2.3. Sélection de DODAG

La Fonction Objectif et l'ensemble de métriques de routage annoncées et de contraintes d'un DAG déterminent comment un nœud sélectionne son ensemble de voisins, son ensemble de parents, et ses parents préférés. Cette sélection détermine implicitement aussi le DODAG au sein d'un DAG. Une telle sélection peut inclure une préférence administrative (Prf) ainsi que des métriques ou d'autres considérations.

Si un nœud a l'option de rejoindre un DODAG plus préféré tout en respectant d'autres objectifs d'optimisation, alors le nœud cherchera généralement à rejoindre le DODAG plus préféré tel que déterminé par l'OF. Toutes choses étant égales par ailleurs, il est laissé à l'implémentation de déterminer quel DODAG est le plus préféré (puisque, pour rappel, un nœud ne doit rejoindre qu'un seul DODAG par Instance RPL).

8.2.2.4. Rang et Mouvement au sein d'une Version de DODAG

1. Un nœud NE DOIT PAS annoncer un Rang inférieur ou égal à tout membre de son ensemble de parents au sein de la Version de DODAG.

2. Un nœud PEUT annoncer un Rang inférieur à son annonce précédente au sein de la Version de DODAG.

3. Soit L le Rang le plus bas au sein d'une Version de DODAG qu'un nœud donné a annoncé. Au sein de la même Version de DODAG, ce nœud NE DOIT PAS annoncer un Rang effectif supérieur à L + DAGMaxRankIncrease. INFINITE_RANK est une exception à cette règle : un nœud PEUT annoncer un INFINITE_RANK au sein d'une Version de DODAG sans restriction. Si le Rang d'un nœud devait être supérieur à ce qui est autorisé par L + DAGMaxRankIncrease, lorsqu'il annonce le Rang, il DOIT annoncer son Rang comme INFINITE_RANK.

4. Un nœud PEUT, à tout moment, choisir de rejoindre un DODAG différent au sein d'une Instance RPL. Un tel rattachement n'a pas de restrictions de Rang, à moins que ce DODAG différent soit une Version de DODAG dont ce nœud a précédemment été membre ; auquel cas, la règle du point précédent (3) doit être observée. Jusqu'à ce qu'un nœud transmette un DIO indiquant sa nouvelle appartenance au DODAG, il DOIT transmettre les paquets le long du DODAG précédent.

5. Un nœud PEUT, à tout moment après avoir entendu le prochain DODAGVersionNumber annoncé par des parents DODAG appropriés, choisir de migrer vers la prochaine Version de DODAG au sein du DODAG.

Conceptuellement, une implémentation maintient un ensemble de parents DODAG au sein de la Version de DODAG. Le mouvement implique des changements à l'ensemble de parents DODAG. Se déplacer vers le Haut ne présente pas le risque de créer une boucle mais se déplacer vers le Bas le pourrait, donc cette opération est soumise à des contraintes supplémentaires.

Lorsqu'un nœud migre vers la prochaine Version de DODAG, l'ensemble de parents DODAG a besoin d'être reconstruit pour la nouvelle Version. Une implémentation pourrait différer la migration pendant un certain temps raisonnable, pour voir si d'autres voisins avec des métriques potentiellement meilleures mais un Rang plus élevé s'annoncent. De même, lorsqu'un nœud saute dans un nouveau DODAG, il a besoin de construire un nouvel ensemble de parents DODAG pour ce nouveau DODAG.

Si un nœud a besoin de se déplacer vers le Bas d'un DODAG auquel il est attaché, augmentant son Rang, alors il PEUT empoisonner ses routes et attendre avant de se déplacer comme décrit dans la Section 8.2.2.5.

Un nœud est autorisé à rejoindre n'importe quelle Version de DODAG dont il n'a jamais été un membre précédent sans aucune restriction, mais si le nœud a été un membre précédent de la Version de DODAG, alors il doit continuer à observer la règle selon laquelle il ne peut pas annoncer un Rang supérieur à L+DAGMaxRankIncrease à tout moment de la vie de la Version de DODAG. Cette règle doit être observée afin de ne pas créer une échappatoire qui permettrait au nœud d'incrémenter effectivement son Rang jusqu'à INFINITE_RANK, ce qui peut avoir un impact sur d'autres nœuds et créer un scénario de comptage à l'infini gaspillant des ressources.

8.2.2.5. Empoisonnement (Poisoning)

1. Un nœud empoisonne les routes en annonçant un Rang de INFINITE_RANK.

2. Un nœud NE DOIT PAS avoir de nœuds avec un Rang de INFINITE_RANK dans son ensemble de parents.

Bien qu'une implémentation puisse annoncer INFINITE_RANK à des fins d'empoisonnement, le faire n'est pas la même chose que de définir le Rang à INFINITE_RANK. Par exemple, un nœud peut continuer à envoyer des paquets de données dont l'Information de Paquet RPL inclut un Rang qui n'est pas INFINITE_RANK, tout en annonçant INFINITE_RANK dans ses DIO.

Lorsqu'un (ancien) parent est observé comme annonçant un Rang de INFINITE_RANK, cet (ancien) parent s'est détaché du DODAG et n'est plus capable d'agir comme un parent, et il n'y a aucun moyen qu'un autre nœud puisse être considéré comme ayant un Rang supérieur à INFINITE_RANK. Par conséquent, cet (ancien) parent ne peut plus agir comme un parent et est supprimé de l'ensemble de parents.

8.2.2.6. Détachement

1. Un nœud incapable de rester connecté à un DODAG au sein d'une Version de DODAG donnée, c'est-à-dire, qui ne peut pas conserver un ensemble de parents non vide sans violer les règles de cette spécification, PEUT se détacher de cette Version de DODAG. Un nœud qui se détache devient la racine de son propre DODAG flottant et DEVRAIT annoncer immédiatement cette nouvelle situation dans un DIO comme alternative à l'empoisonnement.

8.2.2.7. Suivre un Parent

1. Si un nœud reçoit un DIO de l'un de ses parents DODAG, indiquant que le parent a quitté le DODAG, ce nœud DEVRAIT rester dans son DODAG actuel via un parent DODAG alternatif, si possible. Il PEUT suivre le parent qui part.

Un parent DODAG peut avoir bougé, migré vers la prochaine Version de DODAG, ou sauté vers un DODAG différent. Un nœud devrait donner une certaine préférence à rester dans le DODAG actuel, si possible via un parent alternatif, mais devrait suivre le parent s'il n'y a pas d'autres options.

8.2.3. Communication des Messages DIO

Lorsqu'un message DIO est reçu, le nœud récepteur doit d'abord déterminer si le message DIO doit être accepté ou non pour un traitement ultérieur, et présenter ensuite le message DIO pour un traitement ultérieur s'il est éligible.

1. Si le message DIO est mal formé, alors le message DIO n'est pas éligible pour un traitement ultérieur et un nœud DOIT le rejeter silencieusement. (Voir la Section 18 pour la journalisation des erreurs).

2. Si l'expéditeur du message DIO est un membre de l'ensemble des voisins candidats et que le message DIO n'est pas mal formé, le nœud DOIT traiter le DIO.

8.2.3.1. Traitement des Messages DIO

À mesure que les messages DIO sont reçus des voisins candidats, les voisins peuvent être promus parents DODAG en suivant les règles de découverte de DODAG telles que décrites dans la Section 8.2. Lorsqu'un nœud place un voisin dans l'ensemble de parents DODAG, le nœud devient attaché au DODAG via le nouveau nœud parent DODAG.

Le parent le plus préféré devrait être utilisé pour restreindre quels autres nœuds peuvent devenir des parents DODAG. Certains nœuds dans l'ensemble de parents DODAG peuvent être d'un Rang inférieur ou égal au parent DODAG le plus préféré. (Ce cas peut se produire, par exemple, si un appareil à énergie contrainte est à un Rang inférieur mais devrait être évité selon un objectif d'optimisation, résultant en un parent plus préféré à un Rang supérieur.)

8.3. Transmission DIO

Les nœuds RPL transmettent des DIO en utilisant un minuteur Trickle [RFC6206]. Un DIO d'un expéditeur avec un DAGRank inférieur qui ne cause aucun changement à l'ensemble de parents, au parent préféré ou au Rang du destinataire DEVRAIT être considéré comme cohérent par rapport au minuteur Trickle.

Les paquets et événements suivants DOIVENT être considérés comme des incohérences par rapport au minuteur Trickle, et provoquer la réinitialisation du minuteur Trickle :

• Lorsqu'un nœud détecte une incohérence lors du transfert d'un paquet, comme détaillé dans la Section 11.2.

• Lorsqu'un nœud reçoit un message DIS multicast sans option d'Information Sollicitée, à moins qu'un drapeau DIS ne restreigne ce comportement.

• Lorsqu'un nœud reçoit un DIS multicast avec une option d'Information Sollicitée et que le nœud correspond à tous les prédicats dans l'option d'Information Sollicitée, à moins qu'un drapeau DIS ne restreigne ce comportement.

• Lorsqu'un nœud rejoint une nouvelle Version de DODAG (par exemple, en mettant à jour son DODAGVersionNumber, en rejoignant une nouvelle Instance RPL, etc.).

Notez que cette liste n'est pas exhaustive, et une implémentation PEUT considérer d'autres messages ou événements comme étant des incohérences.

Un nœud NE DEVRAIT PAS réinitialiser son minuteur Trickle DIO en réponse à des messages DIS unicast. Lorsqu'un nœud reçoit un DIS unicast sans option d'Information Sollicitée, il DOIT envoyer un DIO unicast à l'expéditeur en réponse. Ce DIO DOIT inclure une option de Configuration DODAG. Lorsqu'un nœud reçoit un message DIS unicast avec une option d'Information Sollicitée et correspond aux prédicats de cette option d'Information Sollicitée, il DOIT envoyer un DIO unicast à l'expéditeur en réponse. Ce DIO unicast DOIT inclure une option de Configuration DODAG. Ainsi, un nœud PEUT transmettre un message DIS unicast à un parent DODAG potentiel afin de sonder la Configuration DODAG et d'autres paramètres.

8.3.1. Paramètres Trickle

Les paramètres de configuration du minuteur Trickle sont spécifiés comme suit :

• Imin : appris du message DIO comme (2^DIOIntervalMin) ms. La valeur par défaut de DIOIntervalMin est DEFAULT_DIO_INTERVAL_MIN.

• Imax : appris du message DIO comme DIOIntervalDoublings. La valeur par défaut de DIOIntervalDoublings est DEFAULT_DIO_INTERVAL_DOUBLINGS.

• k : appris du message DIO comme DIORedundancyConstant. La valeur par défaut de DIORedundancyConstant est DEFAULT_DIO_REDUNDANCY_CONSTANT. Dans RPL, lorsque k a la valeur de 0x00, cela doit être traité comme une constante de redondance infinie dans RPL, c'est-à-dire que Trickle ne supprime jamais les messages.

8.4. Sélection de DODAG

La sélection de DODAG dépend de l'implémentation et de l'OF. Afin de limiter les mouvements erratiques, et toutes métriques étant égales, les nœuds DEVRAIENT conserver leur sélection précédente. Aussi, les nœuds DEVRAIENT fournir un moyen de filtrer un parent dont la disponibilité est détectée comme fluctuante, au moins lorsque des choix plus stables sont disponibles.

Lorsque la connexion à un DODAG ancré n'est pas possible ou préférable pour des raisons de sécurité ou autres, des DODAG dispersés PEUVENT s'agréger autant que possible en DODAG plus grands afin de permettre la connectivité au sein du LLN.

Un nœud DEVRAIT vérifier que la connectivité bidirectionnelle et une qualité de lien adéquate sont disponibles avec un voisin candidat avant de considérer ce candidat comme un parent DODAG.

8.5. Fonctionnement en tant que Nœud Feuille

Dans certains cas, un nœud RPL peut s'attacher à un DODAG en tant que nœud feuille uniquement. Un exemple d'un tel cas est lorsqu'un nœud ne comprend pas ou ne supporte pas (politique) l'OF de l'Instance RPL ou la métrique/contrainte annoncée. Comme spécifié dans la Section 18.6, liée à la fonction de politique, le nœud peut soit rejoindre le DODAG en tant que nœud feuille soit ne pas rejoindre le DODAG. Comme mentionné dans la Section 18.5, il est alors recommandé de journaliser une faute.

Un nœud feuille n'étend pas la connectivité du DODAG ; cependant, dans certains cas, le nœud feuille peut encore avoir besoin de transmettre des DIO à l'occasion, en particulier, lorsque le nœud feuille n'a pas toujours agi en tant que nœud feuille et qu'une incohérence est détectée.

Un nœud opérant en tant que nœud feuille doit obéir aux règles suivantes :

1. Il NE DOIT PAS transmettre de DIO contenant le Conteneur de Métrique DAG.

2. Ses DIO DOIVENT annoncer un DAGRank de INFINITE_RANK.

3. Il PEUT supprimer la transmission DIO, à moins que la transmission DIO n'ait été déclenchée en raison de la détection d'une incohérence lorsqu'un paquet est transféré ou en réponse à un message DIS unicast, auquel cas la transmission DIO NE DOIT PAS être supprimée.

4. Il PEUT transmettre des DAO unicast comme décrit dans la Section 9.2.

5. Il PEUT transmettre des DAO multicast au voisinage « 1 saut » comme décrit dans la Section 9.10.

Un cas particulier qui nécessite qu'un nœud feuille envoie un DIO est si ce nœud feuille était un membre précédent d'un autre DODAG et qu'un autre nœud transfère un message en supposant l'ancienne topologie, déclenchant une incohérence. Le nœud feuille a besoin de transmettre un DIO afin de réparer l'incohérence. Notez qu'en raison de la nature avec perte des LLN, même si le nœud feuille peut avoir empoisonné ses routes de manière optimiste en annonçant un Rang de INFINITE_RANK dans l'ancien DODAG avant de devenir un nœud feuille, cette annonce peut s'être perdue et un nœud feuille doit être capable d'envoyer un DIO plus tard afin de réparer l'incohérence.

Dans le cas général, le nœud feuille NE DOIT PAS s'annoncer comme un routeur (c'est-à-dire, envoyer des DIO).

8.6. Rang Administratif

Dans certains cas, il pourrait être bénéfique d'ajuster le Rang annoncé par un nœud au-delà de celui calculé par l'OF sur la base d'une politique spécifique à l'implémentation et des propriétés du nœud. Par exemple, un nœud qui a une batterie limitée devrait être une feuille à moins qu'il n'y ait pas d'autre choix, et peut alors augmenter le calcul de Rang spécifié par l'OF afin d'exposer un Rang exagéré.