Iot Handout

Notes :
Une brève introduction aux

protocoles réseaux pour l’IoT
Chaput Emmanuel
2021-2022
Chaput Emmanuel Une brève introduction auxprotocoles réseaux pour l’IoT 2021-2022 1 / 83
Plan I
Notes :
1 Introduction
2 L’architecture 6TiSCH
3 Le protocole COAP
4 Le standard MQTT
5 Le protocole RPL
6 Références bibliographiques
Introduction
Notes :
1 Introduction
Contexte de l’IoT
Notes :
Fondé sur l’utilisation d’un grand nombre de capteurs

Bas coût
Sans fil
Pauvres en énergie
Contextes applicatifs variés
Observation de l’environnement
Santée
Processus industriels
...
Besoin d’une architecture de communication
Fiable, déterministe
Énergétiquement efficace
Capable de passer à l’échelle
...
⇒ Quelle standardisation du côté de l’IETF ?
L’architecture 6TiSCH
Notes :
L’architecture
IEEE 802.15.4e
La sous couchee 6top
6LowPAN
Le groupe de travail 6tisch

Notes :
IPv6 over the TSCH mode of IEEE 802.15.4e [11]

Créé en 2013
Dans la zone Internet Area (int)
Déploiement de IPv6 sur le mode TSCH de IEEE 802.15.4e
Initialement, il s’intéressait essentiellement au routage
Définir une architecture
Définir une sous-couche 6top pour négocier les ressources d’ordonnancement
Spécifier une fonction de scheduling
Fournir des spécifications au groupe DetNet
...
Lien avec des groupes tels que 6LoWPAN, ROLL, CoRE, . . .
L’architecture
Notes :
L’architecture
IEEE 802.15.4e
6LowPAN
L’architecture protocolaire 6TiSCH

Notes :
Le routage est assuré par RPL
Le procotocle applicatif COAP
Approche RESTful
D’autres protocoles existent (eg MQTT)
Les applications utilisent UDP
Pour des raisons de performances
Messages de petite taille
MQTT utilise de préférence TCP
IP v6 est au cœur du réseau
Choix des groupes de travail de l’IETF
IP v4 reste utilisable
6LowPAN
Adaptation des paquets IPv6 aux technologies de communication
6top
La couche 6top permet de piloter l’ordonnancement TSCH
Elle fournit à la couche supérieure une interface permettant de paramétrer la
QoS
Le protocole 6P permet aux entités de dialoguer
TSCH est la couche d’accès au support
Time Slot Channel Hopping
La couche physique utilisée est celle de IEEE802.15.4
IEEE 802.15.4e
Notes :
L’architecture
IEEE 802.15.4e
6LowPAN
La technologie IEEE 802.15.4
Notes :
Low-Rate Wireless Personal Area Networks (LR - WPAN)

Technologie à bas coût (énergétique notemment)
Faible débit (250 Kbps)
Courte distance
Bandes 2.4 GHz, 900 MHz, 868MHz
CSMA / CA
Diverses évolutions
IEEE 802.15.4 A en 2007
Nouvelles couches physiques : UWB et CSS
Intègre celles de 802.15.4-2006 à base de DSSS et PSSS
IEEE 802.15.4e en 2012
Intégration d’une couche MAC à base de channel hopping : TSCH
Vise l’Industrial IoT
⇒ Voir le cours de G. Jakllari
TSCH
Notes :
Problèmes de IEEE 802.15.4

Peu fiable
Délai non borné
Pas de protection contre les interférences
...
Définition d’une extension (IEEE 802.15.4e)
Time Slotted Channel Hopping (TSCH)
Deterministic and Synchronous Multi-channel Extension
(DSME)
Low Latency Deterministic Network (LLDN)
De nombreux points restent à règler par les couches
supérieures [28]
La construction et la maintenance du réseau
Le routage
La gestion des ressources
L’ordonnancement
La sous couche 6top

Notes :
L’architecture
IEEE 802.15.4e
6LowPAN
La sous-couche 6top
Notes :
Elle fournit un cadre permettant de définir un

ordonnancement au dessus de TSCH
Définition de fonctions d’ordonnancement SF scheduling
function
Spécification du protocole 6P qui leur permet de
communiquer
Une SF décide d’ajouter ou supprimer des cellules
Elle communique avec son homologue au travers du
protocole 6P
Les fonctions d’ordonnancement restent à définir
Une fonction minimale a été proposée [2]
Travaux de recherche en cours
Les principes de bases : la cellule

Notes :
La cellule, élément de base de la communication [28]

Elle décrit les ressources de communication (slot, porteuse)
Elle peut être dédiée ou partagés (via un algorithme de backoff)
Elle peut être en émission ou/et en réception, ou non utilisée (sleep)
Elle donne l’adresse de l’interlocuteur
Elle peut être hard (allouée statiquement) ou soft
La configuration minimale de 6TiSCH définit
Une seule slotframe de taille à définir
Dont une seule cellule est ordonnancée
Lorsque A souhaite ajouter/supprimer/déplacer une cellule de
communication avec B
Il utilise une cellule dédiée
Une cellule partagée si ce n’est pas possible
Les principes de bases : une transaction

Notes :
L’équipement A souhaite ajouter deux cellules pour sa

