Scenarios and Routing Requirements for Mega-Constellation LEO Satellite Networks

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Terminology

The following terms are defined for use in this document:¶

ISL (Inter-Satellite Link)

A link between two satellite nodes, specifically referring to vacuum photon transmission links realized via space laser communications in this document.¶

GS (Ground Station)

Terrestrial facilities responsible for connecting the space segment to land-based network infrastructures.¶

PoP (Point of Presence)

Interface points where the satellite network connects to the terrestrial Internet core.¶

Time-Variant Topology

The characteristic of LEO satellite networks where inter-satellite geometric relationships and link reachability change periodically, predictably, yet at high frequencies due to high-speed orbital dynamics.¶

3.1. Evolution toward Spaceborne Routing Networks

Traditional satellite communication systems have commonly relied on ground-centric architectures, in which satellites provide connectivity between user terminals and terrestrial gateways. In such deployments, traffic is typically delivered to an available ground station, while the terrestrial network performs most long-distance routing and transport functions.¶

However, the deployment of ground stations may be constrained by geographical conditions, regulatory requirements, and infrastructure costs. In regions with limited gateway availability, such as oceans, polar regions, and remote territories, relying primarily on terrestrial gateways may restrict the flexibility of end-to-end connectivity.¶

With the increasing availability of optical ISLs, satellite networks can support multi-hop packet forwarding across the space segment. Traffic entering the constellation through a satellite or ground gateway may traverse multiple ISLs before reaching a suitable egress gateway or another destination within the satellite network.¶

In this architecture, the space segment acts as a packet transport network rather than merely a relay between user terminals and nearby ground stations.¶

      Dense GS Era
   +---------------+
   |      GS       |
   +-------+-------+
           |
         SAT
           |
         UT
               |
               v


         ISL-Assisted Era

   GS ---- SAT ---- SAT
               \
                \
                 UT

                |
                v

 Spaceborne Routing Era

 UT -- SAT -- SAT -- SAT -- SAT
                            |
                           GS
                            |
                           PoP

For long-distance connections, optical ISLs may also provide propagation-delay advantages over certain terrestrial routes because of the higher speed of light in vacuum. However, actual end-to-end performance depends on satellite path geometry, forwarding delays, gateway locations, and the selected terrestrial Points of Presence (PoPs). Consequently, efficient routing and appropriate gateway selection remain important factors in determining overall network performance.¶

As satellite constellations increase in scale and support more complex traffic patterns, the routing system needs to maintain connectivity across highly dynamic ISLs while avoiding excessive control-plane overhead. These characteristics provide the technical context for the interoperability scenarios discussed below.¶

3.2. Multi-Vendor Interoperability within a LEO Constellation

Unlike a network built entirely around a single proprietary implementation, a large-scale LEO satellite constellation may involve equipment and network components supplied by multiple vendors. Satellite routers, ground gateways, and routing control systems may be developed by different manufacturers or introduced during different deployment phases.¶

For satellite network operators adopting such deployment models, interoperability among independently developed routing implementations is an important operational requirement. Equipment from different vendors may need to participate in a common routing system to provide consistent reachability and packet forwarding across the constellation.¶

           Single LEO Constellation
       (Illustrative Portion of the Network)

   ...       ...       ...       ...       ...       ...
    |         |         |         |         |         |
  [A01]-----[A02]-----[B01]-----[B02]-----[C01]-----[C02]
    |         |         |         |         |         |
  [A03]-----[B03]-----[B04]-----[C03]-----[A04]-----[C04]
    |         |         |         |         |         |
  [C05]-----[B05]-----[A05]-----[A06]-----[C06]-----[B06]
    |         |         |         |         |         |
  [B07]-----[C07]-----[A07]-----[C08]-----[B08]-----[A08]
    |         |         |         |         |         |
  [C09]-----[A09]-----[B09]-----[A10]-----[B10]-----[C10]
    |         |         |         |         |         |
   ...       ...       ...       ...       ...       ...

  Axx : Satellite Router supplied by Vendor A
  Bxx : Satellite Router supplied by Vendor B
  Cxx : Satellite Router supplied by Vendor C

  ----- / | : Inter-Satellite Links (ISLs)

  All routers participate in a common routing system.

This requirement becomes particularly relevant in large-scale constellations where routing decisions are affected by frequent topology changes. Different implementations need to exchange and interpret routing information consistently, including information related to link availability, routing reachability, and topology changes.¶

