ソフトウェア定義ネットワーク （ SDN ）の分野でスタートアップや開発を行っている人を驚かせることはありません。このトピックは、大企業やオープンソースコミュニティの両方で広く研究されています。



ただし、最近まで、ほとんどすべての開発はデータセンターのインフラストラクチャの管理を目的としており、1年以上前に、 SDNの概念をトランスポートネットワークに適用できるとは考えていませんでした。



2015年10月、 NetCrackerの T-SDN （ トランスポートソフトウェア定義ネットワーク ）コントローラーが、ヨーロッパのオペレーターの1つのネットワークに展開されました。 このコントローラーにより、ネットワーク操作の大部分が自動化され、その結果、オペレーターは大幅に時間を節約できました。これは、エンジニアがネットワークのセットアップとサービスの提供に費やした数百時間です。

ネットワーク構造

ドメイン内のネットワーク要素には、実際に再構成可能な光入出力マルチプレクサであり、ネットワーク要素間の信号パスを変更できるROADM / WSSカードが含まれていました。 クライアントポート間でドメイン間接続が発生し、これらのポートはトランスポンダーと呼ばれるボード上にあります（光トランスポンダーは、端末アクセス機器とWDM回線間のインターフェイスを提供するデバイスです）。 私たちの場合、10 Gbit / s（ IEEE 802.3ae ）クライアントインターフェイスと集約ODU4を備えたトランスポンダー が使用されました 。 ODUは、ルート全体でこのデータの制御を提供するデータコンテナーであり、 OTN （ 光トランスポートネットワーク ）テクノロジーの一部です。 テスト光​​ネットワークは、1つの物理ファイバーで最大80個のこのようなコンテナーを送信でき、それぞれの速度は100ギガビット/秒でした。





コントローラは、ネットワーク上で次の機能をサポートできました。

• クライアントの要求に応じたネットワーク上のサービスの自動敷設;
  
  
  
  
• デバイスポートに障害が発生した場合の保護ルートへの自動切り替え、またはデバイスが保護ルートをサポートしていない場合のルートの再計算。
  
  
  
  
• エラーと通知の監視。

T-sdn

彼らの建築家とイデオロギーのインスピレーションがT-SDNの概念に何を入れたかをより詳細に理解してみましょう。



T-SDNの主なアイデアは、データセンターのSDNと同様に、 データプレーンとコントロールプレーンの分離です。これは、トランスポートネットワークの特定のドメインのネットワークデバイスと対話する単一のコントロールコントローラーの作成によって実装されます。 。 コントローラーの上にはアプリケーション層 （ SDNアプリケーション層 ）があり、特定のインターフェースを介してコントローラーと通信します。 コントローラはドメインの構造に関するすべてを知っているという事実により、ネットワークを改善するための追加の機会があります。 それらのいくつかについては、異なるプロトコルのソリューションがすでに存在しますが、 T-SDNは既存のアプローチを大幅に改善できます。



T-SDNが提供するもの：

• トランスポートネットワークでの運用の簡素化。
  
  
  
  プロバイダーからのサービスのリクエストは、オンラインストアで注文するのと同じくらい簡単であると想定されています。 注文が行われると、コントローラーはすべてのデバイスを自動的に再構成し、必要なリソースを割り当てます。 したがって、クライアントは数分で必要なサービスを受け取ります。
  
  
  
  
• 最適な帯域利用率。
  
  
  
  チャネル容量の使用を最適化する（または、言うまでもなく、チャネルの最適な使用）は新しいタスクではありません。 ただし、トランスポートネットワークでのクライアントチャネルの動的な配布のための完全なソリューションはまだ存在せず、将来、トランスポートコントローラーがこのタスクを処理することが想定されています。
  
  
  
  例として、このケースを検討してください。 クライアントトラフィックは、2つの方法で光デバイスAとBの間を通過します。 青い点線は光ファイバ、黒い線はクライアントチャネルです。 グラフは、チャネルのどの部分がビジーで、どれが空いているかを示します（それぞれ赤と緑の色）。
  
  
  
  
  
  ここで、接続の帯域幅の50％を占める新しいクライアントチャネルを配置する必要があると想像してください。 これを行うには、たとえば、上から下のパスに行くチャネルの1つを保持して、接続の50％を解放します。
  
  
  
  
  
  この操作は、既存のクライアントがトラフィックが逆方向に進んでいることに気付かないように実行する必要があります-短期的なサービス拒否やサービス品質（ QoS ）の低下でさえも受け入れられません。 このようなチャネルの再配布は可能ですが、現時点ではエンジニアが手動モードで実行しているため、多くの時間がかかり、エラーが発生する可能性があります。 コントローラーはこのプロセスを潜在的に自動化できます。 帯域幅の使用は実際には100％不可能であることに注意する必要があります。図は問題を説明するためだけのものです。 実際、リサイクル率は通常約80〜90％です。
  
  
  
  
