18. Considérations de gestion

Le but de cette section est de prendre en considération la gestion de RPL et la manière dont RPL sera exploité dans un LLN. La portée de cette section est d'examiner les aspects suivants de la gestion : configuration, surveillance, gestion des pannes, comptabilité et performance du protocole à la lumière des recommandations énoncées dans [RFC5706].

18.1. Introduction

La plupart des normes de gestion IETF existantes sont des modules MIB (modèles de données basés sur la Structure of Management Information (SMI)) pour surveiller et gérer les périphériques réseau.

Pour un certain nombre de protocoles, la communauté IETF a utilisé le cadre de gestion standard de l'IETF, notamment le protocole SNMP (Simple Network Management Protocol) [RFC3410], la structure des informations de gestion [RFC2578] et les modèles de données MIB pour la gestion des nouveaux protocoles.

Comme indiqué dans [RFC5706], la politique commune en termes d'exploitation et de gestion a été étendue à une politique plus ouverte à un ensemble d'outils et de protocoles de gestion plutôt que de s'appuyer strictement sur un protocole unique tel que SNMP.

En 2003, l'Internet Architecture Board (IAB) a organisé un atelier sur la gestion de réseau [RFC3535] qui a discuté des forces et des faiblesses de certains protocoles de gestion de réseau IETF et les a comparés aux besoins opérationnels, en particulier la configuration.

Une question discutée était la non-convivialité du format binaire de SNMP [RFC3410]. Dans le cas des LLN, il convient de noter qu'au moment de la rédaction du présent document, le groupe de travail CoRE travaille activement sur la gestion des ressources des périphériques dans les LLN. Néanmoins, on estime que cette section fournit des indications importantes sur la manière dont RPL doit être déployé, exploité et géré.

Comme indiqué dans [RFC5706] :

Un modèle d'information de gestion doit inclure une discussion sur ce qui est gérable, quels aspects du protocole doivent être configurés, quels types d'opérations sont autorisés, quels événements spécifiques au protocole peuvent se produire, quels événements peuvent être comptés et pour quels événements un opérateur doit être notifié.

Ces aspects sont discutés en détail dans les sections suivantes.

RPL sera utilisé sur une variété d'appareils qui peuvent avoir des ressources telles que la mémoire variant de quelques kilo-octets à plusieurs centaines de kilo-octets et même des méga-octets. Lorsque la mémoire est très contrainte, il peut ne pas être possible de satisfaire toutes les exigences énumérées dans cette section. Il vaut tout de même la peine de les énumérer toutes de manière exhaustive, et les responsables de la mise en œuvre détermineront ensuite lesquelles de ces exigences pourraient être satisfaites en fonction des ressources disponibles sur l'appareil.

18.2. Gestion de la configuration

Cette section traite de la gestion de la configuration, en énumérant les paramètres du protocole pour lesquels la gestion de la configuration est pertinente.

Certains paramètres RPL sont facultatifs. Les exigences de configuration ne sont applicables que pour les options qui sont utilisées.

18.2.1. Mode d'initialisation

"Architectural Principles of the Internet" [RFC1958], Section 3.8, déclare : "Évitez les options et les paramètres autant que possible. Toutes les options et tous les paramètres doivent être configurés ou négociés dynamiquement plutôt que manuellement". Cela est particulièrement vrai dans les LLN où le nombre d'appareils peut être important et où la configuration manuelle est infaisable. Cela a été pris en compte dans la conception de RPL par laquelle la racine DODAG fournit un certain nombre de paramètres aux appareils rejoignant le DODAG, évitant ainsi une configuration fastidieuse sur les routeurs et des sources potentielles de mauvaise configuration (par exemple, valeurs des minuteries Trickle, etc.). Néanmoins, il existe des paramètres RPL supplémentaires qu'une implémentation RPL devrait permettre de configurer, qui sont discutés dans cette section.

18.2.1.1. Mode de fonctionnement DIS au démarrage

Lorsqu'un nœud est mis sous tension pour la première fois :

1. Le nœud peut décider de rester silencieux, attendant de recevoir des messages DIO du DODAG d'intérêt (annonçant un OF pris en charge et des métriques/contraintes) et de ne pas envoyer de messages DIO multidiffusion tant qu'il n'a pas rejoint un DODAG.

2. Le nœud peut décider d'envoyer un ou plusieurs messages DIS (facultativement, demandant un DIO pour un DODAG spécifique) comme sonde initiale pour les DODAG voisins, et en l'absence de messages DIO en réponse après une période de temps configurable, le nœud peut décider d'enraciner un DODAG flottant et de commencer à envoyer des messages DIO multidiffusion.

Une implémentation RPL DEVRAIT permettre de configurer le mode de fonctionnement préféré indiqué ci-dessus ainsi que les paramètres requis (dans le second mode : le nombre de messages DIS et la minuterie associée).

18.2.2. Configuration des messages et options de base DIO et DAO

RPL spécifie un certain nombre de paramètres de protocole compte tenu du large spectre d'applications où il sera utilisé. Cela dit, une attention particulière a été accordée à la limitation du nombre de ces paramètres qui doivent être configurés sur chaque routeur RPL. Au lieu de cela, un certain nombre de valeurs par défaut peuvent être utilisées et, si nécessaire, ces paramètres peuvent être fournis par la racine DODAG, permettant ainsi un réglage dynamique des paramètres.

Une implémentation RPL DEVRAIT permettre de configurer les paramètres de protocole de routage suivants. Comme indiqué ci-dessus, notez qu'un grand ensemble de paramètres est configuré sur la racine DODAG.

18.2.3. Paramètres de protocole à configurer sur chaque routeur du LLN

Une implémentation RPL DOIT permettre de configurer les paramètres RPL suivants :

• RPLInstanceID [message DIO, dans le message de base DIO]. Bien que le RPLInstanceID doive être configuré sur la racine DODAG, il doit également être configuré en tant que politique sur chaque nœud afin de déterminer si le nœud doit rejoindre ou non un DODAG particulier. Notez qu'un second RPLInstanceID peut être configuré sur le nœud, s'il devient racine d'un DODAG flottant.

• Liste des points de code d'objectif (OCP) pris en charge

• Liste des métriques prises en charge : [RFC6551] spécifie un certain nombre de métriques et de contraintes utilisées pour la formation du DODAG. Ainsi, une implémentation RPL devrait permettre de configurer la liste des métriques qu'un nœud peut accepter et comprendre. Si un DIO est reçu avec une métrique et/ou une contrainte qui n'est pas comprise ou prise en charge, comme spécifié dans la section 8.5, le nœud rejoindra en tant que nœud feuille.

