<?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="std" docName="draft-hou-satellite-routing-framework-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="Routing Framework for LEO Constellation">Routing Framework for LEO Mega-constellation Based on Region Division</title>
    <seriesInfo name="Internet-Draft" value="draft-hou-satellite-routing-framework-00"/>
    <author fullname="Dongxu Hou" initials="D" 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>
        <email>hou.dongxu@zte.com.cn</email>
      </address>
    </author>
    <!--
    <author fullname="Xiao Min" initials="M" surname="Xiao">
      <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>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 day="20" month="June" year="2023"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Satellite</keyword>
    <keyword>Constellation</keyword>
    <keyword>Routing</keyword>
    <abstract>
      <t>The inter-satellite routing is the premis to ensure that the satellite network provides 
                end-to-end stable service covering the whole world. However, the mature terrestrial 
                network technologies are difficult to directly apply to the satellite network for the 
                highly dynamic network topology and the limited on-board resources. This issue is 
                further exacerbated in LEO mega-constellations. In view of this challenge, this 
                document presents a routing framework for LEO mega-constellation. Based on the orbit 
                position characteristic and the predictable topology, this framwork realizes flexible 
                region division, establishes intra-region and inter-region path, as well as completes 
                end-to-end data forwarding.</t>
    </abstract>
  </front>
  <!-- ***** MIDDLE MATTER ***** -->

    <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The LEO mega-constellation networks can overcome the limitations of the conventional 
                terrestial network, achieving global signal coverage, and providing large broadband 
                as well as low-latency network services for global users. The global communications 
                ecosystem believes that satellite-based communication will become an importan part 
                of 5G-advanced and 6G.</t>
      <t>Routing issues are the premise to ensure the stable worldwide end-to-end service based 
                on the satellite network. Compared with the terrestial network, the satellite network 
                has the characteristics of highly dynamic nodes, time-varying network topology, and 
                limited on-board resources. So the mature terrestrial nework routing technology is 
                difficult to directly apply.</t>
      <t>In view of this situation, some improved routing methods have been proposed based 
                on the predictable topology changes in the satellite network. However, the development 
                trend of the satellite network is becoming more and more low-orbit and large-scale, 
                which further intensifies the dynamic property of the network. More topology 
                changes as well as information announcements are happend, which would result in 
                frequent routing calculations, much more protocol overhead, and even route flapping.</t>
      <t>To trackle the above issue, the terrestial network generally adopts the manner of 
                area division to imporve the efficiency of routing convergence and network management. 
                The existing area division method typically divides a network into a backbone area 
                and multiple non-backbone areas. The backbone area is unique and has routing 
                informations of all areas. The non-backbone areas establish fixed connections around 
                the backbone area. Thus, nodes in the backbone area are responsible for traffic 
                forwarding between all areas, and require higher performance. However, the performance 
                of satellites is peer-to-peer and limited, especially in the single-layer satellite 
                constellation. The current area division method could easily make the backbone area 
                congested in the satellite network. Besides, due to the permanent changes of the 
                satellite network topology, the connection relationship between different areas is 
                unable to maintain stability, and each area need to exchange routing informations 
                continuously. So the existing area division method is not only inefficient but also 
                lacks sufficient flexibility, and can't meet the requirement of routing in the 
                satellite network.</t>
      <t>Considering these problems, this document proposes a routing framework for LEO 
                mega-constellation networks based on region division. The details of this framework 
                are as follows:</t>
      <t>(1) Firstly, based on the relative position between satellites, the new node type and 
                capability are defined to realize flexible region divesion.</t>
      <t>(2) Then, the mapping relationship between nodes and regions is established based on 
                the satellite orbit position to reduce the inter-region network information 
                announcement.</t>
      <t>(3) Finally, based on the predictable network topology in the satellite network, the 
                inter-region and intra-region paths are constructed to complete the end-to-end data 
                forwarding.</t>
      <t>Further details are discussed in subsequent sections.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Requirements Language</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
                NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are
                to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/>
        <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as
                shown here.</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]), Routing 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>Region Planning</name>
      <section numbered="true" toc="default">
        <name>Region Model</name>
        <t>In the satellite network, each satellite moves along the orbit, which can be divided 
                    into circular orbit satellites and elliptical orbit satellites. Different orbits 
                    can be described by Keplerian parameters. At present, the mainstream of satellite 
                    networks basically adopt circular orbit.</t>
        <figure>
          <name>N5 and its adjacent satellites</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
    Orbit     Orbit     Orbit
   Plane 1   Plane 2   Plane 3
  
     |         |         |    
   +---+     +---+     +---+    
