Thread und IPv6

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

Niedriger Energieverbrauch

Einige Matter-Knoten sind verkabelt und haben Energiebudgets, die es ihnen ermöglichen, ihre Funkschnittstellen dauerhaft eingeschaltet zu lassen. Andere Arten von Knoten, z. B. Sensoren, müssen jahrelang mit einer Batterie betrieben werden und ihre Funkschnittstellen in Netzwerken mit geringem Stromverbrauch wie Thread nutzen. Die Proxyarchitektur und die Thread energieeffizienten Endgeräte ermöglichen es aktiven Knoten, sowohl Funktionen auf Netzwerk- als auch auf Anwendungsebene bereitzustellen, die ihre untergeordneten Knoten vor energieintensiven Transaktionen schützen.

Ein wesentlicher Aspekt von Matter ist, dass es sowohl auf Netzwerkmedien mit hoher Durchsatzleistung wie WLAN und Ethernet als auch auf Netzwerken mit geringer Latenz und niedriger Bandbreite wie Thread funktioniert. Wenn alle Multicast-Pakete aus dem WLAN mit Thread verbunden würden, würden wir das Netzwerk überlasten und möglicherweise überfluten. Thread soll IPv6 in energieeffizienten Mesh-Netzwerken mit niedriger Latenz ermöglichen, nicht die Datenübertragung mit hoher Bandbreite. Die ICMPv6-Pings von Thread in einem lokalen Netzwerk haben zwar in der Regel eine RTT von weniger als einigen Dutzend Millisekunden, die Gesamtbandbreite ist jedoch auf 250 kbit/s bei der IEEE 802.15.4-PHY begrenzt. Mit Paketweiterleitungen und Overhead beträgt die typische maximale Bandbreite etwa 125 kbit/s. Mit anderen Worten: um Größenordnungen geringer als bei WLAN.

Frames auf dem IEEE 802.15.4-PHY haben 127 Byte, aber die größte (und typische) maximale Übertragungseinheit (MTU) von IPv6-Paketen in Thread beträgt 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 im Thread Einstiegsleitfaden zu openthread.io unter IPv6-Adressierung.

Border-Router

Wie können Knoten also in derselben Fabric auf beiden Transportmedien koexistieren? Beide Netzwerke verwenden zwar dieselben Matter-Anmeldedaten auf Anwendungsebene, aber nicht dieselbe Linktechnologie. In diesem Szenario benötigt das Netzwerk einen Thread Border Router (BR), um eine Verbindung zu ermöglichen. BRs sind Stub-IPv6-Router.

Stub-Router ermöglichen die Verbindung zwischen Stub-Netzwerken und regulären Netzwerken. Ein Stichnetzwerk ist ein „Letzte-Meile-Netzwerk“, das seinen Mitgliedern eine äußere Konnektivität bietet, aber nicht als Transitnetzwerkpfad zwischen anderen Netzwerken dient. Matter-Stichnetzwerke sind in der Regel auf Thread basierend. Weitere Informationen zu Stubnetzwerken finden Sie im RFC-Entwurf.

Brücken sind daher für die Verbindung zwischen dem Stumpfnetzwerk und dem benachbarten Infrastrukturnetzwerk verantwortlich, also dem lokalen WLAN oder Ethernet-Netzwerk. 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. Daher leitet der BR nur Unicasts an das oder vom IPv6-Präfix Thread weiter.

Border-Router sind außerdem für Folgendes verantwortlich:

  • IPv6-Präfixe und ‑Routen werden sowohl für das Thread als auch für die benachbarten Infrastrukturnetzwerke automatisch konfiguriert, damit Hosts auf beiden Seiten des Thread-Grenzrouters miteinander kommunizieren können.
  • mDNS-DNS-SD-Erkennungspakete im Namen von Thread-Knoten veröffentlichen, damit sie im benachbarten Infrastrukturnetzwerk erkannt werden können.

Weitere Informationen finden Sie im Leitfaden zu Border Routern auf openthread.io.

IPv6-Multicast

Gruppennachrichten sind ebenfalls wichtig, da sie die gleichzeitige Steuerung mehrerer Matter-Knoten über Multicast ermöglichen. Um diesen Traffic in das Thread-Netzwerk zu leiten, implementieren sowohl Matter als auch Thread das Unicast-präfixbasierte IPv6-Multicast-Adressierungsschema, das in RFC 3306 definiert ist.

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:

Tabelle 1: Unicast Prefixbasierte IPv6-Adressen
Bits Beschreibung
12 Bit 0xFF3
4 Bit 0x05

Umfang: site-local

8 Bit 0x00

reserviert

8 Bit 0x40

Gibt ein 64-Bit-langes Präfix an.

8 Bit 0xFD

Gibt ein ULA-Präfix an

56 Bit Fabric-ID
8 Bit 0x00
16 Bit Gruppen-ID

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

Bei der Bildung von IPv6-Multicast-Adressen werden auch die oberen 56 Bit der Fabric-ID verwendet. Das bedeutet, dass Multicast-Adressen nur innerhalb einer Fabric gültig sind, während Unicast-Adressen zwischen Fabrics freigegeben werden. Knoten mit vielen Fabrics können potenziell mehrere Multicast-Adressen haben, die sich überschneidende Knotengruppen auf jeder Fabric definieren.

Ports

Matter verwendet Port 5540 für seine Multicasts.