Internet DRAFT - draft-hou-satellite-route-advertisement
draft-hou-satellite-route-advertisement
Network Working Group H. Hou, Ed.
Internet-Draft X. Min
Intended status: Informational F. Zhou
Expires: 20 August 2024 ZTE Corporation
February 2024
Lightweight Route Information Advertisement for LEO Mega-constellation
draft-hou-satellite-route-advertisement-00
Abstract
This document presents a lightweight route information advertisement
method in satellite networks. On the one hand, the method selects
the advertisement link by the way of route-associated judgment, to
reduce the overhead of route information advertisement. On the other
hand, the method provides a manner for dealing with link fault during
the route information advertisement process, to ensure the
reliability of routing information advertisement.
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.
Hou, et al. Expires 20 August 2024 [Page 1]
Internet-Draft Lightweight Route Advertisement 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Network Structure . . . . . . . . . . . . . . . . . . . 4
4. Route-associated Judgment . . . . . . . . . . . . . . . . . . 5
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 11
6. Route Information Advertisement . . . . . . . . . . . . . . . 15
7. Future Works . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The continuous topology change is a main characteristic of the LEO
constellation, which can be divided into the predictable topology
change and the unpredictable topology change. The predictable
topology change is caused by the periodic motion of the satellite,
while the unpredictable topology change is caused by emergencies.
With the increasing scale of satellite networks, the probability of
unpredictable topology changes is also increasing.
For the predictable topology change, the snapshot-based routing
method divides the satellite network motion period into multiple time
slices, and performs routing calculation based on time slices.
Unlike the predictable topology change, the unpredictable topology
change requires the corresponding protocol mechanism to capture
network anomalies and flooding the route information within a certain
range. However, the route information flooding without constraints
would cause significant bandwidth overhead as well as additional
routing convergence delay. Considering the limited on-board
resources, the above method is undoubtedly inefficient.
Hou, et al. Expires 20 August 2024 [Page 2]
Internet-Draft Lightweight Route Advertisement February 2024
The minimum requirement to complete the route information
advertisement within a certain network topology is to construct a
connected graph. Therefore, the route information only needs to be
advertised on the sub-topology of the physical topology. The sub-
topology is constructed by removing some links from the physical
topology, and has the same node reachability as the original network.
The minimum spanning tree is an available sub-topology. However, the
minimum spanning tree can not be used as a good sub-topology for
fault-prone large-scale networks such as the LEO mega-constellation.
Any failed link in these networks would decompose a tree-like
structure into two disjoint sub-topologies, and prevent information
advertisement. In addition, with the increasing scale of the
network, the time complexity of the algorithm to construct the sub-
topology is furhter increased.
Aiming at the above issues, this document provides a lightweight
route information advertisement mechanism in the LEO mega-
constellation. On the one hand, the mechanism selects the route
information advertisement link by the way of route-associated
judgment to reduce the overhead of route information advertisement.
On the other hand, the mechanism provides a method for dealing with
link fault during the route information advertisement process, to
ensure the reliability of routing information advertisement.
2. 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].
Hou, et al. Expires 20 August 2024 [Page 3]
Internet-Draft Lightweight Route Advertisement February 2024
* IGP: Interior Gateway Protocol, examples of IGPs inculde Open
Shortest Path First (OSPF [RFC2328]), route information Protocol
(RIP [RFC2453]), Intermediate System to Intermediate System (IS-IS
[RFC7142]) and Enhanced Interior Gateway Routing Protocol (EIGRP
[RFC7868]).
3. Basic Network Structure
In the LEO mega-constellation, 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.
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 has 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. As shown in Figure 1, if the satellite
contains a single antenna in each direction, the satellite Node E has
two links in the same orbit and two links in different adjacent
orbits with other satellites. 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.
| | |
+---+ +---+ +---+
---| A |-----| B |-----| C |---
+---+ +---+ +---+
| | |
| | |
+---+ +---+ +---+
---| D |-----| E |-----| F |---
+---+ +---+ +---+
| | |
| | |
+---+ +---+ +---+
---| G |-----| H |-----| I |---
+---+ +---+ +---+
| | |
Hou, et al. Expires 20 August 2024 [Page 4]
Internet-Draft Lightweight Route Advertisement February 2024
Figure 1: Node E and its adjacent satellites
The link delay is the main factor that affects the advertisement
efficiency. The longer the inter-satellite distance is, the longer
the advertisement propagation delay is. The propagation delay is
related to the accumulated delay of upstream links and the link delay
in the basic network structure. Figure 1 shows the basic network
topology which is managed by Node E, including 8 surrounding nodes of
Node E and links connecting these nodes. Since the satellite moves
regularly along the orbit, each node can maintain the propagation
delay of edges in the basic structure based on its own position and
orbit parameters. The propagation delay of the edge can be marked as
W, e.g. W_AB. Based on the accumulated delay of upstream links and
the link delay in the basic network structure, each node can realize
the route-associated judgment of information advertisement. It
should be noted that the basic structure in the real network is not
presented as a simple rectangle or square for the variation distances
between nodes.
4. Route-associated Judgment
As shown in Figure 1, Node E has four links connected to the neighbor
nodes. If the routing information is announced from one of these
four links, Node E judges whether to advertise the route information
to other neighbors based on the accumulated link delay and the link
delay in the basic network structure. The route information
advertisement is classified into the horizontal direction
advertisement and the vertical direction advertisement. According to
the receiving direction of the route information, the information
advertisement is divided into the fault related advertisements and
the non-fault related advertisements. The fault occurs in different
network locations can be divided into the horizontal direction
network fault and the vertical direction network fault.
Hou, et al. Expires 20 August 2024 [Page 5]
Internet-Draft Lightweight Route Advertisement February 2024
|
| | | | |
+---+ +---+ | +---+ +---+
--| |----| |-|--| |----| |--
+---+ +---+ | +---+ +---+
| | | | |
| | | | |
+---+ +---+ | +---+ +---+
--| |----| |-|--| |----| |--
+---+ +---+ | +---+ +---+
| | | | |
| | | | |
+---+ +---+\|/ +---+ +---+
--| |----| A |-X--| B |----| |--
+---+ +---+/|\ +---+ +---+
| | | | |
| | | | |
+---+ +---+ | +---+ +---+
--| |----| |-|--| |----| |--
+---+ +---+ | +---+ +---+
| | | | |
Left Part | Right Part
Figure 2: Horizontal direction network fault
|
| | | | |
+---+ +---+ | +---+ +---+
--| |----| |-|--| |----| |--
+---+ +---+ | +---+ +---+
| | | | |
| | -----> | |
+---+ +---+ | +---+ +---+
--| |----| A |-|--| C |----| |--
+---+ +---+ | +---+ +---+
| X | | |
| | | | |
+---+ +---+ | +---+ +---+
--| |----| B |-|--| D |----| |--
+---+ +---+ | +---+ +---+
| | --+--> | |
| | | | |
+---+ +---+ | +---+ +---+
--| |----| |-|--| |----| |--
+---+ +---+ | +---+ +---+
| | | | |
Left Part | Right Part
Hou, et al. Expires 20 August 2024 [Page 6]
Internet-Draft Lightweight Route Advertisement February 2024
Figure 3: Vertical direction network fault
According to different fault types, the route information
advertisement manner at the source node should be classified and
discussed. For a network fault in the horizontal direction, the
whole network topology is divided into a left part and a right part
by the vertical plane of the failed link as shown in Figure 2. The
source node advertises information from links except the failed link,
and all route information is not advertised across the left part and
the right part.
For a network fault in the vertical direction, the network topology
is divided into the left part and the right part by two adjacent
orbit planes where source nodes and corresponding neighbor nodes are
located. The source node advertises information from links except
the failed link. It should be noted that except for the first hop
advertisement in the horizontal direction, the route information is
not advertised across the left or right part. As shown in Figure 3,
Node C and Node D are the right neighbors of the source nodes A and B
of the failed link. And the network topology is divide into a left
part and a right part by the orbit planes of Node C, D, A, B.
1) Route Information From the Horizontal Direction
| | |
+---+ +---+ +---+
---| A |-----| B |-----| C |---
+---+ +---+ +---+
| | |
| | |
+---+ +---+ << +---+ << Routing
---| D |-----| E |-----| F |--- Info
+---+ +---+ +---+
| | |
| | |
+---+ +---+ +---+
---| G |-----| H |-----| I |---
+---+ +---+ +---+
| | |
Figure 4: Route information from the horizontal direction
When the route information is advertised from the horizontal
direction, the upstream node should inform the advertised node of the
accumulated link delays of itself and its adjacent nodes at the same
orbit. After receiving the route information and the accumulated
link delays, the advertised node judges whether to advertise the
Hou, et al. Expires 20 August 2024 [Page 7]
Internet-Draft Lightweight Route Advertisement February 2024
route information to the downstream node according to the network
information maintained by itself. As shown in Figure 4, the
advertised node informs the downstream node in the horizontal
direction by default. The basic process is as follows:
Step 1: The route information and the accumulated link delays are
advertised to Node E by Node F. The accumulated link delays refer to
the delays when the routing information reaches Node C, F, and I,
which are marked as Sum_C, Sum_F, and Sum_I.
Step 2: After receiving the route information, Node E needs to
determine whether to advertis the route information to the downstream
nodes, including Node B, D, and H.
For Node B: Node E evaluates the accumulated link delay at Node B
from the perspectives of Node F and Node C respectively, denoted as
Sum_FB=Sum_F+W_EF+W_BE and Sum_CB=Sum_C+W_BC. If Sum_FB is less than
Sum_CB, Node E advertises the route information to Node B, otherwise
Node E does not advertise.
For Node D: Node E advertises the route information to Node D by
default, and simultaneously informs the accumulated link delay when
the route information reaches Node B, E, and H, which are marked as
Sum_B, Sum_E, and Sum_H.
2) Route Information From the Vertical Direction
(1) Fault Related Link Scenario
When the route information is advertised from the vertical direction
link which is a fault related link, the upstream node advertises the
route information from the vertical direction by default, and informs
the advertised node the accumulated link delay of itself. After
receiving the route information and the accumulated link delay, the
advertised node continues to advertise to the downstream node in the
horizontal direction by default. As shown in Figure 5, Node K is a
node at the fault related link. The basic process is as follows:
Hou, et al. Expires 20 August 2024 [Page 8]
Internet-Draft Lightweight Route Advertisement February 2024
| | | |
+---+ +---+ +---+ +---+
--| A |----| B |----| C |----| D |--
+---+ +---+ +---+ +---+
| | | |
| | <<<<< | >>>>> |
+---+ +---+ +---+ +---+
--| E |----| F |----| G |----| H |--
+---+ +---+ +---+ +---+
| | ^ | |
| | ^ | |
+---+ +---+ +---+ +---+
--| I |----| J |----| K |----| L |--
+---+ +---+ +---+ +---+
| | ^ | |
^ Routing
^ Info
Figure 5: Fault related link scenario
Step 1: The route information and the accumulated link delay are
advertised to Node G by Node K. The accumulated link delay refers to
the delay when the route information reaches Node K, which is marked
as SUM_K.
Step 2: According to Sum_K and the link delay maintained by Node G,
Node G informs Node F of the accumulated link delay estimations when
the route information reaches Node C, G, and K, which are recorded as
Sum_C, Sum_G, and Sum_K. Sum_C and Sum_G could be denoted as
Sum_C=Sum_K+W_CG+W_GK and Sum_G=Sum_K+W_GK respectively.
Step 3: After the route information reaches Node F, the route
information advertisement method of Node F regresses to the process
described in 1).
As mentioned earlier, the route information is not advertised across
the left part and right part. When the route information is
advertised from the vertical direction link which is a fault related
link, the route information would only be advertised to the neighbor
nodes at one side in the horizontal direction. There is no need to
limit the notified side, and the notified side may be unified in
advance when performing the associated judgement of the route
information advertisement. As shown in Figure 6, if Node G
advertises routing information to Node F, it would not advertise to
Node H. Except for special cases, when a link fault occurs in the
vertical direction link, the source node will advertise to the
neighbor nodes on both sides in the horizontal direction.
Hou, et al. Expires 20 August 2024 [Page 9]
Internet-Draft Lightweight Route Advertisement February 2024
(2) Non-fault Related Link Scenario
| | | |
+---+ << +---+ << +---+ << +---+ <<
--| A |----| B |----| C |----| D |--
+---+ +---+ +---+ +---+ Routing
v| v| v| | Info
v| v| v| |
+---+ +---+ +---+ << +---+ <<
--| E |----| F |----| G |----| H |--
+---+ +---+ +---+ +---+
v| v| v| |
v| v| v| |
+---+ +---+ << +---+ << +---+ <<
--| I |----| J |----| K |----| L |--
+---+ +---+ +---+ +---+
| | | |
Figure 6: Non-fault related link scenario
When the route information is announced from the vertical direction
link which is a non-fault related link, the upstream node announces
the route information in the vertical direction by default, and does
not inform the advertised node of the accumulated link delay of
itself. After receiving the route information, the advertised node
continues to inform the downstream node along the vertical direction
by default. The downstream node continues to advertise the route
information in the vertical direction until the arriving node has
received the same route information previously.
If a node has received a route information, the subsequent same route
information will not be announced to the downstream node. Meanwhile,
the route information announced by the non-fault related link along
the vertical direction will not be announced along the horizontal
direction. As shown in Figure 6, Node D, H, and L advertise route
information as upstream nodes. The basic process is as follows:
Step 1:
After receiving the route information from Node D, Node C judges
based on the process described in 1) and advertises the route
information to Node G and Node B. Meanwhile, Node H advertises to
Node G by default.
Step 2:
Hou, et al. Expires 20 August 2024 [Page 10]
Internet-Draft Lightweight Route Advertisement February 2024
For Node G: After receiving the route information from Node C, since
Node G is in the non-fault related link and Node C advertises to Node
G in the vertical direction, Node G continues to advertise the route
information to Node K along the vertical direction where the link
between Node C and Node G is located by default. At the same time,
relevant messages are no longer announced to Node F. The
subsequently received route information advertised by Node H will be
discarded by Node G.
Assuming that Node K has received the information at Node L in
advance, Node K decides to announce the route information to Node J
based on the process described in 1). Meanwhile, the subsequent
route information from Node G will be blocked at Node K.
Step 3:
For Node B: The route information and the accumulated link delay are
announced to Node B by Node C. Since the horizontal links where Node
B and Node C are located have a lower delay than the horizontal links
where Node F and Node G are located, the subsequent nodes of the
horizontal link where Node B and Node C are located will advertise
the route information downward by default.
After receiving the advertisement of Node C, Node B decides to
advertise the route information to Node A and Node F according to the
process described in 1).
Step 4:
For Node F: After receiving the route information, Node F continues
to inform Node J. If the information transmitted by Node F arrives
earlier than the information at Node K, Node J continues to announce
along the vertical direction link, and at the same time, the
subsequently received message sent by Node K to Node J is no longer
announced to Node I.
5. Error Handling
The above method can ensure the synchronization of the route
information among the nodes in the certain network range. However,
the single point fault would cause the synchronization error of route
information during the advertisement process. There are two types of
single point fault, including the horizontal fault and the vertical
fault. In this section, the fault handling method is discussed. It
should be noted that if a link affected by a single point fault is
not the link selected by the route-associated judgment, the route
information advertisement process is not affected by the single point
fault, as shown in Figure 7.
Hou, et al. Expires 20 August 2024 [Page 11]
Internet-Draft Lightweight Route Advertisement February 2024
| | |
+---+ << +---+ << +---+ <<
---| A |-----| B |-----| C |---
+---+ +---+ +---+ Routing
v| v| | Info
v| v| |
+---+ \ / +---+ << +---+ <<
---| D |--X--| E |-----| F |---
+---+ / \ +---+ +---+
v| v| |
v| v| |
+---+ << +---+ << +---+ <<
---| G |-----| H |-----| I |---
+---+ +---+ +---+
| | |
Figure 7: Horizontal direction fault without impact
1) Handling Method For the Horizontal Direction Fault
When the vertical route information arrives later than the horizontal
route information or there is no vertical route information
advertisement, the single point fault would affect the route
information advertisement process. In this case, the detour link
with the smaller total delay is selected to advertise the route
information. In order to ensure the consistency of the accumulated
link delay, the detour link delay is not added to the accumulated
link delay, and the accumulated link delay in the normal state is
still used as the basis for determining the route information
advertisement of the downstream node.
| | | |
+---+ << +---+ << +---+ << +---+ <<
--| X |----| A |----| B |----| C |--
+---+ +---+ +---+ +---+ Routing
| v| ^| | Info
| v| ^| |
+---+ << +---+ \ /+---+ << +---+ <<
--| Y |----| D |--X-| E |----| F |--
+---+ +---+ / \+---+ +---+
| | | |
| | | |
+---+ << +---+ << +---+ << +---+ <<
--| Z |----| G |----| H |----| I |--
+---+ +---+ +---+ +---+
| | | |
Hou, et al. Expires 20 August 2024 [Page 12]
Internet-Draft Lightweight Route Advertisement February 2024
Figure 8: Horizontal direction fault with impact
As shown in Figure 8, the link between Node D and Node E is
interrupted. When the route information arrives at Node E, the route
information would pass through Node B and Node A in turn which has
lower path delay compared with the other detour paths. At the same
time, Node E would inform Node D the accumulated link delays at Node
B, E, H.
2) Handling Method For the Vertical Direction Fault
The vertical direction fault during the advertisment process could be
divided into two scenarios, including the non-fault related link and
the fault-related link. The fault handling methods for these cases
are described below.
(1) Fault Related Link Scenario
In the fault related link scenario, the route information advertised
from the upstream node would bypass to one side at the fault point
and reach the adjacent orbit. The advertisement process would be
restarted at the adjacent orbit, as shown in Figure 9. The basic
process is as follows:
| | |
+---+ << +---+ >> +---+
---| A |-----| B |-----| C |---
+---+ +---+ +---+
| ^| |
| ^| |
+---+ << +---+ >> +---+
---| D |-----| E |-----| F |---
+---+ +---+ +---+
| ^| |
| ^| X
+---+ << +---+ << +---+
---| G |-----| H |-----| I |---
+---+ +---+ +---+
| | ^|
^
Routing
Info
Figure 9: Fault related link scenario
Hou, et al. Expires 20 August 2024 [Page 13]
Internet-Draft Lightweight Route Advertisement February 2024
Step 1: For the link fault between Node I and Node F, Node I informs
the route information and the acculumated link delay Sum_I from the
neighbor orbit.
Step 2: After Node H receives the route information and Sum_I, it
continues to inform Node G by default. At the same time, Node H
advertises the route information and Sum_H to Node E in the vertical
direction. Sum_H could be represented by following Formula.
Sum_H=Sum_I+W_HI
Step 3: After Node E receives the route information and Sum_H, it
continues to inform Node D by default. At the same time, Node E
advertises the route information and Sum_E to Node B in the vertical
direction. Sum_E could be represented by following Formula.
Besides, Node E advertises the route information to Node F by
default.
Sum_E=Sum_H+W_HE
Step 4: Node B and subsequent downstream nodes repeat the above
process until a downstream node in the vertical direction which has
received the same route information.
(2) Non-fault Related Link Scenario
In the non-fault related link scenario, the route information from
the upstream node would detour to the unadvertised downstream node
side at the fault point, as shown in Figure 10.
| | |
+---+ << +---+ << +---+ <<
---| A |-----| B |-----| C |---
+---+ +---+ +---+
v| X v| Routing
v| | v| Info
+---+ >> +---+ +---+ <<
---| D |-----| E |-----| F |---
+---+ +---+ +---+
v| v| v|
v v v
Figure 10: Non-fault related link scenario
Step 1: For the link fault between Node B and Node E, Node B
announces the route information from the neighbor orbit.
Hou, et al. Expires 20 August 2024 [Page 14]
Internet-Draft Lightweight Route Advertisement February 2024
Step 2: Node A continues to inform Node D after receiving the route
information.
Step 3: After receiving the route information, Node D informs Node E,
so as to complete the detour process of the route information
advertisement.
6. Route Information Advertisement
As shown in Figure 11, a fault occurs in the link between A1 and A2
at a certain time. The network topology is divided into the left
part and the right part by the vertical plane of the fault link. For
the left part, starting from the link fault point A2, the route
information is advertised to the neighbor nodes in the three
direction of up(B2), down(E2), and left(A3). The specific process is
as follows:
Boundary Boundary
| ^ ^ ^ ^ ^ |
| ^ | ^ | ^ | ^ | ^ | | |
| +---+ +---+ +---+ +---+ +---+ | +---+
| | Dn|-- --| D5|----| D4|-- --| D3|----| D2|--+-| D1|
| +---+ ... +---+ +---+ ... +---+ +---+ | +---+
| ^ | ^ | ^ | ^ | ^ | | |
| ^ ... ^ ... ^ ... ^ ... ^ ... | ...
| ^ | ^ | ^ | ^ | ^ | | |
| +---+ <<<< +---+ <<<+---+ <<<< +---+ <<<+---+ | +---+
| | Cn|-- --| C5|----| C4|-- --| C3|----| C2|--+-| C1|
| +---+ ... +---+ +---+ ... +---+ ^+---+ | +---+
| v | v | v | | ^ | | |
| v | v | v | | ^ | | |
| v+---+ v+---+ v+---+ <<<< +---+ <<<+---+ | +---+
| | Bn|-- --| B5|----| B4|-- --| B3|----| B2|--+-| B1|
| +---+ ... +---+ +---+ ... +---+ ^+---+ | +---+
| v | v | v | | ^ | | |
| v | v | v | | ^ | | |
| v+---+ v+---+ <<<+---+ <<<< +---+ <<<+---+ \|/+---+
| | An|-- --| A5|----| A4|-- --| A3|----| A2|--X-| A1|
| +---+ ... +---+ +---+ ... +---+ +---+ /|\+---+
| | | | | | | |
|----+-----------+--------+-----------+--------+----+---+----
| +---+ +---+ +---+ +---+ +---+ | +---+
| | En|-- --| E5|----| E4|-- --| E3|----| E2|--+-| E1|
| +---+ ... +---+ +---+ ... +---+ +---+ | +---+
| |
|<------------------------------------------------->|<----->|
Left Part Right Part
Hou, et al. Expires 20 August 2024 [Page 15]
Internet-Draft Lightweight Route Advertisement February 2024
Figure 11: Route information advertisement
1) Advertisement Process From A2 to A3
The advertisement process from A2 to A3 is as follows.
Step 1: A2 informs A3 of the route information and the accumulated
link delays which include Sum_B2, Sum_E2, and Sum_A2. In combination
with its own position and orbit parameters, A2 regularly maintains
the network information in the basic structure. The accumulated link
delays could be represented by following formulas.
Sum_B2=W_A2B2
Sum_E2=W_A2E2
Sum_A2=0
Step 2: After receiving the route information, A3 needs to determine
whether to announce the route information to B3, A4, and E3.
If Sum_A2+W_A2A3+W_A3B3 is less than Sum_B2+W_B2B3, A3 advertises the
route information to B3, otherwise, no advertisement is required.
If Sum_A2+W_A2A3+W_A3E3 is less than Sum_E2+W_E2E3, A3 advertises the
route information to E3, otherwise, no advertisement is required.
By default, A3 informs A4 of the route information and the
accumulated link delays which include Sum_B3, Sum_E3, and Sum_A3. In
combination with its own position and orbit parameters, A3 regularly
maintains the network information in the basic structure. The
accumulated link delays could be represented by following formulas.
Sum_B3=Sum_B2+W_B2B3
Sum_E3=Sum_E2+W_E2E3
Sum_A3=W_A2A3
The process of above route information advertisement from A3 to A4 is
repeated until the edge node of the left part is reached or the route
information on the vertical direction is received.
2) Advertisement Process From A2 to B2
Step 1: A2 informs B2 of the route information and the accumulated
link delay corresponding to the arrival of the route information at
A2 which is marked as Sum_A2=0.
Hou, et al. Expires 20 August 2024 [Page 16]
Internet-Draft Lightweight Route Advertisement February 2024
Step2: After receiving the route information, B2 continues to
advertise the route information as well as the accumulated link
delays to C2 and B3.
For Node C2: The advertisement process from B2 to C2 is consistent
with the scenario summarized in the previous section. B2 informs C2
of the accumulated link delays. The route information advertisement
process from B2 to C2 continues to repeat and reach the D2 in the
near-polar region of the western hemisphere. The route information
passes through the polar region until it reaches the node at the
semi-perimeter position of the same orbital plane.
For Node B3: The advertisement process from B2 to B3 is consistent
with the scenario summarized in the previous section. B2 needs to
inform B3 of the accumulated link delays which include Sum_A2, Sum_B2
and Sum_C2. In combination with its own position and orbit
parameters, B2 regularly maintains the network information in the
basic structure. The accumulated link delays could be represented by
following formulas.
Sum_A2=0
Sum_B2=W_A2B2
Sum_C2=Sum_B2+W_B2C2
Step 3: The route information announced by C3 reaches C4 after
multiple hops, and C4 makes a judgment according to the horizontal
link announcement process summarized in the previous section, and
announces the route information to B4.
Step 4: After the B4 receives the vertical route information, on the
one hand, the subsequent horizontal advertisement received by the B4
will be stopped, and the information will not be advertised to the
next-hop horizontal node B5, on the other hand, the B4 advertises the
information to the A4 along the vertical direction, and if the A4 has
received the route information, the advertisement will be stopped,
otherwise, the advertisement will continue.
3) Advertisement Process From A2 to E2
The advertisement process from A2 to E2 is the same as the
advertisement process from A2 to B2, and the route information
advertisement process on the right side of the vertical line is the
same as the route information advertisement process on the left side
of the vertical line, which is not described here.
Hou, et al. Expires 20 August 2024 [Page 17]
Internet-Draft Lightweight Route Advertisement February 2024
7. Future Works
In this document, the method of route information advertisement in
the LEO mega-constellation is discussed. It should be noted that the
satellite network is one of the application scenarios. The LEO mega-
constellation network constructs a mesh topology. For other
scenarios which have the same network topology property, this method
could also be applied.
In the future work, the extension of the current routing protocol to
support the method of route information advertisement described in
this document would be taken in mind.
8. Security Considerations
TBA.
9. Acknowledgements
TBA.
10. IANA Considerations
This document has no IANA action requested.
11. References
11.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>.
11.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>.
Hou, et al. Expires 20 August 2024 [Page 18]
Internet-Draft Lightweight Route Advertisement February 2024
[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>.
[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
Hou, et al. Expires 20 August 2024 [Page 19]
Internet-Draft Lightweight Route Advertisement February 2024
Fenlin Zhou
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: zhou.fenlin@zte.com.cn
Hou, et al. Expires 20 August 2024 [Page 20]
