diff --git a/doc/site/en/guides/thread-primer/index.md b/doc/site/en/guides/thread-primer/index.md new file mode 100644 index 000000000..b2ba1d1bf --- /dev/null +++ b/doc/site/en/guides/thread-primer/index.md @@ -0,0 +1,37 @@ +# What is Thread? + +
+Thread +
+ +Thread® 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). diff --git a/doc/site/en/guides/thread-primer/ipv6-addressing.md b/doc/site/en/guides/thread-primer/ipv6-addressing.md new file mode 100644 index 000000000..329f19d48 --- /dev/null +++ b/doc/site/en/guides/thread-primer/ipv6-addressing.md @@ -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 + +
+OT Scopes +
+ +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`. + +

Unicast

+ +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: + +
+OT RLOC Topology +
+ +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): + +
+OT RLOC16 +
+ +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 +0000:00ff:fe00:RLOC16. + +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: + +
+OT RLOC +
+ +This same logic can be used to determine the RLOC for all highlighted nodes in the sample topology above: + +
+OT Topology w/ Address +
+ +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: + +
+OT Topology after Change +
+ +## 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. + + + + + + + + + + + + + + + + + + + + + + +

Link-Local Address (LLA)

An EID that identifies a Thread interface reachable by a single radio transmission.
Examplefe80::54db:881c:3845:57f4
IIDBased on 802.15.4 Extended Address
ScopeLink-Local
Details
  • Used to discover neighbors, configure links, and exchange routing information
  • Not a routable address
  • Always has a prefix of fe80::/16
+ + + + + + + + + + + + + + + + + + + + + + +

Mesh-Local EID (ML-EID)

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).
Examplefde5:8dba:82e1:1:416:993c:8399:35ab
IIDRandom, chosen after commissioning is complete
ScopeMesh-Local
Details
  • Does not change as the topology changes
  • Should be used by applications
  • Always has a prefix fd00::/8
+ + + + + + + + + + + + + + + + + + + + + + +

Routing Locator (RLOC)

Identifies a Thread interface, based on its location in the network topology.
Examplefde5:8dba:82e1:1::ff:fe00:1001
IID0000:00ff:fe00:RLOC16
ScopeMesh-Local
Details
  • Generated once a device attaches to a network
  • For delivering IPv6 datagrams within a Thread network
  • Changes as the topology changes
  • Generally not used by applications
+ + + + + + + + + + + + + + + + + + + + + + +

Anycast Locator (ALOC)

Identifies a Thread interface via RLOC lookup, when the RLOC of a destination is not known.
Examplefde5:8dba:82e1:1::ff:fe00:fc01
IID0000:00ff:fe00:fcXX
ScopeMesh-Local
Details
  • fcXX = ALOC destination, which looks up the appropriate RLOC
  • Generally not used by applications
+ + + + + + + + + + + + + + + + + + + + + + +

Global Unicast Address (GUA)

An EID that identifies a Thread interface on a global scope, beyond a Thread network.
Example2000::54db:881c:3845:57f4
IID
  • SLAAC — Randomly assigned by the device itself
  • DHCP — Assigned by a DHCPv6 server
  • Manual — Assigned by the application layer
ScopeGlobal
Details
  • A public IPv6 address
  • Always has a prefix of 2000::/3
+ +## 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 0xfcXX, 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`
`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). diff --git a/doc/site/en/guides/thread-primer/network-discovery.md b/doc/site/en/guides/thread-primer/network-discovery.md new file mode 100644 index 000000000..c4ff1e872 --- /dev/null +++ b/doc/site/en/guides/thread-primer/network-discovery.md @@ -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` + +
+OT Active Scan +
+ +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. + +

Mesh Link Establishment

+ +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. + +
+OT MLE Attach Parent Request +
+ + + + + + + + + + + + + + + + + + + +
Parent Request Message Contents
ModeDescribes the attaching device
ChallengeTests the timeliness of the Parent Response to prevent replay + attacks
Scan MaskLimits the request to only Routers or to both Routers and REEDs
+ +### 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. + +
+OT MLE Attach Parent Response +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Parent Response Message Contents
VersionThread protocol version
ResponseCopy of the Parent Request Challenge
Link Frame + Counter802.15.4 Frame Counter on the Router/REED
MLE Frame + CounterMLE Frame Counter on the Router/REED
Source + AddressRLOC16 of the Router/REED
Link + MarginReceive signal quality of the Router/REED
ConnectivityDescribes the Router/REED’s level of connectivity
Leader + DataInformation about the Router/REED’s Leader
ChallengeTests the timeliness of the Child ID Request to prevent replay + attacks
+ +### 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. + +
+OT MLE Attach Child ID Request +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Child ID Request Message Contents
VersionThread protocol version
ResponseCopy of the Parent Response Challenge
Link Frame + Counter802.15.4 Frame Counter on the Child
MLE Frame + CounterMLE Frame Counter on the Child
ModeDescribes the Child
TimeoutInactivity duration before the Parent removes the Child
Address + Registration (MEDs and SEDs only)Register IPv6 addresses
+ +### 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. + +
+OT MLE Attach Child ID Response +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Child ID Response Message Contents
Source + AddressParent's RLOC16
Address16Child's RLOC16
Leader + DataInformation about the Parent’s Leader (RLOC, Partition ID, Partition + weight)
Network + DataInformation about the Thread network (on-mesh prefixes, address + autoconfiguration, more-specific routes)
Route + (REED only)Route propagation
TimeoutInactivity duration before the Parent removes the Child
Address + Registration (MEDs and SEDs only)Confirm registered addresses
+ +## 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 diff --git a/doc/site/en/guides/thread-primer/node-roles-and-types.md b/doc/site/en/guides/thread-primer/node-roles-and-types.md new file mode 100644 index 000000000..888b4c7d2 --- /dev/null +++ b/doc/site/en/guides/thread-primer/node-roles-and-types.md @@ -0,0 +1,151 @@ +# Node Roles and Types + +## Forwarding roles + +
+OT Node Roles +
+ +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. + +
+OT Device Taxonomy +
+ +### 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: + +
+OT End Device to Router +
+ +Conversely, when a Router has no children, it can downgrade itself and operate +as an End Device: + +
+OT Router to End Device +
+ +## Other roles and types + +### Thread Leader + +
+OT Leader and Border Router +
+ +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 + +
+OT Partitions +
+ +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 diff --git a/doc/site/en/guides/thread-primer/router-selection.md b/doc/site/en/guides/thread-primer/router-selection.md new file mode 100644 index 000000000..be96bb6c5 --- /dev/null +++ b/doc/site/en/guides/thread-primer/router-selection.md @@ -0,0 +1,176 @@ +# Router Selection + +## Connected Dominating Set + +
+OT Connected Dominating Set
Example of a Connected Dominating Set
+
+ +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. + +
+OT MLE Link Request +
+ + + + + + + + + + + + + + + + + + + + + + + +
Link Request Message Contents
VersionThread protocol version
ChallengeTests the timeliness of the Link Response to prevent replay + attacks
Source + AddressRLOC16 of the sender
Leader + DataInformation about the Router's Leader, as stored on the sender (RLOC, + Partition ID, Partition weight)
+ +### 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. + +
+OT MLE Link Accept and Request +
+ +### 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. + +
+OT MLE Link Accept +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Link Accept Message Contents
VersionThread protocol version
ResponseTests the timeliness of the Link Response to prevent replay + attacks
Link Frame + Counter802.15.4 Frame Counter on the sender
MLE Frame + CounterMLE Frame Counter on the sender
Source + AddressRLOC16 of the sender
Leader + DataInformation about the Router's Leader, as stored on the sender (RLOC, + Partition ID, Partition weight)
+ +## 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 diff --git a/script/make-pretty b/script/make-pretty index 374313d07..096f887fc 100755 --- a/script/make-pretty +++ b/script/make-pretty @@ -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')