Thread et IPv6

Matter utilise IPv6 pour ses communications opérationnelles et exploite l'adressage IPv6 Unicast et Multicast pour accéder respectivement à ses nœuds et à ses groupes.

Faible consommation d'énergie

Certains nœuds Matter sont filaires et disposent de budgets énergétiques qui leur permettent de maintenir leurs radios allumées en permanence. D'autres types de nœuds, tels que les capteurs, doivent fonctionner pendant des années sur batterie, en utilisant leurs radios sur des réseaux à faible consommation d'énergie tels que Thread. L'architecture proxy, ainsi que les appareils de fin de veille Thread, permettent aux nœuds entièrement alimentés de fournir des fonctionnalités au niveau du réseau et de l'application qui isolent leurs nœuds enfants des transactions énergivores.

Un aspect fondamental de Matter est qu'il fonctionne à la fois sur des supports réseau à haut débit tels que le Wi-Fi et Ethernet, mais aussi sur des réseaux à faible latence et à faible bande passante, tels que Thread. Si tous les paquets Multicast du Wi-Fi étaient transférés vers Thread, nous surchargerions le réseau et risquerions de l'inonder. L'objectif de Thread est d'activer IPv6 dans les réseaux maillés à faible consommation et à faible latence, et non de transférer des données à bande passante élevée. Bien que les pings ICMPv6 de Thread sur un réseau local soient généralement inférieurs à quelques dizaines de millisecondes de RTT, sa bande passante totale est limitée à 250 kbit/s au niveau de la couche physique IEEE 802.15.4. Avec les retransmissions de paquets et les frais généraux, la bande passante maximale standard est d'environ 125 kbit/s. En d'autres termes, des ordres de grandeur inférieurs au Wi-Fi.

Les trames de la couche physique IEEE 802.15.4 font 127 octets, mais l'unité de transmission maximale (MTU) la plus grande (et la plus courante) des paquets IPv6 dans Thread est de 1 280 octets. Par conséquent, les paquets IPv6 doivent souvent être divisés en plusieurs trames PHY. Ce processus est défini par la norme RFC4944.

Pour en savoir plus, consultez IPv6 Addressing (Adressage IPv6) dans le guide d'initiation à Thread sur openthread.io.

Routeurs de bordure

Comment les nœuds peuvent-ils coexister sur les deux supports de transport tout en se trouvant dans le même fabric ? Bien que les deux réseaux partagent les identifiants Matter au niveau de l'application, ils n'utilisent pas la même technologie de liaison. Dans ce scénario, le réseau a besoin d'un Thread Border Router (TBR) pour activer la connectivité. Les routeurs de bordure sont des routeurs IPv6 stub.

Les routeurs d'extrémité permettent d'établir la connectivité entre les réseaux d'extrémité et les réseaux standards. Un réseau d'extrémité est un réseau de "dernier kilomètre" qui fournit une connectivité externe à ses membres, mais ne sert pas de chemin de réseau de transit entre d'autres réseaux. En règle générale, les réseaux stub Matter sont basés sur Thread. Pour en savoir plus sur les réseaux stub, consultez le brouillon de la RFC.

Les routeurs de bordure ont donc la responsabilité d'être le lien entre le réseau stub et le réseau d'infrastructure adjacent, qui est le réseau Wi-Fi ou Ethernet local. Ils ne transfèrent que les paquets pertinents pour le réseau Thread.

Pour ce faire, vous devez attribuer différents préfixes IPv6 à Thread et aux réseaux d'infrastructure adjacents. Ainsi, le BR ne transfère que les monodiffusions vers ou depuis le préfixe IPv6 Thread.

Les routeurs de bordure sont également responsables des tâches suivantes :

  • en configurant automatiquement les préfixes et les routes IPv6 pour les réseaux Thread et d'infrastructure adjacente afin que les hôtes de chaque côté de la TBR puissent communiquer.
  • publier des paquets de découverte DNS-SD mDNS pour le compte des nœuds Thread, afin qu'ils puissent être découverts sur le réseau d'infrastructure adjacent.

Pour en savoir plus, consultez le guide OpenThread Border Router (OTBR).

Multidiffusion IPv6

Les messages de groupe sont également importants, car ils permettent de contrôler simultanément plusieurs nœuds Matter via Multicast. Pour acheminer ce trafic vers le réseau Thread, Matter et Thread implémentent le Unicastschéma d'adressage IPv6 basé sur un préfixe Multicast défini par la RFC 3306.

Cette méthode permet de sélectionner les nœuds de destination d'un paquet Multicast en fonction de leur préfixe Unicast IPv6 partagé.

Par exemple, une adresse Multicast Matter peut se présenter comme suit :

FF35:0040:FD<Fabric ID>00:<Group ID>

Le tableau 1 détaille la construction de cette adresse :

Tableau 1 : Unicast Adresses IPv6 basées sur un préfixe
Bits Description
12 bits 0xFF3
4 bits 0x05

Champ d'application : site-local

8 bits 0x00

réservés

8 bits 0x40

Indique un préfixe de 64 bits de long.

8 bits 0xFD

Désigne un préfixe ULA

56 bits ID de structure
8 bits 0x00
16 bits ID du groupe

Pour en savoir plus, consultez la section Multicast du guide d'initiation à Thread et la RFC elle-même.

Lorsque les adresses IPv6 Multicast sont formées, elles incluent également les 56 bits supérieurs de l'ID de structure. Cela implique que le champ d'application de Multicast se trouve dans une structure, tandis que les adresses Unicast sont partagées entre les structures. Les nœuds comportant de nombreuses structures peuvent potentiellement avoir plusieurs adresses Multicast définissant des groupes de nœuds qui se chevauchent et qui sont limités à chaque structure.

Ports

Matter utilise le port 5540 pour ses multicasts.