For example, when an ISL becomes unavailable or changes its adjacent peer, routers from different vendors may need to update their routing state and coordinate forwarding behavior to avoid persistent inconsistencies, routing loops, or unnecessary service disruption.¶

Furthermore, as a constellation expands or undergoes equipment upgrades, new satellite nodes and routing implementations may need to interoperate with existing deployments without requiring network-wide replacement or redesign.¶

These scenarios motivate the examination of common routing requirements, including interoperable routing information exchange, consistent handling of topology changes, and scalable routing-state management.¶

The objective is not to prescribe a particular routing algorithm or constellation-specific optimization strategy, but to identify routing behaviors and protocol interactions for which interoperability may be necessary.¶

3.3. Satellite-Terrestrial Network Interconnection

As satellite networks develop multi-hop transport capabilities, they may also serve as wide-area transport infrastructures connecting geographically separated terrestrial networks.¶

In such scenarios, a terrestrial network operator may use the transport capabilities of a satellite network operator to establish connectivity between remote regions or network sites. Traffic may enter the satellite network through a terrestrial gateway, traverse multiple satellite nodes and ISLs, and exit through another gateway connected to a remote terrestrial network.¶

Unlike conventional satellite access services, where the satellite system primarily connects individual users to the terrestrial Internet, this scenario treats the satellite constellation as a transport network supporting interconnection between independently operated terrestrial networks.¶

            Satellite Transport Network
             (Satellite Network Operator)

    +----------------------------------------------+
    |                                              |
    |  [SAT-1]---[SAT-2]---[SAT-3]---[SAT-4]       |
    |     |         |         |         |          |
    |  [SAT-5]---[SAT-6]---[SAT-7]---[SAT-8]       |
    |     |                             |          |
    |  Feeder Link                  Feeder Link    |
    |     |                             |          |
    |   [GW-A]                        [GW-B]       |
    +-----|-----------------------------|----------+
          |                             |
        [PE-A]                        [PE-B]
          |                             |
    +-----+----------+           +------+---------+
    |  Terrestrial   |           |  Terrestrial   |
    |   Network A    |           |   Network B    |
    +----------------+           +----------------+

    SAT-x : Satellite Router
    GW-x  : Satellite Network Ground Gateway
    PE-x  : Terrestrial Provider Edge Router
    ----- : Inter-Satellite Link (ISL)

Such deployments introduce routing considerations at the boundaries between terrestrial and satellite networks.¶

First, the satellite network needs to maintain reachability between ingress and egress gateways despite changes in its internal topology. The available satellite paths and gateway connectivity may vary over time due to orbital motion, planned ISL reconfiguration, or unexpected link failures.¶

Second, terrestrial and satellite networks may operate under different routing architectures and administrative policies. Interconnection therefore requires appropriate mechanisms to exchange reachability information while preserving the independence of their internal routing systems.¶

Third, changes in satellite gateway availability or internal transport connectivity may affect the reachability of remote terrestrial destinations. The routing system needs to handle such changes without unnecessarily propagating fine-grained satellite topology information into terrestrial networks.¶

Existing inter-domain routing protocols, such as BGP, can provide reachability exchange between independently administered networks. The routing considerations discussed here do not assume that these protocols need to be replaced. Instead, they motivate further examination of how dynamic satellite transport connectivity interacts with existing routing mechanisms, particularly in maintaining gateway reachability, path continuity, and scalable routing-state exchange.¶

3.4. Interconnection among Heterogeneous Satellite Constellations

Future space networks may involve multiple satellite constellations with different functions, orbital configurations, and operational characteristics. Examples include communication constellations, space-based computing systems, remote-sensing constellations, and other satellite systems requiring data transport services.¶

These systems may benefit from interconnection to support data exchange, shared transport infrastructure, and coordinated service delivery.¶

For example, a remote-sensing constellation may use a communication satellite network to transport collected data toward a ground processing center. Similarly, a space-based computing system may require connectivity to external satellite networks for data exchange or access to communication services.¶

