SDN と OpenFlow：制御/データ分離の原理

コントロールプレーンとデータプレーンを切り離す

従来のルータ/スイッチは、1台の箱の中に2つの役割を同居させています。データプレーンは実際にパケットを受け取り、転送表を引いて出力ポートへ送り出す高速な部分です。コントロールプレーンはその転送表を作る頭脳で、OSPF や BGP といったルーティングプロトコルを各機器が自分で走らせ、隣接機器と情報交換しながら経路を計算します。つまり経路判断のロジックが網の全機器に分散して埋め込まれているわけです。

この分散モデルは堅牢ですが、網全体の挙動を一貫して制御するのが難しいという弱点があります。各機器が自分のローカルな視点でプロトコルどおりに動くため、「このフローだけ別経路へ」「この区間だけ帯域を絞る」といった全体最適の意図を直接書き下せず、プロトコルのパラメータを間接的にいじって誘導するしかありません。

SDN（Software-Defined Networking） はここを反転させます。コントロールプレーンを各機器から引き剥がし、論理的に集中化したコントローラへ移します。スイッチは経路を自分で考えるのをやめ、コントローラから配られた転送ルール（フローテーブル）どおりにパケットを動かす単純な実行体になります。判断はソフトウェア1か所に集まり、そこから網全体を一望してプログラムできる——これが SDN の一行要約です。

フローテーブル：マッチとアクション

SDN スイッチの中核は フローテーブルです。これは従来の宛先 IP だけを見るロンゲストプレフィックスマッチの転送表よりも一般化されており、各エントリ（フローエントリ）が マッチ条件とアクションの組で表されます。

マッチ条件は単一フィールドではなく、複数のヘッダフィールドの組み合わせで指定できます。入力ポート、送信元/宛先 MAC、VLAN、EtherType、送信元/宛先 IP、IP プロトコル番号、TCP/UDP ポートなどを横断的に条件にでき、各フィールドはワイルドカード（任意）も許します。これにより L2 から L4 までをまたいだ粒度で「どのパケット群か」を切り出せます。

アクションはマッチしたパケットへの処理で、代表的には次のものです。

アクションにはMPLS ラベルや VLAN タグの Push/Pop も含まれ、L2/L3 をまたいだ転送やトンネル処理を1つのテーブルで表現できます。複数エントリが同時にマッチし得るため、各エントリには 優先度（priority） があり、最も優先度の高いものが選ばれます。完全一致のエントリを高優先度、ワイルドカード混じりの包括的なエントリを低優先度に置く、という階層化が定石です。各エントリはパケット数・バイト数のカウンタも持ち、コントローラはこれを統計として吸い上げられます。

OpenFlow のメッセージ

OpenFlow は、コントローラとスイッチの間でこのフローテーブルを操作するためのプロトコルです。SDN の概念を実装する南行 API（southbound API） の代表例で、両者は TCP（通常 6653 番、保護に TLS）でコネクションを張り、定義済みのメッセージを交換します。主要なメッセージは次のように分類できます。

動作の典型は リアクティブな流れです。スイッチに該当エントリのないパケットが届くと、テーブルミス時の既定動作として Packet-In でそのパケット（または先頭部分）がコントローラへ上がります。コントローラは網全体の視点で経路を決め、Flow-Mod で経路上の各スイッチへフローエントリを書き込み、必要なら Packet-Out で当該パケット自身も送り出します。以降の同一フローはスイッチ内で完結し、コントローラは介在しません。

リアクティブなフロー確立（最初の1パケット）:

  新規フロー着弾
      │ テーブルミス
      ▼
  [Switch] ──Packet-In──▶ [Controller]   先頭パケットを判断委譲
                              │ 経路計算
      ◀──Flow-Mod───────────┘            経路上の各スイッチへエントリ投入
      ◀──Packet-Out─────────              当該パケットを送出
      │
      ▼
  以降の同一フロー：スイッチ内で完結（コントローラ不介在）

対照的に プロアクティブな方式では、コントローラが事前にフローエントリを全スイッチへ配っておき、Packet-In をほぼ発生させません。初回遅延がなくコントローラへの負荷集中も避けられるため、本番網ではプロアクティブが基本で、リアクティブは例外処理に限る設計が一般的です。

北行 API：意図をルールへ翻訳する

南行 API がコントローラとスイッチをつなぐのに対し、北行 API（northbound API） はコントローラとその上で動くアプリケーションをつなぎます。経路制御・ロードバランサ・ファイアウォール・ネットワーク仮想化といったアプリは、低レベルなフローエントリを直接書くのではなく、「テナント A の通信を分離せよ」「この2台を疎通させよ」といった意図を北行 API（多くは REST/JSON、gRPC など）でコントローラへ伝えます。

コントローラはその意図を、網のトポロジ情報と突き合わせて具体的なフロールールの集合へ翻訳し、南行 API で各スイッチへ展開します。北行 API には OpenFlow のような単一の標準が定まっておらず、コントローラ実装（OpenDaylight、ONOS など）ごとに API が異なるのが実情です。

この二層構造が SDN の価値の源泉です。アプリは個々のスイッチの実装やベンダを意識せず、コントローラの抽象モデルに対してプログラムを書けます。コントローラは網全体の単一の論理ビュー（集中したトポロジと状態）を提供し、その上で経路や分離をソフトウェアとして組み立てられます。物理配線をまたいだ論理ネットワークを作るVXLAN オーバーレイのような仮想化も、こうしたコントローラ主導の制御と組み合わせて運用されます。

まとめ

SDN は、各機器に分散していたコントロールプレーンを引き剥がして論理的に集中したコントローラへ移し、データプレーンとの分離を徹底する考え方です。スイッチは自律判断をやめ、コントローラから配られたフローテーブルどおりにパケットを動かします。フローエントリは複数ヘッダフィールドの match と Output/Set-Field/Group などの action の組で、優先度つきに照合されます。OpenFlow はこの制御を担う南行 API の代表で、Packet-In でスイッチが判断を委譲し、Flow-Mod でコントローラがルールを書き込みます。リアクティブとプロアクティブの使い分け、Packet-In 集中の回避が実装の勘所です。さらに上位の北行 API がアプリの意図を受け取り、コントローラがそれをフロールールへ翻訳する——ネットワークがソフトウェアのプログラム対象になること、これこそが制御/データ分離の狙いそのものです。