RFC 9717

A Routing Architecture for Satellite Networks

📅 published January 2025, from ietf

RFC 9717 ✨ A Routing Architecture for Satellite Networks 🛰️

Okay bestie, this one is a Informational RFC from T. Li at Juniper Networks 💖, published January 2025 as an Independent Submission 🎀. It's ISSN 2070-1721 and it doesn't obsolete or update any other RFCs, so it's a clean slate 🧚. Tia wrote it as the author's personal take, not an IETF product or a community consensus 💅.

Satellites are literally the main character of this whole doc 🛰️✨. The entire topology is always moving, and the links are way flakier than what we get on the ground 😭. Some changes can be predicted because orbits are so predictable 🌈.

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.

Status of This Memo 📋

This is not an Internet Standards Track spec, it's just published for info 🧠. It's an independent contribution to the RFC Series, and the RFC Editor published it at their discretion without saying anything about whether you should implement it 🤷‍♀️. Documents approved 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 at https://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.

Table of Contents 📚

1.  Introduction
  1.1.  Related Work
  1.2.  Terms and Abbreviations
2.  Overview
  2.1.  Topological Considerations
  2.2.  Link Changes
  2.3.  Scalability
  2.4.  Assumptions
    2.4.1.  Traffic Patterns
    2.4.2.  User Station Constraints
    2.4.3.  Stochastic Connectivity
  2.5.  Problem Statement
3.  Forwarding Plane
4.  IGP Suitability and Scalability
5.  Stripes and Areas
6.  Traffic Forwarding and Traffic Engineering
7.  Scheduling
8.  Future Work
9.  Deployment Considerations
10. Security Considerations
11. IANA Considerations
12. References
  12.1.  Normative References
  12.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🚀

Satellite networks are a super interesting challenge for packet networking 💅. The whole topology is constantly moving, and the links are way less reliable than what we're used to on terrestrial networks 😭. Some link changes can be anticipated because of orbital dynamics 🌙.

This doc proposes a scalable routing architecture for satellite networks. It's built on existing routing protocols and mechanisms and then boosted with scheduled link connectivity change info ✨. Again, no protocol changes here 🙅‍♀️.

Large-scale satellite networks are being deployed now, which is an unforeseen use case for conventional routing protocols 🛰️🤯. The high rate of planned topology change and the extreme scale are unprecedented on the ground. Links between satellites can use free-space optics that allows liberal connectivity 🌈. Still, the range of the links and conjunction with the sun limit things, so the links are far less reliable than network designers are used to 🥺. On top of that, links can change their endpoints dynamically, which means the topology structure itself changes 🌀.

Current satellite networks are proprietary, so there isn't much info out there to analyze and discuss. This doc is based on what's currently accessible 🔍.

This doc gives one approach to a routing architecture for these networks using current standards-based routing tech. It also tackles scalability while handling the fast rate of topology change 🦋. It's meant to give some starter guidance for satellite network operators, but without specific details it can only be the basis for a more complete analysis and design 📝.

This document presents the author's view and is neither the product of the IETF nor a consensus view of the community 💜.

A survey of related work can be found in [Westphal]. Link-state routing for satellite networks has been considered in [Cao] and [Zhang] 🧚.

