ネットワーク・プロトコル#112

宇宙向けソフトウェア定義ネットワーキング(SDN) — 制御プレーンを衛星から切り離す

SDRが変えたのは信号処理という物理層の中身でした。この回で扱うのは1つ上のレイヤー、すなわち「パケットをどこへ転送すべきか」を決める論理そのものです。データプレーンとコントロールプレーンを分離するSDNの発想を、絶えず組み替わるメガコンステレーションのトポロジに適用する発想と、伝搬遅延がその発想に突きつける固有の制約を数式で理解します。

前提知識: SDR — 受信機をハードウェアからソフトウェアへ溶かし込む、IP over CCSDS — 宇宙リンクの上でインターネットプロトコルそのものを走らせる

SDNOpenFlow制御プレーンメガコンステレーションネットワーク最適化

この回で学ぶこと

SDRの回では、アナログのミキサ・フィルタ・VCOという物理的な回路が担っていた仕事を、サンプリング定理に基づくデジタル演算に置き換える設計思想を見ました。あれは受信機という物理層の中身を、専用ハードウェアからソフトウェアへ溶かし込む話でした。ミキシングも、フィルタリングも、PLLの位相追尾も、結局は「1つのリンクの中で、どうやって正しくビットを取り出すか」という、リンク単体で完結する問題です。

この回で扱うのは、まったく異なる階層の話です。衛星間リンク(ISL)の回やContact Graph Routingの回で見たように、現代の宇宙ネットワークは1本のリンクではなく、数百〜数千機の衛星が織りなすメッシュです。このメッシュの中で、「あるノードに届いたパケットを、次にどのリンクへ送り出すべきか」を決める論理——制御プレーン(control plane)——を、個々の衛星が積んだ専用のルーティングチップから切り離し、集中管理されたソフトウェアの上で柔軟に書き換えられるようにする。これが**ソフトウェア定義ネットワーキング(Software Defined Networking, SDN)**という考え方です。

SDRが「物理層のハードウェアをソフトウェアに置き換えた」のに対し、SDNは「ネットワーク層の制御ロジックをハードウェアから切り離す」話であり、扱っている対象のレイヤーが根本的に異なります。この回では地上のSDNの基本思想(データプレーンとコントロールプレーンの分離)を数式付きで整理したうえで、それがメガコンステレーションの動的なトポロジになぜ特に効くのか、そして深宇宙・地球周回を問わず宇宙ネットワークに固有の伝搬遅延という制約が、地上生まれのSDNの発想にどんな修正を迫るのかを見ていきます。

直感的導入: 「頭脳」をルータの筐体から引きはがす

伝統的なネットワーク機器(ルータやスイッチ)は、データプレーン(実際にパケットを1つずつ受け取り、指定されたポートへ転送するハードウェア処理)と、コントロールプレーン(「宛先Xへのパケットはポート3へ出す」という転送ルールそのものを決定するソフトウェア処理)の両方を、1つの筐体の中に同居させています。OSPFやBGPのようなルーティングプロトコルは、各ルータの中の小さなCPUが、隣接ルータとの情報交換(リンクステートの広告など)を通じて、自分の転送ルールを自分自身で計算するという、完全に分散した仕組みです。

SDNの発想はこれを分解します。データプレーンの機能(パケットを受け取って転送するだけの、単純だが高速なハードウェア)は各ノードに残しつつ、コントロールプレーンの機能(転送ルールを決定する頭脳)を、ネットワーク全体を見渡せる1つ(あるいは少数)の集中コントローラに集約するのです。各ノードは、コントローラから送られてくる転送ルールに従ってパケットを右から左に流すだけの「手足」になり、「どこに何を送るべきか」という判断はすべてコントローラ側のソフトウェアが担います。地上のデータセンターや広域網(WAN)で広く実用化されているこの発想を、絶えずトポロジが組み替わる宇宙ネットワークに応用しよう、というのがこの回の主題です。

定式化1: データプレーンとコントロールプレーンの分離

フローテーブルという抽象化

SDNのデータプレーン側のノード(スイッチ)は、フローテーブルと呼ばれる単純なルールの集合 $R = \{(m_i, p_i, a_i)\}_{i=1}^{K}$ を保持します。ここで $m_i$ はパケットヘッダに対するマッチ条件(たとえば「宛先アドレスが特定の範囲に入っている」)、 $p_i$ は優先度、 $a_i$ は「このポートへ転送する」「ヘッダを書き換える」「破棄する」といったアクションです。パケットのヘッダ $h$ がスイッチに到着すると、スイッチは次のルールを適用します。

a^{\star}(h) = a_{i^{\star}}, \qquad i^{\star} = \operatorname*{arg\,max}_{i:\ m_i \text{ が } h \text{ にマッチ}} p_i

つまり、パケットのヘッダにマッチするルールのうち、最も優先度の高いものが選ばれ、そのアクションが実行されます。これがOpenFlowに代表される、SDNのデータプレーン制御プロトコルの中核をなす抽象化です。スイッチ自身はこのマッチ・アクションの照合と実行だけを高速に行う専用ハードウェアであり、ルール $R$ 自体をどう決めるかにはいっさい関与しません。

サウスバウンドAPIとノースバウンドAPI

ルール $R$ を各スイッチに配布するのがコントローラの仕事です。コントローラとスイッチの間の通信インタフェースをサウスバウンドAPI(OpenFlowの flow-mod メッセージなどがこれにあたります)と呼び、コントローラがネットワーク全体のトポロジ情報 $G=(V,E,w)$ (ノード集合、リンク集合、各リンクの重みや残余容量などの属性)をアプリケーション側に公開するインタフェースをノースバウンドAPIと呼びます。経路最適化アプリケーションはノースバウンドAPI経由でネットワーク全体の状態を取得し、最適なルール集合 $R$ を計算し、サウスバウンドAPI経由でそれを各スイッチに書き込みます。

\underbrace{\text{アプリケーション}}_{\text{最適化ロジック}} \;\xrightarrow{\text{ノースバウンドAPI}}\; \underbrace{\text{コントローラ}}_{\text{ネットワーク全体の状態} \ G} \;\xrightarrow{\text{サウスバウンドAPI}}\; \underbrace{\text{各スイッチ}}_{\text{フローテーブル} \ R}

この分離の最大の価値は、ネットワーク全体を1つの最適化問題として解けることにあります。次節でこれを定式化して、分散型のルーティングとの違いを具体的に見ます。

分散型ルーティングとの違い: 局所最適 vs 大域最適

OSPFのような分散型リンクステートプロトコルでは、各ノードが自分のリンクステートデータベース(隣接関係とリンクコスト)をフラッディングで交換し、各ノードが独立にダイクストラ法を実行して自分の転送テーブルを計算します。これは各ノードにとっての最短経路を与えますが、ネットワーク全体で見たときに望ましい状態——たとえば「特定のリンクに流量が集中しすぎないようにする」という負荷分散——を保証しません。

これを負荷分散問題として定式化してみましょう。トラヒック需要行列を $D_{s,d}$ (送信元 $s$ から宛先 $d$ へのデータレート要求)、各リンク $e \in E$ の容量を $c_e$ とすると、ネットワーク全体で最大リンク利用率を最小化する問題は

\min_{\{f_{s,d}\}} \ \max_{e \in E} \ \frac{\sum_{(s,d):\, e \in \text{path}(s,d)} D_{s,d}}{c_e} \quad \text{s.t. フロー保存則}

という大域的な最適化問題として書けます。各ノードが自分のリンクコストだけを見て貪欲に最短経路を選ぶ分散型ルーティングでは、複数の独立したフローが「たまたま同じリンクを最短と判断してしまう」ことでこの $\max_e$ の項が不必要に悪化する状況を防げません。SDNコントローラはネットワーク全体の $G$ とトラヒック需要 $D$ を同時に見渡せるため、原理的にこの大域最適化問題を(多品種流問題として、あるいはその近似として)直接解き、各フローを意図的に迂回・分散させることができます。これがSDNが分散型ルーティングに対して持つ、性能面での本質的な優位性です。