communication avec B
Il envoie un message 6P de requête à B
Il y propose au moins deux cellules
B accuse réception de ce message
Au niveau 802.15.4
L’équipement B envoie une réponse à A
Il y liste les cellules choisies
A accuse réception de ce message
Au niveau 802.15.4
Les cas d’erreurs sont évidemment prévus
Timer de retransmission
Messages d’erreur 6P
Ce sont plus précisément les fonctions d’ordonnancement
qui dialoguent
Désignées par le champ SFID
L’échange peut être en 3 temps
B propose les cellules
Un exemple : MSF
Notes :
Minimal Scheduling Function [2]

Définit les règles d’ajout/suppression de cellules
Fondée sur la configuration minimale 6TiSCH [27]
Décrit le comportement du nœud dès son entrée dans le réseau
Recommande l’utilisation de 3 slotframes
Slotframe 0 pour l’accès au réseau (bootstrap traffic)
Slotframe 1 composée de cellules “autonomes”
Slotframe 2 composée de cellules négociées
Ajout/suppression/déplacement de cellules de communication avec son
parent (cf RPL)
Pour s’adapter aux besoins du trafic
Pour changer de parent
Pour prendre en compte des collisions
Transactions en deux temps uniquement
Initiées par un nœud vers son parent
Au moins 5 cellules doivent être proposées
Aucune règle n’est imposée pour choisir les cellules
Un mécanisme de scrutation peut être mis en place pour minimiser les risques
de collision
6LowPAN
Notes :
L’architecture
IEEE 802.15.4e
6LowPAN
Le groupe de travail 6LowPAN

Notes :
IPv6 over Low power WPAN [10]

Créé en 204
Dans la zone Internet Area (int)
Focalisé sur l’utilisation d’IPv6 dans des réseaux contraints
En particulier IEEE802.15.4e
Nœuds limités en énergie, mémoire, . . .
Définition et analyse des difficultés dans ce contexte [15]
Proposition d’une technique d’encapsulation
Fragmentation
Gestion d’adresse
Découverte des voisins
Compression d’entête
Aujourd’hui terminé (2014)
IPv6 sur IEEE 802.15.4e
Notes :
Quelles applications ? [15]

Définir des use cases [14]
Mettre en évidence les besoins afin de définir les protocoles
Quelle gestion des addresses ?
Adresses IPv6 sur 128 bits
Adresses IEEE étendues sur 64 bits (EUI -64)
Identifiant 16 bits
Quelle encapsulation ?
Paquets IP nécessitant 1280 octets
Trames de 127 octets
Quel rendement ?
Taille des entêtes (IPv6, sécurité, . . . )
Trames de 127 octets
Quel routage ?
Maillage non total
Accès à une passerelle
Quelle Configuration ?
Distribution des adresses
...
Encapsulation
Notes :
La RFC 4944 définit un format d’encapsulation

Transmission of IPv6 Packets over IEEE 802.15.4 Networks
Utilisation de trames de données avec accusé de réception
Un mécanisme de fragmentation/réassemblage est
nécessaire
La place disponible pour la charge utile peut être de 81
octets !
Des entêtes s’insèrent entre le niveau 2 et IPv6 qui
permettent de gérer
La fragmentation Dispatch Type d’entête
01 000001 IPv6
Assez similaire à la fragmentation IPv4 01 000010 LOWPAN_HC1 (compression)
La compression d’entête 01 010000 LOWPAN_BC0 (broadcast)
10 xxxxxx MESH (entête mesh)
Entête IPv6 cmpressée sur un octet 11 000xxx FRAG1 (fragmentation)
Fondée sur des propriétés du lien plutôt que sur une session 11 100xxx FRAGN (fragmentation)
Extensions proposées [8] ... ...
L’adressage
Adresses sur 16 ou 64 bits en fonction de Very First et Final
Quel routage ?
Notes :
Le groupe de travail 6LowPAN s’est intéressé aux contraintes sur le routage
[13]
Pas de solution, mais des guidelines
Contraintes spécifiques aux réseaux industriels [21], urbains [5], domestiques
[1], du bâtiment [19]
Un réseau 802.15.4 peut être
En étoile
Maillé
Quel routage dans un réseau maillé LoWPAN ?
Variété des nœuds (alimentés ou non)
Certains nœuds sont extrèmement contraints
La prise en compte des périodes de sommeil est critique
Les LoWPANs sont essentiellement des réseaux feuilles (stub)
Besoin d’efficacité dans des environnements peu fiables
Ni 802.15.4 ni IPv6/802.15.4 [20] ne stipulent comment construire la
topologie
Deux approches sont évoquées
Le route-over
Ce sera le choix de RPL
Le mesh-under
Comme LOADng
Autoconfiguration des adresses
Notes :
L’identifiant de l’interface est obtenu, au choix

À partir de l’adresse EUI -64
En appliquant la technique classique (IPv6/Ethernet) [4] à la concaténation de
Les 16 bits d’identifiant du réseau (PAN - ID)
16 bits à 0
Les 16 bits d’adresse courte
L’adresse de lien local est alors simplement
fe80::<identifiant>
La correspondance est assurée comme dans IPv6 [12]
La découverte des voisins est adaptée [22]
En particulier en l’absence de mécanismes multicast
Et pour prendre en compte les hôtes en sommeil
Extension de Neighbor Discovery for IP version 6 [?]
Le procotocle COAP
Notes :
3 Le protocole COAP
Le paradigme RESTfull
Introduction
Architecture et principes
Format des messages
La fiabilité
Les échanges
Un exemple simple
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Le groupe de travail CORE
Notes :
Constrained RESTful Environments [9]

