11. Transfert de Paquets et Évitement/Détection de Boucles

11.1. Suggestions pour le Transfert de Paquets

Ce document spécifie un protocole de routage. Ces suggestions non normatives sont fournies pour aider à la conception d'une implémentation de transfert en illustrant comment une telle implémentation pourrait fonctionner avec RPL.

Lors du transfert d'un paquet vers une destination, la priorité est donnée à la sélection d'un successeur de saut suivant comme suit :

1. Cette spécification couvre uniquement comment un successeur est sélectionné à partir de la version DODAG qui correspond au RPLInstanceID marqué dans l'en-tête IPv6 du paquet transféré. Le routage en dehors de l'instance peut être effectué tant que des règles supplémentaires sont mises en place, telles que l'ordre strict des instances et des protocoles de routage pour protéger contre les boucles. De telles règles peuvent être définies dans un document séparé.

2. Si une préférence administrative locale favorise une route qui a été apprise à partir d'un protocole de routage différent de RPL, alors utilisez ce successeur.

3. Si l'en-tête du paquet spécifie une route source en incluant un en-tête RH4 tel que spécifié dans [RFC6554], alors utilisez cette route. Si le nœud ne parvient pas à transférer le paquet avec cette route source spécifiée, alors ce paquet devrait être rejeté. Le nœud PEUT enregistrer une erreur. Le nœud peut envoyer un message d'erreur ICMPv6 dans l'en-tête de routage source à la source du paquet (voir Section 20.18).

4. S'il existe une entrée dans la table de routage correspondant à la destination qui a été apprise à partir d'une annonce de destination multicast (par exemple, la destination est un voisin à un saut), alors utilisez ce successeur.

5. S'il existe une entrée dans la table de routage correspondant à la destination qui a été apprise à partir d'une annonce de destination unicast (par exemple, la destination est située en bas du sous-DODAG), alors utilisez ce successeur. S'il existe des bits de contrôle de chemin DAO associés à plusieurs successeurs, consultez les bits de contrôle de chemin pour ordonner les successeurs par préférence lors du choix. Si, pour un bit de contrôle de chemin DAO donné, plusieurs successeurs sont enregistrés comme ayant affirmé ce bit, la priorité devrait être donnée au successeur qui a affirmé ce bit le plus récemment.

6. S'il existe une version DODAG offrant une route vers un préfixe correspondant à la destination, alors sélectionnez l'un de ces parents DODAG comme successeur selon l'OF et les métriques de routage.

7. Tout autre parent DODAG non encore tenté peut être choisi pour la prochaine tentative de transfert d'un paquet unicast lorsqu'aucune meilleure correspondance n'existe.

8. Enfin, le paquet est rejeté. ICMP Destination Inaccessible PEUT être invoqué (une incohérence est détectée).

La limite de sauts (Hop Limit) DOIT être décrémentée lors du transfert selon [RFC2460].

Notez que le successeur choisi NE DOIT PAS être le voisin qui était le prédécesseur du paquet (horizon partagé), sauf dans le cas où il est prévu que le paquet change d'une direction ascendante à une direction descendante, comme déterminé par la table de routage du nœud effectuant le changement, tel que le passage des routes DIO aux routes DAO à l'approche de la destination afin de continuer à voyager vers la destination.

11.2. Évitement et Détection de Boucles

Les mécanismes d'évitement de boucles RPL sont maintenus simples et conçus pour minimiser l'agitation et les états. Des boucles peuvent se former pour un certain nombre de raisons, par exemple, la perte de paquets de contrôle. RPL inclut une technique de détection de boucle réactive qui protège contre l'effondrement et déclenche la réparation des chemins rompus.

La détection de boucle RPL utilise les informations de paquet RPL qui sont transportées dans les paquets de données, s'appuyant sur un mécanisme externe tel que [RFC6553] qui place les informations de paquet RPL dans un en-tête d'option IPv6 saut par saut.

Le contenu des informations de paquet RPL est défini comme suit :

• Down 'O' : Drapeau de 1 bit indiquant si le paquet est censé progresser vers le haut ou vers le bas. Un routeur définit le drapeau 'O' lorsque le paquet est censé progresser vers le bas (en utilisant les routes DAO), et l'efface lors du transfert vers la racine du DODAG (vers un nœud de rang inférieur). Un hôte ou un nœud feuille RPL DOIT définir le drapeau 'O' à 0.

• Rank-Error 'R' : Drapeau de 1 bit indiquant si une erreur de rang a été détectée. Une erreur de rang est détectée lorsqu'il y a une inadéquation dans les rangs relatifs et la direction indiquée dans le bit 'O'. Un hôte ou un nœud feuille RPL DOIT définir le bit 'R' à 0.

• Forwarding-Error 'F' : Drapeau de 1 bit indiquant que ce nœud ne peut pas transférer le paquet plus loin vers la destination. Le bit 'F' peut être défini par un nœud enfant qui n'a pas de route vers la destination pour un paquet avec le bit Down 'O' défini. Un hôte ou un nœud feuille RPL DOIT définir le bit 'F' à 0.

• RPLInstanceID : Champ de 8 bits indiquant l'instance DODAG le long de laquelle le paquet est envoyé.

• SenderRank : Champ de 16 bits mis à zéro par la source et à DAGRank(rank) par un routeur qui transfère à l'intérieur du réseau RPL.

11.2.1. Opération du Nœud Source

Si la source connaît le RPLInstanceID qui est préféré pour le paquet, alors elle DOIT définir le champ RPLInstanceID associé au paquet en conséquence ; sinon, elle DOIT le définir à RPL_DEFAULT_INSTANCE.

11.2.2. Opération du Routeur

11.2.2.1. Transfert d'Instance

