## Memo ## Memo with LLM ## Abstract コンピュータ・ネットワークは私たちの日常生活に欠かせないものであり、そのユースケースは、個人所有の物理的なコンピュータの接続から、クラウド・コンピューティング、モノのインターネットなどへと拡大している。新たなユースケースに対応するためには、コンピュータ・ネットワークにはネットワーク制御機構の柔軟性、すなわち、ネットワーク制御機構を必要に応じて改良できること、また、ネットワークが安定的かつ堅牢に運用され、社会に大きな悪影響を与えないことが求められる。しかし、従来のネットワーク機器は制御ソフトウェアと物理デバイスが密に結合しているため、ネットワーク機器ベンダー以外がネットワーク制御機構を開発・展開することは困難でした。 Software Defined Networking ([[SDN]]) はキャンパス、エンタープライズ、データセンターネットワークのようなプライベートネットワークにおいてこの状況を変えようとしている。SDN ではネットワーク制御ソフトウェアはネットワークデバイスから切り離され、デバイスは外部コンピュータ（コントローラ）からデバイスがどのようにパケットを転送するかを集中的に制御するためのオープンで共通の API を提供する。SDN はネットワーク管理者がデバイス上の API を使って独自のネットワーク制御ソフトウェアを開発し、展開することでニーズに応えることを可能にする。OpenFlow は将来有望な API として注目されており、OpenFlow 機能をサポートする機器は OpenFlow スイッチと呼ばれる。OpenFlowは、各機器上のパケット転送ルールをフロー・エントリとして抽象化し、各エントリは、パケットにマッチする条件となるヘッダフィールドとその値、マッチしたパケットに適用されるアクション、統計情報のタプルで構成される。フローエントリーにマッチしたパケットは、アクションによって指定されたとおりに処理される。フローエントリはコントローラによってインストールされ、フローエントリを逃したパケットは OpenFlow メッセージの一つである Packet-In メッセージにカプセル化され、Packet-In メッセージは特に指定がない限り TCP 上の OpenFlow チャネルを通してコントローラに送信される。 OpenFlowをベースとしたSDNは、新たなネットワーク制御メカニズムの導入の柔軟性を高めることができる反面、故障耐性、想定外のトラフィックに対するネットワーク機器の保護、制御ソフトウェアによる高負荷の回避など、安定性や堅牢性の面で課題がある。SDN や OpenFlow では、安定性や堅牢性を高めるための仕組みはネットワーク制御の柔軟性を保持しなければならないが、従来のネットワークの仕組みは特定の仕様の下で設計されている。ネットワーク制御のための処理は、SDN や OpenFlow ではコントローラにほぼ集約されているのに対し、従来のネットワークでは制御ソフトウェアがネットワーク機器に分散している。本論文では、これらの問題にどのように対処するかを議論する。 最初の問題はコントローラでの処理だ。コントローラはネットワークで発生する全てのイベントを一元的に処理するため、イベントが多く発生するとコントローラの負荷が増大しやすく、各イベントを処理するための処理が高負荷となる。マルチキャスト制御は、この点に注意が必要なケースの一つである。プライベートネットワークにおけるマルチキャスト制御では、送受信者の状態に応じてネットワークがオンデマンドでマルチキャストツリーを更新する必要がある。また、ビデオストリーミングのようなマルチキャストの典型的なアプリケーションを考えると、ネットワークは障害時にマルチキャストパケットの配信を迅速に復旧させる必要がある。従来のネットワーク技術では、この2つを同時に満たすことはできず、OpenFlowベースのアプローチにその可能性がある。しかし、コントローラが単純な方法でマルチキャストを制御する場合、つまり、送信者と受信者のセットが変更されたり、ネットワーク上で障害が発生した場合に、コントローラがマルチキャストツリーを再計算して再インストールする場合、ツリーの計算に多くの時間がかかるため、コントローラの負荷が増大する。さらに、マルチキャストパケットの配送を高速に復旧させるためには、スイッチのフローエントリの変更時の性能の低さに注意する必要がある。 本論文では、受信者が接続される可能性のある全てのスイッチをカバーする冗長マルチキャストツリーを事前に計算し、送信者と実際の受信者を接続するために必要な各ツリーの一部を設置することを提案する。すべてのマルチキャストツリーにはラベルが付けられ、パケットが入ってきたスイッチは、マルチキャストパケットの配送に使用すべきマルチキャストツリーのラベルを付ける。この方式では、コントローラは、既存のマルチキャストグループにレシーバを追加または削除したり、障害からマルチキャストツリーを回復するための処理時間を短縮し、障害時にスイッチ内の多くのフローエントリを置き換える必要がない。 2つ目の問題は、コントローラとスイッチ間のOpenFlowチャネルである。ネットワークの制御性を維持するためには、チャネルの障害を即座に検出する必要がある。しかし、コントローラは多くのキープアライブメッセージを処理しなければならないが、コントローラのメッセージ処理性能は必ずしも高くないため、キープアライブメッセージを頻繁に交換することは不十分である。 本論文では、チャネルが常に利用可能かどうかをチェックする代わりに、相手側に配送されるべきメッセージが発生した時点で障害を検出することを提案する。コントローラは、スイッチからのメッセージの到着を共有して比較し、メッセージの到着が矛盾している場合に、故障したチャネルを検出する。スイッチは、ポートダウンや重要な Packet-In メッセージなどの重要なメッセージを送信した直後に keep-alive メッセージを送信します。その結果、スイッチとコントローラは、必要なときに即座にチャネルの障害を検出し、適切なアクションをとることができる。 3つ目の課題は、多くの未知のパケットに対するスイッチの保護である。対応するフローエントリがインストールされる前に，フローエントリを欠落したパケットを多数受信した場合，性能の低いことが多いスイッチの CPU は，多数の Packet-In メッセージを生成するために過負荷となり，スイッチは制御不能となる．このようなパケットの中には，ネットワーク制御上重要でフィルタリングされるべきでないパケットも存在するため，スイッチ側ですべてをフィルタリングすることは困難である． 本論文では、重要なパケットを確実にPacket-Inメッセージとしてコントローラに渡す一方で、そのようなパケットを選択的にフィルタリングするスイッチのメカニズムを提案する。コントローラがネットワーク制御に使用するヘッダフィールドは、あらかじめコントローラからスイッチに指定される。スイッチはコントローラから指定されたヘッダフィールドの値を記録し、記録された値と一致するパケットを含む Packet-In メッセージをフィルタリングで除外する。これにより、ネットワーク制御に大きな影響を与えることなく、スイッチの CPU での処理を削減することができます。