MULTI DOMICILIATION DANS LINTERNET DES OBJETS

UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

NGUYỄN QUANG DUY

MULTI-DOMICILIATION DANS
L'INTERNET DES OBJETS
MÔ HÌNH ĐA MẠNG CHỦ TRONG
« INTERNET KẾT NỐI VẠN VẬT »

MÉMOIRE DE FIN D'ÉTUDE DU MASTER INFORMATIQUE

Hanoï – 2015


UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

NGUYỄN QUANG DUY

MULTI-DOMICILIATION DANS
L'INTERNET DES OBJETS
MÔ HÌNH ĐA MẠNG CHỦ TRONG
« INTERNET KẾT NỐI VẠN VẬT »

Spécialité : Réseaux et Systèmes communicants
Code : Programme pilote

MÉMOIRE DE FIN D'ÉTUDE DU MASTER INFORMATIQUE
Sous la direction de :

Dr. Julien MONTAVONT
MCF, Université de Strasbourg

Hanoï – 2015


ATTESTATION SUR L’HONNEUR
J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données
et les résultats qui y sont présentés sont exacts et n’ont jamais été publiés ailleurs. La
source des informations citées dans ce mémoire a été bien précisée.

LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong Luận văn là trung thực và chưa từng được ai công bố
trong bất kỳ công trình nào khác. Các thông tin trích dẫn trong Luận văn đã được chỉ
rõ nguồn gốc.

Signature de l'étudiant :

NGUYEN Quang Duy

i


Remerciements
Au laboratoire ICube, où j'ai réalisé mon stage :
Je tiens à exprimer toute ma reconnaissance à mon encadrant de stage, Monsieur
Julien MONTAVONT, pour la soutien, l'aide, l'orientation, la guidance qu'il m'a
apportées durant mon stage, ainsi que tout au long de la réalisation de cette
mémoire. Sans lui, cette mémoire n'aurait jamais vu le jour.

Je tiens ensuite à remercier le directeur de l'équipe Réseaux du laboratoire ICube,
Monsieur Thomas NOËL, pour m'avoir donné cette occasion de stage.
J'adresse aussi mes remerciements à tous les professeurs, les doctorants, les
stagiaires de l'équipe Réseaux et la personnel au laboratoire ICube pour vos
accueilles et vos gentillesses pendant ma durée de stage.
À l'Institut Francophone International (IFI), où je fais mes études de Master :
Je souhaite exprimer ma sincère gratitude à tous mes professeurs de l’Institut
Francophone International, qui m'ont si bien enseigné, soutenu et encouragé à
accomplir jusqu'ici toutes les étapes de ma formation. Je réserve spécialement mes
sincères remerciements aux Messieurs NGUYEN Hong Quang et HO Tuong Vinh,
les responsables des études à l'IFI, pour leurs enthousiasme, support et
responsabilité.
Enfin, je remercie tous mes amis, les secrétaires et la personnel à l'Institut
Francophone International pour la compagnon, la confiance et l'aide pendant tout
au long de mes trois ans des études à l'IFI.

ii


Résumé
Internet des Objets est un scénario où les objets physiques qui sont munis de capteurs
et/ou d'actionneurs peuvent collecter et s'échanger d'informations depuis
l'environnement, ainsi d'être capable d'accéder à l'internet. Les réseaux locales dans
l'internet des objets ne peuvent pas utiliser les protocoles de routage classiques de la
pile TCP/IP à cause des limitations imposées des dispositifs de capteurs embarqués.
RPL est un protocole de routage IPv6 à vecteur de distance pour les réseaux à basse
puissance et avec perte (LLN), qui peut répondre à cette problématique. Par contre
dans le protocole RPL, il n'y a généralement qu'une racine et donc qu'un routeur de
bordure qui connecte aux autres réseaux. Pour cette raison, lorsque le nombre de
nœuds dans le réseau augmente, cette racine risque d'être surchargée. Deuxième

nouvelle problématique posée, si jamais cette racine tombe en panne, tout le réseau
d'objets se retrouve déconnecté.
Dans ce stage, nous avons utilisé la technique de multi-domiciliation dans l'internet
des objets. En outre, nous avons conçu une solution protocolaire « Syn-RPL » afin de
répondre aux deux problématiques mentionnées (la surcharge et la panne du routeur
de bordure) en utilisant un point de synchronisation et une racine virtuelle qui permet
de synchroniser plusieurs routeurs de bordure dans un réseau locale. J'ai mis en place
une campagne d'expérimentations avec trois phases de travail (phase de démarrage,
phase de réparation du DODAG et phase de gestion de la panne d'un routeur de
bordure) afin de mesurer les performances de ce protocole. Le modèle Syn-RPL
réponde à deux problématiques proposées avec le grand taux de réussit.

iii