Le RPLInstanceID est associé par la source au paquet. Ce RPLInstanceID DOIT correspondre à l'instance RPL sur laquelle le paquet est placé par n'importe quel nœud, qu'il s'agisse d'un hôte ou d'un routeur. Le RPLInstanceID fait partie des informations de paquet RPL.

Un routeur RPL qui transfère un paquet dans le réseau RPL DOIT vérifier si le paquet inclut les informations de paquet RPL. Sinon, alors le routeur RPL DOIT insérer les informations de paquet RPL. Si le routeur est un routeur d'entrée qui injecte le paquet dans le réseau RPL, le routeur DOIT définir le champ RPLInstanceID dans les informations de paquet RPL. Les détails de la façon dont ce routeur détermine le mappage vers un RPLInstanceID sont hors de portée de cette spécification et laissés à une spécification future.

Un routeur qui transfère un paquet en dehors du réseau RPL DOIT supprimer les informations de paquet RPL.

Lorsqu'un routeur reçoit un paquet qui spécifie un RPLInstanceID donné et que le nœud peut transférer le paquet le long du DODAG associé à cette instance, alors le routeur DOIT le faire et laisser la valeur RPLInstanceID inchangée.

Si un nœud ne peut pas transférer un paquet le long du DODAG associé au RPLInstanceID, alors le nœud DEVRAIT rejeter le paquet et envoyer un message d'erreur ICMP.

11.2.2.2. Détection de Boucle d'Incohérence DAG

Le DODAG est incohérent si la direction d'un paquet ne correspond pas à la relation de rang. Un récepteur détecte une incohérence s'il reçoit un paquet avec soit :

• le bit 'O' défini (vers le bas) provenant d'un nœud de rang supérieur.

• le bit 'O' effacé (pour le haut) provenant d'un nœud de rang inférieur.

Lorsque la racine du DODAG incrémente le DODAGVersionNumber, une discontinuité de rang temporaire peut se former entre la version DODAG suivante et la version DODAG précédente, en particulier si les nœuds ajustent leur rang dans la version DODAG suivante et diffèrent leur migration vers la version DODAG suivante. Un routeur qui est encore membre de la version DODAG précédente peut choisir de transférer un paquet à un (futur) parent qui est dans la version DODAG suivante. Dans certains cas, cela pourrait amener le parent à détecter une incohérence car l'ordre des rangs dans la version DODAG précédente n'est pas nécessairement le même que dans la version DODAG suivante, et le paquet peut être jugé comme ne progressant pas. Si le routeur expéditeur sait que le successeur choisi a déjà rejoint la version DODAG suivante, alors le routeur expéditeur DOIT mettre à jour le SenderRank à INFINITE_RANK lorsqu'il transfère les paquets à travers la discontinuité dans la version DODAG suivante afin d'éviter une fausse détection d'incohérence de rang.

Une incohérence le long du chemin n'est pas considérée comme une erreur critique et le paquet peut continuer. Cependant, une seconde détection le long du chemin du même paquet ne devrait pas se produire et le paquet DOIT être rejeté.

Ce processus est contrôlé par le bit Rank-Error associé au paquet. Lorsqu'une incohérence est détectée sur un paquet, si le bit Rank-Error n'était pas défini, alors le bit Rank-Error est défini. S'il était défini, le paquet DOIT être rejeté et le temporisateur Trickle DOIT être réinitialisé.

11.2.2.3. Détection et Récupération d'Incohérence DAO

La récupération de boucle d'incohérence DAO est un mécanisme qui s'applique uniquement au mode de fonctionnement avec stockage (Storing mode).

En mode sans stockage (Non-Storing mode), les paquets sont routés par la source vers la destination, et les incohérences DAO ne sont pas corrigées localement. Au lieu de cela, une erreur ICMP avec un nouveau code "Erreur dans l'en-tête de routage source" est renvoyée à la racine. Le message "Erreur dans l'en-tête de routage source" a le même format que le "Message de destination inaccessible", tel que spécifié dans [RFC4443]. La partie du paquet invoquant qui est renvoyée dans le message ICMP devrait enregistrer au moins jusqu'à l'en-tête de routage, et l'en-tête de routage devrait être consommé par ce nœud de sorte que la destination dans l'en-tête IPv6 soit le prochain saut que ce nœud n'a pas pu atteindre.

Une incohérence DAO se produit lorsqu'un routeur a une route descendante qui a été précédemment apprise d'un message DAO via un enfant, mais que cette route descendante n'est plus valide chez l'enfant, par exemple, parce que l'état associé chez l'enfant a été nettoyé. Avec la récupération de boucle d'incohérence DAO, un paquet peut être utilisé pour explorer et nettoyer récursivement les états DAO obsolètes le long d'un sous-DODAG.

De manière générale, un paquet qui descend ne devrait jamais remonter. Si la récupération de boucle d'incohérence DAO est appliquée, alors le routeur DEVRAIT renvoyer le paquet au parent qui l'a passé avec le bit Forwarding-Error 'F' défini et le bit 'O' laissé intact. Sinon, le routeur DOIT rejeter silencieusement le paquet.

À la réception d'un paquet avec un bit Forwarding-Error défini, le nœud DOIT supprimer les états de routage qui ont causé le transfert vers ce voisin, effacer le bit Forwarding-Error, et tenter d'envoyer le paquet à nouveau. Le paquet peut être envoyé à un voisin alternatif, après l'expiration d'un temporisateur spécifique à l'implémentation configurable par l'utilisateur. Si ce voisin alternatif a toujours un état DAO incohérent via ce nœud, le processus se répétera, ce nœud définira le bit Forwarding-Error 'F', et l'état de routage dans le voisin alternatif sera également nettoyé.