誰も話題にしなくなったOpenFlow、それでもSDNは前へ進む：あの注目のSDNプロトコルは今（1/2 ページ）

SDNとOpenFlowは、かつてはほとんど同義だった。だが今では、OpenFlowはいかにも影が薄い。この変化はネットワーク担当者にとって重要な教訓だ。

[Doug Marschke，TechTarget]

SDNマップ（1回で分かる：「SDN」の基本、主要ベンダーの動向をマップで押さえよう）《クリックで拡大》

　「SDN」と「OpenFlow」はしばらくの間、同列に考えられていた。ネットワークの専門家がSDN（Software Defined Networking）という言葉を盛んに使い始めた頃、OpenFlowも併せて取り上げるのが常だった。しかし今では、SDNが話題に上っても、OpenFlowは言及すらされないことが多い。かつては注目度が高かったこのSDNプロトコルはどうなったのか。悪いアイデアだったのか。OpenFlowはもう過去のものになってしまったのだろうか。

　こうした疑問に答えを出すため、まず、OpenFlowが何を目指していたのかを確認しよう。OpenFlowプロトコルの仕様を管理する非営利の標準化団体Open Networking Foundation（ONF）は、次のように述べている。

併せて読みたいお薦め記事

SDN導入を成功に導くには

• SDN導入を成功させる「小さなことからコツコツと」
• サイバーエージェントとビッグローブが語る「ビジネスに生きるSDN」
• もう“実験”じゃない　これからのSDNの話をしよう

OpenFlow／SDN、誤解の構造

• 【技術動向】OpenFlowはなぜ誤解されるのか
• 【技術動向】OpenFlowに対する4つの誤解を検証する

SDNの基礎知識

• 1回で分かる：「SDN」の基本、主要ベンダーの動向をマップで押さえよう
• 5つの「なぜ？」で理解するSDNの基本

OpenFlowとは何だったのか

　「OpenFlowは、SDNアーキテクチャのコントロールレイヤーと転送レイヤーの間の標準通信インタフェースとして初めて定義された。OpenFlowを使用することで、物理的および仮想的な（ハイパーバイザーベースの）ネットワーク機器（スイッチやルータなど）の転送プレーンに対して直接アクセスし、操作することができる」

　転送プレーンは従来、コントロールプレーンとともにネットワーク機器に組み込まれていたが、OpenFlowは基本的に、SDNコントローラーから送信されるフロールールに基づいてトラフィックの転送に関するルールを設定し、転送プレーンに適用することを可能にする。これは、コントロールプレーンから転送プレーンを分離できることを意味する。これによってオープンでシンプルなスイッチの構築が可能になる。米Google、NTT、米Goldman Sachsといった大手企業がいち早くOpenFlowを導入し、大きな成功を収めた事例が報告されている。ベンチャーキャピタリストは、OpenFlow対応機器を手掛ける企業に多額の資金を投じ、多くの人が、OpenFlowは2015年までに業界を席巻するだろうと予想した。だが、それは見込み違いだった。

　これまでのところ、OpenFlowが広く普及していない理由としては以下が挙げられる。

OpenFlowの新しいバージョンに対応するスイッチが乏しい

　「OpenFlow 1.0」に対応するスイッチは多いが、ベンダーは「OpenFlow 1.3」のサポートには消極的になっている。その一因は、この新プロトコルで採用されている記述方式にある。OpenFlow 1.3では、属性の多くがTLV（Type：タイプ、Length：長さ、Value：値）として定義されており、多くのベンダーがこのTLVをサポートしないことを選択した。ONFはテストおよび適合性プログラムにより、OpenFlow 1.3のサポートを促進しようと最善を尽くした。だが多くのスイッチベンダーが、メリットよりもサポートのコストの方が重要であると考えた。

半導体チップにおける大規模OpenFlowテーブルのサポートの遅れ

　カスタムチップやマーチャントチップ（汎用ネットワークチップ）のメーカーがOpenFlowの大規模なフローテーブル（あるいは単に多くのテーブル）をサポートするには、自社製品に変更を加える必要がある。だが、この変更がまだ行われていないため、これらのチップの多くは、高速のTCAM（Ternary Content Addressable Memory：三値連想メモリ）を有効利用できない。対応チップの投入が遅れていることが、OpenFlowの普及のネックになっている。

平均的なネットワークエンジニアは、OpenFlowプロトコルの展開方法を理解していない

　ネットワークエンジニアは、未知のプロトコルを学ぶことに慣れているが、それはSDNやOpenFlowが登場する以前のプロトコルに限ってのことだ。ほとんどのエンジニアは、転送プレーンではなく、コントロールプレーンを規定するプロトコルを学んできた。OpenFlowを展開するには、スイッチのパイプライン処理のような事項を新たに理解する必要がある。この処理はほとんどのネットワークエンジニアにとってなじみのない概念だ。

　業界では、こうしたOpenFlowの課題解決に向けた取り組みが行われてきたが、他のインタフェースも定義され、市場にひしめいている。一方、OpenFlowスイッチを作っていたベンダーのマーケティング部門では大半が、OpenFlow自体は売りにくいことをすぐに理解した。そこでこうしたマーケティング部門の多くは、OpenFlow製品の位置付けをより広い観点から見直し、“SDNソリューション”と銘打った。販売アプローチが変わっても、OpenFlowプロトコルを使ったソリューションであることに変わりはなかったが、ユーザーはそのユースケースだけを見ていればよかった。すなわち、ユーザーは上位の抽象化レイヤーで操作や構成を行うことができ、下位レイヤーで機能するこのプロトコルを学ぶ必要がなかった。