---| 1 |-----| 4 |-----| 7 |---
   +---+     +---+     +---+    
     |         |         |    
     |         |         |        
   +---+     +---+     +---+  
---| 2 |-----| 5 |-----| 8 |---
   +---+     +---+     +---+  
     |         |         |        
     |         |         |        
   +---+     +---+     +---+    
---| 3 |-----| 6 |-----| 9 |---
   +---+     +---+     +---+    
     |         |         |    
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <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 may have four types of 
                    contiguous neighbour satellites and each type refers to a direction. The number of 
                    neighbor satellites distributed in one direction is determined by the number of 
                    antennas deployed on the satellite for communication. If the satellite contains a 
                    single antenna in each direction, the connection relationship between the satellite N5 
                    and its two satellites in the same orbit and two satellites in different adjacent orbits
                    is shown in Figure 1. In a multi-tier satellite constellation, each satellite may 
                    have two additional types of adjacent satellites, upper level satellites and lower 
                    level satellites in different tiers.</t>
        <t>Therefore, the quadrangle is adopted as the basic model of region division, that is, a 
                    region also have four types of contiguous neighbour regions and each type refers to a 
                    direction, as shown in Figure 2. In this way, satellites in each region and the 
                    adjacency relationship between regions could remain unchanged with the dynamic change 
                    of satellite topology.</t>
        <figure>
          <name>Basic model of region division</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--+--| 2 |
+---+  |  +---+     +---+     +---+  |  +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |   l=3
       |  +---+     +---+     +---+  |
      h=3 | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+  
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section numbered="true" toc="default">
        <name>Mapping Relationship</name>
        <t>In a satellite constellation which has M orbit planes and N nodes per orbit plane, 
                    the orbit position information of a satellite can be marked with (X, Y), namely the 
                    node identifier. The corresponding region number k of this satellite can be calculated 
                    by Formula 1.</t>
        <t>k=ceil(X/l)*(M/l)+ceil(Y/h)+delta</t>
        <t>The X is the orbit plane of the satellite. The Y is the sequence in the orbit plane 
                    of the satellite. The h is the number of satellites included in the region 
                    in a single orbit plane. The l is the number of orbits spanned by the region. The h and 
                    the l are region range parameters which can be pre-planned by the control layer of the 
                    network. The delta is an offset value when calculating the region number.</t>
        <t>Based on the orbit position information, the communication port of the satellite 
                    is addressed. During the data forwarding process, each relay satellite resolves the destination 
                    node identifier from the destination address, and then calculates the region number of the 
                    destination node via Formula 1. Through this method, each node can determine the mapping 
                    relationship between regions and nodes.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Node Capability</name>
      <t>In order to realize the region division described in the previous section, the corresponding 
                capability of the satellite node should be defined.</t>
      <t>It should be noted that the process of satellite motion along the orbit is 
                periodic and predictable. Predictable information in a satellite network 
                includes the real-time position of a satellite, the connectivity of satellite 
                links, the characteristics of satellite links.</t>
      <t>Based on these predictable information, the management plane, the control plane 
                and the forwarding plane of the network can be adaptively improved to ensure a 
                stable and optimal end-to-end reachable path between a pair of satellites. On 
                one hand, the flooding of routing convergence information caused by network 
                topology changes can be avoided. On the other hand, the routing re-calculation 
                is able to be fulfilled in advance before the satellite network topology changes. 
                Thus the calculated results can be updated immediately and timely. The same methods 
                can also apply to predictable changes in the characteristics of satellite links. 
                The node capabilities described in this section incorporate this manner.</t>
      <section numbered="true" toc="default">
        <name>Node Type</name>
        <t>According to the relative position of a satellite in the rigion, the type of the 
                    satellite can be classified as the internal node and the border node. The internal 
                    node doesn't connect nodes outside of the rigion. The border node is part of the 
                    rigion and has connections to nodes outside of the rigion. The internal node and 
                    the border node are collectively referred as the intra-region nodes. The node which have 
                    connections to the border node in the neighbor rigion is called the cross-rigion 
                    neighbor node.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Border Node Capability</name>
        <t>Each region is abstracted as a single virtual node to hide the network information 
                    and the topology change from the external network. The virtual node represents the 
                    time-varying geographical location of a region in the satellite network. The geographical 
                    location of the virtual node corresponds to the specified node in the region. The 
                    specified node could be configured by the network administrator or elected via protocol 
                    mechanism. It should be noted that there is only one edge between any two adjacent virtual 
                    nodes.</t>
        <t>In order to shield the network information in a region from the external network, the 
                    border node should have the following features:</t>
        <t>(1) The capability of establishing connections with cross-rigion neighbor nodes.</t>
        <t>The border node is the agent of the external connection for the local region, and 
                    is responsible for establishing the connection with the cross-rigion neighbor node.
                    During the connection establishment process, these nodes build the adjacency 
                    relationship and announce the region number with each other. After the border node 
                    receives the region number of the neighbor region, the border node informs this 
                    information to other nodes on the local region.</t>
        <t>(2) The capability of maintaining connections with cross-rigion neighbor nodes.</t>
        <t>The change of the connection relationship between the border node and the cross-rigion 
                    neighbor node can be divided into predictable and unpredictable. The predictable 
                    connection change can be self-calculated and obtained by each node according to the 
                    orbit parameters. Therefore, the border node only notifiy the unpredictable connection 
                    change to nodes in the same region. Figure 3 presents a unpredictable link failure 
                    between A19 adn A24, and N8 is responsible for informing other nodes in the same region.</t>
        <figure>
          <name>Inter-region link failure</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+ \|/ +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--X--| 2 |
