Aller au contenu principal

16. Résumé des Exigences pour les Implémentations Interopérables

Cette section résume l'interopérabilité de base et référence le texte normatif pour les implémentations RPL fonctionnant dans l'un des trois modes majeurs. Les implémentations sont censées supporter soit aucune route descendante, soit le mode sans stockage (Non-Storing) uniquement, soit le mode avec stockage (Storing) uniquement. Un quatrième mode, le fonctionnement en tant que feuille, est également possible.

Les implémentations conformes à cette spécification peuvent contenir différents sous-ensembles de capacités selon le scénario d'application. Il est important pour l'implémenteur de supporter un niveau d'interopérabilité cohérent avec celui requis par le scénario d'application. À cette fin, des conseils supplémentaires peuvent être fournis au-delà de cette spécification (par exemple, comme des déclarations d'applicabilité), et il est entendu que dans certains cas, ces conseils supplémentaires peuvent outrepasser des parties de cette spécification.

16.1. Exigences Communes

Dans un cas général, le plus grand niveau d'interopérabilité peut être atteint lorsque tous les nœuds dans un LLN RPL coopèrent pour utiliser les mêmes MOP, OF, métriques et contraintes, et sont ainsi capables d'agir comme des routeurs RPL. Lorsqu'un nœud n'est pas capable d'être un routeur RPL, il peut être possible d'interagir de manière plus limitée en tant que feuille RPL.

Toutes les implémentations RPL doivent supporter l'utilisation des informations de paquet RPL transportées dans les paquets de données (Section 11.2). Un tel mécanisme est décrit dans [RFC6553].

Les implémentations RPL devront supporter l'utilisation de la Détection d'Inaccessibilité de Voisin (NUD), ou un mécanisme équivalent, pour maintenir l'accessibilité des nœuds RPL voisins (Section 8.2.1). Des mécanismes alternatifs peuvent être optimisés pour les capacités contraintes de l'implémentation, tels que des indices de la couche liaison.

Cette spécification fournit des moyens pour obtenir une PIO et ainsi former une adresse IPv6. Lorsque ce mécanisme est utilisé, il peut être nécessaire d'effectuer une résolution d'adresse et une détection d'adresse dupliquée via un processus externe, tel que IPv6 ND [RFC4861] ou 6LoWPAN ND [6LOWPAN-ND].

16.2. Fonctionnement en tant que Nœud Feuille RPL (Uniquement)

  • Une implémentation d'un nœud feuille (uniquement) ne participe jamais en tant que routeur RPL. Les implémentations interopérables de nœuds feuilles se comportent comme résumé dans la Section 8.5.

  • Le support d'un encodage MOP particulier n'est pas requis, bien que si le nœud feuille envoie des messages DAO pour établir des routes descendantes, le nœud feuille devrait le faire d'une manière cohérente avec le mode de fonctionnement indiqué par le MOP.

  • Le support d'une OF particulière n'est pas requis.

  • En résumé, un nœud feuille n'émet généralement pas de messages DIO, il peut émettre des messages DAO et DIS. Un nœud feuille accepte les messages DIO bien qu'il ignore généralement les messages DAO et DIS.

16.3. Fonctionnement en tant que Routeur RPL

Si aucun conseil supplémentaire n'est disponible, alors une implémentation de routeur RPL DOIT au moins supporter l'OF0 sans métrique [RFC6552].

Pour un fonctionnement cohérent, une implémentation de routeur RPL doit supporter le MOP utilisé par le DODAG.

Tous les routeurs RPL devront implémenter Trickle [RFC6206].

16.3.1. Support des Routes Ascendantes (Uniquement)

Une implémentation d'un routeur RPL qui supporte uniquement les routes ascendantes supporte ce qui suit :

  • Routes ascendantes (Section 8)

  • Encodage MOP 0 (Section 20.3)

  • En résumé, les messages DIO et DIS sont émis, et les messages DAO ne sont pas émis. Les messages DIO et DIS sont acceptés, et les messages DAO sont ignorés.

16.3.2. Support des Routes Ascendantes et Descendantes en Mode Sans Stockage

Une implémentation d'un routeur RPL qui supporte les routes ascendantes et les routes descendantes en mode sans stockage supporte ce qui suit :

  • Routes ascendantes (Section 8)

  • Routes descendantes (Non-Stockage) (Section 9)

  • Encodage MOP 1 (Section 20.3)

  • Trafic descendant routé par la source ([RFC6554])

  • En résumé, les messages DIO et DIS sont émis, et les messages DAO sont émis vers la racine du DODAG. Les messages DIO et DIS sont acceptés, et les messages DAO sont ignorés par les nœuds autres que les racines DODAG. Le multicast n'est pas supporté par les moyens décrits dans cette spécification, bien qu'il puisse être supporté par d'autres moyens.

16.3.3. Support des Routes Ascendantes et Descendantes en Mode Avec Stockage

Une implémentation d'un routeur RPL qui supporte les routes ascendantes et les routes descendantes en mode avec stockage supporte ce qui suit :

  • Routes ascendantes (Section 8)

  • Routes descendantes (Stockage) (Section 9)

  • Encodage MOP 2 (Section 20.3)

  • En résumé, les messages DIO, DIS et DAO sont émis. Les messages DIO, DIS et DAO sont acceptés. Le multicast n'est pas supporté par les moyens décrits dans cette spécification, bien qu'il puisse être supporté par d'autres moyens.

16.3.3.1. Support Optionnel pour le Schéma Multicast De Base

Une implémentation en mode avec stockage peut être améliorée avec un support multicast de base grâce aux ajouts suivants :

  • Support Multicast De Base (Section 12)

  • Encodage MOP 3 (Section 20.3)

16.4. Éléments pour Spécification Future

Un certain nombre d'éléments sont laissés à une spécification future, y compris, mais sans s'y limiter, les suivants :

  • Comment attacher un nœud non-RPL tel qu'un hôte IPv6, par exemple, pour distribuer de manière cohérente au moins le matériel PIO au nœud attaché.

  • Comment obtenir le matériel d'authentification en support si le mode authentifié est utilisé (Section 10.3).

  • Détails du fonctionnement sur plusieurs instances simultanées.

  • Mécanismes de configuration avancés, tels que l'approvisionnement des RPLInstanceID, le paramétrage des Fonctions Objectif, et les paramètres pour contrôler la sécurité. (Il est prévu que de tels mécanismes puissent étendre le DIO comme moyen de diffuser des informations à travers le DODAG).