• オンデマンド帯域幅-トラフィックが購入したチャネルの容量を超えた場合、クライアントサービスの帯域幅が自動的に増加します。 この動作により、データを短時間で高速で送信できるようになり、ピーク負荷時のパケットのドロップも防止されます。 要求時の帯域幅には、クライアントからの大きな財政投資は必要ありません-帯域幅が増加した期間のみ支払う必要があります。
  
  
  
  
• トランスポートネットワークで最適なルートを構築します。
  
  
  
  一元化されたネットワーク管理により、さまざまなメトリックと要件を考慮して、サービスを敷設するためのルートを最適に選択できます。
  
  
  
  
• 高レベルの信頼性とサービスの可用性（ 高可用性 ）。
  
  
  
  自動制御により、ネットワーク障害に迅速に対応できます。 コントローラーは、障害が発生した場合の迅速なサービス回復のために、保護ルート予約のあらゆる方法をサポートしています。
  
  
  
  
• 高レベルのアプリケーションを介してネットワーク構成を保護します。
  
  
  
  ネットワーク管理者がデバイスの構成を変更すると、エラーが発生し、長期的なサービス拒否などの深刻な結果につながる可能性があります。 エンジニアのエラーによるグローバルネットワークの重大な混乱の多くのケースがあります。これは、インターネットの重要な部分に影響を与える2015年6月12日のルートリークでした。 高レベルのビジュアルアプリケーションを使用すると、誤った構成の可能性を大幅に減らすことができます。ほとんどの細心の作業は自動的に行われます。
  
  
  
  
• システムを簡単にスケーリングする機能（ スケーラビリティ ）。
  
  
  
  デバイスと制御アプリケーションの数を増やすことは、追加のコントローラー設定なしで実行されます。
  
  
  
  T-SDNのこれらおよびその他の宣言された機能は、厳しい批判や不信など、非常に異なる反応を引き起こしますが、ソフトウェア構成のトランスポートネットワークの本格的な研究、プロトタイピング、およびパイロットローンチのみが状況を真に理解できます。
  
  
  
  モスクワ、サンクトペテルブルク、ニジニノヴゴロドのNetCrackerの従業員は、 NECエンジニアの支援を受けて、現在T-SDNの研究とT-SDNコントローラーの機能の開発を積極的に行っています。
  
  

NetCracker T-SDNコントローラー

コントローラーの開発時には、次の要件のサポートに焦点を当てます。

• 大規模プロバイダーの高度に分散されたトランスポートネットワークの完全な管理。
  
  
  
  
• プロバイダーのネットワーク全体にルートを敷設する。
  
  
  
  
• 要件とさまざまなメトリックに基づくルートの最適化。
  
  
  
  
• マルチベンダーネットワーク（さまざまなメーカーのデバイス上に構築されたネットワーク）のサポート。
  
  
  
  
• 要求に応じた帯域幅。
  
  
  
  
• 高レベルの信頼性とサービスの可用性。
  
  
  
  
• システムを簡単にスケーリングする機能。
  
  
  
  
• 最適な帯域利用率。

NetCrackerは、あらゆるレベルでプロバイダーのネットワークを単独で制御できるコントローラーを開発しています。 このようなネットワークを管理するためのパフォーマンス要件は非常に高いため、コントローラーは、 T-SDNドメインコントローラー（低レベルコントローラー）とT-SDNコントローラー（高レベルコントローラー）自体の2種類のコントローラーで構成される階層構造を持っています。 ドメインコントローラーは、ネットワークの一部、つまり特定のドメインのみを管理し、トランスポートネットワークデバイスを直接管理する機能を引き継ぎます。 最上位コントローラーはネットワークデバイスではなくドメインコントローラーを管理するため、ネットワークインフラストラクチャとの通信から抽象化され、システムパフォーマンスを向上させることができます。 ネットワーク管理タスクは分解され、下位レベルのコントローラーに委任されます。 最上位のコントローラーは、ドメインに関するデータを受け取り、それらを処理して、さらにアクションを実行します。



次の図は、 T-SDNドメインコントローラー（単一ドメイン管理）および最上位のT-SDNコントローラー（すべてのドメインの管理）によって管理されるネットワークを示しています。





簡単に言えば、最上位のコントローラーは、デバイスのグループ全体を1つのデバイスとして「認識」します。 この概念により、一方では大幅なオーバーヘッドコストを回避し、パフォーマンスを向上させることができます。他方では、ドメインコントローラーの可視性範囲にないため、ドメインレベルで制御できないクロスドメイン接続とともにネットワーク全体を表示することができますT-SDN このアプローチにより、ネットワーク全体にクライアントサービスを配置できます：プロバイダーのネットワークへの入り口から出口まで、サービスの効率的な管理、ルートの最適化、信頼性、可用性を実現します。

NetCracker T-SDNコントローラアーキテクチャ