+---+  |  +---+     +---+     +---+ /|\ +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |
       |  +---+     +---+     +---+  |
          | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>(3) The capability of isolating network information advertisements between different regions.</t>
        <t>If the network variation is happened in a region (such as link interruption, node failure, and etc.), 
                    the affected nodes will typically flood routing information to other nodes. When the 
                    flooding information reaches the border node, this information will be blocked, that is, 
                    the routing information in a region can't pass through the border node to the adjacent region.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Shared Node Capability</name>
        <t>In addition to the above unique features of the border node, both the border node and 
                    the internal node share the following functions:</t>
        <t>(1) The capability of maintaining intra-region network information.</t>
        <t>When a region is initially created, the node establishes a connection with a neighbor 
                    node, determines the node of the region based on the planned region parameters, generates 
                    a network topology in the region according to the orbit parameters, notifies its own 
                    network information to other nodes in the region, and continuously monitors its own 
                    direct links. Then, the node calculates and updates the intra-region network topology 
                    according to the planned time interval by the predictability of satellite orbital 
                    movement. As a sudden failure occurs, the node notifies it and updates the local 
                    network information and the intra-region topology. Figure 4 presents a unpredictable link 
                    failure between N5 adn N8. N5 and N8 are responsible for informing other nodes in 
                    the same region.</t>
        <figure>
          <name>Intra-region link failure</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+ \ / +---+  |  +---+
| 8 |--+--| 2 |-----| 5 |--X--| 8 |--+--| 2 |
+---+  |  +---+     +---+ / \ +---+  |  +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |
       |  +---+     +---+     +---+  |
          | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>(2) The capability of maintaining cross-region connection relationships.</t>
        <t>When a region is initially created, the node generates a mapping relationship between 
                    the border node and the adjacent region according to the notification information of 
                    the border node. Then, the node periodically calculates the connectivity between border 
                    nodes and connected cross-region neighbor nodes based on the predictability of satellite 
                    orbital movement, and updates the mapping relationship. As a sudden failure occurs, 
                    each node in the local region receives the routing information announced by the border node, 
                    and updates the mapping relationship.</t>
        <t>(3) The capability of maintaining inter-region network topology.</t>
        <t>Based on the orbit parameters of the designated nodes in the region corresponding to the 
                    virtual nodes, and the planned region range, the node calculate the geographical positions 
                    of other virtual nodes in the entire network to obtain the inter-region network topology.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Routing Computation</name>
      <section numbered="true" toc="default">
        <name>Information for Routing Calculation</name>
        <t>Through above node capabilities, each node maintains following network informaiton, including the 
                    intra-region topology relationship, the inter-region topology relationship, as well as the 
                    mapping relationship between the border node and the adjacent region.</t>
        <t>(1) Inter-region topology relationship</t>
        <t>Based on the satellite parameters (such as orbit parameters, satellite running time, and etc.), 
                    each satellite calculates the geographical location of virtual node corresponding to each region 
                    and constructs the inter-region topology relationship. Then, according to the inter-region 
                    topology relationship and the route computation algorithm, inter-region paths between the local 
                    region and others are obtained. Finally, the next hop regions to reach destination regions is also 
                    achieved. Figure 5 shows the representation of the inter-region topology relationship.</t>
        <figure>
          <name>Inter-region topology relationship</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
