Présentation

Article

1 - DE LA NÉCESSITÉ D’UN NOUVEAU PROTOCOLE DE ROUTAGE POUR LES LLN

2 - ENVIRONNEMENT RPL

  • 2.1 - Définition
  • 2.2 - Organisation de la topologie dans RPL
  • 2.3 - Vue d’ensemble du fonctionnement de RPL

3 - CONSTRUCTION DE LA TOPOLOGIE

  • 3.1 - Formation des routes montantes : message DODAG Information Object (DIO)
  • 3.2 - Formation des routes descendantes : message Destination Advertisement Object

4 - MAINTIEN DE LA TOPOLOGIE

  • 4.1 - Réparation globale
  • 4.2 - Réparation locale
  • 4.3 - Détection des boucles de routage

5 - TEMPORALITÉ DE RPL

  • 5.1 - DIO : algorithme Trickle
  • 5.2 - DAO : intervalle DelayDAO
  • 5.3 - Exemple de construction de topologie au démarrage de RPL

6 - MÉTRIQUES RPL

7 - PRÉCISIONS SUR LE RANG

8 - OBJECTIVE FUNCTIONS

  • 8.1 - Objective Function Zero
  • 8.2 - Minimum Rank with Hysteresis Objective Function (MRHOF)

9 - RPL ET MULTI-CHEMIN

10 - SÉCURITÉ DANS RPL

11 - IMPLÉMENTATION DE RPL

12 - CONCLUSION

13 - GLOSSAIRE

Article de référence | Réf : TE7516 v1

Précisions sur le rang
Protocole de routage RPL

Auteur(s) : Tanguy ROPITAULT

Date de publication : 10 mai 2016

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

RÉSUMÉ

L’internet des Objets n’est plus un fantasme de science-fiction. Les progrès technologiques permettent maintenant d’envisager la connexion des objets du quotidien à l’Internet. Des solutions ouvertes et interopérables doivent cependant être utilisées pour garantir une communication optimum entre ces objets. Le protocole de routage est un élément clé de cet objectif, car il permet pour chaque objet de décider comment joindre un autre objet. Les contraintes s’appliquant aux objets (faible puissance, communications instables) doivent être prises en compte pour le développement de protocole de routages adaptés. Dans cet article, nous présentons le protocole RPL, spécialement conçu pour les réseaux à faible puissance et fort taux de perte.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

ABSTRACT

RPL routing protocol

The Internet of Things is no longer a science-fiction fantasy. Ongoing technological advances herald the connection of everyday objects to the Internet. However, open and interoperable solutions must be used to ensure optimal communication between these objects. The routing protocol is a key element of this objective, because it enables each object to decide on how to reach another object. The typical constraints of the objects (e.g. low power, unstable communication channels) must be taken into account in the development of appropriate routing protocols. In this article, we present the RPL protocol, which was specifically designed for low-power and lossy networks: the networks formed in the Internet of Things.

Auteur(s)

INTRODUCTION

Les capteurs ont longtemps été simplement utilisés pour quantifier et surveiller une valeur physique de façon locale : capteur de CO2 dans une usine, de température au sein du foyer, de luminosité pour un éclairage urbain, etc. L’apparition de l’Internet et les recherches dans le domaine des technologies sans fil ont permis de doter ces capteurs d’une connectivité et a donné naissance aux réseaux de capteurs sans fil. La généralisation de ces capteurs a entraîné la création d’une multitude de nouvelles applications : surveillance de la consommation énergétique d’un foyer, gestion des feux de signalisation urbains ou système d’éclairage intelligent pour une commune. De manière plus large, les réseaux de capteurs sans fil peuvent être vus comme un sous-ensemble du concept plus large de l’Internet des objets. L’Internet des objets vise à donner une connectivité à un ensemble hétérogène d’objets du quotidien (machine à laver, compteur électrique, éclairages, ou vêtements par exemple) à l’aide de communications filaires ou sans fil.

Du fait de la faible puissance (énergétique, de traitement) des objets à connecter à l’Internet, il a souvent été considéré que leur connexion à l’architecture Internet traditionnelle était impossible entraînant de facto le développement de solutions propriétaires et non interopérables (ZigBee, LON, KNX, etc.). L’IETF (Internet Engineering Task Force), l’organisme en charge de la standardisation des protocoles de l’Internet, a donc créé plusieurs groupes de travail afin de spécifier des protocoles interopérables pour les réseaux composés d’appareils fortement contraints ou LLN (Low Power and Lossy Networks ou réseaux à faible puissance et fort taux de perte).