Abstract
Internet of Things (IoTs) is a scenario in which the physical objects embedded sensors
and/or actuators collect and exchange the informations from the environment, and
they can also accesse internet. Local networks in IoTs can not use traditional routing
protocols like thoses in TCP/IP stack because of the limitations of the embedded
devices. RPL is a distance-vector routing protocol IPv6 designed for Low-power and
Lossy Networks (LLN), which is adapted for the mentioned limitations. However in
the RPL protocol, there is usually only one root/edge router which connects to other
outsided networks. For this reason, when the number of nodes in the local network
increases, the root may be overloaded. Second problem found is when this root fails
by some reason, the entire network of Things is also disconnected.
In this thesis, we used the multi-homing technique in IoTs. Moreover, we designed a
protocol which called "Syn-RPL" to meet the two mentioned problems (overload and
failure of the edge router) using a synchronization point and a virtual root which
allows to synchronize multiple edge routers in a local network. We have set up a plan

of experiments with three different phases (starting phase, repairing phase of DODAG
and management phase of the failure of an edge router) to measure the performance of
this protocol. The Syn-RPL model resolve the proposed problems with the high rate of
success.

iv


Table de matières
Attestation sur l'honneur

i

Remerciements

ii

Résumé

iii

Abstract

iv

Liste de figures

vii

Liste des tableaux

viii

1. Introduction

1

1.1. Problématique ………………………………………………………….

2

1.2. Motivation ……………………………………………………………...

2

1.3. Objectifs et contributions ………………………………………………

3

1.4. Environnement de stage ………………………………………………..

3

2. Contexte

5

2.1. Internet des Objets ……………………………………………………..

6

2.1.1. Pile de protocoles dans l'Internet des Objets …………………………

6

2.1.2. Réseaux de capteurs ………………………………………………….

7

2.1.3. IEEE 802.15.4 ………………………………………………………..

8

2.1.4. IPv6 …………………………………………………………………..

8

2.1.5. 6LowPAN ……………………………………………………………. 11
2.1.6. RPL …………………………………………………………………..

11

2.2. Multi-domiciliation dans l'Internet des Objets ………………………... 13
2.2.1. Multi-domiciliation ………………………………………………….. 13
2.2.2. Multi puits de collecte dans les réseaux d'objets ……………………. 14

v


3. Contribution pour la multi-domiciliation dans l'Internet des Objets

16

3.1. Approche de la multi-domiciliation dans l'internet des objets ………… 17
3.2. Racine virtuelle ………………………………………………………... 18
3.3. Point de synchronisation ………………………………………………. 19
3.4. Protocole Syn-RPL …………………………………………………….

20

3.4.1. Messages du protocole Syn-RPL …………………………………….

21

3.4.2. Phase de démarrage …………………………………………………..

22

3.4.3. Phase de réparation de DODAG ……………………………………..

23

3.4.4. Arrivée d'un nouveau routeur lors d'une phase de réparation ………..

24

3.4.5. Phase de gestion de panne du routeur de bordure ……………………

25

4. Expérimentation et analyse

26

4.1. Équipements …………………………………………………………...

26

4.1.1. Contiki ………………………………………………………………..

27

4.1.2. Cooja …………………………………………………………………

27

4.1.3. TelosB ………………………………………………………………..

28

4.1.4. Foren6 ………………………………………………………………..

28

4.1.5. Radvd ………………………………………………………………...

29

4.2. Expérimentation ……………………………………………………….. 29
4.2.1. Scénario expérimental ………………………………………………..

30

4.2.2. Expériences …………………………………………………………..

32

4.2.3. Configurations ………………………………………………………..

33

4.3. Analyse ………………………………………………………………...

35

4.3.1. Phase de démarrage …………………………………………………..

35

4.3.2. Phase de réparation du DODAG ……………………………………..

36

4.3.3. Phase de gestion de panne d'un routeur de bordure ………………….

38

5. Conclusion et perspectives

40

Annex A . Installation de Contiki

42

Annex B . Installation et configuration de Foren6

43

Références

45

vi


Liste de figures
1.1 FIT/IoT-lab et quelques équipements utilisés ………………………………..

4

2.1 Pile d'un modèle du réseau d'objets ………………………………………….

7

2.2 Exemple d'un réseau de capteurs …………………………………………….

8

2.3 Unicast adresses locale de lien et globale ……………………………………

9

