RFC 7497 - Rate Measurement Test Protocol Problem Statement and Requirements 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7497
タイトル : RFC 7497 - レート測定テストプロトコルの問題ステートメントと要件
翻訳編集 : 自動生成

[要約] 要約： RFC 7497は、ネットワークのレート測定テストプロトコルの問題と要件について説明しています。目的：このRFCの目的は、ネットワークのレート測定テストに関連する問題を特定し、それに対する要件を定義することです。

Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 7497                                     AT&T Labs
Category: Informational                                       April 2015
ISSN: 2070-1721

Rate Measurement Test Protocol Problem Statement and Requirements

レート測定テストプロトコルの問題ステートメントと要件

Abstract

概要

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

このメモは、IPパフォーマンスメトリック（IPPM）を測定するためのテストプロトコルのアクセスレート測定に関する問題ステートメントを示しています。キーレート測定テストプロトコルの側面には、非対称レートや非対称パケットサイズなど、テストするパス上のパケット特性を制御する機能が含まれます。

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/rfc7497.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7497で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Active Rate Measurement . . . . . . . . . . . . . . . . . . .   6
   4.  Measurement Method Categories . . . . . . . . . . . . . . . .   7
   5.  Test Protocol Control and Generation Requirements . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction

1. はじめに

There are many possible rate measurement scenarios. This memo describes one rate measurement problem and presents a rate measurement problem statement for test protocols to measure IP Performance Metrics (IPPM).

多くの可能なレート測定シナリオがあります。このメモは、1つのレート測定問題について説明し、IPパフォーマンスメトリック（IPPM）を測定するためのテストプロトコルのレート測定問題ステートメントを提示します。

When selecting a form of access to the Internet, subscribers are interested in the performance characteristics of the various alternatives. Standardized measurements can be a basis for comparison between these alternatives. There is an underlying need to coordinate measurements that support such comparisons and to test control protocols to fulfill this need. The figure below depicts some typical measurement points of access networks.

インターネットへのアクセスの形式を選択するとき、加入者はさまざまな選択肢のパフォーマンス特性に関心があります。標準化された測定は、これらの代替案を比較するための基礎となります。このような比較をサポートする測定を調整し、このニーズを満たすために制御プロトコルをテストする根本的なニーズがあります。次の図は、アクセスネットワークのいくつかの典型的な測定ポイントを示しています。

   User     /====== Fiber =======  Access Node \
   Device -|------ Copper -------  Access Node -|-- Infrastructure -- GW
   or Host  \------ Radio -------  Access Node /

                               GW = Gateway

The access rate scenario or use case has received widespread attention of Internet-access subscribers and seemingly all Internet-industry players, including regulators. This problem is being approached with many different measurement methods. The eventual protocol solutions to this problem (and the systems that utilize the protocol) may not directly involve users, such as when tests reach from the infrastructure to a service-specific device, such as a residential gateway. However, no aspect of the problem precludes users from developing a test protocol controlled via command line interfaces on both ends. Thus, a very wide range of test protocols, active measurement methods, and system solutions are the possible outcomes of this problem statement.

アクセス率のシナリオまたはユースケースは、インターネットアクセスサブスクライバーと、規制当局を含むすべてのインターネット業界のプレーヤーから広く注目されています。この問題は、さまざまな測定方法で対処されています。この問題の最終的なプロトコルソリューション（およびプロトコルを利用するシステム）は、テストがインフラストラクチャから住宅用ゲートウェイなどのサービス固有のデバイスに到達する場合など、ユーザーに直接関与しない場合があります。ただし、問題のいかなる側面も、ユーザーが両端のコマンドラインインターフェイスを介して制御されるテストプロトコルを開発することを妨げるものではありません。したがって、非常に広範囲のテストプロトコル、アクティブな測定方法、およびシステムソリューションが、この問題ステートメントの考えられる結果です。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Purpose and Scope

2. 目的と範囲

The scope and purpose of this memo is to define the measurement problem statement for test protocols conducting access rate measurement on production networks. Relevant test protocols include [RFC4656] and [RFC5357], but the problem is stated in a general way so that it can be addressed by any existing test protocol, such as [RFC6812].

このメモの範囲と目的は、本番ネットワークでアクセスレート測定を行うテストプロトコルの測定問題ステートメントを定義することです。関連するテストプロトコルには[RFC4656]と[RFC5357]が含まれますが、問題は[RFC6812]などの既存のテストプロトコルで対処できるように一般的な方法で記述されています。

This memo discusses possible measurement methods but does not specify exact methods that would normally be part of the solution.

このメモでは、可能な測定方法について説明しますが、通常はソリューションの一部となる正確な方法を指定していません。

We are interested in access measurement scenarios with the following characteristics:

次の特性を持つアクセス測定シナリオに関心があります。

o The access portion of the network is the focus of this problem statement. The user typically subscribes to a service with bidirectional access partly described by rates in bits per second. The rates may be expressed as raw capacity or restricted capacity, as described in [RFC6703]. These are the quantities that must be measured according to one or more standard metrics and for which measurement methods must also be agreed on as a part of the solution.

