



rtgwg                                                            S. Luan
Internet-Draft                                        Beihang University
Intended status: Informational                                    W. Wei
Expires: 29 August 2026                                            M. Ke
                                                       Xidian University
                                                               H. Dongxu
                                                                  X. Min
                                                         ZTE Corporation
                                                        25 February 2026


   Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO
                       Satellite Networks (SDAF)
                        draft-luan-rtgwg-sdaf-00

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 29 August 2026                 [Page 1]

Internet-Draft                SDAF for LEO                 February 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 29 August 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 29 August 2026                 [Page 2]

Internet-Draft                SDAF for LEO                 February 2026


     4.2.  Failure/Disruption Detection  . . . . . . . . . . . . . .  10
     4.3.  Reverse-Flow Triggering . . . . . . . . . . . . . . . . .  10
       4.3.1.  RF-CF Policy  . . . . . . . . . . . . . . . . . . . .  10
       4.3.2.  RF-LF Policy  . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Reverse-Flow Forwarding and Transition  . . . . . . . . .  11
     4.5.  Recovery from Failures/Disruptions  . . . . . . . . . . .  11
   5.  Failure Scenario Handling . . . . . . . . . . . . . . . . . .  12
     5.1.  Single-Link Failure . . . . . . . . . . . . . . . . . . .  12
     5.2.  Boundary Conditions and Limitations . . . . . . . . . . .  13
   6.  Interoperability with Existing Protocols and Technologies . .  14
   7.  Key Characteristics . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Core Advantages . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Limitations . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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
   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



Luan, et al.             Expires 29 August 2026                 [Page 3]

Internet-Draft                SDAF for LEO                 February 2026


   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 29 August 2026                 [Page 4]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                 [Page 5]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                 [Page 6]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                 [Page 7]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                 [Page 8]

Internet-Draft                SDAF for LEO                 February 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 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:

   1.  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.

   2.  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.

   3.  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

      Figure 1: Example local interface indexing and symmetry mapping
                           (CLI/FLI) for node A.





Luan, et al.             Expires 29 August 2026                 [Page 9]

Internet-Draft                SDAF for LEO                 February 2026


4.2.  Failure/Disruption Detection

   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.

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:




Luan, et al.             Expires 29 August 2026                [Page 10]

Internet-Draft                SDAF for LEO                 February 2026


   *  If the CFI is available, the packet is forwarded through the CFI.

   *  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 29 August 2026                [Page 11]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                [Page 12]

Internet-Draft                SDAF for LEO                 February 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 2: 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 29 August 2026                [Page 13]

Internet-Draft                SDAF for LEO                 February 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 29 August 2026                [Page 14]

Internet-Draft                SDAF for LEO                 February 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>.

Acknowledgments

   The authors would like to thank colleagues and reviewers for their
   valuable feedback.

Contributors

   None.

Authors' Addresses




Luan, et al.             Expires 29 August 2026                [Page 15]

Internet-Draft                SDAF for LEO                 February 2026


   Shenshen Luan
   Beihang University
   Email: luanshenshen@buaa.edu.cn


   Wenting Wei
   Xidian University
   Email: wtwei@xidian.edu.cn


   Mingliang Ke
   Xidian University
   Email: ml.ke.xidian@foxmail.com


   Hou Dongxu
   ZTE Corporation
   Email: hou.dongxu@zte.com.cn


   Xiao Min
   ZTE Corporation
   Email: xiao.min2@zte.com.cn




























Luan, et al.             Expires 29 August 2026                [Page 16]
