Skip to main content

Lightweight Route Information Advertisement for LEO Mega-constellation
draft-hou-satellite-route-advertisement-00

Document Type Active Internet-Draft (individual)
Authors Hou Dongxu , Xiao Min , Fenlin Zhou
Last updated 2024-02-17
Replaces draft-hou-lsr-satellite-route-advertisement
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hou-satellite-route-advertisement-00
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]