On the ground, topology is something you can lie about for a while.
Draw three routers in a triangle. Give every link a cost. Put a metro ring behind one node and a transit exit behind another. You may be simplifying the real network, but the simplification holds still long enough to be useful. The routers stay where you put them. The fiber stays in the trench. The drawing may be incomplete, but it is not moving under your pencil.
Space does not work that way.
A satellite network begins with geometry. Altitude, inclination, terminal count, terminal range, antenna slew rate, and ground-station placement decide what links can exist before any router opens its mouth. The protocol does not get a vote. The controller does not get a vote. The routers inherit the graph the sky hands them.
That is the geometry problem.
If the geometry is wrong, every result downstream is suspect. You are not testing IS-IS, OSPF, BGP, path computation, a vendor router, or a real external workload against an orbital network. You are testing against your drawing of one.
The drawing is not good enough.
Two flavors of Walker
Most practical low Earth orbit constellations are variations on a Walker pattern: satellites spread across orbital planes, evenly spaced, moving in a shape that repeats. Two forms matter immediately.
A Walker Delta tilts its planes at a moderate inclination. Starlink and Kuiper live in this neighborhood. The planes all move the same general way, cross-plane motion stays tame, and the inter-satellite links can remain fairly civilized. The price is coverage. A 53-degree constellation does not reach the poles. It was never going to. The geometry stops there.
A Walker Star pushes the planes close to polar. Iridium and OneWeb live here. Now the constellation can reach the whole planet, but the cross-plane links have a different problem. Near the equator, satellites in adjacent planes drift past each other at a rate the terminals can track. Near the pole, those same satellites are moving in opposite directions and closing hard.
From the antenna's point of view, the other satellite is no longer drifting past. It is whipping by.
Nothing failed. The topology changed because the topology is motion.
That is the polar seam. It is not a routing bug. It is not a bad timer. It is the point where the hardware can no longer keep the link lit.
Primitives, not presets
NodalArc cannot be a pile of constellation presets. That would be a toy, and not a very useful one. The point is to describe the pieces cleanly enough that different skies, different hardware, different ground exits, and different routing can be combined without hand-wiring every experiment.
The primitives are simple on purpose.
A satellite type describes the machine.
A constellation describes where those machines fly.
A ground station describes where the orbital network touches Earth.
The routing block describes what runs inside the nodes.
That discipline matters because space networks are full of tempting false answers. Change the geometry and the protocol at the same time, and you may not know which one produced the result. Change the ground exits and the satellite hardware together, and the lesson blurs. NodalArc is built to keep the variables apart until you choose to combine them.
The first primitive is the satellite type.
satellite_type:
name: starlink-v2
isl_terminals:
- type: optical
count: 4
max_range_km: 5000
bandwidth_mbps: 100
max_tracking_rate_deg_s: 3.0
field_of_regard_deg: 140
ground_terminals:
- type: rf
count: 1
bandwidth_mbps: 1000
band: KuThat is hardware, not decoration. Four optical terminals. One ground terminal. A range. A bandwidth. A pointing limit.
A drawing might want six links from a satellite. The satellite has four terminals. The other two links do not exist. There is nowhere to plug them in.
The hardware does not decorate the topology. The hardware decides which parts of the geometry become real.
Iridium NEXT tells a different story.
satellite_type:
name: iridium-next
isl_terminals:
- type: rf
band: Ka
count: 2
role: intra-plane
max_range_km: 4400
bandwidth_mbps: 10
max_tracking_rate_deg_s: 4.0
field_of_regard_deg: 120
- type: rf
band: Ka
count: 2
role: cross-plane
max_range_km: 4400
bandwidth_mbps: 10
max_tracking_rate_deg_s: 2.5
field_of_regard_deg: 120
ground_terminals:
- type: rf
band: Ka
count: 1
bandwidth_mbps: 200There is the polar seam, sitting in the file.
The cross-plane terminals can track at 2.5 degrees per second. At lower latitudes, that is enough. Near the pole, adjacent planes are counter-rotating and the apparent motion runs past the terminal's limit. The beam cannot stay on target. The link drops.
It is not folklore. It is not a special excuse invented after the network fails. It is a mechanical limit, stated before the experiment starts.
The second primitive is constellation geometry.
mode: parametric
name: starlink-early-44
satellite_type: starlink-v2
orbit:
altitude_km: 550
inclination_deg: 53
pattern: walker-delta
planes:
count: 4
raan_spacing_deg: 45
sats_per_plane: 11
phase_offset_deg: 8.2This is a small Walker Delta. Four planes. Eleven satellites per plane. A 53-degree inclination. The planes move in the same general direction, and the cross-plane links can stay steady enough to make the routing problem look almost polite.
Almost.
The same structure can describe Iridium.
mode: parametric
name: iridium-66
satellite_type: iridium-next
orbit:
altitude_km: 780
inclination_deg: 86.4
pattern: walker-star
planes:
count: 6
raan_spacing_deg: 31.6
sats_per_plane: 11
phase_offset_deg: 5.45
polar_seam:
enabled: true
latitude_threshold_deg: 70Now the inclination is 86.4 degrees. The constellation goes polar. The seam is explicit. Above 70 degrees latitude, cross-plane links are allowed to drop because the terminals can no longer track fast enough.
The protocol did nothing wrong. The router did nothing wrong. The link disappeared because the geometry made it disappear.
The third primitive is the ground station.
ground_station:
name: ashburn
lat_deg: 39.04
lon_deg: -77.49
alt_m: 100
min_elevation_deg: 25
terminals:
- type: rf
count: 2
bandwidth_mbps: 1000
tracking_capacity: 1
terrestrial_prefixes:
- prefix: "172.16.2.0/24"
metric: 10
- prefix: "0.0.0.0/0"
metric: 100A ground station is not just a dot on a map. It is a place where the orbital network becomes reachable from Earth. It has latitude, longitude, elevation limits, terminal count, terminal capacity, and prefixes to advertise.
Geometry with addresses.
Put a station in Ashburn and you get one kind of exit. Put one in Svalbard and you get another. Put one in McMurdo and the network has to care about a part of the planet most terrestrial backbones never think about.
The fourth primitive is the routing.
routing:
protocol: isis
extensions:
- traffic-engineering
area_assignment:
strategy: per-planeToday it is FRR.
FRR is the easiest first tool because it is open, practical, and speaks the protocols we need to test. But NodalArc is not built around FRR as the answer. It is built around the emulation as the question.
The router could be FRR. It could be Juniper cRPD, Cisco XRd, Arista cEOS, Nokia SR Linux, or something else that can live in a container and speak like a router. It could be an external controller. It could be a real workload attached to the emulated fabric.
NodalArc's job is to build the moving network around that router, then let it behave like itself.
That is why this is emulation, not simulation. A simulator tells you what its model thinks a router would do. An emulator gives the router a world to live in and watches what it actually does.
A session is a controlled argument
A session ties the primitives together.
session:
name: iridium-66-isis-flat
constellation: configs/constellations/iridium-66.yaml
ground_stations: configs/ground-stations/sets/polar-emphasis.yaml
routing:
protocol: isis
extensions:
- traffic-engineering
- sr
area_assignment:
strategy: flat
time:
step_seconds: 1Now you have an experiment.
Iridium geometry. Polar-emphasis ground stations. IS-IS with traffic engineering and segment routing enabled. One flat area. One-second time steps.
Hold the geometry steady and change IS-IS to OSPF. Now the protocol changed and the sky did not.
Hold the routing steady and change the constellation from Iridium to Kuiper. Now the sky changed and the protocol did not.
Keep both and move the ground exits. Now you can see what the network does when the path to Earth changes underneath it.
Change the routing to offline path computation and the question changes again. Not because the satellites moved differently. Because the router stopped discovering the future one failure at a time and started receiving a plan made from geometry it could already know.
That last argument belongs later. For now, the important thing is the separation.
The sky draws the graph first. The network lives inside it. NodalArc exists to keep those facts in the right order.
post 003 (The Future Is Computable) starts the engine. The primitives become position, position becomes visibility, and visibility becomes the carrier events the router actually sees.