Routing Architecture for Satellite Networks Based on Hierarchical Structure

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

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 when, and only when, they appear in all capitals, as shown here.

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]).

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.

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.

Transition process between different interface states | |--┐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.

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.

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.

Use Case

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.

Logcial topology without unexpected failures ###-| 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.

Prediction topology without unexpected failures ###-| 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.

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.

Logcial topology with unexpected failures ###-| N5 |-### <--> ###-| N9 |-### \__/ \__/ \__/ ^ ^ ^ | | | | | | v v v .--. .--. .--. ###-| N2 |-### <--> ###-| N6 |-### <--> ###-| N10|-### \__/ \__/ \__/ ^ ^ ^ | | | | | | v v v .--. .--. .--. ###-| N3 |-### <--> ###-| N7 |-### <--> ###-| N11|-### \__/ \__/ \__/ ^ ^ ^ | | | | | | v v v .--. \ / .--. .--. ###-| N4 |-### ###-| N8 |-### <--> ###-| N12|-### \__/ / \ \__/ \__/ ]]> Step 2: The prediction topology calculated by the satellite network topology prediction module is illustrated in Figure 5.

Prediction topology with unexpected failures ###-| N7 |-### ###-| N11|-### \__/ \__/ \__/ ^ ^ ^ | | | | | | v v v .--. \ / .--. .--. ###-| N4 |-### ###-| 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.

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.

Security Considerations TBA

Acknowledgements TBA

IANA Considerations This document has no IANA actions.