<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-hou-satellite-route-advertisement-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.3 -->
  <!-- ***** FRONT MATTER ***** -->

    <front>
    <title abbrev="Lightweight Route Advertisement">Lightweight Route Information Advertisement for LEO Mega-constellation</title>
    <seriesInfo name="Internet-Draft" value="draft-hou-satellite-route-advertisement-00"/>
    <author fullname="Hou Dongxu" initials="H." role="editor" surname="Hou">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <phone/>
        <email>hou.dongxu@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Xiao Min" initials="X." surname="Min">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <phone/>
        <email>xiao.min2@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Fenlin Zhou" initials="F" surname="Zhou">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>zhou.fenlin@zte.com.cn</email>
      </address>
    </author>
    <date month="Feb" year="2024"/>
    <!--<area>General</area>-->
    <!--<workgroup>Internet Engineering Task Force</workgroup>-->
    <area>Routing</area>
    <workgroup></workgroup>
    <keyword>Satellite network</keyword>
    <keyword>Route advertisement</keyword>
    <keyword/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

    <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <ul spacing="normal">
        <li>VLEO: Very Low Earth Orbit with the altitude below 450 km.</li>
        <li>LEO: Low Earth Orbit with the altitude between 180 km and 2000 km.</li>
        <li>MEO: Medium Earth Orbit with the altitude between 2000 km and 35786 km.</li>
        <li>GEO: Geosynchronous Orbit with the altitude 35786 km.</li>
        <li>Intra-satellite links: Links between adjacent satellites in the same orbit.</li>
        <li>Intra-satellite links: Links between adjacent satellites in the different orbits.</li>
        <li>SGP4: Simplified Perturbations Models.</li>
        <li>BGP: Border Gateway Protocol [RFC4271].</li>
        <li>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]).</li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>Basic Network Structure</name>
      <t>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.</t>
      <t>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.</t>
      <figure>
        <name>Node E and its adjacent satellites</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     |         |         |
   +---+     +---+     +---+
---| A |-----| B |-----| C |---
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+     +---+
---| D |-----| E |-----| F |---
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+     +---+
---| G |-----| H |-----| I |---
   +---+     +---+     +---+
     |         |         |   
	                   ]]></artwork>
      </figure>
      <t>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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Route-associated Judgment</name>
      <t>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. </t>
      <figure>
        <name>Horizontal direction network fault</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
                 |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----|   |-|--|   |----|   |--
  +---+    +---+ |  +---+    +---+
    |        |   |    |        |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----|   |-|--|   |----|   |--
  +---+    +---+ |  +---+    +---+
    |        |   |    |        |
    |        |   |    |        |
  +---+    +---+\|/ +---+    +---+
--|   |----| A |-X--| B |----|   |--
  +---+    +---+/|\ +---+    +---+
    |        |   |    |        |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----|   |-|--|   |----|   |--
  +---+    +---+ |  +---+    +---+
    |        |   |    |        |
    Left Part    |    Right Part
	                   ]]></artwork>
      </figure>
      <figure>
        <name>Vertical direction network fault</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
                 |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----|   |-|--|   |----|   |--
  +---+    +---+ |  +---+    +---+
    |        |   |    |        |
    |        | -----> |        |
  +---+    +---+ |  +---+    +---+
--|   |----| A |-|--| C |----|   |--
  +---+    +---+ |  +---+    +---+
    |        X   |    |        |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----| B |-|--| D |----|   |--
  +---+    +---+ |  +---+    +---+
    |        | --+--> |        |
    |        |   |    |        |
  +---+    +---+ |  +---+    +---+
--|   |----|   |-|--|   |----|   |--
  +---+    +---+ |  +---+    +---+
    |        |   |    |        |
    Left Part    |    Right Part
	                   ]]></artwork>
      </figure>
      <t>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.</t>
      <t>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.</t>
      <t>1) Route Information From the Horizontal Direction</t>
      <figure>
        <name>Route information from the horizontal direction</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     |         |         |
   +---+     +---+     +---+
---| A |-----| B |-----| C |---
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+ <<  +---+ << Routing
---| D |-----| E |-----| F |--- Info
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+     +---+
---| G |-----| H |-----| I |---
   +---+     +---+     +---+
     |         |         | 
	                   ]]></artwork>
      </figure>
      <t>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 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:</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>2) Route Information From the Vertical Direction</t>
      <t>(1) Fault Related Link Scenario</t>
      <t>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:</t>
      <figure>
        <name>Fault related link scenario</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
    |        |        |        |
  +---+    +---+    +---+    +---+
--| A |----| B |----| C |----| D |--
  +---+    +---+    +---+    +---+
    |        |        |        |
    |        |  <<<<< | >>>>>  |
  +---+    +---+    +---+    +---+
--| E |----| F |----| G |----| H |--
  +---+    +---+    +---+    +---+
    |        |      ^ |        |
    |        |      ^ |        |
  +---+    +---+    +---+    +---+
--| I |----| J |----| K |----| L |--
  +---+    +---+    +---+    +---+
    |        |      ^ |        |
                    ^ Routing
                    ^ Info
	                   ]]></artwork>
      </figure>
      <t>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.</t>
      <t>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.</t>
      <t>Step 3: After the route information reaches Node F, the route information advertisement 
                method of Node F regresses to the process described in 1).</t>
      <t>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.</t>
      <t>(2) Non-fault Related Link Scenario</t>
      <figure>
        <name>Non-fault related link scenario</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
    |        |        |        |
  +---+ << +---+ << +---+ << +---+ <<
--| 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 |--
  +---+    +---+    +---+    +---+
    |        |        |        |
	                   ]]></artwork>
      </figure>
      <t>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. </t>
      <t>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:</t>
      <t>Step 1:</t>
      <t>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.</t>
      <t>Step 2:</t>
      <t>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.</t>
      <t>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.</t>
      <t>Step 3:</t>
      <t>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.</t>
      <t>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).</t>
      <t>Step 4:</t>
      <t>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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Error Handling</name>
      <t>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. </t>
      <figure>
        <name>Horizontal direction fault without impact</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     |         |         |
   +---+ <<  +---+ <<  +---+ <<
---| A |-----| B |-----| C |---
   +---+     +---+     +---+   Routing
    v|        v|         |     Info
    v|        v|         |
   +---+ \ / +---+ <<  +---+ <<
---| D |--X--| E |-----| F |---
   +---+ / \ +---+     +---+
    v|        v|         |
    v|        v|         |
   +---+ <<  +---+ <<  +---+ <<
---| G |-----| H |-----| I |---
   +---+     +---+     +---+
     |         |         |
	                   ]]></artwork>
      </figure>
      <t>1) Handling Method For the Horizontal Direction Fault</t>
      <t>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.</t>
      <figure>
        <name>Horizontal direction fault with impact</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
    |        |        |        |
  +---+ << +---+ << +---+ << +---+ <<
--| X |----| A |----| B |----| C |--
  +---+    +---+    +---+    +---+   Routing
    |       v|       ^|        |     Info
    |       v|       ^|        |
  +---+ << +---+ \ /+---+ << +---+ <<
--| Y |----| D |--X-| E |----| F |--
  +---+    +---+ / \+---+    +---+
    |        |        |        |
    |        |        |        |
  +---+ << +---+ << +---+ << +---+ <<
--| Z |----| G |----| H |----| I |--
  +---+    +---+    +---+    +---+
    |        |        |        |
	                   ]]></artwork>
      </figure>
      <t>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.</t>
      <t>2) Handling Method For the Vertical Direction Fault</t>
      <t>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.</t>
      <t>(1) Fault Related Link Scenario</t>
      <t>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:</t>
      <figure>
        <name>Fault related link scenario</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     |         |         |
   +---+ <<  +---+  >> +---+
---| A |-----| B |-----| C |---
   +---+     +---+     +---+
     |        ^|         |
     |        ^|         |
   +---+ <<  +---+  >> +---+
---| D |-----| E |-----| F |---
   +---+     +---+     +---+
     |        ^|         |
     |        ^|         X
   +---+ <<  +---+ <<  +---+
---| G |-----| H |-----| I |---
   +---+     +---+     +---+
     |         |        ^|
                        ^
                       Routing
                       Info
	                   ]]></artwork>
      </figure>
      <t>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.</t>
      <t>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.</t>
      <t>Sum_H=Sum_I+W_HI</t>
      <t>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.</t>
      <t>Sum_E=Sum_H+W_HE</t>
      <t>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.</t>
      <t>(2) Non-fault Related Link Scenario</t>
      <t>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.</t>
      <figure>
        <name>Non-fault related link scenario</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
     |         |         |
   +---+ <<  +---+ <<  +---+ <<
---| A |-----| B |-----| C |---
   +---+     +---+     +---+
    v|         X        v|    Routing
    v|         |        v|    Info
   +---+ >>  +---+     +---+ <<
---| D |-----| E |-----| F |---
   +---+     +---+     +---+
    v|        v|        v|
    v         v         v
	                   ]]></artwork>
      </figure>
      <t>Step 1: For the link fault between Node B and Node E, Node B announces the route information 
                from the neighbor orbit.</t>
      <t>Step 2: Node A continues to inform Node D after receiving the route information.</t>
      <t>Step 3: After receiving the route information, Node D informs Node E, so as to complete the 
                detour process of the route information advertisement.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Route Information Advertisement</name>
      <t>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:</t>
      <figure>
        <name>Route information advertisement</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[ 
 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
	                   ]]></artwork>
      </figure>
      <t>1) Advertisement Process From A2 to A3</t>
      <t>The advertisement process from A2 to A3 is as follows.</t>
      <t>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.</t>
      <t>Sum_B2=W_A2B2</t>
      <t>Sum_E2=W_A2E2</t>
      <t>Sum_A2=0</t>
      <t>Step 2: After receiving the route information, A3 needs to determine whether to announce 
                the route information to B3, A4, and E3.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>Sum_B3=Sum_B2+W_B2B3</t>
      <t>Sum_E3=Sum_E2+W_E2E3</t>
      <t>Sum_A3=W_A2A3</t>
      <t>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.</t>
      <t>2) Advertisement Process From A2 to B2</t>
      <t>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.</t>
      <t>Step2: After receiving the route information, B2 continues to advertise the route information 
                as well as the accumulated link delays to C2 and B3.</t>
      <t>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.</t>
      <t>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.</t>
      <t>Sum_A2=0</t>
      <t>Sum_B2=W_A2B2</t>
      <t>Sum_C2=Sum_B2+W_B2C2</t>
      <t>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.</t>
      <t>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.</t>
      <t>3) Advertisement Process From A2 to E2</t>
      <t>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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Future Works</name>
      <t>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.</t>
      <t>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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBA.</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBA.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA action requested.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

    <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-tvr-use-cases" target="https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-cases-00" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tvr-use-cases.xml">
          <front>
            <title>TVR (Time-Variant Routing) Use Cases</title>
            <author fullname="Edward J. Birrane" initials="E. J." surname="Birrane">
              <organization>JHU/APL</organization>
            </author>
            <author fullname="Nicolas Kuhn" initials="N." surname="Kuhn">
              <organization>Thales Alenia Space</organization>
            </author>
            <author fullname="Yingzhen Qu" initials="Y." surname="Qu">
              <organization>Futurewei Technologies</organization>
            </author>
            <date day="15" month="April" year="2023"/>
            <abstract>
              <t>Time-Variant Routing (TVR) refers to the calculation of a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces use cases where TVR computations could improve message exchange in a network.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-use-cases-00"/>
        </reference>
        <reference anchor="I-D.hou-tvr-satellite-network-usecases" target="https://datatracker.ietf.org/doc/html/draft-hou-tvr-satellite-network-usecases-01" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.hou-tvr-satellite-network-usecases.xml">
          <front>
            <title>Satellite Network Routing Use Cases</title>
            <author fullname="Hou Dongxu" initials="H." surname="Dongxu">
              <organization>ZTE Corporation</organization>
            </author>
            <author fullname="Xiao Min" initials="X." surname="Min">
              <organization>ZTE Corporation</organization>
            </author>
            <author fullname="Fenlin Zhou" initials="F." surname="Zhou">
              <organization>ZTE Corporation</organization>
            </author>
            <author fullname="Dongyu Yuan" initials="D." surname="Yuan">
              <organization>ZTE Corporation</organization>
            </author>
            <date day="13" month="March" year="2023"/>
            <abstract>
              <t>Time-Variant Routing (TVR) is chartered and proposed to solve the problem of time-based, scheduled changes, including the variations of links, adjacencies, cost, and traffic volumes in some cases. In a satellite network, the network is in continual motion which will cause detrimental consequences on the routing issue. However, each network node in a satellite network follows a predefined orbit around the Earth and represents an appropriate example of time-based scheduled mobility. Therefore, TVR can be implemented to improve the routing and forwarding process in satellite networks. This document mainly focuses on the use cases in this scenario.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-hou-tvr-satellite-network-usecases-01"/>
        </reference>
        <reference anchor="I-D.lhan-satellite-semantic-addressing" target="https://datatracker.ietf.org/doc/html/draft-lhan-satellite-semantic-addressing-03" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.lhan-satellite-semantic-addressing.xml">
          <front>
            <title>Satellite Semantic Addressing for Satellite Constellation</title>
            <author fullname="Lin Han" initials="L." surname="Han">
              <organization>Futurewei Technologies, Inc.</organization>
            </author>
            <author fullname="Richard Li" initials="R." surname="Li">
              <organization>Futurewei Technologies, Inc.</organization>
            </author>
            <author fullname="Alvaro Retana" initials="A." surname="Retana">
              <organization>Futurewei Technologies, Inc.</organization>
            </author>
            <author fullname="chenmeiling" initials="" surname="chenmeiling">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Ning Wang" initials="N." surname="Wang">
              <organization>University of Surrey</organization>
            </author>
            <date day="3" month="March" year="2023"/>
            <abstract>
              <t>This document presents a semantic addressing method for satellites in satellite constellation connecting with Internet. The satellite semantic address can indicate the relative position of satellites in a constellation. The address can be used with traditional IP address or MAC address or used independently for IP routing and switching.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-lhan-satellite-semantic-addressing-03"/>
        </reference>
        <reference anchor="StarLink" target="https://en.wikipedia.org/wiki/Starlink">
          <front>
            <title>Starlink</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="KUIPER" target="https://tinyurl.com/bs7syjnk">
          <front>
            <title>Amazon receives FCC approval for project Kuiper satellite constellation.</title>
            <author initials="" surname="">
              <organization/>
            </author>
          </front>
        </reference>
        <reference anchor="ThreeGPP" target="https://www.3gpp.org/">
          <front>
            <title>3GPP</title>
            <author/>
            <date/>
          </front>
        </reference>
        <reference anchor="Large-Scale-LEO-Network-Routing" target="https://ojs.wiserpub.com/index.php/CNC/article/view/2105">
          <front>
            <title>Large Scale LEO Satellite Networks for the Future Internet: Challenges and Solutions to Addressing and Routing," Computer Networks and Communications, 1(1), 31-58</title>
            <author/>
            <date/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>
