mirror of
https://github.com/espressif/openthread.git
synced 2026-06-06 05:24:51 +00:00
[docs] add English source for the Thread Primer (#5088)
This commit is contained in:
Jeff Bumgardner
@@ -0,0 +1,37 @@
|
||||
# What is Thread?
|
||||
|
||||
<figure class="attempt-right">
|
||||
<img src="../images/ot-logo-thread.png" srcset="../images/ot-logo-thread.png 1x, ../images/ot-logo-thread_2x.png 2x" border="0" alt="Thread" />
|
||||
</figure>
|
||||
|
||||
<a href="http://threadgroup.org/">Thread<sup>®</sup></a> is an IPv6-based
|
||||
networking protocol designed for low-power Internet of Things devices in an IEEE
|
||||
802.15.4-2006 wireless mesh network, commonly called a Wireless Personal Area
|
||||
Network (WPAN). Thread is independent of other 802.15.4 mesh networking
|
||||
protocols, such a ZigBee, Z-Wave, and Bluetooth LE.
|
||||
|
||||
Thread's primary features include:
|
||||
|
||||
* Simplicity — Simple installation, start up, and operation
|
||||
* Security — All devices in a Thread network are authenticated and all
|
||||
communications are encrypted
|
||||
* Reliability — Self-healing mesh networking, with no single point of failure,
|
||||
and spread-spectrum techniques to provide immunity to interference
|
||||
* Efficiency — Low-power Thread devices can sleep and operate on battery power
|
||||
for years
|
||||
* Scalability — Thread networks can scale up to hundreds of devices
|
||||
|
||||
If you're new to Thread, understanding the basics are critical to using
|
||||
OpenThread in your own applications. The goal of this primer is to explain the
|
||||
concepts behind Thread and how it works, and provide a springboard to OpenThread
|
||||
development.
|
||||
|
||||
It is assumed you have good working knowledge of the following:
|
||||
|
||||
* IEEE 802.15.4
|
||||
* Networking and routing concepts
|
||||
* IPv6
|
||||
|
||||
This primer is based on version 1.1.1 of the Thread Specification. It does not
|
||||
cover the full specification, which is available at
|
||||
[threadgroup.org](http://threadgroup.org/ThreadSpec).
|
||||
@@ -0,0 +1,274 @@
|
||||
# IPv6 Addressing
|
||||
|
||||
Let's take a look at how Thread identifies each device in the network, and what
|
||||
types of addresses they use to communicate with each other.
|
||||
|
||||
Key Term: In this primer, the term "interface" is used to identify an endpoint
|
||||
of a Thread device within a network. Typically, a single Thread device has
|
||||
a single Thread interface.
|
||||
|
||||
## Scopes
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-scopes_2x.png"><img src="../images/ot-primer-scopes.png" srcset="../images/ot-primer-scopes.png 1x, ../images/ot-primer-scopes_2x.png 2x" border="0" alt="OT Scopes" /></a>
|
||||
</figure>
|
||||
|
||||
There are three scopes in a Thread network for unicast addressing:
|
||||
|
||||
* Link-Local — all interfaces reachable by a single radio transmission
|
||||
* Mesh-Local — all interfaces reachable within the same Thread network
|
||||
* Global — all interfaces reachable from outside a Thread network
|
||||
|
||||
The first two scopes correspond to prefixes designated by a Thread network.
|
||||
Link-Local have prefixes of `fe80::/16`, while Mesh-Local have prefixes of
|
||||
`fd00::/8`.
|
||||
|
||||
<h2 style="clear:right">Unicast</h2>
|
||||
|
||||
There are multiple IPv6 unicast addresses that identify a single Thread device.
|
||||
Each has a different function based on the scope and use case.
|
||||
|
||||
Before we detail each type, let's learn more about a common one, called the
|
||||
Routing Locator (RLOC). The RLOC identifies a Thread interface, based on its
|
||||
location in the network topology.
|
||||
|
||||
### How a Routing Locator is generated
|
||||
|
||||
All devices are assigned a Router ID and a Child ID. Each Router maintains a
|
||||
table of all their Children, the combination of which uniquely identifies a
|
||||
device within the topology. For example, consider the highlighted nodes in the
|
||||
following topology, where the number on a Router (pentagon) is the Router ID,
|
||||
and the number on an End Device (circle) is the Child ID:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-rloc-topology_2x.png"><img src="../images/ot-primer-rloc-topology.png" srcset="../images/ot-primer-rloc-topology.png 1x, ../images/ot-primer-rloc-topology_2x.png 2x" border="0" width="600" alt="OT RLOC Topology" /></a>
|
||||
</figure>
|
||||
|
||||
Each Child's Router ID corresponds to their Parent (Router). Because a Router is
|
||||
not a Child, the Child ID for a Router is always 0. Together, these values are
|
||||
unique for each device in the Thread network, and are used to create the RLOC16,
|
||||
which represents the last 16 bits of the RLOC.
|
||||
|
||||
For example, here's how the RLOC16 is calculated for the upper-left node (Router
|
||||
ID = 1 and Child ID = 1):
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-rloc16_2x.png"><img src="../images/ot-primer-rloc16.png" srcset="../images/ot-primer-rloc16.png 1x, ../images/ot-primer-rloc16_2x.png 2x" border="0" width="400" alt="OT RLOC16" /></a>
|
||||
</figure>
|
||||
|
||||
The RLOC16 is part of the Interface Identifier (IID), which corresponds to the
|
||||
last 64 bits of the IPv6 address. Some IIDs can be used to identify some types
|
||||
of Thread interfaces. For example, the IID for RLOCs is always of the form
|
||||
<code>0000:00ff:fe00:<var>RLOC16</var></code>.
|
||||
|
||||
The IID, combined with a Mesh-Local Prefix, results in the RLOC. For example,
|
||||
using a Mesh-Local Prefix of `fde5:8dba:82e1:1::/64`, the RLOC for a node where
|
||||
RLOC16 = `0x401` is:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-rloc_2x.png"><img src="../images/ot-primer-rloc.png" srcset="../images/ot-primer-rloc.png 1x, ../images/ot-primer-rloc_2x.png 2x" border="0" width="600" alt="OT RLOC" /></a>
|
||||
</figure>
|
||||
|
||||
This same logic can be used to determine the RLOC for all highlighted nodes in the sample topology above:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-rloc-topology-address_2x.png"><img src="../images/ot-primer-rloc-topology-address.png" srcset="../images/ot-primer-rloc-topology-address.png 1x, ../images/ot-primer-rloc-topology-address_2x.png 2x" border="0" width="600" alt="OT Topology w/ Address" /></a>
|
||||
</figure>
|
||||
|
||||
However, because the RLOC is based on the location of the node in the topology,
|
||||
the RLOC of a node can change as the topology changes.
|
||||
|
||||
For example, perhaps node `0x400` is removed from the Thread network. Nodes
|
||||
`0x401` and `0x402` establish new links to different Routers, and as a result
|
||||
they are each assigned a new RLOC16 and RLOC:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-rloc-topology-change_2x.png"><img src="../images/ot-primer-rloc-topology-change.png" srcset="../images/ot-primer-rloc-topology-change.png 1x, ../images/ot-primer-rloc-topology-change_2x.png 2x" border="0" width="600" alt="OT Topology after Change" /></a>
|
||||
</figure>
|
||||
|
||||
## Unicast address types
|
||||
The RLOC is just one of many IPv6 unicast addresses a Thread device can have.
|
||||
Another category of addresses are called Endpoint Identifiers (EIDs), which
|
||||
identify a unique Thread interface within a Thread network partition. EIDs are
|
||||
independent of Thread network topology.
|
||||
|
||||
Common unicast types are detailed below.
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2><h3>Link-Local Address (LLA)</h3></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 style="background-color:rgb(238, 241, 242)">An EID that identifies a Thread interface reachable by a single radio transmission.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Example</b></td><td><code>fe80::54db:881c:3845:57f4</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>IID</b></td><td>Based on 802.15.4 Extended Address</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scope</b></td><td>Link-Local</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Details</b></td><td><ul><li>Used to discover neighbors, configure links, and exchange routing information</li><li>Not a routable address</li><li>Always has a prefix of <code>fe80::/16</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2><h3>Mesh-Local EID (ML-EID)</h3></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 style="background-color:rgb(238, 241, 242)">An EID that identifies a Thread interface, independent of network topology. Used to reach a Thread interface within the same Thread partition. Also called a Unique Local Address (ULA).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Example</b></td><td><code>fde5:8dba:82e1:1:416:993c:8399:35ab</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>IID</b></td><td>Random, chosen after commissioning is complete</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scope</b></td><td>Mesh-Local</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Details</b></td><td><ul><li>Does not change as the topology changes</li><li>Should be used by applications</li><li>Always has a prefix <code>fd00::/8</code></li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2><h3>Routing Locator (RLOC)</h3></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 style="background-color:rgb(238, 241, 242)">Identifies a Thread interface, based on its location in the network topology.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Example</b></td><td><code>fde5:8dba:82e1:1::ff:fe00:1001</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>IID</b></td><td><code>0000:00ff:fe00:<var>RLOC16</var></code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scope</b></td><td>Mesh-Local</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Details</b></td><td><ul><li>Generated once a device attaches to a network</li><li>For delivering IPv6 datagrams within a Thread network</li><li>Changes as the topology changes</li><li>Generally not used by applications</li></ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2><h3>Anycast Locator (ALOC)</h3></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 style="background-color:rgb(238, 241, 242)">Identifies a Thread interface via RLOC lookup, when the RLOC of a destination is not known.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Example</b></td><td><code>fde5:8dba:82e1:1::ff:fe00:fc01</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>IID</b></td><td><code>0000:00ff:fe00:fc<var>XX</var></code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scope</b></td><td>Mesh-Local</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Details</b></td><td><ul><li><code>fc<var>XX</var></code> = <a href="#anycast">ALOC destination</a>, which looks up the appropriate RLOC</li><li>Generally not used by applications</li></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2><h3>Global Unicast Address (GUA)</h3></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 style="background-color:rgb(238, 241, 242)">An EID that identifies a Thread interface on a global scope, beyond a Thread network.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Example</b></td><td><code>2000::54db:881c:3845:57f4</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>IID</b></td><td><ul><li>SLAAC — Randomly assigned by the device itself</li><li>DHCP — Assigned by a DHCPv6 server</li><li>Manual — Assigned by the application layer</li></ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scope</b></td><td>Global</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Details</b></td><td><ul><li>A public IPv6 address</li><li>Always has a prefix of <code>2000::/3</code></li></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Multicast
|
||||
|
||||
Multicast is used to communicate information to multiple devices at once. In a
|
||||
Thread network, specific addresses are reserved for multicast use with different
|
||||
groups of devices, depending on the scope.
|
||||
|
||||
IPv6 Address | Scope | Delivered to
|
||||
---- | ---- | ----
|
||||
`ff02::1` | Link-Local | All FTDs and MEDs
|
||||
`ff02::2` | Link-Local | All FTDs
|
||||
`ff03::1` | Mesh-Local | All FTDs and MEDs
|
||||
`ff03::2` | Mesh-Local | All FTDs
|
||||
|
||||
Key Point: A major difference between FTDs and MTDs are that FTDs subscribe to
|
||||
the `ff03::2` multicast address. MTDs do not.
|
||||
|
||||
You might notice that Sleepy End Devices (SEDs) are not included as a
|
||||
recipient in the multicast table above. There is an additional unicast
|
||||
prefix-based multicast address used for All Thread Nodes, including SEDs. This
|
||||
multicast address varies by Thread network, because it is built on the
|
||||
unicast Mesh-Local prefix.
|
||||
|
||||
Arbitrary scopes beyond those already listed are also supported for Thread
|
||||
devices.
|
||||
|
||||
|
||||
## Anycast
|
||||
|
||||
Anycast is used to route traffic to a Thread interface when the RLOC of a
|
||||
destination is not known. An Anycast Locator (ALOC) identifies the location of
|
||||
multiple interfaces within a Thread partition. The last 16 bits of an ALOC,
|
||||
called the ALOC16, is in the format of <code>0xfc<var>XX</var></code>, which
|
||||
represents the type of ALOC.
|
||||
|
||||
For example, an ALOC16 between `0xfc01` and `0xfc0f` is reserved for DHCPv6
|
||||
Agents. If the specific DHCPv6 Agent RLOC is unknown (perhaps because the
|
||||
network topology has changed), a message can be sent to a DHCPv6 Agent ALOC to
|
||||
obtain the RLOC.
|
||||
|
||||
Thread defines the following ALOC16 values:
|
||||
|
||||
ALOC16 | Type
|
||||
---- | ----
|
||||
`0xfc00` | Leader
|
||||
`0xfc01` – `0xfc0f` | DHCPv6 Agent
|
||||
`0xfc10` – `0xfc2f` | Service
|
||||
`0xfc30` – `0xfc37` | Commissioner
|
||||
`0xfc40` – `0xfc4e` | Neighbor Discovery Agent
|
||||
`0xfc38` – `0xfc3f`<br>`0xfc4f` – `0xfcff` | Reserved
|
||||
|
||||
## Recap
|
||||
|
||||
What you've learned:
|
||||
|
||||
* A Thread network consists of three scopes: Link-Local, Mesh-Local, and Global
|
||||
* A Thread device has multiple unicast IPv6 addresses
|
||||
* An RLOC represents a device's location in the Thread network
|
||||
* An ML-EID is unique to a Thread device within a partition and should be used by applications
|
||||
* Thread uses multicast to forward data to groups of nodes and routers
|
||||
* Thread uses anycast when the RLOC of a destination is unknown
|
||||
|
||||
To learn more about Thread's IPv6 addressing, see sections 5.2 and 5.3 of the
|
||||
[Thread Specification](http://threadgroup.org/ThreadSpec).
|
||||
@@ -0,0 +1,292 @@
|
||||
# Network Discovery and Formation
|
||||
|
||||
## Thread networks
|
||||
|
||||
Thread networks are identified by three unique identifiers:
|
||||
|
||||
* 2-byte Personal Area Network ID (PAN ID)
|
||||
* 8-byte Extended Personal Area Network ID (XPAN ID)
|
||||
* A human-readable Network Name
|
||||
|
||||
For example, a Thread network may have the following identifiers:
|
||||
|
||||
Identifier | Value
|
||||
---- | ----
|
||||
PAN ID | `0xBEEF`
|
||||
XPAN ID | `0xBEEF1111CAFE2222`
|
||||
Network Name | `yourThreadCafe`
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-network-active-scan_2x.png"><img src="../images/ot-primer-network-active-scan.png" srcset="../images/ot-primer-network-active-scan.png 1x, ../images/ot-primer-network-active-scan_2x.png 2x" border="0" alt="OT Active Scan" /></a>
|
||||
</figure>
|
||||
|
||||
When creating a new Thread network, or searching for an existing one to join, a
|
||||
Thread device performs an active scan for 802.15.4 networks within radio range:
|
||||
|
||||
1. The device broadcasts an 802.15.4 Beacon Request on a specific Channel.
|
||||
1. In return, any Routers or Router Eligible End Devices (REEDs) in range
|
||||
broadcast a Beacon that contains their Thread network PAN ID, XPAN ID, and
|
||||
Network Name.
|
||||
1. The device repeats the previous two steps for each Channel.
|
||||
|
||||
Once a Thread device has discovered all networks in range, it can either attach
|
||||
to an existing network, or create a new one if no networks are discovered.
|
||||
|
||||
<h2 style="clear:right">Mesh Link Establishment</h2>
|
||||
|
||||
Thread uses the Mesh Link Establishment (MLE) protocol to configure links and
|
||||
disseminate information about the network to Thread devices.
|
||||
|
||||
In link configuration, MLE is used to:
|
||||
|
||||
* Discover links to neighboring devices
|
||||
* Determine the quality of links to neighboring devices
|
||||
* Establish links to neighboring devices
|
||||
* Negotiate link parameters (device type, frame counters, timeout) with peers
|
||||
|
||||
MLE disseminates the following types of information to devices wishing to
|
||||
establish links:
|
||||
|
||||
* Leader data (Leader RLOC, Partition ID, Partition weight)
|
||||
* Network data (on-mesh prefixes, address autoconfiguration, more-specific
|
||||
routes)
|
||||
* Route propagation
|
||||
|
||||
Route propagation in Thread works similar to the Routing Information Protocol
|
||||
(RIP), a distance-vector routing protocol.
|
||||
|
||||
Note: MLE only proceeds once a Thread device has obtained Thread network
|
||||
credentials through Thread Commissioning. Commissioning and Security will be
|
||||
covered in depth later in this Primer. For now, this page assumes that the
|
||||
device has already been commissioned.
|
||||
|
||||
## Create a new network
|
||||
|
||||
If the device elects to create a new network, it selects the least busy Channel
|
||||
and a PAN ID not in use by other networks, then becomes a Router and elects
|
||||
itself the Leader. This device sends MLE Advertisement messages to other
|
||||
802.15.4 devices to inform them of its link state, and responds to Beacon
|
||||
Requests by other Thread devices performing an active scan.
|
||||
|
||||
## Join an existing network
|
||||
|
||||
If the device elects to join an existing network, it configures its Channel, PAN
|
||||
ID, XPAN ID, and Network Name to match that of the target network via Thread
|
||||
Commissioning, then goes through the MLE Attach process to attach as a Child
|
||||
(End Device). This process is used for Child-Parent links.
|
||||
|
||||
Key Point: Every device, router-capable or not, initially attaches to a Thread
|
||||
network as a Child (End Device).
|
||||
|
||||
1. The Child sends a multicast [Parent Request](#1_parent_request) to all
|
||||
neighboring Routers and REEDs in the target network.
|
||||
1. All neighboring Routers and REEDs (if the Parent Request Scan Mask includes
|
||||
REEDs) send [Parent Responses](#2_parent_response) with information about
|
||||
themselves.
|
||||
1. The Child chooses a Parent device and sends a [Child ID
|
||||
Request](#3_child_id_request) to it.
|
||||
1. The Parent sends a [Child ID Response](#4_child_id_response) to confirm link
|
||||
establishment.
|
||||
|
||||
### 1. Parent Request
|
||||
|
||||
A Parent Request is a multicast request from the attaching device that is used
|
||||
to discover neighboring Routers and Router Eligible End Devices (REEDs) in the
|
||||
target network.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-attach-01_2x.png"><img src="../images/ot-primer-network-mle-attach-01.png" srcset="../images/ot-primer-network-mle-attach-01.png 1x, ../images/ot-primer-network-mle-attach-01_2x.png 2x" width="350" border="0" alt="OT MLE Attach Parent Request" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Parent Request Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Mode</b></td>
|
||||
<td>Describes the attaching device</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Challenge</b></td>
|
||||
<td>Tests the timeliness of the Parent Response to prevent replay
|
||||
attacks</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Scan Mask</b></td>
|
||||
<td>Limits the request to only Routers or to both Routers and REEDs</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### 2. Parent Response
|
||||
|
||||
A Parent Response is a unicast response to a Parent Request that provides
|
||||
information about a Router or REED to the attaching device.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-attach-02_2x.png"><img src="../images/ot-primer-network-mle-attach-02.png" srcset="../images/ot-primer-network-mle-attach-02.png 1x, ../images/ot-primer-network-mle-attach-02_2x.png 2x" width="350" border="0" alt="OT MLE Attach Parent Response" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Parent Response Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Version</b></td>
|
||||
<td>Thread protocol version</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Response</b></td>
|
||||
<td>Copy of the Parent Request Challenge</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Link Frame
|
||||
Counter</b></td>
|
||||
<td>802.15.4 Frame Counter on the Router/REED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>MLE Frame
|
||||
Counter</b></td>
|
||||
<td>MLE Frame Counter on the Router/REED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Source
|
||||
Address</b></td>
|
||||
<td>RLOC16 of the Router/REED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Link
|
||||
Margin</b></td>
|
||||
<td>Receive signal quality of the Router/REED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Connectivity</b></td>
|
||||
<td>Describes the Router/REED’s level of connectivity</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Leader
|
||||
Data</b></td>
|
||||
<td>Information about the Router/REED’s Leader</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Challenge</b></td>
|
||||
<td>Tests the timeliness of the Child ID Request to prevent replay
|
||||
attacks</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### 3. Child ID Request
|
||||
|
||||
A Child ID Request is a unicast request from the attaching device (Child) that
|
||||
is sent to the Router or REED (Parent) for the purpose of establishing a
|
||||
Child-Parent link. If the request is sent to a REED, it [upgrades itself to a
|
||||
Router](/guides/thread-primer/router-selection#upgrade_to_a_router) before
|
||||
accepting the request.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-attach-03_2x.png"><img src="../images/ot-primer-network-mle-attach-03.png" srcset="../images/ot-primer-network-mle-attach-03.png 1x, ../images/ot-primer-network-mle-attach-03_2x.png 2x" width="350" border="0" alt="OT MLE Attach Child ID Request" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Child ID Request Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Version</b></td>
|
||||
<td>Thread protocol version</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Response</b></td>
|
||||
<td>Copy of the Parent Response Challenge</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Link Frame
|
||||
Counter</b></td>
|
||||
<td>802.15.4 Frame Counter on the Child</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>MLE Frame
|
||||
Counter</b></td><td>MLE Frame Counter on the Child</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Mode</b></td>
|
||||
<td>Describes the Child</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Timeout</b></td>
|
||||
<td>Inactivity duration before the Parent removes the Child</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Address
|
||||
Registration (MEDs and SEDs only)</b></td>
|
||||
<td>Register IPv6 addresses</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### 4. Child ID Response
|
||||
|
||||
A Child ID Response is a unicast response from the Parent that is sent to the
|
||||
Child to confirm that a Child-Parent link has been established.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-attach-04_2x.png"><img src="../images/ot-primer-network-mle-attach-04.png" srcset="../images/ot-primer-network-mle-attach-04.png 1x, ../images/ot-primer-network-mle-attach-04_2x.png 2x" width="350" border="0" alt="OT MLE Attach Child ID Response" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Child ID Response Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Source
|
||||
Address</b></td>
|
||||
<td>Parent's RLOC16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Address16</b></td>
|
||||
<td>Child's RLOC16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Leader
|
||||
Data</b></td>
|
||||
<td>Information about the Parent’s Leader (RLOC, Partition ID, Partition
|
||||
weight)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Network
|
||||
Data</b></td>
|
||||
<td>Information about the Thread network (on-mesh prefixes, address
|
||||
autoconfiguration, more-specific routes)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Route
|
||||
(REED only)</b></td>
|
||||
<td>Route propagation</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Timeout</b></td>
|
||||
<td>Inactivity duration before the Parent removes the Child</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Address
|
||||
Registration (MEDs and SEDs only)</b></td>
|
||||
<td>Confirm registered addresses</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Recap
|
||||
|
||||
What you've learned:
|
||||
|
||||
* A Thread device performs an active scan for existing networks
|
||||
* Thread uses Mesh Link Establishment to configure links and disseminate
|
||||
information about network devices
|
||||
* MLE Advertisement messages inform other Thread devices about a device's
|
||||
network and link state
|
||||
* The MLE Attach process establishes Child-Parent links
|
||||
@@ -0,0 +1,151 @@
|
||||
# Node Roles and Types
|
||||
|
||||
## Forwarding roles
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-roles_2x.png"><img src="../images/ot-primer-roles.png" srcset="../images/ot-primer-roles.png 1x, ../images/ot-primer-roles_2x.png 2x" border="0" alt="OT Node Roles" /></a>
|
||||
</figure>
|
||||
|
||||
In a Thread network, nodes are split into two forwarding roles:
|
||||
|
||||
### Router
|
||||
|
||||
A Router is a node that:
|
||||
|
||||
* forwards packets for network devices
|
||||
* provides secure commissioning services for devices trying to join the network
|
||||
* keeps its transceiver enabled at all times
|
||||
|
||||
### End Device
|
||||
|
||||
An End Device (ED) is a node that:
|
||||
|
||||
* communicates primarily with a single Router
|
||||
* does not forward packets for other network devices
|
||||
* can disable its transceiver to reduce power
|
||||
|
||||
Key Point: The relationship between Router and End Device is a Parent-Child
|
||||
relationship. An End Device attaches to exactly one Router. The Router is always
|
||||
the Parent, the End Device the Child.
|
||||
|
||||
## Device types
|
||||
|
||||
Furthermore, nodes comprise a number of types.
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-taxonomy_2x.png"><img src="../images/ot-primer-taxonomy.png" srcset="../images/ot-primer-taxonomy.png 1x, ../images/ot-primer-taxonomy.png 2x" border="0" alt="OT Device Taxonomy" /></a>
|
||||
</figure>
|
||||
|
||||
### Full Thread Device
|
||||
|
||||
A Full Thread Device (FTD) always has its radio on, subscribes to the
|
||||
all-routers multicast address, and maintains IPv6 address mappings. There are
|
||||
three types of FTDs:
|
||||
|
||||
* Router
|
||||
* Router Eligible End Device (REED) — can be promoted to a Router
|
||||
* Full End Device (FED) — cannot be promoted to a Router
|
||||
|
||||
An FTD can operate as a Router (Parent) or an End Device (Child).
|
||||
|
||||
### Minimal Thread Device
|
||||
|
||||
A Minimal Thread Device does not subscribe to multicast traffic and forwards all
|
||||
messages to its Parent. There are two types of MTDs:
|
||||
|
||||
* Minimal End Device (MED) — transceiver always on, does not need to poll for
|
||||
messages from its parent
|
||||
* Sleepy End Device (SED) — normally disabled, wakes on occasion to poll for
|
||||
messages from its parent
|
||||
|
||||
An MTD can only operate as an End Device (Child).
|
||||
|
||||
### Upgrading and downgrading
|
||||
|
||||
When a REED is the only node in reach of a new End Device wishing to join the
|
||||
Thread network, it can upgrade itself and operate as a Router:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-router-upgrade_2x.png"><img src="../images/ot-primer-router-upgrade.png" srcset="../images/ot-primer-router-upgrade.png 1x, ../images/ot-primer-router-upgrade_2x.png 2x" border="0" width="400" alt="OT End Device to Router" /></a>
|
||||
</figure>
|
||||
|
||||
Conversely, when a Router has no children, it can downgrade itself and operate
|
||||
as an End Device:
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-router-downgrade_2x.png"><img src="../images/ot-primer-router-downgrade.png" srcset="../images/ot-primer-router-downgrade.png 1x, ../images/ot-primer-router-downgrade_2x.png 2x" border="0" width="400" alt="OT Router to End Device" /></a>
|
||||
</figure>
|
||||
|
||||
## Other roles and types
|
||||
|
||||
### Thread Leader
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-leader_2x.png"><img src="../images/ot-primer-leader.png" srcset="../images/ot-primer-leader.png 1x, ../images/ot-primer-leader_2x.png 2x" border="0" alt="OT Leader and Border Router" /></a>
|
||||
</figure>
|
||||
|
||||
The Thread Leader is a Router that is responsible for managing the set of
|
||||
Routers in a Thread network. It is dynamically self-elected for fault tolerance,
|
||||
and aggregates and distributes network-wide configuration information.
|
||||
|
||||
Note: There is always a single Leader in each Thread network
|
||||
[partition](#partitions).
|
||||
|
||||
### Border Router
|
||||
|
||||
A Border Router is a device that can forward information between a Thread
|
||||
network and a non-Thread network (for example, Wi-Fi). It also configures a
|
||||
Thread network for external connectivity.
|
||||
|
||||
Any device may serve as a Border Router.
|
||||
|
||||
Note: There can be multiple Border Routers in a Thread network.
|
||||
|
||||
## Partitions
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-partitions_2x.png"><img src="../images/ot-primer-partitions.png" srcset="../images/ot-primer-partitions.png 1x, ../images/ot-primer-partitions_2x.png 2x" border="0" alt="OT Partitions" /></a>
|
||||
</figure>
|
||||
|
||||
A Thread network might be composed of partitions. This occurs when a group of
|
||||
Thread devices can no longer communicate with another group of Thread devices.
|
||||
Each partition logically operates as a distinct Thread network with its own
|
||||
Leader, Router ID assignments, and network data, while retaining the same
|
||||
security credentials for all devices across all partitions.
|
||||
|
||||
Partitions in a Thread network do not have wireless connectivity between each
|
||||
other, and if partitions regain connectivity, they automatically merge into a
|
||||
single partition.
|
||||
|
||||
Key Point: Security credentials define the Thread network. Physical radio
|
||||
connectivity defines partitions within that Thread network.
|
||||
|
||||
Note that the use of "Thread network" in this primer assumes a single partition.
|
||||
Where necessary, key concepts and examples are clarified with the term "partition."
|
||||
Partitions are covered in-depth later in this primer.
|
||||
|
||||
## Device limits
|
||||
|
||||
There are limits to the number of device types a single Thread network supports.
|
||||
|
||||
Role | Limit
|
||||
----|----
|
||||
Leader | 1
|
||||
Router | 32
|
||||
End Device | 511 per Router
|
||||
|
||||
Thread tries to keep the number of Routers between 16 and 23. If a REED attaches
|
||||
as an End Device and the number of Routers in the network is below 16, it
|
||||
automatically promotes itself to a Router.
|
||||
|
||||
## Recap
|
||||
|
||||
What you learned:
|
||||
|
||||
* A Thread device is either a Router (Parent) or an End Device (Child)
|
||||
* A Thread device is either a Full Thread Device (maintains IPv6 address
|
||||
mappings) or a Minimal Thread Device (forwards all messages to its Parent)
|
||||
* A Router Eligible End Device can promote itself to a Router, and vice versa
|
||||
* Every Thread network partition has a Leader to manage Routers
|
||||
* A Border Router is used to connect Thread and non-Thread networks
|
||||
* A Thread network might be composed of multiple partitions
|
||||
@@ -0,0 +1,176 @@
|
||||
# Router Selection
|
||||
|
||||
## Connected Dominating Set
|
||||
|
||||
<figure class="attempt-right">
|
||||
<a href="../images/ot-primer-cds_2x.png"><img src="../images/ot-primer-cds.png" srcset="../images/ot-primer-cds.png 1x, ../images/ot-primer-cds_2x.png 2x" width="350" border="0" alt="OT Connected Dominating Set" /></a><figcaption style="text-align: center"><i>Example of a Connected Dominating Set</i></figcaption>
|
||||
</figure>
|
||||
|
||||
Routers must form a Connected Dominating Set (CDS), which means:
|
||||
|
||||
1. There is a Router-only path between any two Routers.
|
||||
1. Any one Router in a Thread network can reach any other Router by staying
|
||||
entirely within the set of Routers.
|
||||
1. Every End Device in a Thread network is directly connected to a Router.
|
||||
|
||||
A distributed algorithm maintains the CDS, which ensures a minimum level of
|
||||
redundancy. Every device initially attaches to the network as an End Device
|
||||
(Child). As the state of the Thread network changes, the algorithm adds or
|
||||
removes Routers to maintain the CDS.
|
||||
|
||||
Thread adds Routers to:
|
||||
|
||||
* Increase coverage if the network is below the Router threshold of 16
|
||||
* Increase path diversity
|
||||
* Maintain a minimum level of redundancy
|
||||
* Extend connectivity and support more Children
|
||||
|
||||
Thread removes Routers to:
|
||||
|
||||
* Reduce the Routing state below the maximum of 32 Routers
|
||||
* Allow new Routers in other parts of the network when needed
|
||||
|
||||
## Upgrade to a Router
|
||||
|
||||
After attaching to a Thread network, the Child device may elect to become a
|
||||
Router. Before initiating the MLE Link Request process, the Child sends an
|
||||
Address Solicit message to the Leader, asking for a Router ID. If the Leader
|
||||
accepts, it responds with a Router ID and the Child upgrades itself to a Router.
|
||||
|
||||
The MLE Link Request process is then used to establish bi-directional
|
||||
Router-Router links with neighboring Routers.
|
||||
|
||||
1. The new Router sends a multicast [Link Request](#1_link_request) to
|
||||
neighboring Routers.
|
||||
1. Routers respond with [Link Accept and Request](#2_link_accept_and_request)
|
||||
messages.
|
||||
1. The new Router responds to each Router with a unicast [Link
|
||||
Accept](#3_link_accept) to establish the Router-Router link.
|
||||
|
||||
### 1. Link Request
|
||||
|
||||
A Link Request is a request from the Router to all other Routers in the Thread
|
||||
network. When first becoming a Router, the device sends a multicast Link Request
|
||||
to `ff02::2`. Later, after discovering the other Routers via MLE Advertisements,
|
||||
the devices send unicast Link Requests.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-link-request-01_2x.png"><img src="../images/ot-primer-network-mle-link-request-01.png" srcset="../images/ot-primer-network-mle-link-request-01.png 1x, ../images/ot-primer-network-mle-link-request-01_2x.png 2x" width="350" border="0" alt="OT MLE Link Request" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Link Request Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Version</b></td>
|
||||
<td>Thread protocol version</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Challenge</b></td>
|
||||
<td>Tests the timeliness of the Link Response to prevent replay
|
||||
attacks</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Source
|
||||
Address</b></td>
|
||||
<td>RLOC16 of the sender</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Leader
|
||||
Data</b></td>
|
||||
<td>Information about the Router's Leader, as stored on the sender (RLOC,
|
||||
Partition ID, Partition weight)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### 2. Link Accept and Request
|
||||
|
||||
A Link Accept and Request is a combination of the Link Accept and Link Request
|
||||
messages. Thread uses this optimization in the MLE Link Request process to
|
||||
reduce the number of messages from four to three.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-link-request-02_2x.png"><img src="../images/ot-primer-network-mle-link-request-02.png" srcset="../images/ot-primer-network-mle-link-request-02.png 1x, ../images/ot-primer-network-mle-link-request-02_2x.png 2x" width="350" border="0" alt="OT MLE Link Accept and Request" /></a>
|
||||
</figure>
|
||||
|
||||
### 3. Link Accept
|
||||
|
||||
A Link Accept is a unicast response to a Link Request from a neighboring Router
|
||||
that provides information about itself and accepts the link to the neighboring
|
||||
Router.
|
||||
|
||||
<figure>
|
||||
<a href="../images/ot-primer-network-mle-link-request-03_2x.png"><img src="../images/ot-primer-network-mle-link-request-03.png" srcset="../images/ot-primer-network-mle-link-request-03.png 1x, ../images/ot-primer-network-mle-link-request-03_2x.png 2x" width="350" border="0" alt="OT MLE Link Accept" /></a>
|
||||
</figure>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th colspan=2>Link Accept Message Contents</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Version</b></td>
|
||||
<td>Thread protocol version</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Response</b></td>
|
||||
<td>Tests the timeliness of the Link Response to prevent replay
|
||||
attacks</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Link Frame
|
||||
Counter</b></td>
|
||||
<td>802.15.4 Frame Counter on the sender</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>MLE Frame
|
||||
Counter</b></td>
|
||||
<td>MLE Frame Counter on the sender</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Source
|
||||
Address</b></td>
|
||||
<td>RLOC16 of the sender</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="25%" style="background-color:rgb(238, 241, 242)"><b>Leader
|
||||
Data</b></td>
|
||||
<td>Information about the Router's Leader, as stored on the sender (RLOC,
|
||||
Partition ID, Partition weight)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Downgrade to a REED
|
||||
|
||||
When a Router downgrades to a REED, its Router-Router links are disconnected,
|
||||
and the device initiates the MLE Attach process to establish a Child-Parent
|
||||
link.
|
||||
|
||||
See [Join an existing
|
||||
network](/guides/thread-primer/network-discovery#join_an_existing_network)
|
||||
for more information on the MLE Attach process.
|
||||
|
||||
## One-way receive links
|
||||
|
||||
In some scenarios, it may be necessary to establish a one-way receive link.
|
||||
|
||||
After a Router reset, neighboring Routers may still have a valid receive link
|
||||
with the reset Router. In this case, the reset Router sends a Link Request
|
||||
message to re-establish the Router-Router link.
|
||||
|
||||
An End Device may also wish to establish a receive link with neighboring
|
||||
non-Parent Routers to improve multicast reliability. We'll learn more about this
|
||||
when we get to Multicast Routing.
|
||||
|
||||
## Recap
|
||||
|
||||
What you've learned:
|
||||
|
||||
* Routers in a Thread network must form a Connected Dominating Set (CDS)
|
||||
* Thread devices are upgraded to Routers or downgraded to End Devices to
|
||||
maintain the CDS
|
||||
* The MLE Link Request process is used to establish Router-Router links
|
||||
+1
-1
@@ -61,7 +61,7 @@
|
||||
set -euo pipefail
|
||||
|
||||
readonly OT_BUILD_JOBS=$(getconf _NPROCESSORS_ONLN)
|
||||
readonly OT_EXCLUDE_DIRS=(third_party)
|
||||
readonly OT_EXCLUDE_DIRS=(third_party doc/site)
|
||||
|
||||
readonly OT_CLANG_SOURCES=('*.c' '*.cc' '*.cpp' '*.h' '*.hpp')
|
||||
readonly OT_MARKDOWN_SOURCES=('*.md')
|
||||
|
||||
Reference in New Issue
Block a user