| Internet-Draft | Consideration for IP-Based Satellite Rou | July 2025 |
| Wang & Zhang | Expires 8 January 2026 | [Page] |
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations.¶
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 8 January 2026.¶
Copyright (c) 2025 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 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 [I-D.ietf-tvr-use-cases]. 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 [RFC2119] [RFC8174] 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.¶
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.¶
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.¶