ネットワーク内コンピューティング: プログラマブル データ プレーンとテクノロジー固有のアプリケーションの調査

ネットワーク内コンピューティング: プログラマブル データ プレーンとテクノロジー固有のアプリケーションの調査

要約 - クラウド コンピューティングと比較して、エッジ コンピューティングはエンド デバイスに近い処理を提供し、ユーザーが経験する遅延を短縮します。最新のインネットワーク コンピューティング パラダイムは、プログラム可能なネットワーク要素を使用して、データがエッジ サーバーまたはクラウド サーバーに到達する前に計算を行い、共通のエッジ/クラウド サーバーベースのコンピューティングを促進し、エンド デバイスに近いワイヤスピードの処理機能を提案します。このペーパーでは、ネットワーク内コンピューティングのユースケース、実現テクノロジー、およびプロトコルについて説明します。私たちの調査によると、プログラマブル データ プレーンを実現テクノロジーとして考慮すると、潜在的なネットワーク内コンピューティング アプリケーションには、ネットワーク内分析、ネットワーク内キャッシング、ネットワーク内セキュリティ、ネットワーク内調整が含まれます。さらに、クラウド コンピューティング、エッジ コンピューティング、5G/6G、NFV の範囲内には、特定のテクノロジー用のインネットワーク コンピューティング アプリケーションもあります。この調査では、提案された分類枠組みに基づいて最先端技術を調査します。さらに、方法論、主な結果、およびアプリケーション固有の基準の観点から、方法を比較するための一連の提案された基準を提供します。最後に、学んだ教訓について議論し、いくつかの潜在的な研究の方向性を強調します。

キーワード – インネットワーク コンピューティング、プログラマブル データ プレーン、ソフトウェア デファインド ネットワーク、クラウド コンピューティング、エッジ コンピューティング、6G、およびネットワーク機能の仮想化。

I.はじめに

長年にわたり、コンピューティングの歴史は、従来の並列コンピューティング、グリッド コンピューティング、クラウド コンピューティングというさまざまなパラダイムを通じて進化してきました。クラウド コンピューティング [1] は、サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、およびサービスとしてのソフトウェア (SaaS) を含むさまざまなサービス モデルを提供し、スケーラビリティ、オンデマンドのリソース プロビジョニング、オンデマンドの価格モデルを提供します。ボリューム課金、便利なアプリケーションとサービスのプロビジョニング、その他の利点と機能。

IaaS (サービスとしてのインフラストラクチャ) は基本層です。この層では、IT の基本リソース (コンピューティング、ネットワーク、ストレージ) が集約され、仮想化と動的化を通じてリソース プールが形成されます。リソースプールとはコンピューティング機能の集合体であり、エンドユーザー（企業）はネットワーク経由で必要なコンピューティングリソースを取得し、独自の業務システムを稼働させることができます。このように、ユーザーはこれらのインフラストラクチャを自分で構築する必要はなく、料金を支払うことでこれらのリソースを使用できます。

IaaS レイヤーの上には、PaaS (Platform as a Service) レイヤーがあります。この層には、基本的なコンピューティング機能を提供することに加えて、ビジネス開発および運用環境もあり、個々の開発者や企業が対応する機能モジュールをソフトウェアまたはハードウェアに組み込むためのアプリケーション コード、SDK、オペレーティング システム、API などの IT コンポーネントを提供します。開発効率を向上させます。企業またはエンド ユーザーにとって、この層のサービスは、ビジネス イノベーションのための高速かつ低コストの環境を提供できます。

最上位層はSaaS（Software as a Service、サービスとしてのソフトウェア）です。実際、SaaS はクラウド コンピューティングの概念が生まれる前から存在しており、クラウド コンピューティング テクノロジーの発展とともにより良く発展してきました。SaaS ソフトウェアは「すぐに使用できる」ため、ユーザーによるインストールは必要ありません。また、ソフトウェアのアップグレードやメンテナンスにはエンドユーザーの参加も必要ありません。同時に、オンデマンド ソフトウェアでもあるため、購入後に返品できない従来のソフトウェアとは比較にならない利点があります。

5G とその後継の時代では、モバイル ビデオ会議、コネクテッド カー、e-ヘルスケア、オンライン ゲーム、仮想現実など、さまざまな新しいアプリケーションが導入されています。産業界と学術界のさまざまな研究イニシアチブを結集することにより、これらの新しいアプリケーションには、1 ～ 100 Gbps 規模の高いデータ レートと往復遅延 0.1 ～ 1 ms の低遅延が必要です [2]、[3]。クラウド コンピューティングは、いくつかの問題があるため、これらの増大する需要に応えることができません。主な問題は、クラウド リソースとエンド デバイス間の距離が長く、インターネット経由で接続が確立されるため、遅延の点で問題が発生することです。さらに、クラウド サーバーの処理能力は、新たな需要に対応できない範囲にあります。例えば、Amazon EC2 クラウド サービスにおける最新世代の汎用コンピューティング インスタンスの処理能力は 5 ～ 50 Gbps の範囲にあります [4]。ただし、この処理能力は、処理リソースの使用率を競うために高いデータ レート (高品質の 360 度ビデオの場合は数 Gbps など) を必要とする多数のアプリケーションや IoT モデルに効果的に対応することはできません。

クラウド関連の問題を解決するために、クラウド コンピューティング、モバイル エッジ コンピューティング、フォグ コンピューティングなどのさまざまな概念を含むエッジ コンピューティング [5] のアイデアが導入されました。エッジ コンピューティングは、ネットワークのエッジとエンド デバイスに近いリソースを提供します。遅延は改善され、処理能力は向上しますが、長期的には増加し続けるトラフィック爆発を持続的にサポートできる可能性は低いです。さらに、この遅延は、0.1 ミリ秒未満の往復遅延を必要とするアプリケーションなどの超低遅延アプリケーションに必要な遅延にはまだ程遠いです。

最近提出的分布式云计算的概念通过利用智能邻近设备的计算和存储容量进行计算或缓存卸载，改善了云端、移动边缘计算和雾计算范式的延迟 [6]，[7]。然而，计算和功耗限制问题、邻近设备的移动性以及更重要的是将计算卸载到邻近设备的安全方面是重大挑战。具有高处理能力的更安全、节能和稳定的计算基础设施可以显著改善计算，并被视为现有计算范式的补充。在这个方向上，基于可编程数据平面技术（SDN的进化概念）的网络计算范式可以在网络边缘提供高处理能力的、节能的网络元素。

数据平面:解决数据该怎么转发，某个数据这个口进来那个口出去，本地的，路由器的功能，决定从路由器输入端口到达的分组如何转发到输出端口。

其转发分组除了传统的基于目标地址和转发表，提出了一种新的基于SDN的方法：基于多个字段+流表。

控制平面:解决数据该怎么走，网络范围内的逻辑，决定数据报如何在路由器之间路由，决定数据报从源到目标主机之间的端到端路径。

其控制方法除了传统的被在路由器中实现，提出了一种新的基于SDN的方法：在远程的服务器中实现，实现了下文提到的转发设备和控制平面分离。

为了简化流量工程和网络管理，并允许更方便地开发新的协议和应用程序，引入了软件定义网络（SDN）[8]的概念，其中转发设备与控制平面分离。根据SDN的概念，网络智能和路由策略通过基于软件的逻辑集中控制器应用。因此，构成数据平面的网络元素是简单的数据包转发设备，可以通过开放接口（例如OpenFlow [9]）进行编程。SDN成为了可编程数据平面（PDP）[10]，[11]的一种推动者。PDP的基本特征是能够通过一些高级语言对数据包进行编程处理。因此，与传统固定功能绑定在交换芯片内不同，PDP为网络运营商提供了控制数据包处理任务的灵活性，从而加快了新数据平面功能的采用和便于原型开发。此外，实现新的数据平面功能，无需重新设计交换机的ASIC，节约了大量的资本支出。

SDN字面意思是软件定义网络，其试图摆脱硬件对网络架构的限制，这样便可以像升级、安装软件一样对网络进行修改，便于更多的APP（应用程序）能够快速部署到网络上。

像交换机和路由器这样的网络元素提供了终端设备和边缘基础设施之间的连接，以及边缘和云基础设施之间的连接。利用可编程网络元素，不仅是为了连接，而且是为了计算，是计算范式的一种新趋势，即称为网内计算[12]，[13]。现在，可编程交换机可以在线速处理（例如，Intel可编程交换机的处理能力为12.8 Tb/s [14]）时每秒处理数十亿个数据包，并支持亚微秒级的数据包处理延迟[15]。利用网内计算，数据包可以在路径上并在到达边缘/云服务器之前以线速处理。事实上，与常见的边缘和云计算范式使用的边缘或云服务器相比，网内计算范式可以在更接近终端设备的位置提供更快的处理设施。本文对网络内计算进行了全面的调查。本文的贡献如下：

1. 对网络内计算主题进行的第一次调查。
2. 讨论支持网络内计算的技术和协议，以及硬件方面的讨论。
3. 基于网络内计算在各种应用和专业主题中的应用情况提出了一种新的研究分类方法。所提出的分类方法还包括最新技术，例如5G/6G、边缘计算和网络功能虚拟化（NFV）的应用。
4. 对相关研究进行批判性评估，并提出了评估和比较研究的新方法、性能和应用相关的标准。
5. 从方法、实现和性能增益等方面对相关研究进行了审查和比较，即延迟/吞吐量改善、带宽节省和功耗降低。
6. 提供了对网络内计算这个新兴话题的经验教训和研究方向。

在接下来的章节中，我们首先给出网络内计算的定义。然后，我们讨论现有的相关调查和教程。接下来，将给出文献分类和调查组织。在调查的其余部分中，我们将使用INC作为网络内计算的缩写。

A. 网内计算的定义

在本节中，我们首先简要介绍涉及网络内计算概念的网络元素，然后我们提供文献中网络内计算的定义，最后，我们将介绍一些用于指定网络内计算的特性，并给出网络内计算提供的计算能力的示意图。网络内计算范式提倡利用网络元素（即可编程交换机、FPGA和智能网卡）进行编程计算的想法。可编程交换机具有被编程以解析和操作到达的数据包字段的能力。FPGA是具有编程逻辑块的半导体元件，可用于对数据包进行有针对性的处理。类似地，智能网卡提供了专用硬件加速功能的实现以及定制数据包处理的功能。第II-A节详细介绍了这些网络元素的体系结构和功能。

对于网络内计算，目前没有标准的定义。ACMSIGARCH在[16]中提供了以下定义：网内计算指的是在网络元素内执行程序，这些程序通常在终端主机上运行。它侧重于在网络中进行计算，使用已经存在于网络中并已经用于转发流量的设备。Sapio等人[12]提供了一种基于将计算卸载到网络元素的定义：网内计算是将一组计算操作从终端主机卸载到交换机和智能网卡等网络元素中。Ports和Nelson [13]将网络内计算定义为：在可编程网络硬件上以线速运行的应用程序特定功能，提供比传统服务器实现更高的吞吐量和更低的延迟。

根据定义和我们调查的研究，可以为网络内计算定义一些特征：

1. 它侧重于在网络元素中执行的计算。这个计算可以是程序、进程、操作、网络功能等；
2. 涉及的网络元素（例如交换机和路由器、FPGA和智能网卡）可以被编程来执行预期的计算；
3. 除了计算之外，网络元素还执行路由和转发数据包的默认过程；
4. 在不使用网络的情况下，计算应该由通用处理器在应用主机或任何其他终端主机（例如服务器、控制器）中完成。

根据我们调查的研究，我们提出图1以说明网络内计算提供的计算能力的原理图。网络内计算结构由蓝色云中的网络元素组成，这些网络元素可以位于终端设备和边缘计算提供的服务器之间（例如MEC服务器、雾节点、云端设备），也可以位于终端设备和云数据中心之间（甚至可以位于边缘服务器和云服务器之间）。绿色路径说明了一条端到端的通信路径，可以在离云端服务器之前的某个点（例如点2）截断，通过在网络元素上的中间节点应用网络内计算，这些节点可以是可编程交换机、FPGA或嵌入主机中的智能网卡加速器。类似地，沿着红色路径的流量可能会在边缘服务器之前的网络元素上进行处理（例如点1），并将结果从比较接近边缘服务器的位置返回到终端设备。

图1. 网络内计算结构的原理图。蓝色云中的网络元素形成网络内计算结构。红色和绿色路径分别说明了与边缘和云的通信。如十字标记所示，这些路径可以在中间网络元素中应用网络内计算，在边缘/云服务器之前的点1和点2处截断。

B. 现有相关调查和教程

在本节中，我们将讨论现有的相关调查和教程，并讨论我们的调查与它们进行比较的贡献。

1. 可编程数据平面的调查

该类别的调查聚焦于可编程数据平面，但缺乏对网络内计算的视角。与这些调查相比，我们的调查与现有研究有四个明显的区别：首先，我们在网络内计算范围内提出了一种基于应用和专题的新分类方法；其次，我们对网络内计算论文进行了全面而批判性的评论，包括最近技术（如5G/6G、边缘计算、NFV）范围内的应用；第三，我们介绍了支持网络内计算的技术、协议和硬件方面的内容；第四，我们从我们提出的方法论/性能/应用相关标准的角度对我们调查的研究进行评估和广泛比较，这在文献中尚未见到。在我们讨论可编程数据平面的调查/教程时，我们还将强调其他区别。

Stubbe [17] は、P4 コンパイラとインタプリタに関する短い調査を提供しています。Bifulco と Rétvári [10] は、プログラマブル ネットワーク要素の設計と実装における抽象化、アーキテクチャ、および問題点の調査を提供しています。Han ら [11] は、既存の PDP 仮想化スキームの概要を示し、その長所と短所について議論しました。[18] は、ソフトウェア定義ネットワーキングにおけるデータ プレーンのプログラマビリティと柔軟性を調査しました。データ プレーン アーキテクチャは、データ プレーンの柔軟性とプログラマビリティによって評価されます。ForCES および OpenFlow データ プレーン アーキテクチャを評価する際の制約に基づいて、データ プレーンの柔軟性とプログラマビリティの問題に対処するためのいくつかのアプローチが示されています。しかし、[10]、[11]、[17]、[18] の記事には、既存のアプリケーション、関連する課題、およびプログラマブル データ プレーンに関する潜在的な研究の方向性の評価が欠けています。

[19]、[20] の記事はステートフル データ プレーンに焦点を当てています。Zhang et al. [19] は、ステートフル データ プレーンと既存のステートフル プラットフォーム (OpenState、OPP、FAST など) の基本コンポーネントの概要を説明しました。この記事では、ロード バランシング、ファイアウォール、SYN フラッド検出、大規模トラフィック検出など、ステートフル データ プレーンに基づくいくつかのアプリケーションをレビューします。Dargahi et al. [20] は、ステートフル SDN データ プレーンの研究の概要を提供し、データ プレーン プログラマビリティのセキュリティ面に焦点を当てています。著者らはいくつかの攻撃シナリオを特定し、スイッチのステートフル処理におけるいくつかの脆弱性を強調しています。ただし、この調査では、既存のアプリケーション、関連する課題、安全性以外の潜在的な研究の方向性については議論されていません。

Da Costa Cordeiro et al. [21] は、データ プレーンのプログラマビリティをサポートする重要なプログラミング言語について説明しています。著者らは、データ プレーン プログラマビリティに関する文献の 2 つのカテゴリを検討しています: 1) プログラム可能なセキュリティと信頼性の管理 (ポリシーのモデリングと分析、ポリシーの検証、侵入検知と防御に関する研究を含む)、2) 強化されたアカウンティングとパフォーマンス管理 (ネットワークの監視、トラフィックに関する研究を含む)エンジニアリングと負荷分散。調査では限られた数の論文のみが議論されました。

Kfory et al. [22] は、従来のネットワークからプログラマブル ネットワークへの進化の概要を提供し、プログラマブル スイッチと P4 の役割を説明し、ネットワーク テレメトリ、モノのインターネット、ネットワーク パフォーマンス、ネットワークなど、P4 を使用して開発されたアプリケーションをレビューしています。そしてP4テスト。この記事では、この分野の他のチュートリアル/調査よりも詳細を説明していますが、私たちの調査とこの調査の間には、依然としていくつかの大きな違いがあります。私たちの調査では、ネットワーク内のコンピューティングのアプリケーションと対象となるトピックに応じてグループ化された、異なる分類法が提案されています。さらに、[22] は、5G/6G、NFV、エッジ コンピューティングなどの最先端技術分野の論文など、ネットワーク内コンピューティングに関する多数の論文をレビューしていません (詳細については、調査のパート VII を参照してください)。私たちがカバーする広範囲の論文)、および [23]、[24]、[25]、[26]、[27]、[28]、[29] などの他の範囲の論文もカバーします。さらに、[22] では考慮されていなかった新しい方法/性能/アプリケーション関連の基準の観点からこれらの研究を評価し、比較します。最後に、[22] の研究方向は主に、スイッチ リソース、算術計算、プログラミングなどのプログラマブル スイッチの制約を克服するデータ プレーン ソリューションに焦点を当てています。その代わりに、さまざまなアプリケーションに対する研究の方向性を提供し、各アプリケーション分野における研究のギャップや関連する研究の方向性についての洞察を提供します。

2. イントラネットワークコンピューティングのチュートリアル

私たちの知る限り、ネットワーク内コンピューティングに関する調査は行われておらず、私たちの調査はその種のものとしては初めてのものです。[13]、[30]、[31] という 3 つの短いチュートリアルがあり、イントラネットワーク コンピューティングの範囲内のいくつかの論文がリストされていますが、各論文の操作や主なアイデアについては説明されておらず、説明もありません。研究の分類、技術的な詳細、比較、学んだ教訓、または特定の研究の方向性。既存のチュートリアルは数ページしかないため、私たちの調査はこれらのチュートリアルと簡単に区別できます。これらのチュートリアルの詳細を以下に示します。

Ports と Nelson [13] は、ネットワーク内コンピューティングに関する短いチュートリアルを提供しています。プログラム可能なネットワーク要素を紹介し、ネットワーク内での計算の効率的な使用について説明します。次に、限られた数のネットワーク内コンピューティング アプリケーションを分類し、それらを実装する適切なネットワーク要素を推奨します。Benson [30] は、ネットワーク内コンピューティングの管理上の課題の概要を示し、既存の管理手法の限界について説明しています。ネットワーク内の一部のコンピューティング アプリケーションのみがリストされており、コメントはありません。Kannan と Chan [31] は、ソフトウェア定義ネットワーキングにおける以前の取り組みから始めて、最近のプログラマブル データ プレーンを含むプログラマブル ネットワークの進化について簡単に紹介しています。彼らは、データ プレーンのプログラマビリティの利点について説明します。著者は、データ プレーン アプリケーションをネットワーク モニタリングとネットワーク内コンピューティングの 2 つのカテゴリに分類しています。このチュートリアルでは、上記のカテゴリに該当する論文をいくつか列挙するだけで、レビューはありません。また、イントラネットワーク コンピューティングのカテゴリでは、論文が何の構成もなくリストされています。読者は、上記のチュートリアルのいずれも、文献内のネットワーク内コンピューティングに関する論文をレビューまたは分類したり、ネットワーク内コンピューティングをサポートするテクノロジやプロトコルについて議論したりしていないことを容易に推測できます。この包括的な調査は、このギャップを埋めることを目的としています。

C. 文書分類と調査組織

このペーパーでは、アルゴリズム、プロトコル、アーキテクチャなどの分野をカバーし、査読済みの環境で発表された既存の論文の調査を提供します。この文書では、定義された一連の基準を使用して文献をレビューします。このセクションでは、まず文献の分類について説明し、次に調査の構成について説明します。

1. 文献分類

この調査では合計 106 件の論文をレビュー対象として特定しました。以下の基準のいずれかを満たす論文を収集しました: (i) タイトルに「ネットワーク内コンピューティング」という用語が明示的に使用されている、(ii) 論文の動機としてセクション IA で定義されている「ネットワーク内コンピューティング」が明示的に使用されている。図 2 は、調査の分類を示しています。イントラネットワーク コンピューティングの範囲内の論文は、さまざまなアプリケーション向けのネットワーク内ソリューションを提供しているため、分類の最初のレベルでは、文献に記載されているアプリケーションに従って論文を分類しました。つまり、(i) ネットワーク イントラネットワーク分析、(ii) ネットワーク内キャッシュ、(iii) ネットワーク内セキュリティ、(iv) ネットワーク内調整、および (v) テクノロジー固有のアプリケーション。次に、各カテゴリ内で、そのカテゴリのコンテキストで扱われる特定のトピックに従って論文を分類しました。

图2. 在网络计算范围内调查研究的分类方案。方框内的数字表示各个部分和子部分。

这种分类的动机在于清晰地定义了网络内计算的参与情况。实际上，通过观察图2中的每个叶节点，读者可以识别特定应用中涉及到的专门主题的层次结构，以及其中涉及到的网络内计算。这里我们提供三个例子：首先，考虑图2中的Flooding，可以清楚地看到网络内计算已经参与其中，以提供防范洪水攻击的解决方案，这属于DDoS攻击缓解的范畴，通常用于安全应用。其次，考虑Edge Intelligence，可以明确网络内计算已经参与其中，以提供边缘智能，这属于边缘计算的范畴，通常用于技术特定的应用。第三，考虑到Cloud Empowered With INC: Resource Allocation Studies，可以清楚地看到网络内计算已经参与了在资源分配时增强云计算的过程，这属于云计算的范畴，通常用于技术特定的应用。类似地，对于图2中的每个叶节点，通过从叶子到根的路径追踪，可以找到网络内计算在专门主题和应用中的参与情况。现在，我们对每个分类的结构提供更多细节，并对每个分类中论文划分的语义/原因给出一些补充说明。请注意，由于网络内计算主题处于初级阶段，我们可以根据每个分类中找到的论文数量来扩展每个分类中的专门主题。

第一类别，即基于分析类型的网络内分析，被结构化为三个子类别：(i) 数据聚合，(ii) 机器学习，和 (iii) 其他分析方法。

在第二类别中，即网络内缓存，我们发现论文提供了基于键值存储的缓存方法。此外，信息中心缓存的主题也与网络内缓存相关。因此，我们确定了两个子类别：(i) 键值存储，和 (ii) 信息中心缓存。

3 番目のカテゴリであるネットワーク内セキュリティでは、ほとんどの論文がネットワーク内の計算を利用して分散型サービス拒否 (DDoS) 攻撃を軽減しています。ファイアウォール ソリューションを提供する研究もいくつかあります。さまざまなセキュリティ アプリケーションを提供する論文もあります。したがって、ネットワーク内のセキュリティは、(i) DDoS 攻撃軽減方法、(ii) ファイアウォール方法、および (iii) その他のセキュリティ アプリケーションの 3 つのサブカテゴリに分類されます。DDoS 攻撃の軽減に関しては、攻撃の種類に基づいて、(i) フラッディング攻撃の軽減方法、(ii) AR-DDoS 攻撃の軽減方法、(iii) トラフィック発信元のセキュリティ アプローチの検討という 5 つのサブカテゴリーを特定しました。 (iv) DDoS 攻撃の緩和全般を考慮したアプローチ、(v) 特定の DDoS 攻撃の緩和ケース。

4 番目のカテゴリであるネットワーク内調整は、(i) コンセンサス プロトコル、および (ii) その他の調整アプリケーションの 2 つのサブカテゴリで構成されます。

5 番目のカテゴリであるテクノロジー固有のネットワーク内コンピューティング アプリケーションでは、テクノロジーに基づいて 4 つのサブカテゴリを特定しました: (i) クラウド コンピューティング、(ii) エッジ コンピューティング、(iii) 4G/5G/6G、および (iv) ) ネットワーク機能仮想化。

クラウド コンピューティングの分野では、(i) データ センターでの負荷分散を提供する論文、(ii) ネットワーク内コンピューティング機能を備えたクラウド コンピューティングでのリソース割り当てソリューションを提供する論文の 2 つのサブカテゴリを特定しました。

エッジ コンピューティングの分野では、次の 3 つのサブカテゴリを特定しました: (i) エッジ インテリジェンス ソリューションを提供する論文、(ii) ネットワーク内コンピューティング機能を備えたエッジ コンピューティングにおけるリソース割り当てソリューションを提供する論文、および (iii) 計算セキュリティに関するエッジ論文を提供する論文解決策。

モバイル通信の分野では、無線とコアの分割はモバイル通信の文献でよく知られている分割です。私たちは、無線アクセスとコア機能にネットワーク内コンピューティングを導入することが適切であると考えています。したがって、4G/5G/6G カテゴリには、(i) 無線アクセス ネットワーク ソリューション、(ii) モバイル データ コア ソリューション、および (iii) その他のアプリケーションの 3 つのサブカテゴリが含まれます。

この文書では、NFV の範囲内で、NFV のフレームワークまたは導入ソリューションを提供します。さらに、ネットワーク機能のハードウェア アクセラレーションは、ネットワーク内コンピューティングに関連する NFV の範囲内のトピックです。したがって、(i) ハードウェア アクセラレーションによるネットワーク機能、および (ii) フレームワーク/展開ソリューションの 2 つのカテゴリを特定しました。これらはさらに 2 つのサブカテゴリに分割されました。(i) ネットワーク要素での仮想ネットワーク機能 (VNF) の展開に焦点を当てました。 (ii) ネットワーク内コンピューティング機能を備えた NFV 環境におけるハイブリッド アンダーレイ ネットワークの展開ソリューションを提供する論文。

NFV (ネットワーク機能仮想化) は、ネットワーク機能をソフトウェア化および仮想化し、ネットワーク機能を専用のハードウェア デバイスから切り離すことによって、ネットワークの柔軟性と拡張性を向上させることを目的としたネットワーク テクノロジです。簡単に言えば、NFV テクノロジーは、従来のネットワーク デバイス (ルーター、ファイアウォール、ロード バランサーなど) の機能をソフトウェア化し、汎用のハードウェア上で実行できるようにすることです。これにより、ネットワークの柔軟性とプログラマビリティが向上し、ネットワーク機器のコストが削減され、ネットワーク機能の更新と保守が容易になります。

2. 調査機関

セクション II では、ネットワーク内でのコンピューティングを可能にするテクノロジーとプロトコルについて説明します。次に、ネットワーク内コンピューティングの概念を説明し、ネットワーク内コンピューティングの利点を紹介するために、2 つのアプリケーション ケース (つまり、ネットワーク内分析とネットワーク内キャッシュ) を示します。最後に、文献内のネットワーク コンピューティング論文を分類、評価、比較するための基準を提案します。セクション III では、データ集約手法、機械学習手法、その他のネットワーク内分析手法を含む、ネットワーク内分析に関する研究の概要を説明します。セクション IV では、キーバリュー ストア アプリケーションやダッシュボード キャッシュなど、ネットワーク内キャッシュ アプローチの概要を説明します。セクション V では、DDoS 攻撃の軽減方法、ファイアウォールの方法、その他のセキュリティ アプリケーションを含む、ネットワーク内セキュリティの範囲内の研究をレビューします。セクション VI では、コンセンサス プロトコルやその他の調整アプリケーションを含む、ネットワーク内調整方法をレビューします。セクション VII では、クラウド コンピューティング、エッジ コンピューティング、4G/5G/6G、ネットワーク機能仮想化などの特定のテクノロジー アプリケーションを検討します。図 2 にセクション III からセクション VII までの調査の組織構造を示します。さらに、各セクションの最後には、そのセクションから得られた概要、比較、教訓が記載されています。セクション VIII では、いくつかの潜在的な研究の方向性について説明します。最後に、セクション IX でこの論文は終わります。

II. テクノロジー、プロトコル、使用例および標準

このセクションでは、まずネットワーク内計算を可能にする技術とメッセージ転送プロトコルについて説明します。次に、ネットワーク内コンピューティングの概念を説明する 2 つのアプリケーション ケースを示し、ネットワーク内コンピューティングの利点のいくつかを強調します。最後に、調査における研究を分析および比較するための基準について説明します。

A. サポート技術

1. ソフトウェア デファインド ネットワーク

Software Defined Networking (SDN) は、リモート ネットワーク管理と新しいルーティング ポリシー、プロトコル、アプリケーションの展開を容易にするように設計されたネットワーキング パラダイムです。SDN の概念によれば、データ プレーンの転送ハードウェアは制御の決定から切り離されます。図 3a と 3b は、従来のネットワークのデバイスの組み込み制御と比較した SDN の概念を示しています。ネットワーク操作とルーティング ポリシーのインテリジェント ロジックは、コントロール プレーンで開発されたソフトウェア ベースのソリューションを通じて集中管理されますが、ネットワーク要素は単純なデータ転送デバイスとなり、OpenFlow などのオープン インターフェイスを介してアクセスできるデータ プレーンを形成します [9]。 ForCES [32] など) プログラミング用。

OpenFlowは、SDN(Software Defined Networking)におけるコントロールプレーンとデータプレーンを分離するためのネットワークプロトコルです。OpenFlow プロトコルは、コントローラーとデータ プレーンの間で情報を通信および交換するための一連のメッセージ形式と処理ルールを定義します。具体的には、OpenFlow プロトコルを使用すると、コントローラーがネットワーク デバイス (スイッチやルーターなど) と通信して、ネットワーク デバイスの転送動作を制御できるようになります。コントローラーは、データ パケットの照合方法と転送方法のルールを定義するフロー エントリを発行することで、ネットワーク デバイスのデータ転送を制御できます。従来のネットワークとは異なり、OpenFlow プロトコルを使用すると、ネットワーク管理者はコントローラを通じてネットワークをグローバルに管理および制御できるため、ネットワークの柔軟性とプログラマビリティが向上します。OpenFlow は、SDN 分野で最も一般的に使用されるネットワーク プロトコルの 1 つとなり、データ センター、エンタープライズ ネットワーク、オペレーター ネットワークで広く使用されています。

簡単に言うと、SDN はハードウェアが転送のみを担当し、ロジック制御 (転送方法) は中央制御装置に引き継がれます。

画像3。(a) 従来のネットワーキング、(b) ソフトウェア定義ネットワーキング。

OpenFlow [9] は最も人気のある SDN プロトコルです。このプロトコルでは、転送デバイス、つまり OpenFlow スイッチには、OpenFlow プロトコルを通じてコン​​トローラと通信するための複数のフロー テーブルと抽象化層が含まれています。各フロー テーブルには、パケット処理および転送ポリシーを定義するための複数のフロー エントリが含まれています。通常、フロー エントリは次で構成されます: a) 受信パケットを照合するためのパケット ヘッダー、イングレス ポート、およびメタデータ内の情報を含む照合フィールド/ルール、b) フロー統計 (到着パケット数、フロー継続時間など) を収集するカウンタ、c) ) 一致が発生したときにパケットに作用する一連の操作。データ パケットが OpenFlow スイッチに到着すると、データ パケットのヘッダー フィールドが照合フィールドと照合されます。一致が成功すると、関連付けられたアクション セットが適用されます。コントローラは OpenFlow プロトコルを通じてスイッチと通信し、スイッチのフロー テーブル内のフロー エントリを追加、更新、または削除できます。制御側では、ネットワーク コントローラーのスケーラビリティとパフォーマンス、SDN コントローラーとスイッチ間のリアクティブまたはプロアクティブな通信、(転送要素とネットワーク サービスに関連する) サウスバウンド通信とノースバウンド通信の実装が、SDN 制御の設計の重要な側面となります。直面した課題。ONOS、OpenDaylight、Floodlight [33]、Beacon [34]、および RouteFlow [35] は、SDN コントローラー実装の例です。

2. プログラム可能なデータプレーン

プログラマブル データ プレーン テクノロジに関係する主な要素は次のとおりです。

(i) コントロールプレーンとデータプレーンの分離

データ プレーンのプログラマビリティに主に貢献しているのは、コントロール プレーンをデータ プレーンから切り離すという概念であり、標準 API [8]、[36] を介して 2 つのプレーン間の対話を可能にします。実際、データ プレーンは、コントロール プレーンの管理下にある「ダム」ネットワーク要素によって実装できます。これらの「ダム」ネットワーク要素は、埋め込まれた状態情報をコントロール プレーンに公開し、ネットワークのプログラマビリティを可能にします。

(ii) データプレーン

データ プレーンはネットワークの最も基本的なインフラストラクチャであり、ネットワーク要素によって送受信されるデータ パケットを処理するために使用されます。データ プレーンは、ハードウェア コンポーネントと特定のソフトウェア メソッドの組み合わせを使用して実装されます。データ プレーン機能は、パケット分類エンジンに基づいて、ASIC、FPGA、ネットワーク プロセッサ、ネットワーク インターフェイス カード (NIC) などのさまざまなネットワーク要素に実装できます。ネットワーク要素テクノロジーは、さまざまな方法でパケット処理プリミティブをコントロール プレーンに公開し、さまざまなプログラミング言語を使用してパケット処理プリミティブにアクセスします。ここでは、ネットワーク内の計算に関与するネットワーク要素のハードウェアと機能の詳細について詳しく説明します。

ここでのプリミティブは通常、データ パケットの照合、転送、変更、破棄、その他の操作など、プログラマブル ネットワーク デバイスの基礎となる操作と機能を指します。これらのプリミティブを提供することにより、ネットワーク デバイスは上位コントローラに一連の抽象インターフェイスを提供できるため、コントローラはこれらのインターフェイスを通じてネットワーク デバイスのデータ処理動作を制御できます。

a. プログラマブルスイッチ

SDN スイッチは、ハードウェア スイッチとソフトウェア スイッチに分類できます。Barefoot Tofino [37]、Cavium XPliant [38]、および Flexpipe [39] はハードウェア スイッチの例です。一方、ソフトウェア スイッチは、CPU 上でパケット分類アルゴリズムに基づいてパケット処理ロジックを実行します [10]。OVS [40]、PISCES [41]、NetBricks [42]、BMv2 [43] はソフトウェア スイッチの例です。プログラマブル ネットワーク スイッチの機能は、一致操作パイプラインとして抽象化できます。Protocol-Independent Switch Architecture (PISA) は、match-action [11] に基づいたよく知られたプログラマブル スイッチ アーキテクチャです。図 4a は PISA の概略図を示しています。

ハードウェア スイッチとソフトウェア スイッチはネットワーク スイッチの 2 つの異なる実装であり、主な違いは次のとおりです。

1. 実現媒体: ハードウェア スイッチは専用のスイッチ チップで実装され、ソフトウェア スイッチは一般的なサーバーまたはコンピュータとソフトウェアの組み合わせで実装されます。ハードウェア スイッチはより高い転送パフォーマンスを提供できますが、ソフトウェア スイッチの転送パフォーマンスはサーバー構成に依存します。
2. プログラマビリティ: ハードウェア スイッチの転送ロジックは通常、チップ内に固定されているため、変更するのは困難です。ソフトウェア スイッチはソフトウェアを使用して転送ロジックを実装するため、プログラムと変更が容易になります。たとえば、P4 言語を使用すると、ソフトウェア スイッチのプログラミングが容易になります。
3. コスト: ハードウェア スイッチのコストは、専用チップを使用するため高くなります。ソフトウェア スイッチに必要なのは汎用コンピューティング プラットフォームだけであり、コストは比較的低いです。
4. 功能:硬件交换机提供的功能取决于芯片设计,不易扩展。软件交换机的功能可以通过软件扩展和升级实现。例如,软件交换机更易于支持新兴的SDN和网络虚拟化功能。
5. 能耗:硬件交换机通常功耗较低,因为使用专用的高度优化的电路。软件交换机运行在通用计算平台上,功耗较高。

该架构由可编程的子结构组成，包括解析器、匹配-操作流水线和解析器。解析器从接收到的数据包中提取头部，并将其存储在称为Packet Header Vectors（PHVs）的中间寄存器中[44]，这些PHVs被视为流水线阶段的输入。在流水线的每个阶段，使用匹配-操作表对提取的头部进行处理。在硬件交换机中，匹配-操作表是在三态内容寻址存储器芯片（TCAM）中实现的，而在软件交换机中，它们是在SDRAM中实现的。还有一种混合情况，即匹配-操作表可以同时位于TCAM和SDRAM中。当匹配不发生时，数据包将被发送回设备/SDN控制器，并相应地对表条目进行所需的更新。当发生匹配时，将执行操作，并将数据包发送到下一个匹配-操作表以进一步进行所需的处理。在每个匹配-操作表中，通过算术逻辑单元（ALUs）应用操作逻辑。通过一个操作，将对数据包字段执行操作，并将结果存储在PHVs中。存储在SRAM中的其他对象，如计数器或寄存器，可以用于执行对先前操作的输出进行状态操作。在流水线阶段的处理完成后，处理过的头部被发送到解析器，解析器将组合这些头部以重构数据包。控制平面可以通过向匹配-操作表中写入条目来管理数据包处理。

PISA提供了一个抽象模型，可以通过各种方式进行增强，以创建具体的架构。例如，一个典型的交换机可以在入口和出口之间拥有单独的流水线，并且在入口和出口流水线之间可以有一个队列管理模块，即调度器（图4b）。此外，具体的架构中还可以包括用于高级处理的专用组件，例如哈希/校验和计算。目前最先进的可编程交换机可以以线速处理的速度处理十亿个数据包 [15]。例如，英特尔第二代P4可编程以太网交换芯片可以提供高达12.8 Tb/s的吞吐量 [14]。

图4。(a)PISA交换机架构，(b)是一个典型的交换机架构，©P4程序与目标的关系。

b.FPGA

FPGAs（可编程门阵列）是一种半导体元件，具有在制造后进行编程和配置以实现所需数据包处理的能力。如图5所示，FPGA的硬件架构包括三个主要元素[45]：（i）计算逻辑块（CLBs），（ii）路由能力（用实线连接CLBs表示），（iii）I/O块。通过查找表和触发器，CLBs提供了一个可编程矩阵的计算单元，最终连接到I/O块。I/O块可以通过像PCIe这样的互连与CPU和系统进行通信。路由能力是通过交换盒和连接盒等互连组件实现的，它提供了连接CLBs之间的连通性，为生成复杂的计算逻辑提供了便利。与具有最高性能的专用ASIC设计相比，利用高时钟速度和存储带宽的最新FPGA已经在许多用例中缩小了性能差距，同时具有灵活性和成本效益的优势[46]。一个众所周知的最新版本是基于FPGA的SUME，它利用了一块带有四个10 Gb以太网端口的Xilinx Virtex 7 FPGA [47]。更近期的基于FPGA的原型平台是Corundum [48]，具备在FPGA上提供100 Gbps网络接口的能力。

图5。FPGA架构。[45].

c.智能网卡

ネットワーク カードは、PCIe インターフェイスを介してコンピューティング ノードに接続できる外部ハードウェア コンポーネントです。ネットワーク カードは、いくつかの標準的な物理層機能と MAC 層機能、およびいくつかのインターネット プロトコル層機能を実装します。実際、ネットワーク カードは、インターネットからのパケットの送受信を担当するだけでなく、IP パケットをオペレーティング システムやアプリケーション層に渡す前に初期処理を実行します。スマート プログラマブル NIC テクノロジーは進化し、一般または特殊なデータ プレーン言語 (P4、eBPF など) を使用して NIC をプログラムできるようになりました。ネットワーク カードは、専用のハードウェア アクセラレーション機能を実装できるだけでなく、FPGA ユニットのようにプログラムして、カスタマイズされたパケット処理を実行することもできます。パケットを到着後に NIC 上で直接処理すると、FPGA などの他のアクセラレータと比較して、処理のためにシステム メモリからアクセラレータ メモリにパケットを転送することに関連する遅延が回避されます。しかし、ネットワーク内コンピューティングに NIC を使用すると、依然として開発プロセスとパフォーマンスの問題に直面しています [46]、[49]。特に、サーバーアプリケーションのオフロードにおける開発抽象化の問題に対処するために、Floem [50] は、データレイアウト、キャッシュと並列処理、およびデバイス間のプログラムコンポーネント間の通信戦略のためのプログラミング抽象化を提供します。最先端の SmartNIC により、毎秒 400 Gb/s の高速パケット処理が可能になります [51]。

PCIe (Peripheral Component Interconnect Express) は、グラフィックス カード、ネットワーク カード、ストレージ コントローラーなど、コンピューター内のさまざまなハードウェア デバイスを接続して高速データ転送と通信を実現するために使用されるコンピューター バス テクノロジーです。PCIe は PCI (Peripheral Component Interconnect) バスのアップグレード バージョンで、シリアル通信プロトコルを使用してデータ伝送速度と帯域幅の使用率を向上させます。

(iii) データプレーンプログラミング言語

P4 [52]、OpenState [53]、Domino [54]、NetKAT [55] など、さまざまなデータ プレーン プログラミング言語が文献に存在しており、P4 が最も広く使用されているプログラミング言語です。P4 は、プログラム可能なネットワーク要素でパケットを処理するための高級プログラミング言語です [52]、[56]。P4 はもともとプログラム可能なハードウェアまたはソフトウェア スイッチ用に設計されましたが、その範囲はネットワーク カードや FPGA などの他のさまざまなデバイスをサポートするように拡張されました。したがって、P4 の仕様では、これらすべてのデバイスを指す一般的な用語「ターゲット」が使用されます。機能が個々のメーカーによって定義される従来の固定機能スイッチとは対照的に、P4 プログラムはスイッチ機能を定義できます。コントロール プレーンは、P4 コンパイラーによって生成された API を介してデータ プレーンと通信し、データ プレーンでテーブルやその他のオブジェクトを使用する際の柔軟性を提供します。

P4 の設計は 3 つの主な要件 [56] に従います: (i) コントローラがスイッチでパケット解析/処理を再構成できるようにする、(ii) パケット転送の共通コンテキストに対してパケット解析/処理を指定し、プロトコルに依存しないを使用する、 (iii) スイッチは、基礎となるスイッチの詳細とは独立してプログラムされます。P4 プログラムは、次の主要コンポーネントで構成されます: (i) フィールドの順序と構造、およびフィールド値の制約を定義するヘッダー、(ii) パケット内のヘッダーとそのシーケンスを指定するパーサー、(iii) ) マッチアクションパケット処理を定義するために使用されるテーブル、(iv) 単純な基本操作から複雑な操作を生成する機能を備えた一致フィールドに適用するアクション、(v) パケットに適用する一致アクションを決定する制御プログラム、テーブル制御シーケンスとフロー。P4 コンパイラは、プログラムの記述をターゲット固有のハードウェア/ソフトウェア プラットフォームにマップします。コンパイル プロセスは 2 つのフェーズに分かれています。まず、P4制御プログラムをテーブル依存グラフ構造に変換し、テーブル間の依存関係を定義します。上記のグラフは、ターゲット固有のマッピングを通じてスイッチの特定のリソースにマッピングされます。図 4c は、P4 プログラムとターゲットの関係を示しています。

3. エッジコンピューティング

エッジ コンピューティング (クラウド、モバイル エッジ コンピューティング、またはフォグ コンピューティングとも呼ばれます) は、エンド デバイスに近いネットワークのエッジにリソースを提供して、遅延を削減し、モバイル データ オフロードなどの機能を有効にします [5]。このセクションの残りの部分では、エッジ コンピューティング パラダイムの概要を説明します。

クラウドレット: Satyanarayanan ら [57] によって提案されたクラウドは、モバイル デバイスの近くに配置されたサーバーのクラスターです。モバイル デバイスは、デバイス上で利用可能なリソースの制限を克服するために、クラウド内で実行されている仮想マシン (VM) にコンピューティング タスクをオフロードできます。仮想マシン テクノロジーに基づいて、クラウド リソースは動的に拡張および縮小でき、サービス リクエストに合わせて拡張できます。モバイル デバイスは、コンピューティング タスクを近くのクラウドにオフロードできるため、デバイス上のリソース制限を克服し、リアルタイムのインタラクティブな応答を確保できます。モバイル デバイスの近くでクラウドにアクセスできない場合でも、リモート クラウドに接続することは可能ですが、必要なサービスを取得するまでの応答時間は短くなります。

マルチアクセス エッジ コンピューティング (MEC) : MEC は、欧州電気通信標準協会 (ETSI) によって導入された概念で、当初はモバイル エッジ コンピューティング (MEC) という名前で開始されました。当初は、仮想化テクノロジとしてモバイル ネットワークと仮想マシンが含まれていました。ただし、このアイデアは後に、非モバイル ネットワーク要件をサポートし、他の仮想化テクノロジを含めるように拡張されました。実際、MEC は、LTE マクロ基地局 (eNodeB) およびマルチ無線アクセス テクノロジ サイトからアクセスできるモバイル エッジ コンピューティング サーバーを通じて、ネットワークのエッジにクラウド コンピューティング機能を提供します。

マルチアクセス (マルチアクセス) とは、MEC アーキテクチャが、無線アクセス (4G、5G ネットワークなど)、有線アクセス (WLAN、光ファイバー ネットワークなど) など、さまざまなアクセス方法をサポートしていることを意味します。

MEC アーキテクチャでは、エッジ ノードはさまざまなネットワーク アクセス方法を通じてモバイル端末デバイスと通信し、対話することができます。たとえば、無線アクセス モードでは、エッジ ノードは 4G、5G、およびその他の移動通信ネットワークを通じて移動端末デバイスと通信し、低遅延、高帯域幅のコンピューティングおよびストレージ サービスを提供できます。有線アクセス モードでは、エッジ ノードは、WLAN や光ファイバーなどの有線ネットワークを通じてモバイル端末デバイスと通信し、対話できます。

複数のアクセスは、MEC アーキテクチャのエッジ ノードがさまざまなネットワーク アクセス方式をサポートできるという事実に反映されており、これにより MEC アーキテクチャはアプリケーション要件やネットワーク環境の変化に応じて適応および調整でき、より優れた効率的なサービスを提供できます。モバイルアプリケーションサービス。同時に、マルチアクセスはモバイル端末機器により多くの選択肢と柔軟性を提供し、アプリケーションの要件やユーザーの好みに応じて選択したり切り替えたりすることができます。

雾计算：雾计算将云计算从网络的核心延伸到网络边缘，从而在靠近终端设备的网络边缘提供计算设施。雾计算部署靠近用户并位于终端用户和云之间的雾节点（例如边缘交换机、网关、智能手机、接入点等）。与云端和MEC不同，雾计算不以独立模式运行，而是与云的存在相结合。

分散式云计算：分散式云计算的最新想法可以看作是边缘计算的进化版本，它利用智能设备（例如智能手机、手机、传感器、无人机、汽车等）的计算和存储能力来增强边缘计算的计算/存储能力，并在设备附近提供云计算能力。这种范式引入的计算连续性不仅提高了延迟体验，还缓解了边缘服务器/数据存储超载和由于边缘基础设施部署而导致的高成本问题。然而，设备的计算/存储和能源限制、设备的移动性以及计算/内容卸载到附近设备的安全方面仍然是主要挑战。有关更多详细信息，可以参考调研报告[6]，[7]。

4. 新兴网络内计算中的技术的作用

在本节中，我们解释了所提到的技术如何在实现网络内计算方面发挥作用：

可编程数据平面：可编程数据平面提供了在网络内执行计算的基础设施。所需的计算（例如数据分析、安全策略、缓存、负载均衡等）在可编程数据平面中实现。可编程交换机和路由器、FPGA和智能网卡是可编程数据平面元素的示例，它们已在网络内计算的范围内使用。

边缘计算：边缘计算可以通过提供网络内计算设备（即位于网络边缘的网络元素）来促进网络内计算，以便在到达远程服务器之前在路径上执行所需的计算。实际上，边缘计算与网络内计算的结合已在多项研究中讨论，例如[15]，[58]。在这方面，与常规边缘服务器相比，计算可以在路径上更靠近终端设备进行。

Software-Defined Networking (SDN): [59]、[60] で説明されているように、ネットワーク内コンピューティングの概念によれば、ネットワーク要素上で計算、意思決定、または制御を実行すると、SDN コントローラーの介入が削減される可能性があります。ただし、SDN コントローラーは、必要な管理タスクだけでなく、データ プレーンでのルールのインストールと更新、データ プレーンでのプログラムと機能の構成とインストール、システムの全体像に従って効率的に実行されるタスクも実行できます。悪意のあるフロー、検証などをブロックするネットワーク [60]、[61]、[62]、[63]、[64]。

B. サポート契約

著者の知る限り、広範なネットワーク化されたコンピューティング アプリケーション向けに専用の通信プロトコルが文献で提案されたことはありません。したがって、ネットワーク コンピューティングの範囲内の既存の研究では、既存のメッセージ パッシング メカニズムが使用されます。IP アドレス指定に基づいていないメッセージング メカニズムは、ネットワーク内のコンピューティング能力を可能にすることが期待されています。このセクションでは、既存の 4 つの非 IP ベースのメッセージ転送メカニズムについて説明し、それらがどのようにネットワーク内の計算を可能にするかについて説明します。

1. 不明なメッセージの転送

不明なルーティング アルゴリズムは、転送の決定にクエリ セマンティクスや宛先ノード アドレスを使用しない転送プロトコル メカニズムです。この点で、フラッディング [65] とランダム ウォーク [66] が最も人気のあるアルゴリズムです。これらのアルゴリズムを使用すると、ネットワーク全体にメッセージをブロードキャストできるため、ネットワーク要素はメッセージを検査し、実装されている場合は必要な計算を適用できます。ただし、これらの方法は、生成されるトラフィックの点で効率的ではありません。

2. 情報集中型ネットワーク (ICN)

インターネットは、将来のインターネット アーキテクチャの原則となった送信元と宛先間の 1 対 1 の通信ではなく、情報とデータを配布するために広く使用されています。この点に関して、元のアイデアは Gritter と Cheriton によって提案されました [67]。ICN は、ユーザーに情報をより効率的に配信するために、ネットワーク内キャッシュとマルチキャスト送信の導入を推奨しています。ICN に基づいて、情報はその場所に関係なく名前付けされ照合されるため、ネットワーク内のどこからでも情報を提供できます。リクエストが到着すると、ネットワークはリクエストされた情報を提供できる最適なソースを見つけます。ICN の詳細な調査は [68] にあります。ICN と同じ方向で、情報は必要な計算とみなされ、命名は計算名とみなされ、計算を問い合わせることができ、ネットワーク要素はデバイスの位置に応じて計算を提供できます。

3. サービス指向ネットワーキング

サービス指向ネットワーキングは ICN の拡張バージョンであり、6G などの将来のインターネット向けのコンテンツおよびコンピューティング サービスのサポートを提供します [69]。各コンピューティング サービスは、その機能とパラメータを一意の名前で識別できます。これは 3 段階の操作を使用して関数を実行します。(i) リクエストを関数に転送し、(ii) 必要なデータをフェッチし、(iii) 計算して結果を返します。さらに、より複雑なサービスを提供するために、関数間のチェーンをサポートします。このコンピューティング パラダイムにより、場所を知らなくてもネットワーク内で計算機能を実行できるようになります。

最近では、コンテンツ/計算/コンテキスト認識指向のサービス中心ネットワーキング プロトコルの採用バージョンが [69] で提案されており、これは 6G にとって非常に有望であると考えられています。転送および知識目的のためのサービス識別子、ターゲット オブジェクトおよびコンテキストを含む要求対象/データ名。サービス識別子の後のターゲット オブジェクトは転送方向を示し、コンテキスト オブジェクトは関数計算の追加情報を提供します。インタレストが到着すると、データ プレーン要素のコンテンツ ストアが検索され、コンテキスト情報に基づいてキャッシュされたコンテンツまたは計算結果が検索されます。キャッシュ ミスの場合、このプロトコルでは、データ プレーン要素でのローカル計算、つまりネットワーク内計算、または転送プロセス パイプライン プログラムを介した対象の転送も可能になります。SDN コントローラーは、新しいマッチング フィールド (つまり、サービス、オブジェクト、コンテキスト)、より高度な転送技術をサポートし、データ/関心処理のコンテキストに従って新しいフロー テーブルを設計することにより、キャッシュ、実行機能、および機能チェーンも処理します。

[69] で提案されているように、新興 6G 垂直サービス (例: 自動運転、産業用制御などの URLLC アプリケーション) における超低遅延 (ULL) の提供を考慮すると、超低遅延要件をサービスの一部として挿入することができます。インタレスト/データ名プロトコルにリクエストを送信して、対応するネットワーク内計算/キャッシュ、および遅延を考慮した転送戦略を適用します。遅延を考慮したパケット転送はこの文書の範囲外であるため、ここではいくつかの標準化の試みについて言及します。IEEE 802.1 シーケンシャル ネットワーク標準は ULL ネットワークのリンク層サポートを提供しますが、IETF 決定論的ネットワーク標準は補足的なネットワーク層 ULL サポートを提供します。興味のある読者は、IEEE TSN および IETF DetNet 標準および関連研究について [70] を参照してください。

4. セマンティクスベースのメッセージ転送

セマンティクスベースのメッセージ転送では、メッセージは IP アドレスではなく、その意味に基づいてルーティングされます [71]、[72]。特定のネットワーク ノードにメッセージを送信するには、ネットワーク内で位置するノードの説明と同様の意味を持つセマンティック キーをメッセージに挿入する必要があります。メッセージがネットワークに到達すると、セマンティック キーで定義されたターゲット宛先に配信され、ターゲット ノードはメッセージの送信元に応答できます。実際、ネットワークは相互接続されたセマンティック ルーターのセットとして見ることができ、各ルーターはメッセージ内のセマンティック キーとセマンティック ルーティング テーブルに保存されているリソースの説明の類似性を比較して、次ホップの宛先を決定します。

セマンティック ルーティングの別の形式はコンテンツ ルーティングであり、ピアツーピア ネットワークのルーティング メカニズムとして使用されています [71]。コンテンツ ルーティング アルゴリズムは、ユーザー クエリに埋め込まれたセマンティック情報も利用して、各ホップでルーティングを決定します。コンテンツ ルーティングでは、セマンティクスまたはオブジェクトがキーワードによって識別され、広告とクエリはこれらのキーワードを使用して表現されます。アドレスベースのルーティングとは対照的に、セマンティック ルーティングでは、オブジェクトに関連付けられたキーにハッシュ関数を適用することによって構築されたキーによってオブジェクトが識別されます。キーベースのルーティングは、そのキーを持つ特定のリソースを選択してメッセージを処理するため、キーワードベースのメッセージ ルーティングよりも効率的です。ただし、キーベースのクエリ ルーティングは部分一致セマンティクスをサポートしません。代わりに、コンテンツ ルーティング システムは、ブラインド検索アプローチを使用して部分一致クエリをサポートできます。ただし、結果としてクエリ ルーティング トラフィックが多くなり、検索の整合性は保証されません。

スマート フラッディングは、最も一般的に使用されるコンテンツ ルーティング手法の 1 つです。これは、いくつかの基準 (以前のクエリ結果、ノードの容量、コンテンツ タイプなど) に従ってメッセージをいくつかの近隣ノードに転送するため、ブラインド検索方法のオーバーヘッドが削減されます。Ahmed et al. は、コンテンツ ルーティングの詳細な説明を提供しています [71]。ネットワーク内計算のコンテキストでは、セマンティクスはネットワーク要素によって実装できる計算とみなすことができます。検索メカニズムを容易にするために、ネットワーク要素は、サポートする計算をセマンティック ルーティング テーブルと同様のデータ構造に公開できます。メッセージ内のセマンティクス、つまり計算情報に基づいて、このようなデータ構造を利用して、計算を適用できるネットワーク要素にメッセージをルーティングできます。

C. ネットワーク内コンピューティングの使用例と利点

このセクションでは、ネットワーク分析とネットワーク キャッシュの範囲における 2 つの使用例を通じて、ネットワーク内コンピューティングの概念を説明します。ユースケースごとに、ネットワーク内計算を使用しないプロセスとネットワーク内計算を使用するプロセスについて説明します。

図6. (a) ネットワーク内計算を行わないアクセス層でのデータ分析、(b) 収集されたデータがアプリケーション分析に十分な場合のネットワーク内計算によるデータ分析、 © アクセスにネットワーク内計算を使用するレイヤーが分析されます。

1. ネットワーク内コンピューティング

図 6a は、階層構造を持つネットワークでデータ分析を実行できるシナリオを示しています。アクセス層では、データが一部のデバイス (IoT デバイスなど) から収集され、スイッチのネットワークに供給されて、分析を実行するサーバー (いわゆる分析サーバー) に到達します。このサーバーは、モデルを推論するために機械学習 (ML) またはある種の集計を実装できます。分析サーバーはエッジに配置されたサーバーである場合があります。サーバーは分析を実行した後、対応するコマンドをターゲットデバイス (アクチュエーターなど) に返します。

図 6b は、スイッチがプログラム可能でネットワーク内計算を利用するシナリオを示しています。このシナリオは、分析を適用する前に十分なデータが収集されている場合に適しています。たとえば、中間層のスイッチでは、必要なデータがすでに収集されており、ML/集約を適用できます。スイッチが受信したパケットに分析を適用できるように、ML/集約手法が中間層スイッチに実装されていると仮定します。この場合、データが分析サーバーに到達する前にネットワーク内で ML/集約を実行すると、エンドデバイスの近くでトラフィックを終了し、ネットワークの上位層で帯域幅を節約できるだけでなく、迅速な注文発行も保証されます。

図 6c は、アクセス層で収集されたすべてのデータを分析に含める必要がある状況を示しています。この場合でも、ML/集約メソッドをプログラマブル スイッチにオフロードすることで、ネットワーク内の計算が効率的になる可能性があります。スイッチは、データがネットワークを通過する際に、データに対して ML/集約操作を実行します。データは、ネットワークのアクセス層にバインドされたスイッチからネットワークに入り、ネットワークを上流に移動し、スイッチで ML/集約が行われます。プログラマブル スイッチは、そのすべての子ノードからデータを受信し、ML/集約操作を実行します。学習されたモデル/集約されたデータは、スイッチによってその親スイッチに送信されます。分析サーバーは最終的な学習/集約を実行し、コマンドをデバイスに転送します。学習されたモデルまたは集約されたデータの量は元のデータのサイズよりも小さいため、データが分析サーバーに到達するのを待ってから操作するのではなく、ネットワークを通過する際のデータ量が削減されます。したがって、この場合も帯域幅を節約できるという利点があります。

分析を適用する前に十分なデータが収集されており、アクセス層で収集されたすべてのデータが分析 (図bおよび図c) の領域に含まれる必要があります。

前者は、分析手法を適用する前に十分なデータが収集されていることを意味します。この場合、アクセス層で収集したデータをすべて分析に含める必要はなく、ある程度のサンプルデータが集まってから分析やモデル推論を行うことも可能です。

後者は、アクセス層で収集されたすべてのデータを分析に含める必要があり、どのデータも除外できないことを意味します。この場合、正確な分析とモデル推論にはより多くのデータが必要になります。

2 つのケースの主な違いは、データ量と精度です。

前者の場合、すべてのデータは必要なく、一定数のデータ サンプルだけで十分であるため、データ量は少ないですが、精度は若干劣る可能性があります。

2 番目のケースでは、すべてのデータを利用する必要があり、データ量は多くなりますが、より高い精度を実現できます。

例えば：

ユーザーの購買行動を分析したい場合、前者の場合、分析とモデル化のために一定の割合のユーザーデータを抽出できますが、この時点ではデータ量は多くありませんが、モデルの精度はそれほど高くない可能性があります。 。

2つ目のケースでは、全ユーザーの購買データを分析する必要があり、データ量は多くなりますが、非常に精度の高いユーザー行動モデルを構築できます。

2. ネットワーク内キャッシュ

図7。(a) 一般的なキャッシュ システム、(b) ネットワーク内キャッシュ。

図 7a は、ユーザーにコンテンツを提供するストレージ サーバーまたはオリジン サーバーがある場合のキャッシュの一般的な状況を示しています。ストレージサーバーはエッジコンピューティングによって提供できます。ユーザーデバイスは、プログラマブルスイッチのネットワークを通じてストレージサーバーに接続できます。項目はキーと値のペアとしてモデル化されます。一般性を失うことなく、ストレージ サーバーにはすべてのアイテムを格納するのに十分な容量があると想定します。コントローラーはパケット転送ルールをスイッチに適用します。一般に、ネットワーク内コンピューティングがない場合、スイッチはパケット転送の役割を果たします。読み取りリクエストがネットワークに到着すると、スイッチはインストールされている転送ルールを適用し、リクエストをストレージ サーバーに転送します。リクエストはストレージ サーバーへのパス全体をたどります。要求されたキーに関連付けられた値は、ユーザーに到達するためのすべてのパスを返します。

図 7b は、ネットワーク内キャッシュがある場合の配信スキームを示しています。ユーザー デバイスとストレージ サーバー間のネットワーク スイッチは、キーと値のペアのパス キャッシュの実装と、標準プロトコルを使用したデータ パケットのルーティングを担当します。ネットワーク内キャッシング サービスの使用が想定されるデータ パケットは、ネットワーク内キャッシング サービスを提供するために必要な処理を実行するために、通常のデータ パケットと区別される場合があります。スイッチには、人気のあるアイテムを保存するための一致操作テーブルとして実装されたキーバリュー ストアがあります。コントローラは、ネットワーク内キャッシュ ポリシーに従ってスイッチ メモリ内のホット アイテムを更新する責任があります。ホットアイテムは、スイッチによって計算され、コントローラに送信されるアイテム統計に基づいて検出できます。読み取りクエリが到着すると、スイッチはキャッシュに項目が含まれているかどうかを確認します。キャッシュ ヒットの場合、スイッチは関連する値をユーザーに返します。それ以外の場合、リクエストはストレージ サーバーに継続されます。パス上で、いずれかのスイッチによってキーが検出されると、パケットの経路は切り詰められます。したがって、ネットワーク内キャッシュによって待ち時間を短縮できます。

3. ネットワーク内コンピューティングの利点

(i) 高スループット

ネットワーク要素は 1 秒あたり数十億のパケットを処理できます。たとえば、Barefoot がリリースした Tofino チップは、12.8 Tb/s の回線速度処理をサポートします。したがって、ネットワーク内コンピューティング パラダイムは、ホストベースのソリューションよりも桁違いに高いスループット処理能力を提供します。

(ii) 低遅延

ホストベースのソリューションは、本質的に非決定的な遅延とジッターに悩まされます。対照的に、ネットワーク要素はマイクロ秒未満の処理遅延をサポートします。パイプライン設計では各ステージで外部メモリにアクセスしないため、レイテンシーはほぼ一定、つまり低ジッターになります。例示的な使用例で説明したように、ネットワーク内計算はネットワーク内で計算を実行するため、トランザクションはパス内で終了し、リモート サービスへのデータの迂回を回避します。したがって、ネットワーク要素からエンドホストへのデータ送信による遅延が軽減されます。実際、ネットワーク内コンピューティングは、ユーザーの近くで計算を実行し、エッジ/クラウド コンピューティング サーバーを超えて計算を実行できます。

(iii) 帯域幅使用量の削減

使用例を通じて説明したように、ネットワーク内コンピューティングは、エッジ/クラウド サーバーに到達する前に、パス上のデータ計算を終了します。したがって、帯域幅の使用量が節約され、バックホール リンク上のトラフィックの輻輳を回避できます。

(iv) 負荷分散

ネットワーク内で計算を利用することにより、一種の負荷分散が発生します。リクエストは、パスに沿ったネットワーク要素によって応答され、エンドホストに到達する前に処理されます。この点において、ワークロードはネットワーク要素とエンドホストの間で分散されます。たとえば、遅延の影響を受けにくいアプリケーションのトラフィックをエンドホストに転送できる一方で、ネットワーク要素は遅延の影響を受けやすいアプリケーションに対応できます。

(v) エネルギー効率

ネットワーク要素は、操作の実行中に消費するエネルギーが少なくなります。一般的なプログラマブル スイッチは、使用エネルギー 1 ワットあたり数十億回の操作を実行できます。たとえば、Arista 7170 シリーズ プログラマブル スイッチの消費電力は 100G ポートあたり 5 ワット未満です。また、[27] の実験では、ネットワーク要素における何百万ものクエリ操作の消費電力が 1 ワット未満であることが示されています。ネットワーク要素は、エネルギー使用量 1 ワットあたりの処理能力において、汎用コンピュータよりも効率的です。また、ネットワーク要素は、デフォルトのタスクがパケット転送であるネットワークの一部であるため、アイドル モードでは多くのエネルギーを消費しません。対照的に、汎用コンピュータはアイドル モードでのエネルギー消費が高くなります。

D. 分類、評価および比較の基準

このセクションでは、ネットワーク コンピューティングの範囲内で文献研究を分類、評価、比較するための一連の基準を提案します。

1. 提案された分類法

最初のレベルでは、ネットワーク内での計算の応用に基づいて研究を分類することを提案します。インネットワーク コンピューティングの範囲を明確にするために、各アプリケーション カテゴリ内で、そのカテゴリのコンテキストでインネットワーク コンピューティングが扱う専門的なトピックに従って論文を整理することを提案します。セクション IC では、私たちが提案する分類構造について詳しく説明します。ここでは、読みやすくするために、第 1 レベルで提案された分類法の概要を示します。分析、キャッシュ、セキュリティ、オーケストレーション、テクノロジー固有のアプリケーションの 5 つのカテゴリが見つかりました。

(i) ネットワーク内分析: このタイプの調査では、ネットワーク要素を利用して、データをエンドホストに渡すことなく、パス上で分析 (機械学習、データ集約、リフロー検出、クエリ処理、制御、ディープ パケット インスペクションなど) を実行します。 。

(ii) ネットワーク内キャッシング: このタイプの研究では、ネットワーク要素を利用してストレージ サーバー上にネットワーク内キャッシング システムを構築し、データ アクセス時間を短縮します。この研究カテゴリでは、キーバリュー ストア アプリケーションの範囲内で実施された研究と、情報中心のキャッシュの範囲内で実施された研究が見つかります。

(iii) ネットワーク内セキュリティ: このタイプの研究は、ネットワーク要素内で一部またはすべての機能を実行し、ネットワーク攻撃を検出および軽減し、セキュリティ目的の専用サーバーによって課せられる攻撃軽減の遅延と運用コストを削減します。

(iv) ネットワーク内調整: 分散システムにコンセンサス プロトコルを実装して、特定のデータ値または一連の操作の一貫性を達成することにより、これは調整の一種と見なすことができます。文献には、ロック管理システム、マルチキャスト通信、コンセンサス調整などの他のタイプの調整もあります。このような研究では、調整の実行に必要な機能の一部またはすべてをネットワーク要素にオフロードして、調整の待ち時間を短縮します。

(v) テクノロジー固有のアプリケーション: このタイプの調査では、クラウド コンピューティング、エッジ コンピューティング、4G/5G/6G、ネットワーク機能仮想化など、特定のテクノロジーに関連するさまざまなネットワーク内コンピューティング アプリケーションが提供されます。この研究カテゴリの研究では、テクノロジーに固有の機能の一部をネットワーク要素にオフロードします。

2. 評価・比較基準の提案

私たちは、ネットワーク内コンピューティングに関する論文を分析、比較、評価するための 2 つのカテゴリの基準、一般的な基準とアプリケーション固有の基準を提案します。

(i) 一般基準:

私たちは、考えられるすべてのネットワーク内コンピューティング ソリューションを分析、比較、評価するために、次の基準を提案します。

• ネットワーク内計算: ネットワーク内計算は、ネットワーク要素内で実行されるタスクまたは計算です。実際、ネットワーク要素の論理コンポーネント (TCAM/SDRAM に配置できるプログラマブル スイッチのマッチング アクション テーブル、FPGA のコンピューティング ロジック ブロック、スマート ネットワーク カードのプログラマブル コンポーネントなど) は、言語 (P4 など) によってプログラムされ、ネットワーク内の計算を実行します。アプリケーションに応じて、ネットワーク内コンピューティングは、一種のデータ集約、機械学習アルゴリズム、トラフィック統計の計算、セキュリティ ポリシー、移動体通信技術における無線/コア ネットワーク機能、または一般的なネットワーク機能などになります。この基準は、研究者に、ターゲットを絞った計算を特定のネットワーク要素に実装できるかどうかを評価するための洞察を提供します。さらに、研究のギャップを埋めるために、ネットワーク要素に実装されていない特定の計算からいくつかの教訓を得ることができます。

• 共同設計: この標準は、提案されたアプローチにおいて、必要な計算または決定を実行するためにネットワーク要素を非ネットワーク要素 (サーバー、コントローラーなど) と一緒に使用するかどうかを定義します。必要な計算は、問題のコンテキストに基づいて定義されます。ネットワーク内分析では、分析を実行します。ネットワーク内キャッシュでは、キャッシュを実行してリクエストに応答します。ネットワーク内セキュリティでは、攻撃の軽減を実行します。ネットワーク内調整では、調整を実行します（例：コンセンサスプロトコルでのコンセンサス）。計算。同様に、テクノロジー固有のアプリケーションでは、必要な計算は対象となる問題のコンテキストから決定されます。たとえば、ネットワークに LTE EPC コントロール プレーンを実装しようとする場合、必要な計算は LTE EPC コントロール プレーンの機能です。提案された方法が共同設計アプローチである場合は常に、必要な計算の一部のみがネットワーク要素で実行され、それ以外の場合は必要な計算全体がネットワーク要素で実装されます。この点において、非共同設計手法はネットワークに完全に実装できます。この規格は、さまざまな問題に対処する際のネットワーク内のコンピューティングの機能についての洞察を研究者に提供します。さらに、ネットワーク要素のハードウェア制約に対処する際の共同設計アプローチの提供など、研究ギャップからいくつかの教訓を得ることができます。

• データ構造: この標準は、実装で使用されるネットワーク要素のデータ構造を定義します。私たちは、ブルーム フィルター (要素がセットのメンバーであるかどうかをテストする機能を提供するデータ構造)、スケッチ (トラフィックの取得など、ネットワークに関する情報を要約できるデータ構造) などのよく知られたデータ構造の使用を報告しました。固定サイズのメモリ情報を必要とする統計情報）、ハッシュ テーブル [44]、[73]。

• ネットワーク要素: この規格は、評価用のネットワーク要素を定義します。文献には、プログラマブル スイッチ/ルーター、FPGA、およびネットワーク インターフェイス カード (NIC) という 3 つのカテゴリのネットワーク要素が見つかりました。表 1 は、各カテゴリの機器を説明しています。この規格は、特定のアプリケーションのネットワーク要素を特定するための洞察を研究者に提供します。さらに、この規格はさまざまなネットワーク要素の使用状況の分布に関する洞察を提供するため、研究のギャップを埋めるための教訓を引き出すことができます。

表I ネットワーク内計算研究で使用されるネットワーク要素のカテゴリ

• プラットフォーム: この規格は、メソッドが評価されるプラットフォーム (ハードウェアまたはソフトウェア) を定義します。ネットワーク要素のソフトウェア バージョン (BMv2、ソフトウェア ルーター、アナログ スイッチなど) が評価に使用される場合、プラットフォームはソフトウェアとみなされることに注意してください。

• 主要な調査結果: この調査では、ネットワーク内のコンピューティング デバイスの遅延、スループット、帯域幅の節約、および電力消費に関して達成された主要な結果が提供されます。

(ii) 特定の基準の適用

また、比較研究のためのアプリケーション固有の基準もいくつか提案します。ここでは基準の概要を示し、詳細については各アプリケーションの専用セクションを参照してください。

• ネットワーク内分析: ネットワーク要素に分析を標準として実装するための簡素化された技術 (量子化、事前計算など) を検討します。さらに、分析の目的が収集されたデータに基づいて構築されたモデルを推論することであることを考慮して、モデルの複雑さ、モデルの精度、推論速度、帯域幅消費量 (データ転送による) などの基準を使用して手法を比較します。また、ネットワークに分析を実装するための技術を、ハードウェア制約の種類、技術的操作、適用された技術によって損なわれる基準などのハードウェア制約と比較する方法も示します。

• ネットワーク内キャッシュ: このスコープのメソッドは、コンテンツ/アイテムへのアクセスを容易にするネットワーク内キャッシュ メカニズムを提供します。ネットワーク内のキャッシュ階層を含むキャッシュ メカニズムを深いキャッシュとして定義し、それ以外の場合は浅いキャッシュとして定義します。ネットワーク内のキャッシュ メカニズムのタイプ (つまり、浅いキャッシュ/深いキャッシュ) を基準として考慮します。さらに、キャッシュ階層、リクエスト処理の負荷分散、コンテンツ/アイテムのアクセス遅延、ネットワーク エッジで利用可能なストレージ、帯域幅消費 (コンテンツ転送による) などの基準を使用して方法を比較します。

• ネットワーク内セキュリティ: これらの手法の目的が攻撃を軽減することであることを考慮して、モデル攻撃検出システム状態、攻撃検出モデル、攻撃検出精度、軽減遅延 (セキュリティ ポリシーの検出と適用の遅延を含む)、および帯域幅を使用します。 (攻撃を検出するためのトラフィック送信による) 消費量を比較して方法を比較します。

• テクノロジー固有のアプリケーション: システムまたはアプリケーション関連のパフォーマンス指標を最適化するための最適化手法がメソッドに適用されているかどうかを評価します。さらに、計算ノードの種類、処理コスト、遅延/スループット、消費電力などの基準の観点から、文献に記載されているアプローチとサーバー/専用ハードウェアベースのスキームの長所と短所を比較します。また、実行時の適応性や耐障害性などの基準を含め、基盤となるネットワーク (ネットワーク要素と汎用コンピューティング ユニットの両方) の混合に対処するためのリソース割り当て手法の長所と短所についても説明します。

この調査の残りの部分では、ネットワーク内コンピューティングに関連すると思われるさまざまな論文をレビューし、上記のカテゴリと以前に指定した基準に従ってそれらの論文について議論します。調査した手法が共同設計アプローチである場合は常に、その背後にある理由を説明します。比較は論理的に説明され、文献で収集された証拠によって裏付けられます。

III. ネットワーク内分析

このセクションでは、ネットワーク内での分析の実行に関する既存の研究の概要を説明します。図 2 セクション III は、このセクションの構造を示しています。データ集約、機械学習、その他の分析の 3 つのカテゴリに分けて、ネットワーク内分析の研究の概要を提供します。データ集約は、さまざまなソースからデータを収集し、そのデータに何らかの集約関数または操作を適用する研究の概要を示します。これは、データから集約モデルを組み立てる分析の一種とみなすことができます。これらの研究では、データ集約はネットワーク要素を使用して実行されます。機械学習カテゴリでは、ネットワーク要素での機械学習技術の実装に関する研究の概要を提供します。最後に、「その他の分析」カテゴリには、大量トラフィックの検出、制御、クエリ処理、複雑なイベント処理、ディープ パケット インスペクションなど、ネットワーク内分析の範囲内で実施される追加の調査が含まれます。このセクションの残りの部分では、前述のカテゴリの研究を紹介し、最後に研究の概要を示して、洞察と得られた教訓について説明します。

A. データの集約

データ集約は、集約関数または演算を適用して、さまざまなソースからのデータを結合する手法です。ネットワーク内データ集約では、ネットワーク要素に集約オーバーレイを設定し、オーバーレイを通過するデータを集約します。集約のために集中ホストにデータを送信するホストベースの集約と比較して、ネットワーク内での集約はネットワーク内のトラフィックを削減するだけでなく、ネットワーク要素の高速な処理速度を利用して集約時間を短縮します。この研究カテゴリでは、[12]、[29]、[74]、[75]、[76]、[77] が同様のマルチレベル データ集約アーキテクチャを採用しており、通常はツリー構造に基づいていますが、さまざまなアプリケーションにプロトコルを提供しています。[29] はハイパフォーマンス コンピューティング アプリケーション用のデータ集約プロトコルを提案し、[12]、[74] の研究では Map-Reduce アプリケーションに基づくデータ集約プロトコルを提供しました。[75] の研究は IoT アプリケーションのネットワーク内アグリゲーションを提供し、[76]、[77] の研究はワイヤレス ネットワークのネットワーク内アグリゲーションを提案しています。

効率的な HPC アーキテクチャでは、すべてのデータ処理をローカルまたはリモートの CPU にオフロードするのではなく、代替システム要素を評価してデータ操作を適切に分散する必要があります。データ操作をネットワークにオフロードすると、データの移動に応じて CPU サイクルが計算用に解放され、通信遅延とネットワーク上で送信されるデータ量が削減されます。これらの目標を達成するために、Graham ら [29] は、ハイパフォーマンス コンピューティングで一般的に使用される通信パターン、つまりメッセージ パッシング インターフェイス (MPI) 標準のセット操作をネットワークにオフロードしました。著者らは、データ集約のために操作をネットワークにオフロードする階層型集約プロトコルを提案しています。小規模データ削減、グローバル削減、ネットワーク要素のバリアなどの削減操作を実行します。データはリーフ ノードから集約ツリーに入り、集約ノードでデータ削減操作が実行されている間にツリーを上に移動します。集約ノードは、すべての子ノードから集約要求を受信し、集約操作を実行します。各集約ノード上の各集約操作では、データ構造を使用して集約操作の進行状況を追跡します。集約の結果は、集約ノードによってツリー構造内の親ノードに送信されます。ルート集約ノードは、最終的な集約操作を実行し、集約操作の結果を生成し、その結果を宛先に転送します。このプロトコルは、トランスポート レベルのエラー、ターミナル ノードのエラー、プロトコル エラーなど、発生する可能性のあるエラーに対処するフォールト トレランス メカニズムもサポートしています。ネットワーク内コンピューティングは、Mellanox の SwitchIB-2 ASIC に実装された集約データ削減操作です。評価の結果、操作完了までの待ち時間が70%改善できることがわかりました。

[12] および [74] の研究では、Map-Reduce ベースのアプリケーションのネットワーク内データ集約が実行されます。Sapio et al. [12] は、リデューサーごとに、リデューサーへのすべてのマッパーのパスを含む、リデューサーをルート ノードとしてスパニング ツリーが構築される集約システムを設計しました。次に、ネットワーク コントローラーは、ツリーごとの集約を実行し、ツリー構造を通じてトラフィックを転送するようにネットワーク要素を構成します。各マップ タスクは、Reducer 間で分割されるキーと値のペアのセットを生成します。パーティションは UDP パケット経由でリデューサーに転送されます。各パケットにはプリアンブルとキーと値のペアのシーケンスが含まれます。プリアンブルでは、キーと値のペアの数とパケットが属するツリー ID を定義します。ツリーごとに、ネットワーク要素はキーと値をメモリに保存します。著者らは、各ネットワーク要素によって実行されるアルゴリズムを提案しています。このアルゴリズムでは、要素はメモリに保存されている値と受信した新しい値を集計します。提案されたアルゴリズムはまた、集約された結果をターゲットに向かって次のノードに転送するようにネットワーク要素をプログラムします。ネットワーク内の計算、つまりデータの保存と Map-Reduce 固有の集計は BMv2 によって実装されます。Word-Count アプリケーションの場合、提案された方法により 87% ～ 89% の帯域幅が節約され、84% の遅延が削減されることが実験により示されています。

