Chapter 4 - Part 4
operational discovery
In the continuation of the topic of the principles of learning the Matter protocol, in this lesson we will teach the topic of operational discovery.
Operational discovery
For Matter nodes already deployed on a Matter Fabric, instead of assuming a fixed IPv6 address and port for the lifetime of the product, dynamic discovery of operational Matter nodes is used at runtime. This is done with the goal of greater flexibility, so that the underlying IPv6 network can grow and evolve over time as needed without breaking Matter's functionality.
The name of the operational example
For operational Matter discovery, the DNS-SD instance name is constructed from a compact 64-bit Fabric ID and a 64-bit Node ID (as assigned by Gateway). Each is expressed as a fixed-length sixteen-character hexadecimal string, encoded as ASCII text (UTF-8) using uppercase letters, separated by spaces.
Compact Fabric ID
In order to reduce the very large size of a full Fabric reference that must be used as a scope structure in the instance name, a compressed 64-bit version of the full Fabric reference should be used. The calculation of compressed Fabric ID should be as follows:
Type of operational services
The DNS-SD service type [RFC 6335] for operational discovery of Matter is _matter. _top. Note that the _top string is a header inherited from the original DNS SRV specification and does not necessarily mean that the advertised application layer protocol runs over TCP only.
Operating service domain and host name
For link-local Multicast DNS, the service domain must be local. For unicast DNS like the one used in Thread, the service domain should be automatically configured by Thread's border router. For DNS-SD, a hostname is required in addition to the instance name. The target hostname must be constructed using one of the available link layer addresses, such as a 48-bit device MAC address (for Ethernet and Wi-Fi) or a 64-bit Extended MAC address (for Thread).
If a privacy-preserving device performs MAC address randomization, the target hostname SHOULD use the privacy-preserving random version, and the hostname record SHOULD be updated each time the underlying link layer address is rotated.
Operational discovery service records
After discovery, IPv6 addresses are returned to AAAA records and key/value pairs in DNS-SD TXT records. If no key is defined, the TXT record may be omitted. Nodes MUST publish AAAA records for all available IPv6 addresses on which they wish to accept operational messages.
Functional recommendations
To improve the overall performance of operational exploration, especially in large installations, the following recommendations should be considered:
1. Nodes SHOULD store the last known IPv6 address and port for each peer node they interact with from the SRV record and resolved using DNS-SD to save the cost of network lookup operations if not needed. Save running time. When the IPv6 address and port for a peer node are unknown, or an attempt to communicate with a peer node at its last known IPv6 address and port appears unsuccessful within the expected network round-trip time, then a node must perform runtime discovery in parallel to determine whether the target node has obtained a new IPv6 address and/or port.
2. Nodes SHOULD respond to non-specific service enumeration requests for the General Operational Discovery Matter service type, but these queries should not be used in routine operations and are recommended to be used only for diagnostic purposes or to determine new cases. When used, it is recommended that the enumeration service use the _I<HHHH> Fabric subtype to enumerate only the desired nodes in the fabric of interest in the local network. Additionally, known response suppression [RFC 6762] SHOULD be used in such cases to minimize the number of unnecessary responses to such a request.
3. When resolving another node's operational service record, a node SHOULD use an SRV query for the operational service instance in question, rather than performing a global enumeration of all nodes. This recommendation reduces the amount of multicast traffic generated on the link when using Multicast DNS and reduces the delay in successful service resolution.
4. Because proxy DNS-SD service discovery may be used in a given network, and service record keeping is expected from DNS-SD clients, nodes SHOULD NOT use DNS-SD as an operational liveness determination method. This is because there may be old records that have not yet expired that may still be available after a node becomes unavailable.
Examples of operational discovery DNS-SD
The following example simulates a Matter node that advertises its availability for control via the Matter protocol. Examples are shown using the dns-sd command line test tool and the avahi command line test tool. The dns-sd command line test tool is included in all versions of macOS. It installs as a DOS command with Bonjour for Windows and is available on Linux by installing the mDNSResponder package. The avahi command-line testing tool from the Avahi project is available for most Linux distributions.
This example is provided for illustrative purposes only. Nodes and controllers do not use command-line testing tools for advertising and discovery. Real Matter nodes and controllers use the appropriate DNS-SD APIs in their programming languages of choice.
In this lesson, we examined the topic of operational exploration in detail. In the next lesson, we will discuss other issues raised in the fourth chapter of the main document of the Matter standard. Stay with us.
