9. Routes Descendantes

Cette section décrit comment RPL découvre et maintient les routes Descendantes. RPL construit et maintient des routes Descendantes avec des messages d'Objet d'Annonce de Destination (DAO). Les routes Descendantes supportent les flux P2MP, des racines DODAG vers les feuilles. Les routes Descendantes supportent également les flux P2P : les messages P2P peuvent circuler vers une racine DODAG (ou un ancêtre commun) via une route Montante, puis s'éloigner de la racine DODAG vers une destination via une route Descendante.

Cette spécification décrit les deux modes qu'une Instance RPL peut choisir pour maintenir les routes Descendantes. Dans le premier mode, appelé « Stockage » (Storing), les nœuds stockent les tables de routage Descendantes pour leur sous-DODAG. Chaque saut sur une route Descendante dans un réseau de stockage examine sa table de routage pour décider du prochain saut. Dans le second mode, appelé « Non-Stockage » (Non-Storing), les nœuds ne stockent pas les tables de routage Descendantes. Les paquets descendants sont routés avec des routes sources peuplées par une racine DODAG [RFC6554].

RPL permet une optimisation P2P simple à un saut pour les réseaux de stockage et de non-stockage. Un nœud peut envoyer un paquet P2P destiné à un voisin à un saut directement à ce nœud.

9.1. Parents d'Annonce de Destination

Pour établir des routes Descendantes, les nœuds RPL envoient des messages DAO vers le Haut. Les destinations de saut suivant de ces messages DAO sont appelées « parents DAO ». La collection des parents DAO d'un nœud est appelée l'« ensemble de parents DAO ».

1. Un nœud PEUT envoyer des messages DAO en utilisant l'adresse multicast de tous les nœuds RPL, ce qui est une optimisation pour provisionner le routage à un saut. Le bit 'K' DOIT être effacé lors de la transmission du DAO multicast.

2. L'ensemble de parents DAO d'un nœud DOIT être un sous-ensemble de son ensemble de parents DODAG.

3. En mode de fonctionnement Stockage, un nœud NE DOIT PAS adresser de messages DAO unicast à des nœuds qui ne sont pas des parents DAO.

4. En mode de fonctionnement Stockage, les adresses IPv6 source et destination d'un message DAO DOIVENT être des adresses link-local.

5. En mode de fonctionnement Non-Stockage, un nœud NE DOIT PAS adresser de messages DAO unicast à des nœuds qui ne sont pas des racines DODAG.

6. En mode de fonctionnement Non-Stockage, les adresses IPv6 source et destination d'un message DAO DOIVENT être une adresse locale unique ou globale.

La sélection des parents DAO est spécifique à l'implémentation et à la Fonction Objectif.

9.2. Découverte et Maintenance des Routes Descendantes

L'Annonce de Destination peut être configurée pour être entièrement désactivée, ou fonctionner en mode Stockage ou Non-Stockage, comme indiqué dans le MOP du message DIO.

1. Tous les nœuds qui rejoignent un DODAG DOIVENT respecter le paramètre MOP de la racine. Les nœuds qui n'ont pas la capacité de participer pleinement en tant que routeur, par exemple, qui ne correspondent pas au MOP annoncé, PEUVENT rejoindre le DODAG en tant que feuille.

2. Si le MOP est 0, indiquant aucun routage Descendant, les nœuds NE DOIVENT PAS transmettre de messages DAO et PEUVENT ignorer les messages DAO.

3. En mode Non-Stockage, la racine DODAG DEVRAIT stocker les entrées de table de routage source pour les destinations apprises des DAO. La racine DODAG DOIT être capable de générer des routes sources pour ces destinations apprises des DAO qui ont été stockées.

4. En mode Stockage, tous les nœuds non-racine et non-feuille DOIVENT stocker les entrées de table de routage pour les destinations apprises des DAO.

Un DODAG peut avoir l'un des plusieurs modes de fonctionnement possibles, tels que définis par le champ MOP. Soit il ne supporte pas les routes Descendantes, soit il supporte les routes Descendantes via le routage source à partir des racines DODAG, soit il supporte les routes Descendantes via des tables de routage dans le réseau.

Lorsque les routes Descendantes sont supportées via le routage source à partir des racines DODAG, il est généralement attendu que la racine DODAG ait stocké les informations de routage source apprises des DAO afin de construire les routes sources. Si la racine DODAG ne parvient pas à stocker certaines informations, alors certaines destinations peuvent être inaccessibles.

