Independent Submission T. Li
Request for Comments: 9717 Juniper Networks
Category: Informational January 2025
ISSN: 2070-1721
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.
衛星ネットワークは、パケットネットワークの興味深い課題をいくつか提示します。トポロジ全体が継続的に動いており、リンクは陸生ネットワークで一般的なものよりもはるかに信頼性が低いです。軌道のダイナミクスのために、リンク接続のいくつかの変更が予想されます。
This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.
このドキュメントでは、スケジュールされたリンク接続変化情報で強化される既存のルーティングプロトコルとメカニズムに基づいて、衛星ネットワークのスケーラブルなルーティングアーキテクチャを提案します。このドキュメントでは、プロトコルの変更は提案されていません。
This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.
この文書は著者の見解を提示し、IETFの積でも、コミュニティのコンセンサスビューでもありません。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9717.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9717で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
1.1. Related Work
1.2. Terms and Abbreviations
2. Overview
2.1. Topological Considerations
2.2. Link Changes
2.3. Scalability
2.4. Assumptions
2.4.1. Traffic Patterns
2.4.2. User Station Constraints
2.4.3. Stochastic Connectivity
2.5. Problem Statement
3. Forwarding Plane
4. IGP Suitability and Scalability
5. Stripes and Areas
6. Traffic Forwarding and Traffic Engineering
7. Scheduling
8. Future Work
9. Deployment Considerations
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Author's Address
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.
衛星ネットワークは、パケットネットワークの興味深い課題をいくつか提示します。トポロジ全体が継続的に動いており、リンクは陸生ネットワークで一般的なものよりもはるかに信頼性が低いです。軌道のダイナミクスのために、リンク接続のいくつかの変更が予想されます。
This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.
このドキュメントでは、スケジュールされたリンク接続変化情報で強化される既存のルーティングプロトコルとメカニズムに基づいて、衛星ネットワークのスケーラブルなルーティングアーキテクチャを提案します。このドキュメントでは、プロトコルの変更は提案されていません。
Large-scale satellite networks are being deployed, presenting an unforeseen application for conventional routing protocols. The high rate of intentional topological change and the extreme scale are unprecedented in terrestrial networking. Links between satellites can utilize free-space optics technology that allows liberal connectivity. Still, there are limitations due to the range of the links and conjunction with the sun, resulting in links that are far less reliable than network designers are used to. In addition, links can change their endpoints dynamically, resulting in structural changes to the topology.
大規模な衛星ネットワークが展開されており、従来のルーティングプロトコルに予期せぬアプリケーションを提示しています。意図的なトポロジカル変化の高い割合と極端なスケールは、陸生ネットワーキングで前例のないものです。衛星間のリンクは、リベラルな接続性を可能にする自由空間光学技術を利用できます。それでも、リンクの範囲と太陽との接続のために制限があり、その結果、ネットワークデザイナーが慣れているよりもはるかに信頼性が低いリンクが生じます。さらに、リンクはエンドポイントを動的に変更し、トポロジの構造的な変化をもたらす可能性があります。
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 for such networks utilizing current standards-based routing technology and to provide a solution for the scalability of the network while incorporating the rapid rate of topological change. This document intends to provide some initial guidance for satellite network operators, but without specific details, this document can only provide the basis for a more complete analysis and design.
このドキュメントでは、現在の標準ベースのルーティングテクノロジーを利用しているこのようなネットワークにルーティングアーキテクチャを提供し、トポロジー変化の急速なレートを組み込んでいる間、ネットワークのスケーラビリティのソリューションを提供する1つのアプローチを提案します。このドキュメントは、衛星ネットワークオペレーターに最初のガイダンスを提供する予定ですが、特定の詳細がなければ、このドキュメントはより完全な分析と設計の基礎を提供することしかできません。
This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.
この文書は著者の見解を提示し、IETFの積でも、コミュニティのコンセンサスビューでもありません。
A survey of related work can be found in [Westphal]. Link-state routing for satellite networks has been considered in [Cao] and [Zhang].
関連研究の調査は[Westphal]にあります。衛星ネットワークのリンク状態ルーティングは、[Cao]および[Zhang]で考慮されています。
Constellation:
星座：
A set of satellites.
衛星のセット。
Downlink:
ダウンリンク：
The half of a ground link leading from a satellite to an Earth station.
衛星からアースステーションへの地上リンクの半分。
Earth station:
アースステーション：
A node in the network that is on or close to the planetary surface and has a link to a satellite. This includes ships, aircraft, and other vehicles below LEO [ITU].
惑星表面の上または近くにあるネットワーク内のノードは、衛星へのリンクを持っています。これには、Leo [ITU]の下の船、航空機、およびその他の車両が含まれます。
Gateway:
ゲートウェイ：
An Earth station that participates in the network and acts as the interconnect between satellite constellations and the planetary network. Gateways have a much higher bandwidth than user stations, have ample computing capabilities, and perform traffic engineering duties, subsuming the functionality of a network controller or Path Computation Element (PCE) [RFC4655]. Multiple gateways are assumed to exist, and each serves a portion of the network.
ネットワークに参加し、衛星星座と惑星ネットワーク間の相互接続として機能するアースステーション。ゲートウェイは、ユーザーステーションよりもはるかに高い帯域幅を持ち、十分なコンピューティング機能を持ち、トラフィックエンジニアリングの義務を実行し、ネットワークコントローラーまたはパス計算要素（PCE）[RFC4655]の機能を包含しています。複数のゲートウェイが存在すると想定されており、それぞれがネットワークの一部を提供します。
GEO:
GEO:
Geostationary Earth Orbit. A satellite in GEO has an orbit that is synchronized to planetary rotation, so it effectively sits over one spot on the planet.
地球軌道。Geoの衛星には、惑星の回転に同期される軌道があるため、惑星の1つの場所に効果的に座っています。
Ground link:
グラウンドリンク：
A link between a satellite and an Earth station, composed of a downlink and an uplink.
ダウンリンクとアップリンクで構成される衛星とアースステーションの間のリンク。
IGP:
IGP:
Interior Gateway Protocol. A routing protocol that is used within a single administrative domain. Note that 'gateway' in this context is semantically equivalent to 'router' and has no relationship to the 'gateway' used in the rest of this document.
インテリアゲートウェイプロトコル。単一の管理ドメイン内で使用されるルーティングプロトコル。このコンテキストでの「ゲートウェイ」は、「ルーター」と意味的に同等であり、このドキュメントの残りの部分で使用されている「ゲートウェイ」とは関係がないことに注意してください。
IS-IS:
is-is：
Intermediate System to Intermediate System. An IGP that is commonly used by service providers [ISO10589] [RFC1195].
中間システムから中間システム。サービスプロバイダー[ISO10589] [RFC1195]が一般的に使用するIGP。
ISL:
ISL:
Inter-Satellite Link. Frequently implemented with free-space optics that allow signaling using photons without any intervening medium [Bell].
衛星間リンク。介入培地のない光子を使用したシグナル伝達を可能にするフリースペース光学で頻繁に実装されます[ベル]。
L1:
L1：
IS-IS Level 1
IS-ISレベル1
L1L2:
L1L2：
IS-IS Level 1 and Level 2
IS-ISレベル1とレベル2
L2:
L2：
IS-IS Level 2
IS-ISレベル2
LEO:
LEO:
Low Earth Orbit. A satellite in LEO has an altitude of 2,000 km or less.
低い地球軌道。レオの衛星の高度は2,000 km以下です。
Local gateway:
ローカルゲートウェイ：
Each user station is associated with a single gateway in its region.
各ユーザーステーションは、その地域の単一のゲートウェイに関連付けられています。
LSP:
LSP:
Link State Protocol Data Unit. An IS-IS LSP is a set of packets that describe a node's connectivity to other nodes.
リンク状態プロトコルデータユニット。IS-IS LSPは、他のノードへのノードの接続を記述するパケットのセットです。
MEO:
MEO:
Medium Earth Orbit. A satellite in MEO is between LEO and GEO and has an altitude between 2,000 km and 35,786 km.
中の地球軌道。MEOの衛星はレオとGEOの間にあり、高度は2,000 kmから35,786 kmです。
SID:
SID:
Segment Identifier [RFC8402]
セグメント識別子[RFC8402]
Stripe:
ストライプ：
A set of satellites in a few adjacent orbits. These form an IS-IS L1 area.
いくつかの隣接する軌道にある衛星のセット。これらはIS-IS L1領域を形成します。
SR:
SR:
Segment Routing [RFC8402]
セグメントルーティング[RFC8402]
Uplink:
アップリンク：
The half of a link leading from an Earth station to a satellite.
アースステーションから衛星へのリンクの半分。
User station:
ユーザーステーション：
An Earth station interconnected with a small end-user network.
小さなエンドユーザーネットワークと相互接続されたアースステーション。
Satellites travel in specific orbits around their parent planets. Some of them have their orbital periods synchronized to planetary rotation, so they are effectively stationary over a single point. Other satellites have orbits that cause them to travel across regions of the planet either gradually or quite rapidly. Respectively, these are typically known as the Geostationary Earth Orbit (GEO), Medium Earth Orbit (MEO), or Low Earth Orbit (LEO), depending on the altitude. This discussion is not Earth-specific; as we get to other planets, we can test this approach's generality.
衛星は、親の惑星の周りの特定の軌道で移動します。それらのいくつかは、軌道の回転と同期している軌道期間を持っているため、単一の点で効果的に静止しています。他の衛星には、徐々にまたは非常に迅速に惑星の領域を移動させる軌道があります。それぞれ、これらは通常、高度に応じて、地球軌道（GEO）、中の地球軌道（MEO）、または低地球軌道（LEO）として知られています。この議論は地球固有ではありません。他の惑星に到達すると、このアプローチの一般性をテストできます。
Satellites may have data interconnections with one another through Inter-Satellite Links (ISLs). Due to differences in orbits, ISLs may be connected temporarily with periods of potential connectivity computed through 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 ISLs that have a higher duty cycle than ISLs between different orbits, but they are still not guaranteed to be always connected.
衛星には、衛星間リンク（ISL）を介して互いにデータの相互接続がある場合があります。軌道の違いにより、ISLは軌道ダイナミクスを介して計算された潜在的な接続性の期間と一時的に接続される場合があります。複数の衛星は同じ軌道にあるかもしれませんが、宇宙ではほぼ一定の分離があります。同じ軌道の衛星には、異なる軌道の間のISLよりも高いデューティサイクルを持つISLがありますが、常に接続されることは保証されていません。
User +-----------------+ Local
Stations --- | Satellites |--- Gateway --- Internet
+-----------------+
Figure 1: Overall Network Architecture
図1：ネットワークアーキテクチャ全体
Earth stations can communicate with one or more satellites in their region. User stations are Earth stations with a limited capacity that communicate with only a single satellite at a time. Other Earth stations that may have richer connectivity and higher bandwidth are commonly called "gateways" and provide connectivity between the satellite network and conventional wired networks. Gateways serve user stations in their geographic proximity and are replicated globally as necessary to provide coverage and to meet service density goals. User stations are associated with a single local gateway. Traffic from one Earth station to another may need to traverse a path across multiple satellites via ISLs.
アースステーションは、その地域の1つ以上の衛星と通信できます。ユーザーステーションは、一度に単一の衛星のみと通信する容量が限られているアースステーションです。より豊富な接続性とより高い帯域幅を持つ可能性のある他の地球ステーションは、一般に「ゲートウェイ」と呼ばれ、衛星ネットワークと従来の有線ネットワーク間の接続性を提供します。ゲートウェイは、地理的に近接してユーザーステーションを提供し、カバレッジを提供し、サービス密度の目標を達成するために必要に応じてグローバルに複製されます。ユーザーステーションは、単一のローカルゲートウェイに関連付けられています。あるアースステーションから別の地球の駅への交通は、ISLを介して複数の衛星を横切る経路を通過する必要がある場合があります。
Like conventional network links, ISLs and ground links can fail without warning. However, unlike terrestrial links, there are predictable times when ISLs and ground links can potentially connect and disconnect. These predictions can be computed and cataloged in a schedule that can be distributed to relevant network elements. Predictions of a link connecting are not guaranteed: A link may not connect for many reasons. Link disconnection predictions due to orbital dynamics are effectively guaranteed, as the underlying physics will not improve unexpectedly.
従来のネットワークリンクと同様に、ISLSと地上リンクは警告なしに失敗する可能性があります。ただし、地上リンクとは異なり、ISLと地上リンクが潜在的に接続および切断できる予測可能な時期があります。これらの予測は、関連するネットワーク要素に配布できるスケジュールで計算およびカタログ化できます。リンク接続の予測は保証されません。リンクは多くの理由で接続できない場合があります。基礎となる物理学が予期せず改善されないため、軌道ダイナミクスによるリンク切断予測は効果的に保証されます。
Some proposed satellite networks are fairly large, with tens of thousands of proposed satellites [CNN]. A key concern is the ability to reach this scale and larger, as useful networks tend to grow.
提案されている衛星ネットワークの一部はかなり大きく、数万の提案された衛星[CNN]があります。有用なネットワークが成長する傾向があるため、重要な懸念は、このスケールとより大きく到達する能力です。
As we know, the key to scalability is the ability to create hierarchical abstractions, so a key question of any routing architecture will be about the abstractions that can be created to contain topological information.
私たちが知っているように、スケーラビリティの鍵は階層的な抽象化を作成する能力であるため、ルーティングアーキテクチャの重要な質問は、トポロジー情報を含むために作成できる抽象化についてです。
Normal routing protocols are architected to operate with a static but somewhat unreliable topology. Satellite networks lack the static organization of terrestrial networks, so normal architectural practices for scalability may not apply, and alternative approaches may need consideration.
通常のルーティングプロトコルは、静的だがやや信頼性の低いトポロジで動作するように設計されています。衛星ネットワークには陸生ネットワークの静的な組織が不足しているため、スケーラビリティのための通常のアーキテクチャプラクティスは適用されず、代替アプローチでは検討が必要になる場合があります。
In a typical deployment of a link-state routing protocol, current implementations can be deployed with a single area that spans a few thousand routers. A single area would also provide no isolation for topological changes, causing every link change to be propagated throughout the entire network. This would be insufficient for the needs of large satellite networks.
リンク状態のルーティングプロトコルの典型的な展開では、数千ルーターにまたがる単一の領域で現在の実装を展開できます。また、単一の領域では、トポロジーの変化に隔離されないため、すべてのリンクの変更がネットワーク全体で伝播されます。これは、大規模な衛星ネットワークのニーズには不十分です。
Multiple areas or multiple instances of an Interior Gateway Protocol (IGP) can be used to improve scalability, but there are limitations to typical approaches.
インテリアゲートウェイプロトコル（IGP）の複数の領域または複数のインスタンスを使用してスケーラビリティを向上させることができますが、典型的なアプローチには制限があります。
Currently, the IETF actively supports two link-state IGPs: OSPF [RFC2328] [RFC5340] and IS-IS.
現在、IETFは2つのリンク状態IGPSを積極的にサポートしています：OSPF [RFC2328] [RFC5340]およびIS-IS。
OSPF requires that the network operate around a backbone area, with subsidiary areas hanging off of the backbone. While this works well for typical terrestrial networks, this does not seem appropriate for satellite networks, where there is no centralized portion of the topology.
OSPFでは、ネットワークがバックボーンエリア周辺で動作することを要求し、補助エリアがバックボーンからぶら下がっています。これは典型的な陸生ネットワークではうまく機能しますが、これはトポロジの集中部分がない衛星ネットワークには適していないようです。
IS-IS has a different hierarchical structure, where Level 1 (L1) areas are connected sets of nodes, and then Level 2 (L2) is a connected subset of the topology that intersects all of the L1 areas. Individual nodes can be L1, L2, or both (L1L2). Typical IS-IS designs require that any node or link that is to be used as transit between L2 areas must appear as part of the L2 topology. In a satellite network, any satellite could end up being used for L2 transit, and so every satellite and link would be part of L2, negating any scalability benefits from IS-IS's hierarchical structure.
IS-ISには異なる階層構造があり、レベル1（L1）領域はノードの接続されたセットであり、レベル2（L2）はすべてのL1領域と交差するトポロジの接続されたサブセットです。個々のノードは、L1、L2、またはその両方（L1L2）です。典型的なIS-IS設計では、L2領域間のトランジットとして使用されるノードまたはリンクがL2トポロジの一部として表示される必要があります。衛星ネットワークでは、すべての衛星がL2トランジットに使用される可能性があるため、すべての衛星とリンクはL2の一部になり、IS-ISの階層構造からスケーラビリティの利点を無効にします。
We elaborate on considerations specific to IS-IS in Section 4.
セクション4のIS-ISに固有の考慮事項について詳しく説明します。
In this section, we discuss some of the assumptions that are the basis for this architectural proposal.
このセクションでは、この建築提案の基礎となる仮定のいくつかについて説明します。
The data payload is IP packets.
データペイロードはIPパケットです。
Satellites are active participants in the control and data planes for the network, participating in protocols and forwarding packets.
衛星は、ネットワークのコントロールおよびデータプレーンにアクティブな参加者であり、プロトコルと転送パケットに参加しています。
There may be a terrestrial network behind each gateway that may interconnect to the broader Internet. The architecture of the terrestrial network is assumed to be a typical IS-IS and BGP deployment [RFC4271] and is not discussed further in this document.
より広いインターネットと相互接続する可能性のある各ゲートウェイの背後には、地上のネットワークがある場合があります。陸生ネットワークのアーキテクチャは、典型的なIS-ISおよびBGP展開[RFC4271]であると想定されており、このドキュメントではこれ以上説明していません。
The satellite network interconnects user stations and gateways. Interconnection between the satellite network and the satellite networks of other network operators is outside the scope of this document.
衛星ネットワークは、ユーザーステーションとゲートウェイを相互に接続します。衛星ネットワークと他のネットワークオペレーターの衛星ネットワークとの相互接続は、このドキュメントの範囲外です。
We assume that the primary use of the satellite network is to provide access from a wide range of geographic locations. We also assume that providing high-bandwidth bulk transit between peer networks is not a goal. It has been noted that satellite networks can provide lower latencies than terrestrial fiber networks in [Handley]. This proposal does not preclude such applications but does not articulate the mechanisms necessary for user stations to perform the appropriate traffic engineering computations. Low-latency, multicast, and anycast applications are not discussed further in this document.
衛星ネットワークの主な使用は、幅広い地理的場所からアクセスを提供することであると仮定します。また、ピアネットワーク間で高帯域幅のバルクトランジットを提供することは目標ではないと想定しています。衛星ネットワークは、[Handley]の地上繊維ネットワークよりも低いレイテンシを提供できることが指摘されています。この提案は、そのようなアプリケーションを排除するものではなく、ユーザーステーションが適切なトラフィックエンジニアリング計算を実行するために必要なメカニズムを明確にしません。このドキュメントでは、低遅延、マルチキャスト、およびAnycastアプリケーションについてはこれ以上説明していません。
As with most access networks, we assume that there will be bidirectional traffic between the user station and the gateway but that the bulk of the traffic will be from the gateway to the user station. We expect the uplink from the gateway to the satellite network to be the bandwidth bottleneck and that gateways will need to be replicated to scale the uplink bandwidth, as the satellite capacity reachable from a gateway will be limited.
ほとんどのアクセスネットワークと同様に、ユーザーステーションとゲートウェイの間に双方向トラフィックがあるが、トラフィックの大部分はゲートウェイからユーザーステーションまでのものになると想定しています。ゲートウェイから衛星ネットワークへのアップリンクが帯域幅のボトルネックになると予想されます。ゲートウェイは、ゲートウェイから到達可能な衛星容量が制限されるため、アップリンク帯域幅をスケーリングするために複製する必要があります。
We assume that it is not essential to provide optimal routing for traffic from user station to user station. If this traffic is sent to a gateway first and then back into the satellite network, it might be acceptable to some operators as long as the traffic volume remains very low. This type of routing is not discussed further in this document.
ユーザーステーションからユーザーステーションへのトラフィックに最適なルーティングを提供することは不可欠ではないと仮定します。このトラフィックが最初にゲートウェイに送信され、次に衛星ネットワークに戻ると、トラフィック量が非常に低い限り、一部のオペレーターには受け入れられる可能性があります。このタイプのルーティングについては、このドキュメントではこれ以上説明していません。
We assume that traffic for a user station should enter the satellite network through a gateway that is in some close geographic proximity to the user station. This is to reduce the number of ISLs used by the path to the user station. Similarly, we assume that user station traffic should exit the satellite network through the gateway that is in the closest geographic proximity to the user station. Jurisdictional requirements for landing traffic in certain regions may alter these assumptions, but such situations are outside the scope of this document.
ユーザーステーションのトラフィックは、ユーザーステーションに近接しているゲートウェイを介して衛星ネットワークに入る必要があると仮定します。これは、ユーザーステーションへのパスで使用されるISLの数を減らすためです。同様に、ユーザーステーションのトラフィックは、ユーザーステーションに最も近い地理的に近いゲートウェイを介して衛星ネットワークを終了する必要があると仮定します。特定の地域へのトラフィックを着陸するための管轄区域の要件は、これらの仮定を変更する可能性がありますが、そのような状況はこのドキュメントの範囲外です。
This architecture does not preclude gateway-to-gateway traffic across the satellite constellations, but it does not seek to optimize it.
このアーキテクチャは、衛星星座全体のゲートウェイからゲートウェイへのトラフィックを排除するものではありませんが、最適化しようとはしません。
The user station is an entity whose operation is conceptually shared between the satellite constellation operator and the operator of the cluster of end stations it serves. For example, the user station is trusted to attach MPLS label stacks to end-user packets. It gets the information to do so from some combination of its direct satellite and its local gateway via protocols outside the scope of this document. Equally, it bootstraps communication via an exchange with the current local satellite so that it can find and communicate with its local gateway -- again with the details of how that is done being outside the scope of this document.
ユーザーステーションは、衛星星座オペレーターとそれが提供するエンドステーションのクラスターのオペレーターとの間で概念的に共有されるエンティティです。たとえば、ユーザーステーションは、MPLSラベルスタックをエンドユーザーパケットに添付することが信頼されています。このドキュメントの範囲外のプロトコルを介して、直接衛星とローカルゲートウェイの何らかの組み合わせから情報を取得します。同様に、現在のローカル衛星との交換を介して通信をブートストラップして、ローカルゲートウェイを見つけて通信できるようにします。これは、このドキュメントの範囲外で行われる方法の詳細を再度備えています。
User stations that can concurrently access multiple satellites are not precluded by this proposal but are not discussed in detail.
複数の衛星に同時にアクセスできるユーザーステーションは、この提案によって排除されることはありませんが、詳細には説明されていません。
We assume that links in general will be available when scheduled. As with any network, there will be failures, and the schedule is not a guarantee, but we also expect that the schedule is mostly accurate. We assume that at any given instant, there are enough working links and aggregate bandwidth to run the network and support the traffic demand. If this assumption does not hold, no routing architecture can magically make the network more capable.
一般的にリンクがスケジュールされると利用可能になると仮定します。他のネットワークと同様に、失敗が発生し、スケジュールは保証ではありませんが、スケジュールはほとんど正確であると予想しています。任意の瞬間に、ネットワークを実行してトラフィック需要をサポートするのに十分な作業リンクと集約帯域幅があると仮定します。この仮定が保持されない場合、ルーティングアーキテクチャは魔法のようにネットワークをより有能にすることはできません。
Satellites that are in the same orbit may be connected by ISLs. These are called "intra-orbit" ISLs. Satellites that are in different orbits may also be connected by ISLs. These are called "inter-orbit" ISLs. Generally, we assume that intra-orbit ISLs have higher reliability and persistence than inter-orbit ISLs.
同じ軌道上の衛星は、ISLによって接続される場合があります。これらは「軌道内」ISLと呼ばれます。異なる軌道にある衛星は、ISLによって接続される場合があります。これらは「軌道間」ISLと呼ばれます。一般に、軌道内ISLは、軌道間ISLよりも信頼性と持続性が高いと想定しています。
We assume that the satellite network is connected (in the graph theory sense) almost always, even if some links are down. This implies that there is almost always some path to the destination. In the extreme case with no such path, we assume that it is acceptable to drop the payload packets. We do not require buffering of traffic when a link is down. Instead, traffic should be rerouted.
いくつかのリンクがダウンしていても、衛星ネットワークが（グラフ理論の意味で）接続されていると仮定します。これは、ほとんど常に目的地への道があることを意味します。そのようなパスがない極端な場合、ペイロードパケットをドロップすることは許容できると仮定します。リンクがダウンしている場合、トラフィックのバッファリングは必要ありません。代わりに、トラフィックを再ルーティングする必要があります。
The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network. This architecture must convey topology information to relevant portions of the network. This enables path computation that is used for data forwarding. The architecture must also scale without global changes to the organizational structure.
ルーティングアーキテクチャの目標は、衛星ネットワークで実行されているプロトコルに組織構造を提供することです。このアーキテクチャは、トポロジー情報をネットワークの関連部分に伝える必要があります。これにより、データ転送に使用されるパス計算が可能になります。また、アーキテクチャは、組織構造をグローバルな変更せずにスケーリングする必要があります。
The end goal of a network is to deliver traffic. In a satellite network where the topology is in a continual state of flux and the user stations frequently change their association with the satellites, having a highly flexible and adaptive forwarding plane is essential. Toward this end, we propose using MPLS as the fundamental forwarding plane architecture [RFC3031]. Specifically, we propose using an approach based on Segment Routing (SR) [RFC8402] with an MPLS data plane [RFC8660], where each satellite is assigned a node Segment Identifier (SID). This allows the architecture to support both IPv4 and IPv6 concurrently. A path through the network can then be expressed as a label stack of node SIDs. IP forwarding is not used within the internals of the satellite network, although each satellite may be assigned an IP address for management purposes. Existing techniques may be used to limit the size of the SR label stack so that it only contains the significant waypoints along the path [Giorgetti]. The label stack operates as a loose source route through the network. If there is an unexpected topology change in the network, the IGP will compute a new path to the next waypoint, allowing packet delivery despite ISL failures. While the IGP is converging, there may be micro-loops in the topology. These can be avoided by using Topology Independent Loop-Free Alternate (TI-LFA) paths [SR-TI-LFA]; otherwise, traffic will loop until discarded based on its TTL.
ネットワークの最終目標は、トラフィックを配信することです。トポロジーが継続的なフラックス状態にある衛星ネットワークでは、衛星との関連を頻繁に変更するため、非常に柔軟で適応的な転送面を持つことが不可欠です。この目的に向けて、MPLSを基本的な転送面アーキテクチャとして使用することを提案します[RFC3031]。具体的には、MPLSデータプレーン[RFC8660]を使用して、セグメントルーティング（SR）[RFC8402]に基づくアプローチを使用して提案します。各衛星には、ノードセグメント識別子（SID）が割り当てられています。これにより、アーキテクチャはIPv4とIPv6の両方を同時にサポートできます。ネットワークを通るパスは、ノードSIDのラベルスタックとして表現できます。IP転送は、衛星ネットワークの内部内では使用されませんが、各衛星には管理目的でIPアドレスが割り当てられる場合があります。既存の手法を使用して、SRラベルスタックのサイズを制限して、パスに沿った重要なウェイポイントのみを含むようにします[Giorgetti]。ラベルスタックは、ネットワークを通るゆるいソースルートとして動作します。ネットワークに予期しないトポロジの変更がある場合、IGPは次のウェイポイントへの新しいパスを計算し、ISLの障害にもかかわらずパケット配信を可能にします。IGPが収束している間、トポロジーにはマイクロループがある可能性があります。これらは、トポロジに依存しないループフリーの代替（TI-LFA）パス[SR-TI-LFA]を使用することで回避できます。それ以外の場合、TTLに基づいて破棄されるまでトラフィックがループします。
We assume that there is a link-layer mechanism for a user station to associate with a satellite. User stations will have an IP address assigned from a prefix managed by its local gateway. The mechanisms for this assignment and its communication to the end station are not discussed herein but might be similar to DHCP [RFC2131]. User station IP addresses change infrequently and do not reflect their association with their first-hop satellite. Gateways and their supporting terrestrial networks advertise prefixes covering all its local user stations throughout the global Internet.
ユーザーステーションが衛星に関連付けるためのリンク層メカニズムがあると仮定します。ユーザーステーションには、ローカルゲートウェイによって管理されたプレフィックスからIPアドレスが割り当てられています。この割り当てのメカニズムとエンドステーションへの通信はここでは説明されていませんが、DHCP [RFC2131]に類似している可能性があります。ユーザーステーションIPアドレスはまれに変更されており、最初のホップ衛星との関連性を反映していません。ゲートウェイとそのサポートする陸生ネットワークは、グローバルインターネット全体のすべてのローカルユーザーステーションをカバーするプレフィックスを宣伝しています。
User stations may be assigned a node SID, in which case MPLS forwarding can be used for all hops to the user station. Alternatively, if the user station does not have a node SID, then the last hop from the satellite to the end station can be performed based on the destination IP address of the packet. This does not require a full longest-prefix-match lookup, as the IP address is merely a unique identifier at this point.
ユーザーステーションにノードSIDが割り当てられる場合があります。この場合、MPLS転送はすべてのホップにユーザーステーションへのホップに使用できます。または、ユーザーステーションにノードSIDがない場合、衛星からエンドステーションまでの最後のホップは、パケットの宛先IPアドレスに基づいて実行できます。これには、IPアドレスはこの時点で単独の識別子にすぎないため、これには完全に長いプレフィックスマッチの検索を必要としません。
Similarly, gateways may be assigned a node SID. A possible optimization is that a single SID value could be assigned as a global constant to always direct traffic to the topologically closest gateway. If traffic engineering is required for traffic that is flowing to a gateway, a specific path may be encoded in a label stack that is attached to the packet by the user station or by the first-hop satellite.
同様に、ゲートウェイにノードSIDを割り当てることができます。最適化の可能性は、単一のSID値をグローバル定数として割り当てて、トポロジカルに最も近いゲートウェイに常にトラフィックを向けることができることです。ゲートウェイに流れるトラフィックに交通工学が必要な場合、特定のパスは、ユーザーステーションまたはファーストホップ衛星によってパケットに取り付けられたラベルスタックにエンコードされる場合があります。
Gateways can also perform traffic engineering using different paths and label stacks for separate traffic flows. Routing a single traffic flow across multiple paths has proven to cause performance issues with transport protocols, so that approach is not recommended. Traffic engineering is discussed further in Section 6.
ゲートウェイは、異なるパスを使用してトラフィックエンジニアリングを実行し、個別のトラフィックフローのラベルスタックを実行することもできます。複数のパスを横切る単一のトラフィックフローをルーティングすると、輸送プロトコルでパフォーマンスの問題を引き起こすことが証明されているため、そのアプローチは推奨されません。トラフィックエンジニアリングについては、セクション6でさらに説明します。
As discussed in Section 2.3, IS-IS is architecturally the best fit for satellite networks but does require some novel approaches to achieve the scalability goals for a satellite network. In particular, we propose that all nodes in the network be L1L2 so that local routing is done based on L1 information and then global routing is done based on L2 information.
セクション2.3で説明したように、IS-ISは衛星ネットワークに最適ですが、衛星ネットワークのスケーラビリティ目標を達成するためにいくつかの新しいアプローチが必要です。特に、ネットワーク内のすべてのノードはL1L2であるため、L1情報に基づいてローカルルーティングが行われ、グローバルルーティングがL2情報に基づいて行われることを提案します。
An interesting property of IS-IS is that it does not require interface addresses. This feature is commonly known as "unnumbered interfaces". This is particularly helpful in satellite topologies because it implies that ISLs may be used flexibly. Sometimes an interface might be used as an L1 link to another satellite, and a few orbits later, it might be used as an L1L2 link to a completely different satellite without any reconfiguration or renumbering.
IS-ISの興味深い特性は、インターフェイスアドレスを必要としないことです。この機能は、一般的に「非仮定インターフェイス」として知られています。これは、ISLが柔軟に使用される可能性があることを意味するため、衛星トポロジーで特に役立ちます。インターフェイスが別の衛星へのL1リンクとして使用される場合があり、数軌道の後に、再構成や変更なしで完全に異なる衛星へのL1L2リンクとして使用される場合があります。
Scalability for IS-IS can be achieved through a proposal known as "Area Proxy" [RFC9666]. With this proposal, all nodes in an L1 area combine their information into a single L2 Link State Protocol Data Unit (LSP). This implies that the size of the L1 Link State Database (LSDB) scales as the number of nodes in the L1 area and the size of the L2 LSDB scales with the number of L1 areas.
IS-ISのスケーラビリティは、「エリアプロキシ」[RFC9666]として知られる提案を通じて実現できます。この提案により、L1領域内のすべてのノードは、情報を単一のL2リンク状態プロトコルデータユニット（LSP）に組み合わせます。これは、L1リンク状態データベース（LSDB）のサイズがL1領域のノードの数として、L2 LSDBスケールのサイズがL1領域のサイズとしてスケーリングすることを意味します。
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 greatly reduced.
領域のプロキシでは、L1エリア内のトポロジカルな変化は他の領域には見えないため、リンク状態の変更のオーバーヘッドは大幅に削減されます。
The Area Proxy proposal also includes the concept of an Area SID. This is useful because it allows traffic engineering to construct a path that traverses areas with a minimal number of label stack entries.
エリアプロキシ提案には、エリアSIDの概念も含まれています。これは、トラフィックエンジニアリングが最小限のラベルスタックエントリを持つエリアを横断するパスを構築できるため、便利です。
For example, suppose that a network has 1,000 L1 areas, each with 1,000 satellites. This would mean that the network supports 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 numbers today. The resulting MPLS label table would contain 1,000 node SIDs from the L1 (and L2) LSDB and 1,000 area SIDs from the L2 LSDB. If each satellite advertises an IP address for management purposes, then the IP routing table would have 1,000 entries for the L1 management addresses and 1,000 area proxy addresses from L2.
たとえば、ネットワークに1,000のL1エリアがあり、それぞれ1,000の衛星エリアがあると仮定します。これは、ネットワークが1,000,000の衛星をサポートしていることを意味しますが、L1 LSDBには1,000のエントリとL2 LSDBの1,000エントリのみが必要であり、今日は簡単に達成可能な数字です。結果のMPLSラベルテーブルには、L1（およびL2）LSDBの1,000ノードSIDとL2 LSDBの1,000エリアSIDが含まれます。各衛星が管理目的でIPアドレスを宣伝している場合、IPルーティングテーブルには、L1管理アドレスの1,000エントリとL2の1,000エリアプロキシアドレスがあります。
In this proposal, IS-IS does not carry IP routes other than those in the satellite topology. In particular, there are no IP routes for user stations or the remainder of the Internet.
この提案では、IS-ISは衛星トポロジー以外のIPルートを搭載していません。特に、ユーザーステーションまたはインターネットの残りのIPルートはありません。
A significant problem with any link-state routing protocol is that of area partition. While there have been many proposals for automatic partition repair, none has seen notable production deployment. It seems best to avoid this issue and ensure areas have an extremely low probability of partitioning.
リンク状態のルーティングプロトコルの重要な問題は、エリアパーティションの問題です。自動パーティション修理には多くの提案がありましたが、顕著な生産展開を見た人はいません。この問題を回避し、領域がパーティション化の可能性が非常に低いことを確認するのが最善のようです。
As discussed above, intra-orbit ISLs are assumed to have higher reliability and persistence than inter-orbit ISLs. However, even intra-orbit ISLs are not sufficiently reliable to avoid partition issues. Therefore, we propose to group a small number of adjacent orbits as an IS-IS L1 area, called a "stripe". We assume that for any given reliability requirement, there is a small number of orbits that can be used to form a stripe that satisfies the reliability requirement.
上記のように、軌道内ISLは、軌道間ISLよりも高い信頼性と持続性があると想定されています。ただし、軌道内ISLでさえ、パーティションの問題を回避するのに十分な信頼性がありません。したがって、「ストライプ」と呼ばれるIS-IS L1領域として少数の隣接する軌道をグループ化することを提案します。特定の信頼性要件について、信頼性要件を満たすストライプを形成するために使用できる少数の軌道があると仮定します。
Stripes are connected to other adjacent stripes using the same ISL mechanism, forming the L2 topology of the network. Each stripe should have multiple L2 connections and never become partitioned from the remainder of the network.
ストライプは、同じISLメカニズムを使用して他の隣接するストライプに接続されており、ネットワークのL2トポロジを形成します。各ストライプには複数のL2接続があり、ネットワークの残りの部分から分割されることはありません。
By using a stripe as an L1 area, in conjunction with Area Proxy, the overhead of the architecture is greatly reduced. Each stripe contributes a single LSP to the L2 LSDB, completely hiding all the details about the satellites within the stripe. The resulting architecture scales proportionately to the number of stripes required, not the number of satellites.
ストライプをL1エリアとして使用することにより、エリアプロキシと併せて、アーキテクチャのオーバーヘッドが大幅に削減されます。各ストライプは、L2 LSDBに単一のLSPを提供し、ストライプ内の衛星に関するすべての詳細を完全に隠しています。結果として生じるアーキテクチャは、衛星の数ではなく、必要なストライプの数に比例してスケールします。
Groups of MEO and GEO satellites with interconnecting ISLs can also form an IS-IS L1L2 area. Satellites that lack intra-constellation ISLs are better as independent L2 nodes.
ISLを相互接続するMEOおよびGEO衛星のグループは、IS-IS L1L2領域を形成することもできます。コンセル内ISLを欠く衛星は、独立したL2ノードとして優れています。
The forwarding architecture presented here is straightforward. A path from a gateway to a user station on the same stripe only requires a single node SID for the satellite that provides the downlink to the user station.
ここに示されている転送アーキテクチャは簡単です。A path from a gateway to a user station on the same stripe only requires a single node SID for the satellite that provides the downlink to the user station.
\
Gateway --> X
\
\
X
\
\
X ---> x User Station
\
Figure 2: On-Stripe Forwarding
図2：ストライプ上の転送
Similarly, a user station returning a packet to a gateway need only provide a gateway node SID.
同様に、ゲートウェイにパケットを返すユーザーステーションは、ゲートウェイノードSIDのみを提供する必要があります。
For off-stripe forwarding, the situation is a bit more complex. A gateway would need to provide the area SID of the final stripe on the path plus the node SID of the downlink satellite. For return traffic, user stations or first-hop satellites would want to provide the area SID of the stripe that contains the satellite that provides access to the gateway as well as the gateway SID.
ストライプ外転送の場合、状況はもう少し複雑です。ゲートウェイは、パス上の最後のストライプのエリアSIDとダウンリンク衛星のノードSIDを提供する必要があります。返品トラフィックの場合、ユーザーステーションまたはファーストホップ衛星は、ゲートウェイとゲートウェイSIDへのアクセスを提供する衛星を含むストライプのエリアSIDを提供したいと思うでしょう。
Source S
|
|
V
Internet
|
|
V \
Gateway L --> X
\
\ \
X --- X
\ \
\ \ Area A
X --- X
\ \
\
U ---> D User Station
\
Figure 3: Off-Stripe Forwarding
図3：ストライプ外転送
As an example (Figure 3), consider a packet from an Internet source (Source S) to a user station (D). A local gateway (Gateway L) has injected a prefix covering D into BGP and has advertised it globally. The packet is forwarded to L using IP forwarding. When L receives the packet, it performs a lookup in a pre-computed forwarding table. This contains a SID list for the user station that has already been converted into a label stack. Suppose the user station is currently associated with a different stripe so that the label stack will contain an area label (A) and a label (U) for the satellite associated with the user station, resulting in a label stack (A, U).
例として（図3）、インターネットソース（ソースS）からユーザーステーション（D）までのパケットを検討してください。ローカルゲートウェイ（ゲートウェイL）は、DをBGPにカバーする接頭辞を注入し、グローバルに宣伝しています。パケットは、IP転送を使用してLに転送されます。Lがパケットを受信すると、事前に計算された転送テーブルでルックアップを実行します。これには、すでにラベルスタックに変換されているユーザーステーションのSIDリストが含まれています。ユーザーステーションが現在別のストライプに関連付けられているため、ラベルスタックにユーザーステーションに関連付けられた衛星のエリアラベル（a）とラベル（U）が含まれ、ラベルスタック（a、u）になります。
The local gateway forwards this into the satellite network. The 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 topology. This forwarding continues until the packet reaches a satellite adjacent to the destination area. That satellite pops label A, removing that label and forwarding the packet into the destination area.
ローカルゲートウェイは、これを衛星ネットワークに転送します。最初のホップ衛星は、スタックの上部にあるエリアラベル（a）に基づいて前方になりました。すべてのエリアラベルは、L2トポロジの一部として伝播されます。この転送は、パケットが宛先エリアに隣接する衛星に到達するまで続きます。その衛星はラベルAをポップし、そのラベルを削除し、パケットを宛先エリアに転送します。
The packet is now forwarded based on the remaining label U, which was propagated as part of the L1 topology. The last satellite forwards the packet based on the destination address (D) and forwards the packet to the user station.
パケットは、L1トポロジの一部として伝播された残りのラベルUに基づいて転送されます。最後の衛星は、宛先アドレス（d）に基づいてパケットを転送し、パケットをユーザーステーションに転送します。
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 the local gateway (L), resulting in the stack (A', L). The forwarding mechanisms are similar to the previous case.
リターンケースは似ています。この場合、ラベルスタックは、ローカルゲートウェイのストライプ/エリア（a '）のラベルとローカルゲートウェイ（L）のラベルで構成されており、スタック（a'、l）になります。転送メカニズムは、以前のケースに似ています。
Very frequently, access networks congest due to over-subscription and the economics of access. Network operators can use traffic engineering to ensure that they get higher efficiency out of their networks by utilizing all available paths and capacity near any congestion points. In this particular case, the gateway will have information about all of the traffic it is generating and can use all of the possible paths through the network in its topological neighborhood. Since we're already using SR, this is easily done by adding more explicit SIDs to the label stack. These can be additional area SIDs, node SIDs, or adjacency SIDs. Path computation can be performed by Path Computation Elements (PCEs) [RFC4655].
非常に頻繁に、アクセス過剰とアクセスの経済性により、ネットワークが混雑します。ネットワークオペレーターは、トラフィックエンジニアリングを使用して、混雑ポイントの近くで利用可能なすべてのパスと容量を利用することにより、ネットワークからより高い効率を得ることができます。この特定のケースでは、ゲートウェイには、生成されているすべてのトラフィックに関する情報があり、トポロジ周辺のネットワークを介したすべての可能なパスを使用できます。すでにSRを使用しているため、これはラベルスタックにより明示的なSIDを追加することで簡単に実行できます。これらは、追加のエリアSID、ノードSID、または隣接SIDにすることができます。パス計算は、PATH計算要素（PCES）[RFC4655]によって実行できます。
Each gateway or its PCE will need topological information from the areas it will route through. It can do this by participating in the IGP directly, via a tunnel, or through another delivery mechanism such as BGP-LS [RFC9552]. User stations do not participate in the IGP.
各ゲートウェイまたはそのPCEには、ルーティングされるエリアからのトポロジー情報が必要です。これは、IGPに直接、トンネルを介して、またはBGP-LSなどの別の送達メカニズムを介して参加することで行うことができます[RFC9552]。ユーザーステーションはIGPに参加しません。
Traffic engineering for packets flowing into a gateway can also be provided by an explicit SR path. This can help ensure that ISLs near the gateway do not congest with traffic for the gateway. These paths can be computed by the gateway or PCE and then distributed to the first-hop satellite or user station, which would apply them to traffic. The delivery mechanism is outside the scope of this document.
ゲートウェイに流れるパケットのトラフィックエンジニアリングは、明示的なSRパスによって提供されることもできます。これにより、ゲートウェイの近くのISLがゲートウェイのトラフィックと混雑しないようにすることができます。これらのパスは、ゲートウェイまたはPCEによって計算されてから、トラフィックに適用するファーストホップ衛星またはユーザーステーションに配布できます。配信メカニズムは、このドキュメントの範囲外です。
The most significant difference between terrestrial and satellite networks from a routing perspective is that some of the topological changes that will happen to the network can be anticipated and computed. Both link and node changes will affect the topology, and the network should react smoothly and predictably.
ルーティングの観点からの地上および衛星ネットワークの最も重要な違いは、ネットワークに起こるトポロジカルな変化のいくつかを予測して計算できることです。リンクとノードの変更の両方がトポロジに影響を与え、ネットワークはスムーズかつ予測可能に反応する必要があります。
The management plane is responsible for providing information about scheduled topological changes. The exact details of how the information is disseminated are outside the scope of this document but could be shown through a YANG model [YANG-SCHEDULE]. Scheduling information needs to be accessible to all of the nodes that will make routing decisions based 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 area and information about L2 changes will need to propagate to all L2 nodes) and to the gateways and PCEs that carry the related topological information.
管理プレーンは、スケジュールされたトポロジカル変更に関する情報を提供する責任があります。情報がどのように広まっているかの正確な詳細は、このドキュメントの範囲外であるが、ヤンモデル[Yang-schedule]を介して表示できる。スケジューリング情報は、スケジュールのトポロジカル変更に基づいてルーティング決定を下すすべてのノードにアクセスできる必要があります（つまり、L1トポロジーの変化に関するデータは、L1領域のすべてのノードとL2の変更に関する情報に循環する必要がありますすべてのL2ノードと、関連するトポロジ情報を運ぶゲートウェイとPCEに伝播する必要があります。
There is very little that the network should do in response to a topological addition. A link coming up or a node joining the topology should not have any functional change until the change is proven to be fully operational based on the usual IS-IS liveness mechanisms. Nodes may pre-compute their routing table changes but should not install them before all relevant adjacencies are received. The benefits of this pre-computation appear to be very small. Gateways and PCEs may also choose to pre-compute paths based on these changes but should not install paths using the new parts of the topology until they are confirmed to be operational. If some path pre-installation is performed, gateways and PCEs must be prepared for the situation where the topology fails to become operational and may need to take alternate steps instead, such as reverting any related pre-installed paths.
トポロジの追加に応じてネットワークがすべきことはほとんどありません。トポロジーに参加するリンクまたはノードは、通常のIS liveningメカニズムに基づいて変更が完全に動作することが証明されるまで、機能的な変更を持たないはずです。ノードはルーティングテーブルの変更を事前に計算する場合がありますが、関連するすべての隣接が受信される前にそれらをインストールしないでください。この再計算の利点は非常に小さいようです。ゲートウェイとPCESは、これらの変更に基づいてパスを事前に計算することも選択できますが、トポロジが動作することが確認されるまで、トポロジの新しい部分を使用してパスをインストールしないでください。何らかのパスのプリインストールが実行された場合、トポロジが動作することができず、代わりに代わりに、関連するプリインストールされたパスを戻すなど、代わりに代わりに措置を講じる必要がある場合にゲートウェイとPCESを準備する必要があります。
The network may choose not to pre-install or pre-compute routes in reaction to topological additions, at a small cost of some operational efficiency.
ネットワークは、ある程度の運用効率のコストで、トポロジーの追加に反応してルートを事前に計算または事前計算しないことを選択できます。
Topological deletions are an entirely different matter. If a link or node is to be removed from the topology, the network should act before the anticipated change to route traffic around the expected topological loss. Specifically, at some point before the topology change, the affected links should be set to a high metric to direct traffic to alternate paths. This is a common operational procedure in existing networks when links are taken out of service, such as when proactive maintenance needs to be performed. This type of change does require some time to propagate through the network, so the metric change should be initiated far enough in advance that the network converges before the actual topological change. Gateways and PCEs should also update paths around the topology change and install these changes before the topology change occurs. The time necessary for both IGP and path changes will vary depending on the exact network and configuration.
トポロジーの削除はまったく異なる問題です。リンクまたはノードがトポロジから削除される場合、予想されるトポロジー損失の周りにトラフィックをルーティングするための予想される変更の前にネットワークが動作する必要があります。具体的には、トポロジが変更される前のある時点で、影響を受けるリンクを高いメートルに設定して、交通を代替パスに向ける必要があります。これは、プロアクティブなメンテナンスを実行する必要がある場合など、リンクが使用されていない場合の既存のネットワークでの一般的な運用手順です。このタイプの変更には、ネットワークを介して伝播するのにしばらく時間がかかるため、実際のトポロジー変更の前にネットワークが収束するように、メトリックの変更を十分に前もって開始する必要があります。また、ゲートウェイとPCESは、トポロジの変更の周りのパスを更新し、トポロジの変更が発生する前にこれらの変更をインストールする必要があります。IGPとパスの両方の変更に必要な時間は、正確なネットワークと構成によって異なります。
Strictly speaking, changing to a high metric should not be necessary. It should be possible for each router to exclude the link and recompute paths. However, it seems safer to change the metric and use the IGP methods for indicating a topology change, as this can help avoid issues with incomplete information dissemination and synchronization.
厳密に言えば、高いメートル法に変更する必要はありません。各ルーターがリンクを除外し、パスを再計算することができるはずです。ただし、メトリックを変更し、IGPメソッドを使用してトポロジの変化を示す方が安全であるように思われます。これは、不完全な情報普及と同期の問題を回避するのに役立つためです。
This architecture needs to be validated by satellite operators, both via simulation and operational deployment. Meaningful simulation hinges on the exact statistics of ISL connectivity; currently, that information is not publicly available.
このアーキテクチャは、シミュレーションと運用展開の両方を介して、衛星オペレーターによって検証される必要があります。意味のあるシミュレーションは、ISL接続の正確な統計にかかっています。現在、その情報は公開されていません。
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.
ISLに関する現在の利用可能な情報は、リンクが機械的に操縦されており、リンクの反対側を継続的に追跡する必要があることを示しています。実際にサポートできる角度と距離は不明であり、変化率に関する制限も同様です。
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,000 mph (55,000 kph). Links in this situation may not be possible or may be so short-lived that they are impractical.
軌道内および軌道上のISLリンクは非常に異なる特性を持つことが期待されています。軌道内リンクははるかに安定しているはずですが、陸生リンクよりもはるかに安定性が低いはずです。軌道間リンクの安定性は低くなります。ほぼ平行な衛星間のリンクは可能ですが、おそらく限られた期間があります。2つの軌道はほぼ直交する可能性があり、その結果、接続の可能性が限られています。Finally, in some topologies there may be parallel orbits where the satellites move in opposite directions, giving a relative speed between satellites around 34,000 mph (55,000 kph).この状況のリンクは不可能な場合もあれば、それほど短命である可能性があるため、非現実的です。
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.
対処すべき重要な質問は、特定のネットワークのパラメーターが、IGPのスケーリング境界内で機能する安定した接続された領域を生成するストライプ割り当てを生成できるかどうかです。リンクが非常に安定している場合、ストライプはほんの数百の衛星を持つほんの数個の平行軌道である可能性があります。ただし、リンクが不安定な場合、ストライプは、特定のIGPの実装のスケーリング制限を超えている可能性のある数十の軌道と数千の衛星を包含する必要がある場合があります。
The network behind a gateway is expected to be a normal terrestrial network. Conventional routing architectural principles apply. An obvious approach would be to extend IS-IS to the terrestrial network, applying L1 areas as necessary for scalability.
ゲートウェイの背後にあるネットワークは、通常の陸生ネットワークになると予想されます。従来のルーティングアーキテクチャの原則が適用されます。明らかなアプローチは、IS-Iを地上ネットワークに拡張し、スケーラビリティに必要なL1領域を適用することです。
The terrestrial network may have one or more BGP connections to the broader Internet. Prefixes for user stations should be advertised to the Internet near the associated gateway. If gateways are not interconnected by the terrestrial network, then it may be advisable to use one autonomous system per gateway as it might simplify the external perception of the network and subsequent policy considerations. Otherwise, one autonomous system may be used for the entire terrestrial network.
地上ネットワークには、より広いインターネットへの1つ以上のBGP接続がある場合があります。ユーザーステーションのプレフィックスは、関連するゲートウェイの近くのインターネットに宣伝する必要があります。ゲートウェイが地上ネットワークによって相互接続されていない場合、ネットワークの外部認識とその後のポリシー考慮事項を簡素化する可能性があるため、ゲートウェイごとに1つの自律システムを使用することをお勧めします。それ以外の場合、1つの自律システムを陸生ネットワーク全体に使用できます。
This document discusses one possible routing architecture for satellite networks. It proposes no new protocols or mechanisms and thus has no new security impact. Security for IS-IS is provided by [RFC5304] and [RFC5310].
このドキュメントでは、衛星ネットワーク用の1つの可能なルーティングアーキテクチャについて説明します。新しいプロトコルやメカニズムは提案されていないため、新しいセキュリティへの影響はありません。IS-ISのセキュリティは[RFC5304]および[RFC5310]によって提供されます。
User stations will interact directly with satellites, potentially using proprietary mechanisms, and under the control of the satellite operator, who is responsible for the security of the user station.
ユーザーステーションは、衛星と直接対話し、潜在的に独自のメカニズムを使用し、ユーザーステーションのセキュリティを担当する衛星オペレーターの制御下にあります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[ISO10589] ISO/IEC, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC9666] Li, T., Chen, S., Ilangovan, V., and G. Mishra, "Area
Proxy for IS-IS", RFC 9666, DOI 10.17487/RFC9666, October
2024, <https://www.rfc-editor.org/info/rfc9666>.
[Bell] Bell, A. G., "On the Production and Reproduction of Sound
by Light", American Journal of Science, vol. S3-20, no.
118, pp. 305-324, DOI 10.2475/ajs.s3-20.118.305, October
1880, <https://ajsonline.org/article/64037>.
[Cao] Cao, X., Li, Y., Xiong, X., and J. Wang, "Dynamic Routings
in Satellite Networks: An Overview", Sensors, vol. 22, no.
12, pp. 4552, DOI 10.3390/s22124552, 2022,
<https://www.mdpi.com/1424-8220/22/12/4552/
pdf?version=1655449925>.
[CNN] Wattles, J., "Elon Musk's SpaceX now owns about a third of
all active satellites in the sky", CNN Business, 11
February 2021, <https://www.cnn.com/2021/02/11/tech/
spacex-starlink-satellites-1000-scn/index.html>.
[Giorgetti]
Giorgetti, A., Castoldi, P., Cugini, F., Nijhof, J.,
Lazzeri, F., and G. Bruno, "Path Encoding in Segment
Routing", 2015 IEEE Global Communications Conference
(GLOBECOM), DOI 10.1109/GLOCOM.2015.7417097, December
2015, <https://ieeexplore.ieee.org/document/7417097>.
[Handley] Handley, M., "Delay is Not an Option: Low Latency Routing
in Space", HotNets '18: Proceedings of the 17th ACM
Workshop on Hot Topics in Networks, pp. 85-91,
DOI 10.1145/3286062.3286075, November 2018,
<https://dl.acm.org/doi/10.1145/3286062.3286075#>.
[ITU] ITU, "Radio Regulations - Articles", 2024,
<https://search.itu.int/history/HistoryDigitalCollectionDo
cLibrary/1.49.48.en.101.pdf#search=radio%20regulation>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[SR-TI-LFA]
Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
19, 22 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-19>.
[Westphal] Westphal, C., Han, L., and R. Li, "LEO Satellite
Networking Relaunched: Survey and Current Research
Challenges", arXiv:2310.07546v1,
DOI 10.48550/arXiv.2310.07646, October 2023,
<https://arxiv.org/pdf/2310.07646.pdf>.
[YANG-SCHEDULE]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
03, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-03>.
[Zhang] Zhang, X., Yang, Y., Xu, M., and J. Luo, "ASER: Scalable
Distributed Routing Protocol for LEO Satellite Networks",
2021 IEEE 46th Conference on Local Computer Networks
(LCN), DOI 10.1109/LCN52139.2021.9524989, 2021,
<https://doi.org/10.1109/LCN52139.2021.9524989>.
The author would like to thank Dino Farinacci, Olivier De jonckere, Eliot Lear, Adrian Farrel, Acee Lindem, Erik Kline, Sue Hares, Joel Halpern, Marc Blanchet, and Dean Bogdanovic for their comments.
著者は、ディノ・ファリナッチ、オリビエ・デ・ジョンケレ、エリオット・リア、エイドリアン・ファレル、エイシー・リンデム、エリック・クライン、スー・ハレス、ジョエル・ハルパーン、マーク・ブランシェ、ディーン・ボグダノビッチにコメントに感謝したいと思います。
Tony Li
Juniper Networks
Email: tony.li@tony.li