SDNはネットワークの制約を打ち破れるか？：SDN Japanレポート（1/2 ページ）
12月6日、7日の2日間に渡って、SDN（Software Defined Networking）をテーマとするイベント「SDN Japan」が開催された。その一部をレポートする。
12月6日、7日の2日間に渡って、SDN（Software Defined Networking）をテーマとするイベント「SDN Japan」が開催された。登録者は1000名を超えたといい、会場は後ろまで人で埋め尽くされる盛況となった。
SDNは、ネットワークを抽象化することにより、より柔軟なネットワーク構築を可能にすると大きな期待を寄せられている。一方で、具体的に「何が変わるのか」「何が可能になるのか」が見えにくい部分も残る。このイベントではそうした問題意識に立って、ビジネス、技術の両面からSDNについての発表やパネルディスカッションが行われた。その模様の一部をレポートする。
「ネットワーキングに革命を」、ONFのダン・ピット氏が呼び掛け
初日の基調講演には、Open Networking Foundationのエグゼクティブディレクター、ダン・ピット氏が登壇。「日本は、SDNやOpenFlowの受容に関して世界をリードしている」と述べ、ぜひこのムーブメントに参加してほしいと呼び掛けた。
同氏はSDNを、30年前にコンピューティングの世界で起こったのと同じことを、ネットワークの世界で引き起こすものだと表現する。現在のネットワークを形作る機器は、チップやハードウェア、ソフトウェアまで丸ごと作り込まれた「メインフレーム」と似たようなもの。新機能を追加したくてもベンダに依頼し、実装されるのを待つしかない。自分自身でネットワークをプログラムできるようにするSDNには、そうした状況を変える可能性があるという。
ピット氏は、アプリケーションプレーンとフォワーディングプレーンを分離する「抽象化」と「プログラマブルであること」、そして「インテリジェンスの集中化と単一のプログラミングインターフェイス」の3つがSDNの特徴だという。その上で、命令セットとして動作するのが「OpenFlow」プロトコルという位置付けだ。
現在OpenFlowプロトコルはバージョン1.3、そしてOpenFlow-Configはバージョン1.0/1.1となっている。2013年以降もこれら仕様を拡張し、さまざまなニーズに応えていく計画という。
具体的に検討中のトピックは、
- セキュリティ
- OAM（運用管理）
- 適合性評価テスト仕様書の作成とラボの準備
- オプティカルトランスポート対応
- ハードウェアアクセラレーション
- 既存ネットワークからの移行支援
- Northbound API
だ。例えば、ファイバチャネルにSDNを適用することで、低遅延で高速なWAN接続を実現できるようになる。同氏は、今後もこの「革命」を推し進め、成功につなげたいと抱負を述べ、そのためにもぜひ取り組みに参加してほしいと会場に呼び掛けた。
通信事業者がSDNに抱く期待と課題
NTTコミュニケーションズ取締役の伊藤幸夫氏による、2つ目の基調講演のテーマは「通信事業者やクラウド事業者は、OpenFlow/SDNにどのような期待を持っているか」である。
通信事業者の使命は「顧客企業に使いやすいネットワークを提供すること」だ。事業者側としては、マネージドで高品質のネットワーク提供に取り組んできた。しかし、顧客企業からの要望などを受けて新しい機能を追加する場合に、多大なコストや時間がかかる。
原因の1つは、新機能を追加するには、さまざまなネットワーク装置の機能開発をベンダに依頼し、それが出来上がるのを待たなければならないからだ。また、事業者側でのシステム開発が必要であったり、バックヤードのオペレーションの変更／追加によってオペレーションコストもかかる。これは、ネットワークがハードウェアにしばられているために起こるデメリットである。
同氏によるとキャリアネットワークの課題は、以下のようにまとめられる。
- 開発スピード
- ハードウェア製品に縛られた開発（柔軟性）
- ネットワークの肥大化などによるオペレーション稼働の増加
- コスト削減
OpenFlow/SDNに対する事業者視点の期待の1つは、いろいろな付加価値を顧客企業に提供する際に、ベンダの開発ロードマップにしばられずに自社に必要な機能を早期に導入し、スピードアップを図れないかという「Time-to-Marketの短縮」である。
もう1つがサービスの差別化だ。現状のネットワークサービスの場合、各社が同様の装置を使用しているため差別化が難しい。しかし、OpenFlow/SDNでは、市場製品の仕様にしばられずに差別化機能を開発・導入することが可能だと期待されている。コストについても、運用自動化によるOPEXの削減、コモディティハードウェアの利用によるCAPEXの削減が期待される。
一方で課題も
現時点で見えている課題のうち、OpenFlowスイッチに関する課題の1つは、現在市販されている製品はOpenFlow v 1.0をサポートするものが多いという点だ。現在、最新のOpenFlow仕様はv1.3.1だが、どこまで最新のバージョンに準拠するかはメーカーの動向に依存する。
また、ソフトウェア処理ではパケット転送性能に限界があるのではないかという疑問も常に存在する。ただこれに関しては、CPUなどハードウェアデバイス類の圧倒的進化が認められる。そもそもここまで踏み込んだ議論ができるようになったこと自体が、性能の進化を示すものという見方もできる。このように考えると、今は、ハードウェア技術とのコンビネーションを工夫する時期に差し掛かっているといえそうだ。
もう1つは、OpenFlowの展開に関する課題だ。エンドツーエンドでアクセシビリティを提供する通信事業者の立場としては、LANの外まで接続を広げないと意味がない。この点、WANへの展開に関する議論がまだ不足しているといえる。
同氏はこのように説明し、通信事業者としては、以下のような項目がクリアされることを望んでいると述べた。
- 全世界をカバーできるスケーラビリティの確保
- コントローラの分散化・冗長化
- 保守機能の充実
- 実現コスト
OpenFlow/SDNのメリットを生かして適用領域を広げることを考えると、これまで述べた課題だけでなく、さまざまな課題を乗り越えていく必要がある。NTTコミュニケーションズでは、新たな取り組みであることを理解したうえで、技術的なフィージビリティを確認するというスタンスで、適用領域拡大に向けて技術課題を洗い出しているところだという。
特に重要なのが、保守機能（OAM）である。通信事業者の視点からは、物理ネットワーク、論理ネットワーク、ユーザーネットワークと階層化している中で、いかに安定運用を実現するかが課題になる。特に、コントロールプレーン（C-Plane）とデータプレーン（D-Plane）の分離による不一致が懸念されるが、現時点ではOpenFlowはOAM機能を持たず、故障検知や切り分けが困難な状況だ。これを踏まえ、ぜひともOAM機能がほしいところだと同氏は述べた。
ほかにOAMに求められる要件としては、以下のような項目があるという。
- 故障の発生をオペレータが認識できること
- 故障個所の特定ができること
- 冗長区間であれば切り替わること
- 必要によって網外の装置に通知できること
SDN/OpenFlowにおけるOAMモデルの取り組みとしては、「ソフトウェアで実装することで、汎用スイッチに必要最小限のOAM機能を実装できないか」との考えから、OpenFlowコントローラの「アプリケーション」としてOAM機能を実装する方法が検討されている。OpenFlowスイッチの中にOpenFlowエージェントを組み込むなどの方法も可能かもしれない。NTTコミュニケーションズでは、さまざまな事柄を勘案してフィールドトライアルを行っているそうだ。
これからのネットワークは、「ハードウェアベース」の従来のネットワークと、SDNのような「ソフトウェアベース」の考え方とをうまく使い分けることが重要になるという。SDNという新しい概念が生まれる背景には、スピード感や柔軟性がこれまで以上にネットワークに求められている状況がある。
これまでのネットワークの作り方から見れば、SDNではソフトウェアの比重があまりに増えているように思えるかもしれない。しかし、デバイス技術が進展し、さらにネットワークの課題を解決する新たなソフトウェアベースの技術概念が誕生した今こそ、SDNに取り組む絶好の機会であると伊藤氏。「顧客にとってもサービス提供者にとってもメリットあるネットワークを構築できるように、OpenFlow/SDNがさらに発展していくことを期待する」とまとめた。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。