draft-li-arch-sat-06.txt | draft-li-arch-sat-07.txt | |||
---|---|---|---|---|
Network Working Group T. Li | Network Working Group T. Li | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Intended status: Informational 21 February 2024 | Intended status: Informational 3 July 2024 | |||
Expires: 24 August 2024 | Expires: 4 January 2025 | |||
A Routing Architecture for Satellite Networks | A Routing Architecture for Satellite Networks | |||
draft-li-arch-sat-06 | draft-li-arch-sat-07 | |||
Abstract | Abstract | |||
Satellite networks present some interesting challenges for packet | 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 | |||
that are far less reliable than what is common in terrestrial | far less reliable than what is common in terrestrial networks. Some | |||
networks. Some changes to link connectivity can be anticipated due | changes to link connectivity can be anticipated due to orbital | |||
to orbital mechanics. | mechanics. | |||
This document proposes a scalable routing architecture for satellite | This document proposes a scalable routing architecture for satellite | |||
networks based on existing routing protocols and mechanisms, enhanced | networks based on existing routing protocols and mechanisms, enhanced | |||
with scheduled link connectivity change information. This document | with scheduled link connectivity change information. This document | |||
proposes no protocol changes. | proposes no protocol changes. | |||
This document presents the author's view and is neither the product | This document presents the author's view and is neither the product | |||
of the IETF nor a consensus view of the community. | of the IETF nor a consensus view of the community. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 24 August 2024. | This Internet-Draft will expire on 4 January 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 26 ¶ | skipping to change at page 2, line 26 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 | 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 | |||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Topological Considerations . . . . . . . . . . . . . . . 5 | 2.1. Topological Considerations . . . . . . . . . . . . . . . 5 | |||
2.2. Link Changes . . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Link Changes . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4.1. Traffic Patterns . . . . . . . . . . . . . . . . . . 7 | 2.4.1. Traffic Patterns . . . . . . . . . . . . . . . . . . 7 | |||
2.4.2. User Station Contraints . . . . . . . . . . . . . . . 8 | 2.4.2. User Station Contraints . . . . . . . . . . . . . . . 8 | |||
2.4.3. Stochastic Connectivity . . . . . . . . . . . . . . . 8 | 2.4.3. Stochastic Connectivity . . . . . . . . . . . . . . . 9 | |||
2.5. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 | 2.5. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 | |||
3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. IGP Suitability and Scalability . . . . . . . . . . . . . . . 10 | 4. IGP Suitability and Scalability . . . . . . . . . . . . . . . 11 | |||
5. Stripes and Areas . . . . . . . . . . . . . . . . . . . . . . 11 | 5. Stripes and Areas . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. Traffic Forwarding and Traffic Engineering . . . . . . . . . 12 | 6. Traffic Forwarding and Traffic Engineering . . . . . . . . . 12 | |||
7. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 | 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 18 | 13.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
1. Introduction | 1. Introduction | |||
Satellite networks present some interesting challenges for packet | 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 | |||
that are far less reliable than what is common in terrestrial | far less reliable than what is common in terrestrial networks. Some | |||
networks. Some changes to link connectivity can be anticipated due | changes to link connectivity can be anticipated due to orbital | |||
to orbital mechanics. | mechanics. | |||
This document proposes a scalable routing architecture for satellite | This document proposes a scalable routing architecture for satellite | |||
networks based on existing routing protocols and mechanisms, enhanced | networks based on existing routing protocols and mechanisms, enhanced | |||
with scheduled link connectivity change information. This document | with scheduled link connectivity change information. This document | |||
proposes no protocol changes. | proposes no protocol changes. | |||
Large-scale satellite networks are being deployed, presenting an | 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 coupled with the extreme scale | rate of intentional topological change and the extreme scale are | |||
are unprecedented in terrestrial networking. Links between | unprecedented in terrestrial networking. Links between satellites | |||
satellites can utilize free-space optics technology that allows | can utilize free-space optics technology that allows liberal | |||
liberal connectivity, but there are limitations due to the range of | connectivity. Still, there are limitations due to the range of the | |||
the links and conjunction with the sun, resulting in links that are | links and conjunction with the sun, resulting in links that are far | |||
far less reliable than network designers are used to. In addition, | less reliable than network designers are used to. In addition, links | |||
links can change their endpoints dynamically, resulting in structural | can change their endpoints dynamically, resulting in structural | |||
changes to the topology. | changes to the topology. | |||
Current satellite networks are proprietary and little information is | ||||
generally available for analysis and discussion. This document is | ||||
based on what is currently accessible. | ||||
This document proposes one approach to provide a routing architecture | This document proposes one approach to provide a routing architecture | |||
for such networks utilizing current routing technology and providing | for such networks utilizing current standards-based routing | |||
a solution for the scalability of the network while incorporating the | technology and providing a solution for the scalability of the | |||
rapid rate of topological change. | network while incorporating the rapid rate of topological change. | |||
This document intends to provide some initial guidance for satellite | ||||
network operators, but without specific details, this document can | ||||
only provide the basis for a more complete analysis and design. | ||||
This document presents the author's view and is neither the product | This document presents the author's view and is neither the product | |||
of the IETF nor a consensus view of the community. | of the IETF nor a consensus view of the community. | |||
1.1. Related Work | 1.1. Related Work | |||
A survey of related work can be found in [Westphal]. Link state | A survey of related work can be found in [Westphal]. Link state | |||
routing for satellite networks has been considered in [Cao] and | routing for satellite networks has been considered in [Cao] and | |||
[Zhang]. | [Zhang]. | |||
1.2. Terms and Abbreviations | 1.2. Terms and Abbreviations | |||
* Constellation: A set of satellites. | * Constellation: A set of satellites. | |||
* Downlink: The half of a ground link leading from a satellite to an | * Downlink: The half of a ground link leading from a satellite to an | |||
Earth station. | Earth station. | |||
* Gateway: An Earth station that participates as part of the network | * Gateway: An Earth station that participates in the network and | |||
and acts as the interconnect between satellite constellations and | acts as the interconnect between satellite constellations and the | |||
the planetary network. Gateways have a much higher bandwidth than | 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 | traffic engineering duties, subsuming the functionality of a | |||
network controller or Path Computation Element (PCE). [RFC4655] | network controller or Path Computation Element (PCE). [RFC4655] | |||
Multiple gateways are assumed to exist, with each serving a | Multiple gateways are assumed to exist, each serving a portion of | |||
portion of the network. | the network. | |||
* GEO: Geostationary Earth Orbit. A satellite in GEO has an orbit | * GEO: Geostationary Earth Orbit. A satellite in GEO has an orbit | |||
that is synchronized to planetary rotation, so it effectively sits | that is synchronized to planetary rotation, so it effectively sits | |||
over one spot on the planet. | over one spot on the planet. | |||
* Ground link: A link between a satellite and an Earth station. | * Ground link: A link between a satellite and an Earth station. | |||
* Earth station: A node in the network that is on or close to the | * Earth station: A node in the network that is on or close to the | |||
surface of the planet and has a link to a satellite. This | planetary surface and has a link to a satellite. This includes | |||
includes ships, aircraft, and other vehicles below LEO. [ITU] | ships, aircraft, and other vehicles below LEO. [ITU] | |||
* IGP: Interior Gateway Protocol. A routing protocol that is used | * IGP: Interior Gateway Protocol. A routing protocol that is used | |||
within a single administrative domain. Note that 'gateway' in | within a single administrative domain. Note that 'gateway' in | |||
this context is semantically equivalent to 'router' and has no | this context is semantically equivalent to 'router' and has no | |||
relationship to the 'gateway' used in the rest of this document. | relationship to the 'gateway' used in the rest of this document. | |||
* IS-IS: Intermediate System to Intermediate System routing | * IS-IS: Intermediate System to Intermediate System routing | |||
protocol. An IGP that is commonly used by service providers. | protocol. An IGP that is commonly used by service providers. | |||
[ISO10589] [RFC1195] | [ISO10589] [RFC1195] | |||
skipping to change at page 4, line 47 ¶ | skipping to change at page 5, line 4 ¶ | |||
* Local gateway: Each user station is associated with a single | * Local gateway: Each user station is associated with a single | |||
gateway in its region. | gateway in its region. | |||
* LSP: IS-IS Link State Protocol Data Unit. An LSP is a set of | * LSP: IS-IS Link State Protocol Data Unit. An LSP is a set of | |||
packets that describe a node's connectivity to other nodes. | packets that describe a node's connectivity to other nodes. | |||
* MEO: Medium Earth Orbit. A satellite in MEO is between LEO and | * MEO: Medium Earth Orbit. A satellite in MEO is between LEO and | |||
GEO orbits and has an altitude between 2,000km and 35,786km. | GEO orbits and has an altitude between 2,000km and 35,786km. | |||
* SID: Segment Identifier [RFC8402] | * SID: Segment Identifier [RFC8402] | |||
* Stripe: A set of satellites in a few adjacent orbits. These form | * Stripe: A set of satellites in a few adjacent orbits. These form | |||
an IS-IS L1 area. | an IS-IS L1 area. | |||
* SR: Segment Routing [RFC8402] | * SR: Segment Routing [RFC8402] | |||
* Uplink: The half of a link leading from an Earth station to a | * Uplink: The half of a link leading from an Earth station to a | |||
satellite. | satellite. | |||
* User station: An Earth station interconnected with a small end- | * User station: An Earth station interconnected with a small end- | |||
user network. | user network. | |||
2. Overview | 2. Overview | |||
2.1. Topological Considerations | 2.1. Topological Considerations | |||
Satellites travel in specific orbits around their parent planet. | Satellites travel in specific orbits around their parent planet. | |||
Some of them have their orbital periods synchronized to the rotation | Some of them have their orbital periods synchronized to planetary | |||
of the planet, so they are effectively stationary over a single | rotation, so they are effectively stationary over a single point. | |||
point. Other satellites have orbits that cause them to travel across | Other satellites have orbits that cause them to travel across regions | |||
regions of the planet gradually or quite rapidly. Respectively, | of the planet gradually or quite rapidly. Respectively, these are | |||
these are typically known as Geostationary Earth Orbits (GEO), Medium | typically known as Geostationary Earth Orbits (GEO), Medium Earth | |||
Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on altitude. | Orbit (MEO), or Low Earth Orbit (LEO), depending on altitude. This | |||
This discussion is not Earth-specific; as we get to other planets, we | discussion is not Earth-specific; as we get to other planets, we can | |||
can test this approach's generality. | test this approach's generality. | |||
Satellites may have data interconnections with one another through | Satellites may have data interconnections with one another through | |||
Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may | Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may | |||
be connected temporarily, with periods of potential connectivity | be connected temporarily, with periods of potential connectivity | |||
computed through orbital mechanics. Multiple satellites may be in | computed through orbital mechanics. Multiple satellites may be in | |||
the same orbit but separated in space, with a roughly constant | the same orbit but separated in space, with a roughly constant | |||
separation. Satellites in the same orbit may have ISLs that have a | separation. Satellites in the same orbit may have ISLs that have a | |||
higher duty cycle than ISLs between different orbits but are still | higher duty cycle than ISLs between different orbits but are still | |||
not guaranteed to always be connected. | not guaranteed to be always connected. | |||
User +-----------------+ Local | User +-----------------+ Local | |||
Stations --- | Satellites |--- Gateway --- Internet | Stations --- | Satellites |--- Gateway --- Internet | |||
+-----------------+ | +-----------------+ | |||
Figure 1: Overall network architecture | Figure 1: Overall network architecture | |||
Earth stations can communicate with one or more satellites that are | Earth stations can communicate with one or more satellites in their | |||
in their region. User stations are Earth stations that have a | region. User stations are Earth stations with a limited capacity and | |||
limited capacity and communicate with only a single satellite at a | communicate with only a single satellite at a time. Other Earth | |||
time. Other Earth stations that may have richer connectivity and | stations that may have richer connectivity and higher bandwidth are | |||
higher bandwidth are commonly called gateways and provide | commonly called gateways and provide connectivity between the | |||
connectivity between the satellite network and conventional wired | satellite network and conventional wired networks. Gateways serve | |||
networks. Gateways serve user stations that are in their geographic | user stations in their geographic proximity and are replicated | |||
proximity and are replicated across the globe as necessary to provide | globally as necessary to provide coverage and meet service density | |||
coverage and meet service density goals. User stations are | goals. User stations are associated with a single local gateway. | |||
associated with a single local gateway. Traffic from one Earth | Traffic from one Earth station to another may need to traverse a path | |||
station to another may need to traverse a path across multiple | across multiple satellites via ISLs. | |||
satellites via ISLs. | ||||
2.2. Link Changes | 2.2. Link Changes | |||
Like conventional network links, ISLs and ground links can fail at | Like conventional network links, ISLs and ground links can fail | |||
any time. However, unlike conventional links, there are predictable | without warning. However, unlike terrestrial links, there are | |||
times when ISLs and ground links can potentially connect and | predictable times when ISLs and ground links can potentially connect | |||
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 elements. | schedule that can be distributed to relevant network elements. | |||
Predictions of a link connecting are not a guarantee: a link may not | Predictions of a link connecting are not guaranteed: a link may not | |||
connect for a variety of reasons. Predictions of a link | connect for many reasons. Link disconnection predictions due to | |||
disconnecting due to orbital mechanics are effectively guaranteed, as | orbital mechanics are effectively guaranteed, as the underlying | |||
the underlying physics is extremely unlikely to improve unexpectedly. | physics will not improve unexpectedly. | |||
2.3. Scalability | 2.3. Scalability | |||
Some proposed satellite networks are fairly large, with tens of | Some proposed satellite networks are fairly large, with tens of | |||
thousands of proposed satellites. [CNN] A key concern is the ability | thousands of proposed satellites. [CNN] A key concern is the ability | |||
to reach this scale and larger, as useful networks tend to grow. | to reach this scale and larger, as useful networks tend to grow. | |||
As we know, the key to scalability is the ability to create | 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 | |||
skipping to change at page 7, line 41 ¶ | skipping to change at page 7, line 47 ¶ | |||
[RFC4271] deployment and is not discussed further. | [RFC4271] deployment and is not discussed further. | |||
The satellite network interconnects user stations and gateways. | The satellite network interconnects user stations and gateways. | |||
Interconnection between the satellite network and the satellite | Interconnection between the satellite network and the satellite | |||
networks of other network operators is outside of the scope of this | networks of other network operators is outside of the scope of this | |||
document. | document. | |||
2.4.1. Traffic Patterns | 2.4.1. Traffic Patterns | |||
We assume that the primary use of the satellite network is to provide | We assume that the primary use of the satellite network is to provide | |||
access from a wide range of geographic locations. We assume that | access from a wide range of geographic locations. We also assume | |||
providing high-bandwidth bulk transit between peer networks is not a | that providing high-bandwidth bulk transit between peer networks is | |||
goal. It has been noted that satellite networks can provide lower | not a goal. It has been noted that satellite networks can provide | |||
latencies than terrestrial fiber networks [Handley]. This proposal | lower latencies than terrestrial fiber networks [Handley]. This | |||
does not preclude such applications but also does not articulate the | proposal does not preclude such applications but does not articulate | |||
mechanisms necessary for user stations to perform the necessary | the mechanisms necessary for user stations to perform the appropriate | |||
traffic engineering computations. Low-latency, multicast, and | traffic engineering computations. Low-latency, multicast, and | |||
anycast applications are not discussed further. | anycast applications are not discussed further. | |||
As with most access networks, we assume that there will be | 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 that the uplink from the gateway to the satellite | |||
network to be the bandwidth bottleneck, and that gateways will need | network to be the bandwidth bottleneck, and that gateways will need | |||
to be replicated to scale the uplink bandwidth, as the satellite | to be replicated to scale the uplink bandwidth, as the satellite | |||
capacity reachable from a gateway will be limited. | capacity reachable from a gateway will be limited. | |||
We assume that it is not essential to provide optimal routing for | 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 | |||
first to a gateway and then back into the satellite network, this | to a gateway first and then back into the satellite network, this | |||
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. | remains very low. This type of routing is not discussed further. | |||
We assume that traffic for a user station should enter the satellite | We assume that traffic for a user station should enter the satellite | |||
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 | 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 | the 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 station. | in the closest geographic proximity to the user station. | |||
Jurisdictional requirements for landing traffic in certain regions | Jurisdictional requirements for landing traffic in certain regions | |||
skipping to change at page 8, line 51 ¶ | skipping to change at page 9, line 12 ¶ | |||
User stations that can concurrently access multiple satellites are | User stations that can concurrently access multiple satellites are | |||
not precluded by this proposal, but are not discussed in detail. | not precluded by this proposal, but are not discussed in detail. | |||
2.4.3. Stochastic Connectivity | 2.4.3. Stochastic Connectivity | |||
We assume that links in general will be available when scheduled. As | 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. | guarantee, but we also expect that the schedule is mostly accurate. | |||
We assume that at any given instant, there are enough working links | We assume that at any given instant, there are enough working links | |||
and aggregate bandwidth to run the network and support the traffic | and aggregate bandwidth to run the network and support the traffic | |||
demand. If this assumption does not hold, then no routing | demand. If this assumption does not hold, no routing architecture | |||
architecture can magically make the network more capable. | can magically make the network more capable. | |||
Satellites that are in the same orbit may be connected by ISLs. | Satellites that are in the same orbit may be connected by ISLs. | |||
These are called intra-orbit ISLs. Satellites that are in different | These are called intra-orbit ISLs. Satellites that are in different | |||
orbits may also be connected by ISLs. These are called inter-orbit | orbits may also be connected by ISLs. These are called inter-orbit | |||
ISLs. We assume that, in general, intra-orbit ISLs have higher | ISLs. We assume that, in general, intra-orbit ISLs have higher | |||
reliability and persistence than inter-orbit ISLs. | reliability and persistence than inter-orbit ISLs. | |||
We assume that the satellite network is connected (in the graph | We assume that the satellite network is connected (in the graph | |||
theory sense) almost all the time, even if some links are down. This | theory sense) almost always, even if some links are down. This | |||
implies that there is almost always some path to the destination. In | implies that there is almost always some path to the destination. In | |||
the extreme case where there is no such path, we assume that it is | the extreme case with no such path, we assume that it is acceptable | |||
acceptable to drop the payload packets. We do not require buffering | to drop the payload packets. We do not require buffering of traffic | |||
of traffic when a link is down. Instead, traffic should be rerouted. | when a link is down. Instead, traffic should be rerouted. | |||
2.5. Problem Statement | 2.5. Problem Statement | |||
The goal of the routing architecture is to provide an organizational | The goal of the routing architecture is to provide an organizational | |||
structure to protocols running on the satellite network such that | structure to protocols running on the satellite network such that | |||
topology information is conveyed through relevant portions of the | topology information is conveyed through relevant portions of the | |||
network, that paths are computed across the network, and that data | network, that paths are computed across the network, and that data | |||
can be delivered along those paths, and the structure can scale to a | can be delivered along those paths, and the structure can scale | |||
very large network without any changes to the organizational | without any changes to the organizational structure. | |||
structure. | ||||
3. Forwarding Plane | 3. Forwarding Plane | |||
The end goal of a network is to deliver traffic. In a satellite | 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 | network where the topology is in a continual state of flux and the | |||
user stations are frequently changing their association with the | user stations frequently change their association with the | |||
satellites, having a highly flexible and adaptive forwarding plane is | satellites, having a highly flexible and adaptive forwarding plane is | |||
essential. Toward this end, we propose to use MPLS as the | essential. Toward this end, we propose to use MPLS as the | |||
fundamental forwarding plane architecture [RFC3031]. Specifically, | fundamental forwarding plane architecture [RFC3031]. Specifically, | |||
we propose to use a Segment Routing (SR) [RFC8402] based approach | we propose to use a Segment Routing (SR) [RFC8402] based approach | |||
with an MPLS data plane [RFC8660], where each satellite is assigned a | with an MPLS data plane [RFC8660], where each satellite is assigned a | |||
node Segment Identifier (SID). This allows the architecture to | node Segment Identifier (SID). This allows the architecture to | |||
support both IPv4 and IPv6 concurrently. A path through the network | support both IPv4 and IPv6 concurrently. A path through the network | |||
can be then expressed as a label stack of node SIDs. IP forwarding | can then be expressed as a label stack of node SIDs. IP forwarding | |||
is not used within the internals of the satellite network, although | is not used within the internals of the satellite network, although | |||
each satellite may be assigned an IP address for management purposes. | each satellite may be assigned an IP address for management purposes. | |||
Existing techniques may be used to limit the size of the SR label | Existing techniques may be used to limit the size of the SR label | |||
stack so that it only contains the significant waypoints along the | stack so that it only contains the significant waypoints along the | |||
path.[Giorgetti] This implies that the label stack operates as a form | path [Giorgetti]. The label stack operates as a loose source route | |||
of loose-source routing through the network. If there is an | through the network. If there is an unexpected topology change in | |||
unexpected topology change in the network, then the IGP will compute | the network, the IGP will compute a new path to the next waypoint, | |||
a new path to the next waypoint, allowing packet delivery despite ISL | allowing packet delivery despite ISL failures. While the IGP is | |||
failures. While the IGP is converging, there may be micro-loops in | converging, there may be micro-loops in the topology. These can be | |||
the topology. These can be avoided through the use of TI-LFA | avoided by using TI-LFA alternate paths | |||
alternate paths [I-D.ietf-rtgwg-segment-routing-ti-lfa], or traffic | [I-D.ietf-rtgwg-segment-routing-ti-lfa], or traffic will loop until | |||
will loop until it is discarded based on its TTL. | discarded based on its TTL. | |||
We assume that there is a link-layer mechanism for a user station to | We assume that there is a link-layer mechanism for a user station to | |||
associate with a satellite. User stations will have an IP address | associate with a satellite. User stations will have an IP address | |||
that is assigned from a prefix managed by its local gateway. The | assigned from a prefix managed by its local gateway. The mechanisms | |||
mechanisms for this assignment and its communication to the end | for this assignment and its communication to the end station are not | |||
station are not discussed herein but might be similar to DHCP | discussed herein but might be similar to DHCP [RFC2131]. User | |||
[RFC2131]. User station IP addresses change infrequently and do not | station IP addresses change infrequently and do not reflect their | |||
reflect their association with their first-hop satellite. Gateways | association with their first-hop satellite. Gateways and their | |||
and their supporting terrestrial networks advertise prefixes covering | supporting terrestrial networks advertise prefixes covering all its | |||
all of its local user stations into the global Internet. | local user stations into the global Internet. | |||
User stations may be assigned a node SID, in which case MPLS | User stations may be assigned a node SID, in which case MPLS | |||
forwarding can be used for all hops to the user station. | forwarding can be used for all hops to the user station. | |||
Alternatively, if the user station does not have a node SID, then the | Alternatively, if the user station does not have a node SID, then the | |||
last hop from the satellite to the end station can be performed based | last hop from the satellite to the end station can be performed based | |||
on the destination IP address of the packet. This does not require a | on the destination IP address of the packet. This does not require a | |||
full longest-prefix-match lookup as the IP address is merely a unique | full longest-prefix-match lookup as the IP address is merely a unique | |||
identifier at this point. | identifier at this point. | |||
Similarly, gateways may be assigned a node SID. A possible | Similarly, gateways may be assigned a node SID. A possible | |||
optimization is that a single SID value 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- | that is attached to the packet by the user station or by the first- | |||
hop satellite. | hop satellite. | |||
Gateways can also perform traffic engineering by using different | Gateways can also perform traffic engineering using different paths | |||
paths and label stacks for different traffic flows. Routing a single | and label stacks for separate traffic flows. Routing a single | |||
traffic flow across multiple paths has proven to cause performance | traffic flow across multiple paths has proven to cause performance | |||
issues with transport protocols, so that approach is not recommended. | issues with transport protocols, so that approach is not recommended. | |||
Traffic engineering is discussed further in Section 6. | Traffic engineering is discussed further in Section 6. | |||
4. IGP Suitability and Scalability | 4. IGP Suitability and Scalability | |||
As discussed in Section 2.3, IS-IS is architecturally the best fit | As discussed in Section 2.3, IS-IS is architecturally the best fit | |||
for satellite networks, but does require some novel approaches to | for satellite networks, but does require some novel approaches to | |||
achieve the scalability goals for a satellite network. In | achieve the scalability goals for a satellite network. In | |||
particular, we propose that all nodes in the network be L1L2 so that | particular, we propose that all nodes in the network be L1L2 so that | |||
skipping to change at page 11, line 8 ¶ | skipping to change at page 11, line 22 ¶ | |||
is done based on L2 information. | is done based on L2 information. | |||
IS-IS has the interesting property that it does not require interface | IS-IS has the interesting property that it does not require interface | |||
addresses. This feature is commonly known as 'unnumbered | 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. | different satellite without any reconfiguration or renumbering. | |||
Scalability for IS-IS can be achieved through the use of a proposal | Scalability for IS-IS can be achieved through a proposal known as | |||
known as Area Proxy [I-D.ietf-lsr-isis-area-proxy]. With this | Area Proxy [I-D.ietf-lsr-isis-area-proxy]. With this proposal, all | |||
proposal, all of the nodes in an L1 area combine their information | nodes in an L1 area combine their information into a single L2 Link | |||
into a single L2 Link State Protocol Data Unit (LSP). This implies | State Protocol Data Unit (LSP). This implies that the size of the L1 | |||
that the size of the L1 Link State Database (LSDB) scales as the | Link State Database (LSDB) scales as the number of nodes in the L1 | |||
number of nodes in the L1 area and the size of the L2 LSDB scales | area and the size of the L2 LSDB scales with the number of L1 areas. | |||
with the number of L1 areas. | ||||
With Area Proxy, topological changes within an L1 area will not be | With Area Proxy, topological changes within an L1 area will not be | |||
visible to other areas, so the overhead of link state changes will be | visible to other areas, so the overhead of link state changes will be | |||
greatly reduced. | greatly reduced. | |||
The Area Proxy proposal also includes the concept of an Area SID. | The Area Proxy proposal also includes the concept of an Area SID. | |||
This is useful because it allows traffic engineering to construct a | This is useful because it allows traffic engineering to construct a | |||
path that traverses areas with a minimal number of label stack | path that traverses areas with a minimal number of label stack | |||
entries. | entries. | |||
Suppose, for example, that a network has 1,000 L1 areas, each with | Suppose, for example, that a network has 1,000 L1 areas, each with | |||
1,000 satellites. This would then 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; numbers that are easily achievable | and 1,000 entries in its L2 LSDB; numbers that are easily achievable | |||
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 | 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 | each satellite advertises an IP address for management purposes, then | |||
the IP routing table would have 1,000 entries for the L1 management | the IP routing table would have 1,000 entries for the L1 management | |||
addresses and 1,000 area proxy addresses from L2. | addresses and 1,000 area proxy addresses from L2. | |||
In this proposal, IS-IS does not carry any IP routes other than those | In this proposal, IS-IS does not carry IP routes other than those in | |||
that are in the satellite topology. In particular, there are no IP | the satellite topology. In particular, there are no IP routes for | |||
routes for user stations or the remainder of the Internet. | user stations or the remainder of the Internet. | |||
5. Stripes and Areas | 5. Stripes and Areas | |||
A significant problem with any link state routing protocol is that of | 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 significant production deployment. | partition repair, none has seen notable production deployment. It | |||
It seems best to simply avoid this issue altogether and ensure that | seems best to avoid this issue and ensure areas have an extremely low | |||
areas have an extremely low probability of partitioning. | probability of partitioning. | |||
As discussed above, intra-orbit ISLs are assumed to have higher | 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 for any | orbits as an IS-IS L1 area, called a stripe. We assume that for any | |||
given reliability requirement, there is a small number of orbits that | given reliability requirement, there is a small number of orbits that | |||
can be used to form a stripe that satisfies the reliability | can be used to form a stripe that satisfies the reliability | |||
requirement. | requirement. | |||
Stripes are connected to other adjacent stripes using the same ISL | Stripes are connected to other adjacent stripes using the same ISL | |||
mechanism, forming the L2 topology of the network. Each stripe | mechanism, forming the L2 topology of the network. Each stripe | |||
should have multiple L2 connections and should never become | should have multiple L2 connections and never become partitioned from | |||
partitioned from the remainder of the network. | the remainder of the network. | |||
By using a stripe as an L1 area, in conjunction with Area Proxy, the | By using a stripe as an L1 area, in conjunction with Area Proxy, the | |||
overhead of the architecture is greatly reduced. Each stripe | overhead of the architecture is greatly reduced. Each stripe | |||
contributes a single LSP to the L2 LSDB, completely hiding all of the | contributes a single LSP to the L2 LSDB, completely hiding all the | |||
details about the satellites within the stripe. The resulting | details about the satellites within the stripe. The resulting | |||
architecture scales proportionately to the number of stripes | architecture scales proportionately to the number of stripes | |||
required, not the number of satellites. | required, not the number of satellites. | |||
Groups of MEO and GEO satellites with interconnecting ISLs can also | Groups of MEO and GEO satellites with interconnecting ISLs can also | |||
form an IS-IS L1L2 area. Satellites that lack intra-constellation | form an IS-IS L1L2 area. Satellites that lack intra-constellation | |||
ISLs are better as independent L2 nodes. | ISLs are better as independent L2 nodes. | |||
6. Traffic Forwarding and Traffic Engineering | 6. Traffic Forwarding and Traffic Engineering | |||
skipping to change at page 13, line 33 ¶ | skipping to change at page 14, line 6 ¶ | |||
\ | \ | |||
Figure 3: Off-stripe forwarding | Figure 3: Off-stripe forwarding | |||
As an example, consider a packet from an Internet source S to a user | As an example, consider a packet from an Internet source S to a user | |||
station D. A local gateway L has injected a prefix covering D into | station D. A local gateway L has injected a prefix covering D into | |||
BGP and advertised it globally. The packet is forwarded to L using | BGP and advertised it globally. The packet is forwarded to L using | |||
IP forwarding. When L receives the packet, it performs a lookup in a | IP forwarding. When L receives the packet, it performs a lookup in a | |||
pre-computed forwarding table. This contains a SID list for the user | pre-computed forwarding table. This contains a SID list for the user | |||
station that has already been converted into a label stack. Suppose | station that has already been converted into a label stack. Suppose | |||
that the user station is currently associated with a different stripe | the user station is currently associated with a different stripe so | |||
so that the label stack will contain an area label A and a label U | that the label stack will contain an area label A and a label U for | |||
for the satellite associated with the user station, resulting in a | the satellite associated with the user station, resulting in a label | |||
label stack (A, U). | stack (A, U). | |||
The local gateway forwards this into the satellite network. The | The local gateway forwards this into the satellite network. The | |||
first-hop satellite now forwards based on the area label A at the top | first-hop 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 | of the stack. All area labels are propagated as part of the L2 | |||
topology. This forwarding continues until the packet reaches a | topology. This forwarding continues until the packet reaches a | |||
satellite that is adjacent to the destination area. That satellite | satellite adjacent to the destination area. That satellite pops | |||
pops label A, removing that label and forwarding the packet into the | label A, removing that label and forwarding the packet into the | |||
destination area. | destination area. | |||
The packet is now forwarded based on the remaining label U, which was | The packet is now forwarded based on the remaining label U, which was | |||
propagated as part of the L1 topology. The last satellite forwards | propagated as part of the L1 topology. The last satellite forwards | |||
the packet based on the destination address D and forwards the packet | the packet based on the destination address D and forwards the packet | |||
to the user station. | to the user station. | |||
The return case is similar. The label stack, in this case, consists | The return case is similar. The label stack, in this case, consists | |||
of a label for the local gateway's stripe/area, A', and the label for | of a label for the local gateway's stripe/area, A', and the label for | |||
the local gateway, L, resulting in the stack (A', L). The forwarding | the local gateway, L, resulting in the stack (A', L). The forwarding | |||
mechanisms are similar to the previous case. | mechanisms are similar to the previous case. | |||
Very frequently, access networks congest due to oversubscription and | Very frequently, access networks congest due to oversubscription and | |||
the economics of access. Network operators can use traffic | the economics of access. Network operators can use traffic | |||
engineering to ensure that they are getting higher efficiency out of | engineering to ensure that they get higher efficiency out of their | |||
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 that it is generating and can | information about all of the traffic it is generating and can use all | |||
use all of the possible paths through the network in its topological | 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 just | |||
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). [RFC4655] | can be performed by Path Computation Elements (PCE). [RFC4655] | |||
Each gateway or its PCE will need topological information from all of | Each gateway or its PCE will need topological information from the | |||
the areas that it will route through. It can do this by being a | areas it will route through. It can do this by participating in the | |||
participant in the IGP either directly, via a tunnel, or another | IGP directly, via a tunnel, or another delivery mechanism such as | |||
delivery mechanism such as BGP-LS [RFC9552]. User stations do not | BGP-LS [RFC9552]. User stations do not participate in the IGP. | |||
participate in the IGP. | ||||
Traffic engineering for traffic into a gateway can also be provided | Traffic engineering for packets flowing into a gateway can also be | |||
by an explicit SR path for the traffic. This can help ensure that | provided by an explicit SR path. This can help ensure that ISLs near | |||
ISLs near the gateway do not congest with traffic for the gateway. | the gateway do not congest with traffic for the gateway. These paths | |||
These paths can be computed by the gateway or PCE and then | can be computed by the gateway or PCE and then distributed to the | |||
distributed to the first-hop satellite or user station, which would | first-hop satellite or user station, which would apply them to | |||
then apply them to traffic. The delivery mechanism is outside of the | traffic. The delivery mechanism is outside of the scope of this | |||
scope of this document. | document. | |||
7. Scheduling | 7. Scheduling | |||
The most significant difference between terrestrial and satellite | 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 | computed. Both link and node changes will affect the topology and | |||
the network should react smoothly and predictably. | the network should react smoothly and predictably. | |||
The management plane is responsible for providing information about | 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 of the scope of this document | |||
but could be done through a YANG model | but could be done through a YANG model [I-D.ietf-tvr-schedule-yang]. | |||
[I-D.united-tvr-schedule-yang]. Scheduling information needs to be | Scheduling information needs to be accessible to all of the nodes | |||
accessible to all of the nodes that will make routing decisions based | that will make routing decisions based on the topological changes in | |||
on the topological changes in the schedule, so information about an | the schedule, so data about an L1 topological change will need to be | |||
L1 topological change will need to be circulated to all nodes in the | circulated to all nodes in the L1 area and information about L2 | |||
L1 area and information about L2 changes will need to propagate to | changes will need to propagate to all L2 nodes, plus the gateways and | |||
all L2 nodes, plus the gateways and PCEs that carry the related | PCEs that carry the related topological information. | |||
topological information. | ||||
There is very little reaction that the network should do in response | There is very little that the network should do in response to a | |||
to a topological addition. A link coming up or a node joining the | topological addition. A link coming up or a node joining the | |||
topology should not have any functional change until the change is | topology should not have any functional change until the change is | |||
proven to be fully operational based on the usual liveness mechanisms | proven to be fully operational based on the usual IS-IS liveness | |||
found within IS-IS. Nodes may pre-compute their routing table | mechanisms. Nodes may pre-compute their routing table changes but | |||
changes but should not install them before all of the relevant | should not install them before all relevant adjacencies are received. | |||
adjacencies are received. The benefits of this pre-computation | The benefits of this pre-computation appear to be very small. | |||
appear to be very small. Gateways and PCEs may also choose to pre- | Gateways and PCEs may also choose to pre-compute paths based on these | |||
compute paths based on these changes, but should be careful to not | changes, but should not install paths using the new parts of the | |||
install paths using the new parts of the topology until they are | topology until they are confirmed to be operational. If some path | |||
confirmed to be operational. If some path pre-installation is | pre-installation is performed, gateways and PCEs must be prepared for | |||
performed, gateways and PCEs must be prepared for the situation where | the situation where the topology fails to become operational and may | |||
the topology does not become operational and may need to take | need to take alternate steps instead, such as reverting any related | |||
alternate steps instead, such as reverting any related pre-installed | pre-installed paths. | |||
paths. | ||||
The network may choose to not do any pre-installation or pre- | The network may choose not to pre-install or pre-compute routes in | |||
computation in reaction to topological additions, at a small cost of | reaction to topological additions, at a small cost of some | |||
some operational efficiency. | operational efficiency. | |||
Topological deletions are an entirely different matter. If a link or | Topological deletions are an entirely different matter. If a link or | |||
node is to be removed from the topology, then 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 | traffic to alternate paths. This is a common operational procedure | |||
in existing networks when links are taken out of service, such as | in existing networks when links are taken out of service, such as | |||
when proactive maintenance needs to be performed. This type of | when proactive maintenance needs to be performed. This type of | |||
change does require some time to propagate through the network, so | change does require some time to propagate through the network, so | |||
the metric change should be initiated far enough in advance that the | the metric change should be initiated far enough in advance that the | |||
network converges before the actual topological change. Gateways and | network converges before the actual topological change. Gateways and | |||
PCEs should also update paths around the topology change and install | PCEs should also update paths around the topology change and install | |||
these changes before the topology change takes place. The time | these changes before the topology change occurs. The time necessary | |||
necessary for both IGP and path changes will vary depending on the | for both IGP and path changes will vary depending on the exact | |||
exact network and configuration. | network and configuration. | |||
Strictly speaking, changing to a high metric should not be necessary. | Strictly speaking, changing to a high metric should not be necessary. | |||
It should be possible for each router to simply exclude the link and | It should be possible for each router to exclude the link and | |||
recompute paths. However, it seems safer to also change the metric | recompute paths. However, it seems safer to change the metric and | |||
and use the IGP methods for indicating a topology change, as this can | use the IGP methods for indicating a topology change, as this can | |||
help avoid issues with incomplete information dissemination and | help avoid issues with incomplete information dissemination and | |||
synchronization. | synchronization. | |||
8. Future Work | 8. Future Work | |||
This architecture needs to be validated by satellite operators, both | 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, and that | |||
information is not publicly available at present. | information is not publicly available currently. | |||
Current available information about ISLs indicates that links are | ||||
mechanically steered and will need to track the opposite end of the | ||||
link continually. The angles and distances that can be practically | ||||
supported are unknown, as are any limitations about the rate of | ||||
change. | ||||
It is expected that intra-orbit and inter-orbit ISL links will have | ||||
very different properties. Intra-orbit links should be much more | ||||
stable, but still far less stable than terrestrial links. Inter- | ||||
orbit links will be less stable. Links between satellites that are | ||||
roughly parallel should be possible, but will likely have a limited | ||||
duration. Two orbits may be roughly orthogonal, resulting in a | ||||
limited potential for connectivity. Finally, in some topologies | ||||
there may be parallel orbits where the satellites move in opposite | ||||
directions, giving a relative speed between satellites around | ||||
34,000mph. Links in this situation may not be possible or may be so | ||||
short-lived as to be impractical. | ||||
The key question to address is whether the parameters of a given | ||||
network can yield a stripe assignment that produces stable, connected | ||||
areas that work within the scaling bounds of the IGP. If links are | ||||
very stable, a stripe could be just a few parallel orbits, with only | ||||
a few hundred satellites. However, if links are unstable, a stripe | ||||
might have to encompass dozens of orbits and thousands of satellites, | ||||
which might be beyond the scaling limitations of a given IGP's | ||||
implementation. | ||||
9. Deployment Considerations | 9. Deployment Considerations | |||
The network behind a gateway is expected to be a normal terrestrial | The network behind a gateway is expected to be a normal terrestrial | |||
network. Conventional routing architectural principles apply. An | network. Conventional routing architectural principles apply. An | |||
obvious approach would be to extend IS-IS to the terrestrial network, | obvious approach would be to extend IS-IS to the terrestrial network, | |||
applying L1 areas as necessary for scalability. | applying L1 areas as necessary for scalability. | |||
The terrestrial network may have one or more BGP connections to the | The terrestrial network may have one or more BGP connections to the | |||
broader Internet. Prefixes for user stations should be advertised | broader Internet. Prefixes for user stations should be advertised to | |||
into 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 | interconnected by the terrestrial network, then it may be advisable | |||
to use one autonomous system per gateway as it might simplify the | to 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. | entire terrestrial network. | |||
10. Security Considerations | 10. Security Considerations | |||
This document discusses one possible routing architecture for | 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 | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 19, line 38 ¶ | |||
[Handley] Handley, M., "Delay is Not an Option: Low Latency Routing | [Handley] Handley, M., "Delay is Not an Option: Low Latency Routing | |||
in Space", ACM Proceedings of the 17th ACM Workshop on Hot | in Space", ACM Proceedings of the 17th ACM Workshop on Hot | |||
Topics in Networks, DOI 10.1145/3286062.3286075, November | Topics in Networks, DOI 10.1145/3286062.3286075, November | |||
2018, <https://doi.org/10.1145/3286062.3286075>. | 2018, <https://doi.org/10.1145/3286062.3286075>. | |||
[I-D.ietf-rtgwg-segment-routing-ti-lfa] | [I-D.ietf-rtgwg-segment-routing-ti-lfa] | |||
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., | Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., | |||
Decraene, B., and D. Voyer, "Topology Independent Fast | Decraene, B., and D. Voyer, "Topology Independent Fast | |||
Reroute using Segment Routing", Work in Progress, | Reroute using Segment Routing", Work in Progress, | |||
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- | Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- | |||
13, 16 January 2024, | 16, 29 June 2024, <https://datatracker.ietf.org/doc/html/ | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg- | draft-ietf-rtgwg-segment-routing-ti-lfa-16>. | |||
segment-routing-ti-lfa-13>. | ||||
[I-D.united-tvr-schedule-yang] | [I-D.ietf-tvr-schedule-yang] | |||
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. | Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. | |||
Blanchet, "YANG Data Model for Scheduled Attributes", Work | Blanchet, "YANG Data Model for Scheduled Attributes", Work | |||
in Progress, Internet-Draft, draft-united-tvr-schedule- | in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang- | |||
yang-00, 11 October 2023, | 00, 16 April 2024, <https://datatracker.ietf.org/doc/html/ | |||
<https://datatracker.ietf.org/doc/html/draft-united-tvr- | draft-ietf-tvr-schedule-yang-00>. | |||
schedule-yang-00>. | ||||
[ITU] "ITU Radio Regulations, Article 1", 2016, | [ITU] "ITU Radio Regulations, Article 1", 2016, | |||
<https://search.itu.int/history/ | <https://search.itu.int/history/ | |||
HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf>. | HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf>. | |||
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | |||
dual environments", RFC 1195, DOI 10.17487/RFC1195, | dual environments", RFC 1195, DOI 10.17487/RFC1195, | |||
December 1990, <https://www.rfc-editor.org/info/rfc1195>. | December 1990, <https://www.rfc-editor.org/info/rfc1195>. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
End of changes. 57 change blocks. | ||||
181 lines changed or deleted | 207 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |