RFC9717: 衛星ネットワークのルーティング・アーキテクチャ

要旨

衛星ネットワークは、パケット・ネットワークにとって興味深い課題を提示する。トポロジー全体が絶えず動いており、リンクの信頼性は地上ネットワークの一般的なものよりはるかに低い。軌道力学によって、リンクの接続性に何らかの変化が生じることが予想される。

本文書は、既存のルーティング・プロトコルとメカニズムに基づく定期的なリンク接続性変更情報によって強化された、衛星ネットワーク用のスケーラブルなルーティング・アーキテクチャを提案する。本文書ではプロトコルの変更は提案しない。

本文書は著者の見解を示すものであり、IETFの成果物でもコミュニティの合意に基づく見解でもない。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではなく、情報提供を目的で公開する。

これは、他のRFCストリームとは独立したRFCシリーズへの寄稿である。RFCエディタは、本文書を独自の裁量で公開することを選択したものであり、実装や展開における価値について表明するものではない。RFCエディタによって公開が承認された文書は、インターネット標準のいかなるレベルの候補にはならない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9721で入手できる。

著作権に関する通知

Copyright (c) 2025 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。

1. はじめに

衛星ネットワークは、パケット・ネットワークにとって興味深い課題を提示する。トポロジー全体が絶えず動いており、リンクの信頼性は地上ネットワークの一般的なものよりはるかに低い。軌道力学によって、リンクの接続性に何らかの変化が生じることが予想される。

本文書は、既存のルーティング・プロトコルとメカニズムに基づき、定期的なリンク接続性変更情報によって強化された、衛星ネットワーク用のスケーラブルなルーティング・アーキテクチャを提案する。本文書ではプロトコルの変更は提案しない。

大規模な衛星ネットワークが展開されつつあり、従来のルーティング・プロトコルで予期しなかった応用を提起している。意図的なトポロジーの変更頻度の高さと考えられないような規模は、地上のネットワークでは前例のないものである。衛星間のリンクは、自由な接続を可能にする自由空間光学技術を利用できる。それでも、リンクの範囲や太陽との関連による制限があるため、ネットワーク設計者が慣れ親しんだものよりもはるかに信頼性が低いリンクとなる。さらに、リンクはエンドポイントを動的に変更できるため、トポロジーの構造的変化が生じる。

現在の衛星ネットワークは独自のものであり、一般に分析や議論に利用できる情報はほとんどない。本文書は現在アクセス可能な情報に基づいている。

本文書は、現在の標準ベースのルーティング技術を利用して、このようなネットワークのルーティング・アーキテクチャを、トポロジーの急速な変化を考慮しながらネットワークのスケーラビリティを実現する解決策を提供する1つのアプローチを提案する。本文書は、衛星ネットワーク・オペレータに初期ガイダンスを提供することを目的としているが、具体的な詳細がないため、より完全な分析と設計のための基礎を提供することしかできない。

本文書は著者の見解を示すものであり、IETFの成果物でもコミュニティの合意に基づく見解でもない。

1.1. 関連研究

関連研究のサーベイが[Westphal]にある。衛星ネットワークのリンク・ステート・ルーティングは[Cao]と[Zhang]で検討されている。

1.2. 用語と略語

コンステレーション: 衛星の集合

ダウンリンク: 衛星から地球局までの地上リンクの半分を指す

地球局: 地球表面上または表面近くにあり、衛星へのリンクを持つネットワークのノード。これには、LEO[ITU]以下の船舶、航空機、その他乗り物も含まれる。

ゲートウェイ: ネットワークに参加し、衛星コンステレーションと惑星ネットワーク間の相互接続の役割を果たす地球局。ゲートウェイは、ユーザ・ステーションよりもはるかに高い帯域幅を持ち、十分なコンピューティング能力を持ち、トラフィック・エンジニアリングの義務を遂行し、ネットワーク・コントローラやパス計算要素(PCE)[RFC4655]の機能を包含する。複数のゲートウェイが存在すると想定され、それぞれがネットワークの一部にサービスを提供する。

GEO: 地球静止軌道。静止軌道にある衛星は、惑星の自転と同期した軌道を持ち、実質的には惑星上の1つの場所に留まる

地上リンク: 衛星と地球局の間のリンクで、ダウンリンクとアップリンクで構成される