[74] の著者らは、Map-Reduce 計算に基づいてネットワーク内データ集約を実行するためのアーキテクチャを提案しました。提案されたアーキテクチャは、スイッチ、ヘッダ抽出モジュール、負荷アナライザ、およびコントローラで構成されます。(i) スイッチは、異なるポートから到着するフローを集約し、集約結果を次ホップに送信します。また、パケットは通常どおり転送されます。(ii) ヘッダ抽出モジュールはデータ パケットのヘッダを確認し、従来経路の L2/L3 情報に基づいて通常のデータ パケットを転送モジュールに送信します。ただし、パケットが集約目的でマークされている場合、パケットは負荷アナライザーに転送されます。(iii) ペイロード アナライザーは、キーと値のペアでフォーマットされたペイロードを受け入れ、その長さに基づいてこれらのペアをさまざまな処理エンジンに割り当てます。処理エンジンは、ハッシュ テーブルに格納されている同じキーの値を集計します。(iv) コントローラは集約ツリーを構築し、スイッチを構成します。ネットワーク内の計算は Map-Reduce 固有の集計であり、NetFPGA-SUME 開発ボードによって実装されます。著者は、Verilog HDL を使用してデータ プレーンを開発し、それを NetFPGA-SUME 開発ボードにコンパイルし、パーティション/集約モードで動作する単純な MapReduce のようなシステムを実装しました。提案されたアーキテクチャは、最大 99% のデータ削減率と最大 44% のジョブ完了時間の短縮を達成しました。

キーベースの集約 [12] および [74] とは異なり、Madureira ら [75] は、さまざまな IoT サービスをカバーするためにサービス ID に基づいて集約を実行します。著者らは、IoT アプリケーションでデータを集約するためのマルチレベルのデータ集約アーキテクチャを提案しています。データは、マルチレベル アーキテクチャの要素を通過するときに集約されます。アグリゲーション プロトコルは、ネットワーク要素のリンク層 (L2) で動作します。パケット ヘッダーには、次の 3 つの主要な要素が含まれます。(i) サービス ID。同じ IoT アプリケーションに属する類似のデータセットを識別するために使用されます。(ii) データ カウンター。データ ブロックの数を定義するために使用されます。(iii) タイプ。パケットの転送に使用される転送メカニズムを示します。集約階層内のスイッチは、階層内の他のスイッチからパケットを受信し、特定の条件が満たされた場合にパケットのサービス ID に基づいてデータ (平均など) を集約します。主な条件は、同じサービス ID を持つ受信データの数がしきい値に達した場合です。著者らは、実装時のスイッチによってサポートされていないループおよび行列のデータ構造を処理する手法も提案しています。ネットワーク内コンピューティングは、BMv2 によって実現される IoT 固有のアグリゲーションです。IoTデバイスとフォグコンピューティングゲートウェイを受信側とした環境でのシミュレーション結果から、提案手法はIoTデバイス内でアグリゲーションを行う場合に比べて平均遅延が5倍高速であることがわかりました。

[76] は、ノイズの多いマルチホップ無線ネットワークにおいて一定の耐障害性を備えたデータ集約プロトコルを提案しました。この研究の主な議論は[77]に記載されています。各ノードは m ビット整数を入力として受け取り、各ノードが事前定義された数の読み取り値を収集した後に計算を開始します。著者は、割り当て可能な関数の実行に焦点を当てています。ネットワーク クラスタリングの後、2 つのクラスタ内プロトコルとクラスタ間プロトコルが提案されます。クラスタ内プロトコルは、クラスタ ヘッドの調整を利用して、クラスタ内のデータに関数を適用します。クラスター間プロトコルを適用することにより、ローカル集約結果はクラスター ヘッドおよび中継ノードを介して受信ノードにルーティングされます。データをコードワードにエンコードし、受信後にデータをデコードすることも、クラスタ内およびクラスタ間プロトコルに含まれます。さらに、クラスタ間でスケジューリングを行って送信を行うことで、同時送信による干渉を軽減します。提案されたプロトコルの効率は、アイデンティティ関数と制限されたタイプのしきい値関数に対して改善されます。著者らはプロトコルの複雑さも分析しています。ネットワーク内計算は分散可能な機能であり、ワイヤレス ネットワーク中継ノードによって実装されます。このアプローチでは、他のデータ集約手法と比較してネットワークにおける関数のより一般的な適用について説明しますが、この議論は分析に基づいており、提案された手法を評価するものではありません。

b. 機械学習

機械学習アルゴリズムは、受信データ パケットの分類や回帰の実行に広く使用されています。これらのアルゴリズムは、パケット ヘッダー フィールドとトラフィック統計を入力特徴として受け取り、収集されたネットワーク トレース データからトラフィック パターンを学習し、将来の入力について予測することができます。機械学習を適用するには、未知のデータ パケットをリモート サーバーに転送して学習アルゴリズムを実行する必要があります。ただし、これには待ち時間と帯域幅の消費量が増加します。ネットワーク内コンピューティングを活用して、学習処理時間を短縮し、イベントに早期に応答し、エッジに近づくときにトラフィックを終了するための研究が行われています。[78] は決定木、SVM、Naive Bayes などのさまざまな分類方法を実装し、[79]、[80] はニューラル ネットワークを実装し、最後に [81] はネットワーク要素による連合学習を実装しました。このセクションの残りの部分では、上記の研究についてさらに詳しく説明します。

[78] では、Xiong と Zilberman は、スイッチ上でデシジョン ツリー、SVM、Naive Bayes、および K-means クラスタリングを実装することを検討しました。著者は、ルックアップ テーブルを使用して計算結果を保存し、スイッチ上で上記の分類とクラスタリングを実装するためのいくつかのアルゴリズムを提案します。デシジョン ツリーを使用すると、パイプラインの各段階で、特徴がそのすべての潜在的な値と照合されます。結果として、ツリー内の分岐を表すアクションがメタデータ フィールドにエンコードされます。パイプラインの最後のステージでは、すべての機能のメタデータ フィールドに基づいて最終結果が計算されます。SVM は複数のテーブルに実装されており、各テーブルは入力と超平面の関係を示します。実際、一致アクション テーブルのキーは特定の入力の特徴セットであり、アクションは入力が超平面の内側に属するか外側に属するかを示す投票です。入力がすべてのテーブル (つまり、すべての超平面) と照合されると、投票数が最も多いカテゴリが分類の結果となります。Naive Bayes は、特徴をキーとして、クラスごとに 1 つのテーブルを使用して実装されます。戻り値は、単純ベイジアン学習で使用される確率を表す整数値です。著者らは、さまざまなマッピングのクラスタリングと、特徴からテーブルへの K 平均法クラスタリングについても説明します。ネットワーク内の計算は、BMv2 および NetFPGA SUME に実装されているデシジョン ツリー、SVM、Naive Bayes、および K 平均法です。提案された方法は、学習に必要な数学的初期化ルックアップ テーブルを使用するため、共同設計方法と見なされます。評価は、複数のカテゴリ (オーディオ、ビデオなど) を使用して IoT トラフィック分類に対して実行されます。は、ライン レートでの分類 (推論) の遅延が 2.6 マイクロ秒、精度が 94% であると報告しました。

[79] では、ネットワーク要素でのニューラル ネットワークの実装について説明しています。著者らは実験を通じて、GPU や TPU などのオフライン アクセラレータで AlexNet ニューラル ネットワークを実行する場合、データ移動のオーバーヘッドが高いことを示しています。パス上にアクセラレータを実装することで、追加のデータ移動オーバーヘッドを削減できます。ただし、ネットワーク要素を使用してニューラル ネットワーク処理を実行するには、処理を分割する必要があり、オーバーヘッドが発生します。著者らは、適切な分割メカニズムを提案することでオーバーヘッドを削減しています。ニューラル ネットワーク パラメータのすべてまたは一部は、ネットワーク要素の SRAM に保存されます。アクティベーションとパラメーターを 2 値化する量子化と呼ばれるプロセスを使用して、ニューラル ネットワークの全結合層の操作を簡素化します。これにより、ニューラル ネットワークのアクティベーションとパラメーターを表すために必要なビット数が削減され、より単純な算術演算が使用されます。ネットワーク内コンピューティングはニューラル ネットワークであり、ネットワーク プロセッサ ベースの SmartNIC に実装されています。ネットワーク内でのニューラル ネットワークの 1 層の処理には 1 ミリ秒かかりますが、CPU によって処理が実行される場合、この待ち時間は 12 ミリ秒にもなります。

[79] と同様に、Lu と Lin [80] はネットワーク内のニューラル ネットワーク推論の方法を提案しました。著者らは、オンライン推論用のスイッチ コアへのパケット クローン作成を可能にするデータ転送処理システムを開発しています。スイッチ内で推論機能を提供するには、Neural Compute Stick (NCS) と呼ばれるハードウェアが使用されます。NCS は、複製されたデータ パケットを処理し、リアルタイム推論を実行するために、USB インターフェイスを介して P4 スイッチに接続されます。提案されたアーキテクチャは 2 つの段階で構成されます: (i) CNN アーキテクチャ LeNet-5 を使用して推論モデルを作成するオフライン モデル トレーニング段階、(ii) オンラインで推論を実行するために NCS を使用するオンライン推論段階。ネットワーク内コンピューティングはニューラル ネットワークであり、Edge-core Wedge 100-32X スイッチに実装されています。畳み込みニューラル ネットワークに基づくマルウェア分類問題の場合、推論時間は、ネットワークで推論が実行される場合は 9 ミリ秒、サーバーで推論が実行される場合は 44 ミリ秒です。正解率は94%以上です。

Qin et al. [81] は、ネットワーク内計算を使用したフェデレーテッド ラーニングのためのワイヤスピード フレームワークを提案しました。活性化関数としてバイナリの重みと符号関数を使用したニューラル ネットワークの分類は、ネットワーク ドメイン内のデバイスのパケットを転送するゲートウェイで実行されます。実数値の重みを含むニューラル ネットワークはコントロール プレーンに保存され、分類アルゴリズムはバックプロパゲーションを実行することによってゲートウェイで再トレーニングされます。ローカル トレーニングの後、ゲートウェイはアグリゲーターとしてローカル更新をクラウドに送信します。通信コストを削減するために、各ゲートウェイはローカルで更新された 1 ビット シンボルのみを報告します。その後、クラウドは多数決メカニズムを通じて結果を発表します。ネットワーク内の計算はニューラル ネットワークであり、BMv2 を使用して実装されます。提案された方法は、集約にはクラウド コンピューティングを、バックプロパゲーションと更新にはコントロール プレーンを活用するため、協調的な設計アプローチです。120 個のニューロンを備えた完全接続の隠れ層に対するマルウェア トラフィック検出の評価では、ネットワーク内の推論の遅延がパケットの 95% で 2 ミリ秒未満であることが示されています。

C. その他の分析

ネットワーク内コンピューティングは、大量トラフィックの検出 [59]、[82]、[83]、制御 [84]、[85]、クエリ処理 [86]、[87]、[88]、複雑なイベント処理 [ 89]、ディープ パケット インスペクションのアプリケーションで活用されています [90]。このセクションでは、これらの研究の概要を説明します。

ヘビーヒッターの検出は、ネットワーク監視とセキュリティの分野における重要な問題です。その目的は、ネットワーク トラフィック内で最大のデータ量を含むフロー (ヘビー ヒッター フロー) を検出することです。

大量のトラフィックの検査は、リンクの輻輳の軽減、ネットワーク攻撃の検出、ネットワーク容量のスケジューリングなど、多くのネットワーク管理アプリケーションにとって有益です。既存の大量トラフィック検査方法は通常、ソフトウェア デファインド ネットワークのコントロール プレーンに実装されます。したがって、コントロール プレーンとデータ プレーン間の頻繁な通信により、意思決定におけるオーバーヘッドと追加の遅延が発生します。このオーバーヘッドを削減するために、ネットワーク内計算が活用されています。[59]、[83]、[82] の研究は、フロー サイズを推定するためにフローごとのパケット数をカウントするデータ プレーンの実装に似ています。カウント値の分析には、[59] では機械学習アプローチが使用され、[82]、[83] ではしきい値に基づく意思決定が提案されています。

Zhang et al. [59] は、プログラマブル データ プレーン上の大量のトラフィックを検出するための決定木ベースの方式を提案しました。提案手法はオフラインでのモデル学習とオンラインでの推論の2ステップから構成される。オフライン モデル トレーニングでは、コントローラーはデシジョン ツリーをトレーニングし、それをターゲット スイッチのリソースにコンパイルします。オンライン推論では、デシジョン ツリーに基づいてプログラム可能なデータ プレーン上で大量のトラフィックが検出されます。パイプラインでは、最初のパケットのヘッダーが抽出され、対応する情報がレジスターに保存されます。フローの受信パケット数がしきい値に達すると、そのフローはデシジョン ツリーを通じて評価され、大量のトラフィックが検出されるとフラグが付けられます。したがって、検出時に必要なアクションを実行できます。ネットワーク内計算は決定木推論段階であり、BMv2、Flnet S9180-32X、および Barefoot Tofino 32D ASIC を使用して実装されます。提案されたスキームは、トレーニング段階がコントローラーによって実行されるため、共同設計アプローチです。検出精度は98%と高く、ハードウェアスイッチの平均スループットは9.4Gbpsです。

[82] は、プログラマブル スイッチの大量トラフィックを検出するアルゴリズムも提案しました。[59] と同様に、フロー キーワードとそれに関連するカウンタを識別するためにテーブルが使用されます。ここで、カウンタはフローに関連付けられたパケット数を表します。パケットが到着すると、対応するフローのカウント情報がテーブルになく、テーブルに空きがある場合、新しいフローがテーブルに挿入され、その初期カウント値が 1 に設定されます。ただし、フローのカウント情報がすでにテーブルに存在する場合は、対応するフロー カウンタが更新されます。テーブルがいっぱいでフロー情報が欠落している場合、テーブル内のカウンタ値が最も小さいフロー エントリが、新しく到着するフローの統計を示すために置き換えられます。フロー パケット数と高トラフィック インスペクションはネットワーク内で計算されます。提案された方法は、メモリ消費量が 80 KB 未満でありながら、95% の精度で大量のトラフィックを検出できます。

Vestin et al. [84] は、センサー/アクチュエーター制御ネットワークにネットワーク内計算を利用しました。センサーは定期的にデータを生成し、分析のためにコントローラーに送信されます。したがって、コントローラーは制御アクションをアクチュエーターに送信します。コントローラとの通信によって生じる遅延を軽減するために、著者らはコントローラの一部の機能をプログラマブル スイッチのデータ プレーンにオフロードしました。スイッチはセンサー値の履歴をキャッシュします。制御の決定に対応する論理式は結合正規形に変換され、スイッチ テーブルに実装されます。したがって、スイッチはアクチュエータの制御決定をトリガーします。さらに、リンク障害が発生した場合のプロアクティブなリンク修復スキームが提案されています。データのキャッシュ、処理、制御の決定などのネットワーク内コンピューティングは、P4 スイッチに実装されています。実験結果は、提案された方法が、コントローラーが制御アクションを送信する場合と比較して、センサーとアクチュエーターの待ち時間を 6 ミリ秒短縮することを示しています。

Cesen ら [85] は、ネットワークがロボットとコントローラーで構成され、ロボット アームが適切に構造化された反復タスクを実行するようにプログラムされている超低遅延ロボット制御の問題に焦点を当てました。コントローラとロボット間の TCP 通信。コントローラーはロボット側から受信したメッセージを分析し、ロボットが特定のしきい値位置から逸脱した場合に停止メッセージを送信するなど、それに応じて制御コマンドを送信します。ネットワーク要素はコントローラーとロボットの間に配置され、ロボットとコントローラーの間でトラフィックを転送するために使用されます。著者らは、遅延が重要なアプリケーションをスイッチにオフロードすることで、特定の制御メカニズムをロボットに近づけることで遅延を短縮できると主張しています。上記のユースケースでは、特定のロボットの位置を検出し、それに応じて停止/移動コマンドをロボットに送信することは、BMv2 によって実装されるネットワーク内計算です。評価の結果、制御コマンド発行のレイテンシは、コントローラが発行するコマンドのレイテンシに比べて、ナノ秒オーダーでほとんど無視できる程度であることがわかりました。

研究 [86]、[88] では、ネットワーク テレメトリと車両料金計算のためのネットワーク内クエリ処理を提案しています。既存のストリーム プロセッサ テレメトリ システムは、多大な帯域幅と処理コストがかかり、最新のネットワークの要件である 1 秒あたり数億回のオペレーションの規模で効率的な処理を提供できません。最新のストリーム プロセッサでこれらの要件をサポートすると、コアあたりの処理能力が低いため、高いコストが発生します。一方、プログラマブル スイッチのみに依存してクエリ処理システムを提供すると、スイッチ処理能力の制限により表現力が犠牲になります。

Gupta et al. [86] は、ハイブリッド プログラマブル スイッチとストリーム プロセッサを利用して、表現力と拡張性を実現しています。作成者は、さまざまな一般的なテレメトリ タスクのクエリを表現するためのインターフェイスを提供しています。各クエリは、一連のデータフロー操作 (フィルター、マップ、リダクション、結合など) で構成されます。データフロー操作は、データ プレーン内のマッチ アクション テーブルにマッピングされます。結合などの一部の操作はデータ プレーンでの実装にコストがかかるため、一連のサブ操作にグループ化されます。各サブオペレーションの実行はデータ プレーンで決定され、結果は最終的にストリーム プロセッサでマージされます。パーティションを決定するために、スイッチで利用可能なリソースの制約を考慮して、ストリーム プロセッサに送信されるパケット数を最小限に抑える整数線形計画を解くプランナーが提案されます。Teixeira ら [87] は、スイッチ内部のパケット処理を監視するための機能を追加することで、[86] のシステムを拡張しました。ネットワーク内計算は、Barefoot Tofino に実装されたクエリ操作です。提案された方法は、クエリ操作を処理するためにストリーム プロセッサとスイッチを組み合わせた共同設計アプローチです。評価の結果、ベースラインと比較してストリームプロセッサの負荷を最大99%削減できることがわかりました。

Jepsen et al. [88] は、高速道路の車両料金を計算するための照会システムの実装について議論しています。クエリ システムは、車両の位置と速度、車両に課せられた料金、高速道路の 2 つの区間間の移動時間などの履歴データを受け取ります。車両への料金通知の送信、事故通知、車両に課される料金の照会など、さまざまなアプリケーションのクエリと通知が定義されています。ベンチマークは、P4 言語を使用してスイッチに実装されます。P4 ヘッダーは、位置報告用データや事故警報用データなどのデータ タイプを指定するフィールドを含む固定幅フィールドで定義されます。したがって、データの種類に応じてテーブルと制御フローが定義され、パイプラインでパケットが処理される方向が示されます。著者らはまた、P4 で汎用状態抽象化を実装する際の課題について、いくつかの視点を提供します。ネットワーク内計算は BMv2 と Barefoot Tofino に実装されたクエリ処理であり、コードはオンラインで入手できますが、著者は論文内で評価を行っていません。

网络数据包携带着基本事件，例如传感器数据和管理数据如入侵检测系统或异常检测。通过评估传入的信息即基本事件，复杂事件处理（CEP）可以推断出更高级别的知识，即复杂事件。传统的CEP是在服务器或覆盖网络上执行的。然而，正如Kohler等人所建议的那样，通过利用网络内部计算进行CEP，可以避免数据流向远程服务器的绕道，从而减少通信延迟，优化带宽消耗。此外，网络硬件的高处理能力可以提供高效的CEP系统。作者表明，在P4中表达CEP操作是可行的。数据平面由一组互连的可编程网络处理元素和主机组成。主机托管基于事件的应用程序，可以是事件源或事件接收器。事件源观察基本事件并传播它们，而事件接收器接收并对复杂事件做出反应。网络处理元素实现非CEP数据包的转发，以及CEP功能，即窗口运算符和事件检测引擎。窗口运算符存储和聚合多个头字段的最后几个值。事件检测引擎基于状态机实现，检测复杂事件。作者还提出了一个将CEP操作编译为P4代码的工具。网络内部计算包括聚合函数和复杂事件检测，这在Netronome Agilio智能网卡和BMv2中均有实现。评估说明了在延迟和吞吐量方面，与BMv2相比，NIC的表现更为优越。对于由两个基本事件组成的复杂事件，NIC的检测延迟在10微秒至29微秒之间，吞吐量在16％至56％之间。

ディープ パケット インスペクション (DPI) は、パケットのペイロードを調査して、正規表現として記述されたパターンを検出します。DPI は、専用アプライアンス (ミドルウェアなど) を使用して導入することも、エンドホスト上のソフトウェアとして実装することもできます。前者はコストが高く、管理や更新が難しく、後者は汎用コンピュータに計算負荷がかかり、サーバー負荷によるパフォーマンスの変動を引き起こします。これらの問題に対処するために、Hypolite らは既存のネットワーク処理ハードウェアを活用してラインレート DPI を達成しています。提案された方法は、Aho-Corasick アルゴリズムを利用して正規表現をコンパイルし、それらを状態遷移テーブルを使用して実装される決定論的な有限オートマトンに変換します。終了状態は、テーブルを使用して終了状態を一致したパターンのセットにマップするパターン一致を表します。提案された方法は、ステートレスなパケット内とステートフルなパケット間の両方に正規表現マッチング機能を提供します。ネットワークの内部計算は、Netronome NFP-6000 SmartNIC を使用して実装された DPI の正規表現マッチングです。評価では、最大 20 Gbps のスループット向上が示されています。

D. 要約、比較、洞察、および教訓

このセクションでは、まずネットワーク イントラネット分析の範囲内で実施された調査を簡単に要約し、次に比較、洞察、得られた教訓について説明します。

1. 概要

このセクションでは、ネットワーク内部分析の範囲内で実施された調査の概要を説明します。ネットワーク内でのデータ集約の方法を提案するいくつかの研究が実施されています [12]、[29]、[74]、[75]、[76]、[77]。データが集約のために集中ホストに転送されるホストベースの集約と比較して、ネットワーク内でのデータ集約はネットワーク トラフィックの量と集約時間を削減できます。データ集約のために、複数のオーバーレイ層がネットワーク全体に構築されます。次に、データ ソースから発信されたトラフィックが構築されたオーバーレイを通過するにつれて、複数のソースからデータが収集され、ネットワーク要素で集約機能が実行されます。研究者らは、ハイパフォーマンス コンピューティング アプリケーション [29]、Map-Reduce ベースのアプリケーション [12]、[74]、モノのインターネット アプリケーション [75]、ワイヤレス ネットワーク [76​​]、[ 77]。アプリケーションに応じて、さまざまな集約関数が定義されます。メッセージ パッシング インターフェイス標準 [29] の集合操作などの HPC 固有の関数、Map-Reduce 固有の関数 [12]、[74]、IoT 固有の関数 [12] ]、分離可能機能などの無線ネットワーク固有の機能 [74]。

トラフィックをリモート サーバーやホストに転送する必要がある一般的な機械学習手法とは異なり、ネットワーク内で機械学習を適用すると、遅延と帯域幅の消費を削減できます。ネットワーク要素での機械学習の実装に焦点を当てた研究もあります。[78] は、デシジョン ツリー、サポート ベクター マシン、単純ベイズ、K 平均法クラスタリングなど、プログラマブル スイッチでのさまざまな分類方法の実装を調査しました。[79]、[80] では、ネットワーク要素にニューラル ネットワークを実装することを検討しました。[81] は、ネットワーク要素を介した連合学習を研究しました。ネットワーク要素のメモリと処理の制限により、量子化技術 [79] や単純化されたニューラル ネットワーク モデル [81] などのいくつかの単純化技術が適用されています。

ネットワーク内分析に関する他の研究も行われています。既存の大量トラフィックの検出方法は通常、ソフトウェア定義ネットワーキング パラダイムのコントロール プレーンに実装されます。ネットワーク要素内の大量のトラフィックを検出すると、意思決定におけるオーバーヘッドと追加の遅延が削減されます。データ プレーン内のフローごとのパケット数のカウントに基づく大量トラフィック検出メカニズムは、[59]、[82]、[83] で検討されています。[84]、[85] の研究では、制御目的でプログラム可能なデータ プレーンを利用しています。[84] では、センサー/アクチュエーター制御ネットワークでパケットを解析し、最終的に制御決定を行うためのスイッチの使用が研究されました。単純なロボット制御は、[85] のプログラマブル スイッチにオフロードされます。[86]、[87]、[88] では、クエリ処理のためのネットワークの内部実装について検討しました。最後に、ネットワーク要素は、複雑なイベント処理 [89] やディープ パケット インスペクション [90] に活用されています。

2. 比較、洞察、得られた教訓

表II. ネットワーク内分析の比較、DS (データ構造)、SIMPL (簡略化)、PLAT (プラットフォーム)、Y (はい)、N (いいえ)、H (ハードウェア)、S (ソフトウェア)

表3: ネットワークに機械学習を実装する際のハードウェア制限に対処するための手法の比較

															**表四：比较网络内分析、基于服务器/控制器的分析和共同设计方案**

表II从贡献、方法论（网络内部计算、共同设计标准、方法中使用的网络元素的数据结构、方法中使用的简化技术）和评估（网络元素、仿真平台、主要结果）等方面比较了审查的研究。从表II中可以看出，文献中的研究要么完全在网络中实现所需的分析（共同设计为“N”），要么遵循共同设计方法（共同设计为“Y”），在此方法中，网络元素与服务器或控制器结合使用，提供所需的分析。

• 技术应对硬件限制的比较：表III比较了应对硬件限制的使用技术。在[79]，[81]中提倡的量化技术通过在学习模型中应用简化，例如在神经网络中使用二进制权重或符号函数作为激活函数，从而促进推断计算。然而，通过量化，精度会因通过网络内部计算实现的推断速度而受到牺牲。另一方面，[78]中的预先计算技术预先计算所需的统计数据，例如朴素贝叶斯中基于高斯的似然计算，并在网络元素中填充所需的查找表。与量化技术相比，这种技术具有获取更高精度的潜力，并提供更精确的统计信息。作为另一种硬件限制，由于具有有限的流水线/阶段和匹配-动作表条目，还存在并行处理限制。数据包重新循环通过重新循环数据包通过网络元素以应用所需的处理来应对这种限制[79]。然而，这会增加延迟，可能在高循环轮次中导致线速率处理违规。根据[79]，要在具有最多96个神经元并行能力的交换机上执行单层的4096个神经元，需要将数据包循环43次，这会延长延迟。

表IV从模型复杂度、模型精度、推断速度和带宽消耗等方面比较了完全在网络中实现的分析方法、基于服务器/控制器的分析方法（这是[79]，[80]，[84]，[85]等研究中进行比较的基准），以及共同设计方案（参见表II中的共同设计方案）。

• モデルの複雑さ: ハードウェアの制限 (例: ステージ/パイプライン/ロジック ユニットの数の制限、マッチアクション テーブル エントリ、レジスタ、およびデータ構造の制限) および浮動小数点演算などの一般的なコンピューティング機能の欠如 (例: プログラマブル スイッチ/ルーター) によるもの。 、完全にネットワーク内に実装されたメソッドは、サーバー/コントローラーベースの分析メソッドよりも機能が劣ります。汎用処理コンピューティング能力を活用することにより、共同設計スキームにより、ネットワークに完全に実装される分析手法が容易になります。たとえば、汎用コンピュータを使用して尤度確率を事前計算し、(利用可能なレジスタ内の) ネットワーク要素に計算を注入することで、ベイジアンや SVM のような複雑な学習モデルを実装することが可能になります [78]。別の例は、[86] で提唱されているように、ネットワークでの単純なクエリ処理をオフロードしながら、ストリーム プロセッサ サーバーで複雑なクエリを処理することで、複雑なクエリ処理モデルを可能にします。

• モデルの精度: ネットワーク内で完全に実装された分析は、サーバー/コントローラーベースの実装と比較して精度が低くなる可能性があります。これは、ニューラル ネットワークなどのネットワーク要素でターゲット分析を実装するために簡略化と近似が必要になる場合があるためです。バイナリ重みまたはシンボリックでは、シグモイド関数などのより正確な活性化関数ではなく、活性化関数が使用されます [81]。共同設計アプローチには、ネットワーク内で完全に実装されるスキームと比較して、複雑な演算を汎用コンピューティング ユニットにオフロードすることで、より高い精度を達成できる可能性があります。

• 推論速度: ネットワーク内で完全に実装された分析方法は、ネットワーク要素のライン レートに近い互換性のあるパイプライン モードで到着パケットを処理する機能を備えており、エンド デバイスの近くで処理できます。したがって、サーバー/コントローラーベースの分析と比較して、より高速な推論が期待されます。たとえば、スマート NIC に実装された単層ニューラル ネットワークでは、推論遅延が最大 92% 削減されると [79] 報告されています。共同設計スキームは、計算の一部が依然としてネットワーク内で実行されるため、サーバー/コントローラーベースの解析と比較してより高い推論速度を達成できる可能性があります。

• 带宽消耗：完全在网络中实现的分析方法将节省带宽消耗，因为数据流量在边缘处终止，不需要传输到服务器或控制器。例如，在[74]中，对于一个map-reduce应用程序，节省带宽高达99%。共同设计方法仍在边缘处执行一些流量处理，因此其带宽消耗将低于基于服务器/控制器的方案。但是，带宽消耗可能比完全在网络中分析更高，因为某些数据仍将传输到服务器/控制器进行处理，或者某些控制信号将在服务器/控制器和网络元素之间传输。例如，在[81]的研究中，流量在云中的聚合器和在边缘节点中实现的网络内神经网络之间传输，以执行加权聚合以构建联合学习方法中的全局学习模型。要有一个有效的共同设计方案，需要进行优化决策，以便在服务器/控制器和网络元素之间最小化通信开销的情况下最优地分配计算。

还有一些见解可以从中吸取一些教训：

• 高键值体积的聚合：[12]，[74]研究了基于键值数据结构的网络内数据聚合。然而，对于存在大量键（例如，在文本中出现大量单词的单词计数应用程序），没有建议任何数据聚合机制。这是关键的，因为网络元素的内存限制大小不能占据任意数量的键。一个得出的教训是需要更多的研究努力来为高键值提供聚合机制。

• 机器学习：另一个洞见是，只有四个研究探讨了网络元素上的机器学习实现，其中[79]，[80]，[81]考虑了神经网络实现，而只有[78]考虑了非神经网络的学习机制。然而，该研究假定用于学习过程中的数学函数的计算已经在设备内设置为查找表。一个得出的教训是需要更多的研究来在网络元素内实现非神经网络的学习方法。特别是，需要更多的研究来开发实现非神经网络学习方法中的数学函数的方法（例如朴素贝叶斯，SVM等）。另一个洞见是，即使神经网络方法进行了简化（例如在权重或激活函数中），为了在网络元素中实现学习，这可能会导致精度降低。需要更多的研究来追求在不使用简化技术的情况下实现神经网络的可行性。

• 共同設計: 共同設計手法は、ネットワーク内分析では特に重要です。その理由は、ネットワーク要素の処理とメモリの制限により、すべての機能や操作をネットワーク要素に実装できるわけではないためです。さらに、すべての操作や機能を、一致アクション テーブルなどの特定のネットワーク転送アーキテクチャにマッピングできるわけではありません。ネットワーク要素に実装できない機能や操作は、エンド ホストやコントローラに保持できます。分析アプリケーションにおける共同設計手法を提供した研究はほとんどありません。たとえば、[86] では、クエリ処理でストリーム プロセッサを使用して複雑な操作を実装するための共同設計アプローチを使用する研究が行われています。私たちが得られる教訓は、ネットワーク内分析の共同設計方法を提供するには、さらなる研究努力が必要であるということです。

IV. ネットワーク内キャッシュ

このセクションでは、Web でのキャッシュに関する既存の研究の概要を説明します。図 2 のセクション IV は、このセクションの構造を示しています。まず、キーバリュー ストアのコンテキストでの研究の概要を説明します。このストアでは、高頻度のキーバリュー ペアのキャッシュがネットワーク要素にオフロードされ、キーバリュー ストア ベースのアプリケーションのクエリを処理する際の待ち時間が短縮されます。次に、ICN の基本アーキテクチャとして NDN の概要を説明します。これはネットワーク内キャッシュと互換性があることがわかります。他の ICN アーキテクチャの包括的な調査は、[68] にあります。

A. キーと値のストア

许多互联网服务的操作，包括搜索服务、社交网络和电子商务，都依赖于高性能的键值存储。为了在数据中心能够响应海量请求，需要扩展存储服务器，这会增加功耗。此外，基于键值存储的服务通常对端到端延迟非常敏感。利用网络内计算有潜力显著提高键值存储系统的性能。在网络元素中缓存内容可以节省在网络中的数据遍历，减少延迟，并且非常适合处理同一信息的频繁请求。[91]，[92]，[93]，[94]，[95]的研究提倡采用分层缓存系统，在高级别和接近网络边缘的位置，网络内缓存操作加速查询处理，而在低级别的缓存中，存储服务器操作。然而，这些研究在实现网络内缓存的网络元素（例如FPGA，可编程交换机）以及缓存协议的详细信息方面存在差异。此外，在[96]中提出了一个具有可编程交换机的复制键值存储在数据平面上，并且在[92]中提出了一个带有网络内缓存的分布式共享内存系统。需要注意的是，上述研究都将存储数据和缓存功能作为网络内计算来执行。此外，它们都是共同设计方法，因为请求的数据是从网络元素或后端存储获取的。在本节的其余部分，我们将提供更多细节。

Tokusashi等人提出了一种分层的基于键值的缓存系统，其中高层存在基于FPGA的网络内缓存，低层存在一个memcached服务器[91]。作者采用了多核处理器方法进行查询处理。所提出的架构包括一个处理单元（PE）网络、多个PE、一个存储器网络和包括DRAM、SRAM和CAM的存储器。传入的查询被分散在PE元素之间，每个PE处理一部分查询。一旦查询被处理，PE就会访问存储器网络。存储器网络中存在三种类型的存储器：包含哈希表桶和数据存储块的DRAM；包含块信息的SRAM；以及作为查找表检索键值对的CAM。

当查询到达时，PE解析数据包以提取键，其哈希用作指向DRAM中地址的指针。如果DRAM中存在键，则会被视为命中。对于命中的SET命令，键值对会在DRAM中更新。对于带有新键的SET命令，PE根据存储在SRAM中的空闲描述符列表将其分配给块。对于命中的GET查询，会向客户端返回一个响应。但是，在缓存中未命中的情况下，请求将被转发到主机上的memcached服务器，并相应地更新缓存和DRAM中的键和值，以包括以后的使用。评估结果显示全线速吞吐量（最高可达13 Mquery/s），同时具有较低的延迟（1.1 µs）和比仅使用memcached服务器的情况下更高的功耗效率（提高了80%）。

Jin等人考虑了另一个分层缓存系统，其中在高层采用可编程的顶部交换机，在低层使用存储服务器[93]。作者提出了一种基于网络内计算的键值存储架构，用于在数据中心内平衡机架内所有存储服务器的负载。作者利用理论讨论，通过在顶部交换机中缓存特定数量的项目，可以执行存储服务器之间的负载平衡。为了在顶部交换机中启用缓存，他们提出了一种架构，包括顶部交换机、控制器和存储服务器。

该交换机提供了基于路径的键值项缓存，并支持使用标准L2/L3协议进行数据包路由。它具有键值缓存模块，用于存储最热门的项，以及统计元素，用于保持每个缓存项的查询频率，并检测未缓存项的热门查询。控制器通过接收交换机的统计报告更新缓存，并决定要插入（驱逐）哪些项到（从）缓存中。

读查询由交换机处理，而写查询则转发到存储服务器。对于读查询，当交换机中有缓存命中时，它会将缓存值插入数据包头。查询的统计频率元素也将在交换机中更新。当有缓存未命中时，查询将被转发到存储服务器进行处理，并回复给客户端。如果交换机检测到未命中的查询为热门查询，则会通知控制器，以便控制器决定缓存策略。使用Barefoot Tofino进行的评估表明，与基准相比，可以实现高达40%的延迟降低和最高10倍的吞吐量增加。

Liu らは、トップスイッチのみを使用する [93] とは異なる、ネットワーク内の深いキャッシュ構造を提案しています [94]。提案されたネットワーク内キャッシュ構造は、データセンター ネットワークにキャッシュ プリミティブを提供します。サーバー ラックは、トップ スイッチとコア スイッチを含む階層型スイッチによって接続されます。データ パケットがスイッチに到着すると、データ パケットは計算のためにネットワーク アクセラレータに転送されます。Web アクセラレータは、パケット ペイロード内のキーと値のペアとコマンドを抽出し、関連する操作を実行します。新しいキーと値のペアの書き込みコマンドの場合、アクセラレータはスペースを割り当ててデータを書き込みます。コマンドがキーに基づいて値を読み取る場合、アクセラレータはキャッシュ ルックアップを実行します。ミスがあった場合、Web アクセラレータは元のパスに沿ってリクエストを転送します。ヒットがある場合、ネットワーク アクセラレータは応答を作成し、スイッチに送信します。著者は、マルチパス キャッシュと、クライアント、スイッチ、またはサーバー障害の場合の処理​​について説明します。著者らは、Cavium XPliant スイッチと OCTEON ネットワーク アクセラレータ プロトタイプを使用して、提案されたキャッシュ構造を検証します。彼らのプロトタイプは、クラスター構成でのリクエストの遅延を 30% 以上削減し、スループットを 2 倍にしました。

[94] と同様に、[95] の研究でも、トップ スイッチやキャッシュ スイッチを含むマルチレベルのネットワーク内キャッシュ構造が提供されています。ただし、[94] ではネットワーク内のキャッシュ構造における負荷分散は保証できませんが、[95] では負荷分散が考慮されています。Liu et al. [95] は、負荷情報を利用してネットワーク内キャッシュ構造内のキャッシュ スイッチ間のクエリ負荷のバランスをとる、クラスタ化ストレージ システム用のネットワーク内キャッシュ アーキテクチャを提案しました。提案されたアーキテクチャには、キャッシュ コントローラー、キャッシュ スイッチ、ストレージ サーバー、クライアント ライブラリが含まれます。(i) コントローラは、ラック/スイッチの挿入やシステム障害などのシステム再構成イベントの下で、キャッシュの分割を決定し、キャッシュ割り当てを更新します。(ii) キャッシュ スイッチは、コントローラからキャッシュ パーティションとキャッシュ ホット キー値オブジェクトを受け取ります。さらに、付随メカニズムに基づくネットワーク内のテレメトリ メカニズムがスイッチに実装され、負荷情報を分散し、キャッシュ間のクエリ分散のガイダンスを提供します。(iii) ストレージ サーバーはキーと値のストアをホストします。(iv) クライアント ライブラリは、アプリケーションがキーと値のストアにアクセスするための機能を提供します。

提案されたアーキテクチャによれば、キャッシュされたオブジェクトに対する読み取りクエリはキャッシュ スイッチによって応答されます。一方、キャッシュされていないオブジェクトの読み取りクエリと書き込みクエリはストレージ サーバーに転送されます。キャッシュスイッチの負荷は上位スイッチのオンチップメモリ​​に格納されるため、スイッチ負荷を考慮したルーティング機構が提案される。著者らは、キャッシュ コヒーレンシ メカニズムと、コントローラ/リンク/スイッチの障害を処理するメカニズムも提供します。評価の結果、キャッシュを行わない場合と比較して、スループットが最大8.5倍向上することがわかりました。

Jin et al. [96] は、データ プレーンとコントロール プレーンを含む、複製されたキーバリュー ストア アーキテクチャを提案しました。(i) データ プレーンは、複製されたネットワーク内のキーと値のストアを構築し、読み取り/書き込みクエリを管理します。キーバリュー ストアは、ハッシュ ベースのメカニズムを使用して、データ プレーン内の複数のスイッチに分散されます。スイッチが読み取り/書き込み操作でパケットを受信すると、目的のアクションを実行し、宛先 IP を次のチェーン ノード (ミスが発生した場合など) またはクライアント IP (ヒットした場合など) に更新します。パケットが順序どおりに到着しないという問題を解決するには、シーケンス番号を使用して書き込みクエリをシリアル化します。(ii) コントロール プレーンは、スイッチ テーブルとレジスタ、およびスイッチ障害によるシステムの再構成を管理します。スイッチの障害は、高速フェイルオーバーとフェイルバックの 2 つのステップに分けられます。高速フェイルオーバーでは、コントローラーは残りのスイッチ ノードを使用してクエリを処理し続けるようにネットワークを再構成します。フェールバックでは、コントローラーは修復されたスイッチを新しいレプリケーション ノードとして追加します。フェールバックでは状態を新しいレプリカにコピーする必要があるため、高速フェールオーバーよりも時間がかかります。評価結果では、Zookeeper のようなサーバーベースのソリューションと比較して、スループットが最大 105 倍向上していることがわかりました。

Wang等人[92]提出了一种具有网络内缓存和缓存一致性管理的机架级分布式共享内存系统。整个架构由一组内存节点、一个顶部交换机和一个影子节点组成。(i)每个内存节点都包括一个全局内存来存储块。此外，它还有一个应用程序线程组件，用于执行应用程序逻辑并通过写/读接口访问全局内存。它还有缓存代理组件，用于在内存中传输缓存数据。(ii)除了使用标准的L2/L3协议路由正常数据包外，交换机负责存储热块，并执行缓存一致性协议的部分，包括请求的序列化和多播。具体而言，它管理访问共享数据的锁。(iii)影子节点帮助在交换机和内存节点之间迁移缓存块的所有权。评估结果显示，在键值存储、图引擎和事务处理工作负载上，分别比分布式共享内存实现高出4.2倍、2.3倍和2倍的吞吐量加速。

B. 以信息为中心的缓存

从以主机为中心的通信模型向基于访问信息的兴趣模型的互联网使用的演变，引入了信息中心网络（ICN）的概念。根据ICN，信息是通过命名机制请求的，并且可以从网络中的节点检索，而不考虑它们的物理位置。尽管该概念早于网络内计算引入，但我们看到ICN架构与网络内缓存一致。特别地，命名数据网络（NDN，也称为内容中心网络）的基本架构引入了提供内容存储以在网络中缓存信息的内容路由器。在这里，我们提供关于NDN的概述，作为ICN中的基本架构，我们认为它与网络内缓存兼容。我们建议有兴趣的读者参考[68]，了解信息中心网络架构的全面调查。

在NDN [97]中，订阅者通过INTEREST消息请求信息对象，回复将是一些DATA消息。消息由存储三个数据结构的内容路由器（CR）转发：(i) 转发信息库（FIB）将信息名称映射到输出接口，以便转发INTEREST消息，(ii) 挂起的兴趣表（PIT）用于存储正在等待DATA消息的INTEREST消息，(iii) 内容存储（CS）用于缓存已通过CR传递的信息对象。

INTEREST メッセージが CR に到着すると、要求されたプレフィックスと名前が一致する情報オブジェクトが CS で検索されます。ヒットが発生した場合、結果は入力インターフェイスを介して DATA メッセージで返されます。それ以外の場合は、FIB で照合が実行され、メッセージの転送先の出力インターフェイスが決定されます。次に、INTEREST の入力インターフェイスが PIT に保存され、INTEREST は FIB によって決定された CR に転送されます。

DATA メッセージが CR に到着すると、情報オブジェクトは CS に保存され、PIT で照合が実行されて、どのインターフェイスを介して DATA メッセージが転送されたかを調べます。

C. 要約、比較、洞察、および教訓

このセクションでは、まずネットワーク内キャッシュのコンテキストで実施された研究を簡単に要約し、次に比較、洞察、得られた教訓について説明します。

1. 概要

このセクションでは、ネットワーク内キャッシュの範囲内で実施された研究の概要を説明します。このタイプの調査では、ネットワーク内の計算により、キーと値またはコンテンツがキャッシュされ、ネットワーク要素へのクエリが処理されます。キャッシング サービスはネットワーク内キャッシング構造とバックエンド ストレージ サーバーの結合を通じて提供されるため、調査されたすべてのネットワーク内キャッシング方法は共同設計方法とみなされます。

Key-Value ストアがデータ センターに存在する展開では、クエリへの応答に長い待ち時間が発生します。ネットワーク内キャッシュにより、ネットワーク全体でのデータのやり取りが回避され、待ち時間が短縮され、スループットが向上します。[91]、[92]、[93]、[94]、[95] の研究では、ストレージ サーバーの上部にクエリを処理するためのネットワーク内キャッシュ構造を構築しています。[91] は FPGA ベースのネットワーク内キャッシュ構造を開発しましたが、[92]、[93]、[94]、[95] はプログラマブル スイッチを利用してネットワーク内キャッシュ構造を実装しています。[91]、[92]、[93] では、ネットワーク内のキャッシュ構造は浅く、トップ スイッチまたは FPGA で構成されていますが、[94]、[95] では、ネットワーク内キャッシュ構造は深く、スイッチの階層で構成されています。一般に、クエリ リクエストがネットワーク内のキャッシュ構造にヒットすると、リクエストされた値が返されます。一方、ネットワーク内のキャッシュ構造を欠落したリクエストはストレージ サーバーに転送されます。[91]、[92]、[93]、[94]、[95] の研究は、キャッシング プロトコルの詳細が異なります。さらに、キーバリューストアのカテゴリでは、[96] はデータプレーンのプログラマブルスイッチを使用した複製キーバリューストアを提案し、[92] はネットワーク内キャッシュを備えた分散共有メモリシステムを紹介しています。

ICN の概念は、名前付けメカニズムを通じて情報またはデータが直接要求され、物理的な場所に関係なくネットワーク内のノードから取得できるというもので、これはネットワーク内のキャッシュと一致していると思われます。特に、名前付きデータ ネットワークの基本アーキテクチャは、ネットワーク内の情報をキャッシュするためにコンテンツ ルーターにコンテンツ ストレージを提供します。[68] は、ICN アーキテクチャの包括的な調査を提供します。

2. 比較、洞察、得られた教訓

表v ネットワーク内コンピューティングとしてデータの保存とキャッシュの機能を実行するネットワーク内キャッシュの研究の比較

表vi 浅い/深い Web キャッシュとサーバーベースのキャッシュ

表VII ネットワーク内キャッシュを実装する際のストレージ制約に対処するための手法の比較

表 V は、貢献度、方法論 (共同設計基準、ネットワーク内キャッシュ構造)、および評価 (ネットワーク要素、シミュレーション プラットフォーム、主な結果) の観点からレビューされた研究を比較しています。表 Vからわかるように、文献の研究では、浅いネットワーク内キャッシュ構造または深いネットワーク内キャッシュ構造が提供されています。表 VI は、浅いネットワーク内キャッシュ スキームと深いネットワーク内キャッシュ スキーム、およびクラウド内のオリジン サーバーまたはネットワーク内のストレージ サーバーがコンテンツを保存するサーバーベースのキャッシュ スキームを比較しています。[91]、[94]、[96] などの多くの研究では、クラウドまたはストレージ サーバーでのキャッシュのケースが比較のベースラインであることに注意してください。

• キャッシュ階層: 浅いネットワーク内キャッシュ スキームは、ネットワーク内キャッシュ要素とオリジン サーバー (ストレージ サーバーとも呼ばれる) を含む 2 レベルの階層を構築します。ディープネットワーク内キャッシュスキームは、ネットワーク内キャッシュ要素のセットを含む階層とオリジンサーバーのネットワーク内キャッシュ構造の 2 つ以上のレベルを含む階層を構築します。一方、クラウドベースのキャッシュ ソリューションは、クラウドに配置されたオリジン サーバーであるレベルのキャッシュを提供します。

• 負荷分散: サーバーベースのキャッシュ スキームでは、すべての要求はキャッシュ サーバーによって応答され、負荷分散の機会はありません。対照的に、浅いネットワーク内キャッシュ スキームは、リクエストがネットワーク内キャッシュ要素またはオリジン/ストレージ サーバーによって処理されるため、負荷分散を提供します。一方、[92]、[93] などの浅いネットワーク内キャッシュ スキームと比較して、[94]、[95]、[96] などの深いネットワーク内キャッシュ スキームは、さまざまな次元でロード バランシングを改善します。のロード バランシングは、イントラ キャッシング構造間、およびイントラ ネットワーク キャッシング構造とオリジン/ストレージ サーバー間で提供されます。

• コンテンツ/アイテム アクセスの遅延: ディープ ネットワーク キャッシュ ソリューションは、エッジに近い複数のネットワーク内キャッシュ内のコンテンツ アクセスと高負荷分散を提供し、ユーザーのエクスペリエンス遅延を最小限に抑えることができます。一方、オリジンサーバーまたはストレージサーバー上のコンテンツへのアクセスのみを提供し、負荷分散をサポートしないサーバーベースのキャッシュソリューションでは、長距離とコアネットワークの輻輳により遅延が長くなります。[94] では 30% 以上のレイテンシの削減が報告されています。したがって、スループットの向上が期待されます。たとえば、サーバーベースのキーバリュー ストア ソリューションと比較してクエリ処理スループットが 105 倍増加したことが [96] で報告されています。

• エッジ ストレージ: 浅いネットワーク内キャッシュ スキームは、ロジック ユニット、マッチ アクション テーブル、レジスタを介して非常に限られたストレージ (たとえば、プログラマブル スイッチで数十/数百メガバイト程度) を提供します。対照的に、ディープネットワーク内キャッシュ方式では、ネットワーク内キャッシュ構造の層にある複数のネットワーク要素のストレージ容量を累積したストレージ容量が提供されます。サーバーベースのキャッシュ ソリューションは、エッジにストレージを提供しません。

• 帯域幅の消費: サーバーベースのキャッシュ スキームは、通常はクラウドに配置されているサーバーへのデータ フローにより、ダウンリンクでかなりの帯域幅を消費します。対照的に、浅いネットワーク内キャッシュ スキームは、コンテンツをエッジで提供することで帯域幅の消費を削減します。ネットワーク内の深いキャッシュ スキームは、ネットワーク内のキャッシュ構造により多くのストレージ容量を提供することで、より多くのリクエストに対応できるため、浅いスキームと比較して帯域幅の節約が高くなります。

表 VII は、ネットワーク内キャッシュを実装する際のストレージ制約に対処するための文献内の技術を比較しています。キー値ベースのキャッシュとネットワーク内の深いキャッシュ構造の利用という 2 つの手法があります。[91]、[92]、[93] などのキー値ベースのキャッシュは、マッチアクション テーブルと互換性のある小さなサイズのキー値ペアに従ってデータを編成するキー値ペアベースの検索システムに焦点を当てています。 。利点は、コンテンツ/アイテムのストレージと取得の互換性と簡単さです。欠点は、TCAM や SDRAM のサイズ制限などのストレージ容量の制限により、ネットワーク要素に少数のキーと値のペアしか格納できないことです。対照的に、深いネットワーク内キャッシュ構造技術は、ネットワーク内キャッシュ構造内の複数のネットワーク要素を活用します (文献では、キャッシュは階層として編成されることがよくあります)。[94]、[95]、[96]、ICN などの研究は、この手法を提唱しています。利点は、ネットワーク内キャッシュのストレージがキャッシュ構造の容量に合わせて拡張できることです。さらに、ファブリック内の複数のネットワーク要素を利用することにより、耐障害性が向上します。ただし、より複雑な保存および取得アルゴリズムが必要になるという欠点があります。さらに、ネットワーク内のキャッシュ全体で読み取り/書き込み操作のデータの一貫性を維持するには、一貫性メカニズムが必要です。

教訓を引き出すためのさらに多くの洞察を次に示します。

• キャッシュ内のネットワーク要素: ネットワーク内キャッシュのコンテキストでは、ほとんどの研究でプログラマブル スイッチ ASIC を使用してネットワーク内キャッシュが実装されています (表 V を参照)。FPGA 駆動の実装は [91] で採用されています。しかし、[91] で提案された方法は、1 つの memcached サーバーにキャッシュ構造を提供するだけであるため、スケーラブルではありません。実際のシステムには多数のサーバが存在しますが、FPGA のメモリ不足を考慮すると、1 つの FPGA では多数のサーバの負荷分散を実現できません。この研究の教訓は、FPGA または NIC ベースのネットワーク内キャッシュ構造を提供するには、さらなる研究作業が必要であるということです。さらに、FPGA または NIC ベースのネットワーク内キャッシュ構造と、スイッチでプログラム可能な ASIC ベースのネットワーク内キャッシュ構造を、レイテンシーやスループットなどのパフォーマンス基準の観点から比較した研究はありません。したがって、私たちが学んだもう 1 つの教訓は、さまざまなタイプのネットワーク内のキャッシュ構造を比較する研究の必要性です。

• ネットワーク内キャッシング構造における負荷分散: もう 1 つの洞察は、ネットワーク内キャッシング構造における負荷分散は全体的なパフォーマンスを保証するために非常に重要であることを考慮して、ネットワーク内キャッシング構造における負荷分散は [95] でのみ議論されているということです。キャッシングシステム。この調査では、ネットワーク内のキャッシュ ファブリック内のスイッチから収集された負荷テレメトリがクエリ ルーティングによって使用され、キャッシュ スイッチ間の負荷分散が確保されます。ただし、スイッチによって適用されるネットワーク内のテレメトリ メカニズムには通信オーバーヘッドがあり、負荷情報の配信に帯域幅を消費します。得られた教訓は、ネットワーク内のキャッシュ構造で効率的な方法で負荷分散を実現するには、さらなる研究作業が必要であるということです。

v. イントラネットのセキュリティ

このセクションでは、ネットワーク内セキュリティに関する研究の概要を説明します。図 2 のセクション V は、このセクションの構造を示しています。まず分散型サービス拒否 (DDoS) 攻撃の軽減に関する研究をレビューし、次にファイアウォール ソリューションを提供する研究をレビューし、最後に他のネットワーク内セキュリティ アプリケーションについて概説します。

A. DDoS 攻撃の軽減

ネットワーク環境は、悪意のある攻撃者によって制御される DDoS 攻撃に悩まされることがよくあります。DDoS 攻撃を軽減するには、スクラビング サービスを使用してクラウド内の攻撃を処理します。ただし、このメカニズムによりトラフィックが再ルーティングされ、遅延が増加し、攻撃に対処するためのリソースをオペレーターが提供するコストが増加します。さらに、スクラビングをクラウド上に展開すると、ユーザーに関する個人情報が漏洩するリスクがあります。これらの問題に対処するために、ネットワーク ベースの DDoS 攻撃軽減は、ネットワーク要素に依存してパケット サンプルまたはフロー レコードを分析し、ネットワーク内で攻撃の検出と軽減を実行します。

複数の研究により、フラッド攻撃に対する緩和メカニズムが提供されています。これらには、SYN フラッド攻撃 [61]、[98]、TCP フラッド攻撃 [99]、リンク フラッド攻撃 [100] が含まれます。SYN/DNS のスプーフィング対策は [60] の焦点です。[101]、[102] はボリューム DDoS 攻撃に焦点を当てています。[103] の研究では、AR-DDoS 攻撃に対するネットワーク内防御アーキテクチャが導入されています。[104]、[105]、[106] は、多くの種類の DDoS 攻撃を含む攻撃軽減のより一般的な観点を提供します。トラフィックの送信元を考慮すると、[107] では送信元アドレス検証に対するプロアクティブなアプローチが検討されており、[108]、[109]、[110] ではスプーフィングされたトラフィックを検出してドロップする研究が行われています。いくつかの具体的なケースも検討されています。[111] の研究では、DoS 攻撃を防ぐための安全な重複アドレス検出が提供されています。最後に、[112] の研究では、大学やデータセンターなど、下流で DDoS 保護サービスを提供するユースケースを検討しています。前述の研究では、検出および/または軽減メカニズムの一部またはすべてをネットワーク要素にオフロードします。以下はこれらの研究のレビューです。

DNSスプーフィング（DNSスプーフィング）とは、攻撃者がDNSサーバーのキャッシュや応答データを改ざんし、ユーザーが訪問したWebサイトを攻撃者が管理する悪意のあるWebサイトに誘導し、ユーザーの機密情報を盗んだり、その他の行為を行うことを指します。悪意のある行為。

1. フラッド攻撃

SYN 固有の防御メカニズムは、通常、SYN クッキーまたは SYN 認証を使用して SYN フラッド攻撃を軽減する SYN プロキシとして展開されます。Scholz et al. [98] は、カーネル バイパス ベースのパッケージ処理と比較して、P4 を使用してデータ プレーン上で SYN Cookie と SYN 認証ポリシーを強制する利点について議論しています。ターゲットはパケットを解析し、一致操作パイプラインによって実装された L2 転送ルールによって転送します。SYN Cookie と SYN 認証ポリシーの計算 (Cookie の計算やホワイトリストの設定を含む) は、ターゲット上に実装されます。 (i) タイムスタンプの生成、暗号化ハッシュの計算などの一部の Cookie 関連の機能は、P4 ターゲットに実装されます。(ii) 著者らは、ホワイトリストを実装するための 2 つのオプションについて議論しています: まず、データ プレーンがホワイトリストに登録する必要があるフロー/IP アドレスをコントロール プレーンに通知し、コントロール プレーンがテーブルにエントリを挿入します。次に、ブルームを活用します。データをフィルタリングする 構造はホワイトリストに登録されています。ネットワーク内コンピューティング、つまり SYN Cookie と SYN 認証ポリシーは、複数の P4 ターゲットに実装されます: T4P4S [113]、市販の既製ハードウェアで実行される DPDK ベースの P4 ソフトウェア ターゲット、NFP-4000 Agilio SmartNIC NPU および NetFPGA SUME 。評価の結果、NetFPGA は約 13 Mpps の SYN フラッド攻撃を処理できることが示されています。

Lin ら [61] は、SYN フラッド攻撃の緩和についても検討しました。この攻撃では、偽の送信元 IP アドレスを持つ大量の ACK パケットがサーバーに送信されるため、サーバーは元の送信元に対して SYN/ACK パケットで応答します。ただし、サーバーは対応する ACK/FIN パケットを受信しません。提案手法では、サーバに最も近いスイッチ上でSYN/ACKおよびACK/FINパケットの数をカウントし、それらの値の比率を計算して攻撃を判定する。異常が検出されると、悪意のある送信元 IP のトラフィックがドロップされ、コントローラに通知されます。提案されているネットワーク内攻撃の軽減により、SDN コントローラー上のトラフィックが削減されます。さらに、著者らは、メモリ消費のコストを削減するために、転送テーブル内のルールをマージするいくつかのマージ メカニズムを提案しています。ネットワーク内の計算には、BMv2 によって実装された、SYN/ACK および ACK/FIN パケット比に基づく SYN フラッド攻撃の検出と、悪意のあるソース IP を持つパケットの破棄が含まれます。提案したネットワーク内検出方法は、コントローラがスイッチにポーリングして情報を収集し、検出を行う場合と比較して、トラフィック量を最大4000バイト/秒削減することができます。

Musumeci et al. [99] は、TCP フラッド攻撃に焦点を当てた機械学習ベースの攻撃検出メカニズムを提案しました。P4 スイッチからのトラフィック情報は定期的に収集され、攻撃を検出するためにフラッド検出モジュールによって分析されます。分析は機械学習分類器を使用して実行されます。情報が収集された時間枠を考慮して、時間枠内のパケットの平均サイズ、TCP パケットの割合、UDP パケットの割合、TCP/UDP 比率、割合などのいくつかの特性が分類に使用されます。著者らは、詳細なトラフィック シグネチャを攻撃検出モジュールから P4 スイッチにオフロードできることも示唆しています。オフロードを実行するために、提案された方法は、P4 言語によって有効になるステートフル データ プレーンの可能性を活用して、P4 スイッチ内でのパケット ミラーリング、ヘッダー ミラーリング、およびメタデータ抽出を有効にします。ネットワーク内の計算、つまりトラフィック特徴抽出は BMv2 によって実装されます。提案された方法は、非ネットワーク要素に実装された TCP フラッド検出モジュールがネットワーク要素と連携して TCP フラッド攻撃を検出するため、協調設計アプローチです。SVM とランダム フォレストを使用した評価では、98% 以上の検出精度が示されています。さらに、P4 スイッチは約 110 マイクロ秒で特徴を抽出できますが、サーバー側の特徴抽出モジュールには約 15 秒かかります。

ネットワーク内にリンク フラッド攻撃軽減策を実装すると、いつでもどこでも疑わしいトラフィックが検出されるだけでなく、新しい構成を導入するための集中コントローラの必要性もなくなります。この集中再構成の適用には長い時間がかかるため、攻撃者はこれを悪用して戦術を変更する可能性があります。これに関して、Xing et al. [100] は、スイッチにいくつかのハードナーを実装することによって、ネットワーク内のリンク フラッド攻撃を検出および軽減する方法を提案しました。デフォルトモードでは、コントローラが計算した最適なポリシーに従ってルーティングが実行されます。ただし、攻撃が検出されると、アラートがネットワーク内に伝播され、スイッチ内で攻撃軽減強化機能がアクティブになります。通常のトラフィックへの中断を最小限に抑えるために、攻撃軽減エンハンサーは悪意のあるトラフィックを再ルーティングしますが、通常のトラフィックは引き続きコントローラーによって決定された元の最適なパスを介してルーティングされます。ネットワーク内コンピューティング、つまりリンク フラッド攻撃の検出と軽減は、BMv2 によって実装されます。評価の結果、提案手法は集中型のSDNコントローラがネットワークを再構成する場合と比較して、通常のユーザーフローのスループットが80%向上することがわかりました。

Afek ら [60] は、DDoS 攻撃に対する SYN および DNS のスプーフィング対策に関する研究を実施しました。2 つの異なる SYN スプーフィング対策方法 (HTTP リダイレクトと TCP リセット)、および 1 つの DNS スプーフィング対策方法が、OpenFlow および P4 ターゲットを使用して実装されています。主な方式は、Cookie ベースの通信プロトコル、つまり SYN Cookie ベースの方式です。SYN パケットが到着すると、生成されたハッシュ Cookie を含む ACK メッセージが応答として送信されます。認証は、クライアントが正しい Cookie で応答した場合にのみ行われます。SYN Cookie メソッドをプリミティブ ステップに変換し、各プリミティブ ステップが SDN データ プレーンの操作として実装されるようにします。データ プレーンを利用することで、SYN Cookie の生成などの一部の認証タスクをコントローラーと通信せずに実行できます。スイッチの TCAM サイズ制限に対処するために、著者らは、提案されたソリューションの複雑さを複数のスイッチに分散する方法を提案します。SYN Cookie メソッドのプリミティブに基づいた SYN および DNS のスプーフィング防止機能で構成されるネットワーク内コンピューティングは、Open vSwitch 2.3.1 を使用して実装されます。評価の結果、提案された緩和方法は、最大 206 Kpps の攻撃レートで Http リクエストを正常に処理し、最大 278 Kpps のスループットを維持できることが示されています。

[101] および [102] は、多くのホストがトラフィックを 1 人または少数の被害者に集約する大規模な DDoS 攻撃に焦点を当てています。[101] は攻撃の検出を検討し、[102] は緩和方法を提案しました。攻撃が発生すると、送信元 IP アドレスと宛先 IP アドレスの分布が正規のパターンから逸脱します。Lapolli et al. [101] は、シャノンエントロピー分析によってこの偏りを測定しました。実際、攻撃の場合、送信元 IP アドレスのエントロピーが増加し、宛先 IP アドレスのエントロピーが減少することが予想されます。著者らは、P4 によって実装されたエントロピー推定に基づく異常検出手法を提案します。提案手法は以下の 3 つのステップから構成されます。 (i) 観測ウィンドウ内で連続して到着するパケット間の IP アドレスのエントロピーを推定します。(ii) 観察ウィンドウの最後では、最近のエントロピー値の中心傾向と分散に基づいて正当なトラフィックがモデル化されます。(iii) 攻撃検出の閾値を計算します。これらのしきい値に基づいて、攻撃が検出されます。シャノンのエントロピー推定に基づくネットワーク内計算、正当なトラフィックの統計的特性計算、およびしきい値ベースの攻撃検出は、BMv2 によって実装されます。評価の結果、提案手法は98.2%の精度と250msの遅延でDDoS攻撃を検出できることがわかりました。

Gonzalez et al. [102] は、[101] によって提案されたエントロピーベースの分析を活用して、大規模な DDoS 攻撃を軽減するためのネットワーク内の遅延メカニズムを提案しています。提案されたメカニズムは、防御を高速化するためにクリティカル パスからコントロール プレーンを削除します。提案手法では、まずパケットの送信元IPアドレスのエントロピー解析により攻撃を検出する。その後、攻撃が検出されると、被害者の次の転送デバイスが上流の転送デバイスに警告します。したがって、これらのデバイスは疑わしいフローのパケットをフィルタリングし、攻撃も検出した場合は上流の転送デバイスに警告します。このプロセスは、悪意のあるトラフィックをその発信元の近くに留めるために繰り返されます。ネットワーク内コンピューティング、つまり大規模な DDoS 攻撃の検出と軽減は、BMv2 によって実装されます。最大 94% の検出精度が報告されており、攻撃に反応するまでの遅延は (攻撃の開始から) 0.1 ミリ秒です。

2.増幅反射DDoS攻撃（AR-DDoS）

在AR-DDoS攻击中，攻击者利用UDP协议的无连接性向互联网上的服务器发送欺骗性请求，该服务器则响应受害者的放大回复。Khooi等人[103]提出了一种防御AR-DDoS攻击的架构，该架构不依赖于任何洗净服务器，同时提供更快的攻击检测和缓解。所提出的架构在ISP网络的边界（即对等侧）和接入侧（面向客户）部署有有状态可编程路由器，以跟踪给定协议中请求/响应的计数。使用count-Min Sketches实现请求/响应的计数跟踪。然后，提出了一种分布式协议，用于在边界和接入路由器中，基于计数值达成可能的攻击共识。最后，在每个边界路由器上开发了一个访问控制列表，用于指示被滥用的服务器的IP地址并禁止恶意流量。网络内计算包括通过BMv2实现的AR-DDoS攻击的检测和缓解。评估结果表明，所提出的方法能够以99.8％的准确率在数据平面中检测和识别攻击。

Amplified Reflection DDoS Attack (AR-DDoS)是一种利用UDP协议的无连接性和网络上的反射服务器，通过欺骗反射服务器向目标服务器发送具有伪造源IP地址的请求，以获取更大的响应，进而使目标服务器的带宽和计算资源受到攻击的一种DDoS攻击方式。攻击者通过欺骗反射服务器向目标服务器发送大量的UDP请求，由于反射服务器会响应请求，而响应的数据包大小通常比请求的数据包大小大得多，攻击者可以通过欺骗反射服务器获取更大的响应，从而放大攻击流量，对目标服务器造成压力。

3.流量源的安全性

[107]、[108]、[109]和[110]的研究考虑了流量源的安全性。[107]提倡主动的源地址验证策略，而[108]、[109]和[110]的研究则以反应性的方式检测和丢弃欺骗性流量。

トークンベースの送信元アドレス検証ソリューションには、安全でないキーネゴシエーション、再暗号化アルゴリズムとルーターの計算オーバーヘッド、非標準ヘッダーの使用など、いくつかの欠点があります。これらの問題を克服するために、Yang et al. [107] は、プログラム可能なルーターに実装できる安全な鍵合意メカニズムを採用しました。提案された方法は、楕円曲線の Diffie-Hellman 一時鍵合意とリソース公開鍵インフラストラクチャを組み合わせて、安全な鍵合意を実現し、中間者攻撃に対抗します。著者らは、ネゴシエートされたキーに基づいて、送信元アドレスを擬似ランダム トークンにマッピングするネットワーク内トークン生成アルゴリズムを設計します。提案されたマーカー生成方法は、標準ヘッダーとの互換性を維持するために、適切なパケット ヘッダー フィールドにマーカーを挿入します。ネットワーク内コンピューティング、つまりタグ生成は市販の P4 スイッチによって実装されます。実験結果は、提案した方法がなりすましパケットをフィルタリングすることによって最大 200 kbps の帯域幅を節約できることを示しています。

Gondaliya et al. [108] は、送信元ノードや宛先ノードではなく、中間スイッチにスプーフィング防止メカニズムを導入することを提唱しています。送信元 IP アドレスが偽造されたスプーフィングされたパケットを検出して破棄するために、著者らは、ネットワーク イングレス フィルタリング、スプーフィング防止方法、リバース パス転送の変種、およびサビ。著者は、各スプーフィング対策メカニズムを実装するマッチアクションテーブルについて説明します。ネットワーク内コンピューティング、つまりスプーフィング防止メカニズムは NetFPGA SUME ハードウェアに実装されています。評価結果によれば、パケット生成速度が8.5Gbps、なりすましパケットの割合が12.5%の場合、なりすまし防止機構のスループットは約7.5Gbpsとなる。

[108] と同様に、[109]、[110] の著者も、なりすましトラフィックのフィルタリングに重点を置いています。著者らは、IP-to-Hop-Count (IP2HC) マッピング テーブルを使用してスプーフィングされた IP トラフィックをフィルタリングできるホップ カウント フィルタリング (HCF) 防御メカニズムを提唱しています。彼らは、HCF メカニズムをエンドホストに適用するのではなく、プログラマブル スイッチ内に統合することを提案しています。これにより、なりすましトラフィックが早期に特定され、ネットワーク帯域幅リソースが節約されます。提案されたアーキテクチャには、それぞれキャッシュとミラーと呼ばれる 2 つのデータ プレーンと 1 つのコントロール プレーンが含まれています。データ プレーンは最もアクティブで正当な IP アドレスを提供し、コントロール プレーンは残りの IP アドレスを管理し、IP2HC マッピング テーブルを保存し、ネットワークのダイナミクスに適応するようにシステム状態を更新します。データ プレーンは 3 つのモジュールを実行します: (i) パケットを検証するための IP2HC モジュール、(ii) 正当なホップ カウントを追跡し、ホップ値を更新するための TCP セッション監視モジュール、(iii) 正当な/スプーフィングされた IP に関する統計を計算するための統計モジュール。パケットのホップ カウント チェックが成功すると、対応する統計が更新され、パケットが転送されます。ただし、チェックが失敗すると、パケットはドロップされ、スプーフィング パケット カウンタが増分されます。スプーフィング パケット カウンタの値は、定期的にコントロール プレーンに報告されます。

スイッチのメモリ制限を克服するために、コントロール プレーンはトラフィックのグローバル ビューを維持します。バイナリ ツリー データ構造を使用して IP アドレス情報を集約し、グローバル IP2HC マッピング テーブルを維持します。さらに、スプーフィング パケット カウンタは、システム状態の調整に使用するために失敗したパケット検査の数をカウントするために使用されます。ネットワーク内の計算は、IP2HC チェック、TCP セッションの監視、正規/スプーフィング IP ヒットを計算するための統計など、ハードウェア Tofino スイッチによって実装されます。提案された方法は、コントロール プレーンが非ネットワーク要素に実装され、IP アドレスのサブセットを処理し、グローバル IP2HC マッピング テーブルを維持し、データ プレーンで必要な更新を実行するため、共同設計アプローチです。ホップ数分布がガウス分布に従うスプーフィングされたトラフィックの場合、提案された方法はスプーフィングされたトラフィックがネットワーク ホストに入るのを防ぎ、約 200 Mbps の帯域幅を節約できます。

4. 一般的な DDoS 攻撃の軽減

[104]、[105]、[106] は、さまざまな DDoS 攻撃をカバーする攻撃軽減のより一般的な観点を提案しました。[104] は、ネットワークのエッジでプログラマブル スイッチを使用して、トラフィックがネットワーク内のデバイスに入る前に分析しました。スイッチは、コントローラの介入なしでトラフィック分析を実行できます。過剰な SYN リクエストとサーバー接続の消費を捕捉するために、スイッチはいくつかの機能と統計を実装します: (i) 入力 SYN パケットに対して一種のシグネチャ マッチングを実行する; (ii) ブルーム フィルタを使用してシグネチャ カウントを計算する;(iii) パケットの数事前定義された時間枠ごとの SYN リクエスト数、(iv) TCP 接続の到着時間、(v) 既存のセッションを閉じることなく時間枠内で確立される連続セッションの最大数。スイッチ データ プレーンが上記のデータを収集すると、コントローラはそれらのデータを収集してトラフィック分散式を定式化し、しきい値を計算します。しきい値はスイッチごとに送信され、スイッチは統計を比較し、攻撃を検出し、悪意のあるトラフィックをドロップします。ネットワーク内の計算には、統計計算 (署名、SYN リクエスト、TCP 接続、セッション確立に関する)、攻撃検出、悪意のあるトラフィックのドロップが含まれ、すべて BMv2 によって実装されます。提案された方法は、コントローラがトラフィック分布を推定し、攻撃検出のしきい値を計算するための共同設計アプローチです。DDoS およびボリューム攻撃の場合、提案された方法を使用した場合、無視できる遅延を経験するクライアントは最大でも 3.5% のみです。さらに、SYN フラッド攻撃の場合、検出遅延は 0.25 秒未満です。

DDoS 攻撃を軽減するための別の一般的なアプローチが [105] で提案されています。NetCor [114] 言語に基づいて、3 つのクラスの防御プリミティブが定義されています: (i) ネットワーク トラフィックに関する統計を収集するモニター、(ii) 特定の種類のパケットに対して行われる防御決定を指定するアクション、(iii)分岐、ディフェンスの制御フローを表現します。各プリミティブ カテゴリは複数のプリミティブで構成されます。たとえば、アクション プリミティブの場合、破棄、パス、パズル、レコードなどを定義できます。次に、スイッチやサーバー上のプリミティブに必要なリソースの量を決定します。提案手法は解析結果に基づいて、プリミティブに必要なステップをサーバとスイッチ間で分割し、スイッチ内のマッチアクションテーブルやレジスタなどのリソースを使用するかを決定します。

次のステップとして、防御戦略のグラフ構造を構築します。ここで、ノードは防御プリミティブであり、エッジはトラフィックの流れを表します。リソース使用量分析に基づいて、プリミティブ実行をスイッチにマッピングするフェーズ。SRAM と ALU の制約を考慮して、マッピング問題は整数線形計画法最適化として定式化され、スイッチで実行される計算を最大化します。著者らは、提案された方法が実行時に動的攻撃をどのように処理するかについても説明します。ネットワーク内コンピューティング、つまりパケット統計の収集と防御操作は、Barefoot Tofino に実装されています。提案された方法は、スイッチとサーバーを使用して必要なプリミティブを実装するための共同設計アプローチです。SYN フラッド、DNS 増幅、HTTP および UDP フラッド攻撃の評価では、正規のトラフィックのスループットを迅速に回復でき、攻撃 UDP パケットをフィルタリングすることで約 20 Gbps の帯域幅を回復できることが示されています。ミドルボックスや NFV システムでは数十マイクロ秒を必要とするのに比べ、パケットは数百ナノ秒で処理できます。

[104]、[105] と比較して、Liu ら [106] は、16 種類のボリューム DDoS 攻撃をカバーするより広範な検出方法を提案しました。さらに、[104]、[105] の研究とは異なり、[106] の緩和モジュールは、ハードウェア リソースの制約を最適化するためにオンデマンドでスイッチによって適用されます。ボリューム攻撃では、攻撃者は大量のトラフィックまたはリクエスト パケットを送信して、被害者の帯域幅またはリソースを使い果たします。検出ロジックはすべての攻撃を識別し、緩和モジュールはオンデマンドでインストールされてハードウェア リソースの使用を最適化します。提案された手法は一般的なスケッチに基づいて機能するため、単一のアルゴリズムで広範囲の指標を追跡することが可能になります。著者らは、軽減を達成するための 3 つのコンポーネントを検討しています。(i) パケットのフィルタリング、(ii) 悪意のあるトラフィックを識別するための分析、および (iii) フィルタリングの更新です。各コンポーネントについて、スイッチ最適化ロジックを使用して緩和機能のライブラリが設計されました。攻撃態勢が変化すると、最適に近いヒューリスティックを使用して新しいリソース割り当てが計算され、最小限のコストでトラフィックを他の利用可能なスイッチにリダイレクトします。ネットワーク内コンピューティングは、Barefoot Tofino に実装された一般的なスケッチベースの攻撃検出および軽減技術です。提案手法は 380 Gbps のスループットを維持しながら攻撃を軽減できます。

5. DDoS 攻撃を軽減する具体的なケース

重复地址检测在IPv6地址配置中非常重要，因此同一子网中的所有节点都能够使用唯一的IPv6地址加入网络并进行通信。在重复地址检测中，节点发送一个或多个邻居请求（NS）消息，并在没有现有节点发送邻居广告（NA）消息时配置地址。在DoS攻击中，将会存在伪造的NA消息，从而无法配置IPv6地址。现有的解决方案要么需要修改协议，要么依赖于容易出现单点故障的中央控制器。为了克服这些问题，Kuang等人提出了一种在网络内安全地进行重复地址检测的方法。所提出的方法利用可编程交换机过滤伪造的NA消息，而无需中央控制节点或修改重复地址检测协议。通过网络内计算，即过滤伪造的NA消息，BMv2实现了这种方法。评估结果表明，所提出的方法可以成功地防止重复地址检测的DoS攻击，且开销可以忽略不计。通过网络内处理，NS/NA消息处理的延迟已降低了高达40％。

Dimolianis等人[112]假设为大学和数据中心提供DDoS保护服务的使用情况。在所提出的缓解方法中，P4设备从子网的流量监视中提取一些特征。根据这些特征，进行异常检测并向缓解系统提供适当的警报。定义了三个特征，并提倡基于阈值的异常检测：（i）每个时期总入流量的数量和分散性，采用移动平均方法计算；（ii）子网重要性，计算为特定子网在时期内的入流量百分比；（iii）数据包对称性，定义为在时期内对于一个子网的入站数据包与出站数据包的比例。该特征用于避免将一个接收大量良性流量的子网错误地检测为受害者。以上三个特征通过阈值进行比较以确定攻击检测。在实现中，利用P4寄存器实现所需的计数器、数组和概率数据结构。此外，所述特征的分析包括在网络元素管道中。在网络内计算方面，即流量特征分析和攻击检测是在Netronome Agilio CX SmartNIC（吞吐量1-2 Mbps）中实现的。

B. 防火墙

已经进行了一些研究，以提出网络内防火墙解决方案。Vörös和Kiss [115] 提供了一个第三层防火墙解决方案，Datta等人 [116] 给出了一个第三层和第四层防火墙解决方案。Vörös和Kiss [115] 在可编程路由器中实现了一个第三层防火墙。在所提出的方法中，违反安全规则或产生过多数据包速率的MAC地址和IP地址被添加到一个名为Ban List的列表中。路由器中的计数器用于测量度量标准以定义Ban List，例如每个主机生成的数据包速率，建立连接的尝试次数等。所提出的方法通过实现IPv6和UDP头将已定义的头扩展到路由器中，即以太网和IPv4头。在解析TCP/UDP数据包后，将研究数据包的字段是否在Ban List中。与Ban List匹配的数据包将被丢弃。在网络内计算方面，即第三层防火墙策略是在P4路由器中实现的。

