[要約] RFC 8456は、SDNコントローラのパフォーマンスを評価するためのベンチマーク手法についての要約です。このRFCの目的は、SDNコントローラのパフォーマンス評価を標準化し、比較可能な結果を提供することです。
Internet Engineering Task Force (IETF) V. Bhuvaneswaran
Request for Comments: 8456 A. Basil
Category: Informational Veryx Technologies
ISSN: 2070-1721 M. Tassinari
Hewlett Packard Enterprise
V. Manral
NanoSec
S. Banks
VSS Monitoring
October 2018
Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance
ソフトウェア定義ネットワーク（SDN）コントローラーのパフォーマンスのベンチマーク手法
Abstract
概要
This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.
このドキュメントでは、ソフトウェア定義ネットワーク（SDN）コントローラーのコントロールプレーンのパフォーマンスをベンチマークする方法を定義します。 SDNコントローラーは、ネットワークの動作を制御するSDNアーキテクチャのコアコンポーネントです。 SDNコントローラーは、目的のネットワーク機能を実現するために、さまざまな設計で実装されています。したがって、このドキュメントの作成者は、SDNコントローラーをブラックボックスと見なし、コントローラーがサポートするプロトコルとネットワークサービスにとらわれない方法で方法を定義するアプローチを採用しています。このドキュメントは、すべてのコントローラー実装のパフォーマンスを測定する方法を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8456.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8456で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
2. Scope ...........................................................4
3. Test Setup ......................................................4
3.1. Test Setup - Controller Operating in Standalone Mode .......5
3.2. Test Setup - Controller Operating in Cluster Mode ..........6
4. Test Considerations .............................................7
4.1. Network Topology ...........................................7
4.2. Test Traffic ...............................................7
4.3. Test Emulator Requirements .................................7
4.4. Connection Setup ...........................................8
4.5. Measurement Point Specification and Recommendation .........9
4.6. Connectivity Recommendation ................................9
4.7. Test Repeatability .........................................9
4.8. Test Reporting .............................................9
5. Benchmarking Tests .............................................11
5.1. Performance ...............................................11
5.1.1. Network Topology Discovery Time ....................11
5.1.2. Asynchronous Message Processing Time ...............13
5.1.3. Asynchronous Message Processing Rate ...............14
5.1.4. Reactive Path Provisioning Time ....................17
5.1.5. Proactive Path Provisioning Time ...................19
5.1.6. Reactive Path Provisioning Rate ....................21
5.1.7. Proactive Path Provisioning Rate ...................23
5.1.8. Network Topology Change Detection Time .............25
5.2. Scalability ...............................................26
5.2.1. Control Sessions Capacity ..........................26
5.2.2. Network Discovery Size .............................27
5.2.3. Forwarding Table Capacity ..........................29
5.3. Security ..................................................31
5.3.1. Exception Handling .................................31
5.3.2. Handling Denial-of-Service Attacks .................32
5.4. Reliability ...............................................34
5.4.1. Controller Failover Time ...........................34
5.4.2. Network Re-provisioning Time .......................36
6. IANA Considerations ............................................37
7. Security Considerations ........................................38
8. References .....................................................38
8.1. Normative References ......................................38
8.2. Informative References ....................................38
Appendix A. Benchmarking Methodology Using OpenFlow Controllers ...39
A.1. Protocol Overview ..........................................39
A.2. Messages Overview ..........................................39
A.3. Connection Overview ........................................39
A.4. Performance Benchmarking Tests .............................40
A.4.1. Network Topology Discovery Time ........................40
A.4.2. Asynchronous Message Processing Time ...................42
A.4.3. Asynchronous Message Processing Rate ...................43
A.4.4. Reactive Path Provisioning Time ........................44
A.4.5. Proactive Path Provisioning Time .......................46
A.4.6. Reactive Path Provisioning Rate ........................47
A.4.7. Proactive Path Provisioning Rate .......................49
A.4.8. Network Topology Change Detection Time .................50
A.5. Scalability ................................................51
A.5.1. Control Sessions Capacity ..............................51
A.5.2. Network Discovery Size .................................52
A.5.3. Forwarding Table Capacity ..............................54
A.6. Security ...................................................55
A.6.1. Exception Handling .....................................55
A.6.2. Handling Denial-of-Service Attacks .....................57
A.7. Reliability ................................................59
A.7.1. Controller Failover Time ...............................59
A.7.2. Network Re-provisioning Time ...........................61
Acknowledgments ...................................................63
Authors' Addresses ................................................64
This document provides generic methodologies for benchmarking Software-Defined Networking (SDN) Controller performance. To achieve the desired functionality, an SDN Controller may support many northbound and southbound protocols, implement a wide range of applications, and work either alone or as part of a group. This document considers an SDN Controller to be a black box, regardless of design and implementation. The tests defined in this document can be used to benchmark an SDN Controller for performance, scalability, reliability, and security, independently of northbound and southbound protocols. Terminology related to benchmarking SDN Controllers is described in the companion terminology document [RFC8455]. These tests can be performed on an SDN Controller running as a virtual machine (VM) instance or on a bare metal server. This document is intended for those who want to measure an SDN Controller's performance as well as compare the performance of various SDN Controllers.
このドキュメントでは、ソフトウェア定義ネットワーク（SDN）コントローラーのパフォーマンスをベンチマークするための一般的な方法論を提供します。目的の機能を実現するために、SDNコントローラーは多くのノースバウンドおよびサウスバウンドプロトコルをサポートし、幅広いアプリケーションを実装し、単独でまたはグループの一部として機能します。このドキュメントでは、設計や実装に関係なく、SDNコントローラーをブラックボックスと見なしています。このドキュメントで定義されているテストは、ノースバウンドプロトコルとサウスバウンドプロトコルに関係なく、SDNコントローラーのパフォーマンス、スケーラビリティ、信頼性、およびセキュリティのベンチマークに使用できます。 SDNコントローラーのベンチマークに関連する用語は、関連する用語のドキュメント[RFC8455]で説明されています。これらのテストは、仮想マシン（VM）インスタンスとして実行されているSDNコントローラーまたはベアメタルサーバーで実行できます。このドキュメントは、SDNコントローラーのパフォーマンスを測定し、さまざまなSDNコントローラーのパフォーマンスを比較したいユーザーを対象としています。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document defines a methodology for measuring the networking metrics of SDN Controllers. For the purpose of this memo, the SDN Controller is a function that manages and controls Network Devices. Any SDN Controller without a control capability is out of scope for this memo. The tests defined in this document enable the benchmarking of SDN Controllers in two ways: standalone mode (a standalone controller) and cluster mode (a cluster of homogeneous controllers). These tests are recommended for execution in lab environments rather than in live network deployments. Performance benchmarking of a federation of controllers (i.e., a set of SDN Controllers) managing different domains, is beyond the scope of this document.
このドキュメントでは、SDNコントローラーのネットワークメトリックを測定する方法を定義します。このメモでは、SDNコントローラーはネットワークデバイスを管理および制御する機能です。制御機能のないSDNコントローラーは、このメモの範囲外です。このドキュメントで定義されているテストは、スタンドアロンモード（スタンドアロンコントローラー）とクラスターモード（同種コントローラーのクラスター）の2つの方法でSDNコントローラーのベンチマークを有効にします。これらのテストは、ライブネットワーク展開ではなく、ラボ環境での実行をお勧めします。異なるドメインを管理するコントローラーの連合（つまり、一連のSDNコントローラー）のパフォーマンスベンチマークは、このドキュメントの範囲外です。
As noted above, the tests defined in this document enable the measurement of an SDN Controller's performance in standalone mode and cluster mode. This section defines common reference topologies that are referred to in individual tests described later in this document.
上記のように、このドキュメントで定義されているテストは、スタンドアロンモードおよびクラスターモードでのSDNコントローラーのパフォーマンスの測定を可能にします。このセクションでは、このドキュメントで後述する個々のテストで参照される一般的な参照トポロジを定義します。
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+-------------------------------+
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| |
| Device Under Test (DUT) |
+-------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-------------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n - 1| |
| +-----------+ +-------------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+
Figure 1
図1
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+---------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | SDN Controller 1 | <--E/W--> | SDN Controller n | |
| +------------------+ +------------------+ |
| |
| Device Under Test (DUT) |
+---------------------------------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-------------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n - 1| |
| +-----------+ +-------------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+
Figure 2
図2
The test cases SHOULD use Leaf-Spine topology with at least two Network Devices in the topology for benchmarking. Test traffic generators TP1 and TP2 SHOULD be connected to the leaf Network Device 1 and the leaf Network Device n. To achieve a complete performance characterization of the SDN Controller, it is recommended that the controller be benchmarked for many network topologies and a varying number of Network Devices. Further, care should be taken to make sure that a loop-prevention mechanism is enabled in either the SDN Controller or the network when the topology contains redundant network paths.
テストケースは、ベンチマーク用にトポロジ内に少なくとも2つのネットワークデバイスを備えたリーフスパイントポロジを使用する必要があります（SHOULD）。テストトラフィックジェネレータTP1およびTP2は、リーフネットワークデバイス1およびリーフネットワークデバイスnに接続する必要があります（SHOULD）。 SDNコントローラーの完全なパフォーマンス特性を実現するには、コントローラーを多くのネットワークトポロジーおよびさまざまな数のネットワークデバイスに対してベンチマークすることをお勧めします。さらに、トポロジに冗長ネットワークパスが含まれている場合は、SDNコントローラーまたはネットワークのいずれかでループ防止メカニズムが有効になっていることを確認してください。
Test traffic is used to notify the controller about the asynchronous arrival of new flows. The test cases SHOULD use frame sizes of 128, 512, and 1508 bytes for benchmarking. Tests using jumbo frames are optional.
テストトラフィックは、新しいフローの非同期到着についてコントローラに通知するために使用されます。テストケースは、ベンチマークに128、512、1508バイトのフレームサイズを使用する必要があります（SHOULD）。ジャンボフレームを使用したテストはオプションです。
The test emulator SHOULD timestamp the transmitted and received control messages to/from the controller on the established network connections. The test cases use these values to compute the controller processing time.
テストエミュレータは、確立されたネットワーク接続でコントローラとの間で送受信される制御メッセージにタイムスタンプを付ける必要があります（SHOULD）。テストケースは、これらの値を使用してコントローラーの処理時間を計算します。
There may be controller implementations that support unencrypted and encrypted network connections with Network Devices. Further, the controller may be backward compatible with Network Devices running older versions of southbound protocols. It may be useful to measure the controller's performance with one or more applicable connection setup methods defined below. For cases with encrypted communications between the controller and the switch, key management and key exchange MUST take place before any performance or benchmark measurements.
ネットワークデバイスとの暗号化されていないおよび暗号化されたネットワーク接続をサポートするコントローラーの実装がある場合があります。さらに、コントローラは、古いバージョンのサウスバウンドプロトコルを実行しているネットワークデバイスと下位互換性がある場合があります。以下に定義されている1つ以上の適用可能な接続設定方法でコントローラーのパフォーマンスを測定すると役立つ場合があります。コントローラとスイッチの間の通信が暗号化されている場合、パフォーマンスまたはベンチマーク測定の前に、キー管理とキー交換を行う必要があります。
1. Unencrypted connection with Network Devices, running the same protocol version.
1. 同じプロトコルバージョンを実行しているネットワークデバイスとの暗号化されていない接続。
2. Unencrypted connection with Network Devices, running different protocol versions.
2. 異なるプロトコルバージョンを実行しているネットワークデバイスとの暗号化されていない接続。
Examples:
例：
a. Controller running current protocol version and switch running older protocol version.
a. 現在のプロトコルバージョンを実行しているコントローラーと、古いプロトコルバージョンを実行しているスイッチ。
b. Controller running older protocol version and switch running current protocol version.
b. 古いプロトコルバージョンを実行しているコントローラーと現在のプロトコルバージョンを実行しているスイッチ。
3. Encrypted connection with Network Devices, running the same protocol version.
3. 同じプロトコルバージョンを実行しているネットワークデバイスとの暗号化された接続。
4. Encrypted connection with Network Devices, running different protocol versions.
4. 異なるプロトコルバージョンを実行しているネットワークデバイスとの暗号化された接続。
Examples:
例：
a. Controller running current protocol version and switch running older protocol version.
a. 現在のプロトコルバージョンを実行しているコントローラーと、古いプロトコルバージョンを実行しているスイッチ。
b. Controller running older protocol version and switch running current protocol version.
b. 古いプロトコルバージョンを実行しているコントローラーと現在のプロトコルバージョンを実行しているスイッチ。
The accuracy of the measurements depends on several factors, including the point of observation where the indications are captured. For example, the notification can be observed at the controller or test emulator. The test operator SHOULD make the observations/measurements at the interfaces of the test emulator, unless explicitly specified otherwise in the individual test. In any case, the locations of measurement points MUST be reported.
測定の精度は、兆候がキャプチャされる観測ポイントを含むいくつかの要因に依存します。たとえば、通知はコントローラーまたはテストエミュレーターで監視できます。個々のテストで明示的に指定されていない限り、テストオペレーターは、テストエミュレーターのインターフェイスで観測/測定を行う必要があります（SHOULD）。いずれの場合も、測定ポイントの位置を報告する必要があります。
The SDN Controller in the test setup SHOULD be connected directly with the forwarding-plane and management-plane test emulators to avoid any delays or failure introduced by the intermediate devices during benchmarking tests. When the controller is implemented as a virtual machine, details of the physical and logical connectivity MUST be reported.
テストセットアップのSDNコントローラーは、フォワーディングプレーンおよび管理プレーンのテストエミュレーターに直接接続して、ベンチマークテスト中に中間デバイスによって生じる遅延や障害を回避する必要があります（SHOULD）。コントローラが仮想マシンとして実装されている場合、物理的および論理的接続の詳細を報告する必要があります。
To increase confidence in the measured results, it is recommended that each test SHOULD be repeated a minimum of 10 times.
測定結果の信頼性を高めるために、各テストは最低10回繰り返す必要があります。
Each test has a reporting format that contains some global and identical reporting components, and some individual components that are specific to individual tests. The following parameters for test configuration and controller settings MUST be reflected in the test report.
各テストには、グローバルで同一のレポートコンポーネントと、個々のテストに固有のいくつかの個別コンポーネントを含むレポート形式があります。テスト構成とコントローラー設定の次のパラメーターは、テストレポートに反映する必要があります。
Test Configuration Parameters:
テスト構成パラメーター：
1. Controller name and version
1. コントローラー名とバージョン
2. Northbound protocols and versions
2. ノースバウンドプロトコルとバージョン
3. Southbound protocols and versions
3. サウスバウンドプロトコルとバージョン
4. Controller redundancy mode (standalone or cluster mode)
4. コントローラー冗長モード（スタンドアロンまたはクラスターモード）
5. Connection setup (unencrypted or encrypted)
5. 接続設定（暗号化されていないか暗号化されている）
6. Network Device type (physical, virtual, or emulated)
6. ネットワークデバイスの種類（物理、仮想、またはエミュレート）
7. Number of nodes 8. Number of links
7.ノードの数8.リンクの数
9. Data-plane test traffic type
9. データプレーンテストのトラフィックタイプ
10. Controller system configuration (e.g., physical or virtual machine, CPU, memory, caches, operating system, interface speed, storage)
10. コントローラーシステム構成（物理または仮想マシン、CPU、メモリ、キャッシュ、オペレーティングシステム、インターフェイス速度、ストレージなど）
11. Reference test setup (e.g., the setup shown in Section 3.1)
11. 参照テストのセットアップ（たとえば、セクション3.1に示すセットアップ）
Parameters for Controller Settings:
コントローラー設定のパラメーター：
1. Topology rediscovery timeout
1. トポロジ再検出タイムアウト
2. Controller redundancy mode (e.g., active-standby)
2. コントローラ冗長モード（例：アクティブ-スタンバイ）
3. Controller state persistence enabled/disabled
3. コントローラー状態の永続化が有効/無効
To ensure the repeatability of the test, the following capabilities of the test emulator SHOULD be reported:
テストの再現性を保証するために、テストエミュレータの以下の機能を報告する必要があります。
1. Maximum number of Network Devices that the forwarding plane emulates
1. 転送プレーンがエミュレートするネットワークデバイスの最大数
2. Control message processing time (e.g., topology discovery messages)
2. メッセージ処理時間の制御（例：トポロジー検出メッセージ）
One way to determine the above two values is to simulate the required control sessions and messages from the control plane.
上記の2つの値を決定する1つの方法は、必要なコントロールセッションとコントロールプレーンからのメッセージをシミュレートすることです。
Objective:
目的：
Measure the time taken by the controller(s) to determine the complete network topology, defined as the interval starting with the first discovery message from the controller(s) at its southbound interface and ending with all features of the static topology determined.
コントローラがネットワークトポロジ全体を決定するのにかかる時間を測定します。これは、サウスバウンドインターフェイスでのコントローラからの最初のディスカバリメッセージから始まり、決定された静的トポロジのすべての機能で終了する間隔として定義されます。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST support network discovery.
1. コントローラはネットワーク検出をサポートする必要があります。
2. The tester should be able to retrieve the discovered topology information through either the controller's management interface or northbound interface to determine if the discovery was successful and complete.
2. テスターは、コントローラーの管理インターフェイスまたはノースバウンドインターフェイスのいずれかを介して、検出されたトポロジ情報を取得して、検出が成功して完了したかどうかを判断できる必要があります。
3. Ensure that the controller's topology rediscovery timeout has been set to the maximum value, to avoid initiation of the rediscovery process in the middle of the test.
3. テストの途中で再検出プロセスが開始されないように、コントローラのトポロジの再検出タイムアウトが最大値に設定されていることを確認してください。
Procedure:
手順：
1. Ensure that the controller is operational and that its network applications, northbound interface, and southbound interface are up and running.
1. コントローラが動作していること、およびそのネットワークアプリケーション、ノースバウンドインターフェイス、サウスバウンドインターフェイスが稼働していることを確認してください。
2. Establish the network connections between the controller and the Network Devices.
2. コントローラとネットワークデバイス間のネットワーク接続を確立します。
3. Record the time for the first discovery message (Tm1) received from the controller at the forwarding-plane test emulator interface (I1).
3. フォワーディングプレーンテストエミュレータインターフェイス（I1）でコントローラから受信した最初のディスカバリメッセージ（Tm1）の時間を記録します。
4. Query the controller every t seconds (the RECOMMENDED value for t is 3) to obtain the discovered network topology information through the northbound interface or the management interface, and compare it with the deployed network topology information.
4. コントローラーをt秒ごとに照会し（tの推奨値は3）、ノースバウンドインターフェイスまたは管理インターフェイスを介して検出されたネットワークトポロジ情報を取得し、展開されたネットワークトポロジ情報と比較します。
5. Stop the trial when the discovered topology information matches the deployed network topology or when the discovered topology information returns the same details for three consecutive queries.
5. 検出されたトポロジ情報が展開されたネットワークトポロジと一致する場合、または検出されたトポロジ情報が3つの連続したクエリに対して同じ詳細を返す場合、試行を停止します。
6. Record the time for the last discovery message (Tmn) sent to the controller from the forwarding-plane test emulator interface (I1) when the trial completes successfully (e.g., when the topology matches).
6. トライアルが正常に完了したとき（トポロジーが一致したときなど）に、転送プレーンテストエミュレーターインターフェイス（I1）からコントローラーに送信された最後の検出メッセージ（Tmn）の時間を記録します。
Measurements:
測定：
Topology Discovery Time (DT1) = Tmn - Tm1
トポロジ検出時間（DT1）= Tmn-Tm1
DT1 + DT2 + DT3 .. DTn
Average Topology Discovery Time (TDm) = -----------------------
Total Trials
SUM[SQUAREOF(DTi - TDm)]
Topology Discovery Time Variance (TDv) = ------------------------
Total Trials - 1
Reporting Format:
レポート形式：
The Topology Discovery Time results MUST be reported in tabular format, with a row for each successful iteration. The last row of the table indicates the Topology Discovery Time variance, and the previous row indicates the Average Topology Discovery Time.
トポロジーのディスカバリー時間の結果は、成功した反復ごとに1行ずつ、表形式で報告する必要があります。表の最後の行はトポロジー発見時間の差異を示し、前の行は平均トポロジー発見時間を示します。
If this test is repeated with a varying number of nodes over the same topology, the results SHOULD be reported in the form of a graph. The X coordinate SHOULD be the number of nodes (N), and the Y coordinate SHOULD be the Average Topology Discovery Time.
同じトポロジー上でさまざまな数のノードを使用してこのテストを繰り返す場合、結果はグラフの形で報告する必要があります（SHOULD）。 X座標はノード数（N）である必要があり（SHOULD）、Y座標は平均トポロジ検出時間である必要があります（SHOULD）。
Objective:
目的：
Measure the time taken by the controller(s) to process an asynchronous message, defined as the interval starting with an asynchronous message from a Network Device after the discovery of all the devices by the controller(s) and ending with a response message from the controller(s) at its southbound interface.
コントローラが非同期メッセージを処理するのにかかる時間を測定します。これは、コントローラがすべてのデバイスを検出した後、ネットワークデバイスからの非同期メッセージで始まり、からの応答メッセージで終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラ。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisite:
前提条件：
The controller MUST have successfully completed the network topology discovery for the connected Network Devices.
コントローラは、接続されたネットワークデバイスのネットワークトポロジー検出を正常に完了している必要があります。
Procedure:
手順：
1. Generate asynchronous messages from every connected Network Device to the SDN Controller, one at a time in series from the forwarding-plane test emulator for the Trial Duration.
1. トライアル期間の転送プレーンテストエミュレータから、接続されているすべてのネットワークデバイスからSDNコントローラーに非同期メッセージを1つずつ直列に生成します。
2. Record every request transmit time (T1) and the corresponding response received time (R1) at the forwarding-plane test emulator interface (I1) for every successful message exchange.
2. すべての要求メッセージ送信時間（T1）および対応する応答受信時間（R1）を、メッセージ交換が成功するたびに転送プレーンテストエミュレーターインターフェイス（I1）に記録します。
Measurements:
測定：
Asynchronous Message Processing Time (APT1) =
SUM{Ri} - SUM{Ti}
-----------------------
Nrx
Where Nrx is the total number of successful messages exchanged.
ここで、Nrxは、正常に交換されたメッセージの総数です。
Average Asynchronous Message Processing Time =
APT1 + APT2 + APT3 .. APTn
--------------------------
Total Trials
Asynchronous Message Processing Time Variance (TAMv) =
SUM[SQUAREOF(APTi - TAMm)]
--------------------------
Total Trials - 1
Where TAMm is the Average Asynchronous Message Processing Time.
ここで、TAMmは非同期メッセージの平均処理時間です。
Reporting Format:
レポート形式：
The Asynchronous Message Processing Time results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Asynchronous Message Processing Time variance, and the previous row indicates the Average Asynchronous Message Processing Time.
非同期メッセージ処理時間の結果は、反復ごとに1行ずつ、表形式で報告する必要があります。表の最後の行は非同期メッセージ処理時間の差異を示し、前の行は平均非同期メッセージ処理時間を示します。
The report SHOULD capture the following information, in addition to the configuration parameters captured per Section 4.8:
レポートは、セクション4.8に従ってキャプチャされた構成パラメータに加えて、次の情報をキャプチャする必要があります（SHOULD）。
- Successful messages exchanged (Nrx)
- 成功したメッセージ交換（Nrx）
- Percentage of unsuccessful messages exchanged, computed using the formula ((1 - Nrx/Ntx) * 100), where Ntx is the total number of messages transmitted to the controller
- 交換された失敗したメッセージの割合。式（（1-Nrx / Ntx）* 100）を使用して計算されます。ここで、Ntxはコントローラーに送信されたメッセージの総数です。
If this test is repeated with a varying number of nodes with the same topology, the results SHOULD be reported in the form of a graph. The X coordinate SHOULD be the number of nodes (N), and the Y coordinate SHOULD be the Average Asynchronous Message Processing Time.
同じトポロジのさまざまな数のノードでこのテストを繰り返す場合、結果はグラフの形で報告する必要があります（SHOULD）。 X座標はノード数（N）である必要があり（SHOULD）、Y座標は平均非同期メッセージ処理時間である必要があります（SHOULD）。
Objective:
目的：
Measure the number of responses to asynchronous messages (a new flow arrival notification message, link down, etc.) for which the controller(s) performed processing and replied with a valid and productive (non-trivial) response message.
コントローラーが処理を実行し、有効で生産的な（重要ではない）応答メッセージで応答した非同期メッセージ（新しいフローの到着通知メッセージ、リンクダウンなど）に対する応答の数を測定します。
Using a single procedure, this test will measure the following two benchmarks on the Asynchronous Message Processing Rate (see Section 2.3.1.3 of [RFC8455]):
このテストでは、単一の手順を使用して、非同期メッセージ処理率に関する次の2つのベンチマークを測定します（[RFC8455]のセクション2.3.1.3を参照）。
1. Maximum Asynchronous Message Processing Rate
1. 最大非同期メッセージ処理率
2. Loss-Free Asynchronous Message Processing Rate
2. ロスのない非同期メッセージ処理率
Here, two benchmarks are determined through a series of trials where the number of messages sent to the controller(s) and the responses received from the controller(s) are counted over the Trial Duration. The message response rate and the Message Loss Ratio are calculated for each trial.
ここで、2つのベンチマークは、コントローラーに送信されたメッセージの数とコントローラーから受信された応答が試用期間にわたってカウントされる一連の試用を通じて決定されます。メッセージ応答率とメッセージ損失率は、試行ごとに計算されます。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller(s) MUST have successfully completed the network topology discovery for the connected Network Devices.
1. コントローラは、接続されたネットワークデバイスのネットワークトポロジー検出を正常に完了している必要があります。
2. Choose and record the Trial Duration (Td), the sending rate STEP size, the tolerance on equality for two consecutive trials (P%), and the maximum possible message-sending rate (Ntx1/Td).
2. トライアル期間（Td）、送信レートのSTEPサイズ、2つの連続するトライアルの等値許容差（P％）、および可能な最大メッセージ送信レート（Ntx1 / Td）を選択して記録します。
Procedure:
手順：
1. Generate asynchronous messages continuously at the maximum possible rate on the established connections from all the emulated/simulated Network Devices for the given Trial Duration (Td).
1. 指定された試用期間（Td）の間、すべてのエミュレート/シミュレーションされたネットワークデバイスから確立された接続で、可能な最大レートで非同期メッセージを継続的に生成します。
2. Record the total number of responses received (Nrx1) from the controller as well as the number of messages sent (Ntx1) to the controller within the Trial Duration (Td).
2. トライアル期間（Td）内にコントローラーから受信した応答の総数（Nrx1）とコントローラーに送信されたメッセージの数（Ntx1）を記録します。
3. Calculate the Asynchronous Message Processing Rate (APR1) and the Message Loss Ratio (Lr1). Ensure that the controller(s) has returned to normal operation.
3. 非同期メッセージ処理率（APR1）とメッセージ損失率（Lr1）を計算します。コントローラが通常の動作に戻ったことを確認します。
4. Repeat the trial by reducing the asynchronous message-sending rate used in the last trial by the STEP size.
4. 最後の試行で使用された非同期メッセージ送信レートをSTEPサイズだけ減らして、試行を繰り返します。
5. Continue repeating the trials and reducing the sending rate until both the maximum value of Nrxn (number of responses received from the controller) and the Nrxn corresponding to a Loss Ratio of zero have been found.
5. Nrxn（コントローラーから受信した応答の数）の最大値とゼロの損失率に対応するNrxnの両方が見つかるまで、試行を繰り返し、送信速度を下げ続けます。
6. The trials corresponding to the benchmark levels MUST be repeated using the same asynchronous message rates until the responses received from the controller are equal (+/-P%) for two consecutive trials.
6. ベンチマークレベルに対応する試行は、コントローラーから受信した応答が2回の連続試行で等しくなる（+/- P％）まで、同じ非同期メッセージレートを使用して繰り返す必要があります。
7. Record the number of responses received (Nrxn) from the controller as well as the number of messages sent (Ntxn) to the controller in the last trial.
7. 最後の試行でコントローラーから受信した応答の数（Nrxn）とコントローラーに送信したメッセージの数（Ntxn）を記録します。
Measurements:
測定：
Nrxn
Asynchronous Message Processing Rate (APRn) = -----
Td
Maximum Asynchronous Message Processing Rate = MAX(APRn) for all n
すべてのnの最大非同期メッセージ処理率= MAX（APRn）
Nrxn
Asynchronous Message Loss Ratio (Lrn) = 1 - -----
Ntxn
Loss-Free Asynchronous Message Processing Rate = MAX(APRn) given Lrn = 0
Lrn = 0の場合の無損失非同期メッセージ処理率= MAX（APRn）
Reporting Format:
レポート形式：
The Asynchronous Message Processing Rate results MUST be reported in tabular format, with a row for each trial.
非同期メッセージ処理率の結果は、各試行ごとに1行ずつ、表形式で報告する必要があります。
The table should report the following information, in addition to the configuration parameters captured per Section 4.8, with columns:
この表は、セクション4.8に従って取得された構成パラメーターに加えて、次の情報を列とともに報告する必要があります。
- Offered rate (Ntxn/Td)
- 提示レート（Ntxn / Td）
- Asynchronous Message Processing Rate (APRn)
- 非同期メッセージ処理率（APRn）
- Loss Ratio (Lr)
- 損失率（Lr）
- Benchmark at this iteration (blank for none, Maximum Asynchronous Message Processing Rate, Loss-Free Asynchronous Message Processing Rate)
- この反復でのベンチマーク（なしの場合は空白、非同期メッセージの最大処理速度、ロスのない非同期メッセージ処理速度）
The results MAY be presented in the form of a graph. The X axis SHOULD be the offered rate, and dual Y axes would represent the Asynchronous Message Processing Rate and the Loss Ratio, respectively.
結果はグラフの形で提示される場合があります。 X軸は提供レートである必要があり（SHOULD）、2つのY軸はそれぞれ非同期メッセージ処理レートと損失率を表します。
If this test is repeated with a varying number of nodes over the same topology, the results SHOULD be reported in the form of a graph. The X axis SHOULD be the number of nodes (N), and the Y axis SHOULD be the Asynchronous Message Processing Rate. Both the Maximum Asynchronous Message Processing Rate and the Loss-Free Asynchronous Message Processing Rate should be plotted for each N.
同じトポロジー上でさまざまな数のノードを使用してこのテストを繰り返す場合、結果はグラフの形で報告する必要があります（SHOULD）。 X軸はノード数（N）である必要があり（SHOULD）、Y軸は非同期メッセージ処理率である必要があります（SHOULD）。最大の非同期メッセージ処理率とロスのない非同期メッセージ処理率の両方を、Nごとにプロットする必要があります。
Objective:
目的：
Measure the time taken by the controller to set up a path reactively between source and destination nodes, defined as the interval starting with the first flow provisioning request message received by the controller(s) at its southbound interface and ending with the last flow provisioning response message sent from the controller(s) at its southbound interface.
コントローラがソースノードと宛先ノードの間にパスをセットアップするのにかかる時間を測定します。これは、サウスバウンドインターフェイスでコントローラが受信した最初のフロープロビジョニング要求メッセージで始まり、最後のフロープロビジョニング応答で終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラから送信されたメッセージ。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document. The number of Network Devices in the path is a parameter of the test that may be varied from two to the maximum discovery size in repetitions of this test.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。パス内のネットワークデバイスの数は、テストのパラメーターであり、このテストの繰り返しで2から最大検出サイズまで変化する可能性があります。
Prerequisites:
前提条件：
1. The controller MUST contain the network topology information for the deployed network topology.
1. コントローラには、展開されたネットワークトポロジのネットワークトポロジ情報が含まれている必要があります。
2. The controller should know the location of the destination endpoint for which the path has to be provisioned. This can be achieved through dynamic learning or static provisioning.
2. コントローラは、パスをプロビジョニングする必要がある宛先エンドポイントの場所を知っている必要があります。これは、動的学習または静的プロビジョニングによって実現できます。
3. Ensure that the default action for "flow miss" in the Network Device is configured to "send to controller".
3. ネットワークデバイスの「フローミス」のデフォルトアクションが「コントローラに送信」するように設定されていることを確認します。
4. Ensure that each Network Device in a path requires the controller to make the forwarding decision while paving the entire path.
4. パス内の各ネットワークデバイスには、パス全体を舗装しながらコントローラーが転送の決定を行う必要があることを確認してください。
Procedure:
手順：
1. Send a single traffic stream from test traffic generator TP1 to test traffic generator TP2.
1. テストトラフィックジェネレータTP1からテストトラフィックジェネレータTP2に単一のトラフィックストリームを送信します。
2. Record the time of the first flow provisioning request message sent to the controller (Tsf1) from the Network Device at the forwarding-plane test emulator interface (I1).
2. フォワーディングプレーンテストエミュレーターインターフェイス（I1）で、ネットワークデバイスからコントローラー（Tsf1）に送信された最初のフロープロビジョニング要求メッセージの時間を記録します。
3. Wait for the arrival of the first traffic frame at the endpoint (i.e., test traffic generator TP2) or the expiry of the Trial Duration (Td).
3. エンドポイントでの最初のトラフィックフレームの到着（つまり、テストトラフィックジェネレータTP2）またはトライアル期間（Td）の期限切れを待ちます。
4. Record the time of the last flow provisioning response message received from the controller (Tdf1) to the Network Device at the forwarding-plane test emulator interface (I1).
4. コントローラー（Tdf1）から転送プレーンテストエミュレーターインターフェイス（I1）でネットワークデバイスに受信した最後のフロープロビジョニング応答メッセージの時間を記録します。
Measurements:
測定：
Reactive Path Provisioning Time (RPT1) = Tdf1 - Tsf1
リアクティブパスプロビジョニング時間（RPT1）= Tdf1-Tsf1
Average Reactive Path Provisioning Time =
RPT1 + RPT2 + RPT3 .. RPTn
--------------------------
Total Trials
Reactive Path Provisioning Time Variance (TRPv) =
SUM[SQUAREOF(RPTi - TRPm)]
--------------------------
Total Trials - 1
Where TRPm is the Average Reactive Path Provisioning Time.
ここで、TRPmは平均リアクティブパスプロビジョニング時間です。
Reporting Format:
レポート形式：
The Reactive Path Provisioning Time results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Reactive Path Provisioning Time variance, and the previous row indicates the Average Reactive Path Provisioning Time.
リアクティブパスプロビジョニング時間の結果は、各反復ごとに1行ずつ、表形式で報告する必要があります。表の最後の行は反応経路のプロビジョニング時間の差異を示し、前の行は平均反応経路のプロビジョニング時間を示します。
The report should capture the following information, in addition to the configuration parameters captured per Section 4.8:
レポートには、セクション4.8に従って取得された構成パラメーターに加えて、次の情報が取得されます。
- Number of Network Devices in the path
- パス内のネットワークデバイスの数
Objective:
目的：
Measure the time taken by the controller to set up a path proactively between source and destination nodes, defined as the interval starting with the first proactive flow provisioned in the controller(s) at its northbound interface and ending with the last flow provisioning response message sent from the controller(s) at its southbound interface.
コントローラーが送信元ノードと宛先ノード間にプロアクティブにパスをセットアップするのにかかる時間を測定します。これは、ノースバウンドインターフェイスでコントローラーにプロビジョニングされた最初のプロアクティブフローで始まり、送信された最後のフロープロビジョニング応答メッセージで終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラから。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST contain the network topology information for the deployed network topology.
1. コントローラには、展開されたネットワークトポロジのネットワークトポロジ情報が含まれている必要があります。
2. The controller should know the location of the destination endpoint for which the path has to be provisioned. This can be achieved through dynamic learning or static provisioning.
2. コントローラは、パスをプロビジョニングする必要がある宛先エンドポイントの場所を知っている必要があります。これは、動的学習または静的プロビジョニングによって実現できます。
3. Ensure that the default action for "flow miss" in the Network Device is "drop".
3. ネットワークデバイスの「フローミス」のデフォルトアクションが「ドロップ」であることを確認します。
Procedure:
手順：
1. Send a single traffic stream from test traffic generator TP1 to test traffic generator TP2.
1. テストトラフィックジェネレータTP1からテストトラフィックジェネレータTP2に単一のトラフィックストリームを送信します。
2. Install the flow entries so that the traffic travels from test traffic generator TP1 until it reaches test traffic generator TP2 through the controller's northbound interface or management interface.
2. トラフィックがテストトラフィックジェネレータTP1からコントローラのノースバウンドインターフェイスまたは管理インターフェイスを介してテストトラフィックジェネレータTP2に到達するまで流れるように、フローエントリをインストールします。
3. Wait for the arrival of the first traffic frame at test traffic generator TP2 or the expiry of the Trial Duration (Td).
3. テストトラフィックジェネレータTP2に最初のトラフィックフレームが到着するか、トライアル期間（Td）の期限が切れるのを待ちます。
4. Record the time when the proactive flow is provisioned in the controller (Tsf1) at the management-plane test emulator interface (I2).
4. 管理面のテストエミュレーターインターフェイス（I2）でコントローラー（Tsf1）にプロアクティブフローがプロビジョニングされた時間を記録します。
5. Record the time of the last flow provisioning message received from the controller (Tdf1) at the forwarding-plane test emulator interface (I1).
5. フォワーディングプレーンテストエミュレーターインターフェイス（I1）でコントローラー（Tdf1）から受信した最後のフロープロビジョニングメッセージの時刻を記録します。
Measurements:
測定：
Proactive Flow Provisioning Time (PPT1) = Tdf1 - Tsf1
プロアクティブフロープロビジョニング時間（PPT1）= Tdf1-Tsf1
Average Proactive Path Provisioning Time =
PPT1 + PPT2 + PPT3 .. PPTn
--------------------------
Total Trials
Proactive Path Provisioning Time Variance (TPPv) =
SUM[SQUAREOF(PPTi - TPPm)]
--------------------------
Total Trials - 1
Where TPPm is the Average Proactive Path Provisioning Time.
TPPmは、プロアクティブパスの平均プロビジョニング時間です。
Reporting Format:
レポート形式：
The Proactive Path Provisioning Time results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Proactive Path Provisioning Time variance, and the previous row indicates the Average Proactive Path Provisioning Time.
プロアクティブパスプロビジョニング時間の結果は、表形式で報告する必要があり、反復ごとに1行が含まれます。表の最後の行はプロアクティブパスプロビジョニング時間の差異を示し、前の行は平均プロアクティブパスプロビジョニング時間を示します。
The report should capture the following information, in addition to the configuration parameters captured per Section 4.8:
レポートには、セクション4.8に従って取得された構成パラメーターに加えて、次の情報が取得されます。
- Number of Network Devices in the path
- パス内のネットワークデバイスの数
Objective:
目的：
Measure the maximum number of independent paths a controller can concurrently establish per second between source and destination nodes reactively, defined as the number of paths provisioned per second by the controller(s) at its southbound interface for the flow provisioning requests received for path provisioning at its southbound interface between the start of the test and the expiry of the given Trial Duration.
コントローラーがソースノードと宛先ノードの間で1秒間に同時に確立できる独立パスの最大数を測定します。これは、サウスバウンドインターフェイスのコントローラーによって1秒あたりにプロビジョニングされたパスの数として定義されます。テストの開始と指定されたトライアル期間の有効期限の間のサウスバウンドインターフェイス。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST contain the network topology information for the deployed network topology.
1. コントローラには、展開されたネットワークトポロジのネットワークトポロジ情報が含まれている必要があります。
2. The controller should know the location of destination addresses for which the paths have to be provisioned. This can be achieved through dynamic learning or static provisioning.
2. コントローラは、パスをプロビジョニングする必要がある宛先アドレスの場所を知っている必要があります。これは、動的学習または静的プロビジョニングによって実現できます。
3. Ensure that the default action for "flow miss" in the Network Device is configured to "send to controller".
3. ネットワークデバイスの「フローミス」のデフォルトアクションが「コントローラに送信」するように設定されていることを確認します。
4. Ensure that each Network Device in a path requires the controller to make the forwarding decision while provisioning the entire path.
4. パス内の各ネットワークデバイスには、パス全体をプロビジョニングしながら、コントローラーが転送の決定を行う必要があることを確認してください。
Procedure:
手順：
1. Send traffic with unique source and destination addresses from test traffic generator TP1.
1. テストトラフィックジェネレータTP1から送信元アドレスと宛先アドレスが一意のトラフィックを送信します。
2. Record the total number of unique traffic frames (Ndf) received at test traffic generator TP2 within the Trial Duration (Td).
2. トライアル期間（Td）内にテストトラフィックジェネレーターTP2で受信した一意のトラフィックフレーム（Ndf）の総数を記録します。
Measurements:
測定：
Ndf
Reactive Path Provisioning Rate (RPR1) = ------
Td
Average Reactive Path Provisioning Rate =
RPR1 + RPR2 + RPR3 .. RPRn
--------------------------
Total Trials
Reactive Path Provisioning Rate Variance (RPPv) =
SUM[SQUAREOF(RPRi - RPPm)]
--------------------------
Total Trials - 1
Where RPPm is the Average Reactive Path Provisioning Rate.
ここで、RPPmは平均リアクティブパスプロビジョニングレートです。
Reporting Format:
レポート形式：
The Reactive Path Provisioning Rate results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Reactive Path Provisioning Rate variance, and the previous row indicates the Average Reactive Path Provisioning Rate.
リアクティブパスプロビジョニングレートの結果は、表形式で報告する必要があり、反復ごとに1行が必要です。表の最後の行は、リアクティブパスプロビジョニングレートの差異を示し、前の行は、平均リアクティブパスプロビジョニングレートを示します。
The report should capture the following information, in addition to the configuration parameters captured per Section 4.8:
レポートには、セクション4.8に従って取得された構成パラメーターに加えて、次の情報が取得されます。
- Number of Network Devices in the path
- パス内のネットワークデバイスの数
- Offered rate
- 提供レート
Objective:
目的：
Measure the maximum number of independent paths a controller can concurrently establish per second between source and destination nodes proactively, defined as the number of paths provisioned per second by the controller(s) at its southbound interface for the paths requested in its northbound interface between the start of the test and the expiry of the given Trial Duration. The measurement is based on data-plane observations of successful path activation.
コントローラーが送信元ノードと宛先ノードの間で1秒間に同時に確立できる独立したパスの最大数を測定します。これは、サウスバウンドインターフェイスでコントローラーによって1秒あたりにプロビジョニングされる、ノースバウンドインターフェイス間のリクエストされたパスのパス数として定義されます。テストの開始と指定されたトライアル期間の期限切れ。この測定は、パスのアクティブ化が成功したことをデータプレーンで観測した結果に基づいています。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST contain the network topology information for the deployed network topology.
1. コントローラには、展開されたネットワークトポロジのネットワークトポロジ情報が含まれている必要があります。
2. The controller should know the location of destination addresses for which the paths have to be provisioned. This can be achieved through dynamic learning or static provisioning.
2. コントローラは、パスをプロビジョニングする必要がある宛先アドレスの場所を知っている必要があります。これは、動的学習または静的プロビジョニングによって実現できます。
3. Ensure that the default action for "flow miss" in the Network Device is "drop".
3. ネットワークデバイスの「フローミス」のデフォルトアクションが「ドロップ」であることを確認します。
Procedure:
手順：
1. Send traffic continuously with unique source and destination addresses from test traffic generator TP1.
1. テストトラフィックジェネレーターTP1からの一意の送信元アドレスと宛先アドレスを使用して継続的にトラフィックを送信します。
2. Install corresponding flow entries so that the traffic travels from simulated sources at test traffic generator TP1 until it reaches the simulated destinations at test traffic generator TP2 through the controller's northbound interface or management interface.
2. 対応するフローエントリをインストールして、トラフィックがテストトラフィックジェネレータTP1のシミュレートされたソースから、コントローラのノースバウンドインターフェイスまたは管理インターフェイスを介してテストトラフィックジェネレータTP2のシミュレートされた宛先に到達するまで移動します。
3. Record the total number of unique traffic frames (Ndf) received at test traffic generator TP2 within the Trial Duration (Td).
3. トライアル期間（Td）内にテストトラフィックジェネレーターTP2で受信した一意のトラフィックフレーム（Ndf）の総数を記録します。
Measurements:
測定：
Ndf
Proactive Path Provisioning Rate (PPR1) = ------
Td
Average Proactive Path Provisioning Rate =
PPR1 + PPR2 + PPR3 .. PPRn
--------------------------
Total Trials
Proactive Path Provisioning Rate Variance (PPPv) =
SUM[SQUAREOF(PPRi - PPPm)]
-------------------------
Total Trials - 1
Where PPPm is the Average Proactive Path Provisioning Rate.
ここで、PPPmはプロアクティブパスの平均プロビジョニングレートです。
Reporting Format:
レポート形式：
The Proactive Path Provisioning Rate results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Proactive Path Provisioning Rate variance, and the previous row indicates the Average Proactive Path Provisioning Rate.
プロアクティブパスプロビジョニングレートの結果は、表形式で報告する必要があり、反復ごとに1行が必要です。表の最後の行はプロアクティブパスプロビジョニングレートの差異を示し、前の行は平均プロアクティブパスプロビジョニングレートを示します。
The report should capture the following information, in addition to the configuration parameters captured per Section 4.8:
レポートには、セクション4.8に従って取得された構成パラメーターに加えて、次の情報が取得されます。
- Number of Network Devices in the path
- パス内のネットワークデバイスの数
- Offered rate
- 提供レート
Objective:
目的：
Measure the amount of time taken by the controller to detect any changes in the network topology, defined as the interval starting with the notification message received by the controller(s) at its southbound interface and ending with the first topology rediscovery message sent from the controller(s) at its southbound interface.
コントローラがネットワークトポロジの変更を検出するのにかかる時間を測定します。これは、サウスバウンドインターフェイスでコントローラによって受信された通知メッセージで始まり、コントローラから送信された最初のトポロジ再検出メッセージで終わる間隔として定義されます。 （s）サウスバウンドインターフェイス。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST have successfully discovered the network topology information for the deployed network topology.
1. コントローラは、展開されたネットワークトポロジのネットワークトポロジ情報を正常に検出している必要があります。
2. The periodic network discovery operation should be configured to twice the Trial Duration (Td) value.
2. 定期的なネットワーク検出操作は、試用期間（Td）値の2倍に構成する必要があります。
Procedure:
手順：
1. Trigger a topology change event by bringing down an active Network Device in the topology.
1. トポロジ内のアクティブなネットワークデバイスを停止して、トポロジ変更イベントをトリガーします。
2. Record the time when the first topology change notification is sent to the controller (Tcn) at the forwarding-plane test emulator interface (I1).
2. 最初のトポロジー変更通知が転送プレーンテストエミュレーターインターフェイス（I1）でコントローラー（Tcn）に送信された時刻を記録します。
3. Stop the trial when the controller sends the first topology rediscovery message to the Network Device or the expiry of the Trial Duration (Td).
3. コントローラがネットワークデバイスに最初のトポロジ再検出メッセージを送信するか、試用期間（Td）の有効期限が切れたら、試用を停止します。
4. Record the time when the first topology rediscovery message is received from the controller (Tcd) at the forwarding-plane test emulator interface (I1).
4. フォワーディングプレーンテストエミュレーターインターフェイス（I1）でコントローラー（Tcd）から最初のトポロジ再検出メッセージを受信した時刻を記録します。
Measurements:
測定：
Network Topology Change Detection Time (TDT1) = Tcd - Tcn
ネットワークトポロジ変更検出時間（TDT1）= Tcd-Tcn
Average Network Topology Change Detection Time =
TDT1 + TDT2 + TDT3 .. TDTn
--------------------------
Total Trials
Network Topology Change Detection Time Variance (NTDv) =
SUM[SQUAREOF(TDTi - NTDm)]
--------------------------
Total Trials - 1
Where NTDm is the Average Network Topology Change Detection Time.
NTDmは、平均ネットワークトポロジ変更検出時間です。
Reporting Format:
レポート形式：
The Network Topology Change Detection Time results MUST be reported in tabular format, with a row for each iteration. The last row of the table indicates the Network Topology Change Detection Time variance, and the previous row indicates the Average Network Topology Change Detection Time.
ネットワークトポロジ変更検出時間の結果は、表形式で報告する必要があり、反復ごとに1行が必要です。表の最後の行はネットワークトポロジ変更検出時間の差異を示し、前の行は平均ネットワークトポロジ変更検出時間を示します。
Objective:
目的：
Measure the maximum number of control sessions the controller can maintain, defined as the number of sessions that the controller can accept from Network Devices, starting with the first control session and ending with the last control session that the controller(s) accepts at its southbound interface.
コントローラーが維持できる制御セッションの最大数を測定します。これは、コントローラーがネットワークデバイスから受け入れることができるセッションの数として定義され、最初の制御セッションから始まり、コントローラーがサウスバウンドで受け入れる最後の制御セッションで終わります。インターフェース。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
None
なし
Procedure:
手順：
1. Establish control connections with the controller from every Network Device emulated in the forwarding-plane test emulator.
1. フォワーディングプレーンテストエミュレータでエミュレートされたすべてのネットワークデバイスから、コントローラとの制御接続を確立します。
2. Stop the trial when the controller starts dropping the control connections.
2. コントローラーが制御接続のドロップを開始したら、試行を停止します。
3. Record the number of successful connections established (CCn) with the controller at the forwarding-plane test emulator.
3. フォワーディングプレーンテストエミュレータのコントローラで確立された成功した接続（CCn）の数を記録します。
Measurement:
測定：
Control Sessions Capacity = CCn
制御セッション容量= CCn
Reporting Format:
レポート形式：
The Control Sessions Capacity results MUST be reported in addition to the configuration parameters captured per Section 4.8.
セクション4.8に従ってキャプチャされた構成パラメータに加えて、制御セッション容量の結果を報告する必要があります。
Objective:
目的：
Measure the network size (number of nodes, links, and hosts) that a controller can discover, defined as the size of a network that the controller(s) can discover, starting with a network topology provided by the user for discovery and ending with the number of nodes, links, and hosts that the controller(s) were able to successfully discover.
コントローラーが検出できるネットワークサイズ（ノード、リンク、ホストの数）を測定します。コントローラーが検出できるネットワークのサイズとして定義され、ユーザーが検出のために提供するネットワークトポロジから始まり、コントローラが正常に検出できたノード、リンク、およびホストの数。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller MUST support automatic network discovery.
1. コントローラは自動ネットワーク検出をサポートする必要があります。
2. The tester should be able to retrieve the discovered topology information through either the controller's management interface or northbound interface.
2. テスターは、コントローラーの管理インターフェースまたはノースバウンドインターフェースを介して、検出されたトポロジー情報を取得できる必要があります。
Procedure:
手順：
1. Establish the network connections between the controller and the network nodes.
1. コントローラとネットワークノード間のネットワーク接続を確立します。
2. Query the controller every t seconds (the RECOMMENDED value for t is 30) to obtain the discovered network topology information through the northbound interface or the management interface.
2. ノースバウンドインターフェイスまたは管理インターフェイスを介して検出されたネットワークトポロジ情報を取得するには、t秒ごとにコントローラにクエリを実行します（tの推奨値は30）。
3. Stop the trial when the discovered network topology information remains the same as that of the last two query responses.
3. 検出されたネットワークトポロジ情報が最後の2つのクエリ応答と同じままになったら、試用を停止します。
4. Compare the obtained network topology information with the deployed network topology information.
4. 取得したネットワークトポロジ情報と展開したネットワークトポロジ情報を比較します。
5. If the comparison is successful, increase the number of nodes by 1 and repeat the trial. If the comparison is unsuccessful, decrease the number of nodes by 1 and repeat the trial.
5. 比較が成功した場合は、ノードの数を1つ増やし、試行を繰り返します。比較が失敗した場合は、ノードの数を1つ減らし、試行を繰り返します。
6. Continue the trial until the comparison (step 5) is successful.
6. 比較（ステップ5）が成功するまでトライアルを続けます。
7. Record the number of nodes for the last trial run (Ns) where the topology comparison was successful.
7. トポロジー比較が成功した最後の試行実行（Ns）のノード数を記録します。
Measurement:
測定：
Network Discovery Size = Ns
ネットワーク探索サイズ= Ns
Reporting Format:
レポート形式：
The Network Discovery Size results MUST be reported in addition to the configuration parameters captured per Section 4.8.
セクション4.8に従ってキャプチャされた構成パラメータに加えて、ネットワーク検出サイズの結果を報告する必要があります。
Objective:
目的：
Measure the maximum number of flow entries a controller can manage in its Forwarding Table.
コントローラが転送テーブルで管理できるフローエントリの最大数を測定します。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. The controller's Forwarding Table should be empty.
1. コントローラの転送テーブルは空である必要があります。
2. "Flow idle time" MUST be set to a higher or infinite value.
2. 「フローアイドル時間」は、より高いまたは無限の値に設定する必要があります。
3. The controller MUST have successfully completed network topology discovery.
3. コントローラは、ネットワークトポロジの検出を正常に完了している必要があります。
4. The tester should be able to retrieve the Forwarding Table information through either the controller's management interface or northbound interface.
4. テスターは、コントローラの管理インターフェイスまたはノースバウンドインターフェイスのいずれかを介して転送テーブル情報を取得できる必要があります。
Procedures:
手順：
o Reactive Flow Provisioning Mode:
o リアクティブフロープロビジョニングモード：
1. Send bidirectional traffic continuously with unique source and destination addresses from test traffic generators TP1 and TP2 at the Asynchronous Message Processing Rate of the controller.
1. コントローラの非同期メッセージ処理レートで、テストトラフィックジェネレータTP1およびTP2からの一意の送信元および宛先アドレスを使用して、双方向トラフィックを継続的に送信します。
2. Query the controller at a regular interval (e.g., every 5 seconds) for the number of learned flow entries from its northbound interface.
2. ノースバウンドインターフェイスから学習したフローエントリの数について、定期的に（たとえば、5秒ごとに）コントローラにクエリを送信します。
3. Stop the trial when the retrieved value is constant for three consecutive iterations, and record the value received from the last query (Nrp).
3. 取得した値が3回連続して一定になったときに試行を停止し、最後のクエリ（Nrp）から受け取った値を記録します。
o Proactive Flow Provisioning Mode:
o プロアクティブフロープロビジョニングモード：
1. Install unique flows continuously through the controller's northbound interface or management interface until a failure response is received from the controller.
1. コントローラーから障害応答を受信するまで、コントローラーのノースバウンドインターフェイスまたは管理インターフェイスを介して継続的に固有のフローをインストールします。
2. Record the total number of successful responses (Nrp).
2. 成功した応答（Nrp）の総数を記録します。
Note:
注意：
Some controller designs for Proactive Flow Provisioning mode may require the switch to send flow setup requests in order to generate flow setup responses. In such cases, it is recommended to generate bidirectional traffic for the provisioned flows.
プロアクティブフロープロビジョニングモードの一部のコントローラー設計では、フローセットアップ応答を生成するために、スイッチがフローセットアップリクエストを送信する必要があります。このような場合は、プロビジョニングされたフローの双方向トラフィックを生成することをお勧めします。
Measurements:
測定：
Proactive Flow Provisioning Mode:
プロアクティブフロープロビジョニングモード：
Max Flow Entries = Total number of flows provisioned (Nrp)
最大フローエントリ=プロビジョニングされたフローの総数（Nrp）
Reactive Flow Provisioning Mode:
リアクティブフロープロビジョニングモード：
Max Flow Entries = Total number of learned flow entries (Nrp)
最大フローエントリ=学習されたフローエントリの総数（Nrp）
Forwarding Table Capacity = Max Flow Entries
転送テーブルの容量=最大フローエントリ
Reporting Format:
レポート形式：
The Forwarding Table Capacity results MUST be tabulated with the following information, in addition to the configuration parameters captured per Section 4.8:
転送テーブル容量の結果は、セクション4.8でキャプチャされた構成パラメータに加えて、次の情報で表にする必要があります。
- Provisioning Type (Proactive/Reactive)
- プロビジョニングタイプ（プロアクティブ/リアクティブ）
Objective:
目的：
Determine the effects of handling error packets and notifications on performance tests. The impact MUST be measured for the following performance tests:
パフォーマンステストでのエラーパケットと通知の処理の影響を判断します。次のパフォーマンステストでは、影響を測定する必要があります。
1. Path Provisioning Rate
1. Path Provisioning Rate
2. Path Provisioning Time
2. パスプロビジョニング時間
3. Network Topology Change Detection Time
3. ネットワークトポロジ変更検出時間
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
Prerequisites:
前提条件：
1. This test MUST be performed after obtaining the baseline measurement results for the performance tests listed above.
1. このテストは、上記のパフォーマンステストのベースライン測定結果を取得した後に実行する必要があります。
2. Ensure that the invalid messages are not dropped by the intermediate devices connecting the controller and Network Devices.
2. 無効なメッセージが、コントローラーとネットワークデバイスを接続する中間デバイスによってドロップされないことを確認してください。
Procedure:
手順：
1. Perform the above-listed performance tests, and send 1% of the messages from the Asynchronous Message Processing Rate test (Section 5.1.3) as invalid messages from the connected Network Devices emulated at the forwarding-plane test emulator.
1. 上記のパフォーマンステストを実行し、非同期メッセージ処理レートテスト（セクション5.1.3）からのメッセージの1％を、転送プレーンテストエミュレータでエミュレートされた接続されたネットワークデバイスからの無効なメッセージとして送信します。
2. Perform the above-listed performance tests, and send 2% of the messages from the Asynchronous Message Processing Rate test (Section 5.1.3) as invalid messages from the connected Network Devices emulated at the forwarding-plane test emulator.
2. 上記のパフォーマンステストを実行し、非同期メッセージ処理レートテスト（セクション5.1.3）からのメッセージの2％を、転送プレーンテストエミュレータでエミュレートされた接続されたネットワークデバイスからの無効なメッセージとして送信します。
Note:
注意：
Invalid messages can be frames with incorrect protocol fields or any form of failure notifications sent towards the controller.
無効なメッセージは、不正なプロトコルフィールドを含むフレーム、またはコントローラに送信される任意の形式の障害通知です。
Measurements:
測定：
Measurements MUST be done as per the equation defined in the "Measurements" section of the corresponding test listed under "Objective".
測定は、「目的」の下にリストされている対応するテストの「測定」セクションで定義された方程式に従って行われなければなりません。
Reporting Format:
レポート形式：
The Exception Handling results MUST be reported in tabular format, with a column for each of the below parameters and row for each of the above-listed performance tests:
例外処理の結果は表形式で報告する必要があります。以下の各パラメーターの列と上記の各パフォーマンステストの行を使用してください。
- Without Exceptions
- 例外なし
- With 1% Exceptions
- 1％の例外あり
- With 2% Exceptions
- With 2% Exceptions
Objective:
目的：
Determine the effects of handling DoS attacks on performance and scalability tests. The impact MUST be measured for the following tests:
DoS攻撃の処理がパフォーマンステストとスケーラビリティテストに与える影響を特定します。次のテストで影響を測定する必要があります。
1. Path Provisioning Rate
1. パスプロビジョニングレート
2. Path Provisioning Time
2. パスプロビジョニング時間
3. Network Topology Change Detection Time
3. ネットワークトポロジ変更検出時間
4. Network Discovery Size
4. ネットワーク探索サイズ
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisite:
Prerequisite:
This test MUST be performed after obtaining the baseline measurement results for the performance tests listed above.
このテストは、上記のパフォーマンステストのベースライン測定結果を取得した後に実行する必要があります。
Procedure:
手順：
Perform the above-listed tests, and launch a DoS attack towards the controller while the trial is running.
上記のテストを実行し、トライアルの実行中にコントローラーにDoS攻撃を仕掛けます。
Note: DoS attacks can be launched on one of the following interfaces:
Note: DoS attacks can be launched on one of the following interfaces:
1. Northbound (e.g., query for flow entries continuously on the northbound interface)
1. ノースバウンド（たとえば、ノースバウンドインターフェイスでフローエントリを継続的に照会する）
2. Management (e.g., Ping requests to the controller's management interface)
2. 管理（例：コントローラの管理インターフェイスへのPing要求）
3. Southbound (e.g., TCP SYN messages on the southbound interface)
3. サウスバウンド（サウスバウンドインターフェイスのTCP SYNメッセージなど）
Measurements:
測定：
Measurements MUST be done as per the equation defined in the "Measurements" section of the corresponding test listed under "Objective".
測定は、「目的」の下にリストされている対応するテストの「測定」セクションで定義された方程式に従って行われなければなりません。
Reporting Format:
Reporting Format:
The results regarding the handling of DoS attacks MUST be reported in tabular format, with a column for each of the below parameters and a row for each of the above-listed tests.
The results regarding the handling of DoS attacks MUST be reported in tabular format, with a column for each of the below parameters and a row for each of the above-listed tests.
- Without any attacks
- 攻撃なし
- With attacks
- 攻撃あり
The report should also specify the nature of the attack and the interface in question.
レポートでは、攻撃の性質と問題のインターフェイスも指定する必要があります。
Objective:
目的：
Measure the time taken to switch from an active controller to the backup controller when the controllers work in redundancy mode and the active controller fails, defined as the interval starting when the active controller is brought down and ending with the first rediscovery message received from the new controller at its southbound interface.
Measure the time taken to switch from an active controller to the backup controller when the controllers work in redundancy mode and the active controller fails, defined as the interval starting when the active controller is brought down and ending with the first rediscovery message received from the new controller at its southbound interface.
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use the test setup illustrated in Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.2に示されているテスト設定を使用する必要があります。
Prerequisites:
前提条件：
1. Master controller election MUST be completed.
1. マスターコントローラーの選択を完了する必要があります。
2. Nodes are connected to the controller cluster per the implemented redundancy mode (e.g., active-standby).
2. Nodes are connected to the controller cluster per the implemented redundancy mode (e.g., active-standby).
3. The controller cluster should have successfully completed the network topology discovery.
3. コントローラクラスタは、ネットワークトポロジの検出を正常に完了しているはずです。
4. The Network Device MUST send all new flows to the controller when it receives them from the test traffic generator.
4. The Network Device MUST send all new flows to the controller when it receives them from the test traffic generator.
5. The controller should have learned the location of the destination (D1) at test traffic generator TP2.
5. コントローラは、テストトラフィックジェネレータTP2で宛先（D1）の場所を学習している必要があります。
Procedure:
手順：
1. Send unidirectional traffic continuously with incremental sequence numbers and source addresses from test traffic generator TP1 at the rate at which the controller can process the traffic without any drops.
1. コントローラがドロップなしでトラフィックを処理できるレートで、テストトラフィックジェネレータTP1からの増分シーケンス番号と送信元アドレスを使用して、単方向トラフィックを継続的に送信します。
2. Ensure that there are no packet drops observed at test traffic generator TP2.
2. テストトラフィックジェネレータTP2でパケットドロップが観察されないことを確認します。
3. Bring down the active controller.
3. Bring down the active controller.
4. Stop the trial when the first frame after the failover operation is received on test traffic generator TP2.
4. Stop the trial when the first frame after the failover operation is received on test traffic generator TP2.
5. Record the time at which the last valid frame was received (T1) at test traffic generator TP2 before the sequence error and the time at which the first valid frame was received (T2) after the sequence error at test traffic generator TP2.
5. シーケンスエラーの前にテストトラフィックジェネレータTP2で最後の有効なフレームが受信された時刻（T1）と、テストトラフィックジェネレータTP2でシーケンスエラーの後で最初の有効なフレームが受信された時刻（T2）を記録します。
Measurements:
測定：
Controller Failover Time = (T2 - T1)
Packet Loss = Number of missing packet sequences
パケット損失=失われたパケットシーケンスの数
Reporting Format:
レポート形式：
The Controller Failover Time results MUST be tabulated with the following information:
コントローラのフェイルオーバー時間の結果は、次の情報で表にする必要があります。
- Number of cluster nodes
- Number of cluster nodes
- Redundancy mode
- 冗長モード
- Controller Failover Time
- コントローラのフェイルオーバー時間
- Packet Loss
- Packet Loss
- Cluster keep-alive interval
- クラスターのキープアライブ間隔
Objective:
目的：
Measure the time taken by the controller to reroute traffic when there is a failure in existing traffic paths, defined as the interval starting with the first failure notification message received by the controller and ending with the last flow re-provisioning message sent by the controller at its southbound interface.
既存のトラフィックパスに障害が発生したときに、コントローラーがトラフィックを再ルーティングするのにかかる時間を測定します。これは、コントローラーが受信した最初の障害通知メッセージで始まり、コントローラーが送信した最後のフロー再プロビジョニングメッセージで終わる間隔として定義されます。サウスバウンドインターフェイス。
Reference Test Setup:
参照テストのセットアップ：
This test SHOULD use one of the test setups illustrated in Section 3.1 or Section 3.2 of this document.
このテストでは、このドキュメントのセクション3.1またはセクション3.2に示されているテストセットアップの1つを使用する必要があります。
Prerequisites:
前提条件：
1. A network with a specified number of nodes and redundant paths MUST be deployed.
1. 指定した数のノードと冗長パスを持つネットワークを展開する必要があります。
2. The controller MUST know the location of test traffic generators TP1 and TP2.
2. コントローラは、テストトラフィックジェネレータTP1およびTP2の場所を認識している必要があります。
3. Ensure that the controller does not pre-provision the alternate path in the emulated Network Devices at the forwarding-plane test emulator.
3. コントローラが、フォワーディングプレーンテストエミュレータで、エミュレートされたネットワークデバイスの代替パスを事前プロビジョニングしないことを確認します。
Procedure:
Procedure:
1. Send bidirectional traffic continuously with a unique sequence number from test traffic generators TP1 and TP2.
1. テストトラフィックジェネレータTP1およびTP2からの一意のシーケンス番号を使用して、双方向トラフィックを継続的に送信します。
2. Bring down a link or switch in the traffic path.
2. Bring down a link or switch in the traffic path.
3. Stop the trial after receiving the first frame after network reconvergence.
3. ネットワークの再コンバージェンス後の最初のフレームを受信した後、トライアルを停止します。
4. Record the time of the last received frame prior to the frame loss at test traffic generator TP2 (TP2-Tlfr) and the time of the first frame received after the frame loss at test traffic generator TP2 (TP2-Tffr). There must be a gap in sequence numbers of these frames.
4. テストトラフィックジェネレーターTP2（TP2-Tlfr）でフレーム損失が発生する前に最後に受信したフレームの時刻と、テストトラフィックジェネレーターTP2（TP2-Tffr）でフレーム損失が発生した後に受信した最初のフレームの時刻を記録します。これらのフレームのシーケンス番号にはギャップが必要です。
5. Record the time of the last received frame prior to the frame loss at test traffic generator TP1 (TP1-Tlfr) and the time of the first frame received after the frame loss at test traffic generator TP1 (TP1-Tffr).
5. テストトラフィックジェネレータTP1（TP1-Tlfr）でフレーム損失が発生する前に最後に受信したフレームの時刻と、テストトラフィックジェネレータTP1（TP1-Tffr）でフレーム損失が発生した後に受信した最初のフレームの時刻を記録します。
Measurements:
測定：
Forward Direction Path Re-provisioning Time (FDRT)
= (TP2-Tffr - TP2-Tlfr)
Reverse Direction Path Re-provisioning Time (RDRT)
= (TP1-Tffr - TP1-Tlfr)
Network Re-provisioning Time = (FDRT + RDRT)/2
Forward Direction Packet Loss = Number of missing sequence frames at test traffic generator TP1
Forward Direction Packet Loss =テストトラフィックジェネレータTP1で失われたシーケンスフレームの数
Reverse Direction Packet Loss = Number of missing sequence frames at test traffic generator TP2
逆方向パケット損失=テストトラフィックジェネレータTP2で失われたシーケンスフレームの数
Reporting Format:
Reporting Format:
The Network Re-provisioning Time results MUST be tabulated with the following information:
The Network Re-provisioning Time results MUST be tabulated with the following information:
- Number of nodes in the primary path
- Number of nodes in the primary path
- Number of nodes in the alternate path
- 代替パス内のノードの数
- Network Re-provisioning Time
- Network Re-provisioning Time
- Forward Direction Packet Loss
- 順方向パケット損失
- Reverse Direction Packet Loss
- 逆方向パケット損失
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The benchmarking tests described in this document are limited to the performance characterization of controllers in a lab environment with isolated networks.
The benchmarking tests described in this document are limited to the performance characterization of controllers in a lab environment with isolated networks.
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを本番ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the controller.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、コントローラーの外部で観測可能な測定のみに依存します。
Special capabilities SHOULD NOT exist in the controller specifically for benchmarking purposes. Any implications for network security arising from the controller SHOULD be identical in the lab and in production networks.
特別な機能は、特にベンチマークの目的でコントローラーに存在すべきではありません。コントローラから生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります（SHOULD）。
[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>.
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8455] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance", RFC 8455, DOI 10.17487/RFC8455, October 2018, <https://www.rfc-editor.org/info/rfc8455>.
[RFC8455] Bhuvaneswaran、V.、Basil、A.、Tassinari、M.、Manral、V。、およびS. Banks、「Software-Defined Networking（SDN）Controller Performanceのベンチマークに関する用語」、RFC 8455、DOI 10.17487 / RFC8455 、2018年10月、<https://www.rfc-editor.org/info/rfc8455>。
[OpenFlow-Spec] ONF, "OpenFlow Switch Specification" Version 1.4.0 (Wire Protocol 0x05), October 2013, <https://www.opennetworking.org/wp-content/ uploads/2014/10/openflow-spec-v1.4.0.pdf>.
[OpenFlow-Spec] ONF、「OpenFlowスイッチ仕様」バージョン1.4.0（ワイヤプロトコル0x05）、2013年10月、<https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-spec- v1.4.0.pdf>。
This section gives an overview of the OpenFlow protocol [OpenFlow-Spec] and provides a test methodology for benchmarking SDN Controllers supporting the OpenFlow southbound protocol. The OpenFlow protocol is used as an example to illustrate the methodologies defined in this document.
このセクションでは、OpenFlowプロトコル[OpenFlow-Spec]の概要を示し、OpenFlowサウスバウンドプロトコルをサポートするSDNコントローラーをベンチマークするためのテスト方法を提供します。 OpenFlowプロトコルは、このドキュメントで定義されている方法を説明するための例として使用されています。
OpenFlow [OpenFlow-Spec] is an open standard protocol defined by the Open Networking Foundation (ONF) and used for programming the forwarding plane of network switches or routers via a centralized controller.
OpenFlow [OpenFlow-Spec]は、Open Networking Foundation（ONF）によって定義されたオープン標準プロトコルであり、集中型コントローラーを介してネットワークスイッチまたはルーターの転送プレーンをプログラミングするために使用されます。
The OpenFlow protocol supports three message types -- namely, controller-to-switch, asynchronous, and symmetric.
OpenFlowプロトコルは、3つのメッセージタイプをサポートします。つまり、コントローラからスイッチへ、非同期、および対称です。
Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch. These messages allow controllers to query/configure the switch ("features" messages, configuration messages), collect information from a switch (Read-State messages), send packets on a specified port of a switch (OFPT_PACKET_OUT messages), and modify the switch forwarding plane and state (Modify-State messages, Role-Request messages, etc.).
コントローラからスイッチへのメッセージは、コントローラによって開始され、スイッチの状態を直接管理または検査するために使用されます。これらのメッセージにより、コントローラーはスイッチのクエリ/構成（「機能」メッセージ、構成メッセージ）、スイッチからの情報の収集（Read-Stateメッセージ）、スイッチの指定ポートでのパケットの送信（OFPT_PACKET_OUTメッセージ）、およびスイッチの変更を行うことができます転送プレーンと状態（Modify-Stateメッセージ、Role-Requestメッセージなど）。
Asynchronous messages are generated by the switch without a controller soliciting them. These messages allow switches to update controllers to denote an arrival of a new flow (OFPT_PACKET_IN messages), switch state changes ("flow-removed" messages, port-status messages), and errors (Error messages).
非同期メッセージは、コントローラが要求することなくスイッチによって生成されます。これらのメッセージにより、スイッチはコントローラーを更新して、新しいフローの到着（OFPT_PACKET_INメッセージ）、スイッチの状態変化（「フローが削除された」メッセージ、ポートステータスメッセージ）、およびエラー（エラーメッセージ）を示すことができます。
Symmetric messages are generated in either direction without solicitation. These messages allow switches and controllers to set up a connection (Hello messages), verify liveness (Echo messages), and offer additional functionalities (Experimenter messages).
Symmetric messages are generated in either direction without solicitation. These messages allow switches and controllers to set up a connection (Hello messages), verify liveness (Echo messages), and offer additional functionalities (Experimenter messages).
The OpenFlow channel is used to exchange OpenFlow messages between an OpenFlow switch and an OpenFlow controller. The OpenFlow channel connection can be set up using plain TCP or TLS. By default, a switch establishes a single connection with the SDN Controller. A switch may establish multiple parallel connections to a single controller (auxiliary connection) or multiple controllers to handle controller failures and load balancing.
OpenFlowチャネルは、OpenFlowスイッチとOpenFlowコントローラー間でOpenFlowメッセージを交換するために使用されます。 OpenFlowチャネル接続は、プレーンTCPまたはTLSを使用してセットアップできます。デフォルトでは、スイッチはSDNコントローラーとの単一の接続を確立します。スイッチは、コントローラの障害と負荷分散を処理するために、単一のコントローラ（補助接続）または複数のコントローラへの複数の並列接続を確立できます。
Procedure:
手順：
Network Devices OpenFlow SDN
Controller Application
| | |
| |<Initialize controller |
| |app., NB and SB interfaces>|
| | |
|<Deploy network with | |
| given no. of OF switches> | |
| | |
| OFPT_HELLO Exchange | |
|<-------------------------->| |
| | |
| OFPT_PACKET_OUT with LLDP| |
| to all switches| |
(Tm1)|<---------------------------| |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch 1| |
|--------------------------->| |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch 2| |
|--------------------------->| |
| . | |
| . | |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch n| |
(Tmn)|--------------------------->| |
| | |
| | <Wait for the expiry of|
| | the Trial Duration (Td)>|
| | |
| | Query the controller for|
| | discovered n/w topo. (Di)|
| |<--------------------------|
| | |
| | <Compare the discovered|
| | n/w topology and the|
| | offered n/w topology>|
| | |
Legend:
伝説：
NB: Northbound SB: Southbound OF: OpenFlow OFP: OpenFlow Protocol LLDP: Link-Layer Discovery Protocol Tm1: Time of reception of first LLDP message from controller Tmn: Time of last LLDP message sent to controller
NB：ノースバウンドSB：サウスバウンドOF：OpenFlow OFP：OpenFlowプロトコルLLDP：リンク層発見プロトコルTm1：コントローラーからの最初のLLDPメッセージの受信時刻Tmn：コントローラーに送信された最後のLLDPメッセージの時刻
Discussion:
討論：
The Network Topology Discovery Time can be obtained by calculating the time difference between the first OFPT_PACKET_OUT with an LLDP message received from the controller (Tm1) and the last OFPT_PACKET_IN with an LLDP message sent to the controller (Tmn) when the comparison is successful.
The Network Topology Discovery Time can be obtained by calculating the time difference between the first OFPT_PACKET_OUT with an LLDP message received from the controller (Tm1) and the last OFPT_PACKET_IN with an LLDP message sent to the controller (Tmn) when the comparison is successful.
Procedure:
手順：
Network Devices OpenFlow SDN
Controller Application
| | |
|OFPT_PACKET_IN with single | |
|OFP match header | |
(T0)|--------------------------->| |
| | |
|OFPT_PACKET_OUT with single | |
| OFP action header | |
(R0)|<---------------------------| |
| . | |
| . | |
| . | |
| | |
|OFPT_PACKET_IN with single | |
|OFP match header | |
(Tn)|--------------------------->| |
| | |
|OFPT_PACKET_OUT with single | |
| OFP action header | |
(Rn)|<---------------------------| |
| | |
|<Wait for the expiry of the | |
|Trial Duration> | |
| | |
|<Record the number of | |
|OFPT_PACKET_INs/ | |
|OFPT_PACKET_OUTs | |
|exchanged (Nrx)> | |
| | |
Legend:
伝説：
T0,T1, ..Tn: transmit timestamps of OFPT_PACKET_IN messages R0,R1, ..Rn: receive timestamps of OFPT_PACKET_OUT messages Nrx: Number of successful OFPT_PACKET_IN/OFPT_PACKET_OUT message exchanges
T0,T1, ..Tn: transmit timestamps of OFPT_PACKET_IN messages R0,R1, ..Rn: receive timestamps of OFPT_PACKET_OUT messages Nrx: Number of successful OFPT_PACKET_IN/OFPT_PACKET_OUT message exchanges
Discussion:
討論：
The Asynchronous Message Processing Time will be obtained by calculating the sum of ((R0 - T0),(R1 - T1)..(Rn - Tn))/Nrx.
非同期メッセージ処理時間は、（（R0-T0）、（R1-T1）..（Rn-Tn））/ Nrxの合計を計算することによって得られます。
Procedure:
手順：
Network Devices OpenFlow SDN
Controller Application
| | |
|OFPT_PACKET_IN with single | |
|OFP match header | |
|--------------------------->| |
| | |
|OFPT_PACKET_OUT with single | |
| OFP action header | |
|<---------------------------| |
| | |
| . | |
| . | |
| . | |
| | |
|OFPT_PACKET_IN with single | |
|OFP match header | |
|--------------------------->| |
| | |
|OFPT_PACKET_OUT with single | |
| OFP action header | |
|<---------------------------| |
| | |
|<Repeat the steps until | |
|the expiry of the | |
|Trial Duration> | |
| | |
|<Record the number of OFP | |
(Ntx1)|match headers sent> | |
| | |
|<Record the number of OFP | |
(Nrx1)|action headers rcvd> | |
| | |
Note: The Ntx1 on initial trials should be greater than Nrx1. Repeat the trials until the Nrxn for two consecutive trials equals (+/-P%).
注：最初の試行のNtx1はNrx1より大きくなければなりません。 2つの連続する試行のNrxnが（+/- P％）になるまで試行を繰り返します。
Discussion:
討論：
Using a single procedure, this test will measure two benchmarks:
Using a single procedure, this test will measure two benchmarks:
1. The Maximum Asynchronous Message Processing Rate will be obtained by calculating the maximum OFPT_PACKET_OUTs (Nrxn) received from the controller(s) across n trials.
1. 最大非同期メッセージ処理率は、n回の試行にわたってコントローラーから受信した最大OFPT_PACKET_OUT（Nrxn）を計算することによって取得されます。
2. The Loss-Free Asynchronous Message Processing Rate will be obtained by calculating the maximum OFPT_PACKET_OUTs received from the controller(s) when the Loss Ratio equals zero. The Loss Ratio is obtained by calculating 1 - Nrxn/Ntxn.
2. ロスのない非同期メッセージ処理率は、ロス率がゼロの場合にコントローラーから受信した最大OFPT_PACKET_OUTを計算することで得られます。損失率は、1-Nrxn / Ntxnを計算して得られます。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow
Generator TP1 Generator TP2 Controller
| | | |
| |G-ARP (D1) | |
| |--------------------->| |
| | | |
| | |OFPT_PACKET_IN(D1) |
| | |-------------------->|
| | | |
|Traffic (S1,D1) | |
(Tsf1)|----------------------------------->| |
| | | |
| | | |
| | | |
| | |OFPT_PACKET_IN(S1,D1)|
| | |-------------------->|
| | | |
| | | FLOW_MOD(D1) |
| | |<--------------------|
| | | |
| |Traffic (S1,D1) | |
| (Tdf1)|<---------------------| |
| | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message Tsf1: Time of first frame sent from TP1 Tdf1: Time of first frame received from TP2
G-ARP：Gratuitous ARPメッセージTsf1：TP1から送信された最初のフレームの時間Tdf1：TP2から受信された最初のフレームの時間
Discussion:
討論：
The Reactive Path Provisioning Time can be obtained by finding the time difference between the transmit and receive times of the traffic (Tsf1 - Tdf1).
リアクティブパスプロビジョニング時間は、トラフィックの送信時間と受信時間の時間差（Tsf1-Tdf1）を見つけることで取得できます。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| | | | |
| | | |<Install flow|
| | | | for S1,D1> |
| |G-ARP (D1) | | |
| |-------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1)| |
| | |----------------->| |
| | | | |
|Traffic (S1,D1) | | |
(Tsf1)|--------------------------->| | |
| | | | |
| | | FLOW_MOD(D1) | |
| | |<-----------------| |
| | | | |
| |Traffic (S1,D1)| | |
| (Tdf1)|<--------------| | |
| | | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message Tsf1: Time of first frame sent from TP1 Tdf1: Time of first frame received from TP2
G-ARP：Gratuitous ARPメッセージTsf1：TP1から送信された最初のフレームの時間Tdf1：TP2から受信された最初のフレームの時間
Discussion:
討論：
The Proactive Path Provisioning Time can be obtained by finding the time difference between the transmit and receive times of the traffic (Tsf1 - Tdf1).
プロアクティブパスプロビジョニング時間は、トラフィックの送信時間と受信時間の時間差（Tsf1-Tdf1）を見つけることで取得できます。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow
Generator TP1 Generator TP2 Controller
| | | |
| | | |
| | | |
| |G-ARP (D1..Dn) | |
| |--------------------| |
| | | |
| | |OFPT_PACKET_IN(D1..Dn)|
| | |--------------------->|
| | | |
|Traffic (S1..Sn,D1..Dn) | |
|--------------------------------->| |
| | | |
| | |OFPT_PACKET_IN(S1..Sn,|
| | | D1..Dn)|
| | |--------------------->|
| | | |
| | | FLOW_MOD(S1) |
| | |<---------------------|
| | | |
| | | FLOW_MOD(D1) |
| | |<---------------------|
| | | |
| | | FLOW_MOD(S2) |
| | |<---------------------|
| | | |
| | | FLOW_MOD(D2) |
| | |<---------------------|
| | | . |
| | | . |
| | | |
| | | FLOW_MOD(Sn) |
| | |<---------------------|
| | | |
| | | FLOW_MOD(Dn) |
| | |<---------------------|
| | | |
| | Traffic (S1..Sn, | |
| | D1..Dn)| |
| |<-------------------| |
| | | |
| | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message D1..Dn: Destination Endpoint 1, Destination Endpoint 2 ..., Destination Endpoint n S1..Sn: Source Endpoint 1, Source Endpoint 2 ..., Source Endpoint n
G-ARP：Gratuitous ARPメッセージD1..Dn：宛先エンドポイント1、宛先エンドポイント2 ...、宛先エンドポイントn S1..Sn：ソースエンドポイント1、ソースエンドポイント2 ...、ソースエンドポイントn
Discussion:
討論：
The Reactive Path Provisioning Rate can be obtained by finding the total number of frames received at test traffic generator TP2 after the Trial Duration.
リアクティブパスプロビジョニングレートは、トライアル期間後にテストトラフィックジェネレータTP2で受信されたフレームの総数を見つけることで取得できます。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| |G-ARP (D1..Dn) | | |
| |--------------->| | |
| | | | |
| | |OFPT_PACKET_IN | |
| | | (D1..Dn)| |
| | |---------------->| |
| | | | |
|Traffic (S1..Sn,D1..Dn) | | |
(Tsf1)|---------------------------->| | |
| | | | |
| | | |<Install flow|
| | | | for S1,D1> |
| | | | |
| | | | . |
| | | |<Install flow|
| | | | for Sn,Dn> |
| | | | |
| | | FLOW_MOD(S1) | |
| | |<----------------| |
| | | | |
| | | FLOW_MOD(D1) | |
| | |<----------------| |
| | | | |
| | | . | |
| | | FLOW_MOD(Sn) | |
| | |<----------------| |
| | | | |
| | | FLOW_MOD(Dn) | |
| | |<----------------| |
| | | | |
| |Traffic (S1..Sn,| | |
| | D1..Dn)| | |
| (Tdf1)|<---------------| | |
| | | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message D1..Dn: Destination Endpoint 1, Destination Endpoint 2 ..., Destination Endpoint n S1..Sn: Source Endpoint 1, Source Endpoint 2 ..., Source Endpoint n
G-ARP: Gratuitous ARP message D1..Dn: Destination Endpoint 1, Destination Endpoint 2 ..., Destination Endpoint n S1..Sn: Source Endpoint 1, Source Endpoint 2 ..., Source Endpoint n
Discussion:
討論：
The Proactive Path Provisioning Rate can be obtained by finding the total number of frames received at test traffic generator TP2 after the Trial Duration.
プロアクティブパスプロビジョニングレートは、トライアル期間後にテストトラフィックジェネレータTP2で受信されたフレームの総数を見つけることで取得できます。
Procedure:
手順：
Network Devices OpenFlow SDN
Controller Application
| | |
| | <Bring down a link in |
| | Switch S1>|
| | |
T0 |PORT_STATUS with link down | |
| from S1 | |
|--------------------------->| |
| | |
|First OFPT_PACKET_OUT with | |
|LLDP to OF switch | |
T1 |<---------------------------| |
| | |
| | <Record time of first|
| | OFPT_PACKET_OUT with|
| | LLDP T1>|
| | |
Discussion:
Discussion:
The Network Topology Change Detection Time can be obtained by finding the difference between the time that OpenFlow Switch S1 sends the PORT_STATUS message (T0) and the time that the OpenFlow controller sends the first topology rediscovery message (T1) to OpenFlow switches.
ネットワークトポロジ変更検出時間は、OpenFlowスイッチS1がPORT_STATUSメッセージ（T0）を送信する時間とOpenFlowコントローラーが最初のトポロジ再検出メッセージ（T1）をOpenFlowスイッチに送信する時間の差を見つけることで取得できます。
Procedure:
手順：
Network Devices OpenFlow
Controller
| |
| OFPT_HELLO Exchange for Switch 1 |
|<------------------------------------->|
| |
| OFPT_HELLO Exchange for Switch 2 |
|<------------------------------------->|
| . |
| . |
| . |
| OFPT_HELLO Exchange for Switch n |
|X<----------------------------------->X|
| |
Discussion:
討論：
The value of Switch (n - 1) will provide the Control Sessions Capacity.
Switch（n-1）の値は、制御セッション容量を提供します。
Procedure:
手順：
Network Devices OpenFlow SDN
Controller Application
| | |
| | <Deploy network with |
| |given no. of OF switches N>|
| | |
| OFPT_HELLO Exchange | |
|<-------------------------->| |
| | |
| OFPT_PACKET_OUT with LLDP| |
| to all switches | |
|<---------------------------| |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch 1| |
|--------------------------->| |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch 2| |
|--------------------------->| |
| . | |
| . | |
| | |
| OFPT_PACKET_IN with LLDP| |
| rcvd from Switch n| |
|--------------------------->| |
| | |
| | <Wait for the expiry of|
| | the Trial Duration (Td)>|
| | |
| | Query the controller for|
| | discovered n/w topo. (N1)|
| |<--------------------------|
| | |
| | <If N1==N, repeat Step 1|
| | with N + 1 nodes|
| | until N1<N >|
| | |
| | <If N1<N, repeat Step 1 |
| | with N=N1 nodes once and |
| | exit> |
| | |
Legend:
伝説：
n/w topo: Network topology OF: OpenFlow
n / w topo：ネットワークトポロジOF：OpenFlow
Discussion:
討論：
The value of N1 provides the Network Discovery Size value. The Trial Duration can be set to the stipulated time within which the user expects the controller to complete the discovery process.
N1の値は、ネットワーク探索サイズの値を提供します。トライアル期間は、ユーザーがコントローラーがディスカバリープロセスを完了することを期待する規定時間に設定できます。
Procedure:
手順：
Test Traffic Network Devices OpenFlow SDN
Generator TP1 Controller Application
| | | |
| | | |
|G-ARP (H1..Hn) | | |
|---------------->| | |
| | | |
| |OFPT_PACKET_IN(D1..Dn)| |
| |--------------------->| |
| | | |
| | |<Wait for 5 secs>|
| | | |
| | | <Query for FWD |
| | | entry> |(F1)
| | | |
| | |<Wait for 5 secs>|
| | | |
| | | <Query for FWD |
| | | entry> |(F2)
| | | |
| | |<Wait for 5 secs>|
| | | |
| | | <Query for FWD |
| | | entry> |(F3)
| | | |
| | | <Repeat Step 2 |
| | |until F1==F2==F3>|
| | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message H1..Hn: Host 1 .. Host n FWD: Forwarding Table
G-ARP：Gratuitous ARPメッセージH1..Hn：ホスト1 ..ホストn FWD：転送テーブル
Discussion:
討論：
Query the controller's Forwarding Table entries multiple times, until three consecutive queries return the same value. The last value retrieved from the controller will provide the Forwarding Table Capacity value. The query interval is user configurable. The interval of 5 seconds shown in this example is for representational purposes.
3つの連続したクエリが同じ値を返すまで、コントローラの転送テーブルエントリを複数回クエリします。コントローラから取得された最後の値は、転送テーブル容量の値を提供します。クエリ間隔はユーザーが構成できます。この例に示されている5秒の間隔は、説明のためのものです。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| |G-ARP (D1..Dn) | | |
| |--------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1..Dn)| |
| | |--------------------->| |
| | | | |
|Traffic (S1..Sn,D1..Dn) | | |
|-------------------------->| | |
| | | | |
| | |OFPT_PACKET_IN(S1..Sa,| |
| | | D1..Da)| |
| | |--------------------->| |
| | | | |
| | |OFPT_PACKET_IN | |
| | | (Sa+1..Sn,| |
| | | Da+1..Dn)| |
| | | (1% incorrect OFP| |
| | | match header)| |
| | |--------------------->| |
| | | | |
| | | FLOW_MOD(D1..Dn)| |
| | |<---------------------| |
| | | | |
| | | FLOW_MOD(S1..Sa)| |
| | | OFP headers| |
| | |<---------------------| |
| | | | |
| |Traffic (S1..Sa,| | |
| | D1..Da)| | |
| |<---------------| | |
| | | | |
| | | | <Wait for the|
| | | | expiry of the|
| | | | Trial|
| | | | Duration>|
| | | | |
| | | | <Record Rx|
| | | | frames at|
| | | | TP2 (Rn1)>|
| | | | |
| | | | <Repeat |
| | | | Step 1 with|
| | | | 2% incorrect|
| | | |OFPT_PACKET_INs>|
| | | | |
| | | | <Record Rx|
| | | | frames at|
| | | | TP2 (Rn2)>|
Legend:
伝説：
G-ARP: Gratuitous ARP message OFPT_PACKET_IN(Sa+1..Sn,Da+1..Dn): OFPT_PACKET_IN with wrong version number Rn1: Total number of frames received at Test Port 2 with 1% incorrect frames Rn2: Total number of frames received at Test Port 2 with 2% incorrect frames
G-ARP：Gratuitous ARPメッセージOFPT_PACKET_IN（Sa + 1..Sn、Da + 1..Dn）：間違ったバージョン番号のOFPT_PACKET_IN Rn1：テストポート2で受信されたフレームの総数、1％の不正なフレームRn2：総数テストポート2で受信したフレームの2％が不正なフレーム
Discussion:
討論：
The traffic rate sent towards the OpenFlow switch from Test Port 1 should be 1% higher than the Path Programming Rate. Rn1 will provide the Path Provisioning Rate of the controller when 1% of incorrect frames are received, and Rn2 will provide the Path Provisioning Rate of the controller when 2% of incorrect frames are received.
テストポート1からOpenFlowスイッチに送信されるトラフィックレートは、パスプログラミングレートよりも1％高くなければなりません。 Rn1は、不正なフレームの1％を受信したときにコントローラーのパスプロビジョニングレートを提供し、Rn2は、不正なフレームの2％を受信したときにコントローラーのパスプロビジョニングレートを提供します。
The procedure defined above provides test steps to determine the effects of handling error packets on the Path Programming Rate. The same procedure can be adapted to determine the effects on other performance tests listed in this benchmarking test.
上記で定義された手順は、パスプログラミングレートに対するエラーパケットの処理の影響を決定するためのテストステップを提供します。このベンチマークテストに記載されている他のパフォーマンステストへの影響を判断するために、同じ手順を適用できます。
Procedure:
手順：
Test Traffic Test Traffic Network Device OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| |G-ARP (D1..Dn) | | |
| |---------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1..Dn)| |
| | |--------------------->| |
| | | | |
|Traffic (S1..Sn,D1..Dn) | | |
|--------------------------->| | |
| | | | |
| | |OFPT_PACKET_IN(S1..Sn,| |
| | | D1..Dn)| |
| | |--------------------->| |
| | | | |
| | |TCP SYN attack | |
| | |from a switch | |
| | |--------------------->| |
| | | | |
| | |FLOW_MOD(D1..Dn) | |
| | |<---------------------| |
| | | | |
| | | FLOW_MOD(S1..Sn) | |
| | | OFP headers | |
| | |<---------------------| |
| | | | |
| |Traffic (S1..Sn, | | |
| | D1..Dn) | | |
| |<----------------| | |
| | | | |
| | | |<Wait for the|
| | | |expiry of the|
| | | | Trial|
| | | | Duration>|
| | | | |
| | | | <Record Rx|
| | | | frames at|
| | | | TP2 (Rn1)>|
| | | | |
Legend:
伝説：
G-ARP: Gratuitous ARP message
G-ARP：Gratuitous ARPメッセージ
Discussion:
討論：
A TCP SYN attack should be launched from one of the emulated/simulated OpenFlow switches. Rn1 provides the Path Programming Rate of the controller upon handling a denial-of-service attack.
TCP SYN攻撃は、エミュレート/シミュレーションされたOpenFlowスイッチの1つから起動する必要があります。 Rn1は、サービス拒否攻撃の処理時にコントローラーのパスプログラミングレートを提供します。
The procedure defined above provides test steps to determine the effects of handling denial of service on the Path Programming Rate. The same procedure can be adapted to determine the effects on other performance tests listed in this benchmarking test.
上記で定義された手順は、パスプログラミングレートに対するサービス拒否の処理の影響を決定するためのテストステップを提供します。このベンチマークテストに記載されている他のパフォーマンステストへの影響を判断するために、同じ手順を適用できます。
Procedure:
手順：
Test Traffic Test Traffic Network Device OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| |G-ARP (D1) | | |
| |-------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1) | |
| | |---------------------->| |
| | | | |
|Traffic (S1..Sn,D1) | | |
|--------------------------->| | |
| | | | |
| | | | |
| | |OFPT_PACKET_IN(S1,D1) | |
| | |---------------------->| |
| | | | |
| | |FLOW_MOD(D1) | |
| | |<----------------------| |
| | |FLOW_MOD(S1) | |
| | |<----------------------| |
| | | | |
| |Traffic (S1,D1)| | |
| |<--------------| | |
| | | | |
| | |OFPT_PACKET_IN(S2,D1) | |
| | |---------------------->| |
| | | | |
| | |FLOW_MOD(S2) | |
| | |<----------------------| |
| | | | |
| | |OFPT_PACKET_IN | |
| | | (Sn-1,D1) | |
| | |---------------------->| |
| | | | |
| | |OFPT_PACKET_IN(Sn,D1) | |
| | |---------------------->| |
| | | . | |
| | | . |<Bring down |
| | | . | the active |
| | | | controller> |
| | | FLOW_MOD(Sn-1) | |
| | | X<-----------------| |
| | | | |
| | |FLOW_MOD(Sn) | |
| | |<----------------------| |
| | | | |
| |Traffic (Sn,D1)| | |
| |<--------------| | |
| | | | |
| | | |<Stop the |
| | | |test after |
| | | |recv. traffic|
| | | |upon |
| | | |failure> |
Legend:
伝説：
G-ARP: Gratuitous ARP message
G-ARP：Gratuitous ARPメッセージ
Discussion:
討論：
The time difference between the last valid frame received before the traffic loss and the first frame received after the traffic loss will provide the Controller Failover Time.
トラフィックが失われる前に受信された最後の有効なフレームと、トラフィックが失われた後に受信された最初のフレームとの時間差により、コントローラーのフェイルオーバー時間が得られます。
If there is no frame loss during the Controller Failover Time, the Controller Failover Time can be deemed negligible.
コントローラのフェイルオーバー時間中にフレームの損失がない場合、コントローラのフェイルオーバー時間は無視できると見なすことができます。
Procedure:
手順：
Test Traffic Test Traffic Network Devices OpenFlow SDN
Generator TP1 Generator TP2 Controller Application
| | | | |
| |G-ARP (D1) | | |
| |--------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1) | |
| | |--------------------->| |
| |G-ARP (S1) | | |
|----------------------------->| | |
| | | | |
| | |OFPT_PACKET_IN(S1) | |
| | |--------------------->| |
| | | | |
|Traffic (S1,D1,Seq. no (1..n))| | |
|----------------------------->| | |
| | | | |
| | |OFPT_PACKET_IN(S1,D1) | |
| | |--------------------->| |
| | | | |
| | Traffic (D1,S1,| | |
| | Seq. no (1..n))| | |
| |--------------->| | |
| | | | |
| | |OFPT_PACKET_IN(D1,S1) | |
| | |--------------------->| |
| | | | |
| | |FLOW_MOD(D1) | |
| | |<---------------------| |
| | | | |
| | |FLOW_MOD(S1) | |
| | |<---------------------| |
| | | | |
| | Traffic (S1,D1,| | |
| | Seq. no(1))| | |
| |<---------------| | |
| | | | |
| | Traffic (S1,D1,| | |
| | Seq. no(2))| | |
| |<---------------| | |
| | | | |
| | | | |
| Traffic (D1,S1,Seq. no(1))| | |
|<-----------------------------| | |
| | | | |
| Traffic (D1,S1,Seq. no(2))| | |
|<-----------------------------| | |
| | | | |
| Traffic (D1,S1,Seq. no(x))| | |
|<-----------------------------| | |
| | | | |
| | Traffic (S1,D1,| | |
| | Seq. no(x))| | |
| |<---------------| | |
| | | | |
| | | | |
| | | | <Bring down |
| | | | the switch in|
| | | | the active|
| | | | traffic path>|
| | | | |
| | |PORT_STATUS(Sa) | |
| | |--------------------->| |
| | | | |
| | Traffic (S1,D1,| | |
| | Seq. no(n - 1))| | |
| | X<------------| | |
| | | | |
|Traffic (D1,S1,Seq. no(n - 1))| | |
| X<------------------------| | |
| | | | |
| | | | |
| | |FLOW_MOD(D1) | |
| | |<---------------------| |
| | | | |
| | |FLOW_MOD(S1) | |
| | |<---------------------| |
| | | | |
| Traffic (D1,S1,Seq. no(n))| | |
|<-----------------------------| | |
| | | | |
| | Traffic (S1,D1,| | |
| | Seq. no(n))| | |
| |<---------------| | |
| | | | |
| | | |<Stop the test|
| | | | after recv. |
| | | | traffic upon|
| | | | failover> |
Legend:
伝説：
G-ARP: Gratuitous ARP message Seq. no: Sequence number Sa: Neighbor switch of the switch that was brought down
G-ARP：Gratuitous ARPメッセージSeq。 no：シーケンス番号Sa：ダウンしたスイッチの隣接スイッチ
Discussion:
討論：
The time difference between the last valid frame received before the traffic loss (packet with sequence number x) and the first frame received after the traffic loss (packet with sequence number n) will provide the Network Re-provisioning Time.
トラフィック損失の前に受信した最後の有効なフレーム（シーケンス番号xのパケット）と、トラフィック損失の後に受信した最初のフレーム（シーケンス番号nのパケット）との時間差により、ネットワーク再プロビジョニング時間が提供されます。
Note that the trial is valid only when the controller provisions the alternate path upon network failure.
トライアルは、コントローラーがネットワーク障害時に代替パスをプロビジョニングする場合にのみ有効であることに注意してください。
Acknowledgments
謝辞
The authors would like to thank the following individuals for providing their valuable comments regarding the earlier draft versions of this document: Al Morton (AT&T), Sandeep Gangadharan (HP), M. Georgescu (NAIST), Andrew McGregor (Google), Scott Bradner, Jay Karthik (Cisco), Ramki Krishnan (VMware), Boris Khasanov (Huawei), and Brian Castelli (Spirent).
著者は、このドキュメントの以前のドラフトバージョンに関する貴重なコメントを提供してくれた次の人物に感謝します。AlMorton（AT＆T）、Sandeep Gangadharan（HP）、M。Georgescu（NAIST）、Andrew McGregor（Google）、Scott Bradner 、Jay Karthik（Cisco）、Ramki Krishnan（VMware）、Boris Khasanov（Huawei）、およびBrian Castelli（Spirent）。
Authors' Addresses
著者のアドレス
Bhuvaneswaran Vengainathan Veryx Technologies Inc. 1 International Plaza, Suite 550 Philadelphia, PA 19113 United States of America
Bhuvaneswaran Vengainathan Veryx Technologies Inc. 1 International Plaza、Suite 550 Philadelphia、PA 19113アメリカ合衆国
Email: bhuvaneswaran.vengainathan@veryxtech.com
Anton Basil Veryx Technologies Inc. 1 International Plaza, Suite 550 Philadelphia, PA 19113 United States of America
Anton Basil Veryx Technologies Inc. 1 International Plaza、Suite 550 Philadelphia、PA 19113アメリカ合衆国
Email: anton.basil@veryxtech.com
Mark Tassinari Hewlett Packard Enterprise 8000 Foothills Blvd. Roseville, CA 95747 United States of America
Mark Tassinari Hewlett Packard Enterprise 8000 Foothills Blvd.ローズビル、カリフォルニア州95747アメリカ合衆国
Email: mark.tassinari@hpe.com
Vishwas Manral NanoSec Co 3350 Thomas Rd. Santa Clara, CA 95054 United States of America
3350トーマスパリーからビスワスミネラルナンスへ。 95054アメリカ合衆国、サンタクララ
Email: vishwas.manral@gmail.com
Sarah Banks VSS Monitoring 930 De Guigne Drive Sunnyvale, CA 94085 United States of America
サラバンクスVSSモニタリング930 De Guigne Driveサニーベール、カリフォルニア州94085アメリカ合衆国
Email: sbanks@encrypted.net