IGP: 内部ゲートウェイ・プロトコル。単一の管理ドメイン内で使われるルーティング・プロトコル。この文脈での「ゲートウェイ」は意味的には「ルータ」と等価であり、本文書の他の部分で使われる「ゲートウェイ」とは無関係であることに留意する。

IS-IS: Intermediate System to Intermediate System。サービス・プロバイダで一般的に使用されているIGP[ISO10589] [RFC1195]。

ISL: 衛星間リンク。媒体を介さずに光子を使って信号を送信できる自由空間光学系でよく実装される[Bell]。

L1: IS-ISレベル1

L1L2: IS-ISレベル1とレベル2

L2: IS-ISレベル2

LEO: 地球低軌道。LEOにある衛星の高度は2,000キロ以下である

ローカル・ゲートウェイ: 各ユーザ・ステーションは、その地域の1つのゲートウェイに関連付けられる

LSP: リンク・ステート・プロトコル・データ・ユニット。IS-IS LSPは、ノードと他のノードとの接続を記述するパケット・セットである

MEO: 地球中軌道。MEOの衛星はLEOとGEOの間にあり、高度は2,000キロから35,786キロの間にある

SID: セグメント識別子[RFC8402]

ストライプ: 隣接するいくつかの軌道にある衛星の集合。これらはIS-IS L1エリアを形成する

SR: セグメント・ルーティング[RFC8402]

アップリンク: 地球局から衛星につながるリンクの半分

ユーザ・ステーション: 小規模なエンド・ユーザ・ネットワークと相互接続された地球局

2.概要

2.1. トポロジー的な考察

衛星は、親惑星の周りを固有の軌道で周回している。衛星の中には、軌道周期が惑星の自転と同期しているものがあり、実質的に1点の上で静止している。他の衛星は、惑星の領域を徐々にまたは非常に急速に移動する軌道を持つ。これらは通常、高度によって静止軌道(GEO)、中軌道(MEO)、低軌道(LEO)と呼ばれる。この議論は地球に固有のものではない。他の惑星に行くことで、このアプローチの一般性をテストすることができる。

衛星は、衛星間リンク(ISL)を通じてデータを相互接続することができる。軌道の違いにより、ISLが一時的に接続されることがあり、軌道力学によって可能な接続期間が計算される。複数の衛星が同じ軌道上にあるが、空間的にほぼ一定の間隔で離れていることがある。同じ軌道にある衛星は、異なる軌道間のISLよりもデューティ・サイクルが高いISLを持つことがあるが、それでも常に接続されている保証はない。

図1: 全体的なネットワーク・アーキテクチャ

地球局は、その地域にある1つ以上の衛星と通信できる。ユーザ・ステーションは、一度に1つの衛星としか通信できない限られた容量の地球局である。より豊富な接続性と高い帯域幅を持つ他の地球局は、一般に「ゲートウェイ」と呼ばれ、衛星ネットワークと従来の有線ネットワークとの接続を提供する。ゲートウェイは、地理的に近いユーザ・ステーションにサービスを提供し、カバレッジを提供し、サービス密度の目標を達成するために、必要に応じてグローバルに複製される(replicated)。ユーザ・ステーションは、単一のローカル・ゲートウェイに関連付けられる。1つの地球局から別の地球局へのトラフィックは、ISLを介して複数の衛星を横断するパスが必要になる場合がある。

2.2. リンクの変化

従来のネットワーク・リンクのように、ISLや地上リンクは警告なしに故障することがある。しかし、地上リンクとは異なり、ISLや地上リンクが接続されたり、切断されたりする可能性があるタイミングは予測可能である。これらの予測は、関連するネットワーク要素に配布できるスケジュールで計算し、カタログ化することができる。リンクの接続予測は保証されない。リンクはさまざまな理由で接続されない可能性がある。軌道力学によるリンク切断の予測は、基礎となる物理が予期せず改善されることがないため、事実上保証される。

2.3. スケーラビリティ

衛星ネットワークの中には、数万基の衛星が提案されているかなり大規模なものもある[CNN]。重要な懸念事項は、役立つネットワークは大きくなる傾向にあるため、この規模以上に到達できるかどうかである。

ご存知のように、スケーラビリティの鍵は階層的な抽象化を作成する能力であるため、ルーティング・アーキテクチャの重要な問題は、トポロジー情報を含む抽象化を作成できるかどうかである。

