仮想化と通信分野のキーテクノロジーであるSoftware-Defined Networkingは、業界の注目の的となっており、Software-Defined Networkingが光トランスポートネットワークを根本的に変える可能性を秘めていることは既知の事実です。
ネットワークエンジニアはついにネットワークリソースの最適化とサービス割り当ての自動化のために中央制御とプログラマビリティを適用することができるようになります。しかし、ここで技術プロバイダは中央の SDN コントローラがファイバーネットワークと通信する方法を開発しなければなりません。
ほとんどの SDN テクノロジはイーサネットをターゲットにしています。通常、中央の制御層とデータ層は物理ネットワークから分離され、全てのネットワークフローを管理するソフトウェアコントローラに集約されます。しかしながら、光トランスポートネットワークはしばしば異なるアーキテクチャとプロトコルを使用するため、制御レイヤとデータレイヤを分離し、ネットワーク上にそのようなコントローラを展開することは困難です。
この問題に対処するために、現在、多くのベンダが SDN コントローラとファイバー・トランスポート・スイッチの仲介役となるオープン・トランスポート・スイッチ (OTS) を開発しています。OTS はコントローラと通信するために OpenFlow プロトコルを使用し、スイッチはそのスイッチ固有のコマンド構文を使用します。
多くのトランスポートスイッチがあるネットワークでは、各スイッチに割り当てられた OTS は SDN コントローラにそのスイッチの能力を伝えます。その結果、コントローラはリンク数、リンク帯域幅、QoS 特性、接続性を含む各スイッチに関する情報を収集し、ネットワークの全体的なビューを作成することができます。このネットワークビューにより、コントローラは特定の帯域幅とQoS要件を満たす接続でアプリケーションの要求に応えることができ、コントローラが異なるベンダーのさまざまなスイッチを設定および監視する必要がなくなります。
OTS の内部モジュールはハードウェア機能を SDN コントローラに送信し、いくつかの状態変化を報告し、パフォーマンスを監視し、コントローラのコマンドに従ってハードウェアリソースを設定します。コマンド構文が異なるので、トランスポートスイッチのタイプ毎に特別な OTS が必要ですが、コードの多くは同じです。ハードウェアに直接接続されているモジュールだけが、OTSの実装で異なります。
SDN コントローラがオープンなトランスポートスイッチを通してどのように通信するか
オープンなトランスポートスイッチは2つの動作モードをサポートします: 明示的と暗黙的です。明示的モードでは、SDN コントローラはネットワーク内の全てのトランスポートスイッチを認識します。各スイッチは OTS 実装に関連付けられていなければなりません。この接続を設定するために、コントローラはパス上の全ての OTS とスイッチと通信しなければなりません。
一方、暗黙モードはトランスポートドメインですぐに利用できるルーティングとシグナリングのコントロールパネルプロトコルを利用します。各エッジスイッチは OTS に関連付けられなければなりませんが、完全にネットワーク内部にあるスイッチはその必要はありません。
コントローラは、各境界のOTSと通信することで、ドメイン全体の接続を作成します。その後、OTSは既存のコントロールパネルプロトコルを使用して、このスイッチをドメインの別の境界に接続します。このコントローラーは、複数のドメインへの接続を得るために、すべてのドメインの境界にあるスイッチを接続するリンクを設定します。
インプリシット・モードを使用することで、ネットワーク・サービス・プロバイダーは移行パスを得ることができます。オープン・トランスポート・スイッチを提供する必要があるのは、ボーダー・スイッチだけです。サービス・プロバイダーは徐々にOTSやスイッチを追加し、それらを明示モードに設定するか、あるいは暗黙モードを使用し続けることになります。第3の可能性は、一部のネットワーク・コンポーネントがステルス・モードを使用し、他のコンポーネントが明示的モードを使用する混合環境です。
あるいは、サービス・プロバイダがトランスポート・スイッチをパーティション化し、2つ以上のOTSを実装して、各パーティションがリンクの一部を管理するようにしてもよい。各スイッチ・パーティションは、マルチリース環境で特定の顧客に割り当てることができます。
要約すると、開発者はOpenFlowプロトコルを拡張する必要があります。現在、OpenFlow はパケットしか扱えません。トランスポートネットワークをサポートするためには、タイムギャップやクロスコネクトといった回線切り替えを扱うコマンドを追加する必要があります。Open Networking Foundation はこのような OpenFlow の拡張について議論しており、近いうちに結果が出ると思います。
