| Internet-Draft | LISP-LEO | April 2023 |
| Pan, et al. | Expires 15 October 2023 | [Page] |
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.¶
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 15 October 2023.¶
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.¶
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 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.¶
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:¶
This document uses the following terms.¶
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.¶
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.¶
+----+----+----+----+----+----+----+----+----+----+----+----+ | 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 | +----+----+----+----+----+----+----+----+----+----+----+----+
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.¶
+-------+-------+
| 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
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:¶
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:¶
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].¶
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.¶
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.¶
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:¶
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:¶
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.
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:¶
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.
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 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.¶
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:¶
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.¶
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.
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.¶
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 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.¶
This present memo does not find any security problem.¶
This document has no IANA actions.¶