定式化2: なぜメガコンステレーションで特に効くのか

衛星間リンク(ISL)の回で見たように、メガコンステレーションのトポロジは静的ではありません。同一軌道面内リンクは比較的安定している一方、軌道面間リンクは相対速度が大きく、リンク距離

R_{\text{cross-plane}}(t) = \left\lVert \vec{r}_1(t) - \vec{r}_2(t) \right\rVert

が時々刻々と変化し、指向限界や地球による遮蔽のためにハンドオーバーが周期的に必要になります。地上のOSPF的な分散ルーティングをそのままこの環境に適用すると、ハンドオーバーのたびに関係するノードすべてがリンクステートを再フラッディングし、各ノードが再びダイクストラ法を回すという収束の手順を、衛星の数だけ、しかも絶えず繰り返すことになります。この収束の間、一時的に矛盾した転送テーブル(ループやブラックホール)が生じうることは、地上の分散ルーティングでもよく知られた弱点です。

一方Contact Graph Routingの回で見たように、衛星の軌道要素は数週間〜数ヶ月先まで正確に予測できるため、将来のトポロジ変化はあらかじめ決定論的に計算できるという宇宙ネットワーク特有の性質があります。SDNの集中コントローラは、この予測可能性を活かして、CGRが使う接触機会の集合(コンタクトプラン)そのものをノースバウンドAPI経由で入力とし、ハンドオーバーが実際に起きる前に次のフローテーブルを計算・配布しておくことができます。

R(t) = \Phi\big(G_{\text{contact}}(t),\ D(t)\big)

ここで $\Phi$ はコントローラが実行する大域最適化ロジック、 $G_{\text{contact}}(t)$ は時刻 $t$ における接触グラフ(既知の軌道力学から予測可能)、 $D(t)$ はトラヒック需要です。CGRが「あらかじめ分かっている時刻表の上で、個々のノードが分散的に経路選択のための計算を行う」フレームワークだったのに対し、SDN的な発想は「あらかじめ分かっているトポロジ変化を先読みして、集中コントローラがネットワーク全体のフローテーブルを一括で計算し、それを能動的に配布する」という、CGRと補完関係にあるアプローチです。分散型プロトコルの収束待ちが原理的に発生しないぶん、トポロジが高頻度で変化するメッシュほど、この先読み配布の恩恵が大きくなります。

定式化3: 伝搬遅延という宇宙特有の壁

地上のデータセンター内SDN(コントローラとスイッチの間の伝搬遅延が数十マイクロ秒以下)を前提に設計された発想を、そのまま宇宙ネットワークに持ち込むと、致命的な問題にぶつかります。コントローラへの問い合わせ・応答そのものに、無視できない伝搬遅延がかかるのです。

コントローラが遠隔地(地上局、あるいは特定の中継衛星)にあり、フローテーブルの更新を必要とするスイッチ(衛星)までの経路が、コントローラとの往復伝搬遅延に加えて、ISLメッシュを $n_{hop}$ 回中継する必要があるとすると、制御ループ全体のレイテンシは概算で

\tau_{ctrl} \approx \underbrace{2\,\tau_{prop,\,ground}}_{\text{地上局↔ゲートウェイ衛星}} + \underbrace{n_{hop}\big(\tau_{prop,\,ISL} + \tau_{proc}\big)}_{\text{ISLメッシュ内の中継}} + \underbrace{\tau_{compute}}_{\text{コントローラの最適化計算}}

と書けます。具体的な数字で桁感をつかんでみましょう。高度 $h=550$ km のLEO衛星から直下の地上局までの片道伝搬遅延は

\tau_{prop} \approx \frac{h}{c} = \frac{550{,}000\ \text{m}}{3\times10^{8}\ \text{m/s}} \approx 1.83\ \text{ms}

程度ですが、これは最も近い(直下の)ケースにすぎません。コントローラを静止軌道(高度約35,786 km)に置く、あるいはGEO中継衛星経由でゲートウェイと接続する構成を考えると、片道の伝搬遅延だけで

