



RTGWG                                                     H. Dongxu, Ed.
Internet-Draft                                                    X. Min
Intended status: Informational                           ZTE Corporation
Expires: 7 May 2026                                        November 2025


   Routing Architecture for Satellite Networks Based on Hierarchical
                               Structure
           draft-hou-rtgwg-satellite-routing-architecture-00

Abstract

   The satellite routing is the premis to ensure that the satellite
   network provides end-to-end stable service covering the whole globe.
   However, the mature terrestrial network technologies are difficult to
   directly apply to the satellite network because of the highly dynamic
   network topology and the limited on-board resources.  In view of this
   challenge, this document presents a hierarchical routing architecture
   for satellite networks based on the prediction topology between
   satellites or satellites and ground stations.

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 5 May 2026.

Copyright Notice

   Copyright (c) 2025 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



Dongxu & Min               Expires 7 May 2026                   [Page 1]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Hierarchical Routing Architecture . . . . . . . . . . . . . .   4
     4.1.  Physical Link Layer . . . . . . . . . . . . . . . . . . .   4
     4.2.  Logical Topology Layer  . . . . . . . . . . . . . . . . .   6
     4.3.  Time-varing Routing Layer . . . . . . . . . . . . . . . .   7
   5.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Time-varying Routing Computation Without Unexpected
           Failures  . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Time-varying Routing Computation With Burst Failures  . .  10
   6.  Extensions and Future Works . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   11. Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The LEO mega-constellation networks can overcome the limitations of
   the conventional terrestial network, achieving global signal
   coverage, and providing large broadband and low-latency network
   services for global users.  The global communications ecosystem
   suggests that satellite-based communication will become an important
   part of 5G-advanced and 6G.

   Routing issues are the premise to ensure the stable worldwide end-to-
   end service based on the satellite network.  Compared with the
   terrestial network, the satellite network has the characteristics of
   highly dynamic nodes, time-varying network topology, and limited on-
   board resources.  So the mature terrestrial nework routing technology
   is difficult to directly apply.

   To tackle the above issues, this document proposes a hierarchical
   routing architecture.  This architecture can be implemented on the
   basis of existing IGP or BGP.  The details of this architecture are
   as follows:

   (1) Firstly, three layers in the hierarchical routing architecture
   are defined.



Dongxu & Min               Expires 7 May 2026                   [Page 2]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


   (2) Then, corresponding functions of ecah layer are illustrated.

   (3) Finally, use cases in different scenarios are described.

   Further details are discussed in subsequent sections.

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.

3.  Terminology

   *  SR: Satellite Router

   *  GS: Ground Station

   *  VLEO: Very Low Earth Orbit with the altitude below 450 km.

   *  LEO: Low Earth Orbit with the altitude between 180 km and 2000 km.

   *  MEO: Medium Earth Orbit with the altitude between 2000 km and
      35786 km.

   *  GEO: Geosynchronous Orbit with the altitude 35786 km.

   *  Intra-satellite links: Links between adjacent satellites in the
      same orbit.

   *  Intra-satellite links: Links between adjacent satellites in the
      different orbits.

   *  SGP4: Simplified Perturbations Models

   *  Lon: Longitude

   *  Lat: Latitude

   *  BGP: Border Gateway Protocol [RFC4271]

   *  IGP: Interior Gateway Protocol, examples of IGPs inculde Open
      Shortest Path First (OSPF [RFC2328]), Routing Information Protocol
      (RIP [RFC2453]), Intermediate System to Intermediate System (IS-IS
      [RFC7142]) and Enhanced Interior Gateway Routing Protocol (EIGRP
      [RFC7868]).



Dongxu & Min               Expires 7 May 2026                   [Page 3]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


4.  Hierarchical Routing Architecture

   This document proposes a hierarchical routing architecture which
   contains three layers, namely the physical link layer, the logical
   topology layer, and the time-varying routing layer.  It should be
   noted that the routing architecture is based on the link state
   routing.

