Differences

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

--- mtrp:routing [2026/06/10 12:46] – created mosh
+++ mtrp:routing [2026/06/10 13:34] (current) – mosh
@@ Line 1: / Line 1: @@
-====== Routing Behavior ======
+====== 5. Routing Behavior ======
-===== Summary =====
+===== 5.1 Purpose =====
-MTRP maintains separate state for direct neighbors, learned route candidates, and preferred forwarding choices.
+This document defines how MTRP learns, stores, and selects routes.
-===== Neighbor Routes =====
+===== 5.2 Direct Neighbor Reachability =====
-A direct neighbor route is a destination that can be reached on a locally registered path without relaying through another node.
+A destination that is reachable directly on a registered local path MUST be treated as a neighbor candidate.
-Direct neighbor routes are stored in the neighbor table.
+Direct-neighbor state MUST be stored in the neighbor table.
-===== Learned Routes =====
+===== 5.3 Learned Route Reachability =====
-A learned route is a route advertisement received from another node.
+A route advertisement received from another node MAY create or update a learned forwarding candidate.
-Learned routes are stored in the forwarding table as route candidates. Multiple candidates may exist for the same destination.
+Learned candidates MUST be stored in the forwarding table.
-Example:
+Multiple forwarding candidates for the same destination MAY exist simultaneously.
-  * destination A via next hop B
-  * destination A via next hop C
-  * destination A via next hop D
-===== Preferred Routes =====
+===== 5.4 Route Resolution Order =====
-Preferred routes are not a copy of all learned routes.
+For unicast traffic, MTRP MUST resolve egress in the following order:
-A preferred route entry is created when MTRP actually selects a forwarding route for a destination during send-time resolution.
+  - explicit valid egress path, if already present
+  - direct-neighbor resolution
+  - forwarding-table resolution
+  - unroutable result if no valid candidate exists
-This means:
+===== 5.5 Metric Behavior =====
-  * the forwarding table represents what the node knows
-  * the preferred route table represents what the node has chosen to use
-===== Send-Time Resolution =====
+Metrics are additive across relayed advertisements.
-When sending a unicast frame, MTRP resolves the egress path in this order:
+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.
-  - use an already-valid explicit egress path if present
+===== 5.6 Preferred Route Population =====
-  - try direct neighbor resolution
-  - try forwarding-table resolution
-  - mark unroutable if no valid path exists
-===== Notes =====
+Preferred-route entries are populated at send-time route selection.
-A destination may appear many times in the forwarding table if multiple next-hop candidates are known.
+Preferred-route entries are not required to be created when a learned route is first stored.
-This is normal behavior.
+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.