相互接続性とバージョン問題

また、OpenFlowはオープンな標準規格だが、実際の実装にあたっては各ベンダーの独自仕様となる部分がどうしてもあり、相互接続性に関する課題が一部で生じている。

例えば、NECのコントローラーはスイッチから設定情報を受け取るのにLLDPを使っているが、同社の早坂氏によると他社のOpenFlowスイッチの中にはLLDPに対応していないものもあり、接続できないケースがあるという。

現在、市場に出回っているOpenFlowスイッチはほぼすべてがOpenFlow 1.0への対応である。実装するベンダーからすると、1.0はまだ仕様として不足している部分が少なくなく、それゆえ独自に拡張せざるを得ないという側面もあるようだ。

OpenFlowは2010年3月に1.0が策定されて以降、ベンダーの対応が追い付かないほど急ピッチでバージョンアップが行われてきた。そして最新の1.3では、コントローラー-スイッチ間の接続の改善・拡張、Tunnel IDのサポート、IPv6拡張ヘッダのサポート、PBB（Provider Backbone Bridge：IEEE802.1ah）のサポートなどの重要機能が追加されるなど、一通りの機能が揃っている。

OpenFlowの標準化作業を行うONFでは、この1.3を当面の安定バージョンとしてデフォルト化していくため、2012年内はバージョンアップを小休止し、仕様のバグ修正などに力を入れていく方針をアナウンスしている。

独自仕様による拡張という動きをとるベンダーはもちろん今後もあるだろうが、このため1.3では相互接続性に関する課題は改善されていくものと期待される。

ファブリックとOpenFlowは補完関係？

OpenFlowについては、いわゆる「イーサネット・ファブリック」（関連記事）との関係もよく話題になる。ともに仮想化／クラウド時代に求められるネットワークを実現する技術であり、OpenFlowとファブリックでは解決できる課題に共通点が多いように見えるためだ。

結論からいえば、オーバーレイ方式では、OpenFlowとファブリックは補完関係になる。オーバーレイ方式では、既存のネットワークをそのまま流用するため、転送能力や耐障害性などは“土台”となる既存の物理ネットワークに大きく左右されることになる。また、オーバーレイ方式の場合、物理ネットワークそのものの運用管理負荷の改善にもつながらない。そこで、ニシラなどではファブリックをネットワーク仮想化の物理インフラに活用することを推奨しているのだ。

他方、ホップ・バイ・ホップ方式では、こうした物理ネットワークの課題も当然解決でき、ファブリックとは「競合関係になる」との見方が一般的だ。