4.1.  Physical Link Layer

   The physical link layer perceives the connection state of links
   between different satellites or satellites and ground stations (GSs).
   This process identifies predictable or unpredictable link changes,
   and introduces a new interface state, namely HOLD, to mark these
   predictable changes.  When the physical interface in HOLD state, the
   corresponding link remains connected to shield predictable network
   topology changes in upper layers.  Normal interface states, including
   UP and DOWN, remain valid.  Descriptions of different interface
   states are as follows:

   (1) UP: If detecting the link prediction down, the interface state
   switches to HOLD.  The link state remains connected and the link
   state change isn't signaled to the logical topology layer.  If
   detecting the unexpected failure, the interface state switches to
   DOWN.  Both affected network nodes should update the local link state
   database and advertise this change.

   (2) HOLD: If detecting link prediction up, the interface state
   switches to UP.  The link state remains and the link state change
   isn't adverteised.  For the other events, the interface state stays
   in HOLD.

   (3) DOWN: If detecting link up, the interface state switch to UP.
   The routing protocol re-establishes the neighbor relationship and
   floods link state changes.  For the other events, the interface state
   stays in DOWN.















Dongxu & Min               Expires 7 May 2026                   [Page 4]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


                             link prediction down
                     ┌------┐                  ┌------┐
link prediction up┌--|      |----------------->|      |--┐link down
link up           |  |  UP  |                  | HOLD |  |link up
                  └->|      |<-----------------|      |<-┘link prediction down
                     └------┘link prediction up└------┘
                       ^  |
                       |  |
                       |  |link down
                 link up  |
                       |  |    ┌------┐
                       |  └--->|      |--┐link down
                       |       | DOWN |  |link prediction down
                       └-------|      |<-┘link prediction up
                               └------┘

   Figure 1: Transition process between different interface states


   Figure 1 illustrates the transition process between different
   interface states drived by events.  Typical events are described as
   follows:

   (1) Link up: When the physical interface is in DOWN state and the
   physical link is found to be operational, a link up evnet is
   triggered.

   (2) Link down: When the physical interface is in UP state and the
   physical link switches to down, a link down event is triggered.

   (3) Link prediction up: When the satellite router predicts the
   physical link recovery, a link prediction up event is triggered.  The
   same event is raised for satellite-ground links.  Upon the physical
   interface leaves HOLD state, following process should be identified.

   a.  If the link is disconnectd when HOLD is expired, the interface
   state switches to DWON and consequent actions are executed, e.g.
   generating link state information.

   b.  If the link is connected when HOLD is expired, the interface
   state switches to UP and no further action is taken.

   (4) Link prediction down: When the satellite router predicts the
   physical link failure, a link prediction down event is triggered.
   The same event is raised for satellite-ground links.  Upon this event
   is happened, the physical interface state switches to HOLD.





Dongxu & Min               Expires 7 May 2026                   [Page 5]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


4.2.  Logical Topology Layer

   The routing protocol running on the logical topology layer is
   responsible for maintaining link state information of all possible
   connections between different satellites or satellites and GSs during
   satellite networks operation, namely logcial topology.  Combining
   with the HOLD state in the physical link layer, the routing protocol
   achieves insensitivity to predictable network topology changes, and
   ensures the stability of the logical topology.  The details are as
   follows.

   (1) Generating complete link state database

   The complete link state database describes all possible connections
   during satellite networks operation.  At the initial moment, the link
   state database on each satellite may be incomplete.  After all
   possible links have been established at least once, each satellite
   could obtain a complete link state database.

   (2) Advertising link state information

   When predictable link interruptions or recoveries occur, the physical
   interface of the corresponding satellite router is set to the HOLD or
   UP state.  The routing protocol detects the state change and doesn't
   trigger link state advertisements or other routing protocol
   mechanisms.

   When unpredictable link interruptions or recoveries occur, the
   routing protocol detects the state change and trigger link state
   advertisements.  Since communication between different nodes through
   the DOWN physical interface is unavailable, the link state
   information must be flooded through other UP interfaces to ensure
   real-time notifications of abrupt network topology changes.

   (3) Recycling link state informaiton

   The IGP recycles invalid link state informaiton through periodic
   flooding and aging mechanism.  The periodic flooding mechanism of IGP
   can be canceled when there are no changes in link state informaiton
   to avoid unnecessary bandwidth consumption.

   (4) Routing computation

   For predictable network changes, the routing computation is triggered
   by the time-varying routing layer periodically.  The routing
   computation triggering interval is set by the user.  For
   unpredictable network changes, the routing protocol self-triggers
   routing computation upon receiving link state changes.



