Consideration for IP-Based Satellite Routing Protocol

With the continuous evolution of the network, satellite network has gradually become a research hotspot. There were three use cases had been defined in the TVR's use case document . One of them is dynamic reachability; some examples of this use case are mobile satellites, predictable moving vessels and so on. Satellite network and terrestrial network use different physical and link layer protocols, making it difficult to achieve convergence at the bottom layer. This problem can be solved at the network layer. On the one hand, TCP/IP is a simple and open protocol, which can help break the boundaries between heterogeneous networks to realize global interconnection. On the other hand, the business is basically based on IP, and the development of IP-based space network can help realize the business integration and collaboration between heaven and earth and the integration and sharing of network resources, thus reducing the cost of network construction and operation and maintenance, and not only realizing the integration of heaven and earth in a more efficient way, but also better meeting the needs of personal communication and information access, and improving the user experience. The development of IP-based space network can not only realize the integration of air and sky more efficiently, but also better satisfy the needs of personal communication and information acquisition, and improve the user experience and satisfaction. Although the TCP/IP protocol architecture is very mature for terrestrial networks, there are still many challenges in applying it to the satellite network. This document makes some considerations on using IP for the satellite routing.

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 when, and only when, they appear in all capitals, as shown here.

Considering advantages on IP-based satellite routing.

TCP/IP, as the common protocol stack of the Internet, naturally supports the seamless interconnection of satellite networks and terrestrial IP networks. For example, Starlink realizes the integration of satellite link and terrestrial backbone network through TCP/IP protocol, and user terminals can directly use standard IP addresses to access Internet services. This standardization lowers the technical threshold for the integration of heaven and earth networks, making satellite communications an effective supplement to terrestrial networks, which is especially valuable in remote areas or emergency communication scenarios.

Mechanisms such as slow start and congestion avoidance of the TCP protocol provide basic congestion management capabilities for satellite networks. Although the high latency of satellite links can diminish their effectiveness, the speed of response to bandwidth changes can be optimized through improved algorithms such as TCP Westwood. For example, in LEO satellite networks, TCP CUBIC can maintain high link utilization during bandwidth fluctuations by dynamically adjusting the window growth rate.

Satellite communication equipment can directly reuse mature technologies of terrestrial networks, such as IP-based routers and switches. This not only reduces R&D costs, but also facilitates the introduction of emerging technologies such as edge computing and network function virtualization (NFV). For example, on-board nodes can deploy intelligent routing functions to optimize transmission efficiency by adjusting TCP parameters in real time.

Considering challenges on IP-based satellite routing.

The round-trip latency of geosynchronous orbit (GEO) satellites is about 560ms, while low orbit (LEO) satellites reduce the latency to 30-80ms, but it is still much higher than the terrestrial network. the acknowledgement mechanism of the TCP protocol significantly reduces the throughput in this environment, for example, the efficiency of the TCP basic mode transmission may be less than 25% in GEO satellites. In addition, delay jitter (e.g., an average of 6.7ms RTT fluctuation in Starlink) further interferes with the stabilization of the congestion window.

Satellite channel BERs (Bit Error Rate) are typically 10-⁶-10-⁷, much higher than terrestrial wired networks.The TCP protocol can mistake packet loss due to random BERs for congestion, triggering unwanted window shrinkage. For example, during inclement weather, such as rain failure, the BER of a satellite link can spike, causing TCP throughput to drop by more than 50 percent.

Satellite network topology changes periodically due to orbital motion, with LEO satellites switching service satellites every 15 seconds or so, resulting in link interruptions or sudden changes in bandwidth. Traditional TCP/IP routing protocols (e.g., OSPF) can hardly adapt to such changes quickly, which may cause path oscillation or data loss. In addition, the establishment and disruption of inter-satellite links can lead to network segmentation, which increases the complexity of route recalculation.

In satellite networks, the movement of satellites causes dynamic changes in the network topology. This necessitates frequent routing calculations and updates by routing protocols to adapt to these changes. For instance, in low-Earth orbit satellite networks, the rapid movement of satellites may lead to frequent updates of routing tables. Each update consumes energy, including onboard processing power and communication energy, thereby increasing the complexity of overall energy management.

Research status on IP-based satellite routing.

The IGP extensions for predictable and scheduled changes of TVR has been defined in [I-D.zw-lsr-tvr-extensions]. This document defines the a set of extensions to IS-IS, OSPFv2 and OSPFv3 for predictable and scheduled changes of TVR. These extensions can be advertised by the node self which has predictable and scheduled changes, or by the node which connected or adjacenct to the node which has predictable and scheduled changes.

The document [I-D.farinacci-lisp-satellite-network] gives the adaptation of LISP in satellite networks. It describes how a LISP overlay structure can run on top of a satellite network underlay. This satellite deployment use-case (described in this document) requires no changes to the LISP architecture or standard protocol specifications. In addition, any LISP implementations that run on a device with an existing satellite interface does not need to be upgraded.

The document define a new 8 B network header for DR-SDSN(Software-defined satellite networking) to further decrease overheads in packet encapsulations, where 16-bit addresses are used instead of 32-bit IPv4 and 128- bit IPv6 addresses. the primary two motivations are as follows. First, considering the limited number of satellites in the constellation, it is sufficient to adopt 16-bit Locs for node addressing, and shorter identifiers as the source and destination address can significantly decrease header overheads for encapsulations. Then, to distinguish different consumers and traffic, user priority and type of service should be indicated in the header so that forwarding nodes can determine the user privilege in resource allocation and requirement preference for flow steering.

Considering requirements for on IP-based satellite routing.

Networking using IP provides superior flexibility, enhanced scalability, and support for dynamic routing and mobile access, among other things. However, the topology of satellite networks containing time-varying characteristics changes frequently, and traditional static routing techniques cannot meet the demand. Therefore, dynamic routing, such as OSPF, is needed to adapt to the dynamic changes in network topology. Therefore, o MUST provide a discovery and resolving methodology for the dynamic routing.

Satellite network may need to support multiple service types, such as voice, video, data, etc., which have different requirements for QoS. Therefore, it is necessary to design effective QoS guarantee mechanisms, such as differential service (DiffServ), integrated service (IntServ), etc., to meet the needs of different services.. Therefore, o MUST support Quality of Service (QoS) guarantee for the needs of different services.

Since a satellite network may be composed of several different heterogeneous networks, it is necessary to address the need for multiple heterogeneous network connections. Therefore, o MUST Support heterogeneous network interconnectioncation.

This document makes some considerations on IP-based satellite routing.

TBD.