| Internet-Draft | Satellite Ground Routing Architecture | November 2024 |
| Dongxu & Min | Expires 31 May 2025 | [Page] |
With the development of network technology, the satellite network are gradually integrating with the terrestrial network. This draft illustrates a satellite ground routing architecture based on access satellite prediction to solve the end-to-end communication issue in the satellite ground integration scenario where the connection between terrestrial nodes and satellites switches frequently. This architecture includes registration nodes which are responsible for maintaining access node information. Each access node preserve satellite orbit information, performs access satellite prediction, and generates encapsulation addresses. The access satellite undertakes data encapsulation, data forwarding, and data unencapsulation based on encapsulation addresses.¶
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 5 May 2025.¶
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.¶
With the development of network technology, the satellite network are gradually integrating with the terrestrial network. The integration methods includes BGP-based integration and tunnel-based integration.¶
The satellite network and the terrestrial network belongs to different ASs(Autonomous Systems). The routing information between different ASs are exchanged by BGP. BGP adjacency relationships between terrestrial nodes and satellites change with connection variation. If terrestrial routing protocols are directly used in this scenario, following issues would occurs:¶
(1) The connection between terrestrial nodes and satellites switch frequently which causes continuous routing information update.¶
(2) Sudden connection interruption can't be avoided for the complex communication environment in the space.¶
(3) The continuous routing informaiton update further influences the stability of the terrestrial network.¶
Therefore, the tunnel-based integration architecture which isolates the impact between different networks is a viable approach. In this architecture, the satellite network is considered as a system which is independent of the terrestrial network, and doesn't need to recognize the routing information of the terrestrial network. When terrestrial nodes communicate across the satellite network, all data packets need to be encapsulated. The maintenance and acquisition of packet encapsulation information is the key issue in this method. Considering this problem, the draft proposes a satellite ground routing architecture based on access satellite prediction.¶
The architecture includes registration nodes which are responsible for maintaining access node information. Each access node preserve satellite orbit information, performs access satellite prediction, and generates encapsulation addresses. The access satellite undertakes data encapsulation, data forwarding, and data unencapsulation based on encapsulation addresses. Further details are discussed in subsequent sections.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The satellite-ground routing architecture which is based on access satellite prediction contains three types of nodes, namely the terrestrial node, the registration node, and the access satellite, as shown in Figure 1.¶
.--. .--. .--.
###-| N1 |-### <--> ###-| N2 |-### <--> ###-| N3 |-###
\__/ \__/ ------------ \__/
| | / ---------- \1 |
/|\ /|\ * / 2 \ \ /|\
\___/ ┌---┐ / \ \ O
/ \ |───| * ─+─
Ground | |Registration / \
Station └---┘Node User
The satellite which communicates with ground nodes at a designated time is the access satellite. As shown in Figure 1, N1 is the access satellite of GS(Ground Station). The access satellite needs to maintain the mapping relationship between all the satellites and the access network addresses which as shown in Table 1. Considering the support for different network architectures, the satellite identifier in the mapping relationship can be IPv4 addresses, IPv6 addresses, DTN addresses, and etc. Therefore, the address type of satellite identifiers are not specified in Table 1 and are only represented by sat1_iden.¶
| Satellite Number | Satellite Identifier | Network Prefix |
|---|---|---|
| sat1 | sat1_iden | prefixA |
| sat2 | sat2_iden | prefixB |
| sat3 | sat3_iden | prefixC |
| ...... | ...... | ...... |
The registration node records the network information of all the terrestrial nodes accessing the satellite network, as shown in Table 2. This table describes the mapping relationship between network nodes or node identifiers and geographic location, e.g. latitude and longitude.¶
| Network Node | Node Identifier | Geographical Location |
|---|---|---|
| User | prefix1.area_id1.device_id1 | (lon1,lat1) |
| GS | prefix2.area_id2.device_id2 | (lon2,lat2) |
| ...... | ...... | ...... |
The terrestrial node includes ground stations, terminal users, and etc. When the terrestrial node accesses the satellite network, it should communicate with the registration node, register its network information, and obtain network information of other terrestrial nodes firstly. The registration and information acquisition process corresponds to "1" and "2" in Figure 1. To build the link with the registration node, the address of the registration node should be pre-configured on the terrestrial node. In addition, the pre-configured information contains the satellite orbit information and the access network information of different satellites.¶
When accessing the satellite network, the terrestrial node establishes connection with the registration node, and informs its address as well as location informaiton to the registration node.¶
Terrestrial nodes switch connections among multiple satellites for the movement of satellites. The access address of terrestrial nodes would also change accordingly. Therefore, the address information registered by terrestrial nodes should meet two requirements:¶
(1) The address information is the unique identifier of the terrestrial node.¶
(2) Based on the address information and the satellite orbit prediction, the address which is served to connect the remote terrestrial node and the corresponding access satellite at a specified time can be determined.¶
To achieve the above requirements, the address information of terrestrial nodes is represented by a loopback address or router ID, and includes two parts of information, namely the geographic area and the device number within the area. The address format is shown in Figure 2.¶
┌--------┬---------┐-----------┐ | Prefix | Area ID | Device ID | └------─-┴---------┴----─------┘
Prefix: The prefix part of an address, which can be used to distinguish node types such as ground stations, end users, and etc.¶
Area ID: The geographic identifier marks different regions of the Earth, to achieve the mapping relationship between the location of the terrestrial node and the Earth's surface regions, as shown in Figure 3.¶
┌---┬---┬---┬---┬---┬---┬---┬---┬---┬---┐ | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| ├---+---+---+---+---+---+---+---+---+---┤ | 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| ├---+---+---+---+---+---+---+---+---+---┤ | 21| 22| 23| 24| 25| 26| 27| 28| 29| 30| ├---+---+---+---+---+---+---+---+---+---┤ | 31| 32| 33| 34| 35| 36| 37| 38| 39| 40| ├---+---+---+---+---+---+---+---+---+---┤ | 41| 42| 43| 44| 45| 46| 47| 48| 49| 50| └---┴---┴---┴---┴---┴---┴---┴---┴---┴---┘
Device ID: The identification information of the terrestrial node, which is used to distinguish different nodes in the same area.¶
After registration, the terrestrial node can obtain the existing registration information in the network from the registration node.¶
Besides address information of the registration node, the satellite orbit information and the access network information of different satellites should also be pre-configured on the terrestrial nodes. The satellite orbit information is used to determine the satellite ephemeris, that is, to determine which satellite provides services to the designated Earth area at a specified time. The access network information of different satellites refers to the network information used when the satellite is connected to the terrestrial node, and the format has been explained in the previous section.¶
Based on the satellite ephemeris, the access satellite of the remote terrestrial node can be determined at a certain time. Then, according to the access network of the access satellite and the address information of the terrestrial node, the access address of the remote terrestrial node can be calculated at a certain time. A typical example is as follows.¶
The access satellite's access network and the address information of user is prefixA and prefix1.area_id1 respectively at the time slot t1. So the corresponding address of user which is applied to communicate with the access satellite is prefixa.area_id1.device_id1. As shown in Table 3, with the continuous switching of access satellites, the access address of the user is constantly changing. The GS generates and use these access address of destination user for data packet transmission. The process of GS source address obtainment is similar with the above description.¶
| Time Slot | Access Address |
|---|---|
| t0-t1 | prefixA.area_id1.device_id1 |
| t1-t2 | prefixB.area_id1.device_id1 |
| t2-t3 | prefixC.area_id1.device_id1 |
After receiving the data packet from GS, the access satellite of GS parses the destination address of the packet, obtains the prefix informaiton, and queries the destination satellite identifier via this informaiton. Then, the service satellite of GS encapsulates the original data packet and complete the subsequent transmission using its own identifier as the source address and the destination satellite identifier as the destination address.¶
As soon as the destination satellite receives the data packet, it unencapsulates the data packet and transfers it to the destination ground node. The reverse data transmission process of the destination ground node is similar with the above process, and not tired in words here.¶
In the future work, following problems would be taken in mind:¶
(1) Extension of the current routing protocol to support the architecture described in this document.¶
(2) Improvement of the routing algorithm presented in this document to consider more network metrics and obtain the optimal path¶
This document discusses one possible satellite ground routing architecture. This architecture adds a new mechanism which is access satellite prediction, but essentially relies on existing routing protocols. So It has no new security impact.¶
TBA¶
This document has no IANA actions.¶