o ネットワークのアクセス部分は、この問題ステートメントの焦点です。ユーザーは通常、ビット/秒のレートで部分的に記述された双方向アクセスを備えたサービスにサブスクライブします。レートは、[RFC6703]で説明されているように、未加工容量または制限容量として表すことができます。これらは、1つ以上の標準メトリックに従って測定する必要があり、測定方法もソリューションの一部として合意する必要がある数量です。

o Referring to the reference path illustrated below and defined in [RFC7398], possible measurement points include a subscriber's host, the access service demarcation point, intra IP access (where a globally routable address is present), or the gateway between the measured access network and other networks.

o 以下に示され、[RFC7398]で定義されている参照パスを参照すると、可能な測定ポイントには、加入者のホスト、アクセスサービス境界ポイント、IP内アクセス（グローバルにルーティング可能なアドレスが存在する場合）、または測定されたアクセスネットワークと他のネットワーク。

   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW

GRA = Globally Routable Address, GW = Gateway

GRA =グローバルにルーティング可能なアドレス、GW =ゲートウェイ

o Rates at some links near the edge of the provider's network can often be several orders of magnitude less than link rates in the aggregation and core portions of the network.

o プロバイダーのネットワークのエッジに近い一部のリンクでのレートは、多くの場合、ネットワークのアグリゲーションおよびコア部分のリンクレートよりも数桁低い場合があります。

o Asymmetrical access rates on ingress and egress are prevalent.

o 入力と出力の非対称アクセスレートが一般的です。

o In many scenarios of interest, services of extremely large-scale access require low-complexity devices participating at the user end of the path, and those devices place limits on clock and control timing accuracy.

o 対象となる多くのシナリオでは、非常に大規模なアクセスのサービスには、パスのユーザー側に参加する複雑性の低いデバイスが必要であり、それらのデバイスはクロックと制御タイミングの精度に制限を課します。

This problem statement assumes that the most likely bottleneck device or link is adjacent to the remote (user-end) measurement device or is within one or two router/switch hops of the remote measurement device.

この問題ステートメントは、最も可能性の高いボトルネックデバイスまたはリンクがリモート（ユーザーエンド）測定デバイスに隣接しているか、リモート測定デバイスの1つまたは2つのルーター/スイッチホップ内にあると想定しています。

Other use cases for rate measurement involve situations where the packet switching and transport facilities are leased by one operator from another, and the link capacity available cannot be directly determined (e.g., from device-interface utilization). These scenarios could include mobile backhaul, Ethernet service access networks, and/or extensions of layer 2 or layer 3 networks. The results of rate measurements in such cases could be employed to select alternate routing, investigate whether capacity meets some previous agreement, and/or adapt the rate of traffic sources if a capacity bottleneck is found via the rate measurement. In the case of aggregated leased networks, available capacity may also be asymmetric. In these cases, the tester is assumed to have a sender and receiver location under their control. We refer to this scenario below as the aggregated leased-network case.

レート測定の他の使用例には、パケット交換およびトランスポート機能が1つのオペレーターから別のオペレーターにリースされており、使用可能なリンク容量を直接決定できない場合があります（たとえば、デバイスインターフェイスの使用率から）。これらのシナリオには、モバイルバックホール、イーサネットサービスアクセスネットワーク、レイヤー2またはレイヤー3ネットワークの拡張などが含まれます。このような場合のレート測定の結果は、代替ルーティングの選択、容量が以前の合意を満たすかどうかの調査、および/またはレート測定を介して容量ボトルネックが見つかった場合のトラフィックソースのレートの調整に使用できます。集約された専用ネットワークの場合、利用可能な容量も非対称になることがあります。これらの場合、テスターは送信者と受信者の場所を制御下にあると想定されます。以下では、このシナリオを集約された専用ネットワークのケースと呼びます。

This memo describes protocol support for active measurement methods consistent with the IPPM working group's traditional charter. Active measurements require synthetic traffic streams dedicated to testing and do not make measurements on user traffic. See Section 2 of [RFC2679], where the concept of a stream is first introduced in IPPM literature as the basis for collecting a sample (defined in Section 11 of [RFC2330]).

このメモは、IPPMワーキンググループの従来の憲章と一致するアクティブな測定方法のプロトコルサポートについて説明しています。アクティブ測定には、テスト専用の合成トラフィックストリームが必要であり、ユーザートラフィックの測定は行いません。 [RFC2679]のセクション2を参照してください。サンプルを収集するための基礎として、ストリームの概念がIPPM文献で最初に紹介されています（[RFC2330]のセクション11で定義）。

As noted in [RFC2330], the focus of access traffic management may influence the rate measurement results for some forms of access, as it may differ between user and test traffic if the test traffic has different characteristics, primarily in terms of the packets themselves (see Section 13 of [RFC2330] for the considerations on packet type, or Type-P).

[RFC2330]に記載されているように、テストトラフィックが主にパケット自体の点で異なる特性を持っている場合、ユーザーとテストトラフィックで異なる場合があるため、アクセストラフィック管理の焦点は、一部の形式のアクセスのレート測定結果に影響を与える可能性があります（パケットタイプ、またはType-Pに関する考慮事項については、[RFC2330]のセクション13をご覧ください）。

