| RFC 9717 | Routing for Satellites | January 2025 |
| Li | Informational | [Page] |
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.¶
This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.¶
This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9717.¶
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.¶
Satellite networks present some interesting challenges for packetnetworking. The entire topology is continually in motion, with linksfar less reliable than what is common in terrestrialnetworks. Some changes to link connectivity can be anticipated due toorbital dynamics.¶
This document proposes a scalable routing architecture for satellite networksbased on existing routing protocols and mechanisms that is enhanced withscheduled link connectivity change information. This document proposesno protocol changes.¶
Large-scale satellite networks are being deployed, presenting anunforeseen application for conventional routing protocols. The highrate of intentional topological change and the extreme scaleare unprecedented in terrestrial networking. Links between satellitescan utilize free-space optics technology that allows liberalconnectivity. Still, there are limitations due to the range of thelinks and conjunction with the sun, resulting in links that are farless reliable than network designers are used to. In addition, linkscan change their endpoints dynamically, resulting in structuralchanges to the topology.¶
Current satellite networks are proprietary, and little information isgenerally available for analysis and discussion. This document isbased on what is currently accessible.¶
This document proposes one approach to provide a routing architecturefor such networks utilizing current standards-based routing technologyand to provide a solution for the scalability of the network whileincorporating the rapid rate of topological change. Thisdocument intends to provide some initial guidance for satellite networkoperators, but without specific details, this document can onlyprovide the basis for a more complete analysis and design.¶
This document presents the author's view and is neither the product of the IETFnor a consensus view of the community.¶
A survey of related work can be found in[Westphal]. Link-state routing forsatellite networks has been considered in[Cao] and[Zhang].¶
Satellites travel in specific orbits around their parent planets. Some of themhave their orbital periods synchronized to planetary rotation, so theyare effectively stationary over a single point. Other satellites have orbitsthat cause them to travel across regions of the planet either gradually or quiterapidly. Respectively, these are typically known as the Geostationary Earth Orbit(GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on thealtitude. This discussion is not Earth-specific; as we get to other planets, wecan test this approach's generality.¶
Satellites may have data interconnections with one another throughInter-Satellite Links (ISLs). Due to differences in orbits, ISLs may beconnected temporarily with periods of potential connectivity computed throughorbital dynamics. Multiple satellites may be in the same orbit but separated inspace with a roughly constant separation. Satellites in the same orbit may haveISLs that have a higher duty cycle than ISLs between different orbits, but they arestill not guaranteed to be always connected.¶
User +-----------------+ Local Stations --- | Satellites |--- Gateway --- Internet +-----------------+
Earth stations can communicate with one or more satellites in theirregion. User stations are Earth stations with a limited capacity thatcommunicate with only a single satellite at a time. Other Earthstations that may have richer connectivity and higher bandwidth arecommonly called "gateways" and provide connectivity between thesatellite network and conventional wired networks. Gateways serve userstations in their geographic proximity and are replicated globally asnecessary to provide coverage and to meet service density goals. Userstations are associated with a single local gateway. Traffic from oneEarth station to another may need to traverse a path across multiplesatellites via ISLs.¶
Like conventional network links, ISLs and ground links can failwithout warning. However, unlike terrestrial links, there arepredictable times when ISLs and ground links can potentially connectand disconnect. These predictions can be computed and cataloged in aschedule that can be distributed to relevant networkelements. Predictions of a link connecting are not guaranteed: A linkmay not connect for many reasons. Link disconnection predictions dueto orbital dynamics are effectively guaranteed, as the underlyingphysics will not improve unexpectedly.¶
Some proposed satellite networks are fairly large, with tens of thousands ofproposed satellites[CNN]. A key concern is the ability to reach this scaleand larger, as useful networks tend to grow.¶
As we know, the key to scalability is the ability to createhierarchical abstractions, so a key question of any routingarchitecture will be about the abstractions that can be created tocontain topological information.¶
Normal routing protocols are architected to operate with a static but somewhatunreliable topology. Satellite networks lack the static organization ofterrestrial networks, so normal architectural practices for scalability may notapply, and alternative approaches may need consideration.¶
In a typical deployment of a link-state routing protocol, currentimplementations can be deployed with a single area that spans a few thousandrouters. A single area would also provide no isolation for topological changes,causing every link change to be propagated throughout the entire network. Thiswould be insufficient for the needs of large satellite networks.¶
Multiple areas or multiple instances of an Interior Gateway Protocol (IGP) can be used to improvescalability, but there are limitations to typical approaches.¶
Currently, the IETF actively supports two link-state IGPs: OSPF[RFC2328][RFC5340] and IS-IS.¶
OSPF requires that the network operate around a backbone area, withsubsidiary areas hanging off of the backbone. While this works wellfor typical terrestrial networks, this does not seem appropriatefor satellite networks, where there is no centralized portion of thetopology.¶
IS-IS has a different hierarchical structure, where Level 1 (L1) areasare connected sets of nodes, and then Level 2 (L2) is a connectedsubset of the topology that intersects all of the L1 areas. Individualnodes can be L1, L2, or both (L1L2). Typical IS-IS designs require that anynode or link that is to be used as transit between L2 areas must appear as partof the L2 topology. In a satellite network, any satellite could end up beingused for L2 transit, and so every satellite and link would be part of L2,negating any scalability benefits from IS-IS's hierarchical structure.¶
We elaborate on considerations specific to IS-IS inSection 4.¶
In this section, we discuss some of the assumptions that are the basisfor this architectural proposal.¶
The data payload is IP packets.¶
Satellites are active participants in the control and data planes for thenetwork, participating in protocols and forwarding packets.¶
There may be a terrestrial network behind each gateway that may interconnect to the broader Internet. The architecture of the terrestrial network is assumed to be a typical IS-IS and BGP deployment[RFC4271] and is not discussed further in this document.¶
The satellite network interconnects user stations and gateways. Interconnectionbetween the satellite network and the satellite networks of other networkoperators is outside the scope of this document.¶
We assume that the primary use of the satellite network is to provideaccess from a wide range of geographic locations. We also assume thatproviding high-bandwidth bulk transit between peer networks is not agoal. It has been noted that satellite networks can provide lowerlatencies than terrestrial fiber networks in[Handley]. This proposaldoes not preclude such applications but does not articulate themechanisms necessary for user stations to perform the appropriatetraffic engineering computations. Low-latency, multicast, and anycastapplications are not discussed further in this document.¶
As with most access networks, we assume that there will bebidirectional traffic between the user station and the gateway butthat the bulk of the traffic will be from the gateway to the userstation. We expect the uplink from the gateway to the satellitenetwork to be the bandwidth bottleneck and that gateways will need tobe replicated to scale the uplink bandwidth, as the satellite capacity reachablefrom a gateway will be limited.¶
We assume that it is not essential to provide optimal routing fortraffic from user station to user station. If this traffic is sentto a gateway first and then back into the satellite network, itmight be acceptable to some operators as long as the traffic volumeremains very low. This type of routing is not discussed further in this document.¶
We assume that traffic for a user station should enter the satellitenetwork through a gateway that is in some close geographic proximityto the user station. This is to reduce the number of ISLs used by thepath to the user station. Similarly, we assume that user stationtraffic should exit the satellite network through the gateway that isin the closest geographic proximity to the userstation. Jurisdictional requirements for landing traffic in certainregions may alter these assumptions, but such situations are outsidethe scope of this document.¶
This architecture does not preclude gateway-to-gateway traffic across thesatellite constellations, but it does not seek to optimize it.¶
The user station is an entity whose operation is conceptually shared between thesatellite constellation operator and the operator of the cluster of end stationsit serves. For example, the user station is trusted to attach MPLS label stacksto end-user packets. It gets the information to do so from some combination ofits direct satellite and its local gateway via protocols outside the scope ofthis document. Equally, it bootstraps communication via an exchange with thecurrent local satellite so that it can find and communicate with its local gateway --again with the details of how that is done being outside the scope of thisdocument.¶
User stations that can concurrently access multiple satellites are not precludedby this proposal but are not discussed in detail.¶
We assume that links in general will be available when scheduled. Aswith any network, there will be failures, and the schedule is not aguarantee, but we also expect that the schedule is mostly accurate. Weassume that at any given instant, there are enough working links andaggregate bandwidth to run the network and support the trafficdemand. If this assumption does not hold, no routing architecturecan magically make the network more capable.¶
Satellites that are in the same orbit may be connected by ISLs. Theseare called "intra-orbit" ISLs. Satellites that are in different orbitsmay also be connected by ISLs. These are called "inter-orbit" ISLs. Generally,we assume that intra-orbit ISLs have higher reliabilityand persistence than inter-orbit ISLs.¶
We assume that the satellite network is connected (in the graph theory sense)almost always, even if some links are down. This implies that there isalmost always some path to the destination. In the extreme case withno such path, we assume that it is acceptable to drop the payload packets. We donot require buffering of traffic when a link is down. Instead, traffic should bererouted.¶
The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network. This architecture must convey topology information to relevant portions of the network. This enables path computation that is used for data forwarding. The architecture must also scale without global changes to the organizational structure.¶
The end goal of a network is to deliver traffic. In a satellite network where the topology is in a continual state of flux and the user stations frequently change their association with the satellites, having a highly flexible and adaptive forwarding plane is essential. Toward this end, we propose using MPLS as the fundamental forwarding plane architecture[RFC3031]. Specifically, we propose using an approach based on Segment Routing (SR)[RFC8402] with an MPLS data plane[RFC8660], where each satellite is assigned a node Segment Identifier (SID). This allows the architecture to support both IPv4 and IPv6 concurrently. A path through the network can then be expressed as a label stack of node SIDs. IP forwarding is not used within the internals of the satellite network, although each satellite may be assigned an IP address for management purposes. Existing techniques may be used to limit the size of the SR label stack so that it only contains the significant waypoints along the path[Giorgetti]. The label stack operates as a loose source route through the network. If there is an unexpected topology change in the network, the IGP will compute a new path to the next waypoint, allowing packet delivery despite ISL failures. While the IGP is converging, there may be micro-loops in the topology. These can be avoided by using Topology Independent Loop-Free Alternate (TI-LFA) paths[SR-TI-LFA]; otherwise, traffic will loop until discarded based on its TTL.¶
We assume that there is a link-layer mechanism for a user station to associate with a satellite. User stations will have an IP address assigned from a prefix managed by its local gateway. The mechanisms for this assignment and its communication to the end station are not discussed herein but might be similar to DHCP[RFC2131]. User station IP addresses change infrequently and do not reflect their association with their first-hop satellite. Gateways and their supporting terrestrial networks advertise prefixes covering all its local user stations throughout the global Internet.¶
User stations may be assigned a node SID, in which case MPLSforwarding can be used for all hops to the userstation. Alternatively, if the user station does not have a node SID,then the last hop from the satellite to the end station can beperformed based on the destination IP address of the packet. This doesnot require a full longest-prefix-match lookup, as the IP address ismerely a unique identifier at this point.¶
Similarly, gateways may be assigned a node SID. A possibleoptimization is that a single SID value could be assigned as a globalconstant to always direct traffic to the topologically closestgateway. If traffic engineering is required for traffic that isflowing to a gateway, a specific path may be encoded in a label stackthat is attached to the packet by the user station or by the first-hopsatellite.¶
Gateways can also perform traffic engineering using different pathsand label stacks for separate traffic flows. Routing a single trafficflow across multiple paths has proven to cause performance issues withtransport protocols, so that approach is not recommended. Traffic engineering isdiscussed further inSection 6.¶
As discussed inSection 2.3, IS-IS is architecturally the best fit forsatellite networks but does require some novel approaches to achieve thescalability goals for a satellite network. In particular, we propose that allnodes in the network be L1L2 so that local routing is done based on L1information and then global routing is done based on L2 information.¶
An interesting property of IS-IS is that it does not requireinterface addresses. This feature is commonly known as "unnumberedinterfaces". This is particularly helpful in satellite topologiesbecause it implies that ISLs may be used flexibly. Sometimes aninterface might be used as an L1 link to another satellite, and a feworbits later, it might be used as an L1L2 link to a completelydifferent satellite without any reconfiguration or renumbering.¶
Scalability for IS-IS can be achieved through a proposalknown as "Area Proxy"[RFC9666]. With thisproposal, all nodes in an L1 area combine their informationinto a single L2 Link State Protocol Data Unit (LSP). This impliesthat the size of the L1 Link State Database (LSDB) scales as thenumber of nodes in the L1 area and the size of the L2 LSDB scales withthe number of L1 areas.¶
With Area Proxy, topological changes within an L1 area will not be visible toother areas, so the overhead of link-state changes will be greatly reduced.¶
The Area Proxy proposal also includes the concept of an Area SID. Thisis useful because it allows traffic engineering to construct a paththat traverses areas with a minimal number of label stack entries.¶
For example, suppose that a network has 1,000 L1 areas, each with1,000 satellites. This would mean that the network supports1,000,000 satellites but only requires 1,000 entries in its L1 LSDBand 1,000 entries in its L2 LSDB, which are easily achievablenumbers today. The resulting MPLS label table would contain 1,000 node SIDsfrom the L1 (and L2) LSDB and 1,000 area SIDs from the L2 LSDB. If eachsatellite advertises an IP address for management purposes, then theIP routing table would have 1,000 entries for the L1 managementaddresses and 1,000 area proxy addresses from L2.¶
In this proposal, IS-IS does not carry IP routes other than thosein the satellite topology. In particular, there are no IProutes for user stations or the remainder of the Internet.¶
A significant problem with any link-state routing protocol is that ofarea partition. While there have been many proposals for automaticpartition repair, none has seen notable production deployment. Itseems best to avoid this issue and ensure areashave an extremely low probability of partitioning.¶
As discussed above, intra-orbit ISLs are assumed to have higherreliability and persistence than inter-orbit ISLs. However, evenintra-orbit ISLs are not sufficiently reliable to avoid partitionissues. Therefore, we propose to group a small number of adjacentorbits as an IS-IS L1 area, called a "stripe". We assume thatfor any given reliability requirement, there is a small number oforbits that can be used to form a stripe that satisfies thereliability requirement.¶
Stripes are connected to other adjacent stripes using the same ISLmechanism, forming the L2 topology of the network. Each stripe shouldhave multiple L2 connections and never become partitioned fromthe remainder of the network.¶
By using a stripe as an L1 area, in conjunction with Area Proxy, theoverhead of the architecture is greatly reduced. Each stripe contributes asingle LSP to the L2 LSDB, completely hiding all the details about thesatellites within the stripe. The resulting architecture scales proportionatelyto the number of stripes required, not the number of satellites.¶
Groups of MEO and GEO satellites with interconnecting ISLs can alsoform an IS-IS L1L2 area. Satellites that lack intra-constellation ISLsare better as independent L2 nodes.¶
The forwarding architecture presented here is straightforward. A path from agateway to a user station on the same stripe only requires a singlenode SID for the satellite that provides the downlink to the userstation.¶
\ Gateway --> X \ \ X \ \ X ---> x User Station \
Similarly, a user station returning a packet to a gateway need onlyprovide a gateway node SID.¶
For off-stripe forwarding, the situation is a bit more complex. A gateway wouldneed to provide the area SID of the final stripe on the path plus the node SIDof the downlink satellite. For return traffic, user stations or first-hopsatellites would want to provide the area SID of the stripe that contains thesatellite that provides access to the gateway as well as the gateway SID.¶
Source S | | V Internet | | V \ Gateway L --> X \ \ \ X --- X \ \ \ \ Area A X --- X \ \ \ U ---> D User Station \
As an example (Figure 3), consider a packet from an Internet source (Source S) to auser station (D). A local gateway (Gateway L) has injected a prefix covering Dinto BGP and has advertised it globally. The packet is forwarded to Lusing IP forwarding. When L receives the packet, it performs alookup in a pre-computed forwarding table. This contains a SID listfor the user station that has already been converted into a labelstack. Suppose the user station is currently associated with adifferent stripe so that the label stack will contain an area label (A)and a label (U) for the satellite associated with the user station,resulting in a label stack (A, U).¶
The local gateway forwards this into the satellite network. The first-hopsatellite now forwards based on the area label (A) at the top of the stack. Allarea labels are propagated as part of the L2 topology. This forwarding continuesuntil the packet reaches a satellite adjacent to the destinationarea. That satellite pops label A, removing that label and forwarding the packetinto the destination area.¶
The packet is now forwarded based on the remaining label U, which waspropagated as part of the L1 topology. The last satellite forwards thepacket based on the destination address (D) and forwards the packet tothe user station.¶
The return case is similar. The label stack, in this case, consists of a labelfor the local gateway's stripe/area (A') and the label for the local gateway (L),resulting in the stack (A', L). The forwarding mechanisms are similar to theprevious case.¶
Very frequently, access networks congest due to over-subscription andthe economics of access. Network operators can use traffic engineeringto ensure that they get higher efficiency out of theirnetworks by utilizing all available paths and capacity near anycongestion points. In this particular case, the gateway will haveinformation about all of the traffic it is generating and can useall of the possible paths through the network in its topologicalneighborhood. Since we're already using SR, this is easily doneby adding more explicit SIDs to the label stack. These can beadditional area SIDs, node SIDs, or adjacency SIDs. Path computationcan be performed by Path Computation Elements (PCEs)[RFC4655].¶
Each gateway or its PCE will need topological information from theareas it will route through. It can do this by participating in theIGP directly, via a tunnel, or through another delivery mechanism suchas BGP-LS[RFC9552]. User stations do not participate in the IGP.¶
Traffic engineering for packets flowing into a gateway can also beprovided by an explicit SR path. This can help ensure that ISLs nearthe gateway do not congest with traffic for the gateway. These pathscan be computed by the gateway or PCE and then distributed to thefirst-hop satellite or user station, which would apply them totraffic. The delivery mechanism is outside the scope of thisdocument.¶
The most significant difference between terrestrial and satellitenetworks from a routing perspective is that some of the topologicalchanges that will happen to the network can be anticipated andcomputed. Both link and node changes will affect the topology, and thenetwork should react smoothly and predictably.¶
The management plane is responsible for providing information aboutscheduled topological changes. The exact details of how theinformation is disseminated are outside the scope of this documentbut could be shown through a YANG model[YANG-SCHEDULE].Scheduling information needs to beaccessible to all of the nodes that will make routing decisions basedon the topological changes in the schedule (i.e., data about an L1topological change will need to be circulated to all nodes in the L1area and information about L2 changes will need to propagate to allL2 nodes) and to the gateways and PCEs that carry the relatedtopological information.¶
There is very little that the network should do in response to atopological addition. A link coming up or a node joining the topologyshould not have any functional change until the change is proven to befully operational based on the usual IS-IS liveness mechanisms. Nodesmay pre-compute their routing table changes but should not installthem before all relevant adjacencies are received. The benefits ofthis pre-computation appear to be very small. Gateways and PCEs mayalso choose to pre-compute paths based on these changes but shouldnot install paths using the new parts of the topology until they areconfirmed to be operational. If some path pre-installation isperformed, gateways and PCEs must be prepared for the situation wherethe topology fails to become operational and may need to takealternate steps instead, such as reverting any related pre-installedpaths.¶
The network may choose not to pre-install orpre-compute routes in reaction to topological additions, at a smallcost of some operational efficiency.¶
Topological deletions are an entirely different matter. If a link ornode is to be removed from the topology, the network should actbefore the anticipated change to route traffic around the expectedtopological loss. Specifically, at some point before the topologychange, the affected links should be set to a high metric to directtraffic to alternate paths. This is a common operational procedure inexisting networks when links are taken out of service, such as whenproactive maintenance needs to be performed. This type of change doesrequire some time to propagate through the network, so the metricchange should be initiated far enough in advance that the networkconverges before the actual topological change. Gateways and PCEsshould also update paths around the topology change and install thesechanges before the topology change occurs. The time necessary forboth IGP and path changes will vary depending on the exact network andconfiguration.¶
Strictly speaking, changing to a high metric should not be necessary. It shouldbe possible for each router to exclude the link and recomputepaths. However, it seems safer to change the metric and use the IGP methodsfor indicating a topology change, as this can help avoid issues with incompleteinformation dissemination and synchronization.¶
This architecture needs to be validated by satellite operators, bothvia simulation and operational deployment. Meaningful simulationhinges on the exact statistics of ISL connectivity; currently, thatinformation is not publicly available.¶
Current available information about ISLs indicates that links aremechanically steered and will need to track the opposite end of thelink continually. The angles and distances that can be practicallysupported are unknown, as are any limitations about the rate ofchange.¶
It is expected that intra-orbit and inter-orbit ISL links will havevery different properties. Intra-orbit links should be much morestable but still far less stable than terrestrial links. Inter-orbitlinks will be less stable. Links between satellites that are roughlyparallel should be possible but will likely have a limitedduration. Two orbits may be roughly orthogonal, resulting in a limitedpotential for connectivity. Finally, in some topologies there may beparallel orbits where the satellites move in opposite directions,giving a relative speed between satellites around 34,000 mph(55,000 kph). Links in this situation may not be possible or may be soshort-lived that they are impractical.¶
The key question to address is whether the parameters of a givennetwork can yield a stripe assignment that produces stable, connectedareas that work within the scaling bounds of the IGP. If links arevery stable, a stripe could be just a few parallel orbits, withonly a few hundred satellites. However, if links are unstable,a stripe might have to encompass dozens of orbits and thousandsof satellites, which might be beyond the scaling limitations of agiven IGP's implementation.¶
The network behind a gateway is expected to be a normal terrestrialnetwork. Conventional routing architectural principles apply. An obviousapproach would be to extend IS-IS to the terrestrial network, applying L1 areasas necessary for scalability.¶
The terrestrial network may have one or more BGP connections to thebroader Internet. Prefixes for user stations should be advertised tothe Internet near the associated gateway. If gateways are notinterconnected by the terrestrial network, then it may be advisable touse one autonomous system per gateway as it might simplify theexternal perception of the network and subsequent policyconsiderations. Otherwise, one autonomous system may be used for theentire terrestrial network.¶
This document discusses one possible routing architecture forsatellite networks. It proposes no new protocols or mechanisms andthus has no new security impact. Security for IS-IS is provided by[RFC5304] and[RFC5310].¶
User stations will interact directly with satellites, potentiallyusing proprietary mechanisms, and under the control of the satelliteoperator, who is responsible for the security of the user station.¶
This document has no IANA actions.¶
The author would like to thankDino Farinacci,Olivier De jonckere,Eliot Lear,Adrian Farrel,Acee Lindem,Erik Kline,Sue Hares,Joel Halpern,Marc Blanchet, andDean Bogdanovic for their comments.¶