Link to the code: Zae-Project / arkspace-core

The IETF Wants to Give Mega-Constellations a Common Language

In March 1972, the first RFC describing the Domain Name System proposed that computers on the ARPANET should identify each other by human-readable names rather than numeric addresses. The proposal was not about network hardware or routing protocols. It was about notation. A common way to describe and address network nodes that every system on the network could interpret the same way.

The Internet Engineering Task Force published an Internet-Draft in March 2026 that occupies an analogous position for satellite constellation networks. The document proposes a standardized “code” for describing satellite constellation topology: the geometry, link structure, coverage patterns, and connectivity of large-scale satellite networks in a format that satellite operators, network engineers, and routing protocol designers can use interchangeably.

The proposal does not specify a new frequency band, a new satellite hardware standard, or a new launch regulation. It is a notation system. But notation systems shape what becomes buildable, and the absence of a common language for mega-constellation topology has been a concrete obstacle to the kind of multi-operator network coordination that satellite internet’s long-term trajectory requires.

Why Constellation Topology Is Difficult to Describe

A single satellite in a circular orbit is characterized by six orbital elements: semi-major axis, eccentricity, inclination, right ascension of the ascending node, argument of perigee, and true anomaly at a reference epoch. These are well-standardized in aerospace engineering and embedded in every satellite tracking system.

A constellation of thousands of satellites is not a collection of independently characterized orbits. It is a geometric structure, a pattern of orbital planes, spacing within planes, phase offsets between planes, and altitude stratification. The geometric structure determines the constellation’s coverage pattern and the topology of its inter-satellite link network at any given time.

Different operators use different internal notations to describe their constellations. SpaceX’s filings with the FCC describe Starlink’s orbital geometry in ways that are opaque to the software tools used by network engineers to model internet routing. Amazon’s Kuiper filings use a different parameterization. European and Chinese operators use their own conventions. The result is that modeling a multi-operator satellite network, which eventually overlapping constellations will require, demands custom translation layers between notations.

For academic researchers studying LEO mega-constellation interference and coexistence, this lack of standardization means their models cannot easily incorporate data from different operators’ public filings. For protocol developers designing routing solutions for satellite-based internet infrastructure, it means validation environments must be hand-crafted rather than generated from standard specifications.

What the IETF Draft Proposes

The Internet-Draft, authored by a working group including researchers from university networks labs and contributors affiliated with satellite connectivity standardization bodies, proposes a “Constellation Description Language” (CDL) that specifies a satellite constellation by a compact set of parameters.

The CDL specification covers:

Shell definition. Each orbital shell in a constellation is described by altitude, inclination, number of orbital planes, number of satellites per plane, and phase offset between planes (the “Walker Delta” or “Walker Star” parameter set extended to include CDL-specific notation for partial coverage and inclined plane configurations).

Inter-satellite link topology. For constellations operating optical or radio inter-satellite links, the CDL specifies the link pattern: which satellites maintain persistent links to which neighbors, the link generation and range specifications, and handoff protocols when links must be established or released as orbital geometry changes.

Ground station interaction parameters. CDL includes notation for the ground segment interface: minimum elevation angles for ground-station contact, frequency bands, and time-division parameters for shared ground station access in multi-operator environments.

Coverage tiles. A grid-based notation for describing the geographic coverage each shell provides as a function of time, enabling coverage continuity analysis without requiring full orbital propagation for every query.

The CDL is not a simulation language. It does not specify satellite propulsion, attitude control, or on-board processing. It describes the network topology that results from a constellation’s orbital configuration, at the level of abstraction useful for network protocol design and routing analysis.

The Protocol Design Problem CDL Addresses

The technical motivation for CDL is the routing protocol problem. The distributed AI coordination protocols being developed for satellite task allocation operate at the application layer. Below them, packets must be routed through a network whose topology changes on timescales of seconds as satellites move and link eligibility changes.

Terrestrial internet routing protocols, including OSPF and BGP, were designed for networks with stable topology or topology that changes slowly enough for distributed convergence to occur before the topology changes again. LEO satellite networks have topology that changes continuously and deterministically. Every satellite moves approximately 7.8 km/s, and the inter-satellite link neighborhood of any given satellite changes on timescales comparable to the routing protocol convergence time of terrestrial systems.

This has motivated research into topology-aware routing protocols that exploit the predictable nature of orbital mechanics. Unlike terrestrial routing, where future topology is unknown, satellite constellation topology can be computed precisely decades in advance. A routing protocol that uses precomputed topology schedules rather than distributed topology discovery can avoid the convergence lag problem entirely.