2.4 Une exemple de la construction d'une adresse d'interface EUI-64 ………….. 10
2.5 En-tête IPv6 …………………………………………………………………. 10
2.6 Scénario « chaque hôte connecte aux routeurs » ……………………………. 14
2.7 Deux approches de multi puits de collecte dans les réseaux d'objets ……….. 15
3.1 Multi-domiciliation dans le réseau d'objets avec m routeurs de bordure et n
nœuds ………………………………………………………………………... 17
3.2 Exemple d'un réseau d'objets avec la racine virtuelle ……………………….. 18
3.3 Démarrage des connexion entre PS et BRs …………………………………. 22
3.4 Réparation d'un DODAG ……………………………………………………. 23
3.5 Connexion d'un nouveau routeur de bordure pendant une phase de
réparation du DODAG associé ……………………………………………… 24
3.6 Traitement de panne du routeur de bordure …………………………………. 25
4.1 Simulateur COOJA ………………………………………………………….. 27
4.2 TelosB ……………………………………………………………………….. 28
4.3 Interface de foren6 …………………………………………………………... 29
4.4 Scénario expérimental ……………………………………………………….. 31
4.5 Comparaison entre RPL et Syn-RPL dans la phase de démarrage ………….. 35
4.6 Comparaison entre RPL et Syn-RPL dans la phase de réparation …………..

37

4.7 Gestion de panne du routeur de bordure …………………………………….

38

B.1 Fenêtre « Manage Sniffers » pour la configuration de renifleur dans foren6 .. 44

vii


Liste des tableaux
2.1 Messages du protocole RPL …………………………………………………. 12
3.1 Informations synchronisées …………………………………………………. 19
3.2 Informations dans table d'association ……………………………………….. 20
3.3 Messages du protocole synchronisé …………………………………………. 21

viii


Chapitre 2. Contexte

Chapitre 1

Introduction
J'ai effectué mon stage de Master 2 au sein de l'équipe de recherche Réseaux du
laboratoire français des sciences de l'Ingénieur, de l'Informatique et de l'Imagerie
(ICube). Motivé par les réseaux modernes et désiré d'être un chercheur dans l'avenir,
j'ai choisi ce stage, un stage de recherche, qui me permettait de maîtriser des
compétences dans ma formation, ainsi que d'être compatible avec mon orientation
professionnelle.
Le sujet de stage proposé portait sur la multi-domiciliation dans l'Internet des Objets
(IdO, ou IoT pour « Internet of Things » en anglais). Globalement, l'internet des objets
est un scénario où les objets physiques qui sont munis de capteurs et/ou d'actionneurs
peuvent collecter et s'échanger d'informations depuis l'environnement, ainsi d'être
capable d'accéder à l'internet. Multi-domiciliation est une technique dans les réseaux
informatiques, qui améliore la fiabilité de connectivité d'internet en utilisant au moins
de deux réseaux d'informatique. En outre, j'ai conçu et mis en œuvre sur une plateforme expérimentale un nouveau protocole qui permet d'offrir plusieurs passerelles à

un même réseau d'objets.
Ce manuscrit est organisé en cinq chapitres. Dans la suite de ce premier chapitre, je
1


Chapitre 2. Contexte

continue à présenter les informations globales du stage : les problématiques du sujet
de stage, mes objectifs et contributions, l'environnement de stage, etc. Je poursuive
l'état de l'art dans le deuxième chapitre en synthétisant les protocoles qui constituent la
pile du réseau d'objets et en introduisant la technique de multi-domiciliation. Le
troisième chapitre, le cœur de mon travail, est consacrée à présenter ma solution
protocolaire afin de résoudre les problématiques posées. Le quatrième chapitre,
j'expliquerai la campagne d'expérimentations sur une plat-forme de test proposée, puis
analyserai les résultats obtenus. Au final, conclut ce stage en présentant les
perspectives de recherche de travail dans le cinquième chapitre.

1.1. Problématique
Dans l'internet des objets, une grande nombre des objets physiques se connectent et
sont capable d'accéder à l'internet global. Ces nœuds sont généralement munis de
capteurs (capteurs de sonore, de vibrations, de luminosité, etc.) et/ou d’actionneurs
afin de surveiller ou d’interagir avec leur environnement. Les informations collectées
sont généralement envoyées de proche en proche vers un puits de collecte via une
technologie de communication sans fils. Un protocole de routage est donc nécessaire
afin que chaque nœud puisse déterminer une route pour joindre le puits de collecte.
Cependant, ces nœuds sont extrêmement contraintes en termes de capacité de calcul,
de mémoire et d'énergie. Il n'est donc pas envisageable d'utiliser les protocoles de
routage classiques de la pile TCP/IP tels que RIP ou OSPF car ces derniers s'avèrent
relativement en ressources. RPL est un protocole de routage IPv6 à vecteur de
distance pour les réseaux à basse puissance et avec perte (LLN), qui peut répondre à