通常のルーティング・プロトコルは、静的だがやや信頼性の低いトポロジーで動作するように設計されている。衛星ネットワークには、地上ネットワークのような静的な構成がないため、スケーラビリティのための通常のアーキテクチャの慣例が適用されない可能性があり、別のアプローチを検討する必要があるかもしれない。

リンク・ステート・ルーティング・プロトコルの一般的な展開では、現在の実装は、数千台のルータにまたがる単一エリアで展開できる。単一のエリアでは、トポロジーの変更に対する分離が提供されないため、すべてのリンクの変化がネットワーク全体に伝播されることになる。これは、大規模な衛星ネットワークのニーズには不十分である。

スケーラビリティを向上させるために、複数エリアや内部ゲートウェイ・プロトコル(IGP)の複数インスタンスを使用することができるが、一般的なアプローチには制限がある。

現在、IETFはOSPF[RFC2328] [RFC5340]とIS-ISの2つのリンク・ステートIGPを積極的にサポートしている。

OSPFは、ネットワークがバックボーン・エリアを中心に動作し、補助エリアはバックボーンにぶら下がる必要がある。これは一般的な地上ネットワークではうまく機能するが、トポロジーの中央集権部分がない衛星ネットワークには適していないようだ。

IS-ISはOSPFとは異なる階層構造を持っており、レベル1 (L1)エリアはノードの集合に接続され、レベル2(L2)はすべてのL1エリアと交差するトポロジーのサブセットに接続される。個々のノードは、L1、L2、またはその両方(L1L2)のいずれかになる。一般的なIS-ISの設計では、L2エリア間のトランジットとして使用されるノードやリンクは、L2トポロジの一部としなければならない。衛星ネットワークでは、どの衛星もL2トランジットに使用される可能性があるため、すべての衛星とリンクがL2の一部となり、IS-ISの階層構造によるスケーラビリティの利点が失われる。

IS-ISに特有の考慮事項については、セクション4で詳しく説明する。

2.4. 前提

本セクションでは、このアーキテクチャの提案の基礎となるいくつかの前提について説明する。

データ・ペイロードはIPパケットである

衛星はネットワークのコントロール・プレーンとデータ・プレーンに積極的に参加し、プロトコルに参加し、パケットを転送する。

各ゲートウェイの背後には、地上ネットワークが存在し、より広範なインターネットと相互接続する可能性がある。地上ネットワークのアーキテクチャは、典型的なIS-ISおよびBGP展開[RFC4271]であると想定され、本文書ではこれ以上説明しない。

衛星ネットワークは、ユーザ・ステーションとゲートウェイを相互接続する。衛星ネットワークと他のネットワーク・オペレータの衛星ネットワーク間の相互接続は、本文書の範囲外である。

2.4.1. トラフィック・パターン

衛星ネットワークの主な用途は、広範囲にわたる地理的場所からのアクセスを提供することであると想定している。また、ピア・ネットワーク間の高帯域幅のバルク・トランジットを提供することは目的ではないことも想定している。[Handley]の研究では、衛星ネットワークは地上のファイバ・ネットワークよりもレンテイシが低いことが指摘されている。本提案は、そのようなアプリケーションを排除するものではないが、ユーザ・ステーションが適切なトラフィック・エンジニアリング計算を実行するために必要なメカニズムを明確に示していない。低レイテンシ、マルチキャスト、エニーキャストのアプリケーションについては、本文書ではこれ以上説明しない。

ほとんどのアクセス・ネットワークと同様に、ユーザ・ステーションとゲートウェイの間には双方向のトラフィックが発生するが、トラフィックの大部分はゲートウェイからユーザ・ステーションに向かうものになると想定する。ゲートウェイから衛星ネットワークへのアップリンクが帯域幅のボトルネックとなり、ゲートウェイから到達可能な衛星の容量には限界があるため、アップリンクの帯域幅を拡張するにはゲートウェイを複製する必要がある。

ユーザ・ステーションからユーザ・ステーションへのトラフィックに最適なルーティングを提供することは必須ではないと想定している。このトラフィックがまずゲートウェイに送信され、その後、衛星ネットワークに戻される場合、トラフィック量が非常に少なければ、一部のオペレータには受け入れられる可能性がある。このタイプのルーティングについては、本文書ではこれ以上説明しない。

ユーザ・ステーションのトラフィックは、ユーザ・ステーションに地理的に近いゲートウェイを介して衛星ネットワークに入るものと想定する。これは、ユーザ・ステーションへのパスで使用されるISLの数を減らすためである。同様に、ユーザ・ステーションのトラフィックは、ユーザ・ステーションに地理的に最も近いゲートウェイを介して衛星ネットワークから出るものと想定する。特定の地域における着陸トラフィックに関する管轄区域の要件により、これらの想定が変わる可能性もあるが、そのような状況は本文書の範囲外である。

このアーキテクチャは、衛星コンステレーションをまたぐゲートウェイ間のトラフィックを排除するものではないが、それを最適化することを目的とするものではない。

2.4.2. ユーザ・ステーションの制約

ユーザ・ステーションは、概念的には、衛星コンステレーション・オペレータと、それがサービスを提供するエンド・ステーションのクラスタ・オペレータの間で運用が共有されるエンティティである。例えば、ユーザ・ステーションは、エンド・ユーザ・パケットにMPLSラベル・スタックをアタッチすることを信頼されている。この情報は、本文書の範囲外のプロトコルを介して、直接衛星とローカル・ゲートウェイの組み合わせから取得する。同様に、ローカル・ゲートウェイを見つけて通信できるように、現在のローカル衛星との交換を介して通信をブートストラップする。これも、その方法の詳細については、本文書の範囲外である。

複数の衛星に同時にアクセスできるユーザ・ステーションは、本提案では排除するものではないが、詳細については議論しない。

2.4.3. 確率的接続性

一般的に、リンクは定期的に利用可能になると仮定する。どのようなネットワークでも障害が発生する可能性があり、スケジュールは保証されないが、スケジュールはほぼ正確であることも前提としている。ネットワークを稼働させてトラフィック需要をサポートするには、どの時点においても、十分な稼働リンクと総帯域幅があることを前提としている。この前提が成り立たない場合、どんなルーティング・アーキテクチャも魔法のようにネットワークの能力を高めることはできない。

同じ軌道上にある衛星は、ISLで接続されることがある。これらは「軌道内」ISL と呼ばれる。異なる軌道にある衛星もISLで接続することができる。これらは「軌道間」ISLと呼ばれる。一般に、軌道内ISLは軌道間ISLよりも信頼性と持続性が高いと仮定する。

一部のリンクがダウンしていても、衛星ネットワークは(グラフ理論の意味で)ほぼ常に接続されていると仮定する。これは、宛先へのパスがほぼ常に存在することを意味する。そのようなパスがない極端なケースでは、ペイロード・パケットをドロップしても問題がないと仮定する。リンクがダウンしたときにトラフィックをバッファリングする必要はない。その代わり、トラフィックを再ルーティングする必要がある。

2.5. 問題の提起

ルーティング・アーキテクチャの目的は、衛星ネットワーク上で動作するプロトコルに組織構造を提供することである。このアーキテクチャは、ネットワークの関連部分にトポロジー情報を伝えなければならない。これにより、データ転送に使用されるパス計算が可能になる。また、このアーキテクチャは、組織構造を全体的に変更することなく拡張できなければならない。

3. フォワーディング・プレーン

ネットワークの最終目標はトラフィックを配信することである。トポロジーが絶えず変化し、ユーザ・ステーションと衛星との関連付けが頻繁に変更される衛星ネットワークでは、柔軟性が高く適応性の高いフォワーディング・プレーンが不可欠である。この目的のために、基本的なフォワーディング・プレーン・アーキテクチャとしてMPLSを使用することを提案する[RFC3031]。具体的には、セグメント・ルーティング(SR)[RFC8402]とMPLSデータ・プレーン[RFC8660]に基づくアプローチを使用することを提案する。このアプローチでは、各衛星にノード・セグメント識別子(SID)が割り当てられる。これにより、アーキテクチャはIPv4とIPv6の両方を同時にサポートすることができる。ネットワークを通るパスは、ノードSIDのラベル・スタックとして表現できる。各衛星には、管理目的でIPアドレスが割り当てられるが、衛星ネットワークの内部ではIPフォワーディングは使用されない。SRラベル・スタックのサイズを制限するため、既存の手法を使用して、パスに沿った重要なウェイポイントのみを含むようにできる[Giorgetti]。ラベル・スタックは、ネットワーク全体の緩やかなソース・ルートとして動作する。ネットワークで予期しないトポロジーの変更があった場合、IGPは次のウェイポイントへの新しいパスを計算し、ISLの障害があってもパケットの配送を可能にする。IGPが収束している間、トポロジーにマイクロ・ループが発生する可能性がある。これは、トポロジーに依存しないループ・フリー代替(TI-LFA)パス[SR-TI-LFA]を使用することで回避できる。そうしないと、トラフィックはTTLによって破棄されるまでループしてしまう。

ユーザ・ステーションが衛星と関連付けるためのリンク層メカニズムがあると仮定する。ユーザ・ステーションは、ローカル・ゲートウェイが管理するプレフィックスから割り当てられたIPアドレスを持つ。この割り当てとエンド・ステーションへの通信メカニズムについてはここでは説明しないが、DHCP[RFC2131]に似ているかもしれない。ユーザ・ステーションのIPアドレスは頻繁に変更されず、最初のホップの衛星との関連付けを反映されない。ゲートウェイとそれをサポートする地上ネットワークは、グローバル・インターネット全体を通して、そのローカル・ユーザ・ステーションをカバーするプレフィックスを広告する。

ユーザ・ステーションにはノードSIDを割り当てることができ、その場合はユーザ・ステーションへのすべてのホップにMPLSフォワーディングを使用することができる。あるいは、ユーザ・ステーションにノードSIDを持たない場合、衛星からエンド・ステーションへの最後のホップは、パケットの宛先IPアドレスに基づいて実行できる。この場合、IPアドレスは単なる一意の識別子であるため、完全な最長プレフィックス一致検索は必要ない。

同様に、ゲートウェイにはノードSIDを割り当てることができる。可能な最適化は、単一のSID値をグローバル定数として割り当て、常にトポロジー的に最も近いゲートウェイにトラフィックを誘導することが考えられる。ゲートウェイに流れるトラフィックにトラフィック・エンジニアリングが必要な場合は、ユーザ・ステーションまたはファースト・ホップの衛星によってパケットに付加されるラベル・スタックに特定のパスをエンコードすることができる。

ゲートウェイは、個別のトラフィック・フローに対して異なるパスとラベル・スタックを使用してトラフィック・エンジニアリングを実行することもできる。単一のトラフィック・フローを複数のパスにルーティングすると、トランスポート・プロトコルのパフォーマンス問題を引き起こすことが証明されているため、このアプローチは推奨されない。トラフィック・エンジニアリングについては、セクション6でさらに詳しく説明する。

4. IGPの適合性とスケーラビリティ

セクション2.3で説明したように、IS-ISはアーキテクチャ的には衛星ネットワークに最適だが、衛星ネットワークのスケーラビリティ目標を達成するにはいくつかの新しいアプローチが必要である。特に、ローカル・ルーティングがL1情報に基づいて行われ、その後、グローバル・ルーティングがL2情報に基づいて行われるように、ネットワーク内のすべてのノードをL1L2にすることを提案する。

IS-ISの興味深い特性は、インタフェース・アドレスを必要としないことである。この機能は一般に「アンナンバード・インタフェース」として知られている。これは、ISLを柔軟に使用できることを意味するので、衛星トポロジーで特に役立つ。あるインタフェースが別の衛星へのL1リンクとして使用され、数軌道後には、再構成やリナンバリングなしに、まったく別の衛星へのL1L2リンクとして使用することもある。

IS-ISのスケーラビリティは、「エリア・プロキシ」[RFC9666]と呼ばれる提案を通じて実現できる。この提案では、L1エリア内のすべてのノードが、それらの情報を1つのL2リンク・ステート・プロトコル・データ・ユニット(LSP)に結合する。これは、L1リンク・ステート・データベース(LSDB)のサイズがL1エリア内のノード数に比例し、L2 LSDBのサイズがL1エリアの数に比例することを意味する。

エリア・プロキシを使用すると、L1エリア内のトポロジーの変更は他のエリアからは見えないため、リンク状態の変更によるオーバーヘッドは大幅に削減される。

エリア・プロキシの提案には、エリアSIDの概念も含まれている。これは、トラフィック・エンジニアリングが最小限の数のラベル・スタック・エントリでエリアを横断するパスを構築できるため有用である。

