<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="info"
      docName="draft-li-istn-addressing-requirement-03"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="Problems and Requirements of Addressing">Problems and Requirements of Addressing in Integrated Space-Terrestrial Network</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-addressing-03"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Yuanjie Li">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>yuanjiel@tsinghua.edu.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Hewu Li">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>lihewu@cernet.edu.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Lixin Liu">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>llx22@mails.tsinghua.edu.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <!-- <author fullname="Wei Liu">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>


         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
     </address>
    </author>
    <author fullname="Jianping Wu">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>jianping@cernet.edu.cn</email>
     </address>
    </author>-->
    <author fullname="Qian Wu">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>wuqian@cernet.edu.cn</email>
     </address>
    </author>
    <author fullname="Jun Liu">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>

         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>juneliu@mail.tsinghua.edu.cn</email>
     </address>
    </author>
    <!-- <author fullname="Zeqi Lai">
   <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street/>
         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>zeqilai@tsinghua.edu.cn</email>
     </address>
    </author>  -->
    <date year="2023"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>template</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <!-- <t>This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users.  
      It introduces the basics of satellite mega-constellations, terrestrial ground stations/terminals, and their inter-networking.  
      Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing.  
      The requirements of network addressing in the space-terrestrial network are discussed in detail, including stability, locality, scalability, efficiency, and backward compatibility with terrestrial Internet.  
      The problems and requirements of network addressing in space-terrestrial networks are outlined, and a possible principle (called cyber-physical convergence) that may satisfy these requirements are discussed.</t> -->

<!--      with an emphasis on the cyber-physical convergence principle (i.e., To align logical network topology, address, and route in the virtual cyberspace with movements of satellite mega-constellations and earth’s rotations in the real physical world).-->
      <t>This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users.  
      It introduces the basics of satellite mega-constellations, terrestrial terminals/ground stations, and their inter-networking.  
      Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing.  
      The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet.  
      The problems and requirements of network addressing in space-terrestrial networks are finally outlined.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      
      <t>
      The future Internet is up in the sky.
      We have seen a rocket-fast deployment of mega-constellations with 100s-10,000s of low-earth-orbit (LEO) satellites, such as  <xref target="STARLINK" format="default">Starlink</xref>,
       <xref target="KUIPER" format="default">Kuiper</xref> and  <xref target="ONEWEB" format="default">OneWeb</xref>.
      These constellations promise competitive low latency and high capacity to terrestrial networks.
      They expand global high-speed Internet to remote areas that were not reachable by terrestrial networks,
      resulting in a tens-of-billions-of-dollar market with 3.7 billion users in rural areas<xref target="ITU-Measure" format="default"></xref>, developing countries, aircraft, or oceans.
      </t>
      
      <t>
      A salient feature for LEO mega-constellations is their high relative motions to the rotating earth.
      Unlike geosynchronous satellite or terrestrial networks, each LEO satellite moves fast (e.g., 28,080 km/h for Starlink), causing short-lived coverage for terrestrial users (less than 3 minutes).
      This yields diverse challenges for the traditional network designs.
      </t>
      
      <t>
      This memo outlines the problems and requirements of addressing in integrated space-terrestrial network.
      It starts with the basics of satellite mega-constellations, terrestrial ground stations/terminals, and their inter-networking.
      <!-- It analyzes how fast space-terrestrial relative motions yields challenges for logical topology, addressing, routing and the issues of existing static network
      addressing in this situation. -->
      <!-- It analyzes how high space-terrestrial relative motions yields challenges for logical topology, addressing, routing and the root cause of these problems. -->
      It analyzes how high space-terrestrial relative motions yields challenges for logical topology, addressing and their impacts on routing.
      Then it discusses the requirements of network addressing in space-terrestrial network for uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet.
      <!-- The memo also introduces a princple, called cyber-physical convergence, that welcomes mobility to satisfy these requirements for network addressing in integrated space-terrestrial network. -->
      </t>
      
    </section>

    <section numbered="true" toc="default">
      <name>Terminology</name>
        <t>GSO: Geosynchronous orbit (at the altitude of 35,786 km).</t>
        <t>NGSO: Non-geosynchronous orbit.</t>
        <t>LEO: Low Earth Orbit (at the altitude of 180-2,000 km).</t>
        <t>MEO: Medium Earth Orbit (at the altitude of 2,000-35,786 km).</t>
        <t>ISL: Inter Satellite Link.</t>
        <!-- <t>NAT: Network Address Translation. A method of mapping an IP address space into another by modifying 
        network address information in the IP header of packets while they are in transit across a traffic routing 
        device.</t> -->
        <t>NAT: Network Address Translation. </t>
        <t>GS: Ground Station, a device on ground connecting the satellite.</t>
        <t>FIB: Forwarding Information Base.</t>
    </section>

    <section numbered="true" toc="default">
      <name>Basics of Space-Terrestrial Network</name>
      <t>As shown in Figure 1, a space-terrestrial network for terrestrial users consists of the satellite or constellations, terrestrial terminals, and ground stations.</t>

      <section numbered="true" toc="default">
        <name>Satellites and Mega-Constellations</name>
        <t>Satellites can be classified based on their relative motions to the earth. A satellite can operate at the 
        geosynchronous orbit (GSO, at about 35,786 km altitude) or non-geosynchronous orbits, such as low earth orbits (LEO, &lt;=2,000km) and medium earth 
        orbits (MEO, between 2,000 km and 35,786 km). Satellites at higher altitudes offer broader coverage, while satellites at lower altitudes move 
        faster.</t>
        <t>Historically, communications in space were dominated by GSO satellites. As shown in <xref target="GSO_NGSO" format="default"></xref>, GSO offers excellent coverage at high 
        altitudes, but at the cost of long space-terrestrial RTT (&gt;=200ms) and low bandwidth (&lt;=10Mbps, due to bit errors in 
        long distance transmission). Instead, recent efforts seek to adopt satellites at lower non-geosynchronous orbits, 
        with a special interest in low-earth orbits. Together with Ku (12–18 GHz) and Ka (26.5–40GHz) bands, these satellites 
        promise competitive bandwidth and latency to terrestrial networks( <xref target="LOWLATENCY-ROUTING-SPACE" format="default"></xref>, 
         <xref target="SPACE-RACE" format="default"></xref>,  <xref target="NETWORK-TOPO-DESIGN" format="default"></xref>). 
        Due to low coverage for each LEO satellite, a mega-constellation is necessary to retain global coverage. 
        <xref target="table_leo" format="default"></xref> exemplifies popular LEO mega-costellations in operation.
        They are enabled by recent advances in satellite miniaturization and rocket reusability.</t>

        <figure anchor="xml_happy">
        <name>A simplified space-terrestrial network architecture</name>
        <artwork align="left" name="A simplified space-terrestrial network architecture" type="11" alt="22">
        <![CDATA[
         +-----------+                 +-----------+
         | Satellite |_______ISL_______| Satellite | (Space Segment)
      _ _|___________|              _ _|___________|                    
         /|           \                /|
        / |            \              / |
       /   (Bent pipe)  \ |          /
      /               _ _\|         /
+---------+               +------------+
|  Mobile |               |   Ground   |
| Station |               |  Station   |            (Ground Segment)
|_________|               |____________|               
                         
                   
        ]]>
           </artwork>
      </figure>

        <table anchor="GSO_NGSO">
        <name>Differences between GSO and NGSO.</name>
        <thead>
          <tr>
            <th colspan="2" align='center'>Orbit</th>
            <th align='center'>Altitude (km)</th>
            <th align='center'>RTT (ms)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">GSO</td>
            <td align="center">GEO</td>
            <td align="center">35,786</td>
            <td align="center">240</td>
          </tr>
          <tr>
            <td rowspan="2">NGSO</td>
            <td align="center">MEO</td>
            <td align="center">2,000-35,786</td>
            <td align="center">12-240</td>
          </tr>
          <tr>
            <td align="center">LEO</td>
            <td align="center">500-2,000</td>
            <td align="center">2-12</td>
          </tr>
        </tbody>
      </table>

        

        <table anchor="table_leo">
        <name>Low-earth-orbit (LEO) satellite mega-constellations in operation.</name>
        <thead>
          <tr>
            <th align='center'>Constellation</th>
            <th align='center'>Num. satellites</th>
            <th align='center'>Num. orbits</th>
            <th align='center'>Altitude (km)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" rowspan="4">Starlink</td>
            <td align="center">1584</td>
            <td align="center">72</td>
            <td align="center">540/550</td>
          </tr>
          <tr>
            <td align="center">720</td>
            <td align="center">36</td>
            <td align="center">570</td>
          </tr>
          <tr>
            <td align="center">348</td>
            <td align="center">6</td>
            <td align="center">560</td>
          </tr>
          <tr>
            <td align="center">172</td>
            <td align="center">4</td>
            <td align="center">560</td>
          </tr>

          <tr>
            <td align="center" rowspan="3">Kuiper</td>
            <td align="center">1156</td>
            <td align="center">34</td>
            <td align="center">630</td>
          </tr>
          <tr>
            <td align="center">1296</td>
            <td align="center">36</td>
            <td align="center">610</td>
          </tr>
          <tr>
            <td align="center">784</td>
            <td align="center">28</td>
            <td align="center">590</td>
          </tr>

          <tr>
            <td align="center" rowspan="2">Telesat</td>
            <td align="center">351</td>
            <td align="center">27</td>
            <td align="center">1015</td>
          </tr>
          <tr>
            <td align="center">1320</td>
            <td align="center">40</td>
            <td align="center">1325</td>
          </tr>

          <tr>
            <td align="center">Iridium</td>
            <td align="center">66</td>
            <td align="center">6</td>
            <td align="center">780</td>
          </tr>

        </tbody>
      </table>

      </section>

      <section numbered="true" toc="default">
        <name>Evolution of Space-Terrestrial Network</name>
        <t>Terrestrial users access satellite networks via terminals (e.g., satellite phones, onboard dishes, IoT endpoints) 
        or ground stations. Ground stations can serve as network gateways (e.g., carrier-grade NAT in  <xref target="STARLINK-CGNAT" format="default">Starlink</xref> and  <xref target="KUIPER-CGNAT" format="default">Kuiper</xref>) and 
        remote satellite controllers (e.g., telemetry, tracking, orbital update commands, or centralized routing control).</t>
        
        <section numbered="true" toc="default">
        <name>"One-to-one" satellite communication</name>
        <t>Early satellite communications favor the simple "bent-pipe-only" model (Figure 1), i.e., satellites only relay terrestrial 
        users' radio signals to the fixed ground stations without ISLs or routing. This model has been popular in GSO 
        satellites with broad coverage (2G GMR <xref target="GEO-MOBILE-RADIO-INTERFACE" format="default"></xref>
         <xref target="ETSI-TS-101" format="default"></xref>, 3G BGAN <xref target="BGAN" format="default"></xref>
         <xref target="ETSI-TS-102" format="default"></xref>, and DVB-S <xref target="SATELLITE-COMMUNICATIONS" format="default"></xref>), 
        and recently adopted by LEO satellites in OneWeb (4G) <xref target="ONEWEB" format="default"></xref> and 5G NTN <xref target="STUDY-NR-SUPPORT" format="default"></xref>
         <xref target="SOLUTION-NR-NTN" format="default"></xref>. However, this model suffers from low LEO satellite coverage. 
        To access the network, both terrestrial users and ground stations must reside inside the satellite's coverage. Due to each LEO satellite's low coverage, 
        most users in remote areas with sparse or no ground stations cannot be served. As shown in <xref target="table_bent_pipe" format="default"></xref>, under current Starlink (no ISLs so far) and ground station deployments
        (<xref target="STARLINK-GS-FOUND" format="default"></xref>, <xref target="AZURE-GS" format="default"></xref>, <xref target="AWS-GS" format="default"></xref>, <xref target="GOOGLE-DATA-CENTER" format="default"></xref>, <xref target="AZURE-CLOUD-STARLINK" format="default"></xref>, <xref target="STARLINK-GS-MAP" format="default"></xref>), 
        27%–52% global populations cannot be served by the 
        "one-to-one" model (depending on how many satellites each ground station can simultaneously associate to). 
        Most under-served users are from remote areas (e.g., Africa), thus causing revenue loss for operators. </t>
        <t>The ground station aggregates traffic from all satellite users and becomes the single-point bottleneck. In reality, Starlink’s LEO satellites generate 5 TB telemetry data per day for the ground stations to process <xref target="REDDIT" format="default"></xref>. With limited space-terrestrial radio link capacity, its ground stations have limited the LEO network’s total capacity <xref target="COMPARISON-THREE-CONSTELLATION" format="default"></xref>. Similarly, each OneWeb's ground station must process 10,000 terminal handovers per second <xref target="ONEWEB-GS" format="default"></xref>. Deploying dense ground stations in these remote areas could mitigate above two problems. However, it is expensive and lowers commercial competitive advantages to terrestrial networks.</t>
        </section>
        
        <section numbered="true" toc="default">
        <name>"One-to-many" networked ground stations</name>
        <t>To this end, networked space-terrestrial infrastructure is crucial for global coverage and single-point bottleneck elimination. 
        To date, inter-satellite links (ISLs) are under early adoption(<xref target="BEIDOU-TEST" format="default"></xref>, <xref target="TheVerge-STARLINK-SPEED" format="default"></xref>).
        The recent "burn on re-entry" regulations from FCC also slows down the adoption of ISLs<xref target="SPACEX-CLAIM" format="default"></xref>.  
        As a near-term remedy, routing with distributed ground station networks is adopted. There are two variants. The ground station-as-gateway is adopted by Starlink and Kuiper. Each ground station is a 
        carrier-grade NAT that offers private IP<xref target="RFC0791" format="default"></xref> for terrestrial users. The ground station-as-relay <xref target="USE-GROUND-RELAY" format="default"></xref> mitigates ISLs with ground 
        station-assisted routing, but is vulnerable to intermittent space-terrestrial links in Ku/Ka-bands. 
        Fundamentally, the "one-to-many" model heavily relies on global deployments of ground station networks, thus offsetting LEO satellites' advantages and competitive edges to terrestrial networks.</t>
        </section>
        
        <section numbered="true" toc="default">
        <name>"Many-to-many" networked satellites</name>
        <t>To unleash LEO mega-constellations' potentials and long-term success, the networked LEO satellites are under rapid deployments<xref target="KUIPER" format="default"></xref><xref target="STARLINK" format="default"></xref>.
        Today's networked LEO satellites typically have a microwave space-terrestrial radio interface and at least 4 laser/microwave inter-satellite links (ISLs) <xref target="LOWLATENCY-ROUTING-SPACE" format="default"></xref><xref target="USE-GROUND-RELAY" format="default"></xref> (2 for intra-orbit satellites, 2 for inter-orbit satellites).  
        With this capability, recent work has explored topology design <xref target="NETWORK-TOPO-DESIGN" format="default"></xref>, low-latency routing <xref target="LOWLATENCY-ROUTING-SPACE" format="default"></xref><xref target="SPACE-RACE" format="default"></xref>, inter-domain routing <xref target="Giuliari20Internet" format="default"></xref>, orbital computing <xref target="ORBITAL-EDGE-COM" format="default"></xref><xref target="IN-ORBIT-COM" format="default"></xref>, and security <xref target="ICARUS" format="default"></xref> in LEO networks. 
        We take a forward-looking view to simplifying LEO networks in the first place and helps these efforts fulfill their merits in space.
        </t>
        
        


         <table anchor="table_bent_pipe">
          <name>Global population that could access Starlink in its current "bent-pipe-only" model.</name>
          <thead>
            <tr>
              <th align='center'></th>
              <th align='center'>Global</th>
              <th align='center'>Africa</th>
              <th align='center'>Oceania</th>
              <th align='center'>South America</th>
              <th align='center'>Asia</th>
              <th align='center'>European</th>
              <th align='center'>North America</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">1-SAT association</td>
              <td align="center">48.71%</td>
              <td align="center">19.52%</td>
              <td align="center">42.85%</td>
              <td align="center">49.63%</td>
              <td align="center">43.49%</td>
              <td align="center">91.00%</td>
              <td align="center">87.50%</td>
            </tr>
            <tr>
              <td align="center">2-SAT association</td>
              <td align="center">57.30%</td>
              <td align="center">24.37%</td>
              <td align="center">56.58%</td>
              <td align="center">53.90%</td>
              <td align="center">55.91%</td>
              <td align="center">94.33%</td>
              <td align="center">91.23%</td>
            </tr>
            <tr>
              <td align="center">4-SAT association</td>
              <td align="center">67.04%</td>
              <td align="center">26.13%</td>
              <td align="center">60.31%</td>
              <td align="center">63.16%</td>
              <td align="center">71.34%</td>
              <td align="center">95.46%</td>
              <td align="center">95.04%</td>
            </tr>
            <tr>
              <td align="center">8-SAT association</td>
              <td align="center">73.04%</td>
              <td align="center">29.17%</td>
              <td align="center">60.68%</td>
              <td align="center">65.65%</td>
              <td align="center">80.28%</td>
              <td align="center">96.91%</td>
              <td align="center">98.86%</td>
            </tr>

          </tbody>
      </table>
      </section>
      </section>
    </section>

    <section numbered="true" toc="default">
      <name>Problems in Space-Terrestrial Network Addressing</name>

      <t>In terrestrial and GEO satellite networks, the logical network topology, addresses, and routes are mostly stationary due to fixed infrastructure. 
      Instead, LEO mega-constellations hardly enjoy this luxury, whose satellites move at high speeds (about 28,080 km/h). 
      The earth’s rotation further complicates the relative motions between space and ground. 
      In this section, we will analyze how high relative motion between space and ground challenges addressing due to topology instability, and its impact on routing<xref target="INTERNET-IN-SPACE" format="default"></xref>.
      </t>

      <!-- <t>In terrestrial and GEO satellite networks, the logical network topology, addresses, and routes are mostly stationary due to fixed infrastructure. 
      Instead, LEO mega-constellations hardly enjoy this luxury, whose satellites move at high speeds (about 28,080 km/h). 
      The earth’s rotation further complicates the relative motions between space and ground.</t>

      <t>We next analyze how high relative motion between space and ground challenges traditional wisdom for network topology, addressing and routing.
      We validate our lessons with trace-driven emulation based on real LEO mega-constellations (<xref target="table_leo" format="default"></xref>), 
      geographical ground stations (<xref target="STARLINK-GS-FOUND" format="default"></xref>, <xref target="AZURE-GS" format="default"></xref>, <xref target="AWS-GS" format="default"></xref>, <xref target="GOOGLE-DATA-CENTER" format="default"></xref>, <xref target="AZURE-CLOUD-STARLINK" format="default"></xref>, <xref target="STARLINK-GS-MAP" format="default"></xref>,), 
      NASA’s global population statistics <xref target="NASA-SOCIOECONOMIC" format="default"></xref>, 
      and Starlink’s U.S. market estimations(<xref target="MIT-TEC-REVIEW" format="default"></xref>, <xref target="STARLINK-DEMAND" format="default"></xref>) to project global users proportionally.</t> -->

      <section numbered="true" toc="default">
      <name>Unstable Space-Terrestrial Topology</name>
        <t>High physical mobility incurs frequent link churns between space and terrestrial nodes, thus causing frequent logical network topology changes. For all mega-constellations in Table 2, the topology changes every 10s of seconds<xref target="INTERNET-IN-SPACE" format="default"></xref>. The link churn populates with more satellites and ground stations. </t>

        <t>In terrestrial mobile networks (e.g., 4G/5G), such physical link churn can be masked by handoffs without incurring logical topology changes. This method works based on two premises. First, all link churns occur at the last-hop radio due to user mobility, without affecting the infrastructure topology. Second, all cellular infrastructure nodes are fixed, resulting in a stable logical topology as “anchors”. </t>
              
        <t>However, neither premise holds in non-geosynchronous constellations. Instead, infrastructure mobility between satellites 
        and ground stations becomes a norm rather than an exception. This voids cellular handoffs’ merits to avoid propagation of 
        physical link churns to logical network topology: They are designed for user mobility only, and heavily rely on the fixed 
        infrastructure as “anchors.” Therefore, 5G NTN lists satellite handoffs as an unsolved problem (<xref target="STUDY-NR-SUPPORT" format="default"></xref>, <xref target="SOLUTION-NR-NTN" format="default"></xref>), 
        and the latest 3GPP 5G release 17 defers its mobility support for satellites <xref target="TEC-SPECI-GROUP-MEETING" format="default"></xref> due to significant architectural changes. While Starlink uses handoffs to migrate 
        physical links between satellites and ground stations (every 15s <xref target="STARLINK-CGNAT" format="default"></xref>), its logical topology and routing are still be repeatedly 
        updated at high costs.</t>
      </section>

      <section numbered="true" toc="default">
      <name>Inconsistent “Locations” for Space/Terrestrial Nodes</name>
      <t>Each space/terrestrial node has two notions of “locations”: The logical location in its topological address, and the physical location in reality. With repetitive topology changes, a static network address can hardly ensure its logical location in the topology is consistent with the fast-moving node’s physical location in reality. Then to correctly forward data, a network should choose one of the following designs:</t>

      <ol spacing="normal" type="a">
            <li>
            <t>Dynamic address updates</t>
            <t>A node can repetitively re-bind its physical location to its logical network address, thus incurring frequent address updates or re-binding. 
            Under high mobility, this could severely disrupt user experiences or incur heavy signaling overhead. 
            <xref target="table_ip_change" format="default"></xref> and <xref target="table_ip_change_total" format="default"></xref> project the address update frequency when using legacy IP addresses<xref target="RFC0791" format="default"></xref> for logical interfaces. 
            In this scheme, the terrestrial users’ logical IP<xref target="RFC0791" format="default"></xref> address changes if it re-associates to a new satellite (thus new interfaces and subnets) to retain its Internet access. 
            Due to high LEO satellite mobility, each user is forced to change its logical IP address<xref target="RFC0791" format="default"></xref> every 133–510s. 
            Every second, we observe 2,082–7,961 global users per second should change their IP addresses.</t>
      <!-- Using DNS, anycast, or ICN may mitigate frequent address changes, but incurs frequent naming- location re-binding and thus signaling overhead.</t> -->

            <table anchor="table_ip_change">
          <name>Frequency of each user's logical IP address update.</name>
          <thead>
            <tr>
              <th align='center'>Starlink</th>
              <th align='center'>Telesat</th>
              <th align='center'>Kuiper</th>
              <th align='center'>Iridium</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">Every 133s</td>
              <td align="center">Every 510s</td>
              <td align="center">Every 179s</td>
              <td align="center">Every 458s</td>
            </tr>
          </tbody>
      </table>

      <table anchor="table_ip_change_total">
          <name>Number of terrestrial users that change logical IP address per second.</name>
          <thead>
            <tr>
              <th align='center'>Starlink</th>
              <th align='center'>Telesat</th>
              <th align='center'>Kuiper</th>
              <th align='center'>Iridium</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">7961</td>
              <td align="center">2082</td>
              <td align="center">5673</td>
              <td align="center">2379</td>
            </tr>

          </tbody>
      </table>

            </li>

            <li>
              <t>Static address binding to a fixed gateway</t> 
              <t>This is adopted by the cellular networks and Starlink <xref target="STARLINK-CGNAT" format="default"></xref> and Kuiper’s<xref target="KUIPER-CGNAT" format="default"></xref> initial rollouts. Each user gets a static address from the remote ground station (via carrier-grade NAT), which masks the external address changes and redirects users’ traffic. This mitigates user address updates, but cannot avoid gateway’s external address updates when changing satellite interfaces (detailed below). It also incurs detours and long routing latencies for remote users from ground stations (e.g., 18,000 km detours and 370 ms extra delays in <xref target="lai2021icnp" format="default"></xref>).</t>
            </li>
      </ol>
      </section>

      <section numbered="true" toc="default">
      <name>Impact on Routing: Frequent Routing Updates</name>
        <t>
          <!-- The frequent address updates further impact network routing.  -->
          The inconsistent locations in addressing further impact the network routing.
          As space and terrestrial infrastructure nodes physically move fast, the logical routing in cyberspace expires frequently. It must be updated frequently, thus threatening various routing schemes:</t>

         <ol spacing="normal" type="a">
            <li>
                <t>Distributed routing: Repetitive re-convergence.</t>
                 <!-- <t>In distributed routing, network nodes distribute topology information to others, locally compute forwarding tables, 
                  and eventually reach a global consensus on routing paths (i.e., convergence). Before global routing convergence, there 
                  is no guaranteed network reachability. With high mobility, each LEO satellite can only offer very short-lived access 
                  for a ground station(&lt;=3 minutes in Starlink). Frequent topology updates cause repetitive routing re-convergence and thus 
                  low network usability. For intra-domain routing (e.g., OSPF<xref target="RFC2328" format="default"></xref>, IS-IS<xref target="RFC1142" format="default"></xref>) with the popular Grid+ topology <xref target="NETWORK-TOPO-DESIGN" format="default"></xref>, <xref target="table_distributed_routing" format="default"></xref> shows all mega-constellations 
                  today can suffer from less than 20% network usability. The usability decreases with more satellites and ground stations. For inter-domain 
                  routing (e.g., BGP<xref target="RFC4271" format="default"></xref>),  <xref target="Giuliari20Internet" format="default"> and </xref> <xref target="NETWORK-IN-HEAVEN" format="default"></xref> show frequent logical topology changes cause BGP<xref target="RFC4271" format="default"></xref> re-peering, thus sharpening the instability of 
                  global Internet routing. Hierarchical routing may help mitigate global re-convergence by localizing link churns in subnets [47], 
                  but still cannot avoid re-convergence inside the subnets <xref target="ROUTING-PROTOCOL-HIERARCHICAL" format="default"></xref>.</t> -->
                  <t>In distributed routing, network nodes distribute topology information to others, locally compute forwarding tables, 
                  and eventually reach a global consensus on routing paths (i.e., convergence). Before global routing convergence, there 
                  is no guaranteed network reachability. With high mobility, each LEO satellite can only offer very short-lived access 
                  for a ground station(&lt;=3 minutes in Starlink). Frequent topology updates cause repetitive routing re-convergence and thus 
                  lowing network usability. 
                  For intra-domain routing (e.g., OSPF<xref target="RFC2328" format="default"></xref>, IS-IS<xref target="RFC1142" format="default"></xref>), 
                  most mega-constellations suffer from low network usability. 
                  Even the the size of constellation is samll, the network needs more than fifty seconds to converge after each handoff while using OSPF<xref target="TIMESLOT-DIVISION" format="default"></xref>.
                  For inter-domain routing (e.g., BGP<xref target="RFC4271" format="default"></xref>),  <xref target="Giuliari20Internet" format="default"></xref> and <xref target="NETWORK-IN-HEAVEN" format="default"></xref> show frequent logical topology changes cause BGP<xref target="RFC4271" format="default"></xref> re-peering, thus sharpening the instability of 
                  global Internet routing. 
                  <!-- Hierarchical routing may help mitigate global re-convergence by localizing link churns in subnets<xref target="ROUTING-PROTOCOL-HIERARCHICAL" format="default"></xref>, but still cannot avoid re-convergence inside the subnets . -->
                </t>
                  

                <!-- <table anchor="table_distributed_routing">
                    <name> Network usability in distributed routing in LEO mega-cosntellations.</name>
                    <thead>
                      <tr>
                        <th align='center'>SATs*orbits</th>
                        <th align='center'>9*1</th>
                        <th align='center'>9*5</th>
                        <th align='center'>18*5</th>
                        <th align='center'>18*11</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td align="center">Starlink</td>
                        <td align="center">92.39%</td>
                        <td align="center">68.42%</td>
                        <td align="center">47.03%</td>
                        <td align="center">17.17%</td>
                      </tr>
                      <tr>
                        <td align="center">Kuiper</td>
                        <td align="center">95.23%</td>
                        <td align="center">68.57%</td>
                        <td align="center">48.41%</td>
                        <td align="center">15.47%</td>
                      </tr>
                    </tbody>
                </table> -->


            </li>

            <li>
                <t> Centralized routing: Repetitive global updates.</t>
                <t>
                  <!-- Centralized routing control is popular in GSO satellites and small constellations.  -->
                  In the centralized routing, a ground station predicts the temporal evolution of topology based on satellites’ orbital patterns, divides it into a series of semi-static topology snapshots, schedules the forthcoming global routing tables for each snapshot, and remotely updates the routing tables to all satellites (e.g., via SDN<xref target="RFC7426" format="default"></xref>, MPLS<xref target="RFC3031" format="default"></xref>, or SRv6<xref target="RFC8754" format="default"></xref>).
                <!-- <t>LEO mega-constellations pose stresses on centralized routing’s scalability, stability, and complexity. Due to frequent link churns, the topology snapshots and FIBs explode with more satellites, ground stations, and faster mobility. <xref target="table_centralized_routing" format="default"></xref> and <xref target="table_centralized_routing_opt" format="default"></xref> show that, without optimizations (i.e., new snapshot upon every link churn), the controller should re-compute all satellites’ routing every 1.4–2.3s. To reduce them, the controller could merge snapshots via scheduling global synchronous handoffs among satellites. However, this is hard as it mandates strong global synchronization. Even so, centralized routing still should re-compute all FIBs every 45–100s. Moreover, every satellite should locally load these new FIBs upon snapshot changes, which is vulnerable to transient global routing inconsistencies and thus black holes or loops. </t> -->
                LEO mega-constellations pose stresses on centralized routing’s scalability, stability, and complexity. 
                Due to frequent link churns, the topology snapshots and FIBs explode with more satellites, ground stations, and faster mobility. 
                <!-- To reduce them, the controller could merge snapshots via scheduling global synchronous handoffs among satellites. 
                However, this is hard as it mandates strong global synchronization. Even so, centralized routing still should re-compute all FIBs frequently. -->
                Moreover, every satellite should locally load these new FIBs upon snapshot changes, which is vulnerable to transient global routing inconsistencies and thus black holes or loops. 
              </t>

                <!-- <table anchor="table_centralized_routing">
                    <name>Cost of centralized LEO routing without global handoff synchronization in 1 hour.</name>
                    <thead>
                      <tr>
                        <th align='center'></th>
                        <th align='center'>Starlink</th>
                        <th align='center'>Kuiper</th>
                        <th align='center'>Telesat</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td align="center">Num. satellites</td>
                        <td align="center">1584</td>
                        <td align="center">1156</td>
                        <td align="center">351</td>
                      </tr>
                      <tr>
                        <td align="center">Num. ground stations</td>
                        <td align="center">232</td>
                        <td align="center">232</td>
                        <td align="center">232</td>
                      </tr>
                      <tr>
                        <td align="center">Num. snapshots</td>
                        <td align="center">2647</td>
                        <td align="center">1938</td>
                        <td align="center">1588</td>
                      </tr>
                      <tr>
                        <td align="center">Num. snapshots</td>
                        <td align="center">614,104</td>
                        <td align="center">449,616</td>
                        <td align="center">368,416</td>
                      </tr>
                    </tbody>
                </table> -->

                <!-- <table anchor="table_centralized_routing_opt">
                    <name>Cost of centralized LEO routing with global handoff synchronization <xref target="TIMESLOT-DIVISION" format="default"></xref> in 1 hour.</name>
                    <thead>
                      <tr>
                        <th align='center'></th>
                        <th align='center'>Starlink</th>
                        <th align='center'>Kuiper</th>
                        <th align='center'>Telesat</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td align="center">Num. satellites</td>
                        <td align="center">1584</td>
                        <td align="center">1156</td>
                        <td align="center">351</td>
                      </tr>
                      <tr>
                        <td align="center">Num. ground stations</td>
                        <td align="center">232</td>
                        <td align="center">232</td>
                        <td align="center">232</td>
                      </tr>
                      <tr>
                        <td align="center">Num. snapshots</td>
                        <td align="center">58</td>
                        <td align="center">36</td>
                        <td align="center">80</td>
                      </tr>
                      <tr>
                        <td align="center">Num. snapshots</td>
                        <td align="center">13,456</td>
                        <td align="center">8,352</td>
                        <td align="center">18,560</td>
                      </tr>
                    </tbody>
                </table> -->
            </li>
         </ol>
       </section>

       <!-- <section numbered="true" toc="default">
        <name>Root cause: Cyber-Physical Inconsistency</name>
        <t>
          Fundamentally, all above problems arise from inconsistencies between logical networks in virtual cyberspace and physical satellite mega-constellations in the real world. 
          This gap was negligible in geosynchronous satellite or terrestrial networks, but evident now in LEO mega-constellations due to high mobility. 
          On the one hand, existing mega-constellations from the aerospace community neglect the networking community’s topology, addressing, and routing demands. 
          On the other hand, traditional logical networks treat fast physical mobility as a challenge rather than an opportunity. 
          They attempt to work it around via terrestrial mechanisms such as cellular handoffs and carrier-grade NAT. While usable for now, they complicate the network architecture and protocols at high costs and thus are hard to scale to mega-constellations in the long term.  
        </t>
        </section> -->
    </section>


    <section numbered="true" toc="default">
      <name>Requirements of Addressing in Space-Terrestrial Network</name>
      <t>Except from the basic properties like clusterability, network addressing in space-terrestrial network should 
      also meet the following requirements: </t>
      
        <section numbered="true" toc="default">
          <!-- <name>Requirements on Uniqueness</name> -->
          <name>Uniqueness</name>
          <t>
            In integrated space-terrestrial networks, each user's L2/L3 address should be globally unique.
            This property calls for address allocation and duplicate address detection mechanisms.
            <!-- The addressing of integrated space-terrestrial network must ensure the uniqueness of each user’s address to avoid conflicts.  -->
              <!-- We recommend that the design of addressing based on IPv6, which has enough space to implement the DAD(Duplicate Address Detection) mechanism.
              Besides, it should also support IPv4 through 4-over-6. -->
          </t>
        </section>

        <section numbered="true" toc="default">
          <!-- <name>Requirements on Stability</name> -->
          <name>Stability</name>
          <t>
            Each terrestrial node's address should stay unchanged despite LEO satellite mobility and Earth's rotations. 
            With this property, location-based routing will be more stable, avoiding routing convergence caused by the high dynamics of integrated space-terrestrial network. 
            The stability of the address also reduces the impact on users' network services.
            <!--This property ensures that the addressing of each node does not change with the movement of users or satellites.
            It also reduces the frequency of network addresses updates and reduces the impact on users' network services.-->
          </t>
        </section>

        <section numbered="true" toc="default">
          <!-- <name>Requirements on Locality</name> -->
          <name>Locality</name>
          <t>
            For any two users or satellites, if their addresses are closer, their actual physical distances should also be closer. 
            Locality not only guarantees the unified logical and physical locations, but also simplifies the design and implementation of location-based routing.</t>
        </section>

        <section numbered="true" toc="default">
          <!-- <name>Requirements on Scalability</name> -->
          <name>Scalability</name>
          <t>
            The address space should scale to numerous terrestrial nodes and LEO satellite mega-constellations.
            <!-- The addressing of integrated space-terrestrial network should be designed to accommodate as many satellites and terrestrial 
            nodes as possible. What’s more, it should scale to more satellites and terrestrial users if needed.-->
          </t>
        </section>

        <section numbered="true" toc="default">
          <!-- <name>Requirements on Efficiency</name> -->
          <name>Efficiency</name>
          <t>
            The addressing of integrated space-terrestrial network should be spatially compact and computationally lightweight to process.
            It should ensure consistent cyber-physical locations, thus easing physically shortest paths without detours.
            <!-- ensure require static address binding to remote gateways (e.g., carrier-grade NAT). -->
          </t>
        </section>

        <section numbered="true" toc="default">
          <!-- <name>Requirements on Backward Compatibility with terrestrial Internet</name> -->
          <name>Backward Compatibility with Terrestrial Internet</name>
          <t>
            The addressing of integrated space-terrestrial network should be compatible with state-of-the-art terrestrial network addressing.
            For example, it should be compatible with the standard IPv6 addressing formats and facilitates inter-networking to external networks without modifying terrestrial infrastructure. 
            For backward compatibility with IPv4, we recommend adopting a 4over6 transition for integrated space-terrestrial networks.
            
            <!-- The network addressing in space-terrestrial network should comprise prefix and user suffix. The prefix is used for 
            networking with external networks, while the per-user suffix ensures the globally unique address.
            By reasonably selecting the size of each area, the number of users in each area is controlled.
            Users are allowed to randomly select suffixes to minimize the probability of address conflicts. 
            This does not require a centralized DHCP server for address allocation and also avoids signaling caused by 
            broadcasting under the traditional DAD mechanism. -->
            <!-- To ensure seamless expansion of the global Internet ecosystem, the addressing in space-terrestrial network should be backward compatible with terrestrial Internet.-->
          </t>
        </section>


      <!-- <ol spacing="normal" type="a">
            <li>
              <t>Stability</t>
              <t>This property ensures that the addressing of each node does not change with the movement of users or satellites. With this property, location-based 
              routing will be more stable, avoiding routing convergence caused by the high dynamics of integrated space-terrestrial network. 
              It also reduces the frequency of network addresses updates and reduces the impact on users' network services.</t>
            </li>

            <li>
              <t>Locality</t>
              <t>For any two users or satellites, this property ensures that if their addresses are closer, their actual physical distances should be closer. 
                 It not only guarantees the unified logical and physical locations, but also simplifies the design and implementation of location-based routing.
              </t>
            </li>

            <li>
              <t>Scalability</t>
              <t>The addressing of integrated space-terrestrial network should be designed to accommodate as many satellites and terrestrial 
              nodes as possible. What’s more, it should scale to more satellites and terrestrial users if needed.</t>
            </li>

            <li>
              <t>Efficiency</t>
              <t>In order to avoid frequent addresses updates, the design of addressing in space-terrestrial network should not 
              require static address binding to remote gateways (e.g., carrier-grade NAT). The addressing method should ensure consistent 
              cyber-physical locations, thus easing physically shortest paths without detours.</t>
            </li>

            <li>
              <t>Backward compatibility with terrestrial Internet</t>
              <t>The network addressing in space-terrestrial network should comprise prefix and user suffix. The prefix is used for 
              networking with external networks, while the per-user suffix ensures the globally unique address.
              By reasonably selecting the size of each area, the number of users in each area is controlled.
              Users are allowed to randomly select suffixes to minimize the probability of address conflicts. 
              This does not require a centralized DHCP server for address allocation and also avoids signaling caused by 
              broadcasting under the traditional DAD mechanism.
              </t>
            </li>
      </ol> -->

      <!-- <t>Besides, as can be seen from the previous section, the problems are fundamentally caused by the inconsistency between logical 
          networks and physical mega-constellations. To this end, addressing in integrated space-terrestrial network needs to align the 
          logical network topology, addressing in virtual cyberspace with satellites’ orbital movements and earth rotations in the real 
          physical world. This brings a new principle called cyber-physical convergence, which welcomes mobility to bridge this gap and 
          streamline diverse architecture and protocols. The cyber-physical convergence includes three steps: </t>
      <t>(1) Align space-terrestrial physical movements: All issues in previous section arise from the high relative motions between 
          space and ground. Therefore, cyber-physical convergence suggests structurizing their physical movements. Structural mobility is 
          feasible due to satellites’ regular orbital movements.</t>
      <t>(2) Stabilize topology via structural mobility: Structural mobility helps stabilize the logical topology in the unstable 
          physical world. Note physical space-terrestrial link churn still exists in mobility, but can be masked in the logical topology 
          based on the regular space-terrestrial movements. </t>
      <t>(3) Unify cyber-physical addressing and routing: A stable logical topology ensures stable network addressing and routing, 
          thus avoiding deficiencies in previous section. Moreover, such topology aligns logical and physical locations, and unifies the 
          topologically and physically shortest path.</t> -->
    </section>

    <!-- <section numbered="true" toc="default">
      <name>General Principle: Cyber-Physical Convergence</name>
      <t>As can be seen from the previous section, the problems are fundamentally caused by the inconsistency between logical 
          networks and physical mega-constellations. To this end, network addressing in integrated space-terrestrial network needs to align the 
          logical network topology, addressing in virtual cyberspace with satellites’ orbital movements and earth rotations in the real 
          physical world. This brings a new principle called cyber-physical convergence, which welcomes mobility to bridge this gap and 
          streamline diverse architecture and protocols. The cyber-physical convergence includes three steps: </t>
      <t>(1) Align space-terrestrial physical movements: All issues in previous section arise from the high relative motions between 
          space and ground. Therefore, cyber-physical convergence suggests structurizing their physical movements. Structural mobility is 
          feasible due to satellites’ regular orbital movements.</t>
      <t>(2) Stabilize topology via structural mobility: Structural mobility helps stabilize the logical topology in the unstable 
          physical world. Note physical space-terrestrial link churn still exists in mobility, but can be masked in the logical topology 
          based on the regular space-terrestrial movements. </t>
      <t>(3) Unify cyber-physical addressing and routing: A stable logical topology ensures stable network addressing and routing, 
          thus avoiding deficiencies in previous section. Moreover, such topology alig</t>
    </section> -->

    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The present memo does not introduce any new technology and/or mechanism and as such does not introduce any security 
      threat to the TCP/IP protocol suite.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4271"/>
            <seriesInfo name="RFC" value="4271"/>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
              <organization/>
            </author>
            <author initials="T." surname="Li" fullname="Tony Li">
              <organization/>
            </author>
            <author initials="S." surname="Hares" fullname="Susan Hares">
              <organization/>
            </author>
            <date year="2006" month="January"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328">
          <front>
            <title>OSPF Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC2328"/>
            <seriesInfo name="RFC" value="2328"/>
            <seriesInfo name="STD" value="54"/>
            <author initials="J." surname="Moy" fullname="J. Moy">
              <organization/>
            </author>
            <date year="1998" month="April"/>
            <abstract>
              <t>This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <!-- <reference anchor="RFC2453" target="https://www.rfc-editor.org/info/rfc2453">
          <front>
            <title>RIP Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC2453"/>
            <seriesInfo name="RFC" value="2453"/>
            <seriesInfo name="STD" value="56"/>
            <author initials="G." surname="Malkin" fullname="G. Malkin">
              <organization/>
            </author>
            <date year="1998" month="November"/>
            <abstract>
              <t>This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference> -->
        <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791">
          <front>
            <title>Internet Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC0791"/>
            <seriesInfo name="RFC" value="791"/>
            <seriesInfo name="STD" value="5"/>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization/>
            </author>
            <date year="1981" month="September"/>
          </front>
        </reference>

        <!-- <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <seriesInfo name="DOI" value="10.17487/RFC2460"/>
            <seriesInfo name="RFC" value="2460"/>
            <author initials="S." surname="Deering" fullname="S. Deering">
              <organization/>
            </author>
            <author initials="R." surname="Hinden" fullname="R. Hinden">
              <organization/>
            </author>
            <date year="1998" month="December"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference> -->

        <reference anchor="RFC1142" target="https://www.rfc-editor.org/info/rfc1142">
          <front>
            <title>OSI IS-IS Intra-domain Routing Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC1142"/>
            <seriesInfo name="RFC" value="1142"/>
            <author initials="D." surname="Oran" fullname="D. Oran">
              <organization/>
            </author>
            <date year="1990" month="February"/>
            <abstract>
              <t>This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.</t>
            </abstract>
          </front>
        </reference>

        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8754"/>
            <seriesInfo name="RFC" value="8754"/>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Dukes" fullname="D. Dukes" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization/>
            </author>
            <author initials="J." surname="Leddy" fullname="J. Leddy">
              <organization/>
            </author>
            <author initials="S." surname="Matsushima" fullname="S. Matsushima">
              <organization/>
            </author>
            <author initials="D." surname="Voyer" fullname="D. Voyer">
              <organization/>
            </author>
            <date year="2020" month="March"/>
            <abstract>
              <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
        </reference>

        <reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc7426">
          <front>
            <title>Software-Defined Networking (SDN): Layers and Architecture Terminology</title>
            <seriesInfo name="DOI" value="10.17487/RFC7426"/>
            <seriesInfo name="RFC" value="7426"/>
            <author initials="E." surname="Haleplidis" fullname="E. Haleplidis" role="editor">
              <organization/>
            </author>
            <author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Denazis" fullname="S. Denazis">
              <organization/>
            </author>
            <author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
              <organization/>
            </author>
            <author initials="D." surname="Meyer" fullname="D. Meyer">
              <organization/>
            </author>
            <author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou">
              <organization/>
            </author>
            <date year="2015" month="January"/>
            <abstract>
              <t>Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.</t>
            </abstract>
          </front>
        </reference>

        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <seriesInfo name="DOI" value="10.17487/RFC3031"/>
            <seriesInfo name="RFC" value="3031"/>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization/>
            </author>
            <author initials="A." surname="Viswanathan" fullname="A. Viswanathan">
              <organization/>
            </author>
            <author initials="R." surname="Callon" fullname="R. Callon">
              <organization/>
            </author>
            <date year="2001" month="January"/>
            <abstract>
              <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>

        <!-- <reference anchor="RFC8793" target="https://www.rfc-editor.org/info/rfc8793">
          <front>
            <title>RIP Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC8793"/>
            <seriesInfo name="RFC" value="8793"/>
            <author initials="B." surname="Wissingh" fullname="B. Wissingh">
              <organization/>
            </author>
            <author initials="C." surname="Wood" fullname="C. Wood">
              <organization/>
            </author>
            <author initials="A." surname="Afanasyev" fullname="A. Afanasyev">
              <organization/>
            </author>
            <author initials="L." surname="Zhang" fullname="L. Zhang">
              <organization/>
            </author>
            <author initials="D." surname="Oran" fullname="D. Oran">
              <organization/>
            </author>
            <author initials="C." surname="Tschudin" fullname="C. Tschudin">
              <organization/>
            </author>
            <date year="2020" month="June"/>
            <abstract>
              <t>Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).</t>
            </abstract>
          </front>
        </reference> -->

        <!-- <reference anchor="RFC4786" target="https://www.rfc-editor.org/info/rfc4786">
          <front>
            <title>Operation of Anycast Services</title>
            <seriesInfo name="DOI" value="10.17487/RFC4786"/>
            <seriesInfo name="RFC" value="4786"/>
            <seriesInfo name="BCP" value="126"/>
            <author initials="J." surname="Abley" fullname="J. Abley">
              <organization/>
            </author>
            <author initials="K." surname="Lindqvist" fullname="K. Lindqvist">
              <organization/>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t>As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.</t>
              <t>Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>            
            </abstract>
          </front>
        </reference> -->
      </references>

      <references>
        <name>Informative References</name>
        <reference anchor="STARLINK" target="http://www.starlink.com/">
          <front>
            <title>SpaceX Starlink</title>
            <author initials="" surname="">
              <organization/>
            </author>
          </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="ONEWEB" target="https://www.oneweb.world/">
            <front>
              <title>OneWeb constellation</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="LOWLATENCY-ROUTING-SPACE" target="https://dl.acm.org/doi/abs/10.1145/3286062.3286075">
            <front>
              <title>Delay is Not an Option: Low Latency Routing in Space</title>
              <seriesInfo name="" value="Proceedings of the 17th ACM Workshop on Hot Topics in Networks. 2018"/>
              <author initials="M." surname="Handley" fullname="M. Handley">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="SPACE-RACE" target="https://dl.acm.org/doi/abs/10.1145/3286062.3286079">
            <front>
              <title>Gearing up for the 21st century space race</title>
              <seriesInfo name="" value="Proceedings of the 17th ACM Workshop on Hot Topics in Networks. 2018"/>
              <author initials="D." surname="Bhattacherjee" fullname="D. Bhattacherjee">
                <organization/>
              </author>
              <author initials="W." surname="Aqeel" fullname="W. Aqeel">
                <organization/>
              </author>
              <author initials="I.N." surname="Bozkurt" fullname="I. Bozkurt">
                <organization/>
              </author>
              <author initials="A." surname="Aguirre" fullname="A. Aguirre">
                <organization/>
              </author>
              <author initials="B." surname="Chandrasekaran" fullname="B. Chandrasekaran">
                <organization/>
              </author>
              <author initials="P.B." surname="Godfrey" fullname="P.B. Godfrey">
                <organization/>
              </author>
              <author initials="G." surname="Laughlin" fullname="G. Laughlin">
                <organization/>
              </author>
              <author initials="B." surname="Maggs" fullname="B. Maggs">
                <organization/>
              </author>
              <author initials="A." surname="Singla" fullname="A. Singla">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="NETWORK-TOPO-DESIGN" target="https://dl.acm.org/doi/abs/10.1145/3359989.3365407">
            <front>
              <title>Network Topology Design at 27,000 km/hour</title>
              <seriesInfo name="" value="Proceedings of the 15th International Conference on Emerging Networking Experiments And Technologies. 2019"/>
              <author initials="D." surname="Bhattacherjee" fullname="D. Bhattacherjee">
                <organization/>
              </author>
              <author initials="A." surname="Singla" fullname="A. Singla">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="COMPARISON-THREE-CONSTELLATION" target="https://www.sciencedirect.com/science/article/pii/S0094576518320368?casa_token=djN7JSZN5voAAAAA:L5QUrRI-78pH3zWYZQW8t6WwIXEQk9r1tGsRcTo9SsiToDFXNIUZrIu8OdttpovBQUNJuuewsrs">
            <front>
              <title>A technical comparison of three low earth orbit satellite constellation systems to provide global broadband</title>
              <seriesInfo name="" value="Acta Astronautica, 2019"/>
              <author initials="I.D." surname="Portillo" fullname="I.D. Portillo">
                <organization/>
              </author>
              <author initials="B.G." surname="Cameron" fullname="B.G. Cameron">
                <organization/>
              </author>
              <author initials="E.F." surname="Crawley" fullname="E.F. Crawley">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="ORBITAL-EDGE-COM" target="https://dl.acm.org/doi/abs/10.1145/3373376.3378473">
            <front>
              <title>Orbital edge computing: Nanosatellite constellations as a new class of computer system</title>
              <seriesInfo name="" value="Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, 2020"/>
              <author initials="D." surname="Bradley" fullname="D. Bradley">
                <organization/>
              </author>
              <author initials="B." surname="Lucia" fullname="B. Lucia">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="IN-ORBIT-COM" target="https://dl.acm.org/doi/abs/10.1145/3422604.3425937">
            <front>
              <title>In-orbit computing: An outlandish thought experiment?</title>
              <seriesInfo name="" value="Proceedings of the 19th ACM Workshop on Hot Topics in Networks, 2020"/>
              <author initials="D." surname="Bhattacherjee" fullname="D. Bhattacherjee">
                <organization/>
              </author>
              <author initials="S." surname="Kassing" fullname="S. Kassing">
                <organization/>
              </author>
              <author initials="M." surname="Licciardello" fullname="M. Licciardello">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="ICARUS" target="https://www.usenix.org/conference/atc21/presentation/giuliari">
            <front>
              <title>{ICARUS}: Attacking low Earth orbit satellite networks</title>
              <seriesInfo name="" value="2021 USENIX Annual Technical Conference (USENIX ATC 21), 2021"/>
              <author initials="G." surname="Giuliari" fullname="G. Giuliari">
                <organization/>
              </author>
              <author initials="T." surname="Ciussani" fullname="T. Ciussani">
                <organization/>
              </author>
              <author initials="A." surname="Perrig" fullname="A. Perrig">
                <organization/>
              </author>
              <author initials="A." surname="Singla" fullname="A. Singla">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="STARLINK-CGNAT" target="https://tinyurl.com/ury6rzw5">
            <front>
              <title>Petition of Starlink Services, LLC for Designation as an Eligible Telecommunication Carrier</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="KUIPER-CGNAT" target="https://eurospace.org/wp-content/uploads/2020/11/information-note-amazon-kuiper_18112020.pdf">
            <front>
              <title>Amazon Kuiper</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="GEO-MOBILE-RADIO-INTERFACE" target="https://en.wikipedia.org/wiki/GEO-Mobile_Radio_Interface">
            <front>
              <title>GEO-Mobile Radio Interface</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="ETSI-TS-101" target="https://en.wikipedia.org/wiki/ETSI">
            <front>
              <title>ETSI. TS 101 376-1-3: GEO-Mobile Radio Interface Specifications; Part 1: General specifications; Sub-part 3: General System Description</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="BGAN" target="https://en.wikipedia.org/wiki/Broadband_Global_Area_Network">
            <front>
              <title>Broadband Global Area Network (BGAN)</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="ETSI-TS-102" target="https://en.wikipedia.org/wiki/ETSI">
            <front>
              <title>ETSI. TS 102 744-3-6: Satellite Earth Stations and Systems (SES); Part 3: Control Plane and User Plane Specifications; Sub-part 6: Adaptation Layer Operation</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="SATELLITE-COMMUNICATIONS" target="https://ui.adsabs.harvard.edu/abs/1977ph...book.....S/abstract">
            <front>
              <title>Satellite communications. McGraw-Hill Education</title>
              <author initials="D." surname="Roddy" fullname="D. Roddy">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="STUDY-NR-SUPPORT" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3234">
            <front>
              <title>Study on New Radio (NR) to support nonterrestrial networks</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="SOLUTION-NR-NTN" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3525">
            <front>
              <title>Solutions for NR to support non-terrestrial networks (NTN)</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="Giuliari20Internet" target="https://dl.acm.org/doi/abs/10.1145/3390251.3390256">
            <front>
              <title>Internet backbones in space</title>
              <seriesInfo name="" value="ACM SIGCOMM Computer Communication Review, 2020, 50(1): 25-37"/>
              <author initials="G." surname="Giuliari" fullname="G. Giuliari">
                <organization/>
              </author>
              <author initials="T." surname="Klenze" fullname="T. Klenze">
                <organization/>
              </author>
              <author initials="M." surname="Legner" fullname="M. Legner">
                <organization/>
              </author>
              <author initials="D." surname="Basin" fullname="D. Basin">
                <organization/>
              </author>
              <author initials="A." surname="Perrig" fullname="A. Perrig">
                <organization/>
              </author>
              <author initials="A." surname="Singla" fullname="A. Singla">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="BEIDOU-TEST" target="https://tinyurl.com/3cufz6dt">
            <front>
              <title>China tests inter-satellite links of BeiDou navigation system</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="TheVerge-STARLINK-SPEED" target="https://tinyurl.com/hj8juyun">
            <front>
              <title>With latest Starlink launch, SpaceX touts 100 Mbps download speeds and "space lasers" (though the system still has a ways to go)</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="SPACEX-CLAIM" target="https://tinyurl.com/yryp2upy">
            <front>
              <title>Spacex claims to have redesigned its starlink satellites to eliminate casualty risks</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="USE-GROUND-RELAY" target="https://dl.acm.org/doi/abs/10.1145/3365609.3365859">
            <front>
              <title>Using ground relays for low-latency wide-area routing in megaconstellations</title>
              <seriesInfo name="" value="Proceedings of the 18th ACM Workshop on Hot Topics in Networks. 2019: 125-132"/>
              <author initials="M." surname="Handley" fullname="M. Handley">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="TEC-SPECI-GROUP-MEETING" target="https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Inbox/RP-210915.zip">
            <front>
              <title>Technical Specification Group Meeting #91E</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="NETWORK-IN-HEAVEN" target="https://dl.acm.org/doi/abs/10.1145/3286062.3286066">
            <front>
              <title>Networking in heaven as on earth</title>
              <seriesInfo name="" value="Proceedings of the 17th ACM Workshop on Hot Topics in Networks. 2018: 22-28"/>
              <author initials="T." surname="Klenze" fullname="T. Klenze">
                <organization/>
              </author>
              <author initials="G." surname="Giuliari" fullname="G. Giuliari">
                <organization/>
              </author>
              <author initials="C." surname="Pappas" fullname="C. Pappas">
                <organization/>
              </author>
              <author initials="A." surname="Perrig" fullname="A. Perrig">
                <organization/>
              </author>
              <author initials="D." surname="Basin" fullname="D. Basin">
                <organization/>
              </author>
            </front>
          </reference>
          <!-- <reference anchor="ROUTING-PROTOCOL-HIERARCHICAL" target="https://link.springer.com/article/10.1007/s11276-005-1772-1">
            <front>
              <title>A routing protocol for hierarchical LEO/MEO satellite IP networks</title>
              <seriesInfo name="" value="Wireless Networks, 2005, 11(4): 507-521"/>
              <author initials="C." surname="Chen" fullname="C. Chen">
                <organization/>
              </author>
              <author initials="E." surname="Ekici" fullname="E. Ekici">
                <organization/>
              </author>
            </front>
          </reference> -->
          <reference anchor="TIMESLOT-DIVISION" target="https://ieeexplore.ieee.org/document/9417256">
            <front>
              <title>A Timeslot Division Strategy for Availability in Integrated Satellite and Terrestrial Network</title>
              <seriesInfo name="" value="2021 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 2021: 1-7"/>
              <author initials="J." surname="Li" fullname="J. Li">
                <organization/>
              </author>
              <author initials="H." surname="Li" fullname="H. Li">
                <organization/>
              </author>
              <author initials="J." surname="Liu" fullname="J. Liu">
                <organization/>
              </author>
              <author initials="Z." surname="Lai" fullname="Z. Lai">
                <organization/>
              </author>
              <author initials="Q." surname="Wu" fullname="Q. Wu">
                <organization/>
              </author>
              <author initials="X." surname="Wang" fullname="X. Wang">
                <organization/>
              </author>
            </front>
          </reference>
          <reference anchor="lai2021icnp" target="">
            <front>
              <title>Cooperatively constructing cost-effective content distribution networks upon emerging low earth orbit satellites and clouds</title>
              <seriesInfo name="" value="2021 IEEE 29th International Conference on Network Protocols (ICNP). IEEE, 2021"/>
              <author initials="Z." surname="Lai" fullname="Z. Lai">
                <organization/>
              </author>
              <author initials="H." surname="Li" fullname="H. Li">
                <organization/>
              </author>
              <author initials="Q." surname="Zhang" fullname="Q. Zhang">
                <organization/>
              </author>
              <author initials="Q." surname="Wu" fullname="Q. Wu">
                <organization/>
              </author>
              <author initials="J." surname="Wu" fullname="J. Wu">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="ITU-Measure" target="">
            <front>
              <title>ITU. Measuring digital development: Facts and figures 2020, 2020</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="STARLINK-GS-FOUND" target="https://tinyurl.com/4m5uah43">
            <front>
              <title>Tesmanian. SpaceX Starlink Gateway Stations Found In The United States and Abroad, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="AZURE-GS" target="https://tinyurl.com/ejfpre">
            <front>
              <title>Microsoft Azure. New Azure Orbital, ground station as a service, now in preview, 2020</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="AWS-GS" target="https://aws.amazon.com/ground-station/">
            <front>
              <title>Amazon AWS Ground station: Easily control satellites and ingest data with fully managed Ground Station as a Service, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="GOOGLE-DATA-CENTER" target="https://tinyurl.com/pzy8vstx">
            <front>
              <title>ZDNet. SpaceX to put Starlink ground stations in Google data centres, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="AZURE-CLOUD-STARLINK" target="https://tinyurl.com/ybcwn7ft">
            <front>
              <title>CNBC. Microsoft partners with SpaceX to connect Azure cloud to Musk’s Starlink satellite Internet, 2020</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <reference anchor="STARLINK-GS-MAP" target="https://tinyurl.com/pu59m7j3">
            <front>
              <title>SpaceX Starlink Ground Station Map, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="REDDIT" target="https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/">
            <front>
              <title>Online discussion with Starlink Engineers about satellites’ capability, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>
          
          <reference anchor="ONEWEB-GS" target="https://www.hughes.com/resources/blog/satellite-essential/oneweb-gateways-require-complex-hughes-engineering">
            <front>
              <title>OneWeb Gateways Require Complex Hughes Engineering, 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference>

          <!-- <reference anchor="NASA-SOCIOECONOMIC" target="https://tinyurl.com/6skkewrf">
            <front>
              <title>NASA Socioeconomic Data and Applications Center(SEDAC). Gridded population of the world: Population count, v4.11 (2020)</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference> -->

          <!-- <reference anchor="MIT-TEC-REVIEW" target="https://www.technologyreview.com/2021/09/06/1034373/starlink-rural-fcc-satellite-internet/">
            <front>
              <title>MIT Technology Review. Who is Starlink really for?, Sep 2021</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference> -->

          <!-- <reference anchor="STARLINK-DEMAND" target="https://tinyurl.com/ufuabs3s">
            <front>
              <title>CNBC. Investing in space: SpaceX says Starlink internet has “extraordinary demand,” with nearly 700,000 interested in service, 2020</title>
              <author initials="" surname="">
                <organization/>
              </author>
            </front>
          </reference> -->

          <reference anchor="INTERNET-IN-SPACE" target="https://conferences.sigcomm.org/hotnets/2021/">
            <front>
              <title>"Internet in Space" for Terrestrial Users via Cyber-Physical Convergence</title>
              <seriesInfo name="" value="Proceedings of the 20th ACM Workshop on Hot Topics in Networks. 2021"/>
              <author initials="Y." surname="Li" fullname="Y. Li">
                <organization/>
              </author>
              <author initials="H." surname="Li" fullname="H. Li">
                <organization/>
              </author>
              <author initials="L." surname="Liu" fullname="L. Liu">
                <organization/>
              </author>
              <author initials="W." surname="Liu" fullname="W. Liu">
                <organization/>
              </author>
              <author initials="J." surname="Liu" fullname="J. Liu">
                <organization/>
              </author>
              <author initials="J." surname="Wu" fullname="J. Wu">
                <organization/>
              </author>
              <author initials="Q." surname="Wu" fullname="Q. Wu">
                <organization/>
              </author>
              <author initials="J." surname="Liu" fullname="J. Liu">
                <organization/>
              </author>
              <author initials="Z." surname="Lai" fullname="Z. Lai">
                <organization/>
              </author>
            </front>
          </reference>
      </references>
    </references>
  </back>
</rfc>