cette problématique. Par contre dans RPL, il n'y a normalement qu'une racine et donc
qu'un unique routeur de bordure avec les autres réseaux. Pour cette raison, tout le
trafic montant (des nœuds vers internet) et descendant (d'internet vers les nœuds)
passent par cette racine ce qui risque des créer des congestions. De plus, si jamais
cette racine tombe en panne, tout le réseau d'objets se retrouve déconnecté. Pour palier
ces problèmes, on peut ajouter plusieurs routeurs de bordure afin de multi-domicilier
le réseau d'objets.

1.2. Motivation
J'avais une grande motivation vis-à-vis de ce stage. Avant tout, le sujet de stage porte
sur l'internet des objets, qui est mon domaine préféré. Ensuite, j'avais de l'occasion
2


Chapitre 2. Contexte

d’entraîner mes compétences au sein d'une telle environnement de recherche
professionnel, l'équipe Réseaux du laboratoire ICube, en réalisant ce stage. En outre,
je souhaite poursuivre en thèse de doctorat et devenir un chercheur d'informatique
dans l'avenir.

1.3. Objectifs et contributions
L'objectif du stage consistait à concevoir un protocole de réseau qui permet à
plusieurs passerelles/routeurs de bordure de collaborer afin de partager le trafic de
réseau en provenance ou à destination d'un réseau d'objets. En cas de défaillance d'un
routeur de bordure, les autres routeurs de bordure devaient prendre en charge, de
manière transparente, le trafic qui passait par le routeur en panne. Ce nouveau
protocole devait s'appuyer sur le protocole RPL et devait être déployé sur une
maquette à petite échelle afin d'évaluer ses performances.
J'ai conçu une protocole qui permet de répondre aux deux objectifs (partage de charge

et gestion de panne) en utilisant une racine virtuelle qui permet de synchroniser les
différents routeurs de bordure. J'ai également monté une plate-forme de test avec des
équipements réseaux et des nœuds munis de capteurs afin de déployer en situation
réelle. Enfin, j'ai mené une campagne d'expérimentations afin de mesurer les
performances de ce protocole et d'identifier les points d'amélioration possibles.

1.4. Environnement de stage
Le laboratoire ICube est une unité mixte de recherche (UMR n°7357) sous la cotutelle
de l'Université de Strasbourg, du Centre National de la Recherche Scientifique
(CNRS), de l'École Nationale du Génie de l'Eau et de l'Environnement de Strasbourg
(ENGEES) et de l'Institut National des Sciences Appliquées (INSA) de Strasbourg.
L'équipe Réseaux du laboratoire ICube bénéficie d'une forte expérience dans le
domaine de l'Internet des Objets multi-sauts. En outre, elle a développé de nombreux
protocoles aux niveaux 2 (MAC) et 3 (routage) de la pile de communications pour
l'Internet des Objets multi-sauts afin de limiter la consommation énergétique et
d'augmenter les performances du réseau. D'autre part, l'équipe Réseaux administre la
plat-forme IoT-Lab strasbourgeois de l'Équipe FIT (Future Internet of Things). Cette
plate-forme distribuée sur 5 sites français (Lille, Grenoble, Paris, Rennes et
3


Chapitre 2. Contexte

Strasbourg), composée de plus de 2700 nœuds capteurs, offre aux chercheurs/centres
de recherches académiques ou industriels la possibilité de développer de nouveaux
concepts, usages ou protocoles de communication pour l'Internet des Objets.

FIT/IoT-lab

Quelques capteurs

Figure 1.1 : FIT/IoT-lab et quelques équipements utilisés

4


Chapitre 2. Contexte

Chapitre 2

Contexte
Le terme « Internet des Objets » a été publié première fois par Kevin Ashton dans une
conférence informatique en 2009. Internet des objets est la concept globale d'un grand
nombre de domaines de recherche et d'application tels que : réseau de capteurs,
domotique, réseau d'électricité intelligente, système de transport intelligente, etc. Au
sein de ce stage, j'ai travaillé sur un modèle de réseau d'objets qui ressemble à un
réseau de capteurs sans fils et dont la pile de protocoles est constituée des protocoles
informatiques de IEEE 802.15.4, IPv6, 6LowPAN, RPL, etc. En outre, j'ai utilisé la
technique multi-domiciliation, une technique de réseaux informatiques qui permet
d'améliorer la fiabilité de connectivité d'internet en offrant plusieurs passerelles à un
seul réseau. Connaissances sur les standards et techniques mentionnées sont
extrêmement nécessaires pour ce stage.
Dans la suite du chapitre, je donnerai une concept globale de l'internet des objets.
Ensuite, nous passerons respectivement les standards de la pile d'un modèle de réseau
d'objets (IEEE 802.15.4, IPv6, 6LowPAN, RPL) et la technique de multidomiciliation.

5


Chapitre 2. Contexte

