← RFC

Loomwave Protocol Specification — Routing Layer

Stage 3 / Checkpoint C deliverable. Status: Draft normative spec. Date: 2026-06-09. Depends on: packet-format.md (addresses, REGISTER/ADVERT/BEACON), mac-spec.md (schedule, fallback). Validated by: sim-result-v5 (INFRA-DV is O(N); flooded link-state collapses at 1441% of channel by N=100; INFRA-DV ~23× cheaper).

Normative language per RFC 2119/8174. This document specifies how addresses are formed, how routes are discovered and maintained, how the few coordinators carry an aggregated link-state backbone, how coordinators are selected by measured vantage rather than config role, and how the network routes when no coordinator exists.


1. Model overview

Routing is two-tier, matching the asymmetric node model:

This is the synthesis chosen at Checkpoint B: mesh-wide flooding (Meshtastic) and mesh-wide link-state both collapse at scale (sim-result-v1/v5); confining link-state to the backbone and aggregating the edge keeps control overhead O(N) and tunable to the ~12–20% airtime budget via registration cadence (v5).

2. Addresses — self-certifying, collision-checked

3. Edge tier — registration and forwarding

3.1 Registration

A client/repeater joins a cell by sending REGISTER (packet-format.md §8.2) to the coordinator in the contention window, carrying CAP_FLAGS (relay-capable, multi-radio, power class), REQ_SLOT, and LINK_REPORTS (the SNR at which it hears each coordinator). The coordinator:

  1. resolves any address collision (§2),
  2. records the node in its cell membership table,
  3. grants a data slot (or reuse assignment) in a subsequent SLOTMAP (mac-spec.md §4),
  4. uses LINK_REPORTS for modulation selection (mac-spec.md §8) and as election evidence (§5).

Registration cadence is the control-overhead knob (v5): clients refresh registration every REG_PERIOD superframes (default scales with cell size to hold control < 15%). A coordinator MUST expire members not heard for REG_EXPIRE (default 3·REG_PERIOD).

3.2 Forwarding table

A client holds a next-hop table keyed by destination prefix, not a full route set: - destinations in-cell → direct (own slot to DST, or coordinator relays), - destinations out-of-cell → next hop = the coordinator, - the coordinator holds, from the backbone tier (§4), the next coordinator toward any remote cell.

A relay MUST forward a DATA frame whose DST is not itself and whose HOPLIM > 0 by decrementing HOPLIM (packet-format.md §3) and transmitting in its own slot toward the next hop. Loops are bounded by HOPLIM; HUSE is a diagnostic.

4.1 Transport-agnostic adjacency

A backbone adjacency is a link, independent of how it is carried — this unifies the hardware and federation stories (project decision, dual-radio-pi-hat-hardware memory):

Adjacency carrier Example
LoRa elevated-to-elevated hop two high sites in radio LOS (high-site-backbone.md)
Intra-node local fabric dual-radio HAT / HAT+USB / two boxes on a site LAN
IP backhaul VPN / point-to-point / internet (what MQTT bridging is today)

Each adjacency advertises a link type and metrics (latency, bandwidth, reliability, and a is_backhaul flag). The SPF computation treats them uniformly except for the dependency rule:

Inter-coordinator link cost is derived from measured SNR/airtime, not hop count: cost rises with lower margin and higher utilization, so SPF prefers robust, uncongested backbone paths. (The propagation basis is the calibrated exponent n≈2.5 from propagation-calibration-result.md.)

5. Coordinator selection — by measured vantage, not config role

This is the normative form of the Checkpoint-B finding (elevated-nodes.md, high-site-backbone.md): role is an unreliable signal for who should coordinate — 4 of 8 real high sites were labeled CLIENT_MUTE/unset. Coordinator membership is therefore elected by capability and vantage.

5.1 Candidacy and evidence

A node asserts candidacy with a coordinator-claim ADVERT (packet-format.md §8.3) whose ADV_BODY carries an election score built from objective, partly-verifiable evidence:

A claim is signed; peers weight it by the corroboration in their own measurements, so a node cannot simply declare a high score — election rewards measured reach, not assertions.

5.2 Election and stability

Rationale. Tying coordination to measured reach (corroborated) rather than a config flag means the network self-organizes its backbone around the nodes that physically can coordinate — and is robust to the real-world fact that operators mislabel roles.

6. Routing without a coordinator (fallback)

When no coordinator is present (mac-spec.md §6), routing is reactive / AODV-style over the epoch-hash contention plane:

Convergence targets (sparse-rural cold start, dense-event, neighborhood) are the scenario classes of sim-result-v7; the spec inherits those measured behaviours rather than re-asserting numbers here.

7. Topology change — join / leave / move

8. Conformance (routing)

A conformant node MUST: (1) derive a self-certifying ADDR24 and run the collision procedure (§2); (2) register via scheduled unicast, never flood registration (§3.1); (3) forward by next-hop with HOPLIM bounding loops (§3.2). A conformant coordinator additionally MUST: (4) keep link-state aggregated to the backbone, never flood LSAs into cells (§4); (5) maintain a LoRa-only reachability view and never let backhaul become a dependency (§4.1); (6) elect/defer by corroborated measured score with hysteresis, never by self-asserted role alone (§5); (7) fall back to rate-capped reactive routing when uncoordinated (§6).


Builds on packet-format.md + mac-spec.md. Coordinator election consumes security-spec.md identities/signatures. Reviewed at Checkpoint C before firmware.