JANOG29レポート〜過熱し過ぎていませんか？
OpenFlowをめぐる期待と現実

あきみち
2012/2/16

　仕様は発展途上、本格的な実装はこれから

　ブロケードコミュニケーションズシステムズの高嶋隆一氏は、「OpenFlowの仕様だけを見ると、いろいろとできそうに見えてしまいますが、本質的な実装はこれからです」と述べています。「OpenFlowの仕様そのものも開発途上であり、製品も、一部の先進的なものが存在するのみ」（同氏）というのが現状です。

　特に、最初に出る製品には実験的な試みが盛り込まれていることが多く、実運用ネットワークに導入しようとするとさまざまな制約にぶつかることになります。プロトコル上は実現可能に見えたとしても、実装上の制約によって不可能な機能やソリューションもありそうです。

　NECビッグローブの淀野氏は、「いままで分散管理していた設定をコントローラで一元管理できる点が魅力」としつつも、OpenFlow製品は発展途上であり、さまざまな課題があると述べています。

　例えば、現時点では市場で販売されているOpenFlowスイッチが少なく、機器の価格がまだ高価であることがその1つです。また現段階では、コントローラの処理能力が、堅牢性や拡張性を意識した作りになっていないように見えることも、不安要因の1つになるかもしれません。さらに、既存の機器構成をすべて変更して新たにOpenFlowスイッチを導入するのはまだ難しいこと、VXLANやTRILLといったほかの技術を使っても課題が解決できそうであることといった指摘も挙がっていました。

　NTTデータの馬場氏は、OpenFlowの相互接続性実験の結果を紹介しました。2011年10月に、同社のOpenFlowコントローラプロトタイプと、アリスタネットワークス、エクストリーム ネットワークス、日本電気、ブロケードの4社によるOpenFlowスイッチの相互接続試験が行われました。実験にはこれら4社の他に、名前を出せないベンダ2社も参加していたようです。

　検証実験の結果について、馬場氏は「マルチベンダ環境での接続は、OpenFlowのバージョンが同じであって、オプション機能を使わないのであれば問題ないのではないか」と感想を述べました。

　一方、「バッドノウハウというか失敗事例」として、フロー設定の書き込みタイミングが製品によって異なる点を挙げました。また、ARPやDHCP、VRRPなどによるマルチキャストやブロードキャストが、OpenFlowネットワークの外から次々と入ってくるので、それらをどうやって処理するのかに苦労したそうです。

関連リンク：
	NTTデータニュースリリース：次世代ネットワーク技術「OpenFlow」を活用したクラウド環境構築の検証実験に成功 http://www.nttdata.co.jp/release/2011/100302.html

　Q＆Aでは、タプル数が増えると機器のコストが高くなってしまうのではないかという指摘がありました。それに対して登壇者は、「コメントしづらい」としつつも、「将来的には、用途を限定したうえで最適化されたハードウェアの実装も必要になるかもしれない」と述べていました。

　過去のネットワーク技術もそうでしたが、初期のOpenFlow実装製品には、このようにまだ足りない部分が残っている可能性があります。市場がそれに落胆し、OpenFlowに対する熱が徐々に冷めていってしまう恐れも指摘されていました。

　セキュリティ問題に対する懸念も

　JANOG29セッションのQ＆Aではまた、OpenFlowスイッチがDDoSやポートスキャンに対してどのように対処可能なのかに関する質問がありました。

　OpenFlowは、設定によっては、新しいフローが到着するたびに、「このフローはどう処理すべきなの？」とコントローラに問い合わせる場合があります（図1）。

図1　OpenFlowの動作フロー

　この結果コントローラに負荷が集中し、ネットワーク全体に影響が出てしまう可能性があるという指摘です（図2）。質問者はさらに、そのような状況が発生する例として、「安いVPSサービスにつなげると大量のポートスキャントラフィックが到着してしまう」と説明しました。