1.2. Terms and Abbreviations 📖

  • Constellation: A set of satellites.
  • Downlink: The half of a ground link leading from a satellite to an Earth station.
  • Earth station: A node in the network that is on or close to the planetary surface and has a link to a satellite. This includes ships, aircraft, and other vehicles below LEO [ITU].
  • Gateway: An Earth station that participates in the network and acts as the interconnect between satellite constellations and the planetary network. Gateways have a much higher bandwidth than user stations, have ample computing capabilities, and perform traffic engineering duties, subsuming the functionality of a network controller or Path Computation Element (PCE) [RFC4655]. Multiple gateways are assumed to exist, and each serves a portion of the network.
  • GEO: Geostationary Earth Orbit. A satellite in GEO has an orbit that is synchronized to planetary rotation, so it effectively sits over one spot on the planet.
  • Ground link: A link between a satellite and an Earth station, composed of a downlink and an uplink.
  • IGP: Interior Gateway Protocol. A routing protocol that is used within a single administrative domain. Note that 'gateway' in this context is semantically equivalent to 'router' and has no relationship to the 'gateway' used in the rest of this document.
  • IS-IS: Intermediate System to Intermediate System. An IGP that is commonly used by service providers [ISO10589] [RFC1195].
  • ISL: Inter-Satellite Link. Frequently implemented with free-space optics that allow signaling using photons without any intervening medium [Bell].
  • L1: IS-IS Level 1
  • L1L2: IS-IS Level 1 and Level 2
  • L2: IS-IS Level 2
  • LEO: Low Earth Orbit. A satellite in LEO has an altitude of 2,000 km or less.
  • Local gateway: Each user station is associated with a single gateway in its region.
  • LSP: Link State Protocol Data Unit. An IS-IS LSP is a set of packets that describe a node's connectivity to other nodes.
  • MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO and has an altitude between 2,000 km and 35,786 km.
  • SID: Segment Identifier [RFC8402]
  • Stripe: A set of satellites in a few adjacent orbits. These form an IS-IS L1 area.
  • SR: Segment Routing [RFC8402]
  • Uplink: The half of a link leading from an Earth station to a satellite.
  • User station: An Earth station interconnected with a small end-user network.

2. Overview 🌟

2.1. Topological Considerations 🪐

Satellites travel in specific orbits around their parent planets. Some of them have orbital periods synchronized to planetary rotation, so they're effectively stationary over a single point 📍. Others have orbits that carry them across regions of the planet either gradually or super fast. These are typically called Geostationary Earth Orbit (GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on altitude 🌍. This discussion isn't Earth-specific; as we get to other planets, we can test how general this approach is 🪐👽.

Satellites may have data interconnections with one another through Inter-Satellite Links (ISLs). Because of orbital differences, ISLs may connect temporarily during periods of potential connectivity that are computed through orbital dynamics ⏳. Multiple satellites may be in the same orbit but separated in space by a roughly constant distance. Satellites in the same orbit may have ISLs with a higher duty cycle than ISLs between different orbits, but they still aren't guaranteed to always be connected 🫠.

  User           +-----------------+    Local
  Stations   --- |   Satellites    |--- Gateway --- Internet
                 +-----------------+

Figure 1: Overall Network Architecture

Earth stations can talk to one or more satellites in their region 🛰️. User stations are Earth stations with limited capacity that only communicate with a single satellite at a time 📱. Other Earth stations, which have richer connectivity and higher bandwidth, are commonly called "gateways" and provide connectivity between the satellite network and conventional wired networks 🌐. Gateways serve user stations in their geographic proximity and are replicated globally as needed to provide coverage and meet service density goals 🗺️. User stations are associated with a single local gateway 💕. Traffic from one Earth station to another may need to cross a path over multiple satellites via ISLs 🌈.

Like conventional network links, ISLs and ground links can fail without warning 😬. But unlike terrestrial links, there are predictable times when ISLs and ground links can potentially connect and disconnect 🗓️. These predictions can be computed and cataloged in a schedule that can be distributed to relevant network elements 📅. Predictions of a link connecting are not guaranteed: a link may not connect for many reasons 🙃. Link disconnection predictions due to orbital dynamics, however, are effectively guaranteed, because the underlying physics won't improve unexpectedly 🧪✨.

Part 1 of 5 done bestie! 🎀 More parts coming, so stay tuned 💖

2.3. Scalability ✨

okay so bestie, scalability is the big boss of this whole doc 👑 Some proposed satellite networks are fairly large, with tens of thousands of proposed satellites [CNN]. The real worry is being able to reach that scale and even bigger, because useful networks tend to grow 📈🫶

As we know, the key to scalability is being able to make hierarchical abstractions 🧚 So the big question for any routing architecture is which abstractions can be created to contain the topological information 🌸

Normal routing protocols are built to run on a static but somewhat unreliable topology 🙈 Satellite networks don't have the static organization that terrestrial networks have, so the usual architectural scalability habits may not apply, and alternative approaches may need to be considered 💅

In a typical link-state routing protocol deployment, current implementations can run a single area that spans a few thousand routers 🍓 But a single area gives no isolation for topological changes, so every link change gets propagated through the entire network 😭 That would be insufficient for the needs of large satellite networks 💀

Multiple areas or multiple instances of an Interior Gateway Protocol (IGP) can be used to improve scalability, but typical approaches have limitations 🦋

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, with subsidiary areas hanging off of the backbone 🌈 That works really well for typical terrestrial networks, but it doesn't seem appropriate for satellite networks, where there's no centralized portion of the topology 🙅‍♀️

IS-IS has a different hierarchical structure, where Level 1 (L1) areas are connected sets of nodes, and then Level 2 (L2) is a connected subset of the topology that intersects all of the L1 areas 🔥 Individual nodes can be L1, L2, or both (L1L2) 💜 Typical IS-IS designs require that any node or link used as transit between L2 areas must appear as part of the L2 topology. In a satellite network, any satellite could end up being used for L2 transit, so every satellite and link would end up in L2, which negates any scalability benefits from IS-IS's hierarchical structure 😤✨

We elaborate on considerations specific to IS-IS in Section 4 🫶

2.4. Assumptions 🌸

In this section, we talk through some of the assumptions that are the basis for this architectural proposal 🧠

The data payload is IP packets 📦

Satellites are active participants in the control and data planes for the network, 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 🎀 Interconnection between the satellite network and the satellite networks of other network operators is outside the scope of this document 🙅‍♀️

2.4.1. Traffic Patterns 🚀

We assume that the primary use of the satellite network is to provide access from a wide range of geographic locations 🌎 We also assume that providing high-bandwidth bulk transit between peer networks is not a goal 🙅‍♀️ It has been noted that satellite networks can provide lower latencies than terrestrial fiber networks in [Handley] ⚡ This proposal doesn't rule out such applications, but it also doesn't articulate the mechanisms needed for user stations to perform the appropriate traffic engineering computations 🤓 Low-latency, multicast, and anycast applications are not discussed further in this document 🫠

As with most access networks, we assume there will be bidirectional traffic between the user station and the gateway, but that the bulk of the traffic will go from the gateway to the user station 📥 We expect the uplink from the gateway to the satellite network to be the bandwidth bottleneck, and that gateways will need to be replicated to scale the uplink bandwidth, since the satellite capacity reachable from a gateway is limited 📶

We assume that it is not essential to provide optimal routing for traffic from user station to user station 🙈 If this traffic is sent to a gateway first and then back into the satellite network, it might be acceptable to some operators as long as the traffic volume stays very low 🍓 This type of routing is not discussed further in this document 💤

We assume that traffic for a user station should enter the satellite network through a gateway that is in some close geographic proximity to the user station 📍 This is to reduce the number of ISLs used by the path to the user station 🛰️ Similarly, we assume that user station traffic should exit the satellite network through the gateway that is in the closest geographic proximity to the user station 🗺️ Jurisdictional requirements for landing traffic in certain regions may alter these assumptions, but those situations are outside the scope of this document 🏳️

This architecture doesn't rule out gateway-to-gateway traffic across the satellite constellations, but it doesn't try to optimize it 🤷‍♀️

2.4.2. User Station Constraints 🎀

