8.2.2. Voisins et parents à travers les versions DODAG

Les règles ci-dessus régissent une seule version DODAG. Les règles de cette section définissent comment RPL fonctionne lorsqu'il y a plusieurs versions DODAG.

8.2.2.1. Version DODAG

1. Le tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) définit de manière unique une version 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 DODAG. Les éléments de l'ensemble de voisins candidats d'un nœud PEUVENT appartenir à différentes versions DODAG.

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

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

4. Les racines DODAG PEUVENT incrémenter le DODAGVersionNumber qu'elles annoncent et ainsi passer à une nouvelle version DODAG. Lorsqu'une racine DODAG incrémente son DODAGVersionNumber, elle DOIT suivre les conventions de Serial Number Arithmetic comme décrit à la Section 7. Les événements déclenchant l'incrémentation du DODAGVersionNumber sont décrits plus loin dans cette section et à 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 supérieur-à dans la Section 7.

6. Une fois qu'un nœud a annoncé une version DODAG en envoyant un DIO, il NE DOIT PAS être membre d'une version 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 inférieur-à 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 que le dernier parent a été supprimé, faisant que le nœud n'est plus associé à ce DODAG), les informations DODAG ne doivent pas être supprimées avant l'expiration d'un temporisateur local spécifique à l'implémentation. Pendant l'intervalle précédant la suppression de l'"ancien" état DODAG, le nœud sera capable d'observer si le DODAGVersionNumber a été incrémenté si de nouveaux parents apparaissent. Cela aidera à protéger contre la possibilité de boucles qui peuvent se produire si ce nœud devait rejoindre par inadvertance l'ancienne version DODAG dans son propre sous-DODAG antérieur.

Lorsque le DODAGVersionNumber est incrémenté, une nouvelle version DODAG se propage vers l'extérieur depuis la racine 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 tout Rank avec un DODAGVersionNumber plus récent sans former de boucle.

Par exemple, supposons qu'un nœud ait 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 Rank de INFINITE_RANK, mais ces annonces peuvent avoir été perdues dans le LLN. Ensuite, si le nœud observait un voisin candidat annonçant une position dans ce DODAG original au DODAGVersionNumber N, ce voisin candidat pourrait éventuellement 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 provoquer une boucle. Dans ce cas, si ce voisin candidat est observé en train d'annoncer un DODAGVersionNumber N+1, alors ce voisin candidat est certain d'être sûr, car il est certain de ne pas être dans le sous-DODAG de ce nœud original, car il a pu incrémenter le DODAGVersionNumber en entendant la racine DODAG pendant que ce nœud original était détaché. Pour cette raison, il est utile pour le nœud détaché de se souvenir des informations DODAG originales, y compris le DODAGVersionNumber N.

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

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

8.2.2.2. Racines DODAG

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

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

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

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 backbone". La racine de backbone est la racine virtuelle du DODAG et expose un Rank de BASE_RANK sur le backbone. Toutes les racines LLN qui sont parentes de cette racine de backbone, y compris la racine de backbone elle-même si elle sert également de racine LLN, exposent un Rank 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 autres paramètres DODAG avec la racine virtuelle sur le backbone. La méthode de coordination sort du cadre de cette spécification (à définir dans les spécifications complémentaires futures).

8.2.2.3. Sélection DODAG

La Fonction Objectif et l'ensemble des métriques et contraintes de routage annoncées 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 également implicitement le DODAG au sein d'un DAG. Une telle sélection peut inclure la 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 répondant à 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 égales par ailleurs, il appartient à l'implémentation de déterminer quel DODAG est le plus préféré (car, pour rappel, un nœud ne doit rejoindre qu'un seul DODAG par instance RPL).

8.2.2.4. Rank et mouvement au sein d'une version DODAG

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

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

3. Soit L le Rank le plus bas au sein d'une version DODAG qu'un nœud donné a annoncé. Au sein de la même version DODAG, ce nœud NE DOIT PAS annoncer un Rank 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 DODAG sans restriction. Si le Rank d'un nœud devait être supérieur à ce qui est autorisé par L + DAGMaxRankIncrease, lorsqu'il annonce le Rank, il DOIT annoncer son Rank 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 Rank, à moins que ce DODAG différent ne soit une version DODAG dont ce nœud a été précédemment membre; dans ce 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 DODAG, il DOIT transférer les paquets le long du DODAG précédent.

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

Conceptuellement, une implémentation maintient un ensemble de parents DODAG au sein de la version DODAG. Le mouvement implique des changements dans 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 pourrait, de sorte que cette opération est soumise à des contraintes supplémentaires.

Lorsqu'un nœud migre vers la version DODAG suivante, l'ensemble de parents DODAG doit ê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 Rank plus élevé s'annoncent. De même, lorsqu'un nœud saute dans un nouveau DODAG, il doit construire un nouvel ensemble de parents DODAG pour ce nouveau DODAG.

Si un nœud doit se déplacer vers le bas dans un DODAG auquel il est attaché, augmentant son Rank, alors il PEUT empoisonner ses routes et retarder avant de se déplacer comme décrit dans la Section 8.2.2.5.

Un nœud est autorisé à rejoindre toute version DODAG dont il n'a jamais été membre précédemment sans aucune restriction, mais si le nœud a été membre précédent de la version DODAG, alors il doit continuer à observer la règle selon laquelle il ne peut pas annoncer un Rank supérieur à L+DAGMaxRankIncrease à tout moment de la vie de la version DODAG. Cette règle doit être observée afin de ne pas créer une faille qui permettrait au nœud d'incrémenter effectivement son Rank 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 les ressources.

8.2.2.5. Empoisonnement

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

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

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

Lorsqu'un (ancien) parent est observé en train d'annoncer un Rank de INFINITE_RANK, cet (ancien) parent s'est détaché du DODAG et n'est plus capable d'agir comme parent, et il n'y a aucun moyen qu'un autre nœud puisse être considéré comme ayant un Rank supérieur à INFINITE_RANK. Par conséquent, cet (ancien) parent ne peut plus agir comme parent et est retiré 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 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 DODAG. Un nœud qui se détache devient la racine de son propre DODAG flottant et DEVRAIT immédiatement annoncer 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 déménagé, migré vers la version DODAG suivante 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.