Thread und IPv6

Matter verwendet IPv6 für die betriebliche Kommunikation und nutzt sowohl die IPv6-Adressierung Unicast als auch Multicast für den Zugriff auf die Knoten bzw. Gruppen.

Geringe Leistung

Einige Matter-Knoten sind verkabelt und haben Energiebudgets, die es ihnen ermöglichen, ihre Funkmodule kontinuierlich eingeschaltet zu lassen. Andere Arten von Knoten wie Sensoren müssen jahrelang mit einer Batterie betrieben werden und ihre Funkgeräte in Low-Power-Netzwerken wie Thread betreiben. Die Proxy-Architektur ermöglicht es zusammen mit Thread Sleepy End Devices (Geräte im Schlafmodus), dass Knoten mit voller Leistung sowohl Netzwerk- als auch Anwendungsebene-Funktionen bereitstellen, die ihre untergeordneten Knoten vor energieintensiven Transaktionen schützen.

Ein grundlegender Aspekt von Matter ist, dass es sowohl auf Netzwerkmedien mit hohem Durchsatz wie WLAN und Ethernet als auch auf Medien mit niedriger Latenz und geringer Bandbreite wie Thread funktioniert. Wenn alle Multicast-Pakete aus dem WLAN in Thread überbrückt würden, würde das Netzwerk überlastet und möglicherweise überflutet. Das Ziel von Thread ist es, IPv6 in Mesh-Netzwerken mit geringem Stromverbrauch und niedriger Latenz zu ermöglichen, nicht die Datenübertragung mit hoher Bandbreite. Während die ICMPv6-Pings von Thread in einem lokalen Netzwerk in der Regel eine RTT von wenigen zehn Millisekunden haben, ist die Gesamtbandbreite auf 250 kbit/s bei der IEEE 802.15.4 PHY begrenzt. Mit Paketübertragungen und Overhead liegt die typische maximale Bandbreite bei etwa 125 kbit/s. Mit anderen Worten: Die Datenmenge ist um Größenordnungen geringer als bei WLAN.

Frames auf der IEEE 802.15.4-PHY sind 127 Byte groß, die größte (und typische) maximale Übertragungseinheit (MTU) von IPv6-Paketen in Thread beträgt jedoch 1.280 Byte. Daher müssen IPv6-Pakete oft in mehrere PHY-Frames aufgeteilt werden. Dieser Prozess ist in RFC4944 definiert.

Weitere Informationen finden Sie unter IPv6 Addressing im Thread Primer auf openthread.io.

Border-Router

Wie können Knoten also gleichzeitig auf beiden Transportmedien in derselben Fabric vorhanden sein? Obwohl beide Netzwerke Anmeldedaten auf Anwendungsebene Matter verwenden, nutzen sie nicht dieselbe Link-Technologie. In diesem Szenario benötigt das Netzwerk einen Thread Border Router (BR), um eine Verbindung herzustellen. BRs sind Stub-IPv6-Router.

Stub-Router ermöglichen die Verbindung zwischen Stub-Netzwerken und regulären Netzwerken. Ein Stub-Netzwerk ist ein „Last-Mile“-Netzwerk, das seinen Mitgliedern eine externe Verbindung bietet, aber nicht als Transitnetzwerkpfad zwischen anderen Netzwerken dient. In der Regel basieren Matter-Stub-Netzwerke auf Thread. Weitere Informationen zu Stub-Netzwerken finden Sie im RFC-Entwurf.

BRs sind daher für die Verbindung zwischen dem Stub-Netzwerk und dem Adjacent Infrastructure Network (dem lokalen WLAN- oder Ethernet-Netzwerk) verantwortlich. Sie leiten nur die Pakete weiter, die für das Thread-Netzwerk relevant sind.

Dazu werden Thread und benachbarten Infrastrukturnetzwerken unterschiedliche IPv6-Präfixe zugewiesen. Der BR leitet Unicasts also nur an oder von dem IPv6-Präfix Thread weiter.

Border-Router sind auch für Folgendes zuständig:

• automatische Konfiguration von IPv6-Präfixen und ‑Routen für das Thread und die angrenzenden Infrastrukturnetzwerke, sodass Hosts auf beiden Seiten des Thread-Border-Routers kommunizieren können.
• mDNS DNS-SD-Erkennungspakete im Namen von Thread-Knoten veröffentlicht, damit sie im angrenzenden Infrastrukturnetzwerk erkannt werden können.

Weitere Informationen finden Sie im Border-Router-Leitfaden auf openthread.io.

IPv6-Multicast

Gruppennachrichten sind ebenfalls wichtig, da sie die gleichzeitige Steuerung mehrerer Matter-Knoten über Multicast ermöglichen. Damit dieser Traffic in das Thread-Netzwerk geleitet werden kann, implementieren sowohl Matter als auch Thread das von RFC 3306 definierte Unicastpräfixbasierte IPv6-MulticastAdressierungsschema.

Mit dieser Methode können die Zielknoten eines Multicast-Pakets anhand ihres gemeinsamen IPv6-Unicast-Präfixes ausgewählt werden.

Eine Matter-Multicast-Adresse könnte beispielsweise so aussehen:

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

In Tabelle 1 wird beschrieben, wie diese Adresse aufgebaut ist:

Weitere Informationen finden Sie im Abschnitt Multicast des Thread-Primers und im RFC selbst.

Wenn IPv6-Multicast-Adressen gebildet werden, enthalten sie auch die oberen 56 Bits der Fabric-ID. Die wichtige Folge ist, dass der Bereich von Multicast innerhalb eines Fabric liegt, während Unicast-Adressen zwischen Fabrics geteilt werden. Knoten mit vielen Fabrics können potenziell mehrere Multicast-Adressen haben, die sich überschneidende Knotengruppen definieren, die auf jede Fabric beschränkt sind.

Ports

Matter verwendet Port 5540 für seine Multicasts.