1.1. Design Principles (Principes de conception)

RPL a été conçu dans le but de répondre aux exigences énoncées dans [RFC5867], [RFC5826], [RFC5673] et [RFC5548].

Un réseau peut exécuter plusieurs instances de RPL simultanément. Chaque instance de ce type peut servir des contraintes ou des critères de performance différents et potentiellement antagonistes. Ce document définit comment une instance unique fonctionne.

Afin d'être utile dans un large éventail de domaines d'application LLN, RPL sépare le traitement et le transfert des paquets de l'objectif d'optimisation du routage. Des exemples de tels objectifs incluent la minimisation de l'énergie, la minimisation de la latence ou la satisfaction de contraintes. Ce document décrit le mode de fonctionnement de RPL. D'autres documents d'accompagnement spécifient les fonctions d'objectif de routage (Objective Functions). Une implémentation RPL, à l'appui d'une application LLN particulière, inclura la ou les fonctions d'objectif nécessaires requises par l'application.

Les opérations RPL nécessitent des liaisons bidirectionnelles. Dans certains scénarios LLN, ces liaisons peuvent présenter des propriétés asymétriques. Il est nécessaire que l'accessibilité d'un routeur soit vérifiée avant que le routeur puisse être utilisé comme parent. RPL s'attend à ce qu'un mécanisme externe soit déclenché pendant la phase de sélection du parent afin de vérifier les propriétés de la liaison et l'accessibilité du voisin. La détection d'inaccessibilité de voisin (NUD) est un tel mécanisme, mais des alternatives sont possibles, notamment la détection de transfert bidirectionnel (BFD) [RFC5881] et des indications des couches inférieures via des déclencheurs de couche 2 (L2) comme [RFC5184]. De manière générale, un mécanisme de détection réactif au trafic est privilégié afin de minimiser le coût de surveillance des liaisons qui ne sont pas utilisées.

RPL s'attend également à un mécanisme externe pour accéder et transporter certaines informations de contrôle, appelées "informations de paquet RPL", dans les paquets de données. Les informations de paquet RPL sont définies dans la section 11.2 et permettent l'association d'un paquet de données à une instance RPL et la validation des états de routage RPL. L'option RPL [RFC6553] est un exemple d'un tel mécanisme. Le mécanisme est requis pour tous les paquets, sauf lorsque le routage source strict est utilisé (c'est-à-dire pour les paquets allant vers le bas en mode sans stockage, comme détaillé plus loin dans la section 9), ce qui empêche par nature les boucles sans fin et allège le besoin d'informations de paquet RPL. Les futures spécifications d'accompagnement pourraient proposer d'autres moyens de transporter les informations de paquet RPL dans les paquets IPv6 et pourraient étendre les informations de paquet RPL pour prendre en charge des fonctionnalités supplémentaires.

RPL fournit un mécanisme pour diffuser des informations sur la topologie de réseau formée dynamiquement. Cette diffusion permet une configuration minimale dans les nœuds, permettant aux nœuds de fonctionner de manière essentiellement autonome. Ce mécanisme utilise Trickle [RFC6206] pour optimiser la diffusion comme décrit dans la section 8.3.

Dans certaines applications, RPL assemble des topologies de routeurs qui possèdent des préfixes indépendants. Ces préfixes peuvent ou non être agrégeables selon l'origine des routeurs. Un préfixe appartenant à un routeur est annoncé comme étant sur la liaison (on-link).

RPL introduit également la capacité de lier un sous-réseau avec un préfixe commun et de router au sein de ce sous-réseau. Une source peut injecter des informations sur le sous-réseau à diffuser par RPL, et cette source fait autorité pour ce sous-réseau. Étant donné que de nombreuses liaisons LLN ont des propriétés non transitives, un préfixe commun que RPL diffuse sur le sous-réseau ne doit pas être annoncé comme étant sur la liaison.

En particulier, RPL peut diffuser des informations de découverte de voisin (ND) IPv6 telles que l'option d'information de préfixe (PIO) [RFC4861] et l'option d'information de route (RIO) [RFC4191]. Les informations ND diffusées par RPL conservent toute leur sémantique d'origine pour le routeur vers l'hôte, avec des extensions limitées pour le routeur vers le routeur, bien qu'elles ne doivent pas être confondues avec des annonces de routage et qu'elles ne doivent jamais être directement redistribuées dans un autre protocole de routage. Un nœud RPL combine souvent des comportements d'hôte et de routeur. En tant qu'hôte, il traitera les options comme spécifié dans [RFC4191], [RFC4861], [RFC4862] et [RFC6275]. En tant que routeur, le nœud RPL peut annoncer les informations des options selon les besoins pour la liaison spécifique, par exemple, dans un message d'annonce de routeur (RA) ND, bien que l'opération exacte soit hors de portée.

Un ensemble de documents d'accompagnement à cette spécification fournira des conseils supplémentaires sous la forme d'énoncés d'applicabilité spécifiant un ensemble de points de fonctionnement appropriés aux scénarios d'application d'automatisation des bâtiments, de domotique, industriels et urbains.