NodalPath is what NodalArc looks like when you take that question seriously.

Posts 003, 004, and 008 have been circling it: the future is computable, the platform already publishes it, and the handoffs are already scheduled. The only component still living in the dark is the router.

FIG.01 — Centralized forwarding ENGINE → SIDECAR → KERNEL
The OME publishes to a centralized nodalpath engine that pushes forwarding tables to four nodes; each node decomposed into FRR (observability only), an accent-filled fwd-sidecar, and the kernel FIB. The OME publishes to a centralized nodalpath engine that pushes forwarding tables to four nodes; each node decomposed into FRR (observability only), an accent-filled fwd-sidecar, and the kernel FIB.
The engine is the sole writer of every node's forwarding table. FRR stays in the pod for observability, but it does not decide what packets do.

What NodalPath does

NodalPath subscribes to the same orbital truth the rest of the platform consumes: the OME's stream of visibility events, the SessionEphemeris, the live constellation state. But instead of letting an IGP turn those events into forwarding state after the fact, NodalPath computes the forwarding state itself, ahead of time, and pushes it directly into each node's kernel.

The controller that knows the future

Centralized path computation is SDN's familiar shape: one engine computes the forwarding decisions for every node and pushes the result down. In terrestrial SDN the controller does the math because the switches cannot reasonably do it themselves.

In orbital networking the controller holds a different advantage: it knows the future. Forwarding state can be computed for a horizon ahead of when the geometry actually produces it, which no terrestrial controller can claim.

So NodalPath is, in shape, that kind of system. A single engine takes the orbital model and the traffic demand, runs a path computation that decides which packets should leave which node on which interface, and emits forwarding-table updates to a sidecar running next to each node's routing daemon. The sidecar applies the update to the kernel. FRR, still running in the same pod, is reduced to observability: zebra reports what is in the kernel, staticd lets you sanity-check it, but neither contributes to forwarding decisions.

The split between routing and forwarding

The distinction that matters is who owns each plane. In a normal FRR session inside NodalArc, the control plane and the forwarding plane live together on each node: IS-IS computes routes, zebra installs them in the kernel forwarding table. Both planes share the same daemon family on each pod.

FIG.02 — Reactive vs proactive SAME EVENTS · OPPOSITE ORDERING
Two stacked timelines on the same axis. Reactive (IGP) row: detect, recompute, install bars trail each event. Proactive (NodalPath) row: pre-installed bar is in place before the event marker arrives. Two stacked timelines on the same axis. Reactive (IGP) row: detect, recompute, install bars trail each event. Proactive (NodalPath) row: pre-installed bar is in place before the event marker arrives.
Same link events plotted on the same axis. The reactive line installs forwarding state after each event lands; the proactive line has it in the kernel already. The gap is the convergence cost the IGP cannot avoid.

In a NodalPath session, the planes are split between processes. The control plane is now a centralized engine that knows the orbital truth in advance. The forwarding plane is a small sidecar on each node that knows nothing about routing protocols, only about how to install what the engine sent it. The sidecar uses pyroute2 to write into a dedicated Linux policy routing table. FRR is still in the pod, but it is observability only. Nothing FRR computes affects the forwarding decisions packets actually see.

The architecture matters because it answers a question that comes up the moment you start thinking about proactive routing: who has the final say? In NodalPath sessions, the answer is the engine. The engine is the sole writer of the forwarding table. Nothing else gets to touch it.

Trying it from a session

Switching a session from an IGP to NodalPath is a one-line change to the session YAML.

IGP (IS-IS)
routing:
  protocol: isis
  extensions:
    - traffic-engineering
  area_assignment:
    strategy: flat
NodalPath
routing:
  protocol: nodalpath
  extensions: []

The constellation file, the ground stations, the propagator, the dispatch policy: all untouched. The only thing that changes is who owns forwarding inside each pod.

When the session deploys, the platform sees the protocol change and brings up the right pod composition. For an IGP session, each pod runs FRR with its full daemon set. For a NodalPath session, each pod still runs FRR (zebra and staticd, observability only) and adds the nodalpath-fwd sidecar. The platform handles the difference; nothing else about the session description has to be aware of it.

You can run the same constellation under both protocols, separately, and compare. Same orbital truth. Same ground stations. Same workload. Different forwarding-plane authority. The differences in the measurements are the differences between proactive and reactive routing on the same orbital network.

What this is for

The whole point of NodalArc is to be a place where these comparisons can be made cleanly. The substrate compensation from post 005 (The Lab Is a Network) made the latency numbers honest. The composability from post 006 (One Idea Per File) made it cheap to change one variable. The authoring contract from post 007 (The YAML Is The Contract) made the comparison cheap to produce. The handoff machinery from post 008 (The Tower Is the One Moving) made the user-perspective intelligible. NodalPath is the first place all of that pays off as a question worth asking.

Whether the proactive answer is meaningfully better than the reactive one is not what this post resolves. That answer comes from running both, measuring both, and reading the numbers. The next several posts move into that phase.

What's next

post 010 (Worlds, Not Constellations) steps back to the contract that lets those comparisons grow without getting sloppy. LEO was the test stand, not the destination. The next shape of NodalArc has to describe network worlds, not just one constellation at a time.