Lorsque les routes Descendantes sont supportées via des tables de routage dans le réseau, l'opération multicast définie dans cette spécification peut ou non être supportée, également comme indiqué par le champ MOP.

Lorsque les routes Descendantes sont supportées via des tables de routage dans le réseau, comme décrit dans cette spécification, il est attendu que les nœuds agissant en tant que routeurs aient été suffisamment provisionnés pour contenir l'état de table de routage requis. Si un nœud agissant en tant que routeur est incapable de contenir l'état complet de la table de routage, alors l'état de routage n'est pas complet, des messages peuvent être rejetés en conséquence, et une faute peut être journalisée (Section 18.5). Les futures extensions de RPL peuvent élaborer sur des actions/comportements raffinés pour gérer ce cas.

Au moment de la rédaction de cette spécification, RPL ne supporte pas le fonctionnement en mode mixte, où certains nœuds effectuent un routage source et d'autres stockent des tables de routage : de futures extensions de RPL peuvent supporter ce mode de fonctionnement.

9.2.1. Maintenance de la Séquence de Chemin

Pour chaque Cible qui est associée à (possédée par) un nœud, ce nœud est responsable d'émettre des messages DAO afin de provisionner les routes Descendantes. Les informations Cible+Transit contenues dans ces messages DAO se propagent ensuite vers le Haut du DODAG. Le compteur de Séquence de Chemin dans l'option d'information de Transit est utilisé pour indiquer la fraîcheur et mettre à jour les informations de routage Descendantes obsolètes comme décrit dans la Section 7.

Pour une Cible qui est associée à (possédée par) un nœud, ce nœud DOIT incrémenter le compteur de Séquence de Chemin, et générer un nouveau message DAO, lorsque :

1. la Durée de Vie du Chemin doit être mise à jour (par exemple, un rafraîchissement ou un no-Path).

2. la liste des sous-champs Adresse Parent DODAG doit être modifiée.

Pour une Cible qui est associée à (possédée par) un nœud, ce nœud PEUT incrémenter le compteur de Séquence de Chemin, et générer un nouveau message DAO, à l'occasion afin de rafraîchir les informations de routage Descendantes. En mode Stockage, le nœud génère un tel DAO pour chacun de ses parents DAO afin de permettre le multichemin. Tous les DAO générés en même temps pour la même Cible DOIVENT être envoyés avec la même Séquence de Chemin dans les Informations de Transit.

9.2.2. Génération des Messages DAO

Un nœud peut envoyer des messages DAO lorsqu'il reçoit des messages DAO, à la suite de changements dans son ensemble de parents DAO, ou en réponse à un autre événement tel que l'expiration d'une durée de vie de préfixe associée. Dans le cas de la réception de DAO, il importe de savoir si le message DAO est « nouveau » ou contient de nouvelles informations. En mode Non-Stockage, chaque message DAO qu'un nœud reçoit est « nouveau ». En mode Stockage, un message DAO est « nouveau » s'il satisfait l'un de ces critères pour une Cible contenue :

1. il a un numéro de Séquence de Chemin plus récent,

2. il a des bits de Contrôle de Chemin supplémentaires, ou

3. c'est un message DAO No-Path qui supprime la dernière route Descendante vers un préfixe.

Un nœud qui reçoit un message DAO de son sous-DODAG PEUT supprimer la planification d'une transmission de message DAO si ce message DAO n'est pas nouveau.

9.3. Règles de Base DAO

1. Si un nœud envoie un message DAO avec des informations plus récentes ou différentes de la transmission de message DAO précédente, il DOIT incrémenter le champ DAOSequence d'au moins un. Une transmission de message DAO qui est identique à la transmission de message DAO précédente PEUT incrémenter le champ DAOSequence.

2. Les champs RPLInstanceID et DODAGID d'un message DAO DOIVENT être la même valeur que les membres de l'ensemble de parents du nœud et les DIO qu'il transmet.

3. Un nœud PEUT définir le drapeau 'K' dans un message DAO unicast pour solliciter un DAO-ACK unicast en réponse afin de confirmer la tentative.

4. Un nœud recevant un message DAO unicast avec le drapeau 'K' défini DEVRAIT répondre avec un DAO-ACK. Un nœud recevant un message DAO sans le drapeau 'K' défini PEUT répondre avec un DAO-ACK, en particulier pour signaler une condition d'erreur.

