Differences

This shows you the differences between two versions of the page.

--- mtrp:routing [2026/06/10 12:51] – mosh
+++ mtrp:routing [2026/06/10 13:34] (current) – mosh
@@ Line 1: / Line 1: @@
-====== Routing Behavior ======
+====== 5. Routing Behavior ======
-===== Neighbor Routes =====
+===== 5.1 Purpose =====
-A neighbor route is a destination reachable directly on a registered local path.
+This document defines how MTRP learns, stores, and selects routes.
-Direct neighbors are stored in the neighbor table.
+===== 5.2 Direct Neighbor Reachability =====
-===== Learned Routes =====
+A destination that is reachable directly on a registered local path MUST be treated as a neighbor candidate.
-A learned route is a route advertisement received from another node.
+Direct-neighbor state MUST be stored in the neighbor table.
-Learned routes are stored in the forwarding table as route candidates. Multiple candidates may exist for the same destination.
+===== 5.3 Learned Route Reachability =====
-Example:
+A route advertisement received from another node MAY create or update a learned forwarding candidate.
-  * destination A via next hop B
-  * destination A via next hop C
-  * destination A via next hop D
-===== Send-Time Resolution =====
+Learned candidates MUST be stored in the forwarding table.
-For unicast frames, MTRP resolves egress in this order:
+Multiple forwarding candidates for the same destination MAY exist simultaneously.
-  - use an already-valid explicit egress path if one is present
+===== 5.4 Route Resolution Order =====
-  - try direct neighbor resolution
-  - try forwarding-table resolution
-  - mark the frame unroutable if no valid path exists
-===== Preferred Routes =====
+For unicast traffic, MTRP MUST resolve egress in the following order:
-Preferred routes are populated when a forwarded route is actually selected.
+  - explicit valid egress path, if already present
+  - direct-neighbor resolution
+  - forwarding-table resolution
+  - unroutable result if no valid candidate exists
-This means a node may have many learned routes in the forwarding table while the preferred route table remains empty until forwarding is needed.
+===== 5.5 Metric Behavior =====
-===== Expected Bench Behavior =====
+Metrics are additive across relayed advertisements.
-If all nodes can hear each other directly:
+A directly reachable destination SHOULD have a lower metric than the same destination learned through one or more relays, assuming all constituent path metrics are positive.
-  * direct routes usually have the lowest metric
-  * forwarded alternatives still appear as learned candidates
+===== 5.6 Preferred Route Population =====
-  * direct routes should normally be selected over indirect ones
+Preferred-route entries are populated at send-time route selection.
+Preferred-route entries are not required to be created when a learned route is first stored.
+As a result, the preferred route table MAY remain empty even when the forwarding table contains valid learned routes.
+===== 5.7 Practical Interpretation =====
+If all participating nodes are direct neighbors of one another, MTRP MAY still learn indirect candidates through re-advertisement. In such a topology, direct routes SHOULD normally be preferred over indirect candidates with worse metrics.