例えば、ネットワークに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のエリア・プロキシ・アドレスを持つことになる。

この提案では、IS-ISは衛星トポロジー内のIP経路以外のIP経路を伝送しない。特に、ユーザ・ステーションやインターネットの残りの部分のIP経路を持たない。

5. ストライプとエリア

リンク・ステート・ルーティング・プロトコルの重大な問題は、エリア分割である。自動パーティション修復の提案は数多くあるが、目立った実用配備に至ったものはない。この問題を回避し、エリアが分割される可能性を極めて低いことを保証するのが最善と思われる。

上で説明したように、軌道内ISLは軌道間ISLよりも信頼性と持続性が高いと想定される。しかし、軌道内ISLであっても、パーティション問題を回避するには十分な信頼性があるとは言えない。そこで、隣接する少数の軌道を「ストライプ」と呼ばれるIS-IS L1エリアとしてグループ化することを提案する。特定の信頼性要件に対して、信頼性要件を満たすストライプを形成するために使用できる少数の軌道が存在すると仮定する。

ストライプは、同じISLメカニズムを用いて隣接する他のストライプに接続され、ネットワークのL2トポロジーを形成する。各ストライプは複数のL2接続があり、ネットワークの残りの部分からパーティション化されることはない。

ストライプをL1エリアとして使用し、エリア・プロキシと組み合わせることで、アーキテクチャのオーバーヘッドは大幅に削減される。各ストライプはL2 LSDBに単一のLSPを提供し、ストライプ内の衛星に関するすべての詳細を完全に隠す。その結果、アーキテクチャは衛星の数ではなく、必要なストライプの数に比例してスケールする。

相互接続ISLを持つMEO衛星とGEO衛星のグループも、IS-IS L1L2エリアを形成できる。コンステレーション内ISLを持たない衛星は、独立したL2ノードとして使用する方が適している。

6. トラフィック転送とトラフィック・エンジニアリング

ここで紹介するフォワーディング・アーキテクチャは単純である。ゲートウェイから同じストライプ上のユーザ・ステーションへのパスは、ユーザ・ステーションへのダウンリンクを提供する衛星の単一のノードSIDを必要とするだけである。

図2: オン・ストライプ転送

同様に、ゲートウェイにパケットを返すユーザ・ステーションは、ゲートウェイ・ノードSIDを提供するだけでよい。

オフ・ストライプ転送の場合、状況はもう少し複雑になる。ゲートウェイは、パス上の最後のストライプのエリアSIDとダウンリンク衛星のノードSIDを提供する必要がある。戻りトラフィックの場合、ユーザ・ステーションまたはファースト・ホップの衛星は、ゲートウェイへのアクセスを提供する衛星を含むストライプのエリアSIDとゲートウェイSIDを提供する必要がある。

図3: オフ・ストライプ転送

例(図3)として、インターネットのソース(ソースS)からユーザ・ステーション(D)へのパケットについて考える。ローカル・ゲートウェイ(ゲートウェイL)がDをカバーするプレフィックスをBGPに注入し、それをグローバルに広告している。パケットはIPフォワーディングを使ってLに転送される。Lはパケットを受信すると、事前に計算されたフォワーディング・テーブルの検索を実行する。これには既にラベル・スタックに変換済みのユーザ・ステーションのSIDリストが含まれている。ラベル・スタックには、エリア・ラベル(A)と、ユーザ・ステーションに関連する衛星のラベル(U)が含まれ、結果としてラベル・スタック(A, U)となる。

ローカル・ゲートウェイはこれを衛星ネットワークに転送する。ファースト・ホップの衛星は、スタックの最上位にあるエリア・ラベル(A)に基づいて転送する。すべてのエリア・ラベルは、L2トポロジーの一部として伝搬される。この転送は、パケットが宛先エリアに隣接する衛星に到達するまで続く。その衛星はラベルAをポップし、そのラベルを取り除き、パケットを宛先エリアに転送する。

パケットは、L1トポロジーの一部として伝搬された残りのラベルUに基づいて転送される。最後の衛星は、宛先アドレス(D)に基づいてパケットを転送し、パケットをユーザ・ステーションに転送する。

戻りの場合も同様である。この場合のラベル・スタックは、ローカル・ゲートウェイのストライプ/エリアのラベル(A')とローカル・ゲートウェイのラベル(L)で構成され、スタック(A'、L)が生成される。フォワーディング・メカニズムは、前のケースと同様である。

