By
Translated by
2021年5月27日に、 TIP (Telecom Infra Project) は、分離分散型バックボーンルータ (DDBR; Disaggregated Distributed Backbone Router) を明記する技術要件仕様書を公開しました。このアーキテクチャは、Vodafone、Telefonica、MTN、KDDI の 4 つの大手通信サービス事業者が、業界を「正しい」方向へ導くために協力した結果です。TIP の意図は、過去数十年にわたり業界で容認されてきた、従来のベンダ主導のサイロ化した実装を回避することにありました。
テレコムインフラプロジェクトが業界標準を設定する
TIP では、通信サービス事業者がベンダーフリーな研究指向の議論を行い、それぞれの専門知識と要件を持ち寄ることができるように運営されています。その目指すところは、ネットワーク オペレータが遭遇する問題の多くを解決するために最も意味のある汎用的な定義を作成することです。重要な点として、TIP の定義はオープンかつ分離可能なアーキテクチャをベースにしていることが挙げられます。
ドライブネッツ ネットワーククラウドの紹介
TIP に参画するオペレータがこれらの汎用的な定義を完成させる主な理由として、スケーラビリティ、総所有コスト（TCO; Total Cost of Ownership）、ユースケースの柔軟性という 3 つのポイントが挙げられます。この 3 つの柱は、クラウドとモノリシック インフラストラクチャ モデルの違いも説明しています。この考えはしばらくここに留めておいて、後でまた取り上げることにしましょう。
TIP の次のステップは、シンプルな RFI フェーズで要件シートに回答させることで、ベンダーをプロセスに参加させることでした。このとき、DriveNets と他のベンダーのグループは、TIP の DDBR の定義に初めて目を留めたのです。
DriveNets がネットワーク業界に参入
DriveNets は、ネットワーク機能として最適な仮想ルーターを実装するというミッションを掲げ、2016 年初頭に創業しました。他の多くのネットワーク機能仮想化（NFV; Network Function Virtualization）実装 [4] と同様に、私たちのものも、当初は、商用デプロイの要件を満たすことが出来ませんでした。私たちの実装は純粋なソフトウェアだったので柔軟性があり、複数のサーバーで動作するので拡張性はあったのですが、三角形を完成させるために当初欠けていたのは TCO の点でした。
NFV のネタバレになりますが、ネットワークに不向きなハードウェアをベースにしたネットワーク機能 (NF; Network Function) を構築することは、概念的に非効率的です。これを身近な NFV 事例に適用すると、NFV がネットワーク指向（vs 機能指向）であればあるほど、その市場での成功には負の相関関係があることがわかるでしょう。
ドライブネッツ ネットワーククラウドの定義
TCO、スケール、柔軟性に焦点を当て、我々は ドライブネッツ ネットワーク クラウドを定義する旅に出発しました。ここでは、従来のネットワーク構築の方法をディスラプト (破壊) するための道程で通過したいくつかのマイルストーンを紹介します。
第一に、ネットワーク内のルータの種類が多すぎる事態を避けるためには、同じソリューションがどのようなネットワークの場所やユースケースにもフィットする必要があることを理解していました。サイズや機能は様々でも、次の図に示すように、ネットワーク全体で同じ標準デバイスを使用する必要があります。
図 1. 分離型オープン・ルータ (Disaggregated Open Router) の範囲
ビジネス機会としては、大規模な IoT やミッションクリティカルなアプリケーションなど、5G がサポートする新しいサービスやユースケースへの適用があります。これは、5G のインフラとサービスを収益化するための取り組みで、新しいターゲット市場にサービスを提供し、新しい収益源を生み出す機会です。
第二に、データ・コントロール・マネジメントの各プレーンのモノリシックな結合を分散させる必要があります。またそれぞれが相互に影響を与えずにパフォーマンスとスケーリングを行うために、互いに独立して制御される必要があります。これらの各プレーンのモノリシックな結合について、以下の図 2 で説明します。
図 2.モノリシック IP バックボーンルーター
第三に、シングルボックス内でのネットワークのスケールアップは限界があることに気づきました。ASIC の能力を最大限に引き出し、ネットワークの要求を満たすには、スケールアウト型のトポロジーが必要です。シングルボックス内でのスケールアップの問題点を図 3 に、望ましいスケールアウトトポロジーを以下の図 4 に示します。
図3.従来のスケールアップ・パス
図4.分離されたスパイン＆リーフ・アーキテクチャ
第四の洞察は、図 5 に示すように、コントロールプレーンをデータプレーン デバイスから分離し、専用のコンピュートリソースに移動させながらホワイトボックスを使用することの重要性です。
図 5.分散型分離バックボーンルーター
このように分離することで、コントロールプレーンは、低コストのホワイトボックス ベースのデータプレーンから独立して、柔軟に拡張・進化させることができます。
未来のネットワークインフラを構築する
ここで、クラウドインフラを定義する 3 つの柱を振り返ってみましょう - TCO、スケール、柔軟性の 3 つでした。DriveNets はドライブネッツ ネットワーク クラウドと呼ぶ未来のネットワーク・インフラストラクチャを構築するにあたり、この 3 つの柱の実現に注力しました。
クロージングとして、一言付け加えたいと思います。上記のアイデアや気づきが DriveNets の進化を促し、ドライブネッツ ネットワーク クラウドというソリューションにつながったのです。とはいえ、ネットワークの世界を業界がどう進化させるべきかの根拠としてこの記事に貼り付けた図表は、すべて TIP DDBR 技術要件仕様書 [7] から引用したものです。
DDBR、DDC（Disaggregated Distributed Chassis; 分離分散型シャーシ）、ネットワーク クラウドといくつかの呼び方がありますが、どう呼ばれようとも、アーキテクチャの基本ロジックが単純にうまくいきさえすれば、それが業界標準になるに違いないと言ってよいでしょう。