Datta等人 [116] 提出了一个可配置的第三层和第四层防火墙，该防火墙开发成为软件交换机。作者引入了一个控制器，以实现防火墙的集中管理。高级安全策略作为输入提供给控制器，相应地控制器将安全规则发送到交换机。安全规则是基于P4数据平面中的转发表实现的。此外，控制器通过远程过程调用通道与交换机通信，以激活或停用防火墙。在网络内计算方面，即第三层和第四层防火墙策略是通过BMv2实现的。所提出的方法是一种协同设计方法，因为控制器向交换机注入安全规则，并对防火墙策略进行集中控制。

C. 其他安全应用程序

除了DDoS或防火墙之外，已经进行了许多研究，涉及网络内安全应用。在[117]中提出了基于随机森林的网络内攻击缓解方法。[62]提出了一种基于区块链的网络内攻击检测方法。[118]，[119]的研究侧重于IP地址的隐私威胁。[120]考虑针对窃听的网络免疫性。[121]研究了网络隐蔽通道的缓解。Laraba等人[122]侧重于减轻明示拥塞通知（ECN）协议的滥用。[63]，[64]关注Bring Your Own Device环境的安全性。

[117] では、ネットワーク内の攻撃を検出するために、ランダム フォレスト アルゴリズムがプログラム可能なスイッチに組み込まれました。提案されたアプローチでは、攻撃がいつ発生したかを判断するためにデータを中央の場所に送信するのではなく、ネットワーク内でコンピューティングすることを推奨しています。スイッチのメモリ制約を考慮して、UNSW-NB15 データセット [123] を分析して、重要な機能のセットを選択し、スイッチに実装するデシジョン ツリーの数を選択します。デシジョン ツリーとデシジョン ロジックのレベルは、一致操作フェーズで実装されます。比較しきい値などの動作パラメータは、コントロール プレーンによって設定されます。著者らは、学習プロセス中に使用されるビットレートや TCP ラウンドトリップ時間などの特定の機能を推定するためのメカニズムも提供します。最後に、スイッチで使用されるランダム フォレスト アルゴリズムに埋め込まれた複数のツリーを拡張しました。ネットワーク内計算、つまりランダム フォレストは BMv2 で実装されます。提案された手法は攻撃の 94% 以上を検出します。

Yazdinejad et al. [62] は、ソフトウェア定義ネットワークにおける攻撃検出のためのブロックチェーンベースのアプローチを提案しました。ブロックチェーンをサポートするために、スイッチ内でのパケット解析のアーキテクチャが定義されており、ブロックチェーンのヘッダー フィールドを抽出できます。SDN コントローラによって記述された関数を使用して、スイッチに到着するパケットのパターンを調査し、攻撃を検出します。攻撃が検出された場合、SDN コントロール プレーンで検証のためにトランザクションが実行されます。SDN コントローラはトランザクションの正当性をチェックし、検証結果をスイッチに返します。ネットワーク内コンピューティング、つまり攻撃検出は、ZedBoard Zynq FPGA を通じて実装されます。提案された方法は、検証ステップが SDN コントローラーによって実行されるため、共同設計アプローチです。その結果、DoS やプロービングなどのさまざまな攻撃の検出率は 70% 以上であることがわかりました。

IP アドレスに基づくインターネット トラフィックはプライバシーの脅威をもたらし、通信ユーザーやデバイスに関する情報が IP アドレスを通じて漏洩する可能性があります。送信者と受信者の IP アドレスをマスクする既存の方法では、クライアント側にソフトウェア (Tor ブラウザなど) をインストールするか、ネットワーク ハードウェアに何らかの変更を加えます。これらの問題を克服するために、Datta et al. [118] はネットワーク内監視メカニズムを提案しました。提案手法では、パケットが中間自律システムに入る前にパケットヘッダ内の IP アドレスを暗号化し、パケットが中間自律システムから出るときに送信元 IP アドレスと宛先 IP アドレスを復号化します。提案された方法は、攻撃者がどのパケットが同じ TCP フローに属しているかを特定できないようにするために、TCP シーケンスと確認応答番号も暗号化します。ネットワーク内のコンピューティングは、IP アドレスの暗号化と復号化です。

[118] と同様に、Chang ら [119] は、IP アドレスに対する暗号化ベースの防御メカニズムを提案しました。提案された方法は、送信側/受信側スイッチが信頼されているが、パスの途中にあるスイッチは悪意がある可能性があることを前提としています。送信側ボーダー スイッチは、アドレスに対して暗号化ベースの変換を実行し、対応するデータ ヘッダーを構築します。他の信頼できないスイッチは、SDN コントローラーによって送信されたフロー テーブルに従って、データ パケットを受信スイッチに転送します。受信スイッチでは、パケット ヘッダーのネゴシエーション パラメータを解凍し、アドレス フィールドを復号化して、通常の IP パケットをターゲット ホストに送信します。ネットワーク内コンピューティング、つまり IP アドレスの暗号化と復号化は、P4 言語を使用した BMv2 を通じて実装されます。提案された方法を使用すると、パケット転送の往復時間は 8 ミリ秒未満になります。

Liu ら [120] は、プログラム可能なデータ プレーンを使用してネットワークの盗聴に対する耐性を向上させる方法を提案しました。提案された手法は 3 つの防御線で構成されます。最初の行は転送ポリシーで、トラフィック パケットはさまざまなネットワーク パスおよびプロトコル (IPv4、IPv6 など) を通じて順不同で転送されます。2 番目の回線は干渉を引き起こすため、盗聴者がトラフィックを適切に分類することができなくなります。これは、ストリームのトラフィック パケットが複数のストリームに分散されるトランスポート暗号化アルゴリズムに基づいて機能します。3 番目の防御線では、暗号化ベースの対策を使用してパケット ペイロードが暗号化されます。イントラネットワーク コンピューティングでは、つまり、上記の防御ラインは P4 を使用して BMv2 に実装されます。実験結果は、提案された方法が盗聴を困難にし、ベースライン方法と比較して送信スループットを 32% 増加できることを示しています。

Xing et al. [121] は、クラウド システムにおけるネットワーク秘密チャネルの脅威に対する軽減アルゴリズムを提案しました。彼らは、タイム チャネルとメモリ チャネルと呼ばれる 2 つのクラスのネットワーク秘密チャネルの脅威に焦点を当てています。前者の例として、攻撃者はパケット間の遅延を利用して秘密メッセージ内の 1 または 0 をエンコードする可能性があります。後者の例として、攻撃者は TCP シーケンス番号または ACK フィールドに秘密データを埋め込む可能性があります。著者らは、高速パス防御としてできるだけ多くのプリミティブをデータ プレーンに移し、強力な汎用 CPU と RAM を備えたスイッチ コントロール プレーン上で低速パス防御を実行します。

高速パスは 3 つのコンポーネントで構成されます: (i) TCP 監視を実行し、それらをキー値として保存する接続監視、(ii) 受信パケットのタイムスタンプと同じパケットからのタイムスタンプの比較に基づくパケット間遅延の特性評価フロー：パケット間の遅延分布を近似するためのパケットの最後に確認されたタイムスタンプ、(iii) 攻撃から防御するためにパケット内の特定のデータを操作する一連の防御手法を採用するメモリ チャネル防御。スロー パス ディフェンスには、チャネル防御用の 3 つのモジュールもあります: (i) 選択した接続のパケット間遅延間隔をクエリし、時間チャネル検出のための統計テストを実行する統計パケット間遅延テスト、(ii) 時間チャネル防御、不審な接続のパケットにランダムな遅延を挿入して時間変調を破る、(iii) パフォーマンス エンハンサー。TCP 接続のパフォーマンスを向上させ、防御によるパフォーマンス低下のコストを削減します。ネットワーク内計算、つまり高速パス コンポーネントは Tofino に実装されます。特定のチャネル防御モジュール、つまり低速パスが汎用 CPU に実装されているため、提案された緩和アルゴリズムは共同設計アプローチです。実験では、タイム チャネル設定ではサーバーがクライアントにファイルを送信し、ストレージ チャネル設定ではクライアントがサーバーにファイルをアップロードします。提案手法はサーバ防御に適している。提案された方法は、蓄積型攻撃に対して 33 秒のデータ転送時間を達成します (防御なしの場合に比べて 0.3% の増加)。時間チャネルの場合、提案された防御方法には 60 秒かかります (防御なしの場合より 3% 増加します)。

ECN は、IP 層と TCP 層の間に位置するプロトコルで、スイッチ キューの占有率に基づいて輻輳の可能性を示すためにネットワーク スイッチによって使用されます。悪意のある TCP エンドポイントは ECN ビットを操作して、ネットワークに輻輳が存在しないように送信者に錯覚させる可能性があります。Laraba ら [122] は、TCP を変更せずにネットワーク全体で機能するネットワーク内 ECN 悪用軽減メカニズムを提案しています。まず、プロトコル仕様が拡張有限状態マシン (EFSM) に変換され、それに応じて不正な動作状態にも拡張されます。次に、EFSM は P4 用に書かれたプログラムを変換し、コンパイルされたバージョンが PISA ターゲット スイッチにインストールされます。最後に、EFSM に基づいて各接続の状態が追跡され、不正な動作としてマークされた状態に入ると、パケットのドロップ、パケットの再ルーティング、アラートの生成、修正アクションの適用など、事前定義されたアクションが手順に従ってトリガーされます。BMv2 で実装された、EFSM に基づくフローの追跡、ECN 攻撃の検出と軽減を含むネットワーク内コンピューティング。評価の結果、提案されたセキュリティ方法は、悪意のある TCP エンドポイントによって引き起こされるスループット損失の 25% を回復できることが示されています。

企業が従業員に私用のタブレット、携帯電話、ラップトップを職場で使用することを許可する BYOD 環境では、セキュリティが課題となります。サーバー側に実装されたセキュリティ手法は、クライアント側のコンテキスト情報にアクセスできず、処理速度もそれほど速くないため、あまり効果的ではない可能性があります。[63]、[64] の研究では、ネットワーク内のコンテキスト認識ベースのセキュリティ ソリューションを提案しています。著者らは、セキュリティ ポリシーを記述するために Pyretic Net-Core [114] に基づく新しい言語を提案しています。これらのポリシーの例としては、営業時間中の特定のサービスのブロック、距離ベースのアクセス制御、管理者がオンラインの場合のアクセスの許可などが挙げられます。デバイス コンテキスト情報を収集し、それをネットワーク トラフィックに埋め込む役割を担うモジュールをクライアント側にインストールします。コンパイラはポリシー プログラムを入力として受け取り、次の 2 つの出力を生成します: (i) クライアント モジュールが収集してパケットに埋め込む必要がある情報を記述したネットワーク要素の構成ファイル、(ii) P4 で記述されたスイッチ プログラム。セキュリティポリシーを強制します。最後に、ランタイム モジュールが SDN コントローラに実装され、スイッチ上で P4 プログラムを構成し、ネットワーク要素と通信してコンテキストに応じた構成を展開します。この集中制御は、パケット処理の決定がスイッチ上で直接行われる一方で、通常は頻度が低いポリシーの展開または変更にのみ使用されます。ネットワーク内コンピューティング、つまりセキュリティ ポリシーは、BMv2 と Wedge 100BF Tofino に実装されています。クライアント/サーバー ベースの通信シナリオでは、提案された方法は、単一のセキュリティ コンテキストに対して 120 万のチェックを実行できます。

D. 要約、比較、洞察、および教訓

このセクションでは、まずネットワーク内セキュリティの文脈で行われた研究を簡単に要約し、次にその洞察と学んだ教訓について説明します。

表VIII は、ネットワーク内の DDOS 攻撃の軽減策の比較です。

表IX: ネットワーク内ファイアウォールと他のセキュリティ アプリケーションの比較

表X: ネットワーク全体に実装されたセキュリティ スキーム、サーバー/コントローラー ベースのセキュリティ スキーム、および協調設計スキームの比較

1. 概要

このセクションでは、サイバーセキュリティの文脈における研究の概要を説明します。DDoS 攻撃を軽減するには、トラフィックをクラウド内のスクラビング サーバーにリダイレクトする必要があり、その結果、待ち時間と運用コストが高くなります。ネットワーク内の DDoS 攻撃を検出して軽減するために必要な機能の一部またはすべてをオフロードすると、遅延と運用コストが削減されます。ネットワーク内の DDoS 軽減方法がいくつか提案されています。SYN、TCP、リンク フラッドを含むネットワーク内フラッド攻撃の軽減については、[60]、[61]、[98]、[99]、[100]、[101]、[102] で研究されています。通常、フラッド攻撃では、Cookie 計算、ホワイトリスト推定、SYN/ACK パケットに関する統計、TCP/UDP パケットに関する統計、IP アドレスのエントロピー分析などの一部の検出プリミティブが Web 要素に対してオフラインで処理されます。さらに、パケットのドロップ、疑わしいフローのリダイレクトなどの緩和プリミティブは、攻撃が検出された後にネットワーク要素によって実行されるアクションです。AR-DDoS 攻撃の軽減については [103] で検討されています。トラフィックソースのセキュリティを考慮して、[107] の研究ではソースアドレス検証のためにタグ生成をプログラマブルルータにオフロードする一方、[108]、[109]、[110] の研究では、ネットワーク要素にホップカウントフィルタリングを実装して偽造をフィルタリングすることによって研究を行っています。渋滞。複数のタイプの DDoS 攻撃を含む攻撃軽減のより一般的な観点は、[104]、[105]、[106] で提案されています。これらの研究では、ネットワーク トラフィックと接続に関する統計を収集し、攻撃 (しきい値ベースの方法の適用など) または防御メカニズム (特定の制御プロセスに従って他のアクションをドロップまたは実行するなど) の発生に関する決定をネットワーク要素にオフロードします。[111] の重複アドレス検出や [112] の大学向け DDoS 保護サービスなど、他の特定のネットワーク内 DDoS 攻撃軽減シナリオも研究されています。

ネットワーク内には、レイヤー 3 に [115]、レイヤー 3 および 4 に [116] など、いくつかのファイアウォール ソリューションがあります。通常、悪意のあるパケットは、TCAM に実装されたルール定義メカニズムを通じて、または禁止リストとの照合を通じて、ネットワーク要素内で検出されます。悪意があると識別された場合、パケットはドロップされます。DDoS やファイアウォールに加えて、ネットワーク内のセキュリティに関する調査がいくつか実施されています。

这些包括基于随机森林的攻击缓解[117]，基于区块链的攻击检测[62]，为IP地址减少隐私威胁[118]，[119]，对窃听进行网络免疫[120]，缓解网络隐蔽通道威胁[121]，缓解ECN协议滥用[122]，以及Bring Your Own Device环境的安全性[63]，[64]。在这些研究中，根据应用程序，执行检测原语（例如决策树，TCP连接统计计算，安全策略）以及缓解原语（例如对一部分数据包进行加密/解密，数据包丢弃）的网络元素被执行。

2. 比较、见解和经验教训

表VIII和IX从贡献、方法论（网络内计算、共同设计准则、方法中使用的网络元素的数据结构）和评估（网络元素、仿真平台、主要结果）等方面比较了被审查的研究。可以看出，这些研究要么完全在网络中实现安全机制（在共同设计条目中为“N”的研究），要么采用共同设计方法（在共同设计条目中为“Y”的研究），其中网络元素与服务器或控制器结合使用，提供所需的安全机制。

表X比较了完全在网络中的安全方案、基于服务器/控制器的安全方案（在许多研究中作为比较基准，例如[61]、[99]、[100]、[105]）以及共同设计方案，从系统状态建模、检测模型、攻击检测精度、缓解延迟和带宽消耗等方面进行比较。

• 建模系统状态：完全在网络中的安全方法处理和分析到达网络元素的流量，因此具有系统的局部视图。相比之下，在基于服务器/控制器的方案中，从网络的各个节点生成的流量以集中的方式进行分析，因此具有全局视图的能力。类似地，共同设计方案可以利用通用计算来模拟具有全局视图的系统。

• 検出モデル: ネットワーク要素に検出モデルを実装するにはハードウェア制限があります (例: ステージ/パイプライン/LU の数の制限、一致アクション エントリの数の制限、レジスタ、FPGA の論理セル間の特定の通信など)。したがって、サーバー/コントローラーベースのスキームと比較して、より単純なモデルをネットワーク要素に実装できます。対照的に、ディープ ニューラル ネットワークなどの高度な検出モデルは、攻撃を検出するために SDN コントローラーまたはサーバーに実装できます [124]。完全にネットワーク内にあるセキュリティ スキームと比較して、共同設計スキームは汎用コンピューティング ユニットが利用できるため、複雑な攻撃検出モデルを実装するための高い機能を備えています。たとえば、[99] では、TCP/UDP パケットの特徴抽出が P4 スイッチにオフロードされ、SVM およびランダム フォレスト学習モデルが従来のサーバーに実装されて、抽出された特徴を分析し、TCP フラッド攻撃を検出します。これは、[101]、[112]、[117] など、ネットワーク要素に単純なしきい値ベースの検出メカニズムを主に実装する、完全にネットワーク内スキームとは異なります。

• 攻撃検出の精度: サーバー/コントローラー ベースのアプローチは、洗練された正確な検出メカニズムを実装し、グローバル システム モデリングを活用できるため、最高の精度を実現します。より単純な検出モデルと部分的なシステム ビュー機能を備えた完全なネットワーク内セキュリティ ソリューションは、サーバー/コントローラー ベースのソリューションよりも精度が低い可能性があります。共同設計スキームは、完全なネットワーク内セキュリティ スキームよりも正確な複雑な攻撃検出モデルを実現でき、汎用コンピューティングの可能性を活用したグローバル システム モデリングの可能性により、より高い精度を達成できます。たとえば、[99] では、ネットワーク内の特徴キャプチャ手順に加えて、汎用コンピューティングを使用した分類ベースの TCP フラッド攻撃検出モジュール操作も 98% 以上の検出精度を報告しています。

• 軽減遅延: ネットワーク要素がコントローラー/サーバー シナリオで使用される従来のコンピューティング システムよりも高いスループットでパケットを処理できるため、完全にネットワーク内のシナリオでは攻撃軽減遅延を最小限に抑えることができます。さらに、SDN コントローラーにパケットを送信したり、サーバーをスクラブしたりせずに攻撃を検出できるため、時間が節約されます。したがって、SDN コントローラーやスクラビング サーバーの介入なしに、データ プレーンで軽減策をトリガーできます。たとえば、[111] で提案されている方法は、プログラマブル スイッチの重複アドレス検出に対する DoS 攻撃を 40% 低い遅延で軽減できます。コントローラー/クリーン サーバーで処理/決定の一部を実行する共同設計シナリオ ([109]、[110] など) では、コントローラー/クリーン サーバーとネットワーク内のセキュリティ ソリューションの間を制御信号/トラフィックが移動する必要がある場合があります。さらに遅延が発生する可能性があります。

• 帯域幅の消費: セキュリティに対する完全にネットワーク内のアプローチでは、トラフィックをクリーニング サーバーまたは (SDN) コントローラーに送信する必要がないため、コントローラー/サーバー ベースのアプローチと比較して帯域幅が節約されます。たとえば、[107] の送信元アドレス検証アプリケーションの実験結果は、偽造パケットのネットワーク フィルタリングにより最大 200 kbps の帯域幅を節約できることを示しています。共同設計アプローチでは、サーバー/コントローラーとネットワーク要素間の通信オーバーヘッドが増加するため、完全なネットワーク内セキュリティ アプローチよりも多くの帯域幅を消費する可能性があります。[99] では、データ プレーンからの特徴抽出と TCP フラッド検出モジュールへの送信が、ネットワーク要素とサーバー間の通信オーバーヘッドの例として挙げられています。

教訓を引き出すためのさらに多くの洞察を次に示します。

• 攻撃検出の多様性: 私たちの文献調査では、ほとんどの研究が DDoS 攻撃、特にフラッド攻撃に対する安全なソリューションを提供していることがわかりました。ただし、他の多くの攻撃については、あまり研究が行われていません。たとえば、AR-DDoS 攻撃 [103] またはネットワーク秘密チャネルの脅威 [121] を考慮した研究は 1 つだけであり、ファイアウォール ソリューションを提供した研究は 2 つだけでした (つまり、[115]、[116])。ただし、攻撃を検出するためにトラフィックをリモート サーバーに再ルーティングすると、長い遅延と運用コストが発生する幅広い種類の攻撃には、ネットワーク内のセキュリティ アプライアンスで対処できます。得られた教訓は、AR-DDoS 攻撃の軽減、ファイアウォール ソリューション、ネットワークの秘密チャネルの脅威の軽減など、フラッド攻撃以外の攻撃に対するネットワーク内セキュリティ ソリューションを提供するには、さらなる研究努力が必要であるということです。

• 機械学習ベースの攻撃検出：もう 1 つの観点は、ほとんどの研究がネットワーク要素に単純なしきい値ベースの検出メカニズムを実装し、プログラム可能なネットワーク要素で統計を収集し、しきい値と比較して攻撃が発生したかどうかを判断するというものです。しきい値検出の ALU 要件は、処理に制約のある多くのネットワーク要素に実装できるほど単純ですが、より正確な検出メカニズムを適用することで検出精度を向上させることができます。機械学習技術により、より高い精度を実現できます。ただし、攻撃を検出するためにネットワーク内で機械学習を使用したのは [117] だけです。得られた教訓は、機械学習をネットワーク要素に適用してネットワーク内の攻撃を検出するには、さらなる研究努力が必要であるということです。

• セキュリティスキームの共同設計: 別の観点からは、ネットワーク要素がサーバーまたは SDN コントローラとともに使用され、検出および攻撃を軽減します。共同設計アプローチにより、より効率的な攻撃検出が可能になります。プログラム可能なネットワーク要素はトラフィック統計を推定するのに適した候補ですが、各ネットワーク要素はトラフィック分布の部分的なビューしか持たないため、攻撃の発生を検出するために必要なパラメータを効果的に決定できません。たとえば、検出精度を向上させるために、攻撃の検出に必要なパラメータ (しきい値など) をトラフィックのグローバル ビューに基づいてサーバーまたは SDN コントローラーで定義し、トラフィック分析をネットワーク要素で実行できます。私たちが得た教訓は、ネットワーク内のセキュリティの共同設計の分野ではさらなる研究が必要であるということです。

VI. イントラネット連携

分散システムの参加エンティティは、計算やシステム操作を実行するために、特定のデータ値や操作のシーケンスについて合意する必要がある場合があります。このような合意は、コンセンサスプロトコルを実装することで実現できます。しかし、コンセンサスメカニズムは、コンセンサスに達するために複数の参加者間で往復の通信を完了する必要があるため、遅延が大きいという問題があります。コンセンサス アルゴリズムの実装に必要な機能の一部またはすべてをネットワーク要素にオフロードすると、潜在的に遅延が削減されます。コンセンサスプロトコルに加えて、ネットワーク内の計算を活用して調整を加速する他の調整メカニズムも文献に記載されています。このセクションでは、ネットワーク内調整の分野における研究の概要を説明します。図 2、セクション VI は、このセクションの構造を示しています。

A. コンセンサスプロトコル

Paxos コンセンサス プロトコルの参加者は、分散システムに値を提案する提案者、値を選択するアクセプタ、アクセプタによって選択された値を学習する学習者という 3 つの役割を果たすことができます。プロトコルは、提案者が値を提案したときに開始され、学習者が受け入れ者によって選択された値を知ったときに終了します。プロトコル全体は複数の反復で実装でき、各反復でサーバー上に展開できるさまざまなアクター間でメッセージが受け渡されます。

Paxos は 2 つのフェーズに分けることができます。最初のフェーズでは、プロポーザーはラウンドナンバーを選択し、アクセプターのサブセットに準備リクエストを送信します。以前に受信したラウンド番号よりも大きいラウンド番号を持つ準備リクエストを受信した場合、アクセプターはプロミスで応答することで、それより小さいラウンド番号を持つ今後のリクエストを拒否します。ただし、アクセプターがリクエストを受け入れた場合は、受け入れられた値と対応するラウンド数をプロポーザーに返します。第 2 フェーズは、プロポーザがアクセプタのサブセットから応答を受信したときに始まります。

第 2 フェーズでは、提案者が値を選択するプロセスが提供されます。提案者が応答で値を受け取らない場合、新しい値を選択します。一方、最初のフェーズでいくつかの値が受信された場合、提案者は最も高いラウンド番号を持つ値を選択します。選択されると、提案者は、選択された値と関連するラウンド番号を含む承認リクエストを同じセクションの承認者に送信します。したがって、アクセプターは、より高いラウンド番号を持つ別のリクエストを既に承認していない限り、受信を承認し、承認された値を学習者に送信します。アクセプターの一部が値を受け入れると、コンセンサスが発生します。

コンセンサス プロトコルに関与する役割をネットワーク スイッチに実装すると、ネットワーク内のメッセージの送信パスが削減され、コンセンサスに達するまでに必要な遅延が短縮されます。[125]、[126] で、Dang らは、P4 を使用した Paxos プロトコルの第 2 フェーズのネットワーク内計算を提案しました。[127] では、著者らはネットワーク内の 2 つのステージからなる完全な Paxos 実装について説明しています。ネットワーク内コンピューティングは、Tofino および NetFPGA SUME に実装されています。[125]、[126] では、コンセンサス プロトコルの一部をネットワークにオフロードすることは共同設計アプローチに属しますが、[127] ではネットワーク内でコンセンサス プロトコルを完全に実装することは共同設計アプローチに属しません。これらは、データセンターのホストベースのコンセンサスと比較して、レイテンシーで少なくとも 3 倍の改善、スループットで 4 桁の大幅な改善を達成できる Paxos のオープンソース実装を提供します。

[128] では、著者らはデータセンターベースの Ordered Unreliable Multicast (OUM) 通信を定義し、そこから NOPaxos をレプリケーション プロトコルとして定義しました。著者は、トップ スイッチとアグリゲーション スイッチ間のツリー構造を想定しています。アグリゲーション スイッチより上の上位レベルの通信は、コア スイッチによって提供されます。OUM 通信では、クライアントは受信者のグループにメッセージを送信します。メッセージの配信は保証されませんが、受信されたメッセージの順序は保証されます。この目標を達成するには、特定の OUM グループ宛てのすべてのパケットが単一のシーケンサーを介して送信され、宛先にルーティングされる前に各パケットにシーケンス番号が挿入されます。SDN コントローラーは、メッセージをシーケンサーとグループ メンバーにルーティングするための転送ルールを編成します。著者らは、シーケンサの 3 つの可能な実装、つまりプログラマブル ネットワーク スイッチ、ネットワーク プロセッサ、およびエンドポイント ホストについて説明します。フォールト トレランスのため、シーケンサーに障害が発生した場合、または OUM グループ メンバーから切断された場合、コントローラーは新しいシーケンサーを選択して構成します。OMU 通信に基づいて、著者はリーダー調整に基づくレプリケーション プロトコルである NOPaxos を提案します。シーケンスは複製プロトコルの一部ですが、提案された方法は共同設計アプローチです。シーケンサーのネットワーク内計算、つまりシーケンサーは Cavium Octeon II CN68XX ネットワーク プロセッサ上に実装されています。評価結果は、レイテンシーが 200 マイクロ秒未満であり、スループットが 50 Kops/s 以上であることを示しています。

B. その他の連携アプリケーション

コンセンサスプロトコルに加えて、他のネットワーク内調整アプリケーションも文献に存在します。[134] では、ロック管理システムが提案されています。[135] では、トランザクション処理システム向けにマルチキャスト通信に基づく調整メカニズムが検討されています。[136] では、データセンターの一貫性を維持するために、ネットワーク内のコンセンサスベースの調整メカニズムが提案されています。

[134] では、Yu らはネットワーク内計算を使用したロック管理システムを提案しました。クライアントのリクエストはロック システムに送信され、スイッチとサーバーの連携を通じてリクエストが処理されます。具体的には、ロックの管理はロック サーバー間で分散されます。各リクエストのターゲット IP は、ディレクトリ サービスから情報を取得することによって、目的のロックを担当するサーバーの IP に設定されます。リクエストがスイッチに到着したとき、スイッチがリクエストされたロック オブジェクト情報を保持しており、ロックが使用可能な場合、スイッチはリクエストに対するロックを許可します。ただし、ロックが利用できない場合でも、十分なメモリが利用可能であれば、リクエストはキューに挿入されます。スイッチがロック オブジェクト情報を保持していない場合、またはメモリが不十分な場合、リクエストはターゲット IP によって定義されたロック サーバーに転送されます。著者らは、ラウンドトリップ時間を短縮するために、同じラウンドでロックとデータを取得する可能性についても説明しています。実装の観点から見ると、レジスタ配列はロック要求をキューに入れるために使用され、ロック サービス用の特定の UDP ポートを定義します。ロック リクエストには、アクション タイプ (ロックの取得/解放)、ロック ID、トランザクション ID、クライアント IP などの複数のフィールドが含まれます。さらに、関連するレジスタ配列へのロック ID のマッピング、およびロックの付与と解放の操作は、一致アクション テーブルを通じて実装されます。最後に、著者らはスイッチにロックを割り当てる問題を分数ナップザック問題と同様の最適化問題として定式化し、多項式時間で解きました。Barefoot Tofino では、ネットワーク内コンピューティング、つまりロック管理が実装されています。提案された方法は、スイッチのメモリ制約により、ロック サーバーがスイッチと共同でロックを処理するため、共同設計アプローチです。提案された方法は、ベースライン方式と比較して、スループットを 18 倍向上させ、遅延を 20 倍削減します。

[135] では、Li らは、クライアントがシャードで構成される分散ストレージ システムを通じてトランザクションを実行するトランザクション処理システムを検討しました。著者らは、ネットワーク内の計算を利用してトランザクションを調整し、パフォーマンスを向上させます。IP および UDP ヘッダーを操作することにより、提案されたプロトコルはマルチキャスト通信を導入し、メッセージは順序を保証して複数のマルチキャスト グループに送信されます。マルチキャスト通信は集中型シーケンサーを使用して実装されており、障害が発生した場合は SDN コントローラーで置き換えることができます。シーケンサ自体は、スイッチ デバイス、ネットワーク ミドルウェア、エンド ホストなど、さまざまな方法で実装できますが、著者らはシーケンサをスイッチに実装することで最高のパフォーマンスを達成できると考えています。プロトコル全体は 3 つの層に分かれています: (i) ネットワーク内同時実行制御層はシャード内およびシャード間で動作し、一貫したトランザクション順序を提供しますが、メッセージ配信の信頼性は保証しません; (ii) 独立したトランザクション層操作の信頼性と原子性を担当する層、(iii) 独立した要素を使用してトランザクションを構築することでトランザクションの分離を提供する一般トランザクション層。ネットワーク内の通信、つまりシーケンサーは、P4 言語を通じて Cavium Octeon CN6880 ネットワーク プロセッサに実装されています。必要な機能の一部がネットワークに実装されるため、このアプローチは共同設計となります。評価結果では、従来の設計と比較して、標準ベンチマークで最大 35 倍高いスループットと最大 80% 低いレイテンシが達成されました。

C. 要約、比較、洞察、および教訓

このセクションでは、まずネットワーク内調整のコンテキストで行われた研究を簡単に要約し、次にその洞察と得られた教訓について説明します。

表XI: ネットワーク内調整研究の比較

1. 概要

このセクションでは、ネットワーク調整の観点から実施された研究の概要を説明します。さまざまなコンセンサスプロトコルが文献で提案されています。これらのプロトコルにより、参加者はコンセンサスを達成することができます。つまり、システムの動作に必要な特定のデータ値または一連の動作について合意することができます。コンセンサス アルゴリズムの実装に必要な機能の一部またはすべてをネットワークにオフロードすると、コンセンサス レイテンシを短縮できます。この研究分野では、Paxos プロトコルの第 2 フェーズ [125]、[126] がネットワーク要素に実装されており、プロトコルの完全な実装は [127] で提案されています。[128] で提案されている順序付けされた信頼性の低いマルチキャスト通信では、シーケンス モジュールはプログラマブル ネットワーク スイッチを使用して実装され、パケットを宛先に転送する前に各パケットにシーケンス番号を追加する機能があります。Raft コンセンサス プロトコルの一部は [129] でプログラマブル スイッチに転送され、[130] で修正されました。分散型 SDN における永続性と正しい動作のための提案されたプロトコルでは、ビザンチン フォールト トレランスがプログラマブル スイッチにオフロードされています [131]、[132]、[133]。

文献には、調整を加速するためにネットワーク コンピューティングを利用する調整メカニズムが他にもあります。ロック管理システムは [134] で紹介されています。マルチキャスト通信に基づく調整メカニズムは、プログラマブル スイッチでシーケンスを実行するトランザクション処理システム用に [135] で提案されています。最後に、[136] では、放送用のネットワーク コンピューティングを使用した、データ センターの一貫性のための調整メカニズムが提案されています。

2. 比較、洞察、得られた教訓

表 XI は、貢献、方法論 (ネットワーク コンピューティング、共通の設計基準)、および評価 (ネットワーク要素、シミュレーション プラットフォーム、主な結果) の観点からレビューされた研究を比較しています。全体的な洞察は、ほとんどのネットワーク コンセンサス調査では、提案されたプロトコルの機能の一部がデータ プレーンにオフロードされているということです。[127] に示されているように、データ プレーンにコンセンサス プロトコルを完全に実装すると、部分的な転送シナリオよりも効率が高くなる可能性があります。私たちが学んだ教訓は、データ プレーンに完全に実装されたコンセンサス プロトコルを提供するには、さらなる研究努力が必要であるということです。

もう 1 つの洞察は、コンセンサス以外の調整メカニズムを提案している研究は [134]、[135]、[136] の 3 つだけであるということです。私たちが学んだ教訓は、ネットワーク コンピューティングを活用して、コンセンサス プロトコルを超えたネットワークと分散システムの調整ソリューションを提供するには、さらなる研究努力が必要であるということです。

VII. テクノロジー固有のネットワーク コンピューティング アプリケーション

このセクションでは、クラウド コンピューティング、エッジ コンピューティング、4G/5G/6G、およびネットワーク機能仮想化における特定のテクノロジを使用したネットワーク コンピューティング アプリケーションについて学びます。図 2 セクション VII は、このセクションの構造を示しています。

A. ク​​ラウドコンピューティング

このセクションでは、データセンターでの負荷分散やリソース割り当てのソリューションを提供するクラウド コンピューティングを調査範囲としています。

1. 負荷分散

仮想 IP アドレス (VIP) サービスのパケットは、サーバー プール (DIP プール) にマッピングできます。ネットワーク コンピューティングにより、ソフトウェア ベースのロード バランサーの必要性がなくなるため、ロード バランシングに使用されるサーバーの高コストと、ソフトウェア実装における高い遅延とジッターが削減されます。Miao et al. [137] は、ネットワーク コンピューティングを利用して、スイッチに 2 つのテーブル (connTable および VIPTable と呼ばれる) を実装することにより、データ センターにロード バランサを提供しました。VIPTable は、VIP にマッピングできる DIP のプールを定義します。一方、connTable は各 TCP 接続を DIP にマップします。つまり、接続パケットは関連する DIP を通過して、必要なサービスを受け取ります。2 つの主な課題が考慮されます。 (i) 限られた SRAM に多数の接続を保存するには、実際の接続キーの代わりに接続キーのハッシュ ダイジェストを保存します。さらに、実際の DIP の代わりに DIP プールのバージョンが保存されます; (ii) 著者らは、接続の存続期間中にサーバーを追加または削除することによって DIP プールが更新される可能性がある現象について説明しています。彼らは、接続ごとの一貫性を、特定の接続のすべてのパケットが接続の存続期間中同じ DIP に関連付けられるという要件として定義します。ブルーム フィルターを使用して接続の到着を追跡し、それに応じて接続に対して一貫した DIP マッピング メカニズムを実装します。ネットワーク コンピューティング、つまり負荷分散は P4 スイッチに実装されています。提案された方法は、ライン レートで 1,000 万の接続の負荷を分散できます。

Ye ら [138] は、データセンター向けのマルチパス負荷分散アプローチを提案しました。彼らは、P4 スイッチ間のツリー状の接続構造 (おそらく複数のルート) を考慮しており、各スイッチにはリーフ スイッチへのすべてのパスの使用率を維持するためのテーブルがあります。提案された方法では、各スイッチはそのポートのリンク帯域幅を知っているため、使用率は転送速度と帯域幅の比率として推定できます。提案手法によれば、トラフィックはフローレットの粒度で処理される。パケットがスイッチに到着すると、現在のタイムスタンプと以前のタイムスタンプを比較することによって到着間隔が計算されます。しきい値より大きい場合、パケットは新しいフローレットとみなされます。次に、重み付けされた使用率テーブルを使用して、フローレットの新しいパスが選択されます。フローレットの検出、パス使用率の推定、およびパケット ルーティングのためのネットワーク計算は、BMv2 に実装されています。クライアント/サーバー ベースのリクエストおよびリーフ/スパイン/コア トポロジの場合、提案された方法によりフローの完了時間が 2% 短縮されます。

[139] は、データセンターにおける遅延に敏感なリモート プロシージャ コール (RPC) 呼び出しのためのトランスポート プロトコルを提案しました。提案されたプロトコルは、リクエスト間で状態を保存しないリクエスト/レスポンス指向のプロトコルであり、一部のパラメーター (送信元 IP アドレス、UDP ポート、RPC シーケンス番号など) は、リクエストを識別するためにクライアントによって開始されます。リクエストの宛先はリクエストを処理するサーバーから切り離されるため、ピアツーピア RPC 通信のセマンティクスが緩和されます。ルーターは、負荷分散ポリシーに基づいて適切な宛先サーバーを識別し、そこにメッセージを配信します。ルーター処理のボトルネックを軽減するために、ルーターはリクエストの最初のパケットのみを決定し、残りのパケットは同じサーバーに送信されます。サーバーは、負荷分散を決定するために、アイドル状態および使用可能な状態のフィードバック メッセージをルーターに送信します。著者は、ランダム、ラウンド ロビン、JSQ、結合境界最短キュー (JBSQ) の負荷分散戦略をソフトウェア ルーターに実装していますが、Tofino データ プレーンには JBSQ のほうが簡単であるため、JBSQ のみを実装しています。ベースライン方法と比較して、16 台のワーカー マシンのクラスターでの Web インデックス検索の遅延は 5.7 倍改善されました。ベースライン方法と比較して、マスター/スレーブ レプリケーションを備えた 4 ノード クラスターでは、キー/値ストア リクエストのスループットが 4.8 倍以上向上しました。

与[137]、[138]、[139]强调在网络元件中完全实现负载均衡不同，Gandhi等人[140]利用网络计算和软件实现的组合来为数据中心提供更灵活的负载均衡。基于软件的负载均衡器有两个限制：处理数据包的容量限制和高可变延迟。为了应对这些限制，作者利用数据中心中已经存在的可编程交换机来部署可伸缩、高性能的负载均衡器。他们利用交换机中未使用的ECMP和隧道表项来执行流量分流和数据包封装。实际上，将虚拟IP地址映射到直接IP地址的数据库存储在交换机中以实现负载均衡。由于负载平衡功能，即流量分发和封装在数据平面中管理，因此它可以具有低延迟/成本，同时具有高容量。另一方面，交换机故障的管理具有挑战性，因此与基于软件的负载均衡器相比，将会有一些灵活性上的妥协。为了克服这个限制，作者利用交换机和软件负载均衡器的组合。交通主要由交换机管理，而软件负载均衡器则扮演备份的角色，以增强灵活性。作者还提出了一种贪婪算法，以决定在交换机之间划分映射，以克服交换机内存限制。网络计算，即流量分流和数据包封装，是在基于仿真的交换机中实现的。所提出的方法是一种协同设计方法，因为它利用了软件实现的负载均衡器和可编程交换机的组合来执行负载均衡。结果表明，所提出的方法提供的容量比纯软件负载均衡器高10倍，成本只是软件负载均衡器的一小部分，同时还将延迟降低了10倍或更多。

