[要約] RFC 7502は、SIPデバイスのベンチマークテスト方法についてのガイドラインです。基本的なセッションのセットアップと登録に焦点を当てており、SIPデバイスの性能評価を目的としています。
Internet Engineering Task Force (IETF) C. Davids
Request for Comments: 7502 Illinois Institute of Technology
Category: Informational V. Gurbani
ISSN: 2070-1721 Bell Laboratories, Alcatel-Lucent
S. Poretsky
Allot Communications
April 2015
Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration
セッション開始プロトコル（SIP）デバイスのベンチマーク手法：基本的なセッションのセットアップと登録
Abstract
概要
This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.
このドキュメントでは、デバイスのセッション開始プロトコル（SIP）パフォーマンスをベンチマークする方法を提供します。 SIPデバイスのベンチマークに関連する用語は、関連する用語のドキュメント（RFC 7501）で説明されています。これら2つのドキュメントを使用して、SIPプロキシサーバー、レジストラー、セッションボーダーコントローラーなどのさまざまな種類のデバイスのベンチマークを取得して比較できます。この文脈での「パフォーマンス」という用語は、SIPメッセージを処理するための被試験デバイス（DUT）の容量を意味します。メディアストリームは、それらがシグナリング動作にどのように影響するかを調べるためにのみ使用されます。 2つのドキュメントの目的は、SIPデバイスの容量の客観的な比較を可能にする正規化された一連のテストを提供することです。 SIPは、パフォーマンスベンチマーク測定に影響を与える可能性のある幅広い構成と動作条件を許可するため、テストセットアップパラメーターと方法論が必要です。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7502.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7502で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Benchmarking Topologies . . . . . . . . . . . . . . . . . . . 5
4. Test Setup Parameters . . . . . . . . . . . . . . . . . . . . 7
4.1. Selection of SIP Transport Protocol . . . . . . . . . . . 7
4.2. Connection-Oriented Transport Management . . . . . . . . 7
4.3. Signaling Server . . . . . . . . . . . . . . . . . . . . 7
4.4. Associated Media . . . . . . . . . . . . . . . . . . . . 8
4.5. Selection of Associated Media Protocol . . . . . . . . . 8
4.6. Number of Associated Media Streams per SIP Session . . . 8
4.7. Codec Type . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Session Duration . . . . . . . . . . . . . . . . . . . . 8
4.9. Attempted Sessions per Second (sps) . . . . . . . . . . . 8
4.10. Benchmarking Algorithm . . . . . . . . . . . . . . . . . 9
5. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Test Setup Report . . . . . . . . . . . . . . . . . . . . 11
5.2. Device Benchmarks for Session Setup . . . . . . . . . . . 12
5.3. Device Benchmarks for Registrations . . . . . . . . . . . 12
6. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Baseline Session Establishment Rate of the Testbed . . . 13
6.2. Session Establishment Rate without Media . . . . . . . . 13
6.3. Session Establishment Rate with Media Not on DUT . . . . 13
6.4. Session Establishment Rate with Media on DUT . . . . . . 14
6.5. Session Establishment Rate with TLS-Encrypted SIP . . . . 14
6.6. Session Establishment Rate with IPsec-Encrypted SIP . . . 15
6.7. Registration Rate . . . . . . . . . . . . . . . . . . . . 15
6.8. Re-registration Rate . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. R Code Component to Simulate Benchmarking Algorithm 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in the Terminology document [RFC7501]. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Media streams, when used, are used only to study how they impact the signaling behavior. This document concentrates on benchmarking SIP session setup and SIP registrations only.
このドキュメントでは、用語ドキュメント[RFC7501]で説明されているように、セッション開始プロトコル（SIP）のパフォーマンスをベンチマークする方法について説明します。方法論と用語は、さまざまなシグナリングとメディア負荷でのシグナリングプレーンパフォーマンスのベンチマークに使用されます。メディアストリームは、使用される場合、シグナリング動作にどのように影響するかを調査するためにのみ使用されます。このドキュメントでは、SIPセッションのセットアップとSIP登録のみのベンチマークに焦点を当てています。
The Device Under Test (DUT) is a network intermediary that is RFC 3261 [RFC3261] capable and that plays the role of a registrar, redirect server, stateful proxy, a Session Border Controller (SBC) or a B2BUA. This document does not require the intermediary to assume the role of a stateless proxy. Benchmarks can be obtained and compared for different types of devices such as a SIP proxy server, Session Border Controllers (SBC), SIP registrars and a SIP proxy server paired with a media relay.
Device Under Test（DUT）は、RFC 3261 [RFC3261]対応のネットワーク仲介者であり、レジストラ、リダイレクトサーバー、ステートフルプロキシ、Session Border Controller（SBC）またはB2BUAの役割を果たします。このドキュメントでは、中間者がステートレスプロキシの役割を引き受ける必要はありません。ベンチマークを取得して、SIPプロキシサーバー、セッションボーダーコントローラー（SBC）、SIPレジストラー、メディアリレーとペアになったSIPプロキシサーバーなど、さまざまな種類のデバイスについて比較できます。
The test cases provide metrics for benchmarking the maximum 'SIP Registration Rate' and maximum 'SIP Session Establishment Rate' that the DUT can sustain over an extended period of time without failures (extended period of time is defined in the algorithm in Section 4.10). Some cases are included to cover encrypted SIP. The test topologies that can be used are described in the Test Setup section. Topologies in which the DUT handles media as well as those in which the DUT does not handle media are both considered. The measurement of the performance characteristics of the media itself is outside the scope of these documents.
テストケースは、DUTが障害なしに長期間にわたって維持できる最大の「SIP登録率」と最大の「SIPセッション確立率」をベンチマークするためのメトリックを提供します（延長期間はセクション4.10のアルゴリズムで定義されています）。暗号化されたSIPをカバーするいくつかのケースが含まれています。使用できるテストトポロジについては、「テストのセットアップ」セクションで説明しています。 DUTがメディアを処理するトポロジと、DUTがメディアを処理しないトポロジの両方が考慮されます。メディア自体のパフォーマンス特性の測定は、これらのドキュメントの範囲外です。
Benchmark metrics could possibly be impacted by Associated Media. The selected values for Session Duration and Media Streams per Session enable benchmark metrics to be benchmarked without Associated Media. Session Setup Rate could possibly be impacted by the selected value for Maximum Sessions Attempted. The benchmark for Session Establishment Rate is measured with a fixed value for maximum Session Attempts.
ベンチマーク指標は、関連メディアの影響を受ける可能性があります。セッション継続時間とセッションごとのメディアストリームの値を選択すると、関連メディアなしでベンチマーク指標をベンチマークできます。セッションセットアップレートは、[試行された最大セッション数]の選択された値によって影響を受ける可能性があります。セッション確立率のベンチマークは、最大セッション試行の固定値で測定されます。
Finally, the overall value of these tests is to serve as a comparison function between multiple SIP implementations. One way to use these tests is to derive benchmarks with SIP devices from Vendor-A, derive a new set of benchmarks with similar SIP devices from Vendor-B and perform a comparison on the results of Vendor-A and Vendor-B. This document does not make any claims on the interpretation of such results.
最後に、これらのテストの全体的な価値は、複数のSIP実装間の比較機能として機能することです。これらのテストを使用する1つの方法は、ベンダーAからSIPデバイスを使用してベンチマークを導出し、ベンダーBから類似のSIPデバイスを使用して新しいベンチマークセットを導出し、ベンダーAとベンダーBの結果を比較することです。このドキュメントでは、そのような結果の解釈については何も主張していません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, conforming to [RFC2119] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」 、および「OPTIONAL」は、[RFC2119]に準拠してBCP 14で説明されているように解釈され、準拠した実装の要件レベルを示します。
RFC 2119 defines the use of these key words to help make the intent of Standards Track documents as clear as possible. While this document uses these keywords, this document is not a Standards Track document.
RFC 2119は、これらのキーワードの使用を定義して、Standards Trackドキュメントの意図をできるだけ明確にするのに役立ちます。このドキュメントではこれらのキーワードを使用していますが、このドキュメントは標準化過程のドキュメントではありません。
Terms specific to SIP [RFC3261] performance benchmarking are defined in [RFC7501].
SIP [RFC3261]パフォーマンスベンチマークに固有の用語は、[RFC7501]で定義されています。
Test organizations need to be aware that these tests generate large volumes of data and consequently ensure that networking devices like hubs, switches, or routers are able to handle the generated volume.
テスト組織は、これらのテストが大量のデータを生成することを認識し、その結果、ハブ、スイッチ、ルーターなどのネットワークデバイスが生成されたボリュームを処理できることを確認する必要があります。
The test cases enumerated in Sections 6.1 to 6.6 operate on two test topologies: one in which the DUT does not process the media (Figure 1) and the other in which it does process media (Figure 2). In both cases, the tester or Emulated Agent (EA) sends traffic into the DUT and absorbs traffic from the DUT. The diagrams in Figures 1 and 2 represent the logical flow of information and do not dictate a particular physical arrangement of the entities.
セクション6.1から6.6で列挙したテストケースは、DUTがメディアを処理しない（図1）とDUTがメディアを処理する（図2）の2つのテストトポロジで動作します。どちらの場合も、テスターまたはエミュレートエージェント（EA）がトラフィックをDUTに送信し、DUTからのトラフィックを吸収します。図1および2の図は、情報の論理的な流れを表しており、エンティティの特定の物理的な配置を示しているわけではありません。
Figure 1 depicts a layout in which the DUT is an intermediary between the two interfaces of the EA. If the test case requires the exchange of media, the media does not flow through the DUT but rather passes directly between the two endpoints. Figure 2 shows the DUT as an intermediary between the two interfaces of the EA. If the test case requires the exchange of media, the media flows through the DUT between the endpoints.
図1は、DUTがEAの2つのインターフェース間の仲介者であるレイアウトを示しています。テストケースでメディアの交換が必要な場合、メディアはDUTを通過せず、2つのエンドポイント間を直接通過します。図2は、EAの2つのインターフェース間の仲介としてのDUTを示しています。テストケースでメディアの交換が必要な場合、メディアはエンドポイント間のDUTを通過します。
+--------+ Session +--------+ Session +--------+
| | Attempt | | Attempt | |
| |------------>+ |------------>+ |
| | | | | |
| | Response | | Response | |
| Tester +<------------| DUT +<------------| Tester |
| (EA) | | | | (EA) |
| | | | | |
+--------+ +--------+ +--------+
/|\ /|\
| Media (optional) |
+==============================================+
Figure 1: DUT as an Intermediary, End-to-End Media
図1：エンドツーエンドの中間媒体としてのDUT
+--------+ Session +--------+ Session +--------+
| | Attempt | | Attempt | |
| |------------>+ |------------>+ |
| | | | | |
| | Response | | Response | |
| Tester +<------------| DUT +<------------| Tester |
| (EA) | | | | (EA) |
| |<===========>| |<===========>| |
+--------+ Media +--------+ Media +--------+
(Optional) (Optional)
Figure 2: DUT as an Intermediary Forwarding Media
図2：中間転送メディアとしてのDUT
The test cases enumerated in Sections 6.7 and 6.8 use the topology in Figure 3 below.
セクション6.7および6.8で列挙したテストケースは、以下の図3のトポロジを使用します。
+--------+ Registration +--------+
| | request | |
| |------------->+ |
| | | |
| | Response | |
| Tester +<-------------| DUT |
| (EA) | | |
| | | |
+--------+ +--------+
Figure 3: Registration and Re-registration Tests
図3：登録および再登録テスト
During registration or re-registration, the DUT may involve backend network elements and data stores. These network elements and data stores are not shown in Figure 3, but it is understood that they will impact the time required for the DUT to generate a response.
登録または再登録中に、DUTにはバックエンドネットワーク要素とデータストアが含まれる場合があります。これらのネットワーク要素とデータストアは図3には示されていませんが、DUTが応答を生成するのに必要な時間に影響を与えることが理解されています。
This document explicitly separates a registration test (Section 6.7) from a re-registration test (Section 6.8) because in certain networks, the time to re-register may vary from the time to perform an initial registration due to the backend processing involved. It is expected that the registration tests and the re-registration test will be performed with the same set of backend network elements in order to derive a stable metric.
このドキュメントでは、特定のネットワークでは、バックエンドの処理が原因で、再登録にかかる時間が初期登録を実行する時間と異なる場合があるため、登録テスト（6.7）と再登録テスト（6.8）を明確に区別しています。安定したメトリックを導き出すために、登録テストと再登録テストは同じバックエンドネットワーク要素のセットで実行されることが予想されます。
Test cases may be performed with any transport protocol supported by SIP. This includes, but is not limited to, TCP, UDP, TLS, and websockets. The protocol used for the SIP transport protocol must be reported with benchmarking results.
テストケースは、SIPでサポートされているトランスポートプロトコルを使用して実行できます。これには、TCP、UDP、TLS、およびWebSocketが含まれますが、これらに限定されません。 SIPトランスポートプロトコルに使用されるプロトコルは、ベンチマーク結果とともに報告する必要があります。
SIP allows a DUT to use different transports for signaling on either side of the connection to the EAs. Therefore, this document assumes that the same transport is used on both sides of the connection; if this is not the case in any of the tests, the transport on each side of the connection MUST be reported in the test-reporting template.
SIPにより、DUTはEAへの接続のいずれかの側でシグナリングに異なるトランスポートを使用できます。したがって、このドキュメントでは、接続の両側で同じトランスポートが使用されることを前提としています。これがいずれのテストにも当てはまらない場合は、接続の両側のトランスポートをテストレポートテンプレートでレポートする必要があります。
SIP allows a device to open one connection and send multiple requests over the same connection (responses are normally received over the same connection that the request was sent out on). The protocol also allows a device to open a new connection for each individual request. A connection management strategy will have an impact on the results obtained from the test cases, especially for connection-oriented transports such as TLS. For such transports, the cryptographic handshake must occur every time a connection is opened.
SIPにより、デバイスは1つの接続を開き、同じ接続を介して複数の要求を送信できます（応答は通常、要求が送信されたのと同じ接続を介して受信されます）。このプロトコルにより、デバイスは個々の要求ごとに新しい接続を開くこともできます。接続管理戦略は、特にTLSなどの接続指向のトランスポートの場合、テストケースから得られる結果に影響を与えます。このようなトランスポートでは、接続が開かれるたびに暗号化ハンドシェイクが発生する必要があります。
The connection management strategy, i.e., use of one connection to send all requests or closing an existing connection and opening a new connection to send each request, MUST be reported with the benchmarking result.
接続管理戦略、つまり、1つの接続を使用してすべての要求を送信するか、既存の接続を閉じて新しい接続を開いて各要求を送信することは、ベンチマーク結果とともに報告する必要があります。
The Signaling Server is defined in the companion terminology document ([RFC7501], Section 3.2.2). The Signaling Server is a DUT.
シグナリングサーバーは、関連用語のドキュメント（[RFC7501]、セクション3.2.2）で定義されています。シグナリングサーバーはDUTです。
Some tests require Associated Media to be present for each SIP session. The test topologies to be used when benchmarking DUT performance for Associated Media are shown in Figure 1 and Figure 2.
一部のテストでは、SIPセッションごとに関連メディアが存在する必要があります。関連メディアのDUTパフォーマンスをベンチマークするときに使用されるテストトポロジを図1と図2に示します。
The test cases specified in this document provide SIP performance independent of the protocol used for the media stream. Any media protocol supported by SIP may be used. This includes, but is not limited to, RTP and SRTP. The protocol used for Associated Media MUST be reported with benchmarking results.
このドキュメントで指定されているテストケースは、メディアストリームに使用されるプロトコルに依存しないSIPパフォーマンスを提供します。 SIPでサポートされている任意のメディアプロトコルを使用できます。これには、RTPおよびSRTPが含まれますが、これらに限定されません。関連メディアに使用されるプロトコルは、ベンチマーク結果とともに報告されなければなりません。
Benchmarking results may vary with the number of media streams per SIP session. When benchmarking a DUT for voice, a single media stream is used. When benchmarking a DUT for voice and video, two media streams are used. The number of Associated Media Streams MUST be reported with benchmarking results.
ベンチマークの結果は、SIPセッションあたりのメディアストリームの数によって異なる場合があります。 DUTを音声用にベンチマークする場合、単一のメディアストリームが使用されます。音声とビデオのDUTをベンチマークする場合、2つのメディアストリームが使用されます。関連メディアストリームの数は、ベンチマーク結果とともに報告する必要があります。
The test cases specified in this document provide SIP performance independent of the media stream codec. Any codec supported by the EAs may be used. The codec used for Associated Media MUST be reported with the benchmarking results.
このドキュメントで指定されているテストケースは、メディアストリームコーデックに依存しないSIPパフォーマンスを提供します。 EAでサポートされている任意のコーデックを使用できます。 Associated Mediaに使用されるコーデックは、ベンチマーク結果とともに報告する必要があります。
The value of the DUT's performance benchmarks may vary with the duration of SIP sessions. Session Duration MUST be reported with benchmarking results. A Session Duration of zero seconds indicates transmission of a BYE immediately following a successful SIP establishment. Setting this parameter to the value '0' indicates that a BYE will be sent by the EA immediately after the EA receives a 200 OK to the INVITE. Setting this parameter to a time value greater than the duration of the test indicates that a BYE will never be sent. Setting this parameter to a time value greater than the duration of the test indicates that a BYE is never sent.
DUTのパフォーマンスベンチマークの値は、SIPセッションの継続時間によって異なる場合があります。セッション継続時間は、ベンチマーク結果とともに報告する必要があります。 0秒のセッション期間は、SIP確立が成功した直後にBYEが送信されることを示します。このパラメーターを値「0」に設定すると、EAがINVITEに対して200 OKを受信した直後にBYEがEAによって送信されます。このパラメーターをテスト期間よりも長い時間値に設定すると、BYEが送信されなくなります。このパラメーターをテスト期間よりも長い時間値に設定すると、BYEが送信されないことを示します。
The value of the DUT's performance benchmarks may vary with the Session Attempt Rate offered by the tester. Session Attempt Rate MUST be reported with the benchmarking results.
DUTのパフォーマンスベンチマークの値は、テスターが提供するセッション試行率によって異なる場合があります。セッション試行率は、ベンチマーク結果とともに報告する必要があります。
The test cases enumerated in Sections 6.1 to 6.6 require that the EA is configured to send the final 2xx-class response as quickly as it can. This document does not require the tester to add any delay between receiving a request and generating a final response.
セクション6.1〜6.6に列挙されているテストケースでは、EAが最終的な2xxクラスの応答をできるだけ早く送信するように構成されている必要があります。このドキュメントでは、要求を受信してから最終応答を生成するまでの間に遅延を追加する必要はありません。
In order to benchmark the test cases uniformly in Section 6, the algorithm described in this section should be used. A prosaic description of the algorithm and a pseudocode description are provided below, and a simulation written in the R statistical language [Rtool] is provided in Appendix A.
セクション6でテストケースのベンチマークを均一に行うには、このセクションで説明するアルゴリズムを使用する必要があります。アルゴリズムの平凡な説明と疑似コードの説明を以下に示し、R統計言語[Rtool]で記述されたシミュレーションを付録Aに示します。
The goal is to find the largest value, R, a SIP Session Attempt Rate, measured in sessions per second (sps), which the DUT can process with zero errors over a defined, extended period. This period is defined as the amount of time needed to attempt N SIP sessions, where N is a parameter of test, at the attempt rate, R. An iterative process is used to find this rate. The algorithm corresponding to this process converges to R.
目標は、1秒あたりのセッション数（sps）で測定されたSIPセッション試行率である最大値Rを見つけることです。これは、DUTが定義された長期間にわたってゼロエラーで処理できます。この期間は、N SIPセッションを試行するのに必要な時間として定義されます。ここで、Nは試行レートRでテストのパラメーターです。反復プロセスを使用してこのレートを見つけます。このプロセスに対応するアルゴリズムはRに収束します。
If the DUT vendor provides a value for R, the tester can use this value. In cases where the DUT vendor does not provide a value for R, or where the tester wants to establish the R of a system using local media characteristics, the algorithm should be run by setting "r", the session attempt rate, equal to a value of the tester's choice. For example, the tester may initialize "r = 100" to start the algorithm and observe the value at convergence. The algorithm dynamically increases and decreases "r" as it converges to the maximum sps value for R. The dynamic increase and decrease rate is controlled by the weights "w" and "d", respectively.
DUTベンダーがRの値を提供する場合、テスターはこの値を使用できます。 DUTベンダーがRの値を提供しない場合、またはテスターがローカルメディアの特性を使用してシステムのRを確立したい場合は、セッション試行率「r」をaに設定してアルゴリズムを実行する必要があります。テスターの選択の価値。たとえば、テスターは「r = 100」を初期化してアルゴリズムを開始し、収束時に値を観察します。アルゴリズムは、Rの最大sps値に収束するときに「r」を動的に増減します。動的な増減率は、それぞれ重み「w」と「d」によって制御されます。
The pseudocode corresponding to the description above follows, and a simulation written in the R statistical language is provided in Appendix A.
上記の説明に対応する疑似コードが続き、R統計言語で書かれたシミュレーションが付録Aに提供されています。
; ---- Parameters of test; adjust as needed
N := 50000 ; Global maximum; once largest session rate has
; been established, send this many requests before
; calling the test a success
m := {...} ; Other attributes that affect testing, such
; as media streams, etc.
r := 100 ; Initial session attempt rate (in sessions/sec).
; Adjust as needed (for example, if DUT can handle
; thousands of calls in steady state, set to
; appropriate value in the thousands).
w := 0.10 ; Traffic increase weight (0 < w <= 1.0)
d := max(0.10, w / 2) ; Traffic decrease weight
; ---- End of parameters of test
proc find_R
proc find_R
R = max_sps(r, m, N) ; Setup r sps, each with m media
; characteristics until N sessions have been attempted.
; Note that if a DUT vendor provides this number, the tester
; can use the number as a Session Attempt Rate, R, instead
; of invoking max_sps()
end proc
エンドプロシージャ
; Iterative process to figure out the largest number of
; sps that we can achieve in order to setup n sessions.
; This function converges to R, the Session Attempt Rate.
proc max_sps(r, m, n)
s := 0 ; session setup rate
old_r := 0 ; old session setup rate
h := 0 ; Return value, R
count := 0
; Note that if w is small (say, 0.10) and r is small
; (say, <= 9), the algorithm will not converge since it
; uses floor() to increment r dynamically. It is best
; to start with the defaults (w = 0.10 and r >= 100).
while (TRUE) {
s := send_traffic(r, m, n) ; Send r sps, with m media
; characteristics until n sessions have been attempted.
if (s == n) {
if (r > old_r) {
old_r = r
}
else {
count = count + 1
if (count >= 10) {
# We've converged.
h := max(r, old_r)
break
}
}
r := floor(r + (w * r))
}
else {
r := floor(r - (d * r))
d := max(0.10, d / 2)
w := max(0.10, w / 2)
}
} return h end proc
} h end procを返す
SIP Transport Protocol = ___________________________
(valid values: TCP|UDP|TLS|SCTP|websockets|specify-other)
(Specify if same transport used for connections to the DUT
and connections from the DUT. If different transports
used on each connection, enumerate the transports used.)
Connection management strategy for connection oriented
transports
DUT receives requests on one connection = _______
(Yes or no. If no, DUT accepts a new connection for
every incoming request, sends a response on that
connection, and closes the connection.)
DUT sends requests on one connection = __________
(Yes or no. If no, DUT initiates a new connection to
send out each request, gets a response on that
connection, and closes the connection.)
Session Attempt Rate _______________________________
(Session attempts/sec)
(The initial value for "r" in benchmarking algorithm in
Section 4.10.)
Session Duration = _________________________________
(In seconds)
Total Sessions Attempted = _________________________
(Total sessions to be created over duration of test)
Media Streams per Session = _______________________
(number of streams per session)
Associated Media Protocol = _______________________
(RTP|SRTP|specify-other)
Codec = ____________________________________________
(Codec type as identified by the organization that
specifies the codec)
Media Packet Size (audio only) = __________________
(Number of bytes in an audio packet)
Establishment Threshold time = ____________________
(Seconds)
TLS ciphersuite used
(for tests involving TLS) = ________________________
(e.g., TLS_RSA_WITH_AES_128_CBC_SHA)
IPsec profile used
(For tests involving IPsec) = _____________________
Session Establishment Rate, "R" = __________________
(sessions per second)
Is DUT acting as a media relay? (yes/no) = _________
Registration Rate = ____________________________
(registrations per second)
Re-registration Rate = ____________________________
(registrations per second)
Notes = ____________________________________________
(List any specific backend processing required or
other parameters that may impact the rate)
Objective: To benchmark the Session Establishment Rate of the Emulated Agent (EA) with zero failures.
目的：失敗なしのエミュレートエージェント（EA）のセッション確立率をベンチマークすること。
Procedure: 1. Configure the DUT in the test topology shown in Figure 1. 2. Set Media Streams per Session to 0. 3. Execute benchmarking algorithm as defined in Section 4.10 to get the baseline Session Establishment Rate. This rate MUST be recorded using any pertinent parameters as shown in the reporting format of Section 5.1.
手順：1.図1に示すテストトポロジでDUTを構成します。2.セッションあたりのメディアストリームを0に設定します。3.セクション4.10で定義されているようにベンチマークアルゴリズムを実行して、ベースラインセッション確立レートを取得します。このレートは、セクション5.1のレポート形式に示されているように、適切なパラメーターを使用して記録する必要があります。
Expected Results: This is the scenario to obtain the maximum Session Establishment Rate of the EA and the testbed when no DUT is present. The results of this test might be used to normalize test results performed on different testbeds or simply to better understand the impact of the DUT on the testbed in question.
期待される結果：これは、DUTが存在しない場合に、EAとテストベッドの最大セッション確立レートを取得するシナリオです。このテストの結果は、さまざまなテストベッドで実行されたテスト結果を正規化するため、または問題のテストベッドに対するDUTの影響をよりよく理解するために使用できます。
Objective: To benchmark the Session Establishment Rate of the DUT with no Associated Media and zero failures.
目的：関連するメディアがなく、障害が発生していないDUTのセッション確立率をベンチマークすること。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 1 or Figure 2. 2. Set Media Streams per Session to 0. 3. Execute benchmarking algorithm as defined in Section 4.10 to get the Session Establishment Rate. This rate MUST be recorded using any pertinent parameters as shown in the reporting format of Section 5.1.
手順：1.図1または図2に示すテストトポロジに従ってDUTを構成します。2.セッションあたりのメディアストリームを0に設定します。3.セクション4.10で定義されているようにベンチマークアルゴリズムを実行して、セッション確立レートを取得します。このレートは、セクション5.1のレポート形式に示されているように、適切なパラメーターを使用して記録する必要があります。
Expected Results: Find the Session Establishment Rate of the DUT when the EA is not sending media streams.
期待される結果：EAがメディアストリームを送信していないときに、DUTのセッション確立レートを見つける。
Objective: To benchmark the Session Establishment Rate of the DUT with zero failures when Associated Media is included in the benchmark test but the media is not running through the DUT.
目的：関連付けられたメディアがベンチマークテストに含まれているが、メディアがDUTを介して実行されていない場合に、失敗なしでDUTのセッション確立率をベンチマークすること。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 1. 2. Set Media Streams per Session to 1. 3. Execute benchmarking algorithm as defined in Section 4.10 to get the session establishment rate with media. This rate MUST be recorded using any pertinent parameters as shown in the reporting format of Section 5.1.
手順：1.図1に示すテストトポロジに従ってDUTを構成します。2.セッションあたりのメディアストリームを1に設定します。3.セクション4.10で定義されているベンチマークアルゴリズムを実行して、メディアとのセッション確立率を取得します。このレートは、セクション5.1のレポート形式に示されているように、適切なパラメーターを使用して記録する必要があります。
Expected Results: Session Establishment Rate results obtained with Associated Media with any number of media streams per SIP session are expected to be identical to the Session Establishment Rate results obtained without media in the case where the DUT is running on a platform separate from the Media Relay.
期待される結果：SIPセッションごとに任意の数のメディアストリームを伴う関連メディアで取得されたセッション確立レートの結果は、DUTがメディアリレーとは別のプラットフォームで実行されている場合、メディアなしで取得されたセッション確立レートの結果と同じであると予想されます。 。
Objective: To benchmark the Session Establishment Rate of the DUT with zero failures when Associated Media is included in the benchmark test and the media is running through the DUT.
目的：関連付けられたメディアがベンチマークテストに含まれ、メディアがDUTを介して実行されている場合に、失敗なしでDUTのセッション確立率をベンチマークすること。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 2. 2. Set Media Streams per Session to 1. 3. Execute benchmarking algorithm as defined in Section 4.10 to get the Session Establishment Rate with media. This rate MUST be recorded using any pertinent parameters as shown in the reporting format of Section 5.1.
手順：1.図2に示すテストトポロジに従ってDUTを構成します。2.セッションあたりのメディアストリームを1に設定します。このレートは、セクション5.1のレポート形式に示されているように、適切なパラメーターを使用して記録する必要があります。
Expected Results: Session Establishment Rate results obtained with Associated Media may be lower than those obtained without media in the case where the DUT and the Media Relay are running on the same platform. It may be helpful for the tester to be aware of the reasons for this degradation, although these reasons are not parameters of the test. For example, the degree of performance degradation may be due to what the DUT does with the media (e.g., relaying vs. transcoding), the type of media (audio vs. video vs. data), and the codec used for the media. There may also be cases where there is no performance impact, if the DUT has dedicated media-path hardware.
期待される結果：DUTとメディアリレーが同じプラットフォームで実行されている場合、関連付けられたメディアで取得されたセッション確立率の結果は、メディアなしで取得された結果よりも低くなる可能性があります。これらの理由はテストのパラメーターではありませんが、テスターがこの低下の理由を知っていると役立つ場合があります。たとえば、パフォーマンスの低下の程度は、DUTがメディアをどのように処理するか（リレーとトランスコーディングの違いなど）、メディアの種類（オーディオとビデオとデータのどちらか）、およびメディアに使用されるコーデックが原因である可能性があります。 DUTに専用のメディアパスハードウェアがある場合、パフォーマンスに影響がない場合もあります。
Objective: To benchmark the Session Establishment Rate of the DUT with zero failures when using TLS-encrypted SIP signaling.
目的：TLSで暗号化されたSIPシグナリングを使用するときに、DUTのセッション確立率を失敗なしでベンチマークすること。
Procedure: 1. If the DUT is being benchmarked as a proxy or B2BUA, then configure the DUT in the test topology shown in Figure 1 or Figure 2. 2. Configure the tester to enable TLS over the transport being used during benchmarking. Note the ciphersuite being used for TLS and record it in Section 5.1. 3. Set Media Streams per Session to 0 (media is not used in this test). 4. Execute benchmarking algorithm as defined in Section 4.10 to get the Session Establishment Rate with TLS encryption.
手順：1. DUTがプロキシまたはB2BUAとしてベンチマークされている場合は、図1または図2に示すテストトポロジでDUTを構成します。2.ベンチマーク中に使用されるトランスポート上でTLSを有効にするようにテスターを構成します。 TLSに使用されている暗号スイートをメモし、セクション5.1に記録します。 3.セッションあたりのメディアストリームを0に設定します（このテストではメディアは使用されません）。 4.セクション4.10で定義されているベンチマークアルゴリズムを実行して、TLS暗号化によるセッション確立率を取得します。
Expected Results: Session Establishment Rate results obtained with TLS-encrypted SIP may be lower than those obtained with plaintext SIP.
期待される結果：TLS暗号化SIPで取得されたセッション確立率の結果は、プレーンテキストSIPで取得された結果よりも低い場合があります。
Objective: To benchmark the Session Establishment Rate of the DUT with zero failures when using IPsec-encrypted SIP signaling.
目的：IPsecで暗号化されたSIPシグナリングを使用する場合に、障害のないDUTのセッション確立レートをベンチマークすること。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 1 or Figure 2. 2. Set Media Streams per Session to 0 (media is not used in this test). 3. Configure tester for IPsec. Note the IPsec profile being used for IPsec and record it in Section 5.1. 4. Execute benchmarking algorithm as defined in Section 4.10 to get the Session Establishment Rate with encryption.
手順：1.図1または図2に示すテストトポロジに従ってDUTを構成します。2.セッションあたりのメディアストリームを0に設定します（このテストではメディアは使用されません）。 3. IPsec用にテスターを構成します。 IPsecに使用されているIPsecプロファイルに注意して、セクション5.1に記録します。 4.セクション4.10で定義されているベンチマークアルゴリズムを実行して、暗号化されたセッション確立レートを取得します。
Expected Results: Session Establishment Rate results obtained with IPsec-encrypted SIP may be lower than those obtained with plaintext SIP.
期待される結果：IPsec暗号化SIPで取得されたセッション確立率の結果は、プレーンテキストSIPで取得された結果よりも低くなる可能性があります。
Objective: To benchmark the maximum registration rate the DUT can handle over an extended time period with zero failures.
目的：DUTが障害なしで長期間にわたって処理できる最大登録率をベンチマークする。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 3. 2. Set the registration timeout value to at least 3600 seconds. 3. Each register request MUST be made to a distinct Address of Record (AoR). Execute benchmarking algorithm as defined in
手順：1.図3に示すテストトポロジに従ってDUTを構成します。2.登録タイムアウト値を少なくとも3600秒に設定します。 3.各登録要求は、別個のレコードアドレス（AoR）に対して行う必要があります。で定義されているベンチマークアルゴリズムを実行する
Section 4.10 to get the maximum registration rate. This rate MUST be recorded using any pertinent parameters as shown in the reporting format of Section 5.1. For example, the use of TLS or IPsec during registration must be noted in the reporting format. In the same vein, any specific backend processing (use of databases, authentication servers, etc.) SHOULD be recorded as well.
最大登録レートを取得するには、セクション4.10。このレートは、セクション5.1のレポート形式に示されているように、適切なパラメーターを使用して記録する必要があります。たとえば、登録時のTLSまたはIPsecの使用は、レポート形式で注記する必要があります。同様に、特定のバックエンド処理（データベース、認証サーバーなどの使用）も記録する必要があります。
Expected Results: Provides a maximum registration rate.
期待される結果：最大登録率を提供します。
Objective: To benchmark the re-registration rate of the DUT with zero failures using the same backend processing and parameters used during Section 6.7.
目的：セクション6.7で使用したのと同じバックエンド処理とパラメーターを使用して、障害がゼロのDUTの再登録率をベンチマークすること。
Procedure: 1. Configure a DUT according to the test topology shown in Figure 3. 2. Execute the test detailed in Section 6.7 to register the endpoints with the registrar and obtain the registration rate. 3. After at least 5 minutes of performing Step 2, but no more than 10 minutes after Step 2 has been performed, re-register the same AoRs used in Step 3 of Section 6.7. This will count as a re-registration because the SIP AoRs have not yet expired.
手順：1.図3に示すテストトポロジに従ってDUTを構成します。2.セクション6.7で詳述されているテストを実行して、エンドポイントをレジストラに登録し、登録レートを取得します。 3.ステップ2を実行してから少なくとも5分後、ステップ2を実行してから10分以内に、セクション6.7のステップ3で使用したものと同じAoRを再登録します。 SIP AoRの有効期限がまだ切れていないため、これは再登録としてカウントされます。
Expected Results: Note the rate obtained through this test for comparison with the rate obtained in Section 6.7.
期待される結果：セクション6.7で得られた速度と比較するために、このテストで得られた速度に注意してください。
Documents of this type do not directly affect the security of the Internet or corporate networks as long as benchmarking is not performed on devices or systems connected to production networks. Security threats and how to counter these in SIP and the media layer is discussed in RFC 3261, RFC 3550, and RFC 3711, and various other documents. This document attempts to formalize a set of common methodology for benchmarking performance of SIP devices in a lab environment.
このタイプのドキュメントは、実稼働ネットワークに接続されたデバイスまたはシステムでベンチマークが実行されない限り、インターネットまたは企業ネットワークのセキュリティに直接影響しません。セキュリティの脅威と、SIPおよびメディアレイヤーでこれらに対抗する方法は、RFC 3261、RFC 3550、RFC 3711、およびその他のさまざまなドキュメントで説明されています。このドキュメントでは、ラボ環境でSIPデバイスのパフォーマンスをベンチマークするための一連の一般的な方法論を形式化しようとしています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC7501] Davids, C., Gurbani, V., and S. Poretsky, "Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration", RFC 7501, April 2015, <http://www.rfc-editor.org/info/rfc7501>.
[RFC7501] Davids、C.、Gurbani、V。、およびS. Poretsky、「Benchmarking Session Initiation Protocol（SIP）Devices：Basic Session Setup and Registration」、RFC 7501、2015年4月、<http：// www。 rfc-editor.org/info/rfc7501>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[Rtool] R Development Core Team, "R: A Language and Environment for Statistical Computing", R Foundation for Statistical Computing Vienna, Austria, ISBN 3-900051-07-0, 2011, <http://www.R-project.org>.
[Rtool] R開発コアチーム、「R：統計計算のための言語と環境」、R Statistical Computingウィーン、オーストリア、ISBN 3-900051-07-0、2011、<http：//www.R-project .org>。
# Copyright (c) 2015 IETF Trust and the persons identified as # authors of the code. All rights reserved. # # Redistribution and use in source and binary forms, with or # without modification, are permitted provided that the following # conditions are met: # # The author of this code is Vijay K. Gurbani. # # - Redistributions of source code must retain the above copyright # notice, this list of conditions and # the following disclaimer. # # - Redistributions in binary form must reproduce the above # copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials # provided with the distribution. # # - Neither the name of Internet Society, IETF or IETF Trust, # nor the names of specific contributors, may be used to # endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND # CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, # INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE # DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE # GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, # WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH # DAMAGE.
＃Copyright（c）2015 IETF Trustおよび＃コードの作成者として識別された人物。全著作権所有。 ＃＃ソースとバイナリ形式での再配布と使用は、以下の条件が満たされている場合に限り、＃変更ありまたはなしで許可されます。＃＃このコードの作成者はVijay K. Gurbaniです。 ＃＃-ソースコードの再配布には、上記の著作権表示、この条件のリスト、および＃次の免責事項を保持する必要があります。 ＃＃-バイナリ形式での再配布は、上記の著作権表示、この条件のリスト、および次の免責事項を＃配布物とともに提供されるドキュメントおよび/またはその他の資料に複製する必要があります。 ＃＃-特定の事前の書面による許可なしに、インターネットソサエティ、IETFまたはIETFトラストの名前、または特定の貢献者の名前も、＃このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。 ＃＃このソフトウェアは、著作権者および＃提供者が「現状のまま」提供するものであり、＃明示的または黙示的な保証は一切含まれませんが、＃商品性および特定の目的に対する適合性の黙示の保証を含みます。いかなる場合も、著作権者または＃寄稿者は、直接的、間接的、偶発的、特別、例示的、または結果的な損害＃（代替＃商品またはサービスの購入を含みますが、これらに限定されません。 、または利益、または事業＃中断）責任の理論上、契約、厳格責任、または不法行為（＃過失またはその他を含む）のいずれかで発生したものであるかどうかにかかわらず、このいずれかを使用した場合このような＃損傷の可能性についてアドバイスしました。
w = 0.10
d = max(0.10, w / 2)
DUT_max_sps = 460 # Change as needed to set the max sps value
# for a DUT
# Returns R, given r (initial session attempt rate).
# E.g., assume that a DUT handles 460 sps in steady state
# and you have saved this code in a file simulate.r. Then,
# start an R session and do the following:
#
# > source("simulate.r")
# > find_R(100)
# ... debug output omitted ...
# [1] 458
#
# Thus, the max sps that the DUT can handle is 458 sps, which is
# close to the absolute maximum of 460 sps the DUT is specified to
# do.
find_R <- function(r) {
s = 0
old_r = 0
h = 0
count = 0
# Note that if w is small (say, 0.10) and r is small # (say, <= 9), the algorithm will not converge since it # uses floor() to increment r dynamically. It is best # to start with the defaults (w = 0.10 and r >= 100).
＃wが小さく（たとえば、0.10）、rが小さい（たとえば、<= 9）場合、floor()を使用してrを動的にインクリメントするため、アルゴリズムは収束しません。 ＃デフォルト（w = 0.10およびr> = 100）から始めるのが最適です。
cat("r old_r w d \n")
while (TRUE) {
cat(r, ' ', old_r, ' ', w, ' ', d, '\n')
s = send_traffic(r)
if (s == TRUE) { # All sessions succeeded
if (r > old_r) {
old_r = r
}
else {
count = count + 1
if (count >= 10) {
# We've converged.
h = max(r, old_r)
break
}
}
r = floor(r + (w * r))
}
else {
r = floor(r - (d * r))
d = max(0.10, d / 2)
w = max(0.10, w / 2)
}
}
h }
h}
send_traffic <- function(r) {
n = TRUE
if (r > DUT_max_sps) {
n = FALSE
}
n }
ん ｝
Acknowledgments
謝辞
The authors would like to thank Keith Drage and Daryl Malas for their contributions to this document. Dale Worley provided an extensive review that led to improvements in the documents. We are grateful to Barry Constantine, William Cerveny, and Robert Sparks for providing valuable comments during the documents' last calls and expert reviews. Al Morton and Sarah Banks have been exemplary working group chairs; we thank them for tracking this work to completion. Tom Taylor provided an in-depth review and subsequent comments on the benchmarking convergence algorithm in Section 4.10.
著者は、この文書への貢献に対して、Keith DrageとDaryl Malasに感謝します。 Dale Worleyは、ドキュメントの改善につながる広範なレビューを提供しました。ドキュメントの最後の電話と専門家によるレビュー中に貴重なコメントを提供してくれたバリーコンスタンティン、ウィリアムサーヴェニー、ロバートスパークスに感謝します。アルモートンとサラバンクは、模範的なワーキンググループの議長を務めてきました。この作業を完了まで追跡してくださったことに感謝します。 Tom Taylorは、セクション4.10でベンチマークの収束アルゴリズムに関する詳細なレビューとその後のコメントを提供しました。
Authors' Addresses
著者のアドレス
Carol Davids Illinois Institute of Technology 201 East Loop Road Wheaton, IL 60187 United States
Carol Davidsイリノイ工科大学201 East Loop Road Wheaton、IL 60187アメリカ合衆国
Phone: +1 630 682 6024
EMail: davids@iit.edu
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville, IL 60566 United States
Vijay K.Gurbani Bell Laboratories、Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville、IL 60566 United States
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com
Scott Poretsky Allot Communications 300 TradeCenter, Suite 4680 Woburn, MA 08101 United States
Scott Poretsky Allot Communications 300 TradeCenter、Suite 4680 Woburn、MA 08101アメリカ合衆国
Phone: +1 508 309 2179
EMail: sporetsky@allot.com