• Informations sur le préfixe, ainsi que la durée de vie valide et préférée et les drapeaux 'L' et 'A'. [Message DIO, Option d'information sur le préfixe]. Une implémentation RPL DEVRAIT permettre de configurer si l'option d'information sur le préfixe doit être transportée avec le message DIO pour distribuer les informations sur le préfixe pour l'autoconfiguration. Dans ce cas, l'implémentation RPL DOIT permettre à la liste des préfixes d'être annoncée dans le PIO avec les drapeaux correspondants.

• Informations sollicitées [message DIS, dans l'option d'information sollicitée]. Notez qu'une implémentation RPL DEVRAIT permettre de configurer quand de tels messages doivent être envoyés et dans quelles circonstances, ainsi que la valeur du RPLInstance ID, les drapeaux 'V'/'I'/'D'.

• Drapeau 'K' : quand un nœud doit définir le drapeau 'K' dans un message DAO [message DAO, dans le message de base DAO].

• MOP (Mode de fonctionnement) [message DIO, dans le message de base DIO].

• Informations de route (et préférence) [message DIO, dans l'option d'information de route]

18.2.4. Paramètres de protocole à configurer sur chaque routeur non racine DODAG dans le LLN

Une implémentation RPL DOIT permettre de configurer le préfixe cible [message DAO, dans l'option cible RPL].

De plus, il existe des circonstances où un nœud peut vouloir désigner une cible pour permettre un traitement spécifique de la cible (priorisation, etc.). De telles règles de traitement sont hors de portée de cette spécification. Lorsqu'elles sont utilisées, une implémentation RPL DEVRAIT permettre de configurer le descripteur de cible sur une base par cible (par exemple, en utilisant des listes d'accès).

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 telle sorte qu'il soit moins préféré. Ainsi, une implémentation RPL DOIT permettre de configurer l'ensemble des actions que le nœud doit initier dans ce cas :

• Démarrer son propre DODAG (flottant) : le nouveau DODAGID doit être configuré en plus de sa DAGPreference.

• Empoisonner le chemin rompu (voir la procédure dans la section 8.2.2.5).

• Déclencher une réparation locale.

18.2.5. Paramètres à configurer sur la racine DODAG

De plus, plusieurs autres paramètres sont configurés uniquement sur la racine DODAG et annoncés dans les options transportées dans les messages DIO.

Comme spécifié dans la section 8.3, une implémentation RPL utilise des minuteries Trickle pour régir l'envoi des messages DIO. Le fonctionnement de l'algorithme Trickle est déterminé par un ensemble de paramètres configurables, qui DOIVENT être configurables et qui sont ensuite annoncés par la racine DODAG le long du DODAG dans les messages DIO.

• DIOIntervalDoublings [message DIO, dans l'option de configuration DODAG]

• DIOIntervalMin [message DIO, dans l'option de configuration DODAG]

• DIORedundancyConstant [message DIO, dans l'option de configuration DODAG]

De plus, une implémentation RPL DEVRAIT permettre de configurer l'ensemble suivant de paramètres RPL :

• Taille du contrôle de chemin [message DIO, dans l'option de configuration DODAG]

• MinHopRankIncrease [message DIO, dans l'option de configuration DODAG]

• Le champ DODAGPreference [message DIO, objet de base DIO]

• DODAGID [message DIO, dans l'option de base DIO] et [message DAO, lorsque le drapeau 'D' du message DAO est défini]

Comportement de la racine DAG : dans certains cas, un nœud peut ne pas vouloir agir en permanence comme une racine DODAG flottante s'il ne peut pas rejoindre un DODAG ancré. Par exemple, un nœud alimenté par batterie peut ne pas vouloir agir comme une racine DODAG flottante pendant une longue période. Ainsi, une implémentation RPL PEUT prendre en charge la capacité de configurer si un nœud peut ou non agir comme une racine DODAG flottante pendant une période configurée.

Incrément du numéro de version DAG : une implémentation RPL peut permettre, par configuration à la racine DODAG, de rafraîchir les états DODAG en mettant à jour le DODAGVersionNumber. Une implémentation RPL DEVRAIT permettre de configurer si des mécanismes périodiques ou déclenchés par des événements sont utilisés par la racine DODAG pour contrôler le changement de DODAGVersionNumber (qui déclenche une réparation globale comme spécifié dans la section 3.2.2).

18.2.6. Configuration des paramètres RPL liés aux mécanismes basés sur DAO

Les messages DAO sont facultatifs et utilisés dans les DODAG qui nécessitent une opération de routage vers le bas. Cette section traite de l'ensemble des paramètres liés aux messages DAO et fournit des recommandations sur leur configuration.

Comme indiqué dans la section 9.5, il est recommandé de retarder l'envoi du message DAO aux parents DAO afin de maximiser les chances d'effectuer une agrégation de routes. Lors de la réception d'un message DAO, le nœud doit donc démarrer une minuterie DelayDAO. La valeur par défaut est DEFAULT_DAO_DELAY. Une implémentation RPL PEUT permettre de configurer la minuterie DelayDAO.

Dans un mode de fonctionnement de stockage, 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 le cadre des mises à jour et de la maintenance de routine de la table de routage. Une implémentation RPL PEUT permettre de configurer un ensemble de règles spécifiant les déclencheurs pour l'incrément DTSN (manuel ou basé sur des événements).

Lorsqu'une entrée DAO expire ou est invalidée, un nœud DEVRAIT faire une tentative raisonnable pour signaler un No-Path à chacun des parents DAO. Ce nombre de tentatives PEUT être configurable.

Une implémentation devrait prendre en charge la limitation du débit d'envoi des messages DAO. Les paramètres associés PEUVENT être configurables.

18.2.7. Configuration des paramètres RPL liés aux mécanismes de sécurité

Comme décrit dans la section 10, les fonctionnalités de sécurité décrites dans ce document sont facultatives à mettre en œuvre et une implémentation donnée peut prendre en charge un sous-ensemble (y compris l'ensemble vide) des fonctionnalités de sécurité décrites.

À cette fin, une implémentation prenant en charge les fonctionnalités de sécurité décrites peut conceptuellement mettre en œuvre une base de données de politique de sécurité. À l'appui des mécanismes de sécurité, une implémentation RPL DEVRAIT permettre de configurer un sous-ensemble des paramètres suivants :

• Modes de sécurité acceptés [mode non sécurisé, mode préinstallé, mode authentifié]

• Valeurs KIM acceptées [messages de contrôle RPL sécurisés, dans la section Sécurité]

• Valeurs de niveau acceptées [messages de contrôle RPL sécurisés, dans la section Sécurité]

• Valeurs d'algorithme acceptées [messages de contrôle RPL sécurisés, dans la section Sécurité]

• Matériel clé à l'appui des modes de clé authentifiés ou préinstallés.

De plus, une implémentation RPL DEVRAIT permettre de configurer une racine DODAG avec un sous-ensemble des paramètres suivants :

• Valeurs de niveau annoncées [message DIO sécurisé, dans la section Sécurité]

• Valeur KIM annoncée [message DIO sécurisé, dans la section Sécurité]

• Valeur d'algorithme annoncée [message DIO sécurisé, dans la section Sécurité]

18.2.8. Valeurs par défaut

Ce document spécifie des valeurs par défaut pour l'ensemble suivant de variables RPL :

• DEFAULT_PATH_CONTROL_SIZE
• DEFAULT_DIO_INTERVAL_MIN
• DEFAULT_DIO_INTERVAL_DOUBLINGS
• DEFAULT_DIO_REDUNDANCY_CONSTANT
• DEFAULT_MIN_HOP_RANK_INCREASE
• DEFAULT_DAO_DELAY

Il est recommandé de spécifier des valeurs par défaut dans les protocoles ; cela dit, comme indiqué dans [RFC5706], les valeurs par défaut peuvent avoir de moins en moins de sens. RPL est un protocole de routage qui devrait être utilisé dans un certain nombre de contextes où les caractéristiques du réseau telles que le nombre de nœuds et les types de liaisons et de nœuds devraient varier considérablement. Ainsi, ces valeurs par défaut sont susceptibles de changer avec le contexte et à mesure que la technologie évolue. En effet, les technologies liées aux LLN (par exemple, matériel, couches de liaison) ont évolué de façon spectaculaire au cours des dernières années et ces technologies devraient changer et évoluer considérablement dans les années à venir.

Les valeurs proposées ne sont pas basées sur de vastes meilleures pratiques actuelles et sont considérées comme prudentes.

18.3. Surveillance du fonctionnement de RPL

Plusieurs paramètres RPL doivent être surveillés pour vérifier le bon fonctionnement du protocole de routage et du réseau lui-même. Cette section répertorie l'ensemble des paramètres de surveillance d'intérêt.

18.3.1. Surveillance des paramètres d'un DODAG

Une implémentation RPL DEVRAIT fournir des informations sur les paramètres suivants :

• Numéro de version DODAG [message DIO, dans le message de base DIO]

• État du drapeau 'G' [message DIO, dans le message de base DIO]

• État du champ MOP [message DIO, dans le message de base DIO]

• Valeur du DTSN [message DIO, dans le message de base DIO]

• Valeur du rang [message DIO, dans le message de base DIO]

• DAOSequence : Incrémenté à chaque message DAO unique, répercuté dans le message DAO-ACK [messages DAO et DAO-ACK]

• Informations de route [message DIO, option d'information de route] (liste des préfixes IPv6 par parent avec durée de vie et préférence]

• Paramètres Trickle :

  • DIOIntervalDoublings [message DIO, dans l'option de configuration DODAG]
  • DIOIntervalMin [message DIO, dans l'option de configuration DODAG]
  • DIORedundancyConstant [message DIO, dans l'option de configuration DODAG]

• Taille du contrôle de chemin [message DIO, dans l'option de configuration DODAG]

• MinHopRankIncrease [message DIO, dans l'option de configuration DODAG]

Valeurs qui ne peuvent être surveillées que sur la racine DODAG :

• Informations de transit [DAO, option d'information de transit] : Une implémentation RPL DEVRAIT permettre de configurer si l'ensemble des options d'information de transit reçues doit être affiché sur la racine DODAG. Dans ce cas, la base de données RPL des informations de transit reçues doit également contenir la séquence de chemin, le contrôle de chemin, la durée de vie du chemin et l'adresse du parent.

18.3.2. Surveillance des incohérences d'un DODAG et détection de boucles

La détection des incohérences DODAG est particulièrement critique dans les réseaux RPL. Ainsi, il est recommandé pour une implémentation RPL de fournir des outils de surveillance appropriés. Une implémentation RPL DEVRAIT fournir un compteur signalant le nombre de fois où le nœud a détecté une incohérence par rapport à un parent DODAG, par exemple, si le DODAGID a changé.

Lorsque cela est possible, des informations plus granulaires sur la détection des incohérences doivent être fournies. Une implémentation RPL PEUT fournir des compteurs signalant le nombre d'incohérences suivantes :

• Paquets reçus avec le bit 'O' défini (vers le bas) d'un nœud avec un rang plus élevé

• Paquets reçus avec le bit 'O' effacé (vers le haut) d'un nœud avec un rang inférieur

• Nombre de paquets avec le bit 'F' défini

• Nombre de paquets avec le bit 'R' défini

18.4. Surveillance des structures de données RPL

18.4.1. Structure de données des voisins candidats

Un nœud dans la liste des voisins candidats est un nœud découvert par les mêmes moyens et qualifié pour devenir potentiellement un parent (avec une confiance locale suffisamment élevée). Une implémentation RPL DEVRAIT fournir un moyen de permettre à la liste des voisins candidats d'être surveillée avec une métrique reflétant la confiance locale (le degré de stabilité des voisins) telle que mesurée par certaines métriques.

Une implémentation RPL PEUT fournir un compteur signalant le nombre de fois qu'un voisin candidat a été ignoré, si le nombre de voisins candidats dépasse la valeur maximale autorisée.

18.4.2. Table de graphe orienté acyclique orienté vers la destination (DODAG)

Pour chaque DODAG, une implémentation RPL est censée garder une trace des valeurs de table DODAG suivantes :

• RPLInstanceID

• DODAGID

• DODAGVersionNumber

• Rang

• Point de code d'objectif

• Un ensemble de parents DODAG

• Un ensemble de préfixes offerts vers le haut le long du DODAG

• Minuteries Trickle utilisées pour régir l'envoi de messages DIO pour le DODAG

• Liste des parents DAO

• DTSN

• État du nœud (routeur contre feuille)

Une implémentation RPL DEVRAIT permettre de surveiller l'ensemble des paramètres énumérés ci-dessus.

18.4.3. Table de routage et entrées de routage DAO

Une implémentation RPL maintient plusieurs éléments d'information liés au DODAG et aux entrées DAO (pour les nœuds de stockage). Dans le cas d'un nœud sans stockage, une quantité limitée d'informations est maintenue (la table de routage est principalement réduite à un ensemble de parents DODAG avec les caractéristiques du DODAG comme mentionné ci-dessus) ; alors que dans le cas de nœuds de stockage, ces informations sont augmentées avec des entrées de routage.

Une implémentation RPL DEVRAIT permettre de surveiller les paramètres suivants :

• Prochain saut (parent DODAG)

• Interface du prochain saut

• Valeur des métriques de chemin pour chaque parent DODAG

Une entrée de table de routage DAO contient conceptuellement les éléments suivants (pour les nœuds de stockage uniquement) :

• Informations sur le voisin annonceur

• Adresse IPv6

• ID d'interface auquel cette entrée a été signalée aux parents DAO

• Compteur de tentatives

• Équivalent logique du contenu DAO :

  • DAO-Sequence
  • Séquence de chemin
  • Durée de vie DAO
  • Contrôle de chemin DAO

• Préfixe de destination (ou adresse ou groupe Mcast)

Une implémentation RPL DEVRAIT fournir des informations sur l'état de chaque état d'entrée de table de routage DAO.

18.5. Gestion des pannes

La gestion des pannes est un composant critique utilisé pour le dépannage, la vérification du mode de fonctionnement correct du protocole et la conception du réseau ; c'est aussi un composant clé de la surveillance des performances du réseau. Une implémentation RPL DEVRAIT permettre la fourniture des informations suivantes liées à la gestion des pannes :

• Débordement de mémoire avec la cause (par exemple, débordement des tables de routage, etc.)

• Nombre de fois qu'un paquet n'a pas pu être envoyé à un parent DODAG signalé comme valide

• Nombre de fois qu'un paquet a été reçu pour lequel le routeur n'avait pas de RPLInstanceID correspondant

• Nombre de fois qu'une procédure de réparation locale a été déclenchée

• Nombre de fois qu'une réparation globale a été déclenchée par la racine DODAG

• Nombre de messages mal formés reçus

• Nombre de secondes avec des paquets à transmettre et pas de prochain saut (parent DODAG)

• Nombre de secondes sans prochain saut (parent DODAG)

• Nombre de fois qu'un nœud a rejoint un DODAG en tant que feuille parce qu'il a reçu un DIO avec une métrique/contrainte qui n'était pas comprise et qu'il a été configuré pour rejoindre en tant que nœud feuille dans ce cas (voir la section 18.6)

Il est RECOMMANDÉ de signaler les pannes via au moins des messages de journal d'erreurs. D'autres protocoles peuvent être utilisés pour signaler de telles pannes.

18.6. Politique

Les règles de politique peuvent être utilisées par une implémentation RPL pour déterminer si le nœud est autorisé ou non à rejoindre un DODAG particulier annoncé par un voisin au moyen de messages DIO.

Ce document spécifie le fonctionnement au sein d'un seul DODAG. Un DODAG est caractérisé par le tuple suivant (RPLInstanceID, DODAGID). De plus, comme indiqué ci-dessus, les messages DIO sont utilisés pour annoncer d'autres caractéristiques du DODAG telles que les métriques et contraintes de routage utilisées pour construire le DODAG et la fonction d'objectif utilisée (spécifiée par OCP).

Les premières règles de politique consistent à spécifier les conditions suivantes qu'un nœud RPL doit remplir pour rejoindre un DODAG :

• RPLInstanceID

• Liste des métriques et contraintes de routage prises en charge

• Fonction d'objectif (valeurs OCP)

Une implémentation RPL DOIT permettre de configurer ces paramètres et DEVRAIT spécifier si le nœud doit simplement ignorer le DIO si le DODAG annoncé n'est pas conforme à la politique locale ou si le nœud doit rejoindre en tant que nœud feuille si seule la liste des métriques et contraintes de routage prises en charge, et l'OF n'est pas pris en charge. De plus, une implémentation RPL DEVRAIT permettre l'ajout du DODAGID dans le cadre de la politique.

Une implémentation RPL DEVRAIT permettre de configurer l'ensemble des fonctions d'objectif (OF) acceptables ou préférées référencées par leurs points de code d'objectif (OCP) pour qu'un nœud rejoigne un DODAG, et quelle action doit être prise si aucun des voisins candidats d'un nœud n'annonce l'une des fonctions d'objectif autorisées configurées, ou si les métriques/contraintes annoncées ne sont pas comprises/prises en charge. Deux actions peuvent être prises dans ce cas :

• Le nœud rejoint le DODAG en tant que nœud feuille comme spécifié dans la section 8.5.

• Le nœud ne rejoint pas le DODAG.

Un nœud dans un LLN peut apprendre des informations de routage à partir de différents protocoles de routage, y compris RPL. Dans ce cas, il est souhaitable de contrôler, via une préférence administrative, quelle route doit être favorisée. Une implémentation DEVRAIT permettre la spécification d'une préférence administrative pour le protocole de routage à partir duquel la route a été apprise.

Structures de données internes : certaines implémentations RPL peuvent limiter la taille de la liste des voisins candidats afin de limiter l'utilisation de la mémoire ; auquel cas, certains voisins candidats autrement viables peuvent ne pas être pris en compte et simplement supprimés de la liste des voisins candidats.

Une implémentation RPL PEUT fournir un indicateur sur la taille de la liste des voisins candidats.

18.7. Isolation des pannes

Il est RECOMMANDÉ de mettre en quarantaine les voisins qui commencent à émettre des messages mal formés à des taux inacceptables.

18.8. Impact sur les autres protocoles

RPL a un impact très limité sur les autres protocoles. Lorsqu'un routeur nécessite plusieurs protocoles de routage, comme un LBR, on s'attend à ce que l'appareil prenne en charge les fonctions de redistribution de routage entre les protocoles de routage pour permettre l'accessibilité entre les deux domaines de routage. Une telle redistribution DEVRAIT être régie par l'utilisation d'une politique configurable par l'utilisateur.

En ce qui concerne l'impact en termes de trafic sur le réseau, RPL a été conçu pour limiter le trafic de contrôle grâce à des mécanismes tels que les minuteries Trickle (Section 8.3). Ainsi, l'impact de RPL sur les autres protocoles devrait être extrêmement limité.

18.9. Gestion des performances

La gestion des performances est toujours un aspect important d'un protocole, et RPL ne fait pas exception. Plusieurs métriques d'intérêt ont été spécifiées par le groupe de travail IP Performance Monitoring (IPPM) : cela étant dit, elles seront difficilement applicables au LLN compte tenu du coût de la surveillance de ces métriques en termes de ressources sur les appareils et de bande passante requise. Néanmoins, les implémentations RPL PEUVENT prendre en charge certaines d'entre elles, et d'autres paramètres d'intérêt sont énumérés ci-dessous :

• Nombre de réparations et temps de réparation en secondes (moyenne, variance)

• Nombre de fois et période de temps pendant laquelle un appareil n'a pas pu transmettre un paquet en raison de l'absence d'un voisin accessible dans sa table de routage

• Surveillance de la consommation de ressources par RPL en termes de bande passante et de mémoire requise

• Nombre de messages de contrôle RPL envoyés et reçus

18.10. Diagnostics

Il peut y avoir des situations où un nœud doit être placé en mode "verbeux" pour améliorer les diagnostics. Ainsi, une implémentation RPL DEVRAIT fournir la capacité de placer un nœud en mode verbeux et de l'en sortir afin d'obtenir des informations de diagnostic supplémentaires.