Créé en 2010
Dans la zone Applications and Real-Time Area (art)
Définition d’un cadre (framework) pour des applications
Qui manipulent des ressources limitées
Mesures de paramètres scalaires
Commandes d’actuateurs
Dans un cadre contraint
Dans un contexte de communication spécifique
Petits paquets, faible débit
Fort taux de perte
Équipements régulièrement en veille
Contraintes énergétiques
Peu de mémoire et de puissance de calcul
...
Notes :
Representational State Transfer

Une architecture logicielle pour le développement d’applications Web
Manipulation de ressources Web de façon uniforme
Via un ensemble d’opérations sans états (stateless)
Ce n’est pas un protocole
Introduit par Roy Fielding en 2000
Fondé sur des principes qui existaient déjà
HTTP et les URLs
Les apports d’une telle approche [6]
Extensibilité
Performance
Simplicité
...
Notes :
Roy Fielding décrit les principes qui doivent guider le développement d’une application RESTful
Modèle client-serveur
Séparation des contingences liées à l’interface utilisateur de celles liées au stockage
Sans état
Chaque requête du client doit contenir toutes les informations nécessaires et ne compter sur aucun
contexte présent sur le serveur
Mise en place de caches
Si une réponse est identifiée comme “cachable”, alors le client peut la réutiliser plus tard pour une
autre requête
Interface uniforme
Fondée en particulier sur la notion d’hypermédias
Système en couches
Un composant ne voit pas au delà de la couche avec laquelle il interagit
Code à la demande
Les fonctionnalités du client peuvent être enrichies par le biais de scripts ou applets
REST et la notion de ressources
Notes :
La ressource est la notion qui modélise l’information

Un document
Un ensemble de documents
...
Toute information est nommée
Par exemple par un URI
L’état d’une ressource à un instant donné est une représentation de la ressource (resource
representation)
Des données
Des méta-données décrivant les données
Des liens hypermédias permettant de naviguer vers d’autres états
Le type des données (media type) permet au client de déterminer comment il peut manipuler les
données
Approche HATEOAS
Hypermedia As The Engine of Application State
Le client n’a besoin que des informations hypermédias fournies par le serveur pour intéragir avec une
représentation
Introduction
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Le protocole COAP
Notes :
Constrained Application Protocol [23]

Protocole de service
Pour des équipements en environnement contraint
Traduction vers HTTP simple
Peut utiliser UDP, SMS, . . .
Principales caractéristiques d’après [23]
Réponse aux besoins des applications M 2 M en environnement contraint
Utilisation de UDP, fiabilité otionnelle, multicast possible
Échange de messages asynchrone
Simplicité (traitement et entêtes)
Utilisation des URI et Content-type
Mise en place simplifiée de caches et proxys
Correspondance stateless avec HTTP
Utilisation possible de DTLS pour la sécurité
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Notes :
Modèle client serveur

Chacun peut être client et/ou serveur
Requête
Émise par le client vers le serveur
Demandant une action sur une ressource
Réponse
Fournie par le serveur suite à une requête
Fondés sur des messages
Permettant un asynchronisme des requêtes/réponses
Potentiellement confirmés
Utilise par exemple le protocole UDP
Format des messages

Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Le format des messages
Notes :
Ver la version du protocole utilisé

T type (CONfirmable (0) ou NON (1), ACK (2), RST (ou reset : 3))
TKL token length entre 0 et 8 octets
Code permet de différencier les messages
Message ID pour éviter les doublons et confirmer
Token pour lier requêtes et réponses
Options (voir plus loin)
Données facultatives
La fiabilité
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
La fiabilité
Notes :
La réception d’un message de type CON doit être confirmé par le récepteur
Message de type ACK
Utilisant le même Message ID
Sinon Time Out et Exponential Backoff
Les messages NON ne reçoivent donc pas de confirmation
Mais peuvent faire l’objet d’un RST (si traitement impossible)
Ils ont un Message ID pour éviter les doublons
Les requêtes multicast sont des messages NON
Transmission des messages non fiabilisés
Notes :
Les messages NON ne donnent pas lieu à des messages ACK