5. Un nœud qui définit le drapeau 'K' dans un message DAO unicast mais ne reçoit pas de DAO-ACK en réponse PEUT replanifier la transmission du message DAO pour une autre tentative, jusqu'à un nombre de tentatives spécifique à l'implémentation.

6. Les nœuds DEVRAIENT ignorer les DAO sans numéros de séquence plus récents et NE DOIVENT PAS les traiter davantage.

Contrairement au champ Version d'un DIO, qui est incrémenté uniquement par une racine DODAG et répété sans changement par les autres nœuds, les valeurs DAOSequence sont uniques à chaque nœud. L'espace de numéros de séquence pour les messages DAO unicast et multicast peut être le même ou distinct. Il est RECOMMANDÉ d'utiliser le même espace de numéros de séquence.

9.4. Structure des Messages DAO

Les DAO suivent une structure commune dans les réseaux de stockage et de non-stockage. Dans la forme la plus générale, un message DAO peut inclure plusieurs groupes d'options, où chaque groupe consiste en une ou plusieurs options Cible suivies d'une ou plusieurs options d'Information de Transit.

Le groupe entier d'options d'Information de Transit s'applique au groupe entier d'options Cible. Les sections suivantes décrivent plus de détails pour chaque mode de fonctionnement.

1. Les nœuds RPL DOIVENT inclure une ou plusieurs options Cible RPL dans chaque message DAO qu'ils transmettent. Une option Cible RPL DOIT avoir un préfixe qui inclut l'adresse IPv6 du nœud si ce nœud a besoin que le DODAG provisionne des routes Descendantes vers ce nœud. L'option Cible RPL PEUT être immédiatement suivie d'une option Descripteur de Cible RPL opaque qui la qualifie.

2. Lorsqu'un nœud met à jour les informations dans une option d'Information de Transit pour une option Cible qui couvre l'une de ses adresses, il DOIT incrémenter le numéro de Séquence de Chemin dans cette option d'Information de Transit. Le numéro de Séquence de Chemin PEUT être incrémenté occasionnellement pour provoquer un rafraîchissement des routes Descendantes.

3. Une ou plusieurs options Cible RPL dans un message DAO unicast DOIVENT être suivies d'une ou plusieurs options d'Information de Transit. Toutes les options de transit s'appliquent à toutes les options Cible qui les précèdent immédiatement.

4. Les DAO multicast NE DOIVENT PAS inclure le sous-champ Adresse Parent DODAG dans les options d'Information de Transit.

5. Un nœud qui reçoit et traite un message DAO contenant des informations pour une Cible spécifique, et qui a des informations antérieures pour cette Cible, DOIT utiliser le numéro de Séquence de Chemin dans l'option d'Information de Transit associée à cette Cible afin de déterminer si le message DAO contient ou non des informations mises à jour selon la Section 7.

6. Si un nœud reçoit un message DAO qui ne suit pas les règles ci-dessus, il DOIT rejeter le message DAO sans traitement supplémentaire.

En mode Non-Stockage, la racine construit un en-tête de routage source strict, saut par saut, en recherchant récursivement des informations à un saut qui lient une Cible (adresse ou préfixe) et une adresse de transit ensemble. Dans certains cas, lorsqu'une adresse enfant est dérivée d'un préfixe qui est possédé et annoncé par un parent, cette relation parent-enfant peut être déduite par la racine dans le but de construire l'en-tête de routage source. Dans tous les autres cas, il est nécessaire d'informer la racine de la relation transit-Cible à partir d'une cible accessible, afin de permettre ultérieurement la construction récursive de l'en-tête de routage. Une adresse qui est annoncée comme Cible dans un message DAO DOIT être colocalisée dans le même routeur, ou accessible sur le lien par le routeur qui possède l'adresse qui est indiquée dans l'Information de Transit associée. Les règles supplémentaires suivantes s'appliquent pour assurer la continuité du chemin de routage source de bout en bout :

1. L'adresse d'un parent utilisée dans l'option de transit DOIT être prise d'un PIO de ce parent avec le drapeau 'R' défini. Le drapeau 'R' dans un PIO indique que le champ préfixe contient en fait l'adresse complète du parent mais l'enfant NE DEVRAIT PAS supposer que l'adresse du parent est sur le lien.