アクセス・ネットワークは、過剰な加入やアクセスの経済性により、頻繁に輻輳する。ネットワーク・オペレータは、トラフィック・エンジニアリングを使用して、輻輳ポイント付近の利用可能なすべてのパスと容量を活用することで、ネットワークの効率性を高めることができる。この特定のケースでは、ゲートウェイは生成するすべてのトラフィックに関する情報を持ち、トポロジー的に近隣にあるネットワークを通るすべての可能なパスを使用できる。SRを既に使用しているため、ラベル・スタックに明示的なSIDを追加することで簡単に実現できる。追加できるSIDには、エリアSID、ノードSID、または隣接SIDがある。パス計算は、パス計算エレメント(PCE)によって実行できる([RFC4655])。

各ゲートウェイまたはそのPCEは、ルーティングするエリアのトポロジー情報を必要とする。これは、IGPに直接参加するか、トンネル経由で参加するか、BGP-LS [RFC9552]などの別の配信メカニズムを介して行うことができる。ユーザ・ステーションはIGPには参加しない。

ゲートウェイに流入するパケットのトラフィック・エンジニアリングは、明示的なSRパスによっても提供できる。これにより、ゲートウェイの付近のISLがゲートウェイのトラフィックで混雑しないようにすることができる。これらのパスはゲートウェイまたはPCEで計算され、ファースト・ホップの衛星またはユーザ・ステーションに配布して、トラフィックに適用することができる。配信メカニズムは、本文書の範囲外である。

7. スケジュール

ルーティングの観点から見た場合、地上ネットワークと衛星ネットワークの最も大きな違いは、衛星ネットワークはネットワークに発生するトポロジーの変更の一部を予測して計算できることである。リンクとノードのどちらの変更もトポロジーに影響を与えるため、ネットワークはスムーズかつ予測どおりに反応すべきである。

マネジメント・プレーンは、定期的にトポロジー変更に関する情報を提供する役割を担っている。情報がどのように伝達されるかの正確な詳細は本文書の範囲外だが、YANGモデル[YANG-SCHEDULE]を通じて示すことができる。スケジュール情報は、スケジュール内のトポロジー変更に基づいてルーティング決定を行うすべてのノード(つまり、L1トポロジー変更に関するデータは、L1エリア内のすべてのノードに配信する必要があり、L2変更に関する情報はすべてのL2ノードに伝播される必要がある)と、関連するトポロジー情報を運ぶゲートウェイおよび PCEにアクセスできる必要がある。

トポロジーの追加に対して、ネットワークが行うべきことはほとんどない。リンクが追加されたり、ノードがトポロジーに参加しても、通常のIS-ISのライブ・メカニズムに基づいて変更が完全に機能することが証明されるまで、機能的な変更は一切行うべきではない。ノードはルーティング・テーブルの変更を事前計算しておくことはできるが、関連するすべての隣接ノードからの応答を受信する前に、それらの変更をインストールしてはならない。この事前計算の利点は非常に小さいと思われる。ゲートウェイとPCEもこれらの変更に基づいてパスを事前計算することを選択できるが、トポロジーの新しい部分を使用してパスをインストールする場合は、それらが機能することが確認されるまではインストールすべきではない。パスの事前インストールを実行する場合、ゲートウェイとPCEは、トポロジーが動作不能になり、代わりに関連する事前インストールされたパスを元に戻すなどの代替手順を行う必要がある状況に備える必要がある。

ネットワークは、運用効率を多少犠牲にしても、トポロジーの追加に応じて経路の事前インストールや事前計算を行わないという選択ができる。

トポロジーの削除はまったく別の問題である。リンクやノードをトポロジーから削除する場合、予想されるトポロジー損失を回避してトラフィックをルーティングするために、ネットワークが予想される変更に先立って対応する必要がある。具体的には、トポロジーの変更が行われる前に、影響を受けるリンクに高いメトリック値を設定して、トラフィックを代替パスに誘導する必要がある。これは、予防的なメンテナンスを実行する必要があるときなど、リンクがサービスから外される場合に、既存のネットワークでよく行われる運用手順である。このタイプの変更はネットワーク全体に反映されるまでに時間を要するため、実際のトポロジー変更の前にネットワークが収束するように、メトリックの変更は十分な余裕をもって開始する必要がある。ゲートウェイとPCEも、トポロジー変更を回避してパスを更新し、トポロジー変更が発生する前にこれらの変更をインストールする必要がある。IGPとパスの変更の両方に必要な時間は、ネットワークと構成によって異なる。