L’émetteur n’a donc aucun moyen (au niveau COAP) de savoir si le message a été reçu
Le message peut alors être retransmis
Pendant une durée limitée (ordre de grandeur 45 s)
Avec un débit limité (comme pour les retransmissions de CONs
Chaque retransmission véhicule le même Message ID
De sorte à éviter qu’une même action soit exécutée plusieurs fois
Vérification à la charge du récepteur
Les échanges
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Les échanges
Notes :
Une requête peut être transmise

Avec un type CON
Avec un type NON
La réponse à une requête de type CON
Peut être piggybackée dans un message de type ACK
Peut être transmise plus tard (après le message ACK)
Elle pourra dans ce cas elle aussi être de type CON
La réponse à une requête de type NON
Sera transmise dans un message NON
La RFC n’interdit pas l’usage d’une réponse de type CON
Dans tous les cas, la réponse véhicule le même token que la requête
Les requêtes
Notes :
Une requête est constituée de différents éléments

La méthode à appliquer
L’identifiant de la ressource sur laquelle appliquer la méthode
Des données (optionnel)
Un type de données (optionnel) [7]
Des méta données sur la requête (optionnel)
Supporte en particulier les méthodes classiques de HTTP
GET, POST, PUT, DELETE
Transition simplifiée
Elles doivent (être implantées de sorte à) être idempotentes
Plusieurs invocations successives doivent conduire au même résultat
Les réponses
Notes :
Contiennent un code d’erreur de la forme x.yz

Succès
2.02 Deleted
2.03 Valid
2.04 Changed
2.05 Content
Erreur client
4.00 Bad Request
4.01 Unauthorized
4.02 Bad Option
4.03 Forbidden
4.04 Not Found
4.05 Method Not Allowed
4.06 Not Acceptable
4.12 Precondition Failed
4.13 Request Entity Too Large
4.15 Unsupported Content-Format
Erreur serveur
5.00 Internal Server Error
5.01 Not Implemented
5.02 Bad Gateway
5.03 Service Unavailable
5.04 Gateway Timeout
5.05 Proxying Not Supported
Un exemple simple
Notes :
3 Le protocole COAP
Introduction
Format des messages
La fiabilité
Les échanges
Un exemple simple
Un exemple simple (1)
Notes :
Un client (eg un capteur) envoie une donnée vers un serveur


Notes :
Le seveur confirme (c’était un message CONfirmable)


Notes :
Un client (eg une application) va chercher une donnée

Notes :
Le serveur répond avec la donnée (et accuse réception)


Notes :
Une requête d’un client avec un token


Notes :
La réponse du serveur . . .
Le standard MQTT
Notes :
4 Le standard MQTT
Le standard MQTT
Notes :
MQ Telemetry Transport est un standard OSI et OASIS

Inventé par IBM en 1999
De type publish/subscribe
MQ vient du middleware IBM MQ (Message Queueing ? Peut-être, mais ce n’en est pas vraiment,
attention !)
Utilise TCP, mais également UDP, . . .
Les informations sont classées selon une hiérarchie de sujets (topics)
Deux éléments principaux
Le client MQTT s’adresse au broker
Le MQTT broker reçoit des messages depuis les clients et les retransmet aux clients
appropriés
Les clients peuvent être de deux types
Les publishers sont donc des clients qui transmettent à un broker des données associées à
un sujet
Les subscribers sont des clients qui s’abonnent à un ou plusieurs topics et reçoivent les
données associées
L’architecture
Notes :
L’architecture est très simple

Les subscribers s’identifient auprès du broker
Les publishers transmettent des données au broker
Le broker fait suivre les données aux subscribers concernés
Un broker peut servir un très grand nombre de clients
Plusieurs brokers peuvent coexister
Un client peut être publisher et/ou subscriber
Les topics
Notes :
Ils sont organisés de façon hiérarchique

Identifiés par des noms structurés par ’/’
mesures/temperatures/noeud1
Wildcards possibles
Il est inutile de définir un topic
Le fait de publier dessus y suffit
Pas de procédure d’initialisation
Un broker peut alors filtrer les messages à transmettre aux subscribers
En fonction du topic
En fonction du contenu des données
En fonction du type des données
Le protocole
Notes :
Le message CONNECT
Permet au client de demander une connexion au broker
Contient l’identifiant du client (ou pas si sateless)
Divers paramètres liés au client
Le message CONNACK
Permet au broker de confirmer l’établissement de la connexion
Le message PUBLISH
Permet au publisher de transmettre des données
Contient notament le topic
Le message SUBSCRIBE
Permet au subscriber de manifester son intérêt auprès du broker
Contient notament des topics
Autres messages
SUBACK, UNSUBSCRIBE/UNSUBACK, PUBREC, PUBREL, PUBCOMP
La qualité de service
Notes :
Il s’agit en fait d’un niveau de fiabilité

Trois niveaux de garantie de livraison
At most once (0)
At least once (1)
Exactly once (2)
Lors d’une transmission publisher vers broker
Niveau choisi par la source
Lors d’une transmission broker vers subscriber
Niveau choisi par l’abonné
Niveau 0
Transmission simple de données par PUBLISH
Niveau 1
Utilisation d’un PUBACK
Niveau 2
Utilisation de PUBREC/PUBREL/PUBCOMP
Le protocole RPL
Notes :
5 Le protocole RPL
Introduction
Principe de base : le DODAG
Construction d’un DODAG
Un exemple de fonction : OF 0
Multiplicité des DODAGs
Le fonctionnement général
Le protocole
L’algorithme trickle
Introduction
Notes :
5 Le protocole RPL
Introduction
Le protocole
Le protocole RPL
Notes :
Quel routage dans les LLN (Low-Power and Lossy Networks) ?

Fortes contraintes des nœuds
Puissance de calcul
Mémoire
Batterie
Liens de communications peu conciliants
Instables
Sujets aux pertes
Faible débit
Traffic varié
Multipoint à point (collecte d’information)
Point à multipoint (annonce de configuration)
Point à point (action vers un équipement)
“An LLN is typically composed of many embedded devices with limited power,
memory, and processing resources interconnected by a variety of links. There
is a wide scope of application areas for LLNs, including industrial monitoring,
building automation (e.g., heating, ventilation, air conditioning, lighting, access
control, fire), connected home, health care, environmental monitoring, urban
sensor networks, energy management, assets tracking, and refrigeration.”
[25]
Le protocole RPL
Notes :
IPv6 Routing Protocol for Low-Power and Lossy Networks [29]

Spécifiquement défini pour répondre à ce cahier des charges
Proposition du groupe de travail ROLL de l’IETF
Diverses applications envisagées, par exemple
Milieu urbain [5]
Automatisation domestique [1]
Milieu industriel [21]
...
Protocole à vecteur de distances
Chaque nœud va déterminer la direction et la distance vers chaque
destination
Construction d’un arbre sur la base de métriques
La racine est un LLN border router (LBR)
Fondé sur du routage par la source
C’est l’émetteur qui va décider du chemin (au moins en partie)

Notes :
5 Le protocole RPL
Introduction
Le protocole
Concept de base : le DODAG

Notes :
La topologie est construite sur la base d’une communication

multipoint à point
Construction d’un arbre orienté vers la destination
Destination Oriented Directed Acyclic Graph (DODAG)
C’est un graphe orienté sans cycle
La racine de l’arbre (root) est donc la destination
Chaque nœud a un parent (un parent préféré et un ou plusieurs
parent·s de secours)
Les transmissions multipoint à point suivent le DODAG
De nœud en nœud
Chacun transmet vers son parent
Communications point à multipoint
En “descendant” l’arbre depuis la racine vers ses feuilles
Communications point à point
En parcourant l’arbre jusqu’à un ancètre commun
Notes :
5 Le protocole RPL
Introduction
Le protocole
Construction du DODAG
Notes :
Le DODAG est optimisé au regard d’une fonction objectif (OF :

Objective Function)
Fonction objectif liée aux besoins applicatifs
Dépend de divers paramètres (nombre de sauts, fiabilité, délai,
énergie, . . . )
Il est mis en place et maintenu par la transmission de
messages spécifiques
D ODAG Information Objects (ou DIO)
Échangés entre nœuds adjacents
Contiennent tout ce qui est nécessaire pour choisir ses parents
dans l’arbre
L’OF associe à chaque nœud un rang (rank)
Le rang d’un nœud caractérise sa position dans l’arbre
Arbitrairement à zéro pour la racine
Il augmente avec la distance à la racine
Le DODAG est ainsi construit progressivement
Par application de la fonction objectif
Depuis la racine jusqu’aux feuilles
Rang et fonction objectif

Notes :
Le rang (rank) d’un nœud est un scalaire qui caractérise la

position du nœud dans le DODAG
Il permet de détecter des boucles
Il doit croître lorsque l’on s’éloigne de la racine de l’arbre
Peut dépendre de diverses métriques (caractéristiques des liens,
des nœuds, . . . )
Ce n’est pas nécessairement une distance
Son calcul est assuré par la fonction objectif
La fonction objectif
C’est elle qui définit le choix des routes par RPL
Elle permet de classer les parents potentiels d’un nœud
Elle décrit comment déterminer le rang d’un nœud en fonction de
divers paramètres
Aucune fonction n’est définie par RPL
Il faut donc définir des fonctions objectifs
Et étendre RPL pour véhiculer des informations utiles [26]
Notes :
5 Le protocole RPL
Introduction
Le protocole
Notes :
La Fonction Objectif 0 (ou OF 0 : Objective Function Zero) [24]

Fonction simple fondée sur les informations présentes dans RPL
Fournit un rang et une liste de parents
Détermine step_of_rank
Définit l’accroissement du rank le long d’un lien
Une valeur statique favorise des chemins à peu de (mauvais) sauts
La RFC recommande donc d’utiliser des propriétés dynamiques de type ETX [26]
L’incrément du rang est calculé
rank_increase = (rank_factor * step_of_rank) + Sr) * MinHopRankIncrease
Le nœud N calcule ensuite son rang en fonction de celui du nœud parent P
R(N) = R(P) + rank_increase
Paramètres
rank_factor (défini globalement) permet d’amplifier l’impact des métriques des liens (1 par défaut)
Sr doit être ≤ stretch_of_rank et permet d’aller chercher d’autres parents pour assurer de la
diversité
MinHopRankIncrease par défaut : 256
Le parent préféré est ensuite celui conduisant au rang le plus faible
Avec quelques considérations liées à la stabilité