There are several aspects of Type-P where user traffic may be examined and selected for special treatment that may affect transmission rates. Various aspects of Type-P are known to influence Equal-Cost Multipath (ECMP) routing with possible rate measurement variability across parallel paths. Without being exhaustive, the possibilities include:

Type-Pには、ユーザートラフィックを検査して、伝送速度に影響を与える可能性のある特別な処理のために選択できるいくつかの側面があります。 Type-Pのさまざまな側面が、等コストマルチパス（ECMP）ルーティングに影響を与え、パラレルパス全体でレート測定値が変動する可能性があることが知られています。網羅的でなくても、可能性は次のとおりです。

o Packet length

o パケット長

o IP addresses

o IPアドレス

o Transport protocol (e.g., where TCP packets may be routed differently from UDP)

o トランスポートプロトコル（TCPパケットがUDPとは異なる方法でルーティングされる場合など）

o Transport-protocol port numbers

o トランスポートプロトコルのポート番号

This issue requires further discussion when specific solutions/ methods of measurement are proposed; for this problem statement, it is sufficient to identify the problem and indicate that the solution may require an extremely close emulation of user traffic, in terms of one or more factors above.

この問題は、特定の解決策/測定方法が提案された場合、さらなる議論を必要とします。この問題の説明では、問題を特定し、上記の1つ以上の要素に関して、ソリューションがユーザートラフィックの非常に厳密なエミュレーションを必要とする可能性があることを示すだけで十分です。

Although the user may have multiple instances of network access available to them, the primary problem scope is to measure one form of access at a time. It is plausible that a solution for the single access problem will be applicable to simultaneous measurement of multiple access instances, but treatment of this scenario is beyond the current scope this document.

ユーザーはネットワークアクセスの複数のインスタンスを利用できる場合がありますが、主な問題の範囲は、一度に1つの形式のアクセスを測定することです。単一アクセスの問題の解決策が複数のアクセスインスタンスの同時測定に適用できる可能性はありますが、このシナリオの扱いは、このドキュメントの現在の範囲を超えています。

A key consideration is whether or not active measurements will be conducted with user traffic present. In-Service testing takes place with user traffic present. Out-of-Service testing occurs during pre-service assessment or during maintenance that interrupts service temporarily. Out-of-Service testing includes activities described as "service commissioning", "service activation", and "planned maintenance". Opportunistic In-Service testing (when there is no user traffic present throughout the test interval, such as outside normal business hours) is essentially equivalent to Out-of-Service testing. Both In-Service and Out-of-Service testing are within the scope of this problem.

重要な考慮事項は、ユーザートラフィックが存在する状態でアクティブな測定を行うかどうかです。インサービステストは、ユーザートラフィックが存在する状態で行われます。アウトオブサービステストは、サービス前の評価中またはメンテナンス中に一時的にサービスを中断します。アウトオブサービスのテストには、「サービスの試運転」、「サービスのアクティブ化」、「計画的なメンテナンス」などのアクティビティが含まれます。 Opportunistic In-Serviceテスト（通常の営業時間外など、テスト間隔全体にわたってユーザートラフィックが存在しない場合）は、本質的にOut-of-Serviceテストと同等です。インサービスとアウトオブサービスの両方のテストは、この問題の範囲内です。

It is a non-goal to solve the measurement protocol specification problem in this memo.

このメモの測定プロトコル仕様の問題を解決することは目的ではありません。

It is a non-goal to standardize methods of measurement in this memo. However, the problem statement mandates support for one category of rate measurement methods in the test protocol and adequate control features for the methods in the control protocol (assuming the control and test protocols are separate).

このメモで測定方法を標準化することは目的ではありません。ただし、問題の説明では、テストプロトコルのレート測定方法の1つのカテゴリのサポートと、制御プロトコルのメソッドに適切な制御機能（制御プロトコルとテストプロトコルが別々であると想定）のサポートが義務付けられています。

3. Active Rate Measurement

3. アクティブレート測定

This section lists features of active measurement methods needed to measure access rates in production networks.

このセクションでは、実稼働ネットワークのアクセス率を測定するために必要なアクティブな測定方法の機能をリストします。

Coordination between source and destination devices through control messages and other basic capabilities described in the methods of IPPM RFCs [RFC2679] [RFC2680], and assumed for test protocols such as [RFC5357] and [RFC4656], are taken as given.

IPPM RFC [RFC2679] [RFC2680]のメソッドで説明され、[RFC5357]や[RFC4656]などのテストプロトコルで想定されている、制御メッセージおよびその他の基本機能による送信元デバイスと宛先デバイス間の調整は、指定されたとおりに行われます。

Most forms of active testing intrude on user performance to some degree, especially In-Service testing. One key tenet of IPPM methods is to minimize test traffic effects on user traffic in the production network. Section 5 of [RFC2680] lists the problems with high measurement traffic rates ("too much" traffic); the most relevant for rate measurement is the tendency for measurement traffic to skew the results, followed by the possibility of introducing congestion on the access link. Section 4 of [RFC3148] provides additional considerations. The user of protocols for In-Service testing MUST respect these traffic constraints. Obviously, categories of rate measurement methods that use less active test traffic than others with similar accuracy are preferred for In-Service testing, and the specifications of this memo encourage traffic reduction through asymmetric control capabilities.