2.1. Internet des Objets
Il existe plusieurs définitions différentes du terme « Internet des Objets ». Cependant,
ces définitions procèdent une caractéristique en commun : l'intégration de la partie
physique (les objets physiques) avec la partie virtuelle (l'internet) dans l'internet des
objets [7]. La partie physique est considérée comme toutes les choses en physique tels
qu'une voiture, un frigo, un animal ou un humain, etc. Ces choses deviennent les
nœuds de l'internet des objets en étant munis de capteurs (capteurs de sonore, de
vibrations, de luminosité, etc.) et/ou d'actionneurs afin de surveiller ou d'interagir avec
leur environnement. Dans la partie virtuelle de l'internet, chaque nœud possède une
identifié unique et les nœuds qui accèdent à l'internet via un même routeur, composent
un réseau d'objets. À partir de cette caractéristique, nous avons offert un concept pour
l'internet des objets : Internet des objets est un scénario où tous les objets physiques
qui sont munis de capteurs et/ou d'actionneurs peuvent collecter et s'échanger
d'informations depuis l'environnement, ainsi d'être capable d'accéder à l'internet.
Internet des Objets peut être partagé aux réseaux d'objets. Dans la carde de ce stage,
un réseau d'objets est en effet un réseau de capteurs sans fils. Les protocoles IPv6,
6LowPAN, IEEE 802.15.4 et RPL sont utilisés afin de construire un standard de pile
de protocoles officielle pour ce réseau.

2.1.1. Pile de protocoles dans l'Internet des Objets
La concept de l'internet des objets comprend un nombreux domaines de recherche et
d'application. Pour cette raison, il existe de grandes possibilités afin de constituer une
pile de protocoles pour un réseau d'objets.
Suivre la normalisation IETF (« Internet Engineering Task Force » en anglais), nous
pouvons construire la pile de protocoles des réseaux d'objets comme celle des réseaux
à faible puissance et avec perte (LLN pour « Low-power and Lossy Networks » en
anglais) [10]. Cette pile de protocoles est composée par six couches différentes, en
ordonnant ce sont : physique, liaison, adaptation, réseau, transport et application.
Sauf deux dernières couches (transport et application), les autres couches seraient

présentées détaillent dans la suite du chapitre.
Vue d'ensemble de la pile de protocoles du réseau d'objets : deux couches liaison et
physique sont construites en utilisant le standard IEEE 802.15.4 ; les protocoles IPv6
et RPL sont mis en œuvre sur la couche réseau ; la couche adaptation est définie par le
6


Chapitre 2. Contexte

standard 6LowPAN. Parmi les couches mentionnées, la couche adaptation est
nouvelle par rapport aux standards anciens de pile de protocoles tels que le modèle
OSI, le modèle TCP/IP.

Figure 2.1 : Pile d'un modèle de réseau d'objets

2.1.2. Réseaux de capteurs
Un Réseau de Capteurs (RdC ou WSN pour « Wireless Sensors Networks » en
anglais), est composé d'un grand nombre de nœuds de capteurs, qui peuvent être
déployés à forte densité à l'intérieur [2]. Grâce aux capteurs et/ou actionneurs intégrés,
ces nœuds sont capables de s'informer des données de l'environnement (la
température, l’humilité, la puissance, etc.), et de transférer ces informations vers un
serveur (une machine pour la gestion du réseau, le traitement des informations
obtenues et la communication avec des autres systèmes) via un puits de collecte du
réseau. À l'inverse, le serveur informe les signales de contrôle aux nœuds, aussi en
passant ce puits de collecte. Un routeur normalement fait le rôle d'un puits de collecte
et il s'appelle un routeur de bordure.
Les caractéristiques importantes des réseaux de capteurs:
•

Nœuds peuvent être densément déployés (centaines nœuds au sein d'un réseau).

•

Mobilité des nœuds entraîne le changement de la topologie du réseau.

•

Défaillance de nœuds peut causer les pannes de route dans le réseau.

•

Nœuds sont contraintes en termes de capacité de calcul, de puissance de radio,
d'énergie et de mémoire.

•

Communication des nœuds limite au sein du réseau. En théorique, ces nœuds
ne peuvent pas accéder à l'internet avec une identité unique.
7


Chapitre 2. Contexte

•

Un réseau de capteurs possède généralement un seul routeur de bordure [12].

Figure 2.2 : Exemple d'un réseau de capteurs

Une remarque : un réseau de capteurs est un réseau à faible puissance et avec perte

(LLN). Cependant, l'inverse de cette remarque n'est pas vrai [8].

2.1.3. IEEE 802.15.4
IEEE 802.15.4 est un standard de protocole publié par IETF. Ce standard est destiné
aux réseaux sans fils. Standard IEEE 802.15.4 spécifie la première couche (physique)
et la deuxième couche (liaison) pour les réseaux locales sans fils à faible coût, vitesse
et puissance.
Standard IEEE 802.15.4 est utilisé officiellement dans les réseaux de capteurs. À
cause de la flexibilité de ce standard, on peut l'intégrer avec un des standards
suivantes de troisième couche : Zigbee, WirelessHart ou IPv6 avec 6LowPAN, etc.
La taille de trame maximale dans le standard IEEE 802.15.4 n'est que 127 octets. À
cause de cette limitation, la fait d'utiliser directement le protocole IPv6 dans la
troisième couche avec le standard IEEE 802.15.4 dans les deux premières couches est
une mauvais idée [section 2.1.3].

2.1.4. IPv6
Protocole IPv4 (Internet Protocol version 4) est le protocole officiel de l'internet.
Cependant, la capacité de domaine d'adresse IPv4 (« Internet Protocol version 4 » en
anglais) est de plus en plus épuisée. Depuis les dernières années, IPv6 (« Internet
8


Chapitre 2. Contexte

Protocol version 6 » en anglais) est considéré comme le remplacement de IPv4 car il
est capable de résoudre des problèmes en suspens, ainsi que possède beaucoup
d'avantages par rapport au IPv4 [1]. IPv6 est le protocole d'internet pour l'avenir et
l'Internet des Objets dépende de IPv6.
Adresse. Le protocole d'internet augmente la taille d'adresse de 32 bits pour la version

