] describes the use of the Time-Slotted Channel Hopping (TSCH) mode of [IEEE.802.15.4
In TSCH mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit Enhanced Beacon (EB) frames during broadcast slots in order to announce the time and channel schedule.
This document defines a new IETF Information Element (IE) subtype to place into the EB to provide join and enrollment information to prospective pledges in a more efficient way.
The following subsections explain the problem being solved, which justifies carrying the join and enrollment information in the EB.
The key words "MUST
", "MUST NOT
", "SHALL NOT
", "SHOULD NOT
", "NOT RECOMMENDED
", and "OPTIONAL
" in this document are to be interpreted as described in BCP 14 [RFC 2119
] [RFC 8174
] when, and only when, they appear in all capitals, as shown here.
Other terminology can be found in Section 2.1
of RFC 9030
As explained in Section 4.5.2
of RFC 8180
, the EB has a number of purposes: it carries synchronization information such as the Absolute Slot Number (ASN) and Join Metric and identifiers for the timeslot template and the channel hopping sequence, and it indicates the TSCH slotframe.
An EB announces the existence of a TSCH network and the nodes already joined to that network. Receiving an EB allows a Joining Node (pledge) to learn about the network and to synchronize with it.
The EB may also be used as a means for a node already part of the network to resynchronize [RFC 7554
There are a limited number of timeslots designated as broadcast slots by each router in the network. Considering 10 ms slots and a slotframe length of 100, these slots are rare and could result in only 1 slot per second for broadcasts, which needs to be used for the beacon. Additional broadcasts for Router Advertisements (RA) or Neighbor Discovery (ND) could be even more scarce.
At Layer 3, [RFC 4861
] defines a mechanism by which nodes learn about routers by receiving multicast RAs. If no RA is received within a set time, then a Router Solicitation (RS) may be transmitted as a multicast, to which an RA will be received, usually unicast.
Although [RFC 6775
] reduces the amount of multicast necessary for address resolution via Neighbor Solicitation (NS) messages, it still requires multicast of either RAs or RSes. This is an expensive operation for two reasons: there are few multicast timeslots for unsolicited RAs; and if a pledge node does not receive an RA, and decides to transmit an RS, a broadcast Aloha slot (see Appendix A.5
of RFC 7554
) is consumed with unencrypted traffic. [RFC 6775
] already allows for a unicast reply to such an RS.
This is a particularly acute issue for the join process for the following reasons:
Use of a multicast slot by even a non-malicious unauthenticated node for a Router Solicitation (RS) may overwhelm that timeslot.
It may require many seconds of on-time before a new pledge receives a Router Advertisement (RA) that it can use.
A new pledge may have to receive many EBs before it can pick an appropriate network and/or closest Join Proxy to attach to. If it must remain in the receive state for an RA as well as find the EB, then the process may take dozens of seconds, even minutes for each enrollment attempt that it needs to make.
In a complex Low-power and Lossy Network (LLN), multiple LLNs may be connected together by Backbone Routers (technology such as [RFC 8929
]), resulting in an area that is serviced by multiple, distinct Layer 2 instances. These are called Personal Area Networks (PANs). Each instance will have a separate Layer 2 security profile and will be distinguished by a different PANID. The PANID is part of the Layer 2 header as defined in [IEEE.802.15.4
]: it is a 16-bit value that is chosen to be unique, and it contributes context to the Layer 2 security mechanisms. The PANID provides a context similar to the Extended Service Set ID (ESSID) in 802.11 networking and can be considered similar to the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2 addresses.
A device that is already enrolled in a network may find after a long sleep that it needs to resynchronize with the Layer 2 network. The device's enrollment keys will be specific to a PANID, but the device may have more than one set of keys. Such a device may wish to connect to a PAN that is experiencing less congestion or that has a shallower Routing Protocol for LLNs (RPL) tree [RFC 6550
]. It may even observe PANs for which it does not have keys, but for which it believes it may have credentials that would allow it to join.
In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension. PANs that are part of the same backbone will be configured to use the same network ID. For RPL networks [RFC 6550
], configuration of the network ID can be done with a configuration option, which is the subject of future work.
In order to provide some input to the choice of which PAN to use, the PAN priority field has been added. This lists the relative priority for the PAN among different PANs. Every EB from a given PAN will likely have the same PAN priority. Determination of the PAN priority is the subject of future work; but it is expected that it will be calculated by an algorithm in the 6LoWPAN Border Router (6LBR), possibly involving communication between 6LBRs over the backbone network.
The parent selection process [RFC 6550
] can only operate within a single PAN because it depends upon receiving RPL DIO messages from all available parents. As part of the PAN selection process, the device may wish to know how deep in the LLN mesh it will be if it joins a particular PAN, and the rank priority field provides an estimation of each announcer's rank. Once the device synchronizes with a particular PAN's TSCH schedule, it may receive DIOs that are richer in their diversity than this value. The use of this value in practice is the subject of future research, and the interpretation of this value of the structure is considered experimental.