図2　OpenFlowコントローラに負荷が集中し、DoS状態に陥る懸念も

　それに対する答えは次のとおりです。「OpenFlowスイッチには、プロアクティブなものとして、予想されるようなフローをあらかじめ書き込んでおかなければなりません。そうしないと、どんどんコントローラに問い合わせが来てしまいます。それでも防げない状況はありますが、インテグレータとしては本格運用の前に試験をします。試験の段階でフローを書き込ませるといった工夫をしています」

　この質問は、実はOpenFlowが抱える大きな問題の1つであり、セッションの参加者も「大きな課題の1つ」ととらえています。ただし、その解決に向けた工夫は、コントローラベンダの実装に依存するようです。

　このような問題を緩和させるために、単一のコントローラが管理するドメインの範囲を小分けにして影響範囲を限定させることや、予想可能なエントリをあらかじめ手動設定しておくなどのワークアラウンドが必要であるという意見も紹介されました。実際にOpenFlowを導入するとなると、この辺りのノウハウが必要なのかもしれません。

　「すでに存在する○○と何が違うの？」という疑問

　Q＆Aで多かった質問が、「OpenFlowって既存の○○と何が違うの？」という内容でした。VXLANやTRILLといった新しいデータセンター系技術、従来のオーバーレイや遠隔操作系技術との違いが気になる人が多いようです。

　現時点では、今後発売されるOpenFlow専用スイッチの多くは、既存スイッチへの付加機能として提供される予定です。そのため、「すでに手元のスイッチに○○の機能が入っているけど、OpenFlowになったときの違いは何？」という部分が気になるのかもしれません。

　それに対してニシラ・ネットワークスの進藤氏は、「データプレーンとコントロールプレーンを分ける技術は昔からあり、最近ではVXLANやTRILL、古いところではATMやMPLSやnetconfなどがあります。しかし、OpenFlowとこれらを直接比べるのは適切ではありません」と述べました。

　「それぞれ、特定領域の問題を解決するための道具やプロトコルであって、ガチンコでOpenFlowと当たるものではないと思っています。例えばVXLANに関しては、『yet another tunneling protocol』であり、それでOpenFlowと同じことができるというのはナンセンスであると思っています。何かが何かを置き換えるものではありません」（進藤氏）。

　ただ、現時点ではまだ製品も多く出ているわけではありません。既存のプロトコルと何がどう違っており、どのような用途が適しているのかが見えてくるのは、これからのことになるでしょう。

　ゆったり温かい目で進化を見守ろう

　この記事では、JANOG29のセッション内容をレポートしつつ、OpenFlowを取り巻く状況について紹介してきました。

　OpenFlowは、今までベンダがやろうとしなかった分野に切り込む仕様であり、今後の発展や派生を考えると非常に面白いプロトコルです。ただ、最初に期待が過熱し過ぎると、実際に出てきた初期製品を見て落胆してしまい、結果として市場導入が失敗してしまうのではないかという恐れが一部で出始めています。

　OpenFlowにあまり過大な期待を寄せることなく、ゆったりと温かく進化を見守る方がいいのではないかと思い始めた今日この頃です。

Profile

あきみち Geekなぺーじ 「Geekなぺーじ」を運営するブロガー。インターネットの構造や、インターネットに関連する事件や事例を追っています。近著は“インターネットが壊れた”からインターネットの構造を理解する「インターネットのカタチ - もろさが織り成す粘り強い世界」。Twitter IDは@geekpage。

OpenFlowをめぐる期待と現実
	OpenFlowは新たなバズワードか？ JANOG29で紹介されたOpenFlowの主な用途 OpenFlowは普及するのか？ するとしたらいつ頃か？ 「日本はOpenFlowクレイジーだ」
	仕様は発展途上、本格的な実装はこれから セキュリティ問題に対する懸念も 「すでに存在する○○と何が違うの？」という疑問 ゆったり温かい目で進化を見守ろう

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）