Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF)
draft-luan-rtgwg-sdaf-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shenshen Luan , Wenting Wei , Mingliang Ke , Hou Dongxu , Xiao Min | ||
| Last updated | 2026-06-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-luan-rtgwg-sdaf-01
rtgwg S. Luan
Internet-Draft Beihang University
Intended status: Informational W. Wei
Expires: 8 December 2026 M. Ke
Xidian University
D. Hou
M. Xiao
ZTE Corporation
6 June 2026
Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO
Satellite Networks (SDAF)
draft-luan-rtgwg-sdaf-01
Abstract
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.
Luan, et al. Expires 8 December 2026 [Page 1]
Internet-Draft SDAF for LEO June 2026
Status of This Memo
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 8 December 2026.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Onboard Characteristics of Satellite Networks . . . . 3
1.1.2. Inherent Deficiencies of Asynchronous Convergence . . 4
1.1.3. Limitations of Existing Approaches . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Document Structure . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Core Principles . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Enforcing Routing Paths via Rotational Symmetry . . . . . 7
3.2. Forming Forward/Reverse Flows via Reflectional
Symmetry . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 9
4.1. Initialization . . . . . . . . . . . . . . . . . . . . . 9
Luan, et al. Expires 8 December 2026 [Page 2]
Internet-Draft SDAF for LEO June 2026
4.2. Failure/Disruption Detection . . . . . . . . . . . . . . 11
4.3. Reverse-Flow Triggering . . . . . . . . . . . . . . . . . 11
4.3.1. RF-CF Policy . . . . . . . . . . . . . . . . . . . . 11
4.3.2. RF-LF Policy . . . . . . . . . . . . . . . . . . . . 11
4.4. Reverse-Flow Forwarding and Transition . . . . . . . . . 12
4.5. Recovery from Failures/Disruptions . . . . . . . . . . . 12
5. Failure Scenario Handling . . . . . . . . . . . . . . . . . . 13
5.1. Single-Link Failure . . . . . . . . . . . . . . . . . . . 13
5.2. Boundary Conditions and Limitations . . . . . . . . . . . 14
6. Interoperability with Existing Protocols and Technologies . . 15
7. Key Characteristics . . . . . . . . . . . . . . . . . . . . . 15
7.1. Core Advantages . . . . . . . . . . . . . . . . . . . . . 15
7.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16
Revision History . . . . . . . . . . . . . . . . . . . . . . . . 16
Changes from draft-luan-rtgwg-sdaf-00 to
draft-luan-rtgwg-sdaf-01 . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
1.1. Problem Statement
1.1.1. Onboard Characteristics of Satellite Networks
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
Luan, et al. Expires 8 December 2026 [Page 3]
Internet-Draft SDAF for LEO June 2026
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.
1.1.2. Inherent Deficiencies of Asynchronous Convergence
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.
1.1.3. Limitations of Existing Approaches
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.
Luan, et al. Expires 8 December 2026 [Page 4]
Internet-Draft SDAF for LEO June 2026
* 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.
1.2. 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.
1.3. Scope
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).
1.4. Document Structure
This document is organized as follows:
* Section 2 defines key terms and abbreviations.
* Section 3 describes the core principles of *SDAF*.
Luan, et al. Expires 8 December 2026 [Page 5]
Internet-Draft SDAF for LEO June 2026
* 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.
* Section 8 discusses security considerations.
* Section 9 provides *IANA* considerations.
2. Terminology
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.
Luan, et al. Expires 8 December 2026 [Page 6]
Internet-Draft SDAF for LEO June 2026
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.
3. Core Principles
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.
3.1. Enforcing Routing Paths via Rotational Symmetry
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
Luan, et al. Expires 8 December 2026 [Page 7]
Internet-Draft SDAF for LEO June 2026
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.
3.2. Forming Forward/Reverse Flows via Reflectional Symmetry
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.
Luan, et al. Expires 8 December 2026 [Page 8]
Internet-Draft SDAF for LEO June 2026
4. Detailed Procedures
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.
4.1. Initialization
Before forwarding any data packets, each satellite node completes
three node-local configuration and preparation steps. These steps
are performed locally and do not depend on the number of destinations
or on real-time control-plane convergence.
1. Configure the Interface Symmetry Mapping Table (ISMT): Each node
locally provisions an ISMT according to its physical interface
geometry and the toroidal topology. The ISMT maps each local PEI
to its corresponding CFI and LFI candidate set. Table: Example
node-local Interface Symmetry Mapping Table (ISMT) for a four-
interface toroidal node.
+===========+=====+===================+=====================+
| Local PEI | CFI | LFI Candidate Set | LFI Selection Order |
+===========+=====+===================+=====================+
| if0 | if1 | {if2, if3} | if2, then if3 |
+-----------+-----+-------------------+---------------------+
| if1 | if0 | {if2, if3} | if2, then if3 |
+-----------+-----+-------------------+---------------------+
| if2 | if3 | {if0, if1} | if0, then if1 |
+-----------+-----+-------------------+---------------------+
| if3 | if2 | {if0, if1} | if0, then if1 |
+-----------+-----+-------------------+---------------------+
Table 1
The ISMT is static during normal operation. It may be pre-
provisioned by the management plane, derived from local interface
geometry, or installed together with the forwarding configuration.
Since the ISMT is indexed only by local interfaces, its size depends
on the number of local ISL interfaces rather than on the number of
network destinations.
1. Configure the Reverse-Flow Policy: Each node selects one of two
mutually exclusive reverse-flow policies, RF-CF or RF-LF.
All nodes in the network MUST maintain consistent policy
selection.
Luan, et al. Expires 8 December 2026 [Page 9]
Internet-Draft SDAF for LEO June 2026
2. Initialize the Local Interface Status Table (LIST) and Link-State
Detection (LSD): Each node maintains one LIST entry for every
local ISL interface. The LIST records both unplanned failures
detected by LSD and planned interruptions notified by the control
plane. Table: Local Interface Status Table (LIST) availability
semantics.
+=========+==============+==============+==========================+
| Failure | Interruption | LIST | Forwarding Meaning |
| State | State | Availability | |
+=========+==============+==============+==========================+
| 0 | 0 | Available | The interface can be |
| | | | selected for forwarding. |
+---------+--------------+--------------+--------------------------+
| 1 | 0 | Unavailable | The interface is |
| | | | excluded due to failure. |
+---------+--------------+--------------+--------------------------+
| 0 | 1 | Unavailable | The interface is |
| | | | excluded due to |
| | | | scheduled interruption. |
+---------+--------------+--------------+--------------------------+
| 1 | 1 | Unavailable | The interface is |
| | | | excluded due to both |
| | | | conditions. |
+---------+--------------+--------------+--------------------------+
Table 2
For each local interface if_k, the LIST maintains two input states: a
failure state F_k and an interruption state I_k. The derived
availability state is computed as follows:
Available(if_k) = (F_k == 0) AND (I_k == 0)
The forwarding plane consults the LIST before selecting any PEI, CFI,
or LFI. Therefore, SDAF can be implemented as a deterministic local
table-lookup procedure in which unavailable interfaces are excluded
before a forwarding or detour interface is selected.
This design requires only two node-local data structures: the ISMT,
which provides symmetric candidate interfaces, and the LIST, which
filters out unavailable interfaces. As a result, the forwarding
plane can make a local recovery decision without waiting for global
control-plane synchronization.
Luan, et al. Expires 8 December 2026 [Page 10]
Internet-Draft SDAF for LEO June 2026
4.2. Failure/Disruption Detection
During operation, the LIST is updated whenever a local interface
satisfies either of the following conditions:
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.
4.3. Reverse-Flow Triggering
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.
4.3.1. RF-CF Policy
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.
4.3.2. RF-LF Policy
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:
* If the CFI is available, the packet is forwarded through the CFI.
Luan, et al. Expires 8 December 2026 [Page 11]
Internet-Draft SDAF for LEO June 2026
* If the CFI is also unavailable, the node is considered isolated,
and the packet is dropped by default.
4.4. Reverse-Flow Forwarding and Transition
Upon receiving a data packet forwarded from another satellite node,
any node processes it according to the following logic:
1. Record the ingress interface and consult the local forwarding
table to determine the PEI associated with the packet's
destination.
2. 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.
* If the packet belongs to a forward flow, this step constitutes
normal forwarding.
* If the packet belongs to a reverse flow, the current node acts
as a PTP, where the reverse flow is converted back into a
forward flow.
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.
4.5. Recovery from Failures/Disruptions
The local interface status table marks an interface as "available"
when the terminal on a satellite link satisfies either of the
following conditions:
Luan, et al. Expires 8 December 2026 [Page 12]
Internet-Draft SDAF for LEO June 2026
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.
5. Failure Scenario Handling
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.
5.1. Single-Link Failure
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
Luan, et al. Expires 8 December 2026 [Page 13]
Internet-Draft SDAF for LEO June 2026
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
Figure 1: Example reverse-flow forwarding and phase transition
(numbered steps are illustrative).
5.2. Boundary Conditions and Limitations
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.
Luan, et al. Expires 8 December 2026 [Page 14]
Internet-Draft SDAF for LEO June 2026
6. Interoperability with Existing Protocols and Technologies
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.
7. Key Characteristics
7.1. Core Advantages
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.
7.2. Limitations
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.
8. Security Considerations
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:
Luan, et al. Expires 8 December 2026 [Page 15]
Internet-Draft SDAF for LEO June 2026
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.
9. IANA Considerations
This document has no IANA actions.
10. Normative References
[RFC9717] Li, T., "A Routing Architecture for Satellite Networks",
RFC 9717, DOI 10.17487/RFC9717, January 2025,
<https://www.rfc-editor.org/info/rfc9717>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Revision History
RFC Editor: Please remove this section before publication.
Changes from draft-luan-rtgwg-sdaf-00 to draft-luan-rtgwg-sdaf-01
* Expanded the SDAF initialization procedure to describe the node-
local configuration steps more explicitly.
* Added an example Interface Symmetry Mapping Table (ISMT) for a
four-interface toroidal node.
Luan, et al. Expires 8 December 2026 [Page 16]
Internet-Draft SDAF for LEO June 2026
* Added Local Interface Status Table (LIST) availability semantics
covering failure and scheduled-interruption states.
* Added the derived interface-availability rule used by the
forwarding plane.
* Clarified that SDAF forwarding decisions can be implemented as
deterministic node-local table-lookup procedures based on ISMT and
LIST.
* Updated author metadata, including the email address for Mingliang
Ke and the English name formats for Dongxu Hou and Min Xiao.
Acknowledgments
The authors would like to thank colleagues and reviewers for their
valuable feedback.
Contributors
None.
Authors' Addresses
Shenshen Luan
Beihang University
Email: luanshenshen@buaa.edu.cn
Wenting Wei
Xidian University
Email: wtwei@xidian.edu.cn
Mingliang Ke
Xidian University
Email: mingliang.ke@stu.xidian.edu.cn
Dongxu Hou
ZTE Corporation
Email: hou.dongxu@zte.com.cn
Min Xiao
ZTE Corporation
Email: xiao.min2@zte.com.cn
Luan, et al. Expires 8 December 2026 [Page 17]