ほとんどの形式のアクティブなテスト、特にインサービステストは、ある程度ユーザーパフォーマンスに影響します。 IPPMメソッドの1つの重要な原則は、運用ネットワークのユーザートラフィックに対するテストトラフィックの影響を最小限に抑えることです。 [RFC2680]のセクション5には、測定トラフィックレートが高い（「トラフィックが多すぎる」）場合の問題がリストされています。レート測定に最も関連するのは、測定トラフィックが結果を歪める傾向であり、続いてアクセスリンクに輻輳が発生する可能性があります。 [RFC3148]のセクション4は、追加の考慮事項を提供します。インサービステストのプロトコルのユーザーは、これらのトラフィックの制約を尊重する必要があります。明らかに、同様の精度を持つ他のものよりもアクティブでないテストトラフィックを使用するレート測定方法のカテゴリは、インサービステストに推奨され、このメモの仕様は、非対称制御機能によるトラフィック削減を促進します。

Out-of-Service tests where the test path shares no links with In-Service user traffic, have none of the congestion or skew concerns. Both types should address practical matters common to all test efforts, such as conducting measurements within a reasonable time from the tester's point of view and ensuring that timestamp accuracy is consistent with the precision needed for measurement [RFC2330]. Out-of-Service tests where some part of the test path is shared with In-Service traffic MUST respect the In-Service constraints described above.

テストパスがインサービスのユーザートラフィックとリンクを共有しないアウトオブサービステストでは、輻輳やスキューの懸念はありません。どちらのタイプも、テスターの観点から妥当な時間内に測定を行い、タイムスタンプの精度が測定に必要な精度と一致することを保証するなど、すべてのテスト作業に共通する実際的な問題に対処する必要があります[RFC2330]。テストパスの一部がインサービストラフィックと共有されるアウトオブサービステストは、上記のインサービス制約を遵守する必要があります。

The intended metrics to be measured have strong influence over the categories of measurement methods required. For example, using the terminology of [RFC5136], it may be possible to measure a path capacity metric while In-Service if the level of background (user) traffic can be assessed and included in the reported result.

測定する予定のメトリックは、必要な測定方法のカテゴリに強い影響を与えます。たとえば、[RFC5136]の用語を使用すると、バックグラウンド（ユーザー）トラフィックのレベルを評価してレポート結果に含めることができれば、インサービス中にパス容量メトリックを測定できる可能性があります。

