rfc9717v1.txt | rfc9717.txt | |||
---|---|---|---|---|
skipping to change at line 182 ¶ | skipping to change at line 182 ¶ | |||
LEO: Low Earth Orbit. A satellite in LEO has an altitude of 2,000 | LEO: Low Earth Orbit. A satellite in LEO has an altitude of 2,000 | |||
km or less. | km or less. | |||
Local gateway: Each user station is associated with a single gateway | Local gateway: Each user station is associated with a single gateway | |||
in its region. | in its region. | |||
LSP: Link State Protocol Data Unit. An IS-IS LSP is a set of | LSP: Link State Protocol Data Unit. An IS-IS 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 GEO | MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO | |||
orbits and has an altitude between 2,000 km and 35,786 km. | and has an altitude between 2,000 km and 35,786 km. | |||
SID: Segment Identifier [RFC8402] | SID: Segment Identifier [RFC8402] | |||
Stripe: A set of satellites in a few adjacent orbits. These form an | Stripe: A set of satellites in a few adjacent orbits. These form an | |||
IS-IS L1 area. | 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 | User station: An Earth station interconnected with a small end-user | |||
network. | 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 planets. | |||
Some of them have their orbital periods synchronized to planetary | Some of them have their orbital periods synchronized to planetary | |||
rotation, so they are effectively stationary over a single point. | rotation, so they are effectively stationary over a single point. | |||
Other satellites have orbits that cause them to travel across regions | Other satellites have orbits that cause them to travel across regions | |||
of the planet either gradually or quite rapidly. Respectively, these | of the planet either gradually or quite rapidly. Respectively, these | |||
are typically known as the Geostationary Earth Orbit (GEO), Medium | are typically known as the Geostationary Earth Orbit (GEO), Medium | |||
Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on the | Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on the | |||
altitude. This discussion is not Earth-specific; as we get to other | altitude. This discussion is not Earth-specific; as we get to other | |||
planets, we can test this approach's generality. | planets, we can test this approach's generality. | |||
Satellites may have data interconnections with one another through | Satellites may have data interconnections with one another through | |||
skipping to change at line 267 ¶ | skipping to change at line 267 ¶ | |||
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. | contain topological information. | |||
Normal routing protocols are architected to operate with a static but | Normal routing protocols are architected to operate with a static but | |||
somewhat unreliable topology. Satellite networks lack the static | somewhat unreliable topology. Satellite networks lack the static | |||
organization of terrestrial networks, so normal architectural | organization of terrestrial networks, so normal architectural | |||
practices for scalability may not apply, and alternative approaches | practices for scalability may not apply, and alternative approaches | |||
may need consideration. | may need consideration. | |||
In a traditional deployment of a link-state routing protocol, current | In a typical deployment of a link-state routing protocol, current | |||
implementations can be deployed with a single area that spans a few | implementations can be deployed with a single area that spans a few | |||
thousand routers. A single area would also provide no isolation for | thousand routers. A single area would also provide no isolation for | |||
topological changes, causing every link change to be propagated | topological changes, causing every link change to be propagated | |||
throughout the entire network. This would be insufficient for the | throughout the entire network. This would be insufficient for the | |||
needs of large satellite networks. | needs of large satellite networks. | |||
Multiple areas or multiple instances of an Interior Gateway Protocol | Multiple areas or multiple instances of an Interior Gateway Protocol | |||
(IGP) can be used to improve scalability, but there are limitations | (IGP) can be used to improve scalability, but there are limitations | |||
to traditional approaches. | to typical approaches. | |||
Currently, the IETF actively supports two link-state IGPs: OSPF | Currently, the IETF actively supports two link-state IGPs: OSPF | |||
[RFC2328] [RFC5340] and IS-IS. | [RFC2328] [RFC5340] and IS-IS. | |||
OSPF requires that the network operate around a backbone area, with | 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 | |||
for satellite networks, where there is no centralized portion of the | satellite networks, where there is no centralized portion of the | |||
topology. | topology. | |||
IS-IS has a different hierarchical structure, where Level 1 (L1) | IS-IS has a different hierarchical structure, where Level 1 (L1) | |||
areas are connected sets of nodes, and then Level 2 (L2) is a | areas are connected sets of nodes, and then Level 2 (L2) is a | |||
connected subset of the topology that intersects all of the L1 areas. | connected subset of the topology that intersects all of the L1 areas. | |||
Individual nodes can be L1, L2, or both (L1L2). Traditional IS-IS | Individual 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 | designs require that any node or link that is to be used as transit | |||
between L2 areas must appear as part of the L2 topology. In a | between L2 areas must appear as part of the L2 topology. In a | |||
satellite network, any satellite could end up being used for L2 | satellite network, any satellite could end up being used for L2 | |||
transit, and so every satellite and link would be part of L2, | transit, and so every satellite and link would be part of L2, | |||
negating any scalability benefits from IS-IS's hierarchical | negating any scalability benefits from IS-IS's hierarchical | |||
structure. | structure. | |||
We elaborate on considerations specific to IS-IS in Section 4. | We elaborate on considerations specific to IS-IS in Section 4. | |||
2.4. Assumptions | 2.4. Assumptions | |||
skipping to change at line 402 ¶ | skipping to change at line 402 ¶ | |||
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 always, 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 with no such path, we assume that it is acceptable | the extreme case with no such path, we assume that it is acceptable | |||
to drop the payload packets. We do not require buffering of traffic | to drop the payload packets. We do not require buffering 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. This | |||
topology information is conveyed through relevant portions of the | architecture must convey topology information to relevant portions of | |||
network, paths are computed across the network, and data can be | the network. This enables path computation that is used for data | |||
delivered along those paths so that the structure can scale without | forwarding. The architecture must also scale without global changes | |||
any changes to the organizational structure. | to the organizational 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 frequently change 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 using MPLS as the fundamental | essential. Toward this end, we propose using MPLS as the fundamental | |||
forwarding plane architecture [RFC3031]. Specifically, we propose | forwarding plane architecture [RFC3031]. Specifically, we propose | |||
using an approach based on Segment Routing (SR) [RFC8402] with an | using an approach based on Segment Routing (SR) [RFC8402] with an | |||
skipping to change at line 442 ¶ | skipping to change at line 442 ¶ | |||
on its TTL. | 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 | |||
assigned from a prefix managed by its local gateway. The mechanisms | assigned from a prefix managed by its local gateway. The mechanisms | |||
for this assignment and its communication to the end station are not | for this assignment and its communication to the end station are not | |||
discussed herein but might be similar to DHCP [RFC2131]. User | discussed herein but might be similar to DHCP [RFC2131]. User | |||
station IP addresses change infrequently and do not reflect their | station IP addresses change infrequently and do not reflect their | |||
association with their first-hop satellite. Gateways and their | association with their first-hop satellite. Gateways and their | |||
supporting terrestrial networks advertise prefixes covering all its | supporting terrestrial networks advertise prefixes covering all its | |||
local user stations into the global Internet. | local user stations throughout 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 | full longest-prefix-match lookup, as the IP address is merely a | |||
unique identifier at this point. | unique identifier at this point. | |||
Similarly, gateways may be assigned a node SID. A possible | Similarly, gateways may be assigned a node SID. A possible | |||
skipping to change at line 548 ¶ | skipping to change at line 548 ¶ | |||
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 | |||
Forwarding in this architecture is straightforward. A path from a | The forwarding architecture presented here is straightforward. A | |||
gateway to a user station on the same stripe only requires a single | path from a gateway to a user station on the same stripe only | |||
node SID for the satellite that provides the downlink to the user | requires a single node SID for the satellite that provides the | |||
station. | downlink to the user station. | |||
\ | \ | |||
Gateway --> X | Gateway --> X | |||
\ | \ | |||
\ | \ | |||
X | X | |||
\ | \ | |||
\ | \ | |||
X ---> x User Station | X ---> x User Station | |||
\ | \ | |||
skipping to change at line 850 ¶ | skipping to change at line 850 ¶ | |||
Routing", 2015 IEEE Global Communications Conference | Routing", 2015 IEEE Global Communications Conference | |||
(GLOBECOM), DOI 10.1109/GLOCOM.2015.7417097, December | (GLOBECOM), DOI 10.1109/GLOCOM.2015.7417097, December | |||
2015, <https://ieeexplore.ieee.org/document/7417097>. | 2015, <https://ieeexplore.ieee.org/document/7417097>. | |||
[Handley] Handley, M., "Delay is Not an Option: Low Latency Routing | [Handley] Handley, M., "Delay is Not an Option: Low Latency Routing | |||
in Space", HotNets '18: Proceedings of the 17th ACM | in Space", HotNets '18: Proceedings of the 17th ACM | |||
Workshop on Hot Topics in Networks, pp. 85-91, | Workshop on Hot Topics in Networks, pp. 85-91, | |||
DOI 10.1145/3286062.3286075, November 2018, | DOI 10.1145/3286062.3286075, November 2018, | |||
<https://dl.acm.org/doi/10.1145/3286062.3286075#>. | <https://dl.acm.org/doi/10.1145/3286062.3286075#>. | |||
[ITU] ITU, "Radio Regulations - Articles", 2016, | [ITU] ITU, "Radio Regulations - Articles", 2024, | |||
<https://search.itu.int/history/ | <https://search.itu.int/history/HistoryDigitalCollectionDo | |||
HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf>. | cLibrary/1.49.48.en.101.pdf#search=radio%20regulation>. | |||
[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", | |||
RFC 2131, DOI 10.17487/RFC2131, March 1997, | RFC 2131, DOI 10.17487/RFC2131, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2131>. | <https://www.rfc-editor.org/info/rfc2131>. | |||
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | |||
End of changes. 10 change blocks. | ||||
20 lines changed or deleted | 20 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |