<?xmlversion="1.0" encoding="utf-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 2.6.10) -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"><!ENTITY I-D.ietf-lsr-isis-area-proxy SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-isis-area-proxy.xml"> <!ENTITY RFC3031 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"> <!ENTITY RFC5304 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"> <!ENTITY RFC5310 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"> <!ENTITY RFC8402 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC8660 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"> <!ENTITY I-D.ietf-rtgwg-segment-routing-ti-lfa SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"> <!ENTITY I-D.ietf-tvr-schedule-yang SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tvr-schedule-yang.xml"> <!ENTITY RFC1195 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"> <!ENTITY RFC2131 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"> <!ENTITY RFC2328 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"> <!ENTITY RFC4271 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"> <!ENTITY RFC4655 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"> <!ENTITY RFC5340 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"> <!ENTITY RFC9552 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml">]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-li-arch-sat-09" number="9717" updates="" obsoletes="" category="info"submissionType="IETF">submissionType="independent" version="3" tocInclude="true" xml:lang="en" symRefs="true" sortRefs="true"> <front> <title abbrev="Routing for Satellites">A Routing Architecture for Satellite Networks</title> <seriesInfo name="RFC" value="9717"/> <author initials="T." surname="Li" fullname="Tony Li"> <organization>Juniper Networks</organization> <address> <email>tony.li@tony.li</email> </address> </author> <dateyear="2024" month="August" day="30"/> <workgroup>Network Working Group</workgroup>year="2025" month="January"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <abstract> <t>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.</t> <t>This document proposes a scalable routing architecture for satellite networks based on existing routing protocols andmechanisms,mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.</t> <t>This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.</t> </abstract> </front> <middle> <sectionanchor="introduction"><name>Introduction</name>anchor="introduction"> <name>Introduction</name> <t>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.</t> <t>This document proposes a scalable routing architecture for satellite networks based on existing routing protocols andmechanisms,mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.</t> <t>Large-scale satellite networks are being deployed, presenting an unforeseen application for conventional routing protocols. The high rate of intentional topological change and the extreme scale are unprecedented in terrestrial networking. Links between satellites can utilize free-space optics technology that allows liberal connectivity. Still, there are limitations due to the range of the links and conjunction with the sun, resulting in links that are far less reliable than network designers are used to. In addition, links can change their endpoints dynamically, resulting in structural changes to the topology.</t> <t>Current satellite networks areproprietaryproprietary, and little information is generally available for analysis and discussion. This document is based on what is currently accessible.</t> <t>This document proposes one approach to provide a routing architecture for such networks utilizing current standards-based routing technology andprovidingto provide a solution for the scalability of the network while incorporating the rapid rate of topological change. This document intends to provide some initial guidance for satellite network operators, but without specific details, this document can only provide the basis for a more complete analysis and design.</t> <t>This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.</t> <sectionanchor="related-work"><name>Relatedanchor="related-work"> <name>Related Work</name> <t>A survey of related work can be found in <xref target="Westphal"/>.Link stateLink-state routing for satellite networks has been considered in <xref target="Cao"/> and <xref target="Zhang"/>.</t> </section> <sectionanchor="terms-and-abbreviations"><name>Termsanchor="terms-and-abbreviations"> <name>Terms and Abbreviations</name><t><list style="symbols"> <t>Constellation: A<dl spacing="normal"> <dt>Constellation:</dt><dd>A set ofsatellites.</t> <t>Downlink: Thesatellites.</dd> <dt>Downlink:</dt><dd>The half of a ground link leading from a satellite to an Earthstation.</t> <t>Earth station: Astation.</dd> <dt>Earth station:</dt><dd>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 belowLEO.LEO <xreftarget="ITU"/></t> <t>Gateway: Antarget="ITU"/>.</dd> <dt>Gateway:</dt><dd>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).(PCE) <xreftarget="RFC4655"/>target="RFC4655"/>. Multiple gateways are assumed to exist, and eachservingserves a portion of thenetwork.</t> <t>GEO: Geostationarynetwork.</dd> <dt>GEO:</dt><dd>Geostationary Earth Orbit. A satellite in GEO has an orbit that is synchronized to planetary rotation, so it effectively sits over one spot on theplanet.</t> <t>Ground link: Aplanet.</dd> <dt>Ground link:</dt><dd>A link between a satellite and an Earth station, composed of aDownlinkdownlink and anUplink.</t> <t>IGP: Interioruplink.</dd> <dt>IGP:</dt><dd>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 thisdocument.</t> <t>IS-IS: Intermediatedocument.</dd> <dt>IS-IS:</dt><dd>Intermediate System to IntermediateSystem routing protocol.System. An IGP that is commonly used by serviceproviders.providers <xref target="ISO10589"/> <xreftarget="RFC1195"/></t> <t>ISL: Inter-satellite link.target="RFC1195"/>.</dd> <dt>ISL:</dt><dd>Inter-Satellite Link. Frequently implemented with free-space optics that allow signaling using photons without any interveningmedium.medium <xreftarget="Bell"/></t> <t>L1: IS-IStarget="Bell"/>.</dd> <dt>L1:</dt><dd>IS-IS Level1</t> <t>L1L2: IS-IS1</dd> <dt>L1L2:</dt><dd>IS-IS Level 1 and Level2</t> <t>L2: IS-IS2</dd> <dt>L2:</dt><dd>IS-IS Level2</t> <t>LEO: Low2</dd> <dt>LEO:</dt><dd>Low Earth Orbit. A satellite in LEO has an altitude of2,000km2,000 km orless.</t> <t>Local gateway: Eachless.</dd> <dt>Local gateway:</dt><dd>Each user station is associated with a single gateway in itsregion.</t> <t>LSP:region.</dd> <!--[rfced] Since "LSP" stands for "Link State Protocol Data Unit" per this document, we removed "IS-IS" from its expansion in the terms list (Section 1.2) and included it in the next sentence as shown below. Please let us know if this is incorrect. Original: LSP: IS-IS Link State Protocol Data Unit. An LSP is a set of packets that describe a node's connectivity to othernodes.</t> <t>MEO:nodes. Current: LSP: Link State Protocol Data Unit. An IS-IS LSP is a set of packets that describe a node's connectivity to other nodes. --> <dt>LSP:</dt><dd>Link State Protocol Data Unit. An IS-IS LSP is a set of packets that describe a node's connectivity to other nodes.</dd> <!--[rfced] To avoid the redundancy of "Orbit orbits" in this sentence (i.e., when "LEO" and "GEO" are expanded, it becomes "between Low Earth Orbit and Geostationary Earth Orbit orbits"), may we remove "orbits" as shown below? Original: MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO orbits and has an altitude between 2,000km and35,786km.</t> <t>SID: Segment35,786km. Perhaps: 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. --> <dt>MEO:</dt><dd>Medium Earth Orbit. A satellite in MEO is between LEO and GEO orbits and has an altitude between 2,000 km and 35,786 km.</dd> <dt>SID:</dt><dd>Segment Identifier <xreftarget="RFC8402"/></t> <t>Stripe: Atarget="RFC8402"/></dd> <dt>Stripe:</dt><dd>A set of satellites in a few adjacent orbits. These form an IS-IS L1area.</t> <t>SR: Segmentarea.</dd> <dt>SR:</dt><dd>Segment Routing <xreftarget="RFC8402"/></t> <t>Uplink: Thetarget="RFC8402"/></dd> <dt>Uplink:</dt><dd>The half of a link leading from an Earth station to asatellite.</t> <t>User station: Ansatellite.</dd> <dt>User station:</dt><dd>An Earth station interconnected with a small end-usernetwork.</t> </list></t>network.</dd> </dl> </section> </section> <sectionanchor="overview"><name>Overview</name>anchor="overview"> <name>Overview</name> <sectionanchor="topological-considerations"><name>Topologicalanchor="topological-considerations"> <name>Topological Considerations</name> <!--[rfced] In the first sentence of Section 2.1, should "parent planet" perhaps be "parent planets", or is this referring to one planet? Original: Satellites travel in specific orbits around their parent planet. Some of them have their orbital periods synchronized to planetary rotation, so they are effectively stationary over a single point. Perhaps: Satellites travel in specific orbits around their parent planets. Some of them have their orbital periods synchronized to planetary rotation, so they are effectively stationary over a single point. --> <t>Satellites travel in specific orbits around their parent planet. Some of them have their orbital periods synchronized to planetary rotation, so they are effectively stationary over a single point. Other satellites have orbits that cause them to travel across regions of the planet either gradually or quite rapidly. Respectively, these are typically known as the Geostationary EarthOrbitsOrbit (GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on the altitude. This discussion is not Earth-specific; as we get to other planets, we can test this approach's generality.</t> <t>Satellites may have data interconnections with one another through Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may be connectedtemporarily,temporarily with periods of potential connectivity computed through orbital dynamics. Multiple satellites may be in the same orbit but separated inspace,space with a roughly constant separation. Satellites in the same orbit may have ISLs that have a higher duty cycle than ISLs between differentorbitsorbits, but they are still not guaranteed to be always connected.</t><figure><artwork><![CDATA[<figure anchor="network-architecture"> <name>Overall Network Architecture</name> <artwork><![CDATA[ User +-----------------+ Local Stations --- | Satellites |--- Gateway --- Internet +-----------------+Figure 1: Overall network architecture]]></artwork></figure> <t>Earth stations can communicate with one or more satellites in their region. User stations are Earth stations with a limited capacityandthat communicate with only a single satellite at a time. Other Earth stations that may have richer connectivity and higher bandwidth are commonly calledgateways"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 necessary to provide coverage and to meet service density goals. User stations are associated with a single local gateway. Traffic from one Earth station to another may need to traverse a path across multiple satellites via ISLs.</t> </section> <sectionanchor="link-changes"><name>Linkanchor="link-changes"> <name>Link Changes</name> <t>Like conventional network links, ISLs and ground links can fail without warning. However, 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:aA link may not connect for many reasons. Link disconnection predictions due to orbital dynamics are effectively guaranteed, as the underlying physics will not improve unexpectedly.</t> </section> <sectionanchor="scalability"><name>Scalability</name>anchor="scalability"> <name>Scalability</name> <t>Some proposed satellite networks are fairly large, with tens of thousands of proposedsatellites.satellites <xreftarget="CNN"/>target="CNN"/>. A key concern is the ability to reach this scale and larger, as useful networks tend to grow.</t> <t>As we know, the key to scalability is the ability to create hierarchical abstractions, so a key question of any routing architecture will be about the abstractions that can be created to contain topological information.</t> <t>Normal routing protocols are architected to operate with a static but somewhat unreliable topology. Satellite networks lack the static organization of terrestrial networks, so normal architectural practices for scalability may notapplyapply, and alternative approaches may need consideration.</t> <t>In a traditional deployment of a link-state routing protocol, current implementations can be deployed with a single area that spans a few thousand routers. A single area would also provide no isolation for topological changes, causing every link change to be propagated throughout the entire network. This would be insufficient for the needs of large satellite networks.</t> <t>Multiple areas or multiple instances of anIGPInterior Gateway Protocol (IGP) can be used to improve scalability, but there are limitations to traditional approaches.</t><t>The<t>Currently, the IETFcurrentlyactively supports two link-stateInterior Gateway Protocols (IGPs):IGPs: OSPF <xreftarget="RFC2328"/><xreftarget="RFC2328"/> <xref target="RFC5340"/> and IS-IS.</t> <t>OSPF requires that the network operate around a backbone area, with subsidiary areas hanging off of the backbone. While this works well for traditional terrestrial networks, this does not seem appropriate for satellite networks, where there is no centralized portion of the topology.</t> <t>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). Traditional IS-IS designs require that any node or link that is to be 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, and so every satellite and link would be part of L2, negating any scalability benefits from IS-IS's hierarchical structure.</t> <t>We elaborate onIS-IS-specificconsiderations specific to IS-IS in <xref target="suitability"/>.</t> </section> <sectionanchor="assumptions"><name>Assumptions</name>anchor="assumptions"> <name>Assumptions</name> <t>In this section, we discuss some of the assumptions that are the basis for this architectural proposal.</t> <t>The data payload is IP packets.</t> <t>Satellites are active participants in the control and dataplaneplanes for the network, participating inprotocols,protocols and forwarding packets.</t> <t>There may be a terrestrial network behind each gateway that may interconnect to the broader Internet. <!--[rfced] We updated three instances of "not discussed further" to "not discussed further in this document". If that is not correct, please let us know. One example (see the text for more instances) Original: The architecture of the terrestrial network is assumed to be a typical IS-IS and BGP deployment [RFC4271] and is not discussed further. Current: 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 architecture of the terrestrial network is assumed to be a typical IS-IS and BGP deployment <xref target="RFC4271"/>deploymentand is not discussedfurther.</t>further in this document.</t> <t>The satellite network interconnects user stations and gateways. Interconnection between the satellite network and the satellite networks of other network operators is outsideofthe scope of this document.</t> <sectionanchor="traffic-patterns"><name>Trafficanchor="traffic-patterns"> <name>Traffic Patterns</name> <t>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 <xref target="Handley"/>. This proposal does not preclude such applications but does not articulate the mechanisms necessary for user stations to perform the appropriate traffic engineering computations. Low-latency, multicast, and anycast applications are not discussedfurther.</t>further in this document.</t> <t>As with most access networks, we assume that there will be bidirectional traffic between the user station and thegateway,gateway but that the bulk of the traffic will be from the gateway to the user station. We expectthatthe uplink from the gateway to the satellite network to be the bandwidthbottleneck,bottleneck and that gateways will need to be replicated to scale the uplink bandwidth, as the satellite capacity reachable from a gateway will be limited.</t> <t>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,thisit might be acceptable to some operators as long as the traffic volume remains very low. This type of routing is not discussedfurther.</t>further in this document.</t> <t>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 such situations are outsideofthe scope of this document.</t> <t>This architecture does not preclude gateway-to-gateway traffic across the satellite constellations, but it does not seek to optimize it.</t> </section> <sectionanchor="user-station-contraints"><name>Useranchor="user-station-constraints"> <name>User StationContraints</name>Constraints</name> <t>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 localgateway,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 localgateway,gateway -- again with the details of how that is done being outside the scope of this document.</t> <t>User stations that can concurrently access multiple satellites are not precluded by thisproposal,proposal but are not discussed in detail.</t> </section> <sectionanchor="stochastic-connectivity"><name>Stochasticanchor="stochastic-connectivity"> <name>Stochastic Connectivity</name> <t>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 that the schedule is 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 does not hold, no routing architecture can magically make the network more capable.</t> <t>Satellites that are in the same orbit may be connected by ISLs. These are calledintra-orbit"intra-orbit" ISLs. Satellites that are in different orbits may also be connected by ISLs. These are calledinter-orbit"inter-orbit" ISLs.WeGenerally, we assumethat, in general,that intra-orbit ISLs have higher reliability and persistence than inter-orbit ISLs.</t> <t>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 that it is acceptable to drop the payload packets. We do not require buffering of traffic when a link is down. Instead, traffic should be rerouted.</t> </section> </section> <sectionanchor="problem-statement"><name>Problemanchor="problem-statement"> <name>Problem Statement</name><t>The<!--[rfced] We updated the last part of this sentence from "and the structure can scale" to "so that the structure can scale" for clarity. Please let us know if this is incorrect. Original: The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network such that topology information is conveyed through relevant portions of the network, that paths are computed across the network, and that data can be delivered along those paths, and the structure can scale without any changes to the organizational structure. Current: The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network such that topology information is conveyed through relevant portions of the network, paths are computed across the network, and data can be delivered along those paths so that the structure can scale without any changes to the organizational structure. --> <t>The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network such that topology information is conveyed through relevant portions of the network, paths are computed across the network, and data can be delivered along those paths so that the structure can scale without any changes to the organizational structure.</t> </section> </section> <sectionanchor="forwarding-plane"><name>Forwardinganchor="forwarding-plane"> <name>Forwarding Plane</name> <t>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 proposeto useusing MPLS as the fundamental forwarding plane architecture <xref target="RFC3031"/>. Specifically, we proposeto use ausing an approach based on Segment Routing (SR) <xref target="RFC8402"/>based approachwith an MPLS data plane <xref target="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 <xref target="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. <!-- [rfced] FYI - We added the expansion for "TI-FLA". Please let us know of any objections. Original: These can be avoided by using TI-LFA alternate paths<xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>,[I-D.ietf-rtgwg-segment-routing-ti-lfa], or traffic will loop until discarded based on its TTL. Current: 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. --> These can be avoided by using Topology Independent Loop-Free Alternate (TI-LFA) paths <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>; otherwise, traffic will loop until discarded based on its TTL.</t> <t>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 <xref target="RFC2131"/>. User station IP addresses change infrequently and do not reflect their association with their first-hop satellite. <!--[rfced] Please clarify "into the global Internet" in this sentence. Do gateways advertise prefixes to cover all of their local user stations perhaps "across the global Internet" or "including those in global Internet"? Original: Gateways and their supporting terrestrial networks advertise prefixes covering all its local user stations into the global Internet. Perhaps: Gateways and their supporting terrestrial networks advertise prefixes to cover all its local user stations across the global Internet. --> Gateways and their supporting terrestrial networks advertise prefixes covering all its local user stations into the global Internet.</t> <t>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-matchlookuplookup, as the IP address is merely a unique identifier at this point.</t> <t>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 that is 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.</t> <t>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 <xref target="trafficEngineering"/>.</t> </section> <sectionanchor="suitability"><name>IGPanchor="suitability"> <name>IGP Suitability and Scalability</name> <t>As discussed in <xref target="scalability"/>, IS-IS is architecturally the best fit for satellitenetworks,networks but does require some novel approaches to achieve the scalability goals for a satellite network. In particular, we propose that all nodes in the network be L1L2 so that local routing is done based on L1 information and then global routing is done based on L2 information.</t><t>IS-IS has the<t>An interesting property of IS-IS is that it does not require interface addresses. This feature is commonly known as'unnumbered interfaces'."unnumbered interfaces". This is particularly helpful in satellite topologies because it implies that ISLs may be used flexibly. Sometimes an interface might be used as an L1 link to anothersatellitesatellite, and a few orbitslaterlater, it might be used as an L1L2 link to a completely different satellite without any reconfiguration or renumbering.</t> <t>Scalability for IS-IS can be achieved through a proposal known asArea Proxy"Area Proxy" <xreftarget="I-D.ietf-lsr-isis-area-proxy"/>.target="RFC9666"/>. With this proposal, all nodes in an L1 area combine their information into a single L2 Link State Protocol Data Unit (LSP). This implies that 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.</t> <t>With Area Proxy, topological changes within an L1 area will not be visible to other areas, so the overhead oflink statelink-state changes will be greatly reduced.</t> <t>The Area Proxy proposal also includes the concept of an Area SID. This is useful because it allows traffic engineering to construct a path that traverses areas with a minimal number of label stack entries.</t><t>Suppose, for<t>For example, suppose that a network has 1,000 L1 areas, each with 1,000 satellites. This wouldthenmean that the network supports 1,000,000satellites,satellites but only requires 1,000 entries in its L1 LSDB and 1,000 entries in its L2LSDB; numbers thatLSDB, which 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. If each satellite advertises an IP address for management purposes, then the IP routing table would have 1,000 entries for the L1 management addresses and 1,000 area proxy addresses from L2.</t> <t>In this proposal, IS-IS does not carry IP routes other than those in the satellite topology. In particular, there are no IP routes for user stations or the remainder of the Internet.</t> </section> <sectionanchor="stripes-and-areas"><name>Stripesanchor="stripes-and-areas"> <name>Stripes and Areas</name> <t>A significant problem with anylink statelink-state routing protocol is that of area partition. While there have been many proposals for automatic partition repair, none has seen notable production deployment. It seems best to avoid this issue and ensure areas have an extremely low probability of partitioning.</t> <t>As discussed above, intra-orbit ISLs are assumed to have higher reliability and persistence than inter-orbit ISLs. However, even intra-orbit ISLs are not sufficiently reliable to avoid partition issues. Therefore, we propose to group a small number of adjacent orbits as an IS-IS L1 area, called astripe."stripe". We assume that for any given reliability requirement, there is a small number of orbits that can be used to form a stripe that satisfies the reliability requirement.</t> <t>Stripes are connected to other adjacent stripes using the same ISL mechanism, forming the L2 topology of the network. Each stripe should have multiple L2 connections and never become partitioned from the remainder of the network.</t> <t>By using a stripe as an L1 area, in conjunction with Area Proxy, the overhead of the architecture is greatly reduced. Each stripe contributes a single LSP to the L2 LSDB, completely hiding all the details about the satellites within the stripe. The resulting architecture scales proportionately to the number of stripes required, not the number of satellites.</t> <t>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 as independent L2 nodes.</t> </section> <sectionanchor="trafficEngineering"><name>Trafficanchor="trafficEngineering"> <name>Traffic Forwarding and Traffic Engineering</name> <!-- [rfced] Please clarify what "this" in "this architecture" refers to. Is it the "forwarding plane" or "on-stripe" architecture? Original: 6. Traffic Forwarding and Traffic Engineering Forwarding in this architecture is straightforward. Perhaps: 6. Traffic Forwarding and Traffic Engineering Forwarding in the forwarding plane architecture is straightforward. --> <t>Forwarding in this architecture is straightforward. A path from a gateway to a user station on the same stripe only requires a single node SID for the satellite that provides the downlink to the user station.</t><figure><artwork><![CDATA[<figure anchor="on-stripe-forwarding"> <name>On-Stripe Forwarding</name> <artwork><![CDATA[ \ Gateway --> X \ \ X \ \ X ---> x User Station \Figure 2: On-stripe forwarding]]></artwork></figure> <t>Similarly, a user station returning a packet to a gateway need only provide a gateway node SID.</t> <t>For off-stripe forwarding, the situation 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 contains the satellite that provides access to the gateway as well as the gateway SID.</t><figure><artwork><![CDATA[<figure anchor="off-stripe-forwarding"> <name>Off-Stripe Forwarding</name> <artwork><![CDATA[ Source S | | V Internet | | V \ Gateway L --> X \ \ \ X --- X \ \ \ \ Area A X --- X \ \ \ U ---> D User Station \Figure 3: Off-stripe forwarding]]></artwork></figure> <t>As anexample,example (<xref target="off-stripe-forwarding"/>), consider a packet from an Internet sourceS(Source S) to a user stationD.(D). A local gatewayL(Gateway L) has injected a prefix covering D into BGP and has advertised it globally. The packet is forwarded to L using IP forwarding. When L receives the packet, it performs a lookup in a pre-computed forwarding table. This contains a SID list for the user station that has already been converted into a label stack. Suppose the user station is currently associated with a different stripe so that the label stack will contain an area labelA(A) and a labelU(U) for the satellite associated with the user station, resulting in a label stack (A, U).</t> <t>The local gateway forwards this into the satellite network. The first-hop satellite now forwards based on the area labelA(A) at the top of the stack. All area labels are propagated as part of the L2 topology. This forwarding continues until the packet reaches a satellite adjacent to the destination area. That satellite pops label A, removing that label and forwarding the packet into the destination area.</t> <t>The packet is now 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 addressD(D) and forwards the packet to the user station.</t> <t>The return case is similar. The label stack, in this case, consists of a label for the local gateway'sstripe/area, A',stripe/area (A') and the label for the localgateway, L,gateway (L), resulting in the stack (A', L). The forwarding mechanisms are similar to the previous case.</t> <t>Very frequently, access networks congest due tooversubscriptionover-subscription and the economics of access. Network operators can use traffic engineering to ensure that they get higher efficiency out of their networks by utilizing all available paths and capacity near any congestion points. In this particular case, the gateway will have information about all of the traffic it is generating and can use all of the possible paths through the network in its topological neighborhood. Since we're already using SR, this is easily donejustby adding more explicit SIDs to the label stack. These can be additional area SIDs, node SIDs, or adjacency SIDs. Path computation can be performed by Path Computation Elements(PCE)(PCEs) <xref target="RFC4655"/>.</t> <t>Each gateway or its PCE will need topological information from the areas it will route through. It can do this by participating in the IGP directly, via a tunnel, or through another delivery mechanism such as BGP-LS <xref target="RFC9552"/>. User stations do not participate in the IGP.</t> <t>Traffic engineering for packets flowing into a gateway can also be provided by an explicit SR path. This can help ensure that ISLs near the gateway do not congest with traffic for the gateway. These paths can be computed by the gateway or PCE and then distributed to the first-hop satellite or user station, which would apply them to traffic. The delivery mechanism is outsideofthe scope of this document.</t> </section> <sectionanchor="scheduling"><name>Scheduling</name>anchor="scheduling"> <name>Scheduling</name> <t>The most significant difference between terrestrial and satellite networks from a routing perspective is that some of the topological changes that will happen to the network can be anticipated and computed. Both link and node changes will affect thetopologytopology, and the network should react smoothly and predictably.</t> <t>The management plane is responsible for providing information about scheduled topological changes. The exact details of how the information is disseminated are outsideofthe scope of this document but could bedoneshown through a YANG model <xref target="I-D.ietf-tvr-schedule-yang"/>. Scheduling information needs to be accessible to all of the nodes that will make routing decisions based on the topological changes in theschedule, soschedule (i.e., data about an L1 topological change will need to be circulated to all nodes in the L1 area and information about L2 changes will need to propagate to all L2nodes, plusnodes) and to the gateways and PCEs that carry the related topological information.</t> <t>There is very little that the network should do in response to a topological addition. A link coming up or a node joining the topology should not have any functional change until the change is proven to be fully operational based on the usual IS-IS liveness mechanisms. Nodes may pre-compute their routing table changes but should not install them before all relevant adjacencies are received. The benefits of this pre-computation appear to be very small. Gateways and PCEs may also choose to pre-compute paths based on thesechanges,changes but should not install paths using the new parts of the topology until they are confirmed to be operational. If some path pre-installation is performed, gateways and PCEs must be prepared for the situation where the topology fails to become operational and may need to take alternate steps instead, such as reverting any related pre-installed paths.</t> <t>The network may choose not to pre-install or pre-compute routes in reaction to topological additions, at a small cost of some operational efficiency.</t> <t>Topological deletions are an entirely different matter. If a link or node is to be removed from the topology, the network should act before the anticipated change to route traffic around the expected topological loss. Specifically, at some point before the topology change, the affected links should be set to a high metric to direct traffic to alternate paths. This is a common operational procedure in existing networks when links are taken out of service, such as when proactive maintenance needs to be performed. This type of change does require some time to propagate through the network, so the metric change should be initiated far enough in advance that the network converges before the actual topological change. Gateways and PCEs should also update paths around the topology change and install these changes before the topology change occurs. The time necessary for both IGP and path changes will vary depending on the exact network and configuration.</t> <t>Strictly speaking, changing to a high metric should not be necessary. It should be possible for each router to exclude the link and recompute paths. However, it seems safer to change the metric and use the IGP methods for indicating a topology change, as this can help avoid issues with incomplete information dissemination and synchronization.</t> </section> <sectionanchor="future-work"><name>Futureanchor="future-work"> <name>Future Work</name> <t>This architecture needs to be validated by satellite operators, both via simulation and operational deployment. Meaningful simulation hinges on the exact statistics of ISLconnectivity, andconnectivity; currently, that information is not publiclyavailable currently.</t>available.</t> <t>Current available information about ISLs indicates that links are mechanically steered and will need to track the opposite end of the link continually. The angles and distances that can be practically supported are unknown, as are any limitations about the rate of change.</t> <t>It is expected that intra-orbit and inter-orbit ISL links will have very different properties. Intra-orbit links should be much morestable,stable but still far less stable than terrestrial links. Inter-orbit links will be less stable. Links between satellites that are roughly parallel should bepossible,possible but will likely have a limited duration. Two orbits may be roughly orthogonal, resulting in a limited potential for connectivity. Finally, in some topologies there may be parallel orbits where the satellites move in opposite directions, giving a relative speed between satellites around34,000mph (55,000kph).34,000 mph (55,000 kph). Links in this situation may not be possible or may be so short-livedas to bethat they are impractical.</t> <t>The key question to address is whether the parameters of a given network can yield a stripe assignment that produces 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. However, if links are unstable, a stripe might have to encompass dozens of orbits and thousands of satellites, which might be beyond the scaling limitations of a given IGP's implementation.</t> </section> <sectionanchor="deployment-considerations"><name>Deploymentanchor="deployment-considerations"> <name>Deployment Considerations</name> <t>The network behind a gateway is expected to be a normal terrestrial network. Conventional routing architectural principles apply. An obvious approach would be to extend IS-IS to the terrestrial network, applying L1 areas as necessary for scalability.</t> <t>The terrestrial network may have one or more BGP connections to the broader Internet. Prefixes for user stations should be advertised to the Internet near the associated gateway. If gateways are not interconnected by the terrestrial network, then it may be advisable to use one autonomous system per gateway as it might simplify the external perception of the network and subsequent policy considerations. Otherwise, one autonomous system may be used for the entire terrestrial network.</t> </section> <sectionanchor="security-considerations"><name>Securityanchor="security-considerations"> <name>Security Considerations</name> <t>This document discusses one possible routing architecture for satellite networks. It proposes no new protocols or mechanisms and thus has no new security impact. Security for IS-IS is provided by <xref target="RFC5304"/> and <xref target="RFC5310"/>.</t> <t>User stations will interact directly with satellites, potentially using proprietary mechanisms, and under the control of the satelliteoperatoroperator, who is responsible for the security of the user station.</t> </section> <sectionanchor="acknowledgements"><name>Acknowledgements</name> <t>The author would like to thank 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.</t> </section> <section anchor="iana-considerations"><name>IANAanchor="iana-considerations"> <name>IANA Considerations</name> <t>This documentmakeshas norequests for IANA.</t>IANA actions.</t> </section> </middle> <back><references title='Normative References'> &I-D.ietf-lsr-isis-area-proxy; <reference anchor="ISO10589" > <front> <title>Intermediate<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/> <displayreference target="I-D.ietf-tvr-schedule-yang" to="YANG-SCHEDULE"/> <references> <name>References</name> <references> <name>Normative References</name> <!-- [I-D.ietf-lsr-isis-area-proxy] Published as RFC 9666 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9666.xml"/> <!-- [rfced] FYI: For [ISO10589], we have made the following updates: a) The original URL navigates to a page where the .zip file is downloaded, so we have replaced this URL with the main page for ISO/IEC 10589:2002, which includes a link to download the file. b) We also changed the title of this reference to reflect the title of the document. Please let us know if there are any objections. Original: [ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO8473)</title> <author > <organization>International Organization8473)", ISO/IEC 10589:2002 , November 2002, <https://standards.iso.org/ittf/ PubliclyAvailableStandards/ c030932_ISO_IEC_10589_2002(E).zip>. Current: [ISO10589] ISO/IEC, "Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol forStandardization</organization>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>. --> <reference anchor="ISO10589" target="https://www.iso.org/standard/30932.html"> <front> <title>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)</title> <author> <organization>ISO/IEC</organization> </author> <date year="2002" month="November"/> </front> <seriesInfoname="ISO/IEC 10589:2002" value=""/> <format type="pdf" target="https://standards.iso.org/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_10589_2002(E).zip"/>name="ISO/IEC" value="10589:2002"/> </reference>&RFC3031; &RFC5304; &RFC5310; &RFC8402; &RFC8660;<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> </references><references title='Informative References'><references> <name>Informative References</name> <!-- [rfced] FYI: For [Bell], we have updated the URL to match the URL from the DOI provided. Note that this new URL is the official page of the American Journal of Science and still provides an open access PDF. Original: [Bell] Bell, A. G., "On the Production and Reproduction of Sound by Light", American Journal of Science Third Series. XX (118): 305-324., DOI 10.2475/ajs.s3-20.118.305, October 1880, <https://zenodo.org/records/1450056>. Current: [Bell] Bell, A. G., "On the Production and Reproduction of Sound by Light", American Journal of Science, vol. S3-20, no. 118, pp. 305-324, DOI 10.2475/ajs.s3-20.118.305, October 1880, <https://ajsonline.org/article/64037>. --> <reference anchor="Bell">target="https://ajsonline.org/article/64037"> <front> <title>On the Production and Reproduction of Sound by Light</title> <author initials="A. G." surname="Bell" fullname="Alexander Grahm Bell"><organization></organization><organization/> </author> <date year="1880" month="October"/> </front><seriesInfo name="American<refcontent>American Journal ofScience" value="Third Series. XX (118): 305-324."/>Science, vol. S3-20, no. 118, pp. 305-324</refcontent> <seriesInfo name="DOI" value="10.2475/ajs.s3-20.118.305"/><format type="pdf" target="https://zenodo.org/records/1450056"/></reference> <!-- [rfced] FYI: For [Cao], we have updated the URL to match the URL from the DOI provided. Note that this change was made because the original URL was a direct download of the PDF file. Also, please note that the full text of the document is still available at this URL as well as the link to download the PDF file. Original: [Cao] Cao, X., Li, Y., Xiong, X., and J. Wang, "Dynamic Routings in Satellite Networks: An Overview", Sensors (Basel, Switzerland), 22(12), DOI 10.3390/s22124552, 2022, <https://www.mdpi.com/1424-8220/22/12/4552/ pdf?version=1655449925>. Current: [Cao] Cao, X., Li, Y., Xiong, X., and J. Wang, "Dynamic Routings in Satellite Networks: An Overview", Sensors, vol. 22, no. 12, p. 4552, DOI 10.3390/s22124552, 2022, <https://www.mdpi.com/1424-8220/22/12/4552/ pdf?version=1655449925>. --> <reference anchor="Cao">target="https://www.mdpi.com/1424-8220/22/12/4552/pdf?version=1655449925"> <front> <title>Dynamic Routings in Satellite Networks: An Overview</title> <author initials="X." surname="Cao"><organization></organization><organization/> </author> <author initials="Y." surname="Li"><organization></organization><organization/> </author> <author initials="X." surname="Xiong"><organization></organization><organization/> </author> <author initials="J." surname="Wang"><organization></organization><organization/> </author> <date year="2022"/> </front><seriesInfo name="Sensors" value="(Basel, Switzerland), 22(12)"/><refcontent>Sensors, vol. 22, no. 12, pp. 4552</refcontent> <seriesInfo name="DOI" value="10.3390/s22124552"/><format type="pdf" target="https://www.mdpi.com/1424-8220/22/12/4552/pdf?version=1655449925"/></reference> <reference anchor="CNN" target="https://www.cnn.com/2021/02/11/tech/spacex-starlink-satellites-1000-scn/index.html"> <front> <title>Elon Musk's SpaceX now owns about a third of all active satellites in the sky</title> <author initials="J." surname="Wattles"><organization></organization><organization/> </author> <date day="11" year="2021" month="February"/> </front> <refcontent>CNN Business</refcontent> </reference> <reference anchor="Giorgetti">target="https://ieeexplore.ieee.org/document/7417097"> <front> <title>Path Encoding in Segment Routing</title> <author initials="A." surname="Giorgetti"><organization></organization><organization/> </author> <author initials="P." surname="Castoldi"><organization></organization><organization/> </author> <author initials="F." surname="Cugini"><organization></organization><organization/> </author> <author initials="J." surname="Nijhof"><organization></organization><organization/> </author> <author initials="F." surname="Lazzeri"><organization></organization><organization/> </author> <author initials="G." surname="Bruno"><organization></organization><organization/> </author> <date year="2015" month="December"/> </front><seriesInfo name="IEEE" value="2015<refcontent>2015 IEEE Global Communications Conference(GLOBECOM)"/>(GLOBECOM)</refcontent> <seriesInfo name="DOI" value="10.1109/GLOCOM.2015.7417097"/> </reference> <reference anchor="Handley">target="https://dl.acm.org/doi/10.1145/3286062.3286075#"> <front> <title>Delay is Not an Option: Low Latency Routing in Space</title> <author initials="M." surname="Handley" fullname="Mark Handley"><organization></organization><organization/> </author> <date year="2018" month="November"/> </front><seriesInfo name="ACM" value="Proceedings<refcontent>HotNets '18: Proceedings of the 17th ACM Workshop on Hot Topics inNetworks"/>Networks, pp. 85-91</refcontent> <seriesInfo name="DOI" value="10.1145/3286062.3286075"/><format type="pdf" target="https://doi.org/10.1145/3286062.3286075"/></reference>&I-D.ietf-rtgwg-segment-routing-ti-lfa; &I-D.ietf-tvr-schedule-yang;<!-- [I-D.ietf-rtgwg-segment-routing-ti-lfa] IESG state: IESG Evaluation::AD Followup as of 01/16/25--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"/> <!-- [I-D.ietf-tvr-schedule-yang] IESG state: I-D Exists as of 01/16/25--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tvr-schedule-yang.xml"/> <!-- [rfced] For [ITU], we found the most current version of this reference at the URL below. May we update this reference to use the most current version? Note that this would include updating the date from 2016 to 2024. Current: [ITU] ITU, "Radio Regulations - Articles", 2016, <https://search.itu.int/history/ HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf>. Perhaps: [ITU] ITU, "Radio Regulations - Articles", 2024, <https://search.itu.int/history/ HistoryDigitalCollectionDocLibrary/ 1.49.48.en.101.pdf#search=radio%20regulation>. --> <reference anchor="ITU">target="https://search.itu.int/history/HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf"> <front><title>ITU Radio Regulations, Article 1</title> <author > <organization></organization><title>Radio Regulations - Articles</title> <author> <organization>ITU</organization> </author> <date year="2016"/> </front><format type="pdf" target="https://search.itu.int/history/HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf"/></reference>&RFC1195; &RFC2131; &RFC2328; &RFC4271; &RFC4655; &RFC5340; &RFC9552;<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/> <reference anchor="Westphal">target="https://arxiv.org/pdf/2310.07646.pdf"> <front> <title>LEO Satellite Networking Relaunched: Survey and Current Research Challenges</title> <author initials="C." surname="Westphal" fullname="Cedric Westphal"><organization></organization><organization/> </author> <author initials="L." surname="Han" fullname="Lin Han"><organization></organization><organization/> </author> <author initials="R." surname="Li" fullname="Richard Li"><organization></organization><organization/> </author> <date year="2023" month="October"/> </front><format type="pdf" target="https://arxiv.org/pdf/2310.07646.pdf"/><seriesInfo name="DOI" value="10.48550/arXiv.2310.07646"/> <refcontent>arXiv:2310.07546v1</refcontent> </reference> <referenceanchor="Zhang" >anchor="Zhang"> <front> <title>ASER: Scalable Distributed Routing Protocol for LEO Satellite Networks</title> <author initials="X." surname="Zhang"><organization></organization><organization/> </author> <author initials="Y." surname="Yang"><organization></organization><organization/> </author> <author initials="M." surname="Xu"><organization></organization><organization/> </author> <author initials="J." surname="Luo"><organization></organization><organization/> </author> <date year="2021"/> </front><seriesInfo name="IEEE" value="46th<refcontent>2021 IEEE 46th Conference on Local Computer Networks(LCN), Edmonton, AB, Canada, 2021,"/>(LCN)</refcontent> <seriesInfo name="DOI" value="10.1109/LCN52139.2021.9524989"/> </reference> </references> </references> <section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>The author would like to thank <contact fullname="Dino Farinacci"/>, <contact fullname="Olivier De jonckere"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Erik Kline"/>, <contact fullname="Sue Hares"/>, <contact fullname="Joel Halpern"/>, <contact fullname="Marc Blanchet"/>, and <contact fullname="Dean Bogdanovic"/> for their comments.</t> </section> </back> <!--##markdown-source: H4sIAIv10WYAA+V9a3Pbxpbg9/4VKOeD7R2Skmj5pamdXcWSHd+VY5XlTHK3 btUtkGiKHYMABw2IZnx9f/ucZ3cDhOzMftnaWlUllkigH6fP+9XT6dQs68JV t2dZ166mL0zr2tKeZefZh7pr4fPsvFmuXWuXbdfYbFU32U3e2rKEj7Kfbbur m0/e5ItFY+/Owju9x7wp6mWVb2DUoslX7bR00xwGnfq8nR6/NDuYW0bKfoX/ 4QBvmrrbmiUMcVs3+7PMVava+G6xcd67umr3Wxjt7eXH18Ztm7OsbTrfzo+P Xx7Pjcm7dl03ZybLpvAf/bjKn2UfZ9mV0094PR/rap98WDewlL90ldvaJm5O vrSb3JUwFbwyK93/lH+Nqepmk7fuzuKMb6cXM2cBkKVvps47Dzu1+XTb1J/3 9P3N+5Pjpy9entGoAuu3VWubjS0cbDe72fvWbmCasY91LfgDXzf59KKGZVUB 8Jefl+u8urXZdVO39bIu6Sg6bwEE2au6+r2rli0AMB1o59p11q4H78Afdw4R g76CVytLb5bW++mmLsLpp0Pd2ObOLW32CPaZvTh9/uQxfRtPJECZNlflOGJe Zu+b27xyf9CfjDxtXhV5U8hn9GYBcABMqe9mGRz1nD7ztnHWI3acIWyP3l6+ yhjA4ZEVnY9Ovi1WZ9mDddtu/dnRkZdp/Mz5egYLO3Jtuzq67halW5b78zs4 8nxRWl2OP1oePzl++WT+d5js7zDZ32myv+Nkjy4fz/5w2wcw0YfXr54cPzk5 41+fPjk+Db+eHMuvL06P5/rrs2fwKW4iwaQfgXh6WPK+0kMqOjqJDNaUfbDb +EG9ym7qDj5dIFbfrtsR6AeaYKI4n2VvZjRZ+JxJ47y0n2ECIIQ3Tb7exEf4 GN4v21l28uLF8fAYZJgH5xv4bJlX2V/qrsEzxsUtna2W9kEGR/Bx7ZoCEQZe nGW//ZY9Ojl58fgse3L8dPpkfjp7IANdvH97Bkc6m58+f3qU/+5n/sl0fjyD h2fw6HdP+A9b1QUfbWOXNR7hyenT4+Onz3CCV3ndg/GDiz3s3i2VnjySzSG/ A+hU2fs7RHa7e/B9IP82w5nGv/trwpUOX/sNjvV2/Nu/zLJfc/mSz2R+PD+g CqOEWfm6gbce/Zh7W06yG6D6P2xTwhE/nmTz+aOT+eMBxJ88eXl85Ofzk/np 06ffp6XdbjfbFFs3W9YbgPH8dPpiPj8+ms+PTuZHOMIRPP8/AGjIwP/7ybOn T09PX76cP6Vz+PlnOYe8ubXtYNRlVdGgsL+To2MY7+QI5NH6yG/zpf08BSJu Sld9QnkiEmd6cnx8PPXL6sgBCn+erdtN+aB30Jcl0Mu7zn966LMbHOe3rKp3 Wb2rfJYv4PSzHMgNURTwNi/LLF8iZWZxjpTvOaZN/2n/IDmP13YBNHIywYM5 +T6W0IG2sDwc+o2rERKt6+HndQ6s+rJiiU24aW83tmoVX+85/beXl5eIHidP 6dfsTVkvgCJf1ZsNCLslsViPPH5lGyTQ7NGbq/c/Xr56/26IEycnxy+P4Ev4 aobjzZ6fnjw/fvn8zzEa3dP4E9dIJb6ty+KeB17DA92tq+75GuD3s/t9Xa/u ffsq/wNw/p7XkQ02XVUnB3hhlzMCG3z2E1BKafcDdmHLfJ85D1IJEAZ4whZB eZZdASpdwRDVch9EM54WItqf4BfvZjrdgCm/y0FHSr8KMjGDs0BEO3lxDw6c v3p3hsJjaW1BnA3wGnH25DmgFHxJqpdf19sMCOMn2M7HeuuWxAAHmlDEhdOn R0/mL54dP5vP6N/n3+fHRe2IGd/z/oNUh2ra293t1DOKTxuG47R103KV95St 9q4BYl/boivtdA9Mkb79+Ev/sOCD7ENeuBqE5m1XMtZPQL9tQdYDIFLSBUA+ +772YFGNnbm2m7mqPVo7QN5mf/QT/3vhbl2bl6/qsmTN6aJeXrlFk8MjJ7PT J7PTFzNbzU6OT2YwrKgNJycvn4pWMD8JGsQcoCO/ns6f66enwEKDXnGqesVL 4LT466/Wt9t13tchHlxdvj+UZ4idHwCTQTcEGJ5lN11zZ/ekXrzqmob4i+XN ChxewcClBT3T/wlsfjULixmg8ytbgI4w/Hbw+hURw+DNK0DL+OngjQ+poi8v fHCgGAM3ly+iEkPc+cl3zzpvPrs7wlz4/GgOetzs+Pmz02d6dv97LWgXYX1+ c/kBgLnMSYXMLgAtGrfoWlsEntDTuEfP5s8AGPQEmv5eBeOv934JnOa37l52 etWl3BClWPZNCXP6DHhJIkaAk1zVS5Y0W9h4NKqyR1evfgbF47LYgDVXV0CG P06A/Vd5kbO8nIxJHnjpKdDFyxk+MXv5dH768sVLM51OQWYDdEFGGxNBWOlk 2wbQF7DY1xs0hGAhgHEI/2XAYzoBYM+fbGuqQBaz7COwSHjVge3b1tu6rG+J 3y9h1a7q4O09cshNjQQ+YVMKdRFvVnmToa2UNbZ0hAAtnFG2W+ctD7CBnZPi YBtcTuMATrriGejxG2vYlvNoDOKgOCtZYXeu3WeoWy8sUCmwL7fNEa2KDlcJ BtYCOY8pWJn1M2NA2/YZmOEdaQtgMmxrDwPnmVf0FPaa5UNz3x/A0yxAhyzw dO1nx4DUt7eC0J64x8biDpzfAJu1Ffy6hNcQRka5dTG2MbZggz1UV3gMY+sH 2zvMKK+NbZYO35O0YzoCnQ81d1ojPFpZWBIgJz4g1pRKR3IxgIUPkII1wji+ k3flgSXrUO0e5kU83LgChLMxP5B9rpbZ/9NYafpYmf2fYaURrMwCVmb/n6Hl Fdo2U9yZHVk97NAC5HC1hd2W9d4WE0URAkBlOpwaPrBg+m+3pSjuBA1Y6R0+ SN6Ug10zwqzd7do06EwC3EV80+cFhRxyatklggnR235uGwtnTqs2uMSugkUB wOBtANM4/yIcvUKEgx21O1xwYjchisACS/cHnGRjASSoFmc16M6gb6JlVzFG t4iVgMz1zsN5LGwDuJgeCeAjDAPGLFKvJQCWbgNIxvaMcEPcRkObYpI1RAm0 w2V0iEUvmO+AZGBHXalqO7/Aq0HsyxszQkOydzg9724rMHPp4Q5Rsq1nwA6y vCgcUyQTIwJC4A0TuwaQsdjWDnmVEAlS8mAxAOkOqQBhEQkRF66cAFBN1bZ7 0AwRFSQ42M2s5cEToLKkqA3MwNzaCkEOvCRXPxjhGgjpcu8dg7BwftmRT3ZI DS4hyMBfeF045HIJIHQw5v3Sqa4sInpT58s1bnJLLkn4bJQrGOIKHTwa9spY RixVAaKOvCmvTQeKWGdwV9vg/ARWVJddoDNCEOJNMDIwBZECeva7tQMycWCg N9saSE3dp02+dTCZ0N4hvTHsTIQdUmfh002LlAAEgrduO1cg2xrnhKbewsGB DQL8DfRNQm30aPitXboVKNwFHL0rPRJOCnjEx7oq90bnxKUDnBzLoRwESkMS b1va1g7wgLD+/6Lw/eEHsmGQKaEla8w5IAPZMfBwI9/QIYmIWpGnFCjqyxc1 QL5+ZbaFaNJG2QObNyOUtM6RvQFvw8UBuBorw73K669faX9fvpBiDuPSAj/a ZsPgOqeAiWNOZcx/Q63Z4ww5OxBg8ZbgEPnmDB+7qHcVMo8z5uh5uSL/VHbb 0G5IapU2J9RdNfUG8TesHLCJTKbLvAFe55lP0rC9T3D2Ch384tVS5G6FiNHR DBKnBBoV1gNjbsu8YoYCUF8hP8dtIohyXhVOHtcizAIopewKcnj5tdsCRuau WWKQaELv14Qad3aNFjpCu0THyuX7GUAWzPmvX3Hxb2DQXb4np2xvI7zibd6o LuIHW4JpcRYwG2CZjKOkh4mQORRedNThmOgoYQxC3bB/GXum60JEuUOmtUHe hEIYtrSAN3euIJFDZwJyotF1Axj4FSQ0ojfGw2W+Zb4DxhfDB+gcWTauAYCG pA1qo6ss2GeoR3T8pO8WvtsoL1qJxMuVgeUJOFCDbNBj0eAZk7uRbTcG6GVp iawfXb+6fDzL4BTEDwH4/g5lFCwYRrnVnaOwyT1MTkKQ9TLQuZCfe/SeE4MF TqnRC8YlhSAd7uX7s+yNrQU0CGA+4/eoTs6QUMLhwOHC44x0FVtBhAIwJOCa 31fLdVNXoHbQYuKJgZqUs1z2dQbv2NWKVAwLcso7wI36zjYwCMojv63brK6S M+dlRvpD8iGMV+xJSZDQbYCmE4L7BmUee5sDlevjv2zxL5ro7ZtrCZ45OCBB seBHQHgMtb9At6iKGA73OVoVPAX4lReAGuiboNATsG4MKM7Qo2n51YdynA+Z epwXPAHdkOBqN6Ttk6Zg/6Nzd6AqAo4AiB/iWmzzMPAC8q4SM0Y0B4pX3SXO QQqTkCnqlYwWiUxhMNxM3978VyKnChZkVRFYFcIzAIitH9gFrWGxZxxdWpXB jSe+IyFcYD5CAOi0Y1b09uZKFhWDEYQMs+x1A7Bh3cchXW9YgSa1M2rBiGWi BwflN0PJCtQKZ9p5Otk1bAC4j8r1vNoz3wITgLeIe+82uFoM2/Hark7OGGzZ lQXUzk74w6v54GM6LP59To8MHuAPkSzRy/0tYryKxJgDb2iB0+NpzifHx8ef NshgUI2m82Q30a1y8kvkEClLxOMBRlIvXR6gFjBYXjMUh0F6beytSrarm+uw fKSoG5Lswe92kbd59ktFi6/wYZpIhS9b3p5YPJwGCKpl49C6Jfn40PcNRPS8 kLzCL3lb7xBM7+gwvgkpeA4nVo6BgMNTQG5GbEwlzRCa+oKCFF968nTy/MWz TxtawM3bi7MQJHqLRhsogLBEwlsMQTNu3ID5trWjakdGvGKFClvxO2AojMNL IqPSkwq6Yb1CwHyCbD/n6T+cDUNUw6mZtw31mRFF5kC4g0KBekNQKWi0BGdG FIJUuidotMEAHyjcU0S5ngD6IYR5WYFLNPdXovWpDhfzXVAYI6WgtaYqtx4j ywk290AzIR2ZxQg7V1gIbgwpAPyYOk62yPOLPy3I4OU9Wew9cRbFKAq1SENk d4JEf08YnBw/LYRXb4gKljmmk+AiiXnzVvNlU3slvBBb4pWBcpoX7JQCkgcB 0VpDBlEJFvwHiyDi1ZEh79mQb/dbESmfKpCGqJ7dqwV48wgo5fFkhNKyR+/o G3Sv97lV9uiKvinsFk4e0ayujBIWAILtmGDdkqkCop9GmOqx/iuuawccyLaR /HnXoHftLJn4LUoxEmFqzALnEOOabZcEdTYgzQnkBXKmFF+dsny2i6tazCbA qNu1YaETvYzsfXkEAsmDonbBrpDCrcQ1T2TNpzpBqcUTL6yJxAFCE23YxuHB 0LyKgMgZa3IfoQHb85Gxn78Iyzp0+qmamOIYzx2i6PlGMI6sV2+BTnJ2NhkS khMlXJqj3LNWnlfhWfJG3PRY2GBgBbOhvRNei5YuCjrozjDufqneHXpO2a3C UVkhrROw1nj0RxGe3HawEDgTJlGUGSVpxAG+cOz//Oc/DXAb4lnx51+mw59/ wY9JQsLTN+reyjL0N/8D/k12Cj//wI9VMcTfOdXKtmnCwr1TmYOnXrtb9LmC 9oCsEDmlGoQ97wttpsdtPVnay5BkYCP2AjmSL8EPz8g1RoR3j5WzJTEYXZCA XH4AZrSOloiEKCpHZkWnk3K7RCGnRA+3sYH30SwmzEK4EaiycUt8pof0pNwO zTrEhqBPIiODFUazKLiYbH8oRTC0gw48DuqyjI7enUOfQ3TPB4sTFVfyPTZx IwpgYD01cOQt2NS4iM8IPt4Ewrix7FjG5VKWCILNG1giqGrIdxOX1BJFSC7e 4o21bVCYQdHwOOptnaP3+ZfeQsQoHNflylQRRDYsdi3pAIA65lAJEE6IZ1QJ vZFUalCUgJDF4Vk8bdRETfDuzuVE3OyhIR3xFftVjblyn2wf4noU5MAVzom7 T/wvjPar3JVGFfRd3lTkE/+p3oEO3UyyDuw7GDv1ncuQwZdttnC4btmyhxkw FDB+batvzBmYMrNERCujPlr+U3U2GToQ6cJG1k1YBsIH9By2xPIQFslEAaAX iiSeDSAHq87eIQ9WZ4JlGweO/zqZLWp3ivjkxrUDpnkmTxk6VfhKXTLoiNyg wQMqpocBxWEXt4hYkW6v6KyJMdEgiLKhZhTnnqgvqMP0x3KPJtV2vff41k75 O9hwQAX4jP28JYZeihfyJrqHQbKjTicO7eI+dzzgCkyTlRgfEtkGBylaVN35 vCKhaw7HIYP01c8/f/0KqvsnS8e+BGaP2gp5XMVNTedDXnRUQySYg7iDUza0 YWAWqy5GoHEFdK6AZTvY2DnpOaiLEYrSZPBt6gs/nHMJk4KytwaLg2QFkrYG 6tnP5dEriGOBbezVC0THK+Z6L+5H0EdZSgl6PFkcrYedPDXuAFWaFnOkU7d7 GsUz5mf8fSRuxqxKV8B4zr51G9gWMqIlKypw1hjoMF0VI0Mak8lGAsAlmJes mPAgdZoFDec9lhlAIKt4vQls0DwgOCwlaJwejNCQwaChcPpSsq/vYoRF9DBi ocvUtgEAYfAKmSrHr5CMKERJdl2g6Gnfa65QnGjwxQS/R97jPBruHEgCNCL5 SEHpQ7FBRqgShGHXkidTOnlhV3cl7s9HMVXVgJp1GYOlh/EXPzFo1uCykT/v hUNJbI70NyS+/DZPlFvFQQnEB78vhXJ4HaTU+g4lmENYaQgJgUz0TQQ4whcA 5kFRxn15Upn0E0fqLh41UQs5sQSYEm9U/mQSPOBg0HislGVmON6IExTR4VBM L3qn9mS3RfctDLCrUyS410MJthqs1j8GbfLm+jU7AzC97etX+hUT2SR2Qt4E mJ6eQ+cZAFloPI1KKD2KZZ2DDrb8tCATCeA2kbh+twB8dhTvJGjiyZLNt1qp sarvzbJfMYrHrJIJdYe573R2CYzGqVNclZatRW/BSiZgbhvUdsx45sIEJXtj 5WzI0szQ04IGIhr5Aw95EuhllwuHWaJV0mO4GjC2Oov6+R5dnTxmcJCbIFp+ 3raEWeTHmmguQKX+P3hx/pj9ZOEdgrANkbuQlMKuVUQGbynKUpb6jPiJPIbG C1B/0UVgaErF5auTSXY1J+N9AToeLhhmnqFOGE6BAcDRR69oIs7Tak/jkaOR QlDi52WCJkrJyVmDymp0vs0FRzYd2O1weDZv8DmMIxld+zzh7BTaPzzVCcmx NHSEHAGlarflRA9DS6DUv7kug8EN3Iv5UD9yQLsInAUXhMAEEIF+fptLmsi+ x/sXtrIrNFFJgSZoPfT3IAjg06/AzuDdmkPVFb8Q3B19ueA52uk74CI8m8Y5 zzHksxW/2NtKtA5WztAton4VDmoLTPP4Usy1CBFoJj9yogykHupEeSl8irwm 23xf1jlFl99eqxO372Yhwc4Z/SE+iGFq8RRIGIwj2zQk+nSUfZtwwjG2KNkZ QXXgc4QXdljFhOIwLOMjUaH4PPIxPgJfrB28Tiqb2ELBEDW9EKXETxbArrFW R219zvjpKU/KPEamY+e6Rul4Vex/E/rCvfz45tpwvG/+/AR4dKICaCgfOJ6c LOJ11yA/k4M5tGbTbfh+/JPNGzFmZ7ypqN6bxEoeGVdTl0aUbQCBeOiHiRIU 1+5aRG7FRzAotnYs+vQDOoLFLL3OWwS4J8phGEYRBTx/gyIH/aU66CEY0iwP w2kxGrrf4XJC7lJit6OVTJDC1GrWdpLJTUxfQb/ENHolFl356YDhbW2EiNdz zA3a7gD7NuY5wOek/eSjiUVkgYrKVYKd25iSKiAcS+1+otgK07niu1++SFED ZmCQ51Xp2gRZimlnmCzAOT5JAhy738JzRJKY3k/cw8Rkvyw6MaQoMsE4PAMO pjMzSmT2WGh9GYPiaILWuylvFpQs0tKWuRdWDgwZ/zC9BavBO0Yt5+LZ2tQo fhgfEkXhAM2iXWQWcOiNXaqCIutOyaUXU1NKEUoj/dAE7CVcUXkuQ6kBRviZ vKpsKPU4EWqycRxJoqNoz73vB7RSFiv8iMVAwOIa09XgND+pcgKjB+cam+js CAJWkXq0xGC16VLCsMHsT0S2uhTJeEaDzghl6roVIOKEnB3wAdcqRcE5iss8 caFhsDc1PTHVqE1dXr0DgxfTv4E6hTvpKyRmwdKiZBtd48o1vo1aHOq5yHzr cYbEKqzZYPkoiQLAwK04oWoR2IFrAsTKGrUO30OTu7oEAJgGS6YB29miqndC 2li8TUlZWhh1v+QYMlWFDOWE9UDj16JetZJLNoJKbLYlkFGFEAN1lNlMOU1j /lGTIHgEP+cweXavFN2SEavqNsjcYIfkqtNkAmRG5IwcHeoGpgFjkGIt/U2n zwXc0O1+du09ckV326My3q9RLQe3C6gx6hAepei/dI3z4lpDrGV1m9x8dChY Tkp5RoqPFdgxDXpfjIYGUe8h94MG+6LaxwYqsXeQT13CK0U0m++J5o8DBdFm h+JDgDFt62mAiyxX3MR973s/5YvX6NqejfeJHUNAypjT7FRJoAiGxGswXAzT YHIvK0QH2Q0VORIA8rs1YiETmXxJbr1ty0FUv87R7T8eK+itNlBqYPXhA82g LMHIYWRFy0TFoXHsy0cHY/YaHrefKRltcihEiPvgIMReQR1CnfXd9dUNIMPC onUB/MYj/WiAPajCGWoXt7bVzLuYfYyxSmQ2zAOZNuvNwlXBN4YmDQu7gY2E X/SCCBNy8Uefnqp5KSKZPiJl2eV/dJx7jXpSXbfoZdz6JJiFy8Bx8di054Km kBvNNuZ1xPVxehmFB1wlnvZhoOpw/Sa/RfdlSFCX7F08s3W9C0ysQJ8HFxCM bZHZekIr/fha8J0iqg2ytKPjKYmbqAqjdFUY4nGJ6jbRsOiAvcNeeAtCJjdw MKBjogf0VRIMO+D+HOiAtyV2Ht3BIT2dAiShiGMGhqhhp2K1T+VbojNRoAYY RfRzhPcTVVhjA5JPLSr3ULlJX0TtjQHYoS2NypBJN8P+iewWLNBK/HltWshg K+LeWp4ZahYAGW4bNPZThQjlT9dP1iUvAjvnUtFsCszWK6LmENlv5Gjruiwm 6IMaTbNHJNnkt5Kdsck/2d7EnCOOmaqU2p9mxahRPx6OX6QuKMAlCspxvIr9 UxxEddT2hF/jR7J75hhG6Q2LHl9/a6qsP5Vt0qkGGDlJkHFysDAOGEtgmAMC HBSSxF3vfEtVkmQcHc41ZlGOmo9xK48EsiTN8bcaXUi28vaxyUs2KCgNYYLu JZh0xbxVsIvE5S7oNcDwXeJxJc9kfxh+O1VqCiphU+2UV6M1RGAGMY/D+iiS 8vjmgb7DGnNf7SyApbBJLa6dIEJ+xTUbxFr1/S06PHZ27kbDZU2JuKTxE6/c 0frgBHJA9YFWtUDVleILBfuzrpsaFrLh5EFknyzC0UJWQTpap9az7TknOUZ4 wLYNnjd5TCQU0HLFCUn3HDoBjyz9WP3Xq93hoPU+xipieFZ8yZqjZRK2SMny 7ZoxIcaDg1KUejbF6iLnGHAEQ3GcErgZqiY5GQUt6TE0YsJcw5aRj7A1JmFy gwxxUNPUB1jPVfkDKibqXbtG/xyfCuoxejL5wM0iS9QDn93jumVHuel5sp1k QoYaSykSgVlWZfc5bLDnVgBzMWT99iq9NP+hX3kW+BgVAHB2PDKQcm9WJej6 SA3kUyjyLfkuU/8ieShhlcHOBDqu8Vtm9AAWIjUJIhu2JVlTE/Nt1VVFTvG5 8nDkngwgPyC2OEJ/zY14h1lhilOIuQp7GKaAPrr58LiXB8rFWKHWS2Q2Ly7x v/Irz54df/2qwQyuJYi5tB6lLNbfFZKlO5b9+ujm7cVjYXNSX9gO3aUt9htj +UnBh7fXd6ccl7q+e9bTkkACnQsTTGwuRSXKACS72xpQGBrrJe6Qpwqyhlsw YZcU4+v0BEQRIUtS0veRdB330Cr9vd7FCZpaa1rTAFDqfg7AqgzMmRdFQ/5H zrLIb7ncY9s1VJE3yy61spYK5hxG7XUojTySK4StErSGZGk3H3rbpfxUZvac IcUxenHAwJIIoSpMndlzSaRRpiIC58uX0E6GnYa2D08OC5KLIjdljfjo665Z Mqu2Y2clWpHE4LBKNSR3REYbyoD7HBH/wDAsqZXCO4n97HryEQZsje5pwsgX owPKn/YoR7d4TKAKBA01BiZ5KsB1YvMNRjJVd5TD2Djg2lPY9jbENGLAihUd rdS+q51o7xwA//h2evX6PKQICAcHkv9TfVmQMuum7zDEZQAsW1catAIAqVHt 0tpQNHg+frwaVXjkJDiyXOZ7TPNSf+6YFwiINmSWhXSCWHPWN3lobZz1WWUR +SMDEV8f0OzKfRZ6IH3xwEZj/Iuu5iRaRYPFKEk7NCIFMRLrW00mE00mhAQc IxofwTHn2WOEA1z89OpaQuknzJPTjLtkbxhbDWXsUTRRmKvOWItalWzUYC7m mJgC6UUexSn2CkqAG7MPc81wVw7KDOMwXA7LAvRtHWekAZBxfZhUSKIPTge1 dgZ031sf3JecoxjDXkOz9oDNBS5Lyvtu7YArkmKKssYkPDfNpyBMQ2RBchp1 jJ3HhBryGqwOHSXRvOJE47AQQ+KhJQbm0fraRv94r3hziCe8RCNxi5SmBqp4 ggEhNZ8YTqjZpqYFUYfOQRcgwkVdrJ3y4UxBvQRoATV/6raqMyQjo9cY8JTy bDuSDZmLMjeXHHguNADDMDo8g+v+/tPCNB8QQVQwbsTTFv1PZPRpGhA8nd3l ZWf7QyEbYWwxIV0cHVZsyIgrSdlWv6JeTF1xl5qYnPp2NVp36UIiAqNOGFXc ryth+qmXfoIb0DA7SQwBhsVub5KImUo4o34fdrlJ3ms4WfE491EQEyn440DB 0XUIZxIoeElFRj6JiY1sk8VFtLJZTnBaYfT8cTaa5PBHDz4qXbOgEIbDUzcF fj/M2hXjBMORlNtEvJOrUWSZVBLvQIRYjqEZCnWSDpcE5lX3COqmqFfYH3ID nLpAz9HH0XM1B0EKzoGQZV/GhzkVguT0TUyQINaYJIhmX35I0yco+NdzlH35 kiRzoGzlePwwDaLkU12gN3/l2nsq1icxUKqETgZ8VVMJT8wDRMSE0S2XIKU5 ZJzRLaL3YAbOhdlqBLbpWwNS0Cg5PoPickr3uZqHw2Gun4SI2L2pDO7qxKQW bwhuiTy4/735IPUzJlC1634XHlw3CCeNmiQefwEe699c667iVRjqyubqAAhF AKGO6SGY9xQiAq0rDOEfxnBSBCC8trblFhNzXdUTBsyYgG0vLJOAa/sem6So R4QYW5B7LjTjhHLQ+uMmgmahmVE5wjlW70ue/aCYGbMyjZTBYAy8wZWMDwXA j60AtI0E2LaRhcSx09pWJMxqhWUogY3B0wRCzKoHWZIgKKImH6oquIzJ0RWS x+SCcCbnmDt6jV2as0TRHWnijMrVr6wJATuIrm6qi1HEZsBRPiqHLdTsT3DP kA4TGB/A5pv1qdmjq5vrx33XXIzVp5YWzJyMhAMg9uP7Fz8+Zo+LdjswMVTZ I0pdfHDapMPDQmEkHYjZbC/qGRL7QKNHSEXYTsZSb0NBegRayLKH47tzJPSp gxThH42tFY5Uxbi2ORXOl7F1Rxybvfy3mA5e7iVMW0hSUnLqepIs9rQvBcfI OPgmubb0DmkklOfrQuZ8QojqUxiRISiyUP1AP5ZUpxiNbVPJipfsQ7FesDYf EwQieFMrF3NEHSXp3qCm7e2E8D+J1pFmpEwW2dwJlgqHM5JmDHSK/E1aW/CR U2DRJ0rcdWPzKjqjozeSc4B5gMEgLHOIAYYcXp5I1q4124i2gFekP4w/wIj3 rwKKxNcP+3AUa0FCpyyNti7UKIvNk5KgJDuWeWdaHsCTBieMCTo4rOwR1cTP HzPqxyXmggw+auyyTNYOEbiJIA7mju+bnPf5WyaZmgbonAm9ipLFky3RB5fm mMOy45AmGoCD1RNXS+xD2sjVfBYTNyOTk2RblYNgyTf7TFaGyegtV6QSkqCP 0Q0d2NEHMdATYuCrqmFEIyMe5mnJ5ji1pLAhkJ1YgD9IObt02qEEZ+wGlHiV tuLQD8HBhHUc9M9QC6NeGYYYrlsynNQh01g+CsqTo/okhZooS11bI99fmvA2 JiblrsFAW2WJNL0k2dH5Jm3dY6Yl5uMZTCr3rOuhBEH/DR8Uab60aWyV1Ejl gFEXh8RhSsrFIRAkXazCslii9vTQfAFcdiTANejuksS7TBLvyv5cvCvWxmFo yoxORukWoZqCWEqosxFAhH0YtgOICYD5WlP+e883jfVz21D+Hxms9jlQrYbV l15zg4mGCLEACHGN8zCTFExulKYB3hQcSdKM4j33nOgvQ2dPi5rUxcotF2Tq TBMynV+x9mfNPfOhnFDS6GX8h9r10OPBy3Ns5IVwLRxFzKgkYRP6CiU58YO2 aDPu5yHL5SAbY2Uw7eDltMwdUaZCbECpyjFGOVZxy5lRJhDmM+ZHdWcGMAWF lg/QVYft/3qaCoAxVS4OAgRwaEOtordPyiGn+kj0QKuad3OtdroIikmiCQP1 FOr6SjM9Qr1bWrgaAwEBB/vyrrdaUdcI/SkAmJPqrW7pgPx67urAmBDRDZ6J KoIxdFMLuZXeJV1LBuvsNzKAtRFJq5fBSAuRQGNSgjE7iOyXkrsIrKGf6ITj Ge6giQnZeNiIGdjaAbEZBtSmLDF3Owkf4rL148SIB/N8xLI3JnlTWiIdoAYm DKERJB7FmYaI2KdskrzXgQu7TpIjBJP62pOaDEZVldiYMMpZiuVy3JmV2EJb So25L7kVQa/q/28m6SHwb1n227AvwN8OGgUcfnL41vhj93yY/Yb9C/4t+5z1 UulGH4URxj/HH2lhMMdLVKYC1Ojq5dYFiT9ycCKNhUOtpFcZO9d6+bWUa9zr m5h8p/5LQhosNzucfyI2lmQ8sjSgrJjYbvEzIlBIOiYGqrXuabNG1UeVYa2c RM0ZjWL0bFt2EtKXBWpqZcCTxLP/mgxuBIKaNJNDrWzEo6i2w058rd9aaSrL 0mCguQ+pJTVN4wACmpyL9dQ7rR/zCRCS33AQ8Iaw5R/J///d9Dtl9L7rYaoS xtU9pDGOzn9L/p9lY8hK6D5KM4O378f03oMkzs6/9fA3pxwO+e2H9Nk/9VT2 C1P2RfZnSHtkku/S+hOg9TFiY2I/53xbNZO1rC0SuLacUozQ2PENt53q8QcK TvTCgYAZa5JAv7N6FWKIIbh1we6fH99cS0KHGIYYIQyNN1igy4q4CeuOg6fw 6pVh/aaXKYAWCZYwosvMgubpk4gA5bKKo1xi4hjHobgCLG8aEn6SIBiZIuIH CFTJdFuCOm9U8vSDsNxNB1MrAAGLfWiSinvktLpaYxmG/Bgg6Nl9cThYv2nw sGtI6joU7bKODorUUyJxeTb184r5Dz9wbtiRyX/9MiJOh/MOVzkxvRbN/cyO R+eT7JfH4nHqo4lA2ov5dm9NBiPCCIelO4vCKL3wX7rBTADS4u0uym8J7udl aeKTsTu0VLpL2Wvi+0uzCCJKckkUJUZZbyjUn8aiqHyGVZfEFyKWxmHmoGHl 72O/0GyLwVfZEPbE3tR3bHqQXogfDyou4wJMAG0aFJUudX0aSwA6DKiyuUHZ uIwpE4kf73L2BN8DtJN+6gVHeeO+EiTAAhEO3t0XyFWH0UW62ZTK0U86RE/Z pIhwinajhsoKz0HqzCTotPikMEffausWololkR46P/RChEdsYZ0/jGl/PP7o a5PsakA/AT+BdmCMq8eC//Fok6I+xNgkFYKAiK2V6443AJv/d8yoiekOk2FV HW4R49zh/gx0xHYLbPa41fASARXjEDV1j0FY0CCzcHVlrIqiBvfejvl/uQ6C nDPKpvbUPU7yhK04N5Z7TOIXFHJNuIIB47exqzndSxaS3yV3s0paYVVUu17t jeyQmuNQOpVk5/aiTXLgqeIUcmT64Ta+IC3W8od6H6IhTolu1bAScJjkeQ3l y5rH8ubE65sEDAAIAKRF3azrusC0b4fepJ19iG4oETUsE28+TNQjps5hCgP+ 3oHMWpC3k7AI9Wv7GcsDYeHkxhU2kZBDP13KaA9/ar8izt9J9BpT8pOwtuVe svmojXJSMWrEnZMkbuzv7bXsudly2mp5ho3WksrwuiFQwWO94sfRbjfBUW04 zOBafqeXFEdlv7jIomY4wvoOSt3JKw36C6dOlFJnk2dtB1Z+yYCQkGFIa4vJ W5jCbGB+0ICmVze8O7y6CuNrgzwtyUxK+ngrk4DpkbeNhFnivSk+03QL0TsU aiHHAVNo2KqggyDFUHHiA2GoakDwFYZjexRMngykM5PSjaxZGQtrDUn1YvIs 9Zq0milthu24JGEjOWs85xDwHnThwkMZyc7KBn70ILm4Ww71BWq5o6cJudEf 13bs5L5TKZ+WGGEzLCqJQc5HMoiKB1JPfGxJGQvakkwxKmMZVnKG+vjgqgd+ LV1Eg7c+bS2RMpGQYI4PCXvbbm1IxEvzdgcX2UhjQTqXWfZjLbfqsLcSOUAv 6phTc7F0/r0eWyhJlYID1I9gxZsahpR0vNj8bS/iO40Paa43wGmL4lmv5oiF /wfsOrnbZiQIK1cKfcZ1HNSX9Zk/t0X1doM6iS3S+sxvt04wGAlcavcSYsgx JP/X85/fZHitcJlmmh5c7Ef55gGnervknkpUL27i7SKc4xUED4e549lT+ZKi UWGXznNDAdS/TF0NsSecsGopsjYKR1OiuohGylAZuVcn5c9E5q7hXgWFLnQQ iDchEH8ogNFpnmJc4hFiXVTGNOr+nES/T68XJXCUEGjAkB5ru7Qsc3/XtI8a u5COWXSHzGF0mFG8wKC64isvrDe0ytWZds8HQqMksy0JEqav32vWv1OaMjJB zKys9skdBwr4aJNoAmyaRQYogwmP+1h1C2/2lPDOd6EbCrLEiuoigxqK/fLx HgtMuEmMadbeBpFbPTMqdo6LpyJAOCziwwuKWBFChModVSuchG/Exi+YdkOj H61mjcsQnOFORox33FwII06zft4uoQJ2mSHRuFzXEixLN8VKWwoeH3Y1SbZl km3JSzGcxJnxTesHTHofj2ovXVQrkGixN01yRJSwH2vQcI0ynbKqmBw7GUF5 6vBEvd0wP1GzNXvO2JFKoBVxR1rMMrZDEJ0QO6GmjUiBv5iYSu9bSwn5UnfG nUyQjZP7R9o36WU1yXaADgl+IgpCrSWqMXxEFKWp03eAbkx6ahJSJyrkjom0 wBEaxHKtViOSAH++hMEP9xptFVxWMg4wcRtr96WwnRKDo7tmQ41z6AClLA+W y7fOaIMuMvE1DT89gckYg8G7H4VqyP2RyO3Yx0+0XC33D83Ys2GdB+2jrNG+ 65c3qWZBVlSWTBj4Ec/Ga2QdwGqT1lBfSG32SRtFuw/4SNtw1jEr0ybJQx7U YcQswVxv60vPZIsX/BYUg6pMuAYv6E1UBhmrPRE7KzU0pXdvxEp82FBOKClW 6PxobUU5tomsjVbMoL2HQJ1yy3vppph6OBBTh/ZfSPBi2AhUEwjyVVjkr8wb LZdG51txl0uWQU8Qaa0MXSMU0WSJTRVGRPwIW1RJQ5yx2xbhTFJEGtYJseRm giRGGRTQEdzRl2qsGhedjKDV61xkuB5NXMfE+XpqwF1OBUSxrb1gOOp2SXm4 6SVVSmoAGnKYh55/osDUUvskHuBqIrgWyfrIchTuv0jsfMpKQ5uV23ZmdBkQ 9+Mge1vVaMrBRnYl/C5mhTjupghElK94gFhQqYvCEeRyAoIPfLyuC67GcQCN pTglhgCX1j+picfZJEkuOeYESqC+pw5HXVgTkeP9DArZH7LXHQWG+Waywy4l KT3d5aUrcjH9EgsuudMNzt+gse3dRu6xpolTRpDmDL2zOapNmKQY3zBrRyjT Qw8yD30rHi4sPkvbk8e636FBQPZ5twCjuXdbYCyRjFcSxm8PFVqypeWgQshf uZXmnXAxBkhQLjWuir7yi+2AuatujSEFBB3WzCR3P6bXpEqfPIynh/sMpbVq mngjvXXxDa1pEsunqyiHmDCIpd2+11g1tiqW2/+E/jG/jpxlKnkybZUZ0p6Y dfTSpAQa0SvHxYKxBINz1jEllO6f1aGG4oeuIkP3F8ZfFqX0teDbC8IVsb6N l1seNCqnVP+wNpOsC7thxdfvvwc0C/mbco0DpsahrlMmC1UGohcZYlGS+0Sp MlxFJY23TKF8LPu4q/VaBkl/12si4NTW9S2Sx+BOzThMvNdCblVNLht9jcF0 qu6SdlExCx8POBRfxn3IMkJz196dF9g9HC/hUCwNrdv8xNw6qf7mu7Lu8N4x m/T86fVhIdnz5BRTOjfbtXn09CndBrRd4w1tV9o0hXtwBr1W+6qnTLpuFGK+ RmHXtFM0dbhLKvEm7CoslCCqaK93N0qJUAyG227DzY4AEuDGmLbL9xWiCWVS X8ve2bJIs7VC3aTG/THHStFqkrSeZUcm2/RUvJ8kRi353qwFwihYGug2RMUz shY2h2TksIbgq/idOsFS/+nB2Up/YbldAh9Yw0zNoEd7FGLJpMA6ZEYTZuS6 Cb77p6bSr80WIAFK1B/SED5eB5WF3vCml5Olvr1Qg7Gw+zq0tmF4pBwKz8Nw miIA5qHP+m26SXxdxF6fw2uPUntE2pZGH2uPv0lnUWlePnLB9AwHP7zGeNjw FQQx5gx69lvSxV31ggI+JnYQ0KMjRYN62bPtrpV9h9WoEx4PZ9TseHRQ95tG JqVQQgBj/VTDdSHpXScY609zHMVbe9i59VpLYQ+znyNjTDIGJOIXUhUo6EPK bQxbB18zoH3vdkasMx7ciiUe51EQkc85NuyBVTgvCbiG2pxWdM0rhskwAOf5 7j2QSWmGTigQ8lTIsuLeeHhMTcX3XGG9hQsNrwdNjRaeI3nAuEDhoNhWgpEz vsZl5zCUNb6cXlWUtPTV29QPN81+bAu6DEbUDtE/ve5Wc6b57uLAWO+7xHyk Ro8U6HADclWznyQ2L2t6sU+KS3Ze7lakZ72uFGCb440fYemxMkp8XxLxMNJ5 /fg03FpLf58cU6hppGieEIZcxRL7YQ055UHJXSSSqJJeOp3ewE5KO2XxkndO Oi8PO1qEVr3YHm/M9U1P61brw/prOsbzJWprpS3YkS7si+8lFp7B97JQFgmo ihcOwPo6B56TL5dukr0HgYjVzBfojKyWn0CwT8xl6UCSXlksZDgvAHcqfKXB INj50tJdXIXdTLLLxn3K/hcwYMDMm85mP+XUd+wvtS3NT3kJGwQ98h0gSfZj CTro2koL2Qssu/mxvi3yCg4tBJBck3HBast5rW/Pfz7/Dn6iu5swhYLhXro2 4osz85+wl/GyC5IAAA==[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "traditional" should be updated for clarity. While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications- author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> </rfc>