| Internet-Draft | SDAF for LEO | February 2026 |
| Luan, et al. | Expires 29 August 2026 | [Page] |
Interior Gateway Protocols (IGPs) such as OSPF are commonly employed in satellite networks to address topology awareness and autonomous routing in response to link interruptions, link/node failures, and subsequent repairs. However, IGP-based approaches suffer from inherent limitations. Synchronization delays between the control plane and the forwarding plane can cause routing black holes, while asynchronous convergence across nodes may induce micro-loops (as described in prior work), leading to packet loss and congestion. These issues are particularly exacerbated in satellite networks characterized by highly dynamic topologies, long inter-satellite propagation delays, and constrained on-board computing resources.¶
This document describes the Symmetry-Driven Asynchronous Forwarding (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal topologies in satellite networks. Low Earth Orbit (LEO) satellite constellations are typically composed of multiple circular orbital planes, forming a toroidal topology by inter-satellite links. SDAF autonomously triggers and processes reverse flows based solely on local link-state information, without requiring control-plane convergence, protocol extensions, or packet header modifications.¶
SDAF is fully compatible with existing protocols and technologies such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the resource-constrained nature of satellite systems. It achieves microsecond-scale convergence and low packet loss under failure conditions.¶
Simulation results and tests conducted on actual satellite routers demonstrate that the SDAF mechanism significantly suppresses packet loss caused by routing black holes and micro-loops, while also alleviating link congestion and packet reordering issues.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The onboard characteristics of satellite networks severely limit the applicability of conventional IGP routing approaches.¶
Highly Dynamic Topology: In LEO constellations, inter-satellite links (ISLs) undergo frequent disruptions due to orbital motion and scheduled maneuvers such as solar avoidance -- representing predictable dynamics. Additionally, unpredictable events like radiation-induced node or link failures introduce stochastic topology changes. These continuous alterations constantly reshape the network topology, triggering repeated routing convergence processes that result in significant performance degradation, including packet loss, congestion, and reordering. Traditional IGP schemes are designed for relatively stable topologies with sporadic failures and are inherently ill-suited to cope with the persistent and rapid dynamics inherent in LEO satellite networks.¶
Stringent Resource Constraints: Satellite payloads operate under strict environmental limitations -- weight, power consumption, and thermal dissipation -- which directly constrain onboard computing resources. Compared to terrestrial routers, satellite routers typically offer an order-of-magnitude lower CPU processing capability, only 1/10 to 1/5 of the memory capacity, and rely on limited solar-powered energy supply. These constraints make it impractical to run high-overhead protocols or sustain intensive, continuous computations. Conventional IGP approaches, however, require frequent topology flooding and repeated FIB updates to track dynamic changes -- generating substantial control-plane signaling traffic that consumes precious inter-satellite bandwidth and imposes unsustainable computational loads on resource-constrained satellite platforms.¶
The asynchronous convergence mechanism inherent in link-state IGP routing suffers significantly amplified negative effects in the context of satellite networks' highly dynamic topologies and stringent resource constraints, directly giving rise to three core issues that undermine forwarding continuity and reliability:¶
Micro-loops: Asynchronous updates across nodes -- caused by control-plane synchronization delays such as IGP flooding and FIB installation -- lead to transient forwarding inconsistencies, resulting in micro-loops [RFC5715]. In satellite networks, the combination of high topology dynamics and long inter-satellite propagation delays dramatically extends both the duration and spatial scope of these micro-loops, exacerbating packet loss and congestion.¶
Routing Black Holes: Upon sudden link or node failures, the control plane relies on mechanisms like Hello timeouts (typically >= 1 second) and subsequent SPF (Shortest Path First) computations (tens to hundreds of milliseconds) -- processes that cannot be accelerated due to onboard resource limitations. Consequently, routers retain stale FIB entries for extended periods, causing sustained packet drops and forming persistent routing black holes that are difficult to recover from promptly.¶
Current loop-free convergence schemes (e.g., TI-LFA, SPRING) were not designed for satellite-specific constraints and thus fail to address the above issues:¶
They assume topological stability and are ill-suited for the frequent, constant topology fluctuations in LEO constellations. Repeated path precomputation, control-plane flooding, and FIB updates result in convergence delays far exceeding millisecond-scale requirements while increasing microloop risk.¶
They incur significant protocol overhead through extensions (e.g., modified routing messages, new header fields) or continuous complex computation (e.g., global path planning, multiple backup paths). Such overhead exceeds the computational, memory, and bandwidth budgets of satellite payloads, rendering these solutions impractical.¶
To achieve global coverage and efficient packet forwarding, LEO satellite constellations commonly adopt torus-like topologies, constructing the network through symmetric intra-orbit and inter-orbit inter-satellite links. Such architectures exhibit high rotational symmetry and a regular, grid-like distribution of inter-satellite links (often referred to as Grid+ topology). This inherent structural regularity serves as a natural advantage for mitigating the adverse effects of topological dynamics. Building on this foundation, this document proposes the SDAF mechanism. The core idea of SDAF is to leverage the intrinsic symmetry of toroidal topologies to alleviate the convergence pressure imposed by frequent topological changes, thereby reducing reliance on control-plane coordination. SDAF enhances the resilience and reliability of packet forwarding in dynamic satellite networks.¶
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.¶
This document specifies the core design principles, forwarding decision procedures, LSD methodology, and integration approaches of the SDAF mechanism with link-state routing protocols (e.g., OSPFv3, IS-IS) and MPLS label switching. It does not cover: hardware implementation details of SDAF, specific satellite payload hardware selection criteria, or extension schemes for non-toroidal topologies (which will be addressed in future documents).¶
This document is organized as follows:¶
Section 4 specifies the end-to-end procedures for SDAF operation.¶
Section 5 discusses failure scenario handling, including single-link, multi-link, and node failures.¶
Section 6 describes interoperability with OSPFv3, IS-IS, and MPLS.¶
Section 7 summarizes key characteristics, including advantages and limitations.¶
Full topology: The complete, fault-free topology of the satellite network.¶
Defective topology: The connected subgraph of the full topology after a failure or disruption.¶
Planned disruption: A predictable, temporary unavailability of an ISL due to orbital motion or solar avoidance.¶
Unplanned failure: An unpredictable outage of an ISL or node due to internal or external factors.¶
Link-State Detection (LSD): A local mechanism for detecting ISL disruptions or failures, with low-latency requirements.¶
Hop Distance (HD): The number of hops on the shortest path between source and destination.¶
Forward Flow (FF): Data forwarding along the shortest path, following decreasing Hop Distance (HD).¶
Reverse Flow (RF): A temporary forwarding state triggered by failure, propagating opposite to FF with increasing HD.¶
Primary Egress Interface (PEI): The egress ISL selected by the shortest-path algorithm for FF.¶
Counter-facing Interface (CFI): The ISL diametrically opposite to the PEI within the toroidal topology.¶
Lateral-facing Interface (LFI): The ISL orthogonal to the PEI; if multiple exist, the lowest-indexed is used.¶
Interface Symmetry Mapping Table (ISMT): A node-local table mapping each PEI to its corresponding CFI and LFI.¶
Local Interface Status Table (LIST): A node-local array recording the availability status of each interface.¶
Phase (P): A logical indicator of flow direction: positive for FF, negative for RF.¶
Phase Transition Point (PTP): A node where RF transitions back to FF, identified by the ingress interface not being equal to the local PEI.¶
Reverse Flow with Counter-facing priority (RF-CF): An RF strategy prioritizing the CFI upon PEI failure.¶
Reverse Flow with Lateral-facing priority (RF-LF): An RF strategy prioritizing the LFI upon PEI failure.¶
The SDAF mechanism leverages the rotational and reflectional symmetries inherent in toroidal topologies to enable autonomous forwarding-plane decisions, thereby addressing the core deficiencies of traditional routing under dynamic topologies and resource constraints.¶
In a ring topology -- a simplified special case of the toroidal topology -- satellite nodes are interconnected via intra-orbit ISL to form a closed loop, exhibiting 360 degrees rotational invariance. For example, the intra-orbital routing domains defined in [RFC9717] inherently constitute such ring structures within each orbital plane. When a satellite node's PEI becomes unavailable due to failure or scheduled interruption, rotational symmetry strictly constrains the only feasible detour to the CFI. This constraint is not unique to SDAF. The IGP routing will inevitably select the CFI, as the symmetry of the ring guarantees it is the sole valid route to the destination.¶
When extended to a two-dimensional toroidal topology -- the typical architecture of multi-orbit LEO satellite constellations -- rotational symmetry exhibits dual-dimensional characteristics. Both the intra-orbit direction and the inter-orbit direction possess rotational invariance. This dual-axis symmetry not only retains the CFI constraint from the one-dimensional ring case but also introduces LFIs to the PEI. Under this structure, a node can determine its CFI and LFI solely through local knowledge of interface positions and their symmetric mappings in the intra- and inter-orbit dimensions, without requiring global topology computation. Provided the network remains connected, both CFI- and LFI-based detours are guaranteed by the topological symmetry to reach the destination, ensuring that all locally selected recovery paths strictly adhere to the natural routing constraints imposed by the constellation's geometric regularity.¶
In a fault-free full topology, all shortest paths from any source node to a common destination are symmetric with respect to the mirror plane defined by the "destination node-topology center" axis. Moreover, these shortest paths always propagate along the minor arc -- the shorter segment between two points on the toroidal topology -- which aligns with the core objective of shortest-path-first routing and constitutes the forward flow.¶
When the PEI becomes unavailable due to failure or scheduled interruption, the forwarding plane autonomously selects either the CFI or a LFI based on the preconfigured policy (RF-CF or RF-LF) to forward packets before the control plane completes reconvergence. At this point, the forwarding path deviates from the minor arc and enters the major arc, propagating in the direction opposite to the original shortest path. Consequently, the HD to the destination no longer decreases but instead increases, forming a RF that is directionally opposed to the forward flow.¶
Due to the constraint of reflection symmetry, once a reverse-flow packet crosses the mirror plane and re-enters the minor-arc region, it inevitably arrives at a PTP. Here, the reflection symmetry inherently triggers an automatic switch in forwarding logic. The packet ceases to propagate as a reverse flow along the major arc and instead transitions back to a forward flow along the minor arc, resuming adherence to the shortest-path-first routing strategy and continuing toward the destination. This bidirectional flow transition occurs entirely without control-plane intervention, driven solely by topological reflection symmetry and local forwarding decisions, thereby ensuring continuous and reliable data delivery.¶
All procedures of the SDAF mechanism are executed locally within the forwarding plane without requiring inter-node coordination. The core process consists of five steps: initialization, fault/interruption detection, reverse-flow triggering, reverse-flow forwarding and convergence, and fault/interruption recovery.¶
Before forwarding any data packets, each satellite node needs only to complete three local configuration and preparation steps. The configuration logic depends on the number of node interfaces but is independent of the number of destinations:¶
Configure Interface Symmetry Mapping Table: Based on the complete physical topology connectivity, a static interface symmetry mapping table is preconfigured locally at each node for every physical interface.¶
Configure Reverse-Flow Policy: Choose one of two mutually exclusive policies of RF-CF or RF-LF.¶
All nodes in the network MUST maintain consistent policy selection.¶
Initialize Link-State Detection (LSD): Enable the LSD mechanism, such as heartbeat packets or physical-layer signal monitoring, on all inter-satellite link (ISL) interfaces.¶
B
|
CLI:2 | CLI:3
FLI:1,3 | FLI:2,4
|
4 | 1
E -------A------- C
3 | 2
|
CLI:1 | CLI:4
FLI:2,4 | FLI:1,3
|
D
When a terminal on a satellite link meets either of the following conditions, the local interface status table is triggered to mark the corresponding interface as "unavailable":¶
Failure: The Link-State Detection (LSD) mechanism detects that an interface has gone down or that its forwarding quality falls below the required threshold.¶
Scheduled Interruption: The pre-provisioned interruption schedule from the control plane indicates that the current time has reached the designated moment for deactivating the interface.¶
When an interface is marked as "unavailable," any data packet that, according to the forwarding table, would egress through that interface as its PEI immediately triggers the reverse-flow mechanism. This occurs without waiting for the control plane to synchronize link-state updates or complete network-wide reconvergence. The execution logic for the two reverse-flow policies is as follows.¶
The node first checks its local interface status table to determine whether the CFI is available:¶
If the CFI is available, the packet is immediately forwarded through the CFI, thereby initiating a reverse flow.¶
If the CFI is unavailable, the node inspects the two LFIs in the preconfigured order and selects the first available LFI for forwarding.¶
If neither the CFI nor any LFI is available, the node is considered isolated, and the packet is dropped by default.¶
The node first checks its local interface status table in the preconfigured order to determine the availability of the two LFIs and selects the first available LFI to forward the packet, thereby initiating a reverse flow.¶
If both LFIs are unavailable, the node then checks the availability of the CFI:¶
Upon receiving a data packet forwarded from another satellite node, any node processes it according to the following logic:¶
Record the ingress interface and consult the local forwarding table to determine the PEI associated with the packet's destination.¶
Compare the ingress interface with the local PEI:¶
Case (1): Ingress interface matches the local PEI¶
The receiving node identifies the packet as part of a reverse flow. It then executes the reverse-flow handling procedure specified in Section 4.3.1 or Section 4.3.2, based on its preconfigured reverse-flow strategy.¶
Case (2): Ingress interface differs from the local PEI¶
The node forwards the packet via its local PEI.¶
Once a reverse flow is converted to a forward flow at a PTP, the packet proceeds toward its destination using standard forward-path forwarding logic. However, if a link failure or scheduled interruption occurs along this newly established forward path, the reverse-flow mechanism is triggered again locally. This cycle of forward-reverse flow switching continues iteratively until either the packet successfully reaches its destination or the hop count exceeds a predefined limit, at which point the packet is discarded.¶
The local interface status table marks an interface as "available" when the terminal on a satellite link satisfies either of the following conditions:¶
Failure Recovery: The Link-State Detection (LSD) mechanism detects that a previously failed interface has come back up or that its forwarding quality has returned to an acceptable level.¶
Scheduled Interruption Recovery: According to the interruption schedule pre-provisioned by the control plane, the current time reaches the designated moment for restoring the interface.¶
Once the local interface status is updated to "available", the following actions are performed:¶
Newly arriving packets whose destination maps to this interface as the PEI are immediately forwarded through it using the standard forward-flow logic.¶
In-flight reverse-flow packets, which were already en route before the recovery, continue unchanged until they reach a PTP, where they revert to forward flow as originally planned. This ensures continuity and avoids mid-path disruption, even before the control plane completes any associated reconvergence triggered by the recovery event.¶
The SDAF mechanism is specifically designed for typical failure and scheduled interruption scenarios in LEO satellite networks with toroidal topologies. All considered scenarios operate under the fundamental assumption that the impaired topology remains a connected subgraph of the full physical topology. In cases where the topology becomes partitioned (i.e., splits into disconnected components), the mechanism, like conventional loop-free convergence schemes such as [RFC5715] , cannot guarantee reachability or path restoration.¶
This section explicitly defines, for each failure scenario, the triggering conditions of the SDAF mechanism, the applicable reverse-flow policy selection, and the core reliability guarantees provided by the design.¶
The single-link failure scenario applies to unpredictable failures or predictable interruptions affecting a single intra-orbit or inter-orbit ISL, under the condition that the toroidal or torus-like topology remains connected and both endpoints of the failed link retain at least one available symmetric interface. Upon detecting the failure via LSD or receiving a scheduled interruption notification from the control plane, each endpoint marks the corresponding PEI as "unavailable" and immediately triggers a reverse flow according to its preconfigured policy, rerouting traffic to bypass the faulty link. Reverse-flow packets automatically switch back to forward flow at the nearest PTP, achieving loop-free convergence. For intra-orbit link failures or ring-like topologies, RF-CF is preferred to leverage symmetric intra-orbit paths for rapid detour. For inter-orbit link failures or when inter-orbit resources are sufficient, RF-LF is favored to avoid latency accumulation from intra-orbit looping. Overall, this approach ensures micro-loop-free rerouting strictly bounded by topological symmetry and enables millisecond-scale, control-plane-independent data-plane recovery with minimal packet loss. As shown in the figure below.¶
(1)
<---- A_1 A_2
---------A---------
| ----> ----> |
B_1| (4) (5) |G_2
B G
| B_2| ^ |G_1 |
(2)| | | (3) | |(6)
v C_1| | |F_2 v
C F
C_2| |F_1 |
X | |(7)
D_1| (8) |E_2 v
D <---- E
D_2 ------------------- E_1
The SDAF mechanism provides fault-handling capabilities only for "connected impaired topologies", that is, scenarios where the network remains a single connected component despite link or node failures. If the topology becomes partitioned into multiple disconnected subgraphs, SDAF cannot construct valid end-to-end paths, and recovery must rely on higher-layer mechanisms such as routing protocol reconvergence.¶
For predictable interruption scenarios (e.g., scheduled maintenance, orbital maneuvers), the handling logic is identical to that of equivalent failure types, with the sole difference lying in the failure detection phase. Instead of relying on LSD for real-time anomaly identification, nodes receive advance notifications from the control plane about the timing of the upcoming interruption.¶
The SDAF mechanism is independent of protocols and requires no modifications to existing IGP routing protocols (e.g., OSPFv3, IS-IS) or forwarding technologies (e.g., IP forwarding, MPLS) commonly used in LEO satellite networks.¶
Dynamic Topology Adaptation: By leveraging the symmetry of the toroidal topology, SDAF enables resilient forwarding in dynamic scenarios such as link outages or node failures, without waiting for control-plane convergence, thereby reducing packet loss through asynchronous forwarding.¶
Low Control-Plane Overhead: For link failures, forwarding decisions can be made solely based on local Link-State Detection and interface mapping tables, eliminating the need for control-plane flooding, SPF computation, or pre-planned path calculation, significantly reducing satellite resource consumption.¶
Microsecond-Level Convergence: In the event of a failure, path switching is rapidly triggered via locally initiated reverse flows, achieving convergence latency of less than 1 ms, significantly faster than the tens to hundreds of milliseconds required by traditional approaches.¶
Strong Protocol Compatibility: It can be directly integrated with link-state routing protocols such as OSPFv3 and IS-IS, as well as MPLS label forwarding, without requiring any modifications to protocol message formats or packet headers.¶
The limitations of SDAF stem from its core design principle of relying on the symmetry of the toroidal topology, specifically including ineffective forwarding in highly asymmetric scenarios and increased transmission latency due to non-shortest-path forwarding.¶
The SDAF mechanism inherits the security properties of existing LEO satellite communication protocols and introduces only a minimal additional attack surface. Below are the key security considerations for LEO satellite constellations with a toroidal topology:¶
Link-State Spoofing: An attacker could forge link-failure signals to trigger unauthorized reverse flows.¶
Mitigation: Link-State Detection (LSD) MUST rely on authenticated mechanisms at the physical or data link layer (e.g., frame checksums, signal characteristic verification) or leverage existing protocol authentication extensions (e.g., OSPFv3 authentication mechanisms [RFC4552]) to prevent false failure indications from triggering reverse flows.¶
This document has no IANA actions.¶
The authors would like to thank colleagues and reviewers for their valuable feedback.¶
None.¶