The user station is an entity whose operation is conceptually shared between the satellite constellation operator and the operator of the cluster of end stations it serves 🤝 For example, the user station is trusted to attach MPLS label stacks to end-user packets 🏷️ It gets the information to do so from some combination of its direct satellite and its local gateway, via protocols outside the scope of this document 📬 Equally, it bootstraps communication via an exchange with the current local satellite so that it can find and communicate with its local gateway 🔍 Again, the details of how that's done are outside the scope of this document 🙃

User stations that can concurrently access multiple satellites are not precluded by this proposal, but they aren't discussed in detail 🛰️🛰️

2.4.3. Stochastic Connectivity 🎲

We assume that links in general will be available when scheduled ⏰ As with any network, there will be failures, and the schedule is not a guarantee, but we also expect the schedule to be mostly accurate 🗓️ We assume that at any given instant, there are enough working links and aggregate bandwidth to run the network and support the traffic demand 💪 If this assumption doesn't hold, no routing architecture can magically make the network more capable 🪄🙅‍♀️

Satellites that are in the same orbit may be connected by ISLs 🔗 These are called "intra-orbit" ISLs 🌀 Satellites that are in different orbits may also be connected by ISLs 🌠 These are called "inter-orbit" ISLs 💫 Generally, we assume that intra-orbit ISLs have higher reliability and 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 is almost always some path to the destination 🗺️ In the extreme case with no such path, we assume it's acceptable to drop the payload packets 🗑️ We do not require buffering of traffic when a link is down 🚫 Instead, traffic should be rerouted 🔀

2.5. Problem Statement 🧩

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 the path computation that's used for data forwarding 🧭 The architecture must also scale without global changes to the organizational structure 📈💖

3. Forwarding Plane 🦋

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 user stations frequently change their association with 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 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 it's 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 they 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 of their local user stations throughout the global Internet 🌐📣

User stations may be assigned a node SID, in which case MPLS forwarding can be used for all hops to the user station 🏃‍♀️ Alternatively, if the user station does not have a node SID, then the last hop from the satellite to the end station can be performed based on the destination IP address of the packet 🎯 This does not require a full longest-prefix-match lookup, as the IP address is merely a unique identifier at this point 🆔✨

Similarly, gateways may be assigned a node SID 🚪 A possible optimization is that a single SID value could be assigned as a global constant to always direct traffic to the topologically closest gateway 🧲 If traffic engineering is required for traffic flowing to a gateway, a specific path may be encoded in a label stack that is attached to the packet by the user station or by the first-hop satellite 🗺️

Gateways can also perform traffic engineering using different paths and label stacks for separate traffic flows 🛤️ Routing a single traffic flow across multiple paths has proven to cause performance issues with transport protocols, so that approach is NOT RECOMMENDED 🙅‍♀️💔 Traffic engineering is discussed further in Section 6 🎀✨

4. IGP Suitability and Scalability ✨

okay so like we said in Section 2.3, IS-IS is literally the best fit for satellite networks 🛰️ but it does need some novel approaches to hit the scalability goals. so we're proposing that every node in the network be L1L2 🎀. local routing is done based on L1 info, and then global routing is done based on L2 info. it's giving layered, bestie 💅

ngl one of the most iconic things about IS-IS is that it doesn't need interface addresses 🦋. this is called "unnumbered interfaces" and it's lowkey so helpful for satellite topologies. it means ISLs can be used super flexibly. like, an interface might be used as an L1 link to one satellite, and then a few orbits later it's an L1L2 link to a completely different satellite, with zero reconfiguration or renumbering. main character energy ✨

Scalability for IS-IS can be achieved through a proposal known as "Area Proxy" [RFC9666] 🧚. with Area Proxy, all nodes in an L1 area combine their info into a single L2 Link State Protocol Data Unit (LSP). so the size of the L1 Link State Database (LSDB) scales as the number of nodes in the L1 area, and the size of the L2 LSDB scales with the number of L1 areas 🍓.

with Area Proxy, topological changes within an L1 area won't be visible to other areas, so the overhead of link-state changes gets greatly reduced 🌸.

