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 câblés 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 une batterie, en utilisant leurs radios sur des réseaux à faible consommation d'énergie tels que Thread. L'architecture proxy, associée aux Thread appareils finaux en mode veille, permet aux nœuds à pleine puissance de fournir des fonctionnalités au niveau du réseau et de l'application qui protègent 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 supports à faible latence et faible bande passante tels que Thread. Si tous les paquets Multicast du Wi-Fi étaient pontés dans Thread, nous surchargerions le réseau et risquerions même de le saturer. L'objectif de Thread est d'activer IPv6 dans les réseaux maillés à faible consommation d'énergie et à faible latence, et non le transfert de données à bande passante élevée. Bien que les pings ICMPv6 de Thread dans un réseau local aient généralement un temps d'aller-retour de quelques dizaines de millisecondes, 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 la surcharge, la bande passante maximale typique est d'environ 125 kbit/s. En d'autres termes, les ordres de grandeur sont inférieurs à ceux du Wi-Fi.

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

Pour en savoir plus, consultez la section Adressage IPv6 du guide Thread sur openthread.io.

Routeurs de bordure

Alors, comment les nœuds peuvent-ils coexister sur les deux supports de transport dans le même Fabric ? Bien que les deux réseaux partagent des 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 routeur de bordure Thread pour permettre la connectivité. Les BR sont des routeurs IPv6 Stub.

Les routeurs stub permettent la connectivité entre les réseaux stub et les réseaux standards. Un réseau stub 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 RFC.

Les BR sont donc responsables de la liaison 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, différents préfixes IPv6 sont attribués à Thread et aux réseaux d'infrastructure adjacents. Le routeur de bordure ne transfère donc que les unicasts vers ou depuis le préfixe IPv6 Thread.

Les routeurs de bordure sont également responsables des éléments suivants :

• configurer 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é du routeur de bordure Thread puissent communiquer.
• publier des paquets de découverte DNS-SD mDNS au nom 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 Border Router sur openthread.io.

Multicast IPv6

Les messages Group sont également importants, car ils permettent de contrôler simultanément plusieurs nœuds Matter via Multicast. Afin de router ce trafic vers le réseau Thread, Matter et Thread implémentent le schéma d'adressage Multicast IPv6 basé sur les préfixes défini par la RFC 3306.Unicast

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

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

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

Le tableau 1 explique comment cette adresse est construite :

Pour en savoir plus, consultez la section Multicast du guide Thread et le RFC lui-même.

Lorsque des adresses Multicast IPv6 sont formées, elles incluent également les 56 bits supérieurs de l'ID de tissu. L'implication importante est que le champ d'application de Multicast se trouve dans un Fabric, tandis que les adresses Unicast sont partagées entre les Fabrics. Les nœuds comportant de nombreux fabrics peuvent potentiellement avoir plusieurs adresses Multicast définissant des groupes de nœuds qui se chevauchent, chacun étant limité à un fabric.

Ports

Matter utilise le port 5540 pour ses multidiffusions.