Such interconnection may be realized through ground-based network gateways or, where technically and operationally feasible, through compatible inter-satellite links. Not all participating satellite systems are necessarily IP routing networks, and some may access the transport network through dedicated gateways.¶

         Heterogeneous Satellite Constellations

 +-----------------------+   +-----------------------+
 |     Remote-Sensing    |   |    Space Computing    |
 |      Constellation    |   |      Constellation    |
 |                       |   |                       |
 | [RS-1]---[RS-2]       |   | [CP-1]---[CP-2]       |
 |    |        |         |   |    |        |         |
 | [RS-3]---[RS-4]       |   | [CP-3]---[CP-4]       |
 |             |         |   |    |                  |
 |           [GW-R]      |   |  [GW-C]               |
 +-------------|---------+   +----|------------------+
               :                  :
               : Interconnection  :
               :                  :
 +-------------|------------------|------------------+
 |             |                  |                  |
 |  Communication Satellite Transport Network        |
 |                                                   |
 |  [SAT-1]---[SAT-2]---[SAT-3]---[SAT-4]            |
 |     |         |         |         |               |
 |  [SAT-5]---[SAT-6]---[SAT-7]---[SAT-8]            |
 |     |         |         |         |               |
 |  [SAT-9]---[SAT-10]--[SAT-11]--[SAT-12]           |
 |                          |                        |
 |                      [Ground GW]                  |
 +--------------------------|------------------------+
                            |
                    [Terrestrial Network]


 RS-x   : Remote-Sensing Satellite
 CP-x   : Space Computing Satellite
 SAT-x  : Communication Satellite Router
 GW-R/C : Interconnection Gateway
 -----  : Intra-Constellation Link
   :    : Logical Interconnection

Where independently administered satellite networks support packet-based routing, interconnection introduces requirements for exchanging reachability information across network boundaries while preserving routing-policy independence and limiting the exposure of internal topology information.¶

Different constellations may also exhibit substantially different link dynamics, connectivity patterns, and routing-state management mechanisms. Interconnection therefore needs to account for heterogeneous network characteristics without requiring all participating systems to adopt identical internal routing architectures.¶

Existing inter-domain routing mechanisms may support some of these requirements. For networks characterized by prolonged disconnections or store-and-forward communication, Delay-Tolerant Networking (DTN) mechanisms may also be applicable.¶

This document focuses on the routing requirements associated with packet-based satellite network interconnection. It does not assume that all satellite constellations require a common routing protocol or that their internal routing mechanisms need to be standardized.¶

3.5. Common Routing Implications

The scenarios described above involve different network boundaries and deployment models, but they share several routing considerations relevant to large-scale LEO satellite networks.¶

First, interoperability among independently developed routing implementations requires consistent interpretation and exchange of routing information. This includes reachability information, relevant topology changes, and other routing state needed to maintain forwarding connectivity. Such interoperability should not depend on identical internal routing algorithms or vendor-specific implementations.¶

Second, routing-state scalability becomes increasingly important as satellite constellations expand and interconnect with other networks. Frequent topology changes within a large constellation should not necessarily trigger network-wide routing updates or require all participating nodes and external networks to maintain complete, fine-grained topology information. Routing abstraction, aggregation, and controlled information propagation are therefore important architectural considerations.¶

Third, satellite routing needs to account for both predictable and unpredictable connectivity changes. Orbital dynamics and planned link schedules provide information that can be used to prepare for anticipated topology transitions. However, unexpected ISL disruptions, equipment failures, and link-quality variations require additional mechanisms to maintain reachability and limit the propagation of routing disturbances.¶

Fourth, interconnection with terrestrial networks and other satellite systems introduces the need to maintain connectivity across network boundaries. Internal topology changes should be handled without unnecessarily affecting external routing stability, while changes that affect inter-network reachability need to be communicated appropriately.¶

These considerations do not necessarily imply that entirely new routing protocols are required. Existing IETF routing protocols and mechanisms provide an important foundation for interoperable networking. However, their applicability and scalability under the combined conditions of large constellation size, highly dynamic topology, constrained onboard resources, and heterogeneous network interconnection require further examination.¶

The following sections analyze the limitations of network-wide routing convergence approaches and existing mitigation mechanisms, and identify routing requirements that may be relevant to interoperable LEO mega-constellation networks.¶

4.1. Conflict Between Global Consistency and Time-Variant Topologies

LEO satellites move at speeds greater than 27,000 km/h. Due to relative geometric changes, satellite attitude control, and optical pointing adjustment, inter-satellite link events, including link disruption and peer change, may occur on timescales ranging from seconds to minutes. A global link-state routing architecture relies heavily on multi-hop control-message flooding across the network to maintain a consistent link-state view. In a constellation with tens of thousands of nodes, the time required for control messages to propagate across the network may be significantly longer than the topology change interval. As a result, convergence may lag behind topology changes, and route computation may rely on stale views.¶

4.2. Control Plane Overhead Scaling with Network Size

When the number of constellation nodes reaches tens of thousands, the number of dynamic inter-satellite links also increases with the scale of the constellation. Any regular link up/down event may trigger network-wide flooding. The control plane would need to frequently encapsulate and transmit link-state advertisements, which may lead to excessive control-plane churn in the space segment. This can consume scarce inter-satellite control-channel resources and significantly reduce bandwidth available for user data traffic.¶

4.3. Engineering Challenges of Network-Wide Shortest-Path Convergence

In a highly dynamic satellite network, propagation delay and continuous topology changes make it difficult for all nodes to obtain a fully consistent and up-to-date topology view at the same time. Under such conditions, frequent attempts to achieve network-wide consistent shortest-path convergence may cause repeated computation, path oscillation, and forwarding instability, thereby affecting service continuity and reliability.¶

4.4. Mismatch between Network-Wide State Maintenance and On-Board Resource Constraints

Network-wide link-state routing requires participating nodes to maintain large-scale topology state and perform corresponding path computation. Compared with terrestrial equipment, on-board computing environments are constrained by power, thermal dissipation, storage, and radiation conditions. Requiring satellite nodes to maintain network-wide fine-grained state and frequently perform large-scale path computation would significantly increase operational burden and engineering risk.¶

5.1. Ground-Centric Architectures

Many existing broadband satellite systems minimize onboard routing complexity by relying heavily on terrestrial infrastructure. In such architectures, user traffic is forwarded to a visible satellite and subsequently delivered to a nearby Ground Station (GS) whenever possible. The terrestrial Internet then performs the majority of long-distance transport and routing functions. Inter-satellite links primarily serve as extensions of gateway reachability rather than as a fully autonomous spaceborne routing fabric.¶

This design offers significant operational advantages. Satellites are not required to maintain extensive routing state, route computation complexity remains low, and network management can leverage the mature capabilities of terrestrial infrastructure. The success of current commercial deployments demonstrates the practicality of this approach under conditions where sufficient gateway coverage is available.¶

However, the effectiveness of ground-centric architectures depends heavily on the availability of geographically distributed ground infrastructure. As future constellations expand service coverage to oceans, polar regions, remote territories, and long-distance intercontinental routes, traffic increasingly traverses multiple inter-satellite hops before reaching a gateway. In such scenarios, the space segment itself becomes an active routing network rather than a simple relay system. Routing efficiency within the satellite constellation directly influences end-to-end performance, making distributed spaceborne routing capabilities increasingly important.¶

5.2. Topology Abstraction Architecture Based on Orbital Domain Partitioning

To improve the scalability of large satellite networks, recent architectural proposals have introduced various forms of topology abstraction and hierarchical organization.[RFC9717] proposes a satellite network routing architecture based on existing routing protocols and mechanisms. Its core idea is to organize satellites in adjacent orbits into larger routing areas and to reduce topology visibility across area boundaries through area abstraction, thereby limiting the amount of link-state information distributed across the entire network.¶

        +------------------+
        |     Domain A     |
        |  SAT SAT SAT     |
        |  SAT SAT SAT     |
        +------------------+
                 |
           Abstract View
                 |
        +------------------+
        |     Domain B     |
        |  SAT SAT SAT     |
        |  SAT SAT SAT     |
        +------------------+

This architecture also uses the predictability of satellite orbital motion to introduce scheduled link-connectivity change information into the routing system. For predictable link disruption or topology adjustment, the routing system can obtain relevant information in advance and perform necessary routing adjustment before the actual change occurs, thereby reducing the impact of periodic topology changes on the control plane.¶

These approaches show that orbital domain partitioning, topology abstraction, and scheduled link awareness can effectively mitigate routing-state scaling issues in large-scale satellite networks. [RFC9717] focuses on providing a satellite network routing architecture based on existing routing protocols and forwarding mechanisms, and provides an important reference for subsequent routing-requirement analysis and protocol-mechanism design for LEO mega-constellations.¶

5.3. Remaining Challenges

Existing approaches have significantly advanced the operational capability of satellite networks and demonstrated practical methods for managing large constellations. In particular, these approaches often rely on assumptions of predictable topology evolution based on orbital mechanics and scheduled connectivity information, as well as hierarchical routing abstractions (e.g., backbone and non-backbone role separation) to improve scalability. However, such assumptions may not fully capture the stochastic nature of inter-satellite link dynamics or the homogeneous characteristics of satellite nodes in large-scale LEO constellations. As LEO mega-constellations evolve toward more autonomous satellite transport networks, several challenges remain that need to be considered in subsequent routing-requirement and protocol-design work.¶

