Scenarios and Routing Requirements for Mega-Constellation LEO Satellite Networks
draft-miao-rtgwg-satellite-routing-reqs-00

RTGWG                                                            X. Miao
Internet-Draft                                                     P. Du
Intended status: Informational             China Satellite Network Group
Expires: 7 January 2027                                          M. Xiao
                                                                     ZTE
                                                                 F. Yang
                                                            China Mobile
                                                               July 2026

Scenarios and Routing Requirements for Mega-Constellation LEO Satellite
                                Networks
               draft-miao-rtgwg-satellite-routing-reqs-00

Abstract

   With the rapid maturation of laser Inter-Satellite Link (ISL)
   technologies, Low Earth Orbit (LEO) mega-constellations are evolving
   from bent-pipe relay networks dependent on dense Ground Stations (GS)
   into highly autonomous spaceborne routing networks.  Traditional
   terrestrial routing protocols and their variants, such as Global
   Link-State Routing Architectures, rely on a globally consistent link-
   state view and a global convergence paradigm, which are fundamentally
   incompatible with the high dynamics, time-variant topologies, and
   frequent link disruptions characteristic of ten-thousand-node scale
   satellite networks.  This document describes core routing scenarios
   including non-dense ground deployment and inter-continental transit,
   analyzes the engineering infeasibility of global convergence
   protocols in space environments, reviews the limitations of existing
   mitigation approaches, and specifies key requirements for satellite
   routing protocols centered around localized autonomy and distributed
   decision-making.

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

Miao, et al.             Expires 7 January 2027                 [Page 1]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   This Internet-Draft will expire on 2 January 2027.

Copyright Notice

   Copyright (c) 2026 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases and Network Scenarios . . . . . . . . . . . . . . .   4
     3.1.  Evolution from Dense GS to Spaceborne Laser Transit
           Networks  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Objective Assessment of Performance Bottlenecks . . . . .   6
   4.  Limitations of Global Convergence Paradigms . . . . . . . . .   6
     4.1.  Conflict Between Global Consistency and Time-Variant
           Topologies  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Control Plane Overhead Scaling with Network Size  . . . .   7
     4.3.  Engineering Challenges of Network-Wide Shortest-Path
           Convergence . . . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  Mismatch between Network-Wide State Maintenance and
           On-Board Resource Constraints . . . . . . . . . . . . . .   7
   5.  Existing Mitigation Approaches  . . . . . . . . . . . . . . .   8
     5.1.  Ground-Centric Architectures  . . . . . . . . . . . . . .   8
     5.2.  Topology Abstraction Architecture Based on Orbital Domain
           Partitioning  . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Remaining Challenges  . . . . . . . . . . . . . . . . . .  10
   6.  Core Routing Requirements for Mega-Constellations . . . . . .  11
     6.1.  Scalable Routing-State Control  . . . . . . . . . . . . .  11
     6.2.  Awareness of Scheduled Topology Changes . . . . . . . . .  11
     6.3.  Fast Recovery from Unplanned Failures . . . . . . . . . .  11
     6.4.  Lightweight Forwarding State  . . . . . . . . . . . . . .  12
     6.5.  On-Board Autonomy with Ground Assistance  . . . . . . . .  12
   7.  Quantitative Objectives and Metrics . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13

Miao, et al.             Expires 7 January 2027                 [Page 2]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   10. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   11. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In recent years, the deployment scale of Low Earth Orbit (LEO) mega-
   constellations has reached the threshold of tens of thousands of
   nodes.  Early discussions on satellite routing primarily focused on
   utilizing mature terrestrial routing protocols (e.g., IS-IS) combined
   with area proxies or time-variant schedules to resolve scalability
   issues in the space segment.  However, with the exponential
   advancement of space laser communications in terms of bandwidth and
   stability, the underlying physical architecture of satellite networks
   has undergone a fundamental shift.  Satellite networks are
   progressively decoupling from their heavy reliance on dense
   terrestrial Ground Stations (GS) and evolving into highly autonomous,
   vacuum-based spaceborne routing networks.

   Traditional terrestrial routing protocols are designed with the core
   assumption of relatively stable topologies and low link-state change
   rates.  Directly applying the global convergence paradigm of the
   terrestrial Internet (such as Global Link-State Routing
   Architectures) to space topologies leads to severe link-state
   advertisement storms and persistent routing obsolescence due to high-
   frequency topology variations.  This document systematically reviews
   the realistic scenarios of satellite routing networks, evaluates
   existing mitigation mechanisms, and defines the functional and
   performance requirements that satellite routing protocols must
   satisfy.

