mtrp:routing
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| mtrp:routing [2026/06/10 13:10] – mosh | mtrp:routing [2026/06/10 13:34] (current) – mosh | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | ====== |
| - | ===== 3.1 Purpose ===== | + | ===== 5.1 Purpose ===== |
| This document defines how MTRP learns, stores, and selects routes. | This document defines how MTRP learns, stores, and selects routes. | ||
| - | ===== 3.2 Direct Neighbor Reachability ===== | + | ===== 5.2 Direct Neighbor Reachability ===== |
| A destination that is reachable directly on a registered local path MUST be treated as a neighbor candidate. | A destination that is reachable directly on a registered local path MUST be treated as a neighbor candidate. | ||
| Line 11: | Line 11: | ||
| Direct-neighbor state MUST be stored in the neighbor table. | Direct-neighbor state MUST be stored in the neighbor table. | ||
| - | ===== 3.3 Learned Route Reachability ===== | + | ===== 5.3 Learned Route Reachability ===== |
| A route advertisement received from another node MAY create or update a learned forwarding candidate. | A route advertisement received from another node MAY create or update a learned forwarding candidate. | ||
| Line 19: | Line 19: | ||
| Multiple forwarding candidates for the same destination MAY exist simultaneously. | Multiple forwarding candidates for the same destination MAY exist simultaneously. | ||
| - | ===== 3.4 Route Resolution Order ===== | + | ===== 5.4 Route Resolution Order ===== |
| For unicast traffic, MTRP MUST resolve egress in the following order: | For unicast traffic, MTRP MUST resolve egress in the following order: | ||
| Line 28: | Line 28: | ||
| - unroutable result if no valid candidate exists | - unroutable result if no valid candidate exists | ||
| - | ===== 3.5 Metric Behavior ===== | + | ===== 5.5 Metric Behavior ===== |
| Metrics are additive across relayed advertisements. | Metrics are additive across relayed advertisements. | ||
| Line 34: | Line 34: | ||
| 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. | 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. | ||
| - | ===== 3.6 Preferred Route Population ===== | + | ===== 5.6 Preferred Route Population ===== |
| Preferred-route entries are populated at send-time route selection. | Preferred-route entries are populated at send-time route selection. | ||
| Line 42: | Line 42: | ||
| As a result, the preferred route table MAY remain empty even when the forwarding table contains valid learned routes. | As a result, the preferred route table MAY remain empty even when the forwarding table contains valid learned routes. | ||
| - | ===== 3.7 Practical Interpretation ===== | + | ===== 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. | 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. | ||
/var/www/wiki.moshnetworks.com/data/attic/mtrp/routing.1781097015.txt.gz · Last modified: by mosh