2. Un PIO avec un drapeau 'A' défini indique que le nœud enfant RPL peut utiliser le préfixe pour autoconfigurer une adresse. Un parent qui annonce un préfixe dans un PIO avec le drapeau 'A' défini DOIT s'assurer que l'adresse ou le préfixe entier dans le PIO est accessible depuis la racine en l'annonçant comme cible DAO. Si le parent définit également le drapeau 'L' indiquant que le préfixe est sur le lien, alors il DOIT annoncer le préfixe entier comme Cible dans un message DAO. Si le drapeau 'L' est effacé et que le drapeau 'R' est défini, indiquant que le parent fournit sa propre adresse dans le PIO, alors le parent DOIT annoncer cette adresse comme cible DAO.

3. Une adresse qui est annoncée comme Cible dans un message DAO DOIT être colocalisée dans le même routeur ou accessible sur le lien par le routeur qui possède l'adresse qui est indiquée dans l'Information de Transit associée.

4. Afin de permettre une compression optimale de l'en-tête de routage, le parent DEVRAIT définir le drapeau 'R' dans tous les PIO avec le drapeau 'A' défini et le drapeau 'L' effacé, et l'enfant DEVRAIT préférer utiliser comme transit l'adresse du parent qui se trouve dans le PIO qui est utilisé pour autoconfigurer l'adresse qui est annoncée comme Cible dans le message DAO.

5. Un routeur pourrait avoir des cibles qui ne sont pas connues pour être sur le lien pour un parent, soit parce qu'elles sont des adresses situées sur une interface alternative ou parce qu'elles appartiennent à des nœuds qui sont externes à RPL, par exemple des hôtes connectés. Afin d'injecter une telle Cible dans le réseau RPL, le routeur DOIT s'annoncer lui-même comme le sous-champ Adresse Parent DODAG dans l'option d'Information de Transit pour cette cible, en utilisant une adresse qui est sur le lien pour le parent DAO de ce nœud. Si la Cible appartient à un nœud externe, alors le routeur DOIT définir le drapeau Externe 'E' dans l'Information de Transit.

Un nœud enfant qui a autoconfiguré une adresse à partir d'un PIO parent avec le drapeau 'L' défini n'a pas besoin d'annoncer cette adresse comme Cible DAO puisque le parent assure que le préfixe entier est déjà accessible depuis la racine. Cependant, si le drapeau 'L' n'est pas défini, alors il est nécessaire, en mode Non-Stockage, pour le nœud enfant d'informer la racine de la relation parent-enfant, en utilisant une adresse accessible du parent, afin de permettre la construction récursive de l'en-tête de routage. Cela se fait en associant une adresse du parent comme transit avec l'adresse de l'enfant comme Cible dans un message DAO.

9.5. Planification de la Transmission DAO

Parce que les DAO circulent vers le Haut, la réception d'un DAO unicast peut déclencher l'envoi d'un DAO unicast à un parent DAO.

1. À la réception d'un message DAO unicast avec des informations mises à jour, telles que contenant une option d'Information de Transit avec une nouvelle Séquence de Chemin, un nœud DEVRAIT envoyer un DAO. Il NE DEVRAIT PAS envoyer ce message DAO immédiatement. Il DEVRAIT retarder l'envoi du message DAO afin d'agréger les informations DAO d'autres nœuds pour lesquels il est un parent DAO.

2. Un nœud DEVRAIT retarder l'envoi d'un message DAO avec un minuteur (DelayDAO). La réception d'un message DAO démarre le minuteur DelayDAO. Les messages DAO reçus pendant que le minuteur DelayDAO est actif ne réinitialisent pas le minuteur. Lorsque le minuteur DelayDAO expire, le nœud envoie un DAO.

3. Lorsqu'un nœud ajoute un nœud à son ensemble de parents DAO, il DEVRAIT planifier une transmission de message DAO.

La valeur et le calcul de DelayDAO dépendent de l'implémentation. Une valeur par défaut de DEFAULT_DAO_DELAY est définie dans cette spécification.

9.6. Déclenchement des Messages DAO

Les nœuds peuvent déclencher leur sous-DODAG pour envoyer des messages DAO. Chaque nœud maintient un Numéro de Séquence de Déclenchement DAO (DTSN), qu'il communique via des messages DIO.