On peut citer principalement le groupe de travail 6LoWPAN (The IPv6 in Low-Power Wireless Personal Area Networks) qui a défini la manière de transporter des datagrammes IPv6 sur des liens à bas débit et à faible consommation, ainsi que la façon d’y former et de maintenir un sous-réseau IPv6 (Internet Protocol version 6). Le groupe de travail ROLL a, quant à lui, défini le protocole de routage RPL, qui permet de construire une topologie de routage sur des réseaux contraints. Il est à noter qu’il ne faut pas prononcer RPL comme un acronyme de trois lettres, mais comme le mot anglais « riple » signifiant ondulation. Le groupe CORE développe une version simplifiée de HTTP demandant moins de ressources tout en gardant une compatibilité avec HTTP. Finalement, le groupe ACE s’occupe de la sécurité dans les environnements contraints. Ces quatre groupes de travail ont un rôle clé dans la définition d’un Internet des Objets ouvert et interopérable.

Dans cet article, nous nous focaliserons sur le protocole de routage RPL en présentant les différents mécanismes mis en œuvre dans RPL.

Un glossaire des principaux termes utilisés est placé en fin d’article.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

KEYWORDS

IPv6   |   Internet of Things   |   low power and lossy networks   |   standard's description   |   routing in LLN network

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-te7516


Cet article fait partie de l’offre

Réseaux Télécommunications

(163 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Présentation

7. Précisions sur le rang

Jusqu’à présent, nous avons vu que le rang représentait la distance d’un nœud par rapport au nœud racine et qu’il devait augmenter le long du DODAG (le rang d’un fils est forcément supérieur à celui de son père). Le rang est calculé en fonction d’une Objective Function donnée. Le rang est en fait une valeur abstraite qui n’a pas d’unité physique proprement dite, mais qui peut plutôt être regardée comme un nombre à virgule fixe où la position de la virgule entre la partie entière et fractionnaire est déterminée par une valeur appelée MinHopRankIncrease .

Prenons l’exemple d’un nœud qui a un rang de 1048 et une valeur de MinHopRankIncrease de 256 :

1048 en binaire peut s’écrire : 10000011000

256 en binaire peut s’écrire : 100000000

La position de la virgule est donc :100,00011000

Ce qui donne une partie entière :4

Ce qui donne une partie décimale :24

La partie entière du rang est donc 4 alors que la partie décimale est égale à 24/256.

MinHopRankIncrease est la plus petite augmentation de rang entre un nœud et un de ses parents. Il est fourni par la racine du DODAG à l’aide de l’option DODAG configuration (§ 3.1.3). Il est à noter que la racine du DODAG est configurée de manière à avoir un rang de MinHopRankIncrease et que MinHopRankIncrease a une valeur par défaut dans RPL de 256.

La figure 20 présente une topologie possible en utilisant RPL avec un MinHopRankIncrease de 256. On voit que la racine R est paramétrée avec le rang 256, et que le rang augmente le long du DODAG, avec au minimum une augmentation du rang de 256.

Lorsque les rangs doivent être comparés, c’est la partie entière du rang qui est utilisée grâce à la fonction DAGRang() définit dans l’équation :

...

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Réseaux Télécommunications

(163 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Précisions sur le rang
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - WINTER (T.) -   RPL : IPv6 routing protocol for low-power and lossy networks.  -  https://tools.ietf.org/html/rfc6550

  • (2) - LEVIS (P.) -   Overview of existing routing protocols for low power and lossy networks.  -  https://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07

  • (3) - DOHLER (M.) -   Routing requirements for urban low-power and lossy networks.  -  https://tools.ietf.org/html/rfc5548

  • (4) - PISTER (K.) -   Industrial routing requirements in low-power and lossy networks.  -  https://tools.ietf.org/html/rfc5673

  • (5) - BRANDT (G.) -   Home automation routing requirements in low-power and lossy networks.  -  https://tools.ietf.org/html/rfc5826

  • (6) - MARTOCCI (J.) -   Building automation routing requirements.  -  https://tools.ietf.org/html/rfc5867

  • ...

DANS NOS BASES DOCUMENTAIRES

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Réseaux Télécommunications

(163 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS