draft-miller-tmesh-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="info" docName="draft-miller-tmesh-00">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="tmesh">TMesh - Thing Mesh PHY/MAC Protocol</title>

<author initials="J." surname="Miller" fullname="Jeremie Miller">
<organization>Filament</organization>
<address>
<postal>
<street></street>
<city>Denver</city>
<code></code>
<country></country>
</postal>
<email>jeremie@jabber.org</email>
<uri></uri>
</address>
</author>
<date year="2015" month="May" day="16"/>

<area>Internet</area>
<workgroup></workgroup>
<keyword>mesh</keyword>
<keyword>protocol</keyword>
<keyword>telehash</keyword>
<keyword>phy</keyword>


<abstract>
<t>A secure PHY/MAC based on <eref target="http://telehash.org">telehash</eref> designed for low-power sleepy devices.
</t>
</abstract>

</front>

<middle>

<section anchor="introduction" title="Introduction">
<t><list style="empty">
<t>this is a work in progress and under active development, expect significant breaking changes
</t>
</list></t>
<t>As embedded devices continue to increase in capabilities while falling in cost there is a growing challenge to manage their energy resources for wirelessly networking them together.  While there are many options for short-range 2.4GHz networks such as Bluetooth Smart (BLE), low-power WiFi, Zigbee and 802.15.4 based mesh networks, there are few choices for long-range sub-GHz mesh networking.
</t>
<t>TMesh builds on the strong end-to-end encryption and privacy capabilities of [telehash v3] by adding a uniquely matched secure Physical RF and Media Access Control protocol.
</t>
<t>The key attributes of TMesh are:
</t>
<t>
<list style="symbols">
<t>high density - thousands per square kilometer</t>
<t>very low power - years on coin cell batteries</t>
<t>wide area - optimized for long-range (&gt;1km) capable radios</t>
<t>high latency - low minimum duty cycle from seconds to hours</t>
<t>peer aware meshing - does not require dedicated coordinator hardware</t>
<t>high interference resiliency - bi-modal PHY to maximize connectivity in all conditions</t>
<t>dynamically resource optimized - powered motes naturally provide more routing assistance</t>
<t>zero metadata broadcast - same absolute privacy and security principles as telehash</t>
<t>dynamic spectrum - able to use any specialized private or regionally licensed bands</t>
</list>
</t>

<section anchor="the-need-for-standards" title="The Need for Standards">
<t>The existing best choices are all either only partial solutions like 802.15.4, require commercial membership to participate like LoRaWAN, ZigBee, and Z-Wave, or are focused on specific verticals like DASH7 and Wireless M-Bus.
</t>
<t>All other options only provide incomplete or indadequate security and privacy, most use only optional AES-128 and often with complicated or fixed provisioning-based key management.  No existing option fully protects the mote identity and network metadata from monitoring.
</t>
</section>

<section anchor="telehash-native" title="Telehash Native">
<t>By leveraging <eref target="http://telehash.org">telehash</eref> as the native encryption and mote identity platform, TMesh can start with some strong assumptions:
</t>
<t>
<list style="symbols">
<t>each mote will have a unique stable 32-byte identity, the hashname</t>
<t>two linked motes will have a unique long-lived session id</t>
<t>all payloads will be encrypted ciphertext with forward secrecy</t>
<t>retransmissions and acknowledgements happen at a higher level and are not required in the framing</t>
<t>motes are members of a private mesh and only communicate with other verified members</t>
<t>chunked encoding defines how to serialize variable length packets into fixed transmission frames</t>
</list>
</t>
</section>