Notes :
5 Le protocole RPL
Introduction
Le protocole
Notes :
Chaque DODAG est optimisé au regard d’une fonction objectif

OF
Définie par un codepoint (OCP)
En fonction de l’application
Une autre application peut nécessiter un autre DODAG
Racine différente
Besoins applicatifs différents
Un routage différent et un DODAG différent en résultent
Plusieurs DODAGs peuvent coexister dans une instance RPL
Distingué par des identifiants différents
Les paquets de données doivent donc être routés en fonction de
l’application
Les identifiants
Notes :
Il existe plusieurs niveaux de gestion de la topologie

Une instance RPL (RPLInstanceID)
Défini par les besoins applicatifs
Caractérisé par une fonction objectif
Un ou plusieurs DODAGs
Une instance de DODAG (DODAGID)
Plusieurs DODAG peuvent exister au sein d’une instance RPL
Une version de DODAG (DODAGVersionNumber)
Chaque reconstruction faite depuis la racine du DODAG est dotée d’un numéro de version
Le rang d’un nœud (Rank)
Au sein d’une version d’un DODAG, chaque nœud est caracérisé par son rang
Ce rang définit un ordre partiel
Notes :
5 Le protocole RPL
Introduction
Le protocole
Caractérisation du routage
Notes :
Un DODAG peut être