1. Si un nœud entend l'un de ses parents DAO incrémenter son DTSN, le nœud DOIT planifier une transmission de message DAO en utilisant les règles des Sections 9.3 et 9.5.

2. En mode Non-Stockage, si un nœud entend l'un de ses parents DAO incrémenter son DTSN, le nœud DOIT incrémenter son propre DTSN.

Dans un mode de fonctionnement Stockage, dans le cadre des mises à jour et de la maintenance de routine de la table de routage, un nœud de stockage PEUT incrémenter le DTSN afin de déclencher de manière fiable un ensemble de mises à jour DAO de ses enfants immédiats.

Dans un mode de fonctionnement Stockage, il n'est pas nécessaire de déclencher des mises à jour DAO de l'ensemble du sous-DODAG, puisque cette information d'état se propagera saut par saut vers le Haut du DODAG.

Dans un mode de fonctionnement Non-Stockage, une incrémentation du DTSN amènera également les enfants immédiats d'un nœud à incrémenter leur DTSN à leur tour, déclenchant un ensemble de mises à jour DAO de l'ensemble du sous-DODAG. Typiquement, dans un mode de fonctionnement Non-Stockage, seule la racine incrémenterait indépendamment le DTSN lorsqu'un rafraîchissement DAO est nécessaire mais qu'une réparation globale (telle que par l'incrémentation du DODAGVersionNumber) n'est pas souhaitée. Typiquement, dans un mode de fonctionnement Non-Stockage, tous les nœuds non-racine incrémenteraient leur DTSN uniquement lorsque leur(s) parent(s) sont observés en train de le faire.

En général, un nœud peut déclencher des mises à jour DAO selon une logique spécifique à l'implémentation, telle que basée sur la détection d'une incohérence de route Descendante ou occasionnellement basée sur un minuteur interne.

Dans un réseau de stockage, la sélection d'un DelayDAO approprié pour les DAO déclenchés peut réduire considérablement le nombre de DAO transmis. Le déclencheur circule vers le Bas du DODAG ; dans le meilleur cas, les DAO circulent vers le Haut du DODAG de telle sorte que les feuilles envoient les DAO en premier, chaque nœud envoyant un message DAO une seule fois. Une telle planification pourrait être approximée en définissant DelayDAO inversement proportionnel au Rang. Notez que cette suggestion est destinée à être une optimisation pour permettre une agrégation efficace (elle n'est pas requise pour un fonctionnement correct dans le cas général).

9.7. Mode Non-Stockage

En mode Non-Stockage, RPL route les messages vers le Bas en utilisant le routage source IP. La règle suivante s'applique aux nœuds qui sont en mode Non-Stockage. Le mode Stockage a un ensemble de règles distinct, décrit dans la Section 9.8.

1. Le sous-champ Adresse Parent DODAG d'une option d'Information de Transit DOIT contenir une ou plusieurs adresses. Toutes ces adresses DOIVENT être des adresses de parents DAO de l'expéditeur.

2. Les DAO sont envoyés directement à la racine le long d'une route par défaut installée dans le cadre de la sélection des parents.

3. Lorsqu'un nœud supprime un nœud de son ensemble de parents DAO, il PEUT générer un nouveau message DAO avec une option d'Information de Transit mise à jour.

En mode Non-Stockage, un nœud utilise les DAO pour signaler ses parents DAO à la racine DODAG. La racine DODAG peut reconstituer une route Descendante vers un nœud en utilisant les ensembles de parents DAO de chaque nœud de la route. Les informations de Séquence de Chemin peuvent être utilisées pour détecter des informations DAO obsolètes. Le but de ce calcul de route par saut est de minimiser le trafic lorsque les parents DAO changent. Si les nœuds signalaient des routes sources complètes, alors lors d'un changement de parent DAO, l'ensemble du sous-DODAG devrait envoyer de nouveaux DAO à la racine DODAG. Par conséquent, en mode Non-Stockage, un nœud peut envoyer un seul DAO, bien qu'il puisse choisir d'envoyer plus d'un message DAO à chacun des multiples parents DAO.

Les nœuds emballent les DAO en envoyant un seul message DAO avec plusieurs options Cible RPL. Chaque option Cible RPL a ses propres options d'Information de Transit qui la suivent immédiatement.

9.8. Mode Stockage

