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
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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控制器的性能、可伸缩性、可靠性和安全性，独立于北向和南向协议。配套术语文档[RFC8455]中描述了与SDN控制器基准测试相关的术语。这些测试可以在作为虚拟机（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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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控制器都不在本备忘录的范围内。本文档中定义的测试以两种方式实现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 |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| 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 |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| 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.
测试用例应使用Leaf Spine拓扑，拓扑中至少有两个网络设备用于基准测试。测试流量生成器TP1和TP2应连接到叶网络设备1和叶网络设备n。为了实现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字节的帧大小进行基准测试。使用巨型帧的测试是可选的。
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.
测试仿真器应在已建立的网络连接上为控制器发送和接收的控制消息加上时间戳。测试用例使用这些值来计算控制器处理时间。
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. 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.
测量的准确性取决于几个因素，包括捕捉指示的观察点。例如，可以在控制器或测试仿真器上观察通知。除非单独测试中另有明确规定，否则测试操作员应在测试模拟器的接口处进行观察/测量。在任何情况下，都必须报告测量点的位置。
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控制器应直接与转发平面和管理平面测试模拟器连接，以避免基准测试期间中间设备引入的任何延迟或故障。当控制器实现为虚拟机时，必须报告物理和逻辑连接的详细信息。
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
7. 节点数
8. Number of links
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.
确定上述两个值的一种方法是模拟所需的控制会话和来自控制平面的消息。
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节所述的试验装置之一。
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. 当发现的拓扑信息与部署的网络拓扑匹配时，或者当发现的拓扑信息为三个连续查询返回相同的详细信息时，停止试用。
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
DT1 + DT2 + DT3 .. DTn
Average Topology Discovery Time (TDm) = -----------------------
Total Trials
SUM[SQUAREOF(DTi - TDm)]
Topology Discovery Time Variance (TDv) = ------------------------
Total Trials - 1
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.
拓扑发现时间结果必须以表格格式报告，每个成功的迭代都有一行。表的最后一行表示拓扑发现时间差异，前一行表示平均拓扑发现时间。
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.
如果在同一拓扑上使用不同数量的节点重复此测试，则应以图表的形式报告结果。X坐标应为节点数（N），Y坐标应为平均拓扑发现时间。
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节所述的试验装置之一。
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控制器生成异步消息，在试验期间，从转发平面测试仿真器依次生成一条消息。
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. 在转发平面测试仿真器接口（I1）上记录每个成功消息交换的每个请求传输时间（T1）和相应的响应接收时间（R1）。
Measurements:
测量：
Asynchronous Message Processing Time (APT1) =
SUM{Ri} - SUM{Ti}
-----------------------
Nrx
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
Average Asynchronous Message Processing Time =
APT1 + APT2 + APT3 .. APTn
--------------------------
Total Trials
Asynchronous Message Processing Time Variance (TAMv) =
SUM[SQUAREOF(APTi - TAMm)]
--------------------------
Total Trials - 1
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.
异步消息处理时间结果必须以表格格式报告，每个迭代都有一行。表的最后一行表示异步消息处理时间差异，前一行表示平均异步消息处理时间。
The report SHOULD capture the following information, in addition to the configuration parameters captured per Section 4.8:
除了根据第4.8节捕获的配置参数外，报告还应捕获以下信息：
- 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.
如果对具有相同拓扑结构的不同数量的节点重复此测试，则应以图表的形式报告结果。X坐标应为节点数（N），Y坐标应为平均异步消息处理时间。
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]):
使用单个程序，该测试将测量异步消息处理率的以下两个基准（见[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.
这里，通过一系列试验确定两个基准，其中发送到控制器的消息数量和从控制器接收到的响应在试验持续时间内计数。计算每个试验的消息响应率和消息丢失率。
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节所述的试验装置之一。
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）、发送速率步长、两次连续试验的相等容差（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. 记录从控制器接收的响应总数（Nrx1）以及在试验持续时间（Td）内发送给控制器的消息数（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. 通过将上一次试验中使用的异步消息发送速率降低步长，重复试验。
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. 必须使用相同的异步消息速率重复与基准级别对应的试验，直到从控制器接收到的响应在两个连续试验中相等（+/-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
Nrxn
Asynchronous Message Processing Rate (APRn) = -----
Td
Maximum Asynchronous Message Processing Rate = MAX(APRn) for all n
最大异步消息处理速率=所有n的最大（APRn）
Nrxn
Asynchronous Message Loss Ratio (Lrn) = 1 - -----
Ntxn
Nrxn
Asynchronous Message Loss Ratio (Lrn) = 1 - -----
Ntxn
Loss-Free Asynchronous Message Processing Rate = MAX(APRn) given Lrn = 0
给定Lrn=0时，无丢失异步消息处理速率=最大（APRn）
Reporting Format:
报告格式：
The Asynchronous Message Processing Rate results MUST be reported in tabular format, with a row for each trial.
异步消息处理速率结果必须以表格格式报告，每个试验都有一行。
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轴应为提供的速率，双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.
如果在同一拓扑上使用不同数量的节点重复此测试，则应以图表的形式报告结果。X轴应为节点数（N），Y轴应为异步消息处理速率。应为每个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节所述的试验装置之一。路径中的网络设备数量是测试的一个参数，在重复该测试时，该参数可以从两个到最大发现大小不等。
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. 在转发平面测试仿真器接口（I1）处记录从控制器（Tdf1）接收到网络设备的最后一条流供应响应消息的时间。
Measurements:
测量：
Reactive Path Provisioning Time (RPT1) = Tdf1 - Tsf1
反应路径供应时间（RPT1）=Tdf1-Tsf1
Average Reactive Path Provisioning Time =
RPT1 + RPT2 + RPT3 .. RPTn
--------------------------
Total Trials
Average Reactive Path Provisioning Time =
RPT1 + RPT2 + RPT3 .. RPTn
--------------------------
Total Trials
Reactive Path Provisioning Time Variance (TRPv) =
SUM[SQUAREOF(RPTi - TRPm)]
--------------------------
Total Trials - 1
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.
反应路径供应时间结果必须以表格格式报告，每个迭代都有一行。表的最后一行表示反应路径供应时间差异，前一行表示平均反应路径供应时间。
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节所述的试验装置之一。
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
Average Proactive Path Provisioning Time =
PPT1 + PPT2 + PPT3 .. PPTn
--------------------------
Total Trials
Proactive Path Provisioning Time Variance (TPPv) =
SUM[SQUAREOF(PPTi - TPPm)]
--------------------------
Total Trials - 1
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.
主动路径供应时间结果必须以表格格式报告，每个迭代都有一行。表的最后一行表示主动路径设置时间差异，前一行表示平均主动路径设置时间。
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.
测量控制器每秒可在源节点和目标节点之间以反应方式并发建立的最大独立路径数，定义为控制器每秒提供的路径数在测试开始和给定试验持续时间到期之间，在其南行接口处接收到用于路径供应的流供应请求的南行接口处。
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节所述的试验装置之一。
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. 记录测试流量生成器TP2在试验持续时间（Td）内接收到的唯一流量帧（Ndf）总数。
Measurements:
测量：
Ndf
Reactive Path Provisioning Rate (RPR1) = ------
Td
Ndf
Reactive Path Provisioning Rate (RPR1) = ------
Td
Average Reactive Path Provisioning Rate =
RPR1 + RPR2 + RPR3 .. RPRn
--------------------------
Total Trials
Average Reactive Path Provisioning Rate =
RPR1 + RPR2 + RPR3 .. RPRn
--------------------------
Total Trials
Reactive Path Provisioning Rate Variance (RPPv) =
SUM[SQUAREOF(RPRi - RPPm)]
--------------------------
Total Trials - 1
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.
反应路径供应率结果必须以表格形式报告，每个迭代都有一行。表的最后一行表示反应路径配置率差异，前一行表示平均反应路径配置率。
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.
测量控制器每秒可在源节点和目标节点之间主动并发建立的最大独立路径数，定义为控制器每秒提供的路径数在测试开始和给定试验持续时间到期之间的北向接口中请求的路径的南向接口处。测量基于成功路径激活的数据平面观察。
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节所述的试验装置之一。
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. 记录测试流量生成器TP2在试验持续时间（Td）内接收到的唯一流量帧（Ndf）总数。
Measurements:
测量：
Ndf
Proactive Path Provisioning Rate (PPR1) = ------
Td
Ndf
Proactive Path Provisioning Rate (PPR1) = ------
Td
Average Proactive Path Provisioning Rate =
PPR1 + PPR2 + PPR3 .. PPRn
--------------------------
Total Trials
Average Proactive Path Provisioning Rate =
PPR1 + PPR2 + PPR3 .. PPRn
--------------------------
Total Trials
Proactive Path Provisioning Rate Variance (PPPv) =
SUM[SQUAREOF(PPRi - PPPm)]
-------------------------
Total Trials - 1
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.
主动路径供应率结果必须以表格格式报告，每个迭代都有一行。表的最后一行表示主动路径调配率差异，前一行表示平均主动路径调配率。
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.
测量控制器检测网络拓扑中的任何更改所用的时间量，定义为从控制器在其南行接口接收到的通知消息开始到从控制器在其南行接口发送的第一条拓扑重新发现消息结束的间隔。
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节所述的试验装置之一。
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）值的两倍。
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
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
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.
网络拓扑变化检测时间结果必须以表格形式报告，每次迭代一行。表的最后一行表示网络拓扑变化检测时间差异，前一行表示平均网络拓扑变化检测时间。
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节所述的试验装置之一。
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节所述的试验装置之一。
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. 当发现的网络拓扑信息与最后两个查询响应的拓扑信息相同时，停止试用。
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节所述的试验装置之一。
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. 当检索到的值在连续三次迭代中保持不变时，停止试验，并记录从上次查询（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. 通过控制器的北向接口或管理接口持续安装unique流，直到收到控制器的故障响应。
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. 路径配置率
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.
本试验应使用本文件第3.1节或第3.2节所述的试验装置之一。
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
- 有2%的例外
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节所述的试验装置之一。
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:
注意：DoS攻击可以在以下接口之一上启动：
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:
报告格式：
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.
有关DoS攻击处理的结果必须以表格形式报告，以下参数各有一列，上述测试各有一行。
- 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.
当控制器在冗余模式下工作且活动控制器发生故障时，测量从活动控制器切换到备份控制器所需的时间，定义为从活动控制器停机开始到从新控制器在其南行接口接收到的第一条重新发现消息结束的间隔。
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. 节点按照实施的冗余模式（例如，主动备用）连接到控制器群集。
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. 当网络设备从测试流量生成器接收到所有新流量时，必须将其发送到控制器。
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. 关闭活动控制器。
4. Stop the trial when the first frame after the failover operation is received on test traffic generator TP2.
4. 当在测试流量生成器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)
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
- 群集节点数
- Redundancy mode
- 冗余模式
- Controller Failover Time
- 控制器故障切换时间
- 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节所述的试验装置之一。
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:
程序：
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. 关闭通信路径中的链路或交换机。
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)
Forward Direction Path Re-provisioning Time (FDRT)
= (TP2-Tffr - TP2-Tlfr)
Reverse Direction Path Re-provisioning Time (RDRT)
= (TP1-Tffr - TP1-Tlfr)
Reverse Direction Path Re-provisioning Time (RDRT)
= (TP1-Tffr - TP1-Tlfr)
Network Re-provisioning Time = (FDRT + RDRT)/2
Network Re-provisioning Time = (FDRT + RDRT)/2
Forward Direction Packet Loss = Number of missing sequence frames at test traffic generator TP1
前向分组丢失=测试业务生成器TP1处缺失的序列帧数
Reverse Direction Packet Loss = Number of missing sequence frames at test traffic generator TP2
反向分组丢失=测试流量生成器TP2处缺失序列帧的数量
Reporting Format:
报告格式：
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 alternate path
- 备用路径中的节点数
- 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 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.
控制器中不应存在专门用于基准测试的特殊功能。在实验室和生产网络中，控制器对网络安全的影响应相同。
[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.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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，“软件定义网络（SDN）控制器性能基准术语”，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规范]ONF，“OpenFlow交换机规范”版本1.4.0（有线协议0x05），2013年10月<https://www.opennetworking.org/wp-content/ 上传/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 southbound协议的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.
OpenFLUT[OpenFLASH SPEC]是开放式网络基础（ONF）定义的开放标准协议，用于通过集中控制器对网络交换机或路由器的转发平面进行编程。
The OpenFlow protocol supports three message types -- namely, controller-to-switch, asynchronous, and symmetric.
OpenFlow协议支持三种消息类型——即控制器到交换机、异步和对称。
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.).
控制器到交换机的消息由控制器启动，用于直接管理或检查交换机的状态。这些消息允许控制器查询/配置交换机（“功能”消息、配置消息）、从交换机收集信息（读取状态消息）、在交换机的指定端口上发送数据包（OFPT_PACKET_OUT消息），以及修改交换机转发平面和状态（修改状态消息、角色请求消息等）。
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_数据包_）的到达、交换机状态更改（“流已删除”消息、端口状态消息）和错误（错误消息）。
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).
对称消息在任一方向生成，无需请求。这些消息允许交换机和控制器设置连接（Hello消息）、验证活动性（回声消息）和提供附加功能（实验者消息）。
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>|
| | |
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.
当比较成功时，网络拓扑发现时间可通过计算从控制器（Tm1）接收到LLDP消息的第一个OFPT_数据包_OUT与发送到控制器（Tmn）的LLDP消息的最后一个OFPT_数据包_IN之间的时间差来获得。
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)> | |
| | |
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：消息R0中OFPT_数据包的发送时间戳，R1，…Rn：OFPT_数据包输出消息的接收时间戳Nrx：成功OFPT_数据包输入/OFPT_数据包输出消息交换的次数
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> | |
| | |
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。重复试验，直到连续两次试验的Nrxn等于（+/-P%）。
Discussion:
讨论：
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_数据包输出（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. 当丢失率等于零时，通过计算从控制器接收的最大PT_数据包输出，可获得无丢失异步消息处理速率。通过计算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)|<---------------------| |
| | | |
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：免费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)|<--------------| | |
| | | | |
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：免费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)| |
| |<-------------------| |
| | | |
| | | |
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:免费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)|<---------------| | |
| | | | |
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:免费ARP消息D1..Dn:目标端点1，目标端点2…，目标端点n S1..Sn:源端点1，源端点2…，源端点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>|
| | |
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:
讨论：
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发送端口_状态消息（T0）的时间与OpenFlow控制器向OpenFlow交换机发送第一个拓扑重新发现消息（T1）的时间之差，可以获得网络拓扑变化检测时间。
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|
| |
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.
开关（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> |
| | |
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拓扑：的网络拓扑：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>|
| | | |
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：免费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.
多次查询控制器的转发表条目，直到连续三次查询返回相同的值。从控制器检索的最后一个值将提供转发表容量值。查询间隔是用户可配置的。本例中所示的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)>|
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)>|
| | | | |
| | | | <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:OFPT_数据包_IN（Sa+1..Sn，Da+1..Dn）的免费ARP消息：OFPT_数据包_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%。当接收到1%的错误帧时，Rn1将提供控制器的路径配置率，当接收到2%的错误帧时，Rn2将提供控制器的路径配置率。
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)>|
| | | | |
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：免费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.
应从其中一个模拟/模拟OpenFlow交换机发起TCP SYN攻击。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<-----------------| |
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> |
| | | | |
| | |FLOW_MOD(Sn) | |
| | |<----------------------| |
| | | | |
| |Traffic (Sn,D1)| | |
| |<--------------| | |
| | | | |
| | | |<Stop the |
| | | |test after |
| | | |recv. traffic|
| | | |upon |
| | | |failure> |
Legend:
图例：
G-ARP: Gratuitous ARP message
G-ARP：免费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))| | |
| |<---------------| | |
| | | | |
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> |
| | | | |
| 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：免费ARP消息序列。否：序号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).
作者要感谢以下个人就本文件早期草稿提供了宝贵意见：Al Morton（AT&T）、Sandeep Gangadharan（HP）、M.Georgescu（NAIST）、Andrew McGregor（谷歌）、Scott Bradner、Jay Karthik（思科）、Ramki Krishnan（VMware）、Boris Khasanov（华为）和Brian Castelli（Spirent）。
Authors' Addresses
作者地址
Bhuvaneswaran Vengainathan Veryx Technologies Inc. 1 International Plaza, Suite 550 Philadelphia, PA 19113 United States of America
布瓦内斯瓦兰·文盖纳森·维克斯技术公司，美国宾夕法尼亚州费城国际广场1号550室，邮编：19113
Email: bhuvaneswaran.vengainathan@veryxtech.com
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号550室19113
Email: anton.basil@veryxtech.com
Email: anton.basil@veryxtech.com
Mark Tassinari Hewlett Packard Enterprise 8000 Foothills Blvd. Roseville, CA 95747 United States of America
马克·塔西纳里·惠普企业8000山麓大道。美国加利福尼亚州罗斯维尔95747
Email: mark.tassinari@hpe.com
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
Email: vishwas.manral@gmail.com
Sarah Banks VSS Monitoring 930 De Guigne Drive Sunnyvale, CA 94085 United States of America
美国加利福尼亚州桑尼维尔德吉涅大道930号，邮编94085
Email: sbanks@encrypted.net
Email: sbanks@encrypted.net