rfc9717xml2.original.xml   rfc9717.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY I-D.ietf-lsr-isis-area-proxy SYSTEM "https://bib.ietf.org/public/rfc/bi
bxml3/reference.I-D.ietf-lsr-isis-area-proxy.xml">
<!ENTITY RFC3031 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30
31.xml">
<!ENTITY RFC5304 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.53
04.xml">
<!ENTITY RFC5310 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.53
10.xml">
<!ENTITY RFC8402 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
02.xml">
<!ENTITY RFC8660 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
60.xml">
<!ENTITY I-D.ietf-rtgwg-segment-routing-ti-lfa SYSTEM "https://bib.ietf.org/publ
ic/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/bibx
ml3/reference.I-D.ietf-tvr-schedule-yang.xml">
<!ENTITY RFC1195 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.11
95.xml">
<!ENTITY RFC2131 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
31.xml">
<!ENTITY RFC2328 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.23
28.xml">
<!ENTITY RFC4271 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
71.xml">
<!ENTITY RFC4655 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
55.xml">
<!ENTITY RFC5340 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.53
40.xml">
<!ENTITY RFC9552 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
52.xml">
]> ]>
<rfc ipr="trust200902" docName="draft-li-arch-sat-09" category="info" submission <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
Type="IETF"> -li-arch-sat-09" number="9717" updates="" obsoletes="" category="info" submissio
nType="independent" version="3" tocInclude="true" xml:lang="en" symRefs="true" s
ortRefs="true">
<front> <front>
<title abbrev="Routing for Satellites">A Routing Architecture for Satellite Networks</title> <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"> <author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>tony.li@tony.li</email> <email>tony.li@tony.li</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<date year="2024" month="August" day="30"/> <keyword>IS-IS</keyword>
<keyword>MPLKS</keyword>
<workgroup>Network Working Group</workgroup> <keyword>Segmenting routing</keyword>
<abstract> <abstract>
<t>Satellite networks present some interesting challenges for packet
<t>Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far
networking. The entire topology is continually in motion, with links less reliable than what is common in terrestrial networks. Some changes
far less reliable than what is common in terrestrial networks. Some to link connectivity can be anticipated due to orbital dynamics.</t>
changes to link connectivity can be anticipated due to orbital <t>This document proposes a scalable routing architecture for satellite
dynamics.</t> networks based on existing routing protocols and mechanisms that
is enhanced
<t>This document proposes a scalable routing architecture for satellite networks with scheduled link connectivity change information. This document
based on existing routing protocols and mechanisms, enhanced with proposes no protocol changes.</t>
scheduled link connectivity change information. This document proposes <t>This document presents the author's view and is neither the product
no protocol changes.</t> of the IETF nor a consensus view of the community.</t>
<t>This document presents the author's view and is neither the product of the IE
TF
nor a consensus view of the community.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>Satellite networks present some interesting challenges for packet
<t>Satellite networks present some interesting challenges for packet
networking. The entire topology is continually in motion, with links networking. The entire topology is continually in motion, with links
far less reliable than what is common in terrestrial far less reliable than what is common in terrestrial
networks. Some changes to link connectivity can be anticipated due to networks. Some changes to link connectivity can be anticipated due to
orbital dynamics.</t> orbital dynamics.</t>
<t>This document proposes a scalable routing architecture for satellite ne
<t>This document proposes a scalable routing architecture for satellite networks tworks
based on existing routing protocols and mechanisms, enhanced with based on existing routing protocols and mechanisms that is enhanced with
scheduled link connectivity change information. This document proposes scheduled link connectivity change information. This document proposes
no protocol changes.</t> no protocol changes.</t>
<t>Large-scale satellite networks are being deployed, presenting an
<t>Large-scale satellite networks are being deployed, presenting an
unforeseen application for conventional routing protocols. The high unforeseen application for conventional routing protocols. The high
rate of intentional topological change and the extreme scale rate of intentional topological change and the extreme scale
are unprecedented in terrestrial networking. Links between satellites are unprecedented in terrestrial networking. Links between satellites
can utilize free-space optics technology that allows liberal can utilize free-space optics technology that allows liberal
connectivity. Still, there are limitations due to the range of the connectivity. Still, there are limitations due to the range of the
links and conjunction with the sun, resulting in links that are far links and conjunction with the sun, resulting in links that are far
less reliable than network designers are used to. In addition, links less reliable than network designers are used to. In addition, links
can change their endpoints dynamically, resulting in structural can change their endpoints dynamically, resulting in structural
changes to the topology.</t> changes to the topology.</t>
<t>Current satellite networks are proprietary, and little information is
<t>Current satellite networks are proprietary and little information is
generally available for analysis and discussion. This document is generally available for analysis and discussion. This document is
based on what is currently accessible.</t> based on what is currently accessible.</t>
<t>This document proposes one approach to provide a routing architecture
<t>This document proposes one approach to provide a routing architecture
for such networks utilizing current standards-based routing technology for such networks utilizing current standards-based routing technology
and providing a solution for the scalability of the network while and to provide a solution for the scalability of the network while
incorporating the rapid rate of topological change. This incorporating the rapid rate of topological change. This
document intends to provide some initial guidance for satellite network document intends to provide some initial guidance for satellite network
operators, but without specific details, this document can only operators, but without specific details, this document can only
provide the basis for a more complete analysis and design.</t> 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
<t>This document presents the author's view and is neither the product of the IE the IETF
TF
nor a consensus view of the community.</t> nor a consensus view of the community.</t>
<section anchor="related-work">
<section anchor="related-work"><name>Related Work</name> <name>Related Work</name>
<t>A survey of related work can be found in <xref target="Westphal"/>. L
<t>A survey of related work can be found in <xref target="Westphal"/>. Link stat ink-state routing for
e routing for
satellite networks has been considered in <xref target="Cao"/> and <xref target= "Zhang"/>.</t> satellite networks has been considered in <xref target="Cao"/> and <xref target= "Zhang"/>.</t>
</section>
</section> <section anchor="terms-and-abbreviations">
<section anchor="terms-and-abbreviations"><name>Terms and Abbreviations</name> <name>Terms and Abbreviations</name>
<dl spacing="normal">
<t><list style="symbols"> <dt>Constellation:</dt><dd>A set of satellites.</dd>
<t>Constellation: A set of satellites.</t> <dt>Downlink:</dt><dd>The half of a ground link leading from a satel
<t>Downlink: The half of a ground link leading from a satellite to an lite to an
Earth station.</t> Earth station.</dd>
<t>Earth station: A node in the network that is on or close to the <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 planetary surface and has a link to a satellite. This includes
ships, aircraft, and other vehicles below LEO. <xref target="ITU"/></t> ships, aircraft, and other vehicles below LEO <xref target="ITU"/>.</dd>
<t>Gateway: An Earth station that participates in the network <dt>Gateway:</dt><dd>An Earth station that participates in the netwo
rk
and acts as the interconnect between satellite constellations and and acts as the interconnect between satellite constellations and
the planetary network. Gateways have a much higher bandwidth than the planetary network. Gateways have a much higher bandwidth than
user stations, have ample computing capabilities, and perform user stations, have ample computing capabilities, and perform
traffic engineering duties, subsuming the functionality of a network traffic engineering duties, subsuming the functionality of a network
controller or Path Computation Element (PCE). <xref target="RFC4655"/> Multiple controller or Path Computation Element (PCE) <xref target="RFC4655"/>. Multiple
gateways are assumed to exist, each serving a portion of the gateways are assumed to exist, and each serves a portion of the
network.</t> network.</dd>
<t>GEO: Geostationary Earth Orbit. A satellite in GEO has an orbit that <dt>GEO:</dt><dd>Geostationary Earth Orbit. A satellite in GEO has a
n orbit that
is synchronized to planetary rotation, so it effectively sits over is synchronized to planetary rotation, so it effectively sits over
one spot on the planet.</t> one spot on the planet.</dd>
<t>Ground link: A link between a satellite and an Earth station, <dt>Ground link:</dt><dd>A link between a satellite and an Earth sta
composed of a Downlink and an Uplink.</t> tion,
<t>IGP: Interior Gateway Protocol. A routing protocol that is used composed of a downlink and an uplink.</dd>
<dt>IGP:</dt><dd>Interior Gateway Protocol. A routing protocol that
is used
within a single administrative domain. Note that 'gateway' in this within a single administrative domain. Note that 'gateway' in this
context is semantically equivalent to 'router' and has no context is semantically equivalent to 'router' and has no
relationship to the 'gateway' used in the rest of this document.</t> relationship to the 'gateway' used in the rest of this document.</dd>
<t>IS-IS: Intermediate System to Intermediate System routing <dt>IS-IS:</dt><dd>Intermediate System to Intermediate System.
protocol. An IGP that is commonly used by service providers. <xref target="ISO10 An IGP that is commonly used by service
589"/> providers <xref target="ISO10589"/> <xref
<xref target="RFC1195"/></t> target="RFC1195"/>.</dd>
<t>ISL: Inter-satellite link. Frequently implemented with free-space <dt>ISL:</dt><dd>Inter-Satellite Link. Frequently implemented with f
ree-space
optics that allow signaling using photons without any intervening optics that allow signaling using photons without any intervening
medium. <xref target="Bell"/></t> medium <xref target="Bell"/>.</dd>
<t>L1: IS-IS Level 1</t> <dt>L1:</dt><dd>IS-IS Level 1</dd>
<t>L1L2: IS-IS Level 1 and Level 2</t> <dt>L1L2:</dt><dd>IS-IS Level 1 and Level 2</dd>
<t>L2: IS-IS Level 2</t> <dt>L2:</dt><dd>IS-IS Level 2</dd>
<t>LEO: Low Earth Orbit. A satellite in LEO has an altitude of 2,000km or less <dt>LEO:</dt><dd>Low Earth Orbit. A satellite in LEO has an altitude
.</t> of 2,000 km or less.</dd>
<t>Local gateway: Each user station is associated with a single gateway <dt>Local gateway:</dt><dd>Each user station is associated with a si
in its region.</t> ngle gateway
<t>LSP: IS-IS Link State Protocol Data Unit. An LSP is a set of packets in its region.</dd>
that describe a node's connectivity to other nodes.</t> <dt>LSP:</dt><dd>Link State Protocol Data Unit. An IS-IS LSP is a se
<t>MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO orbits a t of packets
nd that describe a node's connectivity to other nodes.</dd>
has an altitude between 2,000km and 35,786km.</t> <dt>MEO:</dt><dd>Medium Earth Orbit. A satellite in MEO is between
<t>SID: Segment Identifier <xref target="RFC8402"/></t> LEO and GEO and has an altitude between 2,000 km and 35,786
<t>Stripe: A set of satellites in a few adjacent orbits. These form an km.</dd>
IS-IS L1 area.</t> <dt>SID:</dt><dd>Segment Identifier <xref target="RFC8402"/></dd>
<t>SR: Segment Routing <xref target="RFC8402"/></t> <dt>Stripe:</dt><dd>A set of satellites in a few adjacent
<t>Uplink: The half of a link leading from an Earth station to a orbits. These form an IS-IS L1 area.</dd>
satellite.</t> <dt>SR:</dt><dd>Segment Routing <xref target="RFC8402"/></dd>
<t>User station: An Earth station interconnected with a small end-user <dt>Uplink:</dt><dd>The half of a link leading from an Earth
network.</t> station to a satellite.</dd>
</list></t> <dt>User station:</dt><dd>An Earth station interconnected with a
small end-user network.</dd>
</section> </dl>
</section> </section>
<section anchor="overview"><name>Overview</name> </section>
<section anchor="overview">
<section anchor="topological-considerations"><name>Topological Considerations</n <name>Overview</name>
ame> <section anchor="topological-considerations">
<name>Topological Considerations</name>
<t>Satellites travel in specific orbits around their parent planet. Some of them <t>Satellites travel in specific orbits around their parent planets. Som
e of them
have their orbital periods synchronized to planetary rotation, so they have their orbital periods synchronized to planetary rotation, so they
are effectively stationary over a single point. Other satellites have orbits are effectively stationary over a single point. Other satellites have orbits
that cause them to travel across regions of the planet gradually or quite that cause them to travel across regions of the planet either gradually or quite
rapidly. Respectively, these are typically known as Geostationary Earth Orbits rapidly. Respectively, these are typically known as the Geostationary Earth Orbi
(GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on t
(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 altitude. This discussion is not Earth-specific; as we get to other planets, we
can test this approach's generality.</t> can test this approach's generality.</t>
<t>Satellites may have data interconnections with one another through
<t>Satellites may have data interconnections with one another through
Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may be Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may be
connected temporarily, with periods of potential connectivity computed through connected temporarily with periods of potential connectivity computed through
orbital dynamics. Multiple satellites may be in the same orbit but separated in orbital dynamics. Multiple satellites may be in the same orbit but separated in
space, with a roughly constant separation. Satellites in the same orbit may have space with a roughly constant separation. Satellites in the same orbit may have
ISLs that have a higher duty cycle than ISLs between different orbits but are ISLs that have a higher duty cycle than ISLs between different orbits, but they
are
still not guaranteed to be always connected.</t> still not guaranteed to be always connected.</t>
<figure anchor="network-architecture">
<figure><artwork><![CDATA[ <name>Overall Network Architecture</name>
<artwork><![CDATA[
User +-----------------+ Local User +-----------------+ Local
Stations --- | Satellites |--- Gateway --- Internet Stations --- | Satellites |--- Gateway --- Internet
+-----------------+ +-----------------+
Figure 1: Overall network architecture
]]></artwork></figure> ]]></artwork></figure>
<t>Earth stations can communicate with one or more satellites in their
<t>Earth stations can communicate with one or more satellites in their region. User stations are Earth stations with a limited capacity that
region. User stations are Earth stations with a limited capacity and
communicate with only a single satellite at a time. Other Earth communicate with only a single satellite at a time. Other Earth
stations that may have richer connectivity and higher bandwidth are stations that may have richer connectivity and higher bandwidth are
commonly called gateways and provide connectivity between the commonly called "gateways" and provide connectivity between the
satellite network and conventional wired networks. Gateways serve user satellite network and conventional wired networks. Gateways serve user
stations in their geographic proximity and are replicated globally as stations in their geographic proximity and are replicated globally as
necessary to provide coverage and meet service density goals. User necessary to provide coverage and to meet service density goals. User
stations are associated with a single local gateway. Traffic from one stations are associated with a single local gateway. Traffic from one
Earth station to another may need to traverse a path across multiple Earth station to another may need to traverse a path across multiple
satellites via ISLs.</t> satellites via ISLs.</t>
</section>
</section> <section anchor="link-changes">
<section anchor="link-changes"><name>Link Changes</name> <name>Link Changes</name>
<t>Like conventional network links, ISLs and ground links can fail
<t>Like conventional network links, ISLs and ground links can fail
without warning. However, unlike terrestrial links, there are without warning. However, unlike terrestrial links, there are
predictable times when ISLs and ground links can potentially connect predictable times when ISLs and ground links can potentially connect
and disconnect. These predictions can be computed and cataloged in a and disconnect. These predictions can be computed and cataloged in a
schedule that can be distributed to relevant network schedule that can be distributed to relevant network
elements. Predictions of a link connecting are not guaranteed: a link elements. Predictions of a link connecting are not guaranteed: A link
may not connect for many reasons. Link disconnection predictions due may not connect for many reasons. Link disconnection predictions due
to orbital dynamics are effectively guaranteed, as the underlying to orbital dynamics are effectively guaranteed, as the underlying
physics will not improve unexpectedly.</t> physics will not improve unexpectedly.</t>
</section>
</section> <section anchor="scalability">
<section anchor="scalability"><name>Scalability</name> <name>Scalability</name>
<t>Some proposed satellite networks are fairly large, with tens of thous
<t>Some proposed satellite networks are fairly large, with tens of thousands of ands of
proposed satellites. <xref target="CNN"/> A key concern is the ability to reach proposed satellites <xref target="CNN"/>. A key concern is the ability to reach
this scale this scale
and larger, as useful networks tend to grow.</t> and larger, as useful networks tend to grow.</t>
<t>As we know, the key to scalability is the ability to create
<t>As we know, the key to scalability is the ability to create
hierarchical abstractions, so a key question of any routing hierarchical abstractions, so a key question of any routing
architecture will be about the abstractions that can be created to architecture will be about the abstractions that can be created to
contain topological information.</t> contain topological information.</t>
<t>Normal routing protocols are architected to operate with a static but
<t>Normal routing protocols are architected to operate with a static but somewha somewhat
t
unreliable topology. Satellite networks lack the static organization of unreliable topology. Satellite networks lack the static organization of
terrestrial networks, so normal architectural practices for scalability may not terrestrial networks, so normal architectural practices for scalability may not
apply and alternative approaches may need consideration.</t> apply, and alternative approaches may need consideration.</t>
<t>In a typical deployment of a link-state routing protocol, current
<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 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, routers. A single area would also provide no isolation for topological changes,
causing every link change to be propagated throughout the entire network. This causing every link change to be propagated throughout the entire network. This
would be insufficient for the needs of large satellite networks.</t> would be insufficient for the needs of large satellite networks.</t>
<t>Multiple areas or multiple instances of an Interior Gateway
<t>Multiple areas or multiple instances of an IGP can be used to improve Protocol (IGP) can be used to improve
scalability, but there are limitations to traditional approaches.</t> scalability, but there are limitations to typical approaches.</t>
<t>Currently, the IETF actively supports two link-state IGPs: OSPF <xref
<t>The IETF currently actively supports two link-state Interior Gateway Protocol target="RFC2328"/> <xref target="RFC5340"/> and IS-IS.</t>
s <t>OSPF requires that the network operate around a backbone area, with
(IGPs): OSPF <xref target="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 subsidiary areas hanging off of the backbone. While this works well
for traditional terrestrial networks, this does not seem appropriate for typical terrestrial networks, this does not seem appropriate
for satellite networks, where there is no centralized portion of the for satellite networks, where there is no centralized portion of the
topology.</t> topology.</t>
<t>IS-IS has a different hierarchical structure, where Level 1 (L1) area
<t>IS-IS has a different hierarchical structure, where Level 1 (L1) areas s
are connected sets of nodes, and then Level 2 (L2) is a connected 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 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 nodes can be L1, L2, or both (L1L2). Typical IS-IS designs require that any
node or link that is to be used as transit between L2 areas must appear as part 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 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, 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> negating any scalability benefits from IS-IS's hierarchical structure.</t>
<t>We elaborate on considerations specific to IS-IS in <xref target="sui
<t>We elaborate on IS-IS-specific considerations in <xref target="suitability"/> tability"/>.</t>
.</t> </section>
<section anchor="assumptions">
</section> <name>Assumptions</name>
<section anchor="assumptions"><name>Assumptions</name> <t>In this section, we discuss some of the assumptions that are the basi
s
<t>In this section, we discuss some of the assumptions that are the basis
for this architectural proposal.</t> for this architectural proposal.</t>
<t>The data payload is IP packets.</t>
<t>The data payload is IP packets.</t> <t>Satellites are active participants in the control and data planes for
the
<t>Satellites are active participants in the control and data plane for the network, participating in protocols and forwarding packets.</t>
network, participating in protocols, and forwarding packets.</t> <t>There may be a terrestrial network behind each gateway that may
interconnect to the broader Internet. The architecture of the
<t>There may be a terrestrial network behind each gateway that may terrestrial network is assumed to be a typical IS-IS and BGP
interconnect to the broader Internet. The architecture of the deployment <xref target="RFC4271"/> and is not discussed further in
terrestrial network is assumed to be a typical IS-IS and BGP this document.</t>
<xref target="RFC4271"/> deployment and is not discussed further.</t> <t>The satellite network interconnects user stations and gateways. Inter
connection
<t>The satellite network interconnects user stations and gateways. Interconnecti
on
between the satellite network and the satellite networks of other network between the satellite network and the satellite networks of other network
operators is outside of the scope of this document.</t> operators is outside the scope of this document.</t>
<section anchor="traffic-patterns">
<section anchor="traffic-patterns"><name>Traffic Patterns</name> <name>Traffic Patterns</name>
<t>We assume that the primary use of the satellite network is to provi
<t>We assume that the primary use of the satellite network is to provide de
access from a wide range of geographic locations. We also assume that access from a wide range of geographic locations. We also assume that
providing high-bandwidth bulk transit between peer networks is not a providing high-bandwidth bulk transit between peer networks is not a
goal. It has been noted that satellite networks can provide lower goal. It has been noted that satellite networks can provide lower
latencies than terrestrial fiber networks <xref target="Handley"/>. This proposa l latencies than terrestrial fiber networks in <xref target="Handley"/>. This prop osal
does not preclude such applications but does not articulate the does not preclude such applications but does not articulate the
mechanisms necessary for user stations to perform the appropriate mechanisms necessary for user stations to perform the appropriate
traffic engineering computations. Low-latency, multicast, and anycast traffic engineering computations. Low-latency, multicast, and anycast
applications are not discussed further.</t> applications are not discussed further in this document.</t>
<t>As with most access networks, we assume that there will be
<t>As with most access networks, we assume that there will be bidirectional traffic between the user station and the gateway but
bidirectional traffic between the user station and the gateway, but
that the bulk of the traffic will be from the gateway to the user that the bulk of the traffic will be from the gateway to the user
station. We expect that the uplink from the gateway to the satellite station. We expect the uplink from the gateway to the satellite
network to be the bandwidth bottleneck, and that gateways will need to network to be the bandwidth bottleneck and that gateways will need to
be replicated to scale the uplink bandwidth, as the satellite capacity reachable be replicated to scale the uplink bandwidth, as the satellite capacity reachable
from a gateway will be limited.</t> from a gateway will be limited.</t>
<t>We assume that it is not essential to provide optimal routing for
<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 traffic from user station to user station. If this traffic is sent
to a gateway first and then back into the satellite network, this to a gateway first and then back into the satellite network, it
might be acceptable to some operators as long as the traffic volume might be acceptable to some operators as long as the traffic volume
remains very low. This type of routing is not discussed further.</t> remains very low. This type of routing is not discussed further in this document
.</t>
<t>We assume that traffic for a user station should enter the satellite <t>We assume that traffic for a user station should enter the satellit
e
network through a gateway that is in some close geographic proximity 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 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 path to the user station. Similarly, we assume that user station
traffic should exit the satellite network through the gateway that is traffic should exit the satellite network through the gateway that is
in the closest geographic proximity to the user in the closest geographic proximity to the user
station. Jurisdictional requirements for landing traffic in certain station. Jurisdictional requirements for landing traffic in certain
regions may alter these assumptions, but such situations are outside regions may alter these assumptions, but such situations are outside
of the scope of this document.</t> the scope of this document.</t>
<t>This architecture does not preclude gateway-to-gateway traffic acro
<t>This architecture does not preclude gateway-to-gateway traffic across the ss the
satellite constellations, but it does not seek to optimize it.</t> satellite constellations, but it does not seek to optimize it.</t>
</section>
</section> <section anchor="user-station-constraints">
<section anchor="user-station-contraints"><name>User Station Contraints</name> <name>User Station Constraints</name>
<t>The user station is an entity whose operation is conceptually share
<t>The user station is an entity whose operation is conceptually shared between d between the
the
satellite constellation operator and the operator of the cluster of end stations 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 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 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 its direct satellite and its local gateway via protocols outside the scope of
this document. Equally, it bootstraps communication via an exchange with the this document. Equally, it bootstraps communication via an exchange with the
current local satellite so it can find and communicate with its local gateway, current local satellite so that it can find and communicate with its local gatew ay --
again with the details of how that is done being outside the scope of this again with the details of how that is done being outside the scope of this
document.</t> document.</t>
<t>User stations that can concurrently access multiple satellites are
<t>User stations that can concurrently access multiple satellites are not preclu not precluded
ded by this proposal but are not discussed in detail.</t>
by this proposal, but are not discussed in detail.</t> </section>
<section anchor="stochastic-connectivity">
</section> <name>Stochastic Connectivity</name>
<section anchor="stochastic-connectivity"><name>Stochastic Connectivity</name> <t>We assume that links in general will be available when scheduled. A
s
<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 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 guarantee, but we also expect that the schedule is mostly accurate. We
assume that at any given instant, there are enough working links and assume that at any given instant, there are enough working links and
aggregate bandwidth to run the network and support the traffic aggregate bandwidth to run the network and support the traffic
demand. If this assumption does not hold, no routing architecture demand. If this assumption does not hold, no routing architecture
can magically make the network more capable.</t> can magically make the network more capable.</t>
<t>Satellites that are in the same orbit may be connected by ISLs. The
<t>Satellites that are in the same orbit may be connected by ISLs. These se
are called intra-orbit ISLs. Satellites that are in different orbits are called "intra-orbit" ISLs. Satellites that are in different orbits
may also be connected by ISLs. These are called inter-orbit ISLs. may also be connected by ISLs. These are called "inter-orbit" ISLs. Generally,
We assume that, in general, intra-orbit ISLs have higher reliability we assume that intra-orbit ISLs have higher reliability
and persistence than inter-orbit ISLs.</t> and persistence than inter-orbit ISLs.</t>
<t>We assume that the satellite network is connected (in the graph the
<t>We assume that the satellite network is connected (in the graph theory sense) ory sense)
almost always, even if some links are down. This implies that there is 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 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 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 not require buffering of traffic when a link is down. Instead, traffic should be
rerouted.</t> rerouted.</t>
</section>
</section> </section>
</section> <section anchor="problem-statement">
<section anchor="problem-statement"><name>Problem Statement</name> <name>Problem Statement</name>
<t>The goal of the routing architecture is to provide an
<t>The goal of the routing architecture is to provide an organizational organizational structure to protocols running on the satellite
structure to protocols running on the satellite network such that network. This architecture must convey topology information to
topology information is conveyed through relevant portions of the relevant portions of the network. This enables path computation that
network, that paths are computed across the network, and that data can is used for data forwarding. The architecture must also scale without
be delivered along those paths, and the structure can scale without global changes to the organizational structure.</t>
any changes to the organizational structure.</t> </section>
</section>
</section> <section anchor="forwarding-plane">
</section> <name>Forwarding Plane</name>
<section anchor="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
<t>The end goal of a network is to deliver traffic. In a satellite network where stations frequently change their association with the satellites, having
the topology is in a continual state of flux and the user stations a highly flexible and adaptive forwarding plane is essential. Toward
frequently change their association with the satellites, having a highly this end, we propose using MPLS as the fundamental forwarding plane
flexible and adaptive forwarding plane is essential. Toward this end, we propose architecture <xref target="RFC3031"/>. Specifically, we propose using an
to use MPLS as the fundamental forwarding plane architecture approach based on Segment Routing (SR) <xref target="RFC8402"/> with an
<xref target="RFC3031"/>. Specifically, we propose to use a Segment Routing (SR) MPLS data plane <xref target="RFC8660"/>, where each satellite is
<xref target="RFC8402"/> assigned a node Segment Identifier (SID). This allows the architecture
based approach with an MPLS data plane <xref target="RFC8660"/>, where each sate to support both IPv4 and IPv6 concurrently. A path through the network
llite is can then be expressed as a label stack of node SIDs. IP forwarding is
assigned a node Segment Identifier (SID). This allows the architecture to not used within the internals of the satellite network, although each
support both IPv4 and IPv6 concurrently. A path through the network can then be satellite may be assigned an IP address for management
expressed as a label stack of node SIDs. IP forwarding is not used within the purposes. Existing techniques may be used to limit the size of the SR
internals of the satellite network, although each satellite may be assigned an label stack so that it only contains the significant waypoints along the
IP address for management purposes. Existing techniques may be used to limit the path <xref target="Giorgetti"/>. The label stack operates as a loose
size of the SR label stack so that it only contains the significant waypoints source route through the network. If there is an unexpected topology
along the path <xref target="Giorgetti"/>. The label stack operates as a change in the network, the IGP will compute a new path to the next
loose source route through the network. If there is an unexpected waypoint, allowing packet delivery despite ISL failures. While the IGP
topology change in the network, the IGP will compute a new path to the next is converging, there may be micro-loops in the topology. These can be
waypoint, allowing packet delivery despite ISL failures. While the IGP is avoided by using Topology Independent Loop-Free Alternate (TI-LFA) paths
converging, there may be micro-loops in the topology. These can be avoided <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>; otherwise,
by using TI-LFA alternate paths traffic will loop until discarded based on its TTL.</t>
<xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>, or traffic will loop unt <t>We assume that there is a link-layer mechanism for a user station to
il associate with a satellite. User stations will have an IP address
discarded based on its TTL.</t> assigned from a prefix managed by its local gateway. The mechanisms for
this assignment and its communication to the end station are not
<t>We assume that there is a link-layer mechanism for a user station to discussed herein but might be similar to DHCP <xref
associate with a satellite. User stations will have an IP address target="RFC2131"/>. User station IP addresses change infrequently and do
assigned from a prefix managed by its local gateway. The mechanisms not reflect their association with their first-hop satellite. Gateways
for this assignment and its communication to the end station are not and their supporting terrestrial networks advertise prefixes covering
discussed herein but might be similar to DHCP <xref target="RFC2131"/>. User all its local user stations throughout the global Internet.</t>
station IP addresses change infrequently and do not reflect their <t>User stations may be assigned a node SID, in which case MPLS
association with their first-hop satellite. 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 forwarding can be used for all hops to the user
station. Alternatively, if the user station does not have a node SID, 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 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 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 not require a full longest-prefix-match lookup, as the IP address is
merely a unique identifier at this point.</t> merely a unique identifier at this point.</t>
<t>Similarly, gateways may be assigned a node SID. A possible
<t>Similarly, gateways may be assigned a node SID. A possible optimization is that a single SID value could be assigned as a global
optimization is that a single SID value be assigned as a global
constant to always direct traffic to the topologically closest constant to always direct traffic to the topologically closest
gateway. If traffic engineering is required for traffic that is gateway. If traffic engineering is required for traffic that is
flowing to a gateway, a specific path may be encoded in a label stack 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 that is attached to the packet by the user station or by the first-hop
satellite.</t> satellite.</t>
<t>Gateways can also perform traffic engineering using different paths
<t>Gateways can also perform traffic engineering using different paths
and label stacks for separate traffic flows. Routing a single traffic and label stacks for separate traffic flows. Routing a single traffic
flow across multiple paths has proven to cause performance issues with flow across multiple paths has proven to cause performance issues with
transport protocols, so that approach is not recommended. Traffic engineering is transport protocols, so that approach is not recommended. Traffic engineering is
discussed further in <xref target="trafficEngineering"/>.</t> discussed further in <xref target="trafficEngineering"/>.</t>
</section>
</section> <section anchor="suitability">
<section anchor="suitability"><name>IGP Suitability and Scalability</name> <name>IGP Suitability and Scalability</name>
<t>As discussed in <xref target="scalability"/>, IS-IS is architecturally
<t>As discussed in <xref target="scalability"/>, IS-IS is architecturally the be the best fit for
st fit for satellite networks but does require some novel approaches to achieve the
satellite networks, but does require some novel approaches to achieve the
scalability goals for a satellite network. In particular, we propose that all 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 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> information and then global routing is done based on L2 information.</t>
<t>An interesting property of IS-IS is that it does not require
<t>IS-IS has the interesting property that it does not require interface addresses. This feature is commonly known as "unnumbered
interface addresses. This feature is commonly known as 'unnumbered interfaces". This is particularly helpful in satellite topologies
interfaces'. This is particularly helpful in satellite topologies
because it implies that ISLs may be used flexibly. Sometimes an because it implies that ISLs may be used flexibly. Sometimes an
interface might be used as an L1 link to another satellite and a few interface might be used as an L1 link to another satellite, and a few
orbits later it might be used as an L1L2 link to a completely orbits later, it might be used as an L1L2 link to a completely
different satellite without any reconfiguration or renumbering.</t> different satellite without any reconfiguration or renumbering.</t>
<t>Scalability for IS-IS can be achieved through a proposal
<t>Scalability for IS-IS can be achieved through a proposal known as "Area Proxy" <xref target="RFC9666"/>. With this
known as Area Proxy <xref target="I-D.ietf-lsr-isis-area-proxy"/>. With this
proposal, all nodes in an L1 area combine their information proposal, all nodes in an L1 area combine their information
into a single L2 Link State Protocol Data Unit (LSP). This implies 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 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 number of nodes in the L1 area and the size of the L2 LSDB scales with
the number of L1 areas.</t> the number of L1 areas.</t>
<t>With Area Proxy, topological changes within an L1 area will not be visi
<t>With Area Proxy, topological changes within an L1 area will not be visible to ble to
other areas, so the overhead of link state changes will be greatly reduced.</t> other areas, so the overhead of link-state changes will be greatly reduced.</t>
<t>The Area Proxy proposal also includes the concept of an Area SID. This
<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 is useful because it allows traffic engineering to construct a path
that traverses areas with a minimal number of label stack entries.</t> that traverses areas with a minimal number of label stack entries.</t>
<t>For example, suppose that a network has 1,000 L1 areas, each with
<t>Suppose, for example, that a network has 1,000 L1 areas, each with 1,000 satellites. This would mean that the network supports
1,000 satellites. This would then mean that the network supports 1,000,000 satellites but only requires 1,000 entries in its L1 LSDB
1,000,000 satellites, but only requires 1,000 entries in its L1 LSDB and 1,000 entries in its L2 LSDB, which are easily achievable
and 1,000 entries in its L2 LSDB; numbers that are easily achievable numbers today. The resulting MPLS label table would contain 1,000 node SIDs
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 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 satellite advertises an IP address for management purposes, then the
IP routing table would have 1,000 entries for the L1 management IP routing table would have 1,000 entries for the L1 management
addresses and 1,000 area proxy addresses from L2.</t> addresses and 1,000 area proxy addresses from L2.</t>
<t>In this proposal, IS-IS does not carry IP routes other than those
<t>In this proposal, IS-IS does not carry IP routes other than those
in the satellite topology. In particular, there are no IP in the satellite topology. In particular, there are no IP
routes for user stations or the remainder of the Internet.</t> routes for user stations or the remainder of the Internet.</t>
</section>
</section> <section anchor="stripes-and-areas">
<section anchor="stripes-and-areas"><name>Stripes and Areas</name> <name>Stripes and Areas</name>
<t>A significant problem with any link-state routing protocol is that of
<t>A significant problem with any link state routing protocol is that of
area partition. While there have been many proposals for automatic area partition. While there have been many proposals for automatic
partition repair, none has seen notable production deployment. It partition repair, none has seen notable production deployment. It
seems best to avoid this issue and ensure areas seems best to avoid this issue and ensure areas
have an extremely low probability of partitioning.</t> have an extremely low probability of partitioning.</t>
<t>As discussed above, intra-orbit ISLs are assumed to have higher
<t>As discussed above, intra-orbit ISLs are assumed to have higher
reliability and persistence than inter-orbit ISLs. However, even reliability and persistence than inter-orbit ISLs. However, even
intra-orbit ISLs are not sufficiently reliable to avoid partition intra-orbit ISLs are not sufficiently reliable to avoid partition
issues. Therefore, we propose to group a small number of adjacent issues. Therefore, we propose to group a small number of adjacent
orbits as an IS-IS L1 area, called a stripe. We assume that orbits as an IS-IS L1 area, called a "stripe". We assume that
for any given reliability requirement, there is a small number of for any given reliability requirement, there is a small number of
orbits that can be used to form a stripe that satisfies the orbits that can be used to form a stripe that satisfies the
reliability requirement.</t> reliability requirement.</t>
<t>Stripes are connected to other adjacent stripes using the same ISL
<t>Stripes are connected to other adjacent stripes using the same ISL
mechanism, forming the L2 topology of the network. Each stripe should mechanism, forming the L2 topology of the network. Each stripe should
have multiple L2 connections and never become partitioned from have multiple L2 connections and never become partitioned from
the remainder of the network.</t> the remainder of the network.</t>
<t>By using a stripe as an L1 area, in conjunction with Area Proxy, the
<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 overhead of the architecture is greatly reduced. Each stripe contributes a
single LSP to the L2 LSDB, completely hiding all the details about the single LSP to the L2 LSDB, completely hiding all the details about the
satellites within the stripe. The resulting architecture scales proportionately satellites within the stripe. The resulting architecture scales proportionately
to the number of stripes required, not the number of satellites.</t> to the number of stripes required, not the number of satellites.</t>
<t>Groups of MEO and GEO satellites with interconnecting ISLs can also
<t>Groups of MEO and GEO satellites with interconnecting ISLs can also
form an IS-IS L1L2 area. Satellites that lack intra-constellation ISLs form an IS-IS L1L2 area. Satellites that lack intra-constellation ISLs
are better as independent L2 nodes.</t> are better as independent L2 nodes.</t>
</section>
</section> <section anchor="trafficEngineering">
<section anchor="trafficEngineering"><name>Traffic Forwarding and Traffic Engine <name>Traffic Forwarding and Traffic Engineering</name>
ering</name> <t>The forwarding architecture presented here is straightforward. A path f
rom a
<t>Forwarding in this architecture is straightforward. A path from a
gateway to a user station on the same stripe only requires a single 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 node SID for the satellite that provides the downlink to the user
station.</t> station.</t>
<figure anchor="on-stripe-forwarding">
<figure><artwork><![CDATA[ <name>On-Stripe Forwarding</name>
<artwork><![CDATA[
\ \
Gateway --> X Gateway --> X
\ \
\ \
X X
\ \
\ \
X ---> x User Station X ---> x User Station
\ \
Figure 2: On-stripe forwarding
]]></artwork></figure> ]]></artwork></figure>
<t>Similarly, a user station returning a packet to a gateway need only
<t>Similarly, a user station returning a packet to a gateway need only
provide a gateway node SID.</t> provide a gateway node SID.</t>
<t>For off-stripe forwarding, the situation is a bit more complex. A gatew
<t>For off-stripe forwarding, the situation is a bit more complex. A gateway wou ay would
ld
need to provide the area SID of the final stripe on the path plus the node SID 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 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 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> satellite that provides access to the gateway as well as the gateway SID.</t>
<figure anchor="off-stripe-forwarding">
<figure><artwork><![CDATA[ <name>Off-Stripe Forwarding</name>
<artwork><![CDATA[
Source S Source S
| |
| |
V V
Internet Internet
| |
| |
V \ V \
Gateway L --> X Gateway L --> X
\ \
\ \ \ \
X --- X X --- X
\ \ \ \
\ \ Area A \ \ Area A
X --- X X --- X
\ \ \ \
\ \
U ---> D User Station U ---> D User Station
\ \
Figure 3: Off-stripe forwarding
]]></artwork></figure> ]]></artwork></figure>
<t>As an example (<xref target="off-stripe-forwarding"/>), consider a pack
<t>As an example, consider a packet from an Internet source S to a et from an Internet source (Source S) to a
user station D. A local gateway L has injected a prefix covering D user station (D). A local gateway (Gateway L) has injected a prefix covering D
into BGP and advertised it globally. The packet is forwarded to L into BGP and has advertised it globally. The packet is forwarded to L
using IP forwarding. When L receives the packet, it performs a using IP forwarding. When L receives the packet, it performs a
lookup in a pre-computed forwarding table. This contains a SID list lookup in a pre-computed forwarding table. This contains a SID list
for the user station that has already been converted into a label for the user station that has already been converted into a label
stack. Suppose the user station is currently associated with a stack. Suppose the user station is currently associated with a
different stripe so that the label stack will contain an area label A different stripe so that the label stack will contain an area label (A)
and a label U for the satellite associated with the user station, and a label (U) for the satellite associated with the user station,
resulting in a label stack (A, U).</t> resulting in a label stack (A, U).</t>
<t>The local gateway forwards this into the satellite network. The first-h
<t>The local gateway forwards this into the satellite network. The first-hop op
satellite now forwards based on the area label A at the top of the stack. All satellite now 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 forwarding continues area labels are propagated as part of the L2 topology. This forwarding continues
until the packet reaches a satellite adjacent to the destination until the packet reaches a satellite adjacent to the destination
area. That satellite pops label A, removing that label and forwarding the packet area. That satellite pops label A, removing that label and forwarding the packet
into the destination area.</t> into the destination area.</t>
<t>The packet is now forwarded based on the remaining label U, which was
<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 propagated as part of the L1 topology. The last satellite forwards the
packet based on the destination address D and forwards the packet to packet based on the destination address (D) and forwards the packet to
the user station.</t> the user station.</t>
<t>The return case is similar. The label stack, in this case, consists of
<t>The return case is similar. The label stack, in this case, consists of a labe a label
l for the local gateway's stripe/area (A') and the label for the local gateway (L)
for the local gateway's stripe/area, A', and the label for the local gateway, L, ,
resulting in the stack (A', L). The forwarding mechanisms are similar to the resulting in the stack (A', L). The forwarding mechanisms are similar to the
previous case.</t> previous case.</t>
<t>Very frequently, access networks congest due to over-subscription and
<t>Very frequently, access networks congest due to oversubscription and
the economics of access. Network operators can use traffic engineering the economics of access. Network operators can use traffic engineering
to ensure that they get higher efficiency out of their to ensure that they get higher efficiency out of their
networks by utilizing all available paths and capacity near any networks by utilizing all available paths and capacity near any
congestion points. In this particular case, the gateway will have congestion points. In this particular case, the gateway will have
information about all of the traffic it is generating and can use information about all of the traffic it is generating and can use
all of the possible paths through the network in its topological all of the possible paths through the network in its topological
neighborhood. Since we're already using SR, this is easily done just neighborhood. Since we're already using SR, this is easily done
by adding more explicit SIDs to the label stack. These can be by adding more explicit SIDs to the label stack. These can be
additional area SIDs, node SIDs, or adjacency SIDs. Path computation additional area SIDs, node SIDs, or adjacency SIDs. Path computation
can be performed by Path Computation Elements (PCE) <xref target="RFC4655"/>.</t can be performed by Path Computation Elements (PCEs) <xref target="RFC4655"/>.</
> t>
<t>Each gateway or its PCE will need topological information from the
<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 areas it will route through. It can do this by participating in the
IGP directly, via a tunnel, or another delivery mechanism such 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> 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
<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 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 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 can be computed by the gateway or PCE and then distributed to the
first-hop satellite or user station, which would apply them to first-hop satellite or user station, which would apply them to
traffic. The delivery mechanism is outside of the scope of this traffic. The delivery mechanism is outside the scope of this
document.</t> document.</t>
</section>
</section> <section anchor="scheduling">
<section anchor="scheduling"><name>Scheduling</name> <name>Scheduling</name>
<t>The most significant difference between terrestrial and satellite
<t>The most significant difference between terrestrial and satellite
networks from a routing perspective is that some of the topological networks from a routing perspective is that some of the topological
changes that will happen to the network can be anticipated and changes that will happen to the network can be anticipated and
computed. Both link and node changes will affect the topology and the computed. Both link and node changes will affect the topology, and the
network should react smoothly and predictably.</t> network should react smoothly and predictably.</t>
<t>The management plane is responsible for providing information about
<t>The management plane is responsible for providing information about
scheduled topological changes. The exact details of how the scheduled topological changes. The exact details of how the
information is disseminated are outside of the scope of this document information is disseminated are outside the scope of this document
but could be done through a YANG model but could be shown through a YANG model
<xref target="I-D.ietf-tvr-schedule-yang"/>. Scheduling information needs to be <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 accessible to all of the nodes that will make routing decisions based
on the topological changes in the schedule, so data about an L1 on the topological changes in the schedule (i.e., data about an L1
topological change will need to be circulated to all nodes in the 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 area and information about L2 changes will need to propagate to all
L2 nodes, plus the gateways and PCEs that carry the related L2 nodes) and to the gateways and PCEs that carry the related
topological information.</t> topological information.</t>
<t>There is very little that the network should do in response to a
<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 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 should not have any functional change until the change is proven to be
fully operational based on the usual IS-IS liveness mechanisms. Nodes fully operational based on the usual IS-IS liveness mechanisms. Nodes
may pre-compute their routing table changes but should not install may pre-compute their routing table changes but should not install
them before all relevant adjacencies are received. The benefits of them before all relevant adjacencies are received. The benefits of
this pre-computation appear to be very small. Gateways and PCEs may this pre-computation appear to be very small. Gateways and PCEs may
also choose to pre-compute paths based on these changes, but should also choose to pre-compute paths based on these changes but should
not install paths using the new parts of the topology until they are not install paths using the new parts of the topology until they are
confirmed to be operational. If some path pre-installation is confirmed to be operational. If some path pre-installation is
performed, gateways and PCEs must be prepared for the situation where performed, gateways and PCEs must be prepared for the situation where
the topology fails to become operational and may need to take the topology fails to become operational and may need to take
alternate steps instead, such as reverting any related pre-installed alternate steps instead, such as reverting any related pre-installed
paths.</t> paths.</t>
<t>The network may choose not to pre-install or
<t>The network may choose not to pre-install or
pre-compute routes in reaction to topological additions, at a small pre-compute routes in reaction to topological additions, at a small
cost of some operational efficiency.</t> cost of some operational efficiency.</t>
<t>Topological deletions are an entirely different matter. If a link or
<t>Topological deletions are an entirely different matter. If a link or
node is to be removed from the topology, the network should act node is to be removed from the topology, the network should act
before the anticipated change to route traffic around the expected before the anticipated change to route traffic around the expected
topological loss. Specifically, at some point before the topology topological loss. Specifically, at some point before the topology
change, the affected links should be set to a high metric to direct change, the affected links should be set to a high metric to direct
traffic to alternate paths. This is a common operational procedure in traffic to alternate paths. This is a common operational procedure in
existing networks when links are taken out of service, such as when existing networks when links are taken out of service, such as when
proactive maintenance needs to be performed. This type of change does proactive maintenance needs to be performed. This type of change does
require some time to propagate through the network, so the metric require some time to propagate through the network, so the metric
change should be initiated far enough in advance that the network change should be initiated far enough in advance that the network
converges before the actual topological change. Gateways and PCEs converges before the actual topological change. Gateways and PCEs
should also update paths around the topology change and install these should also update paths around the topology change and install these
changes before the topology change occurs. The time necessary for changes before the topology change occurs. The time necessary for
both IGP and path changes will vary depending on the exact network and both IGP and path changes will vary depending on the exact network and
configuration.</t> configuration.</t>
<t>Strictly speaking, changing to a high metric should not be necessary. I
<t>Strictly speaking, changing to a high metric should not be necessary. It shou t should
ld
be possible for each router to exclude the link and recompute 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 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 for indicating a topology change, as this can help avoid issues with incomplete
information dissemination and synchronization.</t> information dissemination and synchronization.</t>
</section>
</section> <section anchor="future-work">
<section anchor="future-work"><name>Future Work</name> <name>Future Work</name>
<t>This architecture needs to be validated by satellite operators, both
<t>This architecture needs to be validated by satellite operators, both
via simulation and operational deployment. Meaningful simulation via simulation and operational deployment. Meaningful simulation
hinges on the exact statistics of ISL connectivity, and that hinges on the exact statistics of ISL connectivity; currently, that
information is not publicly available currently.</t> information is not publicly available.</t>
<t>Current available information about ISLs indicates that links are
<t>Current available information about ISLs indicates that links are
mechanically steered and will need to track the opposite end of the mechanically steered and will need to track the opposite end of the
link continually. The angles and distances that can be practically link continually. The angles and distances that can be practically
supported are unknown, as are any limitations about the rate of supported are unknown, as are any limitations about the rate of
change.</t> change.</t>
<t>It is expected that intra-orbit and inter-orbit ISL links will have
<t>It is expected that intra-orbit and inter-orbit ISL links will have
very different properties. Intra-orbit links should be much more very different properties. Intra-orbit links should be much more
stable, but still far less stable than terrestrial links. Inter-orbit stable but still far less stable than terrestrial links. Inter-orbit
links will be less stable. Links between satellites that are roughly links will be less stable. Links between satellites that are roughly
parallel should be possible, but will likely have a limited parallel should be possible but will likely have a limited
duration. Two orbits may be roughly orthogonal, resulting in a limited duration. Two orbits may be roughly orthogonal, resulting in a limited
potential for connectivity. Finally, in some topologies there may be potential for connectivity. Finally, in some topologies there may be
parallel orbits where the satellites move in opposite directions, parallel orbits where the satellites move in opposite directions,
giving a relative speed between satellites around 34,000mph giving a relative speed between satellites around 34,000 mph
(55,000kph). Links in this situation may not be possible or may be so (55,000 kph). Links in this situation may not be possible or may be so
short-lived as to be impractical.</t> short-lived that they are impractical.</t>
<t>The key question to address is whether the parameters of a given
<t>The key question to address is whether the parameters of a given
network can yield a stripe assignment that produces stable, connected network can yield a stripe assignment that produces stable, connected
areas that work within the scaling bounds of the IGP. If links are 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 very stable, a stripe could be just a few parallel orbits, with
only a few hundred satellites. However, if links are unstable, only a few hundred satellites. However, if links are unstable,
a stripe might have to encompass dozens of orbits and thousands a stripe might have to encompass dozens of orbits and thousands
of satellites, which might be beyond the scaling limitations of a of satellites, which might be beyond the scaling limitations of a
given IGP's implementation.</t> given IGP's implementation.</t>
</section>
</section> <section anchor="deployment-considerations">
<section anchor="deployment-considerations"><name>Deployment Considerations</nam <name>Deployment Considerations</name>
e> <t>The network behind a gateway is expected to be a normal terrestrial
<t>The network behind a gateway is expected to be a normal terrestrial
network. Conventional routing architectural principles apply. An obvious network. Conventional routing architectural principles apply. An obvious
approach would be to extend IS-IS to the terrestrial network, applying L1 areas approach would be to extend IS-IS to the terrestrial network, applying L1 areas
as necessary for scalability.</t> as necessary for scalability.</t>
<t>The terrestrial network may have one or more BGP connections to the
<t>The terrestrial network may have one or more BGP connections to the
broader Internet. Prefixes for user stations should be advertised to broader Internet. Prefixes for user stations should be advertised to
the Internet near the associated gateway. If gateways are not the Internet near the associated gateway. If gateways are not
interconnected by the terrestrial network, then it may be advisable to interconnected by the terrestrial network, then it may be advisable to
use one autonomous system per gateway as it might simplify the use one autonomous system per gateway as it might simplify the
external perception of the network and subsequent policy external perception of the network and subsequent policy
considerations. Otherwise, one autonomous system may be used for the considerations. Otherwise, one autonomous system may be used for the
entire terrestrial network.</t> entire terrestrial network.</t>
</section>
</section> <section anchor="security-considerations">
<section anchor="security-considerations"><name>Security Considerations</name> <name>Security Considerations</name>
<t>This document discusses one possible routing architecture for
<t>This document discusses one possible routing architecture for
satellite networks. It proposes no new protocols or mechanisms and satellite networks. It proposes no new protocols or mechanisms and
thus has no new security impact. Security for IS-IS is provided by thus has no new security impact. Security for IS-IS is provided by
<xref target="RFC5304"/> and <xref target="RFC5310"/>.</t> <xref target="RFC5304"/> and <xref target="RFC5310"/>.</t>
<t>User stations will interact directly with satellites, potentially
<t>User stations will interact directly with satellites, potentially
using proprietary mechanisms, and under the control of the satellite using proprietary mechanisms, and under the control of the satellite
operator who is responsible for the security of the user station.</t> operator, who is responsible for the security of the user station.</t>
</section>
</section> <section anchor="iana-considerations">
<section anchor="acknowledgements"><name>Acknowledgements</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<t>The author would like to thank Dino Farinacci, Olivier De jonckere, <back>
Eliot Lear, Adrian Farrel, Acee Lindem, Erik Kline, Sue Hares, Joel <displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-L
Halpern, Marc Blanchet, and Dean Bogdanovic for their comments.</t> FA"/>
<displayreference target="I-D.ietf-tvr-schedule-yang" to="YANG-SCHEDULE"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<section anchor="iana-considerations"><name>IANA Considerations</name> 666.xml"/>
<t>This document makes no requests for IANA.</t> <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>
<seriesInfo name="ISO/IEC" value="10589:2002"/>
</reference>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
304.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
</references>
<references>
<name>Informative References</name>
</middle> <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 Be
ll">
<organization/>
</author>
<date year="1880" month="October"/>
</front>
<refcontent>American Journal of Science, vol. S3-20, no. 118, pp. 305-
324</refcontent>
<seriesInfo name="DOI" value="10.2475/ajs.s3-20.118.305"/>
</reference>
<back> <reference anchor="Cao" target="https://www.mdpi.com/1424-8220/22/12/455
2/pdf?version=1655449925">
<front>
<title>Dynamic Routings in Satellite Networks: An Overview</title>
<author initials="X." surname="Cao">
<organization/>
</author>
<author initials="Y." surname="Li">
<organization/>
</author>
<author initials="X." surname="Xiong">
<organization/>
</author>
<author initials="J." surname="Wang">
<organization/>
</author>
<date year="2022"/>
</front>
<refcontent>Sensors, vol. 22, no. 12, pp. 4552</refcontent>
<seriesInfo name="DOI" value="10.3390/s22124552"/>
</reference>
<references title='Normative References'> <reference anchor="CNN" target="https://www.cnn.com/2021/02/11/tech/spac
ex-starlink-satellites-1000-scn/index.html">
<front>
<title>Elon Musk's SpaceX now owns about a third of all active satel
lites in the sky</title>
<author initials="J." surname="Wattles">
<organization/>
</author>
<date day="11" year="2021" month="February"/>
</front>
<refcontent>CNN Business</refcontent>
</reference>
&I-D.ietf-lsr-isis-area-proxy; <reference anchor="Giorgetti" target="https://ieeexplore.ieee.org/docume
<reference anchor="ISO10589" > nt/7417097">
<front> <front>
<title>Intermediate System to Intermediate System Intra-Domain Routing Excha <title>Path Encoding in Segment Routing</title>
nge Protocol for use in Conjunction with the Protocol for Providing the Connecti <author initials="A." surname="Giorgetti">
onless-mode Network Service (ISO 8473)</title> <organization/>
<author > </author>
<organization>International Organization for Standardization</organization <author initials="P." surname="Castoldi">
> <organization/>
</author> </author>
<date year="2002" month="November"/> <author initials="F." surname="Cugini">
</front> <organization/>
<seriesInfo name="ISO/IEC 10589:2002" value=""/> </author>
<format type="pdf" target="https://standards.iso.org/ittf/PubliclyAvailableSta <author initials="J." surname="Nijhof">
ndards/c030932_ISO_IEC_10589_2002(E).zip"/> <organization/>
</reference> </author>
&RFC3031; <author initials="F." surname="Lazzeri">
&RFC5304; <organization/>
&RFC5310; </author>
&RFC8402; <author initials="G." surname="Bruno">
&RFC8660; <organization/>
</author>
<date year="2015" month="December"/>
</front>
<refcontent>2015 IEEE Global Communications Conference (GLOBECOM)</ref
content>
<seriesInfo name="DOI" value="10.1109/GLOCOM.2015.7417097"/>
</reference>
</references> <reference anchor="Handley" target="https://dl.acm.org/doi/10.1145/32860
62.3286075#">
<front>
<title>Delay is Not an Option: Low Latency Routing in Space</title>
<author initials="M." surname="Handley" fullname="Mark Handley">
<organization/>
</author>
<date year="2018" month="November"/>
</front>
<refcontent>HotNets '18: Proceedings of the 17th ACM Workshop on Hot T
opics in Networks, pp. 85-91</refcontent>
<seriesInfo name="DOI" value="10.1145/3286062.3286075"/>
</reference>
<references title='Informative References'> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-rtgwg-segment-routing-ti-lfa.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-tvr-schedule-yang.xml"/>
<reference anchor="Bell" > <reference anchor="ITU" target="https://search.itu.int/history/HistoryDi
<front> gitalCollectionDocLibrary/1.49.48.en.101.pdf#search=radio%20regulation">
<title>On the Production and Reproduction of Sound by Light</title> <front>
<author initials="A. G." surname="Bell" fullname="Alexander Grahm Bell"> <title>Radio Regulations - Articles</title>
<organization></organization> <author>
</author> <organization>ITU</organization>
<date year="1880" month="October"/> </author>
</front> <date year="2024"/>
<seriesInfo name="American Journal of Science" value="Third Series. XX (118): </front>
305-324."/> </reference>
<seriesInfo name="DOI" value="10.2475/ajs.s3-20.118.305"/>
<format type="pdf" target="https://zenodo.org/records/1450056"/>
</reference>
<reference anchor="Cao" >
<front>
<title>Dynamic Routings in Satellite Networks: An Overview</title>
<author initials="X." surname="Cao">
<organization></organization>
</author>
<author initials="Y." surname="Li">
<organization></organization>
</author>
<author initials="X." surname="Xiong">
<organization></organization>
</author>
<author initials="J." surname="Wang">
<organization></organization>
</author>
<date year="2022"/>
</front>
<seriesInfo name="Sensors" value="(Basel, Switzerland), 22(12)"/>
<seriesInfo name="DOI" value="10.3390/s22124552"/>
<format type="pdf" target="https://www.mdpi.com/1424-8220/22/12/4552/pdf?versi
on=1655449925"/>
</reference>
<reference anchor="CNN" target="https://www.cnn.com/2021/02/11/tech/spacex-starl
ink-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>
</author>
<date year="2021" month="February"/>
</front>
</reference>
<reference anchor="Giorgetti" >
<front>
<title>Path Encoding in Segment Routing</title>
<author initials="A." surname="Giorgetti">
<organization></organization>
</author>
<author initials="P." surname="Castoldi">
<organization></organization>
</author>
<author initials="F." surname="Cugini">
<organization></organization>
</author>
<author initials="J." surname="Nijhof">
<organization></organization>
</author>
<author initials="F." surname="Lazzeri">
<organization></organization>
</author>
<author initials="G." surname="Bruno">
<organization></organization>
</author>
<date year="2015" month="December"/>
</front>
<seriesInfo name="IEEE" value="2015 IEEE Global Communications Conference (GLO
BECOM)"/>
<seriesInfo name="DOI" value="10.1109/GLOCOM.2015.7417097"/>
</reference>
<reference anchor="Handley" >
<front>
<title>Delay is Not an Option: Low Latency Routing in Space</title>
<author initials="M." surname="Handley" fullname="Mark Handley">
<organization></organization>
</author>
<date year="2018" month="November"/>
</front>
<seriesInfo name="ACM" value="Proceedings of the 17th ACM Workshop on Hot Topi
cs in Networks"/>
<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;
<reference anchor="ITU" >
<front>
<title>ITU Radio Regulations, Article 1</title>
<author >
<organization></organization>
</author>
<date year="2016"/>
</front>
<format type="pdf" target="https://search.itu.int/history/HistoryDigitalCollec
tionDocLibrary/1.43.48.en.101.pdf"/>
</reference>
&RFC1195;
&RFC2131;
&RFC2328;
&RFC4271;
&RFC4655;
&RFC5340;
&RFC9552;
<reference anchor="Westphal" >
<front>
<title>LEO Satellite Networking Relaunched: Survey and Current Research Chal
lenges</title>
<author initials="C." surname="Westphal" fullname="Cedric Westphal">
<organization></organization>
</author>
<author initials="L." surname="Han" fullname="Lin Han">
<organization></organization>
</author>
<author initials="R." surname="Li" fullname="Richard Li">
<organization></organization>
</author>
<date year="2023" month="October"/>
</front>
<format type="pdf" target="https://arxiv.org/pdf/2310.07646.pdf"/>
</reference>
<reference anchor="Zhang" >
<front>
<title>ASER: Scalable Distributed Routing Protocol for LEO Satellite Network
s</title>
<author initials="X." surname="Zhang">
<organization></organization>
</author>
<author initials="Y." surname="Yang">
<organization></organization>
</author>
<author initials="M." surname="Xu">
<organization></organization>
</author>
<author initials="J." surname="Luo">
<organization></organization>
</author>
<date year="2021"/>
</front>
<seriesInfo name="IEEE" value="46th Conference on Local Computer Networks (LCN
), Edmonton, AB, Canada, 2021,"/>
<seriesInfo name="DOI" value="10.1109/LCN52139.2021.9524989"/>
</reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
131.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
</back> <reference anchor="Westphal" target="https://arxiv.org/pdf/2310.07646.pd
f">
<front>
<title>LEO Satellite Networking Relaunched: Survey and Current Resea
rch Challenges</title>
<author initials="C." surname="Westphal" fullname="Cedric Westphal">
<organization/>
</author>
<author initials="L." surname="Han" fullname="Lin Han">
<organization/>
</author>
<author initials="R." surname="Li" fullname="Richard Li">
<organization/>
</author>
<date year="2023" month="October"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.2310.07646"/>
<refcontent>arXiv:2310.07546v1</refcontent>
</reference>
<!-- ##markdown-source: <reference anchor="Zhang">
H4sIAIv10WYAA+V9a3Pbxpbg9/4VKOeD7R2Skmj5pamdXcWSHd+VY5XlTHK3 <front>
btUtkGiKHYMABw2IZnx9f/ucZ3cDhOzMftnaWlUllkigH6fP+9XT6dQs68JV <title>ASER: Scalable Distributed Routing Protocol for LEO Satellite
t2dZ166mL0zr2tKeZefZh7pr4fPsvFmuXWuXbdfYbFU32U3e2rKEj7Kfbbur Networks</title>
m0/e5ItFY+/Owju9x7wp6mWVb2DUoslX7bR00xwGnfq8nR6/NDuYW0bKfoX/ <author initials="X." surname="Zhang">
4QBvmrrbmiUMcVs3+7PMVava+G6xcd67umr3Wxjt7eXH18Ztm7OsbTrfzo+P <organization/>
Xx7Pjcm7dl03ZybLpvAf/bjKn2UfZ9mV0094PR/rap98WDewlL90ldvaJm5O </author>
vrSb3JUwFbwyK93/lH+Nqepmk7fuzuKMb6cXM2cBkKVvps47Dzu1+XTb1J/3 <author initials="Y." surname="Yang">
9P3N+5Pjpy9entGoAuu3VWubjS0cbDe72fvWbmCasY91LfgDXzf59KKGZVUB <organization/>
8Jefl+u8urXZdVO39bIu6Sg6bwEE2au6+r2rli0AMB1o59p11q4H78Afdw4R </author>
g76CVytLb5bW++mmLsLpp0Pd2ObOLW32CPaZvTh9/uQxfRtPJECZNlflOGJe <author initials="M." surname="Xu">
Zu+b27xyf9CfjDxtXhV5U8hn9GYBcABMqe9mGRz1nD7ztnHWI3acIWyP3l6+ <organization/>
yhjA4ZEVnY9Ovi1WZ9mDddtu/dnRkZdp/Mz5egYLO3Jtuzq67halW5b78zs4 </author>
8nxRWl2OP1oePzl++WT+d5js7zDZ32myv+Nkjy4fz/5w2wcw0YfXr54cPzk5 <author initials="J." surname="Luo">
41+fPjk+Db+eHMuvL06P5/rrs2fwKW4iwaQfgXh6WPK+0kMqOjqJDNaUfbDb <organization/>
+EG9ym7qDj5dIFbfrtsR6AeaYKI4n2VvZjRZ+JxJ47y0n2ECIIQ3Tb7exEf4 </author>
GN4v21l28uLF8fAYZJgH5xv4bJlX2V/qrsEzxsUtna2W9kEGR/Bx7ZoCEQZe <date year="2021"/>
nGW//ZY9Ojl58fgse3L8dPpkfjp7IANdvH97Bkc6m58+f3qU/+5n/sl0fjyD </front>
h2fw6HdP+A9b1QUfbWOXNR7hyenT4+Onz3CCV3ndg/GDiz3s3i2VnjySzSG/ <refcontent>2021 IEEE 46th Conference on Local Computer Networks (LCN)
A+hU2fs7RHa7e/B9IP82w5nGv/trwpUOX/sNjvV2/Nu/zLJfc/mSz2R+PD+g </refcontent>
CqOEWfm6gbce/Zh7W06yG6D6P2xTwhE/nmTz+aOT+eMBxJ88eXl85Ofzk/np <seriesInfo name="DOI" value="10.1109/LCN52139.2021.9524989"/>
06ffp6XdbjfbFFs3W9YbgPH8dPpiPj8+ms+PTuZHOMIRPP8/AGjIwP/7ybOn </reference>
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==
</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>
</rfc> </rfc>
 End of changes. 133 change blocks. 
932 lines changed or deleted 584 lines changed or added

This html diff was produced by rfcdiff 1.48.