The measurement architecture MAY be either of one-way (e.g., [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity aspects of end-user or aggregated access measurement clearly favor two-way (with a low-complexity user-end device and round-trip results collection, as found in [RFC5357]). However, the asymmetric rates of many access services mean that the measurement system MUST be able to evaluate performance in each direction of transmission. In the two- way architecture, both end devices MUST include the ability to launch test streams and collect the results of measurements in both (one-way) directions of transmission (this requirement is consistent with previous protocol specifications, and it is not a unique problem for rate measurements).

測定アーキテクチャは一方向（例：[RFC4656]）または双方向（例：[RFC5357]）のいずれかですが、エンドユーザーまたは集約されたアクセス測定の規模と複雑さの側面は明らかに双方向（ [RFC5357]にあるように、複雑度の低いユーザーエンドデバイスとラウンドトリップの結果コレクション。ただし、多くのアクセスサービスの非対称レートは、測定システムが各送信方向のパフォーマンスを評価できなければならないことを意味します。双方向アーキテクチャでは、両方のエンドデバイスに、テストストリームを起動し、送信の両方向（一方向）の測定結果を収集する機能が含まれている必要があります（この要件は以前のプロトコル仕様と一致しており、一意ではありません）レート測定の問題）。

The following paragraphs describe features for the roles of test packet SENDER, RECEIVER, and results REPORTER.

次の段落では、テストパケットの送信者、受信者、結果報告者の役割の機能について説明します。

SENDER:

送信者：

Generate streams of test packets with various characteristics as desired (see Section 4). The SENDER MAY be located at the user end of the access path or elsewhere in the production network, such as at one end of an aggregated leased-network segment.

必要に応じて、さまざまな特性を持つテストパケットのストリームを生成します（セクション4を参照）。 SENDERは、アクセスパスのユーザー側、または集約された専用ネットワークセグメントの一方の端など、本番ネットワークのどこかに配置できます。

RECEIVER:

レシーバー：

Collect streams of test packets with various characteristics (as described above), and make the measurements necessary to support rate measurement at the receiving end of an access or aggregated leased-network segment.

（上記のように）さまざまな特性を持つテストパケットのストリームを収集し、アクセスまたは集約された専用ネットワークセグメントの受信側でレート測定をサポートするために必要な測定を行います。

REPORTER:

報告者：

Use information from test packets and local processes to measure delivered packet rates and prepare results in the required format (the REPORTER role may be combined with another role, most likely the SENDER).

テストパケットとローカルプロセスからの情報を使用して、配信されたパケットレートを測定し、必要な形式で結果を準備します（REPORTERの役割は別の役割と組み合わせることができますが、SENDERが最も可能性があります）。

4. Measurement Method Categories

4. 測定方法のカテゴリー

A protocol that addresses the rate measurement problem MUST serve the test stream generation and measurement functions (SENDER and RECEIVER). The follow-up phase of analyzing the measurement results to produce a report is outside the scope of this problem and memo (REPORTER).

レート測定の問題に対処するプロトコルは、テストストリームの生成および測定機能（SENDERおよびRECEIVER）を提供する必要があります。測定結果を分析してレポートを作成するフォローアップフェーズは、この問題とメモ（REPORTER）の範囲外です。

For the purposes of this problem statement, we categorize the many possibilities for rate measurement stream generation as follows:

この問題の説明のために、レート測定ストリーム生成の多くの可能性を次のように分類します。

1. Packet pairs, with fixed intra-pair packet spacing and fixed or random time intervals between pairs in a test stream.

1. パケットのペア。ペア内のパケット間隔は固定で、テストストリームのペア間の固定またはランダムな時間間隔。

2. Multiple streams of packet pairs, with a range of intra-pair spacing and inter-pair intervals.

2. 一連のペア内間隔とペア間間隔のある、パケットペアの複数のストリーム。

3. One or more packet ensembles in a test stream, using a fixed ensemble size in packets and one or more fixed intra-ensemble packet spacings (including zero spacing, meaning that back-to-back burst ensembles and constant rate ensembles fall in this category).

3. テストストリーム内の1つ以上のパケットアンサンブル。パケット内の固定されたアンサンブルサイズと1つ以上の固定イントラアンサンブルパケット間隔を使用します（ゼロ間隔を含みます。これは、連続したバーストアンサンブルと定率アンサンブルがこのカテゴリに含まれることを意味します）。。

4. One or more packet chirps (a set of packets with specified characteristics), where inter-packet spacing typically decreases between adjacent packets in the same chirp and each pair of packets represents a rate for testing purposes.

4. 1つ以上のパケットチャープ（指定された特性を持つパケットのセット）。通常、同じチャープ内の隣接するパケット間でパケット間の間隔が狭くなり、各ペアのパケットはテスト目的のレートを表します。

The test protocol SHALL support test packet ensemble generation (category 3), as this appears to minimize the demands on measurement accuracy. Other stream generation categories are OPTIONAL.

テストプロトコルは、測定精度に対する要求を最小限に抑えるように見えるため、テストパケットアンサンブルの生成（カテゴリ3）をサポートする必要があります（SHALL）。他のストリーム生成カテゴリはオプションです。

For all supported categories, the following is a list of additional variables that the protocol(s) MUST be able to specify, control, and generate:

サポートされているすべてのカテゴリについて、以下はプロトコルが指定、制御、および生成できる必要がある追加の変数のリストです。

a. variable payload lengths among packet streams;

a. パケットストリーム間での可変ペイロード長。

b. variable length (in packets) among packet streams or ensembles;

b. パケットストリームまたはアンサンブル間の可変長（パケット単位）。

c. variable IP header markings among packet streams;

c. パケットストリーム間の可変IPヘッダーマーキング。

d. choice of UDP transport and variable port numbers, or choice of TCP transport and variable port numbers for two-way architectures only, or both (see below for additional requirements on TCP transport generation); and

d. UDPトランスポートと変数ポート番号の選択、または双方向アーキテクチャのみのTCPトランスポートと変数ポート番号の選択、またはその両方（TCPトランスポート生成の追加要件については、以下を参照）。そして

e. variable number of packet pairs, ensembles, or streams used in a test session.

e. テストセッションで使用される可変数のパケットペア、アンサンブル、またはストリーム。

The ability to revise these variables during an established test session is OPTIONAL, as multiple test sessions could serve the same purpose. Another OPTIONAL feature is the ability to generate streams with VLAN tags and other markings.

複数のテストセッションが同じ目的を果たす可能性があるため、確立されたテストセッション中にこれらの変数を変更する機能はオプションです。別のオプション機能は、VLANタグやその他のマーキングを使用してストリームを生成する機能です。

For measurement systems employing TCP as the transport protocol, the ability to generate specific stream characteristics requires a sender with the ability to establish and prime the connection such that the desired stream characteristics are allowed. See [IPPM-METRICS] for more background.

トランスポートプロトコルとしてTCPを使用する測定システムの場合、特定のストリーム特性を生成する機能には、目的のストリーム特性が許可されるように接続を確立して準備する送信者が必要です。詳細については、[IPPM-METRICS]をご覧ください。

Beyond a simple connection handshake and the options establishment, an "open-loop" TCP sender requires the SENDER ability to:

単純な接続のハンドシェイクとオプションの確立に加えて、「オープンループ」TCP送信者には、次のことを行うSENDER機能が必要です。

o generate TCP packets with well-formed headers (all fields valid), including Acknowledgement aspects;

o 確認応答の側面を含む、整形式のヘッダー（すべてのフィールドが有効）を含むTCPパケットを生成します。

o produce packet streams at controlled rates and variable inter-packet spacings, including packet ensembles (back-to-back at server rate); and

o 制御されたレートと可変のパケット間間隔でパケットストリームを生成します。これには、パケットアンサンブル（サーバーレートで連続）が含まれます。そして

o continue the configured sending stream characteristics despite all control indications except receive-window exhaust.

o 受信ウィンドウの排気を除くすべての制御表示にもかかわらず、設定された送信ストリーム特性を継続します。

The corresponding TCP RECEIVER performs normally, having some ability to configure the receive window sufficiently large so as to allow the SENDER to transmit at will (up to a configured target).

対応するTCP RECEIVERは正常に動作し、SENDERが自由に（構成されたターゲットまで）送信できるように、受信ウィンドウを十分に大きく構成する機能があります。

It may also be useful (for diagnostic purposes) to provide a control for the bulk transfer capacity measurement with fully-specified (and congestion-controlled) TCP senders and receivers, as envisioned in [RFC3148], but this would be a brute-force assessment, which does not follow the conservative tenets of IPPM measurement [RFC2330].

[RFC3148]で想定されているように、完全に指定された（および輻輳が制御された）TCP送信側と受信側でバルク転送容量測定の制御を提供することも（診断目的で）役立つかもしれませんが、これは強引なものになりますIPPM測定の保守的な原則に従わない評価[RFC2330]。

Measurements for each UDP test packet transferred between SENDER and RECEIVER MUST be compliant with the singleton measurement methods described in IPPM RFCs [RFC2679][RFC2680]. The timestamp information or loss/arrival status for each packet MUST be available for communication to the REPORTER function.

SENDERとRECEIVERの間で転送される各UDPテストパケットの測定は、IPPM RFC [RFC2679] [RFC2680]で説明されているシングルトン測定方法に準拠している必要があります。各パケットのタイムスタンプ情報または損失/到着ステータスは、REPORTER関数への通信に使用できる必要があります。

5. Test Protocol Control and Generation Requirements

5. テストプロトコルの制御と生成の要件

In summary, the test protocol must support the measurement features described in the sections above. This requires:

要約すると、テストプロトコルは、上記のセクションで説明した測定機能をサポートする必要があります。これには以下が必要です。

1. Communicating all test variables to the SENDER and RECEIVER;

1. すべてのテスト変数をSENDERとRECEIVERに伝達します。

2. Results collection in a one-way architecture;

2. 一方向アーキテクチャでの結果コレクション。

3. Remote device control for both one-way and two-way architectures; and

3. 一方向と双方向の両方のアーキテクチャのリモートデバイス制御。そして

4. Asymmetric packet rates in a two-way measurement architecture, or coordinated one-way test capabilities with the same effect (asymmetric rates may be achieved through directional control of packet rate or packet size).

4. 双方向測定アーキテクチャでの非対称パケットレート、または同じ効果を持つ調整された一方向テスト機能（非対称レートは、パケットレートまたはパケットサイズの方向制御によって実現できます）。

The ability to control and generate asymmetric rates in a two-way architecture is REQUIRED. Two-way architectures are RECOMMENDED to include control and generation capability for both asymmetric and symmetric packet sizes because packet size often matters in the scope of this problem and test systems SHOULD be equipped to detect directional size dependency through comparative measurements.

双方向アーキテクチャで非対称レートを制御および生成する機能が必要です。双方向のアーキテクチャは、非対称および対称の両方のパケットサイズの制御機能と生成機能を含めることをお勧めします。これは、パケットサイズがこの問題の範囲内で重要であることが多く、テストシステムは、比較測定によって方向サイズの依存性を検出できるように装備する必要があるためです。

Asymmetric packet size control is indicated when the result of a measurement may depend on the size of the packets used in each direction, i.e., when any of the following conditions hold:

非対称パケットサイズ制御は、測定結果が各方向で使用されるパケットのサイズに依存する可能性がある場合、つまり次のいずれかの条件が満たされる場合に示されます。

o there is a link in the path with asymmetrical capacity in opposite directions (in combination with one or more of the conditions below, but their presence or specific details may be unknown to the tester);

o 反対方向に非対称の容量を持つパスにリンクがあります（以下の条件の1つ以上と組み合わせて、その存在または特定の詳細はテスターに知られていない可能性があります）。

o there is a link in the path that aggregates (or divides) packets into link-level frames and may have a capacity that depends on packet size, rate, or timing;

o パケットをリンクレベルのフレームに集約（または分割）するパスにリンクがあり、パケットサイズ、レート、またはタイミングに依存する容量がある場合があります。

o there is a link in the path where transmission in one direction influences performance in the opposite direction;

o パスにリンクがあり、一方向の送信が反対方向のパフォーマンスに影響します。

o there is a device in the path where transmission capacity depends on packet header processing capacity (in other words, the capacity is sensitive to packet size);

o パスにデバイスがあり、伝送容量がパケットヘッダーの処理容量に依存している（つまり、容量はパケットサイズに影響されます）。

o the target application stream is nominally MTU size packets in one direction versus ACK stream in the other (noting that there are a vanishing number of symmetrical rate application streams for which rate measurement is wanted or interesting but such streams might have some relevance at this time);

o ターゲットアプリケーションストリームは、名目上は一方向のMTUサイズのパケットに対して他の方向のACKストリームです（レート測定が必要であるか興味深い対象の対称レートアプリケーションストリームの数が消えていることに注意してください。ただし、このようなストリームは現時点で何らかの関連性がある可能性があります）。 ;

o the distribution of packet losses is critical to rate assessment;

o パケット損失の分布は、レートの評価にとって重要です。

and possibly other circumstances revealed by measurements comparing streams with symmetrical size and asymmetrical size.

対称的なサイズと非対称的なサイズのストリームを比較する測定によって明らかにされた他の状況。

Implementations may support control and generation for only symmetric packet sizes when none of the above conditions hold.

実装は、上記の条件がいずれも成立しない場合に、対称パケットサイズのみの制御と生成をサポートする場合があります。

The test protocol SHOULD enable measurement of the capacity metric [RFC5136] either Out-of-Service, In-Service, or both; other metrics [RFC5136] are OPTIONAL.

テストプロトコルは、容量メトリック[RFC5136]のアウトオブサービス、インサービス、またはその両方の測定を有効にする必要があります（SHOULD）。他のメトリック[RFC5136]はオプションです。

6. Security Considerations

6. セキュリティに関する考慮事項

The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].

ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]と[RFC5357]を参照してください。