Dongxu & Min               Expires 7 May 2026                   [Page 6]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


4.3.  Time-varing Routing Layer

   (1) Response procedure of interface and routing protocol triggered by
   predictable network changes.

   Since the routing protocol maintains a stable logical topology,
   predictable network changes can't trigger routing computation through
   link state information advertisements.  The time-varying routing
   layer needs to introduce another method to trigger routing
   computation and generate routes based on the real network topology.
   Additionally, it must adjust the physical interface state based on
   predictable network changes.

   Based on satellite orbital parameters, longitude and latitude of
   ground nodes, satellite antenna pointing angles, and etc., combined
   with satellite trajectory prediction algorithm, satellite positions
   and link connection relationship between different nodes can be
   predicted at a special time.  The satellite network topology
   prediction module running on the time-varying routing layer is
   responsible for managing output information.  It periodically
   triggers routing computation and changes the state of physical
   interfaces.

   (2) Time-varing routing computation

   The routing computation is initiated by the satellite network
   topology prediction module.  The computation process consists of
   three steps: connection relationship calculation, routing
   calculation, and route entity update.

   Routing calculation and route entity update can reuse the mechanisms
   of existing link state routing protocols.  The connection
   relationship calculation is different from the standard practice.
   The conventional link state protocols run the Dijkstra algorithm on
   the adverteised link state database.

   However, the link state database maintained by the proposed routing
   architecture covers the full logical topology.  As building SPT based
   on the Dijkstra algorithm, it must query the prediction data produced
   in step (1) to decide links which could be used at the computation
   instant.  Links predicted to be down are pruned from the logical
   topology, so the SPT is built on the true and instantaneous topology.

5.  Use Case







Dongxu & Min               Expires 7 May 2026                   [Page 7]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


5.1.  Time-varying Routing Computation Without Unexpected Failures

   Step 1: The routing protocol mantains the logcial topology which is
   the complete graph, as shown in Figure 2.


               .--.                .--.                .--.
          ###-| N1 |-### <--> ###-| N5 |-### <--> ###-| N9 |-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N2 |-### <--> ###-| N6 |-### <--> ###-| N10|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N3 |-### <--> ###-| N7 |-### <--> ###-| N11|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N4 |-### <--> ###-| N8 |-### <--> ###-| N12|-###
               \__/                \__/                \__/

           Figure 2: Logcial topology without unexpected failures


   Step 2: The satellite network topology prediction module maintains a
   prediction topology.  As shown in Figure 3.















Dongxu & Min               Expires 7 May 2026                   [Page 8]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


               .--.                .--.                .--.
          ###-| N1 |-###      ###-| N5 |-###      ###-| N9 |-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N2 |-###      ###-| N6 |-###      ###-| N10|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N3 |-### <--> ###-| N7 |-###      ###-| N11|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N4 |-### <--> ###-| N8 |-### <--> ###-| N12|-###
               \__/                \__/                \__/

         Figure 3: Prediction topology without unexpected failures


   Step 3: The effective topology used for routing computation is
   exactly the one shown in Figure 5.  The routing computation phase
   consists of two sub-steps, namely topology calculation and routing
   calculation.  The proposed method doesn't modify the standard routing
   calculation step but refines the topology calculation step.  The
   implementation proceeds as follows:

   Step 3.1: Based on the topology information in the link state
   database, the base topology graph is generated, as shown in Figure 3.

   Step 3.2: Based on the Dijkstra algorithm, the satellite router
   calculates the shortest path tree with itself as the root.  The
   computation process of the Dijkstra algorithm traverse all nodes and
   edges in the logcial topology.  During this process, the connection
   state of traversed edges are determined by the prediction connection
   relationship between satellites or satellites and GSs.  Disconnection
   links are filtered and don't participate in the computation process.

   Step 3.3: The process of STEP 3.2 is executed repeatedly until the
   shortest path tree is obtained.



Dongxu & Min               Expires 7 May 2026                   [Page 9]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


5.2.  Time-varying Routing Computation With Burst Failures

   Step 1: The logcial topology maintained by the logical topology layer
   is shown in Figure 4.  For the burst failure, the link between N4 and
   N8 is in the disconnection state.


               .--.                .--.                .--.
          ###-| N1 |-### <--> ###-| N5 |-### <--> ###-| N9 |-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N2 |-### <--> ###-| N6 |-### <--> ###-| N10|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N3 |-### <--> ###-| N7 |-### <--> ###-| N11|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.      \ /       .--.                .--.
          ###-| N4 |-### <X-> ###-| N8 |-### <--> ###-| N12|-###
               \__/      / \       \__/                \__/

            Figure 4: Logcial topology with unexpected failures


   Step 2: The prediction topology calculated by the satellite network
   topology prediction module is illustrated in Figure 5.














Dongxu & Min               Expires 7 May 2026                  [Page 10]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


               .--.                .--.                .--.
          ###-| N1 |-###      ###-| N5 |-###      ###-| N9 |-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N2 |-###      ###-| N6 |-###      ###-| N10|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.                .--.                .--.
          ###-| N3 |-### <--> ###-| N7 |-###      ###-| N11|-###
               \__/                \__/                \__/
                ^                   ^                   ^
                |                   |                   |
                |                   |                   |
                v                   v                   v
               .--.      \ /       .--.                .--.
          ###-| N4 |-### <X-> ###-| N8 |-### <--> ###-| N12|-###
               \__/      / \       \__/                \__/

           Figure 5: Prediction topology with unexpected failures


   Step 3: The satellite network topology used for topology calculation
   is shown in Figure 5.  The calculation process is consistent with
   Step 3 in the previous use case.

6.  Extensions and Future Works

   In the future work, the extension of the current routing protocol to
   support the framework described in this document would be taken in
   mind.

7.  Security Considerations

   TBA

8.  Acknowledgements

   TBA






Dongxu & Min               Expires 7 May 2026                  [Page 11]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


9.  IANA Considerations

   This document has no IANA actions.

10.  Normative References

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

11.  Informative References

   [I-D.hou-tvr-satellite-network-usecases]
              "Satellite Network Routing Use Cases",
              <https://datatracker.ietf.org/doc/html/draft-hou-tvr-
              satellite-network-usecases-01>.

   [I-D.ietf-tvr-use-cases]
              "TVR (Time-Variant Routing) Use Cases",
              <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-
              cases-00>.

   [KUIPER]   "Amazon receives FCC approval for project Kuiper satellite
              constellation.", <https://tinyurl.com/bs7syjnk>.

   [Large-Scale-LEO-Network-Routing]
              "Large Scale LEO Satellite Networks for the Future
              Internet: Challenges and Solutions to Addressing and
              Routing," Computer Networks and Communications, 1(1),
              31-58", <https://ojs.wiserpub.com/index.php/CNC/article/
              view/2105>.

   [StarLink] "Starlink", <https://en.wikipedia.org/wiki/Starlink>.

   [ThreeGPP] "3GPP", <https://www.3gpp.org/>.

Authors' Addresses









Dongxu & Min               Expires 7 May 2026                  [Page 12]

Internet-Draft  Routing Architecture for Satellite Netwo   November 2025


   Hou Dongxu (editor)
   ZTE Corporation
   No.50 Software Avenue
   Nanjing
   Jiangsu, 210012
   China
   Email: hou.dongxu@zte.com.cn


   Xiao Min
   ZTE Corporation
   No.50 Software Avenue
   Nanjing
   Jiangsu, 210012
   China
   Email: xiao.min2@zte.com.cn



































Dongxu & Min               Expires 7 May 2026                  [Page 13]
