25 年以上にわたってシャーシベースのルーティング・プラットフォームを導入してきたサービスプロバイダーは、柔軟性、規模、コストの面でこのプラットフォームが持つ課題を世界的に認識してきました。
長年にわたりシャーシベースのルーターの容量や限られたスロットを超えて拡張するための選択肢は（よくあることですが）シャーシの追加導入や、より多くのスロットとラインカードを備えた使用率の低い大型シャーシへのアップグレード、マルチシャーシ・ソリューションの採用など多岐にわたっていました。
ドライブネッツ ネットワーククラウドの紹介
これらのオプションはどれも簡単で理想的なものではありません。実際、ルーターを追加するのは高価で、ルーティングやトランクの複雑さが増します。アップグレードには、フォークリフトの使用に触れるまでもなく、より多くの電力と冷却が必要です。そして数年ごとに繰り返されるこのサイクルは、控えめに言っても苦痛です。
大規模なクラウド・プロバイダーがデータセンター・サーバー・アプリケーションとそれに関連するスパイン／リーフの展開（3層 CLOS）を採用するようになったため、サービスプロバイダー（SP）も大規模なコア／アグリゲーション・ルーターをスケールアウトするために CLOS アーキテクチャを検討するようになりましたが、そのアプリケーションはクラウド・プロバイダーのデータセンター内のトラフィックパターンやアプリケーションと完全に一致するとは限りません。特に、ToR（トップ・オブ・ラック）のリーフ／スパイン・スイッチと関連チップは、SP のキャリアクラスのルーティング要件にはあまり適していません。また SP のコロケーションでは、トラフィック・フロー・パターンがデータセンター内のサーバー間を行き来する横方向トラフィック (East-West) が支配的ということもなく、一貫性のある決定論的な QoS 処理とコンバージェンスのニーズも大きく異なります。さらに、数百台とは言わないまでも、数十台のリーフデバイスを管理し、自動化する負担も加わります。したがって、SPは大規模なルーティング・ファブリックにCLOSを選択する前に、あらゆる要素を慎重に検討すべきであり、クラウド・プロバイダーの間で人気があるからという理由だけでCLOSを採用すべきではありません。
幸いなことに、オープン・コンピュート・プラットフォーム（OCP）の分離分散型シャーシ（DDC）とテレコムインフラプロジェクト（TIP）の分離分散型バックボーンルーター（DDBR）拡張は、両方のアーキテクチャの長所を組み合わせたハイブリッドソリューションを提供しています。これらのソリューションは、ドライブネッツを含む複数のプレーヤーによって提供され、ベンダーのサポートが拡大しています。マルチシャーシを避ける一方で、DDC（分離分散型シャーシ）は従来のシャーシ設計のスケーリング問題に対処し、無制限のデータプレーンとコントロールプレーンのスケールアウトを提供します。物理的な接続性は CLOS アーキテクチャに似ていますが、従来のシャーシ・ベース・ルーターの管理のシンプルさとキャリアクラスのルーター性能を維持しています。また、DDC（分離分散型シャーシ）ルーターには複数のスパイン＆リーフ・コンポーネントが含まれますが、ソフトウェアによって論理的に囲い込まれ、単一の制御および管理プレーンを提供します。CLOS アーキテクチャとは異なり、DDC ではスパインとリーフ・ボックス間の何百ものリンク間でルーティング・プロトコルを実行する必要がないため運用、トラブルシューティング、モニタリングの面でコア/アグリゲーション/エッジ・ルーターのインスタンス化が簡素化されます。
マルチサービス・ルーティング・アプリケーションに「適切な」次世代アーキテクチャを選択するには、常に妥協が必要です。サービスプロバイダーは運用の簡素化を優先するため、シャーシベースのアーキテクチャを選択する傾向があります。
一方、拡張性を重視するデータセンター（DC）は、通常、CLOS（スパインとリーフ）を好むことができます。SP のネットワーク・アーキテクチャを選択する場合、従来の CLOS ソリューションがキャリアクラスのパフォーマンス、マルチサービス・ルーターによる独自のトラフィック・フロー・パターン、複雑な分散制御およびデータプレーン機能のコストを満たすかどうかを慎重に評価する必要があります。ほとんどの場合、シャーシと CLOS アーキテクチャの両方の長所を組み合わせた DDC（分離分散型シャーシ）ソリューションを選択することになるでしょう。