irf/dnac: inter-regional forwarding as a flat region mesh

[zebastian]

Adds inter-regional forwarding (IRF) and DTN node auto-configuration (DNAC) to ION-DTN as implemented by Scott Burleight in the IONe code.

Then reworks IRF from the original hierarchical region tree into a flat region mesh.

The branch is structured so the upstream provenance is preserved:

• 7 commits authored by Scott Burleigh import the original irf/dnac code from IONe (the irr→irf rename, IRF path-trace reports, dnac→dnacp, registration-contact fix, etc.).
• 1 compatibility commit integrates that code into ION-DTN's diverged ICI/BP internals (shared files: rfx.c, ion.{c,h}, ionsec.{c,h}, rfx.h, ipnfw.c, libbpP.c, bpextensions.c, bp.h, bpP.h,
  Makefile.am).
• 2 commits implement the flat-mesh model + adapt the test.

The original IRF organized regions as a tree: every node belonged to at most two regions (a home/inner and an outer/super region), and routing direction (inward/outward) plus loop-freedom derived from that hierarchy. This PR removes the hierarchy: a node can belong to any number of peer regions with no precedence, which lets passageway
regions, private contact plans, and "shortcut" links fall out naturally without special mechanisms.

Known limitations

• Cross-region membership changes aren't auto-propagated. A per-region CPS announcement can't tell members of region Z that a node just joined region Y, so a node becoming a passageway
  mid-life needs an out-of-band re-brief (documented at the announcement site; tests/irf does this explicitly in one step).
• A non-bridge node that's asked to relay declines silently (no blacklist feedback) — it may be re-probed by upstream. Single-hop blacklist feedback is left as follow-up.
• No path-cost metric yet (confirmed passageways are chosen by earliest confirmation), and the first probe fans out more widely than the old tree (bounded by trace + confirm/blacklist).

[zebastian]

@scburleigh to review

changes done:

Data model (ici/include/ion.h)

• RegionMember is now { fqnn, regionNbrs[ION_MAX_REGIONS], regionCount, bridgeAllowed } (was { fqnn, homeRegionNbr, outerRegionNbr }).
• IonDB.regions is a 16-slot array (ION_MAX_REGIONS) plus a node-level bridgeAllowed.

Routing (bpv7/irf/libirf.c, bpv7/ipn/ipnfw.c)

• irf_identify_passageways selects passageways by shared region + explicit IPT-trace loop-prevention (never forward to a node already in the trace), replacing the inward/outward hierarchy
  logic. Candidate eligibility uses a single binary-searched rolodex snapshot rather than a per-candidate scan-and-lock.
• Opt-in bridging is enforced locally at the bridge (tryIRF consults ionBridgeAllowed), so candidate selection doesn't depend on racy propagation of a remote node's flag.

Region management (ici/library/rfx.c)

• Registration/unregistration rewritten as additive set membership with no hierarchy or cascade; vacateRegion compacts the regions array and retains other nodes' membership for mesh
  routing.
• Each passageway's full membership + bridge flag propagate through the existing contact briefings.

Opt-in bridge flag

• New ionadmin command m bridge { 0 | 1 } (documented in ionrc.pod). Default off — a multi-region node only relays inter-regional traffic if it opts in; it may always originate
  inter-regional bundles.

Admin / DNAC

• dnacp places a new node in the sponsor's most-recently-joined region.

[250MHz]

Note that there's an internal branch with IONe's IRF all cleaned up; it hasn't been merged into integration yet because of concerns about maintainability and funding, etc., but we're planning to make the branch public once IPNSIG is ready for their Bundle Bone experiments.

A flat mesh does differ from how I-D.burleigh-regions-00 treats region numbers with topographical significance, though my first impression is that a flat mesh is more flexible. Interested to hear Scott's thoughts as well.

[scburleigh]

Sure. https://datatracker.ietf.org/doc/draft-burleigh-regions/ is the best approach I've been able to come up with so far, provided that two additional notions are included:

• The “passageway” between a “child” region and its “parent” region should be an additional region with its own contact plan, thus keeping the contact plans of the parent and child regions private; this could be vital for commercial operations and more generally for network security. The passageway region’s name might be an expression of the form parentRegionNumber.childRegionNumber. Every node in the passageway region would be cited in the passageway region’s contact plan and in the contact plan of either the parent region or the child region, but not both. This would easily enable multiple alternate routes through the region topology without adding more structural mechanisms.
• Routing might be accelerated, at the cost of some additional management and routing complexity, by agreement between the administrators of any two regions to establish a “shortcut” passageway region in addition to the standard parent/child passageways. Such a shortcut passageway might be named by an expression of the form largerRegionNumber.smallerRegionNumber, to make it easily distinguishable as a shortcut. This lets you flatten the mesh as much as you like, at the cost of losing easy routing based just on region numbers.

[scburleigh]

@zebastian, commenting a little further: I think the approach I described in my earlier comment has many of the same advantages as the approach you've taken here. The region topology itself is flat - any two regions can be directly connected by a shortcut passageway region - but the names of the regions are hierarchical. This naming convention imposes a default structure on the topology that a bundle can navigate successfully, from any region in the network to any other, without knowing anything other than the name of one region in which the destination node resides. It's advantageous in a way that is similar to Internet routing while remaining delay-tolerant.

True, the default path from the source region to the destination region might be lengthy. But since regions pre-exist their residents, an operator of a space enterprise can assure short IRF paths among her own nodes by simply choosing to occupy some set of regions whose numbers are numerically adjacent, anywhere in the topology: 11817, 118171, 118172, 118173, 118174 for example. Short paths to nodes in the regions of other enterprises can be assured by choosing to occupy regions whose numbers are similarly numerically near, like 11821, 118211, 118212. Forwarding among nodes in regions that are closely related in this way is not only trivial but also quick. Forwarding among nodes in regions connected by shortcut passageways is also quick but is not trivial - management is needed that goes beyond simply editing contact plans.

Just as in your approach, a node can belong to (that is, be cited in the contact plans of) any number of regions. But each node resides in at most one non-passageway region; the only precedence is that a bundle that is issued by a bundle must traverse the node's local region before traversing any other, no surprise there. No special mechanisms are needed for passageway regions, private contact plans, or shortcut regions; it's all just a matter of editing contact plans and letting contact plan synchronization propagate the edits to all region members.

On the limitations you mention:

• Cross-region membership changes could be auto-propagated, but it may not be a good idea. When a node is added to the contact plan for region A, that contact plan change is propagated to all nodes in region A including all nodes in the passageway regions between A and adjacent regions. The nodes in those passageway regions could readily forward that region membership information to other nodes in the passageway regions and from there to adjacent regions, etc. Whether or not flooding this information across the network makes sense remains an open question. I think a mechanism that's similar to the way URLs get propagated among Internet users and applications - basically, targeted announcements - may make more sense.
• No node is explicitly asked to relay anything across the region topology, any more than any node is explicitly asked to forward a bundle through the local region. Forwarding across the network is just a matter of determining the next node to forward the bundle to - always a node in the local region, even if that node is also a known member of the passageway region to the next region on the best IRF path - and sending to that node. You do it or you don't, for whatever reason makes sense. When forwarding fails, for whatever reason, recovery procedures need to be invoked.
• There is no dependence on probing at any time, so probe performance isn't an issue; blacklisting is not a feature of the architecture. Some sort of path cost metric ought to emerge eventually, but I don't know know what that mechanism might be.