ネットワークエンジニアリングに関するコンサルティングサービスを提供している米NetCraftsmenで主席アーキテクトを務めるテリー・スラッテリー氏は、米ラスベガスで開催された「Interop」において、参加者であるネットワークエンジニアとテレコムエンジニアに対して次のように語った。「音声と動画はネットワークのパフォーマンスの影響を受けやすいため、優先ネットワークリソースが必要になる。SDNは音声と動画に優先ネットワークリソースを確実かつ自動的に付与することができる。だが、UCのためのSDNを本格稼働するのはまだ時期尚早だ」

　米HP NetworkingやNECなどのベンダーは、UCのためのSDNに焦点を当て、米Microsoftと連携して「Skype for Business（旧Microsoft Lync）」とのネットワーク通信をソフトウェアによって実現することに取り組んでいる。Microsoftは同社のUC プラットフォームの致命的な問題を特定するため、2014年にSDN APIをリリースした。

デバイスを制御する中央集中型コントローラーソフト「Cisco APIC」（出典：シスコシステムズ）《クリックで拡大》

　一方で「米Cisco Systemsは別の道を歩んでいる。従来のネットワーク設備で機能する同社の「Cisco Application Policy Infrastructure Controller（APIC）」でデバイスのタグ付けを可能にした」とスラッテリー氏は語る。

　デバイスにタグ付けすることで、企業はデバイスをPC単位ではなく機能や役割でグループ化できるようになり、ネットワークはプログラムで操作しやすくなる。

既存のUCアプリケーションのネットワーク制限

　従来のネットワークは静的に構成されていた。そのため、個々のアプリケーションの要求に応じることはできなかった。また、リアルタイムのトラフィックを十分に把握することができないため、音声と動画の配信に影響するネットワークの変化をアプリケーションに伝達できない。

　 「技術者は手動でCLI（コマンドラインインタフェース）コマンドを使用することに長けている。そのため、自動化によってネットワークが停止することを不安視している。アプリケーションとネットワーク間の相互通信、高速な自動化された構成、組み込みのセキュリティ、新しいフォワーディングパスの選択などといった機能を使うUCにとって、SDNは導入する価値のあるテクノロジーだ」とスラッテリー氏はいう。

　REST（Representational State Transfer）のアプリケーションプログラミングインタフェース（API）では、一元管理されたSDNコントローラーとアプリケーションがUCコントローラーを介して対話できるようにする。

　「トラフィックの種類に基づいてパスを動的に選択するようにしたい」とスラッテリー氏は語る。SDNのポリシーは、ネットワークでオーバーサブスクリプションが発生しているときに、必要な処置を行うことができる。具体的には、UCコントローラーにコーデックの調整を要求したり、通話を拒否したり、パケットをドロップしたり、別のパスにトラフィックを移したりすることができる。

　UCアプリケーションのためにSDNを使用すると、動的なサービス品質が実現可能だ。通話受付管理（CAC）を複数のUCアプリケーションに統合すれば、リアルタイムのメディアトラフィックが混雑したパスを通らないようにすることができる。

SDNのUCへの適用事例

　米Nemertes ResearchでUCアナリストを務めるアーウィン・ラザル氏は「SDNはまだ誕生して日が浅い。そのため、現時点でSDNがUCに使われるのは、UCアプリケーションが自身の要求をネットワークに伝達することでネットワークがリアルタイムで自動的に構成できるところに限られる」と話す。

　UCアプリケーションは、ネットワークに対してこれから通話を発信するところであることを伝達し、把握しておくべき事象が発生していないかどうかを尋ねる。「この機能は、ふくそうの発生頻度が高いワイヤレスネットワークにおいて特に便利だ」と、ラザル氏は語る。

　もう1つのユースケースは、SDN APIを活用してトラフィックの情報を取得することだ。SDN APIは各種ネットワークコンポーネントのネットワークの接続を確認して、音声や動画などの特殊なアプリケーションに関連するフローで何が起こっているかを明らかにする。ラザル氏によれば、一部のベンダーはネットワーク調査が不要な管理を可能にするSDNの使い方を模索しているという。

UC SDNの進め方

　ネットワーク担当者の中には、ネットワークの自動化によって自分たちの仕事がなくなることを危惧している人もいる。スラッテリー氏はこの意見に反対し、UC SDNを企業にとって価値あるものにするためには、さらに努力が必要だと付け加える。

　「ベンダーが提供するドキュメントは曖昧な点が往々にしてある。誰かがSDNの機能を特定しなければならない。SDNの監視やトラブルシューティングに関して言及されたことはないが、どちらも最終的には突き止めたいことだ。また、ベンダーはSDNの機能を特定する方法について考える時間をもっと多く取るべきだ。SDNを取り巻く全てのものが過渡期にある。ユースケースは必要な機能を定義するのに役立つ」とスラッテリー氏は語る。

　リアルタイムのコミュニケーションはSDNによって改善される見込みがある。だが、スラッテリー氏は企業に対して、現時点ではネットワークアーキテクチャのプランを変更せず、一方でUCアプリケーションのためのSDNプランを計画するようベンダーに圧力をかけることを提案している。

　スラッテリー氏は、企業でネットワークやアプリケーションを担当しているチームがSDNに慣れるために、チームで協働してSDNがUCにもたらすメリットを明らかにすることを推奨している。まず、ネットワークの小さな部分でSDNを試してみるとよいだろう。それが問題なく機能すれば、SDNの範囲を広げることができる。