[要約] RFC 8762は、シンプルな双方向アクティブ測定プロトコルに関するものであり、ネットワークのパフォーマンス測定とトラブルシューティングを目的としています。
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8762 G. Jun
Category: Standards Track ZTE Corp.
ISSN: 2070-1721 H. Nydell
Accedian Networks
R. Foote
Nokia
March 2020
Simple Two-Way Active Measurement Protocol
シンプルな双方向アクティブ測定プロトコル
Abstract
概要
This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.
このドキュメントでは、Simple Two-way Active Measurement Protocol（STAMP）について説明します。これにより、遅延、遅延変動、パケット損失など、一方向とラウンドトリップの両方のパフォーマンスメトリックを測定できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8762.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8762で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Terminology
2.2. Requirements Language
3. Operation and Management of Performance Measurement Based on
STAMP
4. Theory of Operation
4.1. UDP Port Numbers in STAMP Testing
4.2. Session-Sender Behavior and Packet Format
4.2.1. Session-Sender Packet Format in Unauthenticated Mode
4.2.2. Session-Sender Packet Format in Authenticated Mode
4.3. Session-Reflector Behavior and Packet Format
4.3.1. Session-Reflector Packet Format in Unauthenticated Mode
4.3.2. Session-Reflector Packet Format in Authenticated Mode
4.4. Integrity Protection in STAMP
4.5. Confidentiality Protection in STAMP
4.6. Interoperability with TWAMP Light
5. Operational Considerations
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
Development and deployment of the Two-Way Active Measurement Protocol (TWAMP) [RFC5357] and its extensions (e.g., [RFC6038], which defines Symmetrical Size for TWAMP) provided invaluable experience. Several independent implementations of both TWAMP and TWAMP Light exist, have been deployed, and provide important operational performance measurements.
Two-Way Active Measurement Protocol（TWAMP）[RFC5357]とその拡張機能（TWAMPの対称サイズを定義する[RFC6038]など）の開発と展開は、非常に貴重な体験を提供しました。 TWAMPとTWAMP Lightの両方のいくつかの独立した実装が存在し、展開されており、重要な運用パフォーマンス測定を提供します。
At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherent separation of control (vendor-specific configuration or orchestration) and test functions. Recent work on "Performance Measurement from IP Edge to Customer Equipment using TWAMP Light" [BBF.TR-390] by the Broadband Forum demonstrates that interoperability among implementations of TWAMP Light is difficult because the composition and operation of TWAMP Light were not sufficiently specified in [RFC5357]. According to [RFC8545], TWAMP Light includes a subset of TWAMP-Test functions. Thus, to have a comprehensive tool to measure packet loss and delay requires support by other applications that provide, for example, control and security.
同時に、アクティブパフォーマンスモニタリングのより単純なメカニズムを使用して、決定論的な動作と、制御（ベンダー固有の構成またはオーケストレーション）とテスト機能の固有の分離を提供できることに注目が集まっています。ブロードバンドフォーラムによる「TWAMP Lightを使用したIPエッジから顧客機器までのパフォーマンス測定」[BBF.TR-390]に関する最近の研究は、TWAMP Lightの構成と動作が十分に指定されていないため、TWAMP Lightの実装間の相互運用性が困難であることを示しています[RFC5357]。 [RFC8545]によれば、TWAMP LightにはTWAMP-Test関数のサブセットが含まれています。したがって、パケットの損失と遅延を測定する包括的なツールを使用するには、制御やセキュリティなどを提供する他のアプリケーションによるサポートが必要です。
This document defines an active performance measurement test protocol, Simple Two-way Active Measurement Protocol (STAMP), that enables measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. Support of some optional TWAMP extensions, e.g., [RFC7750], is discussed in [STAMP-OPTION].
このドキュメントでは、アクティブパフォーマンス測定テストプロトコルであるSimple Two-way Active Measurement Protocol（STAMP）を定義します。これにより、遅延、遅延変動、パケット損失など、一方向とラウンドトリップの両方のパフォーマンスメトリックを測定できます。 [RFC7750]など、オプションのTWAMP拡張機能のサポートについては、[STAMP-OPTION]で説明しています。
STAMP: Simple Two-way Active Measurement Protocol
スタンプ：シンプルな双方向アクティブ測定プロトコル
NTP: Network Time Protocol
NTP：ネットワークタイムプロトコル
PTP: Precision Time Protocol
PTP：Precision Time Protocol
HMAC: Hashed Message Authentication Code
HMAC：ハッシュメッセージ認証コード
OWAMP: One-Way Active Measurement Protocol
OWAMP：一方向アクティブ測定プロトコル
TWAMP: Two-Way Active Measurement Protocol
TWAMP：双方向アクティブ測定プロトコル
MBZ: Must be Zero
MBZ：ゼロでなければなりません
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
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]で説明されているように解釈されます。
Figure 1 presents the Simple Two-way Active Measurement Protocol (STAMP) Session-Sender and Session-Reflector with a measurement session. In this document, a measurement session, also referred to as a "STAMP session", is the bidirectional packet flow between one specific Session-Sender and one particular Session-Reflector for a time duration. The configuration and management of the STAMP Session-Sender, Session-Reflector, and sessions are outside the scope of this document and can be achieved through various means. A few examples are Command Line Interface, telecommunication services' Operational Support System (OSS) / Business Support System (BSS), SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN) controllers.
図1は、測定セッションを備えたシンプルな双方向アクティブ測定プロトコル（STAMP）セッション送信側とセッション反射板を示しています。このドキュメントでは、「セッション」とも呼ばれる測定セッションは、特定のセッション送信者と特定のセッションリフレクタの間の、ある期間の双方向パケットフローです。 STAMP Session-Sender、Session-Reflector、およびセッションの構成と管理は、このドキュメントの範囲外であり、さまざまな方法で実現できます。いくつかの例は、コマンドラインインターフェイス、テレコミュニケーションサービスの運用サポートシステム（OSS）/ビジネスサポートシステム（BSS）、SNMP、およびNETCONF / YANGベースのソフトウェア定義ネットワーク（SDN）コントローラーです。
o----------------------------------------------------------o
| Configuration and |
| Management |
o----------------------------------------------------------o
|| ||
|| ||
|| ||
+----------------------+ +-------------------------+
| STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
+----------------------+ +-------------------------+
Figure 1: STAMP Reference Model
図1：STAMP参照モデル
The STAMP Session-Sender transmits test packets over UDP transport toward the STAMP Session-Reflector. The STAMP Session-Reflector receives the Session-Sender's packet and acts according to the configuration. Two modes of the STAMP Session-Reflector characterize the expected behavior and, consequently, performance metrics that can be measured:
STAMP Session-Senderは、UDPトランスポートを介してSTAMP Session-Reflectorに向けてテストパケットを送信します。 STAMP Session-Reflectorは、Session-Senderのパケットを受信し、構成に従って動作します。 STAMP Session-Reflectorの2つのモードは、予想される動作を特徴付け、その結果、測定可能なパフォーマンスメトリックを特徴付けます。
Stateless: The STAMP Session-Reflector does not maintain test state and will use the value in the Sequence Number field in the received packet as the value for the Sequence Number field in the reflected packet. As a result, values in the Sequence Number and Session-Sender Sequence Number fields are the same, and only round-trip packet loss can be calculated while the reflector is operating in stateless mode.
ステートレス：STAMPセッションリフレクターはテスト状態を維持せず、受信パケットのシーケンス番号フィールドの値を、反射パケットのシーケンス番号フィールドの値として使用します。その結果、[シーケンス番号]フィールドと[セッション送信者のシーケンス番号]フィールドの値は同じになり、リフレクターがステートレスモードで動作している間は、往復のパケット損失しか計算できません。
Stateful: STAMP Session-Reflector maintains the test state, thus allowing the Session-Sender to determine directionality of loss using the combination of gaps recognized in the Session Sender Sequence Number and Sequence Number fields, respectively. As a result, both near-end (forward) and far-end (backward) packet loss can be computed. That implies that the STAMP Session-Reflector MUST maintain a state for each configured STAMP-Test session, thereby uniquely associating STAMP-Test packets with one such session instance and, thus, enabling the addition of a sequence number in the test reply that is individually incremented by one on a per-session basis.
ステートフル：STAMPセッションリフレクターはテスト状態を維持するため、セッション送信者は、セッション送信者のシーケンス番号フィールドとシーケンス番号フィールドでそれぞれ認識されたギャップの組み合わせを使用して、損失の方向性を決定できます。その結果、近端（フォワード）と遠端（バックワード）の両方のパケット損失を計算できます。これは、STAMPセッションリフレクターが、構成された各STAMPテストセッションの状態を維持する必要があることを意味します。これにより、STAMPテストパケットをそのようなセッションインスタンスに一意に関連付け、テスト応答にシーケンス番号を個別に追加できるようにします。セッションごとに1ずつ増加します。
STAMP supports two authentication modes: unauthenticated and authenticated. Unauthenticated STAMP-Test packets, defined in Sections 4.2.1 and 4.3.1, ensure interworking between STAMP and TWAMP Light, as described in Section 4.6 regarding packet formats.
STAMPは、非認証と認証の2つの認証モードをサポートしています。セクション4.2.1および4.3.1で定義されている未認証のSTAMP-Testパケットは、パケット形式に関するセクション4.6で説明されているように、STAMPとTWAMP Light間の相互作用を保証します。
By default, STAMP uses symmetrical packets, i.e., the size of the packet transmitted by the Session-Reflector equals the size of the packet received by the Session-Reflector.
デフォルトでは、STAMPは対称的なパケットを使用します。つまり、Session-Reflectorによって送信されるパケットのサイズは、Session-Reflectorによって受信されるパケットのサイズと同じです。
A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver Port) as the default destination UDP port number. A STAMP implementation of the Session-Sender MUST be able to be used as the destination UDP port numbers from the User Ports (aka Registered Ports) and Dynamic Ports (aka Private or Ephemeral Ports) ranges defined in [RFC6335]. Before using numbers from the User Ports range, the possible impact on the network MUST be carefully studied and agreed on by all users of the network domain where the test has been planned.
STAMPセッション送信者は、デフォルトの宛先UDPポート番号としてUDPポート862（TWAMPテスト受信者ポート）を使用する必要があります。セッション送信者のスタンプ実装は、[RFC6335]で定義されているユーザーポート（別名登録ポート）および動的ポート（別名プライベートポートまたはエフェメラルポート）範囲からの宛先UDPポート番号として使用できる必要があります。ユーザーポート範囲の数値を使用する前に、ネットワークへの影響の可能性を慎重に調査し、テストが計画されているネットワークドメインのすべてのユーザーが同意する必要があります。
By default, an implementation of the STAMP Session-Reflector MUST receive STAMP-Test packets on UDP port 862. An implementation of the Session-Reflector that supports this specification MUST be able to define the port number to receive STAMP-Test packets from User Ports and Dynamic Ports ranges, which are defined in [RFC6335]. STAMP defines two different test packet formats: one for packets transmitted by the STAMP Session-Sender and one for packets transmitted by the STAMP Session-Reflector.
デフォルトでは、STAMP Session-Reflectorの実装は、UDPポート862でSTAMP-Testパケットを受信する必要があります。この仕様をサポートするSession-Reflectorの実装は、ユーザーポートからSTAMP-Testパケットを受信するためのポート番号を定義できる必要があります[RFC6335]で定義されているダイナミックポートの範囲。 STAMPは2つの異なるテストパケット形式を定義します。1つはSTAMPセッション送信者が送信するパケット用、もう1つはSTAMPセッションリフレクターが送信するパケット用です。
A STAMP Session-Reflector supports the symmetrical size of test packets, as defined in Section 3 of [RFC6038], as the default behavior. A reflected base test packet includes information from the Session-Reflector and, thus, is larger. To maintain the symmetry between base STAMP packets, the base STAMP Session-Sender packet includes the Must-Be-Zero (MBZ) field to match to the size of a base reflected STAMP test packet. Hence, the base STAMP Session-Sender packet has a minimum size of 44 octets in unauthenticated mode (see Figure 2) and 112 octets in the authenticated mode (see Figure 4). Generating variable length of a test packet in STAMP is defined in [STAMP-OPTION].
STAMP Session-Reflectorは、[RFC6038]のセクション3で定義されている対称サイズのテストパケットをデフォルトの動作としてサポートします。反射されたベーステストパケットには、Session-Reflectorからの情報が含まれるため、サイズが大きくなります。ベースSTAMPパケット間の対称性を維持するために、ベースSTAMPセッション送信パケットには、ベース反射STAMPテストパケットのサイズと一致するように、Must-Be-Zero（MBZ）フィールドが含まれています。したがって、ベースSTAMPセッション送信側パケットの最小サイズは、非認証モード（図2を参照）では44オクテット、認証モード（図4を参照）では112オクテットです。 STAMPでテストパケットの可変長を生成することは、[STAMP-OPTION]で定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| |
| MBZ (30 octets) |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: STAMP Session-Sender Test Packet Format in Unauthenticated Mode
図2：非認証モードでのSTAMPセッション送信者テストパケットの形式
The fields are defined as following:
フィールドは次のように定義されています。
* The Sequence Number field is four octets long. For each new session, its value starts at zero and is incremented by one with each transmitted packet.
* シーケンス番号フィールドは4オクテットの長さです。新しいセッションごとに、その値はゼロから始まり、送信されるパケットごとに1ずつ増加します。
* The Timestamp field is eight octets long. The STAMP node MUST support the Network Time Protocol (NTP) version 4 64-bit timestamp format [RFC5905], the format used in [RFC5357]. The STAMP node MAY support the IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit timestamp format [IEEE.1588.2008], the format used in [RFC8186]. The use of the specific format, NTP or PTP, is part of configuration of the Session-Sender or the particular test session.
* Timestampフィールドは8オクテットの長さです。スタンプノードはネットワークタイムプロトコル（NTP）バージョン4 64ビットタイムスタンプフォーマット[RFC5905]、[RFC5357]で使用されるフォーマットをサポートする必要があります。 STAMPノードは、IEEE 1588v2プレシジョンタイムプロトコル（PTP）で切り捨てられた64ビットのタイムスタンプフォーマット[IEEE.1588.2008]をサポートする場合があります[IEEE.1588.2008]。このフォーマットは、[RFC8186]で使用されています。特定の形式、NTPまたはPTPの使用は、Session-Senderまたは特定のテストセッションの構成の一部です。
* The Error Estimate field is two octets long with the format displayed in Figure 3:
* Error Estimateフィールドは2オクテット長で、図3に表示されている形式です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Error Estimate Format
図3：エラー推定形式
The S, Scale, and Multiplier fields are interpreted as they are defined in Section 4.1.2 of [RFC4656]. The Z field is interpreted as it is defined in Section 2.3 of [RFC8186]:
S、Scale、およびMultiplierフィールドは、[RFC4656]のセクション4.1.2で定義されているとおりに解釈されます。 Zフィールドは、[RFC8186]のセクション2.3で定義されているとおりに解釈されます。
0: NTP 64-bit format of a timestamp
0：タイムスタンプのNTP 64ビット形式
1: PTPv2 truncated format of a timestamp
1：タイムスタンプのPTPv2切り捨て形式
The default behavior of the STAMP Session-Sender and Session-Reflector is to use the NTP 64-bit timestamp format (Z field value of 0). An operator using configuration/management function MAY configure the STAMP Session-Sender and Session-Reflector to use the PTPv2 truncated format of a timestamp (Z field value of 1). Note that an implementation of a Session-Sender that supports this specification MAY be configured to use the PTPv2 format of a timestamp even though the Session-Reflector is configured to use NTP format.
STAMP Session-SenderおよびSession-Reflectorのデフォルトの動作は、NTP 64ビットタイムスタンプフォーマット（Zフィールド値0）を使用することです。構成/管理機能を使用するオペレーターは、タイムスタンプ（Zフィールド値が1）のPTPv2切り捨て形式を使用するように、STAMPセッション送信側とセッション反射側を構成できます（MAY）。この仕様をサポートするSession-Senderの実装は、Session-ReflectorがNTP形式を使用するように構成されている場合でも、タイムスタンプのPTPv2形式を使用するように構成できます。
* The MBZ field in the Session-Sender unauthenticated packet is 30 octets long. It MUST be all zeroed on the transmission and MUST be ignored on receipt.
* セッション送信者の非認証パケットのMBZフィールドは30オクテット長です。送信時にすべてゼロにする必要があり、受信時には無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| MBZ (70 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: STAMP Session-Sender Test Packet Format in Authenticated Mode
図4：認証モードでのSTAMPセッション送信者テストパケットの形式
The field definitions are the same as the unauthenticated mode, listed in Section 4.2.1. Also, MBZ fields are used to make the packet length a multiple of 16 octets. The value of the field MUST be zeroed on transmission and MUST be ignored on receipt. Note, that both MBZ fields are used to calculate a key hashed message authentication code (HMAC) [RFC2104] hash. Also, the packet includes an HMAC hash at the end of the PDU. The detailed use of the HMAC field is described in Section 4.4.
フィールド定義は、セクション4.2.1にリストされている非認証モードと同じです。また、MBZフィールドは、パケット長を16オクテットの倍数にするために使用されます。フィールドの値は送信時にゼロにしなければならず、受信時に無視しなければなりません。両方のMBZフィールドは、キーハッシュメッセージ認証コード（HMAC）[RFC2104]ハッシュの計算に使用されることに注意してください。また、パケットのPDUの最後にHMACハッシュが含まれています。 HMACフィールドの詳細な使用法はセクション4.4で説明されています。
The Session-Reflector receives the STAMP-Test packet and verifies it. If the base STAMP-Test packet is validated, the Session-Reflector that supports this specification prepares and transmits the reflected test packet symmetric to the packet received from the Session-Sender copying the content beyond the size of the base STAMP packet (see Section 4.2).
Session-Reflectorは、STAMP-Testパケットを受信して検証します。基本STAMP-Testパケットが検証されると、この仕様をサポートするSession-Reflectorは、Session-Senderから受信したパケットと対称的な反射テストパケットを準備して送信し、基本STAMPパケットのサイズを超えてコンテンツをコピーします（セクション4.2を参照）。 ）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: STAMP Session-Reflector Test Packet Format in Unauthenticated Mode
図5：非認証モードでのSTAMPセッションリフレクターテストパケットの形式
Fields are defined as the following:
フィールドは次のように定義されています。
* The Sequence Number field is four octets long. The value of the Sequence Number field is set according to the mode of the STAMP Session-Reflector:
* シーケンス番号フィールドは4オクテットの長さです。シーケンス番号フィールドの値は、スタンプセッションリフレクターのモードに従って設定されます。
- In the stateless mode, the Session-Reflector copies the value from the received STAMP-Test packet's Sequence Number field.
- ステートレスモードでは、Session-Reflectorは受信したSTAMP-Testパケットのシーケンス番号フィールドから値をコピーします。
- In the stateful mode, the Session-Reflector counts the transmitted STAMP-Test packets. It starts with zero and is incremented by one for each subsequent packet for each test session. The Session-Reflector uses that counter to set the value of the Sequence Number field.
- ステートフルモードでは、Session-Reflectorは送信されたSTAMP-Testパケットをカウントします。ゼロから始まり、各テストセッションの後続のパケットごとに1ずつ増加します。 Session-Reflectorはそのカウンターを使用して、Sequence Numberフィールドの値を設定します。
* The Timestamp and Receive Timestamp fields are each eight octets long. The format of these fields, NTP or PTPv2, is indicated by the Z field of the Error Estimate field, as described in Section 4.2.1. Receive Timestamp is the time the test packet was received by the Session-Reflector. Timestamp is the time taken by the Session-Reflector at the start of transmitting the test packet.
* TimestampフィールドとReceive Timestampフィールドは、それぞれ8オクテットの長さです。これらのフィールドの形式であるNTPまたはPTPv2は、セクション4.2.1で説明されているように、Error EstimateフィールドのZフィールドで示されます。受信タイムスタンプは、セッションリフレクターがテストパケットを受信した時刻です。タイムスタンプは、テストパケットの送信を開始するときにセッションリフレクタが費やす時間です。
* The Error Estimate field has the same size and interpretation as described in Section 4.2.1. It is applicable to both Timestamp and Receive Timestamp.
* Error Estimateフィールドのサイズと解釈は、セクション4.2.1で説明したものと同じです。タイムスタンプと受信タイムスタンプの両方に適用できます。
* The Session-Sender Sequence Number, Session-Sender Timestamp, and Session-Sender Error Estimate fields are copies of the corresponding fields in the STAMP-Test packet sent by the Session-Sender.
* Session-Sender Sequence Number、Session-Sender Timestamp、およびSession-Sender Error Estimateフィールドは、Session-Senderによって送信されたSTAMP-Testパケットの対応するフィールドのコピーです。
* The Session-Sender TTL field is one octet long, and its value is the copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the received STAMP-Test packet.
* Session-Sender TTLフィールドは1オクテット長で、その値は受信したSTAMP-TestパケットからのIPv4（またはIPv6のホップ制限）のTTLフィールドのコピーです。
* The MBZ fields are used to achieve alignment of fields within the packet on a four-octet boundary. The value of each MBZ field MUST be zeroed on transmission and MUST be ignored on receipt.
* MBZフィールドは、パケット内のフィールドを4オクテットの境界で整列させるために使用されます。各MBZフィールドの値は送信時にゼロに設定されなければならず、受信時に無視されなければなりません（MUST）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
| MBZ (15 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: STAMP Session-Reflector Test Packet Format in Authenticated Mode
図6：認証モードのSTAMPセッションリフレクターテストパケットの形式
The field definitions are the same as the unauthenticated mode, listed in Section 4.3.1. Additionally, the MBZ field is used to make the packet length a multiple of 16 octets. The value of the field MUST be zeroed on transmission and MUST be ignored on receipt. Note that the MBZ field is used to calculate the HMAC hash value. Also, the STAMP Session-Reflector test packet format in authenticated mode includes the HMAC [RFC2104] hash at the end of the PDU. The detailed use of the HMAC field is in Section 4.4.
フィールド定義は、セクション4.3.1にリストされている非認証モードと同じです。さらに、MBZフィールドは、パケット長を16オクテットの倍数にするために使用されます。フィールドの値は送信時にゼロにしなければならず、受信時に無視しなければなりません。 MBZフィールドはHMACハッシュ値の計算に使用されることに注意してください。また、認証モードのSTAMP Session-Reflectorテストパケット形式には、PDUの最後にHMAC [RFC2104]ハッシュが含まれます。 HMACフィールドの詳細な使用法はセクション4.4にあります。
Authenticated mode provides integrity protection to each STAMP message by adding Hashed Message Authentication Code (HMAC). STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in IPsec defined in [RFC4868]); hence, the length of the HMAC field is 16 octets. In the authenticated mode, HMAC covers the first six blocks (96 octets). HMAC uses its own key, which may be unique for each STAMP-Test session; key management and the mechanisms to distribute the HMAC key are outside the scope of this specification. One example is to use an orchestrator to configure the HMAC key based on the STAMP YANG data model [STAMP-YANG]. HMAC MUST be verified as early as possible to avoid using or propagating corrupted data.
認証モードは、ハッシュメッセージ認証コード（HMAC）を追加することにより、各STAMPメッセージに整合性保護を提供します。 STAMPは、128ビットに切り捨てられたHMAC-SHA-256を使用します（[RFC4868]で定義されているIPsecでの使用と同様）。したがって、HMACフィールドの長さは16オクテットです。認証モードでは、HMACは最初の6つのブロック（96オクテット）をカバーします。 HMACは独自のキーを使用します。これは、各STAMP-Testセッションで一意である場合があります。鍵管理とHMAC鍵を配布するメカニズムは、この仕様の範囲外です。 1つの例は、オーケストレーターを使用して、STAMP YANGデータモデル[STAMP-YANG]に基づいてHMACキーを構成することです。 HMACは、破損したデータの使用または伝播を回避するために、できるだけ早く検証する必要があります。
Future specifications may define the use of other, more advanced cryptographic algorithms, possibly providing an update to the STAMP YANG data model [STAMP-YANG].
将来の仕様では、他のより高度な暗号化アルゴリズムの使用を定義し、STAMP YANGデータモデル[STAMP-YANG]の更新を提供する可能性があります。
If confidentiality protection for STAMP is required, a STAMP-Test session MUST use a secured transport. For example, STAMP packets could be transmitted in the dedicated IPsec tunnel or share the IPsec tunnel with the monitored flow. Also, the Datagram Transport Layer Security protocol would provide the desired confidentiality protection.
STAMPの機密保護が必要な場合、STAMP-Testセッションはセキュアなトランスポートを使用する必要があります。たとえば、STAMPパケットを専用のIPsecトンネルで送信したり、監視対象のフローとIPsecトンネルを共有したりできます。また、Datagram Transport Layer Securityプロトコルは、必要な機密保護を提供します。
One of the essential requirements to STAMP is the ability to interwork with a TWAMP Light device. Because STAMP and TWAMP use different algorithms in authenticated mode (HMAC-SHA-256 versus HMAC-SHA-1), interoperability is only considered for unauthenticated mode. There are two possible combinations for such a use case:
STAMPの重要な要件の1つは、TWAMP Lightデバイスと連携する機能です。 STAMPとTWAMPは認証モード（HMAC-SHA-256とHMAC-SHA-1）で異なるアルゴリズムを使用するため、相互運用性は非認証モードでのみ考慮されます。このようなユースケースには、2つの可能な組み合わせがあります。
* STAMP Session-Sender with TWAMP Light Session-Reflector
* TWAMP Light Session-Reflectorを備えたSTAMPセッション送信者
* TWAMP Light Session-Sender with STAMP Session-Reflector
* TWAMP Light Session-Sender with STAMP Session-Reflector
In the former case, the Session-Sender might not be aware that its Session-Reflector does not support STAMP. For example, a TWAMP Light Session-Reflector may not support the use of UDP port 862, as specified in [RFC8545]. Thus, Section 4 permits a STAMP Session-Sender to use alternative ports. If any of STAMP extensions are used, the TWAMP Light Session-Reflector will view them as the Packet Padding field.
前者の場合、Session-Senderは、Session-ReflectorがSTAMPをサポートしていないことを認識していない可能性があります。たとえば、[RFC8545]で指定されているように、TWAMP Light Session-ReflectorはUDPポート862の使用をサポートしない場合があります。したがって、セクション4では、STAMPセッション送信者が代替ポートを使用することを許可しています。 STAMP拡張機能のいずれかが使用されている場合、TWAMP Light Session-Reflectorはそれらをパケットパディングフィールドとして表示します。
In the latter scenario, if a TWAMP Light Session-Sender does not support the use of UDP port 862, the test management system MUST set the STAMP Session-Reflector to use UDP port number, as permitted by Section 4. The Session-Reflector MUST be set to use the default format for its timestamps, NTP.
後者のシナリオでは、TWAMP Light Session-SenderがUDPポート862の使用をサポートしていない場合、テスト管理システムは、セクション4で許可されているように、UDPポート番号を使用するようにSTAMP Session-Reflectorを設定しなければなりません（MUST）。タイムスタンプのデフォルト形式であるNTPを使用するように設定します。
A STAMP Session-Reflector that supports this specification will transmit the base packet (Figure 5) if it receives a packet smaller than the STAMP base packet. If the packet received from the TWAMP Session-Sender is larger than the STAMP base packet, the STAMP Session-Reflector that supports this specification will copy the content of the remainder of the received packet to transmit a reflected packet of symmetrical size.
この仕様をサポートするSTAMP Session-Reflectorは、STAMPベースパケットより小さいパケットを受信すると、ベースパケット（図5）を送信します。 TWAMP Session-Senderから受信したパケットがSTAMP基本パケットよりも大きい場合、この仕様をサポートするSTAMP Session-Reflectorは、受信したパケットの残りの内容をコピーして、対称サイズの反射パケットを送信します。
STAMP is intended to be used on production networks to enable the operator to assess service level agreements based on packet delay, delay variation, and loss. When using STAMP over the Internet, especially when STAMP-Test packets are transmitted with the destination UDP port number from the User Ports range, the possible impact of the STAMP-Test packets MUST be thoroughly analyzed. The use of STAMP for each case MUST be agreed by users of nodes hosting the Session-Sender and Session-Reflector before starting the STAMP-Test session.
STAMPは、運用ネットワークで使用して、オペレーターがパケット遅延、遅延変動、および損失に基づいてサービスレベル契約を評価できるようにすることを目的としています。インターネット経由でSTAMPを使用する場合、特にSTAMP-Testパケットがユーザーポート範囲の宛先UDPポート番号で送信される場合、STAMP-Testパケットの影響の可能性を徹底的に分析する必要があります。 STAMP-Testセッションを開始する前に、Session-SenderとSession-Reflectorをホストしているノードのユーザーが、各ケースでSTAMPを使用することに同意する必要があります。
Also, the use of the well-known port number as the destination UDP port number in STAMP-Test packets transmitted by a Session-Sender would not impede the ability to measure performance in an Equal-Cost Multipath environment, and analysis in Section 5.3 of [RFC8545] fully applies to STAMP.
また、Session-Senderによって送信されるSTAMP-Testパケットの宛先UDPポート番号としてウェルノウンポート番号を使用しても、等コストマルチパス環境でのパフォーマンスを測定する機能、およびセクション5.3の分析が妨げられることはありません。 [RFC8545]はSTAMPに完全に適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC5357] does not identify security considerations specific to TWAMP-Test but refers to security considerations identified for OWAMP in [RFC4656]. Since both OWAMP and TWAMP include control-plane and data-plane components, only security considerations related to OWAMP-Test discussed in Sections 6.2 and 6.3 of [RFC4656] apply to STAMP.
[RFC5357]はTWAMP-Testに固有のセキュリティの考慮事項を識別しませんが、[RFC4656]でOWAMPに対して識別されたセキュリティの考慮事項を参照します。 OWAMPとTWAMPの両方にコントロールプレーンとデータプレーンのコンポーネントが含まれているため、[RFC4656]のセクション6.2および6.3で説明されているOWAMP-Testに関連するセキュリティ上の考慮事項のみがSTAMPに適用されます。
STAMP uses the well-known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver Port. Thus, the security considerations and measures to mitigate the risk of the attack using the registered port number documented in Section 6 of [RFC8545] equally apply to STAMP. Because of the control and management of a STAMP-Test being outside the scope of this specification, only the more general requirement is set:
STAMPは、OWAMP-Test / TWAMP-Testレシーバーポートに割り当てられた既知のUDPポート番号を使用します。したがって、[RFC8545]のセクション6に記載されている登録済みのポート番号を使用した攻撃のリスクを軽減するためのセキュリティの考慮事項と対策は、STAMPにも同様に適用されます。 STAMP-Testの制御と管理はこの仕様の範囲外であるため、より一般的な要件のみが設定されています。
To mitigate the possible attack vector, the control and management of a STAMP-Test session MUST use the secured transport.
起こり得る攻撃ベクトルを軽減するために、スタンプテストセッションの制御と管理は、セキュアなトランスポートを使用する必要があります。
The load of the STAMP-Test packets offered to a network MUST be carefully estimated, and the possible impact on the existing services MUST be thoroughly analyzed before launching the test session. Section 3.1.5 of [RFC8085] provides guidance on handling network load for UDP-based protocol. While the characteristic of test traffic depends on the test objective, it is highly recommended to stay in the limits, as provided in [RFC8085].
ネットワークに提供されるSTAMP-Testパケットの負荷は慎重に推定する必要があり、既存のサービスへの影響の可能性は、テストセッションを開始する前に徹底的に分析する必要があります。 [RFC8085]のセクション3.1.5は、UDPベースのプロトコルのネットワーク負荷の処理に関するガイダンスを提供します。テストトラフィックの特性はテストの目的によって異なりますが、[RFC8085]で規定されているように、制限内に留まることを強くお勧めします。
Use of HMAC-SHA-256 in the authenticated mode protects the data integrity of the STAMP-Test packets.
認証モードでHMAC-SHA-256を使用すると、STAMP-Testパケットのデータ整合性が保護されます。
[IEEE.1588.2008] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, July 2008.
[IEEE.1588.2008] IEEE、「ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588、2008年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[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>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<https://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, DOI 10.17487/RFC5357, October 2008, <https://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、DOI 10.17487 / RFC5357、10月2008、<https://www.rfc-editor.org/info/rfc5357>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <https://www.rfc-editor.org/info/rfc5905>。
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <https://www.rfc-editor.org/info/rfc6038>.
[RFC6038] Morton、A。およびL. Ciavattone、「Two-Way Active Measurement Protocol（TWAMP）Reflect Octets and Symmetrical Size Features」、RFC 6038、DOI 10.17487 / RFC6038、2010年10月、<https：//www.rfc- editor.org/info/rfc6038>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[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>。
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, <https://www.rfc-editor.org/info/rfc8186>.
[RFC8186] Mirsky、G。およびI. Meilik、「双方向アクティブ測定プロトコル（TWAMP）でのIEEE 1588タイムスタンプ形式のサポート」、RFC 8186、DOI 10.17487 / RFC8186、2017年6月、<https：// www .rfc-editor.org / info / rfc8186>。
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.
[RFC8545]モートン、A。、エド。 G.ミルスキー編、「一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）の既知のポート割り当て」、RFC 8545、DOI 10.17487 / RFC8545、2019年3月、< https://www.rfc-editor.org/info/rfc8545>。
[BBF.TR-390] Broadband Forum, "Performance Measurement from IP Edge to Customer Equipment using TWAMP Light", TR-390 Issue 1, May 2017.
[BBF.TR-390]ブロードバンドフォーラム、「TWAMP Lightを使用したIPエッジから顧客機器までのパフォーマンス測定」、TR-390第1号、2017年5月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868]ケリー、S.、S。フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<https： //www.rfc-editor.org/info/rfc4868>。
[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016, <https://www.rfc-editor.org/info/rfc7750>.
[RFC7750] Hedin、J.、Mirsky、G。、およびS. Baillargeon、「Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol（TWAMP）」、RFC 7750、DOI 10.17487 / RFC7750、February 2016、<https://www.rfc-editor.org/info/rfc7750>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[STAMP-OPTION] Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-way Active Measurement Protocol Optional Extensions", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-option-tlv-03, 21 February 2020, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-03>.
[スタンプオプション] Mirsky、G.、Xiao、M.、Nydell、H.、Foote、R.、Masputra、A。、およびE. Ruffini、「Simple Two-way Active Measurement Protocol Optional Extensions」、作業中、Internet-Draft、draft-ietf-ippm-stamp-option-tlv-03、2020年2月21日、<https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-03> 。
[STAMP-YANG] Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-05, 25 October 2019, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-05>.
[STAMP-YANG] Mirsky、G.、Xiao、M。、およびW. Luo、「Simple Two-way Active Measurement Protocol（STAMP）Data Model」、Work in Progress、Internet-Draft、draft-ietf-ippm-stamp -yang-05、2019年10月25日、<https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-05>。
Acknowledgments
謝辞
The authors express their appreciation to Jose Ignacio Alvarez-Hamelin and Brian Weis for their great insights into the security and identity protection as well as the most helpful and practical suggestions. Also, our sincere thanks to David Ball, Rakesh Gandhi, and Xiao Min for their thorough reviews and helpful comments.
著者は、セキュリティとID保護に関する優れた洞察と、最も役立つ実用的な提案について、Jose Ignacio Alvarez-HamelinとBrian Weisに感謝の意を表します。また、David Ball、Rakesh Gandhi、Xiao Minのレビューと役立つコメントに心から感謝します。
Authors' Addresses
著者のアドレス
Greg Mirsky ZTE Corp.
グレッグ・ミルスキーZTE Corp.
Email: gregimirsky@gmail.com
Guo Jun ZTE Corp. 68# Zijinghua Road Nanjing Jiangsu, 210012 China
G UO Jun ZT Eco RP。68＃Z i essence road NaN京江蘇、210012中国
Phone: +86 18105183663
Email: guo.jun2@zte.com.cn
Henrik Nydell Accedian Networks
Henrik Nydell Accedian Networks
Email: hnydell@accedian.com
Richard Foote Nokia
りちゃｒｄ ふぉおて のきあ
Email: footer.foote@nokia.com