Thread e IPv6

Matter usa IPv6 para sus comunicaciones operativas y aprovecha el direccionamiento IPv6 de Unicast y Multicast para acceder a sus nodos y grupos, respectivamente.

Bajo consumo de energía

Algunos nodos Matter están conectados y tienen presupuestos de energía que les permiten mantener sus radios encendidos de forma continua. Otros tipos de nodos, como los sensores, tienen requisitos para funcionar durante años con una batería y operar sus radios en redes de bajo consumo, como Thread. La arquitectura de proxy, junto con Thread dispositivos finales inactivos, permite que los nodos de potencia completa proporcionen funcionalidad a nivel de la red y de la aplicación que aísla sus nodos secundarios de las transacciones que consumen mucha energía.

Un aspecto fundamental de Matter es que funciona tanto en medios de red de alto rendimiento, como Wi-Fi y Ethernet, pero también en redes de baja latencia y ancho de banda, como Thread. Si todos los Multicast paquetes de Wi-Fi se conectaran a Thread, sobrecargaríamos la red y, posiblemente, la inundaríamos. El objetivo de Thread es habilitar IPv6 en redes de malla de baja potencia y latencia, no la transferencia de datos de alto ancho de banda. Si bien los pings ICMPv6 de Thread en una red local suelen ser inferiores a unas pocas decenas de milisegundos de RTT, su ancho de banda total se limita a 250 kbps en la capa física IEEE 802.15.4. Con las retransmisiones de paquetes y la sobrecarga, el ancho de banda máximo típico es de alrededor de 125 kbps. Es decir, órdenes de magnitud menos que Wi-Fi.

Los marcos de la capa física IEEE 802.15.4 son de 127 bytes, pero la unidad de transmisión máxima (MTU) más grande (y típica) de los paquetes IPv6 en Thread es de 1,280 bytes. Por lo tanto, los paquetes IPv6 suelen dividirse en varios marcos de capa física. Este proceso se define en RFC4944.

Para obtener más información, consulta Direccionamiento IPv6 en la guía de Thread en openthread.io.

Routers de borde

Entonces, ¿cómo pueden coexistir los nodos en ambos medios de transporte mientras están en la misma estructura? Aunque ambas redes comparten credenciales de Matter a nivel de la aplicación, no comparten la misma tecnología de vínculo.Matter En este caso, la red necesita un Thread router de borde (BR) para habilitar la conectividad. Los BR son routers IPv6 de stub.

Los routers de stub habilitan la conectividad entre redes de stub y redes normales. Una red de stub es una red de "última milla" que proporciona conectividad externa a sus miembros, pero no sirve como una ruta de red de tránsito entre otras redes. Por lo general, las redes de stub Matter se basan en Thread. Consulta el borrador de RFC para obtener más información sobre las redes de stub.

Por lo tanto, los BR tienen la responsabilidad de ser el vínculo entre la red de stub y la red de infraestructura adyacente, que es la red Wi-Fi o Ethernet local. Solo reenvían los paquetes que son relevantes para la Thread red.

Este proceso se realiza asignando diferentes prefijos IPv6 a Thread y a las redes de infraestructura adyacente. Por lo tanto, el BR solo reenvía unidifusiones hacia o desde el prefijo IPv6 Thread.

Los routers de borde también son responsables de lo siguiente:

  • Configurar automáticamente los prefijos y las rutas IPv6 para las redes Thread y de infraestructura adyacente, de modo que los hosts de cualquier lado del Thread router de borde puedan comunicarse.
  • Publicar paquetes de descubrimiento DNS-SD de mDNS en nombre de Thread nodos, de modo que se puedan descubrir en la red de infraestructura adyacente.

Para obtener más información, consulta la guía del router de borde en openthread.io.

Multidifusión IPv6

Los mensajes de grupo también son importantes, ya que permiten el control simultáneo de varios nodos Matter a través de Multicast. Para enrutar este tráfico a la Thread red, tanto Matter como Thread implementan el Unicast esquema de direccionamiento de multidifusión IPv6 Multicast basado en prefijos de unidifusión definido por el RFC 3306.

Este método permite la selección de los nodos de destino de un Multicast paquete en función de su prefijo IPv6 Unicast compartido.

Por ejemplo, una dirección Matter Multicast podría verse de la siguiente manera:

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

En la Tabla 1, se detalla cómo se construye esta dirección:

Tabla 1: Unicast Direcciones IPv6 basadas en prefijos
Bits Descripción
12 bits 0xFF3
4 bits 0x05

Alcance: local del sitio

8 bits 0x00

Reservado

8 bits 0x40

Indica un prefijo de 64 bits de largo

8 bits 0xFD

Designa un prefijo ULA

56 bits ID de Fabric
8 bits 0x00
16 bits ID del grupo

Puedes encontrar más información en la Multicast sección de la Thread guía y en la propia RFC.

Cuando se forman las direcciones Multicast IPv6, también incluyen los 56 bits superiores del ID de Fabric. La implicación importante es que el alcance de Multicast está dentro de una estructura, mientras que Unicast las direcciones se comparten entre las estructuras. Los nodos con muchas estructuras pueden potencialmente tener varias direcciones Multicast que definen grupos de nodos superpuestos con alcance en cada estructura.

Puertos

Matter usa el puerto 5540 para sus multidifusiones.