2.基于INC的云资源分配研究

このタイプの研究は、ネットワーク コンピューティングが強化されたクラウド コンピューティング環境におけるクラウド リソース割り当てソリューションを提供します。トクサシら [27] は、アプリケーションのコンピューティング タスクをデータ センターのサーバーからネットワークに動的にオフロードするオンライン リソース割り当てスキームを提案しました。ネットワークコンピューティングを実行するかどうかを決定するために、ネットワーク制御とホスト制御の 2 種類のコントローラが提案されています。ネットワーク制御では、アプリケーションによって交換されるメッセージの平均数が事前定義されたしきい値から逸脱すると、ワークロードはネットワークによって処理されます。ホスト制御では、アプリケーションの電力消費または CPU 使用率がしきい値を超えると、コントローラーがワークロードをネットワークにオフロードします。ネットワーク コンピューティング、つまりアプリケーションの実行は、NETFPGA と Tofino によって実現されます。提案された方法は、データセンター サーバーとネットワーク要素の組み合わせを利用してアプリケーションにサービスを提供するため、協調設計アプローチです。実験によると、商用 CPU 上のソフトウェア システムの消費電力は、FPGA を使用すると 100 倍、ASIC 実装を使用すると 1000 倍増加する可能性があります。

Blöcher et al. [28] は、データセンターサーバーとネットワークリソースのコンテキストにおけるリソース割り当てスキームを提案しました。テナントは、いくつかの事前定義された API を使用してアプリケーションを記述し、複合有向グラフの形式で送信します。複合コレクションは、複合リポジトリ内のいくつかのテンプレートを通じて定義されます。各コンポジットには、集約、負荷分散、キャッシュ、データベース機能、およびその他の機能を含めることができ、これらはネットワーク コンピューティング ノードとデータ センター サーバーの組み合わせによって実行できます。テナントは、サーバーの CPU コアの数や RAM サイズ、ネットワーク コンピューティング ノードのプログラミング バージョンやスループットなど、必要なネットワーク コンピューティング ノードまたはサーバーの特性も定義します。アプリケーションが送信されると、それは多態性のリソース要求、つまりサーバーとネットワークのタスクのグラフに変換されます。多態性リソース要求に対するリソース割り当ては、最適化問題としてモデル化されます。その目標は、サーバーとネットワークのコンピューティング リソースの制約を尊重しながら、最大数の要求にリソースを割り当てることです。この最適化問題を解決するためにヒューリスティックが提案されています。提案された方法は、データセンター サーバーとネットワーク要素の組み合わせを利用してアプリケーションにサービスを提供するため、協調設計アプローチです。4000 台のマシンのクラスターを使用したワークロード追跡実験では、ネットワークの迂回を 20%、配置の待ち時間を 50% 削減できることが示されました。

Wu と Madhyastha [141] は、サードパーティ、つまりプラグイン プロバイダーが新しいサービスの API を公開することでクラウド プロバイダーの機能を強化できる状況を検討しました。このようなマルチプロバイダー環境では、P4 プログラムをネットワーク スイッチにインストールして、パケットを処理する必要があるかどうかに応じて、プラグイン VM またはクラウド サービスの適切な宛先にパケットを転送することを決定できます。プラグインによって。ネットワーク コンピューティングは、プラグイン VM とクラウド サービスの間でデータ パケットを分散することです。

B. エッジコンピューティング

このセクションでは、エッジ コンピューティング テクノロジへの INC のアプリケーションの概要を説明します。まず、ネットワーク コンピューティングをエッジ インテリジェンス配信に適用することに関する研究の概要を説明します。次に、INC ベースのエッジ コンピューティングにおけるリソース割り当て/タスク オフロード方法を議論する研究の概要を示します。タスクへのリソースの割り当ての決定もタスクのオフロードで処理されるため、タスクのオフロード方法はリソース割り当ての一種であることがわかりました。3 番目に、エッジ コンピューティング セキュリティの観点から、INC アプリケーションに関して発見したセキュリティ メカニズムについて説明します。

1. エッジインテリジェンス

エッジ インテリジェンスに関する研究では、[15] はネットワーク コンピューティングを利用して、モバイル エッジ コンピューティングを含むエッジ インテリジェンス サービスの主要なサブタスクを実行し、インテリジェンス/制御シナリオ全体を加速します。一方、[69]、[81] の研究では、ネットワーク コンピューティングを通じて連合学習プロセスを最適化しています。Mai ら [15] は、産業用 IoT 向けのネットワーク コンピューティングを強化したモバイル エッジ アーキテクチャを提案しています。このアーキテクチャでは、エッジでインテリジェンスと制御を提供する必要がある低遅延が要求される重要なサブタスクがネットワーク要素にオフロードされ、残りのタスクはネットワーク要素にオフロードされます。サブタスクはモバイル エッジ コンピューティングによって実行されます。提案されたアーキテクチャでは、センサー/アクチュエーターと MEC サーバー間の接続は、プログラム可能なネットワーク要素を通じて提供されます。ロボット動作制御と火災検知という 2 つの使用例が考慮されます。

ロボットの運動制御のユースケースでは、アクションは乗算操作、つまり現在のロボットの状態ベクトルとパラメーター行列の積として定義されます。パラメーター行列は機械学習によって学習されます。制御マトリックスの乗算は必要な計算量と記憶容量が少ないため、プログラマブル スイッチにオフロードされますが、パラメータ マトリックスの学習プロセスは MEC でより複雑なプロセスとして実行されます。ロボットのセンサーによって収集されたステータス データは、UDP データグラムにカプセル化され、受信パケット ヘッダーを解析してステータス データを抽出するネットワーク要素に送信されます。次に、乗算演算が実行され、結果がロボットに返されます。同時に、UDP パケットは MEC に転送され、機械学習操作を実行してパラメータ マトリックスを更新し、それに応じてネットワーク要素のマトリックスを更新します。

对于火灾检测用例，利用复杂事件处理(CEP)引擎根据传感器监测数据流检测潜在的火灾危险。通过一个工具，应用程序功能转换为一组“匹配-动作”，分析数据流以便于检测火灾。匹配操作将在可编程交换机中执行，而计算和存储密集型的规则学习过程则在MEC中执行。每当检测到复杂事件(如火灾危险信号)时，交换机将发送报警信息。每当CEP引擎接收到连续的温度事件超过预定义阈值时，匹配就会发生。网络计算，即轻量级的关键子任务(如机器人运动控制应用中的矩阵乘法)是在P4交换机中实现的。所提出的方法是一种协同设计方法，因为它利用了MEC服务器来执行像学习这样的复杂任务。评估结果表明，复杂事件可以成功被检测到。

Qin等人[81]提出了一种联合学习方法，用于由一个中央云和多个边缘网络域组成的系统。对于每个域，有一个网关节点负责：(i)将该域的设备的数据包转发到/从中转站，(ii)基于神经网络的二进制分类。网关从传入数据包的头部提取比特，并将其作为输入提供给神经网络进行分类。在网关执行神经网络分类的同时，在本地更新之后进行聚合。网络计算是使用BMv2实现的神经网络。由于云端参与聚合，所以提出的方法是一种协同设计方法。对于恶意软件流量检测的用例，评估显示，与没有联合学习的情况相比，联合学习提高了近20%的检测精度(精度约为95%)。

サービス中心のネットワーキング、ソフトウェア デファインド ネットワーキング、エッジのインテリジェンスの進歩は、すでに将来のネットワークに影響を与えています。Li ら [69] はこれらのテクノロジーを総合的に検討し、ネットワーク インテリジェンスの概念を提案しました。著者らは、ソフトウェア定義ネットワーク内のノードがコンテキスト固有のコンテンツへの関心を宣言できる、および/またはコンテキストがコンテンツを提供する/コンピューティング ノードがサービスを提供する、コンテンツ/コンピューティング/コンテキスト認識サービス中心ネットワーキング プロトコルの採用バージョンについて説明しています。 。提案されたプロトコルにより、エッジ ノード間のネットワーク コンピューティングが可能になります。著者らは、エッジ インテリジェンスのアプリケーションの焦点としてフェデレーテッド ラーニングに焦点を当てています。フェデレーテッド ラーニングでは、ネットワークのエッジにあるアグリゲーターと複数のワーカー ノードがフェデレーテッド ラーニングを実行します。著者らは、特定のデータに対してローカル トレーニングを実行するワーカー ノードがデータのコンテンツへの関心を他のノードに送信でき、これらのノードがデータを持っている場合は、ネットワーク コンピューティングを通じてローカル トレーニングを直接実行できるというシナリオを定義しています。ネットワーク計算によるトレーニングのオフロードにより、通信のオーバーヘッドを削減できます。ネットワーク コンピューティングはキャッシュとモデル トレーニングであり、これらはすべて Open vSwitch を使用して実装されます。ただし、評価には限界があります。4 つのスイッチと 1 人のユーザーによる小規模なネットワーク トポロジの場合、著者らは、畳み込みニューラル ネットワーク ベースの画像分類アプリケーションでフェデレーテッド ラーニングを実行する際の学習の比較を行わず、ネットワーク内のトラフィック レートのみを報告します。

2. INC拡張によるエッジコンピューティング環境でのリソース割り当て/タスクオフロード

図8. FPGA アクセラレーション計算機を使用したエッジでのコンピューティングの強化 [144]

このような研究は、ネットワーク コンピューティングで強化されたエッジ コンピューティング環境におけるリソース割り当てまたはタスクのオフロード ソリューションを提供します。[58]、[142]、[143] は最適化手法を使用してリソース割り当ての問題に対処していますが、[144] は FPGA アクセラレータで強化されたエッジ プロセッサにタスクをオフロードするためのタスク オフロード機能を備えたアーキテクチャを提供しています。Ali ら [58] は、有線ネットワークの構築がコスト効率が悪い屋外ロック コンサートやスポーツ イベントなどの使用例に焦点を当てました。著者らは、ワイヤレス メッシュ ネットワーク上で必要なサービスを提供するためのアーキテクチャを設計および実装します。マイクロサービスは半永久的なワイヤレス メッシュ デバイスに実装されます。実際、メッシュ リレー ノードやメッシュ ルーターなどのメッシュ ネットワーク要素は、主にデータ パケットのルーティングに使用され、ネットワーク コンピューティングのフォグ ノードとして機能してマイクロサービスを提供します。提案されたアーキテクチャには、IoT、フォグ、アプリケーション、フォグ コントローラーの 3 つのレイヤーが含まれています。IoT レイヤーのデバイスはデータを生成しますが、フォグ レイヤーでは API が提供され、計算のためにワイヤレス フォグ ノードにマイクロサービスを配置します。さらに、フォグ ノードのメモリ/ストレージ/CPU 使用率やリンク負荷とパケット損失に関する情報を含むネットワーク情報は、どのフォグ ノードが計算を実行するかを決定するために使用されます。構築されたコンテナーのリポジトリは、フォグ ノードにマイクロサービスをインストールするためのオンデマンド コンテナーを提供するためにアプリケーション層で使用されます。フォグ コントローラーは、フォグ ノード、IoT デバイス、マイクロサービス間の通信を制御します。さらに、フォグ コントローラーは、応答時間を最小限に抑えるアルゴリズムを通じて、マイクロサービスによってホストされるフォグ ノードの選択を実行します。ネットワーク コンピューティング、つまりマイクロサービスの実行は、メッシュ ネットワーク要素に実装されます。エンドツーエンドのメッセージング シナリオの場合、ノード数が 650 未満のフォグ ネットワークの場合、提案された方法の遅延は 6 ミリ秒未満です。

Lia et al. [142] は、SDN 対応ノードが特定の入力タスクを実行する、エッジ コンピューティングの分野向けのリソース割り当てソリューションを提案しました。SDN 対応ノードでの計算タスクの配置は、事前定義されたタスク遅延制約を尊重しながらネットワーク使用量を最小限に抑えることを目的とした整数線形計画問題としてモデル化されます。最適なソリューションは CPLEX 最適化ツールによって見つかりました。ネットワーク コンピューティングは、SDN によって有効化されたノードによって実行されるタスクの実行です。シミュレーション結果によると、最大 100 ミリ秒の遅延制約により、クラウドベースのコンピューティング手法と比較して、クラウドへのタスクオフロードの割合が 99% 削減され、交換されるデータ量が 10 分の 1 に削減されます。

Cooke と Fahmy [143] は、ネットワークのエッジ層、中間層 (ゲートウェイやルーターなど)、クラウド データセンターを含むさまざまな層に分散されたコンピューティング ノードで構成される分散ハイブリッド コンピューティング環境を検討しました。ノードには、ソフトウェアおよびハードウェアのアクセラレーションを実装する機能があります。コンピューティング ノードの実装の決定とタスクへのノードの割り当ては、最適化問題としてモデル化されます。オブジェクト追跡のユースケース (カメラ経由) については、レイテンシ、スループット、エネルギー消費、コストなど、タスクをさまざまな実装に分散するパフォーマンス メトリクスを評価しました。さまざまなシナリオでは、さまざまな層でネットワーク コンピューティングが適用されます。ネットワーク コンピューティングは、FPGA アクセラレータによって実装されるタスクの実行です。提案された方法は、タスクがソフトウェア (汎用コンピューティング ノード上) とハードウェア アクセラレーション リソースによって実行されるため、共同設計されています。上記のユースケースでは、FPGA アクセラレータを追加すると、0.8 秒のレイテンシー、133 カメラ フレーム/秒のスループット、1.56 (エネルギー単位) のエネルギーが得られましたが、クラウドでの実装では 1.9 秒と 3.4 カメラ フレーム/秒が得られ、レイテンシー、スループット、エネルギーの場合は 30。

Xu et al. [144] は、計算集約型タスクをオフロードしてモバイル アプリケーションを高速化するために、ネットワークのエッジに導入される FPGA ベースの高速化手法を提案しました。著者らは、イーサネット経由で接続された WiFi ルーターと FPGA ボードで構成される無線エッジ ネットワークにモバイル デバイスが接続されるシステム アーキテクチャを提案しています。ワイヤレス エッジ ネットワークのエッジ オフロード マネージャー コンポーネントは、要求された計算を FPGA アクセラレータで強化されたエッジ プロセッサ内で実行するか、要求をリモート クラウドに転送するかを決定します (図 8 を参照。3 つのアプリケーションが考慮されます。 (i) LeNet-5 のような畳み込みニューラル ネットワーク モデルで動作する手書き数字認識。(ii) オブジェクト認識。バイナリ ニューラル ネットワーク モデルに基づいて実行されます。(iii) 顔検出。類似性チェックに基づいたコンピューター ビジョン アルゴリズムで動作します。ネットワーク コンピューティングは、ニューラル ネットワーク推論およびコンピューター ビジョン アルゴリズム操作であり、ARMA-FPGA ボード (Xilinx Zc706) に実装されています。提案された方法は、アクセラレータで実行できる演算のみが FPGA にオフロードされ、残りは汎用 CPU で実行されるため、共同設計アプローチです。実験結果は、提案された方法が、汎用の CPU ベースのエッジ/クラウド オフロードと比較して、応答時間と実行時間をそれぞれ 3 倍と 15 倍短縮し、モバイル デバイスとエッジ ノードをそれぞれ 29.5% と 16.2% 節約することを示しています。の。

3. 安全性

​ 图10 基于虚拟化平台[155]的网络计算体系结构。

在本节中，我们解释了我们在边缘计算范围内调查的研究中发现的安全机制。为了减少传输开销和提高服务能力，在工业物联网的大规模机器通信中，将运行在集中式服务器上的访问控制程序迁移到边缘数据平面设备中，这是由宋等人提出的[145]。图9展示了所提出方法的结构。各种异构终端发送不同服务的请求，例如感知、数据上传和所需的控制信令。整个过程分为四个步骤：（i）系统初始化：在此步骤中，管理员通过控制平面内的网络管理应用程序设置适当的访问控制策略。策略根据一些上下文变量定义，例如，终端的感知频率、终端和服务对象之间的距离。根据上下文变量的值，定义操作，并且控制器在靠近终端的边缘可编程交换机上设置整个策略。(ii)请求发送：终端向访问设备发送其服务请求以及上下文信息。(iii)请求处理：访问设备，即交换机从数据包头中提取上下文信息，并根据匹配的服务对象应用相应的规则，即允许、拒绝、警报、重新认证。控制器将实时与交换机进行交互以更新策略。(iv)生成安全日志：记录和评估终端的访问行为，以便根据报告的上下文、请求上传特征和终端恶意行为的历史计算终端的信任值。交换机将计算统计数据，例如大小、频率和请求的服务对象。基于日志，可以在服务器上实现复杂的攻击检测（例如DoS攻击）方法。为了确保日志的可信度，作者使用了区块链作为数据结构。为了应对交换机存储限制，提出了一种算法，在交换机上动态部署策略。网络内计算计算访问服务的统计数据，并运行在BMv2中实现的访问控制策略。所提出的方法是一种协同设计方案，由于控制器与数据平面的实时交互以及在服务器上实现的攻击检测。与集中式方法相比，由于交换机的管道速度以及靠近终端的处理，授权决策时间已经减少了8毫秒。通过过滤非法流量以及在边缘响应，网络中传输的流量体积减少了近3倍。

Zhang et al. [146] は、フォグ コンピューティング環境を通じて実装される、安全な大規模画像データ処理のための信号処理ベースの方法を提案しました。著者らは取り扱いプロセスを安全にすることに主な焦点を当てていたため、この研究をこのカテゴリーで検討しました。提案手法では、離散ウェーブレット変換で表現されたカラー画像をサンプリングし、圧縮センシングと呼ばれる高度な信号処理技術を用いて圧縮する。正弦波論理変調マップは、圧縮センシングコーディングを実行するための測定行列を構築するために使用されます。さらに、認証された測定値は、セキュリティ目的でカラー画像のエンコードとして生成されます。結果として得られる測定値は（セキュリティ目的で）正規化され、画像の後処理のためにフォグ ノードに送信され、値の順序の抽出、測定値の分解、エネルギー値のマスキング（エネルギーを隠すための順列拡散アーキテクチャに基づく）などの特定のセキュリティ メカニズムで強化されます。情報）。最後に、関連データは、保管、再構築、整合性検証のためにデータセンターに転送されます。著者らは、処理を高速化するために、提案した処理をFPGAのフォグノードに実装しました。ネットワーク内コンピューティングは、DE2-70 FPGA に実装された、セキュリティ メカニズムで強化された画像の後処理です。提案された方法は、クラウド データセンターがストレージ、再構築、完全性認証に使用されるため、共同設計です。実験結果は、提案された方法が特定の攻撃の下でプライバシーのセキュリティを保証できることを示しています。さらに、提案手法を使用すると、再構成時間がほぼ 2 倍に短縮されました。

C. 4G/5G/6G

まず、4G/5G/6G の無線アクセス ネットワーク (RAN) におけるネットワーク内コンピューティングの活用に関する研究をレビューし、次にモバイル コア ネットワークで行われた研究について説明し、最後に 4G/5G の他の分野での利用をレビューします。 /6G イントラネット コンピューティングに関する研究。

1. 無線アクセスネットワーク

[147] では、LTE RAN はエッジ ゲートウェイ機能を展開します。[148] の研究では、次世代 NodeB の機能の一部をプログラマブル スイッチにオフロードします。最後に、[149] の研究では、ネットワーク内計算を利用することにより、RAN でのハンドオーバー動作が改善されています。

Aghdai et al. [147] は、LTE 無線アクセス ネットワークにおけるエッジ ゲートウェイを提案し、サービス オペレーターがモバイル ユーザーのすぐ近くにネットワーク機能を展開できるようにしました。彼らは、エッジ ゲートウェイの主な機能として 2 つの機能を考慮しています: (i) モバイル エッジ ユーザーにコンテンツ配信を提供する; (ii) トラフィック分散に負荷分散戦略を適用して、受信したトラフィックを MEC サービスの 1 つに振り向ける。ネットワーク内コンピューティング、つまり前述のエッジ ゲートウェイ機能は、Netronomr NFP4000 P4 ターゲットを使用して実装された IP トランスポートのエッジに実装されます。UE が中間ゲートウェイを介して SPGW、HSS、および MME コンポーネントをホストするノードに接続される単純なトポロジの場合、LTE プロトコル スタックと提案されたゲートウェイのエンドツーエンド遅延は平均 50 マイクロ秒です。

Vörös et al. [148] は、高スループットを実現するプログラマブル スイッチを使用した 5G RAN における次世代 NodeB (gNodeB) の実装に焦点を当てました。暗号化/復号化などの一部の gNodeB 機能はプログラマブル スイッチでは実装できないことを考慮して、プログラマブル スイッチと外部サービスを使用するハイブリッド アプローチが採用されています。実際には、主要なパケット処理はプログラマブル スイッチに実装され、複雑な機能は外部サービスによって実行されます。ネットワーク内コンピューティング、つまり gNodeB の一部の機能の実現は、P4 ハードウェア スイッチを使用して実現されます。gNodeB の複雑な機能は汎用プロセッサを使用したサービスによって提供されるため、提案された方法は共同設計アプローチです。P4 ハードウェア スイッチの評価では、提案されたハイブリッド アプローチが既存の gNodeB ソリューションの代替となり得ることが示されています。

Palagummi と Sivalingamf [149] は、ベースバンド ユニットの機能が中央ユニット (CU) と複数の分散ユニット (DU) に分割される次世代 RAN を検討しました。著者らは、移動端末 (UE) が DU 間でハンドオーバーする必要がある場合のハンドオーバー問題に焦点を当てています。著者らは、UE のパス上にリソースを事前に割り当てるリソース割り当て方法を提案します。CU/DU の機能は、コンピューティング サーバー、P4 スイッチ、コントローラーの 3 つのコンポーネントに分類されます。P4 ベースのスイッチが CU と DU の間で動作します。CU/DU の機能のうち、ネットワーク内コンピューティングには、UE のモバイル動作の追跡と DU でのリソース割り当ての事前実行が含まれており、これらの機能は P4BM ソフトウェア スイッチで実装されます。CU/DU の機能の一部がネットワークにオフロードされるため、提案手法は協調設計手法です。実装結果は、提案された方法によりスイッチング時間が約 18% および 25% 短縮されることを示しています。

2.モバイルデータコア

在[150]中，描述了对LTE EPC移动数据核心进行重新设计的研究，其中将一些控制平面过程卸载到可编程交换机中。[151]的研究提出了在可编程交换机中实现的5G移动数据核心的网关。最后，[152]利用网络内计算来实现Serving Gateway的用户平面，而[153]则提出了用于User Plane Function的网络内实现。

LTE EPC（Long-Term Evolution Evolved Packet Core）的控制平面包括附着、脱离、S1释放、业务请求和切换等过程。大部分信令流量与S1释放和业务请求等过程有关，这些过程操作用户特定的上下文。因此，Shah等人提出将这些过程卸载到可编程数据平面交换机的数据包处理管道中，从而提高控制平面的吞吐量和延迟。同时，他们考虑了三个挑战：第一，控制平面在交换机中存储的状态与集中式控制平面中的主副本状态不一致。为解决这一挑战，卸载的控制平面状态与其主副本状态进行同步。第二，为了在交换机中存储用户上下文，同时尊重交换机的内存限制，将用户上下文分区存储在多个交换机中。第三，为了处理交换机故障并避免丢失存储在交换机中的用户上下文，将用户上下文在交换机之间进行复制，并提出一种应对交换机故障的机制。在LTE EPC的控制平面中，即S1释放和业务请求过程的网络内计算，通过BMv2和Netronome Agilio CX智能网卡实现。因为LTE EPC的其他控制平面功能是在非网络元素中实现的，所以该方法是一种协同设计方法。硬件原型显示，当交换机硬件存储65K并发用户的状态时，吞吐量和延迟分别提高了102倍和98%。

Singhらは、5Gモバイルデータパケットのコアアーキテクチャに焦点を当てている。このアーキテクチャによれば、アップリンクおよびダウンリンクの IP トラフィックは、シグナリング ゲートウェイ (SGW) を介して無線ネットワークの eNodeB サイトにルーティングされます。実際には、複数の eNodeB とそれらの間のハンドオーバーは SGW によって管理されます。モバイル パケット コアと外部 IP ネットワーク間の接続、およびパケット フィルタリング、課金ポリシー、サービス品質管理などの機能は、パケット データ ネットワーク ゲートウェイ (PGW) によって処理されます。一方、モビリティ管理エンティティ (MME) は、ネットワーク全体でユーザー認証、セッション処理、ユーザー追跡などのセキュリティ手順を実行します。

著者らは、SGW と PGW の機能を統合した Evolved Packet Gateway (EPG) を定義しています。作成者は、vEPG コントロール プレーンを x86 サーバー上に保持しながら、vEPG ユーザー プレーン機能をプログラマブル スイッチに実装しました。vEPG ユーザー プレーンを実装するためのパイプラインには、L2 テーブル、アップリンクおよびダウンリンクのファイアウォール テーブル、GTP カプセル化およびカプセル化解除テーブル、IPv4 ルーティング テーブルが含まれます。モバイル データ パケットのコア アーキテクチャにおける SGW と PGW のネットワーク内コンピューティング、つまりユーザー プレーン機能は、Barefoot Tofino ハードウェア上に実装されています。提案された方法は、2 マイクロ秒未満の遅延でライン レートで動作します。

Shen らは、5G パケット処理の簡素化されたアーキテクチャについて説明しています。このアーキテクチャでは、サービング ゲートウェイ (SGW) はコントロール プレーン (SGW-C) とユーザー プレーン (SGW-U) で構成され、複数の SGW-U が 1 つの SGW-C によって制御されます。逆方向接続は、基地局、コア ネットワーク、およびエッジ ネットワーク間の接続を提供し、逆方向に送信されるトラフィックは GPRS トンネリング プロトコル (GTP) に基づいています。

バックホールで送信されたGTPパケットは、SGW-Uでイーサネットパケットに変換され、エッジサーバに送信されます。一方、エッジ サーバー上のイーサネット パケットは、逆方向に送信される前に GTP パケットに変換する必要があります。このため、専用のソフトウェア/ハードウェアが GTP ヘッダーの処理を担当します。ソフトウェアベースの方法では送信スループットが低いため、著者らはプログラム可能なネットワーク要素を利用して、5G モバイル エッジ ネットワーク用の SGW-U システムを実装しました。Realtek RLT 9310 スイッチと FPGA プラットフォームは、ネットワーク内のコンピューティング、つまり SGW-U 機能を実現するために使用されます。実験結果は、10 Gbps のスループットと 5 マイクロ秒のパケット処理遅延が達成されることを示しています。

Paolucci等人提供了一个5G X-haul测试平台，通过使用实现了用户面功能（UPF）模块的P4交换机进行了增强。网络内计算，即UPF功能，由GTP协议封装/解封装功能以及5G MEC架构中的N3-N6-N9流量转发组成。此外，通过使用BMv2和P4代码在网络中实现了监测GTP流性能指标，如经验延迟。流量的经验延迟低于200微秒。

3.其他INC应用

有几项研究利用网络内计算在其他4G/5G/6G应用中。分别在[154]和[155]中考虑了5G片段流和6G任务的处理。Ricart-Sanchez等人[154]演示了一种在5G网络片段中处理流的网络内解决方案。他们通过6元组（5G用户源和目标IP、5G用户源和目标端口、区分服务代码点和与用户设备和5G核心网络之间建立的无线电隧道相关的GTP隧道ID）定义了网络片段。这些6元组在匹配/操作阶段的TCAM表中使用，以定义网络片段。动作被定义为对片段执行的操作。网络元素流水线已扩展以实现排队规则，以在处理片段的流程中应用基于优先级的规则。根据排队规则，低优先级队列将不会被处理，直到高优先级队列被处理。实际上，定义了几个不同的队列，允许为片段定义各种类型的QoS。网络内计算，即5G片段流的处理是在P4-NetFPGA中实现的。在私人数据中心部署的5G边缘到核心基础设施上进行的评估结果显示，最高优先级队列的端到端延迟在0.5毫秒以下，最低优先级队列的端到端延迟在3毫秒以下。

Hu ら [155] は、図 10 に示すように、6G でネットワーク内コンピューティングを適用するためのアーキテクチャを提案しました。提案されたアーキテクチャは、ネットワーク機能をスイッチ チップを備えたホスト システムにオフロードし、高性能スイッチ チップがパケット処理機能を実装します。この点で、アプリケーション展開の柔軟性が提供されるだけでなく、アプリケーションの移行機能も提供されます。実際、仮想化環境は、スケジュール ポリシーに基づいてホスト間で移行できるコンテナ内でアプリケーションを実行する機能を備えたホスト上にセットアップできます。著者らは、データ ストリーム上で動作するタスクをネットワーク内のコンピューティング デバイスにオフロードするという決定を、データ転送全体のオーバーヘッド、エネルギー消費、およびリソースのアイドル状態を最小限に抑える多目的最適化問題としてモデル化しています。この最適化問題を解決するアルゴリズムが提案されています。ネットワーク内コンピューティングは、PX30 Cortex-A35 CPU を含む INC-Server によって実装されるタスク実行です。データ集約アプリケーションの場合、ネットワーク内処理によりクラウド サーバーの負荷が 60% 削減され、エネルギー消費が 50% 削減されます。

Wu ら [156] は、強化されたモバイル ブロードバンド アプリケーションよりも接続数が桁違いに多い IoT アプリケーションに焦点を当てています。一方で、接続された各デバイスによって提供されるデータ トラフィックは、従来の 4G 通信よりも大幅に少なくなります。複数の宛先にデータを送信する場合、複数の小さなデータが 1 つのブロックにエンコードされます。これは、データ フレームが送信される前に P4 スイッチで行われます。次に、eMBMS ベアラーを介して、ブロックはスイッチから LTE-M セル内のターゲット デバイスに転送されます。パケットが IoT デバイスに到着すると、宛先でデコードが行われます。提案された方法を使用すると、データ送信に使用される無線リソース ブロックの数がベースラインと比較して 8 分の 1 に削減されます。

Gökarslan ら [157] は、処理を削減し、ネットワーク監視メカニズムを提供し、ネットワークのセキュリティを強化する、産業用 5G ネットワーク用のプログラム可能なデータ プレーンを提案しました。提案されたデータ プレーン パイプラインは、RAN とユーザー プレーン機能 (UPF) の間の接続上で実行されます。GTP パケットを UPF に送信するか、パケットを別の gNodeB に転送するかのルーティング決定は、gNodeB 間にある P4 スイッチにオフロードされます。著者らはまた、5G のパフォーマンスを向上させるために、P4 パイプラインに監視機能とセキュリティ機能を導入しています。ネットワーク内のコンピューティング、つまりトラフィック ルーティングの決定、監視、セキュリティ機能は BMv2 に実装されています。従来の 5G アーキテクチャと比較して、提案された方法はセル内ネットワークの遅延を 2 分の 1 に短縮します。さらに、セキュリティ ルールは 95% の信頼性で 10 ミリ秒以内に更新できます。

Ricart-Sanchez et al. [158] は、5G モバイル ネットワーク用のハードウェア アクセラレーションによるレイヤー 4 ファイアウォールを提案しました。提案されているファイアウォールは、エッジとコア ネットワークの間に配置され、5G ユーザーとインフラストラクチャを保護します。ファイアウォールは、パーサー、マッチアクション テーブル、およびパーサーを使用して実装されます。MAC、IP、UDP/TCP、および汎用パケット無線サービス トンネリング プロトコル (GTP) のヘッダーは、解析対象として定義されます。解析後、パケットは match-action パイプラインを通じて処理され、パケットの抽出されたフィールドによってドロップまたは転送アクションが定義されます。TCAM テーブルは、5G ユーザーの送信元/宛先 IP とポート、トランスポート プロトコル タイプ、および GTP トンネル情報を照合部分として含むように定義されています。悪意のあるパケットの場合、DROP アクションが適用されますが、デフォルトは許可アクションです。最後に、ドロップされなかったパケットが再構築され、5G インフラストラクチャを通じて送信されます。著者らは、[159] での研究を拡張して、5G でのマルチテナンシーをサポートしています。ネットワーク内コンピューティング、つまりレイヤー 4 ファイアウォール ポリシーは P4-NetFPGA NIC [160] に実装されます。評価では、ネットワーク内のパケット処理遅延はソフトウェアベースのソリューションよりも 2493 倍速く、エッジ ノードとコア ノード間のスループットの向上は 3.5 Gb/s にも達しました。

D. ネットワーク機能の仮想化

ネットワーク機能仮想化 (NFV) は、ネットワーク機能を特定用途向け集積回路 (ASIC) や特定のハードウェアから分離し、これらの機能を仮想マシンやコンテナーなどの仮想化インフラストラクチャに実装するパラダイムです。この取り組みの結果、コストが削減され、ネットワーク機能の更新を処理する柔軟性が向上しました。VM/コンテナの展開は大量のリソースを消費し、仮想化層でのオペレーティング システムのオーバーヘッドにより追加の負担が発生し、VNF に必要なパフォーマンスとスループットが利用できない可能性があります。ネットワーク コンピューティングは、これらの問題を解決するために活用されています。研究は、ハードウェア アクセラレーションによるネットワーク機能とフレームワーク/展開ソリューションの 2 つのグループに分類できます。

1. ハードウェアアクセラレーションによるネットワーク機能

汎用ハードウェア上でソフトウェアとして実行されるネットワーク機能 (NF) のパフォーマンスの問題を軽減するために、仮想化されたネットワーク機能にハードウェア アクセラレーション技術が使用されています。NF は、ルーティング操作のための IP/MAC ルックアップ、トンネルベースの転送のためのパケットのカプセル化とカプセル化解除、セキュリティのためのパケットの暗号化と復号化などのタスクを実行する必要があります。これらのタスクを実行するには、ネットワーク インターフェイス コントローラー (NIC) を頻繁に監視し、NF を通じて IP パケットを処理する必要があります。これにより、多くの CPU サイクルと I/O インタラクションが消費されます。カスタム技術と特殊技術として分類されるハードウェア アクセラレーション技術を使用すると、このプロセスの効率を向上させることができます。

専用ハードウェア アクセラレーションは、ハードウェアの再プログラムや動作の変更が制限されているかまったく機能しない、特定の機能用に設計されたハードウェアです。したがって、専用ハードウェア アクセラレーションはネットワーク コンピューティングの範囲外であり、ネットワーク要素の汎用プログラミングの柔軟性が必要です。カスタム アクセラレーションはコスト効率が高く、プログラムおよび構成が容易であるため、アプリケーションに応じて新しいネットワーク機能やプロトコルを採用できます。これらのアクセラレータの背後にある一般的な考え方は、一部の処理をネットワーク要素 (FPGA、スマート NIC、プログラマブル スイッチなど) にオフロードして、一般的な CPU によって実行される処理の前または後にパケットを処理できるようにすることです。ネットワーク機能のコンテキストでは、チェックサム計算、暗号化と復号化、パケット分割と再構築 [161]、ルーティング [162]、負荷分散 [163] などはすべて、CPU サイクルを節約するためにネットワーク要素にオフロードできるものであり、ネットワーク機能のパフォーマンスを向上させる機能の例。詳細については、興味のある読者に [45]、[161] を参照してください。

2. フレームワーク/導入ソリューション

このような研究では、NFV コンピューティング環境でネットワーク コンピューティングを活用するためのフレームワークと導入ソリューションが提案されています。ある研究ではネットワーク要素に VNF を展開することに焦点を当てていますが、別の研究ではネットワーク コンピューティング機能を備えた NFV 環境でのフレームワーク/展開ソリューションを提供しています。

a. ネットワーク要素に VNF を導入する

[164]、[165] は P4 を使用し、通信プロバイダーの要件を満たすデータ センター (CORD) 環境として再構成された中央オフィスに展開されるブロードバンド ネットワーク ゲートウェイ データ プレーンを開発しました。ブロードバンド ネットワーク ゲートウェイ システムの仮想ネットワーク機能について説明します。トラフィック レートの強制、クライアント トンネリング、トラフィック アクセス制御、トラフィック分離、認証、認可とアカウンティング、キューイングと階層スケジューリングなどです。ブロードバンド ネットワーク ゲートウェイ機能は、アップリンクおよびダウンリンクのデータ プレーンで実行されます。ネットワーク コンピューティング、つまりブロードバンド ネットワーク ゲートウェイ機能は、ベア メタル Tofino、BMv2、Netronome SmartNIC、および P4-NetFPGA に実装されています。加入者が FPGA および P4 データ プレーン (Tofino) を介してコア ネットワークに接続し、10,000 データ パケットの VOIP 送信を実行するシナリオの場合、エンドツーエンドの遅延は最大 14.5 マイクロ秒です。同様に、Osinski et al. [166] は、仮想ブロードバンド ネットワーク ゲートウェイの一部の機能をプログラマブル ASIC にオフロードしましたが、詳細や評価は彼らの研究には含まれていませんでした。

図11. p4 対応デバイス上のサービス機能リンク フレームワーク [170]。

Osinski ら [167]、[168] は、ソフトウェア スイッチまたはトップ スイッチ、SmartNIC、FPGA などのハードウェア デバイスで実行できる、データ センターで VNF をインスタンス化するための NFV フレームワークを提案しました。フレームワークのプロトタイプは、OpenStack Neutron、P4 言語、および BMv2 ソフトウェア スイッチに基づいて実装されています。

Mafioletti ら [169] は、VNF の機能コンポーネントの分析に基づいて、ネットワーク要素に VNF を展開する方法を提案しました。著者らは、ネットワーク要素に展開するために、VNF を小さな組み込みネットワーク機能 (eNF) に分解するフレームワークを提案しています。トラフィック処理の重複を発見するために、サービス機能チェーン内の VNF の機能コンポーネントが検査されました。したがって、VNF内の共通コンポーネントが新しいコンポーネントにマージされ、ネットワーク要素にオフロードされるeNFが定義されます。最後に、ヘッダーの解析と分類、パケットの破棄とカウント、および eNF 機能を実行する必要がある操作を含む、対応する P4 プリミティブが定義されます。チェーン内のネットワーク トラフィックの方向を決定するために、ハッシュ テーブルとブルーム フィルターに基づくチェーン メカニズムも定義されています。ネットワーク コンピューティング、つまり小規模なネットワーク機能はスマート NIC 上に実装されます。3 つの VNF を備えたファイアウォール VNF チェーン アプリケーションの場合、すべての VNF がネットワーク内で実行されている場合は、すべての VNF がソフトウェアで実行されている場合 (3300 マイクロ秒) に比べて、遅延を 76 倍 (43 マイクロ秒) に短縮できます。最大 8 倍のスループット向上が達成されました。

[170]、[171] で実施された研究は、ハードウェア機能と P4 SFC の柔軟性を備えた P4 デバイス上のサービス機能チェーン (SFC) のフレームワークを設計しました。図 11 に示すように、提案されたフレームワークは、オペレーターが必要な SFC リクエストを生成するためのいくつかの高レベルのプリミティブを提供します。さらに、コンバータは、与えられた SFC 要求に従って、対応する P4 プログラムを生成します。コンバータは、最長共通サブシーケンス ベースのアルゴリズムを適用して、P4 プログラム内の複数の SFC をマージします。Tofinoにはネットワークコンピューティング、つまりネットワーク機能が実装されています。現実世界での SFC の評価では、ソフトウェア ベースの NFV ソリューションと比較してスループットが 10,000 倍向上していることが示されています。同様に、レイテンシは 10,000 分の 1 に短縮されます。

b. INC テクノロジーを使用した NFV (ハイブリッド インフラストラクチャ ネットワーク用のフレームワーク/導入ソリューション)

ネットワーク要素と汎用コンピューティング ノードを含む、ハイブリッド インフラストラクチャ ネットワーク上に VNF (仮想ネットワーク機能) を展開する実装については、[172]、[173] で検討されています。Lopes ら [172] は、ヘテロジニアス アーキテクチャで FPGA と汎用プロセッサから構成される VNF コンポーネントを管理および配布するためのプラットフォームを提案しました。著者は、各 VNF コンポーネントの適切な基準の選択を支援するために、VNF コンポーネントの属性に関するガイダンスと説明を提供します。ネットワーク コンピューティングでは、VNF コンポーネントは NetFPGA 上に実装されます。提案されたアプローチは、VNF コンポーネントがネットワーク要素と汎用プロセッサを含む混合ベース環境に展開されるため、共同設計アプローチです。ディープ パケット インスペクションとファイアウォール機能については、このアプローチにより、ソフトウェア ソリューションと比較してスループットが 2 倍 (最大 800 Mbps) 向上します。

Moro et al. [173] は、ハイブリッド インフラストラクチャ ネットワーク上に VNF を展開するための最適化されたフレームワークを提案しました。著者らは、VNF を µVNF と呼ばれる複数の小さな機能に分解し、それらをプログラマブル スイッチ、NIC、エッジ/フォグ コンピューティング ノードのハイブリッド インフラストラクチャ全体に分散します。次に、最適化フレームワークを開発して、展開コストを最小限に抑える分解を選択し、各 µVNF を展開するノードを決定します。著者らはまた、プログラマブル スイッチ上でインスタンス化するために、複数の µVNF を 1 つの P4 プログラムに統合できるツールを導入しています。リンク障害条件下での提案されたアルゴリズムのロバスト性を研究します。提案手法におけるネットワーク計算はμVNFの実行である。μVNF の実行はネットワーク要素やエッジ/フォグ コンピューティング ノードを含むハイブリッド インフラストラクチャ環境に分散されるため、提案された方法は共同設計アプローチです。ベースラインと比較して、提案された方法は導入コストを 3 倍改善します。

E. 要約、比較、洞察、および学んだ教訓

このセクションでは、まずテクノロジー固有のアプリケーションを簡単に要約し、次に得られた洞察と学んだ教訓について説明します。

1. 概要

ネットワーク コンピューティングをクラウド コンピューティングに適用する研究がいくつかあります。[137]、[138]、[139]、[140] の研究では、ネットワーク コンピューティングを利用してデータ センターの負荷分散を実現しています。負荷分散をネットワーク要素にオフロードします。[27]、[28]、[141] の研究は、INC に参加するクラウド環境のデータセンター アプリケーションに対するリソース割り当てを提供します。[27]、[28] では、ネットワーク要素を利用してアプリケーションまたはアプリケーション コンポーネントの計算を実行します。[141] の研究では、ハイブリッド クラウド プロバイダーとアドオン プロバイダーでネットワーク コンピューティングを利用しています。

エッジ コンピューティングの範囲内でネットワーク コンピューティングを適用する研究もいくつかあります。一部の研究は、エッジにインテリジェントな機器を提供することを目的としています。[15] は、インテリジェントな認識または制御シナリオの主要なサブタスクのみをネットワークにオフロードし、[69] と [81] の研究では、連合学習の最適化にネットワーク コンピューティングを使用しています。ネットワーク コンピューティングに加わる、エッジ コンピューティングにおけるリソース割り当てまたはタスクのオフロード方法を提供する研究もいくつかあります [58]、[142]、[143]、[144]。

さらに、4G/5G/6G の範囲でいくつかの研究が実施されています。[147]、[148]、[149] の研究では、ネットワーク コンピューティングを利用して、無線アクセス ネットワーク (RAN) でのより高いスループットとより低い遅延を実現しています。これらの研究では、トラフィック ステアリング、負荷分散、gNodeB の一部の機能、無線リソース割り当てなどの計算がプログラマブル スイッチにオフロードされています。[150]、[151]、[152]、[153] の研究では、ネットワーク コンピューティングを利用してモバイル データ コアを簡素化しています。これらは、ネットワーク要素を利用して、いくつかのコントロール プレーン プロセス、またはサービング ゲートウェイやユーザー プレーン機能などのオフロード可能なモバイル データ コア ネットワーク機能を実行します。[154]、[155]、[156]、[157]、[158] は、ネットワーク コンピューティングを使用して、5G ネットワーク スライシング、6G アプリケーション、LTE サービス、IoT アプリケーション、モニタリングなどの 4G/5G/6G の他の領域での処理を高速化しています。 /5Gネットワ​​ークのセキュリティ。

ネットワーク機能の仮想化は、仮想マシン/コンテナの展開により大量のリソースを消費します。さらに、ハイパーバイザー上のオペレーティング システムによって発生するオーバーヘッドは、必要なパフォーマンスとスループットにとって十分ではない可能性があります。ネットワーク コンピューティングは、これらの問題を克服するためにいくつかの研究で活用されています。[45]、[161] の調査では、ハードウェア アクセラレーションによるネットワーク機能が検討されています。一部の研究では、NFV 環境でネットワーク コンピューティングを活用するためのフレームワーク/展開ソリューションを提案しています。いくつかの研究は、ネットワーク要素での VNF の展開に焦点を当てています [164]、[165]、[167]、[168]、[169]、[170]、[171]。通常、提案されたフレームワーク/展開提案は、VNF を SmartNIC、FPGA、プログラマブル スイッチなどのネットワーク要素に分解することによって、VNF 全体または VNF 機能の一部を実装します。[172]、[173] の研究は、ネットワーク コンピューティングの強化、つまりネットワーク要素と汎用コンピューティング ノードの組み合わせを備えた NFV 環境におけるフレームワーク/展開ソリューションを提供します。

2. 比較、洞察、得られた教訓

表 XII、XIII、XIV、および XV は、クラウド、エッジ、4G/5G/6G、および NFV のコンテキストにおけるテクノロジー固有の調査を比較しています。これらの研究は、貢献、方法論（ネットワーク コンピューティング、共同設計、最適化/目的関数）、評価（ネットワーク要素、シミュレーション プラットフォーム、主な結果）の観点から比較されます。そこからいくつかの洞察が得られ、そこからいくつかの教訓が得られます。

表XII: クラウド コンピューティングの動作原理の比較

表XIII: エッジ コンピューティングのコンテキストにおける作業の比較

表XIV: 4G/5G/6G 範囲でのエンジニアリングの比較。テクノロジーに関わる日々の仕事。（テクノロジー）

表XV: NFV の範囲内のソリューション/展開の取り組みの比較

• フォールト トレランス: 一般的な点は、[140]、[150] など、テクノロジ固有のアプリケーションにおけるフォールト トレランスを考慮した研究はほとんどないということです。ネットワーク要素、特にスイッチには障害が発生する可能性があるため、フォールト トレランスはネットワーク コンピューティングにとって重要です。さらに、輻輳によりネットワーク要素が使用できなくなる可能性があります。5G RAN を例にとると、スイッチの障害によりスイッチへの RAN 機能のオフロードの実行が失敗すると、潜在的な障害が発生する可能性があり、UE とコア ネットワーク間のような高可用性要件を持つサービスでは許容できません。接続が中断される可能性があります。 、ローミング無効化など。私たちが学んだ教訓は、ネットワーク コンピューティングにフォールト トレラントな技術を提供するには、さらなる研究努力が必要であるということです。

• INC を使用したコンピューティング環境: もう 1 つの洞察は、ほとんどの研究がネットワーク要素の必要な機能の実装に焦点を当てていることです。ただし、インフラストラクチャは、独自の機能とプロパティを持つネットワーク要素とコンピューティング ノードの混合など、異種リソースで構成されています。ネットワーク要素はかなりの処理速度を提供しますが、強力な処理能力とメモリ能力を備えた計算ノードに比べて柔軟性が劣ります。この点で、トレードオフを調整し、最適な決定に到達するには、最適化が必要です。ハイブリッド インフラストラクチャ ネットワークを最適化した研究はほとんどありません。[28] INC を使用してクラウドでのリクエスト受け入れを最大化することに重点を置き、[173] INC を使用して NFV での VNF 導入コストを最小限に抑えることに焦点を当てています。学んだ教訓は、ハイブリッド インフラストラクチャ、特にそのような最適化の観点が欠けている 5G/6G 環境でのコンピューティング割り当ての最適な戦略を決定するには、より多くの研究努力が必要であるということです。

• 最適化: 調査対象の研究のほとんどは、次世代モバイル通信に必要な機能 (5G RAN、モバイル データ コア機能、仮想ネットワーク機能、エッジ インテリジェンスなど) を実装することでネットワーク コンピューティングを活用することを検討しています。ただし、ネットワーク コンピューティングを効果的に利用するには、既存のテクノロジーに加えて、ターゲット コンピューティング環境でシステムまたはアプリケーション関連のパフォーマンス メトリクスを最適化するための最適な戦略を決定するためのソリューションを提供する必要があります。この最適化アプローチを検討した研究はほとんどなく、ほとんどがエッジ コンピューティング [58]、[142]、[145] の範囲内であり、応答時間とリソース利用の最適化に焦点を当てています。学んだ教訓は、特に NFV、クラウド コンピューティング、5G/6G などのテクノロジに関して、さまざまなシステム/アプリケーション関連の標準を最適化するアプローチによるソリューションを提供するには、より多くの研究努力が必要であるということです。これは、高電力汎用コンピューティング ノードから低電力ネットワーク要素への計算のオフロードによる消費電力の最適化にとって特に重要であり、この問題を考慮した唯一の研究は [155] です。エネルギー効率は、特に 6G 設計の重要な焦点であり、6G 強化ネットワーク コンピューティングにエネルギー効率が高く最適化されたリソース割り当てを提供します。これは、将来の研究トレンドと見なすことができます。

次のセクションでは、コンピューティング ノード、パフォーマンス メトリクス、および方法論の観点からさらに比較します。一般に、これらのテクノロジーにおけるネットワーク内処理の適用は、既存のベースのテクノロジーと比較して、QoS 基準 (スループットや遅延の改善など) およびリソース使用率の基準 (消費電力や帯域幅消費の削減など) で優れたパフォーマンスを達成することを目的としています。比較のためのサーバー/専用ハードウェア ソリューション。これらの規格の主な性能は、表 XII、XIII、XIV、および XV に報告されています。比較を容易にするために、表 XVI では、ネットワーク内に実装された機能とサーバー/専用ハードウェアベースのスキームを比較しています。これは、[157]、[169]、[170]、[171]、[ などの多くの研究の比較ベースラインです。 172]。詳細については以下で説明します。

表XVI: 完全にネットワーク化された実装とサーバー/専用ハードウェア ソリューションの技術的機能の比較

表XVII: ハイブリッド コンピューティング環境におけるリソース割り当てスキームの比較

• コンピューティング ノード: サーバー/専用ハードウェア ソリューションは、汎用コンピュータまたは専用ハードウェア (VNF ミドルウェア、gNodeB など) をコンピューティング ノードとして利用します。対照的に、ネットワーク内で実装されるスキームでは、ネットワーク要素はコンピューティング ノードとして重要な役割を果たしますが、ネットワーク要素と他の非ネットワーク要素リソースを組み合わせて利用することも可能です。

• コスト: 既存のデータ プレーン要素で処理を管理し、負荷分散用のサーバー [137]、[140] や専用ハードウェア、たとえば gNodeB [148] などの高コストのコンピューティング リソースを省略することにより、サーバー/専用ハードウェア ソリューションと比較します。 ]、または 5G の SGW や PGW [151] などの 5G の専用ゲートウェイ）、ネットワーク内に実装されるスキームによりコストを削減できます。