\tau_{prop,\,GEO} \approx \frac{35{,}786{,}000\ \text{m}}{3\times10^{8}\ \text{m/s}} \approx 119\ \text{ms}, \qquad \text{往復で約} \ 239\ \text{ms}

に達します。さらに、対象の衛星が最寄りのゲートウェイ接続衛星から複数のISLホップだけ離れていれば、ISLの回で見た軌道面間リンクの距離(数千km規模)に応じて、1ホップあたり数ミリ秒の伝搬遅延がホップ数だけ積み上がります。データセンター内SDNが前提とする「往復レイテンシは無視できるほど小さい」という仮定は、宇宙ネットワークではまったく成り立ちません。

制御ループが有効であるための条件

SDRの回で、離散化されたPLLが連続時間の設計理論をそのまま使ってよい条件として $\omega_n T_s \ll 1$ (サンプリング周期がループの時定数に比べて十分短い)という不等式を導いたのを思い出してください。SDNの制御ループにも、構造的にまったく同じ形の条件が現れます。ネットワークの状態(輻輳・リンク断・ハンドオーバーなど)が意味のある形で変化する時間スケールを $\tau_{event}$ とすると、集中コントローラによる反応的な制御が有効であるためには、

\tau_{ctrl} \ll \tau_{event}

が満たされなければなりません。コントローラへの問い合わせ・計算・配布に要する時間 $\tau_{ctrl}$ が、ネットワーク状態が変化してしまう時間スケール $\tau_{event}$ に近づく、あるいはそれを超えると、コントローラが送り返してくるフローテーブルは配布された時点ですでに古い(その根拠となったトポロジがもう変わってしまっている)ものになり、制御ループとして意味を失います。地上のデータセンターでは $\tau_{ctrl}$ がマイクロ秒〜ミリ秒オーダー、 $\tau_{event}$ (サーバ障害やトラヒック急変の時間スケール)がそれよりずっと長いため、この不等式は楽に満たされます。しかし宇宙ネットワークでは、上で見た通り $\tau_{ctrl}$ 自体が数十〜数百ミリ秒に達しうる一方、ハンドオーバーや突発的なリンク断は同程度、あるいはそれより短い時間スケールで起きることがあり、この不等式が破れる場面が現実に生じます。

定式化4: ハイブリッドアーキテクチャ — 階層化された制御

$\tau_{ctrl} \ll \tau_{event}$ が破れる状況では、すべての判断を集中コントローラに委ねる純粋な反応的SDNは機能しません。実務的な解は、地上の広域網SDN(たとえばGoogleのB4のような大規模WAN)ですでに採られている階層化の発想を、宇宙ネットワークの事情に合わせて拡張することです。

速い時間スケールの判断(オンボード自律制御): リンク断の検出、緊急のフェイルオーバーといった、 $\tau_{event}$ が短い事象への対応は、集中コントローラへの問い合わせを待たず、各衛星(あるいは局所的な「ドメインコントローラ」)があらかじめ受け取っている複数の代替ルール(バックアップフローエントリ)の中から即座に切り替えることで処理します。これは中央への問い合わせなしに動く点で、地上の分散ルーティングに近い性質を持ちますが、あくまで集中コントローラがあらかじめ計算し配布しておいた選択肢の中から選ぶだけであり、経路そのものをゼロから再計算するわけではありません。
遅い時間スケールの判断(集中コントローラによる戦略的最適化): 前節で見た大域的な負荷分散や、既知の軌道力学に基づく将来のトポロジ変化への先読み対応など、 $\tau_{event}$ が長く $\tau_{ctrl}$ に対して十分な余裕がある問題は、地上局や特定の中継衛星に置かれた集中コントローラが、ネットワーク全体を見渡して定期的に(あるいはイベント駆動で)フローテーブルを再計算し、まとめて配布します。