Grounded s’il fournit aux nœuds une connectivité qui assure les
besoins applicatifs
Floating s’il ne fournit que le routage nécessaire
Par exemple lors d’une reconstruction
Vis à vis du traffic descendant, le mode de fonctionnement des
nœuds peut être
Storing si les nœuds conservent une table de routage avec des
routes “descendantes”
Le trafic ne remonte que jusqu’à l’ancètre commun
Coûteux en mémoire (tables de routage)
Non storing si les nœuds ne conservent de routes que vers la
racine de l’arbre
Le trafic remonte systématiquement à la racine
Le Non-Storing Mode
Notes :
Dans ce mode de fonctionnement, le paquets “descendants”

sont routés par la source
Chaque paquet doit donc contenir les adresses des nœuds dans
de une option Transit Information
Les messages DAO sont transmis vers la racine de l’arbre
Les changements de topologie doivent être remontés de sorte à
assurer la cohérence
Les DAO définissent uniquement les parents de chaque nœud,
et non le chemin
Cela permet de limiter le nombre de messages en cas de
changement de topologie
Le Storing Mode
Notes :
Dans ce mode de fonctionnement, les paquets descendants

sont routés en fonction de l’adresse de destination
Les messages DAO ne contiennt pas l’adresse du parent (inutile ici :
le DAO est envoyé au parent)
Les conséquences d’un DAO reçu en unicast doivent
éventuellement être propagées (changement de destinations
atteignables)
Les messages DAO sont transmis en unicast aux parents
L’information transmise ici décrit les destinations atteignables, pas
les routes pour les atteindre
Les métriques et contraintes
Notes :
La fonction d’objectif associée à un DODAG se fonde sur un certain nombre de métriques et

de contraintes [26]
Par exemple la fonction zéro [24]
Les contraintes peuvent porter sur les nœuds comme sur les liens et limiter leur utilisation
Nœuds alimentés uniquement
Liens suffisament fiables
...
Les métriques servent à évaluer le coût d’un chemin
Nombre de sauts
Fiabilité
...
Elle les transforme en un Rank
Une mesure de la distance d’un nœud à la racine du DODAG
Elle décrit également comment chaque nœud détermine ses parents dans l’arbre
Le protocole
Notes :
5 Le protocole RPL
Introduction
Le protocole
Les messages
Notes :
RPL n’est pas un protocole indépendant [29]

Utilisation de messages ICMPv6 [3]
Trois types de messages définis
DIS (DODAG Information Solicitation) à comparer au Router Solicitation de ICMP v6. Permet
à un nœud de demander un DIO.
DIO (DODAG Information Object) permet à un nœud de fournir des informations sur un
DODAG .
DAO (Destination Advertisment Object) permet d’annoncer une route vers une feuille de
l’arbre.
Format des messages
Notes :
Code
Format TLV classique
0x00 DIS
0x01 DIO Types définis
0x02 DAO 0x00 Pad1 (padding)
0x03 DAO ACK 0x01 PadN (padding)
0x80 Secure DIS 0x02 Metric container [26]
0x81 Secure DIO 0x03 Route information préfixe et durée
0x82 Secure DAO 0x04 DODAG conf. décrit le DODAG
0x83 Secure DAO ACK 0x05 Target Prefix atteignable ou cherché
0x8a Consistency check 0x06 Transit info. définit un chemin
Security 0x07 Solicited info. permet de préciser la
Permet de sécuriser les demande
version 0x8? 0x08 Prefix info. annonce préfixe
Intégrité, anti rejeu, 0x09 RPL target ou tagging
confidentialité
Base
Dépend du code
Les DODAG Information Objects (ou DIO)

Notes :
Contenu de la base
Permettent de découvrir l’instance RPL
Obtenir les paramètres du DODAG InstanceID Quelle instance de RPL
Sa version Version Number Version du DODAG
Son mode de fonctionnement
Rank Du nœud source
...
Trouver un ensemble de parents G Grounded
Sur réception de ces messages MOP Mode Of Operation
Choisir son parent (Storing ?)
Déterminer son rank
Prf Préférence de la racine
Maintenir le DODAG
DTSN DAO Trigger Sequence
Number
Flags Non spécifiés
DODAGID L’identifiant du DODAG
Les Destination Advertisement Objects (ou DAO)

Notes :
Permettent d’annoncer une destination le