2.  Conventions

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

2.2.  Terminology

   The following terms are defined for use in this document:

   ISL (Inter-Satellite Link)  A link between two satellite nodes,
      specifically referring to vacuum photon transmission links
      realized via space laser communications in this document.

Miao, et al.             Expires 7 January 2027                 [Page 3]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   GS (Ground Station)  Terrestrial facilities responsible for
      connecting the space segment to land-based network
      infrastructures.

   PoP (Point of Presence)  Interface points where the satellite network
      connects to the terrestrial Internet core.

   Time-Variant Topology  The characteristic of LEO satellite networks
      where inter-satellite geometric relationships and link
      reachability change periodically, predictably, yet at high
      frequencies due to high-speed orbital dynamics.

3.  Use Cases and Network Scenarios

3.1.  Evolution from Dense GS to Spaceborne Laser Transit Networks

   Early commercial satellite networks relied heavily on the dense
   deployment of local Ground Stations.  In this mode, satellites merely
   acted as "bent-pipes in the sky," and the data flow exhibited a
   simplistic single-hop structure:

     [ User Terminal ]
          |
          v (Uplink)
     [ Space Satellite A ]
          |
          v (Downlink)
     [ Local Dense GS ] ---> [ Terrestrial Internet Core ]

   Figure 1: Traditional Data Flow under Dense Ground Station Deployment

   However, in actual deployment, global GS construction faces complex
   transnational regulatory constraints, exorbitant construction and
   maintenance costs, and geopolitical security risks.  Consequently,
   most commercial constellations cannot achieve dense global ground
   deployment.  With the comprehensive adoption of vacuum laser ISLs in
   next-generation constellations, user data flows have shifted to a
   non-dense ground deployment mode utilizing multi-hop spaceborne
   transits:

Miao, et al.             Expires 7 January 2027                 [Page 4]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

  [ User Antenna ]
       |
       v (Uplink)
  [ Space Satellite A ] --(Vacuum Laser ISL)--> [ Space Satellite B ]
                                                       |
                                                (Vacuum Laser ISL)
                                                       v
  [ Remote GS ] <-- (Downlink, Thousands of km) -- [ Space Satellite C ]
       |
       v
  [ Terrestrial Internet PoP ]

 Figure 2: Multi-hop Space Transit Data Flow in Non-Dense GS Regions

         Dense GS Era
      +---------------+
      |      GS       |
      +-------+-------+
              |
            SAT
              |
            UT
                  |
                  v

            ISL-Assisted Era

      GS ---- SAT ---- SAT
                  \
                   \
                    UT

                   |
                   v

    Spaceborne Routing Era

    UT -- SAT -- SAT -- SAT -- SAT
                               |
                              GS
                               |
                              PoP

        Figure 3: Architectural Evolution of LEO Satellite Networks

Miao, et al.             Expires 7 January 2027                 [Page 5]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   As ISL capabilities improve and gateway density decreases, the space
   segment progressively evolves from a simple access network into an
   autonomous routing network.

3.2.  Objective Assessment of Performance Bottlenecks

   Prior network analyses asserted that performance degradation in non-
   dense GS regions stems directly from the scarcity of local ground
   stations.  However, the extended physical distance between users and
   ground stations, which necessitates multi-hop inter-satellite transit
   before downlinking, does not inherently entail a degradation in
   communication performance.  On the contrary, since light propagates
   approximately 30% faster in a vacuum than in standard terrestrial
   silica fiber optics, data transmission via spaceborne laser networks
   can potentially achieve higher speeds than conventional terrestrial
   networks.  When providing long-distance inter-continental transit
   (e.g., New York to London, Tokyo to Los Angeles, and Sydney to
   Singapore), the theoretical physical latency of inter-satellite laser
   links is lower than that of traditional submarine fiber cables.
   Operational engineering practices demonstrate that the performance
   ceiling of satellite routing networks is actually restricted by the
   highly non-uniform global distribution of terrestrial Internet Points
   of Presence (PoPs).  With the enhanced transit capabilities of the
   space segment, the routing and scheduling efficiency of data packets
   within the space network directly determines whether they can be
   precisely and efficiently delivered to the optimal terrestrial PoP
   egress.

4.  Limitations of Global Convergence Paradigms

   A global link-state routing architecture computes routes by
   distributing link-state topology information and running SPF
   (Shortest Path First) computation.  In LEO constellations with tens
   of thousands of nodes, directly applying network-wide fine-grained
   link-state flooding and globally synchronized convergence may face
   significant scalability and stability challenges.  This is not merely
   a local issue that can be solved by parameter tuning; rather, it
   reflects a fundamental mismatch between the design assumptions of
   such mechanisms and the physical characteristics of satellite
   networks.

Miao, et al.             Expires 7 January 2027                 [Page 6]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

4.1.  Conflict Between Global Consistency and Time-Variant Topologies

   LEO satellites move at speeds greater than 27,000 km/h.  Due to
   relative geometric changes, satellite attitude control, and optical
   pointing adjustment, inter-satellite link events, including link
   disruption and peer change, may occur on timescales ranging from
   seconds to minutes.  A global link-state routing architecture relies
   heavily on multi-hop control-message flooding across the network to
   maintain a consistent link-state view.  In a constellation with tens
   of thousands of nodes, the time required for control messages to
   propagate across the network may be significantly longer than the
   topology change interval.  As a result, convergence may lag behind
   topology changes, and route computation may rely on stale views.

4.2.  Control Plane Overhead Scaling with Network Size

   When the number of constellation nodes reaches tens of thousands, the
   number of dynamic inter-satellite links also increases with the scale
   of the constellation.  Any regular link up/down event may trigger
   network-wide flooding.  The control plane would need to frequently
   encapsulate and transmit link-state advertisements, which may lead to
   excessive control-plane churn in the space segment.  This can consume
   scarce inter-satellite control-channel resources and significantly
   reduce bandwidth available for user data traffic.

4.3.  Engineering Challenges of Network-Wide Shortest-Path Convergence

   In a highly dynamic satellite network, propagation delay and
   continuous topology changes make it difficult for all nodes to obtain
   a fully consistent and up-to-date topology view at the same time.
   Under such conditions, frequent attempts to achieve network-wide
   consistent shortest-path convergence may cause repeated computation,
   path oscillation, and forwarding instability, thereby affecting
   service continuity and reliability.

4.4.  Mismatch between Network-Wide State Maintenance and On-Board
      Resource Constraints

   Network-wide link-state routing requires participating nodes to
   maintain large-scale topology state and perform corresponding path
   computation.  Compared with terrestrial equipment, on-board computing
   environments are constrained by power, thermal dissipation, storage,
   and radiation conditions.  Requiring satellite nodes to maintain
   network-wide fine-grained state and frequently perform large-scale
   path computation would significantly increase operational burden and
   engineering risk.

Miao, et al.             Expires 7 January 2027                 [Page 7]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

5.  Existing Mitigation Approaches

   The challenges discussed in the previous section have motivated the
   development of several architectural approaches intended to improve
   the scalability and operational feasibility of large-scale satellite
   networks.  Rather than attempting to maintain complete network-wide
   topology awareness at all times, these approaches seek to reduce
   routing complexity through infrastructure assistance, topology
   abstraction, or predictive mechanisms.  Although such techniques
   significantly improve practicality in current deployments, important
   challenges remain as satellite networks continue evolving toward
   increasingly autonomous spaceborne routing systems.

5.1.  Ground-Centric Architectures

   Many existing broadband satellite systems minimize onboard routing
   complexity by relying heavily on terrestrial infrastructure.  In such
   architectures, user traffic is forwarded to a visible satellite and
   subsequently delivered to a nearby Ground Station (GS) whenever
   possible.  The terrestrial Internet then performs the majority of
   long-distance transport and routing functions.  Inter-satellite links
   primarily serve as extensions of gateway reachability rather than as
   a fully autonomous spaceborne routing fabric.

   This design offers significant operational advantages.  Satellites
   are not required to maintain extensive routing state, route
   computation complexity remains low, and network management can
   leverage the mature capabilities of terrestrial infrastructure.  The
   success of current commercial deployments demonstrates the
   practicality of this approach under conditions where sufficient
   gateway coverage is available.

   However, the effectiveness of ground-centric architectures depends
   heavily on the availability of geographically distributed ground
   infrastructure.  As future constellations expand service coverage to
   oceans, polar regions, remote territories, and long-distance
   intercontinental routes, traffic increasingly traverses multiple
   inter-satellite hops before reaching a gateway.  In such scenarios,
   the space segment itself becomes an active routing network rather
   than a simple relay system.  Routing efficiency within the satellite
   constellation directly influences end-to-end performance, making
   distributed spaceborne routing capabilities increasingly important.

Miao, et al.             Expires 7 January 2027                 [Page 8]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