Privacy considerations for measurement systems, particularly when Internet users participate in the tests in some way, are described in [LMAP-FRAMEWORK].

特にインターネットユーザーが何らかの方法でテストに参加する場合の測定システムのプライバシーに関する考慮事項は、[LMAP-FRAMEWORK]で説明されています。

There may be a serious issue if a proprietary service level agreement involved with the access network segment provider were somehow leaked in the process of rate measurement. To address this, test protocols SHOULD NOT convey this information in a way that could be discovered by unauthorized parties.

アクセスネットワークセグメントプロバイダーに関連する独自のサービスレベル契約がレート測定のプロセスで何らかの形で漏洩した場合、深刻な問題が発生する可能性があります。これに対処するために、テストプロトコルは、許可されていない者によって発見される可能性のある方法でこの情報を伝えてはなりません。

7. Operational Considerations

7. 運用上の考慮事項

All forms of testing originate network traffic, either through their communications for control and results collection, from dedicated measurement packet streams, or from a combination of both types of traffic. Testing traffic primarily falls in one of two categories: subscriber traffic or network management traffic. There is an ongoing need to engineer networks so that various forms of traffic are adequately served, and publication of this memo does not change this need. Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Likewise, a service provider or third party SHOULD obtain the subscriber's permission to conduct tests, since they might temporarily reduce service quality. The protocol SHOULD communicate the permission status once the overall system has obtained it, either explicitly or through other means.

