Internet DRAFT - draft-pan-intarea-lisp-leo
draft-pan-intarea-lisp-leo
Internet Area Working Group T. Pan
Internet-Draft J. Hu
Intended status: Standards Track Y. Chen
Expires: 15 October 2023 BUPT
X. Zhang
CURI
M. Gao
BUPT
13 April 2023
Location/Identity Separation-based Mobility Management for LEO Satellite
Networks
draft-pan-intarea-lisp-leo-00
Abstract
In space-terrestrial integrated networks, the motion of LEO
satellites relative to ground terminals is inevitable and can trigger
the reassignment of terminal IP addresses, disrupting ongoing TCP
connections. The traditional Mobile IP protocol solves this problem
using a home agent and tunneling mechanism. However, for space-
terrestrial integrated networks, Mobile IP is inefficient due to
increased latency when registering with the remote home agent, high
packet loss caused by large registration latency, and triangular
routing to the remote home agent. To address these issues, this
draft proposes LISP-LEO, a location/identity separation-based
mobility management protocol for LEO satellite networks.
Specifically, LISP-LEO divides the Earth's surface into partitions
and maintains a partition-satellite mapping table in real-time based
on the regularity of satellite motion. LISP-LEO always routes
traffic to the satellite above the destined terminal by querying the
partition-satellite mapping table, eliminating triangular routing and
related performance overheads. Additionally, LISP-LEO proposes a
last-hop relay to handle the corner case when multiple satellites
occur above the destined terminal.
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/.
Pan, et al. Expires 15 October 2023 [Page 1]
Internet-Draft LISP-LEO April 2023
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 15 October 2023.
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Location/Identity Separation-based Protocol . . . . . . . . . 6
3.1. Partition Design . . . . . . . . . . . . . . . . . . . . 6
3.2. Partition-Satellite Mapping Table . . . . . . . . . . . . 7
3.3. Location/Identity Separation-based Addressing . . . . . . 9
3.4. Satellite Broadcast . . . . . . . . . . . . . . . . . . . 10
3.5. Terminal Registration with the Service Satellite . . . . 10
3.6. End-to-End Transmission between Terminals . . . . . . . . 14
4. Known Open Issues and Areas of Future Work . . . . . . . . . 16
5. Security Consideration . . . . . . . . . . . . . . . . . . . 17
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Satellite networks are recognized as a valuable complement to
terrestrial networks due to their extensive coverage of the Earth's
surface and their ability to overcome terrain limitations. Compared
to MEO and GEO satellites, LEO satellites are smaller, less
expensive, and closer to the ground, resulting in significantly lower
space-ground transmission latency. Additionally, LEO satellite
Pan, et al. Expires 15 October 2023 [Page 2]
Internet-Draft LISP-LEO April 2023
constellations feature high-density mesh topologies, which enable
multi-path routing for traffic load balancing and link failure
tolerance, even under extreme conditions. Given the commercial value
of low latency and high reliability, as well as declining satellite
launch costs, several companies have begun designing and launching
mega-scale LEO satellite constellations into space. For instance,
SpaceX's Starlink project aims to launch 12,000 LEO satellites and
conduct inter-satellite routing to achieve global internet coverage
[foust2018spacex].
Mobility management is one of the key challenges faced by LEO
satellite networks. A typical LEO satellite constellation has an
orbital altitude of less than 2000 km, resulting in a small Earth
coverage area for a single satellite. In addition, the relative
motion between LEO satellites and ground terminals occurs frequently,
leading to short durations of Ground-to-Satellite Links (GSLs).
Terminal-satellite handovers are inevitable during terminal-to-
terminal communication via the LEO satellite network. However, at
the network layer, such handovers result in the reassignment of the
terminal IP address, which can disrupt running TCP connections since
a TCP connection is established with a fixed pair of 5-tuple socket
addresses. The disruption of TCP connections can further impact the
carried services and end-user experiences.
Previous work on mobility management in LEO satellite networks has
mainly focused on link-layer handover, which addresses the transfer
of an ongoing link connection to a new spot beam or satellite
[chowdhury2006handover], [papapetrou2004satellite]. In contrast,
network-layer mobility management has received relatively little
attention. Some existing solutions borrow ideas from mobility
management protocols used in terrestrial networks and apply them to
LEO satellite networks [sarikaya2001supporting],
[darwish2021location]. For instance, Mobile IP [RFC3344] proposes
two IP addresses to identify a mobile terminal and its location: the
Home Address (HoA), which is a unique identifier of the mobile
terminal and remains constant, and the Care-of Address (CoA), which
specifies the current location of the mobile terminal in the network.
In the initial stage, the home agent of a mobile terminal is the
satellite above the mobile terminal. Upon a satellite handover, the
mobile terminal obtains a new CoA from the new satellite (the foreign
agent) and sends a binding update to the home agent. Through the
binding update operation, the HoA can be associated with the CoA at
the home agent to maintain communication continuity after handover.
The home agent sends packets destined for the mobile terminal through
a tunnel to the CoA, and upon arrival at the end of the tunnel, each
packet is delivered to the mobile terminal.
Pan, et al. Expires 15 October 2023 [Page 3]
Internet-Draft LISP-LEO April 2023
However, the distance between the home agent and the mobile terminal
in LEO satellite networks varies constantly due to satellite motion.
As a result, the time required for registration with the home agent
can sometimes be quite long, leading to high registration latency.
This can cause severe packet loss since packets destined for the
terminal's original CoA may be lost during registration.
Additionally, the use of Mobile IP in LEO satellite networks results
in the so-called triangular routing problem
[sanguankotchakorn2008effect]. When a source terminal sends traffic
to the mobile terminal, packets must first travel to the home agent,
which then encapsulates the packets and tunnels them to the foreign
agent. Finally, the foreign agent decapsulates these packets and
delivers them to the mobile terminal. This packet route is
inefficient, and in the worst-case scenario, when the mobile terminal
is near the source terminal while its home agent is on the opposite
side of the Earth, the packets destined for the mobile terminal may
have to traverse the Earth twice.
To overcome the limitations of Mobile IP in LEO satellite networks,
we propose LISP-LEO, a novel network-layer mobility management
protocol based on location/identity separation. In our design, we
divide the Earth's surface into multiple partitions and establish a
dynamic partition-satellite mapping table. Each partition is
assigned a service satellite that manages the mobility of terminals
within that partition. We introduce a new IP addressing method based
on location/identity separation, in which the terminal's address
contains two parts: the Partition Identifier (PID) and the Identity
Identifier (IID). The PID indicates the partition where the terminal
is located, and the IID indicates its identity. With this method,
the terminal's address remains unchanged during satellite handovers.
To avoid the triangular routing problem, we always route traffic to
the satellite above the partition where the destination terminal is
located (its service satellite). We do this by querying the
partition-satellite mapping table using the PID part of the
destination IP address. We encapsulate the packets with the source
and destination satellite identifiers and tunnel them to the service
satellite. In the corner case where the terminal's service satellite
is different from its access satellite, the service satellite will
relay the packets to the access satellite, which will finally deliver
them to the terminal. In LISP-LEO, the service satellite plays a
similar role as the home agent in Mobile IP, but it is always close
to the mobile terminal, avoiding the triangular routing problem.
Our major contributions are summarized as follows:
* We propose a novel IP addressing method based on location/identity
separation, using different fields of an IP address to separately
identify the location and identity of a mobile terminal. Since
Pan, et al. Expires 15 October 2023 [Page 4]
Internet-Draft LISP-LEO April 2023
the location information of the new address represents the
partition where the terminal is located, the terminal's address
need not be changed when a satellite handover happens.
* We divide the Earth's surface into partitions and maintain a
partition-satellite mapping table in real-time according to the
regularity of satellite motion. We always route traffic to the
satellite above the destined terminal by querying the mapping
table, resolving triangular routing in Mobile IP.
* We deal with the corner case where the satellite above the
destined partition is not the access satellite of the destined
terminal via last-hop relay for accurate traffic delivery.
2. Terminology
This document uses the following terms.
* Satellite Identifier (SID): In LISP-LEO, each satellite is
assigned a unique SID as its identify. All SIDs are represented
by S1, S2, ..., Sm, where m is the total number of satellites.
* Partition Identifier (PID): The Earth's surface is divided into
multiple partitions. Each partition is assigned a unique PID,
which is used to identify the partition. All PIDs are represented
by 1, 2, ..., n, where n is the total number of partitions.
* Identity Identifier (IID): An IID is assigned to a mobile terminal
as its identify. The form of IIDs is the same as PIDs. And the
terminal's address is designed to consist of a PID and an IID.
The PID indicates the terminal's location and represents the
partition where the terminal is located; the IID is used to
identify the terminal.
* Access Satellite: A mobile terminal needs to select a satellite as
its access satellite (its current point of attachment to the LEO
satellite network). To have the best signal transmission quality,
the terminal will select the satellite with the maximum elevation
angle (the nearest) as its access satellite
[papapetrou2004satellite].
* Service Satellite: In this protocol, we establish a one-to-one
mapping between partitions and satellites. Each partition
corresponds to the satellite with the maximum elevation angle from
its center. The satellite associated with a partition is defined
as the service satellite of terminals in that partition.
Pan, et al. Expires 15 October 2023 [Page 5]
Internet-Draft LISP-LEO April 2023
3. Location/Identity Separation-based Protocol
LISP-LEO is an advanced mobility management protocol, and we provide
a detailed description of its technical operations. First, we divide
the Earth's surface into partitions and create a one-to-one mapping
between partitions and satellites. Then, we design a location/
identity separation-based addressing method for each mobile terminal
on the ground to keep its IP address unchanged during satellite
handover. Additionally, to ensure that a mobile terminal is aware of
its access satellite, each satellite broadcasts its presence to the
ground. After receiving the broadcast signals and updating its
access satellite, the terminal registers with its service satellite.
Finally, we examine the end-to-end packet transmission process
between two mobile terminals, covering techniques such as tunneling
and last-hop relay.
3.1. Partition Design
A typical M × N LEO satellite constellation consists of M orbital
planes with N satellites in each plane. Each satellite in the
constellation operates in tandem to provide global coverage of the
Earth's surface. Due to the circular coverage area of each
satellite, the coverage areas of adjacent satellites may overlap,
potentially allowing a mobile terminal to be within the coverage area
of one or more satellites simultaneously.
According to the number of satellites in the LEO satellite
constellation and the coverage area of a satellite, we divide the
Earth's surface into multiple partitions. For simplicity, we use a
uniform division by latitude and longitude, resulting in the same
number of partitions as the number of satellites. The size of each
partition is slightly smaller than the coverage area of a single
satellite. For a typical M × N constellation, the division results
in M × N partitions, each spanning 360/N degrees of latitude and
360/(2 × M) degrees of longitude.
In our design, we assign each partition a unique PID as its identity.
For example, in a 6 × 8 LEO constellation, the Earth's surface is
divided into 48 partitions, each assigned a PID ranging from 1 to 48
as shown in Figure 1. Also, using the latitude and longitude range
of a partition, we can easily find its center. To implement our
protocol, all satellites and mobile terminals on the ground need to
store information about each partition, including its PID and center.
Pan, et al. Expires 15 October 2023 [Page 6]
Internet-Draft LISP-LEO April 2023
+----+----+----+----+----+----+----+----+----+----+----+----+
| 02 | 10 | 18 | 26 | 34 | 42 | 03 | 11 | 19 | 27 | 35 | 43 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 01 | 09 | 17 | 25 | 33 | 41 | 04 | 12 | 20 | 28 | 36 | 44 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 08 | 16 | 24 | 32 | 40 | 48 | 05 | 13 | 21 | 29 | 37 | 45 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 07 | 15 | 23 | 31 | 39 | 47 | 06 | 14 | 22 | 30 | 38 | 46 |
+----+----+----+----+----+----+----+----+----+----+----+----+
Figure 1: The partition design of a 6 x 8 LEO constellation.
3.2. Partition-Satellite Mapping Table
Similar to partitions, each satellite is assigned a unique SID as its
identity. Then we establish a one-to-one mapping between partitions
and satellites. Each partition corresponds to the satellite with the
maximum elevation angle from its center. To keep track of this
mapping, each satellite maintains a partition-satellite mapping
table, which stores the relationship between partitions and
satellites. Specifically, each entry in the mapping table contains a
PID as the key and a SID as the value. For example, in Figure 2,
partition n is associated with satellite Sj, which is recorded as an
entry {n, Sj} in the partition-satellite mapping table.
Pan, et al. Expires 15 October 2023 [Page 7]
Internet-Draft LISP-LEO April 2023
+-------+-------+
| PID | SID | O: satellite *: mobile terminal
+-------+-------+
| n | Sj |
+-------+-------+ Packet Format
| ... | ... | +-------------------+
+-------+-------+ | Src SID: Si |
Mapping Table +-------------------+
| Dst SID: Sj |
----------------+-------------------+----------------
Si / | Src IP: m.a.b.c | \ Sj
O Tunnel Encap +-------------------+ Tunnel Decap O
| | Dst IP: n.x.y.z | |
| +-------------------+ |
+-------------------+ +-------------------+
| Src IP: m.a.b.c | Inter-Satellite Routing | Src IP: m.a.b.c |
+-------------------+ +-------------------+
| Dst IP: n.x.y.z | | Dst IP: n.x.y.z |
+-------------------+ Direction: h1->h2 +-------------------+
| |
| |
* *
h1 h2
Partition: m Partition: n
IP: m.a.b.c IP: n.x.y.z
Figure 2: In LISP-LEO, the packets sent from the source terminal
(h1) to the destination terminal (h2) will first query the
partition-satellite mapping table in the satellite above the head
(Si), using the PID (n) in the destination IP to obtain the
corresponding SID (Sj), then encapsulated and tunneled via inter-
satellite routing to the satellite (Sj) above the destination
terminal (h2).
As satellites periodically fly over the Earth's surface, the mapping
relationship keeps changing. Therefore, each satellite needs to
update its mapping table according to the regularity of satellite
motion. The update process is as follows:
* First, each satellite obtains its location (its latitude and
longitude information) via GPS. Then according to the real-time
satellite location prediction approach [pan2019opspf], the
satellite estimates the location of other satellites.
Pan, et al. Expires 15 October 2023 [Page 8]
Internet-Draft LISP-LEO April 2023
* Second, the elevation angle between the center of each partition
and each satellite is calculated separately. This calculation is
based on the partition information that is pre-stored and the
location information of each satellite obtained in the previous
step.
* Finally, the partition-satellite mapping table is updated with new
information. Specifically, the mapping table is updated to
associate each partition with the satellite that has the maximum
elevation angle from the center of that partition.
3.3. Location/Identity Separation-based Addressing
Based on the above partition design, we introduce a new addressing
method based on location/identity separation. The terminal's address
is designed to consist of a PID and an IID:
IP Address = PID + IID.
In the new address, the PID indicates the terminal's location and
represents the partition where the terminal is located; the IID is
used to identify the terminal. As shown in Figure 2, terminal h1 is
located in partition m and its address is m.a.b.c. Here, we follow
the rule of the Class A IPv4 address (32-bit) [RFC0791]. The first 8
bits of the address are used for the PID and the remaining 24 bits
represent the IID. Moreover, to avoid conflicting with others' IIDs
when a mobile terminal moves into a neighbor partition, its IID
should be globally unique.
Each mobile terminal obtains its address by calculating its PID and
IID. The calculation rules are as follows:
* PID: Each mobile terminal obtains its location via GPS and
calculates the partition containing the location according to the
pre-stored partition information.
* IID: Each mobile terminal has been assigned a constant IID in
advance which will not be changed.
According to the proposed addressing method, when a mobile terminal
moves within a partition, its address will remain unchanged even if a
satellite handover occurs. Moreover, the addressing method has good
scalability. When the number of partitions increases in the future,
we can further consider a support for longer-bit partition fields of
IP addresses. And if we want to further support more mobile
terminals in the LEO satellite network, we can even adopt the IPv6
address format (longer-bit, 128-bit) [RFC2460].
Pan, et al. Expires 15 October 2023 [Page 9]
Internet-Draft LISP-LEO April 2023
3.4. Satellite Broadcast
As described earlier, each mobile terminal on the ground is covered
by at least one satellite to meet its communication requirements.
When a mobile terminal moves into the overlapping coverage areas of
multiple satellites, it is necessary to select a suitable access
satellite as its current point of attachment to the LEO satellite
network. To achieve this, we design a satellite broadcast mechanism.
Each satellite periodically broadcasts within its coverage area to
advertise its service. Each broadcast message contains information
about the corresponding satellite, such as its SID and location.
Each mobile terminal determines its access satellite relying on the
broadcasts it receives. To have the best signal transmission
quality, the terminal selects the satellite with the maximum
elevation angle (the nearest) as its access satellite
[papapetrou2004satellite]. Specifically, after receiving satellite
broadcasts from multiple satellites, the terminal obtains the
location of these satellites. Then combined with the terminal's
location obtained from GPS, the terminal calculates the satellite
with the maximum elevation angle, which is chosen as the terminal's
access satellite.
3.5. Terminal Registration with the Service Satellite
Based on the mapping relationship depicted in Section 3.2, the
satellite associated with a partition is designated as the service
satellite for mobile terminals within that partition. In our
protocol, the service satellite is considered to be crucial and plays
a similar role to the home agent in Mobile IP. And we design a
registration mechanism to maintain mobility bindings at the service
satellite. Specifically, each mobile terminal must register with its
service satellite after updating its access satellite. This
registration process creates or modifies a mobility binding at the
service satellite that associates the terminal's address with the SID
of its access satellite.
Pan, et al. Expires 15 October 2023 [Page 10]
Internet-Draft LISP-LEO April 2023
As previously mentioned, the coverage area of a satellite is slightly
larger than the size of a partition. Additionally, the maximum
elevation angle rule dictates that a mobile terminal's access
satellite is closest to itself, while its service satellite is
closest to the center of the partition where the terminal is located.
As a result, a mobile terminal's service satellite is either the
access satellite or one of the four adjacent satellites of the access
satellite. To deal with both scenarios, our protocol defines two
different registration procedures, one registering directly with the
terminal's service satellite, and the other registering via a non-
service satellite that relays the registration to the terminal's
service satellite one-hop away. The following rules specify the
different conditions to use the above two registration procedures:
* Direct Registration: If a mobile terminal's access satellite
happens to be its service satellite, the mobile terminal must
register directly with its service satellite.
* Indirect Registration: If a mobile terminal's access satellite is
not its service satellite, the mobile terminal must register
indirectly with its service satellite via its access satellite.
Both registration procedures involve the exchange of Registration
Request and Registration Reply messages. As shown in Figure 3, when
registering directly with the service satellite, the registration
procedure only requires the following two messages:
(1) The mobile terminal sends a Registration Request to the
service satellite.
(2) The service satellite responses a Registration Reply to the
mobile terminal, granting the Request.
Pan, et al. Expires 15 October 2023 [Page 11]
Internet-Draft LISP-LEO April 2023
O: satellite
*: mobile terminal
Si
Satellite +------------O------------+
\#
\\
b \\
\\ a
\\
#\
The Earth's Surface +------------------*------+
MT
a. MT sends a Registration Request to Si
b. Si sends a Registration Reply to MT
Si is not only the MT's service satellite,
but also its access satellite.
Figure 3: Registering directly with the service satellite.
As shown in Figure 4, when the mobile terminal registers indirectly
with the service satellite via the access satellite instead, the
registration procedure requires the following four messages:
(1) The mobile terminal sends a Registration Request to the access
satellite to start the registration process.
(2) The access satellite processes the Registration Request and
then relays it to the service satellite one-hop away.
(3) The service satellite sends a Registration Reply back to the
access satellite to grant the Request.
(4) The access satellite processes the Registration Reply and then
relays it to the mobile terminal to inform it of the disposition
result of its Request.
Pan, et al. Expires 15 October 2023 [Page 12]
Internet-Draft LISP-LEO April 2023
O: satellite
*: mobile terminal
b
Si #--- Sj
Satellite +----O----------------O------+
---# /#
c //
d //
// a
//
#/
The Earth's Surface +-------------*--------------+
MT
a. MT sends a Registration Request to Sj
b. Sj relays the Registration Request to Si
c. Si sends a Registration Reply to Sj
d. Sj relays the Registration Reply to MT
Si is the MT's service satellite and Sj is
its access satellite.
Figure 4: Registering indirectly with the service satellite.
To prevent registration failure caused by packet loss or other
issues, a mobile terminal initiates a timer with a reasonable waiting
time each time it sends a Registration Request. If no Registration
Reply is received within the specified waiting time, the mobile
terminal will resend a new Registration Request. The timer settings
should take into account the round-trip time (RTT) of space-
terrestrial communication as well as the message processing latency.
In the proposed registration mechanism, each mobile terminal will
register with its service satellite when a satellite handover occurs.
Due to the periodic movement of satellites over the Earth's surface,
a mobile terminal's service and access satellites are constantly
changing. However, a mobile terminal's service satellite is always
either the access satellite or one of the access satellite's four
neighbors. This ensures that the distance between the mobile
terminal and its service satellite remains relatively stable during
satellite motion. Consequently, the registration latency is also
bounded within a stable range proportional to the distance between
the mobile terminal and its service satellite.
Note that the satellite broadcast interval has an impact on the
timeliness of registration when a satellite handover occurs. If the
interval is too long, the mobile terminal may not receive the
Pan, et al. Expires 15 October 2023 [Page 13]
Internet-Draft LISP-LEO April 2023
broadcasts to update its access satellite in time after handover,
thereby delaying the registration with the service satellite. This
will cause potential packet loss as packets may be routed to a new
service satellite. Due to the lack of the latest registration
information, the new service satellite does not know whether to route
the packets to the mobile terminal or its access satellite, so it
simply drops them. On the contrary, if these broadcasts can be
triggered frequently (such as every 1ms), the mobile terminal can be
sensitive to satellite handovers and complete registration quickly,
at the cost of some message processing overhead.
3.6. End-to-End Transmission between Terminals
As shown in Section 3.2 and Section 3.3, each satellite in the LEO
satellite network maintains a partition-satellite mapping table that
provides a real-time mapping between each partition and the satellite
closest to its center. In addition, the PID in the address of a
mobile terminal indicates the partition where the terminal is
located. Therefore, for communication between a source terminal (ST)
and a destination terminal (DT), when a packet arrives at the ST's
access satellite, we can identify the DT's service satellite by
querying the mapping table using the PID in the destination address.
Once we have determined the service satellite, we can use tunneling
to route the packet between the ST's access satellite and the DT's
service satellite. Specifically, the ST's access satellite
encapsulates the original IP packet and tunnels it to the DT's
service satellite, which is then responsible for delivering the
packet to the DT.
Underneath the tunnel, each satellite functions as a router with its
own routing table and forwards each packet based on its destination
address. The satellite routing table is responsible for storing all
routes to other satellites. Essentially, the inter-satellite network
is the underlay network of the overlay tunnel between the ST and the
DT. We use the SID of the ST's access satellite and the SID of the
DT's service satellite as the source and destination addresses of the
underlay routing for tunneling the original IP packet. This ensures
that the inter-satellite network can be entirely independent from the
ground network, allowing us to use any inter-satellite routing
protocol, such as OPSPF [pan2019opspf], to calculate the satellite
routing table. During inter-satellite routing, after each satellite
receives an incoming packet, it will look up its routing table based
on the destination SID in the outer packet header, determine the next
hop and forward the packet.
Based on the above discussion, we describe the packet transmission
process between terminals in detail:
Pan, et al. Expires 15 October 2023 [Page 14]
Internet-Draft LISP-LEO April 2023
(1) The ST sends an IP packet to its access satellite to start the
packet transmission procedure.
(2) The ST's access satellite queries the local partition-
satellite mapping table, encapsulates the packet, and then
forwards it to the DT's service satellite.
(3) The DT's service satellite queries the registration
information (the bindings between the terminals' addresses and the
SIDs of their access satellites) and forwards the packet to the DT
directly or indirectly.
There are two scenarios in which the DT's service satellite forwards
traffic to the DT. Upon receiving a packet, the service satellite
queries the registered bindings to obtain the corresponding SID
according to the DT's address in the inner packet header. Then, the
service satellite compares the obtained SID with its own SID, and
there are two results. One is that the service satellite is the DT's
access satellite, as shown in Figure 2. In this case, the service
satellite directly decapsulates the packet and forwards it to the DT
through its interface towards the ground. The other is that the DT's
service satellite is not its access satellite, which requires an
additional one-hop relay, as shown in Figure 5. Specifically, the
service satellite needs to relay the packet to the access satellite
first. To achieve this, the service satellite modifies the
destination SID in the outer packet header to the obtained SID (the
access satellite's SID) and the source SID in the outer packet header
to its own SID. After receiving the packet, the DT's access
satellite decapsulates and forwards the packet to the DT.
Pan, et al. Expires 15 October 2023 [Page 15]
Internet-Draft LISP-LEO April 2023
O: satellite
ST: source terminal
DT: destination terminal
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Sm Sn b XX XX Si c Sj
O O--------XX Inter-Satellite Routing XX-------#O--------#O
# XX XX /
/ XXXXXXXXXXXXXXXXXXXXXXXXXXXXX /
a / / d
/ /
/ #
ST DT
a. ST sends an IP packet to Sn b. Sn forwards the packet to Si
c. Si relays the packet to Sj d. Sj forwards the packet to DT
Sm is the ST's service satellite and Sn is its access satellite. Si is the
DT's service satellite and Sj is its access satellite.
Figure 5: Packet transmission between terminals (including last-
hop relay).
To summarize, in LISP-LEO, the traffic from the ST is first forwarded
to the DT's service satellite. If the DT's service satellite is not
its access satellite, the service satellite needs to further deliver
the traffic to the access satellite. As described above, if the DT's
service and access satellites are the same, there is no triangular
routing. Otherwise, the route taken by the traffic destined for the
DT can still be triangular. However, in this case, the DT's service
and access satellites are only one-hop away from each other. So
after arriving at the service satellite, the traffic destined for the
DT only needs an additional one-hop relay to reach the access
satellite, which finally forwards the traffic to the DT.
Consequently, in both cases, LISP-LEO can well address the triangular
routing problem in Mobile IP.
4. Known Open Issues and Areas of Future Work
Based on the above description, this protocol is effective in
situations where mobile terminals always move within their
partitions. However, there is still a chance that a mobile terminal
moves into a neighboring partition during communication, even if a
single partition is designed to be large enough. As illustrated in
Section 3.3, the PID in the terminal's address indicates the current
partition where the terminal is located. So the terminal's address
needs to be updated. Otherwise, the packets destined for the
terminal will be sent to the satellite above the old partition by
Pan, et al. Expires 15 October 2023 [Page 16]
Internet-Draft LISP-LEO April 2023
querying the partition-satellite mapping table, affecting the
accuracy of packet delivery. However, updating the address during
the communication process will interrupt the running TCP connections
and affect the communication quality. Although this document does
not provide a specific solution, we will explore potential options.
One preliminary idea is to allow each mobile terminal to detect
whether its IP address has changed. Once there is a change, the
terminal will send an address notification message to the peer to
notify the changed IP address. After the peer receives the message,
a new TCP connection will be established to maintain the previous
communication.
5. Security Consideration
This present memo does not find any security problem.
6. IANA Consideration
This document has no IANA actions.
7. References
7.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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4",
RFC 3344, DOI 10.17487/RFC3344, August 2002,
<https://www.rfc-editor.org/info/rfc3344>.
7.2. Informative References
[chowdhury2006handover]
Chowdhury, P.K., Atiquzzaman, M., and W. Ivancic,
"Handover schemes in satellite networks: State-of-the-art
and future research directions", 2006.
[darwish2021location]
Darwish, T., Kurt, G., and H. Yanikomeroglu, "Location
management in IP-based future LEO satellite networks: A
review", 2021.
Pan, et al. Expires 15 October 2023 [Page 17]
Internet-Draft LISP-LEO April 2023
[foust2018spacex]
Foust, J., "Spacex's space-internet woes: despite
technical glitches, the company plans to launch the first
of nearly 12,000 satellites in 2019", 2018.
[pan2019opspf]
Pan, T., Huang, T., and X. Li, "OPSPF: Orbit Prediction
Shortest Path First Routing for Resilient LEO Satellite
Networks", 2019.
[papapetrou2004satellite]
Papapetrou, E., Karapantazis, S., and G. Dimitriadis,
"Satellite handover techniques for LEO networks", 2004.
[sanguankotchakorn2008effect]
Sanguankotchakorn, T. and P. Jaiton, "Effect of triangular
routing in mixed IPv4/IPv6 networks", 2008.
[sarikaya2001supporting]
Sarikaya, B. and M. Tasaki, "Supporting node mobility
using mobile IPv6 in a LEO-satellite network", 2001.
Authors' Addresses
Tian Pan
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: pan@bupt.edu.cn
Jun Hu
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: hjun_41@bupt.edu.cn
Yujie Chen
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Pan, et al. Expires 15 October 2023 [Page 18]
Internet-Draft LISP-LEO April 2023
Email: jerrychen@bupt.edu.cn
Xuebei Zhang
China Unicom Research Institute
No. 33 Erlong Road, Xicheng District
Beijing
100048
China
Email: zhangxb170@chinaunicom.cn
Minglan Gao
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: gml@bupt.edu.cn
Pan, et al. Expires 15 October 2023 [Page 19]
