OpenFlow導入ガイド[後編]――対応ベンダー急拡大で気になる製品選びのポイント

グーグルやNTTコミュニケーションズが商用環境で利用するなど、すでに“実導入”フェーズに入ったOpenFlow。後編では、徐々に選択肢が広がりつつあるOpenFlow対応製品の選び方のポイントを解説する。

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

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

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

RELATED ARTICLE関連記事

SPECIAL TOPICスペシャルトピック

スペシャルトピック一覧

FEATURE特集

NEW ARTICLES新着記事

記事一覧

WHITE PAPERホワイトペーパー

ホワイトペーパー一覧
×
無料会員登録

無料会員登録をすると、本サイトのすべての記事を閲覧いただけます。
また、最新記事やイベント・セミナーの情報など、ビジネスに役立つ情報を掲載したメールマガジンをお届けいたします。