+------+------+------+
| Area1| Area2| Cost |
+------+------+------+
|  A14 |  A19 |  10  |
+------+------+------+
	             ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>(2) Intra-region topology relationship</t>
        <t>Each satellite calculates the connection relationship between any two nodes in the local region based 
                    on the satellite parameters. According to the connection relationship, intra-region topology 
                    relationship is constructed, which shows in Figure 6.</t>
        <figure>
          <name>Intra-region topology relationship</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
+------+------+------+
| Node1| Node2| Cost |
+------+------+------+
|  N1  |  N2  |  6   |
+------+------+------+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>(3) Mapping relationship</t>
        <t>In a region, each satellite receives the neighbor region number advertised by the border node. Then, 
                    a mapping relationship between the neighbor region and the border node is constructed. Figure 7 shows 
                    the representation of the mapping relationship.</t>
        <figure>
          <name>Mapping relationship</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
+-----------+----------+
| Edge Node | Nig Area |
+-----------+----------+
|    N1     |   INF    |
+-----------+----------+
|    N2     |   A14    |
+-----------+----------+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section numbered="true" toc="default">
        <name>Routing Computation</name>
        <t>Based on these network information, the intra-region routing table and inter-region routing table 
                    could be constructed.</t>
        <t>(1) Intra-region routing</t>
        <t>When the destination address of the data packet is identified in the local region, the intra-region 
                    routing table is used for the data forwarding. The data forwarding process is consistent with the 
                    terrestrial network. The intra-region routing table entries include destination address, network 
                    mask, routing priority, routing overhead, forwarding interface, and next hop address.</t>
        <t>(2) Inter-region routing</t>
        <t>When the destination address of the data packet is identified in the remote region, the inter-region 
                    routing table is used for the data forwarding. The path calculation process of each node is as 
                    follows:</t>
        <t>a. Firstly, based on the inter-region topology relationship, the inter-region path from the region 
                    where the node is located to other regions is calculated.</t>
        <t>b. Then, according to the mapping relationship and the intra-region topology relationship, the 
                    intra-region path to the next hop region is calculated.</t>
        <t>The inter-region routing table entries replaces the destination address and network mask with the 
                    destination area, and adds the next hop forwarding area. Figure 8 presents an example of the 
                    inter-region routing table.</t>
        <figure>
          <name>Inter-region routing table</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
+--------+---------+-----+------+-----+------------+
|Dst Area| Nxt Area| Pri | Cost | Inf | Nxt Hop Adr|
+--------+---------+-----+------+-----+------------+
|   22   |   18    |  1  |  6   | eth |  x.x.x.x   |
+--------+---------+-----+------+-----+------------+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Use Cases</name>
      <section numbered="true" toc="default">
        <name>Scenario 1: Intra-region data forwarding</name>
        <t>As shown in Figure 9, N2 and N4 are located in the same region. N2 serves as the 
                    source end to send data to the destination end N4. The data forwarding path 
                    between N2 and N4 pass through N2, N5, and N4 in turn. The routing process is 
                    consistent with that of the terrestial network. So, this document doesn't 
                    describe the process here.</t>
        <figure>
          <name>Intra-region data forwarding</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
                     Orbit plane 1       Orbit plane 2

                 |       .--.                .--.       |
                 |  ###-| N3 |-### <--> ###-| N6 |-###  |
                 |       \__/                \__/       |
                 |        ^        A18        ^         |
   --------------+--------+-------------------+---------+--------------
        A14      |        v        A19        v         |     A24
     .--.        |       .--.                .--.       |        .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v          |        v ----------------> v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^         |         ^
      |          |        |                   |         |         |
      v          |        v                   v         |         v
     .--.        |       .--.                .--.       |        .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
     \__/        |       \__/                \__/       |        \__/
                 |        ^                   ^         |
   --------------+--------+-------------------+---------+--------------  N
                 |        v        A20        v         |                ^
                 |       .--.                .--.       |                |
                 |  ###-| N1 |-### <--> ###-| N4 |-###  |         Moving |
                 |       \__/                \__/       |      Direction S
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
      <section numbered="true" toc="default">
        <name>Scenario 2: Inter-region data forwarding</name>
        <figure>
          <name>End-to-end inter-region path</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
+-----+-----+-----+-----+-----+-----+
| A1  | A6  | A11 | A16 | A21 | A26 |
|     |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+
| A2  | A7  | A12 | A17 | A22 | A27 |
|     |     |     |    ^>>    |     |
+-----+-----+-----+----^+-----+-----+
| A3  | A8  | A13 | A18^| A23 | A28 |
|     |     |     |    ^|     |     |
+-----+-----+-----+----^+-----+-----+
| A4  | A9  | A14 | A19^| A24 | A29 |
|   >>>>>>>>>>>>>>>>>>>>|     |     |
+-----+-----+-----+-----+-----+-----+
| A5  | A10 | A15 | A20 | A25 | A30 |
|     |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
        <t>As shown in Figure 10, the satellite network is divided into 30 regions. At a certaion 
                    time, Sat1 is located in region 4 and Sat2 is located in region 22. Sat1 serves as 
                    the source end to send data to the destination end Sat2. The data forwarding path 
                    between Sat1 and Sat2 pass through region 4, 9, 14, 19, 18, 17, and 22 in turn.</t>
        <t>As shown in Figure 11, the data is forwarded from Node 6 in region 14 to Node 3 in region 19
                    20. Node 3 resolves the destination node identifier (x_dst, y_dst) from the destination 
                    address, and then calculates the region number of the destination node as 22 via 
                    Formula 1.</t>
        <t>Node 3 queries the inter-region routing table to forward data. According to the 
                    inter-region routing table record, if the destination node is located in region 22, 
                    the data packet is forwarded via region 18, and the next hop node is Node 6. Each 
                    node in region 19 repeats the above operations, and finally forwards the packet to 
                    region 18. For the border node, the next hop address in the inter-region routing 
                    table is the port address of the cross-rigion neighbor satellite.</t>
        <figure>
          <name>Inter-region data forwarding</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[ 
                     Orbit plane 1       Orbit plane 2

                 |       .--.                .--.       |
                 |  ###-| N3 |-### <--> ###-| N6 |-###  |
                 |       \__/                \__/       |
                 |        ^        A18        ^  ^      |
   --------------+--------+-------------------+--|------+--------------
        A14      |        v        A19        v  |      |     A24
     .--.        |       .--.                .--.       |        .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v          |        v                   v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v ----------------> v ----------------> v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
     \__/        |       \__/                \__/       |        \__/
                 |        ^                   ^         |
   --------------+--------+-------------------+---------+--------------  N
                 |        v        A20        v         |                ^
                 |       .--.                .--.       |                |
                 |  ###-| N1 |-### <--> ###-| N4 |-###  |         Moving |
                 |       \__/                \__/       |      Direction S
	                   ]]></artwork>
        </figure>
        <t keepWithPrevious="true"/>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Conclusion and Future Works</name>
      <t>In this document, the routing framework in the LEO mega-constellation is discussed. This 
                framework not only reduce the link state information maintenance and routing calculation 
                cost, but also improve the routing stability and convergence speed.</t>
      <t>In the future work, following problems would be taken in mind:</t>
      <t>(1) Extension of the current routing protocol to support the framework described in this 
                document.</t>
      <t>(2) Improvement of the routing algorithm presented in this document to consider more 
                network metrics and obtain the optimal path</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 actions.</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>