R(t) = \underbrace{R_{\text{local}}(t)}_{\tau_{ctrl}^{\text{local}} \ll \tau_{event}^{\text{fast}} \text{ を満たす反応}} \ \cup \ \underbrace{R_{\text{global}}(t)}_{\tau_{ctrl}^{\text{global}} \ll \tau_{event}^{\text{slow}} \text{ を満たす反応}}

このハイブリッド構成は、SDRの回で見た「サンプリング周期が十分短ければ連続時間の設計理論をそのまま使え、そうでなければ設計を見直す」という条件分岐と本質的に同じ発想を、時間スケールごとに制御の主体(オンボード/集中コントローラ)を使い分けるという形でネットワーク制御の階層に適用したものだと理解できます。純粋な集中制御でも純粋な分散制御でもなく、時間スケールに応じてどちらの利点を取るかを設計上使い分けることが、宇宙SDNの実務上の要点です。

実務での使われ方

地上のSDN基盤

SDNの概念は2000年代後半、Stanford大学のClean Slateプロジェクトを源流とするOpenFlowプロトコルの提案(McKeownらによる2008年の論文)から本格的に広まり、現在はOpen Networking Foundation (ONF)がOpenFlow Switch Specificationを策定・維持しています。オープンソースのSDNコントローラ実装としてONOSやOpenDaylightが広く使われ、データセンターだけでなく広域網(WAN)にも適用が進んでいます。特にGoogleが自社のバックボーンWANに導入したB4は、集中コントローラによる大域的なトラヒックエンジニアリングによってリンク利用率を大幅に改善したことを報告した、実運用規模でのSDNの代表的な成功事例として知られています。この回で見た「分散型ルーティングの局所最適 vs SDNの大域最適」という対比は、まさにB4が地上のWANで実証した価値そのものです。

宇宙ネットワークへの応用: 研究段階から実証へ

衛星ネットワークへのSDN応用は、現時点では多くが研究・実証段階にあります。NASAのSCaN(Space Communications and Navigation)プログラムは、国際宇宙ステーション搭載の実験基盤(SCaN Testbed、旧称CoNNeCT)などを通じて、ソフトウェア無線・ソフトウェア定義の通信技術を軌道上で実証する取り組みを続けており、こうした基盤はSDR単体の実証にとどまらず、より上位のネットワーク制御をソフトウェア化する研究の土台にもなっています。学術界でも、IEEEの通信系ジャーナルを中心に「Software-Defined Satellite Networks」を主題とするサーベイ論文や、メガコンステレーションのISLメッシュにOpenFlow的な集中制御を適用するシミュレーション研究が数多く発表されており、この回で定式化した「伝搬遅延がSDNの反応的制御にどこまで制約を課すか」という問題は、それらの研究の中心的なテーマの1つになっています。

産業界の動きとしては、商用メガコンステレーション事業者(TelesatのLightspeedやOneWebなど)が、地上の運用センターでコンステレーション全体のルーティング・リソース割当を集中的に計算し、それを衛星群に配布するという運用形態を採っており、これは厳密な意味でのOpenFlow準拠SDNではないものの、制御プレーンを衛星から切り離し、地上の集中システムでネットワーク全体を最適化するというSDNの精神そのものを体現しています。なお、EutelsatのQuantum衛星のような「ソフトウェア定義衛星」は、ペイロード(ビーム形状・周波数割当・カバレッジ)を軌道上で再構成できるという別の意味での「ソフトウェア定義」であり、この回で扱ったネットワーク層の制御プレーン分離とは焦点が異なる点に注意してください。両者はしばしば同じ「ソフトウェア定義」という言葉でくくられますが、前者は物理層のペイロード構成、この回で扱ったのはネットワーク層の経路制御ロジックの分離です。

こうした背景から、地上のクラウドネットワーキングやデータセンターSDNで培われた技術(集中コントローラ、宣言的なネットワーク構成管理、Kubernetesに代表されるクラウドネイティブな運用手法)を宇宙システム、特に地上局ネットワークやミッション運用センターの構成管理に応用しようとする技術トレンドも近年強まっており、「ソフトウェア定義地上局(Software Defined Ground Station)」といった言葉も使われ始めています。