First, routing-domain partitioning still depends on the link stability, orbital configuration, and connectivity characteristics of a specific constellation. How to determine routing areas that are stable, connected, and bounded in size under different constellation configurations and link conditions remains an open issue.¶

Second, scheduled topology changes can be handled in advance through scheduling information, but unplanned link failures remain unavoidable. The routing system still needs to maintain service continuity while limiting the impact scope, preventing local failures from evolving into large-scale control-plane disturbance.¶

Third, the routing protocol needs to clarify the propagation scope of state information, how scheduled changes and unplanned changes should be handled differently, what granularity of routing state satellite nodes should maintain, and how route computation should adapt to constrained on-board resources.¶

Fourth, the routing system needs to maintain cross-region reachability, path stability, and fast recovery without requiring a complete network-wide fine-grained topology view.¶

These remaining challenges motivate the routing requirements described in the next section.¶

6.1. Interoperable Routing Information Exchange

In a multi-vendor satellite network, routers and gateways from different vendors may run a common routing protocol. The protocol SHOULD support the exchange of routing information needed to maintain reachability, including destination reachability, link availability, and relevant topology changes.¶

The format and meaning of exchanged routing information SHOULD be clearly defined so that different implementations can process it consistently, including during scheduled topology changes and unexpected link failures. Interoperability SHOULD NOT require vendor-specific protocol extensions or control interfaces.¶

6.2. Scalable Routing-State Control

The routing protocol SHOULD support routing-state control in scenarios with tens of thousands of highly dynamic satellite nodes. The protocol SHOULD NOT require every satellite node to maintain a complete network-wide fine-grained topology view, and SHOULD NOT trigger network-wide link-state flooding due to local link changes.¶

Any link disruption triggered by local dynamics, such as polar-region traversal or minor attitude adjustment, SHOULD be handled preferentially within the affected routing area. Only when a local event affects cross-region reachability or critical forwarding capability SHOULD necessary abstracted state changes be advertised externally.¶

6.3. Awareness of Scheduled Topology Changes

Because satellite orbital mechanics are highly predictable, the routing protocol SHOULD incorporate time-varying connectivity plans distributed by the management plane. For predictable link disruption, link establishment, peer change, or bandwidth variation, the protocol SHOULD be able to receive and use the corresponding planning information.¶

The protocol SHOULD support necessary metric adjustment, path preparation, or forwarding-state update before scheduled topology changes occur, in order to reduce service interruption, packet loss, and control-plane instability.¶

6.4. Fast Recovery from Unplanned Failures

The routing protocol SHOULD be able to handle unplanned link failures and abrupt link-quality degradation. For sudden link failures, short-term loss of lock, equipment faults, or local congestion, the protocol SHOULD support fast detection, fast bypass, and local recovery.¶

The protocol SHOULD limit the impact of failures to a local scope and, when necessary, advertise only abstracted reachability changes externally.¶

6.5. Lightweight Forwarding State

A satellite node SHOULD NOT be required to maintain a complete global forwarding table containing massive terrestrial user prefixes or all constellation-node information. The protocol SHOULD support prefix aggregation, area abstraction, label forwarding, or other lightweight mechanisms to reduce satellite forwarding-state size.¶

The forwarding mechanism SHOULD adapt to the storage, computing, power, and reliability constraints of on-board equipment, and SHOULD support stable end-to-end forwarding within a limited forwarding-table size.¶

6.6. On-Board Autonomy with Ground Assistance

The routing protocol SHOULD support basic routing operation on satellite nodes in the absence of continuous ground control. Ground systems can provide constellation plans, policy configuration, and global optimization information. The satellite routing system SHOULD provide a certain level of autonomous operation capability to support sparse ground-station coverage, transoceanic and intercontinental relay, and long-distance inter-satellite multi-hop routing scenarios.¶

6.7. Inter-Network Reachability and Routing Isolation

When a LEO satellite network provides transport connectivity between terrestrial networks or connects to other packet-based satellite networks, the routing architecture SHOULD support the exchange of reachability information at network boundaries. This exchange SHOULD respect the routing policies of each network and SHOULD NOT require external networks to maintain detailed topology information about the satellite constellation.¶

When ISL failures, gateway changes, or internal path changes affect external reachability, the satellite network SHOULD update the relevant reachability information. Routing changes that do not affect external reachability SHOULD be handled within the satellite network to avoid unnecessary routing updates to other networks.¶

Existing inter-domain routing protocols may be used where applicable.¶