5.2.  Topology Abstraction Architecture Based on Orbital Domain
      Partitioning

   To improve the scalability of large satellite networks, recent
   architectural proposals have introduced various forms of topology
   abstraction and hierarchical organization.[RFC9717]proposes a
   satellite network routing architecture based on existing routing
   protocols and mechanisms.  Its core idea is to organize satellites in
   adjacent orbits into larger routing areas and to reduce topology
   visibility across area boundaries through area abstraction, thereby
   limiting the amount of link-state information distributed across the
   entire network.

           +------------------+
           |     Domain A     |
           |  SAT SAT SAT     |
           |  SAT SAT SAT     |
           +------------------+
                    |
              Abstract View
                    |
           +------------------+
           |     Domain B     |
           |  SAT SAT SAT     |
           |  SAT SAT SAT     |
           +------------------+

           Figure 4: Example of Hierarchical Topology Abstraction

   This architecture also uses the predictability of satellite orbital
   motion to introduce scheduled link-connectivity change information
   into the routing system.  For predictable link disruption or topology
   adjustment, the routing system can obtain relevant information in
   advance and perform necessary routing adjustment before the actual
   change occurs, thereby reducing the impact of periodic topology
   changes on the control plane.

   These approaches show that orbital domain partitioning, topology
   abstraction, and scheduled link awareness can effectively mitigate
   routing-state scaling issues in large-scale satellite networks.
   [RFC9717] focuses on providing a satellite network routing
   architecture based on existing routing protocols and forwarding
   mechanisms, and provides an important reference for subsequent
   routing-requirement analysis and protocol-mechanism design for LEO
   mega-constellations.

Miao, et al.             Expires 7 January 2027                 [Page 9]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

5.3.  Remaining Challenges

   Existing approaches have significantly advanced the operational
   capability of satellite networks and demonstrated practical methods
   for managing large constellations.  In particular, these approaches
   often rely on assumptions of predictable topology evolution based on
   orbital mechanics and scheduled connectivity information, as well as
   hierarchical routing abstractions (e.g., backbone and non-backbone
   role separation) to improve scalability.  However, such assumptions
   may not fully capture the stochastic nature of inter-satellite link
   dynamics or the homogeneous characteristics of satellite nodes in
   large-scale LEO constellations.  As LEO mega-constellations evolve
   toward more autonomous satellite transport networks, several
   challenges remain that need to be considered in subsequent routing-
   requirement and protocol-design work.

   First, routing-domain partitioning still depends on the link
   stability, orbital configuration, and connectivity characteristics of
   a specific constellation.  How to determine routing areas that are
   stable, connected, and bounded in size under different constellation
   configurations and link conditions remains an open issue.

   Second, scheduled topology changes can be handled in advance through
   scheduling information, but unplanned link failures remain
   unavoidable.  The routing system still needs to maintain service
   continuity while limiting the impact scope, preventing local failures
   from evolving into large-scale control-plane disturbance.

   Third, the routing protocol needs to clarify the propagation scope of
   state information, how scheduled changes and unplanned changes should
   be handled differently, what granularity of routing state satellite
   nodes should maintain, and how route computation should adapt to
   constrained on-board resources.

   Fourth, the routing system needs to maintain cross-region
   reachability, path stability, and fast recovery without requiring a
   complete network-wide fine-grained topology view.

   These remaining challenges motivate the routing requirements
   described in the next section.

Miao, et al.             Expires 7 January 2027                [Page 10]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

6.  Core Routing Requirements for Mega-Constellations

   Based on the above scenarios and constraints, the design objective of
   a routing protocol for LEO mega-constellations SHOULD NOT be to
   frequently compute instantaneous globally optimal paths.  Instead,
   the protocol SHOULD maintain network reachability, control-plane
   stability, path continuity, and fast recovery under constrained state
   size and constrained computing resources.  The protocol SHOULD
   satisfy the following core requirements.

6.1.  Scalable Routing-State Control

   The routing protocol SHOULD support routing-state control in
   scenarios with tens of thousands of highly dynamic satellite nodes.
   The protocol SHOULD NOT require every satellite node to maintain a
   complete network-wide fine-grained topology view, and SHOULD NOT
   trigger network-wide link-state flooding due to local link changes.

   Any link disruption triggered by local dynamics, such as polar-region
   traversal or minor attitude adjustment, SHOULD be handled
   preferentially within the affected routing area.  Only when a local
   event affects cross-region reachability or critical forwarding
   capability SHOULD necessary abstracted state changes be advertised
   externally.