演習問題

高度 $h=550$ km のLEO衛星と、静止軌道(高度約 $35{,}786$ km)に置かれた集中コントローラとの間で、片道・往復の伝搬遅延をそれぞれ計算せよ。同じLEO衛星が直下の地上局(片道 $\tau_{prop} \approx 1.83$ ms)と通信する場合と比べて、GEOコントローラ方式では制御ループのレイテンシがおよそ何倍になるか概算せよ。
あるSDNスイッチのフローテーブルに、次の2つのルールが登録されているとする。ルールA: マッチ条件「宛先アドレスが $10.0.0.0/8$ に含まれる」、優先度 $100$ 、アクション「ポート1へ転送」。ルールB: マッチ条件「宛先アドレスが $10.1.0.0/16$ に含まれる」、優先度 $200$ 、アクション「ポート2へ転送」。宛先アドレス $10.1.2.3$ を持つパケットが到着したとき、本文中の判定式 $i^{\star} = \arg\max_i p_i$ (マッチするルールの中で優先度最大)に従うと、どちらのアクションが選ばれるか。また、もしルールBの優先度が $50$ だった場合はどうなるか、それぞれ理由とともに答えよ。
本文で導いた条件 $\tau_{ctrl} \ll \tau_{event}$ について、(a) 地上のデータセンター内SDN、(b) 静止軌道コントローラが直接制御するLEOメガコンステレーションSDN、の2つのケースについて、この不等式が成立しやすいかどうかをそれぞれ論じ、(b)のケースで不等式が破れがちな理由を、本文中の具体的な伝搬遅延の数値を用いて説明せよ。
Contact Graph Routingの回で学んだCGRと、この回のSDNの発想は、どちらも「軌道要素から将来のトポロジ変化を予測できる」という宇宙ネットワーク特有の性質を利用している。両者の違いを、「経路の計算主体(集中コントローラか、各ノードの分散計算か)」と「計算結果がいつノードに配布されるか」という2つの観点から、自分の言葉で整理せよ。

まとめと次回予告

この回では、SDRの回で扱った物理層のソフトウェア化とは異なるレイヤーの話として、ネットワークの制御プレーンをデータプレーンから切り離し、集中コントローラで一括最適化するSDNの発想を整理しました。フローテーブルのマッチ・アクション抽象化、分散型ルーティングとの局所最適・大域最適の対比、そしてISLの回・CGRの回で学んだ予測可能な軌道トポロジをSDNの先読み配布に活かす発想を数式で追いました。そのうえで、地上のデータセンターSDNが暗黙に仮定してきた「往復レイテンシは無視できる」という前提が宇宙ネットワークでは崩れることを、具体的な伝搬遅延の数値で確認し、 $\tau_{ctrl} \ll \tau_{event}$ という条件のもとで、速い判断はオンボードの自律制御に、遅い判断は集中コントローラの戦略的最適化に委ねる、階層化されたハイブリッドアーキテクチャが実務的な解になることを見ました。

次回は、こうしたSDNやCCSDSの各種プロトコルが、実際に「異なる事業者・異なる機関の機器の間で本当に相互接続できるのか」を検証する、CCSDS準拠性試験・相互運用性検証という、標準化の理念と現実の実装との間を橋渡しする回を扱います。

参考文献

N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner, “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, 38(2), 2008
Open Networking Foundation (ONF), OpenFlow Switch Specification
S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hölzle, S. Stuart, A. Vahdat, “B4: Experience with a Globally-Deployed Software Defined WAN,” Proc. ACM SIGCOMM, 2013
M. Handley, “Delay is Not an Option: Low Latency Routing in Space,” Proc. ACM HotNets
NASA SCaN Program, SCaN Testbed (CoNNeCT) Overview and Experiment Results
S. Burleigh, A. Hooke, L. Torgerson, K. Fall, V. Cerf, B. Durst, K. Scott, H. Weiss, “Delay-Tolerant Networking: An Approach to Interplanetary Internet,” IEEE Communications Magazine, 2003
J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76