long de l’arbre
Émis par un nœud à son parent en mode
Storing Contenu de la base
Émis par un nœud à la racine en mode Non InstanceID Quelle instance de RPL
Storing K Faut-il un ACK
Peuvent faire l’objet d’un accusé de D Valide la présence de
réception DODAGID
Contiennent en particulier Flags Non définis
Une ou plusieurs options Target définissant
des destinations Reserved Non défini
Une ou plusieurs options Transit Information DAOSequence Pour l’associer à l’ACK
permettant de construire le chemin vers les
destinations DODAGID L’identifiant du DODAG
Les D ODAG Information Sollicitations (ou DIS)
Notes :
Permettent à un nœud de solliciter un DIO

Similaire à un Router Solicitation de ND Contenu de la base
dans IPv6 Flags Non définis
Reserved Non défini
Notes :
5 Le protocole RPL
Introduction
Le protocole
Notes :
Objectifs
Permettre à des nœuds communiquants de maintenir des données
cohérentes
Assurer une réactivité importante (eg quelques dizaines de
millisecondes)
Limiter les transmissions (eg quelques messages par heure)
Auto-adaptable à la densité des nœuds
Mise en œuvre simple et peu coûteuse
Décrit dans [16, 18, 17]
Principes
Choisir une date aléatoire de transmission dans un intervalle
Ne transmettre que si un nombre minimal de messages ont été
reçus
Utiliser un intervalle court en cas d’incohérence
Faire croître rapidement l’intervalle sinon
Notes :
Initialisation
τ ∈ [τmin , τmax ] a
Au début d’un intervalle
Paramètres de l’algorithme c←0
τmin durée minimale de l’intervalle t ∈ [τ /2, τ [ (choisi aléatoirement)
τmax durée maximale de l’intervalle À la réception d’une donnée cohérente
k seuil sur le nombre de messages c ←c+1
reçus
À la réception d’une donnée incohérente b
Variables τ ← τmin
τ durée de l’intervalle courant Commencer un nouvel intervalle
c nombre de message reçus sur À la date de transmission t
l’intervalle courant Transmettre si et seulement si c < k
t date de transmission dans À la fin d’un intervalle
l’intervalle courant τ ← min(2 × τ, τmax )
a. La RFC ne précise pas de valeur

b. Uniquement si τ > τmin dans la RFC
Utilisation dans RPL

Notes :
Quand un nœud doit-il considérer qu’il y a incohérence ?

Incohérence détectée lors de la transmissoin d’un paquet de données
Réception d’un message DIS en multicast (en fonction de l’option Solicited Information)
À l’entrée dans une nouvelle version de DODAG
Les messages DIS reçus en unicast ne sont pas considérés comme signe d’incohérence
Simple mise à jour de certains paramètres
Quelles valeurs doivent prendre les paramètres ?
τmin = 2DIOIntervalMin ms
DIOIntervalMin = DEFAULT_DIO_INTERVAL_MIN = 3
τmax = 2DIOIntervalDoublings
DIOIntervalDoublings = DEFAULT_DIO_INTERVAL_DOUBLINGS = 20
k = DIORedundancyConstant
DIORedundancyConstant = DEFAULT_DIO_REDUNDANCY_CONSTANT = 0
Exercice
[1] A. Brandt, J. Buron, and G. Porcu.

Home Automation Routing Requirements in Low-Power and Lossy Networks.
Technical Report 5826, IETF, April 2010. Notes :
[2] Tengfei Chang, Mališa Vučinić, Xavier Vilajosana, Simon Duquennoy, and Diego Dujovne.
6TiSCH Minimal Scheduling Function (MSF).
Internet-Draft draft-ietf-6tisch-msf-08, Internet Engineering Task Force, November 2019.
Work in Progress.
[3] A. Conta, S. Deering, and M. Gupta.
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification.
RFC 4443, IETF, March 2006.
[4] M. Crawford.
Transmission of IPv6 Packets over Ethernet Networks.
RFC 2464, IETF, December 1998.
[5] M. Dohler, T. Watteyne, T. Winter, and D. Barthel.
Routing Requirements for Urban Low-Power and Lossy Networks.
Technical Report 5548, IETF, May 2009.
[6] Roy Fielding.
Architectural styles and the design of network-based software architectures (phd thesis). sl :
University of irvine, 2000.
[7] N. Freed and N. Borenstein.
Multipurpose Internet Mail Extensions (MIME) Part Two : Media Types.
RFC 2046 (Draft Standard), November 1996.
Updated by RFCs 2646, 3798, 5147, 6657.
[8] J. Hui and P. Thubert.
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. Notes :
Technical Report 6282, IETF, September 2011.
[9] IETF , https ://datatracker.ietf.org/wg/core.
Constrained RESTful Environments (core).
[10] IETF, https ://datatracker.ietf.org/wg/6lowpan.
IPv6 over Low power WPAN (6lowpan).
[11] IETF, https ://datatracker.ietf.org/wg/6tisch.
IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch).
[12] J. Kempf.
Goals for Network-Based Localized Mobility Management (NETLMM).
RFC 4831, IETF, April 2007.
[13] E. Kim, D. Kaspar, C. Gomez, and C. Bormann.
Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Routing.
Technical Report 6606, May 2012.
[14] E. Kim, D. Kaspar, and JP. Vasseur.
Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs).
Technical Report 6568, IETF, April 2012.
[15] N. Kushalnagar, G. Montenegro, and C. Schumacher.
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) : Overview,

