[要約] RFC 9411は、次世代ネットワークセキュリティデバイスのベンチマーキング用語と方法論を提供し、NGFWやNGIPSなどを対象としています。この文書の目的は、ベンチマークの適用性、再現性、透明性を向上させ、今日の複雑なセキュリティ中心のネットワークアプリケーションの使用事例にテスト方法論を整合させることです。
Internet Engineering Task Force (IETF) B. Balarajah
Request for Comments: 9411
Obsoletes: 3511 C. Rossenhoevel
Category: Informational EANTC AG
ISSN: 2070-1721 B. Monkman
NetSecOPEN
March 2023
This document provides benchmarking terminology and methodology for next-generation network security devices, including next-generation firewalls (NGFWs) and next-generation intrusion prevention systems (NGIPSs). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFWs and NGIPSs. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security-centric network application use cases. As a result, this document makes RFC 3511 obsolete.
このドキュメントは、次世代のファイアウォール（NGFW）や次世代侵入防止システム（NGIPSS）を含む、次世代ネットワークセキュリティデバイスのベンチマーク用語と方法論を提供します。このドキュメントで説明されている主な領域は、NGFWSおよびNGIPSのテスト用語、テスト構成パラメーター、およびベンチマーク方法論です。（読者は、これらのデバイスとそれらに含まれるセキュリティ機能に関する実用的な知識を持っていると想定されています。）このドキュメントは、ベンチマークの適用性、再現性、透明性を改善し、テスト方法論を今日のますます複雑なレイヤー7セキュリティ中心に合わせることを目的としています。ネットワークアプリケーションのユースケース。その結果、このドキュメントによりRFC 3511が廃止されます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9411.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9411で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Scope
4. Test Setup
4.1. Testbed Configuration
4.2. DUT/SUT Configuration
4.2.1. Security Effectiveness Configuration
4.3. Test Equipment Configuration
4.3.1. Client Configuration
4.3.2. Backend Server Configuration
4.3.3. Traffic Flow Definition
4.3.4. Traffic Load Profile
5. Testbed Considerations
6. Reporting
6.1. Introduction
6.2. Detailed Test Results
6.3. Benchmarks and Key Performance Indicators
7. Benchmarking Tests
7.1. Throughput Performance with Application Traffic Mix
7.1.1. Objective
7.1.2. Test Setup
7.1.3. Test Parameters
7.1.4. Test Procedures and Expected Results
7.2. TCP Connections Per Second with HTTP Traffic
7.2.1. Objective
7.2.2. Test Setup
7.2.3. Test Parameters
7.2.4. Test Procedures and Expected Results
7.3. HTTP Throughput
7.3.1. Objective
7.3.2. Test Setup
7.3.3. Test Parameters
7.3.4. Test Procedures and Expected Results
7.4. HTTP Transaction Latency
7.4.1. Objective
7.4.2. Test Setup
7.4.3. Test Parameters
7.4.4. Test Procedures and Expected Results
7.5. Concurrent TCP Connection Capacity with HTTP Traffic
7.5.1. Objective
7.5.2. Test Setup
7.5.3. Test Parameters
7.5.4. Test Procedures and Expected Results
7.6. TCP or QUIC Connections per Second with HTTPS Traffic
7.6.1. Objective
7.6.2. Test Setup
7.6.3. Test Parameters
7.6.4. Test Procedures and Expected Results
7.7. HTTPS Throughput
7.7.1. Objective
7.7.2. Test Setup
7.7.3. Test Parameters
7.7.4. Test Procedures and Expected Results
7.8. HTTPS Transaction Latency
7.8.1. Objective
7.8.2. Test Setup
7.8.3. Test Parameters
7.8.4. Test Procedures and Expected Results
7.9. Concurrent TCP or QUIC Connection Capacity with HTTPS
Traffic
7.9.1. Objective
7.9.2. Test Setup
7.9.3. Test Parameters
7.9.4. Test Procedures and Expected Results
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Test Methodology - Security Effectiveness Evaluation
A.1. Test Objective
A.2. Testbed Setup
A.3. Test Parameters
A.3.1. DUT/SUT Configuration Parameters
A.3.2. Test Equipment Configuration Parameters
A.4. Test Results Validation Criteria
A.5. Measurement
A.6. Test Procedures and Expected Results
A.6.1. Step 1: Background Traffic
A.6.2. Step 2: CVE Emulation
Appendix B. DUT/SUT Classification
Acknowledgements
Contributors
Authors' Addresses
It has been 18 years since the IETF initially recommended test methodology and terminology for firewalls [RFC3511]. Firewalls have evolved significantly from the days of simple access control list (ACL) filters. As the underlying technology progresses and improves, recommending test methodology and terminology for firewalls, requirements, and expectations for network security elements has increased tremendously. Security function implementations have evolved and diversified into intrusion detection and prevention, threat management, analysis of encrypted traffic, and more. In an industry of growing importance, well-defined and reproducible key performance indicators (KPIs) are increasingly needed to enable fair and reasonable comparisons of network security functions. These reasons led to the creation of a new next-generation network security device benchmarking document, which makes [RFC3511] obsolete. The measurement of performance for processing IP-fragmented traffic (see Section 5.9 of [RFC3511])is not included in this document since IP fragmentation does not commonly occur in traffic anymore, unlike how it might have at the time when [RFC3511] was written. It should also be noted that [RFC2647] retains significant value and was consulted frequently while creating this document.
IETFが最初にファイアウォールのテスト方法と用語を推奨してから18年が経ちました[RFC3511]。ファイアウォールは、単純なアクセス制御リスト（ACL）フィルターの時代から大幅に進化しました。基礎となるテクノロジーが進行して改善するにつれて、ネットワークセキュリティ要素のファイアウォール、要件、および期待のテスト方法と用語を推奨することで大幅に増加しました。セキュリティ機能の実装は、侵入検知と予防、脅威管理、暗号化されたトラフィックの分析などに進化し、多様化しています。重要性が高まっている業界では、ネットワークセキュリティ機能の公正かつ合理的な比較を可能にするために、明確に定義され、再現可能な主要パフォーマンスインジケーター（KPI）がますます必要になっています。これらの理由により、新しい次世代ネットワークセキュリティデバイスベンチマークドキュメントが作成され、[RFC3511]が廃止されました。IPフラグメントされたトラフィックを処理するためのパフォーマンスの測定（[RFC3511]のセクション5.9を参照）は、[RFC3511]が書かれた時点でどのようにあるかとは異なり、IPの断片化は一般にトラフィックで発生しなくなったため、このドキュメントには含まれていません。。また、[RFC2647]はかなりの価値を保持し、このドキュメントの作成中に頻繁に相談されたことにも注意する必要があります。
For a more detailed explanation of what an NGFW is, see the Wikipedia article [Wiki-NGFW].
NGFWとは何かの詳細な説明については、Wikipediaの記事[Wiki-NGFW]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document provides testing terminology and testing methodology for modern and next-generation network security devices that are configured in Active ("Inline", see Figures 1 and 2) mode. It covers the validation of security effectiveness configurations of network security devices, followed by performance benchmark testing. This document focuses on advanced, realistic, and reproducible testing methods. Additionally, it describes testbed environments, test tool requirements, and test result formats.
このドキュメントは、アクティブ（「インライン」、図1および2を参照）で構成されている最新および次世代のネットワークセキュリティデバイスのテスト用語とテスト方法論を提供します。ネットワークセキュリティデバイスのセキュリティ有効性構成の検証と、パフォーマンスベンチマークテストが続きます。このドキュメントは、高度で現実的で再現可能なテスト方法に焦点を当てています。さらに、テストベッド環境、テストツール要件、テスト結果形式について説明します。
The performance testing methodology described in this document is not intended for security devices or systems that rely on machine learning or behavioral analysis. If such features are present in a Device Under Test / System Under Test (DUT/SUT), they should be disabled.
このドキュメントで説明されているパフォーマンステスト方法は、機械学習や行動分析に依存するセキュリティデバイスまたはシステムを対象としていません。このような機能がテスト /システムのテスト中のデバイス（DUT / SUT）に存在する場合、それらは無効にする必要があります。
The test setup defined in this document applies to all benchmarking tests described in Section 7. The test setup MUST be contained within an isolated test environment (see Section 3 of [RFC6815]).
このドキュメントで定義されているテストセットアップは、セクション7で説明されているすべてのベンチマークテストに適用されます。テストセットアップは、分離されたテスト環境に含まれている必要があります（[RFC6815]のセクション3を参照）。
Testbed configuration MUST ensure that any performance implications that are discovered during the benchmark testing aren't due to the inherent physical network limitations, such as the number of physical links and forwarding performance capabilities (throughput and latency) of the network devices in the testbed. For this reason, this document recommends avoiding external devices, such as switches and routers, in the testbed wherever possible.
テストベッドの構成は、ベンチマークテスト中に発見されたパフォーマンスへの影響は、テストベッドのネットワークデバイスの物理リンクの数や転送パフォーマンス機能（スループットとレイテンシ）など、固有の物理ネットワークの制限によるものではないことを保証する必要があります。このため、このドキュメントでは、可能な限りテストベッドで、スイッチやルーターなどの外部デバイスを避けることを推奨しています。
In some deployment scenarios, the network security devices (DUT/SUT) are connected to routers and switches, which will reduce the number of entries in MAC (Media Access Control) or Address Resolution Protocol / Neighbor Discovery (ARP/ND) tables of the DUT/SUT. If MAC or ARP/ND tables have many entries, this may impact the actual DUT/ SUT performance due to MAC and ARP/ND table lookup processes. This document also recommends using test equipment with the capability of emulating layer 3 routing functionality instead of adding external routers in the testbed.
一部の展開シナリオでは、ネットワークセキュリティデバイス（DUT/SUT）がルーターとスイッチに接続されており、Mac（メディアアクセス制御）またはアドレス解像度プロトコル/ネイバーディスカバリー（ARP/ND）テーブルのエントリ数を減らします。dut/sut。MACまたはARP/NDテーブルに多くのエントリがある場合、これはMACおよびARP/NDテーブルルックアッププロセスによる実際のDUT/SUTパフォーマンスに影響を与える可能性があります。このドキュメントでは、テストベッドに外部ルーターを追加する代わりに、レイヤー3ルーティング機能をエミュレートする機能を備えたテスト機器を使用することも推奨しています。
The testbed setup for Option 1 (Figure 1) is the RECOMMENDED testbed setup for the benchmarking test.
オプション1（図1）のテストベッドセットアップは、ベンチマークテストに推奨されるテストベッドセットアップです。
+-----------------------+ +-----------------------+
| +-------------------+ | +-----------+ | +-------------------+ |
| | Emulated Router(s)| | | | | | Emulated Router(s)| |
| | (Optional) | +----- DUT/SUT +-----+ (Optional) | |
| +-------------------+ | | | | +-------------------+ |
| +-------------------+ | +-----------+ | +-------------------+ |
| | Clients | | | | Servers | |
| +-------------------+ | | +-------------------+ |
| | | |
| Test Equipment | | Test Equipment |
+-----------------------+ +-----------------------+
Figure 1: Testbed Setup - Option 1
図1：テストベッドのセットアップ - オプション1
If the test equipment used is not capable of emulating OSI layer 3 routing functionality or if the number of used ports is mismatched between the test equipment and the DUT/SUT (which is needed for test equipment port aggregation), the test setup can be configured as shown in Figure 2.
使用されるテスト機器がOSIレイヤー3ルーティング機能をエミュレートできない場合、または使用済みポートの数がテスト機器とDUT/SUT（テスト機器ポート集約に必要な）の間で不一致になっている場合、テストセットアップを構成できます。図2に示すように。
+-------------------+ +-----------+ +--------------------+
|Aggregation Switch/| | | | Aggregation Switch/|
| Router +------+ DUT/SUT +------+ Router |
| | | | | |
+----------+--------+ +-----------+ +--------+-----------+
| |
| |
+-----------+-----------+ +-----------+-----------+
| | | |
| +-------------------+ | | +-------------------+ |
| | Emulated Router(s)| | | | Emulated Router(s)| |
| | (Optional) | | | | (Optional) | |
| +-------------------+ | | +-------------------+ |
| +-------------------+ | | +-------------------+ |
| | Clients | | | | Servers | |
| +-------------------+ | | +-------------------+ |
| | | |
| Test Equipment | | Test Equipment |
+-----------------------+ +-----------------------+
Figure 2: Testbed Setup - Option 2
図2：テストベッドのセットアップ - オプション2
The same DUT/SUT configuration MUST be used for all benchmarking tests described in Section 7. Since each DUT/SUT will have its own unique configuration, users MUST configure their devices with the same parameters and security features that would be used in the actual deployment of the device or a typical deployment. The DUT/SUT MUST be configured in "Inline" mode so that the traffic is actively inspected by the DUT/SUT.
セクション7で説明したすべてのベンチマークテストに同じDUT/SUT構成を使用する必要があります。各DUT/SUTには独自の構成があるため、ユーザーは実際の展開で使用される同じパラメーターとセキュリティ機能を持つデバイスを構成する必要があります。デバイスまたは典型的な展開。DUT/SUTは、トラフィックがDUT/SUTによって積極的に検査されるように、「インライン」モードで構成する必要があります。
Tables 2 and 3 below describe the RECOMMENDED and OPTIONAL sets of network security features for NGFWs and NGIPSs, respectively. If the recommended security features are not enabled in the DUT/SUT for any reason, the reason MUST be reported with the benchmarking test results. For example, one reason for not enabling the anti-virus feature in an NGFW may be that this security feature was not required for a particular customer deployment scenario. It MUST be also noted in the benchmarking test report that not enabling the specific recommended security features may impact the performance of the DUT/ SUT. The selected security features MUST be consistently enabled on the DUT/SUT for all benchmarking tests described in Section 7.
以下の表2と3は、NGFWSとNGIPSSのネットワークセキュリティ機能の推奨されたオプションのセットと、それぞれ推奨されたオプションのセットについて説明します。何らかの理由でDUT/SUTで推奨されるセキュリティ機能が有効になっていない場合、ベンチマークテスト結果で理由を報告する必要があります。たとえば、NGFWでウイルス対策機能を有効にしない理由の1つは、このセキュリティ機能が特定の顧客展開シナリオに必要ではなかったことです。また、ベンチマークテストレポートでは、特定の推奨セキュリティ機能を有効にしないことで、DUT/ SUTのパフォーマンスに影響を与える可能性があることにも注意する必要があります。選択したセキュリティ機能は、セクション7で説明されているすべてのベンチマークテストに対してDUT/SUTで一貫して有効にする必要があります。
To improve repeatability, a summary of the DUT/SUT configuration, including a description of all enabled DUT/SUT features, MUST be published with the benchmarking results.
再現性を向上させるには、すべての有効なDUT/SUT機能の説明を含むDUT/SUT構成の要約をベンチマークの結果とともに公開する必要があります。
The following table provides a brief description of the security feature; these are approximate taxonomies of features commonly found in currently deployed NGFWs and NGIPSs. The features provided by specific implementations may be named differently and not necessarily have configuration settings that align with the taxonomy.
次の表には、セキュリティ機能の簡単な説明があります。これらは、現在展開されているNGFWSおよびNGIPSによく見られる機能のおおよその分類法です。特定の実装によって提供される機能は、異なる名前を付けられている場合があり、必ずしも分類法と一致する構成設定があるとは限りません。
+================+==================================================+
| DUT/SUT | Description |
| Features | |
+================+==================================================+
| TLS Inspection | The DUT/SUT intercepts and decrypts |
| | inbound HTTPS traffic between servers and |
| | clients. Once the content inspection has |
| | been completed, the DUT/SUT encrypts the |
| | HTTPS traffic with ciphers and keys used |
| | by the clients and servers. For TLS 1.3, |
| | the DUT works as a middlebox (proxy) and |
| | holds the certificates and Pre-Shared Keys |
| | (PSKs) that are trusted by the client and |
| | represent the identity of the real server. |
+----------------+--------------------------------------------------+
| IDS/IPS | The DUT/SUT detects and blocks exploits |
| | targeting known and unknown |
| | vulnerabilities across the monitored |
| | network. |
+----------------+--------------------------------------------------+
| Anti-Malware | The DUT/SUT detects and prevents the |
| | transmission of malicious executable code |
| | and any associated communications across |
| | the monitored network. This includes data |
| | exfiltration as well as command and |
| | control channels. |
+----------------+--------------------------------------------------+
| Anti-Spyware | Anti-Spyware is a subcategory of Anti- |
| | Malware. Spyware transmits information |
| | without the user's knowledge or |
| | permission. The DUT/SUT detects and |
| | blocks the initial infection or |
| | transmission of data. |
+----------------+--------------------------------------------------+
| Anti-Botnet | The DUT/SUT detects and blocks traffic to |
| | or from botnets. |
+----------------+--------------------------------------------------+
| Anti-Evasion | The DUT/SUT detects and mitigates attacks |
| | that have been obfuscated in some manner. |
+----------------+--------------------------------------------------+
| Web Filtering | The DUT/SUT detects and blocks malicious |
| | websites, including defined |
| | classifications of websites across the |
| | monitored network. |
+----------------+--------------------------------------------------+
| Data Loss | The DUT/SUT detects and prevents data |
| Protection | breaches and data exfiltration, or it |
| (DLP) | detects and blocks the transmission of |
| | sensitive data across the monitored |
| | network. |
+----------------+--------------------------------------------------+
| Certificate | The DUT/SUT validates certificates used in |
| Validation | encrypted communications across the |
| | monitored network. |
+----------------+--------------------------------------------------+
| Logging and | The DUT/SUT logs and reports all traffic |
| Reporting | at the flow level across the monitored |
| | network. |
+----------------+--------------------------------------------------+
| Application | The DUT/SUT detects known applications as |
| Identification | defined within the traffic mix selected |
| | across the monitored network. |
+----------------+--------------------------------------------------+
| Deep Packet | The DUT/SUT inspects the content of the |
| Inspection | data packet. |
| (DPI) | |
+----------------+--------------------------------------------------+
Table 1: Security Feature Description
表1：セキュリティ機能の説明
+============================+=============+==========+
| DUT/SUT (NGFW) Features | RECOMMENDED | OPTIONAL |
+============================+=============+==========+
| TLS Inspection | x | |
+----------------------------+-------------+----------+
| IDS/IPS | x | |
+----------------------------+-------------+----------+
| Anti-Spyware | x | |
+----------------------------+-------------+----------+
| Anti-Virus | x | |
+----------------------------+-------------+----------+
| Anti-Botnet | x | |
+----------------------------+-------------+----------+
| Anti-Evasion | x | |
+----------------------------+-------------+----------+
| Web Filtering | | x |
+----------------------------+-------------+----------+
| Data Loss Protection (DLP) | | x |
+----------------------------+-------------+----------+
| DDoS Protection | | x |
+----------------------------+-------------+----------+
| Certificate Validation | | x |
+----------------------------+-------------+----------+
| Application Identification | x | |
+----------------------------+-------------+----------+
Table 2: NGFW Security Features
表2：NGFWセキュリティ機能
+==============================+=============+==========+
| DUT/SUT (NGIPS) Features | RECOMMENDED | OPTIONAL |
+==============================+=============+==========+
| TLS Inspection | x | |
+------------------------------+-------------+----------+
| Anti-Malware | x | |
+------------------------------+-------------+----------+
| Anti-Spyware | x | |
+------------------------------+-------------+----------+
| Anti-Botnet | x | |
+------------------------------+-------------+----------+
| Application Identification | x | |
+------------------------------+-------------+----------+
| Deep Packet Inspection (DPI) | x | |
+------------------------------+-------------+----------+
| Anti-Evasion | x | |
+------------------------------+-------------+----------+
Table 3: NGIPS Security Features
表3：NGIPSセキュリティ機能
Note: With respect to TLS Inspection, there are scenarios where it will be optional.
注：TLS検査に関しては、オプションになるシナリオがあります。
Below is a summary of the DUT/SUT configuration:
以下は、DUT/SUT構成の概要です。
* The DUT/SUT MUST be configured in "Inline" mode.
* DUT/SUTは、「インライン」モードで構成する必要があります。
* "Fail-Open" behavior MUST be disabled.
* 「フェイルオープン」動作は無効にする必要があります。
* All RECOMMENDED security features are enabled.
* 推奨されるすべてのセキュリティ機能が有効になっています。
* Logging and reporting MUST be enabled. The DUT/SUT SHOULD log all traffic at the flow level (5-tuple). If the DUT/SUT is designed to log all traffic at different levels (e.g., IP packet levels), it is acceptable to conduct tests. However, this MUST be noted in the test report. Logging to an external device is permissible.
* ロギングとレポートを有効にする必要があります。DUT/SUTは、フローレベル（5タプル）ですべてのトラフィックを記録する必要があります。DUT/SUTがすべてのトラフィックを異なるレベル（IPパケットレベルなど）でログに記録するように設計されている場合、テストを実施することは許容されます。ただし、これはテストレポートに注意する必要があります。外部デバイスへのログは許容されます。
* Geographical location filtering SHOULD be configured. If the DUT/ SUT is not designed to perform geographical location filtering, it is acceptable to conduct tests without this feature. However, this MUST be noted in the test report.
* 地理的位置フィルタリングを構成する必要があります。DUT/ SUTが地理的位置フィルタリングを実行するように設計されていない場合、この機能なしでテストを実施することは受け入れられます。ただし、これはテストレポートに注意する必要があります。
* Application Identification and Control MUST be configured to trigger applications from the defined traffic mix.
* アプリケーションの識別と制御は、定義されたトラフィックミックスからアプリケーションをトリガーするように構成する必要があります。
In addition, a realistic number of access control lists (ACLs) SHOULD be configured on the DUT/SUT where ACLs are configurable and reasonable based on the deployment scenario. For example, it is acceptable not to configure ACLs in an NGIPS since NGIPS devices do not require the use of ACLs in most deployment scenarios. This document determines the number of access policy rules for four different classes of the DUT/SUT: Extra Small (XS), Small (S), Medium (M), and Large (L). A sample DUT/SUT classification is described in Appendix B.
さらに、ACLが展開シナリオに基づいてACLSが構成可能で合理的であるDUT/SUTで、現実的な数のアクセス制御リスト（ACL）を構成する必要があります。たとえば、NGIPSデバイスはほとんどの展開シナリオでACLを使用する必要がないため、NGIPでACLを構成しないことは許容できます。このドキュメントは、DUT/SUTの4つの異なるクラスのアクセスポリシールールの数を決定します。サンプルDUT/SUTの分類については、付録Bで説明します。
The ACLs defined in Table 4 MUST be configured from top to bottom in the correct order, as shown in the table. This is due to ACL types listed in specificity-decreasing order, with "block" first, followed by "allow", representing a typical ACL-based security policy. The ACL entries MUST be configured with routable IP prefixes by the DUT/ SUT, where applicable. (Note: There will be differences between how security vendors implement ACL decision making.) The configured ACL MUST NOT block the test traffic used for the benchmarking tests.
表4で定義されているACLSは、表に示すように、正しい順序で上から下に構成する必要があります。これは、ACLタイプが特異性を減少させる順序でリストされており、最初に「ブロック」、次に「Allow」が続き、典型的なACLベースのセキュリティポリシーを表します。ACLエントリは、該当する場合、DUT/ SUTによってルーティング可能なIPプレフィックスで構成する必要があります。（注：セキュリティベンダーがACLの意思決定を実装する方法には違いがあります。）構成されたACLは、ベンチマークテストに使用されるテストトラフィックをブロックしてはなりません。
+===================================================+==============+
| |DUT/SUT |
| |Classification|
| |# Rules |
+=============+=============+==============+========+===+==+===+===+
| Rules Type | Match | Description | Action |XS |S |M |L |
| | Criteria | | | | | | |
+=============+=============+==============+========+===+==+===+===+
| Application | Application | Any | block |5 |10|20 |50 |
| layer | | application | | | | | |
| | | not included | | | | | |
| | | in the | | | | | |
| | | measurement | | | | | |
| | | traffic | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
| Transport | SRC IP and | Any SRC IP | block |25 |50|100|250|
| layer | TCP/UDP DST | prefix used | | | | | |
| | ports | and any DST | | | | | |
| | | ports not | | | | | |
| | | used in the | | | | | |
| | | measurement | | | | | |
| | | traffic | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
| IP layer | SRC/DST IP | Any SRC/DST | block |25 |50|100|250|
| | | IP subnet | | | | | |
| | | not used in | | | | | |
| | | the | | | | | |
| | | measurement | | | | | |
| | | traffic | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
| Application | Application | Half of the | allow |10 |10|10 |10 |
| layer | | applications | | | | | |
| | | included in | | | | | |
| | | the | | | | | |
| | | measurement | | | | | |
| | | traffic (see | | | | | |
| | | the note | | | | | |
| | | below) | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
| Transport | SRC IP and | Half of the | allow |>1 |>1|>1 |>1 |
| layer | TCP/UDP DST | SRC IPs used | | | | | |
| | ports | and any DST | | | | | |
| | | ports used | | | | | |
| | | in the | | | | | |
| | | measurement | | | | | |
| | | traffic (one | | | | | |
| | | rule per | | | | | |
| | | subnet) | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
| IP layer | SRC IP | The rest of | allow |>1 |>1|>1 |>1 |
| | | the SRC IP | | | | | |
| | | prefix range | | | | | |
| | | used in the | | | | | |
| | | measurement | | | | | |
| | | traffic (one | | | | | |
| | | rule per | | | | | |
| | | subnet) | | | | | |
+-------------+-------------+--------------+--------+---+--+---+---+
Table 4: DUT/SUT Access List
表4：DUT/SUTアクセスリスト
Note 1: Based on the test customer's specific use case, the testers can increase the number of rules.
注1：テスト顧客の特定のユースケースに基づいて、テスターはルールの数を増やすことができます。
Note 2: If half of the applications included in the test traffic are less than 10, the missing number of ACL entries (placeholder rules) can be configured for any application traffic not included in the test traffic.
注2：テストトラフィックに含まれるアプリケーションの半分が10未満の場合、テストトラフィックに含まれていないアプリケーショントラフィックに対して、ACLエントリの数が欠落している（プレースホルダールール）を構成できます。
Note 3: In the event that the DUT/SUT is designed to not use ACLs, it is acceptable to conduct tests without them. However, this MUST be noted in the test report.
注3：DUT/SUTがACLSを使用しないように設計されている場合、それらなしでテストを実施することは許容されます。ただし、これはテストレポートに注意する必要があります。
The selected security features (defined in Tables 2 and 3) of the DUT/SUT MUST be configured effectively to detect, prevent, and report the defined security vulnerability sets. This section defines the selection of the security vulnerability sets from the Common Vulnerabilities and Exposures (CVEs) list [CVE] for testing. The vulnerability set should reflect a minimum of 500 CVEs from no older than 10 calendar years to the current year. These CVEs should be selected with a focus on in-use software commonly found in business applications, with a Common Vulnerability Scoring System (CVSS) Severity of High (7-10).
DUT/SUTの選択されたセキュリティ機能（表2および3で定義されている）は、定義されたセキュリティの脆弱性セットを検出、防止、および報告するために効果的に構成する必要があります。このセクションでは、テスト用の共通の脆弱性とエクスポージャー（CVE）リスト[CVE]からのセキュリティ脆弱性セットの選択を定義します。脆弱性セットは、10暦年以下から今年までの最低500セブを反映する必要があります。これらのCVEは、ビジネスアプリケーションで一般的に見られる使用中のソフトウェアに焦点を当てて選択する必要があります。
This document is primarily focused on performance benchmarking. However, it is RECOMMENDED to validate the security features configuration of the DUT/SUT by evaluating the security effectiveness as a prerequisite for performance benchmarking tests defined in Section 7. In case the benchmarking tests are performed without evaluating security effectiveness, the test report MUST explain the implications of this. The methodology for evaluating security effectiveness is defined in Appendix A.
このドキュメントは、主にパフォーマンスベンチマークに焦点を当てています。ただし、セクション7で定義されたパフォーマンスベンチマークテストの前提条件としてセキュリティの有効性を評価することにより、DUT/SUTのセキュリティ機能の構成を検証することをお勧めします。これの意味。セキュリティの有効性を評価するための方法論は、付録Aで定義されています。
In general, test equipment allows configuring parameters in different protocol layers. Extensive proof-of-concept tests conducted to support preparation of this document showed that benchmarking results are strongly affected by the choice of protocol stack parameters, especially OSI layer 4 transport protocol parameters. For more information on how TCP and QUIC parameters will impact performance, review [fastly]. To achieve reproducible results that will be representative of real deployment scenarios, careful specification and documentation of the parameters are required.
一般に、テスト機器を使用すると、異なるプロトコル層でパラメーターを構成できます。このドキュメントの準備をサポートするために実施された広範な概念実証テストは、ベンチマークの結果が、プロトコルスタックパラメーター、特にOSIレイヤー4トランスポートプロトコルパラメーターの選択によって強く影響を受けることを示しました。TCPおよびQUICパラメーターがパフォーマンスにどのように影響するかの詳細については、[早く]レビューを確認してください。実際の展開シナリオを代表する再現性のある結果を達成するには、パラメーターの慎重な仕様とドキュメントが必要です。
This section specifies common test equipment configuration parameters applicable for all benchmarking tests defined in Section 7. Any benchmarking-test-specific parameters are described under the test setup section of each benchmarking test individually.
このセクションでは、セクション7で定義されたすべてのベンチマークテストに適用される一般的なテスト機器構成パラメーターを指定します。ベンチマークテスト固有のパラメーターは、各ベンチマークテストのテストセットアップセクションで個別に説明されています。
This section specifies which parameters should be considered while configuring emulated client endpoints in the test equipment. Also, this section specifies the RECOMMENDED values for certain parameters. The values are the defaults typically used in most of the client operating system types.
このセクションでは、テスト機器でエミュレートされたクライアントエンドポイントを構成しながら、どのパラメーターを考慮する必要があるかを指定します。また、このセクションでは、特定のパラメーターの推奨値を指定します。値は、ほとんどのクライアントオペレーティングシステムタイプで通常使用されるデフォルトです。
Pre-standard evaluations have shown that it is possible to set a wide range of arbitrary parameters for OSI layer 4 transport protocols on test equipment leading to optimization of client-specific results; however, only well-defined common parameter sets help to establish meaningful and comparable benchmarking results. For these reasons, this document recommends specific sets of transport protocol parameters to be configured on test equipment used for benchmarking.
標準以前の評価により、クライアント固有の結果の最適化につながるテスト機器にOSIレイヤー4輸送プロトコルの幅広い任意のパラメーターを設定できることが示されています。ただし、明確に定義された一般的なパラメーターセットのみが、意味のある比較可能なベンチマーク結果を確立するのに役立ちます。これらの理由により、このドキュメントは、ベンチマークに使用されるテスト機器で構成する特定の輸送プロトコルパラメーターセットを推奨しています。
The TCP stack of the emulated client endpoints MUST fulfill the TCP requirements defined in Appendix B of [RFC9293]. In addition, this section specifies the RECOMMENDED values for TCP parameters configured using the parameters described below.
エミュレートされたクライアントエンドポイントのTCPスタックは、[RFC9293]の付録Bで定義されているTCP要件を満たす必要があります。さらに、このセクションでは、以下のパラメーターを使用して構成されたTCPパラメーターの推奨値を指定します。
The IPv4 and IPv6 Maximum Segment Sizes (MSSs) are set to 1460 bytes and 1440 bytes, respectively. TX and RX initial receive window sizes are set to 65535 bytes. The client's initial congestion window should not exceed 10 times the MSS. Delayed ACKs are permitted, and the maximum client delayed ACK should not exceed 10 times of the MSS before a forced ACK; also, the maximum delayed ACK timer is allowed to be set to 200 ms. Up to three retries are allowed before a timeout event is declared. The TCP PSH flag is set to high in all traffic. The source port range is 1024-65535. The clients initiate TCP connections via a three-way handshake (SYN, SYN/ACK, ACK) and close TCP connections via either a TCP three-way close (FIN, FIN/ACK, ACK) or a TCP four-way close (FIN, ACK, FIN, ACK).
IPv4およびIPv6の最大セグメントサイズ（MSSS）は、それぞれ1460バイトと1440バイトに設定されています。TXおよびRX初期受信ウィンドウサイズは65535バイトに設定されています。クライアントの最初の輻輳ウィンドウは、MSSの10倍を超えてはなりません。遅延ACKは許可されており、最大クライアントの遅延ACKは、強制ACKの前にMSSの10倍を超えてはなりません。また、最大遅延ACKタイマーを200ミリ秒に設定できます。タイムアウトイベントが宣言される前に、最大3回のレトリが許可されます。TCP PSHフラグは、すべてのトラフィックで高く設定されています。ソースポート範囲は1024-65535です。クライアントは、TCP 3ウェイクローズ（FIN、FIN/ACK、ACK）またはTCP 4ウェイクローズ（FIN）を介して、3ウェイハンドシェイク（Syn、Syn/Ack、Ack）を介してTCP接続を開始し、TCP接続を閉じます、ack、fin、ack）。
QUIC stack emulation on the test equipment MUST conform to [RFC9000] and [RFC9001]. This section specifies the RECOMMENDED values for certain QUIC parameters to be configured on test equipment used for benchmarking purposes only. The QUIC stream type (defined in Section 2.1 of [RFC9000]) is set to "Client-Initiated, Bidirectional". 0-RTT and early data are disabled. The QUIC connection termination method is an immediate close (Section 10.2 of [RFC9000]). Flow control is enabled. UDP payloads are set to the datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. In addition, transport parameters and default values defined in Section 18.2 of [RFC9000] are RECOMMENDED to configure on test equipment. Also, this document references Appendices B.1 and B.2 of [RFC9002] for congestion-control-related constants and variables. Any configured QUIC and UDP parameter MUST be documented in the test report.
テスト機器のQUICスタックエミュレーションは、[RFC9000]および[RFC9001]に適合する必要があります。このセクションでは、ベンチマーク目的のみに使用されるテスト機器で構成する特定のQUICパラメーターの推奨値を指定します。QUICストリームタイプ（[RFC9000]のセクション2.1で定義）は、「クライアント開始、双方向」に設定されています。0-RTTおよび初期データは無効になっています。QUIC接続終了方法は、すぐに近いです（[RFC9000]のセクション10.2）。フロー制御が有効になっています。UDPペイロードは、IPv6の場合は1232バイト、IPv4で1252バイトのデータグラムサイズに設定されています。さらに、[RFC9000]のセクション18.2で定義されている輸送パラメーターとデフォルト値は、テスト機器で構成するために推奨されます。また、このドキュメントは、混雑コントロール関連定数と変数について、[RFC9002]の[RFC9002]の付録B.1およびB.2を参照しています。設定されたQUICおよびUDPパラメーターは、テストレポートに文書化する必要があります。
The client IP space contains the following attributes.
クライアントIPスペースには、次の属性が含まれています。
* If multiple IP blocks are used, they MUST consist of multiple unique, discontinuous static address blocks.
* 複数のIPブロックを使用する場合、それらは複数の一意の不連続な静的アドレスブロックで構成する必要があります。
* A default gateway MAY be used.
* デフォルトゲートウェイを使用できます。
* The differentiated services code point (DSCP) marking should be set to Default Forwarding (DF) '000000' on the IPv4 Type of Service (ToS) field and IPv6 Traffic Class field.
* 差別化されたサービスコードポイント（DSCP）マーキングは、IPv4タイプのサービス（TOS）フィールドおよびIPv6トラフィッククラスフィールドでデフォルト転送（DF） '000000'に設定する必要があります。
* One or more extension headers MAY be used for IPv6 clients. If multiple extension headers are needed for traffic emulation, this document references [RFC8200] to choose the correct order of the extension headers within an IPv6 packet. Testing with one or more extension headers may impact the performance of the DUT. The extension headers MUST be documented and reported.
* IPv6クライアントには、1つ以上の拡張ヘッダーを使用できます。トラフィックエミュレーションに複数の拡張ヘッダーが必要な場合、このドキュメントは[RFC8200]を参照して、IPv6パケット内の拡張ヘッダーの正しい順序を選択します。1つ以上の拡張ヘッダーを使用したテストは、DUTのパフォーマンスに影響を与える可能性があります。拡張ヘッダーを文書化して報告する必要があります。
The following equation can be used to define the total number of client IP addresses that need to be configured on the test equipment.
次の方程式を使用して、テスト機器で構成する必要があるクライアントIPアドレスの総数を定義できます。
Desired total number of client IP addresses = Target throughput [Mbit/s] / Average throughput per IP address [Mbit/s]
クライアントIPアドレスの希望の総数=ターゲットスループット[Mbit/s]/平均スループットIPアドレス[Mbit/s]
As shown in the example list below, the value for "Average throughput per IP address" can be varied depending on the deployment and use case scenario.
以下のサンプルリストに示すように、「IPアドレスごとの平均スループット」の値は、展開およびユースケースシナリオによって異なる場合があります。
Example 1 DUT/SUT deployment scenario 1: 6-7 Mbit/s per IP (e.g., 1,400-1,700 IPs per 10 Gbit/s of throughput)
例1 DUT/SUT展開シナリオ1：6-7 Mbit/sあたりMbit/s（たとえば、スループットの10 gbit/sあたり1,400-1,700 IP）
Example 2 DUT/SUT deployment scenario 2: 0.1-0.2 Mbit/s per IP (e.g., 50,000-100,000 IPs per 10 Gbit/s of throughput)
例2 DUT/SUT展開シナリオ2：0.1-0.2 IPあたりMbit/s（例：スループットの10 gbit/sあたり50,000-100,000 IP）
Client IP addresses MUST be distributed between IPv4 and IPv6 based on the deployment and use case scenario. The following options MAY be considered for a selection of ratios for both IP addresses and traffic load distribution.
クライアントIPアドレスは、展開およびユースケースシナリオに基づいて、IPv4とIPv6の間に配布する必要があります。次のオプションは、IPアドレスとトラフィック負荷分布の両方の比率の選択について考慮される場合があります。
Option 1 100 % IPv4, no IPv6
オプション1 100％IPv4、IPv6なし
Option 2 80 % IPv4, 20% IPv6
オプション2 80％IPv4、20％IPv6
Option 3 50 % IPv4, 50% IPv6
オプション3 50％IPv4、50％IPv6
Option 4 20 % IPv4, 80% IPv6
オプション4 20％IPv4、80％IPv6
Option 5 no IPv4, 100% IPv6
オプション5 IPv4なし、100％IPv6
Note: IANA has assigned IP address ranges for testing purposes, as described in Section 8. If the test scenario requires more IP addresses or subnets than IANA has assigned, this document recommends using private IPv4 address ranges or Unique Local Address (ULA) IPv6 address ranges for the testing.
注：IANAは、セクション8で説明されているように、テスト目的でIPアドレス範囲を割り当てています。テストシナリオでIANAが割り当てたよりも多くのIPアドレスまたはサブネットが必要な場合、このドキュメントでは、プライベートIPv4アドレス範囲または一意のローカルアドレス（ULA）IPv6アドレスを使用することを推奨しています。テストの範囲。
The client (emulated web browser) contains attributes that will materially affect the traffic load. The objective is to emulate modern, typical browser attributes to improve the relevance of the result set for typical deployment scenarios.
クライアント（エミュレートされたWebブラウザー）には、トラフィック負荷に重大な影響を与える属性が含まれています。目的は、典型的な展開シナリオの結果セットの関連性を改善するために、最新の典型的なブラウザ属性をエミュレートすることです。
The emulated browser MUST negotiate HTTP version 1.1 or higher. The emulated browser SHOULD advertise a User-Agent header. The emulated browser MUST enforce content length validation. HTTP header compression MAY be set to enable. If HTTP header compression is configurable in the test equipment, it MUST be documented if it was enabled or disabled. Depending on test scenarios and the chosen HTTP version, the emulated browser MAY open multiple TCP or QUIC connections per server endpoint IP at any time, depending on how many sequential transactions need to be processed.
エミュレートされたブラウザは、HTTPバージョン1.1以上をネゴシエートする必要があります。エミュレートされたブラウザは、ユーザーエージェントヘッダーを宣伝する必要があります。エミュレートされたブラウザは、コンテンツの長さの検証を実施する必要があります。HTTPヘッダー圧縮を有効に設定することができます。HTTPヘッダー圧縮がテスト機器で構成可能である場合、有効または無効になった場合は文書化する必要があります。テストシナリオと選択したHTTPバージョンに応じて、エミュレートブラウザーは、シーケンシャルトランザクションの数に応じて、いつでもサーバーエンドポイントIPごとに複数のTCPまたはQUIC接続を開くことができます。
For HTTP/2 traffic emulation, the emulated browser opens multiple concurrent streams per connection (multiplexing). For HTTPS requests, the emulated browser MUST send an "h2" protocol identifier using the TLS extension Application-Layer Protocol Negotiation (ALPN). The following default values (see [Undertow]) are the RECOMMENDED settings for certain HTTP/2 parameters to be configured on test equipment used for benchmarking purposes only:
HTTP/2トラフィックエミュレーションの場合、エミュレートブラウザーは接続ごとに複数の同時ストリームを開きます（多重化）。HTTPSリクエストの場合、エミュレートブラウザーは、TLS拡張アプリケーション層プロトコルネゴシエーション（ALPN）を使用して「H2」プロトコル識別子を送信する必要があります。以下のデフォルト値（[undertow]を参照）は、ベンチマーク目的でのみ使用されるテスト機器で構成される特定のHTTP/2パラメーターの推奨設定です。
* Maximum frame size: 16384 bytes
* 最大フレームサイズ：16384バイト
* Initial window size: 65535 bytes
* 初期ウィンドウサイズ：65535バイト
* HPACK header field table size: 4096 bytes
* HPackヘッダーフィールドテーブルサイズ：4096バイト
* Server push enable: false (Note: In [Undertow], the default setting is true. However, for testing purposes, this document recommends setting the value to false for server push.)
* サーバーのプッシュ有効化：false（注：[undertow]では、デフォルト設定は真です。ただし、テストのために、このドキュメントはサーバープッシュの値をfalseに設定することをお勧めします。）
This document refers to [RFC9113] for further details of HTTP/2. If any additional parameters are used to configure the test equipment, they MUST be documented.
このドキュメントは、HTTP/2の詳細については[RFC9113]を参照してください。テスト機器の構成に追加のパラメーターが使用される場合は、文書化する必要があります。
For HTTP/3 traffic emulation, the emulated browsers initiate secure QUIC connections using TLS 1.3 ([RFC9001] describes how TLS is used to secure QUIC). This document refers to [RFC9114] for HTTP/3 specifications. The specification for transport protocol parameters is defined in Section 4.3.1.2. QPACK configuration settings, such as MAX_TABLE_CAPACITY and QPACK_BLOCKED_STREAMS, are set to zero (default), as defined in [RFC9204]. Any HTTP/3 parameters used for test equipment configuration MUST be documented.
HTTP/3トラフィックエミュレーションの場合、エミュレートされたブラウザは、TLS 1.3を使用して安全なQUIC接続を開始します（[RFC9001]は、TLSを使用してQUICを保護する方法を説明します）。このドキュメントは、HTTP/3仕様の[RFC9114]を指します。輸送プロトコルパラメーターの仕様は、セクション4.3.1.2で定義されています。max_table_capacityやqpack_blocked_streamsなどのqpack構成設定は、[rfc9204]で定義されているように、ゼロ（デフォルト）に設定されています。テスト機器の構成に使用されるHTTP/3パラメーターを文書化する必要があります。
For encrypted traffic, the following attributes are defined as the negotiated encryption parameters. The test clients MUST use TLS version 1.2 or higher. The TLS record size MAY be optimized for the HTTPS response object size, up to a record size of 16 KB. If Server Name Indication (SNI) is required (especially if the server is identified by a domain name), the client endpoint MUST send TLS extension SNI information when opening a security tunnel. Each client connection MUST perform a full TLS handshake, and session reuse or resumption MUST be disabled. (Note: Real web browsers use session reuse or resumption. However, for testing purposes, this feature must not be used to measure the DUT/SUT performance in the worst-case scenario.)
暗号化されたトラフィックの場合、次の属性はネゴシエートされた暗号化パラメーターとして定義されます。テストクライアントは、TLSバージョン1.2以上を使用する必要があります。TLSレコードサイズは、16 kBのレコードサイズまでのHTTPS応答オブジェクトサイズに対して最適化できます。サーバー名表示（SNI）が必要な場合（特にサーバーがドメイン名で識別される場合）、クライアントのエンドポイントは、セキュリティトンネルを開くときにTLS拡張SNI情報を送信する必要があります。各クライアント接続は、完全なTLSハンドシェイクを実行する必要があり、セッションの再利用または再開を無効にする必要があります。（注：実際のWebブラウザはセッションの再利用または再開を使用します。ただし、テストのために、この機能を使用して、最悪のシナリオでDUT/SUTのパフォーマンスを測定する必要はありません。）
The following ciphers and keys supported by TLS 1.2 are RECOMMENDED for the HTTPS-based benchmarking tests defined in Section 7.
TLS 1.2でサポートされる次の暗号とキーは、セクション7で定義されたHTTPSベースのベンチマークテストに推奨されます。
1. ECDHE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash Algorithm: ecdsa_secp256r1_sha256 and Supported group: secp256r1)
1. ecdhe-ecdsa-aes128-gcm-sha256 with prime256v1（署名ハッシュアルゴリズム：ecdsa_secp256r1_sha256およびサポートされたグループ：SECP256R1）
2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash Algorithm: rsa_pkcs1_sha256 and Supported group: secp256r1)
2. RSA 2048を備えたECDHE-RSA-AES128-GCM-SHA256（署名ハッシュアルゴリズム：RSA_PKCS1_SHA256およびサポートグループ：SECP256R1）
3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp384r1 (Signature Hash Algorithm: ecdsa_secp384r1_sha384 and Supported group: secp384r1)
3. ecdhe-ecdsa-aes256-gcm-sha384 with secp384r1（署名ハッシュアルゴリズム：ecdsa_secp384r1_sha384およびサポートグループ：SECP384R1）
4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash Algorithm: rsa_pkcs1_sha384 and Supported group: secp384r1)
4. ecdhe-rsa-aes256-gcm-sha384 with rsa 4096（署名ハッシュアルゴリズム：RSA_PKCS1_SHA384およびサポートグループ：SECP384R1）
Note: The above ciphers and keys were those commonly used for enterprise-grade encryption cipher suites for TLS 1.2 at of the time of publication (2023). Individual certification bodies should use ciphers and keys that reflect evolving use cases. These choices MUST be documented in the resulting test reports with detailed information on the ciphers and keys used, along with reasons for the choices.
注：上記の暗号とキーは、出版時（2023）のTLS 1.2のエンタープライズグレードの暗号化暗号スイートに一般的に使用されるものでした。個々の認証機関は、進化するユースケースを反映する暗号とキーを使用する必要があります。これらの選択肢は、結果のテストレポートに、使用された暗号とキーに関する詳細情報と、選択の理由を記録する必要があります。
IANA recommends the following cipher suites for use with TLS 1.3, as defined in [RFC8446].
IANAは、[RFC8446]で定義されているように、TLS 1.3で使用するための次の暗号スイートを推奨しています。
1. TLS_AES_128_GCM_SHA256
1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA384
2. TLS_AES_256_GCM_SHA384
3. TLS_CHACHA20_POLY1305_SHA256
3. TLS_CHACHA20_POLY1305_SHA256
4. TLS_AES_128_CCM_SHA256
4. TLS_AES_128_CCM_SHA256
This section specifies which parameters should be considered while configuring emulated backend servers using test equipment.
このセクションでは、テスト機器を使用してエミュレートされたバックエンドサーバーを構成しながら、どのパラメーターを考慮する必要があるかを指定します。
The TCP stack on the server-side MUST be configured similarly to the client-side configuration described in Section 4.3.1.1.
サーバー側のTCPスタックは、セクション4.3.1.1で説明するクライアント側の構成と同様に構成する必要があります。
The QUIC parameters on the server-side MUST be configured similarly to the client-side configuration. Any configured QUIC parameter MUST be documented in the report.
サーバー側のQUICパラメーターは、クライアント側の構成と同様に構成する必要があります。構成されたQUICパラメーターは、レポートに文書化する必要があります。
The sum of the server IP space MUST contain the following attributes.
サーバーIPスペースの合計には、次の属性が含まれている必要があります。
* The server IP blocks MUST consist of unique, discontinuous static address blocks with one IP per server Fully Qualified Domain Name (FQDN) endpoint per test port.
* サーバーIPブロックは、サーバーごとに1つのIPを使用して、テストポートごとに1つのIPを使用して、1つのIPを使用して1つのIPを持つ一意の不連続な静的アドレスブロックで構成する必要があります。
* A default gateway is permitted. The DSCP marking is set to DF '000000' on the IPv4 ToS field and IPv6 Traffic Class field. One or more extension headers for the IPv6 server are permitted. If multiple extension headers are required, this document references [RFC8200] to choose the correct order of the extension headers within an IPv6 packet.
* デフォルトゲートウェイが許可されています。DSCPマーキングは、IPv4 TOSフィールドとIPv6トラフィッククラスフィールドでDF '000000'に設定されています。IPv6サーバーの1つ以上の拡張ヘッダーが許可されています。複数の拡張ヘッダーが必要な場合、このドキュメントは[RFC8200]を参照して、IPv6パケット内の拡張ヘッダーの正しい順序を選択します。
* The server IP address distribution between IPv4 and IPv6 MUST be identical to the client IP address distribution ratio.
* IPv4とIPv6の間のサーバーIPアドレス分布は、クライアントIPアドレス分布比率と同一でなければなりません。
Note: IANA has assigned IP address blocks for the testing purpose described in Section 8. If the test scenario requires more IP addresses or address blocks than IANA has assigned, this document recommends using private IPv4 address ranges or Unique Local Address (ULA) IPv6 address ranges for the testing.
注：IANAは、セクション8で説明されているテスト目的にIPアドレスブロックを割り当てました。テストシナリオでIANAが割り当てたよりも多くのIPアドレスまたはアドレスブロックが必要な場合、このドキュメントはプライベートIPv4アドレス範囲または一意のローカルアドレス（ULA）IPv6アドレスを使用することをお勧めしますテストの範囲。
The HTTP 1.1 and HTTP/2 server pools listen on TCP ports 80 and 443 for HTTP and HTTPS. The HTTP/3 server pool listens on any UDP port. The server MUST emulate the same HTTP version (HTTP 1.1, HTTP/2, or HTTP/3) and settings chosen by the client (emulated web browser). For the HTTPS server, TLS version 1.2 or higher MUST be used with a maximum record size of 16 KB. Ticket resumption or session ID reuse MUST NOT be used for TLS 1.2; also, session ticket or session cache MUST NOT be used for TLS 1.3. The server MUST serve a certificate to the client. The cipher suite and key size on the server-side MUST be configured similarly to the client-side configuration described in Section 4.3.1.4.
HTTP 1.1およびHTTP/2サーバープールは、HTTPとHTTPのTCPポート80および443で聴きます。HTTP/3サーバープールは、任意のUDPポートに耳を傾けます。サーバーは、同じHTTPバージョン（HTTP 1.1、HTTP/2、またはHTTP/3）とクライアントが選択した設定（エミュレートWebブラウザー）をエミュレートする必要があります。HTTPSサーバーの場合、TLSバージョン1.2以降は、最大記録サイズ16 kBで使用する必要があります。チケットの再開またはセッションIDの再利用は、TLS 1.2に使用しないでください。また、TLS 1.3にはセッションチケットまたはセッションキャッシュを使用しないでください。サーバーは、クライアントに証明書を提供する必要があります。サーバー側の暗号スイートとキーサイズは、セクション4.3.1.4で説明したクライアント側の構成と同様に構成する必要があります。
At the beginning of the test (the init phase; see Section 4.3.4), the server endpoint initializes, and the server endpoint will be ready to accept TCP or QUIC connections as well as inbound HTTP and HTTPS requests. The client endpoints initialize and are given attributes such as a MAC and IP address. After the init phase of the test, each client sweeps through the given server IP space, generating a service recognizable by the DUT. Sequential and pseudorandom sweep methods are acceptable. The method used MUST be stated in the final report. Thus, a balanced mesh between client endpoints and server endpoints will be generated in a client IP and port to server IP and port combination. Each client endpoint performs the same actions as other endpoints, with the difference being the source IP of the client endpoint and the target server IP pool. The client MUST use the server IP address or FQDN in the host header.
テストの開始時（INITフェーズ、セクション4.3.4を参照）、サーバーエンドポイントが初期化され、サーバーエンドポイントはTCPまたはQUIC接続、およびインバウンドHTTPおよびHTTPSリクエストを受け入れる準備ができています。クライアントのエンドポイントは初期化され、MacやIPアドレスなどの属性が与えられます。テストのinitフェーズの後、各クライアントは指定されたサーバーIPスペースをスイープし、DUTが認識できるサービスを生成します。順次および擬似ランダムスイープメソッドは許容されます。使用される方法は、最終レポートに記載する必要があります。したがって、クライアントのエンドポイントとサーバーエンドポイント間のバランスの取れたメッシュは、クライアントIPおよびポートツーサーバーIPとポートの組み合わせで生成されます。各クライアントエンドポイントは、他のエンドポイントと同じアクションを実行し、違いはクライアントエンドポイントとターゲットサーバーIPプールのソースIPです。クライアントは、ホストヘッダーでサーバーIPアドレスまたはFQDNを使用する必要があります。
Client endpoints are independent of other clients that are concurrently executing. When a client endpoint initiates traffic, this section describes how the client steps through different services. Once the test is initialized, the client endpoints randomly hold (perform no operation) for a few milliseconds for better randomization of the start of client traffic. Each client (HTTP 1.1 or HTTP/2) will either open a new TCP connection or connect to an HTTP persistent connection that is still open to that specific server. HTTP/3 clients will open UDP streams within QUIC connections. At any point that the traffic profile may require encryption, a TLS encryption tunnel will form, presenting the URL or IP address request to the server. If using SNI, the server MUST then perform an SNI name check by comparing the proposed FQDN to the domain embedded in the certificate. Only when correct will the server process the HTTPS response object. The initial response object to the server is based on benchmarking tests described in Section 7. Multiple additional sub-URLs (response objects on the service page) MAY be requested simultaneously. This MAY be to the same server IP as the initial URL. Each sub-object will also use a canonical FQDN and URL path.
クライアントのエンドポイントは、同時に実行されている他のクライアントから独立しています。クライアントのエンドポイントがトラフィックを開始すると、このセクションでは、クライアントがさまざまなサービスをどのように踏み込むかについて説明します。テストが初期化されると、クライアントのエンドポイントは、クライアントトラフィックの開始をより適切にランダム化するために、数ミリ秒間ランダムに保持されます（操作なし）。各クライアント（HTTP 1.1またはHTTP/2）は、新しいTCP接続を開くか、その特定のサーバーに開かれたHTTP永続的な接続に接続します。HTTP/3クライアントは、QUIC接続内でUDPストリームを開きます。トラフィックプロファイルが暗号化を必要とする任意の時点で、TLS暗号化トンネルが形成され、URLまたはIPアドレスリクエストがサーバーに提示されます。SNIを使用する場合、サーバーは、提案されたFQDNを証明書に埋め込まれたドメインと比較して、SNI名チェックを実行する必要があります。正しい場合にのみ、サーバーがHTTPS応答オブジェクトを処理します。サーバーへの初期応答オブジェクトは、セクション7で説明されているベンチマークテストに基づいています。複数の追加のサブURL（サービスページの応答オブジェクト）が同時に要求される場合があります。これは、初期のURLと同じサーバーIPに対してである可能性があります。各サブオブジェクトは、標準的なFQDNおよびURLパスも使用します。
The loading of traffic is described in this section. The loading of a traffic load profile has five phases: Init, ramp up, sustain, ramp down, and collection.
このセクションでは、トラフィックの負荷について説明します。トラフィック負荷プロファイルの負荷には、init、ランプアップ、サステイン、ランプダウン、コレクションの5つのフェーズがあります。
Init phase:
INITフェーズ：
Testbed devices, including the client and server endpoints, should negotiate layer 2-3 connectivity, such as MAC learning and ARP/ND. Only after successful MAC learning or ARP/ND SHALL the test iteration move to the next phase. No measurements are made in this phase. The minimum recommended time for the Init phase is 5 seconds. During this phase, the emulated clients MUST NOT initiate any sessions with the DUT/SUT; in contrast, the emulated servers should be ready to accept requests from the DUT/SUT or emulated clients.
クライアントやサーバーのエンドポイントを含むテストベッドデバイスは、Mac LearningやARP/NDなどのレイヤー2-3接続をネゴシエートする必要があります。Mac LearningまたはARP/NDが成功した後のみ、テスト反復は次の段階に移動します。このフェーズでは測定は行われません。INITフェーズの最小推奨時間は5秒です。この段階では、エミュレートされたクライアントはDUT/SUTとのセッションを開始してはなりません。対照的に、エミュレートされたサーバーは、DUT/SUTまたはエミュレートされたクライアントからのリクエストを受け入れる準備ができている必要があります。
Ramp Up phase:
ランプアップフェーズ：
The test equipment MUST start to generate the test traffic. It MUST use a set of the approximate number of unique client IP addresses to generate traffic. The traffic MUST ramp up from zero to the desired target objective. The target objective is defined for each benchmarking test. The duration for the ramp up phase MUST be configured long enough that the test equipment does not overwhelm the DUT's/SUT's stated performance metrics defined in Section 6.3, namely TCP or QUIC connections per second, inspected throughput, concurrent TCP or QUIC connections, and application transactions per second. No measurements are made in this phase.
テスト機器は、テストトラフィックの生成を開始する必要があります。一意のクライアントIPアドレスのおおよその数のセットを使用して、トラフィックを生成する必要があります。トラフィックは、ゼロから目的の目的に上昇する必要があります。ターゲット目標は、ベンチマークテストごとに定義されます。ランプアップフェーズの期間は、テスト機器がセクション6.3で定義されているDUTの/SUTの指定されたパフォーマンスメトリック、すなわち1秒あたりのTCPまたはQUIC接続、スループット、同時TCPまたはQUIC接続、およびアプリケーション、およびアプリケーション、およびアプリケーションを圧倒しないように、十分に長く構成する必要があります。1秒あたりのトランザクション。このフェーズでは測定は行われません。
Sustain phase:
維持フェーズ：
This phase starts when all required clients are active and operating at their desired load condition. In the sustain phase, the test equipment MUST continue generating traffic to a constant target value for a constant number of active clients. The minimum RECOMMENDED time duration for the sustain phase is 300 seconds. This is the phase where measurements occur. The test equipment MUST measure and record statistics continuously. The sampling interval for collecting the raw results and calculating the statistics MUST be less than 2 seconds.
このフェーズは、必要なすべてのクライアントがアクティブであり、希望の負荷条件で動作しているときに始まります。サステインフェーズでは、テスト機器は、一定のアクティブなクライアントの一定の目標値へのトラフィックを生成し続ける必要があります。サステインフェーズの最小推奨期間は300秒です。これは、測定が発生するフェーズです。テスト機器は、統計を継続的に測定および記録する必要があります。生の結果を収集し、統計を計算するためのサンプリング間隔は2秒未満でなければなりません。
Ramp Down phase:
ランプダウンフェーズ：
The test traffic slows down from the target number to 0, and no measurements are made.
テストトラフィックはターゲット数から0に減速し、測定は行われません。
Collection phase:
収集フェーズ：
The last phase is administrative and will occur when the test equipment merges and collates the report data.
最後のフェーズは管理的であり、テスト機器がレポートデータをマージして照合すると発生します。
This section describes steps for a reference test (pre-test) that controls the test environment, including test equipment, focusing on physical and virtualized environments and test equipment. Below are the RECOMMENDED steps for the reference test.
このセクションでは、テスト機器、物理的および仮想化された環境、テスト機器に焦点を当てたテスト環境を制御する参照テスト（事前テスト）の手順について説明します。以下は、参照テストに推奨される手順です。
1. Perform the reference test either by configuring the DUT/SUT in the most trivial setup (fast forwarding) or without the presence of the DUT/SUT.
1. DUT/SUTを最も些細なセットアップ（早送り）で構成するか、DUT/SUTの存在なしに参照テストを実行します。
2. Generate traffic from the traffic generator. Choose a traffic profile used for the HTTP or HTTPS throughput performance test with the smallest object size.
2. トラフィックジェネレーターからトラフィックを生成します。HTTPまたはHTTPSスループットパフォーマンステストに使用されるトラフィックプロファイルを最小のオブジェクトサイズで選択します。
3. Ensure that any ancillary switching or routing functions added in the test equipment do not limit performance by introducing packet loss or latency. This is specifically important for virtualized components (e.g., vSwitches or vRouters).
3. テスト機器に追加された補助的なスイッチングまたはルーティング機能が、パケットの損失または遅延を導入してパフォーマンスを制限しないことを確認してください。これは、仮想化されたコンポーネント（vswitchesやvrouterなど）にとって特に重要です。
4. Verify that the generated traffic (performance) of the test equipment matches and reasonably exceeds the expected maximum performance of the DUT/SUT.
4. テスト機器の生成されたトラフィック（パフォーマンス）が一致し、DUT/SUTの予想される最大パフォーマンスを合理的に超えることを確認します。
5. Record the network performance metrics packet loss and latency introduced by the test environment (without the DUT/SUT).
5. テスト環境（DUT/SUTなし）によって導入されたネットワークパフォーマンスメトリックパケットの損失とレイテンシを記録します。
6. Assert that the testbed characteristics are stable during the entire test session. Several factors might influence stability, specifically for virtualized testbeds, for example, additional workloads in a virtualized system, load balancing, and movement of virtual machines during the test or simple issues, such as additional heat created by high workloads leading to an emergency CPU performance reduction.
6. テストベッドの特性は、テストセッション全体で安定していると主張します。特に仮想化されたテストベッドの安定性に影響を与える可能性があります。たとえば、仮想化システムの追加ワークロード、テスト中のロードバランス、仮想マシンの動き、または緊急CPUパフォーマンスにつながる高ワークロードによって作成された追加の熱など、仮想マシンの動き削減。
The reference test MUST be performed before the benchmarking tests (described in Section 7) start.
基準テストは、ベンチマークテスト（セクション7で説明）の開始前に実行する必要があります。
This section describes how the benchmarking test report should be formatted and presented. It is RECOMMENDED to include two main sections in the report: the introduction and the detailed test results sections.
このセクションでは、ベンチマークテストレポートをフォーマットして提示する方法について説明します。レポートには、紹介と詳細なテスト結果セクションの2つの主要セクションを含めることをお勧めします。
The following attributes should be present in the introduction section of the test report.
次の属性は、テストレポートの紹介セクションに存在する必要があります。
1. Time and date of the execution of the tests
1. テストの実行の日時
2. Summary of testbed software and hardware details
2. テストベッドソフトウェアとハードウェアの詳細の概要
a. DUT/SUT hardware/virtual configuration
a. DUT/SUTハードウェア/仮想構成
* Make and model of the DUT/SUT, which should be clearly identified
* DUT/SUTの作成とモデル。
* Port interfaces, including speed and link information
* 速度やリンク情報を含むポートインターフェイス
* If the DUT/SUT is a Virtual Network Function (VNF)
* DUT/SUTが仮想ネットワーク関数（VNF）の場合
* Host (server) hardware and software details
* ホスト（サーバー）ハードウェアとソフトウェアの詳細
* Interface acceleration type (such as Data Plane Development Kit (DPDK) and single-root input/output virtualization (SR-IOV))
* インターフェイスアクセラレーションタイプ（データプレーン開発キット（DPDK）やシングルルート/出力仮想化（SR-IOV）など）
* Used CPU cores
* 使用したCPUコア
* Used RAM
* 使用したRAM
* Resource sharing (e.g., pinning details and Non-Uniform Memory Access (NUMA) node) configuration details
* リソース共有（例：詳細のピン留めおよび不均一なメモリアクセス（numa）ノード）構成の詳細
* Hypervisor version
* ハイパーバイザーバージョン
* Virtual switch version
* 仮想スイッチバージョン
* Details of any additional hardware relevant to the DUT/ SUT, such as controllers
* コントローラーなど、DUT/ SUTに関連する追加のハードウェアの詳細
b. DUT/SUT software
b. DUT/SUTソフトウェア
* Operating system name
* オペレーティングシステム名
* Version
* バージョン
* Specific configuration details (if any)
* 特定の構成の詳細（ある場合）
c. DUT-/SUT-enabled features
c. dut/sut対応機能
* Configured DUT/SUT features (see Tables 2 and 3)
* 構成されたDUT/SUT機能（表2および3を参照）
* Attributes of the abovementioned features
* 上記の機能の属性
* Any additional relevant information about the features
* 機能に関する追加の関連情報
d. Test equipment hardware and software
d. テスト機器のハードウェアとソフトウェア
* Test equipment vendor name
* テスト機器ベンダー名
* Hardware details, including model number and interface type
* モデル番号とインターフェイスタイプを含むハードウェアの詳細
* Test equipment firmware and test application software version
* テスト機器ファームウェアとテストアプリケーションソフトウェアバージョン
* If the test equipment is a virtual solution
* テスト機器が仮想ソリューションである場合
* The host (server) hardware and software details
* ホスト（サーバー）ハードウェアとソフトウェアの詳細
* Interface acceleration type (such as DPDK and SR-IOV)
* インターフェイス加速タイプ（DPDKやSR-IOVなど）
* Used CPU cores
* 使用したCPUコア
* Used RAM
* 使用したRAM
* Resource sharing (e.g., pinning details and NUMA node) configuration details
* リソース共有（例：詳細とnumaノードのピン留め）構成の詳細
* Hypervisor version
* ハイパーバイザーバージョン
* Virtual switch version
* 仮想スイッチバージョン
e. Key test parameters
e. 重要なテストパラメーター
* Used cipher suites and keys
* 使用済みの暗号スイートとキー
* IPv4 and IPv6 traffic distribution
* IPv4およびIPv6トラフィック分布
* Number of configured ACLs
* 構成されたACLの数
* TCP and UDP stack parameter, if tested
* TCPおよびUDPスタックパラメーター（テストした場合）
* QUIC, HTTP/2, and HTTP/3 parameters, if tested
* quic、http/2、およびhttp/3パラメーター、テストした場合
f. Details of the application traffic mix used in the benchmarking test Throughput Performance with Application Traffic Mix (Section 7.1)
f. アプリケーショントラフィックミックスを使用したベンチマークテストスループットパフォーマンスで使用されるアプリケーショントラフィックミックスの詳細（セクション7.1）
* Name of applications and layer 7 protocols
* アプリケーションの名前とレイヤー7プロトコル
* Percentage of emulated traffic for each application and layer 7 protocols
* 各アプリケーションとレイヤー7プロトコルのエミュレートトラフィックの割合
* Percentage of encrypted traffic, used cipher suites, and keys (the RECOMMENDED ciphers and keys are defined in Section 4.3.1.4)
* 暗号化されたトラフィック、使用済み暗号スイート、キーの割合（推奨される暗号とキーは、セクション4.3.1.4で定義されています）
* Used object sizes for each application and layer 7 protocols
* 各アプリケーションに使用されたオブジェクトサイズとレイヤー7プロトコル
3. Results Summary / Executive Summary
3. 結果要約 /エグゼクティブサマリー
a. Results should be presented with an introduction section documenting the summary of results in a prominent, easy-to-read block.
a. 結果は、顕著で読みやすいブロックに結果の概要を文書化する紹介セクションで提示する必要があります。
In the results section of the test report, the following attributes should be present for each benchmarking test.
テストレポートの結果セクションでは、ベンチマークテストごとに次の属性が存在する必要があります。
a. KPIs MUST be documented separately for each benchmarking test. The format of the KPI metrics MUST be presented as described in Section 6.3.
a. KPIは、ベンチマークテストごとに個別に文書化する必要があります。KPIメトリックの形式は、セクション6.3で説明されているように提示する必要があります。
b. The next level of details should be graphs showing each of these metrics over the duration (sustain phase) of the test. This allows the user to see the measured performance stability changes over time.
b. 次のレベルの詳細は、テストの持続時間（サステインフェーズ）にわたってこれらの各メトリックを示すグラフである必要があります。これにより、ユーザーは測定されたパフォーマンスの安定性が時間の経過とともに変化するのを確認できます。
This section lists key performance indicators (KPIs) for overall benchmarking tests. All KPIs MUST be measured during the sustain phase of the traffic load profile described in Section 4.3.4. Also, the KPIs MUST be measured from the result output of test equipment.
このセクションには、ベンチマーク全体のテストの主要なパフォーマンスインジケーター（KPI）がリストされています。すべてのKPIは、セクション4.3.4で説明されているトラフィック負荷プロファイルのサステンフェーズ中に測定する必要があります。また、KPIは、テスト機器の結果出力から測定する必要があります。
Concurrent TCP Connections
同時TCP接続
The aggregate number of simultaneous connections between hosts across the DUT/SUT or between hosts and the DUT/SUT (defined in [RFC2647]).
DUT/SUT全体またはホストとDUT/SUTの間のホスト間の同時接続の総数（[RFC2647]で定義）。
Concurrent QUIC Connections
同時のquic接続
The aggregate number of simultaneous connections between hosts across the DUT/SUT.
DUT/SUT全体のホスト間の同時接続の総数。
TCP Connections Per Second
1秒あたりのTCP接続
The average number of successfully established TCP connections per second between hosts across the DUT/SUT or between hosts and the DUT/SUT. As described in Section 4.3.1.1, the TCP connections are initiated by clients via a TCP three-way handshake (SYN, SYN/ACK, ACK). Then, the TCP session data is sent, and then the TCP sessions are closed via either a TCP three-way close (FIN, FIN/ ACK, ACK) or a TCP four-way close (FIN, ACK, FIN, ACK). The TCP sessions MUST NOT be closed by RST.
DUT/SUT全体またはホストとDUT/SUTの間のホスト間で、1秒あたりに正常に確立されたTCP接続の平均数。セクション4.3.1.1で説明されているように、TCP接続は、TCP 3ウェイハンドシェイク（syn、syn/ack、ack）を介してクライアントによって開始されます。次に、TCPセッションデータが送信され、TCPセッションはTCP 3ウェイクローズ（FIN、FIN/ ACK、ACK）またはTCP 4ウェイクローズ（FIN、ACK、FIN、ACK）を介して閉鎖されます。TCPセッションは、最初に閉じてはなりません。
QUIC Connections Per Second
1秒あたりのQUIC接続
The average number of successfully established QUIC connections per second between hosts across the DUT/SUT. As described in Section 4.3.1.2, the QUIC connections are initiated by clients. Then, the data is sent, and then the QUIC sessions are closed by the "immediate close" method.
DUT/SUT全体のホスト間で、1秒あたりのQUIC接続に成功した平均数。セクション4.3.1.2で説明されているように、QUIC接続はクライアントによって開始されます。次に、データが送信され、その後、QUICセッションは「即時閉鎖」メソッドによって閉鎖されます。
Since the QUIC specification defined in Section 4.3.1.2 recommends disabling 0-RTT and early data, this KPI is focused on the 1-RTT handshake. If required, 0-RTT can be also measured in separate test runs while enabling 0-RTT and early data in the test equipment.
セクション4.3.1.2で定義されているQUIC仕様では、0-RTTおよび初期データの無効化を推奨するため、このKPIは1-RTTの握手に焦点を当てています。必要に応じて、0-RTTを個別のテスト実行で測定しながら、テスト機器の0-RTTおよび初期データを有効にすることもできます。
Application Transactions Per Second
アプリケーショントランザクションあたり
The average number of successfully completed transactions per second. For a particular transaction to be considered successful, all data MUST have been transferred in its entirety. In case of an HTTP(S) transaction, it MUST have a valid status code (200 OK).
1秒あたりの正常に完了したトランザクションの平均数。特定のトランザクションが成功するためには、すべてのデータが完全に転送されている必要があります。HTTPトランザクションの場合、有効なステータスコード（200 OK）が必要です。
TLS Handshake Rate
TLS握手率
The average number of successfully established TLS connections per second between hosts across the DUT/SUT or between hosts and the DUT/SUT.
DUT/SUT全体またはホストとDUT/SUT間のホスト間で、1秒あたりの確立されたTLS接続の平均数。
For TLS 1.3, the handshake rate can be measured with the 0-RTT or 1-RTT handshake. The transport protocol can be either TCP or QUIC.
TLS 1.3の場合、0-RTTまたは1-RTTの握手で握手速度を測定できます。輸送プロトコルは、TCPまたはQUICのいずれかです。
Inspected Throughput
検査されたスループット
The number of bits per second of examined and allowed traffic a network security device is able to transmit to the correct destination interface(s) in response to a specified offered load. The throughput benchmarking tests defined in Section 7 SHOULD measure the average layer 2 throughput value when the DUT/SUT is "inspecting" traffic. It is also acceptable to measure other OSI layer throughput. However, the measured layer (e.g., layer 3 throughput) MUST be noted in the report, and the user MUST be aware of the implication while comparing the throughput performance of multiple DUTs/SUTs measured in different OSI layers. This document recommends presenting the inspected throughput value in Gbit/s rounded to two places of precision with a more specific kbit/s in parenthesis.
検査および許可された1秒あたりのビット数ネットワークセキュリティデバイスは、指定された提供された負荷に応じて、正しい宛先インターフェイスに送信できます。セクション7で定義されているスループットベンチマークテストでは、DUT/SUTがトラフィックを「検査」している場合、平均レイヤー2スループット値を測定する必要があります。また、他のOSIレイヤースループットを測定することも許容できます。ただし、測定されたレイヤー（例：レイヤー3スループット）はレポートに記載されている必要があり、ユーザーは、異なるOSI層で測定された複数のDUT/SUTのスループットパフォーマンスを比較しながら、その意味に注意する必要があります。このドキュメントでは、括弧内のより具体的なKBIT/sを使用して、2つの正確な場所に丸められたGBIT/sで検査されたスループット値を提示することを推奨しています。
Time to First Byte (TTFB)
最初のバイト（TTFB）までの時間
The elapsed time between the start of sending the TCP SYN packet or QUIC initial Client Hello from the client and the client receiving the first packet of application data from the server via the DUT/SUT. The benchmarking tests HTTP transaction latency (Section 7.4) and HTTPS transaction latency (Section 7.8) measure the minimum, average, and maximum TTFB. The value should be expressed in milliseconds.
クライアントからTCP SynパケットまたはQUIC初期クライアントのHelloを送信する開始までの経過時間と、DUT/SUTを介してサーバーからアプリケーションデータの最初のパケットを受信するクライアント。ベンチマークテストHTTPトランザクションレイテンシ（セクション7.4）およびHTTPSトランザクションレイテンシ（セクション7.8）は、最小、平均、および最大TTFBを測定します。値はミリ秒で表現する必要があります。
URL Response Time / Time to Last Byte (TTLB)
URL応答時間 /最後のバイト（TTLB）への時間
The elapsed time between the start of sending the TCP SYN packet or QUIC initial Client Hello from the client and the client receiving the last packet of application data from the server via the DUT/SUT. The benchmarking tests HTTP transaction latency (Section 7.4) and HTTPS transaction latency (Section 7.8) measure the minimum, average, and maximum TTLB. The value should be expressed in milliseconds.
クライアントからTCP SynパケットまたはQUIC初期クライアントのHelloを送信するか、DUT/SUTを介してサーバーからアプリケーションデータの最後のパケットを受信したクライアントを送信するまでの経過時間。ベンチマークテストHTTPトランザクションレイテンシ（セクション7.4）およびHTTPSトランザクションレイテンシ（セクション7.8）は、最小、平均、および最大TTLBを測定します。値はミリ秒で表現する必要があります。
This section mainly focuses on the benchmarking tests with HTTP/1.1 or HTTP/2 traffic, which uses TCP as the transport protocol. In particular, this section does not define specific benchmarking tests for KPIs related to QUIC or HTTP/3. However, the test methodology defined in the benchmarking tests TCP or QUIC connections per second with HTTPS traffic (Section 7.6), HTTPS transaction latency (Section 7.8), HTTPS throughput (Section 7.7), and concurrent TCP or QUIC connection capacity with HTTPS traffic (Section 7.9) can be used to test KPIs related to QUIC or HTTP/3. The throughput performance test with the application traffic mix defined in Section 7.1 can be performed with any other application traffic, including HTTP/3.
このセクションでは、主に、TCPを輸送プロトコルとして使用するHTTP/1.1またはHTTP/2トラフィックを使用したベンチマークテストに焦点を当てています。特に、このセクションでは、QUICまたはHTTP/3に関連するKPIの特定のベンチマークテストを定義しません。ただし、HTTPSトラフィック（セクション7.6）、HTTPSトランザクションレイテンシ（セクション7.8）、HTTPSスループット（セクション7.7）、およびHTTPSトラフィックの同時接続容量（HTTPSトランザクションレイテンシ（セクション7.6））とのベンチマークテストTCPまたはQUIC接続で定義されたテスト方法論は、セクション7.9）は、QUICまたはHTTP/3に関連するKPIをテストするために使用できます。セクション7.1で定義されたアプリケーショントラフィックミックスを使用したスループットパフォーマンステストは、HTTP/3を含む他のアプリケーショントラフィックで実行できます。
Using a relevant application traffic mix, determine the sustainable inspected throughput supported by the DUT/SUT.
関連するアプリケーショントラフィックミックスを使用して、DUT/SUTによってサポートされている持続可能な検査スループットを決定します。
Based on the test customer's specific use case, testers can choose the relevant application traffic mix for this test. The details about the traffic mix MUST be documented in the report. At least, the following traffic mix details MUST be documented and reported together with the test results:
テスト顧客の特定のユースケースに基づいて、テスターはこのテストに関連するアプリケーショントラフィックミックスを選択できます。トラフィックミックスの詳細は、レポートに文書化する必要があります。少なくとも、次のトラフィックミックスの詳細を文書化し、テスト結果とともに報告する必要があります。
* Name of applications and layer 7 protocols
* アプリケーションの名前とレイヤー7プロトコル
* Percentage of emulated traffic for each application and layer 7 protocol
* 各アプリケーションのエミュレートトラフィックの割合とレイヤー7プロトコル
* Percentage of encrypted traffic and used cipher suites and keys (the RECOMMENDED ciphers and keys are defined in Section 4.3.1.4)
* 暗号化されたトラフィックと使用済みの暗号スイートとキーの割合（推奨される暗号とキーは、セクション4.3.1.4で定義されています）
* Used object sizes for each application and layer 7 protocols
* 各アプリケーションに使用されたオブジェクトサイズとレイヤー7プロトコル
The testbed setup MUST be configured as defined in Section 4. Any benchmarking-test-specific testbed configuration changes MUST be documented.
テストベッドのセットアップは、セクション4で定義されているように構成する必要があります。ベンチマークテスト固有のテストベッド構成の変更を文書化する必要があります。
In this section, the benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. If the DUT/SUT is configured without TLS inspection, the test report MUST explain how this impacts the encrypted traffic of the relevant application traffic mix.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。DUT/SUTがTLS検査なしで構成されている場合、テストレポートは、これが関連するアプリケーショントラフィックミックスの暗号化されたトラフィックにどのように影響するかを説明する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target inspected throughput: Aggregated line rate of one or more interfaces used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario
* ターゲット検査スループット：DUT/SUTで使用される1つまたは複数のインターフェイスの集約ラインレートまたは特定の展開シナリオの要件に基づいて定義された値
* Initial throughput: 10% of the "Target inspected throughput"
* 初期スループット：「ターゲット検査スループット」の10％
* Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.1.4.
* 注：初期スループットは、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.1.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* One of the ciphers and keys defined in Section 4.3.1.4 is RECOMMENDED to use for this benchmarking test.
* セクション4.3.1.4で定義されている暗号とキーの1つは、このベンチマークテストに使用することをお勧めします。
This test MUST be run with a relevant application traffic mix profile.
このテストは、関連するアプリケーショントラフィックミックスプロファイルで実行する必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions MUST be less than 0.001% (1 out of 100,000 transactions) of the attempted transactions.
a. 故障したアプリケーショントランザクションの数は、試行されたトランザクションの0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。
c. If HTTP/3 is used, the number of failed QUIC connections due to unexpected HTTP/3 error codes MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated QUIC connections.
c. HTTP/3を使用すると、予期しないHTTP/3エラーコードによる失敗したQUIC接続の数は、開始されたQUIC接続の0.001％（100,000接続のうち1つ）未満でなければなりません。
The following KPI metrics MUST be reported for this benchmarking test:
このベンチマークテストでは、次のKPIメトリックを報告する必要があります。
* Mandatory KPIs (benchmarks): inspected throughput and application transactions per second
* 必須のKPI（ベンチマーク）：検査されたスループットおよびアプリケーショントランザクションあたり
* Note: The TTLB MUST be reported along with the object size used in the traffic profile.
* 注：TTLBは、トラフィックプロファイルで使用されるオブジェクトサイズとともに報告する必要があります。
* Optional TCP-stack-related KPIs: TCP connections per second, TLS handshake rate, TTFB (minimum, average, and maximum), TTLB (minimum, average, and maximum)
* オプションのTCPスタック関連KPI：TCP接続あたりのTCP接続、TLSハンドシェイクレート、TTFB（最小、平均、および最大）、TTLB（最小、平均、最大）
* Optional QUIC-stack-related KPIs: QUIC connections per second and concurrent QUIC connections
* オプションのQUICスタック関連KPI：秒あたりのQUIC接続と同時のQUIC接続
The test procedures are designed to measure the inspected throughput performance of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (initial throughput) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、トラフィック負荷プロファイルの持続期間でDUT/SUTの検査されたスループット性能を測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（初期スループット）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution.
このテスト手順は、異なるIPタイプのIPv4のみ、IPv6のみ、IPv4とIPv6混合トラフィック分布で複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to generate test traffic at the "initial throughput" rate, as described in Section 7.1.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4. The DUT/SUT MUST reach the "initial throughput" during the sustain phase. Measure all KPIs, as defined in Section 7.1.3.5. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.1.3.4.
セクション7.1.3.2で説明されているように、テスト機器のトラフィック負荷プロファイルを構成して、「初期スループット」レートでテストトラフィックを生成します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。DUT/SUTは、サステンフェーズ中に「初期スループット」に到達する必要があります。セクション7.1.3.5で定義されているように、すべてのKPIを測定します。Sustainフェーズ中の測定されたKPIは、セクション7.1.3.4で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to generate traffic at the "Target inspected throughput" rate defined in Section 7.1.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
セクション7.1.3.2で定義された「ターゲット検査スループット」レートでトラフィックを生成するようにテスト機器を構成します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target inspected throughput") in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステンフェーズでターゲット目標（「ターゲット検査スループット」）の望ましい値（「ターゲット検査スループット」）に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable average inspected throughput within the test results validation criteria. The final test iteration MUST be performed for the test duration defined in Section 4.3.4.
テスト結果の検証基準内で達成可能な平均検査スループットを決定します。セクション4.3.4で定義されているテスト期間については、最終的なテスト反復を実行する必要があります。
Using HTTP traffic, determine the sustainable TCP connection establishment rate supported by the DUT/SUT under different throughput load conditions.
HTTPトラフィックを使用して、異なるスループット負荷条件下でDUT/SUTがサポートする持続可能なTCP接続確立率を決定します。
To measure connections per second, test iterations MUST use different fixed HTTP response object sizes (the different load conditions) defined in Section 7.2.3.2.
1秒あたりの接続を測定するには、テスト反復は、セクション7.2.3.2で定義されている異なる固定HTTP応答オブジェクトサイズ（異なる負荷条件）を使用する必要があります。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target connections per second: Initial value from the product datasheet or the value defined based on the requirement for a specific deployment scenario
* 1秒あたりのターゲット接続：製品データシートからの初期値または特定の展開シナリオの要件に基づいて定義された値
* Initial connections per second: 10% of "Target connections per second"
* 1秒あたりの初期接続：「標的接続あたりのターゲット接続」の10％
* Note: Initial connections per second is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.2.4.
* 注：1秒あたりの初期接続は、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.2.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KB.
* 推奨される応答オブジェクトサイズは、1、2、4、16、および64 kbです。
The client MUST negotiate HTTP and close the connection with FIN immediately after the completion of one transaction. In each test iteration, the client MUST send a GET request requesting a fixed HTTP response object size.
クライアントは、1つのトランザクションが完了した直後にHTTPを交渉し、FINとの接続を閉じる必要があります。各テストの反復で、クライアントは固定されたHTTP応答オブジェクトサイズを要求するGETリクエストを送信する必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、試行されたトランザクションの0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
d. Concurrent TCP connections MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate.
d. 同時TCP接続は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。これにより、DUTが開始され、TCP接続がほぼ同じレートで閉鎖されます。
TCP connections per second MUST be reported for each test iteration (for each object size).
各テスト反復（各オブジェクトサイズ）について、1秒あたりのTCP接続を報告する必要があります。
The test procedure is designed to measure the DUT/SUT's rate of TCP connections per second during the sustaining period of the traffic load profile. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (Initial connections per second) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、交通負荷プロファイルの持続期間中にDUT/SUTのTCP接続のレートを1秒あたり測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（1秒あたりの初期接続）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution.
このテスト手順は、異なるIPタイプのIPv4のみ、IPv6のみ、IPv4とIPv6混合トラフィック分布で複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish "Initial connections per second", as defined in Section 7.2.3.2. The traffic load profile MUST be defined as described in Section 4.3.4.
セクション7.2.3.2で定義されているように、テスト機器のトラフィック負荷プロファイルを構成して、「秒あたりの初期接続」を確立します。トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。
The DUT/SUT MUST reach the "Initial connections per second" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.2.3.3.
DUT/SUTは、サステインフェーズの前に「1秒あたりの初期接続」に到達する必要があります。サステインフェーズ中の測定されたKPIは、セクション7.2.3.3で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT continue to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順はステップ2を継続してはなりません。
Configure test equipment to establish the target objective ("Target connections per second") defined in Section 7.2.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4.
セクション7.2.3.2で定義されているターゲット目標（「ターゲット接続」）を確立するために、テスト機器を構成します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。
During the ramp up and sustain phases of each test iteration, other KPIs, such as inspected throughput, concurrent TCP connections, and application transactions per second, MUST NOT reach the maximum value the DUT/SUT can support. The test results for specific test iterations MUST NOT be reported as valid results if the abovementioned KPI (especially inspected throughput) reaches the maximum value. (For example, if the test iteration with 64 KB of HTTP response object size reached the maximum inspected throughput limitation of the DUT/SUT, the test iteration MAY be interrupted and the result for 64 KB must not be reported.)
各テスト反復のランプアップおよびサステンフェーズ中、検査されたスループット、同時TCP接続、アプリケーショントランザクションなどの他のKPIは、DUT/SUTがサポートできる最大値に達してはなりません。特定のテスト反復のテスト結果は、上記のKPI（特に検査されたスループット）が最大値に達した場合、有効な結果として報告してはなりません。（たとえば、64 kBのHTTP応答オブジェクトサイズを使用したテスト反復がDUT/SUTの最大検査スループット制限に達した場合、テスト反復が中断され、64 kBの結果を報告する必要はありません。）
The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target connections per second") in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズでターゲット目標（「ターゲット接続」）の望ましい値（「ターゲット接続」）に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable TCP connections per second within the test results validation criteria.
テスト結果の検証基準内で、達成可能なTCP接続を1秒あたりに決定します。
Determine the sustainable inspected throughput of the DUT/SUT for HTTP transactions varying the HTTP response object size.
HTTP応答オブジェクトサイズを変更するHTTPトランザクションのDUT/SUTの持続可能な検査スループットを決定します。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target inspected throughput: Aggregated line rate of one or more interfaces used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario
* ターゲット検査スループット：DUT/SUTで使用される1つまたは複数のインターフェイスの集約ラインレートまたは特定の展開シナリオの要件に基づいて定義された値
* Initial throughput: 10% of "Target inspected throughput"
* 初期スループット：「ターゲット検査スループット」の10％
* Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.3.4.
* 注：初期スループットは、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.3.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* Number of HTTP response object requests (transactions) per connection: 10
* 接続ごとにHTTP応答オブジェクト要求（トランザクション）の数：10
* RECOMMENDED HTTP response object size: 1, 16, 64, and 256 KB and mixed objects defined in Table 5
* 推奨されるHTTP応答オブジェクトサイズ：1、16、64、および256 KBと表5で定義されている混合オブジェクト
+==================+=============================+
| Object size (KB) | Number of requests / Weight |
+==================+=============================+
| 0.2 | 1 |
+------------------+-----------------------------+
| 6 | 1 |
+------------------+-----------------------------+
| 8 | 1 |
+------------------+-----------------------------+
| 9 | 1 |
+------------------+-----------------------------+
| 10 | 1 |
+------------------+-----------------------------+
| 25 | 1 |
+------------------+-----------------------------+
| 26 | 1 |
+------------------+-----------------------------+
| 35 | 1 |
+------------------+-----------------------------+
| 59 | 1 |
+------------------+-----------------------------+
| 347 | 1 |
+------------------+-----------------------------+
Table 5: Mixed Objects
表5：混合オブジェクト
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the total attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、合計試行試行の0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. Traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
b. トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満である場合、一定の速度と見なされます）。
c. Concurrent TCP connections MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate.
c. 同時TCP接続は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。これにより、DUTが開始され、TCP接続がほぼ同じレートで閉鎖されます。
Inspected throughput and HTTP transactions per second MUST be reported for each object size.
検査されたスループットとHTTPトランザクションは、各オブジェクトサイズについて報告する必要があります。
The test procedure is designed to measure HTTP throughput of the DUT/ SUT. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (initial throughput) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、DUT/ SUTのHTTPスループットを測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（初期スループット）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions and HTTP response object sizes.
このテスト手順は、異なるIPv4およびIPv6トラフィック分布とHTTP応答オブジェクトサイズで複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish "initial throughput", as defined in Section 7.3.3.2.
セクション7.3.3.2で定義されているように、「初期スループット」を確立するために、テスト機器のトラフィック負荷プロファイルを構成します。
The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "initial throughput" during the sustain phase. Measure all KPIs, as defined in Section 7.3.3.4.
トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。DUT/SUTは、サステンフェーズ中に「初期スループット」に到達する必要があります。セクション7.3.3.4で定義されているように、すべてのKPIを測定します。
The measured KPIs during the sustain phase MUST meet the test results validation criteria "a" defined in Section 7.3.3.3. The test results validation criteria "b" and "c" are OPTIONAL for Step 1.
サステインフェーズ中の測定されたKPIは、セクション7.3.3.3で定義されているテスト結果の検証基準「A」を満たす必要があります。テスト結果の検証基準「B」と「C」は、ステップ1のオプションです。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objective ("Target inspected throughput") defined in Section 7.3.3.2. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
セクション7.3.3.2で定義されているターゲット目標（「ターゲット検査スループット」）を確立するようにテスト機器を構成します。テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズの目標目標の望ましい値に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable inspected throughput within the test results validation criteria and measure the KPI metric transactions per second. The final test iteration MUST be performed for the test duration defined in Section 4.3.4.
テスト結果の検証基準内で達成可能な検査されたスループットを決定し、1秒あたりのKPIメトリックトランザクションを測定します。セクション4.3.4で定義されているテスト期間については、最終的なテスト反復を実行する必要があります。
Using HTTP traffic, determine the HTTP transaction latency when the DUT is running with sustainable HTTP transactions per second supported by the DUT/SUT under different HTTP response object sizes.
HTTPトラフィックを使用して、DUTが異なるHTTP応答オブジェクトサイズの下でDUT/SUTによってサポートされている持続可能なHTTPトランザクションでDUTが実行されているときにHTTPトランザクションレイテンシを決定します。
Test iterations MUST be performed with different HTTP response object sizes in two different scenarios: one with a single transaction and the other with multiple transactions within a single TCP connection. For consistency, both the single and multiple transaction tests MUST be configured with the same HTTP version.
テストイテレーションは、2つの異なるシナリオで異なるHTTP応答オブジェクトサイズで実行する必要があります。1つは単一のトランザクションを備えたもので、もう1つは単一のTCP接続内で複数のトランザクションを備えています。一貫性のために、単一および複数のトランザクションテストの両方を同じHTTPバージョンで構成する必要があります。
Scenario 1: The client MUST negotiate HTTP and close the connection with FIN immediately after the completion of a single transaction (GET and RESPONSE).
シナリオ1：クライアントは、単一のトランザクションが完了した直後にHTTPを交渉し、FINとの接続を閉じる必要があります（GETと応答）。
Scenario 2: The client MUST negotiate HTTP and close the connection with FIN immediately after the completion of 10 transactions (GET and RESPONSE) within a single TCP connection.
シナリオ2：クライアントは、単一のTCP接続内で10回のトランザクション（GETおよび応答）が完了した直後にHTTPを交渉し、FINとの接続を閉じる必要があります。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target objective for scenario 1: 50% of the connections per second measured in the benchmarking test TCP connections per second with HTTP traffic (Section 7.2)
* シナリオの目標目標1：1秒あたりの接続の50％は、ベンチマークテストTCP接続でHTTPトラフィックで測定されました（セクション7.2）
* Target objective for scenario 2: 50% of the inspected throughput measured in the benchmarking test HTTP throughput (Section 7.3)
* シナリオの目標目標2：ベンチマークテストで測定された検査されたスループットの50％HTTPスループット（セクション7.3）
* Initial objective for scenario 1: 10% of "Target objective for scenario 1"
* シナリオ1：10％の「シナリオ1の目標目標」の最初の目的
* Initial objective for scenario 2: 10% of "Target objective for scenario 2"
* シナリオ2：「シナリオ2の目標目標」の10％の最初の目的
* Note: The initial objectives are not KPIs to report. These values are configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.4.4.
* 注：最初の目的は、報告するKPIではありません。これらの値は、トラフィックジェネレーターで構成され、セクション7.4.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* HTTP transaction per TCP connection: Test scenario 1 with a single transaction and test scenario 2 with 10 transactions
* TCP接続ごとのHTTPトランザクション：テストシナリオ1単一のトランザクションおよびテストシナリオ2を使用して10トランザクションを使用して2
* HTTP with GET request requesting a single object: The RECOMMENDED object sizes are 1, 16, and 64 KB. For each test iteration, the client MUST request a single HTTP response object size.
* get requestを使用したHTTP単一オブジェクト：推奨されるオブジェクトサイズは1、16、および64 kbです。各テスト反復について、クライアントは単一のHTTP応答オブジェクトサイズを要求する必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the total attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、合計試行試行の0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
d. Concurrent TCP connections MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate.
d. 同時TCP接続は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。これにより、DUTが開始され、TCP接続がほぼ同じレートで閉鎖されます。
e. After ramp up, the DUT MUST achieve the target objectives defined in Section 7.4.3.2 and remain in that state for the entire test duration (sustain phase).
e. ランプアップ後、DUTはセクション7.4.3.2で定義されている目標目標を達成し、テスト期間全体（サステインフェーズ）の間、その状態にとどまらなければなりません。
The TTFB (minimum, average, and maximum) and TTLB (minimum, average, and maximum) MUST be reported for each object size.
TTFB（最小、平均、最大）およびTTLB（最小、平均、および最大）は、各オブジェクトサイズについて報告する必要があります。
The test procedure is designed to measure the TTFB or TTLB when the DUT/SUT is operating close to 50% of its maximum achievable connections per second or inspected throughput. The test procedure consists of two major steps. Step 1 ensures the DUT/SUT is able to reach the initial performance values and meets the test results validation criteria when it was very minimally utilized. Step 2 measures the latency values within the test results validation criteria.
テスト手順は、DUT/SUTが1秒あたりの最大達成可能な接続の50％近くまたは検査されたスループットの50％近くで動作している場合に、TTFBまたはTTLBを測定するように設計されています。テスト手順は、2つの主要なステップで構成されています。ステップ1 DUT/SUTが初期のパフォーマンス値に到達できるようにし、非常に最小限に及ぼすときにテスト結果の検証基準を満たすことができます。ステップ2は、テスト結果の検証基準内の遅延値を測定します。
This test procedure MAY be repeated multiple times with different IP types (IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution), HTTP response object sizes, and single and multiple transactions per connection scenarios.
このテスト手順は、異なるIPタイプ（IPv4のみ、IPv6のみ、IPv4およびIPv6混合トラフィック分布）、HTTP応答オブジェクトサイズ、および接続シナリオごとの単一および複数のトランザクションで複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish the initial objectives, as defined in Section 7.4.3.2. The traffic load profile MUST be defined as described in Section 4.3.4.
セクション7.4.3.2で定義されているように、テスト機器のトラフィック負荷プロファイルを構成して、初期目標を確立します。トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。
The DUT/SUT MUST reach the initial objectives before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.4.3.3.
DUT/SUTは、サステインフェーズの前に初期目標に到達する必要があります。Sustainフェーズ中の測定されたKPIは、セクション7.4.3.3で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objectives defined in Section 7.4.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4.
テスト機器を構成して、セクション7.4.3.2で定義されているターゲット目標を確立します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。
The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT MUST reach the desired value of the target objective in the sustain phase.
テスト結果の検証基準内で、DUT/SUTは、サステンフェーズの目標目標の望ましい値に達する必要があります。
Measure the minimum, average, and maximum values of the TTFB and TTLB.
TTFBおよびTTLBの最小値、平均値、最大値を測定します。
Determine the number of concurrent TCP connections that the DUT/SUT sustains when using HTTP traffic.
HTTPトラフィックを使用するときにDUT/SUTが持続する同時のTCP接続の数を決定します。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be noted for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストでは、次のパラメーターに注意する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target concurrent connection: Initial value from the product datasheet or the value defined based on the requirement for a specific deployment scenario
* ターゲットの同時接続：製品データシートからの初期値または特定の展開シナリオの要件に基づいて定義された値
* Initial concurrent connection: 10% of "Target concurrent connection"
* 初期同時接続：「ターゲットコンカレント接続」の10％
* Note: Initial concurrent connection is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.5.4.
* 注：最初の同時接続は、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.5.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* Maximum connections per second during ramp up phase: 50% of maximum connections per second measured in the benchmarking test TCP connections per second with HTTP traffic (Section 7.2)
* ランプアップフェーズ中の1秒あたりの最大接続：HTTPトラフィックとのベンチマークテストTCP接続で測定された1秒あたりの最大接続の50％（セクション7.2）
* Ramp up time (in traffic load profile for "Target concurrent connection"): "Target concurrent connection" / "Maximum connections per second during ramp up phase"
* ランプアップ時間（「ターゲットコンキュラント接続」のトラフィック負荷プロファイル）：「ターゲットコンカレント接続」 /「ランプアップフェーズ中の秒あたりの最大接続」
* Ramp up time (in traffic load profile for "Initial concurrent connection"): "Initial concurrent connection" / "Maximum connections per second during ramp up phase"
* ランプアップ時間（「初期コンカレント接続」のトラフィック負荷プロファイル）：「ランプアップフェーズ中の1秒あたりの最大接続」 /「最大接続」
The client MUST negotiate HTTP, and each client MAY open multiple concurrent TCP connections per server endpoint IP.
クライアントはHTTPをネゴシエートする必要があり、各クライアントはサーバーエンドポイントIPごとに複数の同時TCP接続を開くことができます。
Each client sends 10 GET requests requesting 1 KB HTTP response object in the same TCP connection (10 transactions / TCP connections), and the delay (think time) between each transaction MUST be X seconds, where X is as follows.
各クライアントは、同じTCP接続（10トランザクション / TCP接続）で1 kbのHTTP応答オブジェクトを要求する10のGETリクエストを送信し、各トランザクション間の遅延（検討時間）はX秒でなければなりません。ここで、Xは次のとおりです。
X = ("Ramp up time" + "steady state time") / 10
x =（ "ランプアップタイム" "定常状態時間"） / 10
The established connections MUST remain open until the ramp down phase of the test. During the ramp down phase, all connections MUST be successfully closed with FIN.
確立された接続は、テストのランプダウンフェーズまで開いたままでなければなりません。ランプダウンフェーズでは、すべての接続をFINで正常に閉じる必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the total attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、合計試行試行の0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
Average concurrent TCP connections MUST be reported for this benchmarking test.
このベンチマークテストでは、平均同時TCP接続を報告する必要があります。
The test procedure is designed to measure the concurrent TCP connection capacity of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (Initial concurrent connection) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、トラフィック負荷プロファイルの持続期間でのDUT/SUTの同時TCP接続容量を測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（初期同時接続）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions.
このテスト手順は、異なるIPv4およびIPv6トラフィック分布で複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure test equipment to establish "Initial concurrent connections" defined in Section 7.5.3.2. Except ramp up time, the traffic load profile MUST be defined as described in Section 4.3.4.
セクション7.5.3.2で定義されている「初期同時接続」を確立するために、テスト機器を構成します。ランプアップ時間を除いて、セクション4.3.4で説明されているように、トラフィック負荷プロファイルを定義する必要があります。
During the sustain phase, the DUT/SUT MUST reach the "Initial concurrent connections". The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.5.3.3.
サステンフェーズ中、DUT/SUTは「初期の同時接続」に到達する必要があります。Sustainフェーズ中の測定されたKPIは、セクション7.5.3.3で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objective ("Target concurrent TCP connections"). The test equipment MUST follow the traffic load profile definition (except ramp up time) as described in Section 4.3.4.
テスト機器を構成して、ターゲット目標（「ターゲットの同時TCP接続」）を確立します。テスト機器は、セクション4.3.4で説明されているように、トラフィックロードプロファイルの定義（ランプアップ時間を除く）に従う必要があります。
During the ramp up and sustain phases, the other KPIs, such as inspected throughput, TCP connections per second, and application transactions per second, MUST NOT reach the maximum value the DUT/SUT can support.
ランプアップおよびサステインフェーズ中、検査されたスループット、1秒あたりのTCP接続、およびアプリケーショントランザクションなどの他のKPIは、DUT/SUTがサポートできる最大値に達してはなりません。
The test equipment MUST start to measure and record KPIs defined in Section 7.5.3.4. Continue the test until all traffic profile phases are completed.
テスト機器は、セクション7.5.3.4で定義されているKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズの目標目標の望ましい値に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable concurrent TCP connections capacity within the test results validation criteria.
テスト結果検証基準内で、達成可能な同時TCP接続容量を決定します。
Using HTTPS traffic, determine the sustainable TLS session establishment rate supported by the DUT/SUT under different throughput load conditions.
HTTPSトラフィックを使用して、異なるスループット負荷条件下でDUT/SUTがサポートする持続可能なTLSセッション確立率を決定します。
Test iterations MUST include common cipher suites and key strengths, as well as forward-looking stronger keys. Specific test iterations MUST include ciphers and keys defined in Section 7.6.3.2.
テストの反復には、一般的な暗号スイートと重要な強度、および将来の見通しの強力なキーが含まれている必要があります。特定のテスト反復には、セクション7.6.3.2で定義された暗号とキーを含める必要があります。
For each cipher suite and key strength, test iterations MUST use a single HTTPS response object size defined in Section 7.6.3.2 to measure connections per second performance under a variety of DUT/SUT security inspection load conditions.
各暗号スイートとキー強度ごとに、テスト反復は、セクション7.6.3.2で定義された単一のHTTPS応答オブジェクトサイズを使用して、さまざまなDUT/SUTセキュリティ検査負荷条件下で1秒あたりのパフォーマンスを測定する必要があります。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target connections per second: Initial value from the product datasheet or the value defined based on the requirement for a specific deployment scenario
* 1秒あたりのターゲット接続：製品データシートからの初期値または特定の展開シナリオの要件に基づいて定義された値
* Initial connections per second: 10% of "Target connections per second"
* 1秒あたりの初期接続：「標的接続あたりのターゲット接続」の10％
* Note: Initial connections per second is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.6.4.)
* 注：1秒あたりの初期接続は、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.6.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* RECOMMENDED ciphers and keys defined in Section 4.3.1.4
* セクション4.3.1.4で定義されている推奨される暗号とキー
* The RECOMMENDED object sizes are 1, 2, 4, 16, and 64 KB.
* 推奨されるオブジェクトサイズは、1、2、4、16、および64 kbです。
The client MUST negotiate HTTPS and close the connection without error immediately after the completion of one transaction. In each test iteration, the client MUST send a GET request requesting a fixed HTTPS response object size.
クライアントは、1つのトランザクションが完了した直後にHTTPSを交渉し、エラーなしで接続を閉じる必要があります。各テスト反復で、クライアントは、固定されたHTTPS応答オブジェクトサイズを要求するGETリクエストを送信する必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole test duration.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、テスト期間全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、試行されたトランザクションの0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated QUIC connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。HTTP/3を使用すると、予期しないエラーによる終了したQUIC接続の数は、開始されたQUIC接続の0.001％（100,000の接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
d. The concurrent TCP connections generation rate MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent QUIC connections generation rate MUST be constant during steady state, and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate.
d. 同時TCP接続の生成率は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。HTTP/3を使用する場合、定常状態では同時のQUIC接続生成率が一定でなければならず、同時のQUIC接続の偏差は10％未満でなければなりません。これにより、DUTがオープンし、ほぼ同じレートで接続を閉じることが確認されます。
If HTTP 1.1 or HTTP/2 is used, TCP connections per second MUST be reported for each test iteration (for each object size).
HTTP 1.1またはHTTP/2が使用されている場合、各テスト反復（各オブジェクトサイズ）について毎秒TCP接続を報告する必要があります。
If HTTP/3 is used, QUIC connections per second MUST be measured and reported for each test iteration (for each object size).
HTTP/3を使用する場合、各テスト反復（各オブジェクトサイズ）について、1秒あたりのQUIC接続を測定し、報告する必要があります。
The KPI metric TLS handshake rate can be measured in the test using 1 KB object size.
KPIメトリックTLSハンドシェイクレートは、1 KBオブジェクトサイズを使用してテストで測定できます。
The test procedure is designed to measure the DUT/SUT's rate of TCP or QUIC connections per second during the sustaining period of the traffic load profile. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (Initial connections per second) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、トラフィック負荷プロファイルの持続期間中に、DUT/SUTのTCPまたはQUIC接続のレートまたはQUIC接続のレートを測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（1秒あたりの初期接続）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions.
このテスト手順は、異なるIPv4およびIPv6トラフィック分布で複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish "Initial connections per second", as defined in Section 7.6.3.2. The traffic load profile MUST be defined as described in Section 4.3.4.
セクション7.6.3.2で定義されているように、テスト機器のトラフィック負荷プロファイルを構成して、「秒あたりの初期接続」を確立します。トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。
The DUT/SUT MUST reach the "Initial connections per second" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.6.3.3.
DUT/SUTは、サステインフェーズの前に「1秒あたりの初期接続」に到達する必要があります。サステンフェーズ中の測定されたKPIは、セクション7.6.3.3で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish "Target connections per second", as defined in Section 7.6.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4.
セクション7.6.3.2で定義されているように、テスト機器を構成して、「秒あたりのターゲット接続」を確立します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。
During the ramp up and sustain phases, other KPIs, such as inspected throughput, concurrent TCP or QUIC connections, and application transactions per second, MUST NOT reach the maximum value the DUT/SUT can support. The test results for the specific test iteration MUST NOT be reported as valid results if the abovementioned KPI (especially inspected throughput) reaches the maximum value. (For example, if the test iteration with 64 KB of HTTPS response object size reached the maximum inspected throughput limitation of the DUT, the test iteration MAY be interrupted, and the result for 64 KB should not be reported).
ランプアップおよびサステインフェーズ中、検査されたスループット、同時TCPまたはQUIC接続、およびアプリケーショントランザクションなどの他のKPIは、DUT/SUTがサポートできる最大値に達してはなりません。特定のテスト反復のテスト結果は、上記のKPI（特に検査されたスループット）が最大値に達した場合、有効な結果として報告してはなりません。（たとえば、64 kbのHTTPS応答オブジェクトサイズを使用したテスト反復がDUTの最大検査スループット制限に達した場合、テスト反復が中断される可能性があり、64 kBの結果を報告する必要はありません）。
The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target connections per second") in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズでターゲット目標（「ターゲット接続」）の望ましい値（「ターゲット接続」）に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable connections per second within the test results validation criteria.
テスト結果の検証基準内で達成可能な接続を1秒あたり決定します。
Determine the sustainable inspected throughput of the DUT/SUT for HTTPS transactions by varying the HTTPS response object size.
HTTPS応答オブジェクトサイズを変化させることにより、HTTPSトランザクションのDUT/SUTの持続可能な検査スループットを決定します。
Test iterations MUST include common cipher suites and key strengths, as well as forward-looking stronger keys. Specific test iterations MUST include the ciphers and keys defined in Section 7.7.3.2.
テストの反復には、一般的な暗号スイートと重要な強度、および将来の見通しの強力なキーが含まれている必要があります。特定のテスト反復には、セクション7.7.3.2で定義されている暗号とキーを含める必要があります。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* Target inspected throughput: Aggregated line rate of one or more interfaces used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario
* ターゲット検査スループット：DUT/SUTで使用される1つまたは複数のインターフェイスの集約ラインレートまたは特定の展開シナリオの要件に基づいて定義された値
* Initial throughput: 10% of "Target inspected throughput"
* 初期スループット：「ターゲット検査スループット」の10％
* Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.7.4.
* 注：初期スループットは、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.7.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* Number of HTTPS response object requests (transactions) per connection: 10
* 接続ごとにHTTPS応答オブジェクト要求（トランザクション）の数：10
* RECOMMENDED ciphers and keys defined in Section 4.3.1.4
* セクション4.3.1.4で定義されている推奨される暗号とキー
* RECOMMENDED HTTPS response object size: 1, 16, 64, and 256 KB and mixed objects defined in Table 5 of Section 7.3.3.2
* 推奨されるHTTPS応答オブジェクトサイズ：1、16、64、および256 KBとセクション7.3.3.2の表5に定義されている混合オブジェクト
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、試行されたトランザクションの0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. Traffic MUST be generated at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
b. トラフィックは一定の速度で生成する必要があります（トラフィック転送レートの偏差が5％未満の場合、一定の速度と見なされます）。
c. The concurrent generated TCP connections MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent generated QUIC connections MUST be constant during steady state, and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate.
c. 同時生成されたTCP接続は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。HTTP/3を使用する場合、定常状態では同時生成されたQUIC接続が一定でなければならず、同時のQUIC接続の偏差は10％未満でなければなりません。これにより、DUTがオープンし、ほぼ同じレートで接続を閉じることが確認されます。
Inspected throughput and HTTPS transactions per second MUST be reported for each object size.
検査されたスループットおよびHTTPSトランザクションは、各オブジェクトサイズについて報告する必要があります。
The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (initial throughput) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（初期スループット）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions and HTTPS response object sizes.
このテスト手順は、異なるIPv4およびIPv6トラフィック分布とHTTPS応答オブジェクトサイズで複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish "initial throughput", as defined in Section 7.7.3.2.
セクション7.7.3.2で定義されているように、「初期スループット」を確立するために、テスト機器のトラフィック負荷プロファイルを構成します。
The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "initial throughput" during the sustain phase. Measure all KPIs, as defined in Section 7.7.3.4.
トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。DUT/SUTは、サステンフェーズ中に「初期スループット」に到達する必要があります。セクション7.7.3.4で定義されているように、すべてのKPIを測定します。
The measured KPIs during the sustain phase MUST meet the test results validation criteria "a" defined in Section 7.7.3.3. The test results validation criteria "b" and "c" are OPTIONAL for Step 1.
サステインフェーズ中の測定されたKPIは、セクション7.7.3.3で定義されているテスト結果の検証基準「A」を満たす必要があります。テスト結果の検証基準「B」と「C」は、ステップ1のオプションです。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objective ("Target inspected throughput") defined in Section 7.7.3.2. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
セクション7.7.3.2で定義されているターゲット目標（「ターゲット検査スループット」）を確立するようにテスト機器を構成します。テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズの目標目標の望ましい値に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable average inspected throughput within the test results validation criteria. The final test iteration MUST be performed for the test duration defined in Section 4.3.4.
テスト結果の検証基準内で達成可能な平均検査スループットを決定します。セクション4.3.4で定義されているテスト期間については、最終的なテスト反復を実行する必要があります。
Using HTTPS traffic, determine the HTTPS transaction latency when the DUT/SUT is running with sustainable HTTPS transactions per second supported by the DUT/SUT under different HTTPS response object sizes.
HTTPSトラフィックを使用して、DUT/SUTが異なるHTTPS応答オブジェクトサイズの下でDUT/SUTによってサポートされている持続可能なHTTPSトランザクションで実行されているときにHTTPSトランザクションレイテンシを決定します。
Scenario 1: The client MUST negotiate HTTPS and close the connection immediately after the completion of a single transaction (GET and RESPONSE).
シナリオ1：クライアントは、単一のトランザクションが完了した直後にHTTPSを交渉し、接続を閉じる必要があります（取得と応答）。
Scenario 2: The client MUST negotiate HTTPS and close the connection immediately after the completion of 10 transactions (GET and RESPONSE) within a single TCP or QUIC connection.
シナリオ2：クライアントは、単一のTCPまたはQUIC接続内で10回のトランザクション（GETおよび応答）が完了した直後にHTTPSを交渉し、接続を閉じる必要があります。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.4
* セクション4.3.1.4で定義されている推奨される暗号スイートとキーサイズ
* Target objective for scenario 1: 50% of the connections per second measured in the benchmarking test TCP or QUIC connections per second with HTTPS traffic (Section 7.6)
* シナリオの目標目標1：1秒あたりの接続の50％は、ベンチマークテストTCPまたはHTTPSトラフィックで1秒あたりのQUIC接続で測定されました（セクション7.6）
* Target objective for scenario 2: 50% of the inspected throughput measured in the benchmarking test HTTPS throughput (Section 7.7)
* シナリオの目標目標2：ベンチマークテストで測定された検査されたスループットの50％httpsスループット（セクション7.7）
* Initial objective for scenario 1: 10% of "Target objective for scenario 1"
* シナリオ1：10％の「シナリオ1の目標目標」の最初の目的
* Initial objective for scenario 2: 10% of "Target objective for scenario 2"
* シナリオ2：「シナリオ2の目標目標」の10％の最初の目的
* Note: The initial objectives are not KPIs to report. These values are configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.8.4.
* 注：最初の目的は、報告するKPIではありません。これらの値は、トラフィックジェネレーターで構成され、セクション7.8.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* HTTPS transaction per TCP or QUIC connection: Test scenario 1 with a single transaction and scenario 2 with 10 transactions
* TCPまたはQUIC接続ごとのHTTPSトランザクション：テストシナリオ1単一のトランザクションと10のトランザクションでシナリオ2で1
* HTTPS with GET request requesting a single object: The RECOMMENDED object sizes are 1, 16, and 64 KB. For each test iteration, the client MUST request a single HTTPS response object size.
* GETリクエストを備えたHTTPS単一のオブジェクト：推奨されるオブジェクトサイズは1、16、および64 kbです。各テスト反復について、クライアントは単一のHTTPS応答オブジェクトサイズを要求する必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the total attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、合計試行試行の0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RST sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated QUIC connections.
b. DUT/SUTによって送信された予期しないTCP RSTによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。HTTP/3を使用すると、予期しないエラーによる終了したQUIC接続の数は、開始されたQUIC接続の0.001％（100,000の接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
d. Concurrent TCP or QUIC connections MUST be constant during steady state, and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent generated QUIC connections MUST be constant during steady state, and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate.
d. 同時TCPまたはQUIC接続は定常状態で一定でなければならず、同時TCP接続の偏差は10％未満でなければなりません。HTTP/3を使用する場合、定常状態では同時生成されたQUIC接続が一定でなければならず、同時のQUIC接続の偏差は10％未満でなければなりません。これにより、DUTがオープンし、ほぼ同じレートで接続を閉じることが確認されます。
e. After ramp up, the DUT/SUT MUST achieve the target objectives defined in the parameters in Section 7.8.3.2 and remain in that state for the entire test duration (sustain phase).
e. ランプアップ後、DUT/SUTは、セクション7.8.3.2のパラメーターで定義されているターゲット目標を達成し、テスト期間全体（Sustain Phase）全体でその状態にとどまる必要があります。
The TTFB (minimum, average, and maximum) and TTLB (minimum, average, and maximum) MUST be reported for each object size.
TTFB（最小、平均、最大）およびTTLB（最小、平均、および最大）は、各オブジェクトサイズについて報告する必要があります。
The test procedure is designed to measure the TTFB or TTLB when the DUT/SUT is operating close to 50% of its maximum achievable connections per second or inspected throughput. The test procedure consists of two major steps. Step 1 ensures the DUT/SUT is able to reach the initial performance values and meets the test results validation criteria when it is very minimally utilized. Step 2 measures the latency values within the test results validation criteria.
テスト手順は、DUT/SUTが1秒あたりの最大達成可能な接続の50％近くまたは検査されたスループットの50％近くで動作している場合に、TTFBまたはTTLBを測定するように設計されています。テスト手順は、2つの主要なステップで構成されています。ステップ1 DUT/SUTが初期パフォーマンス値に到達できるようにし、非常に最小限に及ぼす場合にテスト結果の検証基準を満たすことができます。ステップ2は、テスト結果の検証基準内の遅延値を測定します。
This test procedure MAY be repeated multiple times with different IP types (IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution), HTTPS response object sizes, and single and multiple transactions per connection scenarios.
このテスト手順は、異なるIPタイプ（IPv4のみ、IPv6のみ、IPv4およびIPv6混合トラフィック分布）、HTTPS応答オブジェクトサイズ、および接続シナリオごとの単一および複数のトランザクションで複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure the traffic load profile of the test equipment to establish the initial objectives, as defined in Section 7.8.3.2. The traffic load profile MUST be defined as described in Section 4.3.4.
セクション7.8.3.2で定義されているように、テスト機器のトラフィック負荷プロファイルを構成して、初期目標を確立します。トラフィック負荷プロファイルは、セクション4.3.4で説明されているように定義する必要があります。
The DUT/SUT MUST reach the initial objectives before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.8.3.3.
DUT/SUTは、サステインフェーズの前に初期目標に到達する必要があります。サステンフェーズ中の測定されたKPIは、セクション7.8.3.3で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objectives defined in Section 7.8.3.2. The test equipment MUST follow the traffic load profile definition described in Section 4.3.4.
テスト機器を構成して、セクション7.8.3.2で定義されているターゲット目標を確立します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義に従う必要があります。
The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed.
テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT MUST reach the desired value of the target objective in the sustain phase.
テスト結果の検証基準内で、DUT/SUTは、サステンフェーズの目標目標の望ましい値に達する必要があります。
Measure the minimum, average, and maximum values of the TTFB and TTLB.
TTFBおよびTTLBの最小値、平均値、最大値を測定します。
Determine the number of concurrent TCP or QUIC connections the DUT/ SUT sustains when using HTTPS traffic.
HTTPSトラフィックを使用するときに、DUT/ SUTが持続する同時TCPまたはQUIC接続の数を決定します。
The testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces, interface type, etc.) MUST be documented.
テストベッドセットアップは、セクション4で定義されているように構成する必要があります。特定のテストベッド構成の変更（インターフェイスの数、インターフェイスタイプなど）を文書化する必要があります。
In this section, benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented.
DUT/SUTパラメーターは、セクション4.2で定義されている要件に準拠する必要があります。この特定のベンチマークテストの構成変更を文書化する必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Client IP address ranges defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているクライアントIPアドレスの範囲
* Server IP address ranges defined in Section 4.3.2.3
* セクション4.3.2.3で定義されているサーバーIPアドレスの範囲
* Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3
* セクション4.3.1.3で定義されているIPv4とIPv6の間の交通分布率
* RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.4
* セクション4.3.1.4で定義されている推奨される暗号スイートとキーサイズ
* Target concurrent connections: Initial value from the product datasheet or the value defined based on the requirement for a specific deployment scenario
* ターゲットの同時接続：製品データシートからの初期値または特定の展開シナリオの要件に基づいて定義された値
* Initial concurrent connections: 10% of "Target concurrent connections"
* 初期の同時接続：「ターゲットコンカレント接続」の10％
* Note: Initial concurrent connections is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1 (Test Initialization and Qualification) described in Section 7.9.4.
* 注：最初の同時接続は、報告するKPIではありません。この値は、トラフィックジェネレーターで構成され、セクション7.9.4で説明されているステップ1（テスト初期化と資格）を実行するために使用されます。
* Connections per second during ramp up phase: 50% of maximum connections per second measured in the benchmarking test TCP or QUIC connections per second with HTTPS traffic (Section 7.6)
* ランプアップフェーズ中の1秒あたりの接続：ベンチマークテストTCPまたはHTTPSトラフィックでの1秒あたりのQUIC接続で測定された1秒あたりの最大接続の50％（セクション7.6）
* Ramp up time (in traffic load profile for "Target concurrent connections"): "Target concurrent connections" / "Maximum connections per second during ramp up phase"
* ランプアップ時間（「ターゲットコンキュラント接続」のトラフィックロードプロファイル）：「ターゲットコンカレント接続」 /「ランプアップフェーズ中の秒あたりの最大接続」
* Ramp up time (in traffic load profile for "Initial concurrent connections"): "Initial concurrent connections" / "Maximum connections per second during ramp up phase"
* ランプアップ時間（「初期接続接続」のトラフィックロードプロファイル）：「初期並行接続」 /「ランプアップフェーズ中の秒あたりの最大接続」
The client MUST perform HTTPS transactions with persistence, and each client can open multiple concurrent connections per server endpoint IP.
クライアントは、永続性でHTTPSトランザクションを実行する必要があり、各クライアントはサーバーエンドポイントIPごとに複数の同時接続を開くことができます。
Each client sends 10 GET requests requesting 1 KB HTTPS response objects in the same TCP or QUIC connections (10 transactions/ connections), and the delay (think time) between each transaction MUST be X seconds, where X is as follows.
各クライアントは、同じTCPまたはQUIC接続（10のトランザクション/接続）で1 kb HTTPS応答オブジェクトを要求する10のGETリクエストを送信し、各トランザクション間の遅延（検討時間）はX秒で、Xは次のとおりでなければなりません。
X = ("Ramp up time" + "steady state time") / 10
x =（ "ランプアップタイム" "定常状態時間"） / 10
The established connections MUST remain open until the ramp down phase of the test. During the ramp down phase, all connections MUST be successfully closed with FIN.
確立された接続は、テストのランプダウンフェーズまで開いたままでなければなりません。ランプダウンフェーズでは、すべての接続をFINで正常に閉じる必要があります。
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、トラフィック負荷プロファイルのサステインフェーズ全体で監視する必要があります。
a. The number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of the total attempted transactions.
a. 故障したアプリケーショントランザクションの数（200 OK以外のHTTP応答コードの受信）は、合計試行試行の0.001％（100,000トランザクションのうち1つ）未満でなければなりません。
b. The number of terminated TCP connections due to unexpected TCP RSTs sent by the DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of the total initiated QUIC connections.
b. DUT/SUTによって送信された予期しないTCP RSTSによる終了TCP接続の数は、開始されたTCP接続の合計の0.001％（100,000接続のうち1つ）未満でなければなりません。HTTP/3を使用すると、予期しないエラーによる終了したQUIC接続の数は、開始されたQUIC接続の0.001％（100,000の接続のうち1つ）未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
Average concurrent TCP or QUIC connections MUST be reported for this benchmarking test.
このベンチマークテストでは、平均同時TCPまたはQUIC接続を報告する必要があります。
The test procedure is designed to measure the concurrent TCP connection capacity of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps. Step 1 ensures the DUT/SUT is able to reach the performance value (Initial concurrent connection) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria.
テスト手順は、トラフィック負荷プロファイルの持続期間でのDUT/SUTの同時TCP接続容量を測定するように設計されています。テスト手順は、3つの主要なステップで構成されています。ステップ1 DUT/SUTがパフォーマンス値（初期同時接続）に到達できるようにし、非常に最小限の使用されたときにテスト結果の検証基準を満たすことができます。ステップ2は、DUT/SUTがテスト結果の検証基準内でターゲットパフォーマンス値に到達できるかどうかを判断します。ステップ3テスト結果の検証基準内で最大達成可能なパフォーマンス値を決定します。
This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions.
このテスト手順は、異なるIPv4およびIPv6トラフィック分布で複数回繰り返される場合があります。
Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status.
接続されたすべての物理インターフェイスのリンクステータスを確認します。すべてのインターフェイスは「UP」ステータスになると予想されます。
Configure test equipment to establish "Initial concurrent connections" defined in Section 7.9.3.2. Except ramp up time, the traffic load profile MUST be defined as described in Section 4.3.4.
テスト機器を構成して、セクション7.9.3.2で定義されている「初期同時接続」を確立します。ランプアップ時間を除いて、セクション4.3.4で説明されているように、トラフィック負荷プロファイルを定義する必要があります。
During the sustain phase, the DUT/SUT MUST reach the "Initial concurrent connections". The measured KPIs during the sustain phase MUST meet the test results validation criteria "a" and "b" defined in Section 7.9.3.3.
サステンフェーズ中、DUT/SUTは「初期の同時接続」に到達する必要があります。Sustainフェーズ中の測定されたKPIは、セクション7.9.3.3で定義されているテスト結果の検証基準「A」および「B」を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
Configure test equipment to establish the target objective ("Target concurrent connections"). The test equipment MUST follow the traffic load profile definition (except ramp up time) described in Section 4.3.4.
テスト機器を構成して、ターゲット目標（「ターゲットコンキュラント接続」）を確立します。テスト機器は、セクション4.3.4で説明したトラフィックロードプロファイルの定義（ランプアップ時間を除く）に従う必要があります。
During the ramp up and sustain phases, the other KPIs, such as inspected throughput, TCP or QUIC connections per second, and application transactions per second, MUST NOT reach the maximum value that the DUT/SUT can support.
ランプアップおよびサステインフェーズ中、検査されたスループット、TCPまたはQUIC接続、および1秒あたりのアプリケーショントランザクションなど、他のKPIは、DUT/SUTがサポートできる最大値に達してはなりません。
The test equipment MUST start to measure and record KPIs defined in Section 7.9.3.4. Continue the test until all traffic profile phases are completed.
テスト機器は、セクション7.9.3.4で定義されているKPIの測定と記録を開始する必要があります。すべてのトラフィックプロファイルフェーズが完了するまでテストを続けます。
Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow Step 3 if the measured value does not meet the target value or does not fulfill the test results validation criteria.
テスト結果の検証基準内で、DUT/SUTは、サステインフェーズの目標目標の望ましい値に達すると予想されます。測定値が目標値を満たしていない場合、またはテスト結果の検証基準を満たさない場合は、ステップ3に従ってください。
Determine the achievable concurrent TCP or QUIC connections within the test results validation criteria.
テスト結果検証基準内で、達成可能な同時TCPまたはQUIC接続を決定します。
This document makes no specific request of IANA.
このドキュメントは、IANAの具体的なリクエストを行いません。
IANA has assigned IPv4 and IPv6 address blocks in [RFC6890] that have been registered for special purposes. The IPv6 address block 2001:2::/48 has been allocated for the purpose of IPv6 benchmarking [RFC5180], and the IPv4 address block 198.18.0.0/15 has been allocated for the purpose of IPv4 benchmarking [RFC2544]. This assignment was made to minimize the chance of conflict in case a testing device were to be accidentally connected to the part of the Internet.
IANAは、特別な目的で登録されている[RFC6890]のIPv4およびIPv6アドレスブロックを割り当てました。IPv6アドレスブロック2001：2 ::/48は、IPv6ベンチマーク[RFC5180]の目的で割り当てられており、IPv4アドレスブロック198.18.0.0/15はIPv4ベンチマーク[RFC2544]の目的で割り当てられています。この割り当ては、テストデバイスがインターネットの一部に誤って接続される場合に備えて、競合の可能性を最小限に抑えるために行われました。
The primary goal of this document is to provide benchmarking terminology and methodology for next-generation network security devices for use in a laboratory-isolated test environment. However, readers should be aware that there is some overlap between performance and security issues. Specifically, the optimal configuration for network security device performance may not be the most secure, and vice versa. Testing security platforms with working exploits and malware carries risks. Ensure proper access controls are implemented to prevent unintended exposure to vulnerable networks or systems. The cipher suites recommended in this document are for test purposes only. The cipher suite recommendation for a real deployment is outside the scope of this document.
このドキュメントの主な目標は、実験室に分離されたテスト環境で使用するための次世代ネットワークセキュリティデバイスのベンチマーク用語と方法論を提供することです。ただし、読者は、パフォーマンスとセキュリティの問題の間に何らかの重複があることに注意する必要があります。具体的には、ネットワークセキュリティデバイスのパフォーマンスの最適な構成は最も安全ではなく、逆も同様です。動作するエクスプロイトとマルウェアを使用したセキュリティプラットフォームのテストには、リスクがあります。脆弱なネットワークまたはシステムへの意図しない露出を防ぐために、適切なアクセス制御が実装されていることを確認してください。このドキュメントで推奨される暗号スイートは、テスト目的のみを目的としています。実際の展開に関する暗号スイートの推奨事項は、このドキュメントの範囲外です。
Security assessment of an NGFW/NGIPS product could also include an analysis whether any type of uncommon traffic characteristics would have a significant impact on performance. Such performance impacts would allow an attacker to use such specifically crafted traffic as a DoS attack to reduce the remaining performance available to other traffic through the NGFW/NGIPS. Such uncommon traffic characteristics might include, for example, IP-fragmented traffic, a specific type of application traffic, or uncommonly high HTTP transaction rate traffic.
NGFW/NGIPS製品のセキュリティ評価には、あらゆるタイプの珍しいトラフィック特性がパフォーマンスに大きな影響を与えるかどうか分析も含めることができます。このようなパフォーマンスへの影響により、攻撃者はこのような特別に作成されたトラフィックをDOS攻撃として使用して、NGFW/NGIPを介して他のトラフィックで利用可能な残りのパフォーマンスを減らすことができます。このような珍しいトラフィックの特性には、たとえば、IPフラグメントされたトラフィック、特定のタイプのアプリケーショントラフィック、またはまれに高いHTTPトランザクションレートトラフィックが含まれる場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[CVE] CVE, "Current CVSS Score Distribution For All
Vulnerabilities", <https://www.cvedetails.com/>.
[fastly] Oku, K. and J. Iyengar, "QUIC vs TCP: Which is Better?",
April 2020, <https://www.fastly.com/blog/measuring-quic-
vs-tcp-computational-efficiency>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999,
<https://www.rfc-editor.org/info/rfc2647>.
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
"Benchmarking Methodology for Firewall Performance",
RFC 3511, DOI 10.17487/RFC3511, April 2003,
<https://www.rfc-editor.org/info/rfc3511>.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May
2008, <https://www.rfc-editor.org/info/rfc5180>.
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton,
"Applicability Statement for RFC 2544: Use on Production
Networks Considered Harmful", RFC 6815,
DOI 10.17487/RFC6815, November 2012,
<https://www.rfc-editor.org/info/rfc6815>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[Undertow] undertow, "An in depth overview of HTTP/2",
<https://undertow.io/blog/2015/04/27/An-in-depth-overview-
of-HTTP2.html>.
[Wiki-NGFW]
Wikipedia, "Next-generation firewall", January 2023,
<https://en.wikipedia.org/w/index.php?title=Next-
generation_firewall&oldid=1133673904>.
This test methodology verifies the DUT/SUT is able to detect, prevent, and report the vulnerabilities.
このテスト方法は、DUT/SUTが脆弱性を検出、防止、報告することができることを検証します。
In this test, background test traffic will be generated to utilize the DUT/SUT. In parallel, some malicious traffic will be sent to the DUT/SUT as encrypted and cleartext payload formats using a traffic generator. Section 4.2.1 defines the selection of the malicious traffic from the Common Vulnerabilities and Exposures (CVEs) list for testing.
このテストでは、DUT/SUTを利用するためにバックグラウンドテストトラフィックが生成されます。並行して、いくつかの悪意のあるトラフィックは、トラフィックジェネレーターを使用して暗号化されたクリアテキストペイロードフォーマットとしてDUT/SUTに送信されます。セクション4.2.1は、テスト用の共通の脆弱性と露出（CVE）リストからの悪意のあるトラフィックの選択を定義します。
The following KPIs are measured in this test:
このテストでは、次のKPIが測定されています。
* Number of blocked CVEs
* ブロックされたCVEの数
* Number of bypassed (non-blocked) CVEs
* バイパス（ブロックされていない）CVEの数
* Background traffic performance (verify if the background traffic is impacted while sending CVEs toward the DUT/SUT)
* バックグラウンドトラフィックのパフォーマンス（DUT/SUTに向かってCVEを送信しながらバックグラウンドトラフィックが影響を受けるかどうかを確認）
* Accuracy of DUT/SUT statistics in terms of vulnerabilities reporting
* 脆弱性レポートの観点からのDUT/SUT統計の精度
The same testbed MUST be used for security effectiveness tests and for benchmarking test cases defined in Section 7.
同じテストベッドは、セキュリティの有効性テストとセクション7で定義されているテストケースのベンチマークに使用する必要があります。
In this section, the benchmarking-test-specific parameters are defined.
このセクションでは、ベンチマークテスト固有のパラメーターを定義します。
DUT/SUT configuration parameters MUST conform to the requirements defined in Section 4.2. The same DUT configuration MUST be used for the security effectiveness test and for benchmarking test cases defined in Section 7. The DUT/SUT MUST be configured in "Inline" mode, all detected attack traffic MUST be dropped, and the session MUST be reset
DUT/SUT構成パラメーターは、セクション4.2で定義されている要件に準拠する必要があります。セキュリティ有効性テストとセクション7で定義されたベンチマークテストケースには、同じDUT構成を使用する必要があります。DUT/SUTは「インライン」モードで構成する必要があり、検出されたすべての攻撃トラフィックをドロップする必要があり、セッションをリセットする必要があります。
Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The same client and server IP ranges MUST be configured as used in the benchmarking test cases. In addition, the following parameters MUST be documented for this benchmarking test:
テスト機器構成パラメーターは、セクション4.3で定義されている要件に準拠する必要があります。同じクライアントとサーバーのIP範囲を、ベンチマークテストケースで使用して構成する必要があります。さらに、このベンチマークテストについては、次のパラメーターを文書化する必要があります。
* Background Traffic: 45% of maximum HTTP throughput and 45% of maximum HTTPS throughput supported by the DUT/SUT (measured with object size 64 KB in the benchmarking tests HTTP(S) Throughput defined in Sections 7.3 and 7.7)
* バックグラウンドトラフィック：DUT/SUTでサポートされている最大HTTPスループットの45％と最大HTTPSスループットの45％（セクション7.3および7.7で定義されているベンチマークテストHTTP（S）スループットでオブジェクトサイズ64 kbで測定）
* RECOMMENDED CVE traffic transmission Rate: 10 CVEs per second
* 推奨されるCVEトラフィック送信率：1秒あたり10個
* It is RECOMMENDED to generate each CVE multiple times (sequentially) at 10 CVEs per second.
* 各CVEを1秒あたり10 CVEで複数回（連続的に）生成することをお勧めします。
* Ciphers and keys for the encrypted CVE traffic MUST use the same cipher configured for HTTPS-traffic-related benchmarking tests (Sections 7.6-7.9)
* 暗号化されたCVEトラフィックの暗号とキーは、https-トラフィック関連のベンチマークテスト用に構成された同じ暗号を使用する必要があります（セクション7.6-7.9）
The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole test duration.
次の基準は、テスト結果の検証基準です。テスト結果の検証基準は、テスト期間全体で監視する必要があります。
a. The number of failed application transactions in the background traffic MUST be less than 0.01% of the attempted transactions.
a. バックグラウンドトラフィックの故障したアプリケーショントランザクションの数は、試行されたトランザクションの0.01％未満でなければなりません。
b. The number of terminated TCP or QUIC connections of the background traffic (due to unexpected errors) MUST be less than 0.01% of the total initiated TCP connections in the background traffic.
b. バックグラウンドトラフィックの終了したTCPまたはQUIC接続の数（予期しないエラーによる）は、バックグラウンドトラフィックの合計開始されたTCP接続の0.01％未満でなければなりません。
c. During the sustain phase, traffic MUST be forwarded at a constant rate (it is considered as a constant rate if any deviation of the traffic forwarding rate is less than 5%).
c. サステインフェーズ中、トラフィックは一定の速度で転送する必要があります（トラフィック転送率の偏差が5％未満の場合、一定の速度と見なされます）。
d. A false positive MUST NOT occur in the background traffic.
d. バックグラウンドトラフィックで偽陽性が発生しないでください。
The following KPI metrics MUST be reported for this test scenario:
このテストシナリオについては、次のKPIメトリックを報告する必要があります。
Mandatory KPIs:
必須のKPI：
* Blocked CVEs: They MUST be represented in the following ways:
* ブロックされたCVE：それらは次の方法で表現する必要があります。
- Number of blocked CVEs out of total CVEs
- 総CVEからのブロックされたCVEの数
- Percentage of blocked CVEs
- ブロックされたCVEの割合
* Unblocked CVEs: They MUST be represented in the following ways:
* ブロックされていないCVE：次の方法で表現する必要があります。
- Number of unblocked CVEs out of total CVEs
- 総CVEからのブロックされていないCVEの数
- Percentage of unblocked CVEs
- ブロックされていないCVEの割合
* Background traffic behavior: It MUST be represented in one of the followings ways:
* バックグラウンドトラフィックの動作：次の方法で表現する必要があります。
- No impact: Considered as "no impact" if any deviation of the traffic forwarding rate is less than or equal to 5% (constant rate)
- 影響なし：トラフィック転送率の偏差が5％以下（一定の速度）がある場合、「影響なし」と見なされる
- Minor impact: Considered as "minor impact" if any deviation of the traffic forwarding rate is greater than 5% and less than or equal to 10% (i.e., small spikes)
- マイナーな影響：トラフィック転送率の偏差が5％を超え、10％以下（すなわち、スパイク）以下の場合、「マイナーな衝撃」と見なされる
- Heavy impact: Considered as "heavy impact" if any deviation of the traffic forwarding rate is greater than 10% (i.e., large spikes) or reduced the background HTTP(S) throughput greater than 10%
- 重い衝撃：トラフィック転送率の偏差が10％を超える（つまり、大きなスパイク）またはバックグラウンドHTTPのスループットを10％を超えた場合、「重い衝撃」と見なされる
* DUT/SUT reporting accuracy: The DUT/SUT MUST report all detected vulnerabilities.
* DUT/SUTレポートの正確性：DUT/SUTは、検出されたすべての脆弱性を報告する必要があります。
Optional KPIs:
オプションのKPI：
* List of unblocked CVEs
* ブロックされていないCVEのリスト
The test procedure is designed to measure the security effectiveness of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of two major steps. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions.
テスト手順は、トラフィック負荷プロファイルの持続期間におけるDUT/SUTのセキュリティの有効性を測定するように設計されています。テスト手順は、2つの主要なステップで構成されています。このテスト手順は、異なるIPv4およびIPv6トラフィック分布で複数回繰り返される場合があります。
Generate background traffic at the transmission rate defined in Appendix A.3.2.
付録A.3.2で定義されている伝送速度でバックグラウンドトラフィックを生成します。
The DUT/SUT MUST reach the target objective (HTTP(S) throughput) in the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Appendix A.4.
DUT/SUTは、サステンフェーズでターゲット目標（HTTP（s）スループット）に到達する必要があります。サステインフェーズ中の測定されたKPIは、付録A.4で定義されているすべてのテスト結果検証基準を満たす必要があります。
If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to Step 2.
KPIメトリックがテスト結果の検証基準を満たしていない場合、テスト手順をステップ2まで継続してはなりません。
While generating background traffic (in the sustain phase), send the CVE traffic, as defined in the parameter section (Appendix A.3.2).
バックグラウンドトラフィックを生成している間（サステンフェーズで）、パラメーターセクション（付録A.3.2）で定義されているように、CVEトラフィックを送信します。
The test equipment MUST start to measure and record all specified KPIs. Continue the test until all CVEs are sent.
テスト機器は、指定されたすべてのKPIの測定と記録を開始する必要があります。すべてのCVEが送信されるまでテストを続けます。
The measured KPIs MUST meet all the test results validation criteria defined in Appendix A.4.
測定されたKPIは、付録A.4で定義されているすべてのテスト結果検証基準を満たす必要があります。
In addition, the DUT/SUT should report the detected vulnerabilities in the log correctly, or there MUST be reference material available that will allow for verification that the correct vulnerability was detected if, for example, a different naming convention is used. This reference material MUST be cited in the report.
さらに、DUT/SUTは、ログ内の検出された脆弱性を正しく報告する必要があります。または、例えば別の命名規則が使用されている場合、正しい脆弱性が検出されたことを検証できるようにする参照資料が必要です。この参照資料は、レポートで引用する必要があります。
This document aims to classify the DUT/SUT into four different categories based on its maximum-supported firewall throughput performance number defined in the vendor datasheet. This classification MAY help users to determine specific configuration scales (e.g., number of ACL entries), traffic profiles, and attack traffic profiles, scaling those proportionally to the DUT/SUT sizing category.
このドキュメントは、ベンダーデータシートで定義されている最大サポートファイアウォールスループットパフォーマンス番号に基づいて、DUT/SUTを4つの異なるカテゴリに分類することを目的としています。この分類は、ユーザーが特定の構成スケール（ACLエントリの数など）、トラフィックプロファイル、および攻撃トラフィックプロファイルを決定し、DUT/SUTサイズのカテゴリに比例してスケーリングするのに役立ちます。
The four different categories are Extra Small (XS), Small (S), Medium (M), and Large (L). The RECOMMENDED throughput values for the following categories are:
4つの異なるカテゴリは、余分な小（XS）、小（s）、中（m）、および大きい（L）です。次のカテゴリの推奨スループット値は次のとおりです。
Extra Small (XS) -
余分な小（xs） -
Supported throughput less than or equal to 1 Gbit/s
サポートされているスループットは1 gbit/s以下
Small (S) -
小さい -
Supported throughput greater than 1 Gbit/s and less than or equal to 5Gbit/s
1 gbit/sを超えるサポートされているスループットと5gbit/s以下
Medium (M) -
中（m） -
Supported throughput greater than 5 Gbit/s and less than or equal to 10Gbit/s
5 gbit/sを超えるサポートされているスループットは、10gbit/s以下
Large (L) -
大部分（l） -
Supported throughput greater than 10 Gbit/s
10 gbit/sを超えるサポートスループット
The authors wish to acknowledge the members of NetSecOPEN for their participation in the creation of this document. Additionally, the following members need to be acknowledged:
著者は、この文書の作成への参加について、NetseCopenのメンバーに認めたいと考えています。さらに、次のメンバーを承認する必要があります。
Anand Vijayan, Chris Marshall, Jay Lindenauer, Michael Shannon, Mike Deichman, Ryan Riese, and Toulnay Orkun.
Anand Vijayan、Chris Marshall、Jay Lindenauer、Michael Shannon、Mike Deichman、Ryan Riese、Toulnay Orkun。
The following individuals contributed significantly to the creation of this document:
次の個人は、このドキュメントの作成に大きく貢献しました。
Alex Samonte, Amritam Putatunda, Aria Eslambolchizadeh, Chao Guo, Chris Brown, Cory Ford, David DeSanto, Jurrie Van Den Breekel, Michelle Rhines, Mike Jack, Ryan Liles, Samaresh Nair, Stephen Goudreault, Tim Carlin, and Tim Otto.
アレックス・サモンテ、アムリタム・パタトンダ、アリア・エスラムボルチザデ、チャオ・グオ、クリス・ブラウン、コリー・フォード、デビッド・デサント、ジュリー・ヴァン・デン・ブリーク、ミシェル・ラインズ、マイク・ジャック、ライアン・ライルズ、サマレシュ・ネア、スティーブン・グードリーチ、ティム・カーリン、ティム・オットー。
Balamuhunthan Balarajah
Berlin
Germany
Email: bm.balarajah@gmail.com
Carsten Rossenhoevel
EANTC AG
Salzufer 14
10587 Berlin
Germany
Email: cross@eantc.de
Brian Monkman
NetSecOPEN
417 Independence Court
Mechanicsburg, PA 17050
United States of America
Email: bmonkman@netsecopen.org