<section anchor="vocabulary" title="Vocabulary">
<t>
<list style="symbols">
<t><spanx style="verb">mote</spanx> - a single physical transmitting/receiving device</t>
<t><spanx style="verb">medium</spanx> - definition of the specific channels/settings the physical transceivers use</t>
<t><spanx style="verb">community</spanx> - a network of motes using a common medium to create a large area mesh</t>
<t><spanx style="verb">neighbors</spanx> - nearby reachable motes in the same community</t>
<t><spanx style="verb">z-index</spanx> - the self-asserted resource level (priority) from any mote</t>
<t><spanx style="verb">leader</spanx> - the highest z-index mote in any set of neighbors</t>
<t><spanx style="verb">knock</spanx> - a single transmission</t>
<t><spanx style="verb">window</spanx> - the variable period in which a knock is transmitted, 2^16 to 2^32 microseconds (1hr)</t>
<t><spanx style="verb">window sequence</spanx> - each window will change frequency/channels in a sequence</t>
</list>
</t>
</section>

<section anchor="overview" title="Overview">
<t>TMesh is the composite of three distinct layers, the physical radio medium encoding (PHY), the shared management of the spectrum (MAC), and the networking relationships between 2 or more motes (Mesh).
</t>
<t>A community is any set of motes that are using a common medium definition and have enough trust to establish a telehash link for sharing peers and acting as a router to facilitate larger scale meshing.  Within any community, the motes that can directly communicate over a medium are called neighbors, and any neighbor that has a higher z-index is always considered the current leader that may have additional responsibilities.
</t>

<section anchor="phy" title="PHY">
<t>A <spanx style="verb">medium</spanx> is a compact 5 byte definition of the exact PHY encoding details required for a radio to operate.  The 5 bytes are always string encoded as 8 base32 characters for ease of use in JSON and configuration storage, an example medium is <spanx style="verb">azdhpa5r</spanx> which is 0x06, 0x46, 0x77, 0x83, 0xb1.
</t>
<t><spanx style="verb">Byte 0</spanx> is the primary <spanx style="verb">type</spanx> that determines if the medium is for a public or private community and the overall category of PHY encoding technique to use.  The first/high bit of <spanx style="verb">byte 0</spanx> determins if the medium is for public communities (bit <spanx style="verb">0</spanx>, values from 0-127) or private communities (bit <spanx style="verb">1</spanx>, values from 128-255).  The other bits in the <spanx style="verb">type</spanx> map directly to different PHY modes on transceivers or different hardware drivers entirely and are detailed in the <spanx style="verb">PHY</spanx> section.
</t>
<t><spanx style="verb">Byte 1</spanx> is the maximum energy boost requirements for that medium both for transmission and reception.  While a mote may determine that it can use less energy and optimize it's usage, this byte value sets an upper bar so that a worst case can always be independently estimated.  The energy byte is in two 4-bit parts, the first half for the additional TX energy, and the second half for the additional RX energy.  While different hardware devices will vary on exact mappings of mA to the 1-16 range of values, effort will be made to define general buckets and greater definitions to encourage compatibility for efficiency estimation purposes.
</t>
<t>Each PHY driver uses the remaining medium <spanx style="verb">bytes 2, 3, and 4</spanx> to determine the frequency range, number of channels, spreading, bitrate, error correction usage, regulatory requirements, channel dwell time, etc details on the transmission/reception.  The channel frequency hopping and transmission window timing are derived dynamically and not included in the medium.
</t>
<t>Transmitted payloads do not generally need whitening as encrypted packets are by nature DC-free.  They also do not explicitly require CRC as all telehash packets have authentication bytes included for integrity verification.
</t>
<t>A single fixed 64 byte payload can be transmitted during each window in a sequence, this is called a <spanx style="verb">knock</spanx>.  If the payload does not fill the full 64 byte frame the remaining bytes must contain additional data so as to not reveal the actual payload size.
</t>
<t><list style="empty">
<t>WIP - determine a standard filler data format that will add additional dynamically sized error correction, explore taking advantage of the fact that the inner and outer bitstreams are encrypted and bias-free (Gaussian distribution divergence?)
</t>
</list></t>
<t>Each transmission window can go either direction between motes, the actual direction is based on the parity of the current nonce and the binary ascending sort order of the hashnames of the motes. A parity of 0 (even) means the low mote transmits and high mote receives, whereas a parity of 1 (odd) means the low mote receives and high mote transmits.
</t>
</section>

<section anchor="mac" title="MAC">
<t>There is no mote addressing or other metadata included in the transmitted bytes, including there being no framing outside of the encrypted ciphertext in a knock.  The uniqueness of each knock's timing and PHY encoding is the only mote addressing mechanism.
</t>
<t>Every window sequence is a unique individual encrypted session between the two motes in one community using a randomly rotating nonce and a shared secret key derived directly from the medium, community name, and hashnames. All payloads are additionally encrypted with the <eref target="http://cr.yp.to/chacha.html">ChaCha20 cipher</eref> before transmission regardless of if they are already encrypted via telehash.
</t>
<t>Each mote should actively make use of multiple communities to another mote and regularly test more efficient mediums to optimize the overall energy usage.  Every mote advertises their current local energy availability level as a <spanx style="verb">z-index</spanx> (single byte value) to facilitate community-wide optimization strategies.
</t>
</section>

<section anchor="mesh" title="Mesh">
<t>There is two mechanisms used for enabling a larger scale mesh network with TMesh, <spanx style="verb">communities</spanx> (MAC layer) and <spanx style="verb">routers</spanx> (telehash/app layer).
</t>
<t>A <spanx style="verb">community</spanx> is defined by motes using a shared medium and the automatic sharing of other neighboring motes that it has active windows with in that medium.  Each neighbor mote hashname is listed along with next nonce, last seen, z-index, and the signal strength.  A mote may be part of more than one community but does not share neighbor mote information outside of each one.
</t>
<t>The <spanx style="verb">leader</spanx> is always the neighbor with the highest z-index reachable directly, this is the mote advertising that it has the most resources available. The leader inherits the responsibility to monitor each neighbor's neighbors for other leaders and establish direct or bridged links with them.
</t>
<t>Any mote attempting to connect to a non-local hashname will use their leader as the telehash router and send it a peer request, whom will forward it to the next highest leader it is connected to until it reaches the highest in the community.  That highest resourced leader is responsible for maintaining an index of the available motes in the community.  Additional routing strategies should be employed by a mesh to optimize the most efficient routes and only rely on the leaders as a fallback or bootstrapping mechanism.
</t>
<t>Any mote that can provide reliable bridged connectivity to another network (wifi, ethernet, etc) should advertise a higher z-index and may also forward any telehash peer request to additional telehash router(s) in the mesh via those networks.
</t>
</section>
</section>
</section>

<section anchor="protocol-definition" title="Protocol Definition">

<section anchor="terminology" title="Terminology">
<t>In this document, the key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,
&quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;,
and &quot;OPTIONAL&quot; are to be interpreted as described in BCP 14, [RFC 2119]
and indicate requirement levels for compliant TMesh implementations.
</t>
</section>

<section anchor="phy-1" title="PHY">

<section anchor="private-hopping-sequence" title="Private Hopping Sequence">
<t>Most PHY transceivers require specific synchronized channel and timing inputs, in TMesh these are randomized based on the MAC encryption layer, using the unique secret and nonce for each pair of motes and current window with ChaCha20.
</t>
<t>The first four bytes (32 bits) of the current nonce are used to determine the window microsecond offset timing as a network order unsigned long integer.  Each window is from 2^16 to 2^32 microseconds, the 32-bit random offset is scaled by the current z-index into the possible range of values.
</t>
<t>The current channel is determined by a private two byte seed value that is the ciphertext of <spanx style="verb">0x0000</spanx> using the current window secret/nonce. While any two motes are synchronizing by sending <spanx style="verb">PING</spanx> knocks the channel must remain stable by using a fixed zero nonce.  The two channel bytes are the seed for channel selection as a network order unsigned short integer.  The 2^16 total possible channels are simply mod'd to the number of usable channels based on the current medium.  If there are 50 channels, it would be <spanx style="verb">channel = seed[1] % 50</spanx>.
</t>
</section>

<section anchor="medium-types" title="Medium Types">
<t>Medium <spanx style="verb">type byte</spanx> (0) table:
</t>
<texttable>
<ttcol align="center">Bit 7</ttcol>
<ttcol align="center">Community</ttcol>

<c>0b0xxxxxxx</c><c>Public</c>
<c>0b1xxxxxxx</c><c>Private</c>
</texttable>
<texttable>
<ttcol align="center">Bits 6-0</ttcol>
<ttcol align="center">Encoding</ttcol>

<c>0bx0000000</c><c>Reserved</c>
<c>0bx0000001</c><c>OOK</c>
<c>0bx0000010</c><c>(G)FSK</c>
<c>0bx0000011</c><c>LoRa</c>
<c>0bx0000100</c><c>(O)QPSK</c>
</texttable>
<t>The <spanx style="verb">energy byte</spanx> (1) table:
</t>
<t><list style="empty">
<t>Work In Progress
</t>
</list></t>
<texttable>
<ttcol align="center">Bits 7-4</ttcol>
<ttcol align="center">Max TX mA</ttcol>

<c>0bx0000000</c><c>1</c>
<c>0bx0000001</c><c>4</c>
<c>0bx0000010</c><c>8</c>
<c>0bx0000011</c><c>16</c>
<c>0bx0000100</c><c>32</c>
</texttable>
<texttable>
<ttcol align="center">Bits 7-4</ttcol>
<ttcol align="center">Max RX mA</ttcol>

<c>0bx0000000</c><c>1</c>
<c>0bx0000001</c><c>2</c>
<c>0bx0000010</c><c>4</c>
<c>0bx0000011</c><c>8</c>
<c>0bx0000100</c><c>16</c>
</texttable>
<t>...
</t>

<section anchor="ook" title="OOK">
<t><list style="empty">
<t>TBD
</t>
</list></t>
</section>

<section anchor="gfsk" title="(G)FSK">
<t><list style="empty">
<t>TBD
</t>
</list></t>
</section>

<section anchor="lora" title="LoRa">
<t>Medium Header
</t>
<t>
<list style="symbols">
<t>byte 2 - standard frequency range (see table)</t>
<t>byte 3 - Bw &amp; CodingRate (RegModemConfig 1)</t>
<t>byte 4 - SpreadingFactor (RegModemConfig 2)</t>
</list>
</t>
<t>All preambles are set to the minimum size of 6.
</t>
<t>LoRa is used in implicit header mode with a fixed size of 64.
</t>
<t>Freq Table:
</t>
<texttable>
<ttcol align="center">Region</ttcol>
<ttcol align="center">Low</ttcol>
<ttcol align="center">High</ttcol>
<ttcol align="center">mW (erp)</ttcol>
<ttcol align="center">Reg</ttcol>
<ttcol align="center">ID</ttcol>

<c>US</c><c>902</c><c>928</c><c>100</c><c>FCC part 15.247</c><c>0x01</c>
<c>EU</c><c>863</c><c>870</c><c></c><c>ETSI EN 300-220</c><c>0x02</c>
<c>Japan</c><c>915</c><c>930</c><c></c><c>ARIB T-108</c><c>0x03</c>
<c>China</c><c>779</c><c>787</c><c>10</c><c>SRRC</c><c>0x04</c>
</texttable>
<t>In the US region 0x01 to reach maximum transmit power each window may not transmit on a channel for more than 400ms, when that limit is reached a new channel must be derived from the nonce (TBD) and hopped to.  See <eref target="https://www.semtech.com/images/promo/FCC_Part15_regulations_Semtech.pdf">App Note</eref>.
</t>
<t>Notes on ranges:
</t>
<t>
<list style="symbols">
<t><eref target="http://www.srrccn.org/srrc-approval-new2.htm">SRRC</eref></t>
<t><eref target="http://image.slidesharecdn.com/smarthometechshort-13304126815608-phpapp01-120228010616-phpapp01/95/smart-home-tech-short-14-728.jpg">Z-Wave</eref></t>
<t><eref target="http://blog.atmel.com/2013/04/23/praise-the-lord-a-new-sub-1ghz-rf-transceiver-supporting-4-major-regional-frequency-bands/">Atmel</eref></t>
</list>
</t>
</section>

<section anchor="oqpsk" title="(O)QPSK">
<t><list style="empty">
<t>TBD
</t>
</list></t>
</section>
</section>
</section>

<section anchor="mac-1" title="MAC">

<section anchor="encrypted-knock-payload" title="Encrypted Knock Payload">
<t>A unique 32 byte secret is derived for every pair of motes in any community. The 32 bytes are the binary digest output of multiple SHA-256 calculations of source data from the community and hashnames.  The first digest is generated from the medium (5 bytes), that output is combined with a digest of the community name for a second digest. The third and fourth digests are generated by combining the previous one with each mote hashname in binary ascending sorted order.
</t>
<t>The 8-byte nonce is initially randomly generated and then rotated for every window using ChaCha20 identically to the knock payload.
</t>
<t>The secret and current nonce are then used to encode/decode the chipertext of each knock with ChaCha20.
</t>
</section>

<section anchor="frame-payload" title="Frame Payload">
<t>Each knock transfers a fixed 64 byte ciphertext frame between two motes.  Once the frame is deciphered it consists of one leading flag byte and 63 payload bytes.  The payload bytes are based on the simple telehash chunking pattern, where any packet is sent as a sequence of chunks of fixed size until the final remainder bytes which terminate a given packet and trigger processing.
</t>
<t>The flag byte format is:
</t>
<t>
<list style="symbols">
<t>bit 0 is the forwarding request, 1 = forward the frame, 0 = process it</t>
<t>bit 1 is the payload format, 1 = full 63 bytes are the next chunk, 0 = the payload is the end of a complete packet and the following byte is the remainder length (from 1 to 62)</t>
<t>bit 2-7 is a position number (less than 64) that specifies the forwarding neighbor based on their list position in the most recent neighborhood map exchanged</t>
</list>
</t>
<t>When receiving a forwarded frame the position number is 1 or greater, a position of 0 means the frame is direct and not forwarded.
</t>
</section>

<section anchor="ping-payload" title="PING Payload">
<t>When two motes are not in sync they both transmit and receive a <spanx style="verb">PING</spanx> knock.  This knock's frame bytes always begin with the current 8-byte nonce value that was used to generate the ciphertext of the remaining 56 bytes of the frame and determine the sender's timing of the knock within the current window.
</t>
<t>Once deciphered the first 8 bytes are the next nonce the sender will be listening for, followed by the 32 bytes of the sending mote's hashname.  All remaining bytes are filled in with random values.
</t>
</section>

<section anchor="ping-synchronization" title="PING Synchronization">
<t>The sender should only transmit a <spanx style="verb">PING</spanx> that includes a next nonce with the opposite parity so that a recipient can immediately respond in that upcoming window sequence if that <spanx style="verb">PING</spanx> is detected.
</t>
<t>Once any mote has detected and validated any incoming <spanx style="verb">PING</spanx> from a mote it is attempting to synchronize with, it simply uses the incoming nonce and waits for the next nonce to transmits a <spanx style="verb">PING</spanx> in the next window.
</t>
<t>The original sender can then detect the response <spanx style="verb">PING</spanx> that has the correct matching nonce, validate the hashname, and become synchronized.
</t>
<t>Once synchronized the channel seed begins rotating immediately so that the subsequent windows are randomly hopping different channels and the knocks become regular frame payloads.
</t>
</section>
</section>

<section anchor="mesh-1" title="Mesh">

<section anchor="zindex" title="z-index">
<t>Every mote calculates its own <spanx style="verb">z-index</spanx>, a uint8_t value that represents the resources it has available to assist with the mesh.  It will vary based on the battery level or fixed power, as well as if the mote has greater network access (is an internet bridge) or is well located (based on configuration).
</t>
<t>The z-index also serves as a window mask for all of that mote's receiving window sizes. This enables motes to greatly reduce the time required waking and listening for low power and high latency applications.
</t>
<t>The first 4 bits is the window mask, and the second 4 bits are the energy resource level.
</t>
<t>The initial/default z-index value is determined by the medium as a fixed value to ensure every community can bootstrap uniformly.  It is then updated dynamically by any mote in the neighborhood channel by sending the desired z-index value along with a <spanx style="emph">future</spanx> nonce at which it will become active.  This ensures that any two motes will stay in sync given the time scaling factor in the z-index.
</t>
</section>

<section anchor="neighbors" title="Neighbors">
<t>Each mote should share enough detail about its active neighbors with every neighbor so that a neighborhood map can be maintained.  This includes the relative sync time of each mote such that a neighbor can predict when a mote will be listening or may be transmitting to another nearby mote.
</t>
<t>Neighborhood:
</t>
<t>
<list style="symbols">
<t>8 byte nonce</t>
<t>4 byte microseconds ago last knock</t>
<t>1 byte z index</t>
<t>1 byte rssi</t>
</list>
</t>
</section>

<section anchor="communities" title="Communities">
<t><list style="empty">
<t>Describe communities and routing in more detail, and routers performing ongoing sync-mode duties.
</t>
</list></t>
<t>A community is defined as a single medium and a string name, both of which must be known to join that community.  They are the primary mechanism to manage and organize motes based on available spectrum and energy, where each community is bound to a single medium with predictable energy usage and available capacity.
</t>
<t>Any mesh may make use of multiple communities to optimize the overall availability and reliability, but different communities are not a trust or secure grouping mechanism, the medium and name are not considered secrets.
</t>

<section anchor="private-community" title="Private Community">
<t>A private community is not visible to any non-member, other than randomly timed knock transmissions on random channels there is no decodeable signals detectable to any third party, it is a dark mesh network that can only be joined via out-of-band coordination and explicit mesh membership trust.
</t>
<t>In order for any mote to join a private community it must first have at a minimum the community name, the hashname of one or more reachable motes in that community, and the medium on which it is operating. It must also have it's own hashname independently added as a trusted member to the mesh so that the reachable motes are aware of the joining one.
</t>
<t>The stable seed for the <spanx style="verb">PING</spanx> channel will be unique to each two motes based on the private secret for the window sequence.
</t>
</section>

<section anchor="public-community" title="Public Community">
<t>A public community is inherently visibile to any mote and should only be used for well-known or shared open services where the existince of the motes in the community is not private.  Any third party will be able to monitor general participation in a public community, so they should be used minimally and only with ephemeral generated hashnames when possible.
</t>
<t>Since the hashnames are not known in advance, the public community window sequence secret is generated with null/zero filled hashnames so that the <spanx style="verb">PING</spanx> channel is a stable seed.  The only difference from a private community is that the hashnames sent/received in a <spanx style="verb">PING</spanx> are used as the source to generate a new window sequence secret once exchanged.
</t>
<t>This functionality should not be enabled/deployed by default, it should only be used when management policy explicitly requires it for special/public use cases, temporary pairing/provisioning setup, or with ephemeral generated hashnames used to bootstrap private communities.
</t>
</section>
</section>

<section anchor="optimizations" title="Optimizations">
<t>Since a community includes the automated sharing the time offsets of neighbors, any mote can then calculate keep-out channels/timing of other motes based on their shared community windows and optimize the overall medium usage.  In this way, each community will have its own QoS based on each local neighborhood.
</t>
</section>
</section>
</section>

<section anchor="implementation-notes" title="Implementation Notes">
<t>
<list style="symbols">
<t>if a packet chunk is incomplete in one window, prioritize subsequent windows from that mote</t>
<t>prioritize different communities based on their energy performance, test more efficient ones dynamically</t>
</list>
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">
</section>

<section anchor="references" title="References">
</section>

</middle>
<back>

<section anchor="examples" title="Examples">
<t>This appendix provides some examples of the tmesh protocol operation.
</t>

<figure align="center"><artwork align="center">
   Request:


   Response:

</artwork></figure>
</section>

</back>
</rfc>