[要約] RFC 8455は、SDNコントローラのパフォーマンスをベンチマークするための用語を定義しています。このRFCの目的は、SDNコントローラのパフォーマンス評価を一貫性のある方法で行うための共通の用語を提供することです。
Internet Engineering Task Force (IETF) V. Bhuvaneswaran
Request for Comments: 8455 A. Basil
Category: Informational Veryx Technologies
ISSN: 2070-1721 M. Tassinari
Hewlett Packard Enterprise
V. Manral
NanoSec
S. Banks
VSS Monitoring
October 2018
Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
Software-Defined Networking（SDN）コントローラーのパフォーマンスをベンチマークするための用語
Abstract
概要
This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.
このドキュメントでは、ソフトウェア定義ネットワーク（SDN）コントローラーのコントロールプレーンのパフォーマンスをベンチマークするための用語を定義します。 SDNコントローラーのベンチマークを目的として、RFC 7426ですでに定義されている用語を拡張します。このドキュメントで提供されている用語は、コントローラーがサポートするプロトコルやネットワークサービスとは関係なく、SDNコントローラーのパフォーマンスのベンチマークに役立ちます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8455.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8455で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Term Definitions ................................................4
2.1. SDN Terms ..................................................4
2.1.1. Flow ................................................4
2.1.2. Northbound Interface ................................4
2.1.3. Southbound Interface ................................5
2.1.4. Controller Forwarding Table .........................5
2.1.5. Proactive Flow Provisioning Mode ....................5
2.1.6. Reactive Flow Provisioning Mode .....................6
2.1.7. Path ................................................6
2.1.8. Standalone Mode .....................................6
2.1.9. Cluster/Redundancy Mode .............................7
2.1.10. Asynchronous Message ...............................7
2.1.11. Test Traffic Generator .............................7
2.1.12. Leaf-Spine Topology ................................8
2.2. Test Configuration/Setup Terms .............................8
2.2.1. Number of Network Devices ...........................8
2.2.2. Trial Repetition ....................................8
2.2.3. Trial Duration ......................................9
2.2.4. Number of Cluster Nodes .............................9
2.3. Benchmarking Terms .........................................9
2.3.1. Performance .........................................9
2.3.1.1. Network Topology Discovery Time ............9
2.3.1.2. Asynchronous Message Processing Time ......10
2.3.1.3. Asynchronous Message Processing Rate ......10
2.3.1.4. Reactive Path Provisioning Time ...........11
2.3.1.5. Proactive Path Provisioning Time ..........12
2.3.1.6. Reactive Path Provisioning Rate ...........12
2.3.1.7. Proactive Path Provisioning Rate ..........13
2.3.1.8. Network Topology Change Detection Time ....13
2.3.2. Scalability ........................................14
2.3.2.1. Control Sessions Capacity .................14
2.3.2.2. Network Discovery Size ....................14
2.3.2.3. Forwarding Table Capacity .................15
2.3.3. Security ...........................................15
2.3.3.1. Exception Handling ........................15
2.3.3.2. Handling Denial-of-Service Attacks ........16
2.3.4. Reliability ........................................16
2.3.4.1. Controller Failover Time ..................16
2.3.4.2. Network Re-provisioning Time ..............17
3. Test Setup .....................................................17
3.1. Test Setup - Controller Operating in Standalone Mode ......18
3.2. Test Setup - Controller Operating in Cluster Mode .........19
4. Test Coverage ..................................................20
5. IANA Considerations ............................................21
6. Security Considerations ........................................21
7. Normative References ...........................................21
Acknowledgments ...................................................22
Authors' Addresses ................................................23
Software-Defined Networking (SDN) is a networking architecture in which network control is decoupled from the underlying forwarding function and is placed in a centralized location called the SDN Controller. The SDN Controller provides an abstraction of the underlying network and offers a global view of the overall network to applications and business logic. Thus, an SDN Controller provides the flexibility to program, control, and manage network behavior dynamically through northbound and southbound interfaces. Since the network controls are logically centralized, the need to benchmark the SDN Controller's performance becomes significant. This document defines terms to benchmark various controller designs for performance, scalability, reliability, and security, independently of northbound and southbound protocols. A mechanism for benchmarking the performance of SDN Controllers is defined in the companion methodology document [RFC8456]. These two documents provide methods for measuring and evaluating the performance of various controller implementations.
ソフトウェア定義ネットワーク（SDN）は、ネットワーク制御が基盤となる転送機能から切り離され、SDNコントローラーと呼ばれる集中管理された場所に配置されるネットワークアーキテクチャです。 SDNコントローラーは、基盤となるネットワークの抽象化を提供し、ネットワーク全体のグローバルなビューをアプリケーションとビジネスロジックに提供します。したがって、SDNコントローラーは、ノースバウンドおよびサウスバウンドインターフェイスを介してネットワーク動作を動的にプログラム、制御、および管理する柔軟性を提供します。ネットワーク制御は論理的に一元化されているため、SDNコントローラーのパフォーマンスをベンチマークする必要性が大きくなります。このドキュメントでは、ノースバウンドプロトコルとサウスバウンドプロトコルに関係なく、パフォーマンス、スケーラビリティ、信頼性、およびセキュリティのさまざまなコントローラー設計をベンチマークするための用語を定義します。 SDNコントローラーのパフォーマンスをベンチマークするメカニズムは、関連する方法論ドキュメント[RFC8456]で定義されています。これらの2つのドキュメントは、さまざまなコントローラー実装のパフォーマンスを測定および評価する方法を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The terms defined in this section are extensions to the terms defined in [RFC7426] ("Software-Defined Networking (SDN): Layers and Architecture Terminology"). Readers should refer to [RFC7426] before attempting to make use of this document.
このセクションで定義されている用語は、[RFC7426]で定義されている用語の拡張です（「ソフトウェア定義ネットワーク（SDN）：レイヤーとアーキテクチャの用語」）。読者は、このドキュメントを利用する前に[RFC7426]を参照する必要があります。
Definition: The definition of "flow" is the same as the definition of "microflows" provided in Section 3.1.5 of [RFC4689].
定義：「フロー」の定義は、[RFC4689]のセクション3.1.5で提供されている「マイクロフロー」の定義と同じです。
Discussion: A flow can be a set of packets having the same source address, destination address, source port, and destination port, or any combination of these items.
ディスカッション：フローは、同じ送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、またはこれらの項目の任意の組み合わせを持つパケットのセットにすることができます。
Measurement Units: N/A
測定単位：N / A
Definition: The definition of "northbound interface" is the same as the definition of "service interface" provided in [RFC7426].
定義：「ノースバウンドインターフェース」の定義は、[RFC7426]で提供される「サービスインターフェース」の定義と同じです。
Discussion: The northbound interface allows SDN applications and orchestration systems to program and retrieve the network information through the SDN Controller.
ディスカッション：ノースバウンドインターフェイスにより、SDNアプリケーションおよびオーケストレーションシステムは、SDNコントローラーを介してネットワーク情報をプログラムおよび取得できます。
Measurement Units: N/A
測定単位：N / A
Definition: The southbound interface is the application programming interface provided by the SDN Controller to interact with the SDN nodes.
定義：サウスバウンドインターフェイスは、SDNノードと対話するためにSDNコントローラーによって提供されるアプリケーションプログラミングインターフェイスです。
Discussion: The southbound interface enables the controller to interact with the SDN nodes in the network for dynamically defining the traffic forwarding behavior.
ディスカッション：サウスバウンドインターフェイスにより、コントローラーはネットワーク内のSDNノードと対話して、トラフィック転送動作を動的に定義できます。
Measurement Units: N/A
測定単位：N / A
Definition: A controller Forwarding Table contains flow entries learned in one of two ways: first, entries can be learned from traffic received through the data plane, or second, these entries can be statically provisioned on the controller and distributed to devices via the southbound interface.
定義：コントローラの転送テーブルには、2つの方法のいずれかで学習されたフローエントリが含まれています。1つ目は、データプレーンを介して受信したトラフィックからエントリを学習する方法、もう1つは、これらのエントリをコントローラに静的にプロビジョニングして、サウスバウンドインターフェイスを介してデバイスに配信する方法です。 。
Discussion: The controller Forwarding Table has an aging mechanism that will be applied only for dynamically learned entries.
ディスカッション：コントローラの転送テーブルには、動的に学習されたエントリにのみ適用されるエージングメカニズムがあります。
Measurement Units: N/A
測定単位：N / A
Definition: Controller programming flows in Network Devices based on the flow entries provisioned through the controller's northbound interface.
定義：コントローラのノースバウンドインターフェイスを介してプロビジョニングされたフローエントリに基づいて、ネットワークデバイスのコントローラプログラミングフロー。
Discussion: Network orchestration systems and SDN applications can define the network forwarding behavior by programming the controller, using Proactive Flow Provisioning. The controller can then program the Network Devices with the pre-provisioned entries.
ディスカッション：ネットワークオーケストレーションシステムとSDNアプリケーションは、プロアクティブフロープロビジョニングを使用してコントローラーをプログラミングすることにより、ネットワーク転送動作を定義できます。コントローラは、事前にプロビジョニングされたエントリを使用してネットワークデバイスをプログラムできます。
Measurement Units: N/A
測定単位：N / A
Definition: Controller programming flows in Network Devices based on the traffic received from Network Devices through the controller's southbound interface.
定義：コントローラのサウスバウンドインターフェイスを介してネットワークデバイスから受信したトラフィックに基づいて、ネットワークデバイスのコントローラプログラミングフロー。
Discussion: The SDN Controller dynamically decides the forwarding behavior based on the incoming traffic from the Network Devices. The controller then programs the Network Devices, using Reactive Flow Provisioning.
説明：SDNコントローラは、ネットワークデバイスからの着信トラフィックに基づいて、転送動作を動的に決定します。次に、コントローラーは、リアクティブフロープロビジョニングを使用してネットワークデバイスをプログラムします。
Measurement Units: N/A
測定単位：N / A
Definition: Refer to Section 5 in [RFC2330].
定義：[RFC2330]のセクション5を参照してください。
Discussion: None
ディスカッション：なし
Measurement Units: N/A
測定単位：N / A
Definition: A single controller handles all control-plane functionalities without redundancy, and it is unable to provide high availability and/or automatic failover.
定義：単一のコントローラーが冗長性なしにすべてのコントロールプレーン機能を処理し、高可用性や自動フェイルオーバーを提供できません。
Discussion: In standalone mode, one controller manages one or more network domains.
ディスカッション：スタンドアロンモードでは、1つのコントローラーが1つ以上のネットワークドメインを管理します。
Measurement Units: N/A
測定単位：N / A
Definition: In this mode, a group of two or more controllers handles all control-plane functionalities.
定義：このモードでは、2つ以上のコントローラーのグループがすべてのコントロールプレーン機能を処理します。
Discussion: In cluster mode, multiple controllers are teamed together for the purpose of load sharing and/or high availability. The controllers in the group may operate in active/standby (master/slave) or active/active (equal) mode, depending on the intended purpose.
ディスカッション：クラスターモードでは、負荷分散や高可用性を目的として、複数のコントローラーがチーム化されます。グループ内のコントローラーは、目的に応じて、アクティブ/スタンバイ（マスター/スレーブ）またはアクティブ/アクティブ（等しい）モードで動作します。
Measurement Units: N/A
測定単位：N / A
Definition: Any message from the Network Device that is generated for network events.
定義：ネットワークイベント用に生成されるネットワークデバイスからのメッセージ。
Discussion: Control messages like flow setup request and response messages are classified as asynchronous messages. The controller has to return a response message. Note that the Network Device will not be in blocking mode and continues to send/receive other control messages.
ディスカッション：フロー設定要求や応答メッセージなどの制御メッセージは、非同期メッセージとして分類されます。コントローラは応答メッセージを返す必要があります。ネットワークデバイスはブロッキングモードではなく、他の制御メッセージを送受信し続けることに注意してください。
Measurement Units: N/A
測定単位：N / A
Definition: The test traffic generator is an entity that generates/receives network traffic.
定義：テストトラフィックジェネレーターは、ネットワークトラフィックを生成/受信するエンティティです。
Discussion: The test traffic generator typically connects with Network Devices to send/receive real-time network traffic.
ディスカッション：通常、テストトラフィックジェネレーターはネットワークデバイスに接続して、リアルタイムのネットワークトラフィックを送受信します。
Measurement Units: N/A
測定単位：N / A
Definition: "Leaf-Spine" is a two-layered network topology, where a series of leaf switches that form the access layer are fully meshed to a series of spine switches that form the backbone layer.
定義：「リーフスパイン」は2層のネットワークトポロジであり、アクセスレイヤーを形成する一連のリーフスイッチが、バックボーンレイヤーを形成する一連のスパインスイッチに完全にメッシュ化されます。
Discussion: In the Leaf-Spine topology, every leaf switch is connected to each of the spine switches in the topology.
ディスカッション：リーフスパイントポロジでは、すべてのリーフスイッチがトポロジ内の各スパインスイッチに接続されます。
Measurement Units: N/A
測定単位：N / A
Definition: The number of Network Devices present in the defined test topology.
定義：定義されたテストトポロジに存在するネットワークデバイスの数。
Discussion: The Network Devices defined in the test topology can be deployed using real hardware or can be emulated in hardware platforms.
ディスカッション：テストトポロジで定義されたネットワークデバイスは、実際のハードウェアを使用して展開することも、ハードウェアプラットフォームでエミュレートすることもできます。
Measurement Units: Number of Network Devices.
測定単位：ネットワークデバイスの数。
Definition: The number of times the test needs to be repeated.
定義：テストを繰り返す必要がある回数。
Discussion: The test needs to be repeated for multiple iterations to obtain a reliable metric. It is recommended that this test SHOULD be performed for at least 10 iterations to increase confidence in the measured results.
ディスカッション：信頼できるメトリックを取得するには、テストを複数回繰り返す必要があります。測定結果の信頼性を高めるために、このテストは少なくとも10回の反復で実行することをお勧めします。
Measurement Units: Number of trials.
測定単位：試行回数。
Definition: Defines the duration of test trials for each iteration.
定義：各反復のテスト試行の期間を定義します。
Discussion: The Trial Duration forms the basis for "stop" criteria for benchmarking tests. Trials not completed within this time interval are considered incomplete.
ディスカッション：トライアル期間は、ベンチマークテストの「停止」基準の基礎を形成します。この期間内に完了しなかった試験は不完全と見なされます。
Measurement Units: Seconds.
測定単位：秒。
Definition: Defines the number of controllers present in the controller cluster.
定義：コントローラークラスターに存在するコントローラーの数を定義します。
Discussion: This parameter is relevant when testing the controller's performance in clustering/teaming mode. The number of nodes in the cluster MUST be greater than 1.
ディスカッション：このパラメーターは、クラスター化/チーミングモードでコントローラーのパフォーマンスをテストするときに関連します。クラスター内のノード数は1より大きくなければなりません。
Measurement Units: Number of controller nodes.
測定単位：コントローラーノードの数。
This section defines metrics for benchmarking the SDN Controller. The procedure for performing the defined metrics is defined in the companion methodology document [RFC8456].
このセクションでは、SDNコントローラーのベンチマークのメトリックを定義します。定義されたメトリックを実行する手順は、関連する方法論のドキュメント[RFC8456]で定義されています。
Definition: 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.
定義：完全なネットワークトポロジを決定するためにコントローラーによって費やされた時間。サウスバウンドインターフェイスでのコントローラーからの最初のディスカバリメッセージから始まり、決定された静的トポロジのすべての機能で終了する間隔として定義されます。
Discussion: Network topology discovery is key for the SDN Controller to provision and manage the network, so it is important to measure how quickly the controller discovers the topology to learn the current network state. This benchmark is obtained by presenting a network topology (tree, mesh, or linear) with a specified number of nodes to the controller and waiting for the discovery process to complete. It is expected that the controller supports a network discovery mechanism and uses protocol messages for its discovery process.
ディスカッション：ネットワークトポロジーの検出は、SDNコントローラーがネットワークをプロビジョニングおよび管理するための鍵となるため、コントローラーがトポロジーを検出する速度を測定して、現在のネットワーク状態を知ることが重要です。このベンチマークは、指定された数のノードを含むネットワークトポロジ（ツリー、メッシュ、または線形）をコントローラーに提示し、検出プロセスが完了するのを待機することで得られます。コントローラはネットワーク検出メカニズムをサポートし、その検出プロセスにプロトコルメッセージを使用することが期待されています。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: 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.
定義：コントローラーが非同期メッセージを処理するのにかかる時間。コントローラーがすべてのデバイスを検出した後、ネットワークデバイスからの非同期メッセージで始まり、応答メッセージで終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラ。
Discussion: For SDN to support dynamic network provisioning, it is important to measure how quickly the controller responds to an event triggered from the network. The event can be any notification messages generated by a Network Device upon arrival of a new flow, link down, etc. This benchmark is obtained by sending asynchronous messages from every connected Network Device one at a time for the defined Trial Duration. This test assumes that the controller will respond to the received asynchronous messages.
ディスカッション：SDNが動的ネットワークプロビジョニングをサポートするためには、コントローラーがネットワークからトリガーされたイベントに応答する速度を測定することが重要です。イベントは、新しいフローの到着、リンクダウンなどでネットワークデバイスによって生成された通知メッセージです。このベンチマークは、定義された試行期間の間、接続されているすべてのネットワークデバイスから非同期メッセージを一度に1つずつ送信することによって取得されます。このテストは、コントローラーが受信した非同期メッセージに応答することを前提としています。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: The number of responses to asynchronous messages per second (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.
定義：コントローラーが処理を実行し、有効で生産的な（重要ではない）応答メッセージで応答した、1秒あたりの非同期メッセージ（新しいフロー到着通知メッセージ、リンクダウンなど）への応答の数。
Discussion: As SDN assures a flexible network and agile provisioning, it is important to measure how many network events (a new flow arrival notification message, link down, etc.) the controller can handle at a time. This benchmark is measured by sending asynchronous messages from every connected Network Device at the rate that the controller processes (without dropping them). This test assumes that the controller responds to all the received asynchronous messages (the messages can be designed to elicit individual responses).
ディスカッション：SDNは柔軟なネットワークと俊敏なプロビジョニングを保証するため、コントローラーが一度に処理できるネットワークイベント（新しいフローの到着通知メッセージ、リンクダウンなど）の数を測定することが重要です。このベンチマークは、コントローラーが処理するレートで（ドロップせずに）接続されているすべてのネットワークデバイスから非同期メッセージを送信することで測定されます。このテストは、コントローラーが受信したすべての非同期メッセージに応答することを前提としています（メッセージは個別の応答を引き出すように設計できます）。
When sending asynchronous messages to the controller(s) at high rates, some messages or responses may be discarded or corrupted and require retransmission to controller(s). Therefore, a useful qualification on the Asynchronous Message Processing Rate is whether the incoming message count equals the response count in each trial. This is called the Loss-Free Asynchronous Message Processing Rate.
非同期メッセージをコントローラーに高速で送信すると、一部のメッセージまたは応答が破棄または破損し、コントローラーへの再送信が必要になる場合があります。したがって、非同期メッセージ処理率の有用な条件は、着信メッセージ数が各試行の応答数と等しいかどうかです。これは、ロスのない非同期メッセージ処理率と呼ばれます。
Note that several of the early controller benchmarking tools did not consider lost messages and instead report the maximum response rate. This is called the Maximum Asynchronous Message Processing Rate.
初期のコントローラベンチマークツールのいくつかは、失われたメッセージを考慮せず、代わりに最大応答率を報告したことに注意してください。これは、最大非同期メッセージ処理率と呼ばれます。
To characterize both the Loss-Free Asynchronous Message Processing Rate and the Maximum Asynchronous Message Processing Rate, a test can begin the first trial by sending asynchronous messages to the controller(s) at the maximum possible rate and can then record the message reply rate and the message loss rate. The message-sending rate is then decreased by the STEP size. The message reply rate and the message loss rate are recorded. The test ends with a trial where the controller(s) processes all of the asynchronous messages sent without loss. This is the Loss-Free Asynchronous Message Processing Rate.
Loss-Free Asynchronous Message Processing RateとMaximum Asynchronous Message Processing Rateの両方を特徴付けるために、テストは非同期メッセージをコントローラーに可能な最大のレートで送信することにより最初の試行を開始し、メッセージの返信レートとメッセージ損失率。メッセージの送信速度は、STEPサイズだけ減少します。メッセージの返信率とメッセージの損失率が記録されます。テストは、コントローラーが送信されたすべての非同期メッセージを失うことなく処理する試行で終了します。これは、ロスのない非同期メッセージ処理率です。
The trial where the controller(s) produced the maximum response rate is the Maximum Asynchronous Message Processing Rate. Of course, the first trial can begin at a low sending rate with zero lost responses and then increase the rate until the Loss-Free Asynchronous Message Processing Rate and the Maximum Asynchronous Message Processing Rate are discovered.
コントローラーが最大応答率を生成した試行は、最大非同期メッセージ処理率です。もちろん、最初の試行は、送信レートが低く、応答が失われないようにしてから、ロスのない非同期メッセージ処理レートと最大非同期メッセージ処理レートが見つかるまでレートを増やします。
Measurement Units: Messages processed per second.
測定単位：1秒あたりに処理されたメッセージ。
Definition: 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) and ending with the last flow provisioning response message sent from the controller(s) at its southbound interface.
定義：コントローラーがソースノードと宛先ノード間のパスをリアクティブにセットアップするのにかかる時間。コントローラーによって受信された最初のフロープロビジョニング要求メッセージで始まり、送信された最後のフロープロビジョニング応答メッセージで終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラ。
Discussion: As SDN supports agile provisioning, it is important to measure how fast the controller provisions an end-to-end flow in the data plane. The benchmark is obtained by sending traffic from a source endpoint to the destination endpoint and finding the time difference between the first and last flow provisioning message exchanged between the controller and the Network Devices for the traffic path.
ディスカッション：SDNはアジャイルプロビジョニングをサポートしているため、コントローラーがデータプレーンでエンドツーエンドフローをプロビジョニングする速度を測定することが重要です。ベンチマークは、ソースエンドポイントから宛先エンドポイントにトラフィックを送信し、トラフィックパスのコントローラーとネットワークデバイス間で交換される最初と最後のフロープロビジョニングメッセージ間の時間差を見つけることによって取得されます。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: The time taken by the controller to proactively set up a path 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 command message sent from the controller(s) at its southbound interface.
定義：コントローラーが送信元ノードと宛先ノード間のパスを事前にセットアップするのにかかる時間。ノースバウンドインターフェイスでコントローラーにプロビジョニングされた最初の事前対応フローで始まり、最後のフロープロビジョニングコマンドメッセージで終了する間隔として定義されます。サウスバウンドインターフェイスのコントローラから送信されます。
Discussion: For SDN to support pre-provisioning of the traffic path from the application, it is important to measure how fast the controller provisions an end-to-end flow in the data plane. The benchmark is obtained by provisioning a flow on the controller's northbound interface for the traffic to reach from a source to a destination endpoint and finding the time difference between the first and last flow provisioning message exchanged between the controller and the Network Devices for the traffic path.
ディスカッション：SDNがアプリケーションからのトラフィックパスの事前プロビジョニングをサポートするには、コントローラーがデータプレーンでエンドツーエンドフローをプロビジョニングする速度を測定することが重要です。ベンチマークは、トラフィックが送信元から宛先エンドポイントに到達するようにコントローラーのノースバウンドインターフェイスでフローをプロビジョニングし、コントローラーとネットワークデバイスの間でトラフィックパス用に交換される最初と最後のフロープロビジョニングメッセージ間の時間差を見つけることによって得られます。 。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: 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 trial and the expiry of the given Trial Duration.
定義：コントローラーがソースノードと宛先ノード間で1秒あたりに同時に反応的に確立できる独立パスの最大数。パスプロビジョニングのために受信されたフロープロビジョニングリクエストに対して、サウスバウンドインターフェイスでコントローラーによって1秒あたりにプロビジョニングされたパスの数として定義されます。トライアルの開始と指定されたトライアル期間の有効期限の間のサウスバウンドインターフェイス。
Discussion: For SDN to support agile traffic forwarding, it is important to measure how many end-to-end flows the controller can set up in the data plane. This benchmark is obtained by sending each traffic flow with unique source and destination pairs from the source Network Device and determining the number of frames received at the destination Network Device.
ディスカッション：SDNが俊敏なトラフィック転送をサポートするには、コントローラーがデータプレーンにセットアップできるエンドツーエンドフローの数を測定することが重要です。このベンチマークは、送信元ネットワークデバイスから一意の送信元と宛先のペアを使用して各トラフィックフローを送信し、宛先ネットワークデバイスで受信されるフレームの数を決定することによって得られます。
Measurement Units: Paths provisioned per second.
測定単位：1秒あたりにプロビジョニングされたパス。
Definition: 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 provisioned in its northbound interface between the start of the trial and the expiry of the given Trial Duration.
定義：コントローラーがソースノードと宛先ノードの間でプロアクティブに1秒あたりに同時に確立できる独立パスの最大数。ノースバウンドインターフェイスでプロビジョニングされたパスのサウスバウンドインターフェイスでコントローラーによって1秒あたりにプロビジョニングされたパスの数として定義されます。試用の開始と指定された試用期間の有効期限。
Discussion: For SDN to support pre-provisioning of the traffic path for a larger network from the application, it is important to measure how many end-to-end flows the controller can set up in the data plane. This benchmark is obtained by sending each traffic flow with unique source and destination pairs from the source Network Device. Program the flows on the controller's northbound interface for traffic to reach from each of the unique source and destination pairs, and determine the number of frames received at the destination Network Device.
ディスカッション：SDNがアプリケーションから大規模ネットワークのトラフィックパスの事前プロビジョニングをサポートするためには、コントローラーがデータプレーンにセットアップできるエンドツーエンドフローの数を測定することが重要です。このベンチマークは、送信元のネットワークデバイスから一意の送信元と宛先のペアを使用して各トラフィックフローを送信することによって取得されます。一意の送信元と宛先のペアのそれぞれからトラフィックが到達するように、コントローラーのノースバウンドインターフェイスのフローをプログラムし、宛先ネットワークデバイスで受信されるフレームの数を決定します。
Measurement Units: Paths provisioned per second.
測定単位：1秒あたりにプロビジョニングされたパス。
Definition: 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 messages sent from the controller(s) at its southbound interface.
定義：コントローラがネットワークトポロジの変更を検出するのにかかる時間。サウスバウンドインターフェイスでコントローラが受信した通知メッセージで始まり、から送信された最初のトポロジ再検出メッセージで終わる間隔として定義されます。サウスバウンドインターフェイスのコントローラ。
Discussion: In order for the controller to support fast network failure recovery, it is critical to measure how fast the controller is able to detect any network-state change events. This benchmark is obtained by triggering a topology change event and measuring the time the controller takes to detect and initiate a topology rediscovery process.
ディスカッション：コントローラーが高速ネットワーク障害リカバリーをサポートするためには、コントローラーがネットワーク状態変更イベントを検出できる速度を測定することが重要です。このベンチマークは、トポロジー変更イベントをトリガーし、コントローラーがトポロジー再検出プロセスを検出して開始するのにかかる時間を測定することによって取得されます。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: 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.
定義：コントローラーが維持できる制御セッションの最大数。コントローラーがネットワークデバイスから受け入れることができるセッションの数として定義され、最初の制御セッションから始まり、コントローラーがコントローラーで受け入れる最後の制御セッションで終わります。サウスバウンドインターフェイス。
Discussion: Measuring the controller's Control Sessions Capacity is important for determining the controller's system and bandwidth resource requirements. This benchmark is obtained by establishing a control session with the controller from each of the Network Devices until the controller fails. The number of sessions that were successfully established will provide the Control Sessions Capacity.
ディスカッション：コントローラーの制御セッション容量の測定は、コントローラーのシステムと帯域幅のリソース要件を決定するために重要です。このベンチマークは、コントローラーに障害が発生するまで、各ネットワークデバイスからコントローラーとの制御セッションを確立することによって取得されます。正常に確立されたセッションの数により、制御セッション容量が提供されます。
Measurement Units: Maximum number of control sessions.
測定単位：制御セッションの最大数。
Definition: The network size (number of nodes and links) 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 and links that the controller(s) can successfully discover.
定義：コントローラーが検出できるネットワークのサイズ（ノードとリンクの数）。コントローラーが検出できるネットワークのサイズとして定義され、ユーザーが検出のために提供するネットワークトポロジから始まり、番号で終了します。コントローラが正常に検出できるノードとリンクの数。
Discussion: Measuring the maximum network size that the controller can discover is key to optimal network planning. This benchmark is obtained by presenting an initial set of Network Devices for discovery to the controller. Based on the initial discovery, the number of Network Devices is increased or decreased to determine the maximum number of nodes and links that the controller can discover.
ディスカッション：コントローラーが検出できる最大ネットワークサイズを測定することは、最適なネットワーク計画の鍵となります。このベンチマークは、検出用のネットワークデバイスの初期セットをコントローラーに提示することで得られます。最初の検出に基づいて、ネットワークデバイスの数が増減され、コントローラーが検出できるノードとリンクの最大数が決定されます。
Measurement Units: Maximum number of network nodes and links.
測定単位：ネットワークノードとリンクの最大数。
Definition: The maximum number of flow entries that a controller can manage in its Forwarding Table.
定義：コントローラが転送テーブルで管理できるフローエントリの最大数。
Discussion: It is important to measure the capacity of a controller's Forwarding Table to determine the number of flows that the controller can forward without flooding or dropping any traffic. This benchmark is obtained by continuously presenting the controller with new flow entries through the Reactive Flow Provisioning mode or the Proactive Flow Provisioning mode until the Forwarding Table becomes full. The maximum number of nodes that the controller can hold in its Forwarding Table will provide the Forwarding Table Capacity.
ディスカッション：コントローラの転送テーブルの容量を測定して、トラフィックがフラッディングまたはドロップすることなくコントローラが転送できるフローの数を決定することが重要です。このベンチマークは、フォワーディングテーブルがいっぱいになるまで、リアクティブフロープロビジョニングモードまたはプロアクティブフロープロビジョニングモードを介して、コントローラーに新しいフローエントリを継続的に提示することによって取得されます。コントローラーが転送テーブルに保持できるノードの最大数は、転送テーブル容量を提供します。
Measurement Units: Maximum number of flow entries managed.
測定単位：管理されるフローエントリの最大数。
Definition: To determine the effect of handling error packets and notifications on performance tests.
定義：パフォーマンステストでのエラーパケットと通知の処理の影響を判断するため。
Discussion: This benchmark is to be performed after obtaining the baseline measurement results for the performance tests defined in Section 2.3.1. This benchmark determines the deviation from the baseline performance due to the handling of error or failure messages from the connected Network Devices.
考察：このベンチマークは、セクション2.3.1で定義されたパフォーマンステストのベースライン測定結果を取得した後に実行されます。このベンチマークは、接続されたネットワークデバイスからのエラーまたは障害メッセージの処理による、ベースラインパフォーマンスからの逸脱を決定します。
Measurement Units: Deviation from baseline metrics while handling Exceptions.
測定単位：例外の処理中のベースラインメトリックからの偏差。
Definition: To determine the effect of handling denial-of-service (DoS) attacks on performance and scalability tests.
定義：パフォーマンスおよびスケーラビリティテストに対するサービス拒否（DoS）攻撃の処理の影響を特定する。
Discussion: This benchmark is to be performed after obtaining the baseline measurement results for the performance and scalability tests defined in Sections 2.3.1 and 2.3.2. This benchmark determines the deviation from the baseline performance due to the handling of DoS attacks on the controller.
ディスカッション：このベンチマークは、セクション2.3.1および2.3.2で定義されたパフォーマンスおよびスケーラビリティテストのベースライン測定結果を取得した後に実行されます。このベンチマークは、コントローラーに対するDoS攻撃の処理によるベースラインパフォーマンスからの逸脱を決定します。
Measurement Units: Deviation from baseline metrics while handling DoS attacks.
測定単位：DoS攻撃の処理中のベースラインメトリックからの偏差。
Definition: The time taken to switch from an active controller to the backup controller when the controllers operate 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.
定義：コントローラーが冗長モードで動作し、アクティブコントローラーが故障したときに、アクティブコントローラーからバックアップコントローラーに切り替わるのにかかる時間。アクティブコントローラーがダウンしてから、最初の再検出メッセージで終了するまでの時間サウスバウンドインターフェイスの新しいコントローラ。
Discussion: This benchmark determines the impact of provisioning new flows when controllers are teamed together and the active controller fails.
ディスカッション：このベンチマークは、コントローラーがチーム化され、アクティブなコントローラーに障害が発生した場合の新しいフローのプロビジョニングの影響を決定します。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
Definition: 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.
定義：既存のトラフィックパスに障害が発生したときに、コントローラーがトラフィックを再ルーティングするのにかかる時間。コントローラーが受信した最初の障害通知メッセージで始まり、コントローラーが送信した最後のフロー再プロビジョニングメッセージで終わる間隔として定義されます。サウスバウンドインターフェイスで。
Discussion: This benchmark determines the controller's re-provisioning ability upon network failures and makes the following assumptions:
ディスカッション：このベンチマークは、ネットワーク障害時のコントローラーの再プロビジョニング機能を決定し、次の仮定を行います。
1. The network topology supports a redundant path between the source and destination endpoints.
1. ネットワークトポロジは、ソースエンドポイントと宛先エンドポイント間の冗長パスをサポートします。
2. The controller does not pre-provision the redundant path.
2. コントローラは冗長パスを事前プロビジョニングしません。
Measurement Units: Milliseconds.
測定単位：ミリ秒。
This section provides common reference topologies that are referred to in individual tests defined in the companion methodology document [RFC8456].
このセクションでは、関連する方法論のドキュメント[RFC8456]で定義されている個々のテストで参照される一般的なリファレンストポロジについて説明します。
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+-------------------------------+
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| |
| Device Under Test (DUT) |
+-------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+
Figure 1
図1
+-----------------------------------------------------------+
| Application-Plane Test Emulator |
| |
| +-----------------+ +-------------+ |
| | Application | | Service | |
| +-----------------+ +-------------+ |
| |
+-----------------------------+(I2)-------------------------+
|
| (Northbound Interface)
+---------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | SDN Controller 1 | <--E/W--> | SDN Controller n | |
| +------------------+ +------------------+ |
| |
| Device Under Test (DUT) |
+---------------------------------------------------------+
| (Southbound Interface)
|
+-----------------------------+(I1)-------------------------+
| |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ |
| / \ / \ |
| / \ / \ |
| l0 / X \ ln |
| / / \ \ |
| +-----------+ +-----------+ |
| | Network | | Network | |
| | Device 1 |..| Device n | |
| +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| |
| Forwarding-Plane Test Emulator |
+-----------------------------------------------------------+
Figure 2
図2
+-------------------------------------------------------------------+
| Lifecycle | Speed | Scalability | Reliability |
+------------+-------------------+---------------+------------------+
| | 1. Network |1. Network | |
| | Topology | Discovery | |
| | Discovery | Size | |
| | Time | | |
| | | | |
| | 2. Reactive Path | | |
| | Provisioning | | |
| | Time | | |
| | | | |
| | 3. Proactive Path | | |
| Setup | Provisioning | | |
| | Time | | |
| | | | |
| | 4. Reactive Path | | |
| | Provisioning | | |
| | Rate | | |
| | | | |
| | 5. Proactive Path | | |
| | Provisioning | | |
| | Rate | | |
| | | | |
+------------+-------------------+---------------+------------------+
| | 1. Maximum |1. Control |1. Network |
| | Asynchronous | Sessions | Topology |
| | Message | Capacity | Change |
| | Processing Rate| | Detection Time |
| | |2. Forwarding | |
| | 2. Loss-Free | Table |2. Exception |
| | Asynchronous | Capacity | Handling |
| | Message | | |
| Operational| Processing Rate| |3. Handling |
| | | | Denial-of- |
| | 3. Asynchronous | | Service Attacks|
| | Message | | |
| | Processing Time| |4. Network |
| | | | Re-provisioning|
| | | | Time |
| | | | |
+------------+-------------------+---------------+------------------+
| Teardown | | |1. Controller |
| | | | Failover Time |
+------------+-------------------+---------------+------------------+
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.
特別な機能は、特にベンチマークの目的でコントローラーに存在すべきではありません。コントローラから生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc -editor.org/info/rfc2330>。
[RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, October 2006, <https://www.rfc-editor.org/info/rfc4689>.
[RFC4689] Poretsky、S.、Perser、J.、Erramilli、S。、およびS. Khurana、「ネットワーク層トラフィック制御メカニズムのベンチマークに関する用語」、RFC 4689、DOI 10.17487 / RFC4689、2006年10月、<https：/ /www.rfc-editor.org/info/rfc4689>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[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>。
[RFC8456] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance", RFC 8456, DOI 10.17487/RFC8456, October 2018, <https://www.rfc-editor.org/info/rfc8456>.
[RFC8456] Bhuvaneswaran、V.、Basil、A.、Tassinari、M.、Manral、V。、およびS. Banks、「ソフトウェア定義ネットワーキング（SDN）コントローラーのパフォーマンスのベンチマーク手法」、RFC 8456、DOI 10.17487 / RFC8456 、2018年10月、<https://www.rfc-editor.org/info/rfc8456>。
Acknowledgments
謝辞
The authors would like to acknowledge Al Morton (AT&T) for his significant contributions to the earlier draft versions of this document. The authors would like to thank the following individuals for providing their valuable comments to the earlier draft versions of this document: Sandeep Gangadharan (HP), M. Georgescu (NAIST), Andrew McGregor (Google), Scott Bradner, Jay Karthik (Cisco), Ramki Krishnan (VMware), and Boris Khasanov (Huawei).
著者は、このドキュメントの以前のドラフトバージョンへの多大な貢献に対してAl Morton（AT＆T）を認めたいと思います。著者は、このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくれた次の人物に感謝します。SandeepGangadharan（HP）、M。Georgescu（NAIST）、Andrew McGregor（Google）、Scott Bradner、Jay Karthik（Cisco） 、Ramki Krishnan（VMware）、Boris Khasanov（Huawei）。
Authors' Addresses
著者のアドレス
Bhuvaneswaran Vengainathan Veryx Technologies Inc. 1 International Plaza, Suite 550 Philadelphia, PA 19113 United States of America
Bhuvaneswaran Vengainathan Veryx Technologies Inc. 1 International Plaza、Suite 550 Philadelphia、PA 19113アメリカ合衆国
Email: bhuvaneswaran.vengainathan@veryxtech.com
Anton Basil Veryx Technologies Inc. 1 International Plaza, Suite 550 Philadelphia, PA 19113 United States of America
Anton Basil Veryx Technologies Inc. 1 International Plaza、Suite 550 Philadelphia、PA 19113アメリカ合衆国
Email: anton.basil@veryxtech.com
Mark Tassinari Hewlett Packard Enterprise 8000 Foothills Blvd. Roseville, CA 95747 United States of America
Mark Tassinari Hewlett Packard Enterprise 8000 Foothills Blvd.ローズビル、カリフォルニア州95747アメリカ合衆国
Email: mark.tassinari@hpe.com
Vishwas Manral NanoSec Co 3350 Thomas Rd. Santa Clara, CA 95054 United States of America
3350トーマスパリーからビスワスミネラルナンスへ。 95054アメリカ合衆国、サンタクララ
Email: vishwas.manral@gmail.com
Sarah Banks VSS Monitoring 930 De Guigne Drive Sunnyvale, CA 94085 United States of America
サラバンクスVSSモニタリング930 De Guigne Driveサニーベール、カリフォルニア州94085アメリカ合衆国
Email: sbanks@encrypted.net