Designing and benchmarking such protocols requires a common description of the constellation topology they operate over. Without CDL or an equivalent standard, every research group defines its own constellation model, and results are not directly comparable. The optical inter-satellite link technology being deployed in 2026 is specifically what CDL’s link topology notation is designed to describe, since OISL-equipped constellations have the most complex and operationally significant inter-satellite link topology.

Connection to Existing Standardization Efforts

The IETF draft does not appear in isolation. It connects to several existing standardization tracks.

The 3GPP standards body, which sets technical specifications for 5G and emerging 6G mobile networks, includes a Non-Terrestrial Networks (NTN) working group that has developed specifications for integrating satellite links into cellular network architecture. The satellite-to-cellular roaming technologies demonstrated at MWC 2026 implement 3GPP NTN Release 17 and 18 standards. CDL’s coverage tile notation is designed to be compatible with 3GPP NTN’s satellite position reporting conventions, enabling NTN implementations to ingest CDL-described constellations without translation.

The CCSDS (Consultative Committee for Space Data Systems), which standardizes communication protocols for space missions, has developed Bundle Protocol extensions for disruption-tolerant networking in space environments. CDL’s contact window notation aligns with CCSDS’s Contact Graph Routing approach, which represents communication opportunities as a graph of timed contacts. This alignment enables integrated design tools that span from constellation orbital geometry through CCSDS routing to application-layer protocols.

The ITU’s Radio Regulations, which govern frequency coordination between satellite operators, require operators to file detailed constellation descriptions that include coverage and orbital parameters. CDL’s shell description format is designed to be derivable from ITU filing formats, enabling automatic CDL generation from regulatory filings. This would allow the multi-operator topology modeling that is currently impractical to become semi-automated as operators accumulate CDL-formatted descriptions.

Implications for Distributed Orbital Computing

The ArkSpace constellation concept described in the project’s foundational documentation envisions a satellite network that functions as a distributed neural computing substrate. The network layer of such a system, the protocols that route computation tasks, data streams, and state synchronization traffic between nodes, depends critically on an accurate and efficiently queryable description of the network topology.

CDL provides the topology description layer that distributed orbital computing protocols need. A computation scheduler that must decide which satellite processes which data segment, routing the data there and returning results within available contact windows, needs to query constellation topology efficiently. With CDL, that query is a geometric computation on a standard data structure. Without it, the scheduler must maintain a proprietary topology model that is not interoperable with other constellation operators or with ground infrastructure that uses different constellation descriptions.

The Starcloud orbital AI training architecture and the distributed satellite coordination protocols developed in 2026 both represent application-layer solutions that assume some underlying network layer. CDL addresses the gap between orbital geometry and the routing and scheduling protocols that operate over it.

From Draft to Standard

Internet-Drafts have a six-month expiration cycle and must be renewed and revised to advance toward IETF Requests for Comments status. The CDL draft’s path to standardization depends on adoption by at least two independent implementations and the formation of a working group within the IETF’s Routing Area or a relevant satellite networking directorate.

The practical timeline for CDL to reach RFC status is typically 2-4 years from initial draft. Early adoption by satellite operators and simulation tool developers can accelerate this. The draft’s alignment with 3GPP NTN and CCSDS creates natural institutional support from standards bodies that are already engaged with satellite network engineering.

The potential significance of the standard is disproportionate to its technical scope. Standards that provide common notation for complex systems unlock collaboration and tooling investment that would not occur without them. The IP addressing system did not itself connect computers; it gave engineers a common way to describe connections, and the tools and protocols built on that notation are what the internet became.

CDL does not route packets through satellite constellations. It gives engineers a common way to describe the topologies that routing protocols operate on. Whether the orbital networking ecosystem that builds on that notation reaches IP-scale significance depends on whether the constellation growth trajectory of the late 2020s and 2030s produces a satellite network that needs internet-comparable routing sophistication. Current indications are that it will.

Path Forward

The 2026 LEO constellation race among Logos Space, Starlink, and Kuiper is adding thousands of satellites per year to an orbital environment that lacks the standardized topology description infrastructure that would make multi-operator coordination tractable. CDL represents an early attempt to build that infrastructure at the notation level, before the operational pressure to resolve interoperability at scale becomes acute.

The IETF draft process is slow by design. It forces the kind of broad review and iterative refinement that produces durable standards. For a notation system that will, if successful, be embedded in satellite constellation design tools, routing protocol implementations, and regulatory filing workflows for decades, that deliberate pace is appropriate.

The question for satellite network engineers in 2026 is whether to adopt CDL-like notation in tooling and protocol work now, before the standard is finalized, or to wait for the RFC. Early adoption builds the implementation experience that standards bodies look for. It also creates investment in the notation that may require revision as the standard evolves. The draft’s current status suggests the technical content is stable enough that early adoption risk is moderate.

Official Sources