4 à 128 bits pour la version 6. La nombre de nœuds disponibles dans l'internet hausse
donc de 232 à 2128, c'est un nombre très énorme. En outre, IPv6 offrir trois types
d'adresse : unicast, multicast et anycast, qui sont respectivement pour la connexion
d'un point à un point ; la connexion d'un point à des multi-points ou des multi-points
aux autres multi-points ; la connexion d'un point à un point spécifique dans un groupe
de nœuds avec la même adresse IPv6. Ces trois types d'adresse permettent de mettre
en œuvre beaucoup d'applications différentes.
En utilisant IPv6, chaque nœud dans l'internet possède généralement deux adresses
unicast IPv6 différentes, ce sont : l'adresse locale de lien (« link-local » en anglais) et
l'adresse globale [3]. Adresse locale de lien fonctionne seulement dans le réseau local
qui est un petit segment dans l'internet et dont les nœuds sont dans une zone limitée.
Par contre, l'adresse globale est une adresse unique au sein de réseau globale.

Adresse Link-local

Adresse Global
Figure 2.3 : Unicast adresses locale de lien et globale

Une adresse unicast IPv6 est composée de deux parties : préfixe de IPv6 et interface
ID. Pour l'adresse locale de lien, le préfixe IPv6 est fixé à 64 bits. Le préfixe de
l'adresse globale n'est pas fixé et il représente la topologie publique du réseau. La
partie internet ID est construite en utilisant la formule EUI-64 (« 64-bits Extended
Unique Identifier » en anglais), qui peut produire 64 bits d'adresse unique à partir de
l'adresse MAC.

9


Chapitre 2. Contexte

Figure 2.4 : Une exemple de la construction d'une adresse d'interface EUI-64

Configuration d'adresse. Comme IPv4, une adresse IPv6 peut être configuré

manuellement (configuration manuelle) ou automatiquement (auto-configuration).
Cependant, outre l'auto-configuration avec état (« Stateful address autoconfiguration
» en anglais), qui est connue avec le nom DHCP (« Dynamic Host Configuration
Protocol » en anglais) dans les réseaux IPv4, l'auto-configuration sans état («
Stateless address autoconfiguration » en anglais), la nouvelle auto-configuration
désignée pour le protocole IPv6, est utilisé fréquemment [13].
Fonctionnement d'auto-configuration sans état s'appuie sur le protocole Découvert de
Voisinage (NDP pour « Neighbor Discovery Protocol » en anglais). Ce protocole
définie cinq types de paquets ICMPv6 aux fins de sollicitation du routeur, l'annonce
de routeur, voisin sollicitation, voisin publicité et les redirections de réseau. À l'aide
de ce protocole, en utilisant seulement les adresses locales, les nœuds sous un réseau
peuvent recevoir le préfixe de ses routeur et donc configurent leur adresses globales.
Ce protocole fournisse également le mécanisme pour éviter les conflits d'adresse
globale.
En-tête IPv6. Un paquet IPv6 comprends deux parties : l'en-tête et la charge utile, avec

le MTU (« Maximum Transmission Unit » anglais) est 1280 octets. En-tête des
paquets IPv6 est simple (moins de champs par rapport à l'en-tête du protocole IPv4) et
la taille de l'en-tête IPv6 est fixée à 40 octets, c'est donc facile pour le processus de
traitement. Il est possible pour plusieurs extensions (la partie qui prend les
informations supplémentaires) suivent l'en-tête IPv6.

Figure 2.5 : En-tête IPv6

10

Chapitre 2. Contexte

L'extension d'en-tête qu'on utilise le plus souvent est ICMPv6 (« Internet Control
Message Protocol version 6 » en anglais). Cette extension peut contenir d'un des
messages importants du protocole NDP, du protocole RPL [section 2.1.5], etc.

2.1.5. 6LowPAN
6LowPAN (« IPv6 over Low-Power Wireless Personal Area Networks » en anglais)
est défini par IETF (« Internet Engineering Task Force » en anglais) [4] comme une
technique pour appliquer le protocole IPv6 dans les réseaux des capteurs. 6LowPAN
est situé dans la couche adaptation (la couche 2.5) entre la couche réseau et la couche
de liaison IEEE 802.15.4.
Pour rappel, la taille d'un paquet maximale de couche physique n'est que 127 octets.
Ce paquet comprend deux parties : l'en-tête à 25 octets et la charge utile à 102 octets.
Cette charge utile est la trame de la couche liaison. Cette trame comprend aussi deux
parties : l'en-tête peut être à talle de 21 octets, le reste pour la charge utile à 81 octets.
Cette charge utile est composé par l'entête de la couche réseau, l'en-tête de la couche
transport et les données d'application. Lors que nous utilisons une en-tête la plus petite
de la couche transport, UDP (« User Datagram Protocol » en anglais), à 8 bytes avec
l'en-tête IPv6 à 40 octets, il ne reste qu'une petite taille à 33 octets pour les données
application. En outre, la MTU (« Maximum Transmission Unit » en anglais) d'un
paquet du protocole IPv6 peut être à 1280 octets. Ce nombre est trop grand pour la
couche liaison. Pour les raisons mentionnés, nous avons besoin de la couche
adaptation qui utilise le standard 6LowPAN.
Technique 6LowPAN comprend deux services principaux : la compression d'en-tête et
la fragmentation. Service de compression d'en-tête utilise plusieurs techniques
(LOWPAN_HC1, LOWPAN_HC2, LOWPAN_ICHP, LOWPAN_NHC) afin de
diminuer la taille de l'en-tête IPv6. Ces techniques suppriment des champs inutiles,
compressent des champs longues à des champs plus courts avec des bits de

signification. Service de fragmentation est utilisé lors que le paquet IPv6 après la
compression d'en-tête est toujours plus grande que 102 octets. Ce paquet est donc
divisé en plusieurs parties pour le processus de transport. À la destination, ces parties
fragmentées sont rassemblées afin de récupérer le paquet.

2.1.6. RPL
RPL (Ripple) est un protocole de routage à vecteur de distances IPv6 qui est créé par
11


Chapitre 2. Contexte

le groupe ROLL (Routing Over Low-power and Lossy). Ce protocole est désigné pour
les réseaux à faible puissance et avec perte (LLN). Dans le pile de protocoles du
réseau LLN, le protocole RPL est intégré avec le protocole IPv6 dans la couche
réseau. L'objectif du protocole RPL est de construire et maintenir un graphe DODAG
(Destination-Oriented Directed Acyclic Graph) qui est la topologie du réseau. La
construction du graphe (DODAG) dépende aux de paramètres configurés : la fonction
objective et l'ensemble de métrique et contrainte de routage. Avec chaque fonction
objectif différente, les nœuds dans un réseau suivent donc une stratégie différente afin
de choisir le parent, de se joindre au DODAG. De même, le paramètre de métrique de
routage permet aux nœuds de décider les meilleurs routes pour le routage.
Messages de communication. Les messages de gestion du RPL sont les messages

ICMPv6 (Internet Control Message Protocol version 6). Dans le protocole RPL, il y a
4 messages : DIS, DIO, DAO et DAO-ACK. Chaque message comprend la partie de
base et des options facultatives.
Message

Nom

Informations portées

Fonction

DIS

DODAG Information
Solicitation

DIO

DODAG Information RPLInstanceID
; Transporter
des
informations
Object
Nombre de version ; nécessaires pour la construction et
Rang ; DODAGID ; la réparation d'un DODAG ;
DTSN
Maintenir DODAG.

DAO

Destination
RPLInstanceID
Advertisement Object DAO séquence
DODAGID

Solliciter un message DIO d'un

nœud de RPL.

; Propager les informations de
; destination vers le haut le long de
DODAG.

Table 2.1 : Messages du protocole RPL

Les significations des informations (RPLInstanceID, DODAGID, Nombre de version,
Rang, etc) seront expliquées détaillent dans une autre section [section 3.2].
Construction du DODAG. Pour construire le DODAG, le routeur de bordure envoie les

messages DIO aux nœuds qui sont au sein de son échelle de radio. Après avoir reçu le
message DIO d'un routeur de bordure, chaque nœud calcule pour décider de se joindre
à ce DODAG ou de le refuser lors qu'il est dans la meilleur condition. Ces nœuds
continuent à diffuser les messages DIO aux autres nœuds.

12


Chapitre 2. Contexte
Routage. Dans le protocole RPL, il y a deux types de routage : le routage montant et le

