Internet-Draft Consideration for IP-Based Satellite Rou July 2025
Wang & Zhang Expires 8 January 2026 [Page]
Workgroup:
rtgwg
Internet-Draft:
draft-wang-rtgwg-sat-routing-protocol-consider-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Wang
China Mobile
P. Zhang
Beihang University

Consideration for IP-Based Satellite Routing Protocol

Abstract

This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations.

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 8 January 2026.

Table of Contents

1. Introduction

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.

2. Conventions

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. Advantages

Considering advantages on IP-based satellite routing.

3.1. Standardized Basis for Global Interconnection

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.

3.2. Mature Congestion Control System

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.

3.3. Hardware and Software Ecological Compatibility

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.

4. Challenges

Considering challenges on IP-based satellite routing.

4.1. High Latency Leads to Reduced Protocol Efficiency

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.

4.2. BER and Congestion Misclassification Problem

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.

4.3. Adaptation Challenges for Dynamic Topologies

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.

5. Current Research

Research status on IP-based satellite routing.

5.1. IS-IS and OSPF Extensions

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.

5.2. LISP for Satellite Networks

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.

6. Consideration

Considering requirements for on IP-based satellite routing.

6.1. Support Dynamic 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.

6.2. Support Quality of Service (QoS) Guarantee

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.

6.3. Support Heterogeneous Network Interconnectioncation

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.

7. Conclusion

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

8. Security Considerations

TBD.

9. IANA Considerations

TBD.

10. Informative References

[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., Qu, Y., Taylor, R., and L. Zhang, "TVR (Time-Variant Routing) Use Cases", Work in Progress, Internet-Draft, draft-ietf-tvr-use-cases-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-cases-09>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Jing Wang
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China
Pengfei Zhang
Beihang University
No.37 Xueyuan Road, Haidian District
Beijing
100191
China