すべての形式のテストは、制御と結果の収集のための通信、専用の測定パケットストリーム、または両方のタイプのトラフィックの組み合わせから、ネットワークトラフィックを発信します。テストトラフィックは主に、サブスクライバートラフィックまたはネットワーク管理トラフィックの2つのカテゴリのいずれかに分類されます。さまざまな形式のトラフィックが適切に処理されるようにネットワークを設計する必要性が継続的にあり、このメモの発行によってこの必要性が変わることはありません。サービスサブスクライバーと承認されたユーザーは、テストを実施する前に、ネットワークオペレーターまたはサービスプロバイダーの許可を取得する必要があります。同様に、サービスプロバイダーまたはサードパーティは、サービス品質を一時的に低下させる可能性があるため、テストを実施するための加入者の許可を取得する必要があります。プロトコルは、システム全体が明示的または他の手段を介してそれを取得すると、許可ステータスを伝達する必要があります（SHOULD）。

Subscribers, their service providers and network operators, and sometimes third parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer performance of streams traversing shared components of the test path, to some degree. The degradation can be minimized by scheduling such tests infrequently and restricting the amount of measurement traffic required to assess capacity metrics. As a result, occasional short-duration estimates with minimal traffic are preferred to measurements based on frequent file transfers of many megabytes with similar accuracy. New measurement methodologies intended for standardization should be evaluated individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods used (and schedules are not typically submitted for standardization).

加入者、そのサービスプロバイダー、ネットワークオペレーター、および場合によってはサードパーティはすべて、ネットワークパフォーマンスの測定を求めています。アクティブなトラフィックを使用したキャパシティテストは、テストパスの共有コンポーネントを通過するストリームのパケット転送パフォーマンスにある程度影響します。このようなテストを頻繁にスケジューリングせず、キャパシティメトリックの評価に必要な測定トラフィックの量を制限することで、パフォーマンスの低下を最小限に抑えることができます。その結果、同様の精度で数メガバイトの頻繁なファイル転送に基づいた測定よりも、トラフィックを最小限に抑えた時折の短時間の見積もりが優先されます。標準化を目的とした新しい測定方法は、潜在的な運用上の問題について個別に評価する必要があります。ただし、スケジュールされたテストの頻度は、使用される方法と同じくらい重要です（スケジュールは通常、標準化のために提出されません）。

