■SDN の課題は、ノースバウンドAPI の整備がポイントに関谷：なるほど。では今後の普及の要になりそうなSDN向けアプリケーションの現状や可能性についてはどう考えていますか?高嶋：ShowNetでは「TTDB」【★脚注5】という機器の設定情報を管理するデータベースを構築しています。今はこのTTDBを参照しながらコンフィギュレーションや運用を行っていますが、もし、SDNのアプリケーション向けに共通化されたAPIがあれば、機器の状態や情報の収集、コンフィギュレーションなどを共通APIで直接制御できるようになるので、かなりの部分をアプリケーションで自動化できるようになります。そういった世界が実現されていけば、ユーザー側の管理コスト削減につながりますし、アプリの実装側も開発コストを下げられるので、もっと普及すると思います。渡邊：確かに、OpenDaylight やOpenContrailといったSDNのパーツとなるコンポーネントはそろってきましたので、今後はこれらを束ねるためのノースバウンドAPI【★脚注6】が整備されるとよいですね。あと2、3年くらいでしょうか、ノースバウンドAPIが出て成熟してくれば、SDNでの一元管理がエンドユーザにもメリットとして感じられるようになると思います。自分でカスタマイズしやすくて、自分に合った形で運用面での自動化が出来るようになってくると良いと思いますね。中村：同感です。APIの抽象度がもう一段上がるというか、デファクトスタンダードとなるようなものができあがると、SDNによる垂直統合はもっと進むと思います。現状ではソフトウェアごとのばらつきなどが結構大きいものだったりします。関谷：そういう意味では、サーバ・ストレージレイヤを束ねる部分ではOpenStackが出てきて、そこでいろいろなPluginのようなものがつくられています。一方ネットワークでは、OpenDaylightやOpenContrailのようなもので、OpenFlowコントローラを取り込む上位のSDNコントローラによって、ネットワーク全体の概念を包括する方向で、まとまる兆しを見せています。しかし、まだやっぱり決定打に欠けるように思いますね。逆にSDN機器側はどうなっていくのでしょうか?渡邊：現場では、ベンダー機能だけでなく、外部APIから使える機器へのニーズがあります。今回、ShowNetで提供していただく機器についてはRESTに対応しているもの、NetConfに対応しているものは明確化していく方向です。高嶋：APIの標準化は、RESTのような概念やスタイルに関する部分だけでなく、各APIの仕様まで標準化が進むとよいですね。関谷：なるほど。ルーティング機能等をサーバ上で実装することで、ルータなどの機器自体も安くなる可能性がありますよね。そのような、ソフトウェアルータの利用はさらに広がっていくのでしょうか?中村：VM上でパケット・フォワーディングを行う、IaaSの中でファイアウォールを実現するといったレベルでのソフトウェアルータといったユースケースは考えられます。ソフトウェアルータの活用場面は広がるのではないでしょうか。渡邊：そうですね。エンタープライズ規模ではメリットを出しにくいかもしれませんが、データセンターや通信キャリアになると、小型のファイアウォールを何千台と導入するより、サーバに機能を持たせてサービスとして提供することでのコストメリットは出しやすいかもしれません。関谷：ホワイトボックスと呼ばれるファームウェアを選べるような機器・製品も出てきました。中村：プログラムを組む立場からいうと、今までサーバの設定や運用に用いてきた技術をネットワークのデプロイにも適用できるので、非常に可能性というか、応用できる幅が広いと感じています。渡邊：ネットワークを一元管理する用途には、安定性という面で効果はあると思います。汎用的なツールで管理するというより、ピンポイントでスペシャルなネットワークを構築したいとか、カスタマイズしたいといったユースケースで特に有効と考えます。関谷：バックボーンネットワークではトラフィック増に対応するため、いわゆる土管の部分と、管理のインテグレーション部分の分離が進んでいます。SDNでもそのような垂直統合を進めるためのアイデアみたいなものは何かありますか?高嶋：FT（Fault Tolerance）構成だけではなく、Webサービスなどでは、裏で別サーバを動かしておいて特定のタイミングでフリップさせるような使い方が増えているのですが、SDNでもこれは実現できそうですね。サーバ管理の側とネットワーク管理の側は、これまで別々でしたが、SDNによって、こういった運用が簡単になることはあるでしょう。関谷：なるほど。よく言われているように、SDNをきっかけにネットワーク屋とサーバ屋の区別がなくなるかもしれませんね。ここまで、SDNの可能性についていろいろ意見が出てきました。適材適所に、しかるべきツールやアプリケーションとともに広がっていくということではないかと思います。関谷：では、もう少し先の未来について聞いてみたいと思います。今話題になっているSDNやNFVの次は、いったい何が世に出てくるのでしょうか? 技術的、学術的なレベルでもかまいません。中村： うーん、難しい質問です（ 笑）。OpenFlowが登場した背景に、転送はハードウェアで行っても、パケットの転送ルールは自分たちで決めたいという事情があって、結果としてスイッチからコントロールプレーンを分離しました。次は、この考え方がネットワーク全体に広がっていくのではないでしょうか。これまではIETFのプロトコルがベースとなり、イーサネットフレームがあって、IPをOSPFで制御し、自律システム間のインターフェイスはBGPで制御する、という構造でした。次はこれまでとは別の識別子を使って、別のルーティングを行うといった流れが出てきてもよいかな、と思っています。いってみれば、IPやイーサネットフレームに縛られないネットワークですね。関谷：最後にまとめとして、次のShowNetでやってみたいことがあれば教えてください。高嶋：自分の立場での夢なのですが、TTDBの情報からネットワークの構成・管理といったオーケストレーションを自動化させることですね。そのためには先ほど話題になっていたAPIの標準化はとても重要だと思います。齋藤：その第1歩として、去年VA（バーチャルアプライアンス）で出展社NWを構築しましたが、今年は、出展社（ユーザー）からのオーダーに合わせてオンデマンドでルータやファイアウォールなどのネットワークファンクションを仮想的に配置し、設定からネットワーク提供までを上位のコントローラから自動的にデプロイできるシステムを構築する予定です。NFVの一つのユースケースとして、また将来めざしているSDNの一つの姿の途中経過として、お見せできると思います。関谷：そういうオンデマンドネットワークのようなことは昔からの夢ですよね。機器を単純につなぎ合わせていけばいいだけの世界、我々が追い求めている夢の1つです。まあ非常に難しいところだとは思いますが、今後の課題というところで、将来的に向かっていく方向性として、この議論が出てきていると思います。今年も引き続き、ShowNet のほうでも、パケットを純粋に運ぶネットワーク部分と、その上のSDNの部分で、いろいろなことを試していけたらと思います。【★脚注1】NFV：Network Functions Virtualizationの略。サーバ仮想化をネットワーク機器に応用したもので、ルータやゲートウェイ、ファイアウォール、ロードバランサなどのネットワーク機器の機能をソフトウェアとして実装し、汎用サーバの仮想化されたOS上で実行する方式。特定の機能に対する突発的な需要の増減や構成変更に柔軟に対応でき、物理的な機器の集約・高密度化を進めることで、管理コストや消費電力の低減を図れる。【★脚注2】OpenFlow： 近年、ネットワーク業界では、ソフトウェアのように柔軟に制御可能なネットワーク技術が求められるようになった。そのなかで注目されている技術の1つがOpenFlow。従来のように制御と転送が共存するネットワーク機器と異なり、OpenFlowは制御と転送を分離したアーキテクチャを採用。ネットワーク管理者は、OpenFlowコントローラと呼ばれる制御部を自ら設計・実装でき、必要な制御機能を自由に実現することが可能。【★脚注3】OpenDaylight：SDN（Software Defined Networking）に対して透過的なアプローチを行うことで、新たなイノベーションを育成し、その実装を加速していくことを目的に、Linux Foundationのもと複数の業界リーダーで結成されたオープンソース・プロジェクトのこと。【★脚注4】OpenContrail：ジュニパーのContrail Systemsの技術を取り入れたSDNソリューションをオープン化してたもので、ソフト（バイナリ、ソースコード）をWebサイトで配布している。無料で利用できるが、コミュニティベースでのサポートとなる。Contrailを利用すると、クラウド環境でハイパーバイザ組込型の仮想ルータ（vRouter）間をMPLSトンネル（GREまたはVXLAN経由）でつなぎ、仮想ネットワークを構成できる【★脚注5】TTDB：Trouble Ticket DBの略。ShowNetで使われる運用情報データベースシステムのこと。ShowNetでは出展社それぞれに提供するサービスの情報（種類・アドレスブロック・VLAN ID・収容機器など）をTTDBに登録しておき、それを参照してコンフィグのテンプレートに基づいて機器設定を投入するシステムを構築している。【★脚注6】ノースバウンド：OpenDaylightがカバーするレイヤのうち上位レイヤに位置するものをさす。具体的には「Service Abstraction Layer」「Controller Platform」「OpenDaylight API」などがある。一方、下位レイヤに位置するサウスバウンドに位置するのが「OpenFlow」。
