1. Introduction
Les réseaux à faible puissance et à pertes (LLN) sont constitués en grande partie de nœuds contraints (avec une puissance de traitement, une mémoire et parfois une énergie limitées lorsqu'ils fonctionnent sur batterie ou par récupération d'énergie). Ces routeurs sont interconnectés par des liaisons à pertes, ne prenant généralement en charge que de faibles débits de données, qui sont généralement instables avec des taux de livraison de paquets relativement faibles. Une autre caractéristique de ces réseaux est que les modèles de trafic ne sont pas simplement point à point, mais dans de nombreux cas point à multipoint ou multipoint à point. De plus, ces réseaux peuvent potentiellement comprendre jusqu'à des milliers de nœuds. Ces caractéristiques offrent des défis uniques à une solution de routage : le groupe de travail IETF ROLL a défini des exigences de routage spécifiques à l'application pour un protocole de routage de réseau à faible puissance et à pertes (LLN), spécifiées dans [RFC5867], [RFC5826], [RFC5673] et [RFC5548].
Ce document spécifie le protocole de routage IPv6 pour les LLN (RPL). Notez que bien que RPL ait été spécifié conformément aux exigences énoncées dans les documents d'exigences susmentionnés, son utilisation n'est en aucun cas limitée à ces applications.
1.1. 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 objectives de routage. Une implémentation RPL, à l'appui d'une application LLN particulière, inclura la ou les fonctions objectives 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é du voisin (NUD) est un tel mécanisme, mais des alternatives sont possibles, notamment la détection de transfert bidirectionnel (BFD) [RFC5881] et des indices des couches inférieures via des déclencheurs de couche 2 (L2) comme [RFC5184]. D'une 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 non-stockage comme détaillé plus loin dans la section 9), ce qui par nature empêche les boucles sans fin et allège le besoin d'informations de paquet RPL. Les futures spécifications d'accompagnement peuvent proposer d'autres moyens de transporter les informations de paquet RPL dans les paquets IPv6 et peuvent é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 du 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égables selon l'origine des routeurs. Un préfixe appartenant à un routeur est annoncé comme étant sur liaison.
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 liaison.
En particulier, RPL peut diffuser des informations de découverte de voisins (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 les annonces de routage et ne doivent jamais être directement redistribuées dans un autre protocole de routage. Un nœud RPL combine souvent les 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 de 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 de déclarations d'applicabilité spécifiant un ensemble de points de fonctionnement appropriés aux scénarios d'application d'automatisation du bâtiment, de domotique, industrielle et urbaine.
1.2. Attentes concernant le type de couche de liaison
Conformément à l'architecture en couches de l'IP, RPL ne repose sur aucune fonctionnalité particulière d'une technologie de couche de liaison spécifique. RPL est conçu pour pouvoir fonctionner sur une variété de couches de liaison différentes, y compris celles qui sont contraintes, potentiellement avec pertes ou généralement utilisées conjointement avec des dispositifs hôtes ou routeurs très contraints, tels que, mais sans s'y limiter, les technologies sans fil à faible puissance ou CPL (communication par courant porteur).
Les implémenteurs peuvent trouver [RFC3819] une référence utile lors de la conception d'une interface de couche de liaison entre RPL et une technologie de couche de liaison particulière.