• 遅延/スループット: サーバー/専用ハードウェア ベースのソリューションと比較して、ネットワーク内アプローチは、ネットワーク要素の処理能力が高く、計算提案が最終デバイスに近づくため、遅延が低く、スループットが高いソリューションが得られる可能性があります。文献では、ソフトウェア ベースのクラウド ロード バランサと比較してレイテンシが 10 倍短縮されたと報告されています [140]、エッジでの FPGA アクセラレーションによりモバイル アプリケーションではレイテンシが最大 15 倍短縮されました [144]、ステートフル リレーのエンドツーエンド メッセージング レイテンシ/ルーティング ノードの遅延は 6 ミリ秒未満 [58]、ネットワーク内の LTE プロトコル スタックとゲートウェイ処理の遅延は 50 マイクロ秒 [147]、次世代 RAN の分散ユニットの遅延は 50 マイクロ秒未満です。それらの間のローミング時間は、 25%削減されました。スループットの向上の例として、[170]、[171] における現実世界のサービス機能チェーンの評価では、ソフトウェア NFV ソリューションでは、ソフトウェア アプローチのスループットが約 0.01 Mbps であるのに対し、ネットワーク機能を実装すると、約 102 Mbps のスループットが得られます。別の例は、LTE EPC コントロール プレーンの操作をプログラマブル スイッチにオフロードすることにより、スループットが 102 倍増加します [150]。

• 功耗：网络元素的每瓦能量使用的处理能力比云、边缘和NFV环境中的服务器高得多。例如，可编程交换机每瓦使用量可以执行数十亿次操作。然而，大多数调查研究并未评估网络内计算对功耗消耗的影响，需要进行更多的研究评估。[27]的研究表明，通过将高消息交换量的云应用程序卸载到网络或将高功耗应用程序从服务器卸载到网络，与在云计算环境中基于通用CPU的软件系统相比，功耗可提高100倍。此外，[155]报告由于在网络内处理6G任务而实现的节能高达50%。

• 网络内实现方案的缺点：与基于服务器/专用硬件的解决方案相比，网络内实现方案有两个缺点：(i) 由于硬件限制，网络内实现方案在实现具有复杂性或高数据需求的功能方面具有较少的能力。这些功能可以是NFV、云/边缘或新一代通信的应用层功能，以及4G/5G/6G中的无线接入或核心功能。利用除网络元素以外的通用计算单元的共设计方案扩展了网络内解决方案的能力。[15]的研究是一个机器人运动控制应用程序的例子，它将控制矩阵学习卸载到MEC服务器中，同时在可编程交换机中执行矩阵与当前状态向量的乘法。另一个例子是[145]中的机器通信应用程序，它在可编程交换机的网络边缘实现访问控制策略，并将复杂的攻击检测保留在服务器中。考虑到数据量，将虚拟IP分区为直接IP映射元素以用于数据中心中的负载均衡是[140]中使用的一种策略，以应对内存限制。同样，在[150]中，处理LTE EPC移动分组核心过程的用户上下文被分配给多个交换机。

(ii) ネットワーク要素だけでなく非ネットワーク リソース (つまり、クラウド、エッジ、NFV、4G/5G/6G の汎用コンピューティング リソース) を含むハイブリッド コンピューティング環境を検討し、サーバー/専用ハードウェア ソリューションと比較した場合のリソース割り当ての決定を検討します。より複雑になります。[28] の研究は、最大数のクラウド アプリケーションにリソースを割り当てることを目的としていますが、[173] の研究は、VNF の展開を最小限に抑えることを目的としており、リソースの異質性に対処する最適化手法を提案しています。ただし、ネットワーク要素のリソース使用率、ネットワーク要素と一般的なコンピューティング リソース間の通信コスト/時間、ネットワーク要素の処理能力など、高次元の最適化変数が問題に関与する可能性があります。最適化変数が多数あるため、従来の最適化手法は効率的ではない可能性があり、今後の研究では機械学習などのより高度な最適化手法を検討する必要がある可能性があります。

• ネットワーク内実装の欠点: サーバー/専用ハードウェア ソリューションと比較して、ネットワーク内実装には次の 2 つの欠点があります。 (i) ネットワーク内実装は、ハードウェアの制限により、複雑な機能や高いデータ要件を実装する際の効果が低い。 。これらの機能は、NFV、クラウド/エッジ コンピューティング、または次世代通信のアプリケーション レベルの機能、または 4G/5G/6G の無線アクセスまたはコア機能です。ネットワーク要素以外の汎用コンピューティング ユニットを利用した共同設計スキームにより、ネットワーク内部ソリューションの機能を拡張できます。[15] の研究は、プログラマブル スイッチで現在の状態ベクトルとの行列積を実行しながら、制御行列学習を MEC サーバーにオフロードするロボット動作制御アプリケーションの例です。もう 1 つの例は、[145] の研究です。これは、プログラマブル スイッチにアクセス制御ポリシーを実装し、サーバーで高度な攻撃検出を維持します。データ量を考慮して、データセンター内のプログラマブル スイッチ間の負荷分散のために仮想 IP を直接 IP マッピング要素に分割することは、[140] で使用される戦略であり、同様に、ユーザー コンテキストは [150] で、処理を処理するスイッチに分割されます。 LTE EPC モバイル データ コア プロセス。(ii) ネットワーク要素だけでなく非ネットワーク リソース (つまり、クラウド、エッジ、NFV、4G/5G/6G の汎用コンピューティング リソース) を含むハイブリッド コンピューティング環境を考慮すると、リソース割り当ての決定はより複雑になります。[28] の研究では、最大数のクラウド アプリケーションにリソースを割り当てることを目的としており、[173] では VNF 導入を最小限に抑えることを目的として、リソースの異質性に対処するための最適化手法を提案しました。ただし、ネットワーク要素のリソース使用率、ネットワーク要素と一般的なコンピューティング リソース間の通信コスト/時間、ネットワーク要素の処理能力など、高次元の最適化変数が問題に関与する可能性があります。最適化変数の数が多いため、従来の最適化手法は効率的ではない可能性があるため、より高度な機械学習最適化手法の探索が将来の研究の方向性となる可能性があります。

このセクションの最後では、前述の技術の中で INC を使用する既存のリソース割り当てスキームを比較します。調査研究では、[27]、[28]、[58]、[172]、[173] がハイブリッド コンピューティング環境でリソース割り当てを実行しました。彼らは、オンライン方法 [27]、[58] またはオフライン方法 [172]、[173] で割り当てを実行できます。表 XVII は、オンライン スキームとオフライン スキームを比較しています。オンライン ソリューションでは、実行時にリソースが動的に割り当てられます。利点の 1 つは、実行時に割り当てを採用し、ネットワーク リソースと従来のコンピューティング リソースを切り替える機会を提供できることです。たとえば、[27] の研究では、アプリケーションの消費電力やメッセージ交換の変更などのパラメータに応じて、ネットワーク要素とクラウド サーバーの間でアプリケーションの実行を動的に切り替える機会が提供されています。さらに、オンライン方式では、障害が発生した割り当てられたリソースを変更できるため、耐障害性が向上します。スイッチなどのネットワーク要素は障害や輻輳が発生しやすいため、これは非常に重要です。一方、欠点は、実行時のリソース割り当ての決定に伴うオーバーヘッドです。オフライン スキームでは、ネットワーク要素と一般的なコンピューティング リソースがコンパイル時に計算に割り当てられるため、実行時のオーバーヘッドがなく、計算に最適な配置を見つける機能が提供されます。欠点は、実行時の柔軟性がなく、リソース障害が発生した場合のフォールト トレランスがないことです。

VIII. 研究の方向性

このセクションでは、ネットワーク内コンピューティングが成熟するにつれて非常に貴重となる、文献レビューから得られた教訓を中心に、最も重要な研究の方向性について説明します。ネットワーク内分析、ネットワーク内キャッシング、ネットワーク内調整、ネットワーク内セキュリティ、および特定のテクノロジのアプリケーションなど、さまざまなアプリケーションに適用できる研究の方向性を含む、別の一般的な研究方向のセクションを用意します。

A. ネットワーク内分析

ネットワーク内分析は、データが集約のために集中ホストに転送されるホストベースの分析と比較して、ネットワーク内のトラフィック量を削減し、分析時間を短縮できます。いくつかの研究により、データ集約、機械学習、およびリフロー検出、制御、クエリ処理などの他の種類の分析に対するネットワーク内分析の可能性が示されています。

1. 機械学習

少数の研究では、プログラム可能なネットワーク要素に機械学習を実装していますが、これは汎用コンピューターに実装された機械学習方法とは程遠いものです。ニューラル ネットワーク実装の適切な開始点は、[79]、[81] の研究から得られます。ただし、[79] では量子化を利用してニューラル操作を簡素化し、[81] ではバイナリの重みと符号関数を活性化関数として利用しています。これらの単純化は精度の低下につながる可能性があるため、研究の方向性の 1 つは、ネットワーク要素、またはネットワーク要素と汎用コンピューターの混合物にニューラル ネットワークを単純化せずに実装して、精度を損なうことなく推論レイテンシーの低減を達成する実現可能性を調査することです。機械学習研究としてのディープ ニューラル ネットワークの傾向を考慮すると、すべてのニューラル ネットワーク パラメーターの保存はメモリの制約によって制限される可能性があるため、研究の方向性の 1 つは、研究で提案されている手法を利用して、プログラマブル データ プレーン デバイスのメモリ制限を克服することです。それに応じて機械学習の実装を微調整します。[174] の研究では、外部メモリにリモート ダイレクト メモリ アクセス (RDMA) 機能を利用してスイッチのメモリを拡張することが提案されています。著者らは、[175] で、トップスイッチのフローテーブルをラック内の複数のサーバー上のローカルメモリまたは外部メモリに適合させるアーキテクチャを提案しています。外部フロー テーブルには、RDMA を使用してアクセスできます。RDMA は、RDMA ベースのネットワーク アダプタまたは通常のネットワーク アダプタでサポートされています。したがって、興味深い研究の方向性は、メモリ拡張メカニズムの下でディープ ニューラル ネットワークの実装を適応させることです。決定木のネットワーク内実装は、非ニューラル学習方法を考慮して [59]、[117] で行われています。ネットワーク要素に他の非ニューラル学習手法を実装することも、研究の方向性の 1 つになる可能性があります。[78] の研究は、Naive Bayes と SVM の出発点となる可能性があります。ただし、この研究では、必要な数学関数の計算がルックアップ テーブルとしてデバイス内にすでに設定されていることを前提としており、そのような計算に関する詳細は提供していません。完全な非ニューラル学習アプローチを実現するには、プログラム可能なネットワーク要素、またはネットワーク要素と汎用コンピュータの混合物に目的の数学関数を実装できる可能性を調査する必要があります。

2. 共同設計分析

ネットワーク要素の処理とメモリの制限により、すべての種類の分析をネットワーク要素に実装できるわけではありません。さらに、特定の分析に必要な機能を、マッチアクション テーブルなどのネットワーク転送アーキテクチャにマッピングすることが困難または不可能な場合もあります。分析のためにネットワーク要素と非ネットワーク要素 (サーバー、コントローラーなど) を組み合わせて利用する共同設計アプローチは、ネットワーク内分析に非常に有望であると思われます。実装できない機能や操作、または分析が複雑な機能や操作は、汎用コンピューティング ノード (サーバー、コントローラーなど) で実行できます。分析に協調設計アプローチを利用した研究はほとんどありませんでした。たとえば、クエリ処理については、[86] で共同設計アプローチが提案されており、単純な操作はデータ プレーンで実行され、複雑な操作はストリーム プロセッサーによって実行されます。共同設計手法は、特にネットワーク要素への実装が複雑または実行不可能な複雑な判別関数やカーネルベースの計算を使用する機械学習分析の場合、貴重な研究の方向性となります。

B. ネットワーク内キャッシュ

文献の研究 (例: [92]、[93]、[94]、[95]、[96]) は、コンテンツ/アイテムへのアクセスを容易にするためにネットワーク内部キャッシュ構造を利用しています。これらの研究は、コンテンツ/アイテムにアクセスして変更するためのプロトコルを提供します。ただし、効率的なネットワーク内部キャッシュ構造を実現するには、さらに多くの基準を考慮することができます。例えば、コンテンツ／アイテム要求を発信する端末装置はモバイルであってもよい。これに関連して、エンドデバイスの近くにコンテンツを提供するためにネットワーク要素内に格納されたデータを再構成するという問題が発生する可能性があります。ネットワーク内部コンピューティングは初期段階にあるため、私たちが調査した調査には、モバイル カバレッジやネットワーク内部キャッシュ構造の再構成ソリューションが不足しています。キー値ベースの検索システムの場合、コンテンツが複合である (つまり、ネットワーク要素間で分散された複数のキーで構成されている) 場合、この問題はさらに悪化します。したがって、潜在的な研究の方向性は、エンドデバイスのモビリティパターンに従ってネットワークの内部キャッシュに保存されたデータを再構成することを決定するための最適化ソリューションと制御メカニズムを提供することです。

C. ネットワーク内のセキュリティ

ネットワーク内のセキュリティは、ネットワーク内の分析、キャッシュ、調整よりも研究コミュニティの注目を集めています。しかし、調査した研究から得られた教訓にあるように、埋める必要のある研究上のギャップがまだいくつかあります。私たちは、主に調査した研究から得られた教訓に基づいて、考えられる研究の方向性について議論します。

1. 機械学習による攻撃検知

文献に記載されているほとんどの攻撃検出方法は、トラフィック統計 (SYN/ACK パケット統計、TCP/UDP パケットと接続統計、フローとサブネット統計など) を特定のしきい値と組み合わせることによってしきい値ベースになっており、攻撃を検出するために比較が行われます。ただし、機械学習技術はネットワーク要素に実装でき、より高い精度で攻撃検出を処理できます。出発点は、ネットワーク内の攻撃を検出するための [117] のランダム フォレスト アプローチです。他の機械学習手法、特にネットワーク要素で実現可能であることが証明されているニューラル ネットワークは、さまざまなサイバー攻撃を検出するために使用できます。

2. 攻撃の検出/軽減を共同設計する

ネットワーク セキュリティの文脈で調査された研究では、プログラム可能なネットワーク要素を使用してセキュリティ関連機能 (トラフィック統計の推定、特定のトラフィック特性の計算、攻撃の検出、攻撃の緩和など) を実行することで有望な結果が示されています。ただし、各ネットワーク要素は、サービスを提供するローカル トラフィックのトラフィック分散をモデル化できます。ローカルなトラフィック分散では、攻撃の発生を検出するためのパラメータを効果的に決定できません。共同設計アプローチを適用することで、ネットワーク要素を (SDN) コントローラーと組み合わせて、攻撃の検出と軽減に役割を果たすことができます。コントローラーは、ネットワーク要素によって構築されたモデルの全体像を提供できるため、攻撃検出パラメーター (しきい値など) についてより正確な決定を行うことができます。したがって、サイバー攻撃を検出して軽減するためのコントローラーとネットワーク要素の共同設計アプローチは、興味深い研究の方向性となる可能性があります。[104]、[109] で提案されている共同設計アプローチは、攻撃軽減のグローバル モデルを含めることを目的としています。[109] はスプーフィングされたトラフィックのフィルタリングに焦点を当てており、[104] は DDoS 攻撃の軽減に焦点を当てています。共同設計アプローチを検討して、ネットワーク要素やコントローラーなどのグローバル エンティティのコラボレーションを通じてグローバル モデルを詳細化し、ネットワーク内のさまざまな攻撃を軽減することができます。

D. 特定の技術的用途

イントラネットワーク コンピューティングは、クラウド/エッジ コンピューティング、4G/5G、ネットワーク機能の仮想化など、特定のテクノロジに関する研究の 4 分の 1 で使用されています。ただし、イントラネット コンピューティングが成熟する前に、埋める必要のある研究上のギャップがまだいくつかあります。このセクションでは、これらの研究の方向性を紹介します。

1. ハイブリッド環境のオーケストレーション

これらの環境では、ネットワーク インフラストラクチャは、ネットワーク要素 (プログラム可能なスイッチやルーター、FPGA、インテリジェント NIC など) と他のノード (物理計算ノード、仮想マシン、仮想ネットワーク機能など) の組み合わせを含む、さまざまな異種リソースを提供します。ストレージノード）。ネットワーク要素は、ワイヤスピードの処理速度でかなり高い処理速度を提供でき、パス上のパケットを操作できるため、長いパケット トラバーサルの必要がなくなります。ただし、ネットワーク要素は、強力な処理能力とメモリ能力を備えたコンピューティング ノードほど柔軟性がありません。さらに、必要な機能によっては、ネットワーク要素に各ネットワーク機能を実装することが複雑になったり、実行不可能になる場合があります。したがって、貴重な研究の方向性は、目的のアプリケーションを処理するためにさまざまなリソースを調整することであり、これには、目的のアプリケーションを展開するためのリソース割り当てとトラフィック ステアリング ソリューションが必要です。ただし、教訓から学んだように、ほとんどの研究は、[58]、[147]、[150]、[152]、[153]、[165] などのネットワーク要素に目的の機能を実装することに焦点を当てています。[143] の研究では、コンピューティング エッジ ノードにハードウェア アクセラレーションを実装することが決定されましたが、特定の目的関数は最適化されませんでした。リクエストの受け入れを最大化することを目的とした、ネットワーク要素とクラウド コンピューティング ノードの組み合わせにおけるリソース割り当ての研究が [28] で提供されています。[173] の研究では、ネットワーク要素と NFV コンピューティング ノードで構成されるハイブリッド インフラストラクチャにおける VNF 分解が考慮されており、導入コストを最小限に抑えることを目的としています。スループットの最大化、帯域幅の最小化、消費電力の最小化、およびサービスの品質指標 (レイテンシ、信頼性など) などの他の目標を考慮したオーケストレーション方法を提供するには、さらなる研究と努力の価値があります。さらに、現在の技術レベルではオーケストレーションメカニズムが不足しているため、ネットワーク内の内部コンピューティング機能を備えた5G/6Gシステムに適したオーケストレーションメカニズムを提供するための研究が必要です。

2. フォールトトレラントネットワークの内部計算

ネットワーク要素、特にスイッチは輻輳により障害が発生したり使用できなくなったりする可能性があるため、フォールト トレランスはネットワーク内部コンピューティングにとって重要です。モバイル パケット コアまたは 5G RAN をホストするスイッチに障害が発生すると、サービス障害が発生する可能性があります。[15] など、火災検知と警報がスイッチにオフロードされる火災検知のようなアプリケーションでは、スイッチの故障が壊滅的な結果を招く可能性があります。したがって、ネットワーク内のコンピューティング アプリケーションにフォールト トレランス メカニズムを提供することが重要です。私たちが調査する技術領域では、[140]、[150] などのいくつかの研究でフォールト トレランスが考慮されています。ネットワーク内のコンピューティング アプリケーションにフォールト トレラントな技術を提供するには、さらなる研究作業が必要です。

3. コンピューティングの移行

考虑到云、边缘、5G/6G和NFV的技术为终端设备提供服务，终端设备的移动性（例如，车载网络、手机）需要解决方案，使计算能够在接近终端设备的地方进行，以满足应用程序的超低延迟要求。在这方面，由于网络内部计算处于起步阶段，在我们调查的研究中，计算迁移尚未得到研究。在网络内部计算的情况下，计算/任务的迁移需要对目标网络元素进行重新编程。为了避免这种重新编程的额外开销，最初的尝试是[155]中的研究，建议将具有虚拟化环境并配备高性能交换机芯片（用于数据包处理）的主机视为一种网络内部计算节点。然而，[155]中的架构是一个抽象的架构，该论文没有提供详细的讨论或任何评估。一个潜在的研究方向将是提供适用于网络内部计算节点的计算迁移架构和优化解决方案，以便在网络内部计算节点之间迁移计算。

E. 通用研究方向

本节中，我们讨论了可引入的研究方向，这些方向独立于网络计算应用或应用网络计算的特定技术。

1.协作式网络计算

一般的なコンピュータやサーバーとは異なり、ネットワーク要素に関する課題の 1 つは、リソースの不足、つまりコンピューティング能力とストレージの制限です。この点において、スイッチ間の連携に基づいたソリューションの設計は、リソース不足に対処するための貴重な研究の方向性と考えることができます。協調シナリオでは、必要な機能またはデータがネットワーク要素間で分散され、スイッチ間で通信して必要な機能または決定を実行することが期待されます。私たちが調査した研究の多くは、プログラム可能なネットワーク要素に適しており、本質的にコラボレーションを必要としない機能の実装に努めています (例: [119]、[136]、[139]、[151])。ただし、ネットワーク コンピューティングは、単一のデバイスに必要な機能を収容することが不可能な、大きな機能空間を伴うシナリオに適用できる可能性があります。このような協調シナリオの例は、スイッチが DNS サーバーの役割を果たす [176] の研究です。名前空間が大きすぎて単一のスイッチに収まらない場合があるため、反復的な解決策は、あるスイッチから別のスイッチを参照することによって実現されます。貴重な研究の方向性は、協調型ネットワーク コンピューティングを活用して、大きな機能空間を必要とする問題を協調的に解決することです。たとえば、5G/6G モバイル パケットのコア機能のプロビジョニングや NFV でのサービス機能のリンクは、両方とも機能セットの収集を必要とする問題であり、すべての機能が単一のネットワーク要素に収まるわけではないため、協調的なネットワーク コンピューティング アプローチを利用する必要があります。機能するためのすべての可能性を満たします。

2. 適切なネットワーク要素の選択

さまざまなネットワーク要素は、コンピューティング能力、ストレージ容量、およびスループットの点で異なります [13]。したがって、パケットに対して実行される計算のタイプと量、ネットワーク要素によって処理されるファンアウト データのサイズ、状態など、さまざまな基準を使用して、特定のアプリケーションを処理する適切なネットワーク要素を選択できます。ネットワーク上に保存された計算とデータの要素内の必要なサイズ。私たちが調査した研究のほとんどは、ネットワーク コンピューティングの範囲内でプログラマブル スイッチを使用してネットワーク コンピューティングを実装していましたが、ネットワーク要素の選択理由を議論せずに FPGA またはスマート NIC での実装を検討した研究はほとんどありませんでした。したがって、研究の方向性の 1 つは、アプリケーション要件とデバイスの機能を分析して、特定のアプリケーションに適したネットワーク要素の適切な選択指示を提供することです。出発点としては、[13]、[177] の研究が挙げられます。[177] では 7 つの最先端のソフトウェア スイッチの設計空間を調査し、NFV トラフィックをルーティングするための特定のアプリケーションでのパフォーマンスを比較していますが、[13] ではより一般的な観点を取り上げています。実際、[13] は、パケットごとの操作数、パケット処理後に必要なストレージの量、出力サイズなど、いくつかのアプリケーション特性に基づいて、いくつかのアプリケーションを実装するためのガイドラインを提供しています。しかし、提供されたガイドラインを評価するための評価が欠けています。最後に、[13] では、ネットワーク セキュリティ、ネットワーク調整、またはテクノロジ固有のアプリケーションなどのアプリケーションについては触れていません。

3. ネットワーク機器の制限とネットワークコンピューティング

ネットワーク コンピューティング アプリケーションの開発における重要な課題は、ネットワーク要素の計算とストレージの制約です。プログラマブル スイッチなどの現在のネットワーク要素は、非浮動小数点値に対する限られた算術演算のみをサポートします。計算上の制限に対処する方法は、複雑な計算が汎用プロセッサーによって実行される共同設計アプローチを実装することです ([15]、[86] など)。共同設計アプローチを使用すると、レイテンシーは増加しますが、それでも計算の一部はネットワーク内で高いパフォーマンスで実行されます。別のアプローチは、[79]、[81] などの単純化および近似手法を適用することです。このアプローチでは、ネットワーク パフォーマンスの維持を犠牲にして精度を犠牲にします。これらの手法をさらに調査して、計算上の制約に対処することができます。

ネットワーク要素に保存されるデータの量は、オンチップ メモリのサイズによって制限されます (たとえば、プログラマブル スイッチのメモリ容量は数十メガバイトから数百メガバイトの範囲です)。最近、メモリ制約に関するいくつかの機能強化が提案されています。たとえば、[174] は、リモート ダイレクト メモリ アクセス (RDMA) 機能を備えた外部メモリを利用することで、スイッチのメモリ容量を拡張しました。[175] は、ラックサーバーにスイッチを設置することにより、トップスイッチのフローテーブルを拡張することを提案しました。特に、ネットワーク キャッシングやネットワーク分析などのネットワーク コンピューティング アプリケーションは、そのパフォーマンスがアクセス可能なメモリに大きく依存するため、これらの強化されたシナリオの研究アプリケーションに使用できます。

4. ネットワークコンピューティングのパフォーマンス面

文献調査では、サーバー/コントローラー/ソフトウェア ベースのソリューションと比較して、レイテンシとスループットの点でネットワーク ソリューションの優れたパフォーマンスが広く実証されています。ただし、ネットワーク要素 (プログラマブル スイッチ、NIC など) のパフォーマンスは、トラフィック負荷やパケット サイズによって異なる場合があります。たとえば、[169] では、3 つの VNF を持つファイアウォール VNF チェーン アプリケーションが説明されています。パケット サイズが 1280 バイト未満で、すべての VNF がスマート NIC にオフロードされる場合、遅延は 76 分の 1 に短縮されます (ソフトウェアによる)。ソリューションの場合は 3300 マイクロ秒、ウェブ ソリューションの場合は 43 マイクロ秒）。ただし、パケット サイズが増加すると、NIC でのパケット処理が遅延測定に悪影響を与える可能性があります。実際、オフロードされていない場合と完全にオフロードされている場合との間のレイテンシーの改善は、1518 バイトのパケットで約 100 マイクロ秒です。この場合、[169] の著者は、VNF の一部をネットワークにオフロードすることが適切であると考えています。ただし、さまざまなネットワーク トラフィックやパケット サイズのさまざまな条件下でネットワーク コンピューティングのメリットを評価するには、まだ研究の余地があり、さまざまなアプリケーションで研究の方向性が期待できる可能性があります。

IX. 結論

ソフトウェア定義ネットワーキング (SDN)、プログラマブル データ プレーン、エッジ コンピューティング、情報/サービス集中型ネットワークなどのプロトコルにより、ネットワーク コンピューティング (In-Network Computing、INC) が可能になります。本稿はINCの話題を初めて調査したものである。提案された研究分類には、ネットワーク内分析、ネットワーク内キャッシュ、ネットワーク内セキュリティ、ネットワーク内調整、クラウド/エッジ コンピューティング、5G/6G、NFV のテクノロジー固有のアプリケーションが含まれます。関連する調査は、ネットワーク内で実行される計算、完全なネットワーク内実装または共同設計アプローチ、使用されるネットワーク要素/データ構造など、提案された方法論/実装関連の基準と比較され、待ち時間、スループット、帯域幅の節約、電力の観点から比較されます。消費パフォーマンスが向上します。さらに、シナリオ比較のためにアプリケーション固有の基準が提案されています。

私たちの調査によると、INC のアプローチは、サーバー/SDN コントローラー ベースのアプローチと比較して、アプリケーション固有の標準を考慮する場合に利点が得られることが示されています。ネットワーク内分析では、より高速な推論速度を達成し、データ転送に必要な帯域幅の消費を削減できます。ネットワーク内の浅い/深いキャッシュ ソリューションはエッジ ストレージを提供できるため、コンテンツ アクセスの遅延、コンテンツ送信に必要な帯域幅の消費が削減され、リクエスト サービスのバランスが向上します。ネットワーク内のセキュリティ スキームにより、遅延を軽減し、必要なトラフィック分析に必要な帯域幅の消費を削減できます。ネットワーク内にテクノロジーの機能 (例: 次世代モバイル通信用の無線アクセス ネットワーク/モバイル データ コア機能、仮想ネットワーク機能、エッジ インテリジェンス) を実装すると、サーバー/専用ハードウェア ベースのソリューションと比較して、必要なコンピューティングのコストと消費電力が削減されます。 、より低いレイテンシーとより高いスループットを実現します。