routage descendant. Lors du routage montant, les flux sont à partir de nœuds de
feuille vers la racine. Lors du routage descendant, les flux sont à partir de la racine
vers les nœuds de bordure du DODAG.
Réparation du DODAG. Lors qu'un route dans le réseau est déconnecté brusquement et

il n'est pas capable de se restaurer, le DODAG a besoins d'être réparé. Cet accident est
survenu généralement à cause de la limitation de batterie des nœuds. Pour résoudre ce

problématique, le protocole RPL fournisse deux méthodes de réparation, ce sont : la
réparation locale et la réparation globale. Lors de la réparation locale, les nœuds fils
du nœud déconnecté vont essayer de se rejoindre au DODAG en chercher un autre
nœud parent eux-même. Par contre, dans la réparation globale, le routeur de bordure
augmente la version du DODAG et diffuser les DIO avec cette nouvelle version du
DODAG afin de reconstruire ce DODAG.

2.2. Multi-domiciliation dans l'Internet des Objets
Multi-domiciliation est une technique des réseaux informatiques. Deux intérêts
principaux de cette technique sont la partage de charge et la gestion de panne dans les
réseaux d'internet. Cependant, il n'existe pas encore d'adaptation officielle de cette
technique sur l'internet des objets.

2.2.1. Multi-domiciliation
Multi-domiciliation (« Multihoming » en anglais) est une stratégie dans les réseaux
informatiques, qui améliore la fiabilité de connectivité d'internet en utilisant au moins
de deux réseaux d'internet. Un exemple de multi-domiciliation est d'utiliser deux
Fournisseurs d'Accès à Internet (FAI, ou ISP pour « Internet Service Provider » en
anglais). Ces deux fournisseurs dans cet exemple connectent au réseau local via deux
routeurs séparés. Ce réseau local peut donc partager en deux sous-réseaux afin d'aller
à l'internet mais il reste toujours la connectivité locale. Lors que la connexion d'une
machine vers le premier fournisseur est déconnectée, l'utilisateur peut quand même
aller à l'internet via la connexion du deuxième fournisseur.
Il existe nombre scénarios pour un environnement de multi-domiciliation [11] : les
hôtes connectes aux routeurs via un seul lien ; les hôtes connectes aux routeurs via
une passerelle temporaire ; chaque hôte connecte aux routeurs, etc. Le choix d'un
scénario dépense de l'objectif et des équipements disponibles dans le réseau adapté.
13

Chapitre 2. Contexte

Au sein de ce stage, on travaille avec le scénario où chaque hôte connecte à plusieurs
routeurs.

Figure 2.6 : Scénario « chaque hôte connecte aux routeurs »

2.2.2. Multi puits de collecte dans les réseaux d'objets
Pour rappel, un réseau de capteurs typique ne possède qu'un puits de collecte qui est
responsable de collecter des données depuis des autres nœuds [2]. On appelle ces puits
de collectes comme les routeurs de bordures. En tant que taille du réseau se
développe, ça veut dire que le nombre de nœuds au sein de ce réseau est de plus en
plus nombreux, les problèmes de la perte des paquets et de la consommation d'énergie
deviennent plus graves, qui peuvent entraîne à la surcharge. Utilisation des multi puits
de collecte est une stratégie qui peut augmente les performances du réseau de capteurs
(en termes de perte de paquets, durée de vie des nœuds, etc), chaque nœud de capteur
communique uniquement avec le puits de collecte le plus proche [12]. Les réseaux
d'objets où RPL est considéré comme le protocole de routage officiel, peut appliquer
cette stratégie de multi puits de collecte. Combinaison de RPL et multi puits de
collecte entraîne à deux sous-approches : multi DODAGs et DODAG avec une racine
virtuelle.
Au sein de la première approche, multi DODAGs, chaque routeur de bordure crée son
propre DODAG. Outre l'avantage de résoudre le problème de surcharge, il reste
encore d'inconvénient. Effectivement, communications entre des DODAGs causent
des traitements supplémentaires. Lors qu'on veut créer une route de deux nœuds
appartiennent à deux DODAGs différentes, il faut avoir une étape pour la recherche
entre des DODAGs.
Au sein de la deuxième approche, DODAG avec une racine virtuelle, une seul
DODAG est construit et les différentes routeurs de bordure ne sont que les sous14

Chapitre 2. Contexte

arbres. Cette solution est plus pratique que la première approche : au lieu d'avoir des
étapes de la recherche entre des DODAGs, chaque routeur de bordure communique
directement à la racine virtuelle, qui connaît toutes les routes du réseau. En plus de
l'avantage de traitement, cette solution est plus efficace au domaine de mémoire, car la
racine virtuelle est responsable de mémoriser toutes les routes du réseau.

Multi DODAGs

DODAG avec une racine virtuelle
Figure 2.7 : Deux approches de multi puits de collecte dans les réseaux d'objets

15