Satellite Ground Routing Architecture Based on Access Satellite Prediction
draft-hou-rtgwg-satellite-ground-routing-00
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.
Document | Type | Active Internet-Draft (individual) | |
---|---|---|---|
Authors | Hou Dongxu , Xiao Min | ||
Last updated | 2024-11-27 | ||
RFC stream | (None) | ||
Intended RFC status | (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-hou-rtgwg-satellite-ground-routing-00
RTGWG H. Dongxu, Ed. Internet-Draft X. Min Intended status: Informational ZTE Corporation Expires: 31 May 2025 November 2024 Satellite Ground Routing Architecture Based on Access Satellite Prediction draft-hou-rtgwg-satellite-ground-routing-00 Abstract 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. 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 5 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Dongxu & Min Expires 31 May 2025 [Page 1] Internet-Draft Satellite Ground Routing Architecture November 2024 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Satellite Ground Routing Architecture . . . . . . . . . . . . 4 5. Node Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 6. Encapsulation Address Generation . . . . . . . . . . . . . . 7 7. Extensions and Future Works . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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. Dongxu & Min Expires 31 May 2025 [Page 2] Internet-Draft Satellite Ground Routing Architecture November 2024 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. 2. Requirements Language 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. 3. Terminology * GS: Ground Station * VLEO: Very Low Earth Orbit with the altitude below 450 km. * LEO: Low Earth Orbit with the altitude between 180 km and 2000 km. * MEO: Medium Earth Orbit with the altitude between 2000 km and 35786 km. * GEO: Geosynchronous Orbit with the altitude 35786 km. * Intra-satellite links: Links between adjacent satellites in the same orbit. * Intra-satellite links: Links between adjacent satellites in the different orbits. * SGP4: Simplified Perturbations Models Dongxu & Min Expires 31 May 2025 [Page 3] Internet-Draft Satellite Ground Routing Architecture November 2024 * Lon: Longitude * Lat: Latitude * BGP: Border Gateway Protocol [RFC4271] * IGP: Interior Gateway Protocol, examples of IGPs inculde Open Shortest Path First (OSPF [RFC2328]), Routing Information Protocol (RIP [RFC2453]), Intermediate System to Intermediate System (IS-IS [RFC7142]) and Enhanced Interior Gateway Routing Protocol (EIGRP [RFC7868]). 4. Satellite Ground Routing Architecture 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 Figure 1: Satellite ground routing architecture based on access satellite prediction 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. Dongxu & Min Expires 31 May 2025 [Page 4] Internet-Draft Satellite Ground Routing Architecture November 2024 +==================+======================+================+ | Satellite Number | Satellite Identifier | Network Prefix | +==================+======================+================+ | sat1 | sat1_iden | prefixA | +------------------+----------------------+----------------+ | sat2 | sat2_iden | prefixB | +------------------+----------------------+----------------+ | sat3 | sat3_iden | prefixC | +------------------+----------------------+----------------+ | ...... | ...... | ...... | +------------------+----------------------+----------------+ Table 1: LEO and its access network prefix with ground nodes 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) | +--------------+-----------------------------+--------------+ | ...... | ...... | ...... | +--------------+-----------------------------+--------------+ Table 2: Registration information of ground access nodes 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. Dongxu & Min Expires 31 May 2025 [Page 5] Internet-Draft Satellite Ground Routing Architecture November 2024 5. Node Addressing 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 | └------─-┴---------┴----─------┘ Figure 2: Address format 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. Dongxu & Min Expires 31 May 2025 [Page 6] Internet-Draft Satellite Ground Routing Architecture November 2024 ┌---┬---┬---┬---┬---┬---┬---┬---┬---┬---┐ | 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| └---┴---┴---┴---┴---┴---┴---┴---┴---┴---┘ Figure 3: Geographic division 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. 6. Encapsulation Address Generation 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. Dongxu & Min Expires 31 May 2025 [Page 7] Internet-Draft Satellite Ground Routing Architecture November 2024 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 | +-----------+-----------------------------+ Table 3: Access address of user from t0 to t3 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. 7. Extensions and Future Works 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 Dongxu & Min Expires 31 May 2025 [Page 8] Internet-Draft Satellite Ground Routing Architecture November 2024 8. Security Considerations 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. 9. Acknowledgements TBA 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 11.2. Informative References [I-D.ietf-tvr-use-cases] Birrane, E. J., Kuhn, N., and Y. Qu, "TVR (Time-Variant Routing) Use Cases", Work in Progress, Internet-Draft, draft-ietf-tvr-use-cases-00, 15 April 2023, <https://datatracker.ietf.org/doc/rfc9657>. [I-D.lhan-satellite-semantic-addressing] Han, L., Li, R., Retana, A., chenmeiling, and N. Wang, "Satellite Semantic Addressing for Satellite Constellation", Work in Progress, Internet-Draft, draft- lhan-satellite-semantic-addressing-03, 3 March 2023, <https://datatracker.ietf.org/doc/html/draft-lhan- satellite-semantic-addressing-03>. [KUIPER] "Amazon receives FCC approval for project Kuiper satellite constellation.", <https://tinyurl.com/bs7syjnk>. Dongxu & Min Expires 31 May 2025 [Page 9] Internet-Draft Satellite Ground Routing Architecture November 2024 [Large-Scale-LEO-Network-Routing] "Large Scale LEO Satellite Networks for the Future Internet: Challenges and Solutions to Addressing and Routing," Computer Networks and Communications, 1(1), 31-58", <https://ojs.wiserpub.com/index.php/CNC/article/ view/2105>. [StarLink] "Starlink", <https://en.wikipedia.org/wiki/Starlink>. [ThreeGPP] "3GPP", <https://www.3gpp.org/>. Authors' Addresses Hou Dongxu (editor) ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: hou.dongxu@zte.com.cn Xiao Min ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: xiao.min2@zte.com.cn Dongxu & Min Expires 31 May 2025 [Page 10]