要約

  • RFC 7149の事業者視点では、コントローラーへの到達性、起動の仕組み、接続を失ったときの継続性は運用上の責任であり、制御と転送を分離すれば自動的に得られる利点ではない。
  • IGP/BGPを使わない設計では、別のブートストラップ用プロトコルやネットワークが必要になる場合がある。既存ルーティングへの統合と費用を比較し、ポリシー決定点（PDP）との接続が切れても基盤ネットワークは稼働を保つべきだ、と覚書は述べる。
  • RFC 7149はInformational文書である。設計上の見方と条件付きの要件を示すもので、インターネット標準でも、導入状況の調査でも、実際の障害報告でもない。

平面の分離だけでは歴史を説明できない

SDNはしばしば「制御面が判断し、転送面が実行する」という明快な分業として説明される。2014年3月のRFC 7149は、その図式が新しさを誇張しかねないと指摘した。ルーターは以前からソフトウェアで経路を判断し、ハードウェアでパケットを転送していた。より重要な変化は、ネットワーク要素をプログラムできる論理的に集中した主体へ、判断ロジックを移すことだった。

そこには運用上の依存関係が生まれる。コントローラーは機器と能力を発見し、サービスやポリシーの情報を交換し、資源を割り当て、決定を適用し、サービスが履行されたかというフィードバックを受け取る。RFC 7149はこれを、トポロジー・能力の発見、サービス提示とパラメーター交渉、動的な資源割当てとポリシー適用、履行・保証のためのフィードバックという四つの領域に整理した。

この整理はネットワーク構成を顧客への約束につなげる。覚書の暫定的な捉え方では、サービスはソフトウェアが選んだ経路だけではなく、顧客と条件を交渉できる、予測可能な結果である。これは分析の視点であって、広く採用されたSDNの定義ではない。「コントローラーがあるか」ではなく「事業者が合意したサービスを提示し、提供し、確認できるか」へ問いを移す。

コントローラーも管理対象へ届く経路を要する

ブートストラップの問題は、この依存を具体化する。IGP/BGPのないネットワークでは、コントローラーが機器を発見・設定するために、別のプロトコルまたはネットワークが必要になることがある。その経路は構築し、保護し、運用し、到達可能な状態に保たなければならない。既存のルーティングシステムに判断点を組み込めば、並行する起動用ネットワークを避けられるかもしれないが、既存システムの振る舞いや境界に設計が結び付く。RFC 7149は、未設定ネットワークの上に制御アプリケーションが自然に現れると考えず、選択肢の費用を比べるよう求める。

障害時の条件も同じ依存を浮かび上がらせる。対象となるIGP/BGPなしの環境では、PDPとの接続を失っても基盤ネットワークは稼働を保つべきだと記している。これは、どのコントローラー障害でも通信が止まるという主張でも、観測された障害の記録でもない。判断主体を分ける設計を選んだなら、通信が途絶えた後に何が自律して動くのかを定める、条件付きの継続要件である。

機器の発見が終わっても、サービスが利用可能とは限らない。顧客条件の交渉、ポリシーの設定、資源の確認、保証フィードバックが未完了でも、機器一覧は作れる。各段階を分けて扱えば、画面上の「接続済み」をサービス提供済みと誤認しにくい。

アーキテクチャの約束を運用証拠へ

RFC 7149は、SDNに必須の単一プロトコルや一斉移行の日付があるとも述べていない。OpenFlowは道具の一つであり、既存網や事業者独自システムとの段階的な統合が想定される。中央の判断主体は単一障害点にならず、転送性能を損なわないことが望ましい。これは設計上の注意であって、特定のシステムが達成済みだという証拠ではない。

歴史を記述する際、この違いは大切だ。Informational RFCは議論を整理し、事業者が答えるべき問いを示せる。しかし、何社が採用したか、サービスの実績がどうだったか、具体的な障害が起きたかは示さない。それを述べるには導入記録、測定、運用報告、顧客への結果が必要であり、覚書の発行だけでは足りない。

長く残る意義は、新しい転送機能よりも、立証責任の位置を変えた点にある。プログラム可能になっても、到達性、観測可能性、退避動作の必要は消えない。むしろ制御チャネル自体がサービス設計の一部になる。コントローラーが何を命令できるかを尋ねる前に、事業者はどう接続し、何を検証でき、判断点への経路を失ったときネットワークがどう動くかを示す必要がある。

出典