En mode Stockage, RPL route les messages vers le Bas par l'adresse de destination IPv6. Les règles suivantes s'appliquent aux nœuds qui sont en mode Stockage :

1. Le sous-champ Adresse Parent DODAG d'une option d'Information de Transmission DOIT être vide.

2. À la réception d'un DAO unicast, un nœud DOIT calculer si le DAO changerait l'ensemble de préfixes que le nœud lui-même annonce. Ce calcul DEVRAIT inclure la consultation des informations de Séquence de Chemin dans les options d'Information de Transit associées au DAO, pour déterminer si le message DAO contient des informations plus récentes qui remplacent les informations déjà stockées au niveau du nœud. Si c'est le cas, le nœud DOIT générer un nouveau message DAO et le transmettre, en suivant les règles de la Section 9.5. Un tel changement inclut la réception d'un DAO No-Path.

3. Lorsqu'un nœud génère un nouveau DAO, il DEVRAIT l'envoyer en unicast à chacun de ses parents DAO. Il NE DOIT PAS envoyer le message DAO en unicast à des nœuds qui ne sont pas des parents DAO.

4. Lorsqu'un nœud supprime un nœud de son ensemble de parents DAO, il DEVRAIT envoyer un message DAO No-Path (Section 6.4.3) à ce parent DAO supprimé pour invalider la route existante.

5. Si les messages vers une adresse Descendante annoncée souffrent d'une erreur de transfert, d'une Détection d'Inaccessibilité de Voisin (NUD), ou d'une défaillance similaire, un nœud PEUT marquer l'adresse comme inaccessible et générer un DAO No-Path approprié.

Les DAO annoncent vers quelles adresses de destination et préfixes un nœud a des routes. Contrairement au mode Non-Stockage, ces DAO ne communiquent pas d'informations sur les routes elles-mêmes : cette information est stockée au sein du réseau et est implicite à partir de l'adresse source IPv6. Lorsqu'un nœud de stockage génère un DAO, il utilise l'état stocké des DAO qu'il a reçus pour produire un ensemble d'options Cible RPL et leurs options d'Information de Transmission associées.

Parce que cette information est stockée dans les tables de routage de chaque nœud, en mode Stockage, les DAO sont communiqués directement aux parents DAO, qui stockent cette information.

9.9. Contrôle de Chemin

Un message DAO d'un nœud contient une ou plusieurs options Cible. Chaque option Cible spécifie soit un préfixe annoncé par le nœud, un préfixe d'adresses accessibles en dehors du LLN, l'adresse d'une destination dans le sous-DODAG du nœud, ou un groupe multicast auquel un nœud dans le sous-DODAG écoute. Le champ Contrôle de Chemin de l'option d'Information de Transit permet aux nœuds de demander ou de permettre plusieurs routes Descendantes. Un nœud construit le champ Contrôle de Chemin d'une option d'Information de Transit comme suit :

1. La largeur de bits du champ Contrôle de Chemin DOIT être égale à la valeur (PCS + 1), où PCS est spécifié dans le champ de contrôle de l'option Configuration DODAG. Les bits supérieurs ou égaux à la valeur (PCS + 1) DOIVENT être effacés lors de la transmission et DOIVENT être ignorés lors de la réception. Les bits inférieurs à cette valeur sont considérés comme des bits « actifs ».

2. Le nœud DOIT construire logiquement des groupements de ses parents DAO tout en peuplant le champ Contrôle de Chemin, où chaque groupe consiste en des parents DAO de préférence égale. Ces groupes DOIVENT ensuite être ordonnés selon la préférence, ce qui permet un mappage logique des parents DAO sur les sous-champs de Contrôle de Chemin (voir Figure 27). Les groupes PEUVENT être répétés afin de s'étendre sur toute la largeur de bits du champ de contrôle de chemin, mais l'ordre, y compris les groupes répétés, DOIT être conservé afin que la préférence soit correctement communiquée.

3. Pour une option Cible RPL décrivant la propre adresse d'un nœud ou un préfixe en dehors du LLN, au moins un bit actif du champ Contrôle de Chemin DOIT être défini. Plus de bits actifs du champ Contrôle de Chemin PEUVENT être définis.

4. Si un nœud reçoit plusieurs DAO avec la même option Cible RPL, il DOIT effectuer un OU binaire sur les champs Contrôle de Chemin qu'il reçoit. Ce OU binaire agrégé représente le nombre de routes Descendantes que le préfixe demande.

5. Lorsqu'un nœud envoie un message DAO à l'un de ses parents DAO, il DOIT sélectionner un ou plusieurs des bits qui sont définis actifs dans le sous-champ qui est mappé au groupe contenant ce parent DAO à partir du champ Contrôle de Chemin agrégé. Un bit donné ne peut être présenté comme actif qu'à un seul parent. Le message DAO qu'il transmet à son parent DOIT avoir ces bits actifs définis et tous les autres bits actifs effacés.

6. Pour l'option Cible RPL et le numéro DAOSequence, les DAO qu'un nœud envoie à différents parents DAO DOIVENT avoir des ensembles disjoints de bits de Contrôle de Chemin actifs. Un nœud NE DOIT PAS définir le même bit actif sur des DAO vers deux parents DAO différents.

7. Les bits de Contrôle de Chemin DEVRAIENT être alloués selon le mappage de préférence des parents DAO sur les sous-champs de Contrôle de Chemin, de sorte que les bits de Contrôle de Chemin actifs, ou groupements de bits, qui appartiennent à un sous-champ de Contrôle de Chemin particulier sont alloués aux parents DAO au sein du groupe qui a été mappé à ce sous-champ.

8. Dans un mode de fonctionnement Non-Stockage, un nœud PEUT passer les DAO sans effectuer de traitement supplémentaire sur le champ Contrôle de Chemin.

9. Un nœud NE DOIT PAS envoyer en unicast un message DAO qui n'a aucun bit actif défini dans le champ Contrôle de Chemin. Il est possible que, pour une option Cible donnée, un nœud n'ait pas assez de bits de Contrôle de Chemin agrégés pour envoyer un message DAO contenant cette Cible à chacun de ses parents DAO, auquel cas ces Parents DAO les moins préférés peuvent ne pas recevoir de message DAO pour cette Cible.

Le champ Contrôle de Chemin permet à un nœud de limiter combien de routes Descendantes seront générées vers lui. Il définit un nombre de bits dans le champ Contrôle de Chemin égal au nombre maximum de routes Descendantes qu'il préfère. Au plus, chaque bit est envoyé à un parent DAO ; des grappes de bits peuvent être envoyées à un seul parent DAO pour qu'il les divise parmi ses propres parents DAO.

Un nœud qui provisionne une route DAO pour une Cible qui a un champ Contrôle de Chemin associé DEVRAIT utiliser le contenu de ce champ Contrôle de Chemin afin de déterminer un ordre de préférence parmi plusieurs routes DAO alternatives pour cette Cible. L'attribution du champ Contrôle de Chemin est dérivée de la préférence (des parents DAO), telle que déterminée sur la base de la meilleure connaissance de ce nœud des métriques agrégées « bout en bout » dans la direction Descendante selon la Fonction Objectif. En mode Non-Stockage, la racine peut déterminer la route Descendante en agrégeant les informations de chaque DAO reçu, ce qui inclut les indications de Contrôle de Chemin des parents DAO préférés.

9.9.1. Exemple de Contrôle de Chemin

Supposons qu'il y ait un LLN fonctionnant en mode Stockage qui contient un Nœud N avec quatre parents, P1, P2, P3, et P4. Soit N ayant trois enfants, C1, C2, et C3 dans son sous-DODAG. Soit PCS égal à 7, de sorte qu'il y aura 8 bits actifs dans le champ Contrôle de Chemin : 11111111b. Considérez l'exemple suivant :

Le champ Contrôle de Chemin est divisé en quatre sous-champs, PC1 (11000000b), PC2 (00110000b), PC3 (00001100b), et PC4 (00000011b), de sorte que ces quatre sous-champs représentent quatre niveaux de préférence différents selon la Figure 27. L'implémentation au Nœud N, dans cet exemple, groupe {P1, P2} pour être de préférence égale l'un à l'autre et le groupe le plus préféré globalement. {P3} est moins préféré que {P1, P2}, et plus préféré que {P4}. Soit le Nœud N effectuant ensuite son mappage de Contrôle de Chemin de telle sorte que :

       {P1, P2} -> PC1 (11000000b) dans le champ Contrôle de Chemin
       {P3}     -> PC2 (00110000b) dans le champ Contrôle de Chemin
       {P4}     -> PC3 (00001100b) dans le champ Contrôle de Chemin
       {P4}     -> PC4 (00000011b) dans le champ Contrôle de Chemin