ただし、私たちの調査では、ネットワーク要素のハードウェア制限により侵害される可能性のあるアプリケーション固有の標準が存在することが示されています。アプリケーション カテゴリごとに、標準を侵害し、ハードウェアの制限に対処するための技術が調査研究で広く議論されています。さらに、汎用コンピューティングで INC を強化するためのメカニズムとして共同設計アプローチが調査され、さまざまなアプリケーション クラスについて、完全なネットワーク内実装スキームに対するアプリケーション固有の基準の利点と妥協点が議論されています。混合コンピューティング環境に対処するために、テクノロジー固有のアプリケーションのリソース割り当てシナリオの補足評価も提供されます。

最後に、この新興分野における潜在的な研究の方向性について説明します。

引用

[1] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: State-of-the- art and research challenges,” J. Internet Services Appl., vol. 1, pp. 7– 18, Apr. 2010.
[2] V. Ziegler et al., “6G architecture to connect the worlds,” IEEE Access, vol. 8, pp. 173508– 173520, 2020.
[3] M. Agiwal, A. Roy, and N. Saxena, “Next generation 5G wireless
networks: A comprehensive survey,” IEEE Commun. Surveys Tuts., vol. 18, no. 3, pp. 1617– 1655, 3rd Quart., 2016.
[4] “Amazon Cloud Service.” [Online]. Available: https://aws.amazon.com/ ec2/instance-types/
[5] C. Mouradian et al., “A comprehensive survey on fog computing: State-of-the-art and research challenges,” IEEE Commun. Surveys Tuts., vol. 20, no. 1, pp. 416–464, 1st Quart., 2018.
[6] AJ Ferrer、JM Marquès、J. Jorba、「分散型
クラウドに向けて: モバイル、アドホック、エッジ コンピューティングのアプローチと課題に関する調査」、ACM Comput。調査、vol. 51、いいえ。[ 7 ] M. Mehrabi et al.、「デバイス拡張 MEC: エンド デバイスの
計算とキャッシュによる
マルチアクセス エッジ コンピューティング
(MEC): 調査」、IEEE Access 、vol. [ 8
] BAA Nunes 他、「ソフトウェア定義ネットワーキングの調査:
プログラマブル ネットワークの過去、現在、未来」、IEEE Commun. Surveys Tuts.、vol. 16、いいえ。
[9] N. McKeown 他、「OpenFlow: キャンパス ネットワークにおけるイノベーションの実現」、ACM SIGCOMM Comput . 共通。Rev.、vol. 38、いいえ。2、69–74ページ、2008年。
[10] R. Bifulco および G. Rétvári、「プログラマブル データ プレーンに関する調査:
抽象化、アーキテクチャ、および未解決の問題」、Proc. 会議 ハイパフォーマンス。スイッチ。ルーティング、2018 年、1 ～ 7 ページ。
[11] S. Han、S. Jang、H. Choi、H. Lee、および S. Pack、「
プログラマブル データ プレーンの仮想化: 調査と未解決の課題」、IEEE J. Commun. 学会、vol.
[12] A. Sapio et al.、「ネットワーク内計算は時代が来た愚かなアイデアです」、Proc. 1、527–534、2020 。会議 Hot Topics Netw.、2017 年、150 ～ 156 ページ。
[13] DR Ports と J. Nelson、「いつネットワークをコンピュータにするべきですか?」手順で。会議 話題のオペラ。システム、2019 年、209 ～ 215 ページ。
[14] 「インテル第 2 世代プログラマブル スイッチ」。[オンライン]。利用可能: https://www.intel.com/content/www/us/en/products/network-io/programmable-ethernet-switch

[15] T. Mai, H. Yao, S. Guo, and Y. Liu, “In-network computing powered
mobile edge: Toward high performance industrial IoT,” IEEE Netw., vol. 35, no. 1, pp. 289–295, Jan./Feb. 2021.
[16] “Sigarch.” [Online]. Available: https://www.sigarch.org/in-network- computing-draft/
[17] H. Stubbe, “P4 compiler & interpreter: A survey,” J. Future Internet Innov. Internet Technol. Mobile Commun., vol. 47, pp. 1–6, May 2017.
[18] E. Kaljic, A. Maric, P. Njemcevic, and M. Hadzialic, “A survey on data plane flexibility and programmability in software-defined networking,” IEEE Access, vol. 7, pp. 47804–47840, 2019.
[19] X. Zhang、L. Cui、K. Wei、FP Tso、Y. Ji、および W. Jia、「ソフトウェア定義ネットワークにおけるステートフル データ プレーンに関する調査」、J. Comput. ネット、vol. 184、2021 年 1 月、アート。いいえ。
[20] T. Dargahi 他、「ステートフル SDN データ プレーンのセキュリティに関する調査」、IEEE Commun . Surveys Tuts.、vol. 19、いいえ。
[21] WL da Costa Cordeiro、JA Marques、LP Gaspary、「OpenFlow を超えるデータプレーン プログラマビリティ: ネットワークとサービスの
運用と管理の機会と課題」 Ｊ．Ｎｅｔｗ．システム。管理、vol. 25、いいえ。
[22] EF Kfory、J. Crichigno、および E. Bou-Harb、「徹底的な調査」
vey on P4 programmable data plane switches: Taxonomy, applications, challenges, and future trends,” IEEE Access, vol. 9, pp. 87094–87155,
2021.
[23] M. G. Venkata, G. Bloch, G. Shainer, and R. Graham, “Accelerating OpenSHMEM collectives using in-network computing approach,” in Proc. Symp. Comput. Architect. High Perform. Comput., 2019, pp. 212–219.
[24] E. Bulut and M. Yuksel, “Integrating in-network computing for secure
and efficient cascaded delivery in DTNs,” in Proc. Workshop Netw.
Meets Intell. Comput., 2019, pp. 19–24.
[25] I. Kettaneh et al., “Falcon: Low latency, network-accelerated schedul- ing,” in Proc. P4 Workshop Europe, 2020, pp. 7– 12.
[26] F. Yang et al., “Understanding the performance of in-network comput-
ing: ケーススタディ」、Proc. IEEE会議 並列配布。プロセス。応用 ビッグデータ クラウド コンピューティング。保つ。計算します。共通。社会 計算します。
Netw.、2019、26–35 ページ。
[27] Y.トクサシら、「オンデマンドでのネットワーク内コンピューティングのケース」、Proc. EuroSys Conf.、2019、pp. 1–16.
[28] M. Blöcher、L. Wang、P. Eugster、および M. Schmidt、「Switches for HIRE: Resource scheduling for data center in-network Computing」、Proc 。ACM会議 アーキット。サポートプログラム。ラング。オペラ。Syst.、2021、268–285 ページ。
[29] RL Graham 他、「スケーラブル階層集約プロトコル
(SHARP): 効率的なデータ削減のためのハードウェア アーキテクチャ」、Proc. ワークショップコミュ。最適。HPC、2016 年、1 ～ 10 ページ。
[30] T. A. Benson, “In-network compute: Considered armed and dangerous,” in Proc. Workshop Hot Topics Oper. Syst., 2019, pp. 216–224.
[31] P. G. Kannan and M. C. Chan, “On programmable networking evolution,” CSI Trans. ICT, vol. 8, pp. 69–76, May 2020.
[32] A. Doria et al., “Forwarding and control element separation (ForCES)
protocol specification,” IETF, RFC 5810, 2010.
[33] “Floodlight, An Open SDN Controller.” [Online]. Available: https:// floodlight.atlassian.net/wiki/spaces/floodlightcontroller/overview
[34] “Beacon.” [Online]. Available: https://openflow.stanford.edu/display/ beacon/home
[35] MR Nascimento 他、「サービスとしての仮想ルーター: ソフトウェア定義ネットワークを活用したルートフロー アプローチ」、Proc. 会議 『Future Internet Technology』、2011 年、34 ～ 37 ページ。
[36] A. Doria et al.、「転送および制御要素分離 (ForCES)
プロトコル仕様」、IETF、RFC 5810、2010。
[37] 「Barefoot Tofino: World's Fastest P4-Programmable Ethernet Switch ASICs」。[オンライン]。入手可能: https://www.intel.com/content/www/us/en/products/network-io/programmable-ethernet-switch/tofino-series/tofino.html
[38] 「XPliant イーサネット スイッチ製品ファミリー」。[オンライン]。利用可能: https://www.openswitch.net/cavium/
[39] 「インテル FlexPipe」。[オンライン]。入手可能: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-switch-fm6000-series-brief.pdf
[40] B. Pfaff et al. 、「Open vSwitch の設計と実装」、Proc. USENIX の症状 ネット。システム。Design Implement.、2015 年、117 ～ 130 ページ。
[41] M. Shahbaz et al.、「Pisces: A Programmable, Protocol-independent software switch」、Proc. ACM SIGCOMM Conf.、2016、525 ～ 538 ページ。
[42] A. Panda et al.、「NetBricks: Take the V out of NFV」、Proc.USENIX Symp. オペラ。システム。「設計の実装」、2016 年、203 ～ 216 ページ。
[43] 「BMv2 ソフトウェア スイッチ」。[オンライン]。入手可能: http://bmv2.org/
[44] N. Gebara et al.、「プログラマブル スイッチのステートレスな現状への挑戦」、Proc. ACM ワークショップ ホット トピックス ネットワーク、2020 年、153 ～ 159 ページ。
[45] P. Shantharama、AS Thyagaturu、および M. Reisslein、「
ネットワーク機能のためのハードウェア アクセラレーション プラットフォームとインフラストラクチャ: 実現テクノロジーと調査研究の調査」、IEEE Access、vol.
[46] O. Michel、R. Bifulco、G. Retvari、および S. Schmid、「プログラム可能なデータ プレーン: 抽象化、アーキテクチャ、アルゴリズム、およびアプリケーション」 、
ACM Comput. 調査、vol. 54、いいえ。
[47] N. Zilberman、Y. Audzevich、GA Covington、および AW Moore、
「NetFPGA SUME: 研究商品としての 100 Gbps に向けて」、IEEE Micro、vol. 4、pp. 1–36、2021 。34、いいえ。5、32–41ページ、9月/10月 [48] A. Forencich、AC Snoeren
、G. Porter、および G. Papen、「Corundum: An open-source 100-Gbps NIC」、Proc. 症状 フィールドプログラム。カスタム
計算します。2020 年 3 月、38 ～ 46 ページ。
[49] GP Katsikas、T. Barbette、M. Chiesa、D. Kosti、および GQ Maguire、
「(SMART) ネットワーク インターフェイス カードについて知っておくべきこと」、Proc. 会議 パッシブアクティブネットワーク。Meas.、2021、319–336 ページ。
[50] PM Phothilimthana 他、「FLOEM: NIC アクセラレーション ネットワーク アプリケーション用プログラミング システム」、Proc. USENIX の症状 オペラ。システム。「設計の実装」、2018 年、663 ～ 679 ページ。
[51] S. Choi、M. Shahbaz、B. Prabhakar、および M. Rosenblum、「λ-NIC:
プログラマブル SmartNIC 上の対話型サーバーレス コンピューティング」、Proc. 会議 配布します。計算します。システム、2020、67–77 ページ。
[52] 「P4: 言語仕様」。[オンライン]。利用可能: https://opennetworking.org/wp-content/uploads/2020/10/P416-言語仕様.html#fig-p4prg
[53] G. Bianchi、M. Bonola、A. Capone、および C. Cascone、「OpenState:
スイッチ内のプラットフォームに依存しないステートフル OpenFlow アプリケーションのプログラミング」、ACM SIGCOMM Comput. 共通。Rev.、vol. 44、いいえ。
[54] A. Sivaraman et al.、「Packet trans.: High-level programming for line-rate switchs」、Proc. 2、pp. 44–51、2014 。ACM SIGCOMM Conf.、2016、15 ～ 28 ページ。
[55] CJ Anderson 他、「NetKAT: ネットワークのセマンティック基盤」、ACM Sigplan Notices、vol. 49、いいえ。[ 56
] P. Bosshart et al.、「P4: プロトコルに依存しないパケット プロセッサのプログラミング」、ACM SIGCOMM Comput. 共通。Rev.、vol. 44、いいえ。3、87–95ページ、2014年。
[57] M. Satyanarayanan、P. Bahl、R. Caceres、および N. Davies、「モバイル コンピューティングにおける VM ベースのクラウドレットの事例」、IEEE Pervasive Comput.、vol. 8、いいえ。4、14～23ページ、10月～12月 [58] S. Ali、M. Pandey、および N. Tyagi、「ワイヤレスフォグ メッシュ:半永久
的なスマート環境におけるマイクロサービスのネットワーク内コンピューティングのフレームワーク」、J. Netw. 管理、vol. 30、いいえ。6、2020、アート。いいえ。e2125。
[59] X. Zhang、L. Cui、FP Tso、および W. Jia、「pHeavy: プログラマブル データ プレーンでの大量のフローの予測」、IEEE Trans. ネット。サービスマネジメント、vol. 18、いいえ。[60] Y. Afek、A. Bremler-Barr、L. Shafir、「 SDN データ プレーン
を使用したネットワークのアンチスプーフィング」、Proc . 4、pp. 4353–4364、2021 年 12 月。
会議 計算します。Commun.、2017、1–9 ページ。
[61] T.-Y. Lin et al.、「SYN フラッディング攻撃と ARP スプーフィングの軽減」
SDN data plane,” in Proc. Asia–Pac. Netw. Oper. Manag. Symp., 2020, pp. 114– 119.
[62] A. Yazdinejad, R. M. Parizi, A. Dehghantanha, and K.-K. R. Choo, “P4-to-blockchain: A secure blockchain-enabled packet parser for soft- ware defined networking,” J. Comput. Security, vol. 88, Jan. 2020, Art. no. 101629.
[63] A. Morrison, L. Xue, A. Chen, and X. Luo, “Enforcing context-aware BYOD policies with in-network security,” in Proc. USENIX Workshop Hot Topics Cloud Comput., 2018, pp. 1–9.
[64] Q. Kang et al., “Programmable in-network security for context-aware
BYOD policies,” in Proc. USENIX Security Symp., 2020, pp. 595–612.
[65] V. Kalogeraki, D. Gunopulos, and D. Zeinalipour-Yazti, “A local search mechanism for peer-to-peer networks,” in Proc. Conf. Inf. Knowl.
Manag., 2002, pp. 300–307.
[66] Q. Lv et al., “Search and replication in unstructured peer-to-peer networks,” in Proc. Conf. Supercomput., 2002, pp. 84–95.
[67] M. Gritter and D. R. Cheriton, “An architecture for content routing support in the Internet,” in Proc. Symp. Internet Technol. Syst., vol. 1,
2001, pp. 37–48.
[68] G. Xylomenos et al., “A survey of information-centric networking research,” IEEE Commun. Surveys Tuts., vol. 16, no. 2, pp. 1024– 1049, 2nd Quart., 2013.
[69] X. Li, R. Xie, F. R. Yu, T. Huang, and Y. Liu, “Advancing software- defined service-centric networking toward in-network intelligence,” IEEE Netw., vol. 35, no. 5, pp. 210–218, Sep./Oct. 2021.
[70] A. Nasrallah et al., “Ultra-low latency (ULL) networks: The IEEE
TSN および IETF DetNet 標準と関連する 5G ULL 研究」、IEEE Commun. Surveys Tuts.、vol. 21、いいえ。[ 71
] R. Ahmed および R. Boutaba、「大規模分散システムにおける分散検索技術の調査」、IEEE Commun. Surveys Tuts.、vol. 13、いいえ。[ 72
] A. Biswas、S. Mohan、および R. Mahapatra、「セマンティック ルーティング テーブルの最適化」、Proc. 会議 計算します。共通。Netw.、2008 年、1 ～ 6 ページ。
[73] RF Martins、FL Verdi、R. Villaça、および LFU Garcia、「マルチテナント P4 ベースのネットワークの監視に確率的データ構造を使用する」、Proc. IEEE 記号。計算します。Commun.、2018、204–207 ページ。
[74] F. Yang 他、「SwitchAgg: ネットワーク内コンピューティングへのさらなるステップ」、Proc. IEEE会議 並列配布。プロセス。応用 ビッグデータ クラウド コンピューティング。保つ。計算します。共通。社会 計算します。Netw.、2019、36–45 ページ。
[75] ALR Madureira、FRC Araújo、および LN Sampaio、「
プログラマブル データ プレーンによる IoT データ アグリゲーションのサポートについて」、J. Comput. ネット、vol. 177、2020年8月、アート。いいえ。[ 76
] C. Li および H. Dai、「ノイズの多い無線チャネルを使用した効率的なネットワーク内コンピューティング」、IEEE Trans. モバイル コンピューター、vol. 12、いいえ。
[77] C. Li et al.、「ノイズの多い無線チャネルを使用したネットワーク内コンピューティングの効率的な設計に向けて」、Proc. 11、pp. 2167–2177、2013 年 11 月。IEEE INFOCOM Conf.、2010、1 ～ 8 ページ。
[78] Z. Xiong と N. Zilberman、「スイッチは機械学習の夢を見るか?」ネットワーク内分類に向けて」、Proc. ACM ワークショップ ホット トピックス ネットワーク、2019 年、25 ～ 33 ページ。
[79] D. Sanvito、G. Siracusano、R. Bifulco、「ネットワークは AI アクセラレータになり得るか?」手順で。ネットでのワークショップ。Comput.、2018 年、20 ～ 25 ページ。
[80] Y.-S. ルーとKC-J。Lin、「ソフトウェア スイッチ内での推論の有効化」、Proc. アジア - 太平洋 ネット。オペラ。管理。Symp.、2019 年、1 ～ 4 ページ。
[81] Q. Qin、K. Poularakis、KK Leung、および L. Tassiulas、「フェデレーテッド ラーニングによるネットワーク エッジでの回線速度およびスケーラブルな侵入検出」、Proc. ネット。会議、2020、352–360ページ。
[82] V. Sivaraman et al.、「データ プレーン内で完全にヘビーヒッター検出」、Proc. 症状 SDN Res.、2017、164 ～ 176 ページ。
[83] R. Harrison、Q. Cai、A. Gupta、および J. Rexford、「コモディティ スイッチによるネットワーク全体のヘビー ヒッター検出」、Proc. 症状 SDN Res.、2018 年、1 ～ 7 ページ。
[84] J. Vestin、A. Kassler、J. Åkerberg、「FastReact: プログラマブル データ プレーンを使用した産業用制御ネットワークのネットワーク内制御とキャッシュ」、Proc. 会議 出現。テクノロジー。ファクトリーオートメーション、vol. 1、2018、219–226ページ。
[85] FER Cesen 他、「プログラマブル データ プレーンにおける低遅延産業用ロボット制御に向けて」、Proc. IEEE会議 ネット。[ 86
] A. Gupta et al.、「Sonata: Query-driven streaming network telemetry」、
Proc. ACM Special Interest Group Data Commun.、2018 年、357 ～ 371 ページ。
[87] R. Teixeira、R. Harrison、A. Gupta、および J. Rexford、「PacketScope:
スイッチ内のパケットのライフサイクルの監視」（Proc. 症状 SDN Res.、2020、76–82 ページ。
[88] T. Jepsen et al.、「高速車線での生活: ラインレートの直線道路」、Proc.
症状 SDN Res.、2018 年、1 ～ 7 ページ。
[89] T. Kohler et al.、「P4CEP: ネットワーク内の複雑なイベント処理に向けて」、Proc. ネットでのワークショップ。Comput.、2018 年、33 ～ 38 ページ。
[90] J. Hypolite 他、「DeepMatch: ネットワーク プロセッサを使用したデータ プレーンでの実用的なディープ パケット インスペクション」、Proc. 会議 出現。ネット。経験値 Technol.、2020、336–350 ページ。
[91] Y. トクサシ、H. マツタニ、および N. Zilberman、「LAKE: ネットワーク内コンピューティングの力」、Proc. 会議 再構成します。計算します。FPGA、2018、1 ～ 8 ページ。
[92] Q. Wang 他、「Concordia: ネットワーク内キャッシュ コヒーレンスを備えた分散共有メモリ」、Proc. USENIX 会議 ファイル ストレージ テクノロジー、2021 年、277 ～ 292 ページ。
[93] X. Jin et al.、「Netcache: Balancing Key-Value Stores with fast in-network caching」、Proc. 症状 オペラ。システム。Principle、2017 年、121 ～ 136 ページ。
[94] M. Liu et al.、「Incbricks: Toward in-network computation with an in-network Cache」、Proc. 会議 アーキット。サポートプログラム。ラング。オペラ。システム、2017 年、795 ～ 809 ページ。
[95] Z. Liu 他、「Distcache: 分散キャッシュを使用した大規模ストレージ システムの証明可能な負荷分散」、Proc. USENIX 会議 File Storage Technol.、2019 年、143 ～ 157 ページ。
[96] X. Jin et al.、「NetChain: Scale-free sub-RTT 調整」、Proc.USENIX Symp. ネット。システム。「設計の実装」、2018 年、35 ～ 49 ページ。

[97] V. Jacobson et al.、「Networkingnamed content」、Proc. 会議 出現。
ネット。経験値
[98] D. Scholz、S. Gallenmüller、H. Stubbe、および G. Carle、「プログラマブル データ プレーンにおける SYN フラッド防御」、Proc . P4 ワークショップ ヨーロッパ、2020 年、13 ～ 20 ページ。[99] F. Musumeci et al.、「 P4 言語による
機械学習支援 DDoS 攻撃検出」、Proc.
会議 Commun.、2020、1–6 ページ。
[100] J. Xing、W. Wu、および A. Chen、「
FastFlex を使用したネットワークへのプログラム可能なデータ プレーン防御の構築」、Proc. ACM Workshop Hot Topics Netw.、2019 年、161 ～ 169 ページ。
[101] Â 。C. Lapolli、JA Marques、LP Gaspary、「リアルタイムのオフロード」
DDoS attack detection to programmable data planes,” in Proc. Symp. Integr. Netw. Service Manag., 2019, pp. 19–27.
[102] L. A. Q. González et al., “BUNGEE: An adaptive Pushback mechanism
for DDoS detection and mitigation in P4 data planes,” in Proc. Symp. Integr. Netw. Manag., 2021, pp. 393–401.
[103] X. Z. Khooi, L. Csikor, D. M. Divakaran, and M. S. Kang, “DIDA: Distributed in-network defense architecture against amplified reflection DDoS attacks,” in Proc. Conf. Netw. Softw., 2020, pp. 277–281.
[104] K. Friday, E. Kfoury, E. Bou-Harb, and J. Crichigno, “Towards a uni- fied in-network DDoS detection and mitigation strategy,” in Proc. IEEE Conf. Netw. Softw., 2020, pp. 218–226.
[105] M. Zhang et al., “Poseidon: Mitigating volumetric DDoS attacks with programmable switches,” in Proc. Conf. NDSS, 2020, pp. 1–9.
[106] Z. Liu et al., “JAQEN: A high-performance switch-native approach for
detecting and mitigating volumetric DDoS attacks with programmable switches,” in Proc. USENIX Security Symp., 2021, pp. 37–48.
[107] X. Yang, J. Cao, and M. Xu, “SEC: Secure, efficient, and compatible source address validation with packet tags,” in Proc. Perform. Comput. Commun. Conf., 2020, pp. 1–8.
[108] H. Gondaliya, G. C. Sankaran, and K. M. Sivalingam, “Comparative evaluation of IP address anti-spoofing mechanisms using a P4/NetFPGA-based switch,” in Proc. P4 Workshop Europe, 2020, pp. 1–6.
[109] G. Li et al.、「NETHCF: ラインレートと適応型スプーフィング IP トラフィック フィルタリングの有効化」、Proc. IEEE会議 ネット。Protocols、2019 年、1 ～ 12 ページ。
[110] J. Bai、J. Bi、M. Zhang、および G. Li、「
スイッチング ASIC を使用したスプーフィング IP トラフィックのフィルタリング」、Proc. ACM シグコム会議 ポスターデモ、2018 年、51 ～ 53 ページ。
[111] P. Kuang、Y. Liu、および L. He、「P4DAD:
P4 を使用した重複アドレス検出の保護」、Proc. IEEE会議 Commun.、2020、1–7 ページ。[112] M. Dimolianis、A. Pavlidis、および V. Maglaris、「 P4 ネットワーク ハードウェア上の
複数機能 DDoS検出スキーマ」、Proc.
会議 イノヴ。クラウド インターネット ネットワーク。ワークショップ、2020、1 ～ 6 ページ。
[113] P. Vörös et al.、「T4P4S: プロトコルに依存しないパケット プロセッサのためのターゲットに依存しないコンパイラ」、Proc. 会議 ハイパフォーマンス。スイッチ。ルーティング、2018 年、1 ～ 8 ページ。
[114] C. Monsanto et al.、「ソフトウェア定義ネットワークの構成」、Proc.
USENIX の症状 ネット。システム。Design Implement.、2013 年、1 ～ 13 ページ。
[115] P. Vörös および A. Kiss、「P4 を使用したセキュリティ ミドルウェア プログラミング」、Proc. 会議 ヒューマンアスペクト情報 『セキュリティ プライバシー トラスト』、2016 年、277 ～ 287 ページ。
[116] R. Datta、S. Choi、A. Chowdhary、および Y. Park、「P4Guard: Designing
P4 based firewall」、Proc. IEEEミル. 共通。会議、2018 年、1 ～ 6 ページ。
[117] J.-H. Lee および K. Singh、「SwitchTree: ランダム フォレストを使用したネットワーク内コンピューティングとトラフィック分析」、J. Neural Comput. Ａｐｐｌ．、ｖｏｌ．2020、1 ～ 12 ページ、2020 年 5 月。
[118] T. Datta、N. Feamster、J. Rexford、および L. Wang、「SPINE: ネットワーク要素における監視保護」、Proc. USENIX ワークショップの無料公開コミュニティ。インターネット、2019 年、1 ～ 9 ページ。[119] D. Chang、W. Sun、および Y. Yang、「 IP 変換に基づく
SDN プロアクティブ防御メカニズム」、Proc.
会議 安全性農産物の情報化、2019 年、248 ～ 251 ページ。
[120] G. Liu et al.、「P4NIS: プログラマブル データ プレーンによる盗聴に対するネットワーク耐性の向上」、Proc. IEEE会議 計算します。共通。ワークショップ、2020、91–96 ページ。
[121] J. Xing、A. Morrison、および A. Chen、「NetWarden: パフォーマンスを損失せずにネットワークの秘密チャネルを軽減する」、Proc. USENIX ワークショップのホット トピック クラウド コンピューティング、2019 年、1 ～ 7 ページ。
[122] A. Laraba et al., “Defeating protocol abuse with P4: Application to explicit congestion notification,” in Proc. Netw. Conf., 2020, pp. 431–439.
[123] N. Moustafa and J. Slay, “UNSW-NB15: A comprehensive data set for network intrusion detection systems,” in Proc. Mil. Commun.Inf. Syst. Conf., 2015, pp. 1–6.
[124] A. El Kamel, H. Eltaief, and H. Youssef, “On-the-fly (D)DoS attack mitigation in SDN using deep neural network-based rate limiting,” J. Comput. Commun., vol. 182, pp. 153– 169, Jan. 2022.
[125] H. T. Dang et al., “NetPaxos: Consensus at network speed,” in Proc.
ACM SIGCOMM Symp. Softw. Defined Netw. Res., 2015, pp. 1–7.
[126] H. T. Dang, M. Canini, F. Pedone, and R. Soulé, “Paxos made switch- Y,” ACM SIGCOMM Comput. Commun. Rev., vol. 46, no. 2, pp. 18–24,
2016.
[127] HT Dang 他、「P4xos: ネットワーク サービスとしてのコンセンサス」、IEEE/ACM Trans. ネット、vol. 28、いいえ。[ 128
] J. Li、E. Michael、NK Sharma、A. Szekeres、DR Ports、「
Paxos のオーバーヘッドには NO と言いましょう: コンセンサスをネットワーク順序に置き換え、 」Proc。USENIX の症状 オペラ。システム。「設計の実装」、2016 年、467 ～ 483 ページ。
[129] Y. チャン、B. ハン、Z.-L. Zhang、V. Gopalakrishnan、「ネットワーク
支援 RAFT コンセンサス アルゴリズム」、Proc. SIGCOMM ポスター デモ、2017 年、94 ～ 96 ページ。
[130] M. Kogias および E. Bugnion、「HovercRaft: マイクロ秒スケールのデータセンター サービスのスケーラビリティとフォールト トレランスの達成」、Proc. 会議 計算します。システム、2020 年、1 ～ 17 ページ。
[131] E. Saic et al.、「P4BFT: フォールト トレラント ネットワーク コントロール プレーンにおけるハードウェア アクセラレーションによる BFT のデモンストレーション」、Proc. ACM SIGCOMM ポスター デモ、2019 年、6 ～ 8 ページ。
[132] E. Saic、N. Deric、E. Goshi、および W. Kellerer、「P4BFT: ハードウェア アクセラレーションによるビザンチン復元力のあるネットワーク コントロール プレーン」、Proc. IEEE グローバル コミューン。会議、2019 年、1 ～ 7 ページ。
[133] S. Han、S. Jang、H. Lee、および S. Pack、「分散ソフトウェア定義ネットワークにおけるスイッチ中心のビザンチン耐障害性メカニズム」、IEEE Commun. Lett.、vol. 24、いいえ。
[134] Z. Yu 他、「Netlock: プログラマブル スイッチを使用した高速で集中的なロック管理」、Proc. 10、pp. 2236–2239、2020 年 10 月。ACM 特別利益団体データ コミュニティ 応用 テクノロジー。アーキット。プロトコルの計算。Commun.、2020、126–138 ページ。
[135] J. Li, E. Michael, and D. R. Ports, “ERIS: Coordination-free consistent trans. using in-network concurrency control,” in Proc. Symp. Oper. Syst. Principle, 2017, pp. 104– 120.
[136] Z. István, D. Sidler, G. Alonso, and M. Vukolic, “Consensus in a box:
Inexpensive coordination in hardware,” in Proc. USENIX Symp. Netw. Syst. Design Implement., 2016, pp. 425–438.
[137] R. Miao et al., “SilkRoad: Making stateful layer-4 load balancing fast
and cheap using switching ASICs,” in Proc. ACM Special Interest Group Data Commun., 2017, pp. 15–28.
[138] J.-L. Ye, C. Chen, and Y. H. Chu, “A weighted ECMP load balancing
scheme for data centers using P4 switches,” in Proc. Conf. Cloud Netw.,
2018, pp. 1–4.
[139] M. Kogias et al.、「R2P2: Making RPCs 'first-class datacenter Citizen」、Proc. USENIXアンヌ。技術。会議、2019 年、863 ～ 880 ページ。
[140] R. Gandhi 他、「DUET: ハードウェアとソフトウェアを使用したクラウド スケールの負荷分散」、ACM SIGCOMM Comput. 共通。Rev.、vol. 44、いいえ。
[141] Z. Wu および HV Madhyastha、「クラウド サービス マーケットプレイスの再考」、Proc . 4、27 ～ 38 ページ。Workshop Hot Topics Netw.、2016 年、134 ～ 140 ページ。
[142] G. Lia et al.、「データ交換を最小限に抑えたエッジでの遅延制約のあるネットワーク内コンピューティング タスクの最適な配置」、Proc. IEEE 5G 世界フォーラム、2021 年、481 ～ 486 ページ。
[143] RA Cooke および SA Fahmy、「異種ハードウェアを使用した分散型ネットワーク内およびニアエッジ コンピューティングのモデル」、J. Future Gener。計算します。システム、vol. 105、395–409ページ、2020年4月。
[144] C. Xu et al.、「FPGA ベースのエッジ コンピューティングのケース」、IEEE Trans. モバイル コンピューター、vol. 21、いいえ。
[145] F. Song 他、「大規模マシン通信における内生アクセス制御のためのスマート コラボレーション コントラクト」、IEEE Internet Things J.、早期アクセス、2021 年 12 月 10日、土井：10.1109/JIOT.2021.3134366。
[146] Y. Zhang 他、「プライバシーが保証された FogCS: フォグ コンピューティングにおける安全な産業用ビッグ画像データ処理のためのカオス圧縮センシング」、IEEE Trans. インド情報、vol. 17、いいえ。[ 147
] A. Aghdai、M. Huang、D. Dai、Y. Xu、および J. Chao、「モバイル ネットワーク向けの透過的なエッジ ゲートウェイ」、Proc. 会議 ネット。プロトコル、2018 年、412 ～ 417 ページ。
[148] P. Vörös、G. Pongrácz、S. Laki、「次世代のハイブリッドに向けて」
NodeB」、Proc. P4 ワークショップ ヨーロッパ、2020 年、56 ～ 58 ページ。
[149] P. Palagummi および KM Sivalingam、「SMARTHO: P4 ベースのスイッチを使用した NG-RAN でのネットワーク開始ハンドオーバー」、Proc. 会議 ネット。サービス管理、2018 年、338 ～ 342 ページ。
[150] R. Shah、V. Kumar、M. Vutukuru、および P. Kulkarni、「TurboEPC: データプレーン プログラマビリティを活用してモバイル パケット コアを加速する」、Proc. 症状 SDN Res.、2020、83–95 ページ。
[151] SK Singh、CE Rothenberg、G. Patra、および G. Pongracz、「仮想進化型パケット ゲートウェイ ユーザー プレーン機能をプログラマブル ASIC にオフロードする」、Proc. ワークショップエマーグ。ネットで。計算します。『パラダイム』、2019 年、9 ～ 14 ページ。
[152] C.-A. Shen et al.、「5G ネットワークにおけるモバイル エッジ コンピューティング用のプログラム可能で FPGA で高速化された GTP オフロード エンジン」、Proc. 会議 計算します。共通。Workshops、2019、pp. 1021–1022。
[153] F. Paolucci et al.、「強化された 5G モバイル エッジ コンピューティングのための P4 スイッチのユーザー プレーン機能オフロード」、Proc. 会議 デザインリリース 共通。Netw.、2021、1 ～ 3 ページ。
[154] R. Ricart-Sanchez、P. Malagon、JM Alcaraz-Calero、および Q. Wang、「5G MEC アーキテクチャ用の P4-NetFPGA ベースのネットワーク スライシング ソリューション」、Proc. 症状 アーキット。ネット。共通。システム、2019 年、1 ～ 2 ページ。
[155] N. Hu、Z. Tian、X. Du、および M. Guizani、「6G 向けのエネルギー効率の高いネットワーク内コンピューティング パラダイム」、IEEE Trans. グリーンコミューン。ネット、vol. 5、いいえ。4、1722–1733ページ、2021年12月。
[156] X.ウー、Z.ジン、W.-K. Jia および X. Shi、「P4 スイッチで算術エンコーディングを使用した複数の小さなデータ フレームの集約」、Proc. アンヌ。消費する。共通。ネット。会議、2021 年、1 ～ 6 ページ。
[157] K. Gökarslan、YS Sandal、および T. Tugcu、「産業用 5G ネットワーク向け P4 を使用した URLLC 認識プログラマブル データ パスに向けて」、Proc. IEEE会議 共通。ワークショップ、2021 年、1 ～ 6 ページ。
[158] R. Ricart-Sanchez、P. Malagon、JM Alcaraz-Calero、および Q. Wang、「5G モバイル ネットワーク用のハードウェア アクセラレーション ファイアウォール」、Proc. 会議 ネット。プロトコル、2018 年、446 ～ 447 ページ。
[159] R. Ricart-Sanchez et al.、「5G マルチテナント アーキテクチャ向け NetFPGA ベースのファイアウォール ソリューション」、Proc. 会議 エッジ コンピューティング、2019 年、132 ～ 136 ページ。
[160] JW Lockwood et al.、「NetFPGA—ギガビット速度のネットワーク スイッチングおよびルーティングのためのオープン プラットフォーム」、Proc. 会議 マイクロ電子。システム。[ 161
] L. Linguaglossa 他、「ネットワーク機能仮想化のためのパフォーマンス加速技術の調査」、Proc. IEEE、vol. 107、いいえ。[ 162
] C. Fernández、S. Giménez、E. Grasa、および S. Bunch、「ソフトウェア定義データ センター向けの P4 対応 RINA インテリア ルーター」、J.コンピュータ、vol. 9、いいえ。3、p.
[163] H. Ballani 他、「エンドホスト ネットワーク機能の有効化」、ACM SIGCOMM Comput . 共通。Rev.、vol. 45、いいえ。
[164] R. Kundel et al.、「P4-BNG: プログラム可能なパケット パイプライン上のセントラル オフィス ネットワーク機能」、Proc. 4、pp. 493–507、2015 。会議 ネット。サービス管理、2019 年、1 ～ 9 ページ。
[165] K. Ralf 他、「OpenBNG: プログラム可能なデータ プレーン ハードウェア上のセントラル オフィス ネットワーク機能」、J. Netw. 管理、vol. 31、いいえ。2021 年 1 日、アート。いいえ。e2134。
[166] T. Osin'ski et al.、「データ プレーンをプログラマブル ASIC にオフロードすることで仮想 BNG のパフォーマンスを解放する」、Proc. P4 ワークショップ ヨーロッパ、2020 年、54 ～ 55 ページ。
[167] T. Osin´ski、H. Tarasiuk、L. Rajewski、および E. Kowalczyk、「DPPx: NFV サービスを強化するための P4 ベースのデータ プレーン プログラマビリティおよび公開フレームワーク」、Proc. 会議 ネット。ソフトウェア、2019 年、296 ～ 300 ページ。
[168] T. Osin'ski、M. Kossakowski、H. Tarasiuk、および R. Picard、「P4 を使用したマルチテナント クラウド インフラストラクチャへのデータ プレーン機能のオフロード」、Proc. 症状 アーキット。ネット。共通。システム、2019 年、1 ～ 6 ページ。
[169] DR Mafioletti et al.、「PIaFFE:
VNF の柔軟な埋め込みのためのネットワーク内での場所に応じたフレームワーク」、Proc. 会議 Commun.、2020、1–6 ページ。
[170] D. Zhang 他、「P4SC: サービス機能チェーンのための高性能かつ柔軟なフレームワーク」、IEEE Access、vol. 170 [171] X. Chen 他、「P4SC: P4 対応デバイスでの高性能サービス機能チェーンの実装に向けて」、Proc.
7 、pp. 160982–160997、2019 。
症状 統合します。ネット。サービス管理、2019 年、1 ～ 9 ページ。
[172] FB Lopes、GL Nazar、および AE Schaeffer-Filho、「VNFAccel: モジュラー VNF コンポーネントの高速化のための FPGA ベースのプラットフォーム」、Proc. 症状 統合します。ネット。『Manager』、2021 年、250 ～ 258 ページ。
[173] D. Moro、G. Verticale、および A. Capone、「ネットワーク機能の分解と展開のためのフレームワーク」、Proc. 会議 デザインリリース 共通。Netw.、2020、1 ～ 6 ページ。
[174] D. Kim et al.、「スイッチ データ プレーン用の汎用外部メモリ」、Proc. ACM ワークショップ ホット トピックス ネットワーク、2018 年、1 ～ 7 ページ。
[175] Y. Xue および Z. Zhu、「ハイブリッド フロー テーブルの設置: サーバー上のフロー テーブルのリモート配置を最適化し、ネットワーク内コンピューティング用の PDP スイッチを強化する」、IEEE Trans. ネット。サービスマネジメント、vol. 18、いいえ。
[176] J. Woodruff、M. Ramanujam、および N. Zilberman、「P4DNS: In-network DNS」、Proc. 1、pp. 429–440、2021 年 3 月。症状 アーキット。ネット。共通。システム、2019 年、1 ～ 6 ページ。
[177] T. Zhang 他、「NFV 用の最先端ソフトウェア スイッチのパフォーマンス ベンチマーク」、J. Comput. ネット、vol. 188、2021 年 4 月、アート。いいえ。107861。