6.2.  Awareness of Scheduled Topology Changes

   Because satellite orbital mechanics are highly predictable, the
   routing protocol SHOULD incorporate time-varying connectivity plans
   distributed by the management plane.  For predictable link
   disruption, link establishment, peer change, or bandwidth variation,
   the protocol SHOULD be able to receive and use the corresponding
   planning information.

   The protocol SHOULD support necessary metric adjustment, path
   preparation, or forwarding-state update before scheduled topology
   changes occur, in order to reduce service interruption, packet loss,
   and control-plane instability.

6.3.  Fast Recovery from Unplanned Failures

   The routing protocol SHOULD be able to handle unplanned link failures
   and abrupt link-quality degradation.  For sudden link failures,
   short-term loss of lock, equipment faults, or local congestion, the
   protocol SHOULD support fast detection, fast bypass, and local
   recovery.

Miao, et al.             Expires 7 January 2027                [Page 11]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   The protocol SHOULD limit the impact of failures to a local scope
   and, when necessary, advertise only abstracted reachability changes
   externally.

6.4.  Lightweight Forwarding State

   A satellite node SHOULD NOT be required to maintain a complete global
   forwarding table containing massive terrestrial user prefixes or all
   constellation-node information.  The protocol SHOULD support prefix
   aggregation, area abstraction, label forwarding, or other lightweight
   mechanisms to reduce satellite forwarding-state size.

   The forwarding mechanism SHOULD adapt to the storage, computing,
   power, and reliability constraints of on-board equipment, and SHOULD
   support stable end-to-end forwarding within a limited forwarding-
   table size.

6.5.  On-Board Autonomy with Ground Assistance

   The routing protocol SHOULD support basic routing operation on
   satellite nodes in the absence of continuous ground control.  Ground
   systems can provide constellation plans, policy configuration, and
   global optimization information.  The satellite routing system SHOULD
   provide a certain level of autonomous operation capability to support
   sparse ground-station coverage, transoceanic and intercontinental
   relay, and long-distance inter-satellite multi-hop routing scenarios.

7.  Quantitative Objectives and Metrics

   To support objective evaluation and conformance testing, satellite
   routing protocols SHOULD satisfy the following quantitative
   engineering baselines in large-scale deployments.  Specific values
   MAY be further refined according to constellation scale, link
   capability, and service class.

   1.  Node Scalability: The routing control plane SHOULD support at
       least 10,000 highly dynamic satellite nodes in concurrent
       operation and SHOULD be scalable toward 50,000 nodes.  Persistent
       control-plane congestion, memory exhaustion, or route-computation
       failure SHOULD NOT occur.

   2.  Impact of Scheduled Handover: For predictable link-state changes,
       the routing protocol SHOULD support advance awareness, path
       preparation, and forwarding-state update.  Link handover time
       SHOULD be no greater than 100 ms, and near-seamless path
       migration SHOULD be supported.

Miao, et al.             Expires 7 January 2027                [Page 12]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   3.  Unplanned Failure Recovery Time: Under a single-link failure, the
       service recovery time from link-failure detection to traffic
       switchover to a backup path SHOULD be no greater than 100 ms.

   4.  Control Plane Overhead: Under continuously highly dynamic
       constellation operation, the bandwidth consumed by routing
       protocol control messages SHOULD NOT exceed 1% of the total
       available bandwidth of any single physical link.

8.  Security Considerations

   Due to their exposed physical nature, spaceborne wireless and laser
   links face significantly higher risks of eavesdropping, malicious
   packet injection, and node spoofing than terrestrial fiber
   infrastructure.  Distributed routing protocols MUST implement
   lightweight, highly cryptographic authentication mechanisms for
   localized flooded control messages to prevent malicious or
   compromised nodes from introducing forged link states that cause
   network-wide traffic blackholes or Denial-of-Service (DoS) attacks.

9.  IANA Considerations

   This document has no IANA actions.

10.  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.  Informative References

   [RFC9717]  Li, T., "A Routing Architecture for Satellite Networks",
              RFC 9717, DOI 10.17487/RFC9717, January 2025,
              <https://www.rfc-editor.org/info/rfc9717>.

Authors' Addresses

   Xin Miao
   China Satellite Network Group
   Email: xin.miao.ietf@outlook.com

Miao, et al.             Expires 7 January 2027                [Page 13]
Internet-Draft         LEO Satellite Routing Reqs              July 2026

   Ping Du
   China Satellite Network Group
   Email: pingdu@ustc.edu

   Min Xiao
   ZTE
   Email: xiao.min2@zte.com.cn

   Feng Yang
   China Mobile
   Email: yangfeng@chinamobile.com

Miao, et al.             Expires 7 January 2027                [Page 14]