Notez que l'implémentation a répété {P4} afin d'obtenir une couverture complète du champ Contrôle de Chemin.

1. Soit C1 envoyant un DAO contenant une Cible T avec un Contrôle de Chemin 10000000b. Le Nœud N stocke une entrée associant 10000000b avec le champ Contrôle de Chemin pour C1 et la Cible T.

2. Soit C2 envoyant un DAO contenant une Cible T avec un Contrôle de Chemin 00010000b. Le Nœud N stocke une entrée associant 00010000b avec le champ Contrôle de Chemin pour C1 et la Cible T.

3. Soit C3 envoyant un DAO contenant une Cible T avec un Contrôle de Chemin 00001100b. Le Nœud N stocke une entrée associant 00001100b avec le champ Contrôle de Chemin pour C1 et la Cible T.

4. À un moment ultérieur, le Nœud N génère un DAO pour la Cible T. Le Nœud N construira un champ Contrôle de Chemin agrégé en effectuant un OU sur la contribution de chacun de ses enfants qui ont donné un DAO pour la Cible T. Ainsi, le champ Contrôle de Chemin agrégé a les bits actifs définis comme : 10011100b.

5. Le Nœud N distribue ensuite les bits de Contrôle de Chemin agrégés parmi ses parents P1, P2, P3, et P4 afin de préparer les messages DAO.

6. P1 et P2 sont éligibles pour recevoir des bits actifs du sous-champ le plus préféré (11000000b). Ces bits sont 10000000b dans le champ Contrôle de Chemin agrégé. Le Nœud N doit définir le bit à un seul des deux parents. Dans ce cas, le Nœud P1 se voit allouer le bit et obtient le champ Contrôle de Chemin 10000000b pour son DAO. Il n'y a plus de bits à allouer au Nœud P2 ; ainsi, le Nœud P2 aurait un champ Contrôle de Chemin de 00000000b et un DAO ne peut pas être généré vers le Nœud P2 puisqu'il n'y a pas de bits actifs.

7. Le deuxième sous-champ le plus préféré (00110000b) a les bits actifs 00010000b. Le Nœud N a mappé P3 à ce sous-champ. Le Nœud N peut allouer le bit actif à P3, construisant un DAO pour P3 contenant la Cible T avec un Contrôle de Chemin de 00010000b.

8. Le troisième sous-champ le plus préféré (00001100b) a les bits actifs 00001100b. Le Nœud N a mappé P4 à ce sous-champ. Le Nœud N peut allouer les deux bits à P4, construisant un DAO pour P4 contenant la Cible T avec un Contrôle de Chemin de 00001100b.

9. Le sous-champ le moins préféré (00000011b) n'a pas de bits actifs. S'il y avait eu des bits actifs, ces bits auraient été ajoutés au champ Contrôle de Chemin du DAO construit pour P4.

10. Le processus de peuplement des messages DAO destinés à P1, P2, P3, P4 avec d'autres cibles (autres que T) procède selon les champs Contrôle de Chemin agrégés collectés pour ces cibles.

9.10. Messages d'Annonce de Destination Multicast

Un cas particulier de l'opération DAO, distinct de l'opération DAO unicast, est l'opération DAO multicast qui peut être utilisée pour peupler les entrées de table de routage à « 1 saut ».

1. Un nœud PEUT envoyer en multicast un message DAO à l'adresse multicast de tous les nœuds RPL de portée link-local.

2. Un message DAO multicast DOIT être utilisé uniquement pour annoncer des informations sur le nœud lui-même, c'est-à-dire, des préfixes directement connectés ou possédés par le nœud, tels qu'un groupe multicast auquel le nœud est abonné ou une adresse globale possédée par le nœud.

3. Un message DAO multicast NE DOIT PAS être utilisé pour relayer des informations de connectivité apprises (par exemple, via un DAO unicast) d'un autre nœud.

4. Un nœud NE DOIT PAS effectuer d'autre traitement lié au DAO sur un message DAO multicast reçu ; en particulier, un nœud NE DOIT PAS effectuer les actions d'un parent DAO à la réception d'un DAO multicast.

• Le DAO multicast peut être utilisé pour permettre une communication P2P directe, sans avoir besoin que le DODAG relaye les paquets.