The Area Proxy proposal also includes the concept of an Area SID 💜. this is useful because it lets traffic engineering build a path that crosses areas with a minimal number of label stack entries 🔥.

for example, say a network has 1,000 L1 areas, each with 1,000 satellites. that means the network supports 1,000,000 satellites, but it only needs 1,000 entries in its L1 LSDB and 1,000 entries in its L2 LSDB. those are easily achievable numbers today 🙈. the resulting MPLS label table would contain 1,000 node SIDs from the L1 (and L2) LSDB and 1,000 area SIDs from the L2 LSDB. and if each satellite advertises an IP address for management purposes, the IP routing table would have 1,000 entries for the L1 management addresses and 1,000 area proxy addresses from L2 🌈.

in this proposal, IS-IS doesn't carry IP routes other than the ones in the satellite topology. in particular, there are no IP routes for user stations or the remainder of the Internet 🙅‍♀️.

5. Stripes and Areas

okay, a big problem with any link-state routing protocol is area partition 💀. there have been lots of proposals for automatic partition repair, but none has seen notable production deployment. so it seems best to avoid this issue entirely and make sure areas have an extremely low probability of partitioning 🫶.

like we covered above, intra-orbit ISLs are assumed to have higher reliability and persistence than inter-orbit ISLs. but even intra-orbit ISLs aren't reliable enough to avoid partition issues 😭. so we propose grouping a small number of adjacent orbits as an IS-IS L1 area, called a "stripe" 🎀. we assume that for any given reliability requirement, there's a small number of orbits that can form a stripe that meets that requirement ✨.

Stripes connect to other adjacent stripes using the same ISL mechanism, and that forms the L2 topology of the network 🦋. each stripe should have multiple L2 connections and never become partitioned from the rest of the network 💖.

by using a stripe as an L1 area, together with Area Proxy, the overhead of the architecture gets greatly reduced 👑. each stripe contributes a single LSP to the L2 LSDB, completely hiding all the details about the satellites inside it 🧚. the result is an architecture that scales with the number of stripes required, not the number of satellites 🔥.

groups of MEO and GEO satellites with interconnecting ISLs can also form an IS-IS L1L2 area 🌸. satellites that lack intra-constellation ISLs are better off as independent L2 nodes 🍓.

6. Traffic Forwarding and Traffic Engineering

the forwarding architecture here is pretty straightforward 💅. a path from a gateway to a user station on the same stripe only needs a single node SID, for the satellite that provides the downlink to that user station ✨.

                \
    Gateway -->  X
                  \
                   \
                    X
                     \
                      \
                       X ---> x  User Station
                        \

                       Figure 2: On-Stripe Forwarding

similarly, a user station returning a packet to a gateway only needs to provide a gateway node SID 🎀.

off-stripe forwarding is a bit more complex 🙈. a gateway would need to provide the area SID of the final stripe on the path, plus the node SID of the downlink satellite. for return traffic, user stations or first-hop satellites would want to provide the area SID of the stripe that holds the satellite providing 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
                                         \

                      Figure 3: Off-Stripe Forwarding

as an example (Figure 3), picture a packet from an Internet source (Source S) heading to a user station (D) 🌈. a local gateway (Gateway L) has injected a prefix covering D into BGP and advertised it globally. the packet gets forwarded to L using IP forwarding. when L receives it, it does a lookup in a pre-computed forwarding table 💜. that table contains a SID list for the user station, already converted into a label stack. suppose the user station is currently associated with a different stripe, so the label stack holds an area label (A) and a label (U) for the satellite associated with the user station. that gives us a label stack of (A, U) 🧚.

the local gateway forwards this into the satellite network 🛰️. the first-hop satellite forwards based on the area label (A) at the top of the stack. all area labels are propagated as part of the L2 topology. this keeps going until the packet reaches a satellite adjacent to the destination area. that satellite pops label A, removing it, and forwards the packet into the destination area 👑.

now the packet is forwarded based on the remaining label U, which was propagated as part of the L1 topology. the last satellite forwards the packet based on the destination address (D) and delivers it to the user station 💖.

the return case is similar 🦋. here the label stack consists of a label for the local gateway's stripe/area (A') and the label for the local gateway (L), so the stack is (A', L). the forwarding mechanisms are similar to the previous case ✨.

access networks very frequently congest due to over-subscription and the economics of access 😭. network operators can use traffic engineering to get higher efficiency out of their networks by using all available paths and capacity near any congestion points 🔥. in this case, the gateway has information about all of the traffic it's generating, and it can use all of the possible paths through the network in its topological neighborhood. since we're already using SR, this is easily done by adding more explicit SIDs to the label stack 🌸. those can be additional area SIDs, node SIDs, or adjacency SIDs. path computation can be performed by Path Computation Elements (PCEs) [RFC4655] 🧚.

each gateway or its PCE will need topological information from the areas it routes through. it can get that by participating in the IGP directly, via a tunnel, or through another delivery mechanism such as BGP-LS [RFC9552] 🎀. user stations do not participate in the IGP 🙅‍♀️.

traffic engineering for packets flowing into a gateway can also be provided by an explicit SR path 🌈. this helps make sure ISLs near the gateway don't get congested with traffic for the gateway 💜. these paths can be computed by the gateway or PCE, then distributed to the first-hop satellite or user station, which applies them to traffic 👑. the delivery mechanism is outside the scope of this document 🍓.

7. Scheduling 📅✨

okay so this is the part where satellite networks are literally different from regular ones 😭🫶 because the topology changes can be predicted ahead of time, like the satellites are doing a choreographed dance and everyone knows the steps 💃🌸 that's so iconic. Both link and node changes shake up the topology, and the network should react smoothly and predictably. no chaos allowed 💅

The management plane is the one in charge of telling everyone about scheduled topology changes 📣 how exactly that info gets shared is out of scope for this doc, but it could be modeled with a YANG model [YANG-SCHEDULE] 🧚 The schedule info needs to reach every node that makes routing decisions based on those changes (so if it's an L1 change, the whole L1 area needs it, and L2 changes need to reach all the L2 nodes) 🦋 and also the gateways and PCEs that carry the related topology info. everyone needs to be in the group chat, bestie 💬

7.1. Topological Additions 🌱

there's very little the network should do when something new shows up. a link coming up or a node joining should not change anything functionally until it's proven fully operational using the usual IS-IS liveness mechanisms 🔥 no rushing it!!

Nodes may pre-compute their routing table changes, but they SHOULD NOT install them before all the relevant adjacencies are received 🙈 ngl the benefit of pre-computing seems to be pretty small 🤷‍♀️

Gateways and PCEs may also pre-compute paths based on these changes, but they SHOULD NOT install paths that use the new parts of the topology until those parts are confirmed operational 💖 and if they do pre-install anything, they MUST be ready for the topology to fail to become operational 😭 in that case they may need to take other steps instead, like reverting any related pre-installed paths 🔄 be prepared, periodt 💅

The network MAY choose not to pre-install or pre-compute routes for topological additions 🧚 it costs a little operational efficiency, but hey, that's the tradeoff 💜

7.2. Topological Deletions 🗑️

okay now deletions are a whole different vibe 😤 if a link or node is going to be removed, the network SHOULD act before the change, routing traffic around the expected loss 🛣️ specifically, at some point before the topology change, the affected links should be set to a high metric so traffic goes to alternate paths 🌈 this is a super common operational move in existing networks when links get taken out of service, like for proactive maintenance 🛠️✨

this stuff takes time to propagate through the network, so the metric change needs to start far enough ahead that the network converges before the actual change happens ⏰ gateways and PCEs should also update paths around the change and install those updates before the topology change occurs 🎀 how long all this takes for IGP and path changes depends on the specific network and config, so it'll vary 🌸

Strictly speaking, changing to a high metric isn't strictly necessary! 🙈 each router could just exclude the link and recompute paths on its own. however, it seems safer to change the metric and use the IGP methods for signaling the topology change, since that helps avoid problems with incomplete information dissemination and synchronization 🫶 safety first, bestie!

8. Future Work 🔮

this architecture needs to be validated by satellite operators, both through simulation and real operational deployment 🛰️ simulation really depends on the exact stats of ISL connectivity, but right now that info isn't publicly available 😭 rip

current available info about ISLs says the links are mechanically steered and need to keep tracking the opposite end of the link continuously 🦋 the angles and distances that can be practically supported are unknown, and so are any limits on the rate of change 🤷‍♀️

it's expected that intra-orbit and inter-orbit ISLs will have very different properties 💅 intra-orbit links should be much more stable, but still way less stable than terrestrial links 🌙 inter-orbit links will be less stable. links between satellites that are roughly parallel should be possible but will likely only last for a limited time ⏳ two orbits might be roughly orthogonal, which gives limited potential for connectivity 🌀 and finally, in some topologies there may be parallel orbits where satellites move in opposite directions, giving a relative speed between satellites of around 34,000 mph (55,000 kph) 🚀💨 links in that situation may not be possible, or may be so short-lived that they're impractical 💀

the key question is whether the parameters of a given network can yield a stripe assignment that makes stable, connected areas that work within the scaling bounds of the IGP 🧩 if links are very stable, a stripe could be just a few parallel orbits with only a few hundred satellites 🌸 but if links are unstable, a stripe might have to span dozens of orbits and thousands of satellites, which could be beyond the scaling limits of a given IGP's implementation 😩🫠

9. Deployment Considerations 🏡

the network behind a gateway is expected to be a normal terrestrial network 🌍 conventional routing architecture principles apply here, no weirdness needed 💖 an obvious approach would be to extend IS-IS into the terrestrial network, using L1 areas as needed for scalability 🧚

the terrestrial network may have one or more BGP connections to the wider Internet 🌐 prefixes for user stations SHOULD be advertised to the Internet near the associated gateway 📡 if gateways aren't interconnected by the terrestrial network, it may be advisable to use one autonomous system per gateway, since that might simplify how the network looks from outside and make policy stuff easier 🎀 otherwise, one autonomous system may be used for the entire terrestrial network 👑

10. Security Considerations 🔐

okay this part is SERIOUS bestie 😤🚨 this document discusses one possible routing architecture for satellite networks. it proposes no new protocols or mechanisms, so it has no new security impact 🙏 security for IS-IS is provided by [RFC5304] and [RFC5310] 🔒

user stations will interact directly with satellites, potentially using proprietary mechanisms, and they're under the control of the satellite operator, who is responsible for the security of the user station 🛰️💀 so the operator has to keep those stations locked down, no excuses 😭🫶

11. IANA Considerations 📋

this document has no IANA actions 💅✨

12. References 📚

12.1. Normative References 💜

[ISO10589] ISO/IEC, "Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, November 2002, <https://www.iso.org/standard/30932.html>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC9666] Li, T., Chen, S., Ilangovan, V., and G. Mishra, "Area Proxy for IS-IS", RFC 9666, DOI 10.17487/RFC9666, October 2024, <https://www.rfc-editor.org/info/rfc9666>.

12.2. Informative References 🦋

okay bestie, these are the reading-list refs 📚✨ the bits that give the spec its backstory, so you can go deeper if you're curious

Acknowledgements 🫶

big thank you to Dino Farinacci, Olivier De jonckere, Eliot Lear, Adrian Farrel, Acee Lindem, Erik Kline, Sue Hares, Joel Halpern, Marc Blanchet, and Dean Bogdanovic for their comments 💜🌸

Author's Address 💅

Tony Li Juniper Networks Email: tony.li@tony.li

📦 where this page comes from