Assumptions, Problem Statement, and Goals.
RFC 4919, IETF, August 2007.
Notes :
[16] P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko.
The Trickle Algorithm.
Technical Report 6206, March 2011.
[17] Philip Levis, Eric Brewer, David Culler, David Gay, Samuel Madden, Neil Patel, Joe Polastre,
Scott Shenker, Robert Szewczyk, and Alec Woo.
The emergence of a networking primitive in wireless sensor networks.
Commun. ACM, 51(7) :99–106, July 2008.
[18] Philip Levis, Neil Patel, David Culler, and Scott Shenker.
Trickle : A self-regulating algorithm for code propagation and maintenance in wireless sensor
networks.
In Proceedings of the 1st Conference on Symposium on Networked Systems Design and
Implementation - Volume 1, NSDI’04, page 2, USA, 2004. USENIX Association.
[19] J. Martocci, P. De Mil, N. Riou, and W. Vermeylen.
Building Automation Routing Requirements in Low-Power and Lossy Networks.
Technical Report 5867, June 2010.
[20] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler.
Transmission of IPv6 Packets over IEEE 802.15.4 Networks.
RFC 4944, IETF, September 2007.
[21] K. Pister, P. Thubert, S. Dwars, and T. Phinney.
Industrial Routing Requirements in Low-Power and Lossy Networks.
Technical Report 5673, IETF, October 2009.
[22] Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann.

Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs). Notes :
Technical Report 6775, November 2012.
[23] Z. Shelby, K. Hartke, and C. Bormann.
The Constrained Application Protocol (CoAP).
RFC 7252 (Proposed Standard), June 2014.
Updated by RFC 7959.
[24] P. Thubert.
Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL).
Technical Report 6552, IETF, March 2012.
[25] JP. Vasseur.
Terms Used in Routing for Low-Power and Lossy Networks.
RFC 7102 (Informational), January 2014.
[26] JP. Vasseur, M. Kim, K. Pister, N. Dejean, and D. Barthel.
Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks.
[27] X. Vilajosana, K. Pister, and T. Watteyne.
Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration.
RFC 8180, IETF, May 2017.
[28] T. Watteyne, M. Palattella, and L. Grieco.
Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT) :
Problem Statement.
RFC 7554 (Informational), May 2015.
[29] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur,
and R. Alexander. Notes :
RPL : IPv6 Routing Protocol for Low-Power and Lossy Networks.
Notes :
Notes :

Iot Handout

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Iot Handout

Transféré par

Droits d'auteur :

Formats disponibles

Notes :

Une brève introduction aux

Fondé sur l’utilisation d’un grand nombre de capteurs

⇒ Quelle standardisation du côté de l’IETF ?

Le groupe de travail 6tisch

IPv6 over the TSCH mode of IEEE 802.15.4e [11]

L’architecture protocolaire 6TiSCH

Low-Rate Wireless Personal Area Networks (LR - WPAN)

⇒ Voir le cours de G. Jakllari

Problèmes de IEEE 802.15.4

La sous couche 6top

Elle fournit un cadre permettant de définir un

Les principes de bases : la cellule

La cellule, élément de base de la communication [28]

Les principes de bases : une transaction

L’équipement A souhaite ajouter deux cellules pour sa

Minimal Scheduling Function [2]

Le groupe de travail 6LowPAN

IPv6 over Low power WPAN [10]

Quelles applications ? [15]

La RFC 4944 définit un format d’encapsulation

L’identifiant de l’interface est obtenu, au choix

Constrained RESTful Environments [9]

Representational State Transfer

La ressource est la notion qui modélise l’information

Constrained Application Protocol [23]

Modèle client serveur

Format des messages

Ver la version du protocole utilisé

Les messages NON ne donnent pas lieu à des messages ACK

Une requête peut être transmise

Une requête est constituée de différents éléments

Contiennent un code d’erreur de la forme x.yz

Un client (eg un capteur) envoie une donnée vers un serveur

Un exemple simple (2)

Le seveur confirme (c’était un message CONfirmable)

Un exemple simple (3)

Un client (eg une application) va chercher une donnée

Le serveur répond avec la donnée (et accuse réception)

Un exemple simple (5)

Une requête d’un client avec un token

Un exemple simple (6)

MQ Telemetry Transport est un standard OSI et OASIS

L’architecture est très simple

Ils sont organisés de façon hiérarchique

Il s’agit en fait d’un niveau de fiabilité

Quel routage dans les LLN (Low-Power and Lossy Networks) ?

IPv6 Routing Protocol for Low-Power and Lossy Networks [29]

Principe de base : le DODAG

Concept de base : le DODAG

La topologie est construite sur la base d’une communication

Le DODAG est optimisé au regard d’une fonction objectif (OF :

Rang et fonction objectif

Le rang (rank) d’un nœud est un scalaire qui caractérise la

La Fonction Objectif 0 (ou OF 0 : Objective Function Zero) [24]

Multiplicité des DODAGs

Chaque DODAG est optimisé au regard d’une fonction objectif

Il existe plusieurs niveaux de gestion de la topologie

Un DODAG peut être

Dans ce mode de fonctionnement, le paquets “descendants”

Dans ce mode de fonctionnement, les paquets descendants

La fonction d’objectif associée à un DODAG se fonde sur un certain nombre de métriques et

RPL n’est pas un protocole indépendant [29]