| Internet-Draft | Routing Architecture for Satellite Netwo | November 2025 |
| Dongxu & Min | Expires 7 May 2026 | [Page] |
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.¶
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 (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 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The 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.¶
(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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document 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.¶
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.¶
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 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.¶
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.¶
(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.¶
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|-###
\__/ \__/ \__/
Step 2: The satellite network topology prediction module maintains a prediction topology. As shown in Figure 3.¶
.--. .--. .--.
###-| N1 |-### ###-| N5 |-### ###-| N9 |-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. .--. .--.
###-| N2 |-### ###-| N6 |-### ###-| N10|-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. .--. .--.
###-| N3 |-### <--> ###-| N7 |-### ###-| N11|-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. .--. .--.
###-| N4 |-### <--> ###-| N8 |-### <--> ###-| N12|-###
\__/ \__/ \__/
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.¶
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|-###
\__/ / \ \__/ \__/
Step 2: The prediction topology calculated by the satellite network topology prediction module is illustrated in Figure 5.¶
.--. .--. .--.
###-| N1 |-### ###-| N5 |-### ###-| N9 |-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. .--. .--.
###-| N2 |-### ###-| N6 |-### ###-| N10|-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. .--. .--.
###-| N3 |-### <--> ###-| N7 |-### ###-| N11|-###
\__/ \__/ \__/
^ ^ ^
| | |
| | |
v v v
.--. \ / .--. .--.
###-| N4 |-### <X-> ###-| N8 |-### <--> ###-| N12|-###
\__/ / \ \__/ \__/
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.¶
In the future work, the extension of the current routing protocol to support the framework described in this document would be taken in mind.¶
TBA¶
TBA¶
This document has no IANA actions.¶