Problems and Requirements of Addressing in Integrated Space-Terrestrial Network
draft-li-istn-addressing-requirement-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Yuanjie Li , Hewu Li , Lixin Liu , Qian Wu , Jun Liu | ||
| Last updated | 2024-06-18 (Latest revision 2023-04-23) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-istn-addressing-requirement-04
Internet Engineering Task Force Y. Li
Internet-Draft H. Li
Intended status: Informational L. Liu
Expires: 20 December 2024 Q. Wu
J. Liu
Tsinghua University
18 June 2024
Problems and Requirements of Addressing in Integrated Space-Terrestrial
Network
draft-li-istn-addressing-requirement-04
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 December 2024.
Li, et al. Expires 20 December 2024 [Page 1]
Internet-Draft Problems and Requirements of Addressing June 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basics of Space-Terrestrial Network . . . . . . . . . . . . . 4
3.1. Satellites and Mega-Constellations . . . . . . . . . . . 4
3.2. Evolution of Space-Terrestrial Network . . . . . . . . . 6
3.2.1. "One-to-one" satellite communication . . . . . . . . 6
3.2.2. "One-to-many" networked ground stations . . . . . . . 7
3.2.3. "Many-to-many" networked satellites . . . . . . . . . 7
4. Problems in Space-Terrestrial Network Addressing . . . . . . 8
4.1. Multi-Dimensional Topology Dynamics . . . . . . . . . . . 8
4.1.1. Space-Terrestrial Dynamics . . . . . . . . . . . . . 8
4.1.2. Intra-Orbital-Shell Dynamics . . . . . . . . . . . . 9
4.1.3. Inter-Orbital-Shell Dynamics . . . . . . . . . . . . 10
4.2. Inconsistent “Locations” for Space/Terrestrial Nodes . . 10
4.3. Impact on Routing: Frequent Routing Updates . . . . . . . 12
5. Requirements of Addressing in Space-Terrestrial Network . . . 13
5.1. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Locality . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Efficiency . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Backward Compatibility with Terrestrial Internet . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Li, et al. Expires 20 December 2024 [Page 2]
Internet-Draft Problems and Requirements of Addressing June 2024
1. Introduction
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 Starlink [STARLINK], Kuiper [KUIPER]
and OneWeb [ONEWEB]. 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 2.7 billion users in rural areas[ITU-Measure], developing
countries, aircraft, or oceans.
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.
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 multi-dimensional
physical dynamics 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.
2. Terminology
GSO: Geosynchronous orbit (at the altitude of 35,786 km).
NGSO: Non-geosynchronous orbit.
LEO: Low Earth Orbit (at the altitude of 180-2,000 km).
MEO: Medium Earth Orbit (at the altitude of 2,000-35,786 km).
ISL: Inter Satellite Link.
NAT: Network Address Translation.
GS: Ground Station, a device on ground connecting the satellite.
FIB: Forwarding Information Base.
Li, et al. Expires 20 December 2024 [Page 3]
Internet-Draft Problems and Requirements of Addressing June 2024
3. Basics of Space-Terrestrial Network
As shown in Figure 1, a space-terrestrial network for terrestrial
users consists of the satellite or constellations, terrestrial
terminals, and ground stations.
3.1. Satellites and Mega-Constellations
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, <=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.
Historically, communications in space were dominated by GSO
satellites. As shown in Table 1, GSO offers excellent coverage at
high altitudes, but at the cost of long space-terrestrial RTT
(>=200ms) and low bandwidth (<=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( [LOWLATENCY-ROUTING-SPACE],
[SPACE-RACE], [NETWORK-TOPO-DESIGN]). Due to low coverage for each
LEO satellite, a mega-constellation is necessary to retain global
coverage. Table 2 exemplifies popular LEO mega-costellations in
operation. They are enabled by recent advances in satellite
miniaturization and rocket reusability.
+-----------+ +-----------+
| Satellite |_______ISL_______| Satellite | (Space Segment)
_ _|___________| _ _|___________|
/| \ /|
/ | \ / |
/ (Bent pipe) \ | /
/ _ _\| /
+---------+ +------------+
| Mobile | | Ground |
| Station | | Station | (Ground Segment)
|_________| |____________|
Figure 1: A simplified space-terrestrial network architecture
Li, et al. Expires 20 December 2024 [Page 4]
Internet-Draft Problems and Requirements of Addressing June 2024
+============+===============+==========+
| Orbit | Altitude (km) | RTT (ms) |
+======+=====+===============+==========+
| GSO | GEO | 35,786 | 240 |
+------+-----+---------------+----------+
| NGSO | MEO | 2,000-35,786 | 12-240 |
| +-----+---------------+----------+
| | LEO | 500-2,000 | 2-12 |
+------+-----+---------------+----------+
Table 1: Differences between GSO and
NGSO.
+===============+=================+=============+===============+
| Constellation | Num. satellites | Num. orbits | Altitude (km) |
+===============+=================+=============+===============+
| Starlink | 1584 | 72 | 550 |
| +-----------------+-------------+---------------+
| | 1584 | 72 | 540 |
| +-----------------+-------------+---------------+
| | 720 | 36 | 570 |
| +-----------------+-------------+---------------+
| | 348 | 6 | 560 |
| +-----------------+-------------+---------------+
| | 172 | 4 | 560 |
+---------------+-----------------+-------------+---------------+
| Kuiper | 1156 | 34 | 630 |
| +-----------------+-------------+---------------+
| | 1296 | 36 | 610 |
| +-----------------+-------------+---------------+
| | 784 | 28 | 590 |
+---------------+-----------------+-------------+---------------+
| Telesat | 351 | 27 | 1015 |
| +-----------------+-------------+---------------+
| | 1320 | 40 | 1325 |
+---------------+-----------------+-------------+---------------+
| Iridium | 66 | 6 | 780 |
+---------------+-----------------+-------------+---------------+
Table 2: Low-earth-orbit (LEO) satellite mega-constellations
in operation.
Li, et al. Expires 20 December 2024 [Page 5]
Internet-Draft Problems and Requirements of Addressing June 2024
3.2. Evolution of Space-Terrestrial Network
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 Starlink [STARLINK-CGNAT] and Kuiper [KUIPER-CGNAT]) and
remote satellite controllers (e.g., telemetry, tracking, orbital
update commands, or centralized routing control).
3.2.1. "One-to-one" satellite communication
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 [GEO-MOBILE-RADIO-INTERFACE] [ETSI-TS-101], 3G BGAN [BGAN]
[ETSI-TS-102], and DVB-S [SATELLITE-COMMUNICATIONS]), and recently
adopted by LEO satellites in OneWeb (4G) [ONEWEB] and 5G NTN
[STUDY-NR-SUPPORT] [SOLUTION-NR-NTN]. 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 Table 3, under current Starlink (no ISLs so far)
and ground station deployments ([STARLINK-GS-FOUND], [AZURE-GS],
[AWS-GS], [GOOGLE-DATA-CENTER], [AZURE-CLOUD-STARLINK],
[STARLINK-GS-MAP]), 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.
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 [REDDIT]. With limited space-terrestrial radio
link capacity, its ground stations have limited the LEO network’s
total capacity [COMPARISON-THREE-CONSTELLATION]. Similarly, each
OneWeb's ground station must process 10,000 terminal handovers per
second [ONEWEB-GS]. 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.
Li, et al. Expires 20 December 2024 [Page 6]
Internet-Draft Problems and Requirements of Addressing June 2024
3.2.2. "One-to-many" networked ground stations
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([BEIDOU-TEST], [TheVerge-STARLINK-SPEED]). The recent "burn
on re-entry" regulations from FCC also slows down the adoption of
ISLs[SPACEX-CLAIM]. 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[RFC0791]
for terrestrial users. The ground station-as-relay
[USE-GROUND-RELAY] 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.
3.2.3. "Many-to-many" networked satellites
To unleash LEO mega-constellations' potentials and long-term success,
the networked LEO satellites are under rapid
deployments[KUIPER][STARLINK]. Today's networked LEO satellites
typically have a microwave space-terrestrial radio interface and 4–5
laser/microwave inter-satellite links (ISLs)
[LOWLATENCY-ROUTING-SPACE][USE-GROUND-RELAY] (2 intra-orbit ISLs, 2
inter-orbit ISLs, and 1 optional inter-orbital-shell ISL).
Starlink's ISLs have started to operate for high latitude areas like
Latin America [STARLINK-ISL-AMERICA], Antarctica
[STARLINK-ISL-ANTARCTICA], and oceans [STARLINK-ISL-OCEANS]. With
this capability, recent work has explored topology design
[NETWORK-TOPO-DESIGN], low-latency routing
[LOWLATENCY-ROUTING-SPACE][SPACE-RACE], inter-domain routing
[Giuliari20Internet], orbital computing
[ORBITAL-EDGE-COM][IN-ORBIT-COM], and security [ICARUS] 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.
Li, et al. Expires 20 December 2024 [Page 7]
Internet-Draft Problems and Requirements of Addressing June 2024
+===========+======+======+=======+=======+======+========+=======+
| |Global|Africa|Oceania| South | Asia |European| North |
| | | | |America| | |America|
+===========+======+======+=======+=======+======+========+=======+
| 1-SAT |48.71%|19.52%| 42.85%| 49.63%|43.49%| 91.00% | 87.50%|
|association| | | | | | | |
+-----------+------+------+-------+-------+------+--------+-------+
| 2-SAT |57.30%|24.37%| 56.58%| 53.90%|55.91%| 94.33% | 91.23%|
|association| | | | | | | |
+-----------+------+------+-------+-------+------+--------+-------+
| 4-SAT |67.04%|26.13%| 60.31%| 63.16%|71.34%| 95.46% | 95.04%|
|association| | | | | | | |
+-----------+------+------+-------+-------+------+--------+-------+
| 8-SAT |73.04%|29.17%| 60.68%| 65.65%|80.28%| 96.91% | 98.86%|
|association| | | | | | | |
+-----------+------+------+-------+-------+------+--------+-------+
Table 3: Global population that could access Starlink in its
current "bent- pipe-only" model.
4. Problems in Space-Terrestrial Network Addressing
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 multi-
dimensional dynamics within space-terrestrial networks challenges
addressing due to topology instability, and its impact on routing
[INTERNET-IN-SPACE][SHORT].
4.1. Multi-Dimensional Topology Dynamics
High physical mobility incurs frequent link churns between space and
terrestrial nodes, thus causing frequent logical network topology
changes. This topology dynamics is multi-dimensional, manifesting
within a single orbital shell and interweaving across heterogeneous
orbital shells.
4.1.1. Space-Terrestrial Dynamics
Unlike classic GEO satellites, LEO satellites' GSLs are unstable due
to their unavoidable complex asynchronous motions to Earth. The GSL
changes are magnified with vast LEO satellites in the mega-
constellation in Table 2. On average, the global GSL churn occurs
every 1.46–3.98s. The link churn populates with more satellites and
ground stations.
Li, et al. Expires 20 December 2024 [Page 8]
Internet-Draft Problems and Requirements of Addressing June 2024
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”.
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 ([STUDY-NR-SUPPORT], [SOLUTION-NR-NTN]), and the latest 3GPP
5G release 17 defers its mobility support for satellites
[TEC-SPECI-GROUP-MEETING] due to significant architectural changes.
While Starlink uses handoffs to migrate physical links between
satellites and ground stations (every 15s [STARLINK-CGNAT]), its
logical topology and routing are still be repeatedly updated at high
costs.
4.1.2. Intra-Orbital-Shell Dynamics
Topoligical dynamics between LEO satellites inside an orbital shell
is milder than space-terrestrial dynamics but still alarming due to
various practical factors. In Starlink, ISL churns in orbital shell
2 and 3 occur every 208.7 and 970.0s, respectively. In orbital shell
4, inter-orbit ISL churn occurs every 11.4s due to its partial
deployment below.
There are three practical factors triggering intra-orbital-shell
dynamics. First, orbital maneuvers cause repetitive ISL churns. To
avoid collisions, a satellite should slightly raise/lower its
altitude. This incurs relative motions to its neighboring satellites
inside the orbital shell and prolongs their distances accumulatively.
They can eventually disrupt laser ISLs if neighboring satellites'
distance is beyond their visibility [STARLINK-SELF-DRIVING] or change
the intra-orbit satellite neighborship to force multiple ISL
reconfigurations [NETWORK-AWARE-MANEUVERS]. Starlink's maneuvers
cause 48 ISL churns per day on average (up to 259 ISL churns/day) in
shell 2 [SHORT]. Second, random satellite/ISL failures cause
unpredicted ISL churns. LEO satellites operates in harsh outer
space. Starlink’s official reports [STARLINK-REPORT-2021-1][STARLINK
-REPORT-2021-2][STARLINK-REPORT-2022-1][STARLINK-REPORT-2022-2][STARL
INK-REPORT-2023-1] show that, by May 2023, every 1 out of 13 Starlink
satellites has failed due to disposal, geomagnetic storm, flight
Li, et al. Expires 20 December 2024 [Page 9]
Internet-Draft Problems and Requirements of Addressing June 2024
control failures, hardware failures using commodity CPUs, and others.
Third, partial deployments cause more frequent ISL churns. An
orbital shell cannot be deployed all at once, thus causing partial
deployments. As of 2023.08, Starlink’s shell 3 and 4 in Table 2 are
still unfinished. Even so, these partial shells already offer
services using ISLs in areas like Antarctica (via shell 4, Starlink’s
only shell covering Antarctica). Partial deployments result in
sparser satellites and more frequent ISL churns. Starlink’s shell 4
has 18.3× more ISL churns than shell 2 (almost completed) [SHORT].
4.1.3. Inter-Orbital-Shell Dynamics
Operational LEO networks adopt multiple orbital shells to match their
satellite distribution and capacity with unevenly distributed users.
For optimal coverage, the LEO network can use multiple shells with
different inclinations and numbers of satellites, each primarily
serving a subset of users at different latitudes. For instance, most
Starlink satellites' inclinations are 53-53.2 to serve most users in
low-latitude areas. Its shells 3 and 4 use 70° and 97.6° inclination
for high-latitude users, but have much fewer satellites due to the
low population.
Different orbital shells have heterogenous altitudes and inclination
angles (Table 2). Similar to space-terrestrial dynamics, such
heterogeneity yields nonlinear, asynchronous, and accumulative
motions between inter-orbital-shell satellites and hence ISL churns.
Inter-orbital-shell dynamics is more dramatic than intra-orbital-
shell dynamics but less critical for the basic functionality of LEO
networking.
Inter-orbital-shell ISLs are nice to have for shorter paths but are
not always as mandatory as other links. Inter-orbital-shell routing
must occur only when the source (destination) resides in the high
latitude areas where the destination's (source's) orbital shell
cannot cover. This scenario is rare in practice due to the low
populations in high-latitude areas. Even without inter-orbital-shell
ISLs, orbital shells can still be indirectly bridged by GSLs from
ground stations in their overlapped terrestrial coverage.
4.2. Inconsistent “Locations” for Space/Terrestrial Nodes
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:
Li, et al. Expires 20 December 2024 [Page 10]
Internet-Draft Problems and Requirements of Addressing June 2024
a. Dynamic address updates
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. Table 4 and
Table 5 project the address update frequency when using legacy IP
addresses[RFC0791] for logical interfaces. In this scheme, the
terrestrial users’ logical IP[RFC0791] 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[RFC0791] every 133–510s. Every second, we observe
2,082–7,961 global users per second should change their IP
addresses.
+============+============+============+============+
| Starlink | Telesat | Kuiper | Iridium |
+============+============+============+============+
| Every 133s | Every 510s | Every 179s | Every 458s |
+------------+------------+------------+------------+
Table 4: Frequency of each user's logical IP
address update.
+==========+=========+========+=========+
| Starlink | Telesat | Kuiper | Iridium |
+==========+=========+========+=========+
| 7961 | 2082 | 5673 | 2379 |
+----------+---------+--------+---------+
Table 5: Number of terrestrial users
that change logical IP address per
second.
b. Static address binding to a fixed gateway
This is adopted by the cellular networks and Starlink
[STARLINK-CGNAT] and Kuiper’s[KUIPER-CGNAT] 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
[lai2021icnp]).
Li, et al. Expires 20 December 2024 [Page 11]
Internet-Draft Problems and Requirements of Addressing June 2024
4.3. Impact on Routing: Frequent Routing Updates
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:
a. Distributed routing: Repetitive re-convergence.
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(<=3 minutes in Starlink). Frequent topology updates
cause repetitive routing re-convergence and thus lowing network
usability. For intra-domain routing (e.g., OSPF[RFC2328], IS-
IS[RFC1142], AODV[RFC3561], DSR[RFC4728]), most mega-
constellations suffer from low network usability. Even the the
size of constellation is small, the network needs more than fifty
seconds to converge after each handoff while using
OSPF[TIMESLOT-DIVISION]. For inter-domain routing (e.g.,
BGP[RFC4271]), [Giuliari20Internet] and [NETWORK-IN-HEAVEN] show
frequent logical topology changes cause BGP[RFC4271] re-peering,
thus sharpening the instability of global Internet routing.
b. Centralized routing: Repetitive global updates.
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[RFC7426], MPLS[RFC3031], or
SRv6[RFC8754]). While helpful and can mitigate the impact of
topology dynamics, prediction-based centralized routing does not
suffice for two reasons: (1) Exhaustive computation: multi-level
LEO dynamics in 4.1 interleave with each other to complicate
overall predictions and result in routing/switch table explosion;
(2) Inaccurate prediction: Chaotic orbital maneuvers, random
failures, and partial deployments in 4.1.2 are less predictable
and limit prediction-based routing’s correctness and
responsiveness. 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.
Li, et al. Expires 20 December 2024 [Page 12]
Internet-Draft Problems and Requirements of Addressing June 2024
5. Requirements of Addressing in Space-Terrestrial Network
Except from the basic properties like clusterability, network
addressing in space-terrestrial network should also meet the
following requirements:
5.1. Uniqueness
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.
5.2. Stability
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.
5.3. Locality
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.
5.4. Scalability
The address space should scale to numerous terrestrial nodes and LEO
satellite mega-constellations. Hierarchical addressing will be more
scalable. By organizing the entire network into hierarchical routing
domains, hierarchical addressing can localize topology/routing
changes inside each domain, thereby facilitating the scaling to
extensive space-terrestrial networks.
5.5. Efficiency
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.
Li, et al. Expires 20 December 2024 [Page 13]
Internet-Draft Problems and Requirements of Addressing June 2024
5.6. Backward Compatibility with Terrestrial Internet
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.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
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.
8. References
8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, DOI 10.17487/RFC1142, February 1990,
<https://www.rfc-editor.org/info/rfc1142>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3561] Perkins, C., "Ad hoc on-demand distance vector (AODV)
routing", RFC 3561, DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271,
January 2006, <https://www.rfc-editor.org/info/rfc4271>.
Li, et al. Expires 20 December 2024 [Page 14]
Internet-Draft Problems and Requirements of Addressing June 2024
[RFC4728] Johnson, D., "The Dynamic Source Routing Protocol (DSR)
for Mobile Ad Hoc Networks for IPv4", RFC 4728,
DOI 10.17487/RFC4728, February 2007,
<https://www.rfc-editor.org/info/rfc4728>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
8.2. Informative References
[AWS-GS] "Amazon AWS Ground station: Easily control satellites and
ingest data with fully managed Ground Station as a
Service, 2021", <https://aws.amazon.com/ground-station/>.
[AZURE-CLOUD-STARLINK]
"CNBC. Microsoft partners with SpaceX to connect Azure
cloud to Musk’s Starlink satellite Internet, 2020",
<https://tinyurl.com/ybcwn7ft>.
[AZURE-GS] "Microsoft Azure. New Azure Orbital, ground station as a
service, now in preview, 2020",
<https://tinyurl.com/ejfpre>.
[BEIDOU-TEST]
"China tests inter-satellite links of BeiDou navigation
system", <https://tinyurl.com/3cufz6dt>.
[BGAN] "Broadband Global Area Network (BGAN)",
<https://en.wikipedia.org/wiki/
Broadband_Global_Area_Network>.
[COMPARISON-THREE-CONSTELLATION]
Portillo, I.D., Cameron, B.G., and E.F. Crawley, "A
technical comparison of three low earth orbit satellite
constellation systems to provide global broadband", Acta
Astronautica, 2019,
<https://www.sciencedirect.com/science/article/pii/
S0094576518320368?casa_token=djN7JSZN5voAAAAA:L5QUrRI-78pH
3zWYZQW8t6WwIXEQk9r1tGsRcTo9SsiToDFXNIUZrIu8OdttpovBQUNJuu
ewsrs>.
Li, et al. Expires 20 December 2024 [Page 15]
Internet-Draft Problems and Requirements of Addressing June 2024
[ETSI-TS-101]
"ETSI. TS 101 376-1-3: GEO-Mobile Radio Interface
Specifications; Part 1: General specifications; Sub-part
3: General System Description",
<https://en.wikipedia.org/wiki/ETSI>.
[ETSI-TS-102]
"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",
<https://en.wikipedia.org/wiki/ETSI>.
[GEO-MOBILE-RADIO-INTERFACE]
"GEO-Mobile Radio Interface",
<https://en.wikipedia.org/wiki/GEO-
Mobile_Radio_Interface>.
[Giuliari20Internet]
Giuliari, G., Klenze, T., Legner, M., Basin, D., Perrig,
A., and A. Singla, "Internet backbones in space", ACM
SIGCOMM Computer Communication Review, 2020, 50(1): 25-37,
<https://dl.acm.org/doi/abs/10.1145/3390251.3390256>.
[GOOGLE-DATA-CENTER]
"ZDNet. SpaceX to put Starlink ground stations in Google
data centres, 2021", <https://tinyurl.com/pzy8vstx>.
[ICARUS] Giuliari, G., Ciussani, T., Perrig, A., and A. Singla,
"{ICARUS}: Attacking low Earth orbit satellite
networks", 2021 USENIX Annual Technical Conference
(USENIX ATC 21), 2021,
<https://www.usenix.org/conference/atc21/presentation/
giuliari>.
[IN-ORBIT-COM]
Bhattacherjee, D., Kassing, S., and M. Licciardello, "In-
orbit computing: An outlandish thought
experiment?", Proceedings of the 19th ACM Workshop on Hot
Topics in Networks, 2020,
<https://dl.acm.org/doi/abs/10.1145/3422604.3425937>.
[INTERNET-IN-SPACE]
Li, Y., Li, H., Liu, L., Liu, W., Liu, J., Wu, J., Wu, Q.,
Liu, J., and Z. Lai, ""Internet in Space" for Terrestrial
Users via Cyber-Physical Convergence", Proceedings of the
20th ACM Workshop on Hot Topics in Networks. 2021,
<https://conferences.sigcomm.org/hotnets/2021/>.
Li, et al. Expires 20 December 2024 [Page 16]
Internet-Draft Problems and Requirements of Addressing June 2024
[ITU-Measure]
"ITU. Measuring digital development: Facts and figures
2022, 2022".
[KUIPER] "Amazon receives FCC approval for project Kuiper satellite
constellation.", <https://tinyurl.com/bs7syjnk>.
[KUIPER-CGNAT]
"Amazon Kuiper", <https://eurospace.org/wp-
content/uploads/2020/11/information-note-amazon-
kuiper_18112020.pdf>.
[lai2021icnp]
Lai, Z., Li, H., Zhang, Q., Wu, Q., and J. Wu,
"Cooperatively constructing cost-effective content
distribution networks upon emerging low earth orbit
satellites and clouds", 2021 IEEE 29th International
Conference on Network Protocols (ICNP). IEEE, 2021.
[LOWLATENCY-ROUTING-SPACE]
Handley, M., "Delay is Not an Option: Low Latency Routing
in Space", Proceedings of the 17th ACM Workshop on Hot
Topics in Networks. 2018,
<https://dl.acm.org/doi/abs/10.1145/3286062.3286075>.
[NETWORK-AWARE-MANEUVERS]
Zhao, W., Li, Y., Li, H., and Y. Chen, "A First Look at
Networking-Aware LEO Maneuvers", Proceedings of the 1st
ACM Workshop on LEO Networking and Communication. 2023,
<https://dl.acm.org/doi/10.1145/3614204.3616107>.
[NETWORK-IN-HEAVEN]
Klenze, T., Giuliari, G., Pappas, C., Perrig, A., and D.
Basin, "Networking in heaven as on earth", Proceedings of
the 17th ACM Workshop on Hot Topics in Networks. 2018:
22-28,
<https://dl.acm.org/doi/abs/10.1145/3286062.3286066>.
[NETWORK-TOPO-DESIGN]
Bhattacherjee, D. and A. Singla, "Network Topology Design
at 27,000 km/hour", Proceedings of the 15th International
Conference on Emerging Networking Experiments And
Technologies. 2019,
<https://dl.acm.org/doi/abs/10.1145/3359989.3365407>.
[ONEWEB] "OneWeb constellation", <https://www.oneweb.world/>.
Li, et al. Expires 20 December 2024 [Page 17]
Internet-Draft Problems and Requirements of Addressing June 2024
[ONEWEB-GS]
"OneWeb Gateways Require Complex Hughes Engineering,
2021", <https://www.hughes.com/resources/blog/satellite-
essential/oneweb-gateways-require-complex-hughes-
engineering>.
[ORBITAL-EDGE-COM]
Bradley, D. and B. Lucia, "Orbital edge computing:
Nanosatellite constellations as a new class of computer
system", Proceedings of the Twenty-Fifth International
Conference on Architectural Support for Programming
Languages and Operating Systems, 2020,
<https://dl.acm.org/doi/abs/10.1145/3373376.3378473>.
[REDDIT] "Online discussion with Starlink Engineers about
satellites’ capability, 2021",
<https://old.reddit.com/r/spacex/comments/gxb7j1/
we_are_the_spacex_software_team_ask_us_anything/>.
[SATELLITE-COMMUNICATIONS]
Roddy, D., "Satellite communications. McGraw-Hill
Education",
<https://ui.adsabs.harvard.edu/abs/1977ph...book.....S/
abstract>.
[SHORT] Li, Y., Liu, L., Li, H., Liu, W., Chen, Y., Zhao, W., Wu,
J., Wu, Q., Liu, J., and Z. Lai, "Stable Hierarchical
Routing for Operational LEO Networks", Proceedings of the
30th Annual International Conference on Mobile Computing
and Networking. 2024,
<https://dl.acm.org/doi/10.1145/3636534.3649362>.
[SOLUTION-NR-NTN]
"Solutions for NR to support non-terrestrial networks
(NTN)",
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3525>.
[SPACE-RACE]
Bhattacherjee, D., Aqeel, W., Bozkurt, I.N., Aguirre, A.,
Chandrasekaran, B., Godfrey, P.B., Laughlin, G., Maggs,
B., and A. Singla, "Gearing up for the 21st century space
race", Proceedings of the 17th ACM Workshop on Hot Topics
in Networks. 2018,
<https://dl.acm.org/doi/abs/10.1145/3286062.3286079>.
Li, et al. Expires 20 December 2024 [Page 18]
Internet-Draft Problems and Requirements of Addressing June 2024
[SPACEX-CLAIM]
"Spacex claims to have redesigned its starlink satellites
to eliminate casualty risks",
<https://tinyurl.com/yryp2upy>.
[STARLINK] "SpaceX Starlink", <http://www.starlink.com/>.
[STARLINK-CGNAT]
"Petition of Starlink Services, LLC for Designation as an
Eligible Telecommunication Carrier",
<https://tinyurl.com/ury6rzw5>.
[STARLINK-GS-FOUND]
"Tesmanian. SpaceX Starlink Gateway Stations Found In The
United States and Abroad, 2021",
<https://tinyurl.com/4m5uah43>.
[STARLINK-GS-MAP]
"SpaceX Starlink Ground Station Map, 2021",
<https://tinyurl.com/pu59m7j3>.
[STARLINK-ISL-AMERICA]
"Starlink's laser links are active, 2022",
<https://www.reddit.com/r/Starlink/comments/xsupcn/
laser_links_are_active/>.
[STARLINK-ISL-ANTARCTICA]
"Starlink Turns On Laser Satellites For Region With Four
Months Long Night, 2022", <https://wccftech.com/starlink-
turns-on-laser-satellites-for-region-with-fourth-month-
long-night/>.
[STARLINK-ISL-OCEANS]
"v1.5 Starlinks with laser inter-satellite links, 2021",
<https: //twitter.com/elonmusk/
status/1436541063406264320?s=21>.
[STARLINK-REPORT-2021-1]
"SpaceX Constellation Status Report: December 1, 2020 -
May 31, 2021, 2021", <https://licensing.fcc.gov/myibfs/
download.do?attachment_key=10375428>.
[STARLINK-REPORT-2021-2]
"SpaceX Constellation Status Report: June 1, 2021 —
November 30, 2021, 2021",
<https://licensing.fcc.gov/myibfs/
download.do?attachment_key=14325486>.
Li, et al. Expires 20 December 2024 [Page 19]
Internet-Draft Problems and Requirements of Addressing June 2024
[STARLINK-REPORT-2022-1]
"SpaceX Constellation Status Report: December 1, 2021 –
May 31, 2022, 2022", <https://licensing.fcc.gov/myibfs/
download.do?attachment_key=16644318>.
[STARLINK-REPORT-2022-2]
"SpaceX Constellation Status Report: June 1, 2022 –
November 30, 2022, 2022",
<https://licensing.fcc.gov/myibfs/
download.do?attachment_key=19127252>.
[STARLINK-REPORT-2023-1]
"SpaceX Constellation Status Report: December 1, 2022 –
May 31, 2023, 2023", <https://licensing.fcc.gov/myibfs/
download.do?attachment_key=23204338>.
[STARLINK-SELF-DRIVING]
Li, Y., Li, H., Liu, W., Liu, L., Zhao, W., Chen, Y., Wu,
J., Wu, Q., Liu, J., Lai, Z., and H. Qiu, "A Networking
Perspective on Starlink's Self-Driving LEO Mega-
Constellation", Proceedings of the 29th Annual
International Conference on Mobile Computing and
Networking. 2023,
<https://dl.acm.org/doi/10.1145/3570361.3592519>.
[STUDY-NR-SUPPORT]
"Study on New Radio (NR) to support nonterrestrial
networks",
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3234>.
[TEC-SPECI-GROUP-MEETING]
"Technical Specification Group Meeting #91E",
<https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Inbox/
RP-210915.zip>.
[TheVerge-STARLINK-SPEED]
"With latest Starlink launch, SpaceX touts 100 Mbps
download speeds and "space lasers" (though the system
still has a ways to go)", <https://tinyurl.com/hj8juyun>.
[TIMESLOT-DIVISION]
Li, J., Li, H., Liu, J., Lai, Z., Wu, Q., and X. Wang, "A
Timeslot Division Strategy for Availability in Integrated
Satellite and Terrestrial Network", 2021 IEEE Wireless
Communications and Networking Conference (WCNC). IEEE,
2021: 1-7, <https://ieeexplore.ieee.org/document/9417256>.
Li, et al. Expires 20 December 2024 [Page 20]
Internet-Draft Problems and Requirements of Addressing June 2024
[USE-GROUND-RELAY]
Handley, M., "Using ground relays for low-latency wide-
area routing in megaconstellations", Proceedings of the
18th ACM Workshop on Hot Topics in Networks. 2019:
125-132,
<https://dl.acm.org/doi/abs/10.1145/3365609.3365859>.
Authors' Addresses
Yuanjie Li
Tsinghua University
Beijing
China
Email: yuanjiel@tsinghua.edu.cn
Hewu Li
Tsinghua University
Beijing
China
Email: lihewu@cernet.edu.cn
Lixin Liu
Tsinghua University
Beijing
China
Email: llx22@mails.tsinghua.edu.cn
Qian Wu
Tsinghua University
Beijing
China
Email: wuqian@cernet.edu.cn
Jun Liu
Tsinghua University
Beijing
China
Email: juneliu@mail.tsinghua.edu.cn
Li, et al. Expires 20 December 2024 [Page 21]