Internet DRAFT - draft-hou-satellite-routing-framework
draft-hou-satellite-routing-framework
Network Working Group H. Dongxu, Ed.
Internet-Draft X. Min
Intended status: Informational F. Zhou
Expires: 20 August 2024 ZTE Corporation
February 2024
Routing Framework for LEO Mega-constellation Based on Region Division
draft-hou-satellite-routing-framework-02
Abstract
The inter-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. This issue is further exacerbated in LEO mega-
constellations. In view of this challenge, this document presents a
routing framework for LEO mega-constellation. Based on the orbit
position characteristic and the predictable topology, this framwork
realizes flexible region division, establishes intra-region and
inter-region path, as well as completes end-to-end data forwarding.
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 4 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dongxu, et al. Expires 20 August 2024 [Page 1]
Internet-Draft Routing Framework for LEO Constellation February 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Region Planning . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Region Model . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mapping Relationship . . . . . . . . . . . . . . . . . . 6
5. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Node Type . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Border Node Capability . . . . . . . . . . . . . . . . . 8
5.3. Shared Node Capability . . . . . . . . . . . . . . . . . 9
6. Routing Computation . . . . . . . . . . . . . . . . . . . . . 11
6.1. Information for Routing Calculation . . . . . . . . . . . 11
6.2. Routing Computation . . . . . . . . . . . . . . . . . . . 12
7. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Scenario 1: Intra-region data forwarding . . . . . . . . 13
7.2. Scenario 2: Inter-region data forwarding . . . . . . . . 14
8. Sudden Failure Handling . . . . . . . . . . . . . . . . . . . 16
8.1. Unreachable node in a region . . . . . . . . . . . . . . 17
8.2. Complete link break in a region . . . . . . . . . . . . . 17
8.3. Complete link break between neighboring regions . . . . . 18
9. Extensions and Future Works . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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.
Dongxu, et al. Expires 20 August 2024 [Page 2]
Internet-Draft Routing Framework for LEO Constellation February 2024
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.
In view of this situation, some improved routing methods have been
proposed based on the predictable topology changes in the satellite
network. However, the development trend of the satellite network is
becoming more and more low-orbit and large-scale, which further
intensifies the dynamic property of the network. More topology
changes as well as information announcements are happend, which would
result in frequent routing calculations, much more protocol overhead,
and even route flapping.
To tackle the above issues, the terrestial network generally adopts
the manner of area division to imporve the efficiency of routing
convergence and network management. The existing area division
method typically divides a network into a backbone area and multiple
non-backbone areas. The backbone area is unique and has routing
informations of all areas. The non-backbone areas establish fixed
connections around the backbone area. Thus, nodes in the backbone
area are responsible for traffic forwarding between all areas, and
require higher performance. However, the performance of satellites
is peer-to-peer and limited, especially in the single-layer satellite
constellation. The current area division method could easily make
the backbone area congested in the satellite network. Besides, due
to the permanent changes of the satellite network topology, the
connection relationship between different areas is unable to maintain
stability, and each area need to exchange routing informations
continuously. So the existing area division method is not only
inefficient but also lacks sufficient flexibility, and can't meet the
requirement of routing in the satellite network.
Considering these problems, this document proposes a routing
framework for LEO mega-constellation networks based on region
division. This framework can be implemented on the basis of existing
IGP. The details of this framework are as follows:
(1) Firstly, based on the relative position between satellites, the
new node type and capability are defined to realize flexible region
divesion.
(2) Then, the mapping relationship between nodes and regions is
established based on the satellite orbit position to reduce the
inter-region network information announcement.
Dongxu, et al. Expires 20 August 2024 [Page 3]
Internet-Draft Routing Framework for LEO Constellation February 2024
(3) Finally, based on the predictable network topology in the
satellite network, the inter-region and intra-region paths are
constructed to complete the end-to-end data forwarding.
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
* 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
* 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]).
4. Region Planning
Dongxu, et al. Expires 20 August 2024 [Page 4]
Internet-Draft Routing Framework for LEO Constellation February 2024
4.1. Region Model
In the satellite network, each satellite moves along the orbit, which
can be divided into circular orbit satellites and elliptical orbit
satellites. Different orbits can be described by Keplerian
parameters. At present, the mainstream of satellite networks
basically adopt circular orbit.
Orbit Orbit Orbit
Plane 1 Plane 2 Plane 3
| | |
+---+ +---+ +---+
---| 1 |-----| 4 |-----| 7 |---
+---+ +---+ +---+
| | |
| | |
+---+ +---+ +---+
---| 2 |-----| 5 |-----| 8 |---
+---+ +---+ +---+
| | |
| | |
+---+ +---+ +---+
---| 3 |-----| 6 |-----| 9 |---
+---+ +---+ +---+
| | |
Figure 1: N5 and its adjacent satellites
When links between satellites are established for end-to-end
communication, each satellite usually has a fixed number of links
which communicate with neighboring nodes, and considering the cost of
satellite links and power restrictions of satellites, satellite links
are generally limited to direct connections between adjacent nodes.
In a single-layer satellite constellation, each satellite may have
four types of contiguous neighbour satellites and each type refers to
a direction. The number of neighbor satellites distributed in one
direction is determined by the number of antennas deployed on the
satellite for communication. If the satellite contains a single
antenna in each direction, the connection relationship between the
satellite N5 and its two satellites in the same orbit and two
satellites in different adjacent orbits is shown in Figure 1. In a
multi-tier satellite constellation, each satellite may have two
additional types of adjacent satellites, upper level satellites and
lower level satellites in different tiers.
Dongxu, et al. Expires 20 August 2024 [Page 5]
Internet-Draft Routing Framework for LEO Constellation February 2024
Therefore, the quadrangle is adopted as the basic model of region
division, that is, a region also have four types of contiguous
neighbour regions and each type refers to a direction, as shown in
Figure 2. In this way, satellites in each region and the adjacency
relationship between regions could remain unchanged with the dynamic
change of satellite topology.
Orbit Orbit Orbit
Plane 1 Plane 2 Plane 3
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | A18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| A14| | A19 | | |A24 |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--+--| 2 |
+---+ | +---+ +---+ +---+ | +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | A20 | | | l=3
| +---+ +---+ +---+ |
h=3 | 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
Figure 2: Basic model of region division
4.2. Mapping Relationship
In a satellite constellation which has M orbit planes and N nodes per
orbit plane, the orbit position information of a satellite can be
marked with (X, Y), namely the node identifier. The corresponding
region number k of this satellite can be calculated by Formula 1.
k=ceil(X/l)*(M/l)+ceil(Y/h)+delta
Dongxu, et al. Expires 20 August 2024 [Page 6]
Internet-Draft Routing Framework for LEO Constellation February 2024
The X is the orbit plane of the satellite. The Y is the sequence in
the orbit plane of the satellite. The h is the number of satellites
included in the region in a single orbit plane. The l is the number
of orbits spanned by the region. The h and the l are region range
parameters which can be pre-planned by the control layer of the
network. The delta is an offset value when calculating the region
number.
Based on the orbit position information, the communication port of
the satellite is addressed. During the data forwarding process, each
relay satellite resolves the destination node identifier from the
destination address, and then calculates the region number of the
destination node via Formula 1. Through this method, each node can
determine the mapping relationship between regions and nodes.
5. Node Capability
In order to realize the region division described in the previous
section, the corresponding capability of the satellite node should be
defined.
It should be noted that the process of satellite motion along the
orbit is periodic and predictable. Predictable information in a
satellite network includes the real-time position of a satellite, the
connectivity of satellite links, the characteristics of satellite
links.
Based on these predictable information, the management plane, the
control plane and the forwarding plane of the network can be
adaptively improved to ensure a stable and optimal end-to-end
reachable path between a pair of satellites. On one hand, the
flooding of routing convergence information caused by network
topology changes can be avoided. On the other hand, the routing re-
calculation is able to be fulfilled in advance before the satellite
network topology changes. Thus the calculated results can be updated
immediately and timely. The same methods can also apply to
predictable changes in the characteristics of satellite links. The
node capabilities described in this section incorporate this manner.
5.1. Node Type
According to the relative position of a satellite in the rigion, the
type of the satellite can be classified as the internal node and the
border node. The internal node doesn't connect nodes outside of the
rigion. The border node is part of the rigion and has connections to
nodes outside of the rigion. The internal node and the border node
are collectively referred as the intra-region nodes. The node which
have connections to the border node in the neighbor rigion is called
Dongxu, et al. Expires 20 August 2024 [Page 7]
Internet-Draft Routing Framework for LEO Constellation February 2024
the cross-rigion neighbor node.
5.2. Border Node Capability
Each region is abstracted as a single virtual node to hide the
network information and the topology change from the external
network. The virtual node represents the time-varying geographical
location of a region in the satellite network. The geographical
location of the virtual node corresponds to the specified node in the
region. The specified node could be configured by the network
administrator or elected via protocol mechanism. It should be noted
that there is only one edge between any two adjacent virtual nodes.
In order to shield the network information in a region from the
external network, the border node should have the following features:
(1) The capability of establishing connections with cross-rigion
neighbor nodes.
The border node is the agent of the external connection for the local
region, and is responsible for establishing the connection with the
cross-rigion neighbor node. During the connection establishment
process, these nodes build the adjacency relationship and announce
the region number with each other. After the border node receives
the region number of the neighbor region, the border node informs
this information to other nodes on the local region.
(2) The capability of maintaining connections with cross-rigion
neighbor nodes.
The change of the connection relationship between the border node and
the cross-rigion neighbor node can be divided into predictable and
unpredictable. The predictable connection change can be self-
calculated and obtained by each node according to the orbit
parameters. Therefore, the border node only notifiy the
unpredictable connection change to nodes in the same region.
Figure 3 presents a unpredictable link failure between A19 adn A24,
and N8 is responsible for informing other nodes in the same region.
Dongxu, et al. Expires 20 August 2024 [Page 8]
Internet-Draft Routing Framework for LEO Constellation February 2024
Orbit Orbit Orbit
Plane 1 Plane 2 Plane 3
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | A18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| A14| | A19 | | |A24 |
| | | | | | |
+---+ | +---+ +---+ +---+ \|/ +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--X--| 2 |
+---+ | +---+ +---+ +---+ /|\ +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | A20 | | |
| +---+ +---+ +---+ |
| 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
Figure 3: Inter-region link failure
(3) The capability of isolating network information advertisements
between different regions.
If the network variation is happened in a region (such as link
interruption, node failure, and etc.), the affected nodes will
typically flood routing information to other nodes. When the
flooding information reaches the border node, this information will
be blocked, that is, the routing information in a region can't pass
through the border node to the adjacent region.
5.3. Shared Node Capability
In addition to the above unique features of the border node, both the
border node and the internal node share the following functions:
(1) The capability of maintaining intra-region network information.
Dongxu, et al. Expires 20 August 2024 [Page 9]
Internet-Draft Routing Framework for LEO Constellation February 2024
When a region is initially created, the node establishes a connection
with a neighbor node, determines the node of the region based on the
planned region parameters, generates a network topology in the region
according to the orbit parameters, notifies its own network
information to other nodes in the region, and continuously monitors
its own direct links. Then, the node calculates and updates the
intra-region network topology according to the planned time interval
by the predictability of satellite orbital movement. As a sudden
failure occurs, the node notifies it and updates the local network
information and the intra-region topology. Figure 4 presents a
unpredictable link failure between N5 adn N8. N5 and N8 are
responsible for informing other nodes in the same region.
Orbit Orbit Orbit
Plane 1 Plane 2 Plane 3
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | A18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| A14| | A19 | | |A24 |
| | | | | | |
+---+ | +---+ +---+ \ / +---+ | +---+
| 8 |--+--| 2 |-----| 5 |--X--| 8 |--+--| 2 |
+---+ | +---+ +---+ / \ +---+ | +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | A20 | | |
| +---+ +---+ +---+ |
| 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
Figure 4: Intra-region link failure
(2) The capability of maintaining cross-region connection
relationships.
Dongxu, et al. Expires 20 August 2024 [Page 10]
Internet-Draft Routing Framework for LEO Constellation February 2024
When a region is initially created, the node generates a mapping
relationship between the border node and the adjacent region
according to the notification information of the border node. Then,
the node periodically calculates the connectivity between border
nodes and connected cross-region neighbor nodes based on the
predictability of satellite orbital movement, and updates the mapping
relationship. As a sudden failure occurs, each node in the local
region receives the routing information announced by the border node,
and updates the mapping relationship.
(3) The capability of maintaining inter-region network topology.
Based on the orbit parameters of the designated nodes in the region
corresponding to the virtual nodes, and the planned region range, the
node calculate the geographical positions of other virtual nodes in
the entire network to obtain the inter-region network topology.
6. Routing Computation
6.1. Information for Routing Calculation
Through above node capabilities, each node periodicly predict time-
varying network states based on the satellite parameters to shield
the dynamic of network. These network states include intra-region
topology relationship, the inter-region topology relationship, as
well as the mapping relationship between the border node and the
adjacent region.
(1) Inter-region topology relationship
Based on the satellite parameters (such as orbit parameters,
satellite running time, and etc.), each satellite calculates the
geographical location of virtual node corresponding to each region
and constructs the inter-region topology relationship. Then,
according to the inter-region topology relationship and the route
computation algorithm, inter-region paths between the local region
and others are obtained. Finally, the next hop regions to reach
destination regions is also achieved. Figure 5 shows the
representation of the inter-region topology relationship.
+------+------+------+
| Area1| Area2| Cost |
+------+------+------+
| A14 | A19 | 10 |
+------+------+------+
Figure 5: Inter-region topology relationship
Dongxu, et al. Expires 20 August 2024 [Page 11]
Internet-Draft Routing Framework for LEO Constellation February 2024
(2) Intra-region topology relationship
Each satellite calculates the connection relationship between any two
nodes in the local region based on the satellite parameters.
According to the connection relationship, intra-region topology
relationship is constructed, which shows in Figure 6.
+------+------+------+
| Node1| Node2| Cost |
+------+------+------+
| N1 | N2 | 6 |
+------+------+------+
Figure 6: Intra-region topology relationship
(3) Mapping relationship
In a region, each satellite receives the neighbor region number
advertised by the border node. Then, a mapping relationship between
the neighbor region and the border node is constructed. Figure 7
shows the representation of the mapping relationship.
+-----------+----------+
| Edge Node | Nig Area |
+-----------+----------+
| N1 | INF |
+-----------+----------+
| N2 | A14 |
+-----------+----------+
Figure 7: Mapping relationship
6.2. Routing Computation
Based on these network information, the intra-region routing table
and inter-region routing table could be constructed.
(1) Intra-region routing
Dongxu, et al. Expires 20 August 2024 [Page 12]
Internet-Draft Routing Framework for LEO Constellation February 2024
When the destination address of the data packet is identified in the
local region, the intra-region routing table is used for the data
forwarding. The data forwarding process is consistent with the
terrestrial network. The intra-region routing table entries include
destination address, network mask, routing priority, routing
overhead, forwarding interface, and next hop address.
(2) Inter-region routing
When the destination address of the data packet is identified in the
remote region, the inter-region routing table is used for the data
forwarding. The path calculation process of each node is as follows:
a. Firstly, based on the inter-region topology relationship, the
inter-region path from the region where the node is located to other
regions is calculated.
b. Then, according to the mapping relationship and the intra-region
topology relationship, the intra-region path to the next hop region
is calculated.
The inter-region routing table entries replaces the destination
address and network mask with the destination area, and adds the next
hop forwarding area. Figure 8 presents an example of the inter-
region routing table.
+--------+---------+-----+------+-----+------------+
|Dst Area| Nxt Area| Pri | Cost | Inf | Nxt Hop Adr|
+--------+---------+-----+------+-----+------------+
| 22 | 18 | 1 | 6 | eth | x.x.x.x |
+--------+---------+-----+------+-----+------------+
Figure 8: Inter-region routing table
7. Data Forwarding
7.1. Scenario 1: Intra-region data forwarding
As shown in Figure 9, N2 and N4 are located in the same region. N2
serves as the source end to send data to the destination end N4. The
data forwarding path between N2 and N4 pass through N2, N5, and N4 in
turn. The routing process is consistent with that of the terrestial
network. So, this document doesn't describe the process here.
Dongxu, et al. Expires 20 August 2024 [Page 13]
Internet-Draft Routing Framework for LEO Constellation February 2024
Orbit plane 1 Orbit plane 2
| .--. .--. |
| ###-| N3 |-### <--> ###-| N6 |-### |
| \__/ \__/ |
| ^ A18 ^ |
--------------+--------+-------------------+---------+--------------
A14 | v A19 v | A24
.--. | .--. .--. | .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v | v ----------------> v | | v
.--. | .--. .--. | .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
\__/ | \__/ \__/ | \__/
^ | ^ ^ | ^
| | | | | |
v | v v | v
.--. | .--. .--. | .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
\__/ | \__/ \__/ | \__/
| ^ ^ |
--------------+--------+-------------------+---------+-------------- N
| v A20 v | ^
| .--. .--. | |
| ###-| N1 |-### <--> ###-| N4 |-### | Moving |
| \__/ \__/ | Direction S
Figure 9: Intra-region data forwarding
7.2. Scenario 2: Inter-region data forwarding
Dongxu, et al. Expires 20 August 2024 [Page 14]
Internet-Draft Routing Framework for LEO Constellation February 2024
+-----+-----+-----+-----+-----+-----+
| A1 | A6 | A11 | A16 | A21 | A26 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+
| A2 | A7 | A12 | A17 | A22 | A27 |
| | | | ^>> | |
+-----+-----+-----+----^+-----+-----+
| A3 | A8 | A13 | A18^| A23 | A28 |
| | | | ^| | |
+-----+-----+-----+----^+-----+-----+
| A4 | A9 | A14 | A19^| A24 | A29 |
| >>>>>>>>>>>>>>>>>>>>| | |
+-----+-----+-----+-----+-----+-----+
| A5 | A10 | A15 | A20 | A25 | A30 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+
Figure 10: End-to-end inter-region path
As shown in Figure 10, the satellite network is divided into 30
regions. At a certaion time, Sat1 is located in region 4 and Sat2 is
located in region 22. Sat1 serves as the source end to send data to
the destination end Sat2. The data forwarding path between Sat1 and
Sat2 pass through region 4, 9, 14, 19, 18, 17, and 22 in turn.
As shown in Figure 11, the data is forwarded from Node 6 in region 14
to Node 3 in region 19 20. Node 3 resolves the destination node
identifier (x_dst, y_dst) from the destination address, and then
calculates the region number of the destination node as 22 via
Formula 1.
Node 3 queries the inter-region routing table to forward data.
According to the inter-region routing table record, if the
destination node is located in region 22, the data packet is
forwarded via region 18, and the next hop node is Node 6. Each node
in region 19 repeats the above operations, and finally forwards the
packet to region 18. For the border node, the next hop address in
the inter-region routing table is the port address of the cross-
rigion neighbor satellite.
Dongxu, et al. Expires 20 August 2024 [Page 15]
Internet-Draft Routing Framework for LEO Constellation February 2024
Orbit plane 1 Orbit plane 2
| .--. .--. |
| ###-| N3 |-### <--> ###-| N6 |-### |
| \__/ \__/ |
| ^ A18 ^ ^ |
--------------+--------+-------------------+--|------+--------------
A14 | v A19 v | | A24
.--. | .--. .--. | .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v | v v | | v
.--. | .--. .--. | .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v ----------------> v ----------------> v | | v
.--. | .--. .--. | .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
\__/ | \__/ \__/ | \__/
| ^ ^ |
--------------+--------+-------------------+---------+-------------- N
| v A20 v | ^
| .--. .--. | |
| ###-| N1 |-### <--> ###-| N4 |-### | Moving |
| \__/ \__/ | Direction S
Figure 11: Inter-region data forwarding
8. Sudden Failure Handling
The above routing calculation process presents the inter-satellite
routing in the large-scale constellation scenario. However, sudden
failures in this scenario have not been explained.
For sudden failures within or between regions which don't trigger
changes in node reachability or network connectivity, the mentioned
node capabilities and link state flooding methods can perform.
For sudden failures which trigger node reachability or network
connectivity changes, the network-wide routing information needs to
be advertised. This scenario can be divided into three categories:
Dongxu, et al. Expires 20 August 2024 [Page 16]
Internet-Draft Routing Framework for LEO Constellation February 2024
8.1. Unreachable node in a region
As shown in Figure 11, Sat2 is disconnected from Sat1, Sat3, Sat4,
and Sat5 for a sudden failure. After completing the intra-region
advertisement, each node in the region finds that the Sat2 is
unreachable based on the intra-region topology relationship table.
The region edge node will notify other regions the unreachability
information.
.--. .--. .--.
###-| N1 |-### <--> ###-| N4 |-### <--> ###-| N7 |-###
\__/ \__/ \__/
^ ^ ^
| X |
v v v
.--. .--. .--.
###-| N2 |-### <-X> ###-| N5 |-### <X-> ###-| N8 |-###
\__/ \__/ \__/
^ ^ ^
| X |
v v v
.--. .--. .--.
###-| N3 |-### <--> ###-| N6 |-### <--> ###-| N9 |-###
\__/ \__/ \__/
Figure 12: Unreachable node in a region
8.2. Complete link break in a region
As shown in Figure 12, a region is divided for sudden failures.
After the intra-region advertisement, each node in the region finds
that the region is divided into two disconnected parts based on the
intra-region topology relationship table. The region edge node will
notify other regions that the region is unreachability.
Dongxu, et al. Expires 20 August 2024 [Page 17]
Internet-Draft Routing Framework for LEO Constellation February 2024
+--------------------------------------------------------+
| .--. .--. .--. |
| ###-| N1 |-### <--> ###-| N4 |-### <X-> ###-| N7 |-### |
| \__/ \__/ \__/ |
| ^ ^ ^ |
| | | | |
| v v v |
| .--. .--. .--. |
| ###-| N2 |-### <--> ###-| N5 |-### <X-> ###-| N8 |-### |
| \__/ \__/ \__/ |
| ^ ^ ^ |
| | | | |
| v v v |
| .--. .--. .--. |
| ###-| N3 |-### <--> ###-| N6 |-### <X-> ###-| N9 |-### |
| \__/ \__/ \__/ |
+--------------------------------------------------------+
Figure 13: Inter-region data forwarding
8.3. Complete link break between neighboring regions
As shown in Figure 13, connections between two regions are
disconnected for sudden failures. According to the mapping
relationship between region edge nodes and adjacent regions, each
directly related node gets this network change. Then, these nodes
will notify other nodes the connectivity change. Nodes in other
regions will update their inter-region topology relationship table
based on the advertisement information.
----------------+ +----------------
.--. | | .--.
###-| N7 |-###|<-X>|###-| N1 |-###
\__/ | | \__/
^ | | ^
| | | X
v | | v
.--. | | .--.
###-| N8 |-###|<-X>|###-| N2 |-###
\__/ | | \__/
^ | | ^
| | | X
v | | v
.--. | | .--.
###-| N9 |-###|<-X>|###-| N3 |-###
\__/ | | \__/
----------------+ +----------------
Dongxu, et al. Expires 20 August 2024 [Page 18]
Internet-Draft Routing Framework for LEO Constellation February 2024
Figure 14: Complete link break between neighboring regions
9. 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.
10. Security Considerations
TBA
11. Acknowledgements
TBA
12. IANA Considerations
This document has no IANA actions.
13. References
13.1. 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>.
13.2. Informative References
[I-D.hou-tvr-satellite-network-usecases]
Dongxu, H., Min, X., Zhou, F., and D. Yuan, "Satellite
Network Routing Use Cases", Work in Progress, Internet-
Draft, draft-hou-tvr-satellite-network-usecases-01, 13
March 2023, <https://datatracker.ietf.org/doc/html/draft-
hou-tvr-satellite-network-usecases-01>.
[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., and Y. Qu, "TVR (Time-Variant
Routing) Use Cases", Work in Progress, Internet-Draft,
draft-ietf-tvr-use-cases-00, 15 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-
cases-00>.
Dongxu, et al. Expires 20 August 2024 [Page 19]
Internet-Draft Routing Framework for LEO Constellation February 2024
[I-D.lhan-satellite-semantic-addressing]
Han, L., Li, R., Retana, A., chenmeiling, and N. Wang,
"Satellite Semantic Addressing for Satellite
Constellation", Work in Progress, Internet-Draft, draft-
lhan-satellite-semantic-addressing-03, 3 March 2023,
<https://datatracker.ietf.org/doc/html/draft-lhan-
satellite-semantic-addressing-03>.
[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
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
Fenlin Zhou
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Dongxu, et al. Expires 20 August 2024 [Page 20]
Internet-Draft Routing Framework for LEO Constellation February 2024
Email: zhou.fenlin@zte.com.cn
Dongxu, et al. Expires 20 August 2024 [Page 21]
