このネットワークリソースの一元管理というアプローチは、実質的に、IaaS、PaaS、SaaSの各クラウドサービスの基盤となっているリソース管理戦略と何ら変わりはない。従って、SDNベースのネットワークがNaaSの基盤になるのは驚くことではない。

SDNアーキテクチャとしてのOpenFlowの役割

　スイッチ／ルータの大手ベンダーの多くが、SDN実装であるアーキテクチャ「OpenFlow」のサポートを表明している。

　OpenFlowは、仕様と、一元管理システムのコンポーネントとなるスイッチまたはルータで実行されるオープンソースソフトウェアから成る。OpenFlowネットワークでは、スイッチまたはルータがパケットを受け取ると、スイッチまたはルータ自体でパケットの処理を決めるのではなく、コントローラーにパケットを送り、コントローラーがポリシーを使用して扱いを決める。このポリシーを基に転送ルールが作成され、このルールがコントローラーから要求側端末に返される。

NaaSにとってのOpenFlowのメリットと課題

　上記のOpenFlowの仕組みから、NaaSを考えた場合のOpenFlowのメリットとデメリットが分かる。まずメリットは、OpenFlow接続は明示的なため安全性が高まり、QoSも向上する可能性があることだ。これは、パケットのルートを設定するポリシーが、アプリケーションだけでなくユーザーの優先度も加味して、リソースへのトラフィックの割り当てを決定できるためだ。つまり、パフォーマンスのレベルを設定できる。理論的には、OpenFlowネットワークでは、DoS攻撃の心配がなく、ハッキングもされにくい。また、ビデオや重要なアプリケーションも提供しやすくなるだろう。

　一方、課題はスケーラビリティだ。全てのパケットを一元管理システムに送って解析する必要があるとすれば、OpenFlowネットワークの実用は厳しい。既に提案されている方法だが、NaaSを実用可能にするには、OpenFlowのスケーラビリティを改善するか、OpenFlowの使用をクラウドネットワーク内に限る必要がある。

　OpenFlowは、トラフィックが予想可能な適度な量のフローのときに、最適に動作する。この場合、一度スイッチまたはルータがコントローラーからトラフィックのルールを取得すると、その後、コントローラーとの通信はほとんど必要なくなる。データセンター内のサーバ間またはサーバとストレージ間のトラフィックに使用した場合、OpenFlowは非常に有用だ。分散型クラウド（パブリック、プライベート、またはハイブリッド）のデータセンターであっても、OpenFlowはクラウド内のトラフィックを管理できるだろう。問題は、クラウドとクラウドユーザー間のトラフィックの管理で、この管理ができない場合は、OpenFlowのSDNやNaaSではどのようにユーザーに対応するかを考えなければならない。

答えはOpenFlowとIPネットワークの統合？

　多数のユーザーが明示的に管理される接続の範囲を明らかに超えて存在する場合、クラウドの境界において、何らかの方法でOpenFlowと従来のIPネットワークを結合することが必要だ。幸い、OpenFlowとMPLSとを組み合わせ、オープンな接続とポリシーにより管理される接続を融合した新しいIPネットワークを作成する提案がなされている。

　また、OpenFlowの制御をより階層的にし、拡張性を高められそうな方法もある。さらに、NaaSが産声を上げたクラウドコンピューティングの世界では、クラウドアプリケーションの扱いを管理するための取り組みもある。これらの取り組みでは、アプリケーションをクラウドの“仮想サービス”に変える。このような取り組みによって、拡張性のあるOpenFlowモデルが確立されるとはまだ断言できないが、確立できた場合、クラウドリソースへのアクセス方法を改善でき、NaaSの駒を進めることができる。将来的には、このような取り組みの果てに、クラウドの枠を超えて、ネットワーク全体をカバーするNaaSが誕生するかもしれない。

　しかし、クラウド内では、そのときを待つ必要はない。OpenFlowによるNaaSなら、現在のイーサネットやIPと比べて、データセンター自体や、データセンター間のクラウドトラフィックをはるかに柔軟かつ的確に管理できるだろう。高価なIPやイーサネットの探索適応技術の更新が不要になるので、運用コストを削減できる可能性が大いにある。現時点では、NaaSの導入は時期尚早なケースもあるだろうが、どの兆候を見ても、NaaSは間もなくデータセンターで利用されるようになると考えられる。