NetCrackerとNECは T-SDNコントローラーアーキテクチャを開発しました。 アーキテクチャは階層構造です。 下位レベルはネットワークインフラストラクチャであり、そのデバイスは、一部のAPIを介して、独自のSDNコントローラーを含むドメインのデバイスと通信します。 次に、ドメインコントローラーのレベルがあります。ドメインコントローラーは、単一のトップレベルT-SDNコントローラーに接続されます。 最上位レベルには、監視および構成機能を提供するアプリケーションがあります。





NetCrackerによって開発されたコントローラーアーキテクチャは、2014年にOpen Networking Foundationによって提案されたSDNリファレンスアーキテクチャ（ ONFアーキテクチャ ）と完全に統合されています。 これにより、 T-SDNコントローラーが国際標準に完全に準拠していることが確認されます。 このようなアーキテクチャの実行可能性は、さまざまなメーカーの機器を使用して、 NetCrackerネットワーク研究所ですでに何度かテストされています。



コントローラーには、次のメインモジュールがあります。



ルートの敷設 （ パスプロビジョニング ）には、論理レベルでルートを構築する操作が含まれます。また、メディエーターと直接対話し、接続されたドメインコントローラーから処理された情報を受け取ります。



パス計算は、さまざまな基準を考慮して、ネットワークグラフ上のルートを決定します。



利用管理は、チャネル容量の使用を最適化する責任があります。



サービストポロジ （ サービストポロジ ）は、関連する計画されたサービスとそのパラメータを保存します。



メディエーター （ メディエーション ）は、基礎となるデバイスのAPIの操作を担当し、 RESTCONF 、 NETCONF 、 SNMP 、 SSH 、 OpenFlow 、 HTTP / HTTPSなどのかなり豊富なネットワーク管理プロトコルセットをサポートします 。



コントローラー管理は、 ISO標準の FCAPSモデルに準拠しており、 コントローラーの構成、障害、およびパフォーマンスの制御を含みます。

パス計算モジュール

最も興味深い複雑なコントローラーモジュールの1つは、パス計算モジュール（ PCE ）です。これは、クライアントが要求したサービスの特定のパスを計算するモジュールです。 このようなモジュールの実装は、数学的アルゴリズムの観点からは簡単な作業ではありません。 OSPFおよびIS-ISチャネルルーティングプロトコルまたはHWMP 802.11sリンクレイヤールーティングプロトコルの専門家は、問題が長い間解決され、実装され、タイムテストされていると言うことがあります。たとえば、ダイクストラのアルゴリズムなど、およびその修正。 ただし、さまざまなベンダーの機器によって課せられた仕様、およびシステムに提示される要件により、詳細な分析と重要なアプローチを必要とする根本的に新しいパスを見つけるタスクが行われます。



PCEの主な要件：

1. 存在するパスを見つける。
   
   
   
   
2. メトリックの柔軟なサポート。
   
   
   
   
3. 訪問することが望ましいまたは望ましくないサイトの会計。
   
   
   
   
4. 訪問に必要なサイトの登録。
   
   
   
   
5. 訪問が禁止されているサイトの登録。
   
   
   
   
6. 機器メーカーからの独立。

特に難しいのは、パラグラフ4と6です。



グラフ上の最適なパスを特定の頂点への必須の訪問で見つけることはNP完全タスクですが、ドメインごとに個別にパスを計算すると、時間コストが最適化されます。 この問題を解決するために、ヒューリスティックアルゴリズムがダイクストラパス検索アルゴリズムと組み合わせて使用​​されます。



製造元からの独立性は、特定の製造元のデバイスの内部構造の実装とこの構造が課す制限に関係なく、正しいパスを見つけることを必要とします。 この問題を解決するために、物理レベル、物理レベル、および抽象レベルを含むマルチレベルグラフ上のパスを見つけるためのフル機能のアルゴリズムが開発されています。

さらなる開発

パイロットバージョンの正常な起動により、 T-SDNコントローラーの開発者はONOSやODENOSなどのオープンソースプロジェクトの開発に貢献し、 Open Networking Foundationや他の組織での新しいSDNテクノロジーの標準化に参加できます。



このプロジェクトは、高度なネットワーク機器のメーカーであるNECとの緊密な協力により開発されています。 したがって、コントローラーの機能は、 NetCrackerネットワーク研究所でNECの最新デバイスでテストされており、 NetCrackerとNECの開発部門は、密接に協力して技術的な問題を直接議論する機会があります。 この相互作用により、ベンダーの機能をよりよく理解し、ネットワークデバイスをより効果的に使用できます。



大規模プロバイダーの機能的ニーズは絶えず増大しています。T-SDNコントローラーに関心のある企業は、 NetCracker開発者に新しい、より複雑で興味深いタスクを容赦なく提供しています。 メディエーターの低レベルのネットワークインターフェースからアプリケーションの視覚化と制御に至るまで、絶対にすべてのコンポーネントが重要な開発を受け取ります（そしてすでに受け取ります）。 NetCracker T-SDNコントローラーチームは、 OSSおよびBSSソリューションの大手プロバイダーとの長年の経験により、この挑戦​​的であるが非常に興味深い分野の開発の基盤を確立しました。