The new test protocol feature of asymmetrical packet size generation in two-way testing is recommended in this memo. It can appreciably reduce the load and packet processing demands of each test and therefore reduce the likelihood of degradation in one direction of the tested path. Current IETF standardized test protocols (e.g., [RFC5357] and [RFC6812]) do not possess the asymmetric size generation capability with two-way testing.

このメモでは、双方向テストにおける非対称パケットサイズ生成の新しいテストプロトコル機能が推奨されています。各テストの負荷とパケット処理の要求をかなり減らすことができるため、テストされたパスの一方向での劣化の可能性を減らすことができます。現在のIETF標準テストプロトコル（[RFC5357]や[RFC6812]など）は、双方向テストで非対称サイズを生成する機能を備えていません。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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>。

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.

[RFC2330] Paxson、V.、Almes、G.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月、<http://www.rfc-editor.org/ info / rfc2330>。

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>.

[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月、<http://www.rfc-editor.org/info/ rfc2679>。

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.

[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの片方向パケット損失メトリック」、RFC 2680、1999年9月、<http://www.rfc-editor.org/info / rfc2680>。

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.

[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J.、and M. Zekauskas、 "A One-way Active Measurement Protocol（OWAMP）"、RFC 4656、September 2006、<http： //www.rfc-editor.org/info/rfc4656>。

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>.

[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、2008年10月、<http： //www.rfc-editor.org/info/rfc5357>。

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>.

[RFC6703] Morton、A.、Ramachandran、G。、およびG. Maguluri、「Reporting IP Network Performance Metrics：Different Points of View」、RFC 6703、2012年8月、<http://www.rfc-editor.org/ info / rfc6703>。

8.2. Informative References

8.2. 参考引用

[IPPM-METRICS] Mathis, M. and A. Morton, "Model Based Bulk Performance Metrics", Work in Progress, draft-ietf-ippm-model-based-metrics-04, March 2015.

[IPPM-METRICS] Mathis、M.、A。Morton、「モデルベースのバルクパフォーマンスメトリック」、作業中、draft-ietf-ippm-model-based-metrics-04、2015年3月。

[LMAP-FRAMEWORK] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for Large-Scale Measurement of Broadband Performance (LMAP)", Work in Progress, draft-ietf-lmap-framework-12, March 2015.

[LMAP-FRAMEWORK] Eardley、P.、Morton、A.、Bagnulo、M.、Burbridge、T.、Aitken、P。、およびA. Akhter、「ブロードバンドパフォーマンスの大規模測定（LMAP）のフレームワーク」、Work in Progress、draft-ietf-lmap-framework-12、2015年3月。

[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001, <http://www.rfc-editor.org/info/rfc3148>.

[RFC3148] Mathis、M。、およびM. Allman、「経験的バルク転送容量メトリックを定義するためのフレームワーク」、RFC 3148、2001年7月、<http://www.rfc-editor.org/info/rfc3148>。

[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008, <http://www.rfc-editor.org/info/rfc5136>.

[RFC5136] Chimento、P。およびJ. Ishac、「Defining Network Capacity」、RFC 5136、2008年2月、<http://www.rfc-editor.org/info/rfc5136>。

[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, "Cisco Service-Level Assurance Protocol", RFC 6812, January 2013, <http://www.rfc-editor.org/info/rfc6812>.

[RFC6812]千葉、M。、クレム、A。、メドレー、S。、サロウイ、J。、トンバレ、S。、およびE.イエダバリ、「Cisco Service-Level Assurance Protocol」、RFC 6812、2013年1月、<http ：//www.rfc-editor.org/info/rfc6812>。

[RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and A. Morton, "A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance", RFC 7398, February 2015, <http://www.rfc-editor.org/info/rfc7398>.

[RFC7398] Bagnulo、M.、Burbridge、T.、Crawford、S.、Eardley、P。、およびA. Morton、「ブロードバンドパフォーマンスの大規模測定のための参照パスと測定ポイント」、RFC 7398、2015年2月、<http://www.rfc-editor.org/info/rfc7398>。

Acknowledgements

謝辞

Dave McDysan provided comments and text for the aggregated leased use case. Yaakov Stein suggested many considerations to address, including the In-Service vs. Out-of-Service distinction and its implication on test traffic limits and protocols. Bill Cerveny, Marcelo Bagnulo, Kostas Pentikousis (a persistent reviewer), and Joachim Fabini have contributed insightful, clarifying comments that made this a better document. Barry Constantine also provided suggestions for clarification.

Dave McDysanは、リースされたユースケースの集計についてコメントとテキストを提供しました。 Yaakov Steinは、サービス中とサービス外の違いや、テストトラフィックの制限とプロトコルへの影響など、対処すべき多くの考慮事項を提案しました。 Bill Cerveny、Marcelo Bagnulo、Kostas Pentikousis（執筆中のレビュアー）、およびJoachim Fabiniは、これをより良いドキュメントにするための洞察に満ちた明確なコメントを提供してくれました。バリー・コンスタンティーヌも明確化のための提案をしました。

Author's Address

著者のアドレス

Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States

Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   EMail: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/