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

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.

Centralized path computation

Centralized path computation is the idea that one component, somewhere in the network, computes the forwarding decisions for all the nodes and pushes the result to each of them. The familiar contrast is the distributed approach traditional IGPs use: every router runs its own copy of the algorithm, every router floods state to every other router, and every router computes its own forwarding table. The two approaches answer the same question (which interface gets the packet?) but the architectures are opposite.

The pattern is most familiar from software-defined networking, where a controller computes flow rules and pushes them down to switches. In that context the controller is doing the math because the switches cannot reasonably do it themselves. In orbital networking the controller has a different advantage: it knows the future. Forwarding state can be computed for a horizon ahead of when the underlying topology actually produces it.

In NodalArc, the centralized-path component is called nodalpath. It subscribes to the OME's stream, propagates the constellation locally, decides what every node's forwarding table should look like at each moment, and pushes those tables to a sidecar that installs them.

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

This requires being careful about a distinction terrestrial network engineers sometimes leave implicit.

Control plane vs forwarding plane

The control plane is whatever decides which packets should go where. In a traditional router this is the routing protocol: IS-IS, OSPF, BGP. The control plane runs on the router's CPU, exchanges state with peers, and computes which interface a packet bound for a given destination should leave on.

The forwarding plane is whatever actually moves the packets. It is the hardware (or software, in our case) that looks at an incoming packet's headers, looks up the forwarding table the control plane computed, and shoves the packet out the chosen interface. The forwarding plane wants to be fast and dumb. The control plane is allowed to be slower and smarter.

In most routers the two planes are intimately coupled and live in the same box. They cooperate by convention more than by explicit handoff. The interesting designs are usually the ones that pull them apart on purpose.

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 wizard from post 007 (The Session Builder) made it visual. 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 walks through the first comparison: same constellation, same ground stations, IS-IS in one run, NodalPath in the other, and the convergence numbers side by side. The point of all the architecture posts has been to make that comparison clean. Now we get to see whether it produces anything interesting.