厳密に言えば、高いメトリックに変更する必要はない。各ルータがリンクを除外し、パスを再計算することは可能である。しかし、メトリックを変更し、トポロジーの変更を示すためにIGP方式を使用する方が安全であると思われる。これにより、不完全な情報の配布や同期に関する問題を回避できる。

8. 今後の取り組み

このアーキテクチャは、衛星オペレータによるシミュレーションと実運用展開の両面で検証する必要がある。意味のあるシミュレーションには、ISL接続の正確な統計情報が必要だが、現在、その情報は一般には公開されていない。

ISLに関する現在入手可能な情報では、リンクは機械的に制御され、リンクの反対側のエッジを継続的に追跡する必要がある。実用上サポート可能な角度や距離は不明であり、変化の速度に関する制限も不明である。

軌道内および軌道間ISLリンクは、非常に異なる特性を持つことが予想される。軌道内リンクは地上リンクよりはるかに安定しているはずだが、それでも地上リンクよりもはるかに不安定である。軌道間リンクは安定性は低いだろう。ほぼ平行な衛星間のリンクは可能だが、おそらく持続時間は限られる。2つの軌道はほぼ直交している可能性があり、その結果、接続の可能性は限られる。最後に、一部のトポロジーでは、衛星が反対方向に移動する平行軌道が存在する可能性があり、衛星間の相対速度は約34,000 mph (55,000 kph)になる。この状況でのリンクは不可能か、あるいは非常に短命で実用的ではない可能性がある。

対処すべき重要な問題は、特定のネットワークのパラメータが、IGPのスケーリング制限内で機能する安定した接続領域を生み出すストライプ割り当てが可能かどうかである。リンクが非常に安定している場合、ストライプは数百基の衛星で構成される数本の平行軌道になる可能性がある。しかし、リンクが不安定な場合は、ストライプが数十基の軌道と数千基の衛星を網羅する必要があり、特定のIGP実装のスケーリングの制限を超える可能性がある。

9. 展開に関する考慮事項

ゲートウェイの背後にあるネットワークは、通常の地上ネットワークであることが想定される。従来のルーティング・アーキテクチャの原則が適用される。明らかなアプローチとしては、IS-ISを地上ネットワークに拡張し、必要に応じてL1エリアを適用してスケーラビリティを確保することが考えられる。

地上ネットワークは、より広範なインターネットへの1つ以上のBGP接続が存在する場合がある。ユーザ・ステーションのプレフィックスは、関連するゲートウェイの近くのインターネットに通知する必要がある。ゲートウェイが地上ネットワークによって相互接続されていない場合、ネットワークの外部からの認識と、その後のポリシーの検討を簡素化できるため、ゲートウェイごとに1つの自律システムを使用することが望ましい。それ以外の場合、地上ネットワーク全体に1つの自律システムを使用することができる。

10. セキュリティに関する考慮事項

本文書では、衛星ネットワークのルーティング・アーキテクチャの1つの可能性について説明する。新しいプロトコルやメカニズムを提案するものではないため、新たなセキュリティ上の影響はない。IS-ISのセキュリティは、[RFC5304]と[RFC5310]によって提供されている。

ユーザ・ステーションは、独自仕様のメカニズムを使用する可能性があり、ユーザ・ステーションのセキュリティに責任を負う衛星オペレータの制御下で、衛星と直接やり取りする。

11. IANAに関する考慮事項

本文書には、IANAによるアクションはない。

12. 参考文献

12.1. 引用規格

[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.

12.2.参考規格

[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/HistoryDigitalCollectionDocLibrary/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.

謝辞

著者は、ディノ・ファリナッチ、オリビエ・デ・ジョンクレ、エリオット・リア、エイドリアン・ファレル、エーセー・リンデム、エリック・クライン、スー・ハリス、ジョエル・ハルパーン、マルク・ブランシェ、ディーン・ボグダノヴィッチらのコメントに感謝する。

著者のアドレス

トニー・リー
